Webサイト制作プロジェクトにおいて、「こんなはずじゃなかった…」という失敗のほとんどは、プロジェクトの最上流である「要件定義」の失敗に起因します。
- 「作ったはいいが、誰も使えない機能が満載」
- 「開発終盤で『あれも必要だった』と追加要望が噴出する」
- 「見積もりと工数が膨れ上がり、予算が破綻する」
私自身、システムエンジニアであると同時に、Web制作会社で1,000件以上の案件ディレクターを経験してきました。その経験から断言できるのは、成功するプロジェクトは、要件定義が優れているという事実です。
この記事では、Webサイト制作を発注する側も、受注する側も知っておくべき、失敗を防ぐための実践的な要件定義の進め方と、陥りがちな「罠」について解説します。
要件定義とは？ 「要求」と「要件」の違い
まず、最も重要な違いを理解する必要があります。
- 要求（やりたいこと）: お客様の「夢」や「願望」です。「売上を2倍にしたい」「かっこいいデザインにしてほしい」といった、ふんわりとした目標を指します。
- 要件（やるべきこと）: その「夢」を実現するために、Webサイトが**具体的に何を（機能）、どのように（非機能）**備えるべきかを定義したものです。「売上2倍のため、カートシステムを導入し、会員ランク別クーポンを発行できるようにする」といった具体的な仕様を指します。
Webディレクターの仕事は、お客様の「要求」をヒアリングし、それを具体的な「要件」に落とし込み、合意することです。
失敗しない要件定義の進め方 3ステップ
Step 1: 「Must（必須）」と「Want（要望）」を仕分ける
ヒアリングで出てきた「要求」を、以下の2つに徹底的に仕分けます。
- Must（必須要件）: これがなければプロジェクトが成立しない、絶対に実現すべきこと。（例：商品をカートに入れて決済できること）
- Want（要望要件）: あれば嬉しいが、無くても運用は開始できること。（例：お気に入り機能、ポイントシステム）
多くのプロジェクトは、全ての「Want」を詰め込もうとして予算とスケジュールが破綻します。まずは「Must」だけで最小限（MVP：Minimum Viable Product）のスタートを切り、公開後に「Want」を追加していくフェーズ分けを提案することが、現実的な成功への近道です。
Step 2: 「機能要件」と「非機能要件」を洗い出す
「何を」作るかだけでなく、「どのように」動くかも定義します。
- 機能要件（目に見える機能）:
- 例：お問い合わせフォーム、ブログ投稿機能、会員登録・ログイン機能、決済機能など。
- 非機能要件（目に見えない品質）:
- 例：セキュリティ:（常時SSL化、管理者権限の分離）
- 例：パフォーマンス:（ページ表示速度が3秒以内であること）
- 例：運用・保守:（ブログの更新はクライアント自身が行えること）
- 例：利用者のITリテラシー:（PCが苦手な人でもスマホで簡単に更新できる管理画面にする）
特に「非機能要件」は見落とされがちですが、サイトの品質や運用コストに直結するため、非常に重要です。
Step 3: 「やらないこと」を明確に定義する
要件定義書には、「やること」だけでなく**「やらないこと（対象外スコープ）」**を明記することが、お互いを守るために不可欠です。
- 例：「レスポンシブ対応は含むが、ガラケー（フィーチャーフォン）対応は含まない」
- 例：「ブログ機能は実装するが、過去サイトからの記事データ移行は対象外とする」
- 例：「ロゴデータはクライアントから支給されるものとし、ロゴ制作は含まない」
これを事前に合意しておくことで、開発終盤での「これもやってくれると思った」というスコープのズレを防ぐことができます。
陥りがちな3つの罠と、その対策
罠1: 「担当者のITリテラシー」を見誤る罠
- 罠: 発注側の担当者がシステムに詳しい場合、現場の運用担当者（例：PCが苦手な事務員）のスキルを無視した「高機能すぎるシステム」を定義してしまうことがあります。
- 対策: 「誰が（Who）」そのシステムを「どのように（How）」使うのかを徹底的にヒアリングします。デモ画面（プロトタイプ）を作成し、実際に使う人に触ってもらいながらフィードバックを得ることが最強の対策です。
罠2: 「とりあえず全部盛り」の罠
- 罠: 「せっかくだから」と、使うかどうかわからない機能（ポイント機能、複雑な検索機能など）を最初から全て実装しようとして、予算と開発期間を浪費してしまう。
- 対策: Step 1の「Must/Want仕分け」を徹底します。プロジェクトの真の目的（例：まずは問い合わせを増やすこと）に立ち返り、「Want」機能は公開後のフェーズ2で検討することを提案します。
罠3: 「議事録・合意」を怠る罠
- 罠: 打ち合わせで「いい感じですね」と口頭で盛り上がっただけで、具体的な仕様書や議事録を残さない。後で「言った」「言わない」の水掛け論になる。
- 対策: 打ち合わせの決定事項は必ず議事録に残し、関係者全員にメールで共有します。最終的な要件定義書は、必ず両者が「合意した証拠（押印や合意メール）」を残してから開発に着手します。
(まとめ) Web制作における要件定義は、家を建てる際の「設計図」です。設計図が曖昧なまま着工すれば、欠陥住宅ができてしまうのは当然です。
優れたWebディレクターは、お客様の「夢」に共感しつつも、それを実現可能な「設計図」に冷静に落とし込む能力を持っています。
この記事が、あなたのWeb制作プロジェクトを成功に導く「ヒント」になれば幸いです。
コメント