*下記はPDFよりテキストを抽出したデータです。閲覧はPDFをご覧下さい。

SEPTEMBER 2005 38 日本全国に点在するガソリンスタンドの数 は五万軒近い。
価格競争の激化などから、九 四年をピークに年々減り続けてはいるものの、 まだコンビニエンスストアより多い。
これら のガソリンスタンドへは、石油元売り会社の 油槽所からタンクローリーによって給油が行 われている。
製油所から油槽所までの一次輸 送を経て、ここから改めてエンドユーザーへ と至るのがバルク輸送（包装を施さないばら 貨物の輸送）の流れだ。
石油のバルク輸送の分野で国内最大手のニ ヤクコーポレーションは、ガソリンスタンド のほか工場やビル、病院など、燃料の大口ユ ーザーを中心に全国に八万カ所の配送先を持 つ。
顧客である元売り会社や商社、特約店の委託で、ガソリン、軽油、灯油、重油などの 石油製品をこれらのユーザーのもとへ配送。
日に一万件のオーダーをこなしている。
配送基地となる「車庫」を全国七〇カ所に 設け、北海道から九州までの七支店で業務を 管轄している。
タンクローリーの保有台数は 二四〇〇台と業界最多。
グループ会社六社の 保有台数を合わせると三〇〇〇台以上の専用 車両を運用している。
ほかに三五〇社の協力 会社が保有する七〇〇台の車両も、同社の配 送業務の一端を担っている。
「車庫」から支店へ業務を統合 ニヤクコーポレーションは、配送に伴う一 連の業務、すなわち受注から配車・輸送指 石油バルク輸送の統合管理を実現 顧客や協力運送会社と情報共有 石油のバルク輸送最大手のニヤクコー ポレーションは、3年前から配送業務の 統合管理システムを導入している。
特有 の受注・配車形態をとるバルク輸送の分 野で初めて、システム上の業務統合を実 現。
子会社のニヤクシステムサポートが 開発した仕組みを使い、これまでに350 社の顧客、200社の運送協力会社と情報 を共有しながら効率化を進めている。
ニヤクコーポレーション ――情報システム 39 SEPTEMBER 2005 示・実績管理・請求までの業務を統合管理 するため、二〇〇二年七月に「ＢＵＳＳ （ Bulk Haul Management Support System）パッケージ」と呼ぶシステムを本格 稼動させた。
同社の情報システム子会社であ るニヤクシステムサポートが日本ＩＢＭと共 同で開発したものだ。
従来のシステムでは、配送業務を支店ごと に分散管理する方法をとっていた。
七〇カ所 の「車庫」で顧客からの受注情報（配送依 頼）を入力して配車を組み、配送の実績を管 理する。
事後に管轄支店にこのデータを集め て、支店で運賃計算やドライバーの給与計算 を行い、請求書を発行して売り上げを本社に 上げるという流れになっていた。
支店ごとの仕組みだったため、運用も支店 によってまちまちだった。
なかには、受注情 報の入力を省いて配車を手作業で行い、実績 だけをシステムに入力しているところもあっ た。
こうした運用でも、支店での運賃計算や 請求書の作成には支障はなかったが、全社的 に見ると、データ が合わなかったり、 処理に時間がか かるなどの問題が あった。
また、シ ステムが分散して いたためメンテナ ンスの手間もかか った。
そこでニヤクコーポレーションは、「ＢＵＳ Ｓ」を導入。
システムを従来の分散管理方式 からサーバーによる一元管理方式へ変更し、 同時に業務態勢の見直しを図った。
それまで「車庫」で行っていた受注・配車 業務を支店に統合。
支店で受注情報を処理し、 配車計画を作成してサーバーへ送る体制へと 改めた。
「車庫」では、インターネットを経 由してパソコンの画面でこの配車計画を見な がら、まずドライバーの登録を行う。
ここか ら輸送指示書や配車表を作成することによっ て、受注から配車までを管理する。
システム化の前提は標準化 ただし、一元管理方式に切り替えても、従 来のように支店によって運用方法が異なって いるようでは意味がない。
「ＢＵＳＳ」の開 発にあたって、ニヤクシステムサポートが最 も重視したのはこの点だった。
支店の運用に差がでるのは、支店によって 顧客や車両台数に違いがあるといった理由の ほかに、バルク輸送が特有の受注・配車形態 をとることも一因になっていた。
ニヤクコーポレーションが受託する配送業 務には、二通りの受注・配車パターンがある。
一つは、特定の顧客に専属車両を提供して配 送を行うケース。
元売り会社からの受託は大 半がこの形態をとり、配送件数全体の六〜七 割を占める。
配車計画は元売り側が作成する ため、同社はこれに従って配送を行い、実績 だけを管理する。
二つ目のケースは、残りの三〜四割を占め る商社や特約店からの受託だ。
この場合は、 ニヤクコーポレーション自身が受注情報をも とに配車計画を作成するが、特有の受注・配 車形態というのはこの部分を指している。
元 売りからの受託と違って、商社や特約店から の受託は、配送の依頼主と出荷元が違う。
積 荷は元売り会社の油槽所から出荷される。
顧 客から配送依頼を受けた運送会社は、顧客が 元売りに発注した製品を出荷元の油槽所まで 引き取りに行き、ユーザーへ配送する。
従って、受注を処理する際には、配送先だ けでなく出荷元も確認する必要がある。
この 処理を行わないと、「車庫」や協力運送会社に配車指示ができない。
一方、引き取り先で ある元売りの油槽所にも、顧客を通じて引き 取りに行く運送会社や車両番号などの配車情 報を伝えておく必要がある。
取引によっては 複雑な流通経路をたどるケースもあり、確認 作業も煩雑になる。
このように受注処理の際に、顧客や協力運 送会社などとの煩雑なやり取りを伴うため、 バルク輸送ではこれまで受注業務のシステム 化が難しかった。
ニヤクコーポレーションも 従来のシステムでは入力項目を限定していた。
業務を標準化しにくく、それが運用の差にも つながっていた。
「ＢＵＳＳ」は、こうしたバルク輸送の特 性に合わせて、あらゆる受注項目をシステム 受注・配車センターの業務の様子 に取り込めるようにした点に大きな特徴があ る。
従来は口頭や手書きでしかやりとりでき なかった情報についてもシステムに入力し、 必要に応じて顧客や協力運送会社と情報を共 有できるようになっている。
システム自体に こうした対応力を持たせるとともに、運用に バラツキがでないよう、受注情報が入力され ないと実績管理ができない仕組みを導入。
こ れによって、あとから支店が実績を入力する といった方法をとれないようにした。
さらに、システムの導入に当たってニヤク システムサポートでは、ニヤクコーポレーシ ョンのメンバーと一緒にチームを組んで、受 注処理などについての細かな業務マニュアル を作成した。
例えば、電話でオーダーを受け る場合には、いったん手書きでメモを作成し てから入力する。
その際、メモの記入は統一 フォーマットに従って行う。
また受注情報は その都度一件ごとに入力する、といった具合 にルールを設けて業務の標準化を図った。
配車は人手の方が早い 受注処理が終わると、ここでの情報をもと に「ＢＵＳＳ」のサブシステムとして導入し た配車支援システムによって配車計画を立て る。
受注情報から配送先を画面の地図上に表 示して、配車担当者が組み合わせながら配車 を行う仕組みだ。
配送時間をシミュレーショ ンしたり、車種などが事前に登録した内容と 合わない場合にアラームを出す機能はあるが、 いわゆる自動配車システムではない。
タンクローリーは、タンクの中が四〜六つ に仕切られており、一度に複数種類の製品を 積むことができる。
そこで配車の際には、一 台のローリーに複数の顧客のさまざまな製品 を混載して実車率を高めるよう工夫している。
「ＢＵＳＳ」による配車の対象は、基本的に 商社や特約店からの受託配送で、複数の顧客 の製品を積み合わせるケースが多い。
オーダ ーごとに引き取り先が複数になることもあり、 場合によっては三カ所で積んで四カ所で降ろ すといったようなケースも出てくる。
また取引上の慣習で、積荷の引き取り先の なかには、事前に登録した車両でないと引き 取りに応じないところもある。
ニヤクシステムサポートでは、こうした複 雑な配車を自動化するのはかえって非効率と 判断した。
「配車というのは?オール・オア・ ナッシング〞に近く、九割方うまくできても 残りがだめならもう一度やり直さなければな らない。
機械で配車したものは（そのロジッ クが見えないだけに）あとから人手で組み換 えようとすると大変な時間がかかってしまう。
むしろ最初から人手でやるほうが早い」と同 社の田川信也システムサポートグループマネ ージャーはその理由を説明する。
「ＢＵＳＳ」は、配車支援システムのほか に、車載端末による運行管理システムとも連 動している。
車載端末によってドライバーへ の配送を指示し、位置情報や車両の稼動状況 を収集。
配送が終了した後に、収集したデー タを「ＢＵＳＳ」のサーバーへ吸い上げて実 績を管理する。
これをもとに運賃計算をして 請求処理をし、さらに同じデータを使ってド ライバーの勤怠管理まで行う。
翌日には運賃収入がわかる ニヤクコーポレーションでは、二〇〇二年 の七月までに配車支援システムと運行管理シ ステムを立ち上げて「ＢＵＳＳ」をフル稼働 させた。
当初は、同社とグループ会社の車両三〇〇 〇台だけに端末を搭載して運用していたが、 翌二〇〇三年の秋からは協力会社の車両にも 対象を拡大した。
ニヤクコーポレーションの協力会社のなか には受託した配送業務の配車組みを自ら行う ところもあるが、協力会社の車両の八割以上 については同社が配車計画を立てている。
従 来は、作成した配車計画をファクスで協力会 社に送っていたのだが、「ＢＵＳＳ」ではイ ンターネット経由で提供する。
この配車計画 に対して、協力会社は配車する車両の番号を 入力して、インターネット経由でニヤクコー ポレーションに返すだけでいい。
さらに「ＢＵＳＳ」によって、配送実績を もとにただちに運賃計算が行われるため、協 力会社は配送の翌日には車両の運賃収入を確 認することができるようになった。
三五〇社ある協力会社のうち、すでに二〇 SEPTEMBER 2005 40 41 SEPTEMBER 2005 〇社が「ＢＵＳＳ」とインターネットで接続 している。
「予想していた以上にシステムを 活用してもらうことができた。
協力会社から は、便利になったとおおむね好評を得ている」 （田川マネージャー）という。
一方、顧客との間でも「ＢＵＳＳ」による 情報の連携が順調に進んでいる。
これまでに 三五〇社からインターネット経由で受注情報 を入手できるようになっている。
また、配送の六割以上を占める元売り会社 からの受託業務についても、顧客とのＥＤＩ 化を推進してきた。
元売り側で作成した配車 情報をＥＤＩで「ＢＵＳＳ」に直接取り込め るようにして、情報を取り込んだ後は、実績 管理・請求までの業務を「ＢＵＳＳ」で一元 管理する。
すでに現在、顧客側が作成する配 車計画の七〜八割程度までをＥＤＩで入手で きるようになった。
「ＢＵＳＳ」による業務の統合、顧客や協 力会社との情報共有によって、業務の効率化 と迅速化は確実に進んだ。
かつての分散管理 体制のもとでは、車庫から支店に実績データ を送信して、支店で運賃計算が終了するまで に二日かかっていたのが、「ＢＵＳＳ」を導 入してからは一時間ほどで処理している。
一 週間近くかかっていた請求書の作成期間も、 大幅に短縮できた。
受注・配車担当者を六割減 また、「ＢＵＳＳ」を導入する以前のニヤ クコーポレーションでは、全国七〇カ所の車庫に合わせて八〇人近い受注・配車担当者を 配置していた。
「ＢＵＳＳ」の導入とともに 業務を車庫から支店に集約し、さらに今年に 入ってから郡山と高松に専門の基地を設置。
北海道を除くエリアを東西に分けて、全国三 カ所で受注・配車業務を手掛けるようにした。
この統合によって、要員を三〇人にまで削減 することができた。
従来は車庫によって車両の稼働率に多少の バラツキもあったが、配車の広域化によって バラツキが解消し、稼働率も上がってきてい るという。
また、請求業務についても全国一 カ所に集約し、ニヤクシステムサポートに委 託する予定で、今年の七月からテストを実施 している。
石油バルク輸送の分野で「ＢＵＳＳ」のよ うな配送管理をパッケージ化したシステム開 発の事例はまだ他にはない。
ニヤクシステム サポートは、ニヤクコーポレーションの情報 システム部門が独立した会社で、システム開 発を担当するメンバーはすべて親会社で配送 業務の実務経験を持つ。
田川マネージャー自 身もかつて配車を担当していた。
「ＢＵＳＳ」の開発にはこうした経験が活 かされている。
特異な業務を手掛けていなが ら、運用を協力運送会社や顧客に広げること ができたのは、開発担当者の業務への理解の 深さによるところが大きい。
これまでニヤクシステムサポートは親会社 のシステム構築をすべて手がけてきた。
しか し「ＢＵＳＳ」の開発では、概要設計と基本 設計およびテストだけを担当し、プログラム 開発などは外部に委託した。
また昨年からは 提携でＢＵＳＳパッケージのＡＳＰ方式によ る販売も開始。
初の外販に乗り出している。
田川マネージャーは「情報の専門会社とい うよりも、業務経験を活かして親会社やほか の運送会社の業務とシステムとの橋渡しをす ることで、実態に合った開発を進めていくこ とに我々の使命があると思う」と語る。
「Ｂ ＵＳＳ」の開発は、情報子会社としての今後 の生き方への自覚を促す契機にもなったよう だ。
（ フリージャーナリスト・内田三知代）