「申請画面がほしい」「利用者管理を作りたい」という言葉は、目的ではなく手段かもしれません。要件とは、機能の一覧だけではなく、誰が何のために使い、最低限どの状態なら完了かを決めることです。分からない項目は無理に埋めず、「仮置き」と「要調査」に分ければ、相談する材料になります。

要件を整理する3段階

最初から全画面の仕様書を作る必要はありません。次の順で会話すると、業務の背景と、最初に試す範囲がつながります。

  1. 01

    目的

    何を減らし、何を確認できる状態に変えたいのかを言葉にします。

  2. 02

    利用者と情報

    誰が使い、どの情報を入力・閲覧し、見せてはいけないものは何かを分けます。

  3. 03

    最初の範囲と確認条件

    代表的な流れを一つ検証し、最低限どの状態なら次へ進めるかを決めます。

目的から逆算して、利用者・情報・最初の確認範囲を順に具体化します。

例（架空）：備品購入申請を小さく整理する

架空の例として、備品購入の申請がメールと表計算に分かれているとします。申請者はメールで依頼し、担当者が表計算へ転記し、承認済みかどうかを個別に確認している状態です。ここで「全部を自動化する」のではなく、まず抜け漏れを減らし、申請の状態を同じ一覧で確認できることを目的にします。

この架空例では、将来の流れを一つ作り切るのではなく、限定した部門・用途の代表的な流れを一つ検証します。確認用試作は実データを使わず、通知、帳票、別部門への展開は、使ってみた結果と運用上の必要性を確認してから判断します。

範囲と状態を同じ表で確認する

初回に入れるもの、後から追加するもの、今回の対象外を分けます。状態も「確認済」「仮置」「要調査」と表示すると、決まったことと、まだ責任者を決めて調べることが混ざりません。担当と根拠まで残せば、次の打ち合わせで判断をやり直せます。

横幅が狭いときは左右にスクロールできます

備品購入申請を例にした、範囲・状態・担当・根拠の一覧
範囲状態担当根拠
最初確認済業務責任者・申請者入力、一覧、承認が目的を確かめる代表的な流れとして合意された。
後仮置業務責任者通知・帳票は手作業で代替できるため、初回利用後に必要性を確認する。
対象外要調査情報管理担当・開発担当代理申請や外部サービス連携は、権限と扱う情報を確認してから判断する。

相談から実装前確認までの6段階

進行中に要件が変わること自体を失敗とせず、変更の理由と影響を記録します。各段階で成果物と判断条件を確認すると、作ることが目的になりません。

  1. STEP 01

    現行業務を観察する

    成果物：メール、表計算、口頭確認を含む現行の流れ。判断条件：関係する役割が、どこで困っているかを同じ図で確認できる。

  2. STEP 02

    目的・利用者・情報を分ける

    成果物：目的、利用者、入力・閲覧情報の整理メモ。判断条件：誰が何のために使い、見せてはいけない情報が何かを説明できる。

  3. STEP 03

    最初の範囲を仮置きする

    成果物：最初・後・対象外に分けた範囲表。判断条件：初回で確かめる目的と、手作業で残す部分に業務側の合意がある。

  4. STEP 04

    本実装前の確認用試作で、代表的な流れを一つ検証する

    成果物：実データを使わない、限定部門・用途の確認用試作。判断条件：実際の利用者がサンプル情報で入力から完了までを追い、最低限の完了状態を確認できる。

  5. STEP 05

    確認条件と安全面を点検する

    成果物：確認項目と未解決事項の一覧。判断条件：承認、個人情報、権限、外部連携を含む境界と、誰が承認するかを説明できる。

  6. STEP 06

    本実装と次の範囲を合意する

    成果物：判断記録と次の計画。判断条件：目的、利用者、初回範囲、扱う情報、確認条件、予算・時期を合意し、進めるか見送るか決められる。

AIはたたき台、人が最終判断をする

AIは、整理した内容から画面やデータのたたき台を作ったり、確認項目を並べたりする補助に向いています。しかし、AIを意思決定者にはしません。人が要件の漏れや矛盾を確認し、権限の境界、テストの観点、公開してよい状態かどうかを最終判断します。AIを使った整理や実装の分担は、AI駆動開発の実践でも工程ごとに紹介しています。

要件整理は、すべてを決めてから始める作業ではありません。現行業務と目的を話し、分かること・仮置きすること・要調査のことを分け、代表的な流れを小さく確かめます。構想段階から目的と優先順位を整理する進め方は、AI駆動システム開発のページでもご案内しています。