こんにちは、キノトロープアカデミーです。

「キノトロープアカデミー」は、Web業界のトップランナーである株式会社キノトロープの社員が講師を務めるオンラインアカデミーです。リモートワーク時代に不可欠な「個のスキル」を高め、職人のような「匠」を目指す人を増やしたい。そんな願いを込め、基礎から経営判断、業務フローまで、一生モノのナレッジを惜しみなく公開していきます。

＜初級編 第6回＞
Webサイト制作における要件定義とは
についてお伝えします。

担当は高橋です。

Webサイト制作やシステム開発を成功させるための最大の鍵、それが「要件定義」です。

開発プロジェクトにおいて、顧客が口頭で説明した要望と、本当に求めている理想の仕上がりが食い違ってしまうケースは珍しくありません。

このような致命的な認識のズレを最小限に抑え、クライアントと制作会社が同じゴールを共有するために要件定義は行われます。

お互いの理想を明確にまとめ、ドキュメントとして言語化していくこのプロセスこそが、プロジェクト全体の費用や期間を確定させ、スムーズな進行を支える重要な土台となるのです。

”Webサイト制作における要件定義”をテーマに、
今日お伝えしたいことは3つあります。

まず、これは怖い話をします。「顧客が本当に必要だったもの」についてです。

有名な風刺画で、知っている方も多いと思いますが、順番に見ていきます。

・【顧客が説明した要件】
木が３連になったブランコのようなものですね

・【プロジェクトリーダーの理解】
ブランコとして成り立たなそうなロープの
かけ方になっています

・【アナリストの設計】
ブランコがなりたたないということで、
強引にブランコが成り立つような設計
になっています

・【プログラマの実装】
アナリストの設計通りにプログラムできなかったので、木にロープがひっかかっているだけのような状況ですね

・【営業の表現】
いかにも過剰にすばらしいもののような表現
になっています

・【プロジェクトの書類】
なにも無し

・【顧客への請求金額】
とても高い

・【実際の運用】
・・・・・・

・【得られたサポート】
切り株程度

・
【顧客が本当に必要だったもの】
となっています。

途中経過もひどいので、どうしようもなさそうな状況ではありますが、
注目すべきは、
・顧客が説明した要件
・顧客が本当に必要だったもの
が異なることです。

Webサイトやシステム開発の行ったことがある人であれば、笑えて・そして笑えない絵だと思います。

何らかの『制作』を行う上では、程度の違いこそあれ、多少なりともこれに近いことを経験することにはなると思います。

「顧客が本当に必要だったもの」に近いものをプロジェクトリーダーの理解となっていれば、そのあとの設計や実装もうまく進められていた可能性もあります。

このような状況とならないために、認識のズレを最小化するために重要となってくるのが要件定義です。

はじめに、前提条件について話します。

「要件定義」の中で何をどこまで行うかも、『定義』によりますが、ここでは、前段としてRFPがあり、戦略策定が行われている前提とします。

Webサイト制作の流れ
RFP【提案依頼書】
提案【提案書】
戦略策定【戦略策定書】
要件定義【要件定義書】
設計・計画【各種設計書】
構築・テスト【サイト、テスト結果報告書】
運用【マニュアル】

そのため、要件定義書の中にもリニューアルの「目的」も記載は必要となりますが、「経営戦略や企業としてどうしていくか、課題はなにがあり、ある場合はどうなるかについて」戦略策定の中で実施する前提とします。

ここまでが前提でしたが、そのうえで、要件定義とは「Webサイト制作において、クライアント（発注元・顧客）の望んでいるサイトの実現方法をまとめ、明確化していく作業」です。

「定義」というとすでにクライアントの中に望んでいる明確なものがあって、それをまとめるイメージですが、実際にはクライアント自身も明確にすべての要件をもっているわけではなく、ヒアリングするだけで作成できるものではありません。

なお、要件定義をまとめた書類を
要件定義書（RDD / Requirement Definition Document/
business requirements document)と呼びます。

要件定義の目的は、クライアントとWeb制作会社の「認識のズレを最小化する」ことです。
ひいては、クライアント内、Web制作会社内でも認識のズレを最小化することができます。

なお、極論として認識のズレが発生しない場合、または発生した場合の影響が費用的にも、期間的にも無視できるレベルであれば、要件定義は不要といえます。

例えば、クライアントから全幅の信頼があり、費用と期間以外はすべておかませで好きなようにやってよい場合や、リニューアルの規模自体が極端に小さい場合は、実施する内容がすべて明確で見積書内に記載する前提条件レベルでも要件定義としても大きな問題はないとは思います。

しかし、当然Webサイトの構築やリニューアルとなると、このような場合はまずないので、やはり要件定義は必要となるでしょう。

また多くの場合、要件定義の内容確定をもって、その後の設計、開発工程の正式な見積もりが確定することにもなるため、費用・期間を確定させるということも目的に含まれます。

また、難しいところは書類だけがあればよいというものではなく、それがクライアントに伝わり認識されていなければ意味がありません。

契約としては、「ここに書いているので」と済ませられる可能性もありますが、クライアントは納得できない状態となり、プロジェクトとしてはうまくいかないことになります。

書類単体としてもわかりやすく理解できるように作成する必要はありますが、クライアント担当者の知識レベルや知っている業務の範囲も様々だったりするため、ひとつずつ内容を説明する機会が必要です。

要件定義はプロジェクト全体の運命を握っているといっても過言ではありません。ここでつまずいたり、十分な調整が行えないまま次のステップに進んだりしてしまうと、プロジェクトをスムーズに進行し完了させることは、まず不可能となるでしょう。

そのため、発注者側（クライアント）としても制作者側としても、要件定義でいかに認識のズレを最小化できるかがプロジェクトの鍵となります。

最後までご覧いただきありがとうございました。

の３点についての内容でした。