1. 届け先を管理する新設のDBサーバーで、バッチ処理時間が想定の6~7倍と判明
2. 一括ロードツールを使い、メモリー上での処理を活用して1時間以内に収めた
3. SOAサービスの粒度は、カスタマイズの手間を減らすため単純な機能単位にした

 「1時間が要件のバッチ処理に当初、6~7時間もかかった。工夫を重ねて、ようやく時間内に収められた」(ヤマトシステム開発 グループソリューションカンパニー 次期NEKOプロジェクト マネージャー 田中諭氏)。

 ヤマト運輸が5年ぶりの刷新を進めている基幹システム「第7次NEKOシステム」。住宅に送る「宅配」から、住宅に住む個人の都合に合わせて送る「個配」を目指したものだ。2010年9月には、送り状に記載された届け先の個人名や住所などを登録した「届け先DBサーバー」を新たに稼働させた。これまで送り状に書かれた届け先は、郵便番号など一部の情報しかシステムに登録していなかった。

 届け先情報をDBに登録することで、配送品質を高める狙いだ。例えば、同じ日(時間帯)に配達する複数の荷物を別々に届けてしまう「口割れ」を防げる。これまでドライバーは、営業店に届いた荷物の届け先を基本的に目視で確認して、口割れを回避していた。新システムでは届け先の個人名などまでDBに登録し、異なる荷主からの荷物であっても、どれを同時に届けるべきか把握可能にした。ドライバーは携帯端末にその情報を取り込み、荷物の伝票をスキャンしてチェックする。

 届け先DBサーバーのもう一つの狙いは、法人顧客へのサービス向上である。例えば届け先の個人名などを指定して、Webサイトで配送状況を調べる機能を追加した。届け先情報は過去3カ月分を記録し、荷主が配送地域の傾向分析などを行えるようにする。

 これらの価値を提供する届け先DBサーバーだが、その開発は容易ではなかった。冒頭のコメントのように、夜間のバッチ処理時間が大きな問題になったのだ(図1)。

図1●ヤマト運輸の「第7次NEKOシステム」の構築で直面した課題
送り状の届け先を管理する届け先DBサーバーでバッチ処理が終わらない、SOAサービスの粒度の定義方法が分からないという課題に直面した
[画像のクリックで拡大表示]

 さらに今回の新システムの開発では、同社として初めて「SOA(Service Oriented Architecture)」を採用したが、そこにも問題が発生した。サービスの粒度をどう決めればよいか、分からなかったのである。バッチ処理とSOAという問題をヤマト運輸はどう克服したのか。具体的に見ていく。

この先は会員の登録が必要です。今なら有料会員(月額プラン)が2020年1月末まで無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら