プロジェクトマネージャ午後Ⅱ論文対策｜実務経験を持つ一発合格者が書いた解答例【平成２７年度：問１】

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

問題文および設問

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

問題文

問１　情報システム開発プロジェクトにおけるサプライヤの管理について

　プロジェクトマネージャ（ＰＭ）は、自社で保有する要員や専門技術の不足などの理由で、システム開発の成果物、サービス、要員などを外部のサプライヤから調達して、情報システムを開発する場合がある。
　システム開発の調達形態には、請負、準委任、派遣などがあるが、成果物が明確な場合、請負で調達することが多い。請負で調達する場合、サプライヤは成果物の完成責任を負う一方、発注者はサプライヤの要員に対して指揮命令することが法的にできない。したがって、プロジェクトを円滑に遂行できるように、発注者とサプライヤは、その進捗や品質の管理、リスクの管理、問題点の解決などについて協議する必要がある。
　仮に、プロジェクトの進捗の遅延や成果物の品質の欠陥などの事態が生じた原因がサプライヤにあったとしても、プロジェクトの最終責任は全て発注者側のＰＭにある。そのため、発注者とサプライヤの間で進捗の管理と品質の管理の仕組みを作成し、実施することが重要になる。

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

設問ア

あなたが携わった情報システム開発プロジェクトにおけるプロジェクトの特徴、及び外部のサプライヤから請負で調達した範囲とその理由について、８００字以内で述べよ。

設問イ

設問アで述べたプロジェクトにおいて、発注者とサプライヤの間で作成した進捗の管理と品質の管理の仕組みについて、請負で調達する場合を考慮して工夫した点を含めて、８００字以上１，６００字以内で具体的に述べよ。

設問ウ

設問イで述べた進捗の管理と品質の管理の仕組みの実施状況と評価、及び今後の改善点について、６００字以上１，２００字以内で具体的に述べよ。

解答例

設問ア

１．プロジェクト概要とサプライヤからの調達

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

　私が担当したプロジェクトは、老朽化したオンプレミス販売管理システムの再構築である。発注側のＰＭとして、プロジェクトに参画した。
　プロジェクトの目的は、保守切れリスク解消、業務効率化、将来の拡張性確保であった。期間１年半、予算約３億円の規模である。このプロジェクトの特徴は、受注・在庫・出荷など販売管理の広範な業務が対象である点、及びＷｅｂ化やＡＰＩ連携等の新技術採用である。体制は自社とサプライヤＡ社の混成チームだが、自社要員は既存システム保守で逼迫し、新技術スキル・工数確保が困難であった。

１．２．サプライヤへの請負調達の概要

　本プロジェクトでは、外部サプライヤＡ社に対し、要件定義書に基づき、外部設計の一部、内部設計、実装、単体テスト、結合テストの一部工程を請負契約で調達した。具体的には、業務の中核であり、新技術を多用する受注管理、在庫連携、出荷管理の３サブシステムを対象とした。検収は工程ごとに成果物と基準に基づき実施した。
　請負で調達した主な理由は、以下の通り。
１）自社のリソース不足とスキルミスマッチ
　既存システム保守により新規開発要員が不足し、Ｗｅｂ化やＡＰＩ連携の開発経験者もほぼ不在であった。この人的リソース制約から、自社のみでの開発は困難と判断した。
２）Ａ社が有する専門技術の必要性
　Ａ社は採用技術の開発実績とノウハウが豊富であり、高品質・効率的な開発にはその活用が不可欠と考えた。
３）納期遵守
　１年半という厳しい納期を達成するには、経験豊富なＡ社の開発力でスピードを確保する必要があった。

　これらの理由から、特定範囲の工程と機能をＡ社へ請負で委託することが、最適解と判断した。

（７７１文字）

設問イ

２．進捗管理と品質管理の仕組みと工夫点
　本プロジェクトで、サプライヤＡ社との請負契約下、円滑な遂行と成功のため、以下の進捗・品質管理の仕組みを作成・実施した。請負では直接指揮命令できないため、役割責任を明確化し、客観情報に基づく協力関係の構築が目的だった。

２．１．進捗管理の仕組み

　請負契約下の進捗管理は、直接作業指示ではなく、成果物の納期遵守を促し、遅延リスクを早期に発見・共有し、協力して対策を講じることを主眼とした。具体的には、週１回の定例進捗会議を設け、当社（ＰＭ、リーダー）、Ａ社（ＰＭ、リーダー）が参加し、ＷＢＳに基づく各タスクの進捗、ＥＶＭ指標、重要課題・懸案事項、リスク、次の打ち手を確認し、定期的な意思疎通と認識齟齬の防止を図った。また、Ａ社からの週次進捗報告書フォーマットを統一し、ＷＢＳワークパッケージ毎の計画・実績工数、進捗率、完了予定日、遅延理由・対策を記載させ、客観評価と比較を容易にした。
　進捗管理において工夫した点は、以下の通り。
・ＥＶＭ（出来高管理）の導入と共有
　請負で直接把握しにくい作業実態を補うため、客観的な進捗評価手法としてＥＶＭを導入した。Ａ社には、ワークパッケージ毎のＰＶ、ＥＶ、ＡＣの週次報告を義務付け、当社側でＳＰＩ、ＣＰＩを算出し定例会議で共有した。ＳＰＩ低下時には、単に遅延指摘でなく、原因（仕様不明確、技術課題等）をＡ社と共に分析し対策協議の材料とした。これにより客観指標管理を実現し、早期の遅延検知と建設的な対策議論を促した。
・課題管理表の共同利用
　仕様疑問点、技術問題、環境制約等の課題を一元管理するため、クラウド上のプロジェクト管理ツールに課題管理表を作成し、当社・Ａ社で共同利用した。発生部門、起票者、内容、担当者、期日、ステータスをリアルタイムで共有・更新可能とし、特に当社側確認待ちによるＡ社作業停滞を防ぐため、当社側にも迅速対応を促した。これにより課題の見える化、ボトルネック特定、迅速な解決を促進した。

２．２．品質管理の仕組み

　請負でも最終的な品質責任は発注者にあるため、サプライヤ任せにせず、品質確保の仕組みを構築した。プロジェクト開始前に、Ａ社と協議の上で定量的な品質目標（レビュー指摘密度、テストバグ密度、重要バグ件数、バグ収束曲線、性能目標等）を設定し、契約書等で合意することで、目指す品質レベルを明確化し管理指標とした。また、各工程で納品される成果物（設計書、コード、テスト仕様書・報告書等）に対する受け入れ基準を具体的なチェックリストで定義し、事前にＡ社と合意することで、検収の客観性と効率性を高めた。設計書の網羅性・標準準拠、テスト報告書の消化率・バグ状況などを基準とした。
　品質管理において工夫した点は、以下の通り。
・合同レビューの実施
　Ａ社内の設計・コードレビューの一部に、当社の業務有識者やＩＴアーキテクトも参加する「合同レビュー」形式を採用した。これは、品質確認への主体的関与を示すと共に、業務要件の解釈や技術実装方針の認識齟齬を早期解消し、品質基準の目線合わせを目的とした。Ａ社には発注者意図を直接確認できるメリット、当社には開発プロセスの透明性確保の狙いがあった。
・品質状況の定量的報告と分析
　月次で品質報告会を実施し、Ａ社から品質目標に対する実績、テスト工程別バグ発生・収束状況、バグ原因分類と傾向の定量的報告を受けた。報告されたデータに基づき、パレート図等でバグ原因の集中箇所を特定するなど、共同で品質状況を分析した。特定された問題に対しては根本原因分析と再発防止策検討をＡ社に依頼し、実施状況もフォローした。これにより継続的な品質改善活動を促した。

（１５６６文字）

設問ウ

３．管理の仕組みの実施状況、評価、今後の改善点

３．１．管理の仕組みの実施状況と評価

１）進捗管理
　週次定例会議でのＥＶＭ指標の確認は、客観的な進捗把握に有効だった。結合テスト中盤のＳＰＩ低下時には、原因（ＡＰＩ連携仕様の当社側の情報提供遅延、Ａ社の技術者不足）を早期特定できた。
　ＥＶＭ導入は、請負下での客観的進捗把握に有効であり、具体的な数値共有がＡ社の主体的対応を促した。遅延が特定された箇所への集中対策で、納期遵守に貢献した。共同利用した課題管理表も迅速な問題解決に寄与。仕組み全体でオープンな連携を促し、早期発見・対応を実現した。
２）品質管理
　品質目標値はＫＰＩとして常に意識され、月次品質報告会で実績が評価された。合同レビューでは当社業務担当者から複雑な業務ロジック等への指摘・改善要望が出され、Ａ社はこれを反映した。品質報告会でのパレート図によるバグ分析では、特定モジュールの製造バグが多発傾向にあることを掴み、Ａ社の重点レビューとテスト強化に繋がった。
　合同レビューは、請負で伝わりにくい業務背景等を早期伝達でき、認識齟齬を防止し品質向上に大きく貢献、信頼関係構築にも繋がった。定量的目標と報告・分析プロセスは、客観的な把握に基づく具体的な品質改善を可能にした。結果、システムテスト以降の重大不具合は抑制され、品質目標を達成できた。発注者の主体的関与の重要性を示し、成功に不可欠だった。

　以上から、これらの仕組みは、当社・Ａ社が協力して目標達成する上で有効に機能したと評価する。

３．２．今後の改善点

　今回の経験を踏まえ、今後のサプライヤ管理で以下改善に取り組みたい。
１）リスク連動の進捗予測精度向上
　ＥＶＭは有効だったがＥＡＣ精度に課題があった。今後はリスク発生確率等を考慮した、より現実的な進捗予測（例：３点見積もり）をＡ社に依頼・共有する仕組みを導入し、遅延リスクのより高精度な察知と対策を可能にしたい。
２）非機能要件テスト早期具体化と品質データ分析効率化
　非機能要件（性能、セキュリティ等）の測定方法、基準、環境、目標値を設計早期段階でＡ社と詳細に詰め、早期合意するプロセスを強化し、リスク低減と手戻り防止を図る。また、品質報告会のデータ集計・分析工数を削減するため、各種開発支援ツールを連携させ、品質データを自動収集・ダッシュボード可視化する仕組み導入を検討し、分析効率化と迅速な改善に繋げたい。
３）契約段階での管理プロセス詳細化
　今回有効だったＥＶＭ報告、合同レビュー、品質目標設定、課題管理ツール利用等の管理プロセスについて、ＲＦＰや契約段階で実施内容・頻度・役割等をより具体的に明記し、初期段階で双方の期待値を明確にすり合わせ、認識齟齬防止と円滑な協力関係構築を徹底したい。

（１１９４文字）

まとめ

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

参考図書

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

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