プロジェクトマネージャ 2013年 午後1 問04

解答の導き方

1. 問われているのは、Q課長が自分のプロジェクトマネジメント業務の一部を、詳細設計以降を担当する予定のU社の管理者に委託した目的です。委託したのは、進捗状況と品質状況を定量的に把握し、評価する部分です。
2. 本文では、U社との取引は今回が初めてだと説明されています。企画部の推薦で分かっているのはU社のデザイン力と技術力であり、U社がプロジェクトをどのように管理するのかは、Q課長にはまだ分かりません。進捗と品質を把握・評価する役割を担ってもらえば、管理者がその状況を適切にとらえ、判断できるかを確認できます。
3. また、Q課長は契約方針を立てた際、「請負契約部分に関しては、念のため事前に確認しておくべきことがあると考えた」とあります。詳細設計から結合テストまでを請負契約で任せる相手として、設計や実装の技術力とは別に、プロジェクトマネジメントの能力を確かめておく必要があると考えたと読み取れます。
4. 基本設計の段階で管理者に定量的な把握・評価を担わせるのは、詳細設計以降を任せる前に、U社のプロジェクトマネジメントの実力を確かめるためです。実際に後の段落でも、Q課長は請負契約に際し、U社の進捗管理・品質管理の方法を把握することがリスク管理上重要だと考えています。単にQ課長の作業負担を減らすことが目的ではありません。

誤りやすいポイント

• 「Q課長の業務負担を軽減するため」と考えることです。本文では、U社の管理能力を把握することがリスク管理上重要だと述べられています。
• 「進捗や品質を改善するため」とだけ答えることです。進捗・品質の把握と評価は委託する業務であり、その目的として問われているのはU社の管理能力を確認することです。
• 「U社の技術力を確認するため」とすることです。技術力は企画部の推薦の時点で評価されています。ここで確認する対象は、進捗状況や品質状況を管理する能力です。
• 基本設計を通じて後から分かった「管理者の関心が実装技術面に偏る」という事実を、委託の目的の根拠にしないことです。委託を決めた時点で分かっているのは、U社が初めての取引先であり、管理者が詳細設計以降を担当する予定だということです。

FAQ

解答の導き方

1. この設問では、ユーザの使用頻度や累積使用時間を基に選ぶ「特定の画面」が、どのような画面なのかを答えます。
2. 本文では、特定の画面を「従来のモバイルアプリのユーザの使用頻度や累積使用時間に関するパレート分析の結果に基づいて決定する」とあります。したがって、画面の利用状況を示す二つの指標、使用頻度と累積使用時間のそれぞれから、優先して設計する画面の特徴を考えます。
3. 使用頻度は、ユーザがその画面をどれだけ多く利用するかを表します。パレート分析で着目されるのは、利用への寄与が大きい画面なので、使用頻度については高い画面が該当します。
4. 累積使用時間は、その画面でユーザが過ごす時間を積み上げたものです。この指標についても、ユーザの利用への寄与が大きい画面を選ぶため、累積使用時間が長い画面が該当します。

誤りやすいポイント

• 使用頻度だけ、または累積使用時間だけを答え、もう一方を抜かさないようにします。本文では二つの指標が示されています。
• 累積使用時間を、1回の利用にかかる時間だけと捉えないようにします。ここでは、利用時間を積み上げた量に着目します。
• 「使いやすさが重要な画面」のように設計上の評価だけを答えるのではなく、問われている使用頻度と累積使用時間の特性を示します。

FAQ

解答の導き方

1. まず、設計やレビューを重点的に行う対象を確認します。本文では、顧客満足度の鍵は特定の画面の「使い勝手の良さ、ワクワク感」だとしています。また、その画面は、ユーザの使用頻度や累積使用時間に関するパレート分析で選ぶとあります。つまり、利用への影響が大きい画面を重点対象にする方針です。
2. 次に、設問が尋ねている二つの工夫を分けて考えます。一つ目は「作業の順序」です。重点対象の画面を後回しにせず、ほかの画面より先に設計・レビューするのが適切です。したがって、作業の順序は重点対象を先行させます。
3. 二つ目は「作業の密度の計画値」です。重点対象では使い勝手や魅力を特に高める必要があるため、設計やレビューを通常より集中的に行う計画にします。つまり、作業の密度の計画値は高くします。これは基本設計の期間を延ばすという意味ではなく、限られた期間の中で重点対象に手厚く取り組むということです。

誤りやすいポイント

• パレート分析の結果を、画面の作業順序や密度の工夫と結び付けず、画面の選び方だけを答えてしまうことです。
• 重要な画面を先に扱うことと、その画面の作業密度を高くすることは別の工夫です。両方を答える必要があります。
• 作業密度を高くすることを、基本設計の期間を長くすることと混同しないようにします。問われているのは、計画期間内で重点対象に作業を集中させる工夫です。

FAQ

解答の導き方

1. まず、基本設計の進め方を定めた背景を確認します。Q課長は、企画部と「開発規模・開発期間の制約条件」に関する意識を合わせています。したがって、基本設計を進める際には、仕様だけでなく、開発規模や期間が当初の前提から外れないかも確認する必要があります。
2. 下線⑤では、基本設計の進捗状況を見ながらQ課長とU社が活動し、その結果を企画部と共有するとしています。さらに、詳細設計以降の前提条件との間に大きな差異が生じるおそれがあれば、企画部に協力を要請します。
3. ここで確認すべきなのは、基本設計の作業が予定どおり進んでいるかだけではありません。基本設計の内容を踏まえて、詳細設計以降に必要となる開発規模や期間が、当初の前提と食い違わないかを確認することです。そのため、活動は「開発規模と開発期間の確認」と表せます。

誤りやすいポイント

• 「進捗状況を見ながら」とあるため、単なる進捗確認だと考えないようにします。活動の結果を詳細設計以降の前提条件と照らし合わせることがポイントです。
• 企画部に協力を要請するのは、差異が大きくなるおそれがある場合です。企画部との仕様調整そのものを、Q課長とU社が行う活動として答えるのではありません。
• 「開発期間」だけに絞ると、当初の制約条件に含まれている「開発規模」を見落とします。

FAQ

解答の導き方

誤りやすいポイント

• 「保守性」とする：保守性は表1に別の条件として既に示されています。難読化や脆弱性診断の目的とは異なります。
• 「品質」とする：品質管理は表1の別の行で扱われています。空欄に対応する提案の具体的な対策に注目すると、情報セキュリティに関する条件だと判断できます。
• 難読化だけに注目する：難読化と脆弱性診断の両方が、空欄に入る条件を判断する根拠になります。

FAQ

解答の導き方

1. Q課長が見直しを求めた理由は、詳細設計と製造について「作成した成果物の量が報告されているだけ」であり、品質を確保するための活動の進捗が分からないことです。つまり、ドキュメントやコードをどれだけ作成したかだけでは、品質を確保する活動がどこまで進んだかを評価できません。
2. 品質を確保する活動の一つとして、成果物のレビューがあります。レビューが進んでいるかを把握するには、作成された成果物のうち、どれだけレビューを終えたかを報告してもらう必要があります。
3. したがって、求められているのは、作成量ではなく「レビュー済の成果物の量」です。

誤りやすいポイント

• 作成したドキュメント量やコード量を答えると、すでに提案されている内容を繰り返すだけになります。問われているのは、品質を確保する活動の進捗です。
• レビュー時間や欠陥数など、品質に関係する別の数値を答えないようにします。この設問では、レビューが済んだ成果物の量を報告することがポイントです。
• レビューの実施を報告するだけでなく、どの程度進んだかを把握できるよう、成果物の量として示す点が重要です。

FAQ

解答の導き方

誤りやすいポイント

• 評価対象工程の数値を、より細かく分析することだけを答えにしないようにします。設問の要点は、分析の視野を評価対象工程の外へ広げることです。
• 欠陥数やレビュー時間などの数値を増やして報告するだけでは、欠陥が混入した原因の特定にはつながりません。
• 「品質を改善する」「再発防止を行う」といった結果だけでは、どのような分析を改善するのかが明確になりません。原因を前工程までたどる点を示します。

FAQ

解答の導き方

1. 問われているのは、保守性を確保するため、コードレビューに加えてどの活動を追加するかです。本文では、コードレビューだけでは「問題検知のタイミングが遅くなるおそれがある」としています。
2. コードレビューは、ソースコードが作成された後に行うレビューです。そのため、保守性に関わる設計上の問題をコードレビューで初めて見つけると、設計にさかのぼって修正が必要になる場合があります。
3. そこで、コードが作成される前の詳細設計段階で、設計内容を保守性の観点から確認する活動を加えます。したがって、追加するのは詳細設計での保守性に関するレビューです。

誤りやすいポイント

• コードレビューをより詳しく行うことだけを答えると、問題検知を早める活動の追加になりません。
• 静的解析ツールの活用は、本文で別途検討を求められている内容です。下線⑧で問われているのは、レビューのタイミングを早めるための活動です。
• 単に「設計レビュー」とするのではなく、詳細設計で保守性を確認する点まで含めて答える必要があります。

FAQ

• Q: なぜ詳細設計の段階でレビューするのですか？
  A: 実装後のコードレビューより早く設計上の問題を発見でき、後工程での手戻りを抑えやすくなるためです。
• Q: コードレビューをなくして、詳細設計のレビューに置き換えるのですか？
  A: いいえ。コードレビューだけでは遅くなるおそれがあるため、詳細設計段階のレビューを追加します。