現役WEBディレクターが解説！例題と見るWEBサイト制作の要件定義について（ウォーターフォール開発）

今回は、現役WEBディレクターの要件定義について、実務に沿いながらお伝えしていこうと思います。

この記事の内容については、あくまでウォーターフォール開発の一例として、お楽しみください。

これからWEBディレクターを目指したいけど、WEBディレクターって何してるの？って疑問がある方も、要件定義って言葉は聞いたことあるけど、実際になにをするのか不安な方は是非見ていってください。

これから制作会社に案件を依頼したいという方も参考になるかと思います。

要件定義とは【ウォーターフォールの場合】

まず初めに、要件定義について確認です。

私はウォーターフォールでの開発しか経験がないので、ウォーターフォールの場合としてお聞きくださいね。

※開発手法にはウォーターフォール、アジャイル、スクラムなどがあり、ウォーターフォール開発は一度開発をしたら仕様のあと戻りはしない前提で、常に仕様を確定させながら進める開発手法です。

要件定義とは、WEBサイト、ソフトウェア、システム開発の上流工程にあたります。デザインレイアウトやシステム仕様の確定などをおこなうフェーズです。

私の場合、開発におけるフェーズ分けの認識としては、

• 要件定義フェーズ(デザイン、設計、コーディング)
• 開発フェーズ(PHP等を用いたバックエンド開発)
• テスト
• データ投入
• 納品
• クライアントテスト
• リリース

といった具合に進めていくことが多いです。
これは会社や個人によって違うかもしれません。

実際、要件定義ってどんなことするの？

要件定義は、WEBディレクターとクライアントの制作担当者との間での会議で、対面で行われることが多いです。

大体の期間を大まかに分けると、

・小規模案件（3～4か月で完成の規模）だと週に1回、2～3時間くらいの会議を4回くらい目安

・大規模（6か月以上で完成）だと週に1回、3～4時間くらいの会議を5～12回くらい目安

※Wordpressで作るかなり小規模な案件の場合、要件定義自体省略して、メールでやり取りすることもあります。

要件定義に入る際、プレゼン提案時のクライアントのやりたい事が、今やろうとしてることと本当に合致しているかをもう一度確認します。

ここで齟齬がある場合もあるし、お話を進めるうえで、やっぱりこの機能いらないとか、あの機能を搭載したいみたいな話は必ず出てきます。

仕様の変更があり、当初の見積もりから金額が変わる場合は、再度お見積もり(フィット&ギャップ)を提出して金額及び仕様を確定させます。

仮プロジェクトを参考に、要件定義について解説

上のようなプロジェクトの場合、
要件定義では、こんなことを確認します。

• スケジュールの再確認
  営業の時に聞いてたスケジュールにはまるのか確認します。難しいようであれば、フェーズを切り分けて提案します。開発をフェーズ１、フェーズ２に切り分けて完成を目指す提案もあります。
  
• 設計
  • 製品のカテゴリ数、商品数を確認
    カテゴリと商品の紐づけを設計に反映させるので、確認します。
  • データ投入の方法（CSV有無）
    製品点数が膨大だと、人の手でひとつひとつ情報を投入することができないこともありますので、CSVインポートするための項目だったりを決めていきます。
  • 動画配信の方法
    自社サーバーに大量の動画データをもつのはおススメしないので、YoutubeやVimeんみたいな動画配信サービスとの連携を提案します。
  • 店舗管理のやり方（どこまで店舗側で更新させるか）
    店舗の権限をどこまで制御するかを決めます。A店舗はB店舗の内容を更新できないようにするみたいなことです。
  • ブログや店舗管理する際の項目決め
    管理画面から、どんな項目を入力、必須項目にするかを決めます。
  • お問い合わせフォームの数、お問い合わせデータのDB管理
    お客様からの問い合わせデータはＤＢで保持する必要があるか、確認メールの配信先(cc,bcc)などの確認です。
• デザイン
  • ワイヤーフレーム
    レイアウトの土台になるように作成します。
  • レイアウト
    私の場合は、テンプレートを使わないで、デザインを1から制作していくので一番時間がかかる部分かもしれないです。
    あとは、CMSから新しくコンテンツを追加したら、WEBサイトにはこんな風に反映させましょうみたいなことを決めていきます。
• サーバーについて
  やりたいことに合わせて、サーバーのスペックを確認をします。サーバーベンダーに見積もりを依頼して、クライアントに提出します。
  
• 追加、排除機能の確認
  話し合いで追加になった機能と、排除になった機能を両者で確認します。

これくらいの内容だと2〜3時間くらいの会議が5～6回あれば十分かと思います。
仕様を決めるための設計に時間を多く使います。

要件定義　まとめ

ここまで、要件定義の内容について見ていきましたが、まとめとして、

• クライアントと制作する内容について、しっかり認識合わせをすることが大事。
• 難しい仕様や、前例のない開発はクライアントに事前に伝えておく。（開発段階で予期せぬ事態が起こり得ることをクライアントにも認識してもらいます。）
• 納品までのスケジュールを管理し、納期に余裕をもって間に合うように段取りを組む。
• デザインと設計を同意のうえ確定させる。
• 設計者と仕様を認識合わせしながら進める

以上の意識をもって、やるべきことに取り組んでいけば、大きな問題に発展することはないかと思います。

特に大事なのは、設計と納期の部分です。

ウォーターフォール開発の場合、設計で食い違いがあったまま開発に進むと、仕様の食い違いを解決するのに後戻りするのが大変です。
余計なスケジュール、工数がかかり、負担が増えます。

あとは、納期。
約束の納期から遅れそうな場合は分かった段階で速やかにクライアントに伝えましょう。
大幅な納期遅れや、ECなど売り上げに直結するものは損害賠償が発生する場合も考えられます。
思った以上にシビアに考えておいたほうがいいです。

要件定義の段階から、スケジュールは余裕をもって引いておきましょう。