- 合格レベルの論文がどんなものか、具体的な完成形を知りたい方
- 自分の実務経験を「評価される論文」に仕上げる書き方のコツを知りたい方
- 設問ア・イ・ウそれぞれの役割と、論理的な文章のつなげ方を学びたい方
プロジェクトマネージャ試験の午後Ⅱの小論文を作成してみました。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。
問題文および設問
問題の原本はIPAにてご確認ください。
問題文
問２ システム開発プロジェクトにおける品質確保策について
プロジェクトマネージャ（ＰＭ）には、品質保証や品質管理の方法などについて品質計画を立案し、設定された品質目標を予算や納期の制約の下で達成することが求められる。
ＰＭは、品質目標の達成を阻害する要因を見極め、その要因に応じた次のような品質確保策を作成し、品質計画に含める必要がある。
・要員の業務知識が不十分な場合、要件の見落としや誤解が起きやすいので、業務に詳しい有識者を交えたウォークスルーによる設計内容の確認やプロトタイプによる利用者の確認を実施する。
・稼働中のシステムの改修の影響が広範囲に及ぶ場合、既存機能のデグレードが起きやすいので、構成管理による修正箇所の確認や既存機能を含めた回帰テストを実施する。
また、予算や納期の制約を考慮して、それらの品質確保策について、次のような工夫をすることも重要である。
・ウォークスルーの対象を難易度の高い要件に絞ることで設計期間を短縮したり、表計算ソフトを利用して画面や帳票のプロトタイプを作成することで設計費用を削減したりする。
・構成管理でツールを活用して修正範囲を特定することで修正の不備を早期に発見してシステムの改修期間を短縮したり、回帰テストで前回の開発のテスト項目やテストデータを用いてテスト費用を削減したりする。
あなたの経験と考えに基づいて、設問ア～ウに従って論述せよ。
設問ア
あなたが携わったシステム開発プロジェクトの特徴、及びその特徴を踏まえて設定された品質目標について、８００字以内で述べよ。
設問イ
設問アで述べた品質目標の達成を阻害する要因とそのように判断した根拠は何か。また、その要因に応じて品質計画に含めた品質確保策はどのようなものか。８００字以上１，６００字以内で具体的に述べよ。
設問ウ
設問イで述べた品質確保策の作成において、予算や納期の制約を考慮して、どのような工夫をしたか。また、工夫した結果についてどのように評価しているか。６００字以上１，２００字以内で具体的に述べよ。
解答例
設問ア
１．プロジェクト概要と品質目標
１．１．プロジェクト概要
私がＰＭして担当したのは、大手製造業Ａ社の基幹業務システム再構築プロジェクトである。目的は、老朽化した現行システムを刷新し、業務効率化とデータ活用基盤の構築、将来変化への対応であった。プロジェクト期間は１８ヶ月、予算は約３億円だった。
本プロジェクトには、品質目標設定に大きく影響する、特に留意すべき特徴があった。
１）現行システムは長年の改修でブラックボックス化し、仕様の全容把握が困難であった。これは後の設計品質や移行品質に影響すると考えた。
２）１８ヶ月という短納期でのカットオーバーが経営戦略上の必達目標であり、スケジュールに余裕がなかった。これはテスト期間の確保や手戻り防止策が重要となることを意味した。
３）開発チームの多くがＡ社の業務知識に不慣れで、仕様の誤解リスクが高かった。これは要件定義や設計の品質確保に直結する課題と認識した。
１．２．特徴を踏まえて設定された品質目標
前述の特徴を踏まえ、以下の品質目標を設定した。
１）機能品質
業務影響大の主要１０機能は不具合ゼロ、システム全体のバグ密度０．３件／ＫＳＬＯＣ以下を目標とした。これは重篤な業務停止リスクの回避と全体的な信頼性確保が狙いであった。
２）非機能品質
データ移行エラー０件、移行後データ不整合率０．００１％以下、主要オンライン画面の平均レスポンス３秒以内を目標とした。これは現行システムの複雑性から、データ移行の正確性を最重要視し、業務効率化の達成を目指したためである。
３）プロセス品質
設計レビューでの重要指摘の８０％以上を設計完了までに検出、単体テストのカバレッジをＣ１基準で９０％以上を目標とした。これは短納期に対応するための手戻り防止と、早期の欠陥修正を意図したものである。
（７９４文字）
設問イ
２．品質目標の阻害要因と品質確保策
２．１．品質目標の阻害要因
前述の品質目標達成を阻害する最重要因は、「開発要員のＡ社業務知識不足」と判断した。現行システムのブラックボックス化や短納期も課題だが、開発チームの業務理解度が低い状況では、これらのリスクは一層深刻化すると考えたためである。具体的には、開発チームの多くがＡ社の詳細な業務、特有の商習慣、現行システムに潜在する暗黙知の理解が浅く、要件定義の抜け漏れや設計の誤解釈リスクが極めて高かった。この業務知識不足が主要因と判断した根拠は次の通りである。
１）プロジェクト初期の認識齟齬
初期の要件定義ワークショップで、開発要員が顧客の業務説明の意図を汲み取れず、認識合わせに時間を要した。これは真の業務ニーズ把握の不備であり、品質への悪影響を強く懸念した。
２）ＰＭ自身の経験
私自身の過去の経験から、業務知識不足は手戻りを誘発し、納期遅延とコスト超過、最終的な品質低下に直結すると確信していた。
３）プロジェクト固有リスクの増幅
現行システムのブラックボックス化という特徴も、業務知識が不足していれば、仕様の不明確な部分の解明や正しい機能移行が困難となり、デグレードのリスクを高めると判断した。短納期制約下では、この手戻りリスクは最優先で排除すべきと考えた。
２．２．品質計画に含めた品質確保策
この阻害要因に対応し、品質目標を達成するため、品質計画に以下の３つの具体的な確保策を盛り込んだ。狙いは、開発メンバーの業務理解促進、円滑なコミュニケーションによる設計品質向上と手戻り削減であった。
１）Ａ社業務エキスパートを巻き込んだ集中的業務知識研修
プロジェクト開始直後に１週間、全開発メンバー対象の集中的業務知識研修を実施した。講師はＡ社の業務エキスパート及び情報システム部担当者とし、Ａ社の基幹業務、業界特有の用語、現行システムの課題、新システムへの期待などを網羅的に解説頂いた。特に重視したのは、複雑な業務ロジックや例外処理の背景にある業務的理由の理解であった。この狙いは、メンバーの業務知識レベルを短期間で引き上げ、初期段階での共通認識を形成し、後の誤解や認識齟齬を最小化すること、及び専門家との関係構築で質疑応答を円滑化することだった。
２）業務シナリオベースの段階的ウォークスルーと早期プロトタイピングの併用
設計成果物完成ごとに、Ａ社業務エキスパートを必須レビュアーとするウォークスルーを実施した。単なる設計書読合せでなく、実際の業務シナリオに基づき、設計内容の妥当性や考慮漏れを業務視点で検証した。狙いは、開発者視点では見落としがちな問題点の早期発見と修正である。さらに補完策として、主要オンライン画面は外部設計中盤で操作可能なプロトタイプを作成し、業務エキスパートとエンドユーザー代表に評価を依頼した。狙いは、設計書では伝わりにくい操作性や業務適合性のフィードバックを早期に得て、手戻りを最小化し、利用者満足度を高めること、及び開発者の業務理解深化であった。
３）業務知識共有ポータルの構築とＱ＆Ａプロセスの整備
プロジェクト専用イントラネットに業務知識共有ポータルを構築し、研修資料、議事録、業務フロー図、用語集、Ｑ＆Ａ等を一元化し、全員が常時参照可能とした。また、ポータル経由でＡ社業務エキスパートへ質問できるＱ＆Ａプロセスを整備し、回答は全て記録・共有しナレッジを蓄積した。狙いは、業務知識の効率的な共有・再利用環境を整備し、メンバー間の知識格差を解消、プロジェクト全体の業務理解度を継続的に向上させること、そして特定担当者への知識偏在リスクを低減しチーム全体の対応力を高めることだった。
（１５６６文字）
設問ウ
３．品質確保策の工夫と評価
３．１．制約下での品質確保策の工夫
前述の品質確保策は、品質目標達成に不可欠と考えたが、厳しい予算・納期の制約下では全てを理想的に実施することは困難だった。そのため、費用対効果と効率性を最大化する工夫を凝らした。
１）段階的ウォークスルーでの工夫
レビュー工数増大と納期遅延を避けるため、リスクベース・アプローチを採用。Ａ社業務エキスパート等と協議し、高リスク箇所（クリティカル機能、仕様大幅変更機能等）にレビュー資源を重点投入した。対象外箇所はピアレビュー等で代替し、事前準備徹底で会議時間を短縮した。これは、限られたリソースで品質向上効果を最大化する狙いである。
２）プロトタイプ作成での工夫
高価な専用ツールでなく、表計算ソフト等の簡易ツールを活用し、コストを大幅削減。再現範囲も主要ＵＩと基本遷移に限定した。予算制約下で費用を抑えつつ、迅速なフィードバックサイクルで手戻り早期発見と満足度向上を狙った。
３）構成管理と影響分析における工夫
ツールはＯＳＳの活用で費用を大幅削減。影響分析は高価なツール導入を見送り、業務知識不足という課題認識のもと、アーキテクトによる現行仕様の手動解析とレビュー体制強化で精度を担保した。これは、レガシーコードが多く予算も厳しい本プロジェクトでは、人的資源活用が費用対効果高いと判断したためである。
４）回帰テストにおける工夫
全手動テストの工数増と納期遅延を回避し、全自動化の初期投資増も避けるため、ＯＳＳの自動化ツールを一部（変更頻度高、クリティカルパス等、全体の約３０％）に限定導入。残りは既存テスト資産を再利用した。これは短納期下で効率と網羅性のバランスを取る判断だった。
３．２．工夫した結果の評価と今後の課題
ウォークスルーの工夫で工数を約１８％削減、重要指摘事項の８５％を設計フェーズで検出し、手戻り減に貢献した。プロトタイプ作成の工夫でコストを約５５％削減、迅速な改善サイクルで利用者満足度向上にも寄与した。構成管理等の工夫でツール費用を約７０％削減、手動解析とレビュー強化で致命的デグレードを阻止できた。回帰テストの工夫で工数約２２％削減、自動テストでデグレード早期発見、バグ密度目標を達成し無事リリースできた。
以上のことから、リスクベースでの資源配分、費用対効果を意識したツール選定、既存資産活用等の工夫は、厳しい制約下での品質確保とプロジェクト成功に大きく貢献した。経営資源の制約を創意工夫で乗り越えられたと考える。今後の課題は、手動部分のヒューマンエラーリスク低減のための更なる自動化推進と、体系的な業務知識移転の仕組み強化と考える。
（１１４４文字）
まとめ
自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。
参考図書
自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。
上記はプロジェクトマネージャ試験の対策本ですが、ITサービスマネージャ試験でも通用する内容です。
コメント