画面遷移図を作成し，企画書を提出して受注が確定。ところが，その後の折衝が，これまた大変である。顧客側にも，いろいろな事情があるのだ。
顧客の「膨らみすぎる夢」を抑えよう
顧客に企画書一式を提出し，発注が確実となったら，ここからが正念場だ。実装機能，予算，工期の確定，開発用データの整備など，煮詰めることが山ほどある。この段階での折衝が，その後の顧客との関係を決めるといっても過言ではない。
顧客が人格円満な人であっても，スムーズに作業が進むとは限らない。顧客にとってWebは専門外なのだから，Webプランナー側が「わかってくれない」と嘆いても始まらない。「わからない」からこそ依頼しているのだ。問題とその対応方法はケースバイケースなので具体的な助言は難しいが，いくつか例を挙げてみよう。
ITやWebに憧憬や万能感を持ち，夢と社内事情が遊離しがちな顧客はまだいるものだ。中には，Webを「棚からぼたもち」の実現ツールのように誤解している人もいる。その昔は「Webサイト開設→マスコミが注目」，その後は「XML技術の採用→即IT業界内ステータスと人脈の確保」，少し前なら「ネットショップ開設→開店当日から大繁盛」「IT起業→成功者」といった誤解だ。
たしかに，開設してすぐに収益につながったというWebサイトはあるだろう。だが，成功したサイトのWebマスターは「苦労」はしていなくても，「努力」はしているはずだ。努力の度合いが低ければ，収益も低い。ローリスク・ローリターンだ。事業者側は，顧客の夢を，どのみち実現不可能なことだと聞き流してはならない。また，受注を急ぐあまり，夢を煽るようなことをしてもならない。そのツケは，仕様膨張という形で跳ね返ってくるかもしれない。
そういった誤解をしている顧客は，Webアプリケーションの提供によって収益を上げる企画であれば，ニーズを読み間違えた価格を設定してしまうことがある。だから，事業者側が提案する価格の裏付けとなる統計資料を，先んじて提示しなければならない。第一回目でも書いたように，通常，統計資料は新規企画を裏付けるには心もとない。そのため，Web上を検索して，説得に使えそうなデータを探し出すしかない。国内に適当な資料がなければ，海外サイトもあたってみよう。「日本でも，そのうち同様になる」と説得して，顧客の先走りを食い止めよう。
また，顧客にとってサイト開設は「納品」＝「支払い」なので，出発点ではなく終着点のように考えがちになることもある。いくら良いサイトを作っても，運用努力を怠ればエンドユーザーは離れてゆく。ユーザーの問い合わせ窓口となる社員の教育，リピーターを逃さないためのサービスの実施は重要な課題だ。物品販売の場合は，破損や鮮度保持，カスタマイズや微調整など，配送方法の確立も必要だ。ユーザー情報の管理方法，問い合わせメールへの返信方法についても，社内標準化は必須である。
企画の早い段階から，顧客側の宣伝への意欲や営業能力を見極め，方向を修正しつつ，地道な運用努力やアフターサポートの重要性を訴えていこう。助言に際しては「こうしなければ，まずいですよ」ではなく，「こうしたほうが一層，効果が出ますよ」と肯定的な言葉を使うほうがよいみたいだ。外部の事業者として一定の距離を保ち続けながら，言うべきことは言う姿勢が大切だ。
さらに，デザイン・センスを自負する顧客の個人的な趣味によって，サイトのイメージプランが損われそうなときは，きっぱりと線引きをしなければならない。デザイナー出身のプランナーは，アートに一家言を持つ顧客と衝突しないように説得しよう。そのためにも，雑談の中で顧客のアートに対する関心の程度を把握しておく必要がある。
狙い通りの結果が出なければ，すべて企画を担当した事業者側の責任になるのだから，苦言を呈することをちゅうちょすべきではない。
「データベース設計の重要性」を訴えよう
データベース絡みの処理を伴う企画では，サンプル・プログラムやプロトタイプの開発に着手した段階で問題が発生することがある。実データあるいは実データと同じ構造のダミー・データがなければ設計は固められないものだが，期限を過ぎても，顧客側ではデータを準備できないことがあるのだ。
頻繁なデータ提出の要請は必要だ。しかし，非難や苦言は何の解決にもならない。再三再四にわたるメールや電話に顧客がウンザリすると，Web開設を諦めたり保留にすることもある。強く要請しながらも，フォローは忘れないようにしよう。既存データがあるなら，必要な部分だけを抽出したり，変換したりできないかも考えてみよう。
たしかに，顧客側担当者がデータを準備する余裕すらないほど忙しいことは多い。物品販売の業種なら，オペレート担当者すら決まらない場合もある。そして，こう言う。「正式なデータは公開日までに必ず用意する。制作側で簡単な見本のダミーデータを作って，それで実開発を進めてほしい」。
顧客がこのような言葉を口にするのは，事業者側が顧客にデータの重要性を伝えきっていないからだ。気軽な進行は気軽な変更につながることを説明しておかなければ，ベータ版の段階で項目（フィールド，あるいは要素）の追加が生じることがある。運用段階で，異なる構造のデータが追加されることもある。RDB（リレーショナル・データベース）でもXMLでも設計から見直し，プログラム・コードを変更することになりかねない。
簡単なXMLデータを例にとって説明しよう。例えば，図1（上）のような構造のデータを，顧客が提出してきたとする（説明を容易にするため，簡素化している）。入門セミナーや応用セミナーなど複数のセミナーを設定する予定のため，3階層の構造になっている。
 |
| 図1●データ作成段階での構造提案の例 |
これを見ると，Webプランナーの皆さんならすぐ心配になるに違いない。
・複数のセミナーの日程が重なることはないのか？
・重なった場合でも，開催時間や開催場所を変えて両方参加できるようにするのか？
・それだけの場所と講師を確保できる見込みはあるか？
・異なる場所で開催可能な場合，同一建物内か？
・移動時間は大丈夫か？
・プログラマも，デザイナー向けの講座を受講できるのか？
・講座が増えて，分類の細分化が必要になる可能性はないのか？
――などなど，山ほどの質問事項を思いつくだろう。
仮にWebサイト開設後，同じ日（例では6月15日）に複数のセミナーの開催が決まったらどうだろうか。受講希望者を振り分けるため，エンジニアは「Ajaxマスター」，デザイナーは「Flashマスター」「InDesignマスター」の詳細ページしか閲覧できないものとし，さらに，実習を進めやすくするためDTPデザイナーについては「InDesignマスター」のみ申し込めるようにしたいという希望が出てくるかもしれない。
すると，結局ナビゲーションと受講申し込みページの処理に若干の手直しが必要となる。それなら，例えば図1（下）のように，あらかじめ階層を追加するよう，もっと話を煮詰めておけばよかった，ということになってしまう。
ことデータベースにかかわる案件では，顧客が気づかないであろうことを，すべて列記して確認しておかなければならない。図1は非常に単純な例だが，実務では，項目数が多く階層も深い何万件のデータがある複数のファイル（あるいはフィールド数が多くリレーションシップが複雑なデータベース）を処理することは珍しくないわけだから，わずかな手直しもバグにつながりかねない。リスクは，結局，事業者側に跳ね返ってくるのである。
データベースの構造以外にも，変更は発生する。納品して問題なく運用し，ずいぶん日にちの経ったころ，顧客側の入力したレガシー・データにミスが見つかることもある。そのデータを流用している個所を急きょチェックするなんぞ，寝耳に水の話であって恐ろしいことだ。プログラムに関していえば，公開後にメールの自動返信のサブジェクトや内容が変わるのも比較的よくある話だ。不安材料は，実開発の前にできるだけつぶしておく必要がある。
新しい企画に気軽にチャレンジするようなアグレッシブな顧客は，一歩間違えればチャレンジする方法まで気軽に変更できると考えがちだ。開発実務担当者にしわ寄せが及ばないよう，前工程をスケジュール通りに進められるかどうかは，Webプランナーのナビゲーションにかかっている。
「顧客の社内事情」を見極めよう
顧客側窓口を経営者自らが務めており，臨機応変に対応する優れた能力が逆方向に向かうと，打ち合わせの度に新しいアイデアを取り入れようとして仕様が変わり続けることがある。これを防ぐには，企画書やレガシー・データの校正に際してサインをもらい，すぐさま実務に着手し，変更するとなると余分な費用が必要になるという方法で説得することだ。まずは当初の企画で開設し，エンドユーザーの反応を確認しながら，改善・工夫していくよう強く進言しよう。そうしなければ，いつまで経っても実作業に着手できない状況になり，開設のタイミングを逃し，企画が古びてしまいかねない。
さらには，社内事情から仕様変更が相次ぐケースもある。例えば，こんなことがある。顧客内にプロジェクト・チームが結成され，小規模案件にもかかわらず打ち合わせには必ず多数の役員が出席する。打ち合わせを重ねる度に，仕様への希望が180度変わる。Webサイト開設に積極的なのが若手の窓口担当者だけで，他の年配の役員は消極的で，成功させようという前向きな意志がない――このような場合は，窓口担当者をサポートする立場に立ち，その意見だけを採用し，二人で周りの役員を説得するようタッグを組むとうまく行くことがある。
仕様の膨張や変更への逐次対応によって本来の工期を越えてしまったら，事業者側も困ることになる。何より，後に控えた他の顧客の案件の着手がずれ込んでしまう。機能の再絞り込み，段階的導入，既存のアプリケーションやサービスによる一部の機能の代替，顧客側社員との作業分担といった方法で乗り切れないかを検討してみよう。
営業と折衝は，発案，企画，設計の何倍も難しい
Web関連の本や資料は多々あるので，顧客も知識は豊富だ。世が「Web 2.0」だといえば，「これからはWeb 2.0だ」「在庫をロングテールで売りたい」とくるが，理想を実施できるだけの社内体制がなければ，絵に描いたモチに終わってしまう。
開業して日が浅い事業者は，自信満々な顧客の言葉に，同じ夢を見てしまうかもしれない。しかし，フタを開けてみるとバックアップ体制は何一つないこともある。足元を見つめて一歩ずつ積み上げる企画を地道に実施すれば，いずれは到達できたであろう目標に，一歩も近づけないという状況に陥る。企画の打ち合わせでは「冷静」を心がけよう。
メールに不慣れであるか出張の多い顧客は，メールでの確認事項のやりとりに，恐ろしく日数のかかることもある。企画の見直しにつながるような質問について，その重大性が判断できないために保留にしてしまうのだ。そのような顧客に対しては，質問や確認は電話やファクシミリで行い，その結果を簡易な議事録として作成してメールで送っておくとよいだろう。
顧客の個性が強く，最初はトンデモナイ相手に見えたとしても，単にITやWebを誤解していたり，実践的な知識が不足しているだけということは少なくない。「理解してもらえない」ではなく「どのように説明すれば理解してもらえるか」を，企画のアイデアを考えるのと同様の方法で考えてみよう。距離があっても事業者側から歩み寄れば，同じだけ努力して歩み寄り返してくれる相手であるなら，一度納品にこぎつけると，制作・開発以外の（講習等の）仕事を依頼してくるなど長い付き合いの始まることもある。意思疎通ができるようになるまでは大変だが，頑張ってみる価値はあるのだ。
―――とまぁ，こんなことを書いてはいても，Webの仕事の中で最も難しくセンスが要求されるのは，営業や折衝の仕事だと筆者は思っている。Web制作の実務者としてはベテランでも，営業経験が少なかったり，エンジニア出身でコミュニケーションの苦手なWebプランナーは，人間関係の構築にも力を注がなければならない。
そして，たとえ運悪くつまづくことがあったとしても，失敗の原因を分析し，対策を立てて，次の仕事で成功に転じなければならないだろう。
