プロジェクトマネージャ 2016年 午後1 問02

解答の導き方

1. 図1では、左側の「現場部門が追加・変更によって実現したい要求事項」から、（i）を経て「A社システム部が提示する要求事項一覧」に進み、さらに（ii）の先にある項目を問われています。したがって、空欄には、要求事項一覧を受け取ったP社側で生じる段階が入ります。
2. 本文では、P社が要求事項一覧を「そのまま追加開発のインプット」とし、要求事項のレビューをほとんど実施していなかったと説明されています。また、業務用語の解釈がA社とP社で異なり、その違いが受入テストまで見つからないこともありました。これらは、要求事項一覧をP社がどう理解したかに関する問題です。
3. 改善プロセスの（1）では、P社が内容を問い返したり質問したりして、「要求事項の解釈にA社と違いがないこと」を確認します。この確認の対象となるのは、一覧そのものではなく、P社が読み取った要求事項です。
4. さらに、（4）では、その後にP社が要求事項をブレークダウンして要件定義書を作成します。したがって、空欄は要件定義書ではなく、その前段階に当たる「P社が解釈した要求事項」と判断できます。

誤りやすいポイント

• 空欄を「要求事項一覧」とすると、図1ですでに示されている中央の項目と重複します。
• 「要件定義書」は、要求事項の解釈・レビューを経た後に作成されるものです。本文の（4）の順序を確認しましょう。
• 問題の焦点は、要求事項の提示だけでなく、P社がそれをどう解釈したかです。A社とP社の解釈のずれに注目します。

FAQ

解答の導き方

誤りやすいポイント

• P社が要求事項のレビューや要件定義書の作成を行うことから、要求事項一覧を定義する責任もP社にあると考えてしまうことがあります。レビューや整理を担うことと、要求事項を定義する責任は別です。
• 現場部門が要求を提示するため、責任も現場部門にあると考えるのは誤りです。本文では、A社システム部が現場部門の要求を受けて一覧を提示し、必要に応じて見直します。
• A社システム部の責任であるからといって、P社は提示された一覧をそのまま受け入れればよいわけではありません。前回開発の問題を防ぐため、P社にも解釈の確認やレビューが求められています。

FAQ

解答の導き方

誤りやすいポイント

• （i）と（ii）を、単に「顧客側の作業」と「開発会社側の作業」に分けるのではなく、図1の矢印が示す情報の受け渡しで考えます。
• (2)はP社からA社システム部への質問が含まれますが、重要なのはA社システム部が現場部門に確認して要求事項を見直す点です。
• (3)はP社による整理を含み、(5)は他システムへの影響確認や要件定義書のレビューを含みます。ほかの観点を含む場合でも、（i）の問題を解決する働きがあれば対象に含めます。
• (1)と(4)は、要求事項一覧の内容がP社に正しく伝わり、同じ解釈になっているかを確かめる施策です。現場部門の意図を一覧に反映する施策とは区別します。

FAQ

解答の導き方

1. 要望1では、相互の認識の違いが進捗や品質の問題につながっているため、その違いをできるだけ早く見つけ、影響を小さくしたいとしています。したがって、問題が起きてから対応するのではなく、認識のずれが生じやすい段階で予防・発見することが重要です。
2. 前回開発では、要求事項の背景や意図が伝わっていないこと、業務用語の解釈がA社とP社で異なることなどが、大きな手戻りにつながっています。これらは、要求事項を理解して要件や設計に具体化する過程で、関係者間の認識を十分に合わせられていないことが原因です。
3. R主任の改善案には、文章中心の開発ドキュメントに図表を活用して認識誤りを予防することに加え、コミュニケーションの質と量を高めるとあります。これを効果的に行うには、要求事項の解釈や設計内容を関係者間で確認する段階が適しています。実装やテストの段階で認識の違いが判明すると、修正範囲が広がり、手戻りも大きくなりやすいためです。
4. したがって、bには、開発の早い段階を表す「上流」「要件定義」「設計」のいずれかが入ります。表の文に当てはめると、それぞれ「上流工程」「要件定義工程」「設計工程」となります。

誤りやすいポイント

• テスト工程を選ばないようにします。テストで認識の違いを見つけることはできますが、要望1は、早期に検出して影響を小さくすることを求めています。
• 図表の活用だけに注目しないようにします。図表は認識誤りを防ぐための手段であり、目的は関係者間の認識を早い段階で合わせることです。
• bの後ろには「工程」が続きます。「上流」「要件定義」「設計」は、いずれも「工程」と組み合わせて意味が通ります。

FAQ

解答の導き方

誤りやすいポイント

• 「依頼事項を速やかに報告する」とだけ書くと、R主任の改善案と同じで、相談のタイミングを早める工夫が不足します。
• 「A社システム部やステークホルダに依頼する」とだけ書くと、相手の対応を求めるだけになり、早期の情報共有が伝わりません。
• 「問題が起きたら報告する」だけでは、依頼内容が固まる前から検討状況を共有するという改善の要点が抜けます。

FAQ

解答の導き方

誤りやすいポイント

• 問題の原因を個人に帰して、「問題を起こした人が対処する」という意味にしてしまうことです。本文では、問題を起こした個人に着目しない姿勢が明示されています。
• 「協力」など、チームで取り組む意味に近い語だけを考えることです。空欄の後ろに「で向き合う」と続く文の形にも合う必要があります。
• 問題が明確になってから報告することを重視することです。本文では、問題になる前の予兆も共有し、チームで早めに対応することが目指されています。

FAQ

解答の導き方

1. まず、ミーティングでのコミュニケーションにどのような課題があったかを確認します。R主任は「発言をするメンバとしないメンバに分かれている」と述べ、発言しないメンバともコミュニケーションを取る必要があると考えていました。つまり、ミーティングで発言する人の意見だけが共有され、発言しない人の考えがチーム内で伝わりにくい状態でした。
2. 次に、Q課長がミーティングの前に行ったことに注目します。各自に検討結果を事前提出させ、集まった意見を整理した資料を配布しています。したがって、下線③で全員に意見を述べさせた目的は、意見を新たに集めることだけではありません。すでに集めた意見を、ミーティングで全員が共有できるようにすることが重要です。
3. さらに、発言しないメンバの意見も全員に届くようにすることが、先に確認した課題への対応になります。そのため、全員に意見を述べさせた意図は、普段ミーティングで発言しないメンバの意見も含め、全員が互いの考えを認識できるようにすることだと分かります。

誤りやすいポイント

• 「全員に意見を述べさせた」ことを、単に発言の機会を増やすためとだけ捉えると、本文にある「発言をしないメンバ」の意見を共有する意図が抜けます。
• 事前に各自の意見を提出させているため、ミーティングで意見を述べさせる目的を「意見を集めること」とだけ考えるのは不十分です。集めた意見を全員で認識することまで含めて考えます。
• 全員の意見を聞くことと、全員の意見を一致させることは別です。ここで問われているのは、全員が互いの意見を認識するための意図です。

FAQ

解答の導き方

誤りやすいポイント

• 「情報共有を活発にすること」だけでは、共有によって何を改善するのかが示されず、解答として不十分です。
• 「チームワークを向上させること」だけでは抽象的です。問題の兆候を共有した後に、早期発見・早期対処につなげる点まで含めます。
• 明らかな問題が発生してから報告するのではなく、問題になる前の予兆も共有することが重要です。

FAQ