システム開発の要件定義でIO仕様が決まらない場合の進め方｜項目100件以上でも破綻させない管理方法

システム開発では、要件定義の段階ですべての入出力（IO）仕様やデータ項目が完全に決まらないことは珍しくありません。特に業務システムでは、利用部門とのヒアリングを重ねることで必要な項目やテーブル構造が変化するケースがあります。

しかし、決まらない状態のまま設計や開発を進めると、手戻りや修正漏れが発生しやすくなります。この記事では、要件定義中にIO仕様が変化する場合の管理方法や、項目数が100件以上ある大規模な画面・帳票設計で混乱を防ぐための実践的な進め方を解説します。

要件定義でIO仕様が完全に決まらないのは珍しいことではない

新規システム開発では、初期段階ですべての入力項目や出力項目を確定することは難しい場合があります。業務担当者自身がシステム化する業務を整理できていないケースや、実際に画面や帳票を見ることで初めて必要な情報に気付くケースがあるためです。

例えば、顧客管理システムを作る場合でも、最初は「顧客名」「住所」「電話番号」程度だった項目が、打ち合わせを進める中で「担当営業」「契約履歴」「問い合わせ履歴」「請求情報」など追加されることがあります。

重要なのは、仕様変更をなくすことではなく、変更が発生する前提で管理する仕組みを作ることです。

いきなり画面項目やテーブル設計を決め始めると、後から大きな変更が発生しやすくなります。まずは業務フローを整理し、「誰が」「いつ」「何の目的で」「どんな情報を利用するのか」を明確にします。

例えば注文管理システムの場合、単純に注文入力画面を作るのではなく、以下のような流れを整理します。

この業務の流れが明確になると、本当に必要なデータ項目と不要な項目を判断しやすくなります。

入力項目や出力項目が100件以上になる場合、頭の中や議事録だけで管理するのは危険です。専用の項目管理表を作成し、変更履歴を残すことが重要になります。

一般的には以下のような項目定義書を作成します。

このような一覧を作ることで、追加された項目、削除された項目、仕様変更された項目を追跡できます。

要件定義中に外部キーやテーブル構造が変わる場合、文章だけで管理すると認識違いが起こります。そのため、ER図（Entity Relationship Diagram）を利用してデータ同士の関係を可視化します。

例えば、最初は「顧客テーブル」と「注文テーブル」だけだったものが、後から「商品テーブル」「担当者テーブル」「請求テーブル」が追加される場合があります。

ER図を更新するルールを決めておけば、設計変更が発生しても開発メンバー全員が最新状態を確認できます。

要件定義後半や開発途中で仕様変更が発生した場合に重要なのは、変更内容を一元管理することです。

具体的には、以下のような変更管理表を作成します。

例えば「顧客番号を10桁から15桁へ変更」という変更があった場合、画面だけでなく、データベース、帳票、外部連携などへの影響を確認できます。

変更管理を行わずに個別対応すると、一部の画面だけ古い仕様が残るなどの不具合につながります。

要件定義が混乱する原因の一つは、「決まったこと」と「まだ検討中のこと」が混ざってしまうことです。

そのため、仕様書には以下のような区分を設けると効果的です。

例えば入力項目について「必要そうだが業務担当者が判断できていない」という場合、無理に確定せず未決事項として管理します。

これにより、開発チームが勝手に判断して後から修正になるリスクを減らせます。

すべての仕様を最初に完全確定するウォーターフォール型の進め方が難しい場合、短いサイクルで確認するアプローチも有効です。

例えば、主要画面だけ先にプロトタイプを作成し、利用者に確認してもらうことで、文章だけでは分からなかった要求を早期に発見できます。

特に業務知識が複雑なシステムでは、実際に画面を見ることで仕様が固まるケースも多くあります。

システム開発の要件定義では、IO仕様やテーブル構造が途中で変化することは珍しくありません。重要なのは、変更を防ぐことではなく、変更を安全に管理できる仕組みを作ることです。

項目数が多い場合は項目定義書、データ構造はER図、変更内容は変更管理表で管理することで、修正漏れや認識違いを防ぐことができます。

また、決定事項と未決事項を明確に分け、必要に応じてプロトタイプや段階的な開発を取り入れることで、複雑な新規開発でも混乱を抑えながら進められます。