カミナシのPdM migi、デザイナー satoami、エンジニア sawakiです。私たちは「カミナシ 設備保全」というプロダクトの立ち上げからグロースまでをチームで進めてきました。
このプロダクトは、β版公開から約1年間ですでに非常に多くのお客さまに導入いただいています👏 しかも、立ち上げ時点ではチームはビジネス側も含めて5名という小規模体制で運営していました。
このような成長の裏側で常に信じてきたのが「インサイトマネジメント」という考え方です。この考え方をチームで徹底してきたことで、いくつもの成果を実現することができました。
過去2年間のプロダクト開発で、手戻りはほぼなし
リリース後に機能を削除したことは一度もない
お客さまからは「これが欲しかった」「今まで見てきたアプリやシステムの中で過去イチで良い」という声
この1年間、noteでの発信やPM confなどの登壇でも取り組みの概要を公開してきましたが、改めて私たちが考える「インサイト駆動でのプロダクト開発」の全体像をまとめてみようと思い、今回Cocodaで事例を公開することとしました。
私たち「カミナシ 設備保全」チームが、なぜインサイトマネジメントに取り組むのか。具体的な開発の現場でどのようにPdM、デザイナー、エンジニアが連携しているのか。少しでもみなさまのヒントになるように整理してみようと思います。
まずそもそもカミナシは、「現場ドリブン」というカルチャーのもと成長してきた会社です。
ノンデスクワーカー向けにDXを推し進めるカミナシでは、私たちが理解できていない現場のペインを事細かに理解するために、特定の職種だけでなく全社員が現場に訪問して観察をしながら事業に活かしていくことをカルチャーとして重んじてきました。
実際、「カミナシ 設備保全」だけでもこれまでに100回以上の現場訪問をしており、社内には無数のインタビューメモや動画が残っています。
普通はこれだけ現場訪問していれば十分ユーザーを理解できると考えるかもしれません。ただ、私たちはこれだけでは足りないと考えていました。
カミナシでは、デザイナーやエンジニアも当たり前のように現場訪問を繰り返していますが、各人が触れられるお客さまの数にはもちろん限界があるので、現場訪問だけではどうしても知っているサンプルに偏りが生まれてしまいます。
加えて、プロダクトが拡大してくるとユースケースも増えていくので、偏りなくさまざまなお客さまを理解していく必要が出てきます。
こうなると、機能開発を進める上でチームメンバーの認識のズレが問題になってきます。チームで同じ話をしているようで実は想像しているサンプルが違っていたり、あまり肌感のない課題に対して機能開発をしなければいけない場面も出てきてしまいます。
このような状況が続くと、やがて「一番お客さまに多く触れている人 is King」のような構図がチームに生まれ始めます。
例えばPdMが「これをつくる！なぜならお客さまはこうだから」と言えば、他のメンバーは「本当か？？」と思いつつ「でも多分そうなんだろう (自分はあまりお客さまに会えていないし)」と、誰もユーザーの全体像は見えていないにも関わらず、いわばPdMのお気持ち駆動のような形で開発が進んでいきます。
プロダクトの立ち上げ初期であれば、PdMが本当に課題を理解していてうまくいくかもしれませんが、プロダクトが拡大すればするほどユースケースは増え、PdMも頭の中だけでは課題を捉えきれなくなります。
そうして、やがて誰にも使われない (またはかなり局所最適な) 機能を量産し始め、プロダクトが愛されなくなっていくバッドシナリオに至るのです。
このような状態は避けたくないですか？私たちは避けたいです。
なので、単に現場訪問をしていたり、一部のお客さまの声を聞けていればOKとするのではなく、チーム全員が偏りなくお客さまのことを深く理解できている状態まで持っていく努力が必要だと考えています。
カミナシ 設備保全チームがこだわっているのは「何をつくるか」を全員深く納得した状態で開発をはじめることです。
ここで陥りやすい失敗として、「何をつくるか」の認識を揃えるためにソリューションの話をしてしまうことがあります。
ただ、どれだけ高解像度なモックアップを見せられても、ユーザーがどういう行動をしていて、どんな課題を持っているのかを分かっていなければ、本当に「これをつくるべきだ」と納得感を持つことは難しいでしょう。
なので私たちは、ソリューションではなく、その手前にあるユーザーの行動や課題感、つまり「インサイト」の認識を揃えることから始めるべきだと考えています。
カミナシ 設備保全チームでは、これまで100回以上の現場訪問の中で得られたお客さまの声から1000を超えるインサイトを蓄積してきました。集めたインサイトから機能開発を進めることで、お客さまから確実に喜ばれる機能しか出さない開発フローを実現できています。
例えば、約2年間のプロダクト開発の中で、手戻りが起こることはほとんどなく、リリースした機能を削除したことは一度もありません。
ここからは、このインサイト駆動のプロダクト開発の具体的な進め方についてまとめます。
私たちの機能開発は、蓄積されたインサイトをもとにスコープを決めるところから始まります。
ここでは、すでに蓄積されているインサイトをざっくり並べて課題が大きい領域を特定し、プロダクトビジョンと合わせて優先度を決定します。
例えばその一つに「設備を動かすための予備品の管理が煩雑で、属人的になっている」というものがありました。
スコープが決まった後は、この課題にまつわる業務をより深く理解するために、プロトタイプを持って何社かのお客さまの工場へ現場訪問させていただき、インタビューを行いながらユースケースを確認していきます。
集めたユースケースはそのままの議事録では読み取りづらく議論しづらいため、誰でも文脈がわかるような一文のファクト情報に加工しておきます。
さらに複数のファクトから共通項を見出し、業務におけるインサイトを抽出します。(ここは手作業で行っており、その方がこの後の工程をむしろ進めやすくなるように思っています。)
こうして抽出されたインサイトを並べて、「課題の周辺にある業務の全体像」や「何にお客さまが困っているのか」といった情報を一枚のフロー図にまとめます。
この業務フロー図をチーム全員で眺めながら、「ここはどういうこと？」とそれぞれが疑問をぶつけつつ、インサイトに紐付けられたリサーチの生データを見て「ああこういうことか」と咀嚼していくような時間を取っています。
PdMやデザイナーから説明するというよりも、1人ひとりがインサイトを眺めつつ、それぞれがこれまで理解できていなかった情報を腹落ちさせていくようなイメージです。
課題の認識が揃ったあとはソリューションの話に進みます。ただ、ここでもデザイン案から話すのではなく、ユースケースマップやドメインモデリングなどを整理して、業務の全体像や課題についての認識を固める話を中心に進めていきます。
ドメインモデリングを終えて、チーム全員が「何をつくるべきか」に完全に腹落ちできたら、ようやくデザインや実装のフェーズに移っていきます。
種明かしをするならば、カミナシ 設備保全チームが機能開発において時間をかけているのはここまでの工程です。今回の機能の例でいうと「調査→インサイト整理→業務整理→チームでの咀嚼→ドメインモデリング」のステップに数十時間をかけました。
そのくらい時間をかけてでも、チーム全員でインサイトから「何をつくるか」の認識を揃えるべきだと考えています。
デザイナーは探索プロセスの初期段階から、裏側でプロトタイピングを重ねています。
現場訪問時にはユースケースを探るためのプロトタイプを用意しておき、PdMとヒアリングを進めます。これはあくまで業務理解のために、これまでのインサイトを手がかりに半分想像でつくっているもので、プロトタイプの中にも「？」などのメモが多く残っています。
その後、チームでインサイトや業務整理を進めている間にも、この後のデザイン・実装のステップで素早く進められるように裏側でデザインのパターンを用意しておきます。
この段階では、デザイン (=ソリューション案) にチームの目線が引っ張られないように、絶対にチームにはデザインを見せないようにしています。
ユースケースが固まっていないのにデザインを見せてしまうと、チームとしても「これが良いのでは？」とソリューションに議論が引っ張られてしまうようなことが起こります。解決すべき課題の認識を揃えてからデザインをFIXさせていくという順序を守ることで、インサイト駆動のフローが徹底できると考えています。
デザインを固めるのは、チーム全員でドメインモデリングを終えた後のタイミングです。この頃にはデザイナーとしてもすでに高解像度でユースケースを理解できているので、あり得ない案は自分で取捨選択しながらスピーディーにデザインを固めることができます。
その後、初めてエンジニアにデザイン案を連携します。この時点で、何をつくれば良いかという論点はほとんどなくなっていることが多く、エンジニアと一緒に「モーダルか画面遷移のどちらが良いか」「データの保存先は」など、細かな論点をユーザー目線から調整してデザインをFIXさせます。
プロダクトデザイナーのsatoamiは、社内のプロダクトデザイナーではなく同じチームのエンジニアにデザインレビューをお願いすることが多いです。
デザインレビューでも徹底してユーザー視点で最終確認をするので、デザインスキルというよりもドメイン理解があるかどうかがデザインFIXにおいても重要だと考えているからです。
カミナシ 設備保全チームでは、エンジニアも業務咀嚼、ユースケースマップ整理、ドメインモデリングのすべてのプロセスに参加しています。
実装を始める前段階からエンジニアもすべての議論に参加してユースケースの理解を深めながら、その裏側で事前にデータ構造などを整理しておくようにします。
デザインが提示されたときにも、ユースケースをもとにどの方向が良さそうかをデザイナーと議論します。
実装前にこれでもかとインサイトを丁寧に確認していくため、実装段階では特にPdMやデザイナーに確認する必要もなく、素早く手戻りなく実装が進められていきます。
このようなフローで「予備品管理機能」のような機能が生まれています。
ちなみにこの機能はお客さまからも「これが欲しかった」「本当によくわかっていますね」という声をいただき、さらにカミナシ 設備保全をアクティブに使う方が増えるきっかけとなりました。
インサイト駆動なプロダクト開発を続けていく中で、これまで私たちが所属していたチームと比べても、全員が自律的に動けるようになっていると感じます。
各自がインサイトにもとづいて意思決定ができるので、驚くべきことにこれまでに手戻りが起こったことは一度しかありません。(一度だけ、簡易な機能なのでと思いこのステップを飛ばした際に手戻りが発生したので、改めてインサイト駆動の重要性を実感しました。)
チームの開発スタイルとして「インサイトがなければつくらない」というレベルで浸透しており、インサイトに腹落ちするための同期の時間を惜しまないようにしています。
インサイトマネジメントを信じ続けた結果、プロダクトも急速に成長することができました。
その甲斐もあり、カミナシの中で最も「全開オープン」というバリューを体現しているとして全社で表彰してもらいました。
ノミネート文章にも「定性データ (インサイト) マネジメント」「Centou」というキーワードが冒頭に書かれているなど、全社の基準になるような動き方をチーム一丸となって続けられています。
これが私たちのインサイト駆動でのプロダクト開発の全貌です。
前提として私たちは、立ち上げに関わった5名全員が過去にさまざまな開発現場を経験してきており、その経験を踏まえてインサイトマネジメントがベストな開発手法だと判断しているチームです。
なので、手法レベルで取り入れているというよりも、「これがなければ絶対にプロダクトは使われなくなるし、手戻りが起こる」という危機感を持って、何としてもインサイト駆動を止めないことを肝に銘じています。
例えば「インサイト整理はx時間やろう」といった決め事があるわけではなく、必ずチームとしての認識が揃うまでは次に進めないことを徹底しています。
これは単なる開発プロセスではなく、インサイトを中心に事業をつくるという「チームの哲学」だと思っています。
ソフトウェアはPdM1人でつくれるわけはなく、さらにカミナシのような深く難しいドメインにものをつくるなら、なおさらチームで「何をつくるか」が揃っていなければ良いプロダクトは生まれないでしょう。
インサイトマネジメントとは単に良い機能がつくれるというレベルの話ではなく、プロセスを徹底することで自律的に動けるチームや愛されるプロダクトができる「資産づくり」なのだと思います。ぜひこの事例を読んで気付きがあった方は、今日からインサイトマネジメントを始めてみてください。