【ITパスポート練習問題 6.3対応】(2) ソフトウェアの見積り

【解説】

正解: 2 ソフトウェアの機能に基づいて開発規模を評価する

この問題は、システム開発における見積もり手法の一つである「ファンクションポイント法（FP法）」の定義とその特徴を正しく理解しているかを確認するものです。

ファンクションポイント法は、入力画面、出力帳票、使用するファイル数など、ユーザーから見て認識できる「機能」の数や複雑さを基準にして、システムの規模（点数）を算出する手法です。プログラミング言語や開発者のスキルに依存せず、客観的な見積もりがしやすいという特徴があります。

選択肢1の「ソースコードの行数に基づいて見積もる」は、プログラムステップ法（LOC法）の説明です。FP法は行数（ステップ数）を用いません。選択肢3の「プロジェクトの進捗状況を監視する手法」は、EVM（アーンドバリューマネジメント）などの説明であり、見積もり手法であるFP法とは異なります。

【解説】

正解: 3 ソフトウェア開発者の技術力

この問題は、ファンクションポイント法が見積もりの根拠として「何を含み、何を含まないか」という計算対象の範囲を理解しているかを確認するものです。

ファンクションポイント法は、あくまで「作ろうとしているシステムの機能的な規模」を測るものです。入力画面や帳票（外部出力）、データベース（内部論理ファイル）などの個数はシステムの要件によって決まりますが、「誰が開発するか（技術力）」は機能の規模そのものには影響しません。したがって、開発者の技術力はFP法の評価要素には含まれません。

選択肢1の「外部入力」や選択肢2の「内部論理ファイル」は、ファンクションポイントを算出する際にカウントする主要な5つの要素（外部入力、外部出力、外部照会、内部論理ファイル、外部インタフェースファイル）に含まれており、評価対象となります。

【解説】

正解: 2 プログラムの実行速度を正確に予測できる

この問題は、ファンクションポイント法を用いることのメリットと、この手法では解決できない限界（対象外の事柄）を区別できているかを問うものです。

ファンクションポイント法はシステムの「開発規模」や「工数」を見積もるための手法であり、完成したプログラムがどれくらいのスピードで動作するかという「実行速度（性能）」を予測するものではありません。したがって、2がファンクションポイント法の利点として不適切です。

選択肢1の「異なる技術や言語のプロジェクトにも適用可能」な点は、ソースコード行数に依存しないFP法の大きな利点です。選択肢3の「ユーザー視点での評価が可能」についても、ユーザーにとって分かりやすい「機能（画面数など）」を単位とするため、見積もりの根拠を合意しやすいという利点があります。

【解説】

正解: 1 過去の類似プロジェクトを基に工数を見積もる

この問題は、見積もり手法の一つである「類推見積法」の基本的なアプローチを理解しているかを確認するものです。

類推見積法は、これから開発しようとするシステムと似ている過去のプロジェクト（類似事例）を探し出し、その実績データを参考にして「前回はこれくらいの規模で3ヶ月かかったから、今回は機能が少し多いので4ヶ月くらいだろう」といったように推測して見積もる手法です。

選択肢2の「詳細なタスク分解を行い見積もる手法」は、WBS（Work Breakdown Structure）などを用いて作業を積み上げる「ボトムアップ見積もり（標準タスク法など）」の説明です。選択肢3の「プロジェクト完了後の工数の実績値を反映する」は、見積もり手法そのものではなく、予実管理や事後評価のプロセスに関する記述です。

【解説】

正解: 2 過去のデータが少ない場合でも高い精度が得られる

この問題は、類推見積法を適用するための前提条件と、その弱点を理解しているかを確認するものです。

類推見積法は、あくまで「過去の類似事例」と比較することで数値を導き出す手法です。そのため、比較対象となる過去のデータが存在しない場合や、データが極端に少ない場合には、推測の根拠が乏しくなり、精度の高い見積もりを行うことはできません。したがって、2が誤った記述となります。

選択肢1の「初期段階でも迅速に見積もりが可能」は、詳細な仕様が決まっていない要件定義などの早い段階で、概算を出すのに適しているという類推見積法の利点です。選択肢3の「過去のプロジェクトデータを再利用する」ことも、組織の資産を活用できるという点で利点といえます。

【解説】

正解: 3 過去のプロジェクトとの類似度

この問題は、類推見積法の精度を高めるために最も重要な判断基準が何であるかを理解しているかを確認するものです。

類推見積法では、「何と比較するか」が結果を左右します。開発するシステムの種類、業務分野、規模感、技術要素などが、参考にする過去のプロジェクトとどれくらい似ているか（類似度）を慎重に考慮する必要があります。類似度が高いほど、見積もりの信頼性は高まります。

選択肢1の「プロジェクトのメンバー数」や選択肢2の「顧客の予算額」もプロジェクトの制約条件としては重要ですが、類推見積法という手法の根幹となる「比較・推測のための基準」としては、類似度が最も優先すべき要素です。

【解説】

正解: 2 タスクの規模を比較して評価する

この問題は、アジャイル開発などでよく用いられる「相対見積」の概念を正しく理解しているかを確認するものです。

相対見積は、「この作業は3時間かかる」といった絶対的な時間で見積もるのではなく、「基準となる作業Aに比べて、作業Bは2倍くらいの大きさだ」というように、タスク同士のサイズを比較して見積もる手法です。人間は絶対的な数値を当てるよりも、比較による大小判断の方が得意であるという特性を利用しています。

選択肢1の「絶対的な時間を基準に見積もる」は、従来型の「絶対見積（理想時間見積もりなど）」の特徴です。選択肢3の「工数見積もりには向いていない」は誤りで、アジャイル開発における工数（規模）の見積もり手法として広く活用されています。

【解説】

正解: 1 Tシャツサイズ（S, M, L）

この問題は、相対見積を行う際に使われる具体的なツールや単位についての知識を問うものです。

相対見積では、詳細な数値を出すことを避けるため、タスクの大きさを直感的に分類できる尺度を用います。「Sサイズ、Mサイズ、Lサイズ」といったTシャツサイズや、フィボナッチ数列（1, 2, 3, 5, 8…）を用いた「ストーリーポイント」などが代表的です。

選択肢2の「具体的な作業時間（時間単位）」は、絶対見積で用いられる尺度です。選択肢3の「プログラムのコード行数」は、プログラムステップ法などで用いられる尺度であり、相対見積の単位としては一般的ではありません。

【解説】

正解: 3 複雑なプロジェクト全体の見積もり

この問題は、相対見積がどのようなスコープ（範囲）で有効に機能するか、その適用範囲の限界を理解しているかを確認するものです。

相対見積は、開発チームが把握できる範囲の具体的なタスクやユーザーストーリーを比較する際には高い効果を発揮します。しかし、未知の要素が多く含まれる「複雑なプロジェクト全体」の総工数を一度に見積もろうとすると、比較対象の基準が曖昧になりやすく、適切な精度が出せないため適していません。

選択肢1の「アジャイル開発におけるタスク見積もり」や、選択肢2の「ストーリーポイントを用いた進捗管理（ベロシティの計測など）」は、相対見積が最も頻繁に活用され、効果を発揮する典型的な場面です。