開発の依頼を成功させるためにGUIDE

表示が遅い、バージョンが古い、社内で管理できない、開発の生産性が低い、業務効率が悪いなど。目的だけでなく課題も示すことで、ゴールと現状のギャップを踏まえた提案が受けられます。

提案と見積の内容を大きく左右する情報です。「コーポレートサイト」「業務システム」と伝えるだけでは、ページ数も機能もわかりません。会員登録が要るのか、既存のデータを移すのか、管理画面から何を操作するのか。細かく書くほど見積の精度は上がります。

予算を伝えると足元を見られる、と思うかもしれません。ただ、予算がわからなければ、依頼先は要件から完成形を想像し、それを作るための費用を出すしかありません。その結果、会社によって金額がバラバラになり、見積の比較が難しくなります。予算を伝えることは必須ではありませんが、伝えないことのデメリットも意識した上で検討することをお勧めします。

制作や開発にどのくらいかかるものなのか、見当がつかないこともあります。短すぎる納期を設定してしまうと、通常より高い見積になることも、見積自体を断られることもあります。わからなければ、希望を伝えたうえで、実現できるかを聞いてみましょう。

いつまでに提案が欲しいか。納期とは別の話です。期限が短すぎると、内容を詰める時間がないまま提出されることになります。規模によりますが、1〜2週間はみておくとよいでしょう。

システムやサーバーの現状を正確に伝えられる担当がいるか（社内・委託先を問わず）で、進め方が変わります。担当がいれば現状を正確に出せて調査コストを抑えられます。いなければ現状把握から始めるため、その分の費用を見積に織り込む必要があります。

社内の規程や、取引先から求められるセキュリティ・品質基準があれば伝えてください。データを国内に置く必要がある、特定の認証を取っている、社外の人間には社内システムのアカウントを発行できない。こうした基準に準拠するために、追加の工数がかかることがあります。あてはまるものがあれば共有してください。

つくるものをどんな形で提供するか（Webサイト・アプリ、スマホアプリ、PCアプリ）と、対応するブラウザ・OSのバージョン範囲。古いバージョンや幅広い環境に対応するほど、開発工数が増えます。使う人の環境に制約がある場合は、後からわかると作り直しになるため、先に伝えてください。

基幹システム、顧客管理や会計などの外部サービス、社内の独自システムなど。連携が必要であれば伝えてください。連携は連携先の仕様によって工数が大きく変わるため、見積の前に把握しておく必要があります。

イメージを伝えるのに便利です。ただ、参考サイトだけを渡すと、そこにある機能が全部必要だと解釈されることがあります。「どこを参考にしたいのか」まで添えると、正確に意図が伝わります。

AWSやGoogle Cloudなどのクラウド、レンタルサーバー、VPSなど。いまの環境に統合するのか、新しく構築するのか。どちらにしても、既存の環境はインフラ構成を提案するために必要な情報です。

わかる範囲で。「把握していない」なら、そう伝えてください。調査から始める必要がある、ということが依頼先に伝わります。

自社で管理しているのか、外部に任せているのか。契約しているサービスはどこか。管理状況によって、移行や設定変更などの公開の段取りが変わります。

既存システムの改修・リプレースでは、ソースコード、DB構造、設計書、サーバーのログイン情報、ドメインの管理権限など、今の作りを直接確認できる情報を開示することで、見積の精度が上がります。逆に見えない部分は、リスクとして金額に乗ります。ただし、これらは機密情報にあたるため、どこまで開示するかは依頼先とNDA（秘密保持契約）などを含めて協議のうえで判断してください。