連載①「ペーパーレス化」は要求ではない — 経営のDXビジョンとMES機能要件の断絶
「うちのDX、正直どうなんだろう」
25年前の論文は、DXの失敗をすべて知っていた
DX導入後、なぜ多くの企業が思うような成果につなげられないのでしょうか。
本連載では、Karl Wiegersが2000年に示した「要求開発における10の罠」をもとに、25年前から変わらないDX失敗の構造を、現代の製造DXに置き換えて紐解いていきます。
第0話では、DXの失敗が技術の問題だけではなく、要求の捉え方や関係者の認識のズレから生まれていること、そして25年前の論文が、現在のDXにも通じる問題をすでに指摘していたことをお伝えしました。
今回は第1話。
「ペーパーレス化は要求ではない――経営のDXビジョンとMES機能要件の断絶」をテーマに、「要求」という言葉の混乱が、プロジェクトにどのような影響を与えるのかを見ていきます。
▶ 第0話はこちら👇
罠１： 不十分なユーザー関与(Confusion over "requirements")/要求という言葉の混乱 — ビジネス要求・ユーザー要求・機能要求などのレベルが混同され、関係者ごとに「要求」の意味が違う。
Wiegersは何と言っていたのでしょうか
Karl Wiegersが2000年の論文で最初に挙げた罠は、意外なほど地味です。 「要求（requirements）」という言葉そのものが、人によって違う意味で使われています。 それだけです。
だが、その帰結は地味ではありません。経営者にとっての「要求」はハイレベルな製品コンセプトや事業ビジョンであり、開発者にとっての「要求」は詳細な画面設計に近い何かです。 そして顧客が出してくる「要求」は、実は要求ではなく「ソリューションのアイデア」であることが多いのです。
Wiegersは危険な兆候として、関係者が何の形容詞もつけずに「その要求」と口にする場面を挙げています。 ビジネス要求なのか、ユーザー要求なのか、機能要求なのか。誰も区別していないとき、参加者はそれぞれ違う細かさの「要求」を頭に描いています。
もう一つの兆候は、ユーザーが「要求は出した」と言っているのに、開発者が「何を作ればいいのか分からない」と感じている状態です。 議論が機能の話ばかりに集中すると、「要求」という言葉の下にある多様な情報：目的、業務シナリオ、品質特性、制約、・・・が抜け落ち、関係者の重要な期待が文書化されないまま、実現もされずに終わります。
処方箋としてWiegersが示したのが、有名な「要求の3階層」です。 最上位のビジネス要求は「この製品があれば世界がどう良くなるか」を記述し、ビジョンとスコープ文書にまとめます。 中間のユーザー要求は「ユーザーがこの製品で遂行できなければならないタスク」を、ユースケースの形で記述します。 そして最下層の機能要求は、ユースケースから導出される「ソフトウェアが示すべき具体的な振る舞い」を項目化したものです。 使いやすさや性能といった非機能要求も、ユースケースと併せてユーザーから聞き出しておきます。
3つはどれも正当で、どれも必要であり、どれか一つで代用はできません。これが25年前の結論です。
DX時代の症状——あるMES導入キックオフの風景
この罠を、製造DXの現場に置き換えてみましょう。ある医薬品メーカーで、MES（製造実行システム）導入のキックオフ会議が開かれたとします（食品メーカーなら、「査察」を「取引先監査」や「FSSC 22000の審査」に読み替えてください。以下の風景は驚くほどそのまま通用します）。
役員「当社のDX要求は明確だ。ペーパーレス化だよ。工場からあの紙の記録を一掃してほしい」
製造課長「そうですね……現場としては、バッチ記録の転記ミスをなくしたいんです。指図書からExcelへ、Excelから日報へ、同じ数字を3回書いていますから」
品質保証部長 「うちの要求はGMP査察への対応です。査察官に『このロットの製造記録を』と言われて、30分以内に出せること」
情報システム部 「では、要求は揃いましたので、ベンダーさんに機能一覧との突合をお願いします」 ベンダー 「承知しました。電子記録機能はございますので、Fitですね」
全員が「要求を出した」と思っています。しかし、よく見てください。 役員の「ペーパーレス化」は要求ではなく手段（ソリューションのアイデア）です。紙をなくすこと自体が目的の会社は存在しません。 製造課長の発言はユーザー要求の断片、 品証部長の発言は業務シナリオと性能要求の混合物であり、 そして誰もビジネス要求：このシステムで事業のどの数字がどう良くなるのか、を語っていません。
それなのに会議は「要求は揃った」として、機能一覧の照合に進んでしまいました。
半年後に何が起きるかは、想像に難くありません。紙は確かに減りました。しかし現場はタブレットの画面をスクリーンショットして印刷し始め、品証は結局、監査前に手作業でデータを整形しています。役員は問います。「ペーパーレス化したのに、なぜ何も速くならないんだ？」 要求と呼ばれていたものが最初から手段だったのですから、当然の帰結です。
これはWiegersの時代から続く古典的な構図です。彼の論文をもとにした製薬業界の要件定義研修でも、まったく同じ例が使われています。
包装システムに対して、 マーケティングは「服用単位で販売できる包装を」と言い、 包装エンジニアは「湿気に弱い製品なので防湿を」と言い、 包装オペレーターは「四角い容器は機械が詰まるから丸い容器を」と言います。 三者三様の「要求」は、どれもその立場では最優先で、どれも正当です。
問題は要求の中身ではなく、それらを全体観をもって整理し、レベル分けし、優先順位をつける営みが存在しないことにあります。
なぜDXで、この罠は悪化するのでしょうか
25年前より状況が良くなっていればよいのですが、実際にはDXがこの罠を三重に悪化させています。
第一に、「DXビジョン」という新しい階層が積み増しされました。 かつては3階層で済んだものが、いまは「全社DX戦略」「デジタルビジョン」といった、さらに抽象度の高い言葉が最上段に乗っています。中期経営計画の「データドリブン経営の実現」と、現場の「秤量記録の電子化」の間には、少なくとも3段の翻訳が必要です。その翻訳を誰も担当していないプロジェクトでは、経営の言葉と現場の言葉が、同じ「DXの要求」として一つの表に同居します。
第二に、パッケージ・SaaS前提の導入が「要求定義」を「機能突合」に矮小化しました。 MESのようなパッケージ製品の導入では、要件定義がしばしば「ベンダーの機能一覧に対するFit＆Gap」から始まります。
だがこれは、Wiegersの3階層でいえば最下層の機能要求だけを、しかもベンダー側の語彙で議論する行為です。ビジネス要求とユーザー要求を飛ばして機能から入れば、「機能はあるのに業務が回らない」システムができあがります。Fit＆Gapが悪いのではありません。その前に自社の要求の階層を整理していないことが問題なのです。
第三に、生成AIとローコードが「手段の言葉」をそのまま実装してしまいます。 「ペーパーレス化したい」とAIに指示すれば、もっともらしい電子フォームが即座に生成される時代になりました。
かつては開発者が「それは要求として曖昧です」と押し返す関門になっていましたが、AIは押し返しません。曖昧な要求、手段と目的の混同は、疑問を差し挟まれることなく、高速に、大量に、システムとして固定化されます。要求の質を問う機会は、むしろ減っています。
DX版の処方箋 「ペーパーレス化」を分解する
Wiegersの処方箋は「3階層を認識し、関係者を教育せよ」でした。これを製造DXの言葉に読み替えると、次のようになります。
1.ソリューションの言葉が出たら、「それによって何が良くなるのか」を問い直す
「ペーパーレス化」と聞いたら、ビジネス要求に翻訳します。 医薬品なら「バッチレコードのレビュー時間を50%短縮し、出荷判定のリードタイムを2日短くする」「転記起因の記録逸脱を年間ゼロにする」。 食品なら「回収事案発生時、対象ロットの原料遡及を2時間以内に完了できるようにする」。 こう書き直せた瞬間、ペーパーレス化は数ある手段の一つに降格し、成果を測る物差しが手に入ります。
2.ユーザー要求は、現場の業務シナリオとして書く
医薬品なら「秤量担当者は、指図に基づいて原料を秤量し、実測値が許容範囲を外れた場合はその場で警告を受け、逸脱処理を開始できなければならない」。
食品なら「仕込み担当者は、配合入力の際にアレルゲン原料への切り替えを検知し、洗浄確認が完了するまで次工程に進めないこと」。 Wiegersのいうユースケースは、製造現場ではSOPと工程の言葉で書けます。ここに現場のオペレーターと品証が同席していないなら、それは罠2（ユーザーの巻き込み不足）に片足を突っ込んでいます。
3.機能要求は、ユーザー要求から導出したものだけを採用する
「電子署名機能」「帳票出力機能」といった機能名の羅列ではなく、「どの業務シナリオのどのステップを支えるための機能か」を紐づけます。 紐づかない機能は、誰の要求でもありません。
4.プロジェクトの冒頭で「要求の辞書」を合意する
ビジネス要求・ユーザー要求・機能要求という3つの言葉の定義と記述例を1枚にまとめ、経営・現場・情シス・ベンダーの全員で共有します。地味な作業ですが、Wiegersが「教育」を処方箋の第一に挙げた理由は、この地味さにあります。そして要求を収集する場には、この階層を理解したファシリテーターを置きます。社内にいなければ、外部の力を借りる価値が最もある部分です。
DXセルフチェック3問
最後に、自社のプロジェクトがうまく機能しているかどうか、次の3問を「はい・いいえ・判断できない」で確認してみてください。
あなたのプロジェクトの要求文書には、「〜化」「〜システムの導入」という手段の言葉が、目的の欄に書かれていませんか？
「このシステムで事業のどの数字がどう変わるのか」を、経営・現場・ベンダーの3者が同じ言葉で答えられますか？
機能一覧のFit＆Gapを始める前に、ユーザー要求（現場の業務シナリオ）を文書化しましたか？
セルフチェックの見方
3つとも「はい」
プロジェクトの目的とユーザー要求が、ある程度整理できている状態です。経営・現場・ベンダーが、同じ内容を答えられるかも確認してみましょう。「いいえ」または「判断できない」が1つある
要求の階層や、関係者間の認識にズレが生じている可能性があります。「いいえ」または「判断できない」が2つ以上ある
機能の比較を進める前に、プロジェクトの目的と現場の業務を整理した方がよいかもしれません。
セルフチェックによって課題の有無は確認できても、「では、自社では何から整理すればよいのか」までは、プロジェクトの状況によって異なります。
「要求」という言葉の交通整理――25年前に示されたこの地味な第一歩が、DXの成否を最初に分けます。
自社の場合、何から整理すればよいか迷った方へ
セルフチェックで「いいえ」や「判断できない」となった項目はありましたか？
同じ項目で迷っていても、プロジェクトの進行段階や関係者、導入するシステムによって、整理すべき内容は異なります。
個別に確認したい方は、次の内容をお送りください。
セルフチェック3問の回答
最も判断に迷った質問
まだ内容を整理できていない場合は、「何から整理すればよいか分からない」とご記載いただくだけでも構いません。
私がメールで御社の課題を回答します。
次回は、罠2「ユーザーの巻き込み不足」。
要件定義の席に、本当のユーザーが座っていないとき、何が起きるのかを見ていきます。
参考資料
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）
