AIとBIの狭間で。高速フィードバックループと本気で向き合って見えてきた、課題と攻略の独り言。

![IMG_8520.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/193036/2df20dc8-3486-4f20-8f93-eb652670171e.png)

この記事は私のnoteのコピー版です。
https://note.com/hakatakinoco/n/ne7a585df3af8

## はじめに

最近、プロダクトのフィードバックについて考える機会があった。

DevOpsでいう「フィードバックループ」って、コードの世界だけじゃないよな、と。ユーザーの声をいかに早く、正確に開発サイクルに組み込むか。これって、もはや僕らエンジニアにとっても他人事じゃない。

でも、ここで一つの問いが浮かぶ。「ユーザーの声」って、多ければ多いほどいいんだろうか？

![IMG_8525.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/193036/b3da0ef2-7059-458c-9cff-6a18ac750d18.jpeg)

量を求めればノイズが増えて質は下がるし、質を求めれば得られる『量』は少なくなる。このジレンマの先に、僕らが本当に作るべき仕組みのヒントがあるんじゃないか。そんなことを考え始めた、ある午後の独り言。

## 手厚い声と、速いサイクルの間で

まず断っておきたいのは、CSやマーケターの仲間たちが顧客から直接ヒアリングしてくれるフィードバックは、めちゃくちゃ貴重だということ。一つ一つが文脈に富んでいて、プロダクトを良くするための示唆に満ちている。まさに職人技であり、僕はその活動に最大のリスペクトを払っている。

ただ、一人のエンジニアとして、リーンやDevOpsの思想に染まった目で見ると、少しだけ課題感も覚えてしまう。匠の技には、どうしても膨大な人的・時間的コストがかかる。一人のユーザーとじっくり向き合う分、そのサイクルはどうしても遅くなるのだ。

> **「Fail Fast, Learn Faster（早く失敗し、より速く学べ）」**

僕らエンジニアが信奉するこの高速な開発循環のスピード感と、手厚いが故に時間がかかるフィードバックのサイクルとの間に、少しずつズレが生まれてきているんじゃないか？

このズレを埋めるために、僕は考えた。もっと広く、もっと速く、もっと多くの声を集める仕組みは作れないか、と。

### すべてのユーザーに発言権を

手軽なフォームで、参加のハードルを極限まで下げる。これは一種の「直接民主主義」への挑戦だ。

でも、現実は甘くない。集まるのはノイズや感情的な声ばかりだろうか？

そして本当に怖いのは「声の大きい少数派」に意思決定が左右されることだ。これは、現実の民主主義が常に抱える課題そのもの。

ここで僕らは最初の問いに戻る。僕らが聞くべきなのは、個々の「声」なのか、それとも群衆の「意思」なのか？

## AIという夢と、BIという現実

大量のフィードバックというノイズの海。これを解決する弾丸として、僕の頭に浮かんだのはもちろん「AI」だった。AIに全部読ませて、「要するにこういうことだろ？」って要約させたり、いい感じに分類させたり…。まさに夢のツールに見えた。

でも、少し冷静に考えると気づく。すべてのフィードバックを毎回リッチなAIモデルに処理させるのは、トークン量あたりのコストが馬鹿にならない。
それに、AIは言葉の意味を構造化するのは得意でも、そのデータが持つ重要度やビジネス上のインパクトまで判断してくれるわけじゃない。AIは全能の神ではなかった。

### そこで僕は思考を切り替えた

AIに全部やらせるのではなく、人間がやるには面倒な部分だけをピンポイントで手伝ってもらうことはできないか？
フィードバックを「不具合」や「要望」みたいにタグ付けする作業なら、キーワードのマッチングとか、BIツールの計算フィールド機能でも、ある程度は自動化できるかもしれない。

こうして、僕は理想の役割分担にたどり着いた。

![IMG_8522.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/193036/23d2073b-12b6-4972-b7d5-e63ac970a5b5.png)


**AIは最強の「下ごしらえ職人」**
テキストを構造化するという、最も面倒で、人間がやるとブレる部分だけを任せる。ここはコストをかける価値がある。

**BIは万能な「作戦司令室」**
AIが下ごしらえしたデータを、人間が高速に分析するための場所。ここは無料で始められるツールで十分だ。

![IMG_8523.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/193036/271025c0-bafb-4332-9915-9872726434af.jpeg)

完璧に見えた。…が、ここで最後の壁にぶつかる。

### BIツールを使いこなすのって、地味にむずくない…？

グラフをいじって「なんとなく」見ることはできても、本当に知りたいこと、例えば「特定のプランのユーザーが、特定の機能について、先月から急に不満を言い始めたリスト」みたいな複雑な条件のデータを出そうとすると、結局SQLを書いたり、BIツールの高度な知識が必要になる。これでは分析の民主化とは言えない。

ここで、僕は天啓を得る。

> **「BIから洞察を得たい、という課題は、AIにクエリを作らせることで解決できる可能性がある」**

「こういうデータが見たいんだけど」と僕らが自然言語でAIに話しかければ、AIがBIツールで実行するための正確なクエリを生成してくれる。

![IMG_8524.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/193036/80a89ddb-1ba2-4ea9-b498-2f01d87b21e0.jpeg)


これだ！これなら、PdMもマーケターも、SQLが書けなくてもデータに直接アクセスできる。「問い」を立てる能力さえあればいい。AIが、人間とBIツールの間の「翻訳者」になってくれるんだ。

## 本当の敵は、自分たちの脳内にいた

最新のツールを揃えても、それを使う僕ら自身が偏っていたら意味がない。僕らが戦うべき最大の敵は、自分たちの脳内にいた。

僕らを蝕むのは「３つの幻想」だ。

### 1. 「集計＝洞察」の幻想

グラフが動いても、それは「何が起きたか」を示しているだけで、「なぜ起きたか」は教えてくれない。

### 2. 「データ＝客観」の幻想

データは中立でも、解釈は中立じゃない。僕らは無意識に自分たちの仮説を裏付けるデータばかり探してしまう。

### 3. 「ツール＝銀の弾丸」の幻想

ツールは思考を助けてはくれても、思考そのものを代替してくれるわけじゃない。

この幻想に抗うため、僕はいくつかのルールを設けることを思いついた。

- **「仮説を立ててからデータを見る」という問い駆動のルール**
- **定量データと定性の生の声とを必ずセットで見る文化**
- **あえて異論を唱える「悪魔の代弁者」をチームに置くこと**

## AIとの壁打ちの先に

AIに、僕らの仮説とデータを見せて、「悪魔の代弁者」そのものをやらせるんだ。

「その解釈、偏ってない？」「別の可能性はない？」とAIに壁打ちさせることで、僕ら自身の思考の穴に気づくことができる。

## 結論

僕が考える、高速フィードバックループの成熟した姿。

それは、単に多くの声を集めることじゃない。

多様な意見を、AIの力で構造化し、人間の偏りを自覚しながら、BIという透明な場で対話し、より良い答えを導き出すプロセスそのものじゃないだろうか。

僕らのプロダクト開発は、もっと賢く、もっと誠実になれるかもしれない。
ユーザーの声と、僕らの偏見と、AIという新しい知性。その三つ巴の格闘の中から、本当に価値あるものが生まれる。

そんなことを考えた、ある午後の独りごと。

-----

## タグ

`#プロダクト開発` `#フィードバック` `#AI` `#BI` `#DevOps` `#データ分析` `#エンジニア`