会議室に、また付箋が増えていた。
要件定義を始めて6週間。ホワイトボードは3枚目になり、Notionのページは階層が5段になっていた。「ここまで整理できている」という手応えがあった。毎週3時間の要件定義ミーティング。積み上がっていくドキュメント。進んでいる感覚があった。
ただ、一つだけ気になることがあった。開発がまだ始まっていないことだ。
開発会社からは「要件が固まったら教えてください」と言われている。
いつ固まるかは、まだわからない。
要件定義が長引く会社に共通するパターンがある。「決めようとするほど、決めなければいけないことが増える」という現象だ。
「この機能を入れる」と決めると、「ではこの機能とあの機能が重複する場合はどうするか」という問いが生まれる。それを決めると、「ではユーザーがこの順番で操作した場合は」という問いが生まれる。木の枝のように、問いが問いを生む。
一つ決めるたびに、未決事項が増えていく。
それでも止まれない。止まると「詰めが甘い」と思われる気がする。抜け漏れが怖い。開発が始まってから「やっぱりここを変えたい」となった時の費用を思うと、今のうちに全部決めておきたい。
その判断は、一見正しい。
ただ一つ、見落としていることがある。
要件定義をしている間も、時間は流れている。
3ヶ月かけて完璧な要件定義書を作り上げたとき、そこに書いてあるユーザー像は、3ヶ月前のユーザー像だ。競合が動いていたかもしれない。ユーザーの期待値が変わっていたかもしれない。市場の前提が、少しずつずれていたかもしれない。
完成した仕様書は、過去の判断の集積だ。
「早く作ればよかった」というのは、結果論ではない。
使ってみないと分からないことは、使ってみるまで分からない。どれだけ精密な要件定義書があっても、実物を触った瞬間に出てくる「なんか違う」は防げない。であれば、その「なんか違う」を早く引き出した方がいい。
荒削りでも動くものを触ってもらう。そこで出てきた「これじゃない」を次に活かす。このサイクルを早く回すほど、最終的に出来上がるものは要件定義書通りの完璧なものより、ずっとユーザーに近いものになる。
分かっていても、難しい。
作りかけのものを見せることへの抵抗は、思っているより根深い。「まだ完成していないから」「もう少し整えてから」。その感覚は真っ当に見えるが、実際は「完成していない状態を見せることへの恐怖」が形を変えたものであることが多い。
一度、今の要件定義を見直してほしい。
「これは開発を始めるために必要なことか」「それとも、開発を始めることへの不安を和らげるためにやっていることか」。
どちらが悪いとは言わない。ただ、両者は全然違う作業だ。
要件定義は、動き出すためにある。完璧にするためではなく、最初の一歩を踏み出すためにある。そこを間違えると、頑張れば頑張るほど、スタートが遠くなる。
「何を決めてから始めればいいか分からない」という相談が、ニチコマには多く来る。
そういう時にまずやることは、一緒に「今決めなくていいこと」を外すことだ。必要以上に決めようとしているものを取り除いていくと、大抵の場合、今週始められるくらいにはなる。
完璧な準備は、後からでもできる。
