情報処理技術者試験(PM/SM)に連続で一発合格したおじさんによる プロジェクトマネージャ試験 午後Ⅱの過去問論文事例(平成29年度問2)

情報処理技術者試験
こんな人におすすめ
  • 午後Ⅱ(小論文)でいつもつまづいている
  • 小論文のネタを探している
  • 合格者のアドバイスを受けたい

プロジェクトマネージャ試験の午後Ⅱの対策として、自分が実際に練習用に作成した小論文を紹介します。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。

スポンサーリンク

問題文および設問

解答例

設問ア

1.プロジェクトの特徴と品質管理計画での考慮事項

1.1.プロジェクト概要

 私が担当したプロジェクトは、パッケージソフトウエアのカスタマイズプロジェクトである。
私が所属しているA社では、複数のパッケージソフトウエア(以下、PKG)の開発・販売を行っている。
A社では、PKGの開発は商品開発本部が、個別企業向けの受託開発は、システム事業部で行っている。個別企業向けのPKGのカスタマイズは、システム事業部が行っている。

 私は、システム事業部に所属しており、B社向けのカスタマイズを伴うPKG導入プロジェクトのプロジェクトマネージャに任命された。

1.2.プロジェクトの特徴と品質面での要求事項

 今回のプロジェクトメンバーの多くは、4月に商品開発本部から異動したばかりで、PKGそのものを熟知しているものの、カスタマイズ経験は全くなかった。
A社では、システム開発における品質要求事項の標準として、「本番運用開始後に発見されるバグ目標、0.01件/KL」を設定しているが、カスタマイズ経験のないメンバーが多いことから、プロジェクト標準の品質管理計画では、この品質要求事項を達成できなくなるリスクがあった。

1.3.品質管理計画での考慮事項

 PKGカスタマイズ経験がないメンバーが多いことを踏まえ、品質管理計画では、次の点を考慮することにした。

1)品質管理基準は、A社標準値より厳しいものに設定すること
2)定性的な観点での品質評価を行うこと
3)品質評価の実現性に問題がないこと

 最も重要と考えた考慮事項は、1)である。通常のカスタマイズ案件よりもレビュー効率が低下する、バグの作りこみが多くなるといったことが予想されるため、標準の品質管理基準では、レビューやテストでバグが取り切れない可能性があった。

(779文字)

設問イ

2.品質管理計画とその実施内容

 プロジェクトメンバーはPKGの製造スキルを十分に有していることから、品質管理上最も重要な工程は、設計行程であると考えた。
品質上のリスクは製造工程以降にも存在するが、後戻りによる進捗・コストへの影響を最小限にするためには、なるべく前の工程で品質を作りこむ必要があると判断した。

 計画した品質管理計画および実施内容は次の通りである。

2.1.策定した品質管理計画

1)品質管理基準

 A社の設計行程での品質管理指標として、規模当たりのレビュー工数を1.0H/KL、バグ摘出目標を20件/KLとしている。今回のプロジェクトでは、それぞれ次のように設定した。

・レビュー工数

 カスタマイズ経験のないメンバーが多いことから、レビュー効率が低下することが予想された。
A社での過去のプロジェクトのなかで、スキル面のリスクがあったプロジェクトのレビュー工数を確認したところ、レビュー工数に2.0H/KL以上を確保したプロジェクトは後工程へのバグの積み残し少なくなる傾向があった。
そこで、スキル面のリスクがあるメンバーが参加するプロジェクトでは、レビューの生産性が半減すると判断し、最低限2.0H/KL必要であると考えた。また、さらなる品質の作りこみを行う工夫として、通常2名体制で行うレビューを、カスタマイズ経験豊富なメンバーを加えた3名体制で行うようにした。
これにより、レビュー工数の目標値を3.0H/KLとした。

・バグ摘出目標

 レビュー工数の試算と同様、スキル面のリスクがあったプロジェクトの設計行程でのバグ摘出状況を確認したところ、40件/KLで後工程での品質が安定していたことから、40件/KLを目標値として設定した。
なお、品質管理における工夫として、摘出したバグの原因のうち、プロジェクトメンバーの経験不足に起因するバグの件数を、プロジェクトメンバーの経験値を判断する重要なモニタリング指標とした。
プロジェクトメンバーの経験がたまると、レビューの生産性や品質の作りこみが向上することによって、経験不足に起因するバグの比率が下がる。そのため、経験不足によるバグの件数を、品質管理指標の見直しをする材料にすることにした。

2)品質評価の観点

 品質評価を行うにあたって、品質管理基準であるレビュー工数・バグ摘出数による定量的な観点だけではなく、バグの内容に着目した定性的な観点で品質評価を行うことにした。
具体的には、バグの原因分析を行った記録をレビューしたり、現場メンバーへのヒアリングを行うようにして、表面的な原因分析ではなく真の原因を特定できているかを確認するようにした。バグ摘出数が目標値をクリアしたとしても、バグの原因分析が不十分だとバグが取り切れないと考えたからである。

2.2.品質管理の実施内容

 定量的な品質指標の計測は、チケット管理システムからを用いることにした。チケット管理システムでは、レビュー工数・バグの摘出件数をリアルタイムで取得できる。
さらに、原因別のバグ件数をグラフ化するといった定量的な分析をするために、現場メンバーへの負担が少ないことが、採用の理由だった。
なお、定性的な情報は、現場メンバーへのヒアリングを行うことにした。定性的な情報はチケットに記録されている記録だけでなく、現場の生の声を聴くことでメンバーの本音を聞き出す狙いがあった。

(1459文字)

設問ウ

3.評価と改善点

3.1.品質管理計画の評価

 策定した品質管理計画は、品質管理計画のレビューを行ったA社の品質管理部門および、プロジェクトオーナーであるA社の役員から、プロジェクトの要求事項を満たしているとの評価をしてもらった。

 特に、品質管理指標の見直しをするためのモニタリング指標を設定したことは、コスト圧縮のための対策として、役員から評価してもらった。

3.2.品質管理の実施結果の評価

 本番運用開始後6カ月を経過した時点で発見されたバグは、0.01件/KL以内に収まっており、品質管理は適切に行われたと判断する。品質管理の実施結果は、次の通り。

・定量的観点

 レビュー時間:3.1H/KL、バグ摘出数:41件/KLであり、いずれも目標値をクリアした。
プロジェクトメンバーの経験不足に起因するバグの件数は、設計工程を通じて摘出バグの50%±5%の範囲内であった。バグの比率が低下することを期待してはいたが、その傾向は見られなかったため、品質管理指標の見直しは実施しなかった。

・定性的観点

 前述の通り、メンバーの経験不足に起因するバグが低下傾向になかったことから、原因分析の妥当性を確認するためのヒアリングを行った。ヒアリングに当たっては、A社の品質管理部門に同席してもらい、他のプロジェクトの知見を踏まえた妥当性の確認を行った。
いくつか、原因の深堀りに問題はあったものの概ね問題はなかった。

3.3.今後の改善点

 プロジェクトメンバーへのヒアリングを行った際、「メンバーの経験不足に起因するバグの真の原因分析や、対策立案に手間取った」との報告がメンバーからあった。
今回、品質管理部門の支援は原因分析・対策立案結果の妥当性確認のみであったが、今後は原因分析・対策立案の現場にも立ち会ってもらうことで、効率的な原因分析・対策立案ができると考える。

(812文字)

まとめ

自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。

参考図書

自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。

上記はプロジェクトマネージャ試験の対策本ですが、ITサービスマネージャ試験でも通用する内容です。

コメント

タイトルとURLをコピーしました