曖昧さのない明確なサービス範囲: 顧客が何を購入するのか分かる10の要素

成果重視のサービスに関する現在の米国Federal Acquisition Regulationは、作業方法や単なる時間数を指定するよりも、必要な結果によって仕事を説明することを推奨しています。また、測定可能な実績基準を求め、目標記述には目的、範囲、履行期間と場所、背景、必要な結果、運用上の制約などを含めるとしています。 [1]

英国政府のDigital, Data and Technology Playbookも、明確で結果重視の仕様を推進しています。技術的な解決策を先に決めるのではなく、利用者と解決すべき問題に集中することを明示的に推奨しています。 [2]

英国の現在のリスク配分と価格設定に関するガイダンスは、実績指標は測定可能かつ客観的であるべきで、供給者は自らが実際に影響を与えられる結果について責任を負うべきだとしています。 [3]

これらは公共調達の資料であり、すべてのサービスに共通するひな形ではありません。ただし、非常に有用な原則を示します。良い業務範囲は、期待する結果、その評価方法、責任の限界を明示すべきです。

良い説明は同時に次の3者を助ける必要があります。

顧客 - 何を受け取り、何を受け取らず、自分側で何を用意すべきか理解する。

専門家 - 責任の境界、前提条件、新しい依頼が範囲変更になる地点を定義する。

双方 - 合意した仕事が完了したと合理的に判断する方法を共有する。

説明がこのうち1つの役割しか十分果たしていなければ、争いや解釈の違いが残る可能性があります。

まず、なぜそのサービスが必要なのかを説明します。

顧客が目的を理解していない段階で、ツールや作業の一覧から始めないようにします。

例えば:

「分析、レポート、イベントを設定します。」

よりも:

「フォームのどの段階で利用者が最も離脱するかを信頼できるデータで把握し、チームが改善すべき箇所を特定できる状態にすることが目的です。」

の方が明確です。

これは、解決策を先に指定するのではなく、ニーズと結果を説明するという英国Digital, Data and Technology Playbookの考え方と一致します。 [2]

目的は 「なぜか」 に答え、結果は 「仕事が終わった時に何が存在するか、何が実現しているべきか」 に答えます。

結果の例:

• 完成した文書,
• 動作する機能,
• 適用済みの設定,
• 結論を含む完了した調査,
• 準備済みの素材一式,
• 定めたまとめを伴う実施済みセッション.

成果重視のサービスでは、FARは要求事項を主に必要な結果によって記述し、実施方法だけで定義しない考え方を採っています。 [1]

これは、専門家が管理できない事業成果まで保証すべきという意味ではありません。合意範囲でキャンペーンを開始することは約束できますが、売上30%増を保証することは供給者の管理外の多くの要因に左右される場合があります。

業務範囲には、合意に含まれる具体的な作業部分を記載します。

例えばウェブサイト案件なら:

• 現在のサイトの分析,
• 情報設計の作成,
• 定めた数の画面のデザイン,
• モバイル版,
• 承認済みデザインの実装,
• 基本的な引き継ぎ文書.

最も長い一覧を作ることが目的ではありません。開始前の工数と期待値に大きく影響する項目を明示することが目的です。

業務範囲は何をするかを説明し、納品物は 顧客が実際に何を受け取るか を説明します。

例:

• 元ファイル,
• 定めた形式の報告書,
• 動作するモジュール,
• コードの保管場所,
• 画像素材一式,
• 録画,
• 文書,
• 推奨事項一覧,
• 設定済み環境へのアクセス.

結果の形式が重要なら明示します。「報告書」 は2ページの文章かもしれませんし、分析、優先順位、事例を含む詳細文書かもしれません。名称だけでは十分でないことがあります。

受入基準は、合意した結果が要求どおりに提供されたと何をもって判断するかを示します。

例えば:

• 完全性,
• 合意仕様への適合,
• 指定形式,
• 指定端末や環境での動作,
• 特定分類の不具合数の上限,
• 納期,
• 定めた品質指標.

FARは成果重視のサービス契約における実績基準が測定可能であり、履行を評価できるよう構成されることを求めています。 [1]

英国のリスクに関するガイダンスも、指標は客観的で、供給者が影響を与えられる結果に関連すべきだとしています。 [3]

したがって 「顧客が満足すること」 は、具体的で観察可能な結果に結びついた基準よりはるかに曖昧です。

サービスは相手側の行動に依存することがよくあります。

顧客が次を提供する必要があるか明示します。

• システムへのアクセス,
• コンテンツや素材,
• データ,
• ブランド情報,
• 判断と承認,
• 連絡担当者,
• テスト環境,
• 定めた期間内の回答.

顧客側の情報不足で作業が止まる可能性があるなら、その点は明確にすべきです。

専門家が実際には管理できない行動まで管理しているかのように、納期責任を書くべきではありません。

価格や日程は、一定の前提が満たされている場合にのみ有効なことがあります。

例:

• 既存データベースが利用可能で正常に動作する,
• 顧客が提供素材の必要な権利を持っている,
• 外部システムに動作する接続手段がある,
• 過去データの移行が不要である,
• 言語数が事前に決まっている,
• 指定された1人が意思決定する.

GAOの信頼できる費用見積もりに関するガイドは、明確な範囲、技術的基準、ルールと前提条件、リスクと不確実性の分析を、健全な見積もりの重要な要素として扱っています。 [7]

小規模サービスが大規模計画向けの手続をそのまま採用する必要はありません。ただし原則は有用です。見積もりが、実際には成立しない可能性のある条件に依存するなら、それを明示します。

除外事項は弱い提案の印ではありません。むしろ約束の境界がよく定義されていることを示す場合があります。

顧客がサービスに含まれると誤解しやすいものは、含まれないと明示する価値があります。

例:

• ライセンス購入,
• コンテンツ作成,
• 有料画像,
• 翻訳,
• 公開後の保守,
• 別システムの作業,
• 無制限の修正,
• 外部サービス費用.

専門家が行わないことをすべて列挙する必要はありません。最も有用なのは、顧客が現実的にサービスの一部だと考えそうな項目の除外です。

進行が顧客の承認や素材提供に依存するなら、日程は 「約2週間」 以上の情報を示すべきです。

例えば:

• 何をもって日程を開始するか,
• 中間段階があるか,
• どの判断で各段階を終了するか,
• 顧客の返答が日程に影響する場合の回答期限,
• 遅延の通知方法,
• 最終受入の方法.

簡単なサービスなら数文で十分です。大きな案件では段階を定めることで、双方が 何が完了し、次に何が必要か を理解しやすくなります。

良いサービス説明は、作業開始後に新しい要求が出た場合の扱いを説明します。

実務上のルールは簡単でも構いません。

「記載された範囲外の作業は、開始前に新しい範囲、日程への影響、追加価格がある場合はその金額を確認します。」

また、次を明示すると有用です。

• 価格方式,
• 価格または算出方法,
• 支払条件,
• 発生し得る追加費用,
• 追加修正回数の扱い.

これで変更がなくなるわけではありません。変更を、当初の約束が気付かないうちに広がることではなく、意識的な判断にします。

明確な業務範囲だからといって、専門家の作業手順をすべて指定する必要はありません。

英国Digital, Data and Technology Playbookは解決策を過度に指定しないよう注意し、結果重視の仕様によって供給者がより効果的な解決方法を提案できる余地を残せると説明しています。 [2]

FARも、仕事のやり方を厳密に指定するより、必要な結果を説明する考え方を優先します。 [1]

そのため:

「ウェブサイトは指定された端末で合意した利用シナリオを正しく実行できること」

は、技術自体が重要な制約でない場合、実装方法を細かく指定するより適切な要求になり得ます。

もちろん、安全性、法令遵守、連携、技術標準のために方法そのものが重要なサービスもあります。その場合は方法を記載すべきです。

範囲を定める際は、次を区別することが重要です。

専門家の直接的な作業結果 と 他の要因にも左右される事業成果.

専門家が約束できる例:

• 合意した範囲でキャンペーンを準備し開始する,
• 分析を実施する,
• 定めた数の素材を納品する,
• 定義した基準を満たす機能を実装する.

一方、売上、顧客数、検索順位など、市場、予算、商品、顧客側の行動、外部システムに左右される成果の保証には、より慎重である必要があります。

英国の現在のリスク配分ガイダンスは、供給者は自らが影響できる結果について責任を負うべきだと明示しています。 [3]

良い説明は責任を弱めません。実際に管理できる場所に責任を置きます。

すべてのサービスに複数ページの文書が必要なわけではありません。

単純な作業なら重要事項は数段落にまとめられます。大規模な案件では同じ考え方を、詳細仕様、日程、受入基準、正式な変更手続へ発展させられます。

世界銀行が公開するTerms of Referenceの例は、その文書がコンサルティングサービスの要求事項と発注者の期待を明確に示し、具体的な案件と現地事情に合わせて調整されるべきだとしています。 [4]

重要なのは長さではありません。欠けている情報が現実的に価格、日程、責任、期待結果を変え得るか が重要です。

ウェブサイトやプロフィール上のサービス説明は、契約成立までの過程の一部にすぎない場合があります。具体的な法的義務は、国、取引の種類、当事者の立場、販売方法によって異なります。

EUの事業者と消費者の取引では、公式Your Europeは契約前情報として、サービスの主な特徴、手数料を含む総価格、支払と履行方法、必要に応じて契約期間などを挙げています。 [5]

EUの事業者向けガイダンスはさらに、消費者契約の標準条項は公正で、消費者が経済的な影響も理解できる明確で分かりやすい言葉で書かれる必要があるとしています。 [6]

これらの要件はEUの特定の消費者取引に関するものです。すべての企業間取引や他の法域に自動的に適用すべきではありません。

本記事はサービス説明に関する編集上のガイドであり、契約書のひな形や法的助言ではありません。

1. 顧客はサービスが解決する問題または目的を理解しているか。
2. 最終結果が明記されているか。
3. 範囲に含まれるものが明確か。
4. 顧客は具体的に何を受け取るか理解しているか。
5. 完了を合理的に評価する方法があるか。
6. 顧客が提供または対応すべきものが明確か。
7. 重要な前提条件が明示されているか。
8. 誤解されやすい明白な除外事項が記載されているか。
9. 日程と段階は双方の依存関係を反映しているか。
10. 範囲変更時の扱いが明確か。
11. 価格、価格方式、追加費用が適切な段階で示されているか。
12. 専門家が管理できない結果を約束していないか。

良い説明かどうかを確かめる方法は単純です。

読んだ後、顧客と専門家が次の質問にほぼ同じ答えを出せるべきです。

何を達成するのか。何を行うのか。顧客は何を受け取るのか。何が含まれないのか。顧客は何をするのか。完了をどう判断するのか。範囲が変わったらどうするのか。

答えが一致していれば、価格と日程にはずっと良い文脈があります。

答えが違う場合、問題は実行中に初めて生じるのではありません。サービス説明の段階ですでに始まっています。

[1] U.S. Federal Acquisition Regulation - Subpart 37.6, Performance-Based Acquisition
出典を開く

[2] UK Government - The Digital, Data and Technology Playbook
出典を開く

[3] UK Government - Risk Allocation and Pricing Approaches Guidance Note
出典を開く

[4] World Bank - Sample Consultants Terms of Reference
出典を開く

[5] Your Europe - Contract information: what you should know before buying
出典を開く

[6] Your Europe - Contracts with consumers
出典を開く

[7] U.S. Government Accountability Office - Cost Estimating and Assessment Guide, GAO-20-195G
出典を開く

方法論上の注記: 出典はそれぞれ適用範囲が異なり、サービス説明についての単一の共通標準を構成するものではありません。本記事は、結果重視、測定可能性、明確な範囲、前提条件、供給者が管理できる要因への責任、顧客への透明な情報という、各出典が実際に裏付ける原則だけを使用しています。