要件定義はSVOC + 5W1(2)Hで!
こんにちは！
株式会社ココナラのエージェント開発部でエンジニアをしているまつもとです。
こちらは株式会社ココナラ Advent Calendar 2025 14日目の記事です。
はじめに
ところで皆さんは要求定義書や要件定義書を書くときに、どのように書くのが良いか悩むことはありませんか。私はいつも悩んでいます。
最初から完成度の高いものや形式にこだわりすぎると中々進まないし、かといって全くの無思慮・無計画で書き進めるのもいかがなものかと思います。
そこで今回は私が要求定義書や要件定義書を書く上で最も心がけている 「SVOC + 5W1(2)H」 を踏まえ、「私なりの書き方」をご紹介したいと思います。
機能要件から書く
業務要件、非機能要件も大切ですが、まずは書きやすい機能要件から書き始めます。
抽象度は高くて良いので機能名を箇条書きで書き出します。
最初から業務要件、非機能要件が洗い出せるならそれに越したことはないですが、最初は「機能要件」だけでも十分だと思います。とりあえず書き始めることが大事だと思っています。
箇条書きで書く
要求、要件は箇条書きの文章で記述します。
１つ１つの文章は可能な限り短く簡潔に記述します。長く複雑な文章は読み手によって異なる解釈を招く可能性が高くなり、後述する「一意性」を損なうことになります。
文章が長くなる場合は箇条書きを階層構造にして１つ１つの文章を短く保つようにします。また、構造化された文書は論理的に捉えやすくなると考えます。
文章を正しく書く
私が要求定義書や要件定義書を書く上で最も心がけている事です。これが一番難しいとは思いますがやはり日本という生活圏で活動する以上、標準的な正しい日本語の文章を書くことは大切です。
「5W1(2)H」や「漏れなく、ダブりなく（MECE）」あるいは「て、に、を、は」といったメソッド、フレームワークは良く耳にしますが、私は更にそこに「SVOC」の視点を加えます。
ある程度箇条書きで要件を記述したら次の観点で文章を見返して要件の曖昧さを排除し、一意性を保つようにします。
- SVOCの視点で主語、述語、目的語、あるいは補語と言った基本的な文書構造を備えているか
- 5W1(2)Hの不足がないか
例えば次の文章は主語（S）あるいは「誰が(W)」という要素が抜け落ちています。
「ユーザーに付与したポイントを通知する」
下記の文章は主語、更にWhen、Whereを補足した改善例です。
「システムは毎月1日にユーザーに付与したポイントをメールで通知する」
正しい文章でなければ読み手によって正しい意図が伝わらず一意性が損なわれます。また5W1(2)Hについて例えば「When」に関する記述がなければ、読み手によって「すぐに」なのか「1日後」なのか捉え方は十人十色です。
誰が読んでもそうとしか解釈できない一意性のある文章を書くことを心がけ、読み手によって解釈が異なるような文章は避けたいところです。
次に何をするか
後は追加ヒアリングをしたり文書を見直して文書を育てていきます。
- 業務要求を振り返る
- 機能要件と業務要求を関連付けします
- Whyが曖昧な場合はWhyを深掘りして業務要求を見つけます
- 紐づく業務要求が見つからない場合、その機能要件は本質的な問題、課題解決になっていない場合があります
- 非機能要件の抽出
- 機能要件が明確になって表面化する非機能要件を抽出します
おわりに
ここまでご覧いただいて「なんだ、そんな当たり前のこと知っているよ」と思う方もいらっしゃるかと思います。
それでも、私自身を含め次のことが出来ていない場合が往々にしてあります。
- 日本語の正しい文章を書く
- 一意性のある文章を書く
他の文書にも当てはまることですが、この点だけでも意識しながら書くことで要求定義書や要件定義書が大分良くなると思います。最初から完成度の高いものを目指さず、要求分析、要求開発に立ち戻るためのプロセスくらいに捉えて気負わずに書くスタンスで良いのではないでしょうか。
明日は慕狼ゆにさんによる「TypeScript使いがHaskellに入門した話」です。
ココナラでは積極的にエンジニアを採用しています。
採用情報はこちら。
カジュアル面談希望の方はこちら。
Discussion