クライアントの希望を満たす、機能の詳細を固めていきます。
提案に際して、企画書を作成します。データベースやサーバの情報や、XMLの設計に公開DTDを利用したり、あるいは参考にする場合はその情報なども、参考資料として企画書に添付します。
書類だけでなく、テストプログラムを提出する方法もあります。技術的に可能かどうかを調べるために有効ですし、クライアントの明確な希望を引き出せない場合は、確認にも役立ちます。ユーザには、実際に動作するものを見て、初めてイメージをつかめるようになる人も多いからです。ダミーのテストデータを作成し、メインとなる処理の部分だけを作成します。
機能の詳細を確認しながら、詰めていきます。すべてを開発側で考えて提案するよりも、クライアントの意見を聞いて膨らませていくことも必要です。クライアントの方が、処理するデータの内容について熟知しているからです。
例えば、検索機能を実装する場合、XML文書のすべてを検索対象とする場合もありますし、特定のノードを検索対象とすることもあります。また、利用するユーザ層や目的によって、検索キーの入力方法やインタフェースデザインも違ってきます。
また、実装予定の機能の実現性を評価し、運用結果を予測します。クライアントの協力を得て現状を分析し、アプリケーション使用による改善点を明確にしておきます。どの程度の費用で開発すれば費用対効果が出るのか、あるいは宣伝効果があるかなど、クライアントが期待する効果が出るかを調査します。このとき、クライアント側のおおよその予算を伺うことができれば、おのずと開発内容は絞り込まれてくるため、この後の段階において、「実装する見込みが全くない」機能に関する打合せや作業に注力しなくてもよくなり、工期を短縮することができます。
機能を固めながら、設計前に、データの流れや、各Webフォームページの関係を表す、画面遷移図を起こします。できるだけ、ヴィジュアル面も考えて図式化します。どんな形になるのか、目で見て分かる形に表現した方が、クライアントにとっては分かりやすく、意見や希望を引き出しやすいからです。本来、画面遷移図作成は、設計段階での作業だと思いますが、たとえ二度手間になっても、企画段階で一度作成して、タタキ台として、もんでおいた方が、後々の作業がスムースに進みます。
発注が確定していない場合は、この段階で、見栄えのよいヴィジュアルデザインがなされたトップページのラフを、Photoshopで作成してプリントするか、あるいはHTMLベースで組むなどして見せておくと、クライアントへの印象が良くなります。
画面遷移図中の各々のWebフォームページの、大まかなレイアウト図（大ラフ）を作成します。フォームやボタンなどの部品をラフにレイアウトした図です。各Webページの操作や機能の概要説明書も作成して添付します。クライアントとともに、ユーザの立場に立って、インタフェースが適切かどうかを検討する資料になります。
各画面のレイアウトを含む画面遷移図すべてを、長尺プロッタで出力してクライアントに渡す制作会社もあるようですが、小・中規模案件の場合、クライアントも使えるソフト（Excelなど）で作成して、ファイルのままお渡しした方が、クライアント側でも要望を書き込んで返すことができ、意見交換がしやすい場合があります。
画面遷移図はクライアントが納得するまで何度でも書き直して検討した方がよいと思います。この段階で十分な時間を使っておいた方が、設計やプログラミング段階で仕様変更が生じ難く、納期間際での変更を避けられるからです。XMLアプリケーションでの間際での仕様変更は、タグ設計の見直しにつながる恐れもあり、工期に大きく影響することがあります。
企画にコンセンサスが得られたら、この段階での仕様を整理して、まとめておきます
頻繁に打合せを行うと、類似の資料が往復して、開発側―クライアント側双方で、誤解を生む事態が発生しないよう、面倒でも、資料は日付毎に整理し、コメントや議事録を添付しておきましょう。ここでは触れませんが、議事録の書き方も重要です。
基本的な仕様が固まったら、スタッフの手配や工期を考慮しながら、開発スケジュールを組み立てます。スケジュールが決定したら、概算見積書を作成してみます。
その際、いつまで継続する仕事か（派遣スタッフを使う場合は、引継の問題も考えておく必要があります）、将来的に機能を拡張する予定がありそうか（低予算の場合、順次機能追加をすることも考えられます）、今後発表される技術を使用して実装した方がよい機能がある場合は、現時点で実装するかどうかなども検討します。
また、使用技術や開発環境に将来性があるかどうか（近い将来にサポートが中止されないか。利用し難くなるデータ形式ではないか、など）、データにどの程度の機密性があるか（セキュリティの問題）も重要です。
見積金額の算出方法は、各事業者によって異なります。
筆者の知る限り、システムハウスでは、作業月数によって全体の金額を算出するようです。SEなら一人月いくら、プログラマならいくら、オペレータならいくら、これだけの工数がかかるので全体でいくら、という計算方法です。一人月の単価とは人件費ですから、当然、地域によって異なります。東京の物価は、統計値では、松山市の1.4倍だそうです。人件費にしても、当然違うはずです。なお、Windowsアプリケーションの開発や中規模のシステム構築なども同じ方法で見積を算出するようです。
一方、制作会社系では、印刷媒体やWebサイトなどと同様の見積方法をとります。画面遷移図はカラーカンプと同様にとらえます。わたしの場合は、JAGDA（日本グラフィックデザイナー協会）会員のデザインスタジオに長年勤めており、社内の見積システムなどを作っていたので、当然のことながら、JAGDA方式です。作業とその難易度を全て書き出し、作業積算方式で見積っています。そのようにすることで、見積がガラス張りになり、クライアントさんに説明しやすくなります。予算と機能の兼ね合いを検討し、予算上難しいものは後日実装としたり、代替案を提案することもできるようになります。
見積金額の算出の際に難しいのは、人月計算であれ、作業積算方式であれ、ベテランが作業した方が工期を短縮できるという点です。特別な指名のない限り、実務担当者の経験年数など、クライアントには「知ったこっちゃあない」わけです。クライアントからすれば、安く、早く、正確に動作するものを、納品してほしいだけで、それができれば、窓口として顔を合わせるわけではないでコーディングを、誰が担当するかは関知しないはずです。
しかし、ベテランほど早く、新人ほど時間がかかるとなると、単純に工期から金額を算出したのでは、ベテランほど安いということになってしまいます。
ごく普通のレベルのプログラマが担当した場合、どれほどの工期がかかるのかを予測することは、今なお、わたしにとっても、なかなか難しい課題です。
企画段階で得られた回答は整理しておき、Webサーバの環境、開発環境、ユーザ側の環境、スタッフ、開発方法、運用方法などの条件をまとめた資料を、必ず見積書に添付します。
初期の段階で条件を書面に記載しておかなければ、公開にいたるまでに情報が曖昧になっていき、トラブルのもとになりかねないからです。
とくに、ユーザ側の環境は重要です。OSやブラウザによって、表示が異なるからです。FireFoxはまだよいにしろ、Safariにも対応となると、VS.NETの吐き出すコードに100％頼ることはできず、CSSを追加するなどの試行錯誤がかなり必要になります。それでも、Windows版IE6と同じ表示や動作を実現するのは、困難です。
携帯端末ともなれば、メーカーだけでなく、機種によって、サポートする言語や送信文字数、文字コードが異なるので、見積書に「全機種に対応」などと明記するのは避けた方がよいと思います。営業という側面から見れば、フロシキは広げたほうがいいとは思いますが、何でも出来るようにPRして引き受けた後、できないと断りをいれるよりも、対応困難と伝えてあったものが結果的には対応できたという方が、クライアントに対して、誠実だと思います。
開発工期は、小規模案件で1カ月、中規模の案件では3カ月は必要と考えられます。既にサンプルプログラムがあって、カスタマイズ程度で納品可能なものであれば、1週間～2週間という工期も十分に考えられます。ネタをどれだけ持っているかが、工期の短縮に直結します。
