プロジェクトマネージャ試験の午後Ⅱ論文のパーツ（ステークホルダ領域）をサンプル論文とともに公開します

　この記事では、プロジェクトマネージャ試験の午後Ⅱ論文のパーツ（ステークホルダ領域）をサンプル論文とともに公開します。

　サンプル論文を掲載する理由は、「ステークホルダ領域における論文のパーツ」を提供するためです。なぜパーツを提供するのかというと、午後Ⅱ試験の具体的な対策として、論文をパーツを準備しておくことが有効な方法だからです。

　プロジェクトマネージャ試験の午後Ⅱで、問題文を見てゼロから2000字超えの論文を書き上げることなんて不可能だと思いますよね。しかも、問題文に合わせる必要があるので、予め作っておいた論文を書いてもテーマに沿わない可能性が高く、それでは合格の確率は極低いです。

　アママネくんのこの感覚は正しいです。プロジェクトマネージャ試験のプロでないかぎり、「準備無し」で合格論文を書くのは無理です。

　ではどうすると良いかというと、準備をしておくんです。具体的に準備というのは、使い回しできる論文のパーツを用意しておくことです。

　私は都内の上場IT企業で、プロジェクトマネージャ試験対策の社内勉強会を2016年から主催しています。その活動の中で午後Ⅱ論文の添削をやっています。年40本として、合計で250本は添削しました。

　ここでは、私が添削した午後Ⅱ論文の中から、「合格レベル」と言い切れる水準の論文をいくつかピックアップしてみます。ぜひ、午後Ⅱ論文のパーツとして使用してみてください。つまり、つかえそうなところがあったら、パクってみてください！

プロジェクトマネージャ試験 平成19年 問1 情報システム開発プロジェクトにおける交渉による問題解決について

平成19年 問1 問題文

　プロジェクトマネージャには,プロジェクトの目標を確実に達成するため,プロジェクトが直面する様々な問題を早期に把握し,適切に対応することが求められる。中でも,利用部門や協力会社などのプロジェクト関係者(以下,関係者という)にかかわる問題は,解決に利害が対立することもあり,プロジェクトマネージャは交渉を通じて問題解決を図ることが必要となる。
　プロジェクト遂行中に関係者との交渉による問題解決が必要な場合として,“開発範囲の認識が異なる”,“プロジェクト要員の交代を求められた”,“リスクが顕在化して運用開始日が守れなくなった”などがある。
　プロジェクトにおける問題解決のために,プロジェクトマネージャは関係者と状況の認識を合わせた後,問題の本質を理解し,解決策としての選択肢の立案,優先順位の決定などを行う。続いて,これらを整理して関係者に提示するが,関係者の考え方や立場の違いなどによって,調整や合意のために交渉が必要になる。この場合,一方の主張が全面的に取り入れられて合意に至ることは少なく,説得や譲歩などを通じて,双方に納得が得られるように交渉し,問題を解決することが肝要である。

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

平成19年 問1 設問文

設問ア あなたが携わった情報システム開発プロジェクトの概要と,関係者との交渉が必要になった問題とその背景について,800 宇以内で述べよ。

設問イ 設問アで述べた問題を解決するための手順について具体的に述べよ。また,交渉時の双方の主張,説得した内容,譲歩した内容,合意に至った解決策を具体的に述べよ。

設問ウ 設問イで述べた手順と解決策について,あなたはどのように評価しているか。また,今後どのように改善したいと考えているか。それぞれ簡潔に述べよ。

平成19年 問1 サンプル論文

１－１　概要(272字)

　私はシステム開発ベンダーZ社でプロジェクトマネージャーとして働いている。今回私が担当したプロジェクトは、外食チェーン店A社の店舗販売状況の可視化システムの刷新である。現行システムはライセンス切れとなり、刷新に伴い、目玉機能として、店舗周辺の人流データ（携帯キャリアからの提供データを活用する）可視化機能が搭載される計画である。体制は2チーム最大8人・総工数約60人月・PJ期間は10ヶ月であった。

　特徴としては、①現行システムを使う既存業務があるため納期遵守である事と②開始して3ヶ月でコロナ禍となり、予算が非常に厳しくなった事である。

１ー２　関係者との交渉が必要になった問題とその背景（利害の対立）(304字)

　要件定義を計画通り2ヶ月で完了し、3月3週目の外部設計中盤で、コロナ禍が本格化した。緊急事態宣言により、人通りが減り、店舗への来店客数は8割減となった。この結果、A社のBIシステム利用部門である販売部から、システム要件の変更が要求された。具体的には、人流データ可視化機能の廃止と、代替として宅配販売実績データ可視化機能の追加である。この理由は、コロナ禍により、外食業では宅配販売が急速に普及したためだ。

　問題は、要件変更が発生したものの、A社が運用開始日の変更を認めなかった事である。背景にある利害の対立の焦点は運用開始日だった。

　A社：現行システムのライセンス期限の観点から、運用開始が遅れると利用部門の業務に多大な悪影響がある。

　Z社：費用を追加せずに運用開始目標日を守ることはできない。

２ー１　問題を解決するための手順（1128）

　計画段階では、問題を解決するための手順として主に以下の６つのSTEPを定め、合意していた。

　①まず、争点となる問題点について認識合わせをする。本PJでは、要件変更に伴う運用開始日について、合意できない状態が問題であるとした。また、スコープの変更となり得るため、3月3週に人流データ可視化機能の外部設計はストップを指示した。

　②問題の本質理解をする。原因分析と問題点詳細化を行う。この理由は、原因分析によってお互いの過失度合いをすり合わせ、問題点の詳細化によって交渉と譲歩を進めやすくすることである。本PJにおける原因は、コロナ禍であり、お互いに過失は無いとした。PJ開始時の両社取り決めでは、天災等による前提の変更リスクは基本的にお互いに過失は無く、発生状況踏まえて都度検討する、としていたためだ。問題点詳細化では、最も影響が大きいものは、BIシステムを使った既存業務ができなくなることであると合意した。つまり、宅配販売実績データ可視化は、既存業務には影響がほぼ無い。

　③解決策として選択肢を立案する。ここでは2つを立案した。選択肢の立案完了時点で3月4週を終えていた。

　選択肢(1)：クラッシングを用いて、11月の運用開始日を死守する。デメリットとして、コストは1.4倍になる。

　選択肢(2)：二段階リリースとする。11月の運用開始日には、現行BIシステムと同等の可視化機能だけを提供する。3ヶ月後の翌年2月に、分析宅配販売実績データ可視化機能を追加リリースする。要件定義への手戻りが発生することを考慮し、コストは1.1倍になる。

　④選択肢の優先順位を決定する。ここでは、選択肢(1)が優先で、次点を選択肢(2)であるとした。理由は、デメリットである費用増加が認められれば、当初の運用開始日を守ることができるためだ。

　⑤関係者に提示する。ここでは、A社利用部門である店舗販売部長とプロモーション部長、A社プロジェクト統括部門である情報システム部長、両社の責任者（経営層）が参加するステアリングコミッティに提示した。スコープ、コスト、納期等のベースラインが大きく変更となるためである。

　⑥関係者の考えなどを踏まえて調整や合意の交渉を行う。情報システム部門とステアリングコミッティは費用増加を、店舗販売部長とプロモーション部長は、11月の納期と機能のバランスをどのように考えているかを確認した。ステークホルダーそれぞれが重要視している項目はそれぞれ異なるため、ステークホルダーの考えを踏まえて、主張・譲歩を経て合意に向かった。解決策の合意完了時点で、4月2週を完了しており、進捗は当初計画と比較して1ヶ月の遅れとなっていた。

２－２　合意に至った解決策（485）

２－２－１　交渉時の双方の主張

　4月1週目の交渉開始時点における双方の主張は相容れなかった。まず、天災リスクに起因する場合、両社に過失は無い旨を合意した。また、ユーザとしては、選択肢(1)(2)共に、コスト負担は、コロナ禍によるA社経営状況悪化により絶対に認められない状態になっていた。ユーザーの主張は、コスト増・納期後ろ倒しは避けて欲しい、というものだった。ベンダとしては、スコープの変更であれば、コストと納期の変更は認めてほしい、というものだった。

２－２－２　説得した内容と譲歩した内容

　双方の主張を踏まえ、まず私が説得した内容は、選択肢(2)では、既存業務への影響は無い、という点だ。11月の第一段リリース時点で既存のBIシステムの機能は100%引き継ぐためだ。この点はユーザー部門から納得を得られた。しかし、コスト増を絶対に認められない、という状態だった。そこで、1.1倍増のコストはZ社で負担するとした。

２－２－３　合意に至った解決策

　解決策は二段階リリース案となった。スコープ変更となった責任はどちらにも無いとした上で、Z社はコストを譲歩し、A社は宅範販売可視化機能の納期を譲歩した、という形である。

３－１　私の評価（689）

　二段階リリースは奏功し、修正後の計画コスト・納期を遵守できた。A社からの評価も高く、本プロジェクトは成功と考えている。二段階リリースに向けて宅配販売データ可視化機能だけをサブプロジェクトとして分割したことで、スコープの変更の影響を最小限にすることができた。この理由としては、①ユーザー部門への丁寧な説明　と　②ステアリングコミッティからの協力を取り付けたことが挙げられる。

　①ユーザー部門への丁寧な説明

　二段階リリースになってしまうことをユーザー部門・ステアリングコミッティに対して、既存業務影響が無いことや運用サポート（ユーザー部門からの利用方法問い合わせ等）を強化することなどを説明して納得を得ながら進めたことが良かったと考えている。このように動いていた理由は、ユーザー部門は現場の業務が円滑に回ることが最優先であり、そこの心配をケアすることが納得を得るための最善と考えていたためだ。

　②ステアリングコミッティからの協力を取り付けたこと

　毎月月末に開催されるステアリングコミッティを普段から重視しており、計画の進捗状況を的確に報告していたことだ。結果、解決策の合意に至るまでの調整には、A社経営層の協力を取り付けることができた。具体的には、ステアリングコミッティにて二段階リリースを決定とし、トップダウンで二段階リリースをA社ユーザー部門へ伝達してもらうことができたのである。ステアリングコミッティはベースライン変更や想定外のリスクが顕在した場合に機能する。想定外のリスクが顕在することもあり得ると考え、普段からステアリングコミッティを重視する姿勢を取っていたことが奏功した。

３－２　今後の改善点（322）

　今後の改善点は、①天災レベルの問題が発生した場合の取り決めを厳格に定めておくことと②

　①天災レベルの問題が発生した場合の取り決めを厳格に定めておくことについてから記載する。機能に対する要求は、通常、契約条件等を定める際に、天災レベルの問題が発生することを考慮することは難しい。優先度が低いように感じるためだ。しかし、リスクとしては確実に存在し、発生した場合には、本プロジェクトのようにスコープの変更に繋がることは多いだろう。発生確率は小さくとも影響度としては極めて大きく、厳格に定めておくべきだ。具体的には、天災レベルの災害が発生したとしてもスコープが変更された場合には、発注側の費用の免責には繋がらない旨を契約条件に加えておくべきと考えている。

まとめ

　午後Ⅱの解き方そのものは、プロジェクトマネージャ試験対策として最強の参考書であるはみよちゃん本こと、翔泳社の「情報処理教科書 プロジェクトマネージャ」で勉強しましょう。

　このブログでは、あくまでパーツの用意に特化していきます。他のマネジメント領域のサンプル論文も用意していますので、ぜひご活用いただければ幸いです。