要件定義基礎編 -要件定義をする人と作る人が違う場合はどうするの？-

2020年11月11日 21:24

前回の記事では、要件定義の概要を説明してきました。
https://note.com/ank_direction/n/n35bd5b36f7a3

今回はもう少し踏み込んだ部分について、例示を交えつつ説明していきます。

■ 「受注者」の中でヒアリングをする人、と実際に作る人が違う場合

実際の開発現場では、要件定義はディレクターやプロデューサーが担当することが多いです。
実際に受注者とのMTGにディレクターが参加して、要件をヒアリングできても、実際にWebサイトやアプリケーションを作るのはデザイナーやエンジニアです。

物を作ってもらう人たちにも正確に要件を伝える必要があります。

発注者からのヒアリングがうまく出来て、その場ではイメージの共有ができても
実際に作業をしてくれる人にまでイメージの共有ができないと意味がありません。
言葉で説明してもなかなかイメージが伝わりづらいかと思うので、またレストランを例に見てみましょう。

今度は「お客様」からヒアリングをするのは「コック長」、実際に料理を作るのは「料理人」という関係性になります。
開発の現場に置き換えると、
コック長 = プロデューサー、ディレクター
料理人 = デザイナー、エンジニア
ととらえていただければOKです。

コック長は、お客様が食べたいものは「甘口の卵焼き」ということを理解していても、それを料理人に伝えるときに、認識齟齬が生まれてしまっています。
例えば…
・焼く前に使う油はサラダ油なのか、バターなのか
・しっかりと焼くのか、半熟に焼くのか
・甘いといっても甘さは控えめなのか、ガッツリと甘めなのか

コック長の中にイメージがあったとしても、料理人と完成系の共有がうまく出来ていないパターンです。
（このような細かい部分をWebやアプリ制作では「仕様」なんて呼んだりしますが、そこはまた追って詳しく説明しますね）

要件定義をする際は、作業をしてくれる人の制作内容を明確にし、発注者、受注者、作業者の意思の統一を図ることが重要です。

先ほどのような認識齟齬をなくすために、要件定義では「ドキュメント化」が重要になります。
仮にディレクションをする立場の人が、作業者に口頭で「要件」を伝えても
そこで認識齟齬が生じてしまうことが多々あります。

ドキュメントにしっかりと「要件」を残すことによって、以下のような利点があります。

・発注者はどのようなものができるのか、イメージができる
・作業者はどのようなものを作ればよいのかイメージができる

そのため。発注者が意図しないものが出てくる可能性が少なくなります。
つまり、要件定義とは「誰が見ても納得ができるレシピ」のようにイメージしていただければと思います。

またレストランの例を見てみましょう。

コック長はお客様との「合意」をとり、「レシピ」を用意することで認識の齟齬がなくなりました。

・実際の現場では、ヒアリングをする人と実際にものを作る人が異なる場合がほとんど

・ディレクターがヒアリングをして完成系のイメージができたとしても、それをエンジニアやデザイナーにイメージの共有をしなくては意味がない

・イメージの共有や、受注者との同意形成のためにドキュメントの作成が重要