----------------------------------------------------------------------

　（問題発生プロジェクトへの新たな参画について）

----------------------------------------------------------------------


----------------------------------------------------------------------
（設問ア）
----------------------------------------------------------------------
１．プロジェクトの概要と参画時の問題状況
----------------------------------------------------------------------
１−１　プロジェクトの概要
----
　私が参画したのは、航空管制支援システムの開発プロ
ジェクトである。全国の空港、７箇所の管制センター、
航空会社などをネットワークで結び、飛行計画、気象情
報、航空機との交信情報などを処理する。また、気象庁
、防衛庁、国際的な航空管制ネットワークにも接続され
ている。重要な公共インフラのために高い信頼性が求め
られ、ホスト系は全て二重化、端末系もファイル／通信
サーバは二重化されている。
----
１−２　プロジェクト参画時の状況
----
　私がプロジェクトに参画したのは、顧客のシステム部
門による立会い試験が終了し、１ヶ月後に顧客の完熟運
用が開始される時点であった。その時点での問題発生状
況を以下に述べる。

（１）大幅なスケジュール遅延
　　立会い試験までにすべての開発が完了せず、顧客と
　調整して試験対象を制限して、試験を実施せざるを得
　なかった。
（２）多数の品質不具合が発生
　　社内でのシステム試験で１００件以上の不具合が発
　見された上に、対象を制限した立会い試験でも約３０
　件の新たな不具合が発見された。
（３）要員の士気低下
　　スケジュールの遅れを取り戻そうとして、深夜残業
　や休日出勤が常態化する状況が３ヶ月以上続いていた。
　要員に疲労が蓄積し、それが新たな品質不具合を発生
　させる悪循環に陥っており、士気が著しく低下してい
　た。
（４）顧客との信頼関係悪化
　　対象を制限して立会い試験を実施したにもかかわら
　ず不具合が発見されたために、顧客が不信を抱き、信
　頼関係が悪化していた。

----------------------------------------------------------------------
（設問イ）
----------------------------------------------------------------------
２．問題点の調査、分析と実施した対策
----------------------------------------------------------------------
２−１　問題点の調査
----
　私は、プロジェクト管理上の問題点を、以下の４点に
付いて調査した。
（１）品質不具合
　　障害報告書を調べて、発見された不具合をその原因
　と作りこまれたフェーズごとに集計するように指示し
　た。その結果、業務間インタフェースの仕様解釈が不
　一致や、その更新が徹底されないために作りこまれた
　不具合が多数を占めていた
（２）レビュー・テスト
　　レビュー・テスト記録票を調べて、レビュー・テス
　ト密度をチェックさせた。特にテストについては、テ
　スト実施の証拠の存在まで確認させた。その結果、１
　日に数十モジュールの設計書がレビューされたり、テ
　スト結果の証拠が残されていない事象が多数発見され
　た。
（３）構成管理
　　変更申請書を調べて、ベースライン凍結後の設計書
　とコードの変更回数と、その理由を分析させた。その
　結果、仕様変更を理由とする変更申請が最も多かった。
（４）プロジェクトの運営方式
　　プロジェクト運営方式を確認したところ、次のよう
　な問題点が判明した。
　　プロジェクトの体制は、業務機能ごとに５つに分け
　られていた。また、３回に分けてサービスを開始する
　のだが、業務グループが内部でリリースバージョンご
　とに分けられ、さらにホスト系と端末系に分けられて
　いた。グループの管理は、ほとんどサブグループが主
　体となっており、進捗会議もリリースバージョンごと
　に分けて開催されていた。
----
２−２　原因の分析
----
　私は、調査結果を以下のように分析した。
（１）サブグループが主体となって業務間インタフェー
　スや顧客との仕様調整を行っていたために、インタフ
　ェースの不一致や、他の業務への影響を考慮しない仕
　様調整が多発した。
（２）それらに対応するための修正作業によって、スケ
　ジュールが遅れていった。
（３）スケジュールの遅れを取り戻すために、レビュー
　やテストを簡略化するようになり、そのために品質が
　低下してさらなる修正作業を発生させている。
----
２−３　実施した対策
----
　私が、プロジェクト管理上の問題点を解決すべく実施
した対策は、以下の５点である。
（１）仕様調整チームの編成
　　各グループから代表者を選出して、業務間のインタ
　フェースや顧客との仕様調整を専任とするチームを編
　成した。そして、このチーム以外がグループ間のイン
　タフェース調整や顧客との仕様調整を行うことを禁止
　した。
（２）プロジェクト運営方式の変更
　　リリース時期ごとに実施されていた進捗会議を一本
　化すると同時に、出席者を正副２名のどちらかのみと
　して、グループの窓口も一本化した。また、全体の進
　捗会議の前日に、グループ内の進捗会議を実施させる
　運用に変更させた。
（３）スケジュールの再設定
　　完熟運用開始までに、残りの開発と不具合の対応を
　完了させることは不可能だと判断した。そこで、、完
　熟運用期間中に、数度に分けて順次不具合に対応や、
　残開発機能をリリースする計画を、顧客と調整して承
　認してもらった。
（４）要員の負荷管理
　　まず最初の１週間は、残業と休日出勤を全面的に禁
　止して、疲弊していた要員を休ませた。その後は、グ
　ループごとに残業時間や休出回数を把握し、プロジェ
　クト進捗会議において報告させることにより、要員の
　負荷状況を監視することにした。
（５）レビュー／テスト結果のチェック
　　レビュー／テストの管理をグループに任せていたの
　を改め、レビュー／テスト密度を監視することにした。
　特にテストについては、実施の証拠がなければテスト
　完了を認めないこととした。

----------------------------------------------------------------------
（設問ウ）
----------------------------------------------------------------------
３．問題解決活動の評価と今後の課題
----------------------------------------------------------------------
３−１　問題解決活動の評価
----
　仕様調整チームの編成により、これ以降は業務間イン
タフェースの不整合を原因とする不具合は発生しなくな
った。また、仕様調整に専任することによってチームメ
ンバの業務ノウハウが高まり、バックログとなっていた
顧客との仕様調整の効率も良くなっていった。
　分割リリースによってスケジュールが合理的になった
こともあり、レビュー／テスト結果のチェックで不合格
となることは少なかった。品質も安定し、分割リリース
ごとに実施された受入テストでは、１〜２件しか不具合
を指摘されなかった。
----
３−２　今後の課題
----
　プロジェクトにおいて問題が発生すると、直接的な事
象への対処に追われて、原因の追求が後回しになりがち
である。さまざまな失敗事例と成功事例を集積すること
によって、問題発生時の即応性を高めることが、今後の
課題だと考えている。