要件定義書はどうやって作るのか？

こんにちは！

アットマーク・テクノロジー株式会社の酒井です

今回は、要件定義書をどうやって作るのか調べてみました。
私自身、要件定義書を作成した経験がないので、。
どういう流れで作成をするのか？であったり、
そもそも要件定義書自体は、顧客がやるべきなのか？それとも開発ベンダーがやるのか？
といったような疑問点があったりします

そこで今回は要件定義フェーズにおける「誰が要件定義書を作成するのか、責務はどうなるのか」とそれを踏まえて、学んだ内容を書き起こそうと思います！

要件定義はだれが行うのか？

要件定義は具体的に、下記の図のようなフェーズで行うのが一般的です。

ここで、要件定義を作成するのは「依頼をしようとするお客様」なのか「依頼を予定する開発ベンダー」なのかという疑問が生じます。

何をしたいのかを要件として書くのが要件定義書であり、
何をしたいのかは当事者が一番よく知っているため、原則として顧客がやるべき事項であると考えます。

しかし現実として顧客側がしっかりとした要件定義書を作成できることは多くないと思います。。
（私自身、何もない状態からどう作ればよいかがイメージとしてでてきませんでした）

顧客はその道のプロではない場合もあり、しっかりとした要件定義書を作れない可能性もあります。

「例えば家を建てる時に購入者はしっかりとして要件を提示するであろうか？」
この問いに関しては、家を建てる時は顧客と話し合いながら建築家が暗黙的に要件を定義しているのではと思います。

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

参考にしたブログにおいてこのようなことが書かれていたが、記事を読んでみて私も同様の意見であった。
前回の内容を基にすると、上流工程における要件定義はすべての土台となりこの土台の詰めが甘いと結局変なものが完成してしまうという事態が発生し、「人・モノ・カネ・時間」これが無駄になってしまうと考えた。
そのため、すべての土台となるものはしっかり作成を行わなければならないし、ミスも許されないと私自身も考える。

要件定義をベンダ側に依頼する場合は、請負契約をしてはならない
その理由として、要件定義書が成果物として納められるかどうかの基準が曖昧であるため。
そのため、派遣契約か出向で契約をする必要がある

要件定義は作業完了にどのくらいの時間や工数がかかるかわからないので、しっかりと合格基準を作り、顧客と会話したうえでどちらが作成をするかを決めたほうが良いと考える。

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

どちらがやったとしても、大切なのは要件定義の最終成果物について「お互いで読み合わせ、最終合意をとること」である。これをやっていなかったら、こんなんじゃなかった問題が発生してしまうので、認識を合わせながら進めるようにする（認識合わせはどの場面においてもとても重要）

「お互いで認識を合わせ、いいものを作ること」その意識が大切だと考えます。

要件定義のパターン分類とメリットデメリットの考察

パターンとしては3通りほどあります。

１．発注者側自身で要件定義する

一番理想的なパターン

自ら要件を定義し、業者を選定し、発注をかけることができる。
しかし先に述べた通り、要件定義のスキルが発注者側にない場合、
ゴールが曖昧なものとなってしまい、上流工程の礎となる土台が貧弱なものになってしまう可能性が大
したがい、このパターンが一番ではあるものの、極めて難しいものとなる。

２．ITコンサルタントに要件定義させる

要件定義のプロにまかせる

単価は高いがしっかりとしたものができる。
ただその分に見合ったものが納められるのも間違いはない。

３．設計ベンダに要件定義させる

ベンダーにおまかせ！なパターン

この方法はベンダーですべてコントロールができてしまう。
私自身も経験があるがベンダーが要件定義工程をやってしまうと、「いい加減なもの」になってしまうことがある。（プロジェクトの進捗が遅れてくるとこのような傾向が顕著になる）
本来要件定義フェーズで決めるべきことを先送りし内容をスカスカにしてスカスカな部分を設計工程で補うということがざらにある。このような細工をすると表向きとしてPJの進捗は順調で、要件定義も完了となるが、要件定義の内容は不足していることとなる。発注者側も依頼している立場側なので内容の薄さに疑問を呈することは少ない。

また参入障壁を高めるべく、当該設計業者しかわからないような内容にされたり、他業者が容易に参入できないようなシステム構成にされたりする。＝ベンダーロックインが発生してしまう

それぞれのパターンの図解

要件定義の作成を行ってみる

要望フェーズで明確にすること

①現状の洗い出し

• 業務プロセス
• 現状の問題点

②ゴール設定

本来あるべき状態、目指す状態

③現状とゴールのギャップを分析

解決すべき課題の洗い出し

④ヒアリング（現場、ユーザー）

システムに何を求めるか？

ポイント

ヒアリングの前段階で、
「何を目的としたプロジェクトなのか？達成したいゴールは何か？」といった
背景の目的を理解してもらうことがよい情報収集のポイント

要求フェーズで明確にすること

①開発目的のブラッシュアップ

• 達成するゴールを数値で明確化
• クリアすべき課題に分解

②ゴールの達成条件を明文化

• SMARTの法則に沿ってチェック

③開発後の業務フロー

• ビジネスフローとシステムの関係性

④システムに実装したいこと

• 機能一覧
• 非機能要求⇒非機能要求グレード2018

ポイント

要望フェーズで議論が発散したり、関係者どうしで意見が食い違うケースが多いので、それらを集約することがPMに求められる。

機能要件としては、農林水産省が公開しているハードウェア構成図こういったものが参考になります。

要求仕様としても同じく農林水産省が公開している、要求仕様が参考になります。