記事0：DXは技術の話ではない

DXという言葉は、ずいぶん軽くなった。AIを入れること。クラウドに移行すること。業務を自動化すること。どれもDXの一部ではあるが、それ自体がDXの本質ではない。

多くの現場で起きているのは、「技術は導入されたが、判断は楽になっていない」という状態だ。

DXの失敗は、技術ではなく判断の問題で起きる

DXが失敗する理由は、ツール選定のミスでも、AIの精度不足でもない。本当の原因は、誰が、どこで、何を判断するのかが曖昧なまま、システムだけが先に動き始めることにある。

たとえば次の3点が決まっていない状態では、AIを入れても、クラウドにしても、判断はむしろ不安定になる。
・どこまでを自動化してよいのか
・どこからは人が判断すべきなのか
・判断の責任は誰が持つのか

このサイトでは、DXを次のように定義する。

DXとは、判断できる構造を設計すること。

それは判断をAIに任せることでも、人を減らすことでもない。 判断を減らすのか、固定するのか、人に残すのか。 その境界を先に決める行為がDXだ。

DXには、2つの極端な形がある。

・変化を前提に、判断スピードを上げるDX
・変化を抑え、判断を固定するDX

どちらが正しい、という話ではない。重要なのは、どちらの設計思想を取っているかを自覚しているかという点だ。この違いを理解せずにDXを進めると、現場は混乱し、AIは誤解され、「DX疲れ」だけが残る。

このサイトでは、DXをPMOの視点から整理していく。 PMOは、人とシステム、開発と運用、変化と不変のあいだに立ち、判断が成立する構造を整える役割だからだ。

PMOは進捗管理者ではない。判断設計のミドルウェアである。

このシリーズでは、次の問いを順に扱っていく。

・判断の境界はどこに引くべきか
・PMOとは、実際には何をしているのか
・AIに渡してよい情報、渡してはいけない情報とは何か
・なぜレガシーは残り続けるのか
・人とAIは、どう協調設計されるべきか

DXを「技術の流行」ではなく、判断設計の問題として捉え直すための整理である。