連載④ 全部Must要件のRFPがベンダー選定を壊す
「うちのDX、正直どうなんだろう」
25年前の論文は、DXの失敗をすべて知っていた
DX導入後、なぜ多くの企業が思うような成果につなげられないのでしょうか。
本連載では、Karl Wiegersが2000年に示した「要求開発における10の罠」をもとに、25年前から変わらないDX失敗の構造を、現代の製造DXに置き換えて紐解いていきます。
第３話では、「トレーサビリティ強化」で合意した気になっていないかをテーマに、曖昧な要求がプロジェクトにどのような影響を与えるのかをお伝えしました。
今回は第４話。
全部Must要件のRFPがベンダー選定を壊すをテーマに、すべてが「必須」とされ、スコープ調整やトレードオフの判断ができないことがプロジェクトにどのような影響を与えるのかを見ていきます。
▶ 第３話はこちら👇
連載③「トレーサビリティ強化」で合意した気になっていないか？｜株式会社LSDC_馬場正弥
罠4：優先順位付けされていない要求(Unprioritized requirements) — すべてが「必須」とされ、スコープ調整やトレードオフ判断ができない。
Wiegersは何と言っていたか
この罠の原文は、あるユーザー代表のセリフから始まります。「要求に優先順位なんて要りませんよ。全部重要です。重要じゃなければ、そもそも挙げていません」。
一見、筋が通っています。だからこそ、この罠は抜けにくいのです。Wiegersが指摘する問題は、全要求を等しく重要だと宣言した瞬間、プロジェクトからトレードオフを判断する手段が奪われることです。新しい要求が来たとき、要員が抜けたとき、予算が足りないと分かったとき、
何かを後回しにしなければならない局面は必ず訪れます。プロジェクト終盤にほぼ確実に訪れる「慌ててスコープを削るフェーズ（rapid descoping phase）」で、どれを保留してよいか誰にも分からないなら、そのプロジェクトはすでにリスクの中にいるといえます。
具体的な症状として、Wiegersは「要求の90%以上が『高』に分類されている」状態を挙げています。この論文をもとにした製薬業界の要件定義研修は、さらに端的に言い切っています。
「すべてに高いプライオリティをつけることは、プライオリティをまったくつけていないのと本質的に同じ」。すべてが高いということは、結局どれも高くないのと同じだからです。
興味深いのは、Wiegersが優先順位付けを渋る側の心理まで解剖していることです。開発者が渋るのは「全部は期限内にできない」と認めたくないから。ユーザーが渋るのは、優先度を下げた項目は永遠に実装されないのではないかと恐れているからです。そしてWiegersは身も蓋もなく付け加えます。その恐れは「当たっているかもしれない」と。だが優先順位を付けない場合の代替シナリオは、ソフトウェアが永遠に納品されないことや、事情を知らない誰かがトレードオフを勝手に決めることです。どちらがましか、という話です。
処方箋の核は、「高」の定義を先に決めることにあります。何をもって高優先とするか、
想定される使用頻度・使用量、最重要ユーザークラスの満足、コア業務プロセスの実現、そして規制対応で要求される機能。少なくとも3段階の優先度スケールを使い、各カテゴリーの定義を明文化して全員の解釈を揃えます。裁量的な（やってもやらなくてもよい）要求は、顧客価値とコスト・技術リスクを突き合わせて分析的に決めます。研修資料には、優先順位が付いているときにだけ使える交渉の定型文も紹介されています。「もちろん追加できます。ただし、人を増やすか、予算を増やすか、"Nice to have"をその分削るか、です」。
DX時代の症状——「対応可」が並んだ比較表の末路
Wiegersが描いたのは開発プロジェクト内部の風景ですが、日本の製造DXでは、この罠はもっと早い段階のRFP（提案依頼書）とベンダー選定で発火することが多いのです。
あるメーカーがMES導入のRFPを発行しました。要件一覧は412項目。各部門のヒアリング結果を集約したもので、重要度の列は「必須」が379件。Must率92%です。誰も嘘はついていません。品証にとって監査証跡は必須であり、製造にとって秤量連携は必須であり、生産管理にとって計画の即時反映は必須なのです。「あなたの業務に重要か」という問いには、全員が正直に答えました。「この投資の第一段階に不可欠か」とは、誰も問われませんでした。
このRFPを受け取ったベンダー側で、何が起きるでしょうか。
ベンダーAは誠実に全項目を積み上げ、カスタマイズ費を含めた見積もりを出しました。予算の2.5倍の金額で。
ベンダーBは競争を意識し、379項目のMustに片っ端から「対応可」と記入しました。標準機能で7割、残りは「設定で対応」「代替運用で対応」という含みを残して。
ベンダーCは、全部Mustで納期も予算も固定のRFPをリスクと判断し、辞退しました。
【図解：ベンダーA/B/Cの選定シーン】
Aは予算ラインを突き破る赤い矢印（誠実だが2.5倍の見積もり）、
Bは予算ラインぴったりの価格バーと同じ○が並ぶグリッド（右下に小さく隠れた「ほころび」も配置）、
Cは辞退を示すフェードした禁止マーク、
そして下部の比較表ではBの列だけがハイライトされ選定マークが付いています。Aには価格を示す警告マーク、Cは比較表の外に灰色で残るだけ。
選定委員会に届くのは、AとBの比較表です。機能適合の列はどちらも「○」がずらりと並びます。全項目Mustなのだから、ベンダーは○を付ける以外に土俵に残る方法がありません。かくして機能では差がつかず、選定基準は実質、価格だけになります。
Bが選ばれます。
本当の請求書は、要件定義フェーズで届きます。「対応可」の内訳を開くと、「設定で対応」の設定は業務に合わず、「代替運用」は現場に新しい手作業を強いるものでした。ギャップ対応の追加見積もりが積み上がり、気づけば総額はベンダーAの提示額に近づいていきます。
ただし、スケジュールは半年遅れで。全部Mustは、ベンダーを競争から降ろすか、不誠実に賢く振る舞うことを強いるかの二択を迫ります。壊れたのはベンダーの誠実さではなく、誠実さが報われる選定の構造のほうです。
なぜDXで、この罠は悪化するのか
第一に、RFPの一括発注という商習慣が「全部盛り」を合理化します。要件を落として発注し、後から追加すれば稟議のやり直しになります。だから発注側は「迷ったら入れる。どうせ書くだけならタダだ」と考えます。しかし書くだけはタダでも、見積もらせることはタダではありません。412項目のMustは、ベンダーのリスクバッファとして見積金額に還流するか、Cのように良質な選択肢を土俵から降ろす形で、発注側に確実に請求されているのです。
第二に、「規制要件」という言葉がMust量産装置になります。GxP環境では「規制対応」は最強のカードであり、これを添えられた要求に異を唱えるのは勇気が要ります。だが精査すると、「規制が要求している」の中身には、規制そのものの要求、当局ガイダンスの推奨、業界慣行、そして単なる社内ルールや前任者の解釈が混在しています。この仕分けをせずに束ねた瞬間、RFPの中で本物の規制要件と社内慣行が同じ重さで並び、ベンダーはそのすべてに保険を掛けた値付けをします。
第三に、機能充足率という比較指標が、優先順位の不在を覆い隠します。「A社は要件充足率96%、B社は93%」という数字は精密に見えますが、毎バッチ使う秤量連携と年数回の集計画面を同じ1点で数えた充足率に、意思決定を支える力はありません。優先順位のない要件一覧から生まれた充足率は、桁数だけ立派な、根拠のない精度なのです。
DX版の処方箋——RFPに「価格が変わる構造」を組み込む
RFP発行前に、3段階の定義を決めてMust率を監査します。 例えば、必須（Must）：これがないと出荷判定業務が成立しない、または規制当局の要求そのものです。重要（Should）：現行の手作業で代替可能だが、事業目標のKPIに直結します。任意（Could）：あれば効率が上がるが、初回稼働に含めなくても業務は回ります。この定義に照らして全項目を再分類し、Must率が5割を超えていたら発行を止めて仕分けをやり直します。仕分けの済んでいないRFPは、要求の文書ではなく願望の文書です。
「規制要件」には出典欄を設けます。 Mustの根拠として「規制対応」を掲げる項目には、GMP省令の条文か、当局ガイダンスか、社内SOPかを書かせます。書けないものはMustの資格を保留します。品証を疑うのではありません。品証自身が査察で「なぜこれを必須としたか」を説明できる状態を作る作業であり、この一手間で「規制」の名を借りた社内慣行が相当数、Should以下に降りてきます。
ベンダーには「Mustのみ」と「Must＋Should」の2段階見積もりを求めます。 全項目一括の見積もりでは、優先順位はベンダーに伝わりません。Mustだけの構成価格と、Shouldを加えた価格を分けて提示させれば、①ベンダーの標準機能がコア業務にどれだけ素で適合するかが見え、②Should以下が「後から交渉できる調整代」として機能し、③比較表が「○の数」ではなく「コア業務への適合と拡張の単価」で読めるようになります。誠実なベンダーほど、この形式を歓迎します。
使用頻度タグでクロスチェックし、リリースに割り当てます。 Wiegersの「頻度・量」の基準はRFPでも簡単に運用できます。各要求に「毎バッチ／毎日／毎週／毎月／年数回」のタグを付け、優先度と突き合わせます。毎バッチの項目がShouldに、年数回の項目がMustにいたら、そこが議論すべき場所です。そのうえで全項目をリリース1／リリース2／バックログに割り当て、リリース2の起動条件（リリース1の安定稼働判定、効果測定値など）を文書化します。「下げたら二度と実装されない」という現場の恐れには、降格のルールではなく昇格のルールを示して答えます。
セルフチェック3問
直近のRFP（またはこれから出すRFP）のMust率は90%を下回っているといえますか？超えているなら、それは優先順位が存在しないのと同じです。
「必須」の定義文は存在しますか？「これがないと出荷できない／規制の要求そのものである」のような検証可能な言葉で書かれていますか？
ベンダーの見積もりを、Mustのみの構成で比較できますか？それとも全部盛りの総額と充足率でしか比べられませんか？
セルフチェックの見方
3つとも「はい」 Must率が適正な水準に収まり、「必須」の根拠も、ベンダー比較の軸も明確になっています。選定や検収の場で「全部Mustだったはずなのに」という混乱が起きる可能性は低い状態です。
「いいえ」または「判断できない」が1つある どこかに、精査されないまま「必須」と扱われている項目が残っています。そこが、見積もり比較や検収時に議論を蒸し返す火種になりやすい状態です。
「いいえ」または「判断できない」が2つ以上ある 「全部重要です」という言葉のまま、誰も優先順位を検討せずにRFP発行や設計に進んでいる、典型的な全部Mustの経路にすでに乗っている状態です。
1問でも「いいえ」または「判断できない」があれば要注意です。全員が「重要です」と即答したことは、優先順位が存在する証拠にはなりません。
全部Mustの要件一覧は、社内では「慌てて削るフェーズ」を、社外では「誠実さが報われない選定」を生みます。「全部重要です」という言葉が聞こえたら、それは要求が多すぎるサインではなく、「高」の定義がまだ存在しないサインです。
自社の場合、何から整理すればよいか迷った方へ
セルフチェックで「いいえ」や「判断できない」となった項目はありましたか？ 同じ項目で迷っていても、プロジェクトの進行段階や関係者、導入するシステムによって、整理すべき内容は異なります。 個別に確認したい方は、次の内容をお送りください。
セルフチェック3問の回答
最も判断に迷った質問
まだ内容を整理できていない場合は、「何から整理すればよいか分からない」とご記載いただくだけでも構いません。 私がメールで御社の課題を回答します。
次回は罠5「誰も使わない機能の作り込み」。良かれと思って追加された機能が、なぜ稼働後のマスタメンテナンスと再バリデーションの重荷に変わるのかを見ていきます。
参考資料
Karl E. Wiegers "10 Requirements Traps to Avoid," STQE Magazine, 2000年（現在は著者によりMediumで公開）https://medium.com/analysts-corner/10-requirements-traps-to-avoid-fb103bfeaaac
Karl E. Wiegers『ソフトウェア要求』（日経BP）
