情報処理技術者試験 プロジェクトマネージャー試験 午後II(論文)で、実際に2022年に合格した論文を紹介します。この論文は、私が受験直後に可能な限り記憶に残っている状態で残した論文です。制限時間2時間の試験であるため、理論の組み立てが甘かったり分かりづらい表現があったりしますが、「この程度はミスしても合格ラインに達する」という事例として参考にしてください。
設問引用
設問は以下の通りです。
問2 プロジェクト目標の達成のためのすテークホルダとのコミュニケーションについて
システム開発プロジェクトでは、プロジェクト目標（以下、目標という）を達成するために、目標の達成に大きな影響を与えるすテークホルダ（以下、主要すテークホルダという）との積極的なコミュニケーションを行うことが求められる。
プロジェクトの計画段階においては、主要ステークホルダへのヒアリングなどを通じて、その要求事項に基づきスコープを定義して合意する。その際、スコープとしては明確に定義されなかったプロジェクトへの期待があることを想定して、プロジェクトへの過大な期待や主要ステークホルダ間の相反する期待の有無を確認する。課題な期待や相反する期待に対しては、適切にマネジメントしないと目標の達成が妨げられるおそれがある。そこで、主要ステークホルダと積極的にコミュニケーションを行い、課題な期待や相反する期待によって目標の達成が妨げられないように努める。
プロジェクトの実行段階においては、コミュニケーションの不足などによって、主要ステークホルダに認識の齟齬や誤解（以下、認識の不一致という）が生じることがある。これによって目標の達成が妨げられるおそれがある場合、主要ステークホルダと積極的にコミュニケーションを行なって認識の不一致解消に努める。
あなたの経験と考えに基づいて、設問ア〜設問ウに従って論述せよ。設問ア あなたが携わったシステム開発プロジェクトの概要、目標、及び主要ステークホルダが目標に与える影響について、800字以内で述べよ。
設問イ 設問アで述べたプロジェクトに関し、”計画段階”において確認した主要ステークホルダの過大な期待や相反する期待の内容、過大な期待や相反する期待によって目標の達成が妨げられるおそれがあると判断した理由、及び”計画段階”において目標が妨げられないように積極的に行なったコミュニケーションについて、800字以上1,600字以内で具体的に述べよ。
設問ウ 設問アで述べたプロジェクトに関し、”実行段階”において生じた認識の不一致とその原因、及び”実行段階”において認識の不一致を解消するために積極的に行なったコミュニケーションについて、600字以上1200字以内で具体的に述べよ。
論文例
実際に合格と判定された論文は以下です。
１．プロジェクトの概要、目標およびステークパーホルダが目標に与える影響
１．１．プロジェクトの特徴
私はSI企業A社に勤めるプロジェクトマネージャーである。この度、事業会社B社向けインフラ更改案件を請け負った。
事業会社B社は３〜５年に１度の頻度で大規模なシステム更改をする。この度、2020年稼働開始の情報系システム群の更改を予定し、「配達分析システム更改など」大小30のプロジェクトを立ち上げた。そのプロジェクトの1つがインフラ更改である。
１．２．プロジェクトの目標
SI企業A社はインフラの構築は当然として、自動化コード（IaC）の納品も担当に含まれている。納品された自動化コードは、事業会社B社が必要に応じメンテナンスしつつ使用する。
プロジェクトの主目標は「情報系システムの安定稼働させるインフラの提供」である。これに加え、副目標「運用部門の自動化」もある。本論文では副目標について論述する。
１．３．ステークホルダが目標に与える影響
本プロジェクトが自動化に込めた期待は「採用戦略」「コスト削減」の２つがある。後者の期待「コスト削減」は運用部門が大きな影響を与えると考えた。なぜならば、自動化コードのコスト削減効果は、どの程度運用の標準化がなされているかに依存するからだ（同じような作業が多いならば、その分、自動化の効果が大きい）。
私は「事業会社Bがどの程度の運用標準化がなされているか」「運用部門がどの程度、標準化に真面目に取り組むか」が未知数であるため、運用部門には十分注意を払う必要があると考えた。
２．期待の内容と期待によって妨げられる目標、目標達成のためのコミュニケーション（計画段階）
２．１．相反する期待
事業会社B社CIOは自動化に「採用戦略」の期待を込めている。可能な限りの自動化を実現しテック系企業である事をアピールして、優秀な人材を集めようとする狙いである。実は、テック系メディアに自動化の取材を受ける日程も決まっている。
私は、この「採用戦略」の期待は「コスト削減」と相反すると考えた。なぜならば、自動化の対象が増えれば増えるほど、使用頻度の低い作業も自動化する事になるからだ（自動化によって減らせる手間よりも自動化コードをメンテナンスする手間の方が大きい）。
２．２．過度の期待
私は自動化によって「コスト削減」の過度の期待がある可能性を危惧した。なぜならば、十分に標準化されていない運用では自動化によるコスト削減効果は小さいからだ。
私はどの程度に標準化されているかを調査するために、要件定義フェーズの１週目時点で、事業会社B社運用部門に現状の運用手順書の提示を依頼した。運用手順書を見て、現状の作業数（例えば分岐が３つある手順書ならば作業数は２✕２✕２＝８とカウント）を集計した。この数は、SI企業A社内の同規模の運用と比較すると、2.5倍程度の作業数である。よって、私は、事業会社B社は十分に運用標準化されておらず、自動化のコスト削減効果は少ないと考えた。
以上の考察により、私は「コスト削減」の期待値を下げる調整が必要と考えた。
２．３．期待によって妨げられる目標
今のところ、期待「採用戦略」は全てを自動化してしまうため、自動化の費用対効果が低いものを含めて自動化コードを納品する予定である。もし、運用部門が「自動化は楽になるものではなく負担が増えるもの」と感じてしまえば、自動化を徐々に使わなくなってしまうだろう。
私はこのような考えから、期待「採用戦略」が目標「運用部門の自動化」を妨げると考えた。
２．４．目標達成のコミュニケーション
私は、まずプロジェクトオーナー（運用部門の部門長）に、自動化が期待以上の効果が得られない事を説明した。自動化によって手間が増える事もあるというのは「にわかには信じられない話」と思い、私は可能な限り定量的な説明を心がけた。自動化のメンテナンスに要するコストは、SI企業A社内の事例に基づき、年間0.15人月/作業数との前提で算出した。
プロジェクトオーナーは状況を理解し、私とプロジェクトオーナーの共同でCIO向けの説明資料を作成した。その後、CIOも状況を理解した。
最終的には、以下２つの施策を実施する事で、プロジェクトオーナーとCIO含め合意した。
1. SI企業A社サポートで運用部門の標準化を進める（当初計画には含まれないため、別プロジェクトとして立ち上げる）
2. 標準化できている作業のみを自動化する。ただし、標準化の範囲が拡大するにつれて、自動化の範囲を徐々に増やす。
３．認識の不一致とその解消方法（実行段階）
３．１．認識の不一致の原因
自動化コードの納品は、運用部門との認識を合わせるためにプロトタイプを使用し、さらにウォークルスーによる打鍵を運用部門に依頼した。打鍵の結果、自動化対象が標準化された業務であるにも関わらず「手作業よりも自動化の方が時間がかかり負担が増えている（自動化は過剰なチェックをする事もあるため、処理によっては非常に遅い事もある）」とのクレームをもらった。
私は「運用部門が楽になる業務を自動化の対象とする方針で差し支えないか」とCIOとプロジェクトオーナーに確認したところ、承認をもらった。
認識不一致の原因は、プロジェクトオーナーは「負担軽減のための自動化」を望んでいたにも関わらず、私が「標準化された業務を自動化する」ようにと限定的な指示してしまった事である。
３．２．認識不一致の解消
私は「負担軽減につながるものを自動化する方針である」旨を伝え、運用部門との認識不一致を解消させる事ができた。
しかし、私は認識不一致が再発するのではないかと考えた。というのは、私の伝え方の悪さにも責任があるが、運用部門が非常に受け身の姿勢であるため具体的で限定的な指示をせざるを得ない背景もあるからだ。
私は事業会社B社運用部門が受け身から自律的なチームに変わるように、少しずつ裁量のある指示に切り替えていった。
要件定義フェーズ開始から5週目頃は具体的な指示を求める事が多かった（OA票の問い合わせが50件/週）ものの、詳細設計頃には自律的に考えるようになった（QA票の問い合わせが2件/週）。
実際のプロジェクト
この論文は設問アの80%事実、設問イと設問ウは完全なフィクションです。私は本プロジェクトにPMではなくネットワーク担当の立場で参画し、期待値コントロールに失敗したため大きな損害を被っています。設問イと設問ウは「もし政治的な制約事項がなければどのようなプロジェクトになっていたのだろうか」「私がPMの立場だったらどのように行動していただろうか」という架空の話です。