[ザ・プロジェクト]

2009年2月20日(金)川上 潤司（IT Leaders編集部）

佐々木 康
日本通運　通運部　課長

1991年に入社。貨物ターミナルや営業部での業務を経て、2005年から本社通運部に勤務。今回のプロジェクトでは、システム利用実態調査や業務要件の取りまとめ、ユーザーとの情報共有、操作方法の教育などを担当した。
 

長田 尚丈
日本通運　IT推進部

2003年に日本通運株式会社入社。情報システム部に配属され、 顧客企業とのEDI接続システムなどの開発・運用を担当。2006年にIT推進部勤務となり、今回のプロジェクトにはリーダーとして参加した

Photo ： 乾 芳江

 

— 2008年1月、通運向けの業務システムを刷新したと聞いています。

長田： 鉄道コンテナ情報システムですね。我々は、「RACS」と呼んでいます。

— どんなシステムですか。

佐々木： 通運業務で発生する情報を収集・処理する仕組みです。通運業務とは、集荷から配送までの過程で貨物鉄道を利用する輸送サービスのことです。

長田： ユーザーは、客先（荷主）からの集荷や貨物駅への配送、到着駅からの集荷、届け先への配送を受け持つ約160拠点の担当者です。顧客からの輸送オーダーを受けて荷物を集荷し、配達が完了するまでを、このシステム上で追跡できるんですよ。

佐々木： RACSはJR貨物のシステムと連携しているので、貨物を載せた列車の位置も把握できます。

— そのRACSを全面刷新した？

長田： そうではありません。RACSはメインフレームとオープンサーバーの二本立てで稼働させていて、今回刷新したのはサーバー上の帳票システムです。

— なぜ刷新に踏み切ったんですか。

長田： RACSは2000年から運用していますが、ここへ来てサーバー側のハードウェアがかなり老朽化していました。導入以来、機能追加を繰り返してきましたから。2006年時点でメモリの使用率は80％を超え、常時アラートが出ている状態。増設しようにも、拡張スロットはもういっぱいでした。

— 当時のハードウェアは？

長田： 富士通のGP7000F M600です（本誌注：CPUはSPARC64、クロック周波数は300MHz）。業務に支障は出ていなかったものの、これが性能的に限界を迎えつつあったんです。例えば処理が集中する月初には、夜間バッチに8時間かかっていた。

佐々木： レスポンスにも問題がありました。帳票によっては、画面に表示するまでに10分かかるものもありました。

長田： 一方で、帳票作成用のミドルウェアのサポート切れも近づいていたことも問題でした。

— プロジェクト開始はいつでしたか。

長田： 2006年8月に検討を開始。11月に、メインフレームとサーバーの2本立てという全体の構成は変えずに、サーバーのハードやソフトをバージョンアップするという方針を決定しました。

 

全面オープン化は非現実的だった

佐々木： 実は、ユーザー側からはメインフレームを撤廃してサーバーに一本化してほしいという声も上がっていました。そのほうが操作画面がシンプルになるからです。でも、時間的にも費用的にもそれは現実的ではなかった。

— 更新後のハードとソフトは？

長田： ハードウェアは富士通のPRIME POWER650、ミドルウェアはInterstage List Creatorです。

— システム刷新の方向性が決まって、次は何をしました？

佐々木： システムの利用実態を調べたり、ユーザーへのヒアリングを通じてニーズを集約し、新たに追加する機能の詳細を詰めていきました。

長田： 単にハードやソフトを入れ替えるだけでは、メリットがないですから。

— どんな機能を盛り込んだんですか。

佐々木： いろいろ新しくしましたが、その1つが発送業務の情報と到着の情報を、同じ画面で見られるようにしたことです。以前は、発注と到着は完全に別画面だったんですよ。それを一つの画面で“見える化”することで、業務品質の改善を狙えます。

長田： それ以外にも、紙の帳票を減らしたり情報の検索性を高めるために、帳票をデータのまま保管する期間を2カ月から1年に延ばしました。

佐々木： 帳票を印刷する用紙を専用紙から普通紙に変更して、用紙コストやプリンタ台数の削減も図りました。

— 用紙コストは分かりますが、プリンタが減ったと言うと？

佐々木： 専用紙は複写式なので、社内標準のレーザープリンタでは印字できません。このため、各拠点は帳票システムのためだけに別途ドットプリンタを設置しなければならなかった。帳票を普通紙に印刷できれば、ドットプリンタは不要になるんです。

長田： このほか、顧客からの輸送オーダーを連続登録できるようにするなど、操作性の向上も盛り込みました。もちろん、帳票そのものの種類も減らしました。内容が重複するものやほとんど使われていないものを削って、140あった帳票を120まで圧縮したんですよ。

—「この帳票はこんなニーズがあって作った」という思い入れから、帳票をなかなか減らせないというユーザー企業の話をよく聞きますが。

長田： その点、私は以前からこのシステムにかかわっているわけではないので、第三者の目で見られたんだと思います。「なんでこんな帳票があるんだろう？　ほとんど使われていないのに」とか「この帳票はこっちの帳票と同じじゃないか」とかね。

— 削減した帳票を使っていたユーザーから文句は出なかった？

佐々木： そういうユーザーには、別の帳票でも同じ役割を果たすことを私のほうから説明し、納得してもらいました。多少時間はかかりましたけど。

— ところで今のお話だと、長田さんは以前からRACSを担当していたわけではなかったんですね。

長田： このプロジェクトに参加するまでは、顧客とのEDIを担当していました。

— 最初は戸惑ったでしょう。

長田： 通運の業務知識はなかったですからね。でも、やるしかありません。社内の文書を読み、分からないことは周りのメンバーに聞きながら勉強しました。ただ、「こんな基本的なことを聞いたらまずい」ということは、インターネットで検索しました（笑）。

佐々木： 通運業務は、ほかの分野に比べて専門性が高いんです。コンテナ形式番号の体系や駅番号など覚えるべきことも多い。よくやったと思います。

●Next：通運業務ならではの事情で、開発期間は5カ月しかなかった