くまごろうです。この投稿ではプロジェクトマネージャ試験 平成28年午後Ⅱ問２「情報システム開発プロジェクトの実行中におけるリスクのコントロールについて」を解説します。
この記事では実際の論文を公開します。論文を考えていく上での参考になればうれしいです。
プロジェクトマネージャ試験は初めて合格した論文試験ということもあり、あまりレベルの高い論文ではありませんが、それでも合格はできているかなと思います。
論文
1.プロジェクトの特徴とプロジェクト目標の達成を阻害するリスクにつながる兆候 1-1.プロジェクトの特徴 ・論述の対象 ・特徴 1-2.プロジェクト目標の達成を阻害するリスクにつながる兆候 ・リスク ・兆候 →兆候の例 メンバの稼働時間が計画以上に増加している状況 メンバが仕様書の記述に対してわかりにくさを表明している状況
1.プロジェクトの特徴とプロジェクト目標の達成を阻害するリスクにつながる兆候 1-1.プロジェクトの特徴 私は独立系SIベンダに勤務しているA社のITエンジニアである。今回論述するプロジェクトは、オフコンで稼働しているB社の宴会管理ステム再構築プロジェクトである。開発期間は１２カ月、総工数は７２人月であった。私はこのプロジェクトのプロジェクトマネージャーとして参画した。 プロジェクトの特徴としては、再構築プロジェクトということもあり、プロジェクト予算に余裕がなかったこと、自部署では実績のない社内で標準化予定の開発フレームワークを採用した点にある。今回アサインした製造メンバーはこのフレームワークを利用した開発を行ったことがなかった。よって製造の初期においては、開発生産性が低いことが想定された。 1-2.プロジェクト目標の達成を阻害するリスクにつながる兆候 このプロジェクトの最大のリスクは、製造工程において製造初期段階の生産性が想定通りに回復せず、結果として予算超過が発生することである。このリスクを早急に察知するため、通常はプログラム単位にEVMを用いて週次で進捗確認を行っているが、水曜日と金曜日の週２回の確認を行うことを私は計画した。 ４週間経過後、ACやPVを確認すると計画通りに開発生産性が回復していることが分かった。しかしそのころから一部のベテラン要員が週平均１０時間の残業を行うようになった。確かにベテラン要員の開発生産性は普通の要員に比べて高く設定しているが、開発フレームワークに慣れてきたこのタイミングでベテラン要員だけ稼働が高くなるのはおかしい。私はこの現象がリスクにつながる兆候だと考え、問題に対処することにした。
2.顕在化すると考えたリスクと予防処置及び対応計画について
2-1.顕在化すると考えたリスクとその理由
顕在化するリスクの例
・開発生産性が目標に達しないリスク
・成果物の品質を確保できないリスク
理由
・察知した兆候の原因分析
・リスク分析(リスクの発生確率や影響度)
【顕在化すると考えたリスク】
・残業が増加すると開発生産性が目標に達しない
→予算超過するリスク
【原因分析】
・PLにヒアリングをして確認
→フレームワークの部品の調整ノウハウがなく時間がかかっている
【リスク分析】
・一般メンバーも難易度の高いプログラム開発に着手する予定だが、
このまま放置すると予算超過すると考えられた。
2-2.予防処置について
・2-1で予防処置が必要だと判断した場合のみ
【予防処置】
・フレームワーク製造元部署から要員を派遣してもらい以下を検討する
①集合教育
②OJT
→OJTに。基礎的な知識の共有ではなく、詳細なノウハウの共有だから。
またベテランに対して行い、文章化、チーム内共有する。
2-3.対応計画について
・2-1で予防処置が必要だと判断した場合のみ
【対応計画】
・生産性が目標に達しない場合に実施。以下を検討
①OJTの延長
②製造要員の派遣又は開発の外部委託
→ノウハウのたまらない①はやりたくない
両方対応計画として持っておくけど、①で改善できる見込みがなければ②を実施
2.顕在化すると考えたリスクと予防処置及び対応計画について 2-1.顕在化すると考えたリスクとその理由 私はベテラン要員の残業時間が増加しているという現象を調査すべく、プロジェクトリーダーのＣ氏に現状を確認した。Ｃ氏からは、今回初めて利用した開発フレームワークは、難易度が中程度までであれば非常に生産性が高いこと。一方で難易度の高いプログラムの場合は、開発フレームワークによって部品化されている機能を細かく調整する必要があるが、どのパラメータを調整してよいかわからず、試行錯誤に時間がかかっているという報告を受けた。今はまだベテラン要員しか難易度の高いプログラムを製造していないが、これからはほかのメンバーも難易度の高いプログラムの製造に着手する計画になっている。私はリスク分析を行い、このままでは開発生産性が計画通りに回復しない場合に、予算超過に対する影響度が高く、発生する確率も高いと判断し、早急に予防処置を計画し実施する必要があると判断した。 2-2.予防処置について 開発生産性を回復させるために、私は開発フレームワーク製造元の部署より要員を派遣してもらい、①集合教育を実施する。②OJTを実施する、の２つを比較し、OJTを実施することにした。理由としては、現状問題となっているのは個々の部品化されている機能の調整であって、集合教育で行うような初歩的な知識の共有ではないからである。またより効率的にOJTを行うために、OJTを受けるのはベテラン要員だけに限定し、一般要員はベテラン要員へ質問するようにルール化し、知識の集積を図った。併せて、OJTで得た知見は文書化してチーム内で共有することをルール化し、チームメンバーへの共有化を図った。以上の処置を実施し、開発生産性が計画通りに回復することを見守ることとした。 2-3.対応計画について 予防処置を実施化したにもかかわらず、開発生産性が計画通りに回復しなかった場合に備え、対応計画の策定も行った。対応計画としては、予防計画の効果の確認が必要なため、開発開始から８週間目の時点で開発生産性が目標に達していない場合に実施することとし、①OJTの期間を延長する、②フレームワーク開発元の部署に対して開発要員を派遣してもらう、又は高難易度のプログラムの製造を委託することを考えた。今回利用した開発フレームワークは会社として積極的に活用する方針を打ち出していることを考えると、自部署として②の施策のようなノウハウが蓄積しない方法は取りたくない。そこで予防処置の効果によって、OJTで対応できる場合は①を、OJTでは対処できないと判断した場合には、開発生産性によって②を実施することにした。以上の対応計画をフレームワーク開発元の部署に提示し、協議を行い、合意に至ることができた。
3.予防処置の実施状況と評価及び今後の改善点について
3-1.予防処置の実施状況と評価
【実施状況】
・OJTを行い文章で共有化した。生産性は回復した。一般の要員も生産性低下はなかった
【評価】
・生産性が回復したことから成功
3-2.今後の改善点について
【改善点】
・製造元の部署からの要員派遣は、費用の関係からOJTに限定をして依頼をした。
しかしその後も高頻度で問い合わせを行った
→製造元部署からクレーム。協議の結果、ノウハウ全社公開を条件に費用折半。
自部署分はプロジェクト予備費より支出した。
→予見できていたので、事前に協議していたほうがスムーズだったのが改善点
3.予防処置の実施状況と評価及び今後の改善点について 3-1.予防処置の実施状況と評価 開発フレームワーク製造元の部署より要員を派遣してもらい、ベテラン要員に対して５日間のOJTを行った。同時にOJTを通じて得た知見をFQAに記載しチーム内に共有を行った。ベテラン要員に関しては、OJTで今回の開発でよく利用する部品の調整を理解でき、開発生産性は回復することができた。一般要員も難易度の高いプログラムの製造に取り掛かったが、不明点は文書で確認し、それでも不明な点はベテラン要員に確認することで、ベテラン要員を中核としてチーム全体で知識の共有を図ることができたため、大きな生産性の低下は発生しなかった。 以上の実施状況から、今回私が実施した予防処置は成功であったと考える。 3-2.今後の改善点について 今回の開発では新しいフレームワークを利用するにあたり、このフレームワークの特性を見極めて開発計画を立案することができなかった。今後のプロジェクト見積もりに今回の知見を活かすため、プロジェクト完了報告書に難易度の高いプログラムの場合は開発初期に開発生産性が低下しがちであるとを注記するとともに、開発生産性の実績値を記述して全社に公開することで、共有を図ることにした。 また今回作成したＦＱＡは開発フレームワーク製造元の部署と共有して全社標準として公開してもらうことにした。こうすることで、初めてこの開発フレームワークを利用するプロジェクトであっても、スムーズに開発を進めることができるようになると考える。 以上の改善点を実施し、今後の開発に備えることにした。 -以上-
いかがでしょうか。冒頭にも記述した通り、最初に受けた論文試験の論文です。参考書に記載されているサンプル論文と比べると劣りますが、これに近いものが実際の試験で書けていれば、まず合格するでしょう。
問に丁寧に答えることができれば、内容は平凡で良いのです。上記論文だって、「①知らないフレームワーク使うのリスク高くないか？ちょっと詳しく進捗確認するか。」→「②進捗悪くなってきたぞ。ベテランさんに聞いてみよう」→「③あー細かい調整の仕方がわからないのね。このままだとまずいよね。対策しようか。」→「④ちょっと作成元の要員を連れてきてOJTしようか。」→「⑤回復しなかったら問題あるから、保険もかけておくか」→「⑥実際やったら生産性回復した。よかったよかった」→「⑦今後のためにも知識共有しておこう」くらいなすごく平凡なものです。
これくらいなら誰でも思いつくし、だれでも書けると思います。
ちなみにこの論文は半分実話です。他部署のお手伝いをしていた時に、その開発では初めてさわるフレームワークを使用していました。そのフレームワークは、他部署で内製化していた残念なフレームワークだったのです。なぜ残念だったかというと、あらゆる部品が独自のプロパティを調整する必要があり、そのことを知らなければ、開発にならなかったためです。
くまごろうはそのことを説明されていませんでした。なので、あまりにも簡単な「線を移動させる」という操作ができずに、１日ほど費やしました。ふつうの.Netなら5秒でできるはずなんですけどね。
こんな感じで論文ネタも、日ごろ業務をしているものを参考にすれば書くことができます。
今回の論文はいかがだったでしょうか。参考になったならば、うれしいです。
また次回お会いしましょう。それでは！！
コメント