プロジェクトマネージャ 2011年 午後1 問01

解答の導き方

1. 図1の中央の合流ノードがどの作業かを確認します。表1では、Gの先行作業が「C、F」となっています。つまり、CとFの両方が終わってから始める作業がGなので、中央のノードの作業IDである①はGです。
2. Gの最早開始を求めます。Cは図1から月6に終了します。一方、表1の作業期間と先行関係から、Dは月1～2、Eは月3～4、Fは月5～7となります。GはCとFの両方の完了を待つため、遅い方のFが終了した次の月、つまり月8に開始します。したがって、最早開始を表す③は8です。
3. 表1ではGの所要期間が1か月です。月8に開始して1か月で終わるので、最早終了を表す④は8、所要期間を表す②は1です。
4. 次に最遅時期を確認します。Gの後には、所要期間がそれぞれ1か月のH、Iが続きます。Gを月8に実施すれば、Hは月9、Iは月10となり、全体は月10に完了します。後ろからたどってもGを遅らせる余地はないため、最遅開始を表す⑤は8、最遅終了を表す⑥も8です。
5. トータルフロートは、最遅開始と最早開始の差です。Gはいずれも月8なので、⑦は0です。また、Gの最早終了は月8で、後続のHは月9に開始します。両作業の間に空き期間はないため、フリーフロートを表す⑧も0です。

誤りやすいポイント

• GはCだけでなくFの完了も待ちます。先行作業のうち早く終わる方ではなく、遅く終わるFを基準に開始時期を判断します。
• 所要期間が1か月の場合、開始と終了は同じ月です。月8に始まるGの終了も月8です。
• トータルフロートとフリーフロートは、どちらもこの作業では0ですが、計算の見方は異なります。トータルフロートは最早・最遅の差、フリーフロートは後続作業の開始を遅らせずに使える余裕です。
• 作業IDと所要期間を取り違えないよう、図1のノード内の位置に合わせて値を入れます。

FAQ

解答の導き方

1. 本文には「まず、成果物を洗い出し、それらを作成するための作業項目を設定した」とあります。つまり、先に完成させるものを決め、それを作るために必要な作業を考える順序です。
2. 成果物を先に決めると、各成果物を作るのに必要な作業を対応付けて確認できます。そのため、成果物に必要な作業の洗い出し漏れを防ぎやすくなります。
3. また、成果物は作業の結果として確認できるものです。本文では、後に「各要素成果物の完成の判定基準を設定」して状況を確認するとしています。完成したかどうかを確かめられる成果物を基準にすれば、作業の進捗も把握しやすくなります。

誤りやすいポイント

• 「作業を効率よく進めるため」のように、本文から直接読み取れない一般論だけを書くと、成果物から作業を設定する理由が伝わりません。
• 成果物と作業項目を混同しないようにしましょう。成果物は作業の結果として作成するものであり、作業項目はその成果物を作るために行う作業です。
• 進捗把握に触れる場合は、「成果物を確認して進捗を把握する」という関係が分かるように書きます。

FAQ

解答の導き方

1. 問われているのは、開発チームの作業を重点的に管理する必要がある理由です。そこで、表1の所要期間と先行作業を使って、作業工程図の経路ごとの期間を比べます。
2. まず、基盤チームが担当する経路は、A、B、Cの順に進みます。各作業の所要期間はそれぞれ2か月なので、Gに合流するまでに合計6か月かかります。
3. 開発チームが担当する経路は、D、E、Fの順に進みます。所要期間は2か月、2か月、3か月なので、Gに合流するまでに合計7か月かかります。GはCとFの両方が先行作業なので、先に完了した経路があっても、両方が完了するまでは開始できません。したがって、Gの開始を左右するのは、より長いD、E、Fの経路です。
4. Gの後には、H、Iが続きます。これらはD、E、Fと同じく、開発チームが担当する作業を含みます。そのため、開発チームが関わるD、E、F、G、H、Iは、いずれもプロジェクトの完了時期を決める最長の経路上にあります。

誤りやすいポイント

• 作業項目の数だけで、どのチームの管理を優先するか判断しないようにします。重要なのは、作業がクリティカルパス上にあるかどうかです。
• GはCとFの両方を先行作業とするため、A、B、Cの経路だけを見てGの開始時期を判断するのは誤りです。
• 開発チームが関わる作業のうち、D、E、Fだけでなく、後続のG、H、Iも経路に含めて考えます。

FAQ

解答の導き方

1. まず、外部設計と内部設計を担当する要員が、どのようなスキルをもっているかを確認します。K氏は品質確保・生産性向上のために「新バージョンでの開発スキルをもった要員の確保が必要」と考えていました。
2. しかし、T社からは、開発要員をプロジェクト開始時から専任で参加させることは確約できず、「プログラム製造からであれば」参加させられるとの回答がありました。そのため、外部設計と内部設計はS社の要員が担当することになっています。
3. S社の要員は旧バージョンに詳しく、新バージョンの機能調査も行っていますが、それだけでは新バージョンでの開発スキルをもった要員が設計を担当できるとは限りません。したがって、体制面のリスク要因は、新バージョンの開発スキルをもった要員が確保されていないことです。
4. 次に、進捗状況を管理する際に注意する観点を考えます。本文には、S社の要員だけで設計を行うことについて「品質確保の観点で不安」があるとあります。このため、作業が予定どおり進んでいるかだけでなく、設計成果物の品質も確保されているかを確認する必要があります。つまり、品質が確保された上で進捗しているかが、注意すべき観点です。

誤りやすいポイント

• 旧バージョンに詳しいことと、新バージョンでの開発スキルがあることを同じと考えないようにします。本文では、旧バージョンに詳しい要員が新バージョンの機能調査を行った上で設計を担当するとしていますが、新バージョンの開発スキルをもった要員が確保されたとは書かれていません。
• 外部設計と内部設計の期間を長めに設定したことは、調査や問合せにかかる時間を見込んだ対応です。スケジュールに余裕を設けても、設計を担当する要員のスキルに関するリスクがなくなるわけではありません。
• 進捗だけを確認する答えにしないようにします。本文で示されている懸念は品質にも関わるため、進捗と品質の両方を確認する必要があります。

FAQ

解答の導き方

1. 問われているのは、社内レビューに加えて開発チームに実施させるアクティビティです。したがって、単に進捗状況を報告させることではなく、設計の内容を確認する活動を考えます。
2. 外部設計と内部設計については、T社の要員を開始段階から専任で参加させられず、「S社の要員にスキルを習得させて対応」することになっています。また、K氏は「品質確保の観点で不安」を感じています。このため、S社の要員だけによる社内レビューでは、新バージョンに関する誤りや不備を十分に見つけられないおそれがあります。
3. 一方で、T社には「外部設計と内部設計での必要に応じた支援」を依頼しています。新バージョンの技術に詳しいT社の要員に設計成果物を確認してもらえば、社内レビューだけでは見落とす可能性のある問題を発見し、設計の品質を確かめられます。
4. したがって、指示するアクティビティは、T社の要員による設計レビューです。

誤りやすいポイント

• 「進捗確認」や「状況報告」と答えることです。設問は、定例ミーティングでの状況確認とは別に、社内レビューに加えて実施する活動を尋ねています。
• 「T社に技術情報の提供を依頼する」と答えることです。技術情報の提供は依頼済みの支援内容ですが、問われているのはレビューに加えて行うアクティビティです。
• 「社内レビューを強化する」とだけ答えることです。設計スキルの不足による品質面の不安を補うため、T社の要員が関与する点が重要です。

FAQ

解答の導き方

1. まず、当初の要員計画で外部設計と内部設計を誰が担当することになっていたかを確認します。T社からは「プログラム製造からであれば、開発のできる要員を専任で参加させることは約束できる。」との回答がありました。そのため、外部設計と内部設計は、旧バージョンに詳しく新バージョンの機能調査を行ったS社の要員が担当する計画でした。
2. ただし、S社の要員だけで設計を進める場合は、資料の確認や機能調査、問合せに時間が掛かると見込まれていました。そのため、当初から外部設計と内部設計の期間は長めに設定されています。
3. 今回は、新EDMSの完成を前倒しするため、外部設計からプログラム製造までの期間を短縮しようとしています。設計期間を短縮するには、従来どおりS社の要員だけで進めるのではなく、新バージョンでの開発スキルをもつ要員を設計段階から投入できるようにする必要があります。
4. しかし、T社が当初約束していた専任要員の参加はプログラム製造からです。したがって、外部設計と内部設計の期間短縮策を実現するために、T社と改めて交渉する内容は、T社要員を専任で参加させることです。

誤りやすいポイント

• 「新バージョンの技術情報の提供」や「外部設計と内部設計での必要に応じた支援」は、当初からT社に依頼している内容です。今回、改めて交渉するのは、設計段階から専任要員に参加してもらうことです。
• 「プログラム製造から要員を専任で参加させること」は、T社がすでに約束している範囲です。設計期間を短縮するには、それより前の段階にも専任要員を参加させる必要があります。
• 「追加要員を投入すること」だけでは、誰に何を依頼するのかが分かりません。設問は、特に外部設計と内部設計についてT社と交渉する内容を問うています。

FAQ

解答の導き方

誤りやすいポイント

• 開発チームの工程だけを見て、2か月短縮できればプロジェクト全体も2か月短縮できると考えることです。作業が並行していても、合流点の後の作業に進むには、両方の工程が完了している必要があります。
• 基盤チームの作業はシステムテストの前に終わればよい、と考えて工程の長さを確認しないことです。図1では、基盤チームの工程にも全体の完了時期に影響するだけの制約があります。
• 作業項目単体の所要期間だけを比べ、開始から後続作業まで含めた経路全体の期間を考えないことです。

FAQ

解答の導き方

1. まず、システムテストGの開始には、先行作業であるCとFの両方が完了している必要があります。そのため、図1では、次の二つの経路のうち、完了に時間が掛かる方がGの開始を決めます。
   • A→B→C：表1の所要期間はそれぞれ2か月なので、合計6か月です。
   • D→E→F：所要期間はそれぞれ2か月、2か月、3か月なので、合計7か月です。
2. 当初はD→E→Fの経路の方が長いため、開発チームの作業期間を短縮する対策だけでは、途中からA→B→Cの経路がGの開始を制約します。例えば、開発側の経路を2か月短縮すると、開発側は5か月になりますが、A→B→Cは6か月のままです。したがって、開発側だけを短縮しても、全体のスケジュールを2か月短縮することはできません。
3. そこで、もう一方のA→B→Cの経路も短縮する必要があります。表1を見ると、Aの「基盤設計」とCの「基盤構築・テスト」は、いずれも基盤チームが担当しています。一方、Bの「製品調達」はメーカも担当に含まれます。S社の要員を追加投入して短縮する対象としては、S社側の要員で対応しやすいAとCが選ばれます。

誤りやすいポイント

• 開発チームの作業だけに注目し、D→E→Fを短縮すれば全体も同じだけ短縮できると考えることです。GはCとFの両方を待つため、もう一方の経路も確認する必要があります。
• 作業期間が長い経路を短縮することだけを考え、短縮後にどの経路が全体を制約するかを見落とすことです。
• Bも基盤チームが担当することだけを見て、メーカも担当に含まれる「製品調達」である点を見落とすことです。S社の要員追加で短縮しやすい作業かどうかを、担当と作業内容から判断します。

FAQ