プロマネ午後Ⅱ論文の書き方がわからない人へ｜一発で合格した実務経験者のサンプル解答【平成２１年度：問２】

プロジェクトマネージャ試験の午後Ⅱの小論文を作成してみました。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。

問題文および設問

問題の原本はIPAにてご確認ください。

問題文

問２　設計工程における品質目標達成のための施策と活動について

　プロジェクトマネージャ（ＰＭ）には、プロジェクトの立上げ時に、信頼性、操作性などに関するシステムの品質目標が与えられる。
　ＰＭは、品質目標を達成するために、品質を作り込む施策と品質を確認する活動を計画する。ＰＭは、設計工程では、計画した品質を作り込む施策が確実に実施されるように管理するとともに、品質目標の達成に影響を及ぼすような問題点を、品質を確認する活動によって早期に察知し、必要に応じて品質を作り込む施策を改善していくことが重要である。
　例えば、サービスが中断すると多額の損失が発生するようなシステムでは、サービス中断時間の許容値などの品質目標が与えられる。設計工程で品質を作り込む施策として、過去の類似システムや障害事例を参考にして、設計手順や考慮すべきポイントなどを含む設計標準を定める。品質を確認する活動として、プロジェクトメンバ以外の専門家も加えた設計レビューなどを計画する。品質を確認する活動の結果、サービス中断時間が許容値を超えるケースがあるという問題点を察知した場合、その原因を特定し、設計手順の不備や考慮すべきポイントの漏れがあったときには、設計標準を見直すなどの改善措置をとる。それに従って設計を修正し、品質目標の達成に努める。

　あなたの経験と考えに基づいて、設問ア～ウに従って論述せよ。

設問ア

あなたが携わったシステム開発プロジェクトの特徴、システムの主要な品質目標と品質目標が与えられた背景について、８００字以内で述べよ。

設問イ

設問アで述べたプロジェクトにおいて計画した、設計工程で品質を作り込む施策と品質を確認する活動はどのようなものであったか。活動の結果として察知した問題点とともに、８００字以上１，６００字以内で具体的に述べよ。

設問ウ

設問イで述べた問題点に対し、特定した原因と品質を作り込む施策の改善内容について、改善の成果及び残された課題とともに、６００字以上１，２００字以内で具体的に述べよ。

解答例

設問ア

１．プロジェクト概要と主要品質目標

１．１．プロジェクト概要

　私がＰＭを担当したプロジェクトは、「既存システム刷新」と「ビジネス拡大に対応できる処理能力及び信頼性の確保」を目的とした、大手小売業のＥＣサイト向け受注処理システム再構築である。本プロジェクトには「約９か月という短納期（時間の制約）。次年度大型セール対応という経営層の強い要請」「在庫管理等多数の関連システムとのリアルタイムデータ同期が求められ、インターフェースの複雑性が高い」という特徴があった。

１．２．品質目標とその背景

　ステークホルダーへのヒアリングと過去障害事例を踏まえ、事業インパクトと実現性を勘案し、本プロジェクトでは次の２点を主要品質目標と定めた。背景には経営課題があった。
１）処理能力の向上
　最重要目標として受注処理能力向上を掲げ、ピーク時毎秒３００件の安定処理を目指した。背景には、過去セールで既存システムの能力不足によりシステムダウンが頻発し、想定売上の約１５％もの販売機会を逸失した経緯がある。この機会損失の再発防止は最優先の経営課題であり、ＥＣ事業成長に不可欠と判断した。
２）データ一貫性の確保
　次に重要な目標として、受注、在庫、顧客情報等のデータ不整合をなくし、データ一貫性を完全に確保することを定めた。背景には、既存システムのデータ不整合が誤案内や注文キャンセルを月平均約５００件誘発し、顧客満足度低下とコールセンター人員５名増強によるコスト増大を招いたことがある。データの正確性は顧客信頼の基盤であり、ブランドイメージ維持向上に必須だった。
　当初高可用性も主要目標として検討したが、人的リソースと期間の制約から上記目標達成を最優先と判断し、努力目標とした。これによりリソースを最重要課題に集中させ、プロジェクト成功確率向上を図った。

（７８９文字）

設問イ

２．設計工程における品質管理と問題点

２．１．計画した品質管理の具体策

　主要品質目標である「処理能力向上」と「データ一貫性確保」の達成のため、品質作り込み施策と品質確認活動から成る、以下の品質管理策を実行した。高リスク領域を早期特定し予防的な品質管理策を重点投入することで、手戻りによる遅延回避を最優先とした。

１）品質作り込みのための施策
・設計標準の策定と徹底
　品質均一化、障害再発防止、手戻り削減（短納期対応）を目的に設計標準を策定した。過去障害事例（ＤＢデッドロック、マイクロサービスでのデータ不整合等）を参考に、データ一貫性に関わるトランザクション管理（分散トランザクションの考慮事項等）、排他制御、エラーハンドリングの設計指針とチェックリストを作成、レビュー時の必須確認事項とした。処理能力向上のため、性能要件を意識したモジュール分割指針、非同期処理導入基準、効率的なＤＢアクセスガイドラインも明文化し徹底した。短納期下での、効率的な品質向上を目指した。
・技術検証（ＰｏＣ）の実施
　新技術（新ＤＢＭＳ、マイクロサービス）導入に伴う性能・一貫性リスクの早期評価のため、重点領域でＰｏＣを実施した。ピーク時負荷（毎秒３００件）を想定し、ＤＢ応答性能や連携遅延、障害時データ整合性を測定・評価した。これにより、設計初期にボトルネックや一貫性の課題を特定し、設計へフィードバックすることで手戻りリスクの低減を図った。
２）品質確認のための活動
・段階的な設計レビュー
　早期のバグ検出と手戻り最小化のため、主要設計完了時に公式レビューを実施した。設計・テスト・運用担当者に加え、ＰＭである私も参加し、品質目標（特にデータ一貫性）達成度を評価観点として明示。マイクロサービス間のトランザクション境界や、障害時復旧設計（処理の取り消し等）の具体性を重点確認した。レビュー指摘事項の対応状況は私が直接追跡し、確実なクローズを確認する体制とした。
・専門家によるアーキテクチャレビュー
　チーム内の見落としリスク低減のため、社内外専門家（シニアアーキテクト、外部コンサルタント）にアーキテクチャ全体レビューを依頼。特にデータ一貫性担保のシステム間連携方式（非同期処理、分散トランザクション管理等）の妥当性を第三者視点で評価してもらった。結果、設計方針の明確化や考慮漏れ障害パターンの指摘を得て、設計改善に繋げた。

２．２．品質管理活動で察知した問題点

　上記品質管理活動、設計工程の早期に主要品質目標である「データ一貫性の確保」を著しく脅かす、重大な問題点を察知した。
　具体的には、複数マイクロサービスに跨るデータ更新処理（注文確定、在庫引当、顧客ポイント更新）において、一部サービス障害時にデータ不整合が発生しうるシナリオが、基本設計レビューで複数指摘された。例えば、注文は確定したが在庫引当に失敗した場合など、一連の業務トランザクションが途中で中断すると、各マイクロサービスが保持するデータに矛盾が生じ、顧客への誤情報提供や在庫不整合による販売機会損失、手作業でのデータ修正といった業務負荷増大リスクがあった。
　特に、障害発生時のロールバック手順や仕組みが設計上考慮されていなかった。加えて、ネットワーク遅延などで同じ処理要求が誤って複数回システムに送信された場合に、データが意図せず重複して更新されるなど、矛盾した状態になったりすることを防ぐための設計上の配慮も不足している箇所が見受けられた。この問題はシステムの信頼性の根幹に関わり、放置すればビジネスに深刻な影響を与えかねないと判断し、最優先で対処すべき課題と認識した。

（１５４７文字）

設問ウ

３．問題点への対策と今後の課題

３．１．問題点に対する原因分析

　前述の問題は、分散環境下での障害時設計の配慮不足が、直接原因だった。「なぜなぜ分析」などによって原因を深掘りした結果、根本原因は「プロジェクト初期における非機能要件定義の具体性の欠如と、それに基づく設計・検証計画の不備」と特定した。具体的には、データ一貫性目標に対し、分散環境での具体的な一貫性レベルや障害シナリオの非機能要件定義が曖昧だった。これが、複雑な設計の必要性への認識の甘さ（人的リソース制約も影響）、障害パターン洗い出し不足、レビュー形骸化（時間の制約も影響）を招き、設計不備が見逃された。

３．２．施策の改善内容

　根本原因の解消と品質目標達成のため、以下の改善を行った。
１）非機能要件の再定義と設計への反映
　関連ステークホルダーとワークショップを実施し、データ一貫性目標の非機能要件を詳細に再定義した（許容不整合レベル等）。これに基づき設計標準（分散トランザクション一貫性担保パターン適用基準等）を強化し、ＰｏＣシナリオも拡充（障害パターン模擬検証等）することで、設計の拠り所を明確にした。
２）レビュープロセスの強化
　設計レビューで非機能要件達成度評価を最重要視し、専用チェックリストを追加。人的リソース制約を補うため、分散トランザクション管理等に知見のある社内外専門家に、非機能要件達成の観点から設計内容の妥当性を重点レビューしてもらう体制とし、客観的・専門的な品質検証の実現を目指した。

３．３．改善の成果と今後の課題

　施策改善の結果、主要品質目標「データ一貫性の確保」を達成した。具体的には、非機能要件の具体化、設計標準の強化、ＰｏＣ拡充、レビュー強化が効果的な設計修正に繋がり、専門家の助言も得て障害時にもデータ不整合なく安定稼働することを確認、システムの信頼性を大幅に向上させた。また、副次的な効果として、チーム全体の品質意識と技術力も向上し、特に設計者の自律的な品質作り込み活動が促進された。
　しかし、今回顕在化した根本原因の再発防止と組織全体の開発能力向上には、非機能要件定義プロセスの全社的な標準化が今後の最重要課題である。非機能要件の具体化は、本来初期段階で行うべきであり、今回はこの遅れが品質リスクを高めた。今後の対策として、非機能要件を具体的かつ定量的に定義する全社標準プロセスの確立し、「明確なメトリクス設定指針」「ステークホルダーとの合意形成手法」の標準化や、設計からテストまでの追跡可能な仕組み導入し、さらにＰＭ・アーキテクトへの関連教育を実施する。この組織的改善で初期の定義漏れや曖昧さを排除し、手戻りリスク低減と高品質なシステム提供を目指す。

（１１５９文字）

まとめ

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

参考図書

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

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