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という問題をヤマト運輸はどう克服したのか。具体的に見ていく。