業務要件定義

この工程は何をするのか

IT パスポート試験シラバス Ver.6.5 の「23. 要件定義」は、この工程をこう定義している。

業務要件定義では，経営戦略やシステム戦略，利用者のニーズを考慮して，システムに求める機能及び要件を定義すること

同じ項の「活用例」には、実際にやることが並んでいる。

利用者の要求の調査，調査内容の分析，現行業務の分析，業務要件の定義，機能要件・非機能要件の定義，要件の合意

平たく言えば、「今どうやっているか」を調べ、「これからどうしたいか」を決め、関係者に「それでいい」と言ってもらう工程。作るものを決める前の工程なので、まだプログラムの話は出てこない。

出題範囲の上ではストラテジ系の「システム企画」（大分類3 システム戦略／中分類7）に入る。マネジメント系の「システム開発技術」に入るシステム要件定義とは別の工程で、そちらは業務要件が決まったあとに「ではシステムはどう振る舞うべきか」を詰める。

機能要件と非機能要件

シラバスが両方を挙げているので、区別しておく。

機能要件 — システムが何をするか（例: 作業記録を入力できる、月次で集計する）
非機能要件 — どのくらいの品質でやるか（例: 何人が同時に使えるか、何秒で返ってくるか、誰が見られるか）

非機能要件は忘れられやすいが、あとから直すと作り直しになる。

具体的な成果物

成果物	中身
現行業務の分析結果	今の手順を、担当者・使っている道具・かかる時間まで含めて書き出したもの
機能要件・非機能要件の一覧	システムに求めることを、機能と品質に分けて列挙したもの
関係者の合意の記録	誰がいつ何に合意したか。「言った / 言わない」を防ぐ

つまずきやすいところ

要望を聞いた相手が、本当の要望を言うとは限らない。 事例カタログの船井総研グループの例では、タブレット入力の仕組みを現場に入れたとき、作業員からこういう声が出ている。

「タブレット入力が二度手間になる」「管理されるようで嫌だ」

同社の対応は、リアルタイムで修正を出し続けることと、作業員一人ひとりにヒアリングを重ねて「不安や懸念に隠れている要望」を見つけ出すことだった（cases/ai-activation-catalog.md）。

「管理されるようで嫌だ」は要件の形をしていない。しかしその裏には「評価に使わないでほしい」という要件が隠れている。要件定義でいちばん難しいのはこの翻訳で、ここを飛ばすと、動くけれど使われないシステムができる。

AI に任せられる範囲

調べて整理し、決めた内容を文書にするところ

Gemini CLI の Plan Mode は、プロジェクトを変更せずに調査し、トレードオフを評価し、実行戦略に合意してからでないと次に進まない read-only の環境として作られている（facts/gemini-cli/plan-mode.md）。要件定義の進め方とそのまま重なる。

調査中はファイルを書き換えられない。書き込みが許されるのは計画ディレクトリ内の .md だけなので、まだ決まっていない段階で勝手に何かを作られる事故が起きない
ask_user で質問や選択肢を出し、正式な計画を書き起こす前に必ず停止して確認を待つ
合意できたら詳細な計画を Markdown で書き出す
Ctrl+X で外部エディタを開いて人が直接手を入れられる。保存して閉じると変更を自動検出し、コメントを読んで戦略を調整したうえで再提示する

最後の項目が要件定義向きで、文書を人と AI で往復しながら詰められる。決定事項を書き取る作業と、書いたものの矛盾を洗い出す作業は任せてよい。

要望をその場で形にして見せるところ

船井総研グループの熊谷俊作氏は、製造業の顧客で工場に朝から晩まで張り付いて現場を観察し、見つけた要望をその場で Gemini に伝え、生成されたコードを即座にアプリに反映している（cases/ai-activation-catalog.md）。

従来なら数か月かかるような開発がその場で実現

結果として顧客の8割がアプリを活用した。要件を文章で確認するより、動くものを見せた方が早く正確に合意できる場面がある、という実例になっている。

まだ人がやること

現場に入って観察すること。 上の熊谷氏の例で AI がやったのは「伝えられた要望をコードにする」ところで、朝から晩まで工場に張り付いて要望を見つけたのは人である。何が問題なのかは、その場に居ないと分からない。

隠れた要望を引き出すこと。 「管理されるようで嫌だ」の裏を読むには、一人ひとりへのヒアリングを重ねる必要があった。相手が言語化していないものは、記録に残っていないので AI には渡せない。

合意を取ること。 誰が決定権を持つのか、反対している人にどう納得してもらうかは、組織の力学の話であって要件の話ではない。

この工程の ai_leverage を high ではなく medium にしているのはこのため。整理と文書化は任せられるが、入力を集める部分と合意を取る部分が人に残っている。