応用情報技術者 2015年 春期 午後 問09

解答の論理構成

1. 本文には、下線部①について「W部長は、プロジェクトメンバを、業務担当は①利用部門から専任で選出し、開発担当はシステム部から専任で選出してPMの配下に置いた」とあります。
2. その背景として「新物流システムは利用部門の意見を最大限に取り入れ、利用者の操作画面を一新するとともに、ワークフローを取り入れて業務プロセスを大きく変えようとしていた。そのため、利用部門をプロジェクトに巻き込んで一体感を生むことが必要であった」と記述されています。
3. つまり、業務プロセスの大幅な変更に対して抵抗を抑え、円滑な合意形成と情報共有を行うには、利用部門が主体的に関与する体制が不可欠です。
4. そこで、業務担当を「利用部門から専任で選出」し、コミュニケーション量と質を高めることで「一体感」を醸成することが狙いと読み取れます。

誤りやすいポイント

• 「専任で選出＝リソース確保」が狙いと短絡的に解釈し、コミュニケーション面を見落とす。
• 体制図や責任分担マトリックスの情報に引っ張られ、権限分散や責任追跡を主目的と考えてしまう。
• 「利用者の操作画面刷新」など技術的側面に注目し、組織文化や抵抗感といった人的側面を軽視する。

FAQ

解答の導き方

1. 問題文からN常務の属性を整理します。本文には「営業担当役員のN常務」とあり、かつ「プロジェクトへの直接の関与は少なかった」「プロジェクトへの関心は高かった」とあります。これらから読み取れる点は次の通りです。

• 役員であることから影響力（権限、パワー）は高い可能性がある（本文に明示はないが職位から推測できる）。
• 「プロジェクトへの関心は高かった」ので関心度は高い。
• 「プロジェクトへの直接の関与は少なかった」ので日常的に会議へ出席したり細かい報告を逐次受ける余裕は少ないと判断できる。

1. ステークホルダ管理の観点では、権限（パワー）と関心度が高い相手には能動的な働きかけ（manage closely）が必要です。しかし「直接の関与は少ない」ことを考慮すると、頻繁な定例出席の要求や大量の詳細資料の一方的提供は実務上非効率です。したがって、短時間で意思決定に結びつく、タイミングを合わせた個別の報告機会が最も効果的です。
2. 選択肢と対応付けて比較します。

• ア：共有ファイルサーバでの閲覧提供は受け身であり、忙しい役員が能動的に詳細を確認することを期待するのは現実的でないため不適切です。問題文にも「共有ファイルサーバに格納」され閲覧可能であると記載されていますが、それだけでは確実な関与を得られません。
• イ：週次の進捗会議への出席は時間負荷が大きく、「直接の関与は少なかった」人物には過度です。問題文は事務局が週次会議を開催していると述べていますが、そこに役員レベルを拘束するのは非効率です。
• ウ：適時に個別の場を設け、成果や状況を具体的に報告する方法は、短時間で重要事項や意思決定ポイントを伝えられ、期待される効果（例：「商品の納期が大幅に短縮されること」への説明）に直接結び付けられます。高権限・高関心・低関与の組合せに最も合致します。
• エ：毎月送付する報告は定期的で有用ではあるものの、重要な判断を要する場面や突発的な意思決定には「適時性」が不足します。補助的手段としては有効でも最優先の方法ではありません。
• オ：質問や意見を待つ受動的対応は、関心が高く影響力のあるステークホルダに対しては不十分で、期待や懸念を見落とすリスクがあります。

誤りやすいポイント

• 「プロジェクトへの直接の関与は少なかった」＝「影響力が低い」と誤解すること。直接関与（作業関与）と組織内での影響力（パワー）は別の概念です。本文の記述は前者を示しており、後者は職位等から判断します。
• 共有ファイルや月次の文書だけで重要ステークホルダの支持を得られると考えること。受動的手段は見落としや理解不足を招きやすいです。
• 頻度（毎週参加させるなど）を優先して、相手の時間制約や意思決定スタイルを考慮しないこと。高位のステークホルダには「質（短く的確）」が重要です。

FAQ

解答の導き方

1. a（役割）について

• 問題文に「事務局は、プロジェクトにおける工程ごとの a、責任及び権限を明確にするために、表1に示す責任分担のマトリックスを作成した。」とあります。ここは「X、責任及び権限」の並列構造になっており、責任や権限と並ぶ語として自然なのは「役割」です。
• 同文の別箇所に「責任分担のマトリックスに、要件定義、ユーザ受入テスト、移行の実行、及び設計の作業支援は、業務担当の a であることを明記した。」とあり、「業務担当の役割であること」と読むのが文法的にも意味的にも自然です。
• 表1を見ると、工程ごとにPM、業務担当、開発担当 の欄があり、セルに "管理責任"、"実行責任"、"作業支援" といった表示があります。これは「誰が、どの工程でどのような役割（＝役目）を持つか」を示すためのマトリックスであり、空欄に入る語は "役割" が適切です。以上よりaは 役割 と確定できます。

1. b（利害）について

• 問題文に「プロジェクトに対する各ステークホルダの b 関係及び関与に関する情報を基に、ステークホルダ登録簿を作成した。b が対立する可能性があるステークホルダに対して、印を付けた。」とあります。ここで「対立する可能性がある」と結びつく語として最も適切なのは「利害」です。
• 「利害が対立する」あるいは「利害関係が対立する」という表現はステークホルダ分析で一般的に使われ、ステークホルダ登録簿に「誰と利害が衝突する可能性があるか」を示してマーキングするのは典型的な運用です。さらに文中ですでに「関与」が明示されているため、空欄は「関与」以外の語である必要があり、文脈からもbは 利害 が最適です。

誤りやすいポイント

• 空欄aを「責任」や「権限」と誤答するケース：空欄の直後に「責任及び権限」と既に書かれているため、同じ意味を重ねて入れるのは文法的に不自然です。
• 空欄aを「担当」や「職務」としてしまうケース：「責任分担のマトリックスに…は、業務担当の 担当 である」となると冗長・重複になります。問題文の流れから「役割」が最も自然です。
• 空欄bを「関心」や「影響」としてしまうケース：どちらも意味は近いですが、文中の「対立する可能性がある」に最も直結する語は「利害」です。利害は「利益や不利益（interests）」の方向が異なることで対立が発生することを表します。
• RACI等のマトリックスの理解を誤るケース：RACIはResponsible / Accountable / Consulted / Informedの略であり、一般に日本語ではそれぞれ「実行責任（Responsible）」「管理責任／説明責任（Accountable）」「協議・相談（Consulted）」「通知・報告（Informed）」のように訳されます。責任分担マトリックスが「何（役割）・誰の責任か（責任）・どの程度の決裁権か（権限）」を示す形式である点を押さえておくと混乱が減ります。

FAQ

解答の論理構成

1. 【問題文】では、A社が「社内のプロジェクト活動の標準化を推進中」である一方、「その時点では作業の進捗度合に関する正式な社内基準はなかった。」と明記されています。
2. さらに、X君は「②本プロジェクトではX君がまとめたこの基準に従って報告するように回答し、プロジェクト内に周知徹底した」とあり、暫定的に独自の基準を採用した状況です。
3. 標準化を推進する立場のA社としては、個別プロジェクトで生まれた実践的な基準を放置せず、全社的なルールとして採用できるかを判断・整備することが求められます。
4. 以上より、「X君がまとめた基準を正式な社内基準とすべきかを検討する」という解答が導かれます。

誤りやすいポイント

• 「周知徹底する」「マニュアル化する」だけでは、標準化推進の“検討・承認プロセス”が抜け落ちるため不十分です。
• 「基準を破棄する」「新たに作り直す」と答えると、【問題文】に示された“暫定基準”を活かす発想が欠如してしまいます。
• 「全プロジェクトに適用する」と即断すると、正式承認前に適用範囲を決定してしまう点で論理の飛躍になります。

FAQ

解答の論理構成

• 【問題文】では質疑応答の手段がばらばらで、「電話や対面による連絡内容を文書化したりすることに多くの時間を費やしていた。さらに、必要項目が漏れていることが度々あった。」と記述されています。
• 下線③で「プロジェクトにおける質疑応答の連絡手段を電子メールに限定」し、媒体は統一できましたが、同じ段落にある「必要項目が漏れている」課題は未解決です。
• 情報欠落を防ぐには、質問・回答メールに必ず記載すべき項目（案件ID、担当者、期限、影響範囲など）をテンプレート化し、入力漏れを構造的に防止する施策が必要です。
• よって、③に加えて行うべき追加策は「連絡が必要な項目を定める。」となります。

誤りやすいポイント

• 媒体を電子メールに限定すれば全て解決と早合点し、情報の質（内容不足・抜け漏れ）に触れない。
• 「フォーマットを配布する」「テンプレートを作成する」など手段を答え、設問が求める“何をすべきか”という内容面（項目定義）を外す。
• 下線③の対策と同じ内容を繰り返し記述してしまう。

FAQ

解答の論理構成

1. 前提確認
   【問題文】には「A社は、詳細設計からソフトウェア結合テストまでの開発工程について、過去に取引実績があった B社と請負契約を締結した。」と明記されています。
2. 請負契約の特性
   請負契約では、発注者は成果物に対して「完成責任」を求めますが、受注者の要員に対して直接の業務指示を行う権限は持ちません。指揮命令権は受注者（B社）にあります。
3. 本件の状況
   X君は「B社の開発要員を招集してプログラムの変更を直接指示」しようとしていました。これは発注者側が受注者の要員を直接動かす行為に当たり、請負契約の枠組みを逸脱します。
4. Y課長の指摘理由
   「開発工程が請負契約なので、受注者の要員への直接指示は契約違反になる」──これが下線④でY課長が示した理由です。

誤りやすいポイント

• 準委任契約と請負契約の違いを取り違え、どちらでも直接指示が可能と思い込む。
• 「緊急対応だから例外的に直接指示してよい」と誤解する。請負契約は緊急でも指揮命令系統を崩さないことが原則です。
• プロジェクト体制図に「開発リーダ」が存在するため、社内のリーダが開発要員まで指揮できると早合点する。

FAQ