1. 基幹システムを統合業務パッケージで再構築し，運用コストの1億円強削減を見込む。
2. プロジェクト初期のミスが尾を引き，本稼働をのべ1年間延期した。
3. 新プロマネの投入でコミュニケーションを回復し，チームがまとまった。

　「これでバージョン・ゼロがようやく完成した」――。東急建設 経営企画室 システムグループ リーダーの木吉博志氏は，2004年9月の中間決算を処理し終えた新システムをそう評価した。NECの建設業向け統合業務パッケージ・ソフト「C-BARX」をカスタマイズした新基幹システムの稼働後，利用者の混乱や細かいトラブルも収束し，本来の導入目的である新しい会計基準に沿った決算を達成できた。

　だが，ここまでの道のりは平坦でなかった（図1）。システム構築を請け負うNECと東急建設との間で，業務用語の不統一によりパッケージ・ソフトのカスタマイズの内容について意見が相違したり，2カ月間連絡が途絶えたりして，一時は危機的状況に陥った。

図1●ERPパッケージ（統合業務パッケージ）を使った基幹システムの本稼働を1年間延期
図1●ERPパッケージ（統合業務パッケージ）を使った基幹システムの本稼働を1年間延期
当初計画では2003年4月に本稼働する予定だったが，要件定義でカスタマイズ範囲について意見が分かれたことが尾を引き，2度の延期を余儀なくされた
[画像のクリックで拡大表示]

　この事態を収拾するため，ベンダーのプロジェクト・マネージャの交代や，カスタマイズ範囲の整理，コミュニケーションの回復に着手し，プロジェクトの立て直しを図った。その後も難題が生じて本稼働を2度延期せざるを得なかったが，それでも必要不可欠な機能を実装した形で新基幹システムの稼働にこぎつけた。

　これにより，運用コストを年間1億円以上削減できるなどの成果を上げた。「紆余曲折はあったが，NECはパートナーとして最良の選択だったと思っている」と東急建設の木吉氏は語る。

リストラでホストの維持が困難に

　プロジェクトの発端は，東急建設のリストラクチャリングにより，ホストを維持管理できなくなったことにある。情報企画担当の2人を残し，他のSE26人をグループ会社の東急コンピュータシステムに出向させた結果，「士気が低下して半数以上のSEが退職してしまった」（東急建設 経営企画室 課長代理 寺田憲治氏）。ホスト上のCOBOL基幹システムは500万ステップに膨らんでいたが，仕様書は運用を維持できるレベルでしかなく，システム全体を熟知するSEも減っていた。同社は「残されたSEだけでシステムを支えるのは無理」との結論に至った。

　システムの運用上でも，運用コストが年間2億8000万円に達していたことと，システムの複雑化により機能変更に「平均で4カ月間かかる」（寺田氏）ことが問題だった。加えて，この時期，東急建設は国際的な会計基準である「工事進行基準」（工事の進ちょくに応じた売上高，原価を各事業年度に計上する）の採用が急務だった。

　そこで3億円前後（本誌推定）を投じ，基幹システムをC-BARXなどのオープン系パッケージで再構築することにした（図2）。新システムでは他社と差異化を図るため原価管理は独自開発するが，工事進行基準に沿った会計処理を実現できる。運用コストも年間1億3000万円削減できると試算した。

図2●パッケージ中心のシステムに切り替える
図2●パッケージ中心のシステムに切り替える
旧システムは30年間にわたり自社開発してきた500万ステップのCOBOLアプリケーション。システム部門のリストラで自社運用が困難になったことなどから，パッケージ・ソフトを中心としたシステムに刷新

用語の相違などがトラブルを生む

　東急建設とNECは2001年12月にプロジェクトを立ち上げ，当初は2003年4月の本稼働を目指していた。しかし，東急建設，NEC双方の問題が絡み，プロジェクトは難航した（図3）。その原因の多くは，プロジェクト開始後の約半年間に起こった基本的な確認作業やコミュニケーションのミスに集約されていた。

図3●問題に手を打ちプロジェクトは一応好転
図3●問題に手を打ちプロジェクトは一応好転
ベンダー側が提案時に業務用語のすり合わせをしていなかったこと，ユーザー側が利用部門の代表者にパッケージ型開発の注意点を周知徹底しきれなかったことなどが，プロジェクトを進める上で問題を生んだ。結果的に2度の本稼働延期を許してしまったものの，プロジェクト・マネージャの交代などで状況は好転した
[画像のクリックで拡大表示]

　まず，NECはプロジェクトの初期で東急建設と用語の定義をすり合わせていなかった。2002年1月から3月まで，NECと東急建設はカスタマイズ対象範囲を機能ベースで確認していた。ただし，時間の制約があったため細かい内容までは立ち入れず，「大項目」のレベルで機能の有無を確認したに過ぎなかった。

　東急建設は事前に，旧原価管理システムのソースや設計情報，ロード・モジュールをNECに渡していたため，旧システムの用語とそれが意味する機能をNECが理解しているものとして話を進めていた。だがNECは，「アウトプットの有無くらいは調査したが，処理内容や操作性，現場業務の流れについては分析していなかった」（NEC側の責任者である，第二製造業ソリューション事業部長代理 安部保志氏）。

　また，東急建設側もホストの全体像を知るベテランがいなくなっていたため，「システムの詳細機能を含めた全体像をだれも分からない」（寺田氏）という状況だった。プロジェクトが進むにつれ，仕様の漏れが度々見つかった。

　用語と機能に対する認識の相違，ならびに業務分析の不足は，要件定義工程でカスタマイズの増加となって噴出した。一例を挙げると，「手形管理一覧」という言葉に対して，東急建設は旧システムでの「支店別に小計を出力する形」を想定していた。一方のNECは，パッケージ標準の「小計を出力しない」手形管理一覧を想定していた。

　支店別に小計を計算できなければ，東急建設にとっては使えない。「（パッケージ導入なので）帳票の体裁が変わるのは当然だと思うが，業務で利用できなければ意味がない」（寺田氏）。小計の機能を組み込むにはカスタマイズが必要だった。

　こうした要因を積み重ねると，東急建設が求めていた機能（旧システムの機能＋国際会計基準などの新機能）を実装するのに，カスタマイズ費用が予算を大きく超えることが分かった。