メインコンテンツへスキップ
見出し画像

「うちのDX、正直どうなんだろう」25年前の論文は、DXの失敗をすべて知っていた

    株式会社LSDC_馬場正弥

    「うちのDX、正直どうなんだろう」と思ったことはありませんか

    DXという言葉が経営の合言葉になって久しいです。予算がつき、推進室ができ、ツールが導入されます。キックオフの資料は立派でしたし、ベンダーのデモも悪くありませんでした。それなのに・・・半年後、現場では相変わらずExcelへの転記が続き、紙の記録は減らず、鳴り物入りのシステムは「一部の人だけが使う何か」になっています。

    もし心当たりがあるなら、安心してください。それはあなたの会社だけの話ではありません。

    BCGが2020年に発表した調査（経営幹部825名への調査と、同社が支援した世界大手70社のプロジェクト分析）によれば、デジタルトランスフォーメーションの70%は目標を達成できていません。McKinseyの2018年のグローバル調査（回答者1,793名）はさらに厳しく、「業績の改善」と「変化の長期定着」の両方を達成できたと答えた企業はわずか16%です。裏を返せば84%が期待した成果に届いていません。石油・自動車・製薬といった伝統的業界に限れば、成功率は4〜11%まで落ち込みます。

    つまり「DXの7〜8割は期待した成果を出せていない」というのは、悲観論でも煽り文句でもありません。世界中の大規模調査が繰り返し示してきた、ごく標準的な観測結果です。

    画像
    DXで成功している企業は3割

    しかもBCGの2024年の調査でも、期限・予算・スコープの期待を完全に満たした企業は30%にとどまります。20年近く同じことを言われ続けて、数字はほとんど動いていません。

    画像

    おかしいと思わないでしょうか。私たちはこの間に、クラウドを手に入れ、アジャイルを学び、ローコードを覚え、いまや生成AIまで使えるようになりました。道具はこれだけ進化したのに、なぜ同じ場所で転び続けるのでしょうか。

    その答えは、25年前にすでに書かれていました

    私は仕事柄、製造業を中心にシステム導入の現場に立ち会ってきました。うまくいったプロジェクトも、そうでないプロジェクトも見てきました。その経験の中でずっと引っかかっていた「失敗の既視感」の正体を、一本の古い論文が言い当てていました。

    Karl Wiegers（カール・ウィーガーズ）が2000年に発表した「10 Requirements Traps to Avoid（避けるべき要求の10の罠）」です。Wiegersは『ソフトウェア要求（Software Requirements）』の著者として知られる、要求工学の第一人者です。

    初めて読んだとき、思わずページをめくる手が止まりました。DXの現場で今日も起きている失敗が、25年前の紙面に、ほとんどそのままの形で書かれていたからです。

    「実際のユーザーが要件定義に参加しない」、「全部が『必須』とされて優先順位がつかない」、「要求が管理されないまま膨らみ続ける」、・・・。
    どうでしょうか。昨日、あなたの会社の会議室で起きていたことではないでしょうか。

    Wiegersが挙げた10の罠を、一覧で示します。まずは眺めながら、自社のプロジェクトの顔を思い浮かべてみてください。

    画像

    いくつ、思い当たったでしょうか。おそらく1つや2つではないはずです。そして重要なのは、これらの罠はどれも「気をつけていたつもりなのに、気づけば陥っている」性質のものだということです。

    なぜ25年前の罠が、いまも私たちを捕まえるのでしょうか

    ここで当然の疑問が湧きます。2000年といえばウォーターフォール全盛、分厚い要求仕様書にハンコや手書き署名を集めていた時代です。クラウドネイティブでアジャイルでAIペアプログラミングの現代に、当時の教訓がそのまま当てはまるのでしょうか、と。

    結論から言えば、当てはまります。そして開発環境がこれほど変わってもなお当てはまり続けているという事実こそ、この論文が示す本質的な問題なのです。

    もう一度、表を見直してください。

    画像

    10の罠の中に、特定のプログラミング言語の話は一つもありません。特定のアーキテクチャの話も、開発手法の話もありません。Wiegersが指摘したのはすべて、人と組織が「要求」を扱うときに陥る、普遍的な失敗パターンなのです。

    「関係者ごとに言葉の意味が違う」のは合意形成の失敗です。「本当のユーザーに聞かない」のはコミュニケーション設計の失敗です。「全部必須」は意思決定の放棄であり、「場当たり的な変更」はガバナンスの不在です。技術は25年で様変わりしましたが、要求を出すのも、解釈するのも、握りつぶすのも、相変わらず人間です。だから罠は古びません。

    それどころか、DXはこれらの罠を悪化させる条件を揃えています。ローコードは「とりあえず作れてしまう」がゆえに、曖昧な要求のまま走り出しやすいです。アジャイルの「変化を歓迎する」という美しい原則は、変更管理なきスコープクリープの免罪符に化けやすいです。生成AIは、曖昧な指示からもっともらしい成果物を量産することで、要求の曖昧さそのものを覆い隠してしまいます。冒頭の調査群が失敗の主因として繰り返し挙げるのも、技術ではなく、経営のコミットメント不足、目的の曖昧さ、組織と文化
    ——つまりWiegersが名指しした罠の、現代版なのです。

    裏を返せば、希望もここにあります。失敗の正体が「人と組織の普遍的なパターン」なら、それは学習できますし、避けられます。実際、7〜8割が転ぶ同じ道で、3割は成果を出しているのです。

    本連載の進め方

    そこで本連載では、この10の罠を一つずつ取り上げ、DXの文脈で読み替えていきます。全12話の構成は次の通りです。

    • 第0話（導入編/今回）：なぜ25年前の論文がDX失敗を予言していたのか——本稿の問題意識を掘り下げ、連載全体の見取り図を示します。

    • 第1話〜第10話（各論）：10の罠を1回に1つずつ。各回とも「Wiegersの原文では何と言っているか」「DX時代の症状（思わず『うちのことだ』とつぶやくあるあるシーン）」「なぜDXでこの罠が悪化するのか」「DX版の処方箋」「セルフチェック3問」という共通フォーマットで進めます。

    • 第11話（総括編）：要求の罠からDXの罠へ——10の罠を貫く本質を総括し、生成AIが要件定義を支援する時代に、人間に残る役割を展望します。

    画像

    各回の終わりに置く「セルフチェック3問」は、そのまま社内の定例会議で使えるように設計するつもりです。

    読み終える頃には、あなたのプロジェクトが「7〜8割」の側ではなく「3割」の側に立つための、具体的な点検リストが手元に残っているはずです。

    25年前の警告に、今度こそ耳を傾けてみましょう。そしてもし、読みながら「これはまさに、いま自社で起きていることだ」と感じる回があったなら——その違和感こそが、プロジェクトを立て直す最初の手がかりになります。

    次回は第1話『「ペーパーレス化」は要求ではない —— 経営のDXビジョンとMES機能要件の断絶』をお届けします。
    現場と経営のギャップに悩むDX担当者    の方は、ぜひアカウントをフォローしてお待ちください。

    画像

    参考資料

     
     

    株式会社LSDC_馬場正弥

     
     
    製薬ITに40年以上。MESやEBR導入を担う中で見たのは「入れたのにうまくいかない」現実。製薬製造DXの成功と失敗を現場目線で発信します。

    あなたへのおすすめ