投稿者: 沼田 勇作

  • (8月10日通信)DXからXDへ

    デジタル設計から変革化ではなく、
    変革設計からデジタル化を考える

    DXという言葉が広く使われるようになりました。

    業務をデジタル化する。
    紙をなくす。
    Excelをシステムへ置き換える。
    生成AIを導入する。
    クラウドサービスを利用する。

    もちろん、これらも大切です。

    しかし、一つ大きな疑問があります。

    デジタル化した結果、会社がどのように変わるのかを、デジタル化する前に設計しているでしょうか。

    私たちは、これからのDXには順番そのものを見直す必要があると考えています。

    そこで提案したいのが、

    DXからXDへ。

    本稿ではXDを、

    Transformation → Digital

    つまり、

    「変革を先に設計し、その変革を実現するためにデジタル化する」

    という考え方として使います。


    「とりあえずデジタル化」が危険な理由

    現在行っている業務を、そのままシステムへ置き換える。

    これは一見すると合理的です。

    紙の申請書をWebフォームへ変える。
    Excel台帳をデータベースへ移す。
    人が行っていた集計をAIに任せる。

    しかし、それだけでは現在の会社の構造をデジタル上に再現しただけかもしれません。

    本来考えるべきなのは、その前です。

    そもそも、その申請は必要なのでしょうか。

    その承認は人間が行う必要があるのでしょうか。

    その情報は誰が入力すべきなのでしょうか。

    AIが判断できる部分はないのでしょうか。

    顧客自身に入力してもらった方が合理的ではないでしょうか。

    会社が10倍の規模になったときも、その業務は同じでしょうか。

    こうした問いを飛ばして現在の業務をそのままデジタル化すると、今存在している非効率までシステムの中へ固定してしまいます。

    そして数年後、

    「会社の組織を変えたい」

    「AIを導入したい」

    「承認工程を減らしたい」

    「拠点を増やしたい」

    と思ったときに、今度はシステムそのものが変革の障害になることがあります。

    DXのために作ったシステムが、DXを妨げる。

    そんな逆転現象が起こり得るのです。


    先に「未来の会社」を設計する

    私たちが考える順番は逆です。

    まず、

    この会社を、将来どのような会社へ変えたいのか。

    を考えます。

    そのうえで、

    誰が働くのか。

    どの仕事を人間が行うのか。

    どの仕事をAIに任せるのか。

    誰が判断するのか。

    誰が承認するのか。

    顧客や取引先はどこまでシステムへ参加するのか。

    どのようなデータが必要なのか。

    誰がそのデータを見ることができるのか。

    会社が成長したときに組織や権限をどう変えるのか。

    を設計していきます。

    つまり、

    未来の会社像

    業務構造

    人・AI・システムの役割

    データ・権限・状態

    デジタル実装

    という順番です。

    デジタルから会社を考えるのではありません。

    会社からデジタルを考える。

    これがXDという考え方です。


    システム設計はIT部門だけの仕事ではなくなる

    ここで重要になるのがシステム設計です。

    経営者がプログラムを書く必要はありません。

    システム開発会社へ依頼してもいい。

    フリーランスへ依頼してもいい。

    社内エンジニアに作ってもらってもいい。

    生成AIにコードを書かせてもいい。

    重要なのは、

    何を作らせるべきなのかを、経営側が理解していることです。

    なぜなら、これからの会社では、

    人間だけでなく、

    システム、

    生成AI、

    AIエージェント、

    外部サービス

    が会社の業務を構成するようになるからです。

    将来の会社をイメージするためには、将来のシステム構造まである程度イメージできなければなりません。

    逆に言えば、

    イメージできない会社を実現することはできません。

    そして、

    言語化できないシステムを、AIにも開発会社にも正確に作らせることはできません。


    「動けば完成」ではない

    ホームページや短期間のマーケティングツールであれば、

    表示される。

    フォームが送信できる。

    広告効果を計測できる。

    それで目的を達成できるものもあります。

    しかし業務システムは違います。

    使い始めた瞬間から、

    顧客情報、

    契約、

    請求、

    在庫、

    社員、

    権限、

    承認、

    業務履歴

    といった会社そのものの情報が蓄積されていきます。

    だから、

    動いたから完成

    ではありません。

    社員が増えても使えるか。

    部署が増えても対応できるか。

    権限変更に対応できるか。

    同時に多くの人が操作しても壊れないか。

    AIを追加できるか。

    業務そのものを変更できるか。

    こうした変化へ耐えられることが重要です。

    業務システムにおける完成とは、

    「動くこと」ではなく、「変え続けられること」

    なのです。


    AI時代だからこそ、設計が重要になる

    生成AIによって、コードを書くことのハードルは急速に下がっています。

    これは非常に大きな可能性です。

    これまでシステム開発会社へ依頼しなければ作れなかったものを、企業自身が作れる時代が始まっています。

    しかし同時に新しい問題も生まれます。

    設計を知らなくても、

    画面を作れる。

    データベースへ保存できる。

    ログイン機能を付けられる。

    APIへ接続できる。

    テストコードまで生成できる。

    つまり、

    設計を知らなくても、それなりに動くシステムまで作れてしまう。

    以前なら技術力不足によって途中で止まっていたものが、AIの支援によって完成してしまう可能性があります。

    だからこそ、

    AI時代に価値が上がるのは、コードを書く能力だけではありません。

    何を作るべきか。

    どのような構造にすべきか。

    どんな権限が必要なのか。

    どんなデータを残すべきか。

    会社が成長したときにどう変化できるのか。

    それを判断する設計力です。


    内製化すべきなのは「開発」ではなく「設計」

    私たちは、すべての企業がプログラマーを抱える必要があるとは考えていません。

    開発は外注しても構いません。

    むしろ高度な専門技術は、専門家へ頼んだ方が合理的です。

    しかし、

    会社の未来をどう設計するのか。

    ここまで外部へ丸投げしてしまえば、会社の将来そのものを外部へ委ねることになります。

    だから企業が本当に内製化すべきなのは、

    プログラミングではありません。

    設計判断です。

    何を作るのか。

    なぜ作るのか。

    誰が使うのか。

    誰に何をさせるのか。

    AIへ何を任せるのか。

    会社が成長したらどう変えるのか。

    ここを自社で考えられるようになる。

    そうすれば、開発会社とも対等に話せます。

    複数の開発会社を比較できます。

    生成AIも正しく使えます。

    専門家へ頼むべき部分も見えてきます。


    DXからXDへ

    デジタル化してから、会社がどう変わるかを考える。

    その順番ではありません。

    変えたい会社を先に描く。

    そして、その会社を実現するために、

    業務を設計し、

    人とAIの役割を設計し、

    システムを設計し、

    最後にデジタル化する。

    これから必要なのは、

    デジタル設計から変革化ではなく、
    変革設計からデジタル化を考えること。

    だから私たちは提案します。

    DXからXDへ。

    デジタル化を設計する前に、変革を設計しよう。

    未来の会社を先に描き、

    その未来を実現するために、

    デジタルを使う。

    それが、AI時代のDXに必要な新しい順番ではないでしょうか。

  • (8月9日通信)承認待ちの仕事は、なぜ止まったままになるのか?

    特集【会社の見える化】— 従業員視点

    申請を送ったのに返事がなく、作業を進められない。催促してよいのか迷っているうちに期限が近づき、最後は口頭で急いで承認してもらう。承認待ちの仕事が多い会社では、この光景が繰り返されます。

    承認者が忙しいことは事実でしょう。しかし、止まる原因を個人の忙しさだけにすると、承認者を替えても同じ問題が起きます。見えなくなっているのは、承認という仕事そのものです。

    メールやチャットは、承認の一覧にならない

    申請をメールで送り、チャットでも一言知らせ、急ぎなら口頭で伝える。連絡手段を増やすほど確実に見えますが、承認者にとっては依頼が複数の場所へ散らばります。どれが未処理で、いつまでに、何を基準に決めるのかを一目で確認できません。

    申請者側にも、届いたのか、読まれたのか、判断材料が不足しているのか、他の承認者へ回ったのかが見えません。「承認待ち」という一語だけでは、待つべきか、補足すべきか、別の仕事を先に進めるべきかを判断できないのです。

    その結果、慎重な社員ほど確認を繰り返し、遠慮する社員ほど期限直前まで待ちます。個人のコミュニケーション能力によって処理速度が変わる状態になります。

    承認依頼を、一つの仕事として記録する

    承認を見える化するには、申請書を電子化するだけでは足りません。一件の承認依頼について、次の情報を一つの場所にそろえます。

    • 何を決めてほしいのか
    • 申請者と現在の承認者は誰か
    • 判断に必要な資料と、申請者の推奨案
    • いつまでに決まらないと、何が止まるのか
    • 承認、差し戻し、保留のどの状態にあるか
    • 差し戻しの場合、何を直せば再申請できるか

    承認者の画面には自分が判断すべき依頼を期限順に表示し、申請者の画面には現在の承認者と状態を表示します。誰かが個別に進捗表を更新するのではなく、承認や差し戻しの操作そのものが状態を変えます。

    通知を増やす前に、期限と優先順位を決める

    滞留対策として通知を何度も送ると、最初は反応が良くても、やがて通知が背景になります。すべてが「至急」なら、何も優先できません。

    通常の回答期限を決め、期限が近いもの、影響が大きいもの、申請から長く動いていないものを区別します。承認者が画面を開いたときに、今日判断すべき件数と順番が分かれば、申請者ごとの催促に頼らず処理できます。

    出張や休暇のときに誰が代行するのか、一定時間を超えたら誰へ知らせるのかも、事前に決めます。例外時の経路がないまま自動通知だけを追加しても、止まっていることを繰り返し知らせるだけです。

    そもそも承認が必要かを問い直す

    見える化すると、少額の購入や定型的な値引きまで、同じ人が毎回承認していることに気づく場合があります。これは処理を速くするだけでなく、承認の設計を見直す機会です。

    金額、粗利率、契約条件、顧客への影響などに基準を設け、範囲内なら担当者が実行し、範囲を外れた案件だけを承認へ回せます。低い危険まで上司が決め続けると、重要な判断が小さな依頼に埋もれます。

    承認を減らすことは、統制を弱めることではありません。決めてよい範囲を明文化し、実行の記録を残すことで、事前承認よりも実態が見える場合があります。

    最初は、最も滞留する一種類を選ぶ

    経費、見積もり、発注、契約など、承認の種類を一度に統合する必要はありません。まず一か月分を振り返り、待ち時間が長い、または止まったときの影響が大きい申請を一つ選びます。

    申請日時、承認日時、差し戻し回数、期限超過、必要だった補足を記録し、どこで時間を使ったかを確認します。人を責める集計ではなく、判断材料の不足、承認者の集中、期限の不明確さといった構造を見つけるための記録です。

    承認待ちが見えるようになると、社員は「返事が来るまで何もできない」という不安から解放されます。待つべき期限と、その間に進められる仕事が分かり、例外だけを適切な相手へ相談できます。承認の見える化は、上司を急かす仕組みではなく、会社の判断を仕事として流す仕組みです。