1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

要件定義のドキュメントは「説明書」じゃない 〜あとで自分を助けるために書いている〜

1
Last updated at Posted at 2026-02-09

:point_up:はじめに

要件定義のドキュメントって、正直、書くのがしんどいですよね。

・時間がかかる
・誰がどこまで読むのか分からない
・書いたあとも修正が入る

それでも実務では、このドキュメントに何度も助けられる瞬間があります。
今回は自分が要件定義を書くときに意識しているスタンスについて書きます。

:sunflower:きれいに書こうとすると、だいたい失敗する

最初の頃は、

・漏れなく
・正確に
・きれいに

書こうとしていました。でもそうすると、

・手が止まる
・進まない
・結局、共有が遅れる

という状態になりがちでした。
要件定義は最初から完成させるものじゃない。
最近はそう割り切っています。

:sunflower:ドキュメントは「思考のログ」

今は要件定義のドキュメントを思考のログとして書いています。

・なぜそう考えたのか
・どこで迷ったのか
・何が未確定なのか

これを書いておくだけで、あとからのレビューや修正がかなり楽になります。

:sunflower:「決まっていないこと」を書いておく

意外と大事なのが、決まっていないことをちゃんと書くことです。

・保留中
・要確認
・仮置き

これが書いていないと、「決まっている前提」で話が進んでしまいます。
未確定を残すのは悪いことじゃなく、ズレを防ぐための保険だと思っています。

:sunflower:誰のために書いているか

要件定義のドキュメントは、顧客のためだけのものではありません。

・未来の自分
・後から入るメンバー
・レビューする人

こういう人たちが「状況を追えるかどうか」が大事です。

:writing_hand:まとめ

要件定義のドキュメントは、完璧な説明書である必要はありません。

・どう考えたか
・何が決まっていないか
・どこを注意してほしいか

これが分かるだけで、ドキュメントは一気に使えるものになります。
要件定義は書いた瞬間よりもあとで読み返したときに価値が出る工程と考えるようになってから、ドキュメントを書くことへの抵抗感はかなり減りました。

次回は『要件定義とスケジュール感のすり合わせ』について書く予定です。

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?