「何を書けばいいかわからない」まま、
開発会社に相談していませんか

「システムを作りたい」という話は、社内で決まった。ところが、開発会社に問い合わせようとした瞬間に手が止まる。メールの本文に、何をどこまで書けばいいのかがわからない。

かといって「とりあえず相談したい」と連絡すれば、今度は開発会社から「要件はどのあたりまで固まっていますか」「認証はどうしますか」「既存システムとの連携は」と質問が返ってきます。答えられない。悪気なく専門用語で話されるほど、こちらは何を答えれば正解なのかわからなくなる。

この記事は、その「書けない・答えられない」状態にいる発注者に向けたものです。開発会社に渡すべき情報は、実は決まっています。その中身を整理したうえで、質問に答えていくだけでその書類（RFP＝提案依頼書）が作れる無料ツールを、実際の設問と出来上がりを一部公開しながらご案内します。

1. なぜ「何を書けばいいかわからない」のか

書けない理由は、知識が足りないからではありません。書くべき項目の一覧を、誰も渡してくれないからです。

引っ越しを思い浮かべてください。業者のサイトを開けば、「いつ」「どこからどこへ」「何人家族か」「エレベーターはあるか」と、聞かれることが最初から画面に並んでいます。だから見積もりを頼むのに迷いません。上から埋めていけば終わりです。専門知識は要りません。

ところがシステム開発には、この入力フォームにあたるものが、発注者側に渡されていません。だから毎回、白紙のメールから書き始めることになります。

そして白紙から書き始めた文章は、たいてい「作りたいものの説明」だけになります。開発会社が見積もるために本当に必要な情報——誰が使うのか、いつまでに要るのか、いくらまでなら出せるのか、今は何に困っているのか——が抜け落ちる。結果、見積もりが出てこないか、幅の広すぎる概算しか返ってこないことになります。

2. 専門用語が通じないのは、発注者のせいではない

開発会社が専門用語で質問してくるのは、悪意でも不親切でもなく、社内で普段使っている言葉のまま話しているだけです。ただ、それを受ける側からすると、質問の意味がわからない以前に「これは自分が決めることなのか、開発会社が決めることなのか」の切り分けすらつきません。

原則として、次のように分けて考えると整理がつきます。

中央の列は、答えられなくて構いません。発注者が最初に整理すべきなのは右の列で、これらは社内の事情を知っている人にしか答えられないことです。

3. 発注者が伝えるべきなのは「技術」ではなく「事情」

前章の右の列を、もう少し具体的に言い換えます。開発会社が知りたいのは、次のようなことです。

• 今、その業務は誰が、どうやってやっているのか
• そのやり方の何が困っているのか（時間がかかる／ミスが出る／属人化している、など）
• それが解消されたら、何がどう良くなるのか
• 使うのは何人か、社内か社外か
• いつまでに動いていないと困るのか、その理由は何か
• 予算はどのくらいの規模を想定しているのか

これらは技術の話ではありません。社内の事情の話です。そして、この情報がないまま見積もりを作ると、開発会社は最悪の場合を想定してリスク分を上乗せするか、逆に安く見積もって後から追加費用が発生することになります。

4. まず相談するために渡す情報は、この7つ

発注時に開発会社へ渡す書類を、一般にRFP（提案依頼書）と呼びます。名前は仰々しいですが、中身は「提案と概算見積もりを出してもらうために必要な情報を、あらかじめまとめた紙」以上のものではありません。

項目は、おおむね次の7つのグループに整理できます。

ここでひとつ、先にお断りしておきます。これは「これだけ書けば要件がすべて固まる」という意味ではありません。実際の開発では、非機能要件、セキュリティ、外部システム連携、データ移行、権限設計、運用体制、法令や社内規定への対応など、詰めるべきことがこの先にたくさんあります。それらは契約後の要件定義フェーズで、開発会社と一緒に詰めていくものです。

ここで、金額についても先に整理しておきます。システム開発の見積もりは、1回では確定しません。提案時に出てくる金額と、最終的に支払う金額は、出るタイミングも性質も違います。

つまり、RFPを渡して返ってくるのは概算見積もりです。これは手抜きではなく、作るものが確定していない段階では、それ以上の精度を出しようがないためです。要件定義で「何を作るか」が決まって初めて、確定見積もりが出せます。

この7つは、その手前——「相談していい状態」「相見積もりを取れる状態」にするための7つだとお考えください。

5. 書けないところは「わからない」のままでいい

ここで多くの方が身構えます。「7項目も埋められない」と。

埋まらない項目があって当然です。

たとえば予算。社内でまだ議論していない段階なら、金額は書けません。その場合、無理に数字を書く必要はなく、「未定」「相談したい」と書いてあるほうが、開発会社としてはよほど扱いやすい情報です。「書いていない」と「決まっていないと書いてある」は、受け取る側にとってまったく別の情報だからです。

RFPは、完璧に埋めるための書類ではなく、わかっていること・わかっていないことを仕分けするための書類です。

6. で、実際どんな質問をされるのか（一部公開します）

全項目を答えても、目安は10〜15分です。ここまでの7項目を、質問に答えるだけで書類の形にできるツールを、STVテックでは「かんたんRFP作成サイト」としてご用意しています。1章で触れた「引っ越し業者の見積もりフォーム」にあたるものだとお考えください。画面は全8ステップで構成されていますが、実際に何かを答えるのは前章の7項目、つまり最初の7ステップまでです。8ステップ目は入力内容を確認して生成するだけで、新たに何かを聞かれることはありません。

ただ、この手のツールで一番気になるのは「で、実際どんな質問をされるの？」だと思います。使ってみたら答えられない質問ばかりだった、では時間の無駄です。

そこで、入力の7ステップで実際に聞かれることを、一部公開します。答えられそうかどうかを、ここで判断してみてください。

の箇所は伏せています。全項目は実際の画面でご確認いただけます。

7. 一行の要望が、17項目のRFPになる

機能の説明よりも、実際に何がどう変わるのかをご覧いただくのが早いと思います。以下は、実際にツールで作成したものです。

この案件では、17項目のうち11箇所が「わからない」のままでした。半分以上が埋まっていない状態でも、書類としては成立します。大事なのは空欄ではなく「わからない（提案時にご提案いただきたい）」と印字されることで、受け取った開発会社は、そこが検討対象だと理解できます。埋められなかった箇所が多いほど「相談すべきこと」が明確になる、と捉えてください。

8. まとめ

本記事では、「開発会社に何を伝えればいいかわからない」という発注者の課題を整理しました。

システム開発の発注で最初につまずくのは、技術ではなく「何を伝えればいいかわからない」という一点です。そこさえ越えれば、あとは開発会社の仕事になります。