• 2019年3月20日水曜日
アリスト戦記
アリスト戦記 https://blog.aristo-solutions.net/2019/03/26.html

【サンプル論文】プロジェクトマネージャ 午後Ⅱ 問1 平成26年

今日も論文の勉強をしたが、果たしてこれで良いのか……。
どうもイマイチ手ごたえが無い。

プロジェクトマネージャ 午後Ⅱ 問1 平成26年

設問ア
1.プロジェクトの特徴と見積もりについて

1.1 プロジェクトの特徴

私は、神奈川県の独立系ITベンダ企業に勤務するプロジェクトマネージャである。今回、私が論述するのは、私が2014年にプロジェクトマネージャを務めた「公共事業系作業支援システム」の新規開発案件である。
 クライアントである某公共機関(以下、クライアント)は、日常業務の殆どを手作業で行っていたが、その中の主要な一つをシステム化することで作業効率を改善するため、本プロジェクトが立ち上がった。
 システムの大まかな内容はクライアントが作成したRFPにより提示されており、開発規模は約50画面。画面はWebシステムで実現する。開発期間は6ヵ月。これに対してより具体的な提案書と見積もりを作成し、入札に成功すれば受注となる。
 特徴としては、このRFPでユーザが快適な操作性を強く要望していることだった。通常、業務系システムはバックエンド処理を重視しフロントエンドには重きを置かないものだが、このプロジェクトはフロントエンドに強い要望があった。しかし、我が社はフロントエンドの開発は余り得意としておらず、この部分にスキル面でのリスクであると当初から考えられていた。

1.2 見積もりのために入手した情報と見積もり時期

上述のとおり、本件は入札案件であるから、見積もり作成は入札の直前、プロジェクト開始前だ。インプットとなる情報はRFPだ。このうち、フロントエンドに関する部分を分析すると、新規開発するシステムはWebシステムだが、その操作性、インターフェースはクライアントアプリに近いものにしたい、という内容だった。
 そこで私は、提案書にWebシステムでクライアントアプリに近い挙動を実現するグラフィカルなインターフェースについて記載した。当然、見積もりにはそれを実現する為の工数を盛り込むことになる。

設問イ
2.工数の見積もり方法と工夫

2.1 工数の見積もり

本件の見積もりはプロジェクト開始前で基本設計も固まっていなかったが、RFPの記載から、開発対象となる画面数は凡そ50画面であることは確度の高い情報だった。この50画面について、画面毎に重み付けを行い、それらを合計した数字が見積もり金額のベースとなる。
 我が社の生産性基準値では、特に理由が無ければ、Web画面の実装工数は3人日、単体テスト工数は2人日、合計5人日で1画面を製造する。設計と結合テスト、総合テストを踏まえた全体の工数は製造工数の2倍だ。
 しかしながら、本件の開発にはグラフィカルなインターフェースを提供する必要がある。製造工数5人日という我が社の生産性基準値は静的な画面で算出された値であるため、グラフィカルなインターフェースを開発する為の工数が含まれておらず、本プロジェクトの生産性基準値としてはそのまま採用は出来ない。
 分析の結果、全50画面のバックエンド処理はそれほど我が社の標準を逸脱するものではなかった。見積もりを左右する不明点は、グラフィカルなインターフェースを開発する工数をどの程度積むべきか、ということだけだ。

2.2 工夫したこと

私は他のプロジェクトの実績からグラフィカルなインターフェースを開発する為の基準値を探そうとしたが、社内にそのような実績は少なく、信用に値する数字は得られなかった。また、社内に実績が少ないということは、社内スキルも不十分であることを意味しており、開発に突入してから予想以上の工数が必要となるリスクも懸念した。
 そこで私は、調査フェーズとしてメンバーを1名追加し、その者にサンプルの先行開発を命じた。このメンバーは通常の開発であれば社内標準の生産性基準値に近い生産性を有していることは分かっていたため、このメンバーがサンプルを開発することで社内標準の生産性基準値と本プロジェクトの生産性基準値を比較することが出来る。
 その結果、1画面の製造に社内標準の2倍である10人日を要した。2倍は多過ぎると感じてヒアリングしたところ、10人日には調査が含まれており、類似した画面をもう一度作るのであれば7.5人日で製造可能だと回答を得た。
 従って、私は本プロジェクトの生産性基準値は社内標準の1.5倍であると設定し、見積もりを作成した。
 画面規模は50画面。1画面辺り15人日。そこに調査コストや提案書作成コスト、営業コスト、リスクも踏まえ、全体を60人月として見積もりをクライアントに提出した。
 結果、妥当な内容だと判断され、受注に成功し、プロジェクトをスタート出来た。プロジェクト期間は2014年4月~9月の6ヵ月だ。

設問ウ
3.プロジェクト運営の施策と評価

3.1 運営面での施策

プロジェクトスタート後、私はその進捗実績をEVMで管理した。社内標準の1.5倍と置いたこのプロジェクトの生産性基準値と差異が無いかを確認する為である。
 その結果、プロジェクトスタート当初から作業に遅延が見られた。残業でカバーすることで進捗率は維持しているが、残業時間を踏まえれば生産性が20%ほど低い計算となる。この残業を長期的に続けることは要員の体調面でリスクであり、さらなる生産性低下を招きかねないため、早急に対策が必要と判断した。
 メンバーにヒアリングを行い分析した結果、生産性が低い原因はシステム開発標準の不備にあると分かった。我が社はグラフィカルなインターフェースの開発経験が少ないため、開発標準にその部分の記載が無い。
 そこで私はプロジェクトスタート前にサンプルを開発したメンバーに開発標準の補強を命じた。開発標準の作成には一週間が必要で、このメンバーはその後もチーム全体のフォローアップに回る配置に変更した。そのリカバリーには翌月より要員1名を追加することで対処した。追加要員は製造完了までの3ヵ月間稼働したため、合計で3人月の追加コストとなったが、これはプロジェクトのバッファコストで収まる範囲内だった。

3.2 実施状況及び評価

開発標準の作成で一時的に遅延していたスケジュールも、開発標準の完成とフォローアップ体制の整備、および要員追加の対策により、基本設計が完了する2ヵ月目の末までにはリカバリーに成功した。それ以降のチーム全体の生産性は見積もり通りの数字に安定した。
 結果、要員追加分以外の追加コストが発生することはなく、2014年9月の納期も守ってプロジェクトを完了出来た為、私の行った見積もり、およびプロジェクト運営は妥当なものであったと評価している。

以上

0 件のコメント:

コメントを投稿