データ整備はなぜ失敗するのか。登る山を間違えないための、AI推進”次の一手”

2026年8月5日に開催された「AI推進カンファレンス ~AIを組織の推進力・競争力に変える~」(主催:サイボウズ株式会社)。全社展開に向けた実践事例が並んだ一日の最後を飾ったのが、クロージング特別講演「現場・部門・IT、それぞれの突破口が語る―AI推進、次の一手」だ。本稿ではそのセッションの模様をレポートする。


SPEAKER
中野 仁(一般社団法人エンタープライズIT協会 代表理事/株式会社AnityA 代表取締役)

MODERATOR
鈴木 秀一(サイボウズ株式会社 執行役員 情報システム本部 本部長)

EVENT
マイナビ TECH+ 主催「AI推進カンファレンス」

生成AIの活用が経営アジェンダとなるなか、その成否を分けるのは「データ整備」だ——ここまでは多くの企業が共通認識として持っている。しかし現実には、データ整備がうまくいく企業と、大規模プロジェクトを立ち上げながら頓挫する企業に分かれていく。その分岐点はどこにあるのか。本セッションでは、サイボウズ執行役員 情報システム本部長の鈴木秀一氏をモデレーターに、エンタープライズIT協会 代表理事でAnityA代表取締役の中野仁が、「なぜデータ整備は失敗するのか」を起点にAI推進の次の一手を掘り下げた。

本カンファレンスのクロージング特別講演として実施されたセッション。
講演者:中野仁(エンタープライズIT協会 代表理事/AnityA 代表取締役)、
モデレーター:鈴木秀一氏(サイボウズ 執行役員 情報システム本部 本部長)
左:サイボウズ株式会社 執行役員 情報システム本部 本部長 鈴木秀一氏/
右:一般社団法人エンタープライズIT協会 代表理事・株式会社AnityA 代表取締役 中野仁
目次

AIは情報系の一部。データは全システムに「根を張っている」

セッション冒頭、鈴木氏はサイボウズのエンタープライズアーキテクチャ全体図を示しながら、AIとデータ整備の位置関係を整理した。

サイボウズのエンタープライズアーキテクチャ。開発系・基幹系・基盤系・情報系の4層で構成され、
AI(対話型/RAG・AIエージェント)は情報系システムの一部として位置づけられている

鈴木:こちらが弊社のエンタープライズアーキテクチャです。AIは情報系システムの一部だと捉えています。だからこそAIにとって必要なのは、その手前にある基幹系や基盤系——つまりデータとプロセスです。まず、データ整備をどう進めるべきか、失敗する企業はどこに問題があるのか、というところからお聞かせください。

中野:AIとデータは表裏一体で、AIを活用しようとすると結局は必ずデータの話に行き着きます。ただ、この図を見ていただくとわかるように、データはあらゆるシステムに「根を張っている」んです。だから、データだけを取り上げて議論することが非常に難しい。

すでに出ている情報をちょっとしたレポートに出す程度ならすぐできますが、そこには限界があります。本当に必要な情報を出そうとすると、プロセスが絡む基幹系システム——データの発生源から直していく必要がある。つまり、根っこの基幹系、真ん中のデータ基盤、最終的に見せる情報系という三層にまたがる話になり、どうしても複雑になる。これがデータ整備の特徴です。

「構想3年、実行5年」——大上段のデータプロジェクトが頓挫する構造

鈴木:その複雑さのなかで、うまくいくケースと悪い方向に行ってしまうケース、それぞれどんなパターンがありますか。

中野:一番よくあるのが、データ整備の大きなプロジェクトを大上段で始めてしまうケースです。「全社データ横断統合基盤」のような物々しい名前のプロジェクトが走り、構想3年・実行5年——ハリウッドもびっくりの大作になる。構想している間にビジネスの状況が変わって頓挫するか、始めたものの結果が出るまでに時間がかかりすぎて、人とお金を消費し続けた末に耐えきれなくなり、プロジェクト半ばで挫折する。データ整備は重要ですが、そこだけを先行させると頓挫する確率が高まります。

鈴木:データ整備というとクレンジング含めて相当な人数がかかるイメージです。では逆に、整備だけを主眼に置かずにうまく進めるには?

中野:失敗パターンにはもう一つ逆側があって、短期的な成果が見えやすい「活用」側にフォーカスしすぎるケースです。その結果、賢くなったように見えるチャットボットをリリースして、一応の成果は見えるけれど「なんか違う」となる。

結局は、整備と活用をバランスよくやるしかない。「それができたら苦労しない」という話ではあるんですが(笑)。基本は、目に見えて成果が出た・何かが変わったと示しつつ、そこからさらに整備を進めることで1年後・2年後にこうなる、というロードマップを引きながら、短期的な成果を出し続ける。魔法や銀の弾丸が存在しないことが、この領域の一番難しいところです。

しかも基盤の話を進めれば、必ず基幹系——プロセス系のシステムが絡んできます。そこからが本当の本番で、現場の業務のなかに取り入れてもらう戦いになる。その手前の、データ整備と活用の最初の一歩でつまずいてしまっている会社さんが、実はすごく多いように見えます。

魔法や銀の弾丸は存在しない。短期の成果を見せ続けながら、1年先・2年先のロードマップを引く。その両立しかない。

中野 仁(エンタープライズIT協会 代表理事/AnityA 代表取締役)

登りやすい山は遭難する。経営と会話してからルートを決める

鈴木:こういう話はどうしても大きくなりがちで、期待も膨らんでいきます。期待値コントロールのコツはありますか。

中野:「大きな期待、小さな予算」は非常によくあるケースです。定石としては、予算と権限の決定権を持っている人の課題を最初に取りに行く。具体的には経営、あるいはビジネス側なら会社の主力事業など、ビジネス上のインパクトが出る領域に集中していくことです。

逆に、コーポレートや間接系は、必要だしやらなければいけないのはわかるんですが、会社全体で見ると登山道を間違えて遭難しやすい。解決しやすいところから叩くのは戦術上間違いではないけれど、そこを叩いても決裁者や会社へのインパクトには響かない——よくある話です。

鈴木:攻めるならフロントオフィス系から、ということでしょうか。この図で言えばマーケ、営業支援、サポートあたり。ただ、そこの業務フローを変えて使えるデータを整えるのは「それができたら苦労しない」領域ですよね。

中野:そうなんです。しかもマーケにはマーケで、DX推進やデータ推進といった別部門が既にあって縄張りが違う、慣習も違うから入りづらい、という組織的な壁もあります。IT部門はバックオフィス側に置かれているケースが多いので、バックオフィスのほうが入りやすくはある。ただ、入りやすいからといって、経営の課題感がそこにない状態で人事や会計を掘っても、なかなか厳しい。フロントオフィスとは予算規模が下手をすればゼロ一つ違いますから。

だから一番いいのは、経営が何を考えているのかを直接取りに行くことです。IT部門の方と話していると、意外と経営と話をしていないケースが多いんですよ。データから価値を生むことに興味のある経営に会いに行き、どの状態が会社にとって重要度の高いポイントなのかを見極めてから、山の登り方を考える。

これは一概に「フロントから行けばいい」という話でもなくて、会社によっては実は管理会計まわりがものすごく重要だというケースもよくあります。要は、ピンを打つ位置を間違えるか、登り方を間違えて滑落するか遭難するか——失敗はだいたいこのどちらかです。

鈴木:耳に覚えのある方も多そうです(笑)。登りやすい登山口から登った結果、誰も見向きもしない頂上に着いてしまう。

中野:そうです。経営からすると「いっぱいお金を使って人を大量投入しているけど、何してるの?」と言われてしょんぼりする。あるいは、ものすごく高い富士山を「人数がいれば登れるはず」とみんなで登り始めて、5合目にたどり着く前に樹海で全員行方不明になる(笑)。

To-Beを描くのは重要ですが、To-Beとはいわば山の頂上です。頂上を設定しないまま、登りやすいところから登る、あるいはベンダーさんが持ってきた夢てんこ盛りのソリューションの「できること」から始めてしまう。すると迷走しがちです。How先行になりすぎて、「これは何を実現するためのHowだっけ?」という問いを常にセットで追い続けないと迷子になる。迷子になった分だけお金を消費して成果は出ないので、部門評価が厳しくなり、経営から「なんで成果が出ないの」と詰められて頓挫する。データ戦略・データ基盤の整備と活用は、この構図に非常に陥りやすい領域だと思います。

鈴木:トップ、つまり興味のある人と会話すること。To-Beのあるべき姿を描くこと。そこを描かずに進むと迷子になり、中野さんの言葉で言えば滑落・遭難してしまう。これを押さえに行くのは、やはりマネージャー——部長級以上の仕事になりますか。

中野:経営の戦略を現場の戦術に落とし込むのはラインマネージャーの役割で、会社によりますが概ね部長級の仕事だと思います。ただ、注意すべきは、直上のラインマネージャーが一番データに興味があり、やりたいTo-Beを持っているとは限らないことです。自分の直上の管掌役員以外とも会話して、一番感度が高い人と話す。マネージャーの仕事はよく「ルーティング」だと言われますが、下に向けてだけでなく、上に向けてもサイロは起きます。このテーマに関して適切なキーマンは誰なのか、その見極めが重要です。

「データ整備の話なのに、データ関係ないじゃん」というところから始まるんですが(笑)、このボタンの掛け違いが、データが関係する大きなプロジェクトの成否を分ける。失敗すれば相当な金額の損失と時間に加えて、嫌になった重要な人材が流出するという二次災害まで起きます。企画とは綺麗なパワーポイントを書くことではなく、それが実行と一体になっているか、というところまで落とし込む必要がある。ここは外部のコンサルタントには難しい。社内の意思で踏み込む、その踏み込みが甘いと今度は梯子が外れる——これもまた滑落ポイントです。

「登りやすい山は遭難する」——登る山(To-Be)とルート(キーマン・順序)の設定を誤ることが、データプロジェクト失敗の典型パターンだと語る両氏

サイボウズの実践——数字ではなく「経緯と文脈」を貯める

後半は、サイボウズ社内で進むkintoneを活用したAIデータ活用の実例を鈴木氏が紹介し、中野が切り込む形で進行した。

鈴木:サイボウズではいま、kintoneを使ったAIのデータ活用を検証し始めていて、そこでわかってきたことがあります。従来BIで使っていたのは、営業目標の達成率、売上、地域別実績といった数字的なデータでした。しかし弊社は全ての業務システムが上から下までkintoneでつながっているので、数字以外のものも蓄積されています。

たとえば営業のフェーズ管理なら、どの顧客からどんな問い合わせがあったかだけでなく、次のフェーズに進むまでにどれぐらい悩んだか。提案なら、金額や割引率という数字だけでなく、なぜその割引率でよかったのか、なぜ今回受注できたのか。交渉なら、誰の承認で、どんな話し合いがあったのか。BIの時代は数字だけでよかったんですが、AIに関しては「経緯」や「文脈」——いつ、何が起きて、誰が関わり、どんな判断をしたのか——という情報が大事だとわかってきました。これを含めてAIにデータを使わせることで、良いことが起きるのではないかと考えています。

SFAの6フェーズごとにkintoneアプリへ蓄積されるコンテキスト。従来の「数字・集計のためのデータ」に対し、
AIが本当に必要とするのは「経緯」と「文脈」の情報——いつ・何が起きて・誰が関わり・どんな判断をしたか

中野:おっしゃる通り、AIによって対象になる情報が変わりましたね。極端な話、商談中に話された内容——議事録や録音のような生データまで商談データに紐付いて入っていれば、引き継ぎも含めて相当なことができるはずです。定性情報の価値が大きく変わってきている。

これまで非構造化データは「使いにくいもの」でしたが、そこも変わりました。定性情報を構造化する、クレンジングする——人間がやると大変な作業を、AI自身にある程度担わせて回してしまえば、データとして抽出できる。この変化はかなり大きいと思います。

鈴木:まさに弊社でやっているのもその点で、生のデータのまま渡してもAIには意味がわかりづらい。行動に対するコンテキストなのか、判断に対するコンテキストなのか、関係性に関するコンテキストなのか、分けてあげる必要があります。これをやっていくと、皆さんAIを使っていて感じる「賢いけど、うちのことは知らないよな」という部分が変わってきます。

中野:業界知識もドメイン知識も全くない、新卒の外資系コンサルみたいな状態ですよね。「賢いんだけどさ」という(笑)。

鈴木:賢いですし、アウトプットの見た目の質も高い。情報自体が構造化されているので、ちょっと賢く「見える」んですよね(笑)。

業務のなかで自然と蓄積されたコンテキストが、生成AIの「種」になる。kintoneに集まる判断・経緯・意図・会話を生成AIが処理し、
文脈を理解した判断支援へ——従来のデータ基盤とは異なる”質”の情報がAIの判断精度を高める

人格を模すAIか、判断材料を揃える秘書AIか——活用の「二刀流」

鈴木:いま実験中の取り組みとして、弊社kintone上の全公開情報をAIに処理させることをやっています。「鈴木さんってどんな人ですか」と聞くと、最近のGaroonのスケジュールやkintone上の活動を見て「最近こんなことをやっている人です」と返ってくる。目指す先は、「この状況でどう判断すべきか」に対して良いサジェストをくれる状態です。

その先で考えているのが2パターンあって、一つは皆さんが作りたがる「CIO AI」「CEO AI」——この人に聞けば中野さんと同じようなフィードバックをくれる、という人格を模すパターン。もう一つは、この状況になった途端に判断に必要な材料を全部揃えてくれるパターン。人の人格を模していく使い方と、人の支援に超特化させる使い方、中野さんはどちらがより成功パターンに近いと思いますか。

中野:抽象度で分かれると思います。具体的で抽象度が低いもの——何をするのかも判断基準もわかっているものは、人格に処理させたほうがいい。ルールベースで処理されるべきものですし、人が介在する理由もあまりないので、極力省力化して、はまらないものだけ例外としてピックアップさせればいい。

一方で抽象度が高ければ高いほど、必要な判断情報をきちんと揃えてくる「秘書」のような形が必要になります。「何をしたいのか」「どこに落としたいのか」が先にあって、ぱくっと投げられないような抽象度の高い問いにこそ、判断材料を揃えるAIが効く。それぞれ目的と用途を間違えなければ、どちらも必要なものだと思いますね。

鈴木:この二刀流で活用していくことが大事な点になりそうですね。

まとめ——To-Beから逃げない

鈴木:本日は、データ整備そのものを主眼に置くのではなくTo-Beのあるべき姿を描いた上で目標に向かって進むことの大事さ、そしてデータ活用では従来のデータの持ち方ではなく文脈・コンテキストを理解させた上でAIに入れていくことをお話しいただきました。ここでもやはり、何をAIに出させたいのかというTo-Beが大事になる、と。

中野:繰り返しになりますが、いろんな会社さんを支援していて、皆さんが一番難しく、そして避けて通ろうとするのがTo-Beなんです。最初から明確にわかっているなら苦労はない。ふわっとしているからこそ、繰り返し議論しなければいけない。

To-Beが決まっていないと、判断の基準が決まらない。判断基準が決まらないと優先順位も決まらず、どこまでリソースを投入するかも決まらない。To-Beのイメージがない、あっても共有されていない状態では、すべてが難しくなります。そこをごまかさず、しつこくやり続けること。これがポイントだと思います。

鈴木:目的を間違えず、登る山をしっかりと登っていく。それが本セッションの結論です。中野さん、本日はありがとうございました。

中野:ありがとうございました。


KEY TAKEAWAYS

  1. データ整備だけを大上段で始めない。「構想3年・実行5年」型のプロジェクトは、環境変化と成果の遅れで頓挫する確率が高い。整備と活用のバランスを取り、短期成果とロードマップを両輪で回す。
  2. 登る山(To-Be)を決めてからルートを引く。登りやすい領域から入ると「誰も見向きもしない頂上」に着く。予算と権限を持つ経営の課題を最初に取りに行き、感度の高いキーマンを見極める。
  3. AIに渡すべきは数字ではなく「経緯と文脈」。いつ・何が起きて・誰が関わり・どんな判断をしたか。業務プロセスの副産物として自然に蓄積される仕組みが、AIの判断精度を左右する。
  4. AI活用は「人格模倣型」と「秘書型」の二刀流。抽象度の低い定型判断はルールベースで人格に処理させ、抽象度の高い問いには判断材料を揃える秘書型を当てる。

PROFILE

中野 仁(なかの・ひさし)
一般社団法人エンタープライズIT協会 代表理事/株式会社AnityA(アニティア) 代表取締役
国内・外資ベンダーのエンジニアを経て事業会社の情報システム部門へ転職。メーカー、Webサービス企業でシステム部門の立ち上げやシステム刷新に関わる。2015年から海外を含む基幹システムを刷新する「5並列プロジェクト」を率い、1年半でシステム基盤をシンプルに構築し直すプロジェクトを敢行。2018年にITコンサル会社AnityAを立ち上げ、代表取締役としてシステム企画・導入についてのコンサルティングを中心に活動している。システムに限らない企業の本質的な変化を実現することが信条。Xは@Jin_AnityA

鈴木 秀一(すずき・ひでかず)
サイボウズ株式会社 執行役員 情報システム本部長
サイボウズへ新卒入社後、リモートサービス、サイボウズLive、cybozu.comのインフラ運用をはじめ、本社移転や社内システム基盤の刷新など、幅広いITインフラ領域を担当。2024年に情報システム本部長に就任し、現在は日本およびグローバル拠点の情報システムを統括する執行役員 情報システム本部長(CIO)を務める。

  • URLをコピーしました!
目次