- 午後Ⅱ(小論文)でいつもつまづいている
- 小論文のネタを探している
- 合格者のアドバイスを受けたい
プロジェクトマネージャ試験の午後Ⅱの対策として、自分が実際に練習用に作成した小論文を紹介します。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。
問題文および設問
解答例
設問ア
１．プロジェクトの特徴と品質管理計画での考慮事項
１．１．プロジェクト概要
私が担当したプロジェクトは、パッケージソフトウエアのカスタマイズプロジェクトである。
私が所属しているＡ社では、複数のパッケージソフトウエア（以下、ＰＫＧ）の開発・販売を行っている。
Ａ社では、ＰＫＧの開発は商品開発本部が、個別企業向けの受託開発は、システム事業部で行っている。個別企業向けのＰＫＧのカスタマイズは、システム事業部が行っている。
私は、システム事業部に所属しており、Ｂ社向けのカスタマイズを伴うＰＫＧ導入プロジェクトのプロジェクトマネージャに任命された。
１．２．プロジェクトの特徴と品質面での要求事項
今回のプロジェクトメンバーの多くは、４月に商品開発本部から異動したばかりで、ＰＫＧそのものを熟知しているものの、カスタマイズ経験は全くなかった。
Ａ社では、システム開発における品質要求事項の標準として、「本番運用開始後に発見されるバグ目標、０．０１件／ＫＬ」を設定しているが、カスタマイズ経験のないメンバーが多いことから、プロジェクト標準の品質管理計画では、この品質要求事項を達成できなくなるリスクがあった。
１．３．品質管理計画での考慮事項
ＰＫＧカスタマイズ経験がないメンバーが多いことを踏まえ、品質管理計画では、次の点を考慮することにした。
１）品質管理基準は、Ａ社標準値より厳しいものに設定すること
２）定性的な観点での品質評価を行うこと
３）品質評価の実現性に問題がないこと
最も重要と考えた考慮事項は、１）である。通常のカスタマイズ案件よりもレビュー効率が低下する、バグの作りこみが多くなるといったことが予想されるため、標準の品質管理基準では、レビューやテストでバグが取り切れない可能性があった。
（７７９文字）
設問イ
２．品質管理計画とその実施内容
プロジェクトメンバーはＰＫＧの製造スキルを十分に有していることから、品質管理上最も重要な工程は、設計行程であると考えた。
品質上のリスクは製造工程以降にも存在するが、後戻りによる進捗・コストへの影響を最小限にするためには、なるべく前の工程で品質を作りこむ必要があると判断した。
計画した品質管理計画および実施内容は次の通りである。
２．１．策定した品質管理計画
１）品質管理基準
Ａ社の設計行程での品質管理指標として、規模当たりのレビュー工数を１．０Ｈ／ＫＬ、バグ摘出目標を２０件／ＫＬとしている。今回のプロジェクトでは、それぞれ次のように設定した。
・レビュー工数
カスタマイズ経験のないメンバーが多いことから、レビュー効率が低下することが予想された。
Ａ社での過去のプロジェクトのなかで、スキル面のリスクがあったプロジェクトのレビュー工数を確認したところ、レビュー工数に２．０Ｈ／ＫＬ以上を確保したプロジェクトは後工程へのバグの積み残し少なくなる傾向があった。
そこで、スキル面のリスクがあるメンバーが参加するプロジェクトでは、レビューの生産性が半減すると判断し、最低限２．０Ｈ／ＫＬ必要であると考えた。また、さらなる品質の作りこみを行う工夫として、通常２名体制で行うレビューを、カスタマイズ経験豊富なメンバーを加えた３名体制で行うようにした。
これにより、レビュー工数の目標値を３．０Ｈ／ＫＬとした。
・バグ摘出目標
レビュー工数の試算と同様、スキル面のリスクがあったプロジェクトの設計行程でのバグ摘出状況を確認したところ、４０件／ＫＬで後工程での品質が安定していたことから、４０件／ＫＬを目標値として設定した。
なお、品質管理における工夫として、摘出したバグの原因のうち、プロジェクトメンバーの経験不足に起因するバグの件数を、プロジェクトメンバーの経験値を判断する重要なモニタリング指標とした。
プロジェクトメンバーの経験がたまると、レビューの生産性や品質の作りこみが向上することによって、経験不足に起因するバグの比率が下がる。そのため、経験不足によるバグの件数を、品質管理指標の見直しをする材料にすることにした。
２）品質評価の観点
品質評価を行うにあたって、品質管理基準であるレビュー工数・バグ摘出数による定量的な観点だけではなく、バグの内容に着目した定性的な観点で品質評価を行うことにした。
具体的には、バグの原因分析を行った記録をレビューしたり、現場メンバーへのヒアリングを行うようにして、表面的な原因分析ではなく真の原因を特定できているかを確認するようにした。バグ摘出数が目標値をクリアしたとしても、バグの原因分析が不十分だとバグが取り切れないと考えたからである。
２．２．品質管理の実施内容
定量的な品質指標の計測は、チケット管理システムからを用いることにした。チケット管理システムでは、レビュー工数・バグの摘出件数をリアルタイムで取得できる。
さらに、原因別のバグ件数をグラフ化するといった定量的な分析をするために、現場メンバーへの負担が少ないことが、採用の理由だった。
なお、定性的な情報は、現場メンバーへのヒアリングを行うことにした。定性的な情報はチケットに記録されている記録だけでなく、現場の生の声を聴くことでメンバーの本音を聞き出す狙いがあった。
（１４５９文字）
設問ウ
３．評価と改善点
３．１．品質管理計画の評価
策定した品質管理計画は、品質管理計画のレビューを行ったＡ社の品質管理部門および、プロジェクトオーナーであるＡ社の役員から、プロジェクトの要求事項を満たしているとの評価をしてもらった。
特に、品質管理指標の見直しをするためのモニタリング指標を設定したことは、コスト圧縮のための対策として、役員から評価してもらった。
３．２．品質管理の実施結果の評価
本番運用開始後６カ月を経過した時点で発見されたバグは、０．０１件／ＫＬ以内に収まっており、品質管理は適切に行われたと判断する。品質管理の実施結果は、次の通り。
・定量的観点
レビュー時間：３．１Ｈ／ＫＬ、バグ摘出数：４１件／ＫＬであり、いずれも目標値をクリアした。
プロジェクトメンバーの経験不足に起因するバグの件数は、設計工程を通じて摘出バグの５０％±５％の範囲内であった。バグの比率が低下することを期待してはいたが、その傾向は見られなかったため、品質管理指標の見直しは実施しなかった。
・定性的観点
前述の通り、メンバーの経験不足に起因するバグが低下傾向になかったことから、原因分析の妥当性を確認するためのヒアリングを行った。ヒアリングに当たっては、Ａ社の品質管理部門に同席してもらい、他のプロジェクトの知見を踏まえた妥当性の確認を行った。
いくつか、原因の深堀りに問題はあったものの概ね問題はなかった。
３．３．今後の改善点
プロジェクトメンバーへのヒアリングを行った際、「メンバーの経験不足に起因するバグの真の原因分析や、対策立案に手間取った」との報告がメンバーからあった。
今回、品質管理部門の支援は原因分析・対策立案結果の妥当性確認のみであったが、今後は原因分析・対策立案の現場にも立ち会ってもらうことで、効率的な原因分析・対策立案ができると考える。
（８１２文字）
まとめ
自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。
参考図書
自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。
上記はプロジェクトマネージャ試験の対策本ですが、ITサービスマネージャ試験でも通用する内容です。
コメント