連載③「トレーサビリティ強化」で合意した気になっていないか？
「うちのDX、正直どうなんだろう」
25年前の論文は、DXの失敗をすべて知っていた
DX導入後、なぜ多くの企業が思うような成果につなげられないのでしょうか。
本連載では、Karl Wiegersが2000年に示した「要求開発における10の罠」をもとに、25年前から変わらないDX失敗の構造を、現代の製造DXに置き換えて紐解いていきます。
第2話では、「現場オペレーターが要件定義にいないMESは、必ず"二重運用"になる」をテーマに、ユーザー巻き込み不足が、プロジェクトにどのような影響を与えるのかをお伝えしました。
今回は第3話。
「トレーサビリティ強化」で合意した気になっていないかをテーマに、
曖昧な要求がプロジェクトにどのような影響を与えるのかを見ていきます。
▶ 第2話はこちら👇
罠3： 曖昧な要求(Vague and ambiguous requirements) — 「使いやすい」「高速に」など解釈が人によって異なる表現のまま進んでしまいます。
Wiegersは何と言っていたのでしょうか
Wiegersは曖昧さを「ソフトウェア要求における最大の恐怖の種（the great bugaboo）」と呼びました。一つの要求文が複数の意味に読めて、どれが正しいか分かりません。これが分かりやすい曖昧さです。しかし本当にたちが悪いのは、もう一段陰湿な形のほうです。複数の読み手がそれぞれ違う解釈をし、全員が「自分の解釈が正しい」と確信している状態です。この場合、曖昧さは誰にも検出されないまま生き延び、解決コストが最も高くなった頃、実装がかなり進んだ頃に、ようやく姿を現します。
この論文をもとにした製薬業界の要件定義研修では、有名な言葉遊びの例が使われています。休暇の行き先を相談する二人。一人は「Great Plains（大平原）が見たい」と言い、もう一人は「Great Planes（大きな飛行機）だね！」と応じます。発音は同じ、合意は成立、中身は別物です。会議室の「合意」の少なくない部分が、実はこれなのです。
Wiegersが挙げる症状は明快です。各要求に対してテストケースを考えられないなら、その要求は十分に定義されていません。 そして決定的な症状は、開発者が顧客に何度も質問に戻るか、あるいは質問せずに推測で作ってしまうことです。誠実な開発者ほど質問に戻るので開発は遅くなり、推測する開発者は速いが間違ったものを作ります。どちらに転んでも高くつきます。
処方箋は具体的です。まず、本質的に主観的な言葉を要求文から追放します。「最小化」「最適化」「迅速」「使いやすい」「簡単」「頻繁に」「通常」「直感的」「堅牢」「柔軟」——そして「および／または」と「〜など」は、疫病のように避けよと言います。「〜などの言語に対応」と書けば、イタリア語は含まれるのでしょうか。誰にも分かりません。「サポートする」という動詞も検証不能であり、何をどうすることが「サポート」なのかを定義しなければなりません。前述の研修ではさらに、shouldとmustの使い分けにも踏み込んでいます。「〜が望ましい（should）」は選択肢の含みを持ちます。本当に必須なら、mustと書くべきです。
次に、多様な視点による要求文書のインスペクション（正式なレビュー）です。書いたアナリスト本人、要求を出したユーザー、実装する開発者、そして検証するテスト担当者。規制対象システムならQAも加えます。ただし研修資料は釘を刺しています。 「これは署名を15個増やせという意味ではない。レビューのプロセスであって、承認の儀式ではない」。
そして最後の武器が2つあります。要件定義の早い段階でテストケースを書き始めること（テストを考えた瞬間、曖昧さは炙り出されます）。 そしてプロトタイプです（動くものの前では、質の悪い要求は隠れられません）。
DX時代の症状——全員が賛成した「トレーサビリティ強化」
MES導入の経営会議。投資の目的を問われたプロジェクトリーダーが答えます。「トレーサビリティの強化です」。
役員は頷きます。
品証も頷きます。
製造も、営業も、ベンダーも頷きます。
満場一致です。議事録には「目的：トレーサビリティ強化で合意」と記されます。
美しい光景ですが、Great Plainsの旅行相談と同じことが起きています。それぞれの頭の中を覗いてみましょう。
役員が思い浮かべているのは、回収事案のニュース映像です。「万一のとき、対象ロットを数時間で特定して、被害を最小限にできる体制」。
品証部長が考えているのはデータインテグリティです。「原料ロットから製品ロットまでの紐付けが監査証跡付きで残り、査察で指摘されないこと」。
製造部長の頭にあるのは工程内の話です。「中間品がどのタンクを通ったか、後から追えること。分割・混合バッチも含めて」。
営業部長は顧客対応を考えています。「取引先から求められるロット証明書を、即日発行できること」。
そして、
ベンダーは自社製品の仕様を思い浮かべています。「標準のロット管理機能。原料と製品の親子関係はカバー済み」。
5人が5枚の別の絵を見ながら、同じ一語に賛成しました。全員が自分の解釈を疑っていないため、Wiegersの言う通り、この曖昧さは検出されないまま要件定義を通過し、設計を通過し、開発を通過します。
姿を現すのは受入テスト、最悪の場合は稼働後です。
回収訓練で役員が「このロットの出荷先は？」と問うと、システムは原料方向の遡及はできるが出荷方向の追跡は対象外だったことが判明します。
品証部長は監査証跡の粒度が査察要求に足りないと言い、製造は「分割バッチが追えないなら意味がない」と言います。
プロジェクトリーダーは呆然とつぶやきます。
「トレーサビリティ強化で、合意しましたよね？」。
しました。言葉には。
「リアルタイムで見える化」も同じ構造を持ちます。制御担当者のリアルタイムは秒未満、製造管理者のそれは「当日中」、経営ダッシュボードなら「翌朝見られれば十分」かもしれません。定義しないまま進めば、検収の場が定義の場になります。検収時の紛争の多くは、悪意の産物ではなく、未定義語の満期到来なのです。
なぜDXで、この罠は悪化するのか
第一に、DXの語彙そのものが曖昧語でできています。 「見える化」「デジタル化」「スマートファクトリー」「データドリブン」「シームレス連携」。これらはビジョンを語る言葉としては優れていますが、要求文に混入した瞬間、Wiegersの危険語リストの現代版になります。しかも社内公用語として流通しているため、「それはどういう意味ですか」と問うことが野暮に感じられ、確認の心理的ハードルが上がっています。
第二に、組織の縦割りが「同床異夢のまま進める」ことを可能にします。
要求の解釈が部門ごとに違っても、要件定義の後は各部門が別々の分科会に分かれて進むため、解釈のズレが衝突する機会が先送りされます。
全員が一つの絵を見る強制イベントがなければ、ズレは統合テストまで安全に冬眠します。
第三に、生成AIが曖昧な要求を「もっともらしく補完」してしまいます。
曖昧な指示を受けた人間の開発者は質問に戻る（遅くなる）か推測する（間違える）かでしたが、生成AIは常に後者を、しかも自信満々に選びます。「トレーサビリティ機能の要件定義書を作って」と指示すれば、一般論として整った文書が数秒で出てきます。それがあなたの工場の分割バッチや再加工の実態を反映している保証は、どこにもありません。曖昧さが罰せられるまでの時間は、かつてなく短く、生成される誤りの量は、かつてなく多いのです。
DX版の処方箋——「合意した言葉」を分解してから進む
1. 危険語リストの製造DX版を作り、要求文書から追放します。
Wiegersのリストに、自社でよく使う言葉を足します。「見える化」「リアルタイム」「トレーサビリティ」「ペーパーレス」「柔軟なマスタ」「将来の拡張性」「使いやすい画面」——これらが要求文に現れたら、機械的に赤を入れて分解します。トレーサビリティなら最低限、①方向（原料への遡及か、出荷先への追跡か、両方か）、②粒度（ロットか、シリアルか、工程内の中間品まで含むか）、③範囲（分割・混合・再加工バッチを含むか）、④速度（照会から回答まで何分か）、⑤証跡（誰がいつ何を変更したかを残すか）の5点を定義して初めて、要求の資格を得ます。
2. 「〜が望ましい」を禁句にし、mustとshouldを仕分けます。
日本語の要件定義書は「〜できることが望ましい」で溢れがちです。望ましい、はベンダーには「やらなくてよい」と読めます。必須ならば「〜できなければならない」と書きます。この仕分けは、次回以降に扱う優先順位付け（罠4）の入口でもあります。
3. 立場の違う4人で要求文書をインスペクションします。
書いた本人、現場ユーザー、実装するベンダー、そしてテスト担当者。 特にテスト担当者の「これ、どうやって検証するんですか？」という問いは、曖昧さ検出器として最強です。医薬品ならCSVの流れに乗せればよく——URSの各項目がテストスクリプトに落とせるかを、PQを書く人の目で先に見てもらいます。なお、レビューアを増やすことと承認印を増やすことは別物です。署名欄は増やさなくてよく、見る目を増やすのです。
4. 要求と同時に「受入シナリオ」を書きます。
Wiegersの「テストケースを早く書け」の実装です。「監査員役が製品ロットXを指定してから、原料ロット一覧と出荷先一覧が出力されるまで15分以内。分割バッチY-1、Y-2を含む」——この1行を要件定義の段階で書いておけば、検収日の紛争は要件定義の日の議論に前倒しされます。議論のコストは、前倒しするほど安くなります。
セルフチェック3問
直近の要件定義書で『見える化』『リアルタイム』『トレーサビリティ』『柔軟』『など』を検索してください。出てきた箇所ごとに『具体的に何分以内か』『どこからどこまでを含むか』を、その場で誰かに聞かれてすぐ答えられますか？答えに詰まる箇所はゼロだと言えますか？
主要な要求のすべてについて、「どうなれば合格か」を受入シナリオの形で書けますか？
要求文書を、テストを書く人がレビューしましたか？（作成者と承認者だけのレビューは、レビューと数えません）
セルフチェックの見方
3つとも「はい」 要求は検証可能な形に分解できています。検収の場で「合意したはずなのに」という紛争が起きる可能性は低い状態です。
「いいえ」または「判断できない」が1つある。どこかに、定義されないまま流通している曖昧語が残っています。そこが、検収時に議論を蒸し返す火種になりやすい状態です。
「いいえ」または「判断できない」が2つ以上ある 「全員が賛成した言葉」が、実は誰も定義していない言葉のまま設計・開発に進んでいる、典型的な曖昧要求の経路にすでに乗っている状態です。
1問でも「いいえ」または「判断できない」があれば要注意です。会議室での合意の早さは、曖昧さがなかった証拠にはなりません。
自社の場合、何から整理すればよいか迷った方へ
セルフチェックで「いいえ」や「判断できない」となった項目はありましたか？
同じ項目で迷っていても、プロジェクトの進行段階や関係者、導入するシステムによって、整理すべき内容は異なります。
個別に確認したい方は、次の内容をお送りください。
セルフチェック3問の回答
最も判断に迷った質問
まだ内容を整理できていない場合は、「何から整理すればよいか分からない」とご記載いただくだけでも構いません。 私がメールで御社の課題を回答します。
次回は罠4「優先順位付けされていない要求」です。
要件一覧の重要度欄が「高」で埋め尽くされるとき、プロジェクトに何が起きるかを見ていきます。
参考資料
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）
