プロマネ試験（午後Ⅱ）対策：令和４年秋問２を実際に解く！

セイジュン

午前Ⅱ（論文）対策。過去問題を使って、解法の流れを確認していくシリーズ、続けます。今回は令和４年（20222年）の秋試験から、プロマネ午後Ⅱの問２です。

こんにちは！セイジュン＠エンジニア応援隊(@39Seijun)です。論文の解法については、こちら午後Ⅱ対策でまとめました。今回は、前回に引き続き令和４年（2022年）の問題でプロット作成をやってみます。皆さんの学習の参考（半面教師）になりましたら。

さて、問２です。タイトルは「プロジェクト目標の達成ためのステークホルダとのコミュニケーションについて」です。ステークホルダを訳すと「利害関係者」ですね。一般的には「株主・経営者・従業員・顧客・取引先のほか、金融機関、行政機関、各種団体など、企業のあらゆる利害関係者」を指します。

ちなみに、「ステークホルダー」と語尾を伸ばさずに、「ホルダ」としていますが、これは情報処理技術者試験がかたくなに守っている癖ｗですね。「外来語のカタカナ表記において音引きを省略する」というのは、むかし日本工業規格（JIS Z 8301）に「その言葉が3音以上の場合には、語尾に長音符号をつけない」という規定があったことに由来しています。論文を書くにあたって、「ホルダー」と伸ばしても失格にならないのでノビノビ書きましょう。

問の本文は省略します。公式サイトでご確認ください。

では、いつも通り、先に設問ア~ウを抜粋、確認していきましょう。

さて、問の本文を読む前に、論文の骨組み（プロット）を、設問ア~ウに沿って作成してみましょう。設問での文字数指示から凡その文字数も補記してみます。

１．私が携わったシステム開発プロジェクトの概要と目標、主要ステークホルダが目標の達成に与える影響・・・設問ア（８００字以内の指示に応える）

１．１．プロジェクトの概要と目的（４００字）

１．２．主要ステークホルダが目標の達成に与える影響（４００字）

２．”計画段階”において確認した主要ステークホルダとの対応・・・設問イ（８００字以上１，６００字以内の指示に対して、１，２００字を想定）

２．１．”計画段階”で確認した主要ステークホルダの過大な期待や相反する期待の内容（４００字）

２．２．その期待によって目標の達成が妨げられるおそれがあると判断した理由(４００字）

２．３．”計画段階”で目標の達成が妨げられないように行ったコミュニケーション（４００字）

３．”実行段階”で生じた認識の不一致について・・・設問ウ（６００字以上１，２００字以内の指示に対して、８００字）

３．１．認識の不一致とその原因（４００字）

３．２．”実行段階”で認識の不一致を解消するために行ったコミュニケーション（４００字）

どうでしょう。凡そのバランス、こんな感じではないでしょうか。では問い本文をざっと見ていきましょう。

この本文も、他の設問同様に、冒頭で結論（出題者の主張）が述べられています。「システム開発プロジェクトでは、プロジェクト目標を達成するために、目標の達成に大きな影響を与えるステークホルダと積極的にコミュニケーションを行うこと」が重要というのが本問の結論です。

以降、２つのパラグラフのうち、１つめが”計画段階”、２つめが”実行段階”です。

まずは”計画段階”から。以下のようにロジカルに進みます。

・ステークホルダへのヒアリング等を通じて、要求時候に基づきスコープを定義して合意

・その際、明確に定義されなかった期待があることを想定し、過大な期待・ステークホルダ間の相反する期待の有無を確認

・これらの期待は適切にマネジメントしないと目標の達成が妨げれらる懸念あり

・よってステークホルダとコミュを行い、期待によって目標達成が妨げられないようする

次に、”実行段階”です。

・コミュニケーション不足によってステークホルダに認識の不一致が生じる懸念あり

・認識の不一致によって目標の達成が妨げられるおそれがある場合、ステークホルダと積極的にコミュして認識の不一致の解消に努める

ざっくりまとめると以上が問いの本文の論旨展開です。問１でも出ていた「ステークホルダ」というワードについて、本問ではスコープがあたっています。

実際のシステム開発プロジェクトに携わっている方にしてみれば、「あるある」ですね。ぱっと見、事例も浮かびやすく書きやすいかなとも思います。

他方、本問の特徴として２点。

１．設問が肉厚。特に、設問イが長文であり、論文記載に求められているものが多そう

２．問１に比べると、設問本文中に「例えば」という言葉がない

この2点の特徴から、個人的には問１を選んだほうが無難かなと思った次第です。

もうちょっと深掘りしていきましょう。本問は、プロットへの事例当て込みではなく、いくつかのキーワードを如何に具体的な事例に落とし込むかで考えてみます。

これが矛盾なく想定できれば、プロットに落とし込め、あとはガリガリ論文にまとめていけばOKですね。では、①から

①プロジェクト目標を何に設定するか

そもそも、このプロジェクトの目標は何か、そして似て非なるものなのですが、できあがったシステム（サービス）の目標は何か、です。プロジェクト計画の上位概念にプロジェクト憲章というものを設ける企業もありますが、そこの一丁目一番地に本プロジェクトの目標を書きます。

例えば、（かなり露骨に書きますが）

・喫緊に迫った既存インフラ保守切れへの対応ため、早期リリースを目標の第一に据える

・ユーザ数が多く社会的なインパクトも大のため、品質第一で進める

・社内営業職を利用者としており、その利便性の追及を第一にする

・極端な話、安く仕上げたい

・稼働後の安定運用が大事

一般的にはプロジェクトベースではQCD(品質・コスト・納期）、システムベースでは利便性や保守性、可用性などが考えられますね。

②主要ステークホルダは誰か

これ、間口を広げすぎると論旨が難しくなりそうです。「主要」「相反する」とありますから、最低でも毛色の異なるステークホルダを２名（２組織）浮かべましょう。

視点１．組織内を横で観た場合、利用者目線と運用・保守目線

例えば、営業部門と経理部門などが浮かびますね。

視点２．組織内を縦で観た場合、システムからのアウトプットに期待大の層と、入力負荷が嫌な層

例えば、経営企画部門と組合などが浮かびます。

まあ、一般的には組織・部門間の不一致として横並びがいいですね。

③”計画段階”での過大な期待・相反する期待は何か

②で決めた主要ステークホルダのそれぞれの過大な期待・相反する期待を浮かべます。

・システムの運用軽減：社内IT部門

・経営指数の可視化：経営企画部門

・伝票入力の負担軽減：経理部門・組合

これも「あるある」なので想定できそうですかね。うまく、「相反する」ところに着地させたいですね。

⑤”実行段階”での認識の不一致は何か

先に⑤にとびます。システム開発プロジェクトの”実行段階”での認識の不一致です。さすがに論文のテーマで「稼働後の」とは出来ないのですね。プロジェクト推進途中の「思っていたのと違う」という奴です。

・プロトタイプ検証の結果、想定よりも入力に手間がかかる

・経営指数の可視化に十分な情報が出力されていない、あるいはタイムラグがある

等々

④⑤コミュニケーションは何か

視点１．コミュニケーションの当事者

②の具体化と矛盾がないか。また、例えば「営業部門」という一つのステークホルダでも、部門長と担当者では異なるので、そこも改めて押さえておきましょう。

視点２．コミュニケーションの手法

一般にコミュというと面前・会話・会議を想定しがちですが、書面・メールなどもあります。特に、「言った言わない」の防止の観点から証跡を残す＝書面でのやり取りというのは重要です。まあ、書面で合意していても、「そういうつもりで読み取らなかった」と寝ころぶ人がいることもまた事実なのですが。。。

視点３．コミュニケーションの頻度

月次、隔週、週次、デイリー。色々ありますね。上記の手法とからめて（マトリックス化して）想定できますか。

例）部門長とは隔週会議体で。その後、即日議事録回付／担当者間は毎朝Web会議で。等々

いかがでしたでしょうか。ここまで、上手くマッピングできれば、あとは論文に落とし込めそうですね。対象とするプロジェクトについては、今回省きました。日経コンを読み込んで、上手く事例に当て込めそうな記事をピックアップしてみてください。

ちなみに、この「思っていたのと違う」問題というのは大昔からありまして。よく引き合いに出されるのがこちらのポンチ絵です。初出は1970年代のアメリカ、と聞きますが、まあそのくらい昔からこの手の問題はあるねということですね。ご参考まで。

【顧客が本当に必要だったもの。。。】

１．顧客が説明した要件

２.プロジェクトリーダーの理解

３．アナリストの設計

４．プログラマーのコード

５．営業の表現、約束

６．プロジェクトの書類

７．実際の運用

８．顧客への請求金額

９．得られたサポート

１０．顧客が本当に必要だったもの

いかがでしたでしょうか。では、また次回、過去問分析で！