提案内容が固まったら,次は企画書に落とし込む作業だ。顧客に合わせてカスタマイズできるような,基本のフォーマットを作っておこう。また,確認漏れや度重なる打合せを避ける意味でも,必要事項を網羅したチェックリストを作っておこう。

企画書の構成と,基本のフォーマットをかためる

 企画提案の際には,基本の企画書だけをポンを渡せばよいというものでもない。企画の根拠や,実装のために必要な費用,工数,スケジュール,公開後の更新方法などを記載した書類一式を提出するものだ。具体的には,表1のように複数の書類をセットにする。

表1●企画提案資料の構成
表1●企画提案資料の構成
[画像のクリックで拡大表示]

 このうち,顧客内部で,まずタタキ台としてテーブルに乗るのが「基本の企画書」だ。基本の企画書では,次のように,必要最低限の事項を明確に定義する。

・顧客名,案件名,ドメイン名(取得済みであれば)
・制作・開発の目的
・訴求対象(ユーザー層)
・期待効果(具体的な売上目標,問合せ件数,アクセス数等)
・実装する機能(個条書きでリストアップ,機能の説明を付ける)
・おおよその工期(制作・開発・運用スケジュール)
・提案の背景(社会的背景,文化的背景,経営・業務課題)
・Webサーバーの環境(OS,プラットフォーム,DB)
・エンドユーザーの環境(端末,OS,画面解像度,回線,ブラウザとそのバージョン,プラグインとそのバージョン)
・使用範囲(使用期間,使用場所,使用方法)
・管理情報(納品予定日,企画の有効期限)
・別添資料の目次
・事業者名と連絡先

 このうち最も重要なのは,「訴求対象」と「期待効果」だ。これらがあいまいなままでは,思い描く結果は得られない。

 訴求対象は,年齢層・職種・居住地域・性別等から,ターゲットとなるユーザーの特性を洗い出したものだ。「万人幻想」を持ってしまいがちな顧客との刷り合わせが必要な,第一のポイントだ。

 期待効果は,できるだけ具体的な数値で示そう。企画の決定権を持つ経営者には,文章よりも,数字のほうが響く。

 Webサーバーやエンドユーザーの環境は,「企画の詳細」にも記載するが,重要なことなので重複してもかまわない。また,概算見積書にテスト費を計上して,その環境(OSやブラウザ)を記載する場合,基本の企画書との間で,不整合があってはならない。

 実装する機能は,唯一のプランだけを書く。他にも提案するプランがある場合は,「企画の詳細」で取り上げたほうがよい。基本の企画書で複数のプランを取り上げてしまうと,顧客が迷い始めるからだ。

 以上の事項を盛り込んだ企画書のフォーマットをワープロソフトなどで作成しておき,依頼のある都度,顧客に合わせて多少の変更を加えながら使えばいい。すでに取引のある顧客で,販売促進や広告宣伝業務用に使い慣れている企画書フォーマットがあるなら,それをベースにしてWeb特有の項目を追加したフォーマットを工夫するのもよいだろう。

基本の企画書からあふれた事項は,別添資料で補足する

 制作・開発に着手する前に,合意を得ておかなければならない事項は多い。それらのうちのいくつかは要件定義や議事録に残されているものだが,企画書の一部として再提出しておくことにより,記憶違いからの無用のトラブルを回避することができる。

 だが,すべての事項を基本の企画書に盛り込んでしまうと,複雑になって説得力が薄れてしまう。

 そこで,あふれた事項は,「企画の詳細」「添付資料」,顧客側更新が考えられる場合は「運用・更新のご提案」といった資料に記載するとよい。ただし,どの書類に記載するかは,顧客への伝わりやすさを検討して決定する。

 例えば「基本の企画書」の,制作・開発の目的,実装する機能の説明,提案の背景といった文章部分はできるだけ簡素化して,「企画の詳細」で補足したほうがよい場合もあれば,逆に「基本の企画書」に「企画の詳細」の詳細説明を盛り込んだほうがよい場合もある。これは顧客のタイプによって異なり,企画書に目を通してもらうための重要なポイントであるから,次回に詳説する。

 これらの書類の作成目的は,確認漏れや定義漏れを防ぐことにあるので,最大項目を網羅したチェックリストを作っておくとよいだろう。基本的な項目を表2にあげておくが,各事業所の立地条件や顧客層,得意とするテーマ*1,専門とするプラットフォームやデータ形式等によって異なる部分があるので,このままではなく,修正・追加して使ってほしい。

*1 本連載第2回目の表「Webサイトの開設目的別,企画時のチェックポイント」を参照。

表2●「企画の詳細」「添付資料」「運用・更新のご提案」のいずれかに記載する項目の例
表2●「企画の詳細」「添付資料」「運用・更新のご提案」のいずれかに記載する項目の例
[画像のクリックで拡大表示]

 記載すべき主な内容は以上の通りだが,「企画書」の明確な定義はなく,決まった形もない。顧客との信頼関係や,案件の規模などによって決まる,流動的な部分も多い。

 なお,表1をはじめとする以上の資料がすべて必要とされるのは,開発工期が2~3カ月の中小規模案件の場合だ。短納期超特急の単発案件では,2ページ程度の「企画書」と,ザックリとした「概算見積書=正式見積書」,項目名とデータ型を記載しただけの「データベース設計書」という4~5ページの書類を提出して口頭発注にいたり,基本設計図を手描きしながら,プログラマに口頭で実装する処理を説明することもある。

 ケースバイケースではあるのだが,「正解」がないわけではない。円滑に制作・開発が進み,目標を達成できた企画書。それが,唯一の正解だ。

企画書と同時に提出する,画面遷移図や概算見積書のとらえかた

 表1の通り,通常は,企画書と同時に,画面遷移図や概算見積書を提出することになる。

 また,書面だけでは結果をイメージしにくいため,画像処理ソフトで作りこんだGIFや,HTMLで組み上げたたモックアップを渡すこともある。登録や検索,CMSのような動的処理が必要な場合は,サンプル・アプリケーションを作成して仮アップし,操作を体感してもらうこともある。

 現在のWeb業界では,表1にある「リンク関係図」のみを指して「画面遷移図」と呼ぶことも多いようだ。呼び名は,顧客層や事業者の職歴によって異なるが,ハコを並べて矢印で結んだような図だ。

 筆者の場合,リンク関係図を別途作成したことはない。提案内容が固まった時点で,基本設計図を引いてしまう。この設計図から,条件分岐方法や,データベースとの連携,フォーム間で渡す値,といったバックグラウンドの処理部分を削除すれば,リンク関係も含む画面設計書になるので,これを画面遷移図の代用としている。

 中小規模のプロトタイプ開発を必要とするWebアプリケーションに限っては,企画段階から基本設計図を引くことによるメリットのほうが大きいように思う。

 プログラム・ファイル数と,難易度,データベース作成にかかる工数等が把握しやすく,作業積算方式の概算見積書を作成しやすいからだ。これは,発注後の仕様変更によるプログラムのパッチワーク化を防いだり,追加開発が生じた時に予算を請求するために役立つ。また,最初から処理を考えて画面を構成しておくと,実装不可能な部分がないから,詳細設計や実開発段階で破綻しない。

 これに,概算見積書を添付して提出書類とする。プロジェクトで動く場合は,ホスティング,Webデザイン,Flashコンテンツ制作,プログラミング,データ入力を担当する複数の事業者が,それぞれ「作業詳細と各費用」を作成し,その合計金額を「概算見積書」にまとめる形になる。初期費用と,メンテナンス・コストは分けて作成する。

 予算の上限が決まっている場合は,素材制作など顧客側でもできる作業はないか,Webサイトの一部をブログで代用できないかといった方法も含めて,顧客の要望を実現できる方法を探ってみよう。

企画書には,受注獲得以外の役割もある

 企画書の役割は,制作・開発内容や見積金額に対して合意を得ることだけではない。企画書は,次の三つの目的のためにも使われる。

(1) 顧客と事業者のベクトルを合わせる。
 企画内容や見積の交渉では,顧客も事業者も自社のことだけを考えがちになるが,エンドユーザーの存在を忘れて進めてしまうと,どちらにもメリットは還元されない。企画書は,制作・開発目的というベクトルを合わせるためのナビゲーターだ。

(2) 円滑な制作・開発を保証する。
 運用環境や実装する機能,工期,メンテナンス・コストを明確にし,仕様膨張を避け,制作・開発を円滑に進めるための防波堤となる。

(3) 公開後の活用を促進する。
 事業者にとっては,結果を出してこそプロの仕事だ。だが,顧客側が公開すれば一段落と考えてしまったのでは,結果はついてこない。円滑運用と定期更新の重要性,更新作業を担当する社員への協力体制の必要性を,顧客に理解してもらう必要がある。企画書は,公開後の期待効果を達成するための手順書でもある。

 以上のようにして,企画書のフォーマットが作成できたら,次の3点に留意して,書類を作成していくことになる。
・文章,チャート,図,イラストなどから,伝わりやすい方法を使う
・顧客に合わせて,頭括式と尾括式を使い分ける。伝えすぎと言葉足らずを避ける
・書き言葉と,電話や打合せといった話し言葉での補足を使い分ける

 この作業は,顧客のタイプを見極めて行う必要がある,詳しくは次回説明しよう。

  【修正履歴】当初,「また,概算見積書にテスト費を計上して,その環境(OSやブラウザ)を記載する場合,基本の見積書との間で,不整合があってはならない。」とありましたが,正しくは「また,概算見積書にテスト費を計上して,その環境(OSやブラウザ)を記載する場合,基本の企画書との間で,不整合があってはならない。」です。「基本の見積書」を「基本の企画書」に修正しました。(2007年1月25日)