【PM】平成21年度PM2問2

- IPA過去問リンク：平成21年度春 -

• プロジェクト名

ハードウェアリースアップに伴う、システム再構築プロジェクト

１．プロジェクトの特徴（８００）

１．１ プロジェクトの特徴（４００）

　これから、私が経験したプロジェクトについて述べる。 そのプロジェクトの対象システムは、Ａ市基幹システムの一部である住民の健康情報（妊婦健診の結果、がん検診の結果、乳幼児健診の結果、予防接種の接種履歴）を管理するシステムだ。

　Ａ市は、人口約５万人の地方自治体である。

　我々は、関東に本社を置く、従業員約６００人の会社である。主に地方自治体業務に特化したシステムの開発、販売、運用をしている。今回、ハードウェアのリースアップに伴うシステムの再構築プロジェクトを受注した。

　プロジェクト期間は１年３ヶ月（平成２５年１月～平成２６年３月）、弊社の要員はピーク時１０名、開発工数が１００人月。このプロジェクトに私はプロジェクトマネージャーとして参画した。

　今回のプロジェクトの特徴として以下を考慮する必要がある。 ユーザ要件として、１年３ヶ月後に控えたハードウェアのリースアップと同時に確実にシステムが稼働することが絶対条件となる。

１．２ システムの主要な品質目標と与えられた背景（４００）

　今回のプロジェクトは、これまで稼働していた汎用機からパソコンサーバに移行する。それがコスト面において現実的な選択とはいえ、これまで非常に高い稼働率を誇っていた汎用機から、パソコンサーバにおけるクライアントサーバシステムへ移行することにＡ市担当者は不安を抱えている。

　そこで、顧客の不安を払拭するため、旧システムと同様の稼働率を担保すること、それが品質上の目標となっていた。具体的な目標値は以下の通りである。

　①　定期メンテナンスを除き、不足の事態による許容停止時間を最大でも４時間とする

　②　１時間以上、４時間未満の障害発生回数は、年間２回とする

２．計画した、設計工程で品質を作り込む施策と品質を確認する活動（１２００）

２．１　施策の計画（４００）

　品質目標を達成するためには、プロジェクトの計画段階で、品質を作り込むプロセスと、品質を確認するプロセスをしっかり定める必要がある。特に今回は設計工程における品質の作り込みと、品質確保を重視している。

　そこで私は、まず設計工程において品質を作り込むにはどうすればいいかを検討した。

　一定の稼働率を確保するためには、ハードウェア、ソフトウェアを含めた全体的な構築の検討が必要だが、開発するソフトウェアのみを見ても、プロジェクトメンバの全員が、高品質を意識するとともに、同じレベルの成果物を作成しなければならない。そのような理由から、品質を作り込む為の施策の中で、設計標準の作成に力を入れることとした。

　まず、社内にある過去の類似システムや障害事例（特に設計ミスを起因にする事例）を数多く集め、それを参考に設計手順や考慮するべきポイントをまとめた。

　設計標準は、キックオフでメンバ全員に配布するとともに、１時間程度の時間を使用して誤解や認識相違が発生しないよう、自ら説明する計画とし、その後も定期的に説明会を実施する予定とした。

２．２　活動内容（４００）

　品質を確保するための活動内容について検討した。

　設計工程に置ける品質確認は、設計書のレビューにて実施する。外部設計書のレビューを実施する際、特に今回設定した品質目標を担保できるかという観点での確認を重視した。

　品質目標たる稼働率を確保可能かどうか、ハードウェアベンダの技術者やクライアントサーバシステムの開発に置ける専門家をレビューに参加してもらうことを考えた。コスト面においても半日同じ場所に集まり、一度に議論を実施すれば十分予算の範囲内に収まると考えた。レビューを半日で完了させるために、資料を事前に配布し目を通してもらうとともに、インスペクション形式で実施する計画も立てた。

２．３　活動結果として察知した問題点（４００）

　プロジェクトは順調に進み、設計工程の後半、外部設計書のバージョン０が完成した。そこで当初の計画通り、専門家を招集してレビューを実施することになった。

　専門家のレビューを実施すると、その経験者しかわからない細かいところでいくつも改善を実施しなければならない箇所が発覚した。その中には、ある条件下で品質目標を達成できないという問題点も指摘された。許容時間が４時間にとどめるどころか、１日たっても復旧がしないケースが発生するのではないかとのことだった。

３．特定した原因と品質を作り込む施策の改善内容について（８００）

３．１　特定した原因と品質を作り込む施策の改善内容（４００）

　レビュー時の指摘を受けて、原因分析を実施した。

　品質目標を確保できない重大な問題に発展するケースは全部で５つあった。その原因をそれぞれ調査すると、大元は設計標準の不備であることが確認できた。各設計書は、私が作成した「想定障害一覧表」を元に、そうした障害が発生するかしないかという視点で設計しているが、その一覧表にないケースだった。設計標準の不備と言える。

３．２　改善の成果及び残された課題（４００）

　原因が特定できたため、早速、設計標準の不備を修正し、それに基づいて設計するように指示を出した。その結果、レビューでの指摘事項は全てクリアされた。その後、プロジェクトは無事完了し現在も稼働しているが、品質目標を達成できない事態は発生していない。

　今回のケースは、品質を確認する工程を重視し、設計レビューをしっかり実施することで、何とか品質目標をクリアすることができた。しかし課題は残っている。

　今回のミスは、設計標準が不十分であったことによる設計工程での品質の作り込みが不十分だったところにある。これでは開発リスクはなくならない。

　そこで、次回からは設計標準そのもののレビューを設計工程に入る前に専門家に実施してもらう必要があると考えている。