この記事は何？

AXやAI導入を設計する人が、「良さそうなものを作れたのに成果が変わらない」という失敗を避けるための知識です。

一言サマリー

AX設計の専門性とは、AI化する業務やシステム構成を決めることそのものではない。

• 何が起きれば本当に事業成果が変わったと言えるのか
• 良いものを作り切ったのに成果が出ないとしたら、何を見落としているのか
• その誤解を避けるために、何を理解し、何を疑い、何を設計する必要があるのか

それらを明らかにした上で、必要な業務変化・人間の役割・AI・データ・システムへ落とし込む役割及び技術である。

はじめに

AXの方針を決めるとは、「何を作るか」を決めることではない

ここが一番最初にすべき認識。

よくある誤解

• AX方針とは、どの業務をAI化するかを決めることである
• To-Be業務フローや状態遷移を描けば、方針が見える
• システム、Dify、Salesforceなどの役割分担を整理すれば全体設計になる
• 乱立しているなら統合方針を作ればよい

実際には

これらはすべて「何を作るか」に近い話であって、その前になぜその変化が必要なのかが存在する。

方針設計でまず必要なのは、

• 成果が出ている未来
• 全部予定通り作ったのに失敗している未来

の両方を具体的にイメージできている状態に至っていること。

その差分が見えて初めて、「何を理解する必要があるか」「何を決める必要があるか」が決まる。

テンプレ

AX設計で最初に確認する問い

AXの方針を考えるとき、最初から詳細なTo-Be業務やシステム構成を書く必要はない。

まずは次の問いに設計者が答えられるかやってみよう。

打ち合わせで先方と議論する問い一覧と言っても良い。

1. この取り組みが本当に成功したら、現実では誰の何がどう変わっているか
2. 想定したものをすべて作り切ったのに成果が変わらないとしたら、なぜか
3. 現在の事業成果を最も制約しているものは何か
4. その制約は、本当にAIや自動化で解消するものか
5. 現在の人間業務で成果を成立させている要因は何か
6. AI化によって、その要因を失う可能性はないか
7. 誰の能力をどう変えることが事業成果につながるのか
8. 今使っている職種・部署・業務区分は、本当に設計単位として妥当か
9. 現在のツールや施策が分散した原因は何か
10. 今回作るものが完成した後も、同じ問題が再発するとしたらなぜか

これらが分かった後に、状態遷移、業務フロー、データ構造、AI、システム境界、対象ユーザー、ロードマップを考える。

AX設計とは、未来のシステムを描くことではない。

成果が生まれる現実を理解し、それを阻害する誤解を一つずつ取り除いた上で、必要な変化だけを設計することである。

詳細知識

サマリー

1. AXの方針を決めることと、何を作るかを決めることは同じではない
2. 業務が楽になることと、事業成果が増えることの間には別の因果構造が存在する
3. AI化すべきなのは、人が時間を使っている場所やAIが得意な場所とは限らない
4. 現在の人間業務には、成果を成立させている暗黙の要因が含まれている
5. 「誰をどう変えるか」によって、価値のあるAXはまったく異なる
6. 職種・部署・既存業務など、今ある区分をそのまま設計単位にしてよいとは限らない
7. ツールの乱立や業務の分散は、統合するだけでは再発することがある
8. AX設計では、成功する未来だけでなく「全部作れたのに失敗する未来」を先に想像することに価値がある

1. AXの方針を決めるとは、「何を作るか」を決めることではない

状態遷移図や業務フローを作っても、それだけでは方針にはならない

• AXの検討を始めると、To-Be業務フロー、状態遷移図、システム構成、データ基盤、ツール統合方針などを作りたくなる。これらはすべて重要な設計物になりうるが、それ自体がプロジェクトの目的ではない。
• 何を判断するために必要なのかが分からなければ、どこまで細かく作るべきかも決まらない。事業全体を9つの状態に分ければ十分な場合もあれば、各状態の間に存在する数十の業務まで分解する必要がある場合もある。
• 必要な粒度を決めるのは、図の作法ではなく、その図を使って何を意思決定したいかである。

「何をアウトプットすればいいか」で迷うとき、その前の問いが決まっていない場合がある

• 状態遷移を書くべきか、As-IsとTo-Beのどちらを書くべきか、システム構成を整理するべきか、データベース方針を決めるべきか、ロードマップを作るべきか。こうした選択肢の間で迷うとき、問題はアウトプットの選択肢が多すぎることとは限らない。
• そもそも、この整理によって、どんな失敗を防ぎたいのかが決まっていないことがある。
• 整理という行為は、それ自体に価値があるわけではない。何も整理しなくても正しく進めるのであれば、整理しない方が速い。わざわざ立ち止まって可視化や意思決定を行うのは、そのまま進むと起きる失敗を避けるためである。

プロジェクト設計では、成果物より先に「何を考えなければ失敗するか」を特定する

• プロジェクト初期に必要なのは、「状態遷移図を作る」という決定ではなく、「このまま進めると、どんな重要なことを考えないまま実装へ進んでしまうか」を把握することである。
• 例えば、本当に成果へ効く業務を選べていない、人間が成果を出していた理由を消してしまう、作業時間は減るがその時間が成果へ使われない、現場が使わない、一部の職種専用の仕組みが増えて仕事が複雑になる、データが足りないため本質的には何も改善しない、といった失敗がありうる。
• これらが見えれば、その失敗を防ぐために必要な情報や整理が決まる。状態遷移も業務フローも、そのために必要なら作ればよい。設計物は思考の目的ではなく、正しい意思決定をするための道具である。

2. 業務が良くなることと、事業成果が良くなることは同じではない

作業時間が減ったからといって、売上が増えるとは限らない

• AXでは、工数削減や自動化率が分かりやすい成果として置かれやすい。しかし、「作業時間が10%減る」という変化と「売上が10%増える」という変化の間には大きな距離がある。
• 例えば、作業時間が減る → 人間の時間が空く → その時間を別の仕事へ投入できる → その仕事が事業成果を生む → 追加の成果を受け止めるだけの需要がある、という因果が成立して初めて、時間削減が売上増加へ変換される。
• 途中のどこかが成立しなければ、業務は楽になったが事業成果は変わらないという状態になる。

生産性向上は、それ自体が成果ではなく「何かを可能にする状態」である場合がある

• 同じ仕事を半分の時間でできるようになれば、生産性は上がる。しかし会社全体で見ると、同じ成果を半分の労力で出せるようになっただけという場合もある。
• コスト削減が目的なら、それは十分に成果になる。一方、売上拡大が目的なら、その余剰能力を何へ使うのかが必要になる。
• そのためAX設計では、「何時間減るか」だけではなく、減った時間によって何が新しくできるようになるのかまで考える必要がある。

削減された時間が細切れなら、別の仕事へ転換できないこともある

• 3分かかっていた処理が2分になれば、1件あたり1分が削減される。1000件あれば1000分の削減になるため、数字だけ見れば大きな改善である。
• しかし、その1分が3分ごとに発生しているのであれば、30分必要な面談を追加で行えるとは限らない。集計上は大きな時間が生まれていても、人間が使えるまとまりとして時間が生まれていない場合がある。
• そのため、どれだけ時間が減るか、誰の時間が減るか、どの単位で時間が空くか、その時間を何へ使えるかは別々に見る必要がある。

本当のボトルネックが人手ではなければ、効率化しても成果は増えない

• 人材と案件のマッチングを例にすると、成果が伸びない理由は、担当者の時間不足、求職者不足、案件不足、情報不足、良い人材への接触の遅さ、マッチング精度、顧客との信頼など様々である。
• 本当の制約が候補者不足なら、マッチング作業を高速化しても成果は増えない。逆に、人材は十分いるが接触が遅いため他社に取られているなら、1件数秒のアラートが大きな価値を持つこともある。
• AXでは、改善幅だけでなく、何が今の事業成果を制約しているのかを見る必要がある。

3. AI化すべきなのは「人が時間を使っている場所」とは限らない

人が忙しい場所と、事業成果を止めている場所は一致しないことがある

• AXでは工数調査から始めることが多く、「この業務に1000時間かかっている」と分かると、そこを自動化したくなる。
• しかし、人が時間を使っていることと、その業務が成果を制約していることは別である。大量の時間がかかっていても、それが事業成果に影響しない仕事なら改善価値は限定的である。
• 逆に、1件数分しかかからなくても、その数分の遅れによって良い候補者を競合に取られているなら、非常に重要な業務になる。

AIが得意な処理を探すことと、事業上の課題を解くことは別である

• 生成AIでは文章生成、情報整理、分類、推薦、質問応答などが比較的簡単にできる。そのため「AIで紹介文を作ろう」「企業情報を自動でまとめよう」「AIマッチングを作ろう」という発想が生まれやすい。
• しかしAIができることから施策を考えると、技術的には成立するが、事業上は重要ではないものを作ることがある。
• 例えば顧客が紹介文をほとんど読まずレジュメだけを見て判断しているなら、紹介文品質を大きく改善しても成果はほとんど変わらない。その場合に重要なのは、良いレジュメをどれだけ早く届けられるかかもしれない。

AXでは、自動化より「意思決定を変えること」の方が価値を持つ場合がある

• 事業成果を変えるために必要なのが、処理速度ではなく優先順位の場合もある。担当者が「今すぐ連絡するべき人」「今週中でよい人」「今は追わなくてよい人」を区別できていないなら、すべてのメールを高速生成するより「今日はこの3人へ最優先で連絡してください」と示す方が成果につながる可能性が高い。
• AXは作業を代替するものだけではない。組織が持っている戦略や市場理解を、日々の行動へ反映する仕組みにすることもAXである。

場合によっては、AIを作らないことが最も正しい設計になる

• 課題を深く見ると、営業リソースの配分基準を変えればよい、管理者が取り逃しを確認できればよい、データ入力ルールを変えればよい、担当者の役割を変えればよい、という結論になる場合もある。
• このとき無理にAIを入れる必要はない。AXの目的が事業成果を変えることなのであれば、AIを使ったかどうかは成果ではない。

4. 現在の人間業務には、成果が成立している理由が埋め込まれている

人間がやっている処理を再現できても、人間が出していた成果を再現できるとは限らない

• 現在の業務を見ると、入力する、確認する、候補を選ぶ、文章を書く、連絡するといった作業が見える。これらだけを再現すれば、業務を自動化できそうに見える。
• しかし人間の仕事には、違和感のある案件だけ深く確認する、顧客によって提案方法を変える、相手の温度感によって連絡速度を変える、職種理解をもとにレジュメを見る、明文化されていない例外を処理する、相手との信頼関係を前提に判断するといった、表面上の作業以外のものが含まれている。
• こうした要素が成果を支えている場合、表面の作業だけをAIへ置き換えると品質が下がる。

人間の「さじ加減」は、非効率ではなく成功要因である場合がある

• 標準化の観点では、人による判断差は問題に見えやすい。しかし、その差の中に価値が含まれている場合もある。
• 例えば与信判断では、同じ数字でも「この企業なら許容する」「この状況なら慎重にする」「この顧客なら追加確認する」という判断が存在する。
• これを単なるバラつきとして消すと、現在の成果を成立させていた判断まで失われることがある。AX設計では、「人による差をなくす」より先に、その差は何によって生まれ、成果にどう影響しているのかを見る必要がある。

システムとして完璧でも、人間が使わなければ成果は出ない

• 新しいツールが既存より高機能でも、現場が使うとは限らない。人間は、慣れている、速い、柔軟に扱える、相手も使っている、面倒が少ない、といった理由で旧来の方法を使い続ける。
• 新しいチャットツールへ移行しても、一部の人が以前のチャットを使い続けるようなことは珍しくない。そのためAX設計では、「良いものを作れば使われる」という前提そのものを疑う必要がある。

現在の人間業務を理解するとは、作業手順ではなく「成果が成立している理由」を理解することである

• AXの業務分析では、誰が何をしているかだけでは足りない。重要なのは、その行為のどこが成果に効いているのかである。
• それが分かれば、AIへ完全移管できる場所、人間の判断を残す場所、AIが人間を支援する場所を分けられる。逆にそれが分からなければ、効率化と同時に成果要因を壊す可能性がある。

5. 「誰に使わせるか」を間違えると、良いシステムでも価値がなくなる

AXの価値は、同じ機能でも利用者によって変わる

• 例えば、商談前に企業情報を調べて自動的に要点をまとめてくれるAIがあるとする。企業調査が苦手な担当者には大きな価値がある一方で、日頃から業界情報を読み込み、商談前の情報収集が既に速い担当者にとっては、ほとんど価値がない場合もある。
• 機能として有用であることと、対象者にとって価値があることは別である。

「ジュニアを平均へ近づける」と「エースの最大値を上げる」は違うAXである

• 企業によってAXに期待するものは異なる。ある会社では「誰が担当しても一定品質にする」ことに価値があり、別の会社では「上位20%の担当者がさらに2倍成果を出す」ことの方が重要かもしれない。
• ジュニア向けなら判断のガイド、情報補完、標準フロー、ミス防止が重要になる。一方でエース向けなら、判断速度の向上、情報量の増加、高度な分析、面倒な周辺作業の除去が重要になるかもしれない。

全員が使える必要はない場合がある

• AXでは「全社展開」を成功条件に置きやすい。しかし組織によっては、20%の人だけが使い、その20%の生産性が5倍になる方が事業成果として大きい場合もある。
• この場合、「誰でも簡単に使えること」より「特定の人にとって圧倒的に強力であること」の方が重要になる。AX設計では、「全員が使える方が良い」という前提も疑う必要がある。

人を強くする以外に、人から仕事を剥がすという設計もある

• すべての領域でAIと人間を協働させる必要はない。誰がやっても成果差が小さい業務は機械へ移し、人間による差が大きい業務へ優秀な人材を集中させるという設計もできる。
• AXでは、人間の平均値を上げる、人間の最大値を上げる、人間から仕事をなくす、という異なる選択肢がある。どれを選ぶべきかは事業構造によって異なる。

6. 既存の職種や部署区分を、そのまま設計単位にしてよいとは限らない

「この職種が重要」という分析と、「この職種専用のAXを作る」は別の意思決定である

• データ分析によって「インフラエンジニアは需給ギャップが大きい」「この職種は案件発生後の速度が重要」と分かることがある。これは事業上その職種を重視する根拠にはなる。
• しかし、「だからインフラエンジニア専用の仕組みを作る」とは限らない。例えば案件発生から候補者接触までの速度が重要なのであれば、それは他の職種でも同じ構造かもしれない。

市場のセグメントと、業務設計のセグメントは一致しないことがある

• マーケティング上は職種別に分析する意味がある。一方でAX設計では、成功要因が異なるか、必要な情報が異なるか、品質要件が異なるか、人とAIの役割が異なるか、オペレーションが異なるかを見る必要がある。
• これらがほとんど同じなら、職種別にシステムを分ける理由は弱い。むしろ職種ごとに別のツールを作ることで、現場の仕事パターンが増える可能性もある。

セグメンテーションそのものが設計対象である

• 既存組織には、部署、職種、顧客ランク、商品、拠点など様々な区分が存在する。しかし、それらは現在の組織運営のために作られた区分であって、AXに最適な区分とは限らない。
• AXでは、どの単位で仕事の性質が変わるのかから改めて区分を考える必要がある。

7. 「乱立しているから統合する」は、原因と結果を取り違えていることがある

ツールが増えていることは問題であっても、原因とは限らない

• 複数の部署が独自システム、Dify、スプレッドシート、Salesforce、個別の自動化を使っていると、統合したくなる。現場から見ても「どれを使えばいいか分からない」という状態になる。
• しかし、「バラバラだから一つにする」だけでは問題が解決しないことがある。なぜなら、そもそもバラバラになった理由が残っているからである。

統合しても、乱立の合理性が残っていれば再び別ツールが生まれる

• 正式システムの変更が遅い、エンジニアが不足している、現場ごとに必要な変更が多い、データへアクセスしにくい、中央チームへ頼むより自分で作る方が速い、といった状況なら、現場が独自ツールを作ることには合理性がある。
• この状態で中央システムを作っても、使いにくければ再び別のツールが生まれる。現在の乱立をN=1の事故として扱うのではなく、乱立を生み出した構造を見る必要がある。

「統合」の意味は、画面やシステムを一つにすることとは限らない

• 統合には様々なレベルがある。正式な記録だけSalesforceへ集約する、分析用データだけBigQueryへ統合する、現場ツールは自由に残す、意思決定ルールだけ共通化する、状態管理だけ一元化するといった設計もありうる。
• 監査上残す必要がある正式台帳と、頻繁に変更したい現場ツールを分けることにも合理性がある。
• AXにおける統合とは、すべてを一つのシステムに入れることではなく、どこを共通化すれば、組織として同じ失敗を繰り返さなくなるかを決めることである。

8. AX設計では、「全部作れたのに失敗する未来」を先に想像することに価値がある

技術的な失敗だけを考えても、事業上の失敗は防げない

• プロジェクトで失敗を考えると、システムが完成しない、精度が足りない、データ連携ができない、予算を超える、といったことを想像しやすい。
• しかしAXでより厄介なのは、想定通りのものが完成したのに、成果が変わらないという失敗である。
• マッチングAIは高精度になったが売上は変わらなかった、作業時間は減ったがその時間は成果に使われなかった、良いツールができたが現場は使わなかった、ジュニアは少し楽になったが事業のトップラインは変わらなかった、といった状態である。

「全部うまくいったのに失敗した。なぜか」と考えると、暗黙の前提が見える

• この問いを置くと、本当に時間不足がボトルネックなのか、本当に紹介文品質が成果を決めているのか、本当に全員が使う必要があるのか、本当に職種別に作る必要があるのか、本当に統合すれば問題がなくなるのか、といった前提を疑える。
• AXでは、実装可能性を確認するだけでなく、実装した結果が現実を変えるという仮説そのものを検証する必要がある。

成功した未来も、抽象語ではなく現実として描く

• 「AXが成功した」「生産性が上がった」「マッチングが良くなった」という抽象的な表現では足りない。
• 例えば、良い人材が登録された直後に担当者へ優先通知が届く、担当者は重要度の低い案件を追わず取れる可能性の高い案件へ集中している、管理者は本来成立したはずのマッチングを取り逃した理由を確認できる、人間による高度な判断が必要ない領域は機械が処理している、熟練者はより成果差が出る業務に時間を使っている、といった状態まで描く。
• ここまで見えれば、その状態を作るために必要なシステムも見えてくる。

成功と失敗の像が見えれば、必要な設計物は後から決まる

• 成果が出る構造と失敗する構造が見えれば、どの業務を見る必要があるか、状態遷移をどこまで書くか、どんなデータが必要か、誰を対象にするか、どの業務をAI化するか、どのツールを統合するか、どこを柔軟なまま残すかを判断できる。
• 逆にこれらが見えていない状態では、どれだけ詳細な業務フローを書いても、正しい設計になっているかは判断できない。

9. AX設計では、「それで本当に現実が変わるのか」を疑う役割が必要になる

プロジェクトは、成功する前提で考える人だけでも進んでしまう

• 開発者はどう作れば実現できるかを考える。事業責任者はどう進めれば実行できるかを考える。現場はどうすれば日々の仕事を回せるかを考える。どれも必要な役割である。
• 一方で、「全部予定通り進んでも成果が出ないとしたら？」と考える人がいない場合がある。そのままでもプロジェクトは前へ進めるからこそ危険である。

疑うというのは、反対することではなく因果を確認することである

• 「10%時間が減ります」と言われたときに、「その10%で何をすると成果が増えるんですか」と問う。
• 「紹介文が高品質になります」と言われたときに、「紹介文が高品質になると、顧客は本当に面談を増やすんですか」と問う。
• 「マッチングを高速化します」と言われたときに、「現在取り逃している理由は本当にマッチング速度ですか」と問う。
• これは施策を否定するためではない。施策と成果の間にある暗黙の仮説を表に出すためである。

良いプロジェクト設計とは、必要な思考を必要なタイミングで発生させることである

• プロジェクトが失敗する理由は、必ずしも能力不足ではない。本来考えるべきことを、誰も考えないまま進んだ結果として失敗することがある。
• だからAX設計では、何が成功なのか、どう失敗しうるのか、どんな前提を置いているのか、その前提は本当に成立するのかを序盤で考える。
• その問いによって重要な論点が数個まで絞れれば、その後はむしろ速く進める。AXの初期設計とは、長く立ち止まることではない。後で迷わず走れるように、先に間違える場所を減らすことである。