この工程は何をするのか
IT パスポート試験シラバス Ver.6.5 の「25. システム開発技術」は、開発プロセスの最初の工程をこう置いている。
① システム要件定義・ソフトウェア要件定義 ・システム・ソフトウェアに要求される機能，性能などを明確化するシステム要件定義，ソフトウェア要件定義などが行われること
用語例に品質の観点が並ぶ。
機能要件，非機能要件，共同レビュー，品質特性（機能性，効率性，使用性，信頼性など）
業務要件定義との違いは、言葉が業務のものからシステムのものに変わること。 「請求書を月末に一括で出したい」（業務要件）を、「月次バッチで最大 5,000 件を 10 分以内に処理する」（システム要件）に置き換える工程。
出題範囲の上でも別の場所にあり、業務要件定義はストラテジ系の「システム企画」、こちらはマネジメント系の「システム開発技術」に入る。
品質特性
シラバスが用語例に挙げているものを、意味を添えて並べる。
| 品質特性 | 問い |
|---|---|
| 機能性 | 求められた機能が揃っているか |
| 効率性 | 使う資源（時間・メモリなど）に見合っているか |
| 使用性 | 使う人にとって分かりやすいか |
| 信頼性 | 止まらないか、止まっても戻せるか |
非機能要件はこの観点ごとに数値にしておく。「速いこと」では検収できない。
具体的な成果物
| 成果物 | 中身 |
|---|---|
| システム要件・ソフトウェア要件の一覧 | 機能と性能を、実装できる粒度まで落としたもの |
| 品質特性ごとの目標値 | 何秒以内、何件まで、稼働率何パーセント |
| 共同レビューの記録 | 発注側と開発側が同じ内容で合意したことの証拠 |
つまずきやすいところ
共同レビューをシラバスがわざわざ用語例に入れている理由。 要件は書いた側と読む側で意味がずれる。発注側と開発側が同席して同じ文書を読み合わせないと、実装が始まってから食い違いが出る。
非機能要件を「あとで」にすると、作り直しになる。 同時利用者数や応答時間は、設計の骨格（どこで処理を分けるか）を決めてしまう。決まってから変えると、部分的な修正では済まない。
AI に任せられる範囲
調査し、合意してから、要件を文書にするところ
Gemini CLI の Plan Mode は、プロジェクトを変更せずに調査し、トレードオフを評価し、実行戦略に合意してからでないと次に進めない read-only の環境として作られている（facts/gemini-cli/plan-mode.md）。この工程の進め方と重なる。
- 調査の段階で書き込めるのは計画ディレクトリ内の
.mdだけ。要件が固まる前にコードを書き始められる事故が起きない ask_userで質問や選択肢を出し、正式な計画を書き起こす前に必ず停止して確認を待つ- 合意後、詳細な計画を Markdown で書き出す
Ctrl+Xで外部エディタを開いて人が直接手を入れると、保存時に変更を自動検出し、コメントを読んで戦略を調整したうえで再提示する
最後の項目が共同レビューに近い形で使える。文書を人と AI で往復させながら、抜けと矛盾を潰していく作業は任せてよい。
既存のコードから現状を読み取るところ
Plan Mode で許可されているツールには read_file、glob、grep_search に加え、codebase_investigator という調査用の subagent が含まれる（facts/gemini-cli/plan-mode.md）。既存システムを作り替える場合、今どう動いているかを読み取る作業はここで任せられる。
まだ人がやること
数値を決めること。 「10 分以内」の 10 がどこから来るのかは業務側の事情で決まる。締め日の何時までに終わっていればよいか、という問いに答えられるのは人だけである。
トレードオフを選ぶこと。 Plan Mode は選択肢を出して確認を待つ設計になっているが、待たれている判断そのものは人がする。速度と正確性のどちらを取るかは要件の話ではなく業務の話になる。
ai_leverage を high ではなく medium にしているのはこのため。書く作業と読む作業は任せられるが、値を決める作業が人に残っている。