DX

価値設計、業務変革、選択と廃止、システム変革、継続的価値創出。DXを技術導入ではなく、業務・サービス・システムの変化として考えるための記事を整理しています。

技術を選ぶ前に、何を、なぜ変えるのかを考えます。

価値から始め、仕事の流れ、既存システム、維持や終了、導入後の改善を見渡すための地図です。

DXは業務・価値・組織の変化を扱います。何をシステム化し、何を対象外とするかの意思決定は企画で整理します。企画とDXは重なる場合がありますが、同義ではありません。

DXを考える5つのテーマ

新しい技術を使うことと、価値を生むことは同じではありません。

誰のどんな困りごとを減らすのかを先に定め、業務・サービス・システムを逆算します。AIも、その価値を届けるための手段の一つとして選びます。

DXを学んで、「価値」という言葉が気になるようになった
DXを学ぶ中で出会った「価値」という視点が、AI・RAG・エージェントを見る順序をどう変えたか。技術導入ではなく、誰の仕事や判断をどう変えるかからAIを考える。

現行業務を速くする前に、その作業が本当に必要かを確かめます。

ECRSの観点で削除・統合・順序変更・簡素化を考え、残る仕事を人・AI・既存システムへどう分けるかを設計します。個々の作業速度ではなく、仕事全体の流れを見直す領域です。

AI化する前に、業務そのものを疑う
AIへ任せる前に、その仕事をなくす・まとめる・変える・単純化できないか考えます。業務改善の手順（ECRS）を踏まえ、残る仕事を人間・既存ソフトウェア・AIのどれへ任せるか判断します。

作ることだけが設計ではありません。

残す・変える・統合する・作らない・終わらせることも、価値と維持責任から判断します。生成コストが下がるほど、何を作らず、何を残さないかを選ぶ意味が大きくなります。

IT戦略では「何を作らないか」も設計する
システムを新しく作る前に、保守・変更・移行・廃止までの負担を考えます。既存の仕組みを使う選択も含め、作るものと作らないものを判断します。

既存システムは、全面刷新だけで変えるものではありません。

現行仕様と依存関係を理解し、継続保守・移行・統合を進めながら、変更しやすさ（Changeability）を確保します。Legacy Modernizationを、必要なら安全に終わらせるところまで含めて考えます。

レガシーシステムは、変えやすくしながら終わらせる
廃止予定でも変更要求が続く既存システムを、どう保守しながら終わらせるか考えます。依存や変更箇所を減らし、役割を段階的に移す判断を整理します。

導入したことを完成とは捉えず、実際の利用と失敗から改善を続けます。

品質・工数・確認負荷を見て、仕組みが価値を生んでいるかを確かめます。評価や現場の学びを次の設計へ戻し、別の業務へ広げるときも成立条件を見直します。

AI導入を業務へ定着させる
AIツールを配るだけでなく、日々の仕事で使い続けられる条件を考えます。人が確認する場面、失敗時の対応、運用結果を改善へ戻す方法を整理します。