投稿者: 沼田 勇作

  • (8月11日通信)必要書類を毎回メールで案内していませんか?

    特集【会社の見える化】— 社外関係者視点

    取引を始めるたびに、必要書類の一覧をメールへ貼り付ける。相手から一式届いたら、足りない書類を探してもう一度連絡する。古い様式が返ってきて、最新版を送り直す。この作業が日常になっていないでしょうか。

    丁寧に案内することは大切です。しかし、同じ説明を人が毎回書き直さなければ取引が進まないなら、親切さで仕組みの不足を補っている状態です。

    添付ファイルには「今、何が必要か」が残らない

    メールで書類を案内すると、その時点の一覧は相手へ届きます。しかし、どのファイルが提出済みで、どれに不備があり、次に何を出せばよいかは、受信箱をたどらなければ分かりません。

    担当者が交代した場合、過去のメールが新しい担当者へ引き継がれていないこともあります。相手は手元にある似た様式を使い、自社は古い版だと気づいて再提出を依頼します。双方が誠実でも、原本と現在の状態が共有されていないために手戻りが起きます。

    さらに、添付ファイル名が「申請書_最新版」「申請書_最新版2」と増えると、どれが正式な版かを人が判断しなければなりません。案内文を定型化するだけでは、この問題は残ります。

    必要書類は、取引の条件によって変わる

    すべての相手へ同じ書類一式を送れば簡単に見えますが、契約の種類、作業内容、金額、法人か個人か、更新か新規かによって必要なものは変わります。不要な書類まで求めると相手の負担が増え、必要なものを見落とすと後で止まります。

    そこで、書類を単なるファイル置き場としてではなく、取引の条件と結び付けます。「この条件なら、この書類が必要」「この書類の有効期限はこの日」「この様式の現行版はこれ」と仕組みで判定できれば、担当者の記憶に依存しません。

    相手には、自分の案件に必要な項目だけをチェックリストとして表示します。提出済み、確認中、差し替え依頼、受理という状態と、差し替え理由が見えれば、電話で聞かなくても次の行動を選べます。

    ファイルの受け渡しと、業務の状態をつなぐ

    共有フォルダーを作るだけでは、どの案件の、何のためのファイルかが曖昧になりがちです。書類は取引先、案件、契約、申請などの業務記録にひも付け、誰がいつ提出し、どの版を確認し、結果がどうだったかを残します。

    相手がアップロードしたら、社内担当者の「確認する仕事」に現れる。担当者が受理したら、相手の画面は「受理済み」になり、次の工程が案内される。一つの操作が双方の状態を更新する形なら、別の管理表への転記がなくなります。

    メールは、例外の相談や説明に使えます。通常の提出、受領確認、版の案内を仕組みへ移すことで、人は判断が必要なやり取りに集中できます。

    社外共有では、見せない設計も同じくらい重要

    便利さを優先して、共有リンクを知っている人なら全ファイルを見られる状態にしてはいけません。相手ごと、案件ごと、役割ごとに、閲覧、提出、差し替えができる範囲を決めます。契約が終わった後の利用期限や、誤ったファイルを提出した場合の扱いも必要です。

    また、社内用の確認メモと、相手へ伝える差し替え理由を分ける場合があります。同じ書類についての情報でも、立場に応じて見せる範囲は違います。事実の原本を一つにしながら、権限で表示を分ける考え方が欠かせません。

    五つの書類から小さく始める

    まず、案内回数が多い手続き一つと、そこで使う主要な書類を五つ程度選びます。それぞれについて、正式名称、必要になる条件、現行版、有効期限、提出形式、受理の条件、差し替え理由を整理してください。

    次に、数社との取引だけでチェックリストを試し、案内メールの回数、提出から受理までの時間、差し替え件数を比べます。相手にも「何が分かりにくかったか」を聞けば、社内では当然だと思っていた不文律が見つかります。

    必要書類を毎回案内しなくても、相手が正しい版を選び、提出状況と次の手続きを確認できる。これは対応を冷たくすることではありません。迷わず進める道筋そのものを、サービスとして提供することです。

  • (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に必要な新しい順番ではないでしょうか。