業種が違えどAI活用は同じ理由で止まっていた

「AIでこれやってよ」というアイデアが現場から出てくる。
経営がAI活用を強く求めていて、AI推進チームや計画書が用意されている。

けれどそこから先の、「実現」はできていない。
実現したものの、結果「どんな成果」をもたらしたのかは分かっていない。

このような状況に共感できる方もいらっしゃるのではないでしょうか？

私は直近、人材サービス会社、物流会社、大手小売・流通会社、産業機器メーカーと、業種の異なる4社でAI活用について話を聞きました。
すると、各社の事情は違うものの、共通する問題が見えてきました。

業種の違う4社のAI活用で何が起きていたか

CASE1：人材サービス会社「現場の要望に応えても、大きな成果につながらない」

1社目は、人材サービスを提供する会社です。

こちらの会社では、現場から「AIでこれをやりたい」というアイデアが次々に上がり、それに対して3名のAI推進チームが対応していました。
すでにアイデアをもとに実現した内容もあり、一見AI活用が進んでいるように思えます。

しかし、担当役員は、現場から出てくるアイデアに対応するという進め方に問題を感じていました。

現場から上がる「AIでこれをやりたい」という要望に、そのまま素直に応えてしまっている。要望をそのまま実現してしまうと、大きな事業インパクトにつながらない。
―担当役員の言葉

こちらの会社では、「事業に大きなインパクトを与えるAI活用の進め方がわからない。」という問題を抱えていました。

要望に応えて何かを作ることと、事業の成果を出すことは全く別ものです。

その業務のどこに問題があり、何が改善すれば成果といえるのか。
そういったことを決めずにただ作り続けても、個別の便利な道具が増えるだけで終わる可能性があります。

CASE2：物流会社「経営トップの号令を、現場の仕事に落とし込めない」

2社目は、物流会社です。

こちらの会社では、経営チームが、トップダウンでAI活用を強く求めていました。
一部の業務を効率化するようなAI活用ではなく、AIを前提に仕事のやり方そのものを作り変えるような活用がしたいと求めていました。

そして、その実現のために、AI推進チームを、各部門から募ってタスクフォームチームを作り編成していました。
所属するメンバーは、所属部門の仕事をこなしながら、AI推進チームの役割を兼任で進める形式です。

AI推進チームは作った。しかし、その活動によって何がどこまで変わったのかと聞かれると、明確には答えられない。
―管理部門責任者の言葉

「代表からの号令はあれど、ゴールが示されていないために活用が進まない」という問題を抱えていました。
「AI前提で仕事を作り変える」という掛け声だけでは、担当者は、全社の中で優先的に手をつければよいか、判断しかねていました。

対象とする部門や業務を選び、変えた後の状態と成果を決める。
経営の号令を現場で実行できる仕事に分解する役割が機能不全に陥っていたのです。

CASE3：「ロードマップはあるが、実現されない」

3社目は、全国に店舗を展開する大手小売会社です。

こちらの会社では、既に外部のコンサルティング会社が作ったAI活用のロードマップがあり、AI 戦略、データ活用戦略、そして営業や在庫管理部門における DX 施策が策定されていました。

支援体制も策定されていましたが、実際に動き始めていた施策は一部でした。

社長から AI 活用の構想はどんどん出てくる。コンサルティング会社も、綺麗な計画書を作ってくれる。しかし、これまでの数年を振り返っても、実現に落とし込めた施策は数える程度しかない。
―経営企画責任者の言葉

こちらの会社では、AI 活用によって会社がどう変わるか、その理想像は描いていました。また、経営チームで構想も持ち、実行したい施策も策定していました。

しかしいざ実行しようとすると、技術制約上の限界や既存システムとの兼ね合いによる制約によって、後になって実現性が低いことがわかったり、現場に浸透するものにならなかったりと、プロジェクトが繰り返し頓挫してきたのです。

経営が掲げる「戦略」と、「実行」の間を、プロジェクトゴールと実現性を鑑みて、推進判断する人が存在していなかったのです。

CASE4：産業機器メーカー「Excel 抽出をワンクリックでできるようにしたい」

4社目は、産業機器を扱うメーカーです。

こちらの会社では、調達・出荷関連業務の AI化を進めようとしていました。
そしてそのために実現しようとしていたことは、注文書や見積書、請求書が入っている基幹システムから、担当者が画面を操作し Excel に書き出す業務を、「Excel 抽出をワンクリックでできるようにする」ことでした。

抽出の手間が減る。それは確かに改善です。

ただ、現場の作業を最後までしっかり観察をさせてもらったところ、本当に負担がかかっているのは、抽出の先の運用プロセスに見えます。

抽出が速くなったとしても、担当者の手元には多くの仕事が残っています。
Excel の並べ替え、整形、印刷。
さらに、取引先ごとの依頼は大変な作業です。
その後、返ってきた書類を確認して、紙に消し込む作業もあるようでした。

そして担当者の業務を観察させてもらい、本当に負担がかかっている業務と、その解決方法について対話を重ねていくうちに、「基幹システムのトップ画面に「証明書の作成依頼」というボタンを1つ置き、Excel 抽出から送信、消し込みまで、担当者が順番に操作している部分を、まとめて済ませられる。」ことが分かりました。

今行っている作業を前提に、便利にしていくことには価値があります。
「Excelの抽出を速くしたい」という要望を受ければ、抽出を速くする方法は考えられます。
しかし、実際に業務を観察すると、本当の課題はそこではないことがあります。

共通するのは「要件」の前の「要求定義不足」

4社とも、AI 活用による構想は持っていました。

しかし、その要望はどんな問題から生まれたのか。
誰のどの仕事を変え、何が改善すれば成果といえるのか、といった検討が十分にできていませんでした。

これは、要望の後の、要求定義が十分になされていなかったということです。

• 要望：何をしたいか。 現場や経営が望んでいること。

• 要求：解決すべき課題を踏まえ、誰のどの仕事を、どのような状態に変えるか。

• 要件：その状態を実現するために、何が必要か。 システム・データ・運用の条件。

要望を聞いたら、すぐに作り方を考えたくなります。
例えば「この書類を自動で作りたい」のように具体的な要望であれば、そのまま実装できそうに思えるでしょう。

ただ、作りたいものが明確なことと、解決すべき課題が明確なことは同じではありません。

本当に負担が大きいのはその作業なのか。
前後の業務まで見たときに、もっと先に解決すべき問題はないか。
現場や経営の要望を受け止めつつ、言葉をそのまま信じるのではなく観察し、本当の問題まで確かめるのが要求の整理です。

この検討が抜けていると、作るものの仕様を詳しく決めても、期待した成果につながらない可能性があります。今回の4社の話から、私は要求定義の重要性を改めて感じました。

要求定義が難しいのは、要望を疑わなければならないから

ここまで読むと、「実装前に要求定義と要件定義をすればよい」と思われるかもしれません。
しかし、特に難しいのは、構想や要望を要求に変えることです。

例えば専門商社の事例で、「品質証明書の目次を自動で作りたい」と言われれば（要望があれば）、目次を作る方法を考えたくなります。

しかし、その事例では、その前に紙の納品書を探し、仕入れ先へ証明書を依頼し、届いたかを確認する仕事があります。
目次の作成だけを自動化しても、担当者の負担はあまり減らないかもしれません。

問うべきなのは、「目次を作る業務をどう自動化するか」ではなく、担当者が、何の成果のために、いつ、何をしていて、一連の業務プロセスのどこに問題があるのかです。
目次作成なのか、納品書探しなのか、証明書の収集や進捗確認なのか。答えによって、取り組むべき内容は変わります。

要求定義とは、要望を詳しい文章にする作業ではありません。
要望の背景にある問題を調べ、誰のどの仕事を、どのような状態に変えるかを決める仕事です。

最初の要望をそのまま採用することはほとんどありません。
要望を出す方に、欲しいものを直接的に聞いてもいけません。
要望を出す方は、自身が求める理想的なものを知らないからです。
ヒアリングや事実の観察から、気づきを得て、落とし込む必要があるものです。

もちろん、要件定義も欠かせません。
必要なデータをどう取得するか、システムをどう動かすか、例外を誰が処理するかを決めなければ実装できないからです。

ただ、要求が曖昧なままでも、間違った方向に向いていたとしても、要件の検討は進められてしまいます。
「目次を生成する機能」の仕様を精緻に作り、その通りに実装することもできるでしょう。
それでも、業務上の問題を解決できるとは限りません。
だからこそ、要件定義の前に、何を解決するのかを決める要求整理が重要なのです。

要求定義と要件定義を、一人で担える人は希少

要求整理と要件定義が必要だと分かっても、それを誰が担うのかという問題が残ります。

事業や業務に詳しければ、システムの実現方法まで判断できるとは限りません。
AIを実装できても、現場の要望のうち、どれを解決すれば事業成果につながるかを判断できるとは限りません。

両方を進めるには、

1. 要望の背景を調べ、解くべき課題を絞る力

2. 現場の事実（Asis）を聞き出し、変更後の業務（Tobe）を設計する力

3. 業務要求を、システム・データ・運用設計に落とす力

4. 効果と制約を踏まえて、関係者の判断をまとめる力

少なくとも4つの力が必要です。

足りない役割を見極めて補う

社内で担えない部分があれば、外部の力を借りる選択肢もあります。
外部に支援を依頼する場合も、まず確認したいのは、どの仕事を社内で担えていないかです。

要望は集まるが、どれに取り組むべきか決められないなら、課題と成果を整理する役割が必要です。
変えたい業務は決まっているが、実現方法が見えないなら、データやシステムを調べ、検証する役割が必要です。

両方に担当者がいても話がつながらないなら、業務上の期待と技術的な制約を整理し、判断を取りまとめる役割が必要です。

私たちDeflagは、これまでコンサルティングやデータ整備、プロダクト開発、AI実装に取り組んできました。
その経験をもとに、現場の課題特定から要求・要件の整理、実装、効果測定まで一貫して伴走できることを強みとしています。

「AIでこれをやりたい」という要望から、どの業務を変え、何を成果とするのかを一緒に整理する要求整理。必要なデータや実現方法を定義し、実装後も業務がどう変わったかを確かめる。

こうした一連の仕事を支援しています。

社内で任せる人が見つからない、何を頼めばよいかも整理できていない。
そんな段階でも、ぜひ一度Deflagにご相談ください。