現場の知見を、仕組みに変える

この記事でわかること

• Fluxell が「現場の知見」を重視している理由
• AI・データ活用で業務理解が欠かせない理由
• Sansan・キーエンスで得た、顧客理解とデータ活用の学び
• 現場の暗黙知を AI やプロダクトに変えるときの進め方
• Fluxell が共に価値を作りたいと考えている企業像

対象読者

自社の業務や顧客理解に強みを持つ経営層、事業責任者、部門責任者を想定しています。

特に「社内に知見はあるが属人化している」「AI やデータで価値化したいが、どう形にすればよいか分からない」と感じている方に向けて書きます。

なぜこのテーマを書くのか

AI 活用の話では、どうしてもモデル、ツール、自動化手法に目が向きやすいと感じます。新しいモデルが出るたび、新しい自動化ツールが出るたびに、それを試すこと自体が目的化してしまうこともあります。

ただ、実務で価値を生むのは技術単体ではないと、これまでの現場では繰り返し感じてきました。

• 採用担当者が候補者を見るときの観点
• 営業担当者が顧客の温度感を判断する感覚
• データ分析担当者が「これは現場で使われない」と感じる勘所
• メディア担当者が読者に届けるために調整している表現
• 熟練担当者が、資料には残っていない例外対応を判断する経験

こうした知見は、業務の中にたくさん埋まっています。マニュアルにも、システム要件にも書かれないまま、人に閉じています。

Fluxell がやりたいのは、こうした知見を AI で 雑に置き換えること ではありません。人の知見を尊重しながら、AI やデータで扱える形に変えること が、長く価値を出していくうえで大切だと考えています。

「AI 導入の前に考えたいこと」 では Fluxell の支援姿勢を全体像として整理しましたが、ここではその中でも「人の知見をどう扱うか」という観点を、もう少し深く書いてみます。

これまで現場で感じてきた課題

Sansan で見えたもの

Sansan のインサイドセールスでは、顧客の発言だけでなく、その裏にある業務背景や意思決定構造を読み取る必要がありました。同じ「情報共有がうまくいかない」という言葉でも、職種や役職、過去の経験によって意味が変わります。

その後 UX リサーチや定量分析にも関わりましたが、そこでは ログ分析だけでも、インタビューだけでも不十分だ ということを身をもって感じました。

• 行動データで傾向を見る
• インタビューで背景を掘る
• アンケートで仮説を広げる
• プロトタイプで検証する

これらを組み合わせて初めて、ようやくユーザーが本当に困っていることに近づける感覚がありました。知見は、人の話と行動とデータの間に存在している と思うようになったのは、この時期です。

Eight Team では、優秀メンバーの行動分析や、新卒メンバーのオンボーディングにも関わりました。属人化していた営業の勘所を、ダッシュボード、提案資料、育成プロセスに少しずつ落としていく仕事です。これは「現場の知見を仕組みに変える」という今のテーマの原点になっています。

キーエンスで見えたもの

キーエンスでは、約 50 社のデータ活用支援に関わりました。製造、小売、建設、エンタメ、サービス業など、業界が変わると、見るべきデータも、現場の判断基準も、意思決定の流れも変わります。

ただし、共通していたのは、データ活用が進まない理由が「分析スキル不足」だけではなかった ということでした。

• 目的が曖昧で、データを集めるところで止まっている
• データの意味が現場で揃っていない (同じ「売上」でも部署で定義が違う)
• 分析結果を誰がどう使うかが決まっていない
• 現場のやる気や納得感が置いていかれている

ここで気づいたのは、データ活用は分析の問題というより、知見と業務をつなぐ問題 だということでした。データを見る前に、誰が何を判断しているのかを知る必要があります。

独立後に見えたもの

独立後の事例も、視点としては地続きです。

YORISAI では、採用業務の書類選考や候補者対応の負荷を下げるだけでなく、採用担当者がどの情報を見て判断しているか を整理する必要がありました。経験豊富な担当者が「この経歴は通したい」と判断する根拠は、職務経歴書の一行に表れていることもあれば、何回かの面接を通して見えてくることもあります。それを AI に渡す形に変えていく作業は、結局は 知見の言語化と構造化 の作業でした。

Racing Oracle では、モデルを作るだけでなく、データ収集・加工・予測・表示・継続運用までを一気通貫で考える必要がありました。レース予想の知見は、データだけでも、人の勘だけでも完結しません。両方を扱える形に整えることで、毎日コンテンツが配信されるサービスに落とし込めました。

これらの事例に共通しているのは、AI で何かを作るとき、現場の知見が出発点であり、終着点でもある ということです。

Fluxell として大切にしている考え方

ここからは、知見を扱うときに意識している軸を 4 つ整理します。

1. 知見を尊重する

AI で人の仕事を単純に置き換えるのではなく、人が積み上げてきた判断を理解することから始めます。

AI に任せる領域を決めるためにも、まずは人が何を見て、どう判断しているのかを理解する必要があります。これは「人の仕事を減らす」と「人の価値を軽く見る」が違うという話でもあります。AI を入れる目的は、人の判断を奪うことではなく、人がより本質的な判断に集中できる時間を増やすことだと考えています。

2. 暗黙知を構造に変える

現場の知見は、そのままだと AI では扱いにくいので、いくつかの観点で分解します。

• どんな入力を見ているか
• どんな条件で判断しているか
• 例外はどこにあるか
• 最終的な出力は何か
• 判断に迷うケースは何か

ヒアリングで聞くべき項目は、ここから逆算します。「優秀な人と新人の違いはどこに出ますか」「判断に迷ったときは何を確認しますか」「うまくいかなかったケースを 1 つ教えてください」といった問いです。

Sansan の UX リサーチ、キーエンスのテーマ設定、独立後の AI 実装で繰り返しやってきた作業ですが、形こそ違えど中身はずっと同じです。

3. 使う人の導線に落とす

知見を構造化しても、業務で使われなければ意味がありません。だから、構造化と並行して、それを誰が、いつ、どこで使うか を考えます。

• Slack
• LINE / WhatsApp
• Google Sheets / Notion
• 管理画面
• レポート
• 社内資料

これらは「ツール選定」ではなく、業務の中での自然な接点として考えます。読者の方が業務の中で開いているものに、AI の出力が流れ込む形が一番自然です。

4. 改善できる形で残す

AI は一度作って終わりではありません。現場の反応を見て、

• プロンプトを直す
• 参照データを足す・差し替える
• 出力形式を変える
• 通知タイミングを変える
• 人の確認ポイントを調整する

といった改善が必要になります。これを前提にすると、初期実装も「完璧を目指す」より「直しやすく作る」方向に自然と寄ります。

実務でどう反映しているか

考え方だけだと抽象的なので、進め方にも触れておきます。

初回ヒアリング

最初の打ち合わせでは、「今どんな知見が属人化していますか」を起点に話を聞いていきます。具体的にはこんな問いを使うことが多いです。

• その業務で、経験者と新人の差はどこに出ますか
• 判断に迷うケースは何ですか
• どの資料やデータを見て判断していますか
• うまくいっている人は何をしていますか
• 逆に、よくあるミスは何ですか

これは要件定義というより、業務の中にある知識の地形を描くフェーズだと考えています。

整理フェーズ

ヒアリングした内容を、AI やデータで扱える形に分解します。

• 入力 (どこからの情報か)
• 判断基準 (何を、どんなルールで見ているか)
• 出力 (最終的に何を返すか)
• 例外 (ルールから外れるケース)
• 人が確認すべきポイント (AI に任せず必ず人が見る部分)
• 改善に使うログ (運用しながら直すための情報)

この整理ができれば、それを実装に落とすこと自体は、技術的にはそこまで難しくありません。

PoC フェーズ

PoC は完全自動化ではなく、人の判断を補助する方向から始めます。

• 候補者情報を要約する
• 問い合わせを分類する
• レポートのたたき台を作る
• 予測結果を説明文に変える
• 営業メモから次のアクションを整理する

人の判断は残したまま、その判断にかかる時間を短くする、というイメージです。ここから始めると、現場の納得感も得やすく、改善のサイクルも回しやすくなります。

実装・運用フェーズ

知見が仕組みに変わったあとは、現場で本当に使われているかを見ます。使われていないなら、どこに原因があるかを切り分けます。

• 導線が悪いのか
• 出力が長すぎるのか
• 信頼されていないのか
• 確認の手間が大きいのか
• 誰の業務にも組み込まれていないのか

原因によって打ち手が違うので、見方を変えながら一つずつ確認します。ここは AI を業務に根付かせるために で詳しく書いていますので、運用定着の話に興味がある方は併せてご覧ください。

どんな人・企業と相性がよいか

相性がよいと感じるケース

• 熟練者の知見が属人化している企業
• 営業、採用、CS、バックオフィスなど判断業務が多い企業
• データはあるが、活用のテーマ設定に悩んでいる企業
• AI を使って、既存業務を少しずつ改善したい企業
• 自社の業務を理解してくれる外部パートナーを探している企業

合わないかもしれないケース

• 現場の知見を聞かずに、AI だけで置き換えたい場合
• 業務フローを変えるつもりがない場合
• 現場への説明や運用定着を軽く見ている場合
• とにかく自動化率だけを追いたい場合

知見の構造化は、関係者の協力なしには進まない仕事です。だからこそ、合うかどうかを最初にすり合わせることが、お互いにとって価値のあるスタートになると考えています。

今後どのような価値を提供したいか

Fluxell では、社内や業界に眠っている知見を AI・データ・プロダクトで扱える形にしていきたいと考えています。

特に、中小企業や専門性の高い業界では、現場の知見が強い一方で、それを仕組みにする人が不足していることが多いと感じています。「現場に強い人はいるが、AI や仕組みに変える人がいない」という空白を、Fluxell が埋めていけたらと考えています。

業務を聞き、構造化し、小さく実装し、運用まで見る。地味な作業ですが、ここを丁寧にやることが、結果として一番大きな価値につながると感じています。

まとめ

• 現場の知見は、AI に置き換える対象ではなく、AI で活かすべき資産です
• 大切なのは、知見を聞き取り、構造化し、業務に組み込む形にすること
• そのために、人の判断を尊重しながら、扱える形に変えていきます
• Fluxell は、その作業を一緒に進めるパートナーになりたいと考えています

後続の Insights では、RAG・AI チャットボット・データ分析・業務自動化など、具体的なテーマも、この「知見を扱う」という視点から整理していきます。

ご相談について

自社の業務知見を AI やデータで活かしたい方は、お問い合わせ よりご連絡ください。

「この業務は属人化している気がする」「AI で何かできそうだが、どこから整理すればよいか分からない」といった段階から、ご一緒に考えられます。