基本情報技術者 2009年 春期 午後 問06
スケジュール管理に関する次の記述を読んで、設問1〜3に答えよ。
A社は、2年前に基幹業務システムをB社に委託して再構築し、業務効率の向上に成功した。経営改革を更に進めるため、蓄積された経営データを活用した経営管理システムを開発することになり、情報システム部内で第Ⅰ期プロジェクトを立ち上げた。
〔第Ⅰ期プロジェクトの概要〕
経営管理システムは、経営データ分析サブシステムM1と経営幹部向けナビゲーションサブシステムM2とで構成される。M1はデータ集計用プログラムと分析プログラムから成る。M2は、M1による分析結果を経営幹部向けに編集し、イントラネットを通してブラウザで閲覧できるようにする。これらのサブシステムの要件定義は、A社の情報システム部が行い、設計からテストまでの開発作業は、経営管理システムの開発経験も豊富であるB社に委託した。B社は、A社からシステムの概略機能について説明を受けた後に概算見積りを行い、開発期間を3か月として請負契約を結んだ。
なお、開発はすべてB社内で行うことにした。
〔システム開発の遂行状況〕
情報システム部による要件定義は予定どおりの日程で完了し、要件定義書がB社に渡された。B社は、自社内での開発作業を開始し、開発期間中は両社合同のプロジェクト進捗会議を毎週1回行った。
開発開始から2か月が経過した時点の進捗会議で、B社から“M1の開発作業に遅れが出ているが、開発メンバを増やして納期に間に合わせる”という報告があった。しかし、2週間後にB社から“開発作業の遅れを取り戻せないので、納期をとりあえず2週間延ばしてほしい”との申出があり、A社は仕方なく了承した。その後もスケジュールの遅れは続き、当初の予定から1か月遅れて開発が完了した。B社からは、“M1が予想以上に複雑であり、更にM2の操作性を自社判断で一層高めたことによって、開発規模が当初見積りの1.5倍になってしまったことが遅延理由である”との報告があった。
A社側での受入検査の結果は、品質を含めて良好で、特に、M2は要件定義時の仕様よりも使い勝手がとても良く、経営幹部の評価も高かった。
設問1：
問題文を見る B社は、今回のシステム開発での遅延理由を二つ挙げている。契約時の見積値とは違ってしまった原因の説明として、表1中のに入れる最も適切な答えを、解答群の中から選べ。
解答群
ア：開発担当者の技術力が計画時の予測よりも低かったので、実際の開発期間が契約時の見積値を超えてしまった。
イ：設計作業の途中に、A社との調整を行わないで勝手に機能を広げてしまったので、開発規模が増大し、実際の開発期間が契約時の見積値を超えてしまった。
ウ：要件定義書を受け取った時点で契約時の概算見積りを見直さなかったので、契約時の概算見積りによる計画のまま開発が進められて、実際の開発期間が契約時の見積値を超えてしまった。
エ：要件定義をすべてA社側で行った上に、開発作業をすべてB社内で行ったので、A社の業務の理解に計画よりも多くの時間を要した。また、仕様の解釈に誤解が生じて設計作業の手戻りも発生し、実際の開発期間が契約時の見積値を超えてしまった。
模範解答
a：ウ、b：イ
解説
解答の導き方
この設問では、B社が挙げた二つの遅延理由について、契約時の見積りと実際の開発期間がずれた原因をそれぞれ考えます。
-
M1が予想以上に複雑だった理由B社は、A社からシステムの概略機能について説明を受けた後、「開発期間を3か月」として契約しています。その後、A社が要件定義を完了し、要件定義書をB社に渡しています。概略の説明だけでは、細かな機能や作業量までは分からないことがあります。そのため、要件定義書を受け取った段階で内容を確認し、最初の概算見積りを見直す必要があります。見直さないまま当初の計画で開発を進めると、M1の複雑さを反映できず、実際の期間が見積りを超える可能性があります。したがって、aには「要件定義書を受け取った時点で契約時の概算見積りを見直さなかった」というウが入ります。
-
M2の操作性を高めた理由B社は、M2の操作性を「自社判断で一層高めた」と報告しています。これは、A社と調整せず、決められた仕様よりも機能や作業の範囲を広げたということです。使いやすくすること自体は良いことですが、追加の作業が発生すれば開発規模も大きくなります。仕様を変更するときは、発注側のA社と調整する必要があります。よって、bには「A社との調整を行わないで勝手に機能を広げた」というイが入ります。このように、aは要件定義書を受け取った後の見積りの見直し不足、bは発注側と調整しない仕様の拡大が原因です。
誤りやすいポイント
- M1が複雑だったことだけに注目して、開発担当者の技術力不足と考えないようにしましょう。本文には、技術力が計画時の予測より低かったとは書かれていません。
- M1については、要件定義書を受け取った後に見積りを見直すべきだった点が重要です。最初の見積りが概略機能を基にしていることを読み落とさないようにしましょう。
- M2は、結果として経営幹部の評価が高くても、A社と調整せず仕様を広げたことはスケジュール管理上の問題です。成果の良さと、進め方が適切だったかどうかは分けて考えます。
- A社が要件定義を行い、B社が開発したという分担だけから、業務理解の遅れや仕様の誤解があったとは判断できません。本文に書かれた遅延理由に沿って選びましょう。
FAQ
Q: 最初の概算見積りを、要件定義書を受け取った後に見直すのはなぜですか？
A: 最初はシステムの概略機能しか分からず、細かな作業量を正確に見積もれないことがあるためです。要件定義書で具体的な内容が分かった段階で、期間や作業量を改めて確認します。
A: 最初はシステムの概略機能しか分からず、細かな作業量を正確に見積もれないことがあるためです。要件定義書で具体的な内容が分かった段階で、期間や作業量を改めて確認します。
Q: M2の使い勝手が良くなったのに、なぜ遅延の原因になるのですか？
A: 操作性を高めるための追加作業が必要になり、開発規模が大きくなるからです。良い改善でも、発注側と調整せずに進めると、見積りやスケジュールとのずれにつながります。
A: 操作性を高めるための追加作業が必要になり、開発規模が大きくなるからです。良い改善でも、発注側と調整せずに進めると、見積りやスケジュールとのずれにつながります。
Q: aとbは、どちらも開発規模が増えたという意味ですか？
A: bは、B社が機能を広げたことで作業が増えた原因です。一方、aは、要件定義書を受け取った後に見積りを見直さず、M1の複雑さを計画に反映できなかった原因です。
A: bは、B社が機能を広げたことで作業が増えた原因です。一方、aは、要件定義書を受け取った後に見積りを見直さず、M1の複雑さを計画に反映できなかった原因です。
関連キーワード: 要件定義、概算見積り、開発規模、スケジュール管理、仕様変更
設問2：
問題文を見る 両社合同によるプロジェクト進捗会議を毎週実施したにもかかわらず、今回のような開発の遅れが生じたことを互いに反省し、進捗会議でのリスク管理について対策会議を行った。この結果、次のような改善策の実施を決めた。に入れる最も適切な答えを、解答群の中から選べ。
これまでの進捗会議では、主にサブシステム単位での作業状況を、B社から報告していた。開発上で何らかの問題が発生した場合又はそのおそれがある場合には、問題点の内容、プロジェクトへの影響度及び対策案について両社で相談してきた。
今後は、より定量的なデータによって開発状況の実態を把握し、プロジェクトに悪影響を与えることがないよう未然に防止する。もし発生した場合でも、その影響を最小限に抑えられるようにする。
定量的なデータとしては、各開発工程での作業成果物の生産データ（プログラム規模など）、品質データ（レビュー結果、テスト結果など）及び進捗データ（プログラムの完成度、プロジェクト進捗度、計画と実績の差異分析）を使用する。これらのデータを分析することによって、例えば、今回の開発でのcといった現象を回避する。
また、開発途中での仕様、スケジュール、開発体制に関する変更管理（変更提案、変更に対する審議・承認など）を進捗会議の場で行う。これによって、例えば、今回の開発でのdといった現象を回避する。
解答群
ア：開発メンバを増強する
イ：概算見積りを行った時点よりも要求機能が複雑であったM1の納期遅延
ウ：操作性を一層高めたことによるM2の納期遅延
エ：納期を2週間延ばした後の更なる遅れの発生
模範解答
c：エ、d：ウ
解説
解答の導き方
この設問では、改善策が防ごうとしている現象を、次の二つに分けて考えます。
- 作業の実績を数字で確かめ、遅れなどの兆候を早めにつかむこと
- 仕様やスケジュールなどの変更を、決められた手順で扱うこと
まず、cに入るのは、定量的なデータを分析する改善策で防ぐ現象です。
本文には、これまでの会議では主にサブシステム単位で作業状況を報告していた一方、今後は「プログラムの完成度」や「計画と実績の差異分析」などを使うとあります。つまり、作業がどれだけ進んだか、予定と実績にどれほど差があるかを数字で把握し、問題が大きくなる前に対策するということです。
今回、B社は開発開始から2か月後に遅れを報告し、その2週間後には納期を延ばしてほしいと申し出ました。ところが、納期を延ばした後も遅れが続き、最終的には当初の予定から1か月遅れて開発が完了しました。計画と実績の差を継続して確認できていれば、納期を延ばしただけで遅れを取り戻せるのか、その後も遅れが広がりそうなのかを早めに判断し、追加の対策を検討できます。
したがって、cには、納期を2週間延ばした後もさらに遅れが発生する現象を表す「エ」が入ります。
次に、dに入るのは、仕様やスケジュールなどの変更を管理する改善策で防ぐ現象です。
変更管理とは、変更の提案を受け、影響を検討して、承認するかどうかを決めることです。本文では、B社が「M2の操作性を自社判断で一層高めた」ため、開発規模が当初見積りの1.5倍になったと報告しています。仕様を独自に追加・変更すれば、必要な作業が増え、納期にも影響します。
変更管理を進捗会議で行えば、操作性を高める変更について、実施するか、スケジュールをどうするかなどを両社で確認できます。そのため、変更によってM2の開発が遅れる現象を防ぐ対象として、dには「ウ」が入ります。
誤りやすいポイント
- cとdを逆にしないようにします。cは、進捗データなどの分析で遅れの兆候をつかむ話です。dは、仕様などの変更を審議・承認する話です。
- 「開発メンバを増強する」は改善策としてB社が実施した対応ですが、解答群の中で防ぐべき「現象」を表しているものではありません。
- M1の遅れとM2の遅れを混同しないようにします。M2については、操作性を高める変更が開発規模の増加につながったことが本文に示されています。変更管理と直接結び付くのは、このM2の変更です。
- 納期を2週間延ばすこと自体が、遅れを解消したわけではありません。延長後も遅れが続いたことが、進捗を数字で把握し、先を見通す必要がある理由です。
FAQ
Q: 進捗を数字で確認すると、なぜ遅れを防ぎやすくなるのですか？
A: 予定と実績の差が分かるためです。差が広がっているときに早く気付けば、作業の見直しや追加対策を検討できます。
A: 予定と実績の差が分かるためです。差が広がっているときに早く気付けば、作業の見直しや追加対策を検討できます。
Q: M2の操作性を高めること自体が、なぜ問題になるのですか？
A: 操作性を高めることが悪いのではありません。関係者の確認や承認を経ずに仕様を変えると、必要な作業や納期への影響を見落としやすくなります。
A: 操作性を高めることが悪いのではありません。関係者の確認や承認を経ずに仕様を変えると、必要な作業や納期への影響を見落としやすくなります。
Q: 変更管理では、変更をすべて禁止するのですか？
A: いいえ。変更の内容や影響を確認し、実施するかどうかを決めるための手順です。必要な変更を行う場合も、スケジュールなどへの影響を踏まえて判断できます。
A: いいえ。変更の内容や影響を確認し、実施するかどうかを決めるための手順です。必要な変更を行う場合も、スケジュールなどへの影響を踏まえて判断できます。
関連キーワード: 進捗管理、定量的管理、変更管理、リスク管理、差異分析
設問3：
問題文を見る 3点見積法によるスケジュール見積りに関する次の記述中のに入れる正しい答えを、解答群の中から選べ。
〔第Ⅱ期プロジェクトの概要〕
経営管理システムの完成から1年後、A社の経営幹部から新たな経営データ分析機能の要求があり、情報システム部に第Ⅱ期プロジェクトを立ち上げた。このプロジェクトでは、経営データ分析サブシステムM3の新規開発とナビゲーションサブシステムM2の改造を行う。システム開発はB社が再び請け負い、開発作業は前回の開発担当者2名で行う。B社では、前回の反省から、開発でのスケジュール見積精度の向上を図るために、3点見積法を使用したスケジュールリスク分析を行うことにした。
3点見積法とは、仕事の作業期間（ここでは日数）を、最頻値、悲観値（悲観的に最も長い期間を見積もる）、及び楽観値（楽観的に最も短い期間を見積もる）の3種の値を用いて推定する方法である。3点見積法による作業期間の平均、分散、標準偏差、開発全体の標準偏差の計算式は、次のように定義されている。
平均 = (悲観値 + 4 × 最頻値 + 楽観値) ÷ 6
分散 = ((悲観値 − 楽観値) ÷ 6)²
標準偏差 = √分散
開発全体の標準偏差 = √(分散の合計)
B社が行った3点見積法によるスケジュールリスク分析を表2に示す。
なお、プロジェクトの作業日数の確率分布は、正規分布（平均μ、分散σ²）に近似できると仮定する。作業日数がμ±1σの範囲に収まる確率は0.68であり、μ±2σの範囲に収まる確率は0.95である。
M2及びM3の開発作業全体の平均作業日数は、e日になる。また、確率0.95で作業が完了する日数を、スケジュールリスクを考慮して見積もったとき、その最長作業日数は、平均作業日数にf日を加えた値である。
eに関する解答群
ア：24
イ：25
ウ：27
エ：29
fに関する解答群
ア：2
イ：2.2
ウ：4
エ：4.4
模範解答
e：イ、f：エ
解説
解答の導き方
この問題では、M3の新規開発とM2の改造にかかる日数を合わせた平均日数と、作業が遅れる可能性を考慮した日数を求めます。
-
平均作業日数を合計します。
表2では、M3の新規開発の平均作業日数が12.7日、M2の改造の平均作業日数が12.3日です。開発全体の平均作業日数は、二つの作業の平均を足して求めます。したがって、eに入るのは25日です。解答群ではイに当たります。 -
開発全体の標準偏差を確認します。
標準偏差は、作業日数が平均からどの程度ばらつくかを表す値です。表2では、開発全体の標準偏差は2.2日です。 -
確率0.95に対応する日数を求めます。
問題文には、作業日数が平均から標準偏差2個分の範囲に収まる確率は0.95とあります。最長の日数を考えるため、平均に標準偏差の2個分を加えます。よって、平均作業日数に加える日数は4.4日です。fに入るのは解答群のエです。作業完了までの見積り日数は、平均の25日に4.4日を加えた値になります。
誤りやすいポイント
- M3とM2の平均作業日数を足さず、どちらか一方の値だけを使わないようにします。
- 3点見積法の平均を求める式と、複数作業の平均を合計する計算は別です。この問題では、表2に示された各作業の平均作業日数を合計します。
- 確率0.95に対応する追加日数は、標準偏差1個分ではなく、問題文で示された標準偏差2個分です。
- 分散と標準偏差は異なります。確率に応じて平均に加えるのは、標準偏差を使って計算した日数です。
FAQ
Q: 分散の合計が5なのに、標準偏差が5ではないのはなぜですか？
A: 標準偏差は、分散の平方根です。分散の合計が5なので、標準偏差はとなり、表2では2.2日と示されています。
A: 標準偏差は、分散の平方根です。分散の合計が5なので、標準偏差はとなり、表2では2.2日と示されています。
Q: なぜ最長日数を求めるときは標準偏差を平均に加えるのですか？
A: 作業が平均より長くかかる側の日数を見積もるためです。この問題では、確率0.95に対応する範囲として平均に標準偏差2個分を加えます。
A: 作業が平均より長くかかる側の日数を見積もるためです。この問題では、確率0.95に対応する範囲として平均に標準偏差2個分を加えます。
Q: 3点見積法では何を見積もりますか？
A: 作業期間を、最も起こりそうな期間、長くかかる場合の期間、短く済む場合の期間の3つから推定します。
A: 作業期間を、最も起こりそうな期間、長くかかる場合の期間、短く済む場合の期間の3つから推定します。
関連キーワード: 3点見積法、平均、分散、標準偏差、正規分布
