同じ依頼について2つの説明を考えてみます。
説明A:
「新しいウェブサイトが必要です。価格と納期を教えてください。」
説明B:
「B2Bサービス企業向けのウェブサイトが必要です。目的は質の高い問い合わせを増やすことです。現在14ページ、既存コンテンツ、ビジュアル・アイデンティティがあります。新しい版のデザインと実装、既存URLの維持、モバイル端末への完全対応、基本的な引き継ぎ文書を希望します。予約システムは変更せず、対象外です。10月に開始し、11月末までに公開したいと考えています。」
2つ目の説明も、すべての問いに答えているわけではありません。技術や作業方法も指定していません。
それでも専門家に、はるかに揃った判断材料を与えています。
全員が違う範囲を見積もっているなら、提案を比較しているのではありません。似た名前の別々の案件を比較しています。
意味のある見積もりと提案比較には、明確な要求が必要です
現在の英国Sourcing Playbookは、明確な仕様には、提案者が参加するかどうかを十分な情報に基づいて判断できるだけの情報が必要だとしています。また、要求事項について共通理解がなければ、提示価格を買い手が想定する費用や期待結果と結びつけることが難しいと指摘しています。 [1]
Government Commercial Functionはさらに直接的に、良い仕様は供給者が商品やサービスの費用を正確に算定できる情報を含み、買い手が同等の条件で提案を比較できるようにすべきだと説明しています。 [2]
一方、英国Digital, Data and Technology Playbookは、解決策を過度に指定することにも警告しています。利用者、問題、期待結果に集中し、供給者が効果的な実現方法を提案できる余地を残すことを勧めています。 [3]
したがって結論は 「すべてをできる限り細かく書く」 ではありません。より良い原則は:
すべての提案で共通でなければならないことを正確に書き、能力ある専門家が合理的に設計できる部分まで決めつけないことです。
提案を比較可能にするには、何を共通化する必要があるのか?
専門的な提案が完全に同じになることはありませんし、それを目指す必要もありません。
比較可能とは、専門家が おおむね同じ前提条件で同じ問題 に答えていることです。
そのため、少なくとも次の理解は近い状態にします。
- 目的,
- 範囲,
- 現在の出発点,
- 期待する結果,
- 重要な制約,
- 日程,
- 顧客側の責任,
- 価格の示し方,
- 提案を評価する基準.
一方、次は異なって構いません。
- 提案する進め方,
- 作業順序,
- 方法,
- チーム構成,
- 使用する道具,
- 段階分け,
- リスクを減らす方法.
こうした違いはむしろ価値があり、見える状態にしておくべきです。
依頼内容に入れておきたい12の情報
1. 解決したい問題
機能一覧ではなく、問題から始めます。
例えば:
「一覧画面、通知、レポートがあるアプリが必要です。」
よりも:
「現在5人が表計算とメールで業務を管理しています。案件の現在状態、担当者、次に必要な作業を把握しにくい状態です。手作業の追跡を減らし、最新状態を一か所で確認できるようにしたいです。」
2つ目の説明は、どんなアプリを作るかまでは決めていません。
しかし専門家は なぜこの案件が必要なのか を理解できます。
2. 期待する結果
成果重視サービスに関するFederal Acquisition Regulationは、作業方法や提供時間ではなく、主に必要な結果で仕事を説明することを推奨しています。目標記述の最低要素には、目的、範囲、背景、必要な結果、運用上の制約などが含まれます。 [4]
そこで、仕事が終わった時に何が可能になっているべきかを書きます。
例:
- 利用者が定めた手続きを自力で完了できる,
- チームがすべての案件の現在状態を確認できる,
- 顧客が優先順位付きの分析を受け取る,
- システムが新しい環境へ移され、合意した基準で動作する,
- 作成物が指定した媒体で公開できる状態になる.
結果は、双方が仕事の方向を理解できる程度に具体的であるべきです。
ただし、市場、利用者の行動、その他供給者が管理できない要因に左右される事業成果まで保証する必要はありません。
3. 現在の状態と開始地点
同じ最終目的でも、どこから始めるかによって必要な作業量は大きく変わります。
次を伝えると役立ちます。
- すでに何があるか,
- 何が動いていて残すべきか,
- 何が動いていないか,
- 元ファイルがあるか,
- 文書があるか,
- 移行すべきデータがあるか,
- 既存システム上で作業する必要があるか,
- すでに用意できている素材は何か.
「新しいウェブサイト」 は、ゼロから作ることも、内容、URL、分析設定、連携、データを保ったまま既存サイトを作り直すことも意味します。
見た目の最終結果が似ていても、作業は異なります。
4. 必須範囲と案件の境界
専門家が問題のどの部分を見積もるべきか推測しなくて済むようにします。
例えば:
対象内:
- 現在の仕組みの分析,
- 新しい画面のデザイン,
- 実装,
- 定めたデータ範囲の移行.
対象外:
- 新規コンテンツ作成,
- ライセンス購入,
- 最初の1か月以降の保守,
- 決済システムの作り直し.
世界銀行のTerms of Reference例は、コンサルティングサービスの要求と期待を明確に示し、具体的な案件に合わせることの重要性を強調しています。 [5]
2つの作業が自然に関連し、一方にもう一方も含まれると誤解しやすい場合ほど、境界は重要です。
5. 必ず受け取りたい具体的な成果物
特定の資料や出力を期待するなら、具体的に書きます。
例えば:
- 動作する仕組み,
- 元ファイル,
- 報告書,
- 文書,
- ビジュアルデザイン,
- 素材一式,
- 環境設定,
- 研修,
- 録画,
- コードとアクセス権の引き渡し.
「デザイン」, 「分析」, 「実装」 という言葉は、人によって異なる意味で使われることがあります。
主な成果物を共通に示すことで、一方の提案が大幅に多くを含むのに、似たサービス名のため違いが見えないという状況を避けやすくなります。
6. 無視できない制約と条件
7. 顧客側が提供する資料、アクセス、責任
専門家は、どの程度の協力を前提に提案できるのか知る必要があります。
提供できるかどうかを明示します。
- 意思決定者,
- システムへのアクセス,
- 既存資料,
- データ,
- テスト用アカウント,
- チームからの情報,
- 利用者へのアクセス,
- コンテンツ,
- 定期的な会議,
- 定めた期間内の回答.
まだ何を提供できるか分からない場合、それを正直に書くことにも価値があります。
データ、資料、人へのアクセス不足は、方法、費用、日程を変えます。これは小さな事務上の話ではなく、提案が成立する条件の一部です。
8. 日程、重要日、スケジュールの柔軟性
すべての日付が同じ意味を持つわけではありません。
次を区別します。
- 希望開始日,
- 動かせない期限,
- 外部行事に連動する日,
- 目安の日,
- 一定の順序で進める必要がある段階.
期限が本当に動かせないなら理由を書きます。
柔軟なら、そのことも書きます。
これにより専門家は、すべての日付を絶対条件と考えるのではなく、別の範囲、順序、段階的な進め方を提案できます。
9. 予算、または少なくとも価格をどう比較したいか
顧客が常に予算全額を開示すべきだという一つのルールはありません。
状況に応じて、次のような情報を出せます。
- 上限予算,
- 予算幅,
- 第1段階の予算,
- まず範囲提案を受けてから価格を求めること,
- 価格内訳の希望形式.
比較では、専門家が似た構造で費用を示すことが特に重要です。
例えば:
「分析、デザイン、実装、月次保守の価格を分けて示してください。含まれない外部サービス費用も明記してください。」
各合計に含まれるものが違う4つの金額より、この形式の方がはるかに比較しやすくなります。
10. 重要な不明点、前提条件、リスク
書かなかったからといって、不確実性がなくなるわけではありません。
次が分からないなら明示します。
- 移行すべきデータ量,
- 外部インターフェースが必要な処理に対応するか,
- すべてのコンテンツが準備できるか,
- 現在のコードを合理的に拡張できるか,
- 必要な承認が期限内に得られるか.
GAOの信頼できる費用見積もりガイドは、明示した前提条件とリスク、不確実性分析の重要性を強調しています。 [6]
良い専門家なら:
- 予備を持たせる,
- 調査段階を提案する,
- 複数案を価格化する,
- 価格変更条件を示す,
- 現時点で正直に出せない精度を装わない,
といった対応ができます。
明示された不明点は、隠れた前提より優れています。
11. 価格だけではない選定基準
何を重視して決めるか分かっているなら、提案作成前に伝えます。
例えば:
- 提案方法の適合性,
- 類似問題の経験,
- 過去の仕事の証拠の質,
- 日程の現実性,
- 対応可能性,
- リスク管理方法,
- 実際に担当する人の能力,
- 価格,
- 保守費用,
- コミュニケーションの質.
世界銀行の現在のRated Criteria資料は、価格以外の基準として、方法と作業計画の質、リスク管理、実績と能力、主要担当者などを挙げています。基準は対象の調達に合わせ、相対的な重要性に応じて重み付けされます。 [7]
小さな案件で正式な採点が必要という意味ではありません。
依頼を出す前に、次へ答えられれば十分です。
「価格以外に、何が一つの提案を私にとって他より良くするのか?」
12. 共通の回答形式
本当に提案を比較したいなら、全員に同じ基本質問へ答えてもらいます。
例えば:
1. 問題と期待結果をどう理解していますか?
2. どのような進め方を提案しますか?
3. 提案には具体的に何が含まれますか?
4. 何が除外されますか?
5. どの前提条件を置いていますか?
6. 日程はどうなりますか?
7. 顧客から何が必要ですか?
8. 主なリスクは何ですか?
9. 価格はいくらで、具体的に何を含みますか?
10. この案件に関連する類似経験や仕事の証拠は何ですか?
公共調達では、回答、基準、価格提示形式を揃えることで、提案を共通基盤で評価しやすくします。Government Commercial Functionは、正確な費用算定と同等条件での比較に十分な情報を与える必要性を強調しています。 [2]
共通形式は専門家の違いを消すものではありません。同じ場所で違いが見えるようにするものです。
予算は伝えるべきか?
依頼の目的によります。
予算を伝えると役立つ場合:
- 利用可能な予算に合わせて範囲を調整できる,
- 一定の上限内で最善案を提案してほしい,
- 財務条件に合わない提案を早く除外したい.
全予算を伝えないことが合理的な場合:
- まず適切な範囲について独立した意見がほしい,
- 現実的な費用をまだ知らない,
- 異なる解決モデルを比較している,
- 価格収集の方法が別に決まっている.
問題は予算を出さないこと自体より、どのような価格回答を求めているか示さないことです。
専門家は、総額、幅、複数案、段階別価格、より正確な見積もりに必要な前提条件のどれを出すべきか分かる必要があります。
より専門的に見せるためだけに、不明点を隠さない
良い依頼内容が、すべての問いに答える必要はありません。
正直に次のように書けます。
- 「現在のシステムを安全に拡張できるか、まだ分かりません。」,
- 「移行が必要なレコード数を正確には把握していません。」,
- 「第2言語版を第1段階に入れるかまだ決めていません。」,
- 「最善の選択肢を決める支援が必要です。」
これは有用な情報です。
不確実性は提案の作り方に影響すべきで、文書から消すべきではありません。
状況によっては、最初に最も適切なサービスは全面実装ではなく、判断、より正確な範囲、信頼できる見積もりで終わる短い調査段階かもしれません。
例: より短くても、より良い提案につながる説明
提案を比較しにくくする7つの失敗
1. 専門家ごとに違う情報を渡す。
2. 問題と目的を説明せず機能だけ並べる。
3. すでにあるものを説明しない。
4. 後から実施方法を変える制約を隠す。
5. 何を含むべきか示さず総額だけ求める。
6. 自分でも事前に決めていない基準で提案を評価する。
7. 問題を詳しく説明することと、解決策を詳しく指定することを混同する。
依頼を送る前の14の確認質問
1. 想像した解決策だけでなく、問題そのものを明確に説明したか?
2. 求める結果は明確か?
3. 専門家は現在状態を理解できるか?
4. 何を残すべきか明確か?
5. 最初の範囲の境界は明確か?
6. 主な成果物を示したか?
7. 本当の制約を書いたか?
8. 顧客側で何を提供するか明確か?
9. 日程とその柔軟性を書いたか?
10. 価格形式は提案比較に使えるか?
11. 重要な不明点を明示したか?
12. 価格以外に何を評価するか分かっているか?
13. 全専門家が似た質問に答えるか?
14. 自分が考えたものより良い解決策の余地を残したか?
最良の依頼内容は専門家にすべてを伝えるのではなく、必要なことをすべて伝える
良い依頼内容には、一見すると相反する2つの目標があります。
複数の専門家が同じ問題を見積もれるよう 十分に具体的 であること。
同時に、それぞれが独自の、より良いかもしれない方法を提案できるよう 十分に開かれている ことです。
役立つ順序は:
問題 -> 結果 -> 現在状態 -> 範囲 -> 成果物 -> 制約 -> 顧客責任 -> 日程 -> 価格形式 -> 不明点とリスク -> 選定基準 -> 共通回答形式.
提案を受け取ってから、一人は案件全体、別の人は分析だけ、三人目は追加連携まで想定していたと分かったなら、問題は見積額そのものではないかもしれません。
全員に同じ文章を送っていても、実際にはそれぞれが別の依頼を受け取った可能性があります。
出典と参考資料
[1] UK Government - The Sourcing Playbook
出典を開く
[2] Government Commercial Function - How to write a procurement specification
出典を開く
[3] UK Government - The Digital, Data and Technology Playbook
出典を開く
[4] U.S. Federal Acquisition Regulation - Subpart 37.6, Performance-Based Acquisition
出典を開く
[5] World Bank - Sample Consultants Terms of Reference
出典を開く
[6] U.S. Government Accountability Office - Cost Estimating and Assessment Guide, GAO-20-195G
出典を開く
[7] World Bank - Rated Criteria
出典を開く
方法論上の注記: 出典は主に公共調達と費用管理の文脈にあります。民間の専門家市場へ直接適用する規則として扱っていません。本記事は、要求の明確さ、結果への集中、前提条件とリスクの明示、比較可能な価格情報、価格以外の品質基準による評価という、各出典が実際に支える原則だけを使用しています。
