要件定義を誰がやるのか問題
要件定義を誰がやるのかという問題がある。この場合の誰が、というのは、顧客か開発ベンダーか、という意味である。
下記の記事で要件定義書の作り方を説明しているが、記事に記載の流れで要件定義書を作ろうとするならば、原則としては顧客がやるべきとなる。何を作りたいのかを要件として書くのが要件定義であって、何が作りたいのかは、当事者が1番よく知っているからだ。本来は顧客がやるべきだ。
しかしながら、現実として、顧客側がしっかりとした要件定義書を作成できることは多くない。一品物であるシステムを初めてつくるのに、システムを作るための要件定義書を、いきなりうまく書けることはないであろう。
顧客はシステム開発のプロではないことのほうが多いのだ。プロではないのにプロらしく定義しろというのは、無謀な話である。家を立てる時、購入者はしっかり要件を提示するだろうか？そうではない。家を立てる場合は、ベンダーが暗黙的に要件を定義しているのだ。
要件定義は、顧客側/ベンダ側で実力のある者がやるべき
筆者の見解としては、顧客側/ベンダ側、どちらがやってもいいと考える。ただし、ベンダーがやる場合は、ベンダーに相応のお金が払われるべきだ。要件定義には時間がかかるし、要件定義できる人材は、会社にとって貴重な人材だ。その貴重な人材に作業させるのだから、顧客はそれ相応の対価を払う必要がある。
[補足1]要件定義で、どこまで書くべきか？という点については、下記記事を参照されたい。なぜ要件定義が難しいのかというと、システムを導入する側が、解決しなければならない課題を整理し、ある程度、システムの振る舞いについて言及しなければならないから難しいのだ。これは、ビジネスの分析をする能力と、システムを具現化する能力の両方必要されることを意味している。だからこそ、要件定義というのは難しいのだ。
[補足2]また、下記記事でも言及しているが、要件定義書の内容が、システム設計成果物に盛り込まれていく。要件定義書の記載が良くないと、それ以降の設計も、ぐだぐだになってしまうのだ。そういう面でも、要件定義書というのは、しっかり作成されなければならないし、ミスも許されないものなのだ。
さて、対価を支払う場合において、請負契約をしてはならない。要件定義書が成果物として検収できるかどうかの基準が極めてあいまいだからだ。顧客側の都合でなんか違うからといって作り直しをした場合、際限のない作り直しが発生する可能性がある。派遣でも出向でもよい。請負契約でない方法で要件定義作業をする必要がある。要件定義というのは、作業完了にどのくらいの時間や工数がかかるかわからないものだ。わからないなりに進めるために、要件定義としての合格基準を作り、顧客と会話した上で、どちらがやるか決めるのが良いと考える。
大切なのは、顧客側/ベンダ側双方の認識合わせ
要件定義はどちらがやってもよいのだが、大切なことは、要件定義の最終成果物について、お互いで読み合わせ、最終合意をとることだ。これをしておかないと、こんなんじゃなかった問題が発生する。認識を合わせながら進めるようにしよう。認識合わせをするための会議のやりかたを下記に記載しておく。
お互いで認識を合わせ、良いものをつくこと。その意識が大切だ。
追記：要件定義のパターン分類とメリットデメリット考察
筆者は、要件定義を誰がやってもいいというスタンスだが、改めて、要件定義を誰がやるかをといパターンで分けた場合のメリデメを整理したい。パターンについては、大まかに3つのパターンに分けることができる。
パターン①：発注側自身で要件定義する
パターン②：ITコンサルタントに要件定義させる
パターン③：設計ベンダに要件定義させる
パターン①：発注側自身で要件定義する
このパターンは、あるべきパターンであり、将来的に目指したいパターンだ。自ら要件を定義し、業者を選定し、発注をかけるというのは、理想的な姿だ。しかしながら、要件定義のスキルがない者が要件定義してしまうと、大変なことになる。そもそもの要件定義の内容が曖昧で、何を作ればいいのかわからない場合や、問題の分析が甘く、開発終盤で要件を際限なく変更してしまう場合など、開発を炎上させるリスクは満載だ。要件定義書の内容にゴーサインを出すのは発注者自身なので、客観的に見てひどい内容の要件定義書であったとしても、ゴーサインが出てしまう場合があるのだ。したがって、このパターンが理想的ではあるものの、ちゃんとした要件定義をすることは、極めて難しい。
パターン②：ITコンサルタントに要件定義させる
このパターンは、要件定義のプロであるITコンサルタントに任せるというパターンだ。ITコンサルは、企業の問題をITで解決することを生業としているので、それなりのスキルを保有している。ただし、非常に高額になる場合がある。月単価300万ぐらいは覚悟したほうが良い。Itコンサルはプロパ社員ではないので、知識ゼロからのスタートとなる。投入直後、とにかく社内の情報を集め、問題を分析し、解くべき課題を明確化していく。泥臭い、大変な仕事だ。土日も関係なく働く、というようなことが往々にある。そういった苦労によりもたらさせる成果物は、ある程度の代物となる。人二人分働かせるようなものなので、金額はべらぼうに高い。
パターン③：設計ベンダに要件定義させる
このパターンは、要件定義からシステムリリースまでを、設計業者でやっていくというパターンだ。要は、丸投げパターンだ。要件定義を設計業者がやるので、要件定義工程がおざなりになることがある。プロジェクトの進捗が遅れてくると、このような傾向が顕著になる。本来要件定義フェーズで決めるべきことを、先送りし、要件定義書の内容をスカスカにして、スカスカな部分を設計工程で補うのだ。このような細工をすると、表向きとしてプロジェクトの進捗は順調で、要件定義も完了となるのだが、要件定義書の内容は不足していることとなる。発注側もプロではないので、要件定義書の内容の薄さに気づくことはない。
また、参入障壁を高めるべく、当該設計業者しかわからないような内容にされたり、他業者が容易に参入できないようなシステム構成にされたりする。設計委託先が100％子会社なら問題はないかもしれないが、資本関係のない会社が設計委託先であった場合は、参入障壁の高さを利用して、高い設計開発費をふっかけられる可能性があるので注意したい。
それぞれのパターンを比較した結果
上の表に、それぞれのパターンを比較した結果を示す。観点は、
①要件定義書の品質
②ベンダーロックインの可能性
③設計業者との認識齟齬発生懸念
④要件定義書の作成にかかるコスト
⑤丸投げ体質を助長させるリスク
だ。
①要件定義書の品質
この点に関しては、ITコンサルの品質が良い。餅は餅屋の世界だ。設計業者の書く要件定義書というのは、個人的な感想であるが、そんなに良くないように思える。筆者もいくつかそのような要件定義書を見てきたが、詰めの甘さが目立つのだ。もちろんそうでないものもあるが、「要件定義を生業」としている業者の成果物のほうが品質は良い。
②ベンダーロックインの可能性
設計業者に要件定義させると、ベンダーロックインの可能性は、非常に高まる。この点は非常に気をつけるべきところだ。システムがある程度進んだ段位で、もうどうしようもなくなる、というパターンは起こりうる。要件定義書も大したことが記載されておらず、システムリプレースをするにも、改修するにも、何をどうすれば良いのかわからないという事態だ。ひどいのは設計書すらない場合で、プログラムを書いた人しかわからないという場合もある。システムを改修するにも、なぜこうなっているかわからないし、どうやって変えればいいかもわからない。結局、当時の知見者に聞くとしかなくなる。そうなったら、高いお金を払ってシステムをメンテナンスし続けてもらうしかないのだ。
③設計業者との認識齟齬の可能性
(要件定義スキルが低い場合)自分達で要件定義する場合は、認識齟齬発生の可能性は高い。ITコンサルに任せた場合は、その可能性を低くすることができる。素人とプロの違いは、この認識齟齬の可能性を排除する活動をしているかだ。要件をどう解釈し、どう実現するかは、設計側に聞かないとわからない。ちゃんと設計側に聞いて、認識齟齬を排除していく必要がある。パターン③においては、認識齟齬の可能性は低い。
④要件定義書の作成にかかるコスト
これは、ITコンサルに書かせると、べらぼうに高い金額になることはある。逆に、設計業者に任せるときは、安くなることがある。中身をスカスカにして次の工程に行くことがあるからだ。永続的に顧客からお金を搾り取るには、要件定義書を薄くして、設計業者にしかわからないようにしてしまえばよいのだ。発注側も要件定義のプロではないので、これが要件定義書だと言われれば、そうか、となってしまう。要件定義書の良品基準は、経験者しかわからないのだ。
⑤丸投げ体質を助長させるリスク
設計業者に任せるパターンが、最も高リスクだ。要件定義工程から設計業者に任せ続けると、考えるということを放棄し、なんとなくやっといてと言うだけになってしまう。ITコンサルに任せるパターンも丸投げではあるものの、設計業者は別業者になりうるので、緊張感を持って要件定義することとなる。丸投げとはいえ、最終成果物のハンコは発注側で押さねばならない。
見解
筆者の見解としては、自社で要件定義をするべきという見解だ。が、それができる実力がないならば、ITコンサル活用を検討すべきだ。受注ありきで、設計業者に任せるのもありだが、それ相応の対価はどこかで請求されることを気にしておいた方が良い。
結論
要件定義は誰がやってもよいが、要件定義書の内容については顧客側とベンダ側で合意すること
