川の流れに任されて流されてみるのはとても楽な事だ
それは行きつく先が思っている方向であれば尚楽しい
何処へ只りつくのか分からないなら冒険心で胸は膨らむかもしれない
しかしその行先が大きな滝壺へ進んでいるなら貴方はどうするだろう？
滝壺に突っ込んで天に運を任せるか？
無駄と分かっていても流れを変える様努力をするだろうか？

確かに自分が今いる場所が川の上であれば無力を知りこれも天の定だと諦め滝壺に落ちて身を砕くしかないだろう
結論から言えば川の流れに身を任せるのは行きつく先が楽しい結果と分かっている川を選び後は下ればいいのだ
つまりわざわざ滝壺が待っている川を選ぶ必要はないのだ

しかし開発業務に携わっていると滝壺へ一直線の案件が実に多いのだ
全てが軌道修正出来る訳でもないが仕事を依頼して来る方の仕事に対する胆識によりこの結果が変わる

Agileはまず要望からUser Storiesを幾重にも作りこつこつと骨組みを繰り返し要望を具現化するので滝壺へ流れつく心配はない

一方Agile以外の開発の出来不出来は最初の要件定義で決まる
実装を優先に後から要件定義をする現場もあるにはあるがその実装は地獄から奇跡的に戻れた後の顛末だったりする
なので要件定義というよりは実装と試験を終えた後にまとまった現行の機能用要件と言えるだろう
地獄から這い上がっているので落伍者も多数いる
大昔見た八甲田山の様なものだろうか（笑）

新規でも機能拡張でも要件定義の役割は開発要件を整理する事にある
整理された文書は次工程作業の地図となる
つまり地図をしっかり作る事で目的に辿り着くための手段が講じれるのだ
ところがこの要件定義が疎かになっている開発現場が多いのが実情だ

その多くの理由は要件定義そのものを知らない者達が陣頭指揮を執っている事にある
要件定義のやり方そのものを知らないとか工数削減のため開発Vendorなど他社に依頼するのは構わないがその手順ぐらいは知っておかないとVendorの手抜きを見抜く事も難しい

Vendor側でもEnd側でも今まで多くの要件定義に携わって来た
客先の要望をそのまま鵜呑みして業務分析調査もせず要件定義を終わらせるVendorも少なくない
そう言ったVendorが残す粕は次の行程で何をすればいいのかすら分からない
然し要望を出した側は要望書の通りに書いてあるのでそれで済んだと思ってしまう
何がしたいのか分からない地図を次の行程で受け取った開発者は地図のない宝探しに迷走する
宝探しの手始めにまた要望者に何がしたいのか？を確認する事になる
要望を聞いて設計書に起こそうと思ってもその指標が定まらないので実装という動作確認で結果良しとする
右往左往しながら様々な罠にはまる作業員もいるので途中落伍者は後を絶たない
自分達が通った足跡はあるがその足取りは不確かなものだったりする
結果から足取りを逆に辿り地図とするもその地図には歯抜けが多くなってしまう
これが所謂仕様漏れというものだ

要件定義の目的は開発要件をまとめ確かな地図として安全な冒険を保証する事にある
新規案件なら業務調査から業務要件と機能要件を分けていく作業になるし
機能拡張案件なら現行の業務と機能要件調査と要望事項の確認からその差分を整理していく作業になる
この最初の一歩で何がしたい？のかと何をすればいいのか？が定まる
後は滝壺へ行かない道順を整理して時には川の流れを堰き止める必要も出て来る

今自分達の開発が地図もない無謀な探検だと感じるのなら勇気を出して皆が安心して冒険できる地図を作ってみようじゃないか
そして地図に自分達の確かな足跡を残そうじゃないか