ITパスポート 2012年 春期 問49
問題文
新システムに求められる運用時間を24時間、365日と決定した。この決定を行う開発工程はどれか。
選択肢
ア：ソフトウェア受入れ
イ：テスト
ウ：プログラミング
エ：要件定義（正解）
🔒 解説は解答すると表示されます
新システムに求められる運用時間を24時間、365日と決定した。この決定を行う開発工程はどれか。【ITパスポート 解説】
正解の理由
運用時間（24時間、365日）はシステムに求められる「いつ利用できるか」という品質に関する条件です。こうした品質や制約をまとめて「非機能要件（ひきのうようけん、non-functional requirements：性能や信頼性など、何を“できる”かではなく、どのように“あるべきか”を表す要件）」と呼びます。
非機能要件を決める工程は、システムで何を実現するかを最初に把握する「要件定義（ようけんていぎ、requirements definition：作るべきシステムの要求を整理して決める工程）」です。したがって、運用時間の決定は要件定義で行います。正しい選択肢は エ です。
非機能要件を決める工程は、システムで何を実現するかを最初に把握する「要件定義（ようけんていぎ、requirements definition：作るべきシステムの要求を整理して決める工程）」です。したがって、運用時間の決定は要件定義で行います。正しい選択肢は エ です。
理由を短くまとめると：
- 運用時間はシステムの品質・運用条件に関わるため「非機能要件」に該当する。
- 非機能要件は開発工程の最初の段階である要件定義で決める必要がある。
- 後工程（設計・プログラミング・テスト・受入れ）で決めるのは遅すぎ、影響が大きい。
解法ステップ
- 設問のキーワードを確認：「運用時間」「24時間、365日」→「いつ使えるか」の情報。
- これが「機能（何をするか）」か「非機能（どのように動くか／運用条件）」かを判定する。→ 非機能要件。
- 非機能要件を決める工程がどれかを考える。→ 要件定義。
- 選択肢のうち要件定義に当たるものを選ぶ。→ エ を選択。
短いメモ：設計・作り・テストは要件に基づいて行う工程なので、要件が確定する前に運用条件を決めておく必要があります。
選択肢別の誤答解説
-
ア: ソフトウェア受入れ
ソフトウェア受入れは「完成したシステムが要件を満たしているかを発注者側が確認・承認する」工程です。運用時間のような要件を決める工程ではなく、決められた要件に対するチェックを行う段階です。 -
イ: テスト
テストは「設計・実装されたソフトウェアが正しく動作するかを確認する」工程です。テスト中に運用時間に関する動作確認（24/365での監視や耐久性テストなど）は行いますが、運用時間そのものを決定するのはテスト工程ではありません。決定は要件定義で行います。 -
ウ: プログラミング
プログラミングは実際にコードを書く作業です。プログラマは要件（例えば24/365の可用性要求）に基づいて実装しますが、運用時間の決定は実装段階より前の要件定義で行うべき事項です。 -
エ: 要件定義（正解）
要件定義はシステムに何を求めるかを決める段階であり、運用時間のような非機能要件をここで定めます。したがって運用時間の決定は要件定義で行います。
よくある誤解
-
「運用時間はテスト工程で決める」
誤解の理由：テストで稼働時間の確認をするため、そこで決めると考えがちです。実際はテストは検証段階で、決定・合意は要件定義で行います。 -
「運用に関することは運用担当が決めるのでは？」
実務では運用担当の意見を反映しますが、システム開発上は関係者（ユーザー、運用、開発、発注者）が要件定義の場で合意して決めます。要件定義は関係者間の合意形成の場でもあります。 -
「非機能要件は後回しでもよい」
非機能要件（可用性・性能・セキュリティなど）を後回しにすると、設計やコストに大きな影響が出ます。可用性を高めるには冗長化や監視仕組みが必要で、設計段階での検討が必須です。
補足コラム
運用時間（24時間、365日）を決めることは、SLA（Service Level Agreement：サービス品質や稼働保証に関する合意）や運用体制、コストに直結します。例えば「24時間稼働」を要求すると、
- サーバ（サービスを提供するコンピュータ）の冗長化が必要になる
- 障害時の監視と復旧体制（オンコールの人員）が必要になる
- メンテナンスの時間帯をどう確保するか（無停止での更新技術や夜間作業計画）が必要になる
これらはすべて設計や予算に影響するため、初期段階で関係者の合意を取り、要件として明文化しておくことが重要です。
事例：銀行システムは高可用性（ほぼ24/365）を要求されます。これを後で決めると、再設計や追加コストが発生してプロジェクトが遅れます。逆に社内の簡単な業務ツールなら平日9時〜17時で良い場合もあり、要件定義で区別します。
FAQ
Q1. 「機能要件」と「非機能要件」はどう見分ければよいですか？
A1. 機能要件は「システムが何をするか（例：顧客情報を登録する）」、非機能要件は「システムがどのように振る舞うか（例：1秒以内に応答する、24時間稼働する）」です。問いに「いつ」「どのくらい」「どの程度」といった条件が含まれる場合は非機能要件の可能性が高いです。
A1. 機能要件は「システムが何をするか（例：顧客情報を登録する）」、非機能要件は「システムがどのように振る舞うか（例：1秒以内に応答する、24時間稼働する）」です。問いに「いつ」「どのくらい」「どの程度」といった条件が含まれる場合は非機能要件の可能性が高いです。
Q2. 要件定義で決めた内容は後で変更できないですか？
A2. 変更は可能ですが、要件は設計・開発・テスト・予算に大きく影響します。変更には再設計や追加コストが伴うので、初期段階で十分に検討・合意しておくことが望ましいです。
A2. 変更は可能ですが、要件は設計・開発・テスト・予算に大きく影響します。変更には再設計や追加コストが伴うので、初期段階で十分に検討・合意しておくことが望ましいです。
Q3. 小さなシステムでも要件定義は必要ですか？
A3. 必要です。規模が小さくても「誰が何時に使うか」「どのくらいの可用性が必要か」を確認しておくと、作るべきものがブレず、無駄なコストを防げます。
A3. 必要です。規模が小さくても「誰が何時に使うか」「どのくらいの可用性が必要か」を確認しておくと、作るべきものがブレず、無駄なコストを防げます。
関連キーワード: 要件定義、非機能要件、可用性、SLA（Service Level Agreement）、運用時間、システム運用、開発工程、品質要件
\ せっかくなら /
ITパスポートを
クイズ形式で学習しませんか？
クイズ画面へ遷移する→
すぐに利用可能！