ホームページリニューアルの最重要工程「要件定義」を理解する
初版公開日：2019/5/11
最終更新日：2019/5/11
こんにちは。
WEB制作会社と事業会社にて制作側と発注側の両方の経験を合計12年以上、WEB担当（ディレクター・エンジニア・SEOコンサル）として中小企業から大手企業まで幅広いクライアントのWEBにおける課題解決をお手伝いしてきました竹内と申します。
この記事のテーマでもある要件定義にもたくさん携わってきました。
この記事の目標は、要件定義とはどういったものなのかとその重要性を理解していただき、制作パートナーに言われるがままになるのではなく、発注側が能動的に関わって行けるようになれることです。
要件定義という言葉には狭義のものから広義のものまで様々ありますが、RFP（提案依頼書）にまとめた内容もまた要件定義の一部と言えます。
ここではサイトの制作工程における「どんなサイトにするのかを決める（定義する）」という範囲に限った要件定義について解説します。
要件定義とは？
要件定義とは、WEBサイトやシステムの開発において必要なページや機能、満たすべき条件などを明確にしていくことです。
WEBサイト制作で言えば、どのようなページやシステムが必要であるるかと、そのページやシステムがユーザーに何をもたらせられればいいかを定義することになります。
具体的には以下のような内容を決めて行きます。
- サイト要件
- サイトマップ制作・ターゲット（ブラウザ・デバイス・ユーザー）設定
- ページ要件
- 情報設計・導線設計・画面設計
- システム要件（機能要件）
- 機能定義・基本設計・詳細設計・DB設計
- 非機能要件
- ユーザビリティ要件・アクセシビリティ要件・セキュリティ要件・品質要件・拡張性要件・運用要件・保守要件・移行性要件
- 技術要件
- インフラ要件（サーバー・ドメイン・SSL・環境構築）・言語・フレームワーク
パッと見て何がなんだかわからなくても大丈夫です。安心してください。
これらを主体的にやるのは制作パートナー側になります。
発注側は出てきた成果物や質問事項などを確認し、返答や意思決定をして行くのが仕事になります。
要件定義を失敗しないためのポイント
要件定義が始まる頃になるとプロジェクトが進んでいる感が出てくるでしょう。
特に制作パートナーが優秀であればあるほど、少しやり取りをしただけで色々なことが決まって行き、理解が追い付く前に進んでしまうこともあるかもしれません。
そうなると理想と違うサイトが生まれかねません。
そうならないためにも、いくつかのポイントに気を付けて要件定義を進める（進めてもらう）ようにしましょう。
可能な限り早く返答を行う
要件定義フェーズは想像よりも遥かに多くの意思決定が必要になります。
よい提案の選び方。または内部統率、決裁フローの重要性についてにも書きましたが、意思決定が必要となる度に社内ミーティングを開いていたり、全員の同意を得ていては遅延するばかりです。
遅延は百害あって一利なしです。
わからないことはわからないと伝えて説明を求める
「AとBどちらがよいですか？」と聞かれても判断できないこともあるでしょう。
AもBも何のことなのかわからない場合や、AとBはわかるけどその違いがわからない場合など様々ありますが、そういった場合は素直に聞いてみましょう。
ちょっとした自尊心や見栄を捨てるだけでプロジェクトの成功率があがります。
また、一度素直に聞くことができれば制作パートナー側も「これで理解できるかな？」という姿勢で確認をしてくれることでしょう。
「Aは○○ですが●●なところがあります。Bは△△ですが▲▲な点が問題があります。私たちとしてはAの方がおすすめですが・・・」という文脈で質問をしてもらえるようになれば意思決定もしやすくなってくると思います。
要求を要件に落とし込んでもらう
発注側から出る要望は要求であって要件とは少し違います。
例えば「スマートフォンでもちゃんと見られるサイトにしたい」という要求は要件にすると「iPhone8以上/iOSX.X以上/Android7.0以上・画面サイズは～」という決め事になります。
曖昧なものは定義とは言えませんので、誰が見ても同じ条件と読めるようにしてもらいましょう。
また、その要求自体が事前に提示した目的とリンクしているかも非常に重要なポイントとなります。
事前に準備した目的やターゲット、課題などと全く結びつかない要望は制作パートナー側からも却下してもらえるとよいでしょう。
自分たちの要望を疑ってもらう
人は無意識に嘘をつくことがあります。
水汲み場まで往復2時間かかる集落の人が「井戸が欲しい」と言うのは真っ当な要望に聞こえますが、本当に村人が欲しいのは井戸ではなく水なのです。
そのことに村人自身は気がついていないことがあります。
自分たちがこうしたいと思っている要望が間違っている可能性を疑い、本当に必要な要件をまとめてもらいましょう。
井戸を作っても水が出なければ意味がありませんし、毎日必要なだけの水を運ぶインフラの整備の方が簡単かもしれません。
知識がなければ判断できない項目は任せる
もともとプログラマーだった人などでなければ、システムの機能要件、特に詳細な設計部分までレビューをするのは難しいでしょう。
そこまで細かいことを訊いてくるパートナーも少ないとは思いますが、任せられる部分は任せましょう。
- 他の選択肢はあるのか
- その選択肢のメリット
- その選択肢のデメリット
- その選択をした場合のリスク
- 一般的にはどれが一番選ばれているか
- 他の選択肢を選ぶのはどんな場合か
- 制作パートナーとしてはどちらがおすすめか
- 担当者の個人的な意見としてはどちらがおすすめか
- 将来的にどちらの選択肢が妥当となりそうか
詳細はわからなくても、こういった項目を説明してもらえれば判断が可能になると思います。
制作側からみても「正直どちらでも大差はないけれど、一応顧客の意思決定を仰がなければならない」という確認項目は多かったりします。
出来る限り時間を使って担当者とコミュニケーションをとる
要件定義が終わってデザインなどが始まると、アウトプットされたものに対する良し悪しをチェックすることが多くなり、必然的に担当者とのコミュニケーションが減ります。
実は要件定義の最中が一番担当者とコミュニケーションの時間を多くとれる一番のチャンスなのです。
自分たちの細かな要望や熱量が伝わっているか、何か漏れなどはないか、小さなことまで汲み取ってくれているか、そういった視点を持って対応すると後の工程で何かあったときも意思の疎通がしやすくなるでしょう。
優先度をつける（やらないことを決める）
すべての要望が要件に落とし込まれると最終的な見積りが出ます。
すべての要件が予算内に収まればいいですが、大抵の場合そうはいかないものです。
そうなるといくつかのページや機能を削ったり、要件の一部を変更したりする必要があります。
どれを止めるかの判断は非常に難しいですが、目的達成の関与率が低いと思われるものから削って行きましょう。
かならずドキュメントに落としてもらう
後で揉めるプロジェクトにはいくつか決まった特長がありますが、炎上すると必ず出てくるのが言った言わないの水掛け論です。
- こういうページがあると思っていてた
- こんな機能があると思っていた
- こんなイメージじゃなかった
- この範囲まで対応してもらえると思ってた
- AがあるならBもあると思っていた
こういった認識の齟齬はどれだけ慎重にプロジェクトを進めていても少しは出てしまうものです。
致命的な要件で起こらなければリカバリーも可能ですが、要件定義が甘いと重要な箇所で起こる可能性が高まります。
それを防ぐためには、ミーティングやメール、電話などで決められたことは必ず文書（要件定義書）にして共有し、お互いに同意することが大切です。
議事録に残っているというのでも弱いです。
必ず議事録から要件定義書に記載されるところまで確認しましょう。
あとから要件漏れに気がついたら1秒でも早く共有する
完璧に抜け漏れがない状態の要件定義書を完成させるのはとても難しいことです。
これは誰も完璧な状態というのがわからないので、漏れがあるかどうか気がつき難いからです。
時間が許す限り何度も要件定義書をはじめとしたドキュメント類を読み返し、サイトの完成像をイメージするしかありません。
そして抜け漏れや確認漏れを見つけたら直ぐに担当者に共有しましょう。
「これが追加になったら費用も追加になってしまうかな。このまま黙っていたら気がついてサービスで実装してくれたりしないかな」と悪い声が囁くのは理解できますが、そうは都合よく行きません。
後になれば後になるほど悪い方に転がりますので、先延ばしはしないようにしましょう。
要件定義が終わったら最終見積りが可能になる
サイトの規模にもよりますが、要件定義だけで一ヶ月を費やすことも多々あります。
そして驚くことに、この要件定義を終えて作るものが概ね見えてきた段階で初めて金額のブレが少ない詳細な見積りが可能になります。
その費用は概算からかけ離れた金額になることも珍しくありません。
制作側も可能な限り概算と本見積に差が出ないように概算の精度を上げようとはしますが「スマートフォンの対応は必要ない予定だったけれど要件定義をやってみたら必要なことがわかった」といったことがあると直ぐに崩壊します。
これほどわかりやすく「無」だった要件が要件定義で「有」になることは少ないかもしれませんが、小さい要件でこれらが積み重なると2倍にも3倍にもなる可能性は充分あります。
後で見積り金額があがると高額に見えるので概算の時点で高額な見積りを出すようにしている会社もあれば、選ばれるために最初は安く見せようとオリエンテーションの内容をミニマムで実装するためだけの安価な見積りを出す会社もあります。
前者であれば概算よりも安くなっているので見栄えは良いですが、後者の場合はとても困るでしょう。
もしも要件定義だけではなく制作工程の発注までを約束していたとしたら想定よりも高い予算でその会社に発注することになってしまいます。
同じだけの金額を出すのなら前者の会社の方がよかったということになりかねません。
もしも安いからという理由だけでその会社への発注を決めたのだとしたら本末転倒となってしまいますので気をつけましょう。
サイト内では何回か出てきますが、おすすめは要件定義までと制作工程以降の契約を分けることです。
まとめ
サイトの要件定義は制作パートナーと望む最初にして最重要な工程です。
準備が8割などとよく言いますが、制作工程がスムーズに進むかどうかは要件定義の精度が大きく関わります。
制作工程に入ってしまえば制作パートナーが主に作業を行うのであなたの業務量は少し落ち着きますので、ここが踏ん張り時と捉え、要件定義に最大限のパワーを割くことができれば、プロジェクトの成功確率はグッと高まるでしょう。
もしも要件定義に不安などがございましたら、是非、ホームページリニューアルカウンセリングをご検討いただき、お問い合わせください。