私が作っているプロダクトの状況
私たちが現在取り組んでいるプロダクトは、
現状のターゲット設定のままでは、ビジネスモデルが成立しないリスクを抱えています。
価値提供が業務効率化に寄りがちで、対価として評価されにくいこと。
また、生命保険代理店におけるIT投資予算が、相対的に大きくないこと。
こうした制約の中で、
このプロダクトを「続ける」ためには、
- 現在のターゲットに対して、
付加価値をどのように増やせるのか - あるいは、
すでに獲得しているアセットを活かして、
異なるターゲットに向き合う余地はないのか
という問いに、正面から向き合う必要がありました。
その検討にあたり、私たちが選んだのが
ナレッジの棚卸しです。
本記事で扱う「ナレッジ棚卸し」とは、
結論を出すための作業ではありません。
当該プロダクト、そして関係するメンバーや共創先が
これまでの開発・実証の中で獲得してきた
既存アセットをあらためて表出させ、
次の検討に向かうための材料を揃えるプロセスを指しています。
この記事では、
「現状ターゲットへの価値向上」と
「他ターゲットへのアプローチ」という
2つの検討ゴールに向かう過程で実践した、
ナレッジ棚卸しの考え方と進め方を共有します。
同じように、
プロダクトの方向性やターゲット設定に悩む
生命保険領域のプロダクトマネージャーの方々にとって、
思考を整理するヒントになれば幸いです。
なぜ「ナレッジ棚卸し」が必要なのか
プロダクト開発が進むにつれ、チームの中には次のような情報が蓄積されていきます。
- ユーザーや現場へのヒアリング内容
- 実証・PoCを通じて得られた気づき
- 実装を見送ったアイデアや要件
- 技術的・組織的な制約条件
これらは個別には価値があるものの、
判断の文脈と切り離されたまま散在しがちです。
その結果、
- 「それは前に検討した」という会話で止まる
- 新しい仮説が過去の学びと接続されない
- 次の一手が思いつきベースになる
といった状態が生まれます。
私たちは、
「アイデアは一部の人が考えるものであり、全員では考えられない」という現状を問題と捉え、
「プロダクトを企画・開発・利用している人たちが、平等にアイデアを出し合える必要がある」と課題設定をしました。
そして、課題解決の施策の1つとして、ナレッジの棚卸しに取り組みました。
私たちが実践している「ナレッジ棚卸し術」
私たちが取り組んだナレッジ棚卸しは、大きく4つのステップに分かれます。
もし、手軽に試してみたいという方は、（1）を流用して、（2）〜（4）を実施してみてください！
（1）アセットを分類し、問いを設定する
棚卸しの起点として、
私たちは獲得してきたものを次の5つのアセットに分類し、
それぞれに対して問いを設定しました。
① ドメインアセット（業務・業界の知見）
- 業務や業界について、新たに言語化できた知見は何か
- アセット全体を通じて、顧客との接点はどう変化・拡張したか
- 単体の取引ではなく、継続的に関わる理由はどこに生まれたか
② データアセット
- 以前は見えなかった、あるいは残らなかった情報は何か
- 暗黙知が、どの単位・粒度でデータ化されたか
- 将来、価値に転換できそうなログは何か
③ 体験アセット
- このアセットによって、ユーザーは何を考えなくてよくなったか
- 以前は属人的・暗黙的だった行動は、どう変化したか
- 「やったほうがいい」から
「やらないと気持ち悪い」に変わった行為は何か
④ 実装・運営アセット
- 大規模投資なしに、すでに成立している機能は何か
- 将来の拡張に耐える、変えずに済みそうな中核要素はどこか
- 個別対応ではなく、型として回り始めている運用は何か
⑤ 組織の期待（社内・共創先）
- 「これはアリかも」と言われ始めたポイントはどこか
- 以前は懐疑的だった人が、どこで態度を変えたか
- 次に「やってみよう」と言われた要素は何か
ここでは、プロダクトの事実に関する良し悪しを判断する必要はありません。
あくまで、プロダクトに関わる人たちが思考を巡らせやすいよう、
答えたくなる問いの設定に集中します。
（2）問いに答える前に、まず「事実・実態」を書き出す
次はこのフレームに対して、プロダクトのナレッジを埋めていきます。
ただし、すぐに問いに答え始める前に、
実際に起きた事実や観測できた変化を淡々と書き出します。
- 起きた出来事
- ユーザーや関係者の具体的な反応
- 数値・ログとして残っている情報
この段階では、解釈や評価は極力入れません。
事実を揃えることで、後の議論の土台をつくります。
ちなみに、このステップは、このフレームの設計段階では考慮されていませんでした。
問いに答えようとした時に、「インプット（活動の経緯）が多すぎて、どのように答えたらいいのか迷う、時間がらなくなる」というフィードバックをもらったため、追加したものになります。
ただし、ここで挙げたことが全員の共通したインプットになってしまうため、思考が制限されてしまうことに注意が必要です。
次に説明する（3）のワークを、短時間で何度か繰り返しながら、ナレッジ表出の状態を測りながら、インプットや問いを調節することを考慮しましょう。
（3）事実を眺めながら、全員で問いに向き合う
問いに向き合う際、
私たちは次のルールを設けました。
（チームには口頭で伝えた部分もあるので、全て伝わったかは怪しいですが・・・）
メンバー個人、またはプロダクトとして
「得られたこと」「前に進んだこと」をできるだけポジティブに捉えて答える
プロダクト開発では、
課題や不足点に目が向きがちです。
あえてポジティブに答えることで、
- どこまで到達できたのか
- 何がすでに積み上がっているのか
- どの前提が変わり始めているのか
が浮かび上がります。
このワークルールにより、
参加者の議論を「失敗の振り返り」ではなく、
「プロダクトの前進を確認し、言語化する場」としてデザインすることができます。
（4）答えをグルーピングし、問いへの「ストレートな答え」に変換する
問いへの回答が出揃ったら、
さらに一段階整理を行います。
- 似た文脈の答えをグルーピングする
- 繰り返し出てくるキーワードを抽出する
- 視点の違い（PdM／エンジニア／業務側）を整理する
そのうえで、
問いごとに一文で言える答えへと変換します。
例：
- 「現時点では、〜まで可能になった」
- 「XXをしなくても、〜ができる」
- 「〇〇なスキル」
- 「（私たちだけが・私たちが活動したことによって）△△な課題を発見した！」
普段考えもしないハードな問いに対して堂々と答えた！という経験が、
次のアイデア出しのきっかけや、アイデアを周囲に発信するための個々人の自信につながるのではないか？と私は考えています。
ナレッジ棚卸しの先に見えてきたこと
この取り組みを通じて、
- メンバー全員が目指したい！と思えるアイデアの発見につながる
といった変化がありました。
・・・と言いたいのですが、私たちは、まだアイディエーションの道すがらです。
この後のアイディエーションも、
この取り組みの狙いに沿うようなワーク設計を考えていきます。
ぜひ、次の発信を期待していただければと思います！
おわりに
プロダクト開発において、
立ち止まることは後退ではありません。
これまで積み上げてきたものに向き合い、
どこまで来たのかを確認することが、
次の前進につながると私たちは考えています。
今後も、
プロダクト開発や共創の中で得られた学びを、
こうした形で発信していきます。
最後まで読んでいただき、ありがとうございました。
