要件定義で最初に書く1枚：目的・対象・やらないことを決める

要件定義で最初に作るのは機能一覧ではなく、目的・対象・やらないことを書いた1枚です。この3つが決まっていないと、機能を足すか減らすかの判断がその場の空気で決まります。逆に3つが決まっていれば、機能一覧は後から議論できます。

Web制作会社、事業会社のWeb担当、大手ITのテクニカルディレクター、独立後の一人体制。どの立場でも、要件が膨らむプロジェクトには共通点がありました。判断の基準になる紙が1枚もなかったことです。

1枚に書くのは3つだけ

私が最初に書く1枚は、A4で収まる分量です。

項目	書くこと	分量の目安
目的	このサイト／システムで到達したい状態	1〜2文
対象	使う人と、決める人	3〜5行
やらないこと	今回の範囲外	3〜7行

これ以上は書きません。1枚に収める理由は、全員が読み切れるからです。20ページの要件定義書は、作った人以外は目次しか見ません。判断の基準は、会議中に指差せる分量である必要があります。

なお、この1枚は要件定義書の代わりではなく、その先頭に置く合意事項です。ISO/IEC/IEEE 29148-2018 は、要件エンジニアリングについて「ライフサイクル全体を通じたシステム・ソフトウェア製品およびサービスの要求に関するプロセスと成果物の規定を含む」とし、良い要求の構成や属性・特性を定義するものだと説明しています（ISO/IEC/IEEE 29148-2018）。詳細はその先で積み上げるものです。1枚は、積み上げる方向を決めるためのものです。

目的は「状態」で書く。手段を書かない

目的の欄に「サイトをリニューアルする」と書いてしまうと、何も決まりません。それは手段だからです。

私は「どうなっていたら成功か」を状態で書くようにしています。

• ✕ コーポレートサイトをリニューアルする
• ○ 採用応募者が、応募前に事業内容と働き方を自分で確認できる状態にする

状態で書くと、後の議論が変わります。「トップページに動画を入れたい」という要望が出たとき、「応募前に自分で確認できる状態に近づくか」で話せる。好き嫌いの話に落ちにくくなります。

数字が置けるなら置きますが、無理に作らなくてよいと考えています。置けないときは、状態の記述を具体的にすることで代替します。

「対象」には決める人まで書く

対象の欄には、使う人だけでなく社内で決める人を書きます。

使う人は「30代の採用応募者」のような書き方でかまいません。重要なのはその下です。「デザインの最終決定は誰か」「原稿の責任者は誰か」「公開の判断は誰か」を名前で書きます。

これを1枚に書いておくと、確認が止まったときに何が起きているかが分かります。決める人が書かれていないプロジェクトでは、「持ち帰って検討します」が何回でも繰り返されます。誰が決めるかを最初に紙にしておくと、その回数が減ります。

役職ではなく名前で書くのがコツです。役職で書くと、実際に判断している人と一致しないことがあります。

「やらないこと」が1枚の本体になる

3つのうち、いちばん効くのがこの欄です。私は3種類に分けて書いています。

1. 今回やらない（次フェーズで扱う可能性がある）
2. そもそもやらない（このプロジェクトの範囲ではない）
3. こちらでやらない（クライアント側や別会社の担当）

「多言語対応は今回やらない」「既存記事の移行はクライアント側で実施」のように、どの種類かが分かる書き方にします。1と2を混ぜて書くと、後で「あれは次回やる話でしたよね」と食い違います。

やらないことを書くのは、断るためではありません。足す判断をしやすくするためです。範囲が書いてあれば、「これを足す代わりに何を外すか」という会話ができます。範囲が無いと、足す話しかできません。

1枚では拾えないもの——非機能は別で扱う

この1枚に、速度・可用性・運用体制といった非機能の話は入れません。入れると1枚に収まらなくなり、収めようとすると曖昧になります。

非機能については、IPAの「非機能要求グレード」が、非機能要求を6つの大項目ごとに階層的に整理した資料を公開しています（非機能要求グレード）。Web制作の規模でそのまま全部を使うことは少ないですが、項目の並びを見ながら「今回どれを決めておくべきか」を選ぶ使い方はできます。私は運用・保守と性能の項目だけ抜き出して、別紙のチェックリストにしています。

明日から試せる一手

いま進めているプロジェクトの資料を開いて、「やらないこと」が書かれた行があるかを探してみてください。無ければ、3行だけ書き足します。今回やらないこと、そもそもやらないこと、こちらでやらないこと。1つずつで十分です。

書いたら、次の打ち合わせでその3行を読み上げて、認識が合っているかだけ確認する。ここで食い違いが出れば、それは要件が膨らむ前に見つかったということです。3行を書く時間より、後から巻き戻す時間のほうがずっと長くなります。