メインコンテンツへスキップ
見出し画像

AIの相談をしているのに、なぜ事業部と情シスの話がかみ合わないのか?

    情報システム部門(情シス)やDX推進部門の会議では、事業部から寄せられるAI活用の相談について、こんな声が出ることがあります。

    「事業部からAIをやりたいと言われるが、要件が曖昧すぎる」

    何に困っているかを聞いても、「AIで何かできないか」という話に戻ってしまい、技術的な確認を始めると事業部の反応が鈍くなります。相談を受ける側には、そんな戸惑いがあります。

    一方、事業部も「情シスに相談すると、すぐにデータやセキュリティの話になる」と感じています。AIで何ができるのかを知りたいのに質問ばかりされ、自分たちの業務を理解してもらえない、という不満です。

    このすれ違いは、どちらか一方の問題ではありません。事業部は業務の困りごと、情シス・DX部門は実現性とリスク、経営は投資価値を見ています。

    同じAIの相談でも、確かめたいことは部門によって違います。その違いを整理しないまま進めると、PoCは始められても、本導入の段階で話が止まってしまいます。

    画像

    事業部の要望を、検証できるユースケースに変える

    情シス・DX部門には、ツールの導入だけでなく、事業部の困りごとを具体的な活用場面へと整理する役割があります。誰のどの業務でAIを使い、何を検証するのかが分かる形にするのです。こうした具体的な活用場面を「ユースケース」と呼びます。

    例えば、事業部から「契約書チェックをAIでやりたい」と相談されたとします。

    そこで、どのAIモデルを使うか、データはどこにあるか、セキュリティ要件は何か、と技術面の確認から始めると、事業部は話についていけなくなります。まずは、実際の業務に沿って次の点を確かめます。

    • 契約書チェックで一番時間がかかるのはどこか。

    • 判断ミスが起きると、どのようなリスクにつながるか。

    • 新人と熟練者で差が出るのは、どの判断か。

    • 過去のレビュー結果は残っているか。

    • AIが案を出した後、誰が最終確認するか。

    • PoCで何が分かれば、次の判断に進めるか。

    こうして業務を確かめると、「AIで契約書を読む」という要望を、「法務の一次確認にかかる時間を短縮し、抜け漏れのリスクを下げる」という目的に置き換えられます。このように目的を具体化すると、何を検証するためにAIを使うのかを、事業部と共有できます。

    技術説明が早すぎると、事業部は受け身になる

    情シス・DX部門が得意とする技術説明には、RAGやAPI(システム同士をつなぐ仕組み)による連携、権限管理、ログ、モデル選定、セキュリティ、クラウドコストなどがあります。いずれも導入に欠かせない論点です。

    ただ、最初の会話で技術の話が前に出すぎると、事業部は「詳しいことは情シスに任せます」「必要なデータがあれば言ってください」と、導入を任せる側に回りがちです。「できるならやってください」となれば、AI活用は情シスだけの案件になってしまいます。

    ところが、本導入の段階では、事業部が日々の業務の進め方を変えなければなりません。例えば、次の点は事業部と一緒に決める必要があります。

    • AIが出した結果を、誰が確認するのか。

    • どの判断を人に残すのか。

    • 例外が起きたときは、どう処理するのか。

    • 業務フローのどこを変えるのか。

    これらは、情シスだけでは決められません。

    KPMGは、AIの試験導入が全社展開で止まる要因として、データ定義の不一致、セキュリティや監査要件の拡大、業務フローの再設計が行われていないことを挙げています。技術が動くかに加えて、業務・データ・管理の仕組みを一体で設計できているかが問われます。

    事業部を巻き込むとは、一緒に業務を設計すること

    事業部を巻き込むという言葉から、協力をお願いする姿を思い浮かべるかもしれません。AIユースケースの選定では、もう一歩踏み込み、関係者が一緒に業務を設計する必要があります。

    それぞれの部門には、設計に欠かせない知識や視点があります。

    • 事業部:業務の困りごと、判断基準、例外処理、現場での使い方。

    • 情シス・DX部門:データ、システム、セキュリティ、運用、技術上の制約。

    • 経営・企画部門:投資判断、他部門への展開、成果を測る指標(KPI)。

    それぞれの知識を持ち寄り、三者で次の問いへの答えをそろえます。

    「このAIテーマは、誰のどの業務を、どのように変えるのか」

    答えを共有しないままPoCへ進めば、検証を終えたところで、また同じ問いに戻ることになります。

    画像

    最初の打ち合わせで、確かめたい六つのこと

    事業部との最初の打ち合わせでは、次の質問が役立ちます。事業部を問い詰めるためではなく、曖昧な要望を実行可能なユースケースにするための問いです。

    業務を特定する その業務では、いつ、誰が、何を見て判断していますか。

    負担を確かめる いま一番時間がかかっている作業はどこですか。

    判断の違いを見つける 熟練者と新人で差が出る判断はどこですか。

    データを確認する その判断に使っている情報は、どこに残っていますか。

    人の役割を決める AIの出力を、誰がどの基準で確認しますか。

    効果を測る PoCで何が分かれば、次に進めますか。

    情シスだけで決めてはいけないこと

    情シス・DX部門が注意したいのは、業務上の最終判断まで、情シス側で決めてしまうことです。

    AIにどこまで答えさせるか、人がどこで確認するか、例外処理をどこに回すか、成果指標を何にするか。技術要件に見えるものもありますが、実際には業務の進め方に関わる判断です。

    情シスが一方的に設計すれば、現場にとって使いにくい仕組みになりかねません。逆に、事業部だけで決めると、データやセキュリティの制約を見落とします。互いの知識を持ち寄って設計する必要があるのは、そのためです。

    要望を聞いたら、四つの欄で整理してみる

    事業部との会議では、すぐに要件定義書を作ろうとせず、まず「翻訳メモ」を残します。書くのは、事業部の言葉、業務上の意味、AIで支援する行為、確認すべき制約の四つです。

    例えば、次のように整理できます。

    「問い合わせを減らしたい」場合

    • 業務上の意味:回答待ち時間と対応工数が負担になっている。

    • AIで支援する行為:社内文書を参照し、一次回答案を出す。

    • 確認すべき制約:出典、権限、最終確認。

    「契約確認を早くしたい」場合

    • 業務上の意味:営業案件が法務確認で止まっている。

    • AIで支援する行為:条項の差分と注意点を提示する。

    • 確認すべき制約:法的判断は人が行う。

    「品質報告を読みたい」場合

    • 業務上の意味:不具合の原因を把握するのに時間がかかっている。

    • AIで支援する行為:報告書を分類し、類似事例を示す。

    • 確認すべき制約:用語の表記ゆれ、過去の分類の信頼性。

    画像

    このメモがあれば、事業部は、自分たちの要望が業務の課題として理解されたかを確かめられます。情シスには技術要件へ進むための手掛かりが残り、経営・企画部門も、何を検証するテーマなのかを把握できます。

    話がかみ合わないときは、業務の場面に戻る

    話がかみ合わないまま進む会議には、次のような兆候があります。

    一つ目は、最初からツール選定の話になることです。どの生成AIやベンダーを選ぶか、社内環境で使えるかは必要な確認ですが、それが先に来ると、業務の目的がぼやけます。

    二つ目は、事業部の要望をそのまま要件にすることです。「AIで自動化したい」という要望でも、実際には、自動化より判断の支援が向いている場合があります。

    三つ目は、誰が業務変更を引き受けるかを決めていないことです。AIを導入しても、現場の手順が変わらなければ使われません。

    こうした兆候があれば、いったん具体的な業務の場面に戻します。

    「このAIは、誰のどの作業の前後に入りますか」

    抽象的なAIの話から、実際に使う場面へと議論を戻すための質問です。

    画像

    会議後には、ユースケースの仮説メモを残す

    初回の会議が終わったら、議事録に加えて、AIをどう使う想定なのかをメモにまとめます。次の検討につなげるための「ユースケースの仮説メモ」です。

    • 対象業務

    • 利用者

    • 利用場面

    • 入力情報

    • AIの出力

    • 人による確認

    • 成果指標

    • 未確認事項

    まだ空欄があっても構いません。その空欄が、次回のヒアリングで確かめる質問になります。

    メモを作ることで、情シス・DX部門は、事業部の話を聞くだけでなく、次に進める形に整理する役割を担えます。AI活用の初期段階では、完璧な要件定義より、関係者が同じ業務の姿を思い描ける仮説メモのほうが役立ちます。

    会議を重ねても共通の理解が残らなければ、事業部との協働は進みません。会議のたびに、誰がどう使うかを具体的にしていくことが大切です。

    事業部の言葉を、業務を変える一歩につなげる

    事業部へのヒアリングからユースケース候補を作り、データ・業務・効果・リスクの観点で整理します。AIツールの知識に加えて、事業部の言葉を、業務シナリオ、データ要件、効果指標、本導入の判断材料へとつなげる力を養うためです。

    技術の話に偏ってきたら、例えば次のように伝えると、業務の話に戻しやすくなります。

    「技術的にできるかを確認する前に、この業務のどの判断をAIで支援したいのかを一緒に整理させてください」

    事業部の要望を否定せずに、情シス側が確認したいことも自然に話し合えます。

    事業部と一緒にAI活用を進めるには、AIの説明だけでなく、現場の困りごとを、実際に試せる業務の形にすることが必要です。情シスがツールを導入し、事業部が業務の進め方を変える。その役割を共有できたとき、PoCは本導入へと近づくのです。

    参考情報

    AIの活用を、テーマ選びから実践へ

    自社のどの業務にAIを活かすか。選んだテーマをどう実現し、現場で使い続けられるようにするか。

    AILでは、人材育成、実践知の蓄積・活用、導入に向けたコンサルティング、プロダクトの提供を通じて、企業のAI活用を支援しています。自社の課題に合った支援を、サービス紹介ページでご覧いただけます。

    AILのサービス・プロダクトについてはこちら →

    AI Librariumについて

    本記事は、AI Librarium(アイブリウム)株式会社が発信しています。

    AILは、専門家の知見や判断基準を、実務で使えるAI Skillとして届け、研修やコンサルティングを通じて企業の業務変革を支援します。その実践で得られた成果や課題を、AI Skillの改善と人材育成に活かし、次の変革につなげていくことを目指しています。

    AI Librarium公式サイト →

     
     
    Lead Always. あたりまえがかわる、このときに。 AI Librarium株式会社の公式noteです。 AIのこと、仕事のこと、取り組みや事例、メンバーの声などを発信していきます。

    あなたへのおすすめ