ITパスポート 令和8年度 問52：development_managementに関する問題

答えは a です。

システムの『何を作るか（要件定義）』を開発者が決めるとき、使う側の利用者は完成イメージのチェックに参加して『これでOK?』と確認するのが良い関わり方です。

たとえば、家を建てるとき、大工さんが設計図を作ったら、住む人が『この間取りで合ってる?』と一緒に確認しますよね。それと同じです。

👉 覚え方：「利用者は要件のレビューに参加して、ちゃんと自分の希望に合うか確認」。

ほかの選択肢：b 全部おまかせだと希望と違うものができる／c 保守できるかは技術者の仕事／d 技術的に作れるかの検証も開発者の仕事。だから利用者の役目は a の『妥当性の確認』です。

なぜこれが正解か

正解は a。システム要件定義では、要件が利用者の業務ニーズを正しく反映しているか（妥当性）を確認することが利用者の重要な役割。開発者が行うシステム要件のレビューに利用者が参加し、自分たちの要求と合致しているか妥当性を確認するのは適切な関わり方である。

各選択肢の解説

• b：開発者に全て任せて決定に従うのは不適切。利用者の業務知識が反映されず、要件齟齬の原因となる。
• c：システムの保守可能性の見極めは開発者・技術者の専門領域であり、利用者の主たる役割ではない。
• d：要件の技術的実現性の検証も開発者の役割。利用者は技術検証ではなく業務的な妥当性を担う。

覚え方・ひっかけ注意

役割分担を整理：『業務として正しいか（妥当性）＝利用者』『技術的に作れるか（実現性）＝開発者』。利用者は丸投げ(b)も技術検証(c,d)もせず、『自分の業務ニーズに合っているかの確認』が本分。要件定義は利用者と開発者の協働が成功の鍵。

理論的背景

システム要件定義（正式名称：システム要件定義フェーズ）はIPA（情報処理推進機構）の「共通フレーム2013（SLCP-JCF2013）」において「業務要件定義」の後に位置する工程として定義される。業務要件を実現するためのシステム機能・性能・インタフェース・セキュリティ等の技術的要件を定義するフェーズである。

正解aの「開発者が行うシステム要件のレビューに参加し、妥当性を確認する」が利用者の適切な関与として正しい理由は、共通フレームが定義する「ステークホルダの要求の確認」プロセスに対応するためである。利用者はシステムを実際に使う立場として「この要件で自分たちの業務が実現できるか」を検証する責任を持つ。技術的な実現方法の判断（選択肢d）は開発者の責務であり、利用者がそれを担うことは役割逸脱になる。

要求工学（Requirements Engineering）の観点では、要件の「妥当性検証（Validation）：正しい要件を定義しているか」が利用者主体で、「検証（Verification）：要件通りに実装されているか」が開発者主体のプロセスとして区分される。

実務での使われ方

実際のシステム開発プロジェクトでは、利用部門（ユーザー企業）と開発部門（SIer）の役割分担として、利用部門は「業務要件定義書の作成（What）」と「システム要件定義書のレビュー・承認」を担い、開発部門は「システム要件定義書の作成（How）」と「技術的実現性の検証」を担う。この役割分担が崩れると、利用者が技術的に不可能な要件を要求したり、開発者が利用者ニーズを誤解した要件を定義したりするリスクが生じる。

アジャイル開発ではユーザーストーリー（「〇〇として、△△したい。なぜなら□□だから」）というフォーマットで利用者が要件を記述し、受け入れ基準（Acceptance Criteria）を明記することで利用者とのレビュー基準を共有する。

試験での位置づけ

ITパスポートの開発管理分野では、システム開発ライフサイクル（SDLC）の各フェーズにおける「利用者と開発者の役割分担」を問う問題が頻出する。本問のような「利用者の関わり方」を問う問題は実務センスを問う出題であり、「参加・レビュー・妥当性確認＝利用者の役割」「技術的実現性の判断・設計・実装＝開発者の役割」という分担理解が基本。近年のDX推進の文脈では、利用部門のデジタルリテラシー向上により、利用者がより主体的にシステム要件定義に関与する（市民開発者・DevBizOps）という新しいトレンドも問われ始めている。基本情報技術者試験では要件定義の各サブプロセス（機能要件・非機能要件の定義・ユーザビリティ要件・セキュリティ要件等）の詳細まで出題される。

選択肢の発展補足

選択肢bの「開発者に全て任せ、その決定に従う」が不適切な理由として、システム要件定義は業務要件をITで実現する橋渡しフェーズであり、業務知識を持つ利用者の関与なしには「実際の業務に使えるシステム」の要件は定義できない。ユーザーエクスペリエンス（UX）研究でも、ユーザーが開発に関与しないシステムは使われない（Technology Acceptance Model）ことが実証されている。選択肢cの「保守可能性の確認」は非機能要件（保守性）の評価であり、開発者・技術アーキテクトが担う領域。ISO/IEC 25010（ソフトウェア品質特性）では保守性を「変更容易性・再利用性・解析性・テスト容易性・修正性」の5サブ特性で定義しており、これを評価できるのは技術的専門知識を持つ開発者である。