青い鳥はそこら中にいた、という話
要件定義とミチル
最近後輩が要件定義なるものに手を出していて、「えっ、早くね？」と、驚いています。
後輩のスキルが高いのは事実ですが、要件定義ってなまじっかスキルが高いとこっそりと炎上する可能性があって、非常にハラハラします。
あ、燃えた。
ということで、本日は開発の世界にある「要件定義」のお話です。
本当はもっと一般化できる話題なのですが、まぁ、今回はかなり（私がやってる）仕事の話に寄せてみました。
チルチルと要件
さて、開発の世界にある「要件定義」とはなんぞや、というお話から始めましょうか。
要件定義っていうのはユーザー（お客様）が考えている「こういうのがほしいなぁ」っていうのを「こういうこと？」って実現可能な形にまとめる作業です。
例えば、「なんか美味しいカレーが食べたい」って言うところからスタートしてみますね。
要件定義で行う作業は「美味しいカレーって、どんなもの？」って言うのを、お客様と、お店の間で合意する作業なんですね。
例えば「あんまり辛すぎても美味しくないよね」って話であれば、あんまりスパイスはバカスカ入れないほうが良いなぁ、って話になりますし。
「ジャガイモが入ってるカレーは日本的すぎて好きじゃない」って言う話であれば、具に何を入れるかを考えなおすことになります。
「シャバシャバなカレーってライスと絡まないから好きじゃないんだよね」って言われたら、まぁ、まずスープカレーは選択肢から外されますね。
こうやって、「どんな食材を使って、どんなカレーにするか？」を決めるのが要件定義です。
ここで重要なのは「本当にお客様が食べたいものは何か？」っていう「要求」を徹底的に調べ出すことにあります。
が、そんなもの、その要求をしっかりと言語化できるなら苦労しないんですよ。
料理に詳しくない限り、「美味しいカレーは何故美味しいのか？」を論じることはできません。
ところが料理に詳しくなくても、目の前のカレーが美味しいかどうかを判断することはできるんですね。
なので、非常に曖昧な「美味しいカレー」ってのをどうやって決めるか、がとっても重要です。
対話してどんどん理想の形を探る、的な。
青い鳥を探すという作業
さて。
「美味しいカレー」の定義がある程度できて、材料を買ってきて、カレーを作ったとしましょう。
ところが、なんか思ったより美味しくない。もう一声欲しい、ってことになってしまいました。
要件定義っていうのは、「お客様と料理人が相談して【美味しいカレーとは何か】を定義し、同意する作業」です。
で、同意の上で作ったカレーに対して、「いや、もうちょっと美味しくなるでしょ、おかしくね？」って言われるのは、何故なのでしょう。
火加減がまずかったのか？ ちょっとタマネギ入れすぎた？
そういう、「料理技術の問題」であれば料理人はキッチンで試行錯誤すれば何とかなりますね。
ところが、それでも何とかならない、なんてことがたまにあります。
この作業が意味することは、「話し合って決めたはずの【美味しいカレーの定義】が間違っている」ということです。
そう、ここから青い鳥を探す旅が始まります。
美味しいカレーとは何か、幸せとは何か。
そう、お客様（チルチル）と料理人（ミチル）はそれを追い求めて迷いの森へと入っていくのです。
青い鳥は何匹もいる
さて、たとえ話はここまでにして。
現実の要件定義においても、「他社から受信したテキストファイルをサーバへ取り込み、変換し、システムに伝票登録する」みたいな、すっごい一見単純そうな開発ですら、開発作業は衝撃的に難航します。
「ファイル取り込み機能と、それを変換する機能と、変換結果をそのまま登録する機能の三点セットで良いよね？」って話で開発を進めるのですが、
そのうち「なんかテキストファイルに誤りがあることがあるから、それを検知したらエラー発生のメールを担当者に送付する仕組みをつけて」とか言われます。
まぁここまでは、変換機能部分に入れれば良いので、特に困らないのですが。
それをOKして開発している時に「あ、エラーのリカバリは再度ファイル受信って言ってたけど、あれ勘違いだったわ」っていう衝撃的な勘違いから何もかもが瓦解していく、とか結構あります。*1
そもそも青い鳥（ユーザーが追い求める幸せ）っていうのは、そもそもユーザーの数だけあるし、仮にアンケートをとっても、大半のユーザーはまだ実感がわかないから適当な返事してくるんですよね。
そのシステムを頻繁に使うはずの、「ベテランだけど、職位がそこまで高くない（外部との連絡を取らない）人」の声が最初の要件定義には含まれてないことが非常に多いんです。
最初のカレーの例であれば、この「美味しいカレーの定義」をする人は実際にカレーを食べる人じゃなくて「カレーを食べる会の幹事を任された人」に過ぎないってことね。
なので、実際にカレーを食べる人たちがいざ食べて「なんか違う」ってなっちゃうんです。
と言うことで、迷いの森に入り込んだチルチルとミチルは、ここでようやく、予想以上に大量にいる青い鳥に愕然とするハメになるんですね。
要件定義って結局何なの？
絶対要件定義って、後になったらブレるんです。
会議なんかでも、「後からユーザーの要求を見つけていくこと」にこそ意義を見出している人がすごい多いんですよ。
「後から例外を見つけたヤツがかっこいい」みたいな風潮で。そんなもん、事前に見つけた方がもっとかっこいいんだからもっと前から本気で考えとけよ、と思うんですけど。*2
そうやってどんどん見つかる後から見つけた問題を改善するにしても予算は動かせないから残業でカバーみたいなザマになるので、自衛として、「要件定義で決めるとはどういうことか？」をちゃんと定義しなくちゃいけません。
つまり「要件定義フェイズってそもそもなにをするハズなの？」って話ですね。
大体この２つのどっちかでしょうか。
- 先に鳥かごに目一杯青い鳥（要件）を詰め込んで、後から見つかった青い鳥（追加要件）は無視する
- 鳥かごの大きさ（ユーザーの要求を満たせる限界）を決めることを要件定義にして、青い鳥（実際の要件）は後からかき集めるようにする
一つ目の方法は上に書いてあるようなやり方なんですけど、事前に徹底的に話し合って、「この範囲外のものはすべて追加請求します」って言う方法ですね。
あんまりこれで上手く行ったことがないんですけど、事前にいろんなユーザーに会うチャンスがもらえるならこの方法が良いと思います。
そもそも要件定義のポイントは、「どれだけの要望を引っ張り出せるか？」ってことで、それは一人の人から沢山ではなくて、沢山の人から少しずつ、っていうのが理想です。
一人の人から沢山貰うと、優先順位があまり高くない部分が要件に含まれちゃうので、実際に使っているいろんな人の声から、「声が多かったものから順に入れる」のが良いわけですね。
ところが、「いろんな人から声をもらう」ためにはその人たちみんなが「普段の仕事を止めて、アンケートに答えたくなる状況」にしなくてはいけないんですね。
だからいろんなユーザーの声が上がってくるのって、実際に完成直前になってデモを見せたりしてる時なんですよ。
いろんなユーザーの声をかき集めるためには、「デモを行うタイミングをどこまで早くできるか？」と「デモを行なってから導入までの間に長い時間を設けて問題ないか？」の二つをしっかりと話し合う必要があります。
そうすれば、一旦作ったあと、心に余裕を持って「青い鳥探し」に出かけることができるんですね。
ちなみに、後者の手段としてはアジャイルだとかプロトタイプを作っていくとかが重要なのですが、アレをやると無条件で工数が減るって言う誤解があって困ります……
