🍀概要
プロジェクトマネージャ試験 平成30年 午後2 問1について、AIを活用して、詳細分析した結果を示します。
本分析は、AIが問題文からその背景にある本質的な課題を深く掘り下げ、プロジェクトマネージャが目指すべき理想像の一端を理解することに役立つよう、多角的な視点から考察したものです。これにより、単なる模範解答の提示に留まらず、論述問題を通して試される思考プロセスや問題解決のアプローチを深く理解するための示唆を提供します。
🧾問題・設問（PM-H30-1-PM2-Q1）
出典：情報処理推進機構 プロジェクトマネージャ試験 平成30年 午後2 問1(🔗取り扱いガイドライン)
📘問題
■タイトル
システム開発プロジェクトにおける非機能要件に関する関係部門との連携について
■内容
システム開発プロジェクトにおいて，プロジェクトマネージャ(PM)は，業務そのものに関わる機能要件に加えて，可用性，性能などに関わる非機能要件についても確実に要件が満たされるようにマネジメントしなければならない。特に非機能要件については，利用部門や運用部門など(以下，関係部門という)と連携を図り，その際，例えば，次のような点に注意を払う必要がある。
・非機能要件が関係部門にとってどのような意義をもつかについて関係部門と認識を合わせる
・非機能要件に対して関係部門が関わることの重要性について関係部門と認識を合わせる
このような点に注意が十分に払われないと，関係部門との連携が不十分となり，システム受入れテストの段階で不満が続出するなどして，場合によっては納期などに大きく影響する問題になることがある。関係部門と連携を図るに当たって，PMはまずプロジェクト計画の段階で，要件定義を始めとする各工程について，非機能要件に関するWBSを設定し，WBSの各タスクの内容と関係部門を定め，関係部門の役割を明確にする。次に，関係部門と十分な連携を図るための取組みについて検討する。それらの内容をプロジェクト計画に反映した上で，関係部門を巻き込みながら一体となってプロジェクトを推進する。
あなたの経験と考えに基づいて，設問ア～ウに従って論述せよ。
📗設問
■設問ア
あなたが携わったシステム開発プロジェクトの特徴，代表的な非機能要件の概要，並びにその非機能要件に関して関係部門と連携を図る際に注意を払う必要があった点及びその理由について，800字以内で述べよ。
■設問イ
設問アで述べた代表的な非機能要件に関し，関係部門と十分な連携を図るために検討して実施した取組みについて，主なタスクの内容と関係部門，及び関係部門の役割とともに，800字以上1,600字以内で具体的に述べよ。
■設問ウ
設問イで述べた取組みに関する実施結果の評価，及び今後の改善点について，600字以上1,200字以内で具体的に述べよ。
📔出題趣旨・採点講評(IPA)
■出題趣旨
プロジェクトマネージャ（PM）は，機能要件に加えて，非機能要件についても確実に要件が満たされるようにマネジメントしなければならない。そのためにPM は，非機能要件に関して，利用部門や運用部門などの関係部門との連携に注意を払った上で，関係部門を巻き込みながら一体となってプロジェクトを推進しなければならない。
本問は，非機能要件に関して，WBS の各タスクの内容と関係部門を定め，関係部門の役割を明確にし，関係部門と十分な連携を図るための取組みを検討することなどについて，具体的に論述することを求めている。論述を通じて，PM として有すべき，非機能要件に関して，関係部門と十分に連携を図りながら推進することについての知識，経験，実践能力などを評価する。
■採点講評
＜全問共通＞全問に共通して，“論述の対象とするプロジェクトの概要”で記入項目間に不整合がある，又はプロジェクトにおける立場・役割や担当した工程，期間が論述内容と整合しないものが見られた。これらは論述の一部であり，評価の対象となるので，適切に記述してほしい。記述したプロジェクトの特徴を踏まえ，設問で問われている事項に対応してプロジェクトマネージャ（PM）としての経験と考えに基づいて論述してほしい。
＜問1＞問1（システム開発プロジェクトにおける非機能要件に関する関係部門との連携について）では，プロジェクト計画の段階で関係部門の役割を明確にした上で，関係部門と十分な連携を図るための取組みを検討し，関係部門と一体となってプロジェクトを推進することについて，具体的に論述できているものが多かった。一方，関係部門と連携を図る際の注意点が不明確な論述，非機能要件の内容を詰める作業の記述に終始してプロジェクト管理の視点に欠ける論述など，関係部門との連携に関するPM の対応内容としては不十分な論述も見られた。
🪄詳細分析(AI)
📝3行まとめ
- 【背景】非機能要件は品質・安定性を左右し、関係部門との不十分な連携は後工程で重大な手戻りやコスト増を招きます。
- 【PM視点】利用・運用部門と早期に認識を合わせ、非機能要件をWBSに組み込み、役割と責任を明確化する視点が重要です。
- 【行動・着眼点】初期段階から関係部門を巻き込み、レビューや合意形成を通じて要件を具体化・検証し、共通理解を継続的に維持すべきです。
🧭システム開発プロジェクトにおける非機能要件に関する関係部門との連携についての考察
1. 問題の背景と現状分析
- 現状の課題・問題点:
- システム開発において、要件は、利用者が直接触れる「機能要件（何ができるか）」と、システムの品質や特性を定める「非機能要件（どのように動くか）」（例：可用性、性能、セキュリティ）に大別される。
- 多くのプロジェクトで、議論の中心が、目に見えて分かりやすい「機能要件」に偏りがちであり、「非機能要件」の検討が、後回しにされたり、軽視されたりする傾向がある。特に、非機能要件のオーナーは、システムの利用者だけでなく、運用部門やインフラ部門など、多岐にわたる「関係部門」であるため、連携が難しい。
- 関係部門との連携が不十分なまま開発を進めると、彼らの要求や制約が、開発の後工程や、受入れテストの段階になって、初めて噴出する。例えば、「こんなレスポンス性能では、業務で使えない」「このセキュリティレベルでは、運用基準を満たせない」といった問題である。
- この段階での手戻りは、アーキテクチャの変更を伴うことも多く、プロジェクトの納期やコストに、致命的な影響を与える。
- 変化の必要性の背景:
- ユーザー体験（UX）の重視: システムの価値が、単に機能が提供されることだけでなく、それが、いかに快適に、速く、安全に使えるか、という「ユーザー体験（UX）」によって、大きく左右されるようになった。非機能要件は、このUXを決定づける、重要な要素である。
- システムの安定稼働への要求: システムが、ビジネスの根幹を支えるようになり、その停止や性能劣化が、直接的な事業損失に繋がるため、可用性や性能といった非機能要件の重要性が、飛躍的に高まった。
- DevOpsの思想: 開発（Development）と運用（Operations）が、密接に連携・協力することで、システム開発のスピードと品質を両立させる、というDevOpsの考え方が普及し、開発の初期段階から、運用部門を巻き込むことの重要性が認識されるようになった。
2. 理想像の抽出と具体化
- あるべき理想的な状態:
- 関係部門との共通認識の醸成: プロジェクトの初期段階で、PMが、主要な非機能要件（例：性能、可用性）を取り上げ、それが、なぜ重要なのか、関係部門（利用部門、運用部門など）にとって、どのような意義を持つのかについて、ワークショップなどを通じて、共通の認識を醸成している。
- WBSへの明確な組み込みと役割分担: プロジェクト計画（WBS）の中に、非機能要件に関するタスク（例：「性能要件定義」「セキュリティ設計」「運用テスト計画」）が、明確に定義されている。さらに、各タスクについて、主担当となる開発チームだけでなく、レビューや承認に関わるべき「関係部門」と、その「役割」が、具体的に明記されている。
- ライフサイクルを通じた継続的な連携: 関係部門との連携が、要件定義やテストといった、特定の工程に限定されない。設計、開発、テストという、開発のライフサイクル全体を通じて、関係部門が、レビュー、プロトタイプ評価、実機テストなどに継続的に関与し、フィードバックを提供する、というプロセスが確立されている。
- 客観的で測定可能な要件定義: 非機能要件が、「使いやすく」「速く」といった、曖昧な言葉でなく、「〇〇画面の応答時間が、95%のトランザクションで3秒以内」「年間計画停止時間を除く、稼働率99.9%」といった、客観的かつ測定可能な形で、関係部門と合意の上で、定義されている。
- 克服すべき障壁:
- 非機能要件の不可視性: 非機能要件は、機能要件と比べて、目に見えにくく、その重要性が、利用部門などに理解されにくい。
- 関係部門のサイロ化: 開発、運用、インフラといった部門が、縦割り（サイロ化）になっており、部門間の円滑なコミュニケーションが阻害される。
- 専門知識の不足: PMや開発者が、性能やセキュリティといった、非機能要件に関する高度な専門知識を持っておらず、関係部門と対等に議論できない。
- 利害関係者の視点:
- プロジェクトマネージャ: 後工程での、非機能要件に起因する、大規模な手戻りリスクを、未然に防止できる。プロジェクトを、安定的に、かつ、予測可能性高く、運営できる。
- 関係部門（運用部門など）: 自分たちの要求（運用性、保守性など）が、開発の初期段階から考慮されるため、完成したシステムを、スムーズに、かつ、安定的に、引き継ぎ、運用することができる。
- 利用部門: 機能が使えるだけでなく、サクサク動き、いつでも安心して使える、満足度の高いシステムを手にすることができる。
- 開発メンバー: 非機能要件が、早期に、かつ明確に定義されるため、アーキテクチャ設計や実装において、手戻りのない、効率的な開発が可能になる。
3. 要約
- [200文字]要約:
非機能要件の軽視は、後工程での致命的な手戻りを招く。理想像は、PMが、運用部門などの関係部門と、早期にその重要性の認識を合わせること。WBSに非機能要件タスクと関係部門の役割を明記し、開発の全工程で連携する。これにより、手戻りを防ぎ、真に価値あるシステムを実現する。 - [400文字]要約:
非機能要件（性能、可用性など）は、機能要件の陰に隠れがちだが、その不備は、後工程で致命的な手戻りを引き起こす。理想的なPMは、まず、運用部門などの関係部門と、非機能要件の重要性について、共通認識を築く。その上で、WBSに、非機能要件に関するタスクと、関係部門の役割を明確に定義する。開発の全工程を通じて、関係部門をレビューやテストに巻き込み、継続的に連携することで、手戻りのない、高品質なシステムを実現する。 - [800文字]による詳細な考察:
本問題は、システム開発における成功の鍵が、コードを書く前の「連携」と「合意形成」にあることを、非機能要件という、特に部門間の連携が不可欠なテーマを通じて、示している。これは、現代のシステム開発が、もはや開発部門だけでは完結し得ない、オーケストラのような、総力戦であることを物語っている。- あるべき理想像とは、「ビジネス価値と技術的健全性の両立を目指す、ライフサイクルを通じた協働（コラボレーション）モデル」の構築である。このモデルでは、非機能要件は、開発の後工程で考慮される「付加的な品質特性」ではない。それは、システムのアーキテクチャの根幹をなし、ビジネスの成功に直結する、「本質的な要件」として、機能要件と対等に扱われる。PMは、このオーケストラの「指揮者」として、様々な楽器（関係部門）の特性を理解し、彼らが、それぞれの専門性を最大限に発揮しつつ、全体として調和（整合性）のとれた音楽（システム）を奏でられるように、導く役割を担う。例えば、性能要件については、利用部門（ビジネスインパクト）、運用部門（監視方法）、インフラ部門（サイジング）、開発部門（実装方法）を、一堂に会したワークショップで議論させ、全員が納得する、現実的かつ測定可能な目標値を、共同で設定する。
- 理想像実現へのアプローチとして、PMは、プロジェクト計画の策定時に、「ステークホルダ・エンゲージメント計画」と「コミュニケーション計画」の中で、非機能要件に関する、関係部門との連携プロセスを、具体的に定義することが不可欠である。WBSを作成する際には、ISO/IEC 25010（システム及びソフトウェア品質モデル）などの、国際標準の品質特性（機能性、信頼性、使用性、効率性、保守性、移植性、セキュリティ）をフレームワークとして用い、要件の洗い出し漏れを防ぐ。各非機能要件に対して、「要件定義」「設計」「実装」「テスト」の各工程で、どの部門が、何をすべきか（役割と責任）を、RACIチャートなどを用いて明確化する。そして、プロジェクトの定例会には、常に運用部門などのキーパーソンに出席を求め、継続的な情報共有と意見交換の場を確保する。
- 期待される効果は、非機能要件に起因する、大規模な手戻りや、本稼働後のトラブルを、未然に防止することである。これにより、プロジェクトのコスト超過や納期遅延のリスクを、大幅に低減できる。また、開発と運用の間に、協力的な関係が築かれ、組織全体のDevOps成熟度の向上にも貢献する。
- 考慮すべきリスクは、関係部門間の利害が対立し、合意形成が困難になることである。PMには、中立的な立場で、議論をファシリテートし、プロジェクト全体の最適解へと導く、高度な調整能力と交渉力が求められる。