【ITパスポート練習問題 6.3対応】23.要件定義

【解説】

正解: 2 業務の目的や課題を明確化するため

この問題は、業務要件定義という工程がシステム開発全体の中でどのような役割を担っているのかを理解しているかを確認するものです。特に、「業務の何を明らかにする段階なのか」という目的を押さえられているかが問われています。

業務要件定義では、現状の業務の目的や課題を整理し、「どのような業務を、どのような状態にしたいのか」を明確にします。業務上の困りごとや改善したい点を洗い出し、それを解決するために必要な要件をまとめることが、この工程の中心的な目的です。そのため、「業務の目的や課題を明確化するため」である選択肢2が正解になります。

選択肢1の「技術的な詳細設計を進めるため」は、プログラム構造やデータ構造などを具体的に決めていく設計工程の目的であり、業務要件定義より後のフェーズの内容です。選択肢3の「システムの運用ルールを策定するため」は、運用設計や運用ルールの整備に関する内容で、こちらも開発の後半フェーズで検討される事項であり、業務要件定義の主な目的とは異なります。

【解説】

正解: 1 システムのプログラムコード記述

この問題は、業務要件定義の段階で実施すべき作業と、後続工程で実施される作業を区別できているかを確認するものです。要件定義では「何を実現するか」を決め、設計・実装では「どのように実現するか」を具体化するという流れを理解しているかがポイントです。

業務要件定義では、現状の業務プロセスを把握し（業務プロセスの現状分析）、その上で業務の目的を達成するために必要な機能を整理します（必要な機能の洗い出し）。したがって、選択肢2の「業務プロセスの現状分析」と選択肢3の「必要な機能の洗い出し」は、どちらも業務要件定義で重要となる典型的な作業です。一方で、具体的な「プログラムコードの記述」は、設計・実装段階で行う開発者の作業であり、要件定義の範囲には含まれません。そのため、業務要件定義において必要とされない作業として選択肢1が正解になります。

選択肢2の「業務プロセスの現状分析」は、現行業務にどのような流れや課題があるかを把握するための基礎作業であり、業務要件定義の出発点となる重要な工程です。選択肢3の「必要な機能の洗い出し」は、把握した業務課題を解決するために、システムとして備えるべき機能を整理する作業であり、まさに要件定義の中核に位置付けられます。これらはどちらも「必要とされる作業」である点が、選択肢1との違いです。

【解説】

正解: 2 業務の目的を達成するための要件

この問題は、業務要件定義で最終的に「何を明確にしておくべきか」という成果物のイメージを持てているかを確認するものです。単に情報を集めるだけでなく、業務目標と結び付いた要件を整理する段階であることを理解しているかがポイントです。

業務要件定義では、業務の目的や解決したい課題を踏まえて、「どのような仕組み・機能・ルールがあれば業務目標を達成できるか」を要件としてまとめます。したがって、「業務の目的を達成するための要件」を明確にする選択肢2が、この工程で明らかにされるべき内容として正解になります。

選択肢1の「システム導入後の保守計画」は、システムを運用していく段階での体制や手順に関する内容であり、主に運用設計や運用計画のフェーズで検討されます。選択肢3の「プロジェクトのスケジュール」は、プロジェクトマネジメントに関する事項であり、プロジェクト計画の一部として扱われるものです。いずれも業務要件そのものではなく、「業務目標に対してどのような要件が必要か」を整理する業務要件定義の中心的な内容とは異なります。

【解説】

正解: 3 プログラムデバッグ

この問題は、利用者の要求を把握するための「調査手法」と、システム開発工程で行う「技術的作業」とを区別できているかを確認するものです。要求定義フェーズと実装フェーズの役割の違いを理解しているかが問われています。

利用者の要求の調査では、利用者がどのような課題を抱えているか、どのような機能を求めているかを把握するために、アンケートやインタビューといった手法が用いられます。これらは利用者の声を直接収集するための典型的な調査手法です。一方で、プログラムデバッグは作成されたプログラムに不具合がないかを確認し、修正するための技術的な作業であり、要求を調査する手法ではありません。そのため、選択肢3が「用いられない手法」として正解になります。

選択肢1の「アンケート調査」は、多数の利用者から広く意見や満足度、要望などを収集できる方法であり、要求調査でよく使われる手法です。選択肢2の「インタビュー」は、個々の利用者に対して詳細に話を聞き、深いニーズや背景事情を把握するための有効な手段です。これらはどちらも利用者の要求を調査する代表的な手法であり、プログラムデバッグとは目的もタイミングも異なる点が重要です。

【解説】

正解: 2 利用者と継続的に対話すること

この問題は、利用者の要求を正確に把握するために、どのような姿勢・進め方が重要かを理解しているかを確認するものです。単発のヒアリングだけでなく、継続的なコミュニケーションが必要であることを意識できているかがポイントです。

利用者の要求は、最初から完全で明確な形で示されるとは限らず、対話を重ねる中で具体化・修正されていくことが多くあります。そのため、要件定義では、利用者と継続的に対話し、質問や確認を繰り返しながらニーズや課題を深掘りしていくことが重要です。この継続的なコミュニケーションを前提とする選択肢2が、利用者の要求を正確に把握するためのポイントとして正解になります。

選択肢1の「開発者の希望を優先すること」は、開発しやすさや技術的な都合を重視する姿勢であり、利用者中心のシステム開発という観点からは不適切です。選択肢3の「システムの完成イメージを決めること」は、最終的には必要な作業ですが、要求を十分に理解する前にイメージだけを先に固定してしまうと、利用者の真のニーズからずれたシステムになりかねません。これらに対して、対話を通じて要求を磨き込む選択肢2が適切であることが分かります。

【解説】

正解: 3 システムが利用者のニーズを満たすため

この問題は、利用者の要求を調査する活動の「目的」は何かを理解しているかを確認するものです。調査そのものが目的ではなく、「どのようなシステムを作るための手段なのか」を意識できているかが問われています。

利用者の要求の調査は、最終的に構築するシステムが利用者のニーズや業務上の課題にきちんと応えるものになるように、その前提となる情報を収集する活動です。利用者が何に困っているのか、どのような機能や改善を期待しているのかを理解し、それを要件として反映させることが、調査の本来の目的です。そのため、「システムが利用者のニーズを満たすため」である選択肢3が正解となります。

選択肢1の「利用者が開発チームに適応するため」は、利用者側が開発者の都合に合わせることを前提としており、本来の利用者中心の考え方と逆転しています。選択肢2の「開発者のスキル向上を目的とするため」は、開発者教育としては意味があるかもしれませんが、利用者の要求調査の目的とは直接結び付きません。これらに対して、システムを利用者ニーズに合致させるという観点を示す選択肢3が適切です。

【解説】

正解: 1 調査データのパターンや傾向を把握すること

この問題は、利用者の要求などについて調査を行った後、その結果をどのように分析すべきかという「分析工程の役割」を理解しているかを確認するものです。単にデータを集めるだけでなく、その中から意味のある情報を読み取ることが求められている点がポイントです。

調査内容の分析では、アンケート結果やインタビュー記録などのデータを整理し、共通する課題や要望、頻出するパターン、時間や属性ごとの傾向などを把握します。こうしたパターンや傾向を把握することで、利用者全体に共通するニーズや優先的に対応すべき問題が見えてきます。そのため、選択肢1の「調査データのパターンや傾向を把握すること」が、分析で最も重視される作業として正解になります。

選択肢2の「プロジェクトの予算を確定すること」は、プロジェクト計画やマネジメントの範囲に属する作業であり、調査データの分析そのものの目的ではありません。選択肢3の「開発スケジュールを策定すること」も、プロジェクト計画の一部であり、分析結果を参考にすることはあっても、「調査内容の分析」という工程の中心的な作業とは言えません。これらと比べて、データから意味を導き出す選択肢1が分析工程の本質を表しています。

【解説】

正解: 3 プログラムコーディングの実施

この問題は、調査内容の分析で利用される「分析手法」と、開発工程で行われる「実装作業」とを区別できているかを確認するものです。データ分析に用いる手法のイメージを持てているかが問われています。

調査内容の分析では、収集したデータを整理し、図表や統計的方法を用いて傾向や関係性を明らかにします。パレート図や特性要因図は、不良の要因分析や重要度の把握などに用いられる代表的な品質管理・分析手法です。また、回帰分析は、ある変数同士の関係を数式として表し、傾向を把握するための統計的手法です。これらは、調査データから有用な知見を得るための「分析の道具」として適切に用いられます。一方、プログラムコーディングはシステムを実装するための作業であり、調査データを分析する手法そのものではありません。そのため、選択肢3が「適切でないもの」として正解になります。

選択肢1の「パレート図や特性要因図の活用」は、原因や重要度を整理し、どこに重点的に対策を打つべきかを判断するのに役立つ分析手法です。選択肢2の「回帰分析を用いた傾向把握」は、データの関係性や将来の傾向を推定するために用いられる統計的分析手法です。どちらも調査内容の分析において「データから意味を読み取る」ための適切な手段であり、コーディング作業とは目的も性質も異なります。

【解説】

正解: 2 利用者の要求に関する明確な洞察

この問題は、調査内容の分析を行った結果として「何が得られていれば成功と言えるか」という成果物のイメージを理解しているかを確認するものです。分析は単なる集計ではなく、「理解の質」を高めるための活動であることを意識できているかがポイントです。

調査内容の分析の目的は、収集したデータを通じて、利用者がどのような課題を抱え、どのようなニーズを持っているのかについての明確な理解を得ることです。つまり、「どの利用者層が、どのような場面で、何に困っているのか」といった洞察を得ることが分析結果として重要です。そのため、「利用者の要求に関する明確な洞察」である選択肢2が、調査内容の分析結果として適切なものとなり、正解になります。

選択肢1の「要求を満たす設計仕様書」は、分析結果を踏まえて後続の設計工程で作成される成果物であり、分析そのものの結果ではありません。選択肢3の「システムテストの結果報告」は、実装されたシステムを検証した後に作成される報告書であり、開発のかなり後半に位置する成果物です。これらは調査分析の次のフェーズ以降で作成されるものであり、「分析結果そのもの」とは性質が異なります。

【解説】

正解: 1 業務プロセスを正確に把握すること

この問題は、「現行業務の分析」が何を目的として行われるのかを理解しているかを確認するものです。新しいシステムを検討する前に、今の業務がどのように行われているかをきちんと把握する必要性を意識できているかが問われています。

現行業務の分析では、業務フローや関係者、入力・出力情報、使用している帳票やシステムなどを調査し、現状の業務プロセスを正確に把握します。その上で、どこに無駄やボトルネックがあるのか、どの部分をシステム化すると効果が高いのかといった課題や改善点を明らかにしていきます。したがって、「業務プロセスを正確に把握すること」を目的とする選択肢1が、現行業務の分析の目的として最も適切であり、正解となります。

選択肢2の「システム開発費用を抑えること」は、結果として期待される効果の一つになり得ますが、現行業務の分析そのものの直接的な目的ではありません。選択肢3の「開発者の作業負担を軽減すること」も、プロジェクト運営上の望ましい状態ではありますが、現行業務の分析を行う主目的とは言えません。これらに対して、業務プロセスの把握という、本来の分析活動の中心を示す選択肢1が適切です。

【解説】

正解: 1 業務フロー図の作成

この問題は、現行業務を分析する際に用いられる代表的な手法を理解しているかを確認するものです。業務の流れをどのように可視化し、関係者間で共有するかという観点が問われています。

現行業務の分析では、業務の手順や担当者、情報の流れなどを整理し、それを分かりやすく図として表現するために「業務フロー図」がよく使われます。業務フロー図を作成することで、処理の抜け・重複・ボトルネックなどを発見しやすくなり、改善の検討にもつなげやすくなります。したがって、現行業務の分析手法として最も適切なのは業務フロー図の作成を挙げた選択肢1であり、これが正解です。

選択肢2の「プログラム言語の選定」は、システムをどの技術基盤で実装するかを決める設計・開発寄りの作業であり、現行業務そのものの分析手法ではありません。選択肢3の「デバッグ作業の実施」は、プログラムの不具合を修正する実装フェーズの作業であり、業務分析とは目的もタイミングも異なります。これらに対し、業務の流れを視覚化する業務フロー図は、現行業務分析に直接用いられる手法です。

【解説】

正解: 3 業務プロセスの課題と改善点

この問題は、現行業務の分析を行った結果として「何を明らかにすべきか」を理解しているかを確認するものです。単に現状を写し取るだけでなく、改善に結び付く視点を持てているかがポイントです。

現行業務の分析では、業務プロセスを詳細に把握したうえで、どの手順に無駄や属人化、遅延の原因があるのかといった「課題」を明らかにし、どのように見直せば効率化や品質向上につながるかという「改善点」を洗い出します。したがって、「業務プロセスの課題と改善点」を明らかにすることを示した選択肢3が、現行業務分析の結果として最も適切であり、正解となります。

選択肢1の「利用するテクノロジーの詳細な選定」は、現行業務分析を踏まえた後のシステム設計や技術選定の段階で検討される内容です。選択肢2の「システム開発の実装手順」も、実際の開発作業をどの順番で進めるかというプロジェクト計画・実装寄りの内容であり、現行業務分析の直接の成果ではありません。これらに対して、業務の現状から導かれる「課題と改善点」は、分析工程のアウトプットそのものである点が違いとなります。

【解説】

正解: 2 業務目標を達成するための要件

この問題は、「業務要件の定義」という工程が、システム開発全体の中でどのような役割を果たすのかを理解しているかを確認するものです。単にシステム仕様を列挙するのではなく、「業務目標」と結び付いた要件整理であることを意識できているかが問われています。

業務要件の定義では、業務の目標や経営上の方針を踏まえ、「その目標を実現するためにシステムにどのような機能やルール、情報の流れが必要か」を要件として整理します。つまり、「どのような業務状態になれば成功と言えるか」を具体的な要件として言語化する工程です。そのため、「業務目標を達成するための要件」を明確にすることを示す選択肢2が、この工程の主な目的として正解になります。

選択肢1の「システムの設計書を作成すること」は、定義された要件を基にシステム構造や画面設計などを具体化していく設計工程の成果物です。選択肢3の「プロジェクトのリスク分析を行うこと」は、プロジェクトマネジメントの一部として行われる活動であり、業務要件そのものを定義する工程とは目的が異なります。これらと比較すると、業務目標に直結する要件を明確にする選択肢2が、業務要件定義の本質を表しています。

【解説】

正解: 1 業務目標を実現するための必要な機能

この問題は、業務要件の定義において特に重視される「要素」が何であるかを理解しているかを確認するものです。業務目標とシステムの機能をどのように結び付けて考えるかという視点が問われています。

業務要件の定義では、「どのような業務目標を達成したいのか」を明確にしたうえで、その目標を実現するために必要な機能や処理、データの扱い方などを整理します。例えば、「処理時間を短縮したい」という目標に対しては、「入力作業を簡略化する機能」や「自動計算機能」など、具体的な機能要件として落とし込んでいきます。このように、業務目標に直結する「必要な機能」を特定することが業務要件定義で重視されるため、選択肢1が正解となります。

選択肢2の「システムのメンテナンス計画」は、システムの運用・保守段階で重要となる計画であり、業務要件の定義そのものではなく、後続の運用設計に属する内容です。選択肢3の「開発ツールの選定」は、開発プロジェクトをどの技術環境で進めるかという技術的な判断であり、業務目標と機能の整理という観点からは離れています。これらに対し、業務目標と直接結び付く機能を特定する選択肢1が、業務要件定義で重視される要素を正しく表しています。

【解説】

正解: 3 利用者の要求と現行業務を基に要件を整理する

この問題は、業務要件定義を進めるうえで、どのような情報に基づいて要件をまとめることが適切かを理解しているかを確認するものです。システム主導ではなく、業務と利用者の視点から要件を組み立てる姿勢を持てているかが問われています。

適切な業務要件定義では、まず現行業務の流れや課題を分析し、同時に利用者からの要求やニーズをしっかりとヒアリングします。そのうえで、「現状の業務」と「利用者の期待」の両方を踏まえた要件として整理していきます。このように、利用者の要求と現行業務を基盤として要件を組み立てる選択肢3が、最も妥当なアプローチであり、正解となります。

選択肢1の「システム構築後に業務プロセスを調整する」は、システムを先に作り、その後で業務を無理に合わせる考え方であり、業務とのミスマッチや現場の負担増大を招きやすく、望ましいアプローチではありません。選択肢2の「全ての業務プロセスをシステム化することを前提にする」は、コストや効果、業務の性質を無視した極端な前提であり、現実的な制約や効率性を十分に考慮していない点で不適切です。これらに対して、利用者の要求と現行業務の両方を起点に要件を整理する選択肢3が、実務的でバランスの取れた進め方と言えます。

【解説】

正解: 2 システムの応答速度

この問題は、「機能要件」と「非機能要件」の違いを理解しているかを確認するものです。特に、システムの「何をするか」と「どのように振る舞うか」を分けて考えられているかがポイントです。

非機能要件は、システムが提供する具体的な機能そのものではなく、「性能」「信頼性」「可用性」「セキュリティ」など、システムの品質や動作特性に関する条件を定義したものです。「システムの応答速度」は、画面遷移や検索結果表示にかかる時間などに関する要求であり、性能面の条件に該当します。そのため、「非機能要件に該当する項目」として選択肢2が正解になります。

選択肢1の「ユーザーログイン機能の仕様」は、ログインという具体的な機能に関する要件であり、「何ができるか」を定義する機能要件の例です。選択肢3の「商品検索機能の設計」も、商品をどのような条件で検索できるかといった具体的な処理内容に関するもので、機能要件に分類されます。これらはシステムの品質条件ではなく、提供する機能の中身に関する要件である点で、非機能要件である選択肢2と区別されます。

【解説】

正解: 2 利用者が検索条件を入力できる機能

この問題は、機能要件がどのような内容を指すのかを具体例を通して理解しているかを確認するものです。ユーザーが「システムを使って何ができるか」に関する記述を機能要件として捉えられているかがポイントです。

機能要件は、システムが提供する具体的な処理やサービスの内容、つまり「どのような入力を受け取り、どのような出力を返すか」といった機能面の要件を示します。「利用者が検索条件を入力できる機能」は、ユーザーが条件を指定して検索処理を行えるようにするという、システムが提供すべき具体的な機能に関する記述です。そのため、選択肢2が機能要件の具体例として正しいものとなります。

選択肢1の「データベースのバックアップ間隔」は、どの頻度でバックアップを取得するかという運用や信頼性に関する条件であり、非機能要件の一種と捉えられます。選択肢3の「サーバーの可用性」は、システムがどの程度の時間停止せず稼働しているべきかという品質面の条件であり、これも非機能要件に該当します。これらはシステムの動作特性に関する条件であり、ユーザーが利用できる具体的な「機能」の説明である選択肢2とは性質が異なります。

【解説】

正解: 3 システムの安定性と性能

この問題は、非機能要件を適切に設定することが、システムのどの部分に大きな影響を与えるかを理解しているかを確認するものです。非機能要件が「品質」に関する要件であることを意識できているかがポイントです。

非機能要件は、システムの応答速度、同時アクセス数への対応、障害発生時の復旧時間、稼働率、セキュリティレベルなど、システムの安定性や性能、信頼性に関する条件を定めるものです。これらの要件が適切に設定されていないと、機能自体は実装されていても、動作が遅い・すぐに止まる・不正アクセスに弱いといった問題が起こり、実用に耐えないシステムとなってしまいます。そのため、「システムの安定性と性能」に大きな影響を与えるとする選択肢3が正解になります。

選択肢1の「システムの利便性と操作性」は、画面レイアウトや操作手順、メッセージ表示などの設計にも大きく関係し、広い意味では一部非機能要件と関わる要素も含みますが、この問題では主にユーザインタフェース設計の観点が強く、性能・安定性に直接結び付く説明にはなっていません。選択肢2の「利用者の業務フロー」は、業務プロセス設計の問題であり、システム品質そのものというよりは業務の組み立て方に関する内容です。これらと比べて、非機能要件の代表的な対象である「安定性」と「性能」を明確に示している選択肢3が、最も適切な答えとなります。

【解説】

正解: 3 要件を文書化し関係者と共有する

この問題は、要件の合意を得るプロセスにおいて、どのような活動が特に重要かを理解しているかを確認するものです。口頭の認識合わせだけでなく、文書として明確にし共有することの重要性を意識できているかが問われています。

要件の合意では、「どのような機能・性能を持つシステムを作るのか」という内容について、利用者・開発者・経営層などの関係者間で認識を一致させる必要があります。そのためには、定義した要件を文書として整理し、誰が見ても同じ意味に読める状態にしてから、関係者全員に共有し、確認や承認を得ることが欠かせません。この「要件を文書化し関係者と共有する」プロセスを示した選択肢3が、要件合意のために最も重要なプロセスとして正解になります。

選択肢1の「プロジェクトメンバーの作業負担を軽減する」は、望ましい結果の一つではありますが、要件の合意そのもののプロセスを表しているわけではありません。選択肢2の「開発スケジュールを確定する」も、プロジェクト計画の一部として重要ではあるものの、「要件内容について合意を形成する」という目的からは一段階ずれた活動です。これらに対し、要件を明文化し共有する選択肢3は、合意形成プロセスの中核となる具体的な行動を示しています。

【解説】

正解: 2 曖昧な表現で要件を定義すること

この問題は、要件の合意を行う場面で、どのような行動が合意形成を妨げるのかを理解しているかを確認するものです。関係者間の誤解を生みやすい要件定義の仕方を避けられているかがポイントです。

要件の合意では、関係者全員が同じ内容を同じ意味で理解していることが重要です。そのため、要件は誰が読んでも解釈がぶれないよう、できるだけ具体的かつ明確な表現で記述する必要があります。「曖昧な表現で要件を定義すること」は、見る人によって受け取り方が変わってしまい、後になって「想定と違う」「そんなつもりではなかった」というトラブルの原因となります。そのため、これは要件合意の場面で避けるべき行動であり、選択肢2が正解となります。

選択肢1の「利害関係者の意見を十分に聞くこと」は、各立場の要望や懸念を把握し、合意を形成するうえで非常に重要な行動です。選択肢3の「定義済みの要件を文書として提供すること」も、認識のズレを防ぎ、後から内容を確認できるようにするために欠かせないプロセスです。これらは合意形成を支援する行動であり、避けるべきものではない点が、選択肢2との違いです。

【解説】

正解: 1 プロジェクトの進行を円滑にするため

この問題は、なぜ要件の合意が必要なのか、その意義を理解しているかを確認するものです。要件合意がプロジェクト全体の進行や成果にどのような影響を与えるかをイメージできているかがポイントです。

要件の合意がしっかりと取れていると、プロジェクトメンバーは「何を作るべきか」「どこまで対応するか」というゴールを共有できます。その結果、設計・実装・テストなど各工程で迷いが減り、手戻りも少なくなります。また、後から「この機能も欲しい」「やはり別の仕様にしたい」といった大きな変更が入りにくくなり、スケジュールやコストの見通しも立てやすくなります。このように、要件合意はプロジェクトの進行を円滑にするための前提条件であるため、選択肢1が最も適切な理由として正解になります。

選択肢2の「システムの技術的制約を排除するため」は、合意によって技術的制約がなくなるわけではなく、むしろ技術的制約も踏まえた形で要件を調整し、現実的な落としどころを見つけることが重要です。選択肢3の「利用者全員の要望を満たすため」は理想ではありますが、予算や期間、技術的制約の中で全ての要望を満たすことは現実的ではない場合も多く、要件合意は「優先順位を付け、合意できる範囲を決める」作業だと言えます。したがって、プロジェクト全体をスムーズに進めるという観点を示した選択肢1が、要件合意が必要とされる理由として最もふさわしい答えです。