1. ソフト開発案件の工数管理を軸に全社的な業務システムを社内で構築
2. 要望だけが膨らみ続け，要件定義もままならない状態に
3. 段階的な開発に方針転換し，少人数のアジャイル型で完遂した

　「あのままでは開発を続けようがなく，おそらくプロジェクトは崩壊していただろう」——。こう振り返るのは，途中からプロジェクト・マネージャとして参画し，失敗しかけたプロジェクトの舵を切り直した，アンリツエンジニアリング 経営システム開発部 課長の佐藤誠則氏である。

　アンリツエンジニアリングは，全社的な業務システムの構築を自社で進めていたが，途中で開発が事実上ストップする危機に直面した。このトラブルに対し，佐藤氏を中心としたプロジェクト・チームは，マスター・スケジュールの組み直しや，ウォータフォール型開発をアジャイル型に切り替えるといった手を打つことにより，プロジェクトを無事完了させた（図1）。

図1●新システムに実装する機能と直面したトラブル
図1●新システムに実装する機能と直面したトラブル
ソフト開発案件の「工数管理」と「原価計算」を中心に，全社規模の業務システムを構築した。要件定義がまとまらず，プロジェクトは危機にひんしたが，コア部分を優先開発するなどの対策で乗り切った
[画像のクリックで拡大表示]

要件定義がまとまらない！

　同社は，通信関連の測定器や試験機器を製造するアンリツのグループ会社である。主にこうした機器の組み込みソフトの開発を手がけている。だが，自社の業務システムはほとんど未整備で，個人や各部門が独自にExcelやAccessデータベースで業務データを管理している状態だった。

　そこで，「個々のソフト開発案件のコストを管理したい」という要望を起点に検討を始め，結果として全社的なシステムの構想に至った。コスト管理の核になるのは「工数管理」「勤怠管理」「プロジェクト管理」の三つ。これらに関連する労務や経理のシステムもプロジェクトのスコープに含めた。関係部門は多岐にわたるが，各部門へのヒアリングを通じて，プロジェクト・チームは多くの要望を集めた。

　しかし，ここでプロジェクトの成否にかかわる問題が起こる。メンバーが集めた要望をうまく整理できず，要件定義が収束しなくなってしまったのだ。最大の問題点は，プロジェクトの体制作りにあった。プロジェクトの進ちょくを追っていくと，その迷走ぶりがうかがえる（図2）。

図2●プロジェクトの経緯
図2●プロジェクトの経緯
[画像のクリックで拡大表示]

　このプロジェクトは2003年2月に発足した。2004年4月の稼働を目指していたが，当初のメンバーは必要人数を下回る2人だけで，プロジェクト・マネージャはいなかった。

　このプロジェクトでは，システムをオープンソース・ソフトで開発することが決まっていたので，経験のある技術者を求めていた。しかし，社内の技術者約230人の中で，「オープンソースを扱える技術者はまだ少数で，彼らの手が空くのを待たなければならなかった」（佐藤氏）。このため，最初に必要な数のメンバーを確保できなかった。プロジェクト・マネージャが不在なのも同じ理由による。

　これに加え，このプロジェクトで求められるスキルと各メンバーのスキルとの間にミスマッチがあった。同社が手がける開発案件は組み込みソフトが圧倒的に多く，それらの案件では要求仕様がきちんと決められていることが多い。メンバーはこういう仕事に慣れていたが，今回のように「要求仕様をユーザーの要望から作り上げることには慣れていなかった」（佐藤氏）。

　これでは集めた要望をうまく整理できないのも無理はない。「すべての要望が等価値になってしまい，優先度を設定して，取捨選択することができなかった」（経営システム開発部 グループリーダ システムエンジニアの小笠原健一氏）。その結果，当初の予定通りに進んでいれば2003年10月から詳細設計とプログラミングを始めているはずだったが，実際は「せいぜい画面のレビューをしていた程度」（小笠原氏）と，作業が大幅に遅れていた。