Webアプリケーションに限らず，印刷媒体であれ，商品開発であれ，モノ作りには「完成イメージ」が必要だ。作業を積み重ねた結果として完成イメージにたどり着くのではなく，完成イメージに引き付けられるように作業を進めるべきである。企画担当者が「目を閉じれば，完成したWebアプリケーションの画面がありありと浮かぶ」と言うようでなければならない。

企画書は，一人で作るべし

　しかし，メンバー全員がまったく同一のイメージを共有することはできない。顧客との初回打ち合わせに備えた段階では，漏れを防ぐ意味で全員参加のブレーンストーミングに意義はあるが，企画書の作成に複数のメンバーがかかわると収拾がつかなくなる。打ち合わせがたび重なると，直感よりも過去の統計値が重視され，独創的な提案はオミットされる。その結果，誰でも考えつくような，可もなく不可もない提案に落ち着いてしまう。

　したがって，企画書を作成する作業は一人の担当者に任せるべきだろう。通常，それはプロジェクト・リーダーかコア・デザイナーということになる。

　Web上に，似たようなサイトがある場合は特に注意が必要である。打ち合わせの際，「先行他社が実装済みの機能は最低網羅しなければ」という意見が優勢になる。その結果，多機能で開発目的の定まらないアプリケーションが氾濫してしまう。

　多数の意見を取り入れた凡庸な企画は，仮に，顧客が喜んで受け入れたにせよ，予想以上の成果はもたらさない。平凡な効果しか生まないなら，さらに短納期低予算で提案する会社が現れたときに仕事を奪われてしまいかねない。

　企画では「足す」のではなく「引く」ことが肝心だ。顧客やエンドユーザーにとって役立つ機能を絞り込み，独創的な提案を一つか二つ追加して，企画書をまとめよう。

　もし奇抜過ぎる提案を思いついたら，「まずは理解者を得る」などと考えないことだ。説得に時間やエネルギーを使う前に，中途半端でもいいから，自分の手でプロトタイプを作ってみよう。そうすれば，すべてのメンバーの説得は無理でも，“努力に免じて”顧客への提案を却下される可能性は減る。そのほうが最終的には全員がハッピーになれる。これは，長年の業務経験を経て，最近ようやく気づいた筆者の教訓である。

　プロジェクト・リーダーは，企画担当者が明確な完成イメージを描けるような体制を敷かなければならない。すべてのメンバーに等しく発言権を与え，打ち合わせを繰り返すのは愚の骨頂である。コラボレーションでは，「みんなで」という4文字が，薬にもなれば毒にもなるのである。

顧客にモックアップやプロトタイプを見せよう

　顧客自身が，明確な完成イメージを持っているケースはごく稀である。通常は，漠然としたイメージと，過度の期待感を持っている。だから企画書には，顧客のイメージを湧き立たせるような，具体性のある資料を添える必要がある。

　受注がほぼ確定しており，実装する機能も明確な場合は，企画段階から詳細な画面遷移図を作成し，バックエンドの処理（データベースとの連携など）を削除して提出資料に代える方法がある。受注確定後，基本設計書と詳細設計書を修正すれば，すぐに実開発に着手できるので効率的である。また，処理まで考えた遷移図となっているため，詳細設計段階での破綻を防ぐこともできる。

　他社とプレゼンテーションを競う場合は，詳細な画面遷移図の作成に時間を費やす必要はない。まず色彩プランを決めてから，モックアップを作成する。是が非でも受注したい案件なら，モックアップをベースにしてプロトタイプも作成する。それらをブラウザで表示して，画面キャプチャを撮って画面遷移図を作成する。

　モックアップは，Photoshopなどで画面全体を作り込み，GIF形式で切り出してHTMLページに貼り込んだものでよい。トップページだけは，ラフデザインをプリントアウトして提出しよう。美しい印刷物は，顧客の心をつかむ有効な手段だ。

　トップページからプログラムによる処理が必要な場合は，プロトタイプを作成する。その場で動かせるという体験は，顧客の心を動かす。提案の重要性も伝わりやすい。実開発ではないから，メインとなる部分の機能を実装すれば十分だが，できればデータはダミーではなく，顧客がピン！とくる，実データがよい。また，エラー処理には気配りが必要だ。プレゼンテーションとはいえ，顧客の操作中に1回でもエラーが出れば，評価は下がると思ったほうがいい。

メンバー全員が知っておくべき
プログラミングの工数

　画面遷移図やモックアップやプロトタイプの作成は，プロジェクト・メンバーの意識を刷り合わせるうえでも重要である。なぜなら，プログラミングを簡単な作業だと誤解しているメンバーもたまにいるからだ。

　例えば下記の図1は，複数の企業が任意の団体を作り，企業情報と，各企業が販売する商品の情報，記事を発信していくという企画の資料である。

【図1】 恐るべき画面遷移図

　画面遷移図とすら言えない簡単過ぎる図である。しかし，筆者に相談してきたあるデザイナーは，これを基本設計書だと誤解している（決して顧客に提出するために簡略化しているのではない）。そして，「どの機能も，入力されたデータを登録する処理だから，全部同じプログラムでいけますよね？」と平然と言うのだ。

　そんなわけがないのは，プログラマの方ならすぐにわかるはずだ。いくつか疑問点を挙げてみよう。

　まず，販売元の企業別に商品情報を登録するなら，入力担当者が一人（特定のオペレータ）なのか複数（各企業の担当者）なのかを知らなくてはならない。顧客側の環境，担当者の技術レベル，更新方法＊1，更新頻度，商品データ数なども詰める必要がある。複数の担当者が入力するなら，担当者の登録フォームが必要かもしれない。企業情報の登録も前提条件となる。さらに，Webで公開するなら，商品写真をアップロードしてURLを参照して登録したり，PR文をフリー入力できるボックスは必須だ。登録項目についても，検討の余地がある。

　分類リストの問題もある。あらかじめ決めておくのでなければ，図2のように入力担当者が新しい分類を作成できなければならない。分類の変更や削除機能を付けるのであれば，分類登録と商品情報登録はフォームを分けたほうがよい。既存の分類が変更されると，登録済みデータに影響が及ぶからだ。

【図2】 図1の中の「企業別商品情報の登録」に必要な機能
[クリックすると別ウィンドウが立ち上がります]

　しかし，これでもまだデータベース関連については検討が足りない。ひとくちに商品情報の登録といっても，データの追加，挿入，削除，既存データの編集（修正）といった一連の処理を実装しなければならないし，データベース設計，整合性を保ったデータの更新（トランザクション）も考慮する必要がある。

　入力されたデータの検証も必要だ。不正なデータが入力された場合はエラーメッセージを表示して[追加]ボタンを使用不可としたり，ボタンは使用可でもクリック後に注意事項を表示して，データベースへの登録を防ぐといった処理が必要になる。

　入力担当者が作業しやすいユーザー・インタフェースについての検討もある。「企業情報の登録」機能では，会社名の「株式会社」や「有限会社」を選択させるのか入力させるのか，省略形を許可するのか，代表者名の姓と名の間の空白の処理，業種の選択肢，入力データの重複のチェック，不正な電子メールアドレスのブロックなど，考えればきりがない。さらに，不正なデータが登録されないように，入力担当者のログイン・ページも用意する必要があるだろう。

　——以上，プログラマ（エンジニア）の視点に立てば，検討事項は無数にあることがわかるが，技術オンチなデザイナには，こういったことを実感として理解することができない。そういう場合は，「Illustratorを使うのは簡単でも，Illustratorというソフトを開発するのは難しいと思うでしょ」とデザイナに言ってみよう。たぶん納得してもらえるはずだ。

　Webページの数，機能の数，プログラム・ファイルの数は同じではない。企画に対して，工期と見積もり金額が妥当であることを，顧客に提案する以前に，メンバーが理解していなければならない。

　そして，プロジェクト・リーダーは，画面遷移図を深く理解し，顧客と完成イメージを共有できるように導かなければならない。後は，顧客側担当者の先見性や理解度と，プロジェクト・リーダーの営業センスが噛み合うかどうかにかかっている。