同じ導入手法を採用しても、企業が異なれば結果には大きな差が生じます。私たちは導入支援の現場で繰り返し観察した結果、その違いは通常、手法そのものではなく、4 つの組織的な条件から生まれることに気づきました。誰が推進するのか、リーダーが関与しているか、AI プロジェクトチームのメンバーをどう選ぶか、そして業務プロセスが事前に明確になっているかという点です。
この 4 つは基本的なことに見えますが、タスクの品質、実際の利用率、部門間調整のスピードを直接左右します。どれほど完成度の高い手法を設計しても、実行条件が異なれば、最終的な成果にも明確な差が表れます。
一、推進責任を担う部門には業務プロセスを理解する力が必要
導入推進の責任者には、業務プロセスを定義する能力と、部門間の調整に必要な権限の両方が求められます。この観点から、推進責任を担うのに適しているのは、通常、総合管理部門、社長室、経営企画室、または管理部門のプロジェクトマネージャーです。情報システム部門の責任者が ERP も管轄し、各部門の業務手順にも精通している場合は、例外的に適任となることもあります。
私たちが見てきた成功例では、経営企画部門のプロジェクトマネージャーが全体を統括し、毎週、部門責任者とともに職務リストを確認したうえで、事業価値に基づいてタスクの優先順位を決めていました。データ連携やシステム環境の問題が発生した段階で、初めて情報システム部門に対応を依頼します。
一方、すべての要望を情報システム部門に丸投げするケースもよく見られます。現場部門は「レポート作成用の AI を一本作ってほしい」とだけ伝えます。しかし、情報システム担当者が、そのレポートが現場でどのように使われているかを理解しているとは限りません。また、前後工程を担う部門に引き継ぎ形式の変更を求める権限もありません。要望は提出されたように見えても、本来定義すべき業務プロセスやルールは、手つかずのまま残ってしまいます。
業務プロセス改善の専任部門がない企業では、社長が部門横断プロジェクトの窓口担当者を一人指名し、情報システム部門にも共同窓口を置く方法があります。前者が調整とタスクの定義を担当し、後者がシステム環境と連携を担当することで、情報システム部門だけに業務要件の責任を負わせない体制をつくります。双方とも毎週決まった時間を確保し、継続的に導入作業を進める必要があります。そうしなければ、プロジェクトは日常業務に押され、後回しになりがちです。
二、リーダーは自ら構築する必要はないが、自ら利用する必要がある
リーダー自身が AI を利用すると、組織には二つの明確なメッセージが伝わります。この取り組みが会社にとって本当に優先度の高いものであること、そして試行錯誤の過程での失敗が許容されていることです。管理職が自らタスクを構築する必要はありませんが、少なくとも管理業務向けのタスクを一つか二つ継続的に使い、データが正しいか、結果が意思決定に役立つかを実際に確かめるべきです。
たとえば、社長が毎週同じタスクを使って受注状況や異常の要約を確認し、データの定義に誤りがあれば、担当部門に直接ルールの修正を求めます。このような関わり方をすれば、完成したタスクが実際に使われ、その結果に基づいて意思決定が行われていることをチームも理解できます。
反対に、会長がキックオフミーティングで挨拶しただけで、その後は姿を見せず、月例会議になって初めて「なぜ利用量が増えないのか」と尋ねるようでは、現場も判断に迷います。これは会社が本気で推進している取り組みなのか、それともまた一つの短期プロジェクトにすぎないのかが分からないからです。
リーダーがどうしても自ら操作する時間を確保できない場合は、意思決定権を持つ経営幹部をビジネスオーナーに指名し、毎月、成果レビューを主宰してもらう方法があります。そのうえで、スタッフがタスクの利用状況、失敗回数、削減できた作業時間、意思決定が必要な事項をまとめた 1 ページのダッシュボードを用意します。最低限、リーダー自身が三つの意思決定を行う必要があります。導入範囲の承認、部門間の対立への対応、そして次の段階に必要なリソースの確定です。
三、AI プロジェクトチームでは、挑戦する人と熟練者を組み合わせる
若手社員は一般的に新しいツールを試すことに前向きであるため、最初のチームに加えるのに適しています。ただし、年齢だけを基準に選んではならず、ベテラン社員を除外するべきでもありません。安定した成果を得やすいのは、新しいことに挑戦する意欲のある社員と、業務プロセスに精通したベテラン社員を組み合わせる方法です。前者が構築を担当し、後者がルールを提示して検証にも参加します。
図面審査を例にすると、日頃から AI をよく使っているエンジニアを一人選び、図面審査に精通したベテラン社員と組ませることができます。二人はワークショップで実際の図面を使ってタスクの初版を作り、その後、ほかの社員にテストしてもらいます。ツールの操作スキルと現場経験を同じテーブルに載せることで、タスクを実務に即したものにできる可能性が高まります。
最も問題が起きやすいのは、管理職が単に「最も手が空いている人」をチームに指名するケースです。このようなメンバーは研修に遅刻せず参加し、課題も提出できるかもしれません。しかし、部門に戻ると、そのタスクは二度と実行されなくなります。本人が業務プロセスに精通しているとは限らず、その後もメンテナンスを続ける意思があるとも限らないからです。
適任者がすぐに見つからない場合は、役職や等級を問わず社内公募を行い、応募者に自分が改善したい定型業務を一つ持参してもらう方法があります。また、二人一組の体制を採用し、技術系のメンバーがツールを担当し、業務プロセスに詳しいメンバーが内容を担当することもできます。どの方法を採る場合でも、構築、共有、メンテナンスの時間を正式な勤務時間に組み込み、プロジェクト評価の対象にする必要があります。メンバーが就業時間後に自主的に取り組むことだけに頼ってはいけません。
四、まず業務プロセスを可視化してこそ、適切なツールを選べる
部門が自らの業務プロセスを明確に説明できない段階では、AI Agent の構築を急ぐべきではありません。少なくとも、開始条件、入力情報、主要な手順、成果物、受け手、例外事項を書き出す必要があります。業務プロセスを可視化して初めて、文書認識、ナレッジ Q&A、表データの検索のどれを使うべきか、あるいは、その業務にはそもそも AI が必要ないのかを判断できます。
購買部門の見積業務は、分かりやすい例です。まず、プロセスを「見積書の受領」「項目の統一」「条件の比較」「差異の表示」「上司による価格承認」という五つのステップに分けます。次に、どの工程が AI に適しているかを判断し、最終的に最初の四つを AI に任せ、価格承認は上司が行うようにします。これなら役割分担が明確であり、管理責任も維持できます。
別のよくある進め方は、会社が先に自動化ツールの購入を決め、その後で各部門に「活用シーンを探す」よう求めるものです。しかし、入力形式や責任の所在が確認されていなければ、システムが完成しても、現場では依然として人手でデータを整理し直さなければなりません。ツールは稼働しているように見えても、従来の業務負担は実際には軽減されていないのです。
業務プロセスが本当に混乱している場合でも、最初からすべての制度を整理しようとする必要はありません。まずは 90 分間のプロセスワークショップを開き、直近で完了した実際の案件を一つだけ選び、その案件が実際にたどった流れを図にします。次に、待ち時間、手戻りが生じた箇所、判断が必要なポイントを明示し、その中から最もルールが明確な業務を一つ選んで、AI Agent に支援させます。
四つの条件は相互に影響し、一つでも弱ければ停滞する
この四つの条件は、実際にはすべて密接に関連しています。推進部門が業務プロセスを理解していなければ、選ぶべきタスクを誤りやすくなります。リーダーが関与しなければ、部門間の対立が起きても最終判断を下す人がいません。チームメンバーの選定を誤れば、タスクが完成してもメンテナンスする人がいなくなります。業務プロセスが整理されていなければ、ツールを購入しても活用できません。
企業は AI を導入する前に、この四つの観点から自社の準備状況を確認できます。現在最も弱い部分がどこかを見極め、どこから補強するかを決めます。そうすることで、AI 導入を単なるツールの構築で終わらせず、各部門の日々の業務プロセスに本当の意味で組み込めるようになります。
本記事は、Intellicon Solutions の『Agent-Ready：台湾製造業 AI 活用白書』から抜粋したものです。本白書では、ナレッジの資産化、業務プロセスの連携、ガバナンスによる承認、組織の推進力という四つの観点から、企業が自社の AI 導入準備度を判断する方法を解説し、12 項目の自己評価シートも収録しています。