システム構築は，推進者の力量が問われる作業である。特に多数の人々がかかわる場合は，さまざまな意見が噴出してまとまらないことが多い。そうした時に推進者は，しっかりした姿勢を維持し，特定の人たちの言いなりにならないように気を付けねばならない。どのような場合にも，推進者の決断が早ければ早いほどロスは少ない。決断が間違っていても早く気づけば間違いを正せる。システム構築の成否は推進者のパワーと決断力にかかっている。

本記事は日経コンピュータの連載をほぼそのまま再掲したものです。初出から数年が経過しており現在とは状況が異なる部分もありますが，この記事で焦点を当てたITマネジメントの本質は今でも変わりません。

　金属加工業のT社は営業システムの刷新を計画した。見積もりから受注，製造，販売，売掛金管理にいたるまでの流れに一貫性を持たせ，製造サイドが常に早めに情報をインプットして原材料や物流の手配までできるようにしたいという狙いがあった。

　新営業システムは，T社にとって全社的なシステムになる。その重要なシステムの開発の指揮をとったのは情報システム部門の新任課長のS氏である。S氏は課長になる前はシステム開発を担当していたので，プロジェクト・マネジメントの経験が浅い。そのため，情報システム部門の本部長の指示で，計画段階ではシステム・コンサルタントの支援を仰ぐことになった。

　早速，営業業務の改善を前提として現状調査から課題の抽出，解決案の策定までの作業を行うことになった。システム・コンサルタントは，営業本部のトップである取締役営業本部長をはじめとして，営業本部のマネジャやキーマンへのインタビューを行った。そこから新システムへの要望と業務の改革の方向性をつかみ，基本計画書としてまとめた。

　基本計画書には新しい業務フローや帳票類も含まれていた。エンドユーザーにもチェックをしてもらい，入力方法への要望などもよくまとめてあった。このような手順で「新営業システム基本計画書」が作成され，経営陣にも説明された上で，関係者に配付された。

　計画段階が終了して開発段階に入ると，複数のベンダーから提案があった。提案内容はさまざまであったが，以前からT社のシステム化を担当してきたF社が基本計画書の機能をほぼ満たすパッケージを提案してきた。費用的にも安かったのでF社に依頼することになった。その際にシステム・コンサルタントからの助言で，新営業システム基本計画書の内容を説明する機会を設けて，これまでの検討の経緯，新システムの目的・実現目標などをF社に理解してもらうことになった。

　しかしF社は，できる限り早く安く仕上げるために，ドキュメントや説明会を極力省きたいと提案してきた。プロジェクト・リーダーのS課長は期間とコストを削減できるのであればそれにこしたことはないと，この提案に飛びついた。コンサルタントからは「安易なプロトタイピング手法は危険である」と再三注意を受けたが，実績のある会社ということもあって，全面的にF社の意向に沿う形で開発が始まった。

システム開発の失敗が責任問題に

　開発が始まるとF社から連絡がほとんどない状態が続いた。画面のプロトタイプが出来上がるまでなにも見ることができない。開発の進ちょく状況の報告もないので，何がどうなっているのかがさっぱりわからない状況が続いた。営業本部からは事あるごとに催促や問い合わせがくる。情報システム部門の本部長からも進ちょく状況の問い合わせがくる。S課長はその都度F社に問い合わせるのだが，「プロトタイプ手法で開発するので，ドキュメントは出さないことを了承してもらったはずだ」，「費用もその分安く抑えてあるので，これ以上負担のかかることはできない」といわれてしまった。

　ようやく画面が出来上がって打ち合わせをすると，当初考えていた機能が入っていなかったり，入力データのつながりがわからなかったり，帳票ができていないためにデータの出力イメージがわかないなど，さまざまな不都合が生じてきた。営業部門の現場担当者に見せたところ，「基本計画書段階の話しと違う」といって作り直しを要求された。S課長がそれをF社に伝えると，「パッケージの性格を考えると，そうした作り直しは意味がない。どうしてもカスタマイズをするなら別途費用が必要」とコストを楯に頑として譲らない。

　途中で計画書作成に携わったシステム・コンサルタントに助言を求めると，「このまま何のドキュメントもなく，進ちょくもわからずにシステム開発を進めると本来求めていたものとかけ離れたシステムになりかねない。そうなってから手直しをしようにも，どうしようもない。少なくとも基本計画書の仕様がきちんと入っているかどうかは検証できるような仕組みにしないとだめだ」と言われた。なんとかF社に頼み込んでコンサルタントと話し合う場を持ってもらった。ところがF社は「うちはT社と契約しているのであって，コンサルティング会社の言うことを聞く必要はない」と強硬だった。

　結局，F社が当初約束した6カ月という開発期間は大幅に遅れ，8カ月近くたっても本番稼働ができない状態だった。F社側は「T社側の要求仕様の変更が多すぎたのが遅れの原因で，こちら側にミスはない」という態度を崩さない。10カ月目にようやく稼働に漕ぎつけた。現場の営業部門からは散々の評価で，「入力しづらい，項目が多すぎる，時間がかかる」などの文句が山のように出てきた。社内でも今回のシステム化が問題になっている。何が原因でこのような状態になったのかという責任問題に発展しそうである。