ROI事件ファイル No.512『先輩に訊けば五分、検索すれば一日』
先輩に訊けば五分、検索すれば一日
第一章：ファイルはあるのに、辿り着けない
「過去の加工実績は、社内のどこかには必ずあるんです。ただ、辿り着けない」
NebulaTech社の技術部門マネージャー、烏丸渉氏は、そう言いながらファイルサーバの階層を開いた。Excelの加工条件表、PowerPointの提案資料、手書きスキャンPDFの工程メモ——形式も保管場所も担当者ごとにバラバラだった。「若手が困ったとき、先輩に訊けば五分で答えが返ってくる。自分で検索すると、一日かけても見つからない」
「現状のRAGチャットシステムは」とClaudeが尋ねた。
「半年前に導入しました」と烏丸氏が答えた。「一問一答は返ってくる。ただ、深掘りができない。『この加工条件と似た過去事例は』と訊いても、関連ファイルを横断的に拾ってこない。要約も浅い。結局、若手は先輩に訊きに行く。先輩の時間が削られる構造は変わらなかった」
「先輩側の負荷は」と私が確認した。
「ベテラン三名に質問が集中しています」と烏丸氏が答えた。「自分の業務が止まる時間が、月平均で六十時間。当然、知識継承の課題も大きい。ベテランの誰かが退職したら、知識ごと消える」
「RAGに必要だったのは、検索精度ではなく、問いの設計でしたね」と私が応じた。「Persona_Analysisで組み直しましょう」
第二章：Persona_Analysisが問う、誰の問いに答えるか
「この案件には、Persona_Analysisが必要です」
Claudeがホワイトボードに「P・A」と書いた。
「Persona_Analysisとは、利用者の属性・行動・課題を架空の人物像として詳細に設計し、その人物の視点でサービス設計を進めるフレームワークです」と私が説明した。「マーケティングでの活用が知られていますが、社内システム設計でも本質的に有効です。なぜなら、社内ツールは『誰が・どんな状況で・何を訊くか』が決まらないと、検索精度を上げても使われないからです。RAGが機能しなかった原因は、ペルソナが曖昧だったことにあります」
「まず現状のコストを測りましょう」とGeminiがROI Polygraphを開いた。烏丸氏から提供されたデータを入力する。
「月間の知識アクセスコストが出ました」とGeminiが読み上げた。「若手十二名の情報探索工数が月平均三百六十時間、時給三千四百円で月百二十二万四千円。ベテラン三名への質問対応工数が月平均百八十時間、時給五千八百円で月百四万四千円。情報が見つからず再作成する重複作業コストが月平均九十万円。過去事例を活用できないことによる提案品質低下の機会損失が月平均七十万円。知識継承リスク期待値が月平均六十万円——ベテラン退職時の影響額と発生確率の積。合計で月四百四十六万八千円。年間換算で約五千三百六十万円」
烏丸氏が数字を見つめた。「RAGを入れて改善したつもりでしたが、コストは消えていなかった」
「では、Persona_Analysisで設計します」と私が続けた。
[ペルソナ第一層——若手エンジニアの典型像を描く]
「最初に、利用者の代表ペルソナを設計します」とClaudeが言った。「『入社二年目の加工技術者・二十五歳・前職なし・専門は機械工学・現在は試作工程を担当・週に三回ほど過去事例を確認したいが先輩を頻繁に呼びにくい状況』。属性だけでなく、行動文脈と心理障壁まで定義します」
[ペルソナ第二層——典型的な問いの構造を分解する]
「次に、ペルソナが発する問いを分解します」とGeminiが続けた。「『過去にこの素材で似た形状を加工した事例はあるか』『失敗事例の原因は何だったか』『この条件で進めて品質は出るか』『ベテランなら次に何を確認するか』。問いの構造を四タイプに分けると、検索精度ではなく、応答設計の問題だと分かります」
[ペルソナ第三層——情報源とのマッピング]
「分類した問いと、社内の情報源を対応づけます」と私が続けた。「加工条件表のExcelは『成功事例の条件参照』に対応。提案資料のPowerPointは『顧客提示のテンプレート参照』。手書きPDFは『失敗事例のメモ・暗黙知』に対応。問いの種類ごとに、どのファイル群を優先的に参照するかが決まる構造です」
[ペルソナ第四層——深掘り対話の設計]
「最後に、深掘り対話の設計です」とClaudeが続けた。「一問一答ではなく、ペルソナの問いに対して『先輩ならこう確認する』という追加質問をシステム側から返す設計にする。『この素材で似た形状はあります。ただし加工速度が異なる事例も含まれます。どちらの条件を優先しますか』のような対話展開で、若手が考えるべき観点が自然と整理される構造を作ります」
[投資回収を試算する]
「ROI Proposal Generatorで試算しましょう」とGeminiが提案した。
- 初期費用：ペルソナ設計・情報源タグ付け・対話エンジン開発・既存RAGとの統合・現場研修費用合計六百四十万円
- 月次費用：対話基盤運用・データ更新継続費合算月二十二万円
- 月次削減効果：若手探索工数削減＝月八十四万円（七割削減想定）、ベテラン対応工数削減＝月七十二万円、重複作業削減＝月六十二万円、提案品質向上＝月四十五万円、知識継承リスク低減＝月四十万円、合計月三百三万円
- 月次純削減：三百三万円－二十二万円＝月二百八十一万円
- 投資回収期間：六百四十万円÷二百八十一万円＝約二・三ヶ月
「二ヶ月強の回収です」とGeminiが整理した。「重要なのは、RAGを置き換えるのではなく、ペルソナ設計を上に重ねる構造であることです。既存投資を活かしながら、応答品質を底上げします」
烏丸氏が数字を確認しながら言った。「RAGの精度をどう上げるかという議論をしていました。ペルソナを設計するという発想がなかった」
「Persona_Analysisは、技術問題を構造問題に置き換える道具です」と私が応じた。
第三章：スモールスタートで進める展開計画
「進め方を整理します」と私がホワイトボードの前に立った。
「第一・二週——若手エンジニア五名へのインタビュー、ペルソナ精緻化。第三週——典型問いの四タイプ分類、情報源マッピング。第四・五週——対話エンジンのプロトタイプ開発、深掘り質問パターン設計。第六・七週——既存RAGとの統合、ファイル群のタグ付け。第八週——技術部内での試験運用、フィードバック収集。第九・十週——応答品質の調整、全社展開準備。第十一週以降——他部署への段階展開、ペルソナの追加設計」
「最初から全社展開しないんですね」と烏丸氏が確認した。
「技術部一部署でのスモールスタートが鉄則です」とClaudeが応じた。「ペルソナ設計は、現場と作りながら精度が上がる性質のものです。最初から全社設計を狙うと、誰のペルソナも刺さらないものになる。技術部で成功事例を作ってから、他部署のペルソナを追加していく」
烏丸氏がメモを取りながら言った。「半年止まっていた議論が、ペルソナ一人を決めるところから動き出すとは思いませんでした」
第四章：先輩を呼ぶ前に、答えが返ってきた日
八ヶ月後、烏丸氏から報告が届いた。
若手の情報探索時間は、Persona_Analysis版システム稼働三ヶ月後に従来比で七十二パーセント減少。「以前は一日かけて見つけていた過去事例が、十分で出てくる。出てくるだけでなく、関連する失敗事例まで一緒に提示される」と烏丸氏は記していた。
ベテランへの質問件数も大幅に減少した。一次的な問い合わせは新システムで完結するようになり、ベテランへの質問は本当に判断が必要な案件のみに絞り込まれた。「ベテラン三名の月平均六十時間の対応工数が、十五時間まで下がった。本人の業務時間が戻ってきた」と報告書にあった。
最も意外な変化は、若手の成長速度に表れた。深掘り対話の設計により、若手が問いを深める習慣がついた。「以前は答えだけ受け取って終わっていた。今は『次に何を確認すべきか』をシステムが投げかけてくる。考える筋肉がついている」と報告書にあった。一年目社員の独立稼働までの期間が、従来の十二ヶ月から八ヶ月に短縮された。
知識継承の構造も変わった。ベテランが日々の業務で残したコメント・補足が、ペルソナの問いに応答する形式でシステムに蓄積されるようになった。「ベテランが書いた文章は属人的な日記だった。ペルソナの問いに対する応答として書くようになってから、組織の資産になった」と烏丸氏は記していた。
技術部での成功を受けて、営業部・調達部のペルソナ設計も第七ヶ月から開始された。「営業ペルソナの問いは技術部とは全く違う。最初から全社展開を狙わなかったのが正解だった」と報告書にあった。
副次効果として、若手の心理障壁が低下した。「ベテランに何度も訊くと申し訳ない」という遠慮が消え、システムへの問いかけを通じて学習サイクルが回るようになった。「質問することへの心理コストが下がった。これが一番大きな変化かもしれない」と烏丸氏は記していた。
烏丸氏の報告書の最後にはこう書かれていた。「検索精度を上げる議論を半年続けて、答えが出なかった。ペルソナを一人決めた瞬間に、設計が動いた。技術問題に見えていたものは、対象を定義していない問題だった」
先輩を呼ぶ前に答えが返ってくる日が当たり前になった朝、ベテランの机が静かに業務時間を取り戻していた、と記されていた。
「RAGの精度を上げる議論には終わりがない。誰が・どんな状況で・何を訊くかが定まらない限り、技術だけでは届かない。Persona_Analysisが問うのは、対象の解像度だ。利用者を一人決めれば、必要な応答が決まり、参照すべき情報源が決まる。情報を整理する前に、問う人を設計する。点在するファイルが組織の資産にならない理由は、保管方法ではなく、問いの設計にあった。若手が一日かけても辿り着けなかった答えが、十分で出てくる日、変わったのは検索エンジンではなく、利用者像そのものだった」
関連ファイル
使用ツール
- ROI Polygraph — 若手探索工数・ベテラン対応負荷・知識継承リスクの可視化
- ROI Proposal Generator — ペルソナ駆動型知識基盤の投資回収シミュレーション
