平成27年度 春期
プロジェクトマネージャ試験 午後II（午後2) 問題
の問１をといてみました。
すみません、かなり投げやりです。
前半の伏線を後半で回収できない、後半で関係ない話をしているなど、結構ひどいできです。
が、準備はここまで。
午前II(午前2)は無勉強でも7割は超える、午後I(午後1)も同様で、たまに難しいのがあるとそうとわかる状態。（＝難しいのは飛ばして、違うので7割前後をそろえられる）
午前I(午前1)はシステム監査の合格があるので免除です。
さて、日曜日はがんばりましょう。
設問ア (566文字)
本論文では、私が、所属するメーカーA社においてプロジェクトマネージャとして関与した資産管理システムBのサーバーリプレースプロジェクト(以下本プロジェクトと略す)を題材に、請負契約での調達について述べる。
１．プロジェクトの特徴
本プロジェクトでは、老朽化してOSのサポート期限切れを迎えるBシステムサーバリプレースを行った。
本プロジェクトでは費用低減が優先であり、新たなプログラム開発を極力排する方針であった。このため、サーバーとOSの更新に伴い必要となる最低限のミドルウェアのバージョンアップに伴う修正などのみを実施した。
本プロジェクトの特徴は、サーバー、OS、ミドルウェアのバージョンアップによるプログラムへの影響が事前に測れないという点にある。
２．請負で調達した範囲
本プロジェクトではインフラ構築の外部設計からシステムテストまでをC社へ請負で発注した。プログラムの修正に関しては企画段階では規模が不明確であり見積ができない点と、運用保守を行っているA社内の人的リソースを当てたいという考えから除外した。企画、要件定義に関してはベンダではコントロールが行えない部分であるためA社にて責任を持つ必要があった。また、移行に関してはプログラム修正による影響が大きいことから本契約には含めず、C社とは別途準委任契約を行って参加してもらう形とした。
設問イ (824文字)
３．管理において留意した点
請負での発注が他の契約と最も異なる点は
① ベンダには成果物責任がある。
② 指揮命令できない。
という2点である。このため、ベンダにして欲しい作業を明確に成果物に含める必要がある。進捗の管理、品質の管理のために行った工夫をそれぞれ述べる。
３．１．進捗の管理における工夫
請負での発注の場合、前出のとおり指揮命令ができない。このため、進捗の報告、フェーズゲートの設定を行った。
進捗の報告については、報告様式と粒度を定義することで各作業の進捗を誰でも明快に確認できる数値での報告とした。例えば主観的な％での報告は禁止した。また、進捗の議事録も成果物に含めることで、認識の相違がないことを文書で確認しながら進めることとした。
フェーズゲートについては、具体的には外部設計、内部設計などの各開発フェーズの完了時に成果物を確認するレビューとして設定した。これにより各フェーズでの残作業を明確にし、共有することでプロジェクト全体の問題として明らかにし、ベンダ内だけに埋もれさせないようにした。
フェーズゲートは品質の観点でも大きな効果を期待して設定したため、３．２でも再度触れる。
３．２．品質の管理における工夫
請負での開発におけるもっとも大きな問題は上流肯定での発注者側とベンダ側との認識の相違が訂正されないまま進捗し、納品において発覚することである。これを防ぐために本プロジェクトではA社提示のフォーマットでの成果物納入を求めるとともに、フェーズゲートで成果物の中間確認を義務付けた。
成果物のフォーマット指定については、各設計書において必要事項も定めることで設計の抜け漏れの予防になるとともに発注側のチェックにおける見逃しを防ぐことになる。
フェーズゲートについては、各フェーズでの成果物を現物で確認することで要件が具体化され、実装、テストでの確認までされていることを一貫して確認し、実現できない要件があれば早期に発見できるようにする目的も兼ねていた。
設問ウ (655文字)
４．管理の実施状況と評価、改善点
３と対応する形で状況と評価、改善点を述べる。
４．１．進捗の管理状況と評価、改善点
進捗管理のフォーマットに関してはおおむね適正に運用できたが、懸案事項があり解決方法を検討する場面では単なる遅延としての表現となりプロジェクト全体への影響が見えにくい面があった。
このため、マイルストーンを細かく設定し、ベンダ作業とプロジェクト全体のWBSとのリンクを取りやすくすることで改善ができると考えている。
４．２．品質の管理状況と評価、改善点
こちらもフォーマットについては有効であった。当初よりフォーマットを指定していたことで、C社のリーダーからも、求められる品質が明らかであり管理が容易になる、との意見があった。
フェーズゲートに関しては、ベンダよりも発注側で問題があり対応方法を急遽検討する必要が生じた。具体的に述べると、C社にて試行用環境を構築し、A社にて試行を行ったところ、新たなOSとミドルウェアの組み合わせではプログラムの修正が想定以上に必要となり、システムテストが当初予定通り完了できないことが判明した。
この結果としてシステムテスト完了時のフェーズゲートレビュー実施が困難になったが、最終的にはステークホルダーへ説明の上、ベンダ側の了承を取り、システムテストは一部作業をスコープ外として別契約をもって行うこととした。
今後は発注側事由による遅延についても契約に明記するとともにリスト登録簿に手管理し、事象発生時のコストへの影響も算出してステークホルダー、特にプロジェクトオーナーへ周知する。