システム開発の発注準備は何から？依頼・質問・提案比較の順を決める

発注の準備は、社内で確かめる仕事から並べる

ここで扱うのは、開発会社が設計やプログラミングをする工程表ではありません。発注側が、相談の前提を集め、候補先の回答を確かめ、社内で選ぶための段取りです。「資料を作る」「提案をもらう」だけでは、その間に必要な確認が抜けてしまいます。

受注入力と在庫更新の改修なら、発注担当は、どの現場に今回の対象を確かめるのかを先に決めます。IT担当へは、どこが未確定なのかを依頼資料へ残してもらいます。候補先から質問が来たときには、その内容を判断できる人へつなぐ仕事も必要です。

提案依頼書（RFP）

開発会社に、依頼したい仕事と条件を伝え、提案を求めるための資料です。本文では、作る項目の一覧よりも、誰と確認し、どの版を渡すかという作業を扱います。

提案の評価

届いた提案が、同じ依頼条件にどう答えているかを確かめる作業です。受領したことや、説明を聞いたこととは分けて記録します。

社内の採否判断

評価内容と未回答を踏まえ、進める案・保留する案を社内の権限に従って決めることです。誰が判断するかは、自社の規程と実際の役割から確認します。

矢印は、前の確認が次の作業へどうつながるかを表しています。全作業を一列に並べて終わるという意味ではありません。質問への回答で対象が変われば、依頼資料や提案の比較条件へ戻って見直します。

依頼前に、窓口と確認する人をそろえる

最初に、社内の発注・購買の手続きがあるかを確認します。候補先を選ぶ方法、外部へ渡す資料の扱い、提案を評価する人、決裁する人が既に決まっている会社もあります。この記事の流れに合わせて、既存の手続きを置き換える必要はありません。

この架空例では、候補先の質問を受け付ける窓口は発注担当とする案です。ただし、質問を受け取れることと、その内容へ回答できることは別です。受注入力の実際の運用は現場、在庫更新の仕組みはIT担当など、内容を確認できる人へ相談する段取りを用意します。

• 発注担当は、受け取る・依頼する・記録する仕事をそろえる

  候補先からの質問を、現場やIT担当へ渡す窓口を決めます。資料の版、質問、回答の確認状況をまとめる場所も相談します。窓口にしただけで、業務内容や技術的な判断まで任せたことにはしません。

• 現場とIT担当には、何を確認してほしいかを具体的に頼む

  「依頼書を見てください」ではなく、「受注入力と在庫更新のうち、今回相談する範囲と未確定の境目を確かめてください」と依頼します。担当がまだ分からない項目は、誰へ担当を確認するかを残します。

• 共通回答を返す人と、社内で判断する人を確かめる

  下書きには、どちらも未確認として残っています。確認した内容を候補先へ伝える役割と、提案の採否を決める役割を、社内の責任者に尋ねます。同じ人が担う場合も、それぞれ何を確認するかは書き分けます。

依頼資料そのものの書き方や、完成を確かめる条件の記入例は、開発会社へ何を伝えるかを整理するRFPの作り方で確認できます。本稿では、その資料を誰と整え、質問や評価へどう渡すかを続けて説明します。

二つの下書き条件から、次の作業を決める

依頼範囲の下書きがある案は、現場と範囲を確かめます。担当境界が未確定の案は、その箇所を明示して共通の質問案を作ります。下書きに何が書かれているかと、次に誰へ何を頼むかを同じ項目で比べてください。

次の二案は、同じ架空の受注改修について、準備の条件が異なる下書きです。一方を直して他方になった記録ではなく、どちらも実際に候補先へ送付したり、提案を受領したりした事例ではありません。「開発会社A・B」は、架空の相談候補の名前です。

範囲を先にそろえる案では、下書きと現場の理解を照合する

受注入力と在庫更新の対象範囲を書いてあっても、現場が確認したとは限りません。発注担当は、下書きのどの部分を現場へ見せ、誰の回答で範囲をそろえるかを決めます。その確認が済んだかを残してから、候補先へ示す資料の版を確かめます。

不明点を残す案では、相談したい範囲を明示する

在庫更新の担当境界が未確定なら、その点を伏せたまま完成した仕様として渡しません。「この境目を整理するための相談なのか」「開発の提案まで求めるのか」を、依頼の目的と一緒に説明します。候補先へ協力を求める範囲、必要な社内確認、その後に見積や提案を見直す条件を尋ねます。

IPAの『ストーリーで学ぶ要件定義実践入門』PDF33〜35ページも、要件を詳しく書けない場合にその旨を示して協力を依頼する考え方と、同じRFPで提案を求める進め方を説明しています。この資料の例を、すべての会社の固定日数や必須の契約順序へ置き換えることはしません。

依頼と確認の順序を、日程へつなぐ

日程を組むときは、作業名の横へ日付を入れる前に、次へ進める条件をそろえます。例えば、提案を比べるためには、何を共通条件として示したかが必要です。共通の回答を返す前には、誰がその内容を確かめるかが必要になります。

1. 現場確認の結果を、依頼資料の下書きへ反映する

   残すものは、今回の対象と未決定、確認した人、確認待ちの内容です。書いた人の自己判断だけで、現場の了承済みにしません。

2. 候補先へ示す版と、質問の受け方をそろえる

   残すものは、依頼資料の版と保存先、質問の窓口、回答を確認する手順です。候補先ごとに異なる前提が伝わった場合は、どこが違うかを先に整理します。

3. 質問への回答を確認し、共通の説明を更新する

   残すものは、何の質問へ誰が回答内容を確認し、どの資料に反映するかです。対象範囲が変わるなら、その変更を比較条件にも反映します。

4. 提案を受け取り、同じ前提で評価する

   残すものは、受領した提案の版、回答済みの項目、未回答とその影響です。提案を開いたことだけで、評価が終わったことにはしません。

5. 社内の判断者へ、評価と残る条件を渡す

   残すものは、採否を判断するための資料と、まだ誰に何を確認するかです。採用方針を判断する作業と、発注条件を整えて手続きを進める作業を、それぞれの担当へつなぎます。

この順を置いた後に、社内の判断が必要な時期、現場やIT担当の確認可能な時期、候補先が回答・提案を用意するために必要な時間を聞いて、実際の日程を調整します。開始日も所要日数も、この例では未確認です。一律の「何日で発注できる」という数字は置きません。

候補先の質問を受け、共通の回答へまとめる

質問は、発注担当の窓口へ集める案にします。質問を受け取ったら、何についての質問か、どの依頼資料の版を読んだものか、誰の確認が必要かを並べます。発注担当が答えを推測して返すより、内容を確かめる人へ具体的に頼める形が役立ちます。

回答内容を確認できたら、依頼条件として全候補に関係する部分を共通の説明へ反映します。候補先ごとの個別メールだけに条件が残ると、片方は更新前、もう片方は更新後の条件で提案することがあります。更新した箇所と参照する版が分かるようにし、各候補先がどの条件で提案するかを確かめます。

共通にするのは、発注側が示す依頼条件や、その解釈をそろえる回答です。候補先が独自に示した提案や他社の秘密情報を、そのまま別の候補へ回すことではありません。何を外部へ示せるかは、自社の資料の扱いと依頼条件に合わせて確認します。

回答をまとめる担当が未確認なら、発注担当はまず社内の責任者へ役割を尋ねます。質問の受付や、回答が必要な点の整理は進められますが、未確認の内容を自社の確定回答として扱う作業は保留します。どこまで済み、何が待ちになっているかを分けると、準備全体を止めずに次の依頼を出せます。

提案が届いたら、同じ版と条件で評価する

二つの架空案では、提案の受領自体が未確認です。ここからは、今後、提案が届いた場合に行う作業を説明します。既に提案を受け取って評価した結果ではありません。

最初に、その提案がどの依頼資料と共通回答を前提にしたものかを確かめます。発注担当は受領状況と資料の版を記録し、内容を評価する人へ渡します。今回相談したい仕事が含まれるかは現場やIT担当と確認し、費用や社内の条件は判断できる担当へつなぎます。

• 対象範囲が、同じ依頼条件へ答えているか

  受注入力と在庫更新のうち、含む部分・含まない部分・まだ確かめる部分を区別します。候補先が別の方法を提案した場合には、依頼条件との違いを説明してもらいます。

• 自社に必要な確認作業が、分かる形になっているか

  現場が何を説明し、どの担当が何を確認する前提かを読みます。候補先の作業だけでなく、発注側が用意する資料や回答も、担当者へ渡せるかを確かめます。

• 未回答が、評価のどこへ影響するか

  在庫更新の担当境界が不明なら、その範囲の提案を確定した条件として比較できません。未回答の確認先と、回答後に見直す資料を残します。

例えば、候補先が更新前の依頼資料を前提としていた場合は、更新箇所を示し、提案の見直しが必要かを尋ねます。一方だけを新しい前提で評価せず、双方の版と回答状況をそろえます。回答がない欄を、対応可能・費用ゼロ・自社の作業不要として埋めることはしません。

費用そのものの差を読む段階では、システム開発の見積を同じ作業範囲で比べる方法を確認してください。本稿の役割は、その比較に使う資料と回答を、発注側の作業順に沿ってそろえることです。

社内で選ぶ前に、判断者と未回答を確かめる

提案を比べたら、誰が社内で採否を決めるかを確かめます。担当者が評価表を作る役割と、会社として進める判断をする役割が同じとは限りません。この例では判断者が未確認なので、経営者、発注の責任者など、自社の手続きを分かる人へ確認します。

判断を頼む資料には、候補先の資料だけを付けるのではなく、どの依頼条件で比較し、誰が何を確かめ、何が未回答かを一緒にまとめます。「こちらがよさそうです」という感想だけでは、判断者が条件の違いや自社に残る仕事を確かめにくくなります。

未回答が今回の目的や対象範囲、費用の確定、自社が用意できる作業へ影響するなら、その部分を確かめる前に採否を確定扱いにしません。確認先、必要な回答、回答後に誰が評価し直すかを残し、判断者へ保留する範囲も説明します。

社内の採用方針を判断した後も、発注条件の確認、必要な手続き、契約や着手の確認は、自社の規程と担当に従って進めます。資料を整理したことを、実際の発注・契約・着手が済んだ証拠として使いません。

回答遅れや条件変更があったら、影響する作業を組み直す

予定どおり回答がそろわない場合は、遅れている仕事と、その回答を使う仕事をつなげて見ます。回答が必要な範囲の提案評価は待ちながら、影響しない資料の整理や、別の現場確認を進められる場合があります。準備全体を一括して完了・未完了のどちらかにせず、作業ごとに整理します。

• 現場やIT担当の確認が遅れる

  発注担当は、どの質問が誰の回答待ちかを明示します。候補先へ前提を確定したと伝える作業や、その前提で提案を評価する作業へ影響するなら、回答予定と次の依頼を調整します。

• 対象範囲や依頼条件が変わる

  どの資料を直し、どの候補先への説明と提案を見直すかを確認します。共通回答と比較条件を更新し、影響する評価を再確認してから、社内判断へ渡します。

• 要件を整理する支援から相談することになる

  その相談で頼む仕事、用意する資料、自社が確認する内容を別に明らかにします。相談の結果が出る前に、開発全体の費用・日程・契約まで確定したものとして扱わず、次の提案や見積に必要な条件を尋ねます。

• 判断する人が決まっていない

  社内の発注・決裁の手続きを確認します。提案資料の整理や質問事項の洗い出しを進めながら、誰へ採否を頼むかを確かめ、担当者の自己判断を会社の承認済みに置き換えません。

回答が得られたら、依頼資料の版、共通回答、提案の比較条件、残る確認、次の担当作業を一組で見直します。予定日だけを動かすよりも、何の前提が変わり、誰が何を確認し直すかを説明できる状態にします。