AI・DX時代の、企業の総合診療医。
AI、DX、業務、組織、人材、データ、IT。
「何をすべきか」を決める前に、まず「なぜ、その問題が起きているのか」を見る。
企業全体から本当の原因を捉え、その会社に合った処方を考え、実現まで支援します。
「まず、これをやろう」と考えていませんか？
- 全社にAIを浸透させるために、AI研修を実施する。
- DXを積極的に進めるために、DX推進担当者・推進部門を置く。
- 情シスの対応を改善するために、情シスの評価制度を見直す。
- ベテラン暗黙知を活用するために、ベテランの知識をAIに学習させる。
- 基幹システム刷新のために、現場から要件を集める。
- AI・DXを具体的に進めるために、他社のAI・DX成功事例を取り入れる。
でも、それは本当に御社にとって正しい処方でしょうか。
問題が起きているところと、問題を生み出しているところは同じとは限りません。
肩が痛いからといって、原因が肩にあるとは限らない。
私自身の経験でも、肩への対処では改善しなかった痛みが、体側を伸ばすことで楽になりました。
企業にも、同じことが起こります。
私自身、肩や首がひどく痛くなり、首を動かすのもつらい時期がありました。
何度も肩に鍼を打ってもらいましたが、なかなか改善しませんでした。
ところが、自分で身体を動かしていく中で、体側を伸ばしたときに肩が楽になり、その後、痛みもなくなっていきました。
私の場合、症状が出ていたのは肩でした。けれど、対処すべきところは肩そのものではなかったのかもしれません。
問題が見えている場所と、問題を生み出している場所は、同じとは限らない。
企業を見るときも、私はこの考え方を大切にしています。
EmzStyleは相談された問題を、そのまま問題とは考えません。
症状から本質へ。
本質から処方へ。
処方から実現へ。
「情シスの対応が遅い」
「営業担当者が動かない」
「AIを使える社員が少ない」
「システムのコストが高い」
こうした相談を受けても、EmzStyleはすぐに解決策を決めません。
その現象がなぜ起きているのか。業務、組織、人材、顧客、データ、IT、AIなどの関係を見ながら、背景にある構造を整理していきます。
そして本当に変えるべきところが見えてから、その会社に合った処方を考えます。
原因が違えば、処方も違う。だから、先に解決策を決めません。
見えている問題と、本当の問題は違うことがあります。
「情シスが遅い。評価制度を変えたい。」
ある企業から「情シスの対応が遅い。もっときちんと仕事をしてもらうために、評価制度を作ってほしい」と相談されました。
しかし詳しく見ていくと、その会社では事業を拡大するたびに似た仕組みを横展開し、複数のシステムを抱えていました。
一つ変更するだけでも複数のシステムへの対応が必要になり、事業が増えるほど保守・改修の負担も増えていたのです。
情シスが怠けていたのではありません。対応が遅くなる構造を、会社自身が作っていました。
必要だったのは評価制度ではなく、共通部分をまとめ、変更を一か所で吸収できるようにするシステム構造そのものの見直しでした。
そして私が設計、提案したのは「プラットフォーム」です。
必要だったのは評価制度ではなく、共通部分をまとめ、変更を一か所で吸収できるシステム構造そのものの見直しでした。
「営業担当者のマインドを変えたい。」
「営業担当者にもっと売ってほしい。自信がないみたいので、マインドを変える研修をしたい」という相談がありました。
しかし話を聞いていくと、問題は単純なマインドではありませんでした。
顧客の状況を整理し、課題を捉え、自社のサービスと結びつけて提案を組み立てるための力が十分に形成されていなかったのです。
「売ろうとしない」という現象と、「なぜ提案できないのか」は別の問題です。
必要なのは精神論ではなく、顧客と自社の双方を構造化し、提案を組み立てられる仕組みでした。
そこで私は、顧客の状況を構造化することと、自社のサービスや強みを構造化することの両方が必要だと考えました。
そして、その二つを結びつけながら提案を組み立てられる仕組みとして、EBA（EmzStyle Business Advisor）を活用する方法を提案しました。
「専門家の知見をAIで再現したい。」
専門家の知見をAIで再現する実証実験で、過去の入力と専門家のアウトプットを使ってAIに再現させようとしているケースがありました。
しかし、入力と出力だけを見ても、その間で専門家が何を見て、どう捉え、どんな仮説を持ち、何を確認し、何を根拠に判断したのかは分かりません。
Input → Output の間には、専門家の認識と判断の構造があります。
AIを試す前に、その見えない思考の構造を明らかにする必要がありました。
そこで専門家へのヒアリングを行い、認識や判断のプロセスを構造化。その構造をもとにAIでの再現を進めることで、安定かつ良好な結果を得られるようになりました。
では、専門家を集めれば、全体が見えるのでしょうか。
本当の原因は、一つの専門領域ではなく、
領域と領域の「関係」にあるかもしれません。
AIにはAI、ITにはIT、組織には組織、人材には人材の専門家がいます。
それぞれの専門家が、自分の領域について正しいことを言っていても、企業の問題がその専門領域の境界に従って発生してくれるわけではありません。
業務の問題がデータにつながり、データがITにつながり、ITが組織や人の役割につながり、それが顧客や経営に影響する。
問題が領域をまたいでいるなら、原因も領域をまたいで見なければ分かりません。
大切なのは、専門家が何人いるかではなく、企業という一つのシステムを、誰が一つの構造として見続けているかです。
「企業全体を、一人の視点で診る」ということ。
分業して、あとからつなぐのではない。
最初から、つながったまま見る。
広く見る。深く見る。そして、行き来する。
複数の専門家で企業全体を見ることもできます。
ただしその場合、それぞれが得た情報や仮説を共有し、互いの認識を合わせ、そのたびに全体像を更新する必要があります。
EmzStyleでは、この統合を一つの視点の中で行います。
経営から業務へ。業務からデータへ。データからITへ。ITから組織へ。そして、そこで見つけた事実から再び経営へ。
全体と細部を行き来しながら、見えてきた事実に応じて全体像そのものを更新していきます。
分業ではコミュニケーションとして行われる統合を、一つの思考の中で行う。
これが「一人の視点で診る」という意味です。
だから、企業にも「総合診療医」が必要です。
企業は、AI、IT、業務、組織、人材、データと、別々に存在しているわけではありません。
すべてがつながり、影響し合って、一つの企業をつくっています。
診るのは一人。実現するのはチーム。
人の身体が診療科ごとに分かれて存在しているわけではないように、企業もAI、IT、業務、組織、人材、データごとに分かれて存在しているわけではありません。
EmzStyleは企業全体を一つの構造として見ながら、必要なところでは専門領域の深部まで入ります。
そして、本当の原因を捉え、その会社に合った処方を設計する。
処方が決まれば、社内の担当者、専門家、ベンダーなど、実際に実行する人たちとともに実現へ進みます。
診るのは一人。実現するのはチーム。
AI・DX時代は、ベストプラクティスではうまくいかない。
他社の成功事例が、御社の正解とは限りません。
かつて多くの企業で似た業務を行っていた領域では、標準化された業務やパッケージ、ベストプラクティスを取り入れることに大きな意味がありました。
しかしAI・DXで変えようとしているのは、業務処理だけではありません。
顧客、事業、業務、組織、人材、データ、IT、そして人が行ってきた判断までが相互につながります。その組み合わせは会社によって違います。
成功事例は参考にはなる。しかし、そのまま自社の処方箋にはできません。
標準化すべきものは標準化する。固有であるべきものは固有にする。その境界を見極め、設計することが必要です。
AI・DXを、AI・DXの中だけで考えない。
AIでできることが増えたからこそ、
企業全体を構造として見ることが、より重要になっています。
AIを業務で使うには、「どのAIを使うか」だけでは足りません。
人はその業務で何を見ているのか。どの情報を使い、何と何を関連づけ、何を根拠に判断しているのか。例外をどう扱い、どこまでAIに任せ、どこを人が担うのか。
AIを深く使おうとするほど、業務、情報、データ、人の認識や判断まで理解する必要があります。
さらにAIを組み込めば、組織、役割、権限、顧客との関係、既存システムにも影響します。
AIでできることが増えるほど、それをどこに、どう組み込むのかを設計する力が重要になります。
そして…、その問題、実は数年前から始まっているかもしれません。
いま「仕方がない」と思っている問題は、
過去の判断が生み出し続けているものかもしれません。
それ、本当に仕方がない問題ですか？
AIを業務で使うには、「システムの改修に時間がかかる。コストが高い。データがつながらない。業務が複雑になっている。
その原因が、いま作られたとは限りません。
例えば過去のシステム刷新で、現場から集めた要件をそのまま新しいシステムへ移せば、古い業務や個別事情まで大量のカスタマイズとして引き継いでしまうことがあります。
最初は動いていても、年月が経つほど改修や運用の負担が増える。そして次の刷新でも同じ考え方をすれば、同じ構造をもう一度作ることになります。
いま見えている症状と、その原因は、場所だけでなく時間も離れていることがあります。
だから現在の問題だけを見るのではなく、「なぜ今の構造になったのか」まで遡って考える必要があります。どのAIを使うか」だけでは足りません。
人はその業務で何を見ているのか。どの情報を使い、何と何を関連づけ、何を根拠に判断しているのか。例外をどう扱い、どこまでAIに任せ、どこを人が担うのか。
AIを深く使おうとするほど、業務、情報、データ、人の認識や判断まで理解する必要があります。
さらにAIを組み込めば、組織、役割、権限、顧客との関係、既存システムにも影響します。
AIでできることが増えるほど、それをどこに、どう組み込むのかを設計する力が重要になります。
間違った問題を解くことほど、高くつくものはありません。
限られた経営資源を、
本当に会社が変わるところへ使う。
この診方を支えているのが、「構造知性」です。
部分ではなく、全体を見る。
要素だけではなく、関係を見る。
現象だけではなく、それを生み出している因果を見る。
では、御社の場合はどうでしょう。
他社の答えではなく、御社で何が起きているのか。
問題を整理してから相談する必要はありません。
まず、いま感じていることから話してみてください。