要件定義は誰の責任か？あるいはプロとアマの分岐点

★システム構築の最初にして最大の難関
システム構築をする際の要件定義は難しい。一度決めたはずの要件が、プロジェクトが進むに従って何度も変更される。

要件はシステムの大もと（そもそも何を作りたいのか？）なので、要件が変われば、
設計書も書きなおし、
プログラムも書きなおし、
テストもやり直し、
マニュアルも書きなおし・・。
気づくのが下流工程になればなるほど、被害は大きくなる。

これほど重要な要件定義なのだが、実はシステム構築においては凄く中途半端な位置付けだ。

「要件を定義するのはユーザー（業務担当者の仕事）の仕事なので、システム開発者は要件定義の結果を受け取ればいい」
という建前論がある一方で、
「とは言っても、システムのプロじゃないんだから、ユーザーが正確で網羅的な要件定義は出来ない」という現実論がある。

その2つの見解のハザマに落っこちて、ただでさえ難しい要件定義が、ますます困難なものになっている。



★要件定義と設計は違う
言うまでもないことだが、要件とは
「手に入れるシステムがこんなふうであって欲しいな」
「これが出来るシステムであるべき」
ということである。

その要件がどうやって実装されているのかは、要件とは関係がない。それは設計の世界の話だ。
大事なところなので、住宅建築に例えてみよう。

要件：
・キッチンは明るい方がいい
・トイレは2ついらない
・風通しの良さが重要

設計：
・キッチンは2階に
・トイレは階段の下、階段3つ降りた所に作る
・階段の上に、常時開けておける小さい窓を作る

こう整理して書くと当たり前に見えるのだが、要件は家に住む人にしか言えない要望だ。トイレが2つあることが書斎よりも重要、という人も中にはいるだろうし、どっちが正しいという話ではない。

そして設計はどちらかと言うと、その道のプロの領域だ。キッチンを2階に設置することで、水回りの配管にどのような配慮が必要なのか・・といったことは専門家でなければ分からない。それらを全て踏まえた上で、ベストな配置を選びとる時に中途半端に素人が口を出すと、かえって悪くなることのほうが多い。
でも家を建てる時になればつい「キッチンは2階にあるのがいいな」と言ってしまうものだけれども。


聖書に「カエサルのものはカエサルに。神のものは神に」という言葉がある。本来の持ち主に返せ、という程度の意味だと思う。
同じ言い回しで表現すれば、こうなる。

「要件はお金を払うユーザーが。設計はプロのシステム開発者が」



業務担当者はシステムがどの様に実装されるかにアレコレ思い巡らすよりもまず、「自分が手に入れたいもの」を明確に表現することに全力を注いだほうがいい。

僕は家を建てたことがあるが、最初はこんな間取りがいいかな・・と小学生の落書きみたいなものを書いていた。だけどあまりに発想が貧困なので、すぐに馬鹿馬鹿しくなった。ド素人の自分が下手に考えて、設計する人にとって「制約」みたいなものになってしまうのは良くない。

それよりも「要件＝こんな家だったら嬉しいな」を色々な方法で設計者に伝えるのが、ユーザーである僕の仕事だ、と思い直した。
・自分たちがどんな人間か
・何が好きで何が嫌いか
・どんな生活をしているか
・家に何を望むか。MustとWant。
・欲しい家をCDアルバムに例えると？服に例えると？人に例えると？

「カエサルのものはカエサルに。神のものは神に」



★だが、要件定義はプロが仕切るべき

要件を話すのは、ユーザーにしか出来ない。
だが、ユーザーは業務のプロであって、要件定義のプロではない。だから世間でよくやられている様に
「要件定義書はユーザーさんが書いて下さい。僕らシステム開発者はその通りに作りますから」
は、無理な注文となる。

要件はユーザーにしか話せないが、話を引き出すのは要件定義というプロセスのプロが責任を持つべきだ。


ユーザーが要件を正しく定義するための工夫は沢山ある。

例えばベストプラクティスアプローチ。僕らケンブリッジは過去プロジェクトの蓄積として、各業務に必要であろう要件のリストを持っている。例えば人事業務で言えば、400行くらいになる。それをベースにすれば、ゼロからお客さんが全て語るよりもずっと早くて網羅的な洗い出しが出来る。

例えば、業務フローアプローチ。
将来業務フローを定義しながら、そこで使うシステム機能を一つ一つ明確にしていく。時間がかかるが、仕事とシステムの噛み合わせがとても良くなる。

他にも挙げていけばキリがないが、どちらにせよ「ユーザーの要件を引き出す責任」はその道のプロであるシステム開発者が持ったほうが、結果として上手くいく。

少なくとも「ユーザーさんが要件を出してくれないから、スケジュールが遅れまくりだよ」とか愚痴を言うよりは、僕は自ら責任持ってリードする方を選びたい。
「要件を出し切ることに責任を感じるかどうか？」で、プロフェッショナルなシステム開発者と、言われたことをやるだけの作業者に二分できるとさえ、思っている。
逆に言えば、「それはお客様のご判断ですから」と慇懃に言って判断を丸投げするシステム開発者があまりに多い事に憤りを感じる。コンサルタントを名乗っていても、そんな感じの人もいますからね。。



★ユーザーが語った要件が誤っている？
さらに言えば、プロジェクトの最初の頃にユーザーさんが「これがほしい」と言ったことが本当に正しいとも限らない。要件定義以降のフェーズでしつこくしつこく、それが正しいかを確認していく作業も、プロであるシステム開発者がリードすべきだ。
なぜなら、ほとんどのユーザーは要件定義がそれほど難しい事を知らないし、要件が誤っている時に対応しなければならないのは開発者の側だからだ。

僕らがやる場合は、プロトタイプを作って業務のシミュレーションをやることで、問題点を山ほど洗い出す。問題が沢山出れば当然ウンザリするが、後の工程になって表面化するよりは100倍マシだ。

そいう事をきちんとやらないで、「ユーザーさんが要件を変えるのが悪い」と言うのはプロ失格だと思う。だが、長くなったので業務シミュレーションの話は、いずれまた気が向いた時に。



まとめ
・要件と設計は別
・要件を語るのはユーザーの責任
・要件を引き出すのは開発者の責任