- AIを導入するだけではビジネス上の問題は解決できず、非効率なプロセスを自動化しても、ただ「ゴミをより速く生産する」結果につながる
- 企業はAIを魔法の杖のように誤解しがちだが、AIは組織をより賢くするものではなく、単に速度を上げるためのツールにすぎない
- AIの唯一の強みは非構造化データの処理能力だが、そのようなデータに依存するプロセス自体がたいてい非構造的で、文書化されていない
- したがって、AIを適用する前にプロセスを設計し構造化する必要があり、入力・変換・出力の各段階を明確に定義しなければならない
- 技術は変わってもビジネス効率の原則は変わらず、AI成功の鍵は結局のところプロセス最適化にある
AI戦略ではなくビジネスプロセス最適化
- 企業は「AI戦略」を議論するが、実際に存在するのは**ビジネスプロセス最適化（BPO）**だけである
- AIはビジネス課題を解決する独立した戦略ではなく、すでに存在するプロセスを加速するためのツールである
- 非効率な構造の上にAIを載せても、問題をより速く拡大させるだけである
『魔法の杖』という思い込み
- 多くの企業はAIが非効率を自動的に取り除いてくれると信じているが、これは誤った前提である
- AIは知性を与えるものではなく、単に意思決定の速度を上げるだけである
- 誤った判断を自動化すれば、「光の速さで愚かな判断」を下すシステムになるだけである
- 複雑な承認手続きのような官僚的プロセスにAIを適用すると、社員のように不満を抱えたロボットを作るようなものだ
非構造化データの罠
- AIは非構造化データの処理に強みを持つ最初の技術である
- メール、Slackメッセージ、PDF、画像など、従来のソフトウェアでは扱えなかったデータを解釈できる
- しかし、そのようなデータに依存するプロセスの大半は非構造的かつ非公式である
- 例：顧客クレーム対応、マーケティングキャンペーンの企画などは文書化されておらず、経験豊富な社員の頭の中にしか存在しない
- 過去にはコンピュータで処理できず人が代わりに担っていたため、**フローチャートや標準業務手順書（SOP）**が存在しない
設計されていないものは自動化できない
- AIを適用するには、まずプロセスを明確に設計し構造化しなければならない
- 非構造化データを扱うには、ワークフローそのものに構造を与える必要がある
- そのためには次の3つの問いが必要である
- トリガー: 非構造化データはどこで発生するのか
- 変換: 人間（またはAI）はそのデータから何を抽出または解釈すべきか
- 出力: 結果はERPやCRMのような構造化システムにどう反映されるのか
速度と知能の違い
- AIはより速くするだけで、より賢くするわけではない
- 例：
- 従来方式では、アナリストが50件の契約書を3日かけてレビューする
- AI方式では、3分でリスク条項を抽出する
- プロセス自体（レビュー→リスク特定→要約）は同じだが、AIが機能するには明確に定義された手順が必要である
- 「リスク」の意味を判断する知的判断は依然として人間の役割である
結論：すべてはプロセスだ
- AIという救世主を探す代わりに、ホワイトボードに立ち返ってバリューチェーンを見直すべきである
- 特に、非構造化データが絡む人間中心の複雑な領域を可視化し、ボトルネックとムダを見つける必要がある
- プロセスがシンプルで論理的かつ堅牢になって初めて、AIを加速装置として活用できる
- 技術は変わっても、ビジネス効率の原則は変わらない
- 結局のところ、核心はいつだってプロセスである
6件のコメント
なんだかごく当たり前の話をしているような気もするけど…
継続的に「カチッとやるだけじゃなく、考えて書け」みたいな似たような文章が上がってくるのを見ると、アメリカではAIを乱用する事例が多いのかも…
2007年に軍の電算室で開発者として初めて仕事を始めたのですが、その頃は「開発者がドメインを十分に理解したうえで、ユーザー要件を磨き込み、最適案を提示すべきだ」と教わりました。
最近は「ユーザーがやってほしいと言うとおりにやってあげる」が主流のようですね。実際、ユーザーもそのほうが好きなのかもしれません..?
（金融業界のSIをやっています）多くの開発者に対して、あなたは専門家なのだから、顧客に言われたとおりにするのではなく、顧客に「あなたたちはこう働くべきだ」と伝えるのはどうか、と聞いてみた。
> 結果は想像どおり。
どういう意味ですか？
「結果は想像しているものと同じ」というのがどういう意味かを尋ねているのであれば。
特に意味はなく、ただそういうニュアンスの言葉遊びの一種として書いたものです。
Hacker Newsの意見
私が最も気に入っている プロセスとドキュメント化 に関する逸話の1つ。
ヘッジファンドで働いていたとき、毎晩翌営業日の取引準備を行う18段階の手順のうち、7番目の段階が失敗した。
私はその段階を文書化して何人かに見せたが、全員が「7番目の段階の文書は間違っている」という点では一致した一方で、「7番目の段階が実際には何をすべきか」についてはまったく合意できなかった。
この経験を通じて、単に 「今起きていることを書き出す」 だけでも、人々が実際のプロセスを理解し、合意するうえで大きな前進になるのだと気づいた。
以前、市場データシステムの文書を書いていたときも、「そんなに複雑ではない」と言っていた人たちが、完成した文書を見て「思ったより複雑だな」と言っていたのを覚えている。
「今は7番目の段階が実際に何をしているかを書く時間であって、どう変えるかを議論する時ではない」と言っても、どうしても混ざってしまう。
まずは間違ったやり方でも1つに整理しておき、あとで直すのが正しいと思う。
結局「文書化しないでおこう」という結論になったが、それがむしろより大きな問題だった。
文書化は合意の基準線を作ってくれるし、新しく参加した人たちも不要な細部の論争なしに仕事ができる。
今では、明確なプロセスなしに大きな仕事をするなど想像もできない。
あるCEOの5段階の製品プロセスを思い出す。
AIはこの中で、いつ投入すべきかが明確でなければならない。
多くの人がこの順番を逆に適用して失敗する。
あまりに過小評価されているが、人類の発明の中でトップ5に入るべきだ。
「AIでめちゃくちゃなビジネスプロセスを黄金に変えることはできない」という一文が印象的だった。
結局 AI戦略というものはなく、あるのはビジネスプロセス最適化だけだ。
名前の付け方が間違っていたのだと思う — 「Redesign」ではなく「Design」であるべきだった。
顧客番号統合の試みが完全にこんがらがり、結局新しい番号を付与しながらも古い番号を使い続けるという混乱が生じた。
こんな会社がAIを導入していたら、どんな 混沌 が起きていたか想像できる。
何十年にもわたるコスト削減と人員削減でプロセスは壊れ、今では大企業でさえまともに機能しなくなっている。
AI企業はこうした廃墟の上でデータをのみ込み、LLMの出力 として返して金を稼いでいる。
大企業における プロセス については複雑な感情がある。
平均的な人たちから良い結果を引き出すには有用だが、優秀な人たちにとってはかえって足かせにもなる。
だから私は、優秀な人材には 例外権限 を与えるのが現実的だと考えている。
彼らが素早く動いて集中できるよう、手続きの一部を免除するような形だ。
こうしたアプローチがプロセスそのものにとって何を意味するのか、今でも考えている。
よく発生するケースには明確なプロセスを用意しつつ、優秀なエンジニアが素早く対応できる 抜け道 も必要だ。
平均品質を引き上げると天井が低くなるという構造的な問題だ。
良いプロセスは、ロックスターがさらに速く働けるよう助けるべきだ。
文書作業をプロセスと取り違える管理が問題だ。
めちゃくちゃな依頼や非協力的な行動が繰り返されると、結局は手続きを強制するしかなくなる。
創造的な試みが減るとしても、無秩序のコストのほうが大きい。
ServiceNowのフォームを1つ立てるだけでも前進 と見なされる現実だ。
「AIは非構造化データを扱う最初の技術だ」という一文がよかった。
非構造化データを扱うプロセスはたいてい非構造的だ、という要約が気に入った。
外部世界や別チームとの 非構造的な相互作用、あるいは変動性が高すぎることが原因だ。
経験豊富なプロセス設計者は、このような 「半構造化された境界」 を認め、注意深く観察する。
AIもこうした原則に従うべきだ — システムの範囲を過度に広げず、小さく構造化されたプロセスが非構造的な環境の中に浮かぶようにすべきだ。
構造化データがなかった時代でも、うまく回っていた会社は多かった。
検索分野で13年間働いて感じたのは、経営陣が常に 「流行の技術」でコスト削減 を夢見る一方で、実際にはもっと深い投資が必要だということだ。
「既存技術には問題があるが、新しい名前で包装された技術 こそが本当の削減効果をもたらす」と言って、新たな流行を売り込み始める。
20年間 プロセス自動化 をやってきて感じるのは、定義されていないプロセスを自動化しようとすると失敗するということだ。
要件を定義する過程が、むしろ会社をより明確にする場合もあったが、たいていはそれを避けようとする。
その代わり、ツールに柔軟性を持たせようとして、結局は何の役にも立たない道具になってしまう。
別のチームがデータ処理ワークフローを単純化するツールを欲しがっているが、現在のプロセス文書すら存在しない。
結局こちらが彼らのプロセスを逆分析しなければならない状況になっている。
Fred Brooksの「No Silver Bullet」を引用したくなる。
リンク
複数の会社でERP導入を見てきたが、既存プロセスをそのまま移そうとして カスタマイズ地獄 に陥っていた。
予算もスケジュールも常に超過していた。
この文章は核心を正確についていると感じた。
プロセスが多すぎる のは問題だが、構造そのものは常に必要だ。
AIは構造化データをうまく扱うので、完全な自由よりも 適切な構造とのバランス が重要だ。
関連リンク
文書化は考えを明確にするうえで非常に有用だ。
繰り返している作業を書き出した瞬間、不要な手順を減らすアイデア が浮かぶ。
今は自分のビジネス運営の一部をAIに任せようとしている。
小さなeコマースブランドを買収するとき、LLMに初期分析を担当させるため、6ページのプロンプトを作って使っている。
この経験を通じて、LLMの知能よりも構造化された作業設計 のほうが経済的価値を生むのだと気づいた。
ただし、まだWebブラウジングやファイルアップロードを自動で処理してくれるエージェントがないため、完全自動化は難しい。