提案書は何のためにあるのか
開発の提案書は、ご相談内容を約束に変えるものです。何を、いつまでに、いくらでつくり、何かが変わったときにどうするのか。
実務上のルールはシンプルです。書かれていない細部は、含まれていないと考えましょう。
範囲：機能を結果として書く
良い範囲の記述は、画面の名前だけでなく、ユーザーが何をできるかを説明しています。「ユーザーはメールアドレスまたはGoogleで登録でき、パスワードを再設定できる」は確認できます。「認証モジュール」では確認できません。
ユーザー種別、主要フロー、管理ツールが別々に書かれているかを見ましょう。管理画面はご相談の段階で忘れられがちで、後から追加すると高くつきます。
対象外：誰も読まないセクション
明確な提案書は、含まれないものを記載しています。たとえば、文章の執筆、翻訳、アプリストアへの申請、外部サービスの利用料、リリース後のホスティングなどです。
対象外のセクションがなければ、追加を依頼しましょう。含まれていると思っていたのに含まれていなかったものは、すべて後から変更依頼として戻ってきます。
理解しておくべき技術的な判断
エンジニアである必要はありませんが、読み終えたら次の質問に答えられるようにしておきましょう。
何を使ってつくるのか。そして、なぜこのプロダクトにそのスタックなのか
コードとアカウント（ホスティング、ドメイン、アプリストア、アクセス解析）の所有者は誰か
どこでホスティングし、リリース後は毎月おおよそいくらかかるのか
別の開発者が引き継げるほど、コードはドキュメント化されるのか
良い開発会社は、選択の理由を平易な言葉で説明します。「いつも使っているから」は理由になりません。
スケジュール：確認できるマイルストーン
納期がひとつあるだけでは、ほとんど何もわかりません。承認済みのデザイン、テスト用URLで動くビルド、リリース可能なバージョンなど、各段階で確認できるものがあるマイルストーンを探しましょう。
進捗をどのくらいの頻度で確認できるかも尋ねましょう。週に一度の確認が妥当な基準で、最後に一度だけのデモはリスクです。
品質：「完成」が何を意味するか
提案書が、機能だけでなく、テスト、パフォーマンス、アクセシビリティに触れているかを確認しましょう。
対応するブラウザと端末、プロダクトが達成すべきパフォーマンス、リリース前に誰がテストするのか。具体的な記載を探しましょう。
価格、支払い、変更
価格に何が含まれ、支払いがどう分割されるのかを正確に確認しましょう。着手金とマイルストーン連動の支払いが一般的で、全額前払いは一般的ではありません。
変更手続きを探しましょう。新しい要望を、誰かが手をつける前にどう見積もり、どう承認するのかが説明されているはずです。
リリース後
多くの提案書はリリース日で終わっています。その後について尋ねましょう。不具合修正の保証期間はあるか、どのくらい続くのか、継続的な作業の料金はどうなるのか。
修正やアップデートの計画がないままのリリースは、多くのプロダクトが静かに止まってしまう場所です。
契約前に尋ねるべき5つの質問
具体的に何が対象外ですか
日々プロジェクトを担当するのは誰ですか
範囲を変える必要が出たらどうなりますか
最終的に、コードとすべてのアカウントは誰のものになりますか
リリース後にはどのようなサポートが含まれますか
著者について
Gleb Sosnovskiy
Sakura Agencyテックリード。Web・モバイルのプロジェクトで開発を統括。