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

解答の論理構成

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

誤りやすいポイント

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

FAQ

解答の論理構成

1. ステークホルダの特徴整理
   • 【問題文】では、ステアリングコミッティのメンバである「営業担当役員の N 常務」について
     「プロジェクトへの直接の関与は少なかったが、…プロジェクトへの関心は高かった。」
     と記載されています。
   • すなわち “関与度（パワー）は低め／関心度は高い” ステークホルダに該当します。
2. コミュニケーション計画のセオリー
   • パワーが低く関心が高い相手には、要所要所でこちらから情報を提供し、疑問や懸念を吸い上げておく“Keep Informed”型の対応が推奨されます。
   • 多人数が集まる週次会議やファイルサーバの閲覧では、意思決定に必要な本質情報が埋もれやすく、エグゼクティブの時間を奪う恐れがあります。
3. 解答群の比較
   • ア：大量の管理情報を自分で“閲覧”させる → 情報過多・パッシブ
   • イ：週次会議へ“毎週出席”させる → 時間拘束が大きい
   • エ：月次報告書を送付 → 一方通行で双方向性に欠ける
   • オ：質問を“待つ” → 受け身でリスク残存
   • ウ：｢適時個別の場を設け、プロジェクトの成果や状況を具体的に報告｣ → 必要なタイミングで要点を直接共有し、即時の質疑応答も可能
4. 結論
   • 上記より、N 常務には能動的かつ個別最適な情報共有を行う「ウ」が最も効果的です。

誤りやすいポイント

• ｢関心が高いから週次会議へ招くべき｣と考え「イ」を選ぶパターン
  → エグゼクティブのスケジュール負荷を考慮していない。
• ｢毎月報告書があれば十分｣として「エ」を選ぶパターン
  → 双方向コミュニケーション不足で意思決定の質が下がる。
• ｢質問が来てから対応｣と受け身で「オ」を選ぶパターン
  → リスクが顕在化してからでは遅く、プロアクティブな情報提供が欠如。

FAQ

解答の論理構成

1. 責任分担マトリックスで明確にする内容
   問題文では、
   「事務局は、プロジェクトにおける工程ごとの a、責任及び権限を明確にするために、表1に示す責任分担のマトリックスを作成した。」
   と記載されています。一般に RACI などのマトリックスは “役割（Role）・責任（Responsibility）・権限（Authority）” を整理する手法であり、最初に来る語は「役割」です。
2. “業務担当の a であることと明記” の用法確認
   同じ段落で「要件定義、ユーザ受入テスト、移行の実行、及び設計の作業支援は、業務担当の a であることと明記した。」と繰り返し使用されています。ここも RACI の “Role” に当たり、「役割」でないと文が成立しません。
   以上より [a]＝「役割」。
3. ステークホルダ登録簿に記載する情報
   「コミュニケーション計画の一環で、プロジェクトに対する各ステークホルダの b 関係及び関与に関する情報を基に、ステークホルダ登録簿を作成した。 b が対立する可能性があるステークホルダに対して、印を付けた。」
   ステークホルダマネジメントでは、関心度や影響度と並び “利害関係（Stakeholder interests）” を分析します。「対立する」という表現も利害関係の衝突を示すものです。
   したがって [b]＝「利害」。
4. 結論
   a：「役割」
   b：「利害」

誤りやすいポイント

• 責任分担マトリックス＝RACIと連想して「責任」や「権限」を [a] に入れてしまうミス。問題文は既に「責任及び権限」と書いており重複してしまいます。
• ステークホルダ登録簿に関して「影響度」「関心度」と誤答するケース。文中に「対立する可能性」とあり、利害関係の衝突を示唆している点を見落としがちです。

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