顧客が本当に欲しかったものは何か？Gemini前提の設計から方針転換した理由
顧客の要望どおりに設計したはずなのに、動かない。そんなとき、どこまでが「要望に応える」ことで、どこからが「言われた通りに作る」ことなのか、線引きに迷ったことはありませんか？
- なぜ最初はGemini前提で設計したのか
- チャットからNotionへ接続できない、という壁
- 顧客が本当に欲しかったものは何だったのか
- 方針転換の提案と、最終的な決め手
なぜ最初はGemini前提で設計したのか
このプロジェクトの設計は、当初Geminiを軸に組み立てていました。理由は明快で、お客様がすでにNotebookLMを使って情報整理を行っており、それがうまく機能していたからです。RAGに近い形で資料を横断的に扱えるNotebookLMの使い勝手に、お客様自身が手応えを感じていました。
あたますでにうまくいっている道具を起点に設計するのは、自然な判断だったと思います。使い慣れた入口を変えずに、その先の蓄積の仕組みだけを整えられれば理想的でした。
お客様の要望をそのまま実装方針に反映し、Geminiを中心に据えた設計案を固めていきました。この段階では、後に方針転換が必要になるとは考えていませんでした。
チャットからNotionへ接続できない、という壁
ところが、実装を進める中で具体的な壁にぶつかりました。Geminiのチャットから、Notionへ直接連携する経路がなかったのです。
ChatGPTやClaudeであれば公式のコネクタ経由でNotionを読み書きできますが、Geminiのチャットにはこの経路が用意されていませんでした。設計の起点にしていた入口そのものが、実装段階で機能しないという事実に直面しました。
これは単なる実装上のつまずきではなく、複数のAIサービスを対等に扱おうとすること自体に無理があったという、設計の前提に関わる問題でした。前々回の記事で紹介したとおり、最終的にGeminiは情報を取得する経路を持たない「入力側専用」という非対称な役割に位置づけることになります。ただ、この時点ではまだ、お客様に「Geminiでは実現できません」とだけ伝えるわけにはいきませんでした。
顧客が本当に欲しかったものは何だったのか
ここで、お客様が本当に求めていたものは何かを、あらためて考え直しました。
あたまお客様が欲しかったのは「Gemini」という特定のツールそのものではなく、NotebookLMで実現できていた「情報を横断して使えること」だったはずだ、と気づきました。
「Geminiを使いたい」という要望は、表に出ていた形にすぎませんでした。その下にあったのは、複数の資料を横断して参照し、必要な情報にすばやくたどり着きたいという、もっと本質的なニーズです。この見立てが立ったことで、ようやく方針転換の提案に向き合えるようになりました。
Notion wikiを軸にした設計に切り替えれば、Geminiでの横断的な情報活用というニーズそのものは、むしろデータベース連携によってより高い精度で満たせる。Gemini自体を無くすことは、ニーズを削ることではなく満たし方を変えることだ、という筋道が見えてきました。
方針転換の提案と、最終的な決め手
とはいえ、この提案をそのまま持っていって、すんなり受け入れてもらえたわけではありません。お客様には明確な懸念がありました。
あたま「NotebookLMでやっていたことを、本当に代替できるのか」という懸念を、お客様は繰り返し口にされていました。すでにうまくいっている道具を手放す不安は、当然のものだと思います。
この懸念に対して、2つのアプローチを取りました。1つは、データベース連携によって知識を横断的に利用できるという利点を、具体的に説明することです。もう1つは、Notion wikiへの移行を全か無かの選択にせず、NotebookLMの利用も引き続き可能な形を残したまま提案したことです。移行によって何かを失う不安を、あらかじめ小さくしておく狙いがありました。
言葉で説明した利点だけでは、懸念は完全には消えませんでした。最終的にお客様が納得してくださった決め手は、実際に導入した後の動作でした。問題なく動き、しかもNotebookLMで見ていたときより正確に動作したことが、何よりの説得材料になりました。
説明で埋めきれなかった懸念の最後の部分は、実際に動かして見せることで埋まりました。提案の言葉より、動いているものの精度のほうが強い説得力を持つ場面だったと感じています。
まとめ
顧客の要望をそのまま実装しようとして壁にぶつかったとき、要望の裏側にある本質的なニーズまで立ち戻れるかどうかが、方針転換を提案できるかの分かれ目でした。「Geminiを使いたい」という要望と、「情報を横断して使いたい」という本質的なニーズを分けて考え直したことで、Gemini自体を手放す提案が「ニーズを削る話」ではなく「満たし方を変える話」として成立しました。そして、言葉での説得には限界があり、最後に納得を得たのは実際に動かしてみせた結果でした。
これまで紹介してきた課題、設計、技術的な工夫、チーム構成への配慮は、すべてこの一件のプロジェクトの中で同時に起きていたことです。次回は、このクラスタの締めくくりとして、全体像をまとめて紹介します。
関連記事
コメント