RFPの成否を決定づける、唯一にして最大の変更点

ほとんどのRFP（提案依頼書）は、多くの理由によって失敗に終わります。

スケジュールが遅れ、想定以上の社内リソースを消費し、サプライヤーは過剰な約束をし、納品物は期待に及ばず、契約締結から数か月も経たないうちに対立的な商談へと発展してしまいます。

しかし、メディア、OTT、放送、デジタルパブリッシング業界における私たちの経験から、RFPが失敗する箇所はほぼ常に同じです。それはベンダーが選定されるはるか前、多くの場合、文書が発行される前です。

失敗の原因は、要件の書き方にあります。

RFPの作成者が成果に不釣り合いなほど大きな影響を与えることができる変更が1つあるとすれば、それはこれです：

サプライヤーに機能の説明を求めるのをやめ、明確で、曖昧さがなく、測定可能な要件を通じて、その機能を証明させる。

RFPプロセスにおけるその他の要素はすべて二次的なものです。

なぜRFPは公平に思えるのに、誤った決定を生むのか

パフォーマンスの低いRFPの多くは、一見すると破綻しているようには見えません。実際、網羅的で、体系化されており、妥当なものに見えることが多いのです。

そこには、以下のようなもっともらしい質問が含まれています：

• CMS内における検索機能について説明してください

• 貴社のプラットフォームがどのようにローカライズに対応しているか説明してください

• スケーラビリティとパフォーマンスに対する貴社のアプローチを教えてください

これらの質問はオープンで、協調的であり、ベンダーにとって親切なものに感じられます。また、有益な情報が得られるようにも感じられます。

しかし実際には、これらは3つの構造的な問題を生み出します。

第一に、これらは解釈の余地を与えてしまいます。各サプライヤーは、微妙に異なる質問に対して回答することになります。

第二に、製品の実態ではなく、マーケティング力を評価することになります。機能が部分的であったり、ロードマップ段階であったり、想定にすぎない場合でも、文章による回答は説得力があるように聞こえてしまいます。

第三に、客観的な比較が不可能になります。評価の議論はすぐに証拠から意見へと逸れてしまい、採点は評価ではなく説得の作業になってしまいます。

この時点で、他のすべてのステップが完璧に実行されたとしても、すでにRFPプロセスは損なわれています。

すべてが狂い始める瞬間：主観的な要件

私たちが目にする最も一般的な失敗のパターンは、ある1つの言葉から始まります：

「説明してください」

例えば：

「CMSの検索機能について説明してください」

この要件を客観的に採点することはできません。成功の共通定義も、測定可能な基準値も、適合性を自信を持って判断する方法も存在しないからです。

すべてのサプライヤーは、検証可能なものを何一つ約束することなく、肯定的に回答できてしまいます。

その後に起こることは予測可能です：

• 評価者が憶測でギャップを埋める

• 基本的な機能を確認するためにワークショップが使われる

• 契約交渉でスコープを遡及的に確定させようとする

• 納品段階で期待のズレが発覚する

RFPが失敗したのは、サプライヤーが不誠実だったからではありません。要件が曖昧さを許容してしまったから失敗したのです。

優れたRFP作成者が行うこと

優れたRFP作成者は、要件に対して全く異なるアプローチを取ります。

サプライヤーに何かがどのように動くかを説明させるのではなく、そのソリューションが受け入れられるために何が真実でなければならないかを定義することから始めます。

彼らはハイレベルな製品ニーズやユーザーストーリーを取り上げ、それを細分化された、検証可能な一連の表明に分解します。

それぞれの表明は以下を満たします：

• 明確であること

• 曖昧さがないこと

• 測定可能であること

• 個別に評価可能であること

極めて重要なのは、各表明に対する回答が、真（True）か偽（False）の2択しか許されないということです。

例えば、検索機能について尋ねる代わりに、以下のように記述します：

• 本ソリューションは、任意のオブジェクトについてCMS内に保存されているすべてのメタデータ属性にわたる検索をサポートしなければならない（SHALL）。

• 本ソリューションは、多言語記事内で定義されているすべての言語にわたる検索をサポートしなければならない（SHALL）。

• 本ソリューションは、通常の動作条件下において、最大X百万個のオブジェクトのデータセットに対し、2秒以内に結果を返さなければならない（SHALL）。（通常の動作条件とは何かを定義することも忘れてはなりません）

解釈の余地はありません。その機能が存在するか、しないかのどちらかです。

このアプローチは、RFPの性質を完全に変えてしまいます。

なぜ二者択一の要件が成果を一変させるのか

記述式の質問ではなく、客観的な表明として要件を書くことで、いくつかの変化が即座に起こります。

サプライヤーの回答はより短く、正確になります。マーケティング用の華美な言葉は役に立たなくなるため、姿を消します。

機能のギャップが早期に表面化します。サプライヤーは、制限事項、依存関係、またはロードマップ上の項目について、明確にせざるを得なくなります。

採点がより迅速になり、根拠が明確になります。評価の議論は、意見ではなく証拠に基づいたものになります。

ワークショップは基本的な確認のためではなく、検証や深掘りのための場になります。

最も重要なのは、契約交渉が容易になることです。要件マトリクスがすでに許容可能な最低限の機能を定義しているため、曖昧さが排除され、紛争のリスクが軽減されます。

これは、下流工程での仕様変更要求、商業的な摩擦、および納品時の期待外れを削減するための、最も効果的な唯一の方法です。

将来を縛ることなく、ユーザーストーリーを要件に変換する

非常に具体的で測定可能な要件を書く際、最もよく懸念されるのが「ソリューションを制約しすぎてしまうのではないか」ということです。

この懸念は妥当です。しかし、だからといって曖昧な要件を受け入れていい理由にはなりません。これは、要件を明確な意図を持って書かなければならないというシグナルです。

具体的かつ客観的な要件は、ソリューションがどのように構築されるかを記述するべきではありません。将来的な進化、再構成、変更の余地を意図的に残しつつ、満たされるべき振る舞いを定義するべきです。

この区別は極めて重要です。

不十分に書かれた要件は、今日の前提条件を固定化してしまいます：

• 内部アーキテクチャを規定する

• 実装パターンを強制する

• 現在の組織的な制約を、恒久的な事実として組み込んでしまう

よく書かれた要件は、その逆を行います。彼らは、変化に対応するための設計（architect-for-change）のアプローチをサポートする成果を定義します。

例えば：

以下の代わりに：

• 本ソリューションは、多言語検索をサポートするためにテクノロジーXを使用しなければならない（SHALL）。

以下を推奨します：

• 本ソリューションは、追加言語ごとの個別開発を必要とすることなく、多言語記事内で定義されているすべての言語にわたる検索をサポートしなければならない（SHALL）。

以下の代わりに：

• CMSは、実装時に定義された固定のコンテンツモデルで構成されなければならない（SHALL）。

以下を推奨します：

• CMSは、コードの変更やプラットフォームの再デプロイを伴うことなく、承認されたユーザーがコンテンツモデルを拡張および変更できるようにしなければならない（SHALL）。

どちらの場合も、要件は依然として二者択一で検証可能ですが、適応する自由は保持されています。

これが、将来の変化に対して責任を持って対処する方法です。プラットフォームがどうあるべきかを予測するのではなく、ビジネスが必然的に変化したときに、それに対応して変化できるようにしておくのです。

ハイレベルなユーザーストーリーも依然として重要な役割を果たします。それらは意図や方向性を表現します。しかし、評価メカニズムはあくまでも要件定義書であり、設計の好みではなく、振る舞いとしての機能を検証するために記述されます。

このバランスを取ることは困難です。どの制約がビジネスを守り、どの制約が単に現状の考え方を維持するためのものにすぎないかを見極めるには、経験が必要です。

その判断の差が、時代が経っても色褪せない要件と、契約が締結される前に時代遅れになってしまう要件の違いを生み出します。

優れた要件を書くことが本当に難しい理由

このアプローチがうまく実行されることが滅多にないのには理由があります。

具体的で、明確で、測定可能かつ客観的な要件を書くことは、単なる事務作業ではありません。それは、製品思考、システムエンジニアリング、運用の現実、およびビジネスリスクの交差点に位置する分析的な専門分野です。

ほとんどの組織において、これを一貫して実行できる人材はほとんど見られません。

複雑なメディアやプラットフォームのプログラムを進める組織が、その決定に長期的なリスクが伴う場合に、専門のRFPおよびテンダリング（入札）の専門知識を外部から導入することが多いのはこのためです。

要件定義の作成者は、以下のことができる必要があります：

• ユーザーストーリーをそのままコピーするのではなく、ユーザーのニーズを理解する

• 抽象的なビジネス目標を、具体的なシステム動作に変換する

• 規模、エッジケース、障害モードを予測する

• 開発を過剰に制限することなく、曖昧さを排除する

• テスト可能で、正当性が立証でき、契約にそのまま使える表明を記述する

これらのスキルを併せ持つ人材は稀です。結果として、要件は委員会によって作成されて妥協によって薄められたり、必要な経験のないチームに委ねられたりしがちです。その結果、ビジネスを守ることに失敗する、善意に満ちただけの文書が出来上がることになります。これは予測可能な結末です。

また、優れた要件が組織内で不快感をもたらすことが多いのもこれが理由です。多くの組織が慣れている時期よりも早く、決断を下すことを迫るからです。不確実性を露呈させ、曖昧な言葉という「安全毛布」を取り上げてしまうのです。

その他の要素も依然として重要…ただ、それほど重要ではない

スケジュールは重要です。ガバナンスも重要です。コミュニケーションも重要です。公平性も重要です。

しかし、これらのどれもが、不十分な要件を補うことはできません。

曖昧な要件に基づいて構築された、完璧に運営されるRFPプロセスであっても、結果は悪いものになります。一方で、他の部分に不完全さがあったとしても、厳格で客観的な要件に基づいて構築されたプロセスは、多くの場合成功します。

この優先順位は、特に調達主導の環境においては受け入れがたいものかもしれませんが、現実を反映しています。

もし1つだけ変更するなら、ここを変えてください

これからRFPを発行しようとしているなら、以下の質問を念頭に置いて見直してください：

すべての要件について、議論の余地なく客観的に採点できますか？

もし答えが「いいえ」であれば、そこに労力を集中させるべきです。

これを正しく行うには、時間と規律が必要です。曖昧な表現を使いたい誘惑に抗い、心地よいと感じるよりも早い段階で明確さを強制する必要があります。

その見返りは非常に大きいです。

Spicy Mangoは、実際の開発経験から構築された、OTT、ストリーミング、およびデジタルパブリッシングプラットフォーム向けの広範なRFPフレームワークと要件ライブラリを維持しています。私たちは、何百ものハイレベルな機能要件および非機能要件を、何千もの明確で測定可能な個別の表明に翻訳した参照資料のライセンスを提供しています。この専門性の深さこそが、Tier 1のメディア組織が単に調達業務を実行するためだけでなく、要件定義のレベルで実際の成功の定義を形成し、戦略的な変革プログラムを実現するために当社を起用する理由の1つです。厳格さを犠牲にすることなくこのプロセスを加速させたい場合は、実際のベストプラクティスを確認するために、ぜひお問い合わせください。