岩井 孝夫
佐藤 三智子
本記事は日経コンピュータの連載をほぼそのまま再掲したものです。初出から数年が経過しており現在とは状況が異なる部分もありますが，この記事で焦点を当てたITマネジメントの本質は今でも変わりません。 |
プロジェクトの推進では，「何をいつまでにどうするか」ということが明確でなくてはならない。このためにプロジェクト管理が重要になる。プロジェクトの失敗にはいろいろな理由があるが，管理者として一番重要なのは，全方位のコミュニケーションを取ることだ。すばらしい計画，高度な開発技術，性能の高いマシンを生かすには，それらを適材適所に当てはめていくことのできる“指揮者”のようなプロジェクト管理者が不可欠である。
中堅の製造業F社では長年使ってきた受注・物流システムの老朽化が目だってきた。そこで思い切ってリニューアルして再構築をすることになった。情報システム部門は社内にあるものの，小人数でありまた長年運用・保守業務が中心だったこともあって，システム構築には自信がない。このため，新システムの構築は全面的なアウトソーシングをする方針を固めた。複数のソフト会社から見積もりをとって業者選定を行った結果，旧システムを手がけ，Ｆ社の実情も熟知しているソフト会社のQ社を選定した。
全面的にアウトソーシングする，しかも委託先は気心の知れたQ社であるといっても，何から何まですべて任せ放しというわけにはいかない。情報システム部のU課長が今回の新システム構築プロジェクトのリーダーとなり，プロジェクト全体を統括するとともにQ社との窓口役を務めることになった。
大規模なシステム開発経験のないU課長は，プロジェクトの発足前にQ社の開発プロジェクト管理者のY氏からプロジェクト計画全体のレクチャを受けた。Y氏は受注システムや物流システムの構築にはかなりの経験があるベテランだったので，U課長も全面的に信頼していた。F社側で行うべき作業分担の調整，業務手順検討メンバーの選出，毎月1回の定例進ちょく連絡会議の開催といった役割をU課長はそれなりにこなしながら開発プロジェクトが進んでいった。
Q社は詳細設計に入った段階でユーザーの意見を取り入れて使いやすいシステムを作る目的で，画面設計に「プロトタイピング設計手法」を導入した。これは委託先の選定時からQ社の提案の目玉でもあった。U課長は，プロトタイピング設計に参画する者を現場から選抜してQ社の技術者との共同作業にあたらせた。こうして出来上がった画面を現場担当者が見ながら，使い勝手や業務の性格に応じて意見をいう形で作業は進んだ。
ところが月1回開かれる連絡会議での進ちょくレビューで問題が起こった。今月に作業が終了し成果物として提出されていなければならないはずの「新業務フロー概要」と「システム詳細設計書」がまだ提出されてこない。
会議終了後にU課長がY氏にその旨を尋ねると，「作業が若干遅れていますが心配ありません」という返事だった。気にはなったが，そのままにして翌月の進ちょくレビュー会議にのぞんだ。ところがこの月の会議でも完了の報告がない。しびれを切らしたU課長は，翌々月の進ちょくレビューで「大日程からみるとすでに2カ月遅れているが，本当に大丈夫なのか」と改めて確認した。
それから2，3日してF社の情報システム担当取締役のところに，Y氏から実情報告があった。内容は，「現場担当者を交えての画面設計で，F社側の検討メンバーから変更要求が相次いでなかなか意見がまとまらず，それが遅れの原因である」ということだった。
担当取締役を通じてY氏の報告を聞いたU課長は，自分を飛ばして報告がなされたことに立腹した。しかしすぐに冷静さを取り戻すと，指摘された問題をF社側の現場メンバーにヒヤリングしてQ社の担当SEの能力にも問題があったことを把握した。そこでF社側の対応のまずさを改善する一方で，Q社の担当SEにも交代してもらった。
あれやこれやで約3カ月の遅延を招いてしまった。しかし「最終納期には影響が出ない」とY氏が確約するので，U課長はそれを信じて開発を進めた。ところが頭初予定の本番開始4カ月前になって，Q社の開発責任者であるX氏から重大な相談ごとがF社に持ち込まれた。それはプログラム開発量の増加で納期遅延が発生するということであった。
原因はプログラム作成段階での仕様変更の多発である。F社の現場メンバーがQ社の開発担当と旧知の間柄であったため，気軽にプログラムの変更を依頼していた。Q社の開発担当者も旧システムの開発でも同じようなことがあったので，今回も予算増額は認められると思って勝手に引き受けてしまったことが判明した，
この話を聞いたU課長は激怒したが，プロジェクトを中止するわけにもいかず，壁に突き当たっている。
