要件定義の進め方

システム開発の大炎上を防ぐために、上流工程(前工程)に位置する「要件定義」について、考えていくブログです。

要件定義書の作り方
PDCAサイクルではなく、PDCサイクルを回そう
あるべきV字モデルについて整理した
スコープを決めてから、QCDの議論をしよう

要件定義は誰がやるべきか

要件定義を誰がやるのか問題

要件定義を誰がやるのかという問題がある。この場合の誰が、というのは、顧客か開発ベンダーか、という意味である。

下記の記事で要件定義書の作り方を説明しているが、記事に記載の流れで要件定義書を作ろうとするならば、原則としては顧客がやるべきとなる。何を作りたいのかを要件として書くのが要件定義であって、何が作りたいのかは、当事者が1番よく知っているからだ。本来は顧客がやるべきだ。

req-definer.com

しかしながら、現実として、顧客側がしっかりとした要件定義書を作成できることは多くない。一品物であるシステムを初めてつくるのに、システムを作るための要件定義書を、いきなりうまく書けることはないであろう。

顧客はシステム開発のプロではないことのほうが多いのだ。プロではないのにプロらしく定義しろというのは、無謀な話である。家を立てる時、購入者はしっかり要件を提示するだろうか?そうではない。家を立てる場合は、ベンダーが暗黙的に要件を定義しているのだ。

要件定義は、顧客側/ベンダ側で実力のある者がやるべき

筆者の見解としては、顧客側/ベンダ側、どちらがやってもいいと考える。ただし、ベンダーがやる場合は、ベンダーに相応のお金が払われるべきだ。要件定義には時間がかかるし、要件定義できる人材は、会社にとって貴重な人材だ。その貴重な人材に作業させるのだから、顧客はそれ相応の対価を払う必要がある。

対価を支払う場合において、請負契約をしてはならない。要件定義書が成果物として検収できるかどうかの基準が極めてあいまいだからだ。顧客側の都合でなんか違うからといって作り直しをした場合、際限のない作り直しが発生する可能性がある。派遣でも出向でもよい。請負契約でない方法で要件定義作業をする必要がある。要件定義というのは、作業完了にどのくらいの時間や工数がかかるかわからないものだ。わからないなりに進めるために、要件定義としての合格基準を作り、顧客と会話した上で、どちらがやるか決めるのが良いと考える。

大切なのは、顧客側/ベンダ側双方の認識合わせ

要件定義はどちらがやってもよいのだが、大切なことは、要件定義の最終成果物について、お互いで読み合わせ、最終合意をとることだ。これをしておかないと、こんなんじゃなかった問題が発生する。認識を合わせながら進めるようにしよう。認識合わせをするための会議のやりかたを下記に記載しておく。

req-definer.com

お互いで認識を合わせ、良いものをつくこと。その意識が大切だ。

結論:要件定義は誰がやってもよいが、要件定義書の内容については顧客側とベンダ側で合意すること