基本情報技術者 2015年 秋期 午後 問06
プロジェクトの見積りに関する次の説明を読んで、設問1~3に答えよ。
P社は、得意先であるQ社の業務システム開発を受託した。今回は、前回開発したシステムの機能拡張であり、前回と同じメンバによるプロジェクトチーム(以下、チームという)が開発を担当することになった。
〔プロジェクトの概要〕
(1) このチームの工程別の生産性基準値は、表1のとおりである。
(2) メンバの総数は5人である。
(3) 各メンバの1日の作業時間は8時間、1週間の作業日数は5日である。また、メンバの生産性は、全員等しいとする。
(4) 各工程の途中段階で開発規模の再見積りを行い、各工程の分担を見直すことにする。
設問1:
問題文を見る 設計工程及び設計工程での再見積り後の予測に関する次の記述中のに入れる正しい答えを、解答群の中から選べ。
設計工程に着手する前の時点(以下、当初という)に見積もった開発規模は、100kステップであった。当初の見積り規模及び表1に示す生産性基準値から算出した設計工程の所要工数は、a人時である。
設計工程では、当初の見積り規模を基に、メンバ全員が設計を均等に分担して、全員が同時に設計を開始した。第1週から第8週まで、全員が毎週40時間を消費した。設計が進んだ結果、各メンバが分担している開発規模が均等でないことが判明した。
現在は設計工程の第8週末の時点であり、現在の設計進捗率を基に開発規模の再見積りを行った。再見積り後の開発規模はbkステップであり、設計〜テスト工程の総工数はc人時となる。第9週以降もこのままの分担で設計を続けた場合、各メンバの設計終了までに要する予測時間は、表2のとおりである。


aに関する解答群
ア:1,000
イ:1,500
ウ:2,000
エ:2,500
bに関する解答群
ア:102
イ:104
ウ:106
エ:108
cに関する解答群
ア:4,080
イ:4,160
ウ:4,240
エ:4,360
模範解答
a:ウ、b:イ、c:イ
解説
解答の導き方
この問題では、工程ごとの生産性を使って、設計に必要な工数、再見積り後の開発規模、全工程の総工数を求めます。
「人時」は、1人が1時間作業した量を表す単位です。また、「kステップ」は、プログラムの規模を1,000ステップ単位で表したものです。
a:設計工程の所要工数
当初の開発規模はなので、必要な工数は開発規模を生産性で割って求めます。
したがって、aは人時で、解答群ではウです。
b:再見積り後の開発規模
第1週から第8週まで、5人全員が毎週40時間作業しています。1人当たりの作業時間は、次のとおりです。
設計の生産性はなので、各メンバが設計した開発規模に換算すると、1人当たり次の量になります。
表2では、メンバごとに進捗率が異なります。これは、各メンバが担当している開発規模が異なるためです。各メンバが設計したを、そのメンバの進捗率で割ると、担当している開発規模を見積もれます。
これらを合計すると、次のようになります。
表2の進捗率は概数なので、開発規模も概算になります。したがって、再見積り後の開発規模はで、bはイです。
表2の予測時間からも確認できます。第9週以降の設計時間の合計は、人時です。第8週末までに使った人時を加えると、設計工程の総工数は人時です。
これに設計の生産性を掛けると、となり、進捗率から求めた規模と一致します。
c:設計からテストまでの総工数
再見積り後の開発規模を使い、工程ごとに生産性で割って工数を求めます。
- 設計:人時
- プログラミング:人時
- テスト:人時
設計からテストまでの総工数は、各工程の工数を合計します。
したがって、cは人時で、解答群ではイです。
誤りやすいポイント
- 工数を求めるとき、生産性を開発規模に掛けないようにします。生産性は「1人時当たりに作業できる規模」なので、開発規模を生産性で割ります。
- aで求めるのは人時です。5人で作業した場合の暦上の時間を求めているのではないため、5人で割る必要はありません。
- 再見積りでは、当初のをそのまま使うのではなく、実際に設計した規模と進捗率から見積もり直します。
- 設計、プログラミング、テストでは生産性が異なります。各工程に対応する表1の値を使います。
FAQ
Q:進捗率が約77%なら、当初のに0.77を掛ければよいのですか。
A:それでは、設計が完了した規模を求める計算になります。この問題では、完了した規模を進捗率で割り、開発規模全体を見積もります。また、当初の見積りと実際の担当規模が異なっているため、各メンバの進捗率を使って再見積りします。
A:それでは、設計が完了した規模を求める計算になります。この問題では、完了した規模を進捗率で割り、開発規模全体を見積もります。また、当初の見積りと実際の担当規模が異なっているため、各メンバの進捗率を使って再見積りします。
Q:cの設計工数人時には、すでに使った工数も含まれていますか。
A:含まれています。表2の予測時間は第9週以降に必要な工数です。第8週末までに使った工数と合わせたものが、設計工程全体の工数です。
A:含まれています。表2の予測時間は第9週以降に必要な工数です。第8週末までに使った工数と合わせたものが、設計工程全体の工数です。
Q:設計工程の工数と、設計の予測時間の合計はなぜ一致するのですか。
A:予測時間の合計人時に、すでに使った人時を加えると人時になります。この値が、再見積り後の開発規模を設計の生産性で割って求めた工数と一致します。
A:予測時間の合計人時に、すでに使った人時を加えると人時になります。この値が、再見積り後の開発規模を設計の生産性で割って求めた工数と一致します。
関連キーワード: 生産性、工数、進捗率、開発規模の再見積り、工程別見積り
設問2:
問題文を見る 第8週末時点での進捗に関する次の記述中のに入れる適切な答えを、解答群の中から選べ。
表2から、dの設計工数が当初の計画値を超えている。このままの分担で継続すると納期に遅延が生じるので、第9週以降の作業分担について見直しを行うことにした。
dに関する解答群
ア:B及びDの2人
イ:B、D及びEの3人
ウ:C以外の4人
エ:Dのただ1人
模範解答
d:イ
解説
解答の導き方
この設問では、第8週末の時点で、各メンバの設計工数が当初の計画値を超えているかを調べます。設計工数は、作業にかかった時間を人時で表したものです。
まず、当初の計画で設計に必要な工数を求めます。開発規模は100kステップ、設計の生産性基準値は0.05 kステップ/人時です。生産性は「1人が1時間でどれだけ作業できるか」を表すので、開発規模を生産性で割ると必要な工数が求まります。
問題文には、メンバ全員が設計を均等に分担したとあります。メンバは5人なので、1人当たりの当初の計画値は次のとおりです。
次に、第8週末までに各メンバが作業した時間を求めます。全員が第1週から第8週まで毎週40時間作業したので、1人当たりの作業済み時間は次のとおりです。
表2の「9週」から「12週」までの予測時間をメンバごとに合計すると、設計終了までに必要な残りの時間が分かります。その残り時間に、すでに作業した320時間を足し、当初の計画値である400人時と比べます。
このように、当初の計画値400人時よりも見込み工数が大きいのは、B、D及びEです。したがって、該当するのは「B、D及びEの3人」です。
誤りやすいポイント
- 表2の予測時間だけを400人時と比べないようにします。表2の時間は第9週以降に必要な「残り時間」です。作業済みの320時間も加えて、設計終了までの見込み工数を求めます。
- チーム全体の工数だけで判断しないようにします。この設問では、各メンバの計画値400人時と、各メンバの見込み工数を個別に比較します。
- 進捗率だけで超過を判断しないようにします。表2には各メンバの残り時間が示されているため、作業済み時間を加えた見込み工数で比較します。
FAQ
Q: 表2の予測時間は、なぜ作業済み時間に加えるのですか?
A: 表2の時間は、第9週以降に設計を終えるまでに必要な時間です。設計全体の工数を見積もるには、それまでに使った時間と、これから必要な時間の両方を合計します。
A: 表2の時間は、第9週以降に設計を終えるまでに必要な時間です。設計全体の工数を見積もるには、それまでに使った時間と、これから必要な時間の両方を合計します。
Q: Aは表2の予測時間が80時間ですが、なぜ計画超過ではないのですか?
A: 80時間は残りの時間です。作業済みの320時間を加えると見込み工数は400時間となり、当初の計画値400人時と同じです。計画値を超えてはいません。
A: 80時間は残りの時間です。作業済みの320時間を加えると見込み工数は400時間となり、当初の計画値400人時と同じです。計画値を超えてはいません。
Q: チーム全体の工数だけを比べれば、誰が超過しているかも分かりますか?
A: チーム全体の合計だけでは、超過したメンバを特定できません。各メンバについて、作業済み時間と残り時間を合計し、それぞれの計画値と比べます。
A: チーム全体の合計だけでは、超過したメンバを特定できません。各メンバについて、作業済み時間と残り時間を合計し、それぞれの計画値と比べます。
関連キーワード: 工数、生産性、開発規模、進捗率、再見積り
設問3:
問題文を見る 各メンバの開発に掛かる工数が均等になるように、第9週以降の作業分担の見直し案として次の二つの案を考えた。残りの設計の途中で設計変更が発生するリスクの影響を考慮して、どちらの案を採用するかを検討したい。ここで、設計変更が発生しても開発規模は変わらないものとする。評価として誤っている答えを、解答群の中から選べ。
第1案は、残りの設計を表2に示した当初の分担のまま実行し、各メンバが設計を終了し次第、プログラミングに着手する。このとき、再見積り後の開発規模を基に全員のプログラミングの終了日がそろうようにプログラミングの分担を割り振る。かつ、テストの分担は全員が均等になるように割り振る。
第2案は、全員の設計の終了日がそろうように残りの設計の分担を割り振る。かつ、プログラミングとテストの分担もそれぞれ全員が均等になるように割り振り、全員のプログラミングの開始日及び終了日をそろえる。
解答群
ア:設計変更が発生しなかった場合、プログラミング工程の終了日は第1案の方が第2案よりも早くなる。
イ:設計変更が発生した場合、第1案では、設計工程のコスト増及びスケジュール遅延だけでなく、その影響で、既に着手していたプログラミングの手戻りなどが発生して、プログラミング工程のコスト増が発生する可能性がある。
ウ:設計変更が発生した場合、第2案では、設計工程のコスト増及びスケジュール遅延は発生するが、その影響で、プログラミング工程のコスト増は発生しない。
模範解答
ア
解説
解答の導き方
設問は、設計変更がない場合のプログラミング終了日と、設計変更が起きた場合の影響を比べ、誤っている評価を選ぶ問題です。
まず、メンバ1人が1週間に作業できる時間は、時間日で時間です。5人全員では、1週間に人時の作業ができます。人時とは、作業にかかる時間を人数分も合わせて表したものです。
残りの設計規模を kステップ、プログラミング規模を kステップとすると、5人全員で作業した場合に必要な期間は、次のように表せます。
- 設計に必要な期間:週
- プログラミングに必要な期間:週
選択肢アは誤りです。
第1案では、問題文に「残りの設計を表2に示した当初の分担のまま」とあるため、メンバによって設計の終了時期が異なる場合があります。設計が終わったメンバからプログラミングに移り、全員の終了日がそろうように分担します。
設計を先に終えたメンバは早くプログラミングを始められます。しかし、全員のプログラミング終了日をそろえるため、開始が遅いメンバはその分、プログラミングの担当量が少なくなります。全員分を合わせて考えると、プログラミングを始められる時期の平均は、設計に必要な総人時を5人で分担した場合の設計終了時期と同じです。
第2案では、「全員の設計の終了日がそろうように」設計を分担します。設計の総量は第1案と同じなので、全員で設計を分担したときの終了時期も、第1案で各メンバの設計終了時期を平均したものと同じです。その後のプログラミング規模も同じで、5人に均等に分担します。
したがって、設計変更がなければ、プログラミング終了日は第1案と第2案で同じになります。第1案の方が早くなるとするアは、誤った評価です。早くプログラミングを始めるメンバがいても、それだけで全体の終了日が早くなるわけではありません。
選択肢イは正しい評価です。
第1案では、メンバごとに設計が終わり次第、プログラミングを始めます。そのため、まだ設計が終わっていないメンバがいる間に、別のメンバがプログラミングを進めていることがあります。
その後に設計変更が起きると、すでに作ったプログラムを直す必要が生じる可能性があります。設計変更で開発規模が変わらなくても、作成済みのプログラムを修正する作業が増えれば、プログラミング工程のコストや期間が増えることがあります。
選択肢ウは正しい評価です。
第2案では、全員が設計を終えてから、全員でプログラミングを始めます。そのため、設計変更が起きても、まだプログラミングには着手していません。設計のやり直しによって設計工程のコストや期間は増えますが、作成済みプログラムの手戻りは発生しません。また、開発規模は変わらない条件なので、プログラミング工程の作業量が増えるとはいえません。
誤りやすいポイント
-
早く着手できるメンバがいると、全体も早く終わると思い込むこと
全体の終了日は、早く始めた人だけでなく、すべての担当作業が終わる時点で決まります。第1案では、設計の開始時期の違いに応じてプログラミングの分担を変えるため、開始が早いことだけでは終了日の短縮につながりません。 -
開発規模が変わらなければ、コストも増えないと思うこと
規模が同じでも、作成済みのプログラムを直す作業が加われば、追加のコストが発生する可能性があります。 -
設計変更があれば、必ずプログラミングの手戻りがあると思うこと
第2案では、設計を終えてからプログラミングに着手します。変更がプログラミング開始前に済めば、作成済みプログラムの修正は発生しません。
FAQ
Q: 第1案は一部のメンバが先にプログラミングを始めるのに、なぜ終了日が早くならないのですか?
A: 先に始めたメンバの担当量と、後から始めるメンバの担当量を調整して、全員の終了日をそろえるためです。設計にかかる総人時とプログラミングにかかる総人時は、どちらの案でも同じなので、全体の終了日は同じになります。
A: 先に始めたメンバの担当量と、後から始めるメンバの担当量を調整して、全員の終了日をそろえるためです。設計にかかる総人時とプログラミングにかかる総人時は、どちらの案でも同じなので、全体の終了日は同じになります。
Q: 開発規模が変わらない設計変更でも、プログラミングのコストが増えることはありますか?
A: あります。規模が同じでも、すでに作成したプログラムを変更内容に合わせて直す作業が発生する場合があるためです。
A: あります。規模が同じでも、すでに作成したプログラムを変更内容に合わせて直す作業が発生する場合があるためです。
Q: 第2案で設計変更が起きた場合、スケジュールはどうなりますか?
A: 設計のやり直しでプログラミング開始が遅れるため、全体のスケジュールも遅れます。ただし、変更時点ではプログラミングに着手していないので、作成済みプログラムの手戻りはありません。
A: 設計のやり直しでプログラミング開始が遅れるため、全体のスケジュールも遅れます。ただし、変更時点ではプログラミングに着手していないので、作成済みプログラムの手戻りはありません。
関連キーワード: 生産性、工数、工程、手戻り、開発規模




