【プロダクト開発に関わる人必読!!!】 モノゴトを前に進める『波乗り理論』
こんにちは。カミナシでプロダクトマネージャー(PM)をしている中村です。
先月、プロダクト戦略に関する記事を書いたのですが、今回はそれを実行する中での考え方を書いてみたいと思います。
紹介するのは、人間の欲求に沿うカタチで自然と行動につなげられる『波乗り理論』(自分が勝手に命名した理論)を使うことで、カミナシでのプロダクト開発やその周辺のモノゴトを前に進めていった話です。
プロダクト開発だけでなく、仕事全般に使える理論だと考えているので、少しでも使えるかも!と思える部分があったらぜひ試してみてください!
※約1万字ほどある記事なので、時間のない方は最初の理論編だけ見てみてください。
1. モノゴトを前に進める『波乗り理論』
人を動かしやすい仕組みは「人間の欲求」に沿ったもの
モノゴトを前に進めるために、どのように考えれば上手くいくのでしょうか。実際はケースバイケースだと思いますし、いろいろな進め方があるとは思うのですが、自分の過去の経験上からは「人間の欲求を満たしているかどうか」がめちゃ大事だと思っています。
例えば、
目標数字があったら、それを達成したい!
競争があったら、それに勝ちたい!
不確実な状態から、確実な状態にしたい!
などといった、人が心理的に「してみたい!」と思えるようなことに沿った仕組み(目標設定や評価観点、コミュニケーションの仕組みなど)があると、モノゴトを前に進めやすくなるのではと思っています。
逆に、「とにかくやれ!」とか「決まってるから!」などと言って無理矢理進めようとしても、短期的に進むことはあっても、長期的にはどこかで破綻をしてしまい、結果的に上手く進められないことが多いように思います。
不安定が人を動かす
プロダクト開発では、特に不確実なものを徐々になくしていきながら進めることが多いので、いくつか例に挙げた様々な欲求の中でも、「不確実な状態から、確実な状態にしたい!」という欲求を上手く使えれば、うまいこと前進できるんじゃないかなと思うことが多くありました。
そんなふうに考えていたある日、「今日のダーリン」という日替わりエッセイの中で糸井重里さんが発信していた内容が、めちゃめちゃ参考になったので紹介します。
これを読んで、「そうか、モノゴトを前に進めるのは、連続的に(自動車とかバイクとかで)スイスイ進む感覚ではなく、人が歩くように不安定→安定→不安定→安定・・・という不安定と安定の循環を経て進んでいくのか」と、めちゃ目からウロコが落ちました。
そして、「この内容をもっと普段の仕事の中で意識すると自然とモノゴトを前に進められるのでは?」と思い、自分なりに体系立てて考えてみようと思うようになりました。
『波乗り理論』とは
そこで、整理したのが『波乗り理論』です。この理論は、「不安定な度合い」を「波」に例えて、「不安定な状態から安定な状態にしていきたい」という人間の欲求を上手く使って(=上手く波を乗りこなして)、モノゴトを前に進めていく方法論です。
そもそも波がない(=安定的な状態)だと、「不安定なものを安定的にしたい」という欲求も生まれないので、波を安定させる方向だけでなく、波を起こすことも大事になります。
また、波が高いままだと、最悪の事態としては、組織崩壊や事業の頓挫などにもつながりかねないので、波を起こした(波が起きた)のであれば、それを全力で安定させていくことも大事になります。
このように、波を起こしたり、それを安定させたりと、状況に応じることが大事だということで、「上手く波に乗る」という表現がちょうどいいのかなと思って、この名前をつけています。
そんな波乗り理論の全体像はいたってシンプルで、下の図がすべてです。「波を起こす」「波を抑える」という2つの方向について、上手くコントロールできればいいよ、という話なだけです。
とはいえ、いくつかポイントとして自分が思っていることがあるので、記載します。
(1) 波を起こせる人は限られる
組織のリーダーや、波を起こすことが得意な人(=だいたいは異端児扱いされている)など、波を起こせる人は一部の人だけだと思ったほうがいいです。全員に「波を起こせ!」と号令をかけても波は起きませんし、チーム全員で波を起こすことを目標に動いても上手くいきません。
なぜかというと、波を起こす=不安定にさせるというのは、人の欲求の真逆をいくからです。欲求に沿っていないので、居心地の悪さ、気持ちの悪さを感じる人が圧倒的多数です。なので、波を起こす人はどうしても限られます。
ただし、波を起こさない限りは次の機会に辿り着けなかったり、上手くモノゴトを前に進められないケースも多いので、リーダーは自ら踏ん張って波を起こすか、そういうことが得意な異端児を重宝してなんとか波を起こす必要があると思っています。
(2) 波を起こすと必ず不安がるリアクションが返ってくる
これは「仕方ない」と思うしかないと思っています。というか、むしろプロセスとしては成功していると思ったほうがいいのかもしれません。
今までにないことに挑戦しようとしていたり、進め方を不安定にさせている行為なので、「不安だ」「心配だ」「この先どうなるのか」という反応があることは、実は狙っている通りの方向に進んでいることだと思って、仕方ないと思うほうがよいと考えています。
(3) 波を起こすタイミングが重要
波を起こすのは、あくまでそのあと波を抑えられるから意味があるものです。チームがその波に耐えられなかったら意味がありません。なので、自分たちが耐えられそうだというのを見極めて波を起こすことが大事です。大丈夫そうという感覚をもてるまでは、もしかしたら波を起こす行為を待った方がいいかもしれません。
※とはいえ、往々にして慎重になりすぎているケースのほうが圧倒的に多いと思っています。チームは必ず成長するので、少し背伸びしたくらいでも問題ないと思っています。
(4) 波を抑えることをリーダーがいつまでもやっているようではダメ
波を抑える仕事(安定化させる仕事)はチームメンバーで行えるものですし、多くの人が関わってできる仕事です。波を抑えることに長けた様々な専門家も世の中にたくさんいます。上手く集合知を集めて、チームとして自律的にこの波を抑える仕事を進めることで、チーム全体としても成長していきやすくなります。
ここで、リーダーがこの領域にいつまでも入り続けると、チームの自律的な行動を阻害することになりかねません。リーダーが意気揚々と波を抑えるための仕事をし続けることは百害あって一利なしだと思っています。
さらに重要なこととして、リーダーは波がおさまってきたタイミングには、もう次の波を起こすことを考えているべきだと思います。いつまでも波を抑える仕事に注力していると、そういう次の波を起こす仕事に着手できなくなります。
ここまでが波乗り理論の全体像です。ここで終わってもいいのですが、理論だけで実例がないとピンとこない部分も多いと思うので、ここからは、私が所属するカミナシという組織での成功・失敗事例をいくつか紹介していければと思います。
2. 波乗り理論で対話を促す
対話の重要性
モノゴトをよい方向に進めるために、「対話」の重要性はよく言われるところです。
組織は、様々な価値観や考え方が違う人たちで成り立っているので、そのことを理解した上で同じ方向を向く必要があります。また、課題解決をしようとした場合においても、一人の人間で考えるだけだと限界があるため、対話が重要になります。このように対話はチームを同じ方向に向け、その方向の中での課題解決をする中で、重要なものだと思います。
さて、そんな大事な「対話」ですが、実際カミナシでプロダクトマネジメントをする中でも、まだまだ不十分だなと思う場面は多くあります。では、どうすれば良質な対話が生まれるのでしょうか?ここで(流れ的に当然ですが)「波乗り理論」が登場します。
※ちなみに、実際はまだまだ上手くいってないものもあります。この記事全体ではかっこつけてますが、実際はそんなもんです。
波を起こして対話を促す
対話を生むには、まず、「波を起こす」ことを第一に考えるのがいいと思います。
大概のケースにおいて、対話が生まれていないときには、変な縛り(ルール、しきたり、思い込み)があったりして、その惰性でちゃんと対話できていないということが多いからです。この惰性を取っ払う=不安にさせる=波を起こすことがまずは大事だと思います。
カミナシのプロダクト開発でも、ルール、しきたり、思い込みみたいなものが邪魔して対話をしっかりできていない場面があったので、ここは自分が積極的に関与して是正しました。(もしくは現在進行形でしようとしてます。)実際の事例をいくつか紹介します。
(1) ルールをなくす:「毎sprintで20%分は比較的規模の小さな顧客要望を必ず対応する」というルールをなくす:
開発は状況に応じて小さな規模の開発を集中的に実施したほうがよい時期と、あえてそのようなものはせずに大規模なものをしっかり対応しきったほうがよい時期があったりします。(要はそのときの優先度で柔軟に変えるべきです。)また、各開発アイテムは依存関係があるので、先々大幅な改修を予定しているものに依存している箇所は後回しにしたほうがいい場合もあります。
このような優先度や依存関係についての対話を上記ルールがあることで阻害していると考え、ルールを廃止しました。その結果、何を優先すべきか、依存関係はあるのかという対話が生まれやすくなったと実感しています。
(2) しきたりをなくす:どんな機能も「必ず」β版として小さく提供することをなくす(挑戦中)
小さく試して不確実性をつぶすことは重要です。顧客価値を高めたり、事業上の成果をだすためには、不確実性をつぶす必要があります。検証はそのような成果をだすための手段として用いることが大事です。しかし、プロダクト開発の現場では往々にして「検証そのものが目的」となりがちだと思っています。(検証することで仕事してる感がでるからとか、社内へのアピールとかのためにそうなると思っています。)
機能をリリースしたら必ず成果を定量的に測ろうとか、本格リリースする前に必ずβ版をリリースしようとか、そういうことは一見正しそうに聞こえます。しかし、例えば、顧客への影響が軽微であったり、事業インパクトにそこまで関係しない機能リリースに関して、詳細に定量データを集めてもあまり意味がありません。木を見て森を見ず状態です。正直そのような機能はリリース後の調査も最低限にとどめて、違うところにリソースを割いたほうが成果につながります。
また、β版リリースも必ずすべきかというとそうではないケース(いきなり本番リリースしちゃったほうが早く検証できるケースなど)があったり、β版としてリリースする前に、社内外でプロトタイプ版で検証すべきだったり、もっと簡易的にアナログな方法で検証すべきだったりと、状況に応じて検証の方法は異なるはずです。
これをすべてとりあえず「β版で」というマインドが高かったので(=しきたりとなっていた)、ここは是正を試みているところです。その結果として、「どのようなことを検証したいのか」「どのようなことがリスクが高い論点なのか」「その論点をどのような手法で検証すべきか」という対話を生み出すことが徐々にできているのではと思っています。
波を抑えて対話を促す
次に考えるのは不安定な状態から安定化させる(=波を抑える)ための仕組みを整えることです。
不安定な状態のまま各チームやメンバーに任せても一定自律的に進めてくれる場合もありますが、時に混乱するだけで関係が破綻したり、前進が遅くなったりするケースもあります。そのため、安定的に対話が生まれるような仕組みを整えることも大事です。
繰り返しですが、このとき注意すべきなのが、あくまで各チームやメンバーが自律的に対話することが理想ということをぶらさないことです。そのため、仕組みもあくまで、各チームやメンバーが自律的に対話することができるようなものにデザインされているべきです。
※と、偉そうに言ってるのですが、自分はこのへんの仕組み化が苦手だったりするので、カミナシの中ではいろんな人の力を借りてます。というかいろんな人が勝手にどんどん整えていってくれてたりしてます。
波を抑える具体的な方法は、よくある方法論ではあるので、ここでは簡単に事例をお伝えします。
・各Scrumチームの役割を明確にする:役割を明確にすることで、それぞれのチームが何を目指すのか?そのためには何をすべきか?本当に成果をだせているかをどう測るか?という深い議論ができるようになりました。
・ロールを超えた新たな会議体を設ける:同じロールではなく、異なるロール(つまり、違う視点をもった人たち)で議論する機会を強制的に作ることができました。
・議論の方法、報告の方法のフレームを整える:フレームに沿って、議論の方向を共通化しつつ対話できるようになりました。
このように、波を起こして「議論が必要だ」という認識をもってもらって対話を生む土壌をつくりつつ、波を抑えて「対話を発生させる仕組み」を整えることで、組織や個々人が対話するように誘導できると思います。
3. 波を起こす探索で新しい価値を作る
探索は難しい
カミナシに入社した後しばらくの間、自分はプロダクトマネジメントにおける探索に関して「難しい」と感じて悩んでいました。何を難しいと感じていたかというと、とにかく探索が意味するところが広すぎる、ということです。
「探索をします」とした場合に、何を目的にしているかの目線が揃わず、PMメンバーが何を目指して動けばいいかわからない。自分自身も何を目的に行うかを明確に示せず、なんとなく「探索しましょう」しか言えない。。というふうに、成果物が出しづらい非生産的な時間を過ごしていました。
ただ、最近はだいぶこの「プロダクトマネジメントにおける探索」というものへの理解も深まり、どのように進めればいいかが明確になってきたので、このあたりをカミナシでの事例も交えて紹介できればと思います。
探索には2種類ある
そんな難しそうな探索ですが、まさに波乗り理論に沿って「波を起こすための探索」と「波を抑えるための探索」という2つにわけることで整理すれば、わかりやすいと考えています。
波を起こすための探索
まず、「波を起こすための探索」を考えます。これはつまり、「これまでの延長線上にない次の機会を見つけにいくための探索」ということになります。
この探索の詳細分類としては、ざっとは(a)新しい顧客群(マーケット)にアプローチする、(b)新しい価値を作り出すという2つがあると思います。
そして、この(a)、(b)の方向に進めるにあたり、(1)既存プロダクトの改修、(2)既存プロダクトへの新規価値の付加、(3)既存プロダクトの再定義、(4)新規プロダクト(サービス)の開発など、いくつかの変化の程度に分かれてくると思います。
上の図で表されるように、右下にいけばいくほど波(不安定さ)は増すものだと思うのですが、程度の違いはあれど、すべて今までしてきた延長線上のものを壊し、新たな機会が得えるものだと思います。これが「波を起こす探索」と位置付けているものです。
カミナシでもこのような新たな機会を見つけるための「波を起こす探索」は、過去も今も積極的に行っていますが、その中でも失敗したもの、成功したもの(成功しかけているもの)それぞれありますので、生々しい実態を紹介したいと思います。
失敗例
少なくとも自分が入社したあと(2023年4月以降)でのカミナシでの失敗例をいくつか記載します。
・失敗例1:新しい市場開拓をPMチーム全体でしようとした
今までの主戦場の市場から新しい市場開拓の可能性がないかを、PMチームとして探索しようと、自分含め各PMメンバーに市場ごとに割り振りをして、全員に市場開拓の探索ミッションをもってもらいました。
しかし、「新規開拓の市場の可能性を探る」というゴール設定に対して、なかなか価値のあるアウトプットが出せずに時が過ぎてしまいました。(当然、開拓できたときのビジネスインパクト試算、開拓する上での論点、どうすれば開拓できそうかの仮説だしなど「可能性を探る」とは何か?というアウトプットイメージの共有まではしていました。)
この失敗のときに思ったのは、各Scrumチームを担当しているPM(目の前の開発をしている)からしたときの、新規市場開拓の可能性を探るというミッションの心理的なインセンティブが生まれていなかったことが、大きな失敗要因だということです。新しい不安定な状態を探ることを、チーム全員でやることはあまり上手くいかないんだなと学びました。
・失敗例2:新しい価値を作ることを、確実にしようとした(そして中途半端になった)
これは自分が直接関わっていたわけではないのですが、入社直後に「XXを目指す」という今までの延長線上にはない価値提供を目指す議論がされていました。一方で、作られた新機能は正直中途半端で、十分新しい価値を提供しているとは思えませんでした。
このとき感じたのは、ミニマムの束縛(MVPとしての提供にやたらこだわる束縛を自分が勝手にそう名付けています)に囚われすぎて、確実に、確実に進めようという気持ちが強すぎ、一定リスクを犯して新しい価値をつくることに挑戦できてないな、ということです。
当然、プロトタイプを経て本格的な開発に入るなり、新しい価値を生み出すにしても不確実性をなくす方法をとったほうが、成功確率は確実にあがります。しかし、それはあくまで今までの延長線上にないことを実現しようとするプロセスにすぎず、そもそもの狙いが中途半端なものであれば、新しい価値を作ることはできません。
新しい価値に挑戦するというのは、それだけリーダーポジションの人間が明確なビジョンを示し(このビジョンが多少ずれていてもあとで検証して修正できるのでOK)、それをメンバーが顧客の実態にあわせてフィットさせていくというプロセスを経ないと、なかなか上手くいかないものだと思いました。
これらの失敗例に共通するのは、波を起こすのは一部の人間だという意識を十分もてるかと、あくまでもびびって確実に対応するのではなく、しっかり波を起こす必要があるという目的認識をもつことです。このあたりが欠落すると失敗しやすいと実感しています。
※ちなみに、これらの失敗は今後新たな試みにより是正しようとしてます。まだまだこれからですが引き続き挑戦していきます!
成功例
逆に、カミナシにおいて上手くいった例も当然あるので、これも紹介します。
・成功例1:新たなプロダクト開発を経営陣が入って推進した
これは今のカミナシの状況だからこそかもしれませんが、経営が新規事業開発(新規プロダクト開発)に関わっていることが、非常にポジティブに働いているように思います。
現在、カミナシでは今まで対象としていた業界のペインだけでなく、他のペインを解消するために、複数の事業、プロダクトを立ち上げようと進めています。(こちらのプレスリリースにある「まるごと現場DX構想」に沿って事業を進めています。)
このように、複数事業や複数プロダクトを意志をもって立ち上げようという声を、経営から社内に発信していたのですが、それだけだと不安な声がでる割合に対して、実際に新しいことに挑戦していく行動自体は不十分だったと自分は感じていました。
ただ弊社の経営陣がすごいのは、その後経営陣全員が何かしら新規事業に関わって、自ら波を起こす動きをしていることです。発信した本人が自ら進める姿勢を見せることで、会社全体が新しいことに挑戦していこうという雰囲気になっています。
やはり新しいことに挑戦するのは、どのレイヤーでも大変なことですが(面白くもありますが!)、リーダーが自ら動くことで波を起こしていることが、よい方向に向かっている主要因だと感じています。
・成功例2:新たなプロダクト開発の方向づけをリーダー陣が集まって短期間で定めた
今も継続中のカミナシ全社の中でも、重要な位置付けのプロジェクトがあります。このプロジェクトの方向について、特定のリーダーに対して責任をもって進めるようCEOから依頼され、課題解決に向けて議論し、目指す状態、それに向けた方針、体制、行動計画を定めました。ここまでを約3日ほどで整理し、その後現在は約2ヶ月ほど経過しましたが、この最初の意思決定の方向でどんどんプロジェクトが進んでいる状態です。
自分もそのプロジェクトを指揮するリーダーメンバーの一人だったのですが、少人数で新しい方向に向かっていくための意思決定を、スピード感をもってできたと実感しています。やはり新しい方向性を示す際には、合議的に進めるのではなく、少数でがっと波を起こすことで上手くいくなと実感しました。
波を抑えるための探索
続いて、「波を抑えるための探索」についても触れます。(実はほとんどの本や、ブログ等で発信されているプロダクトマネジメントの探索はこちらに該当するものだと思っていて、あまり新たに発信すべき内容はない気もしていたりします。)
この探索に含まれるものはプロダクト開発の不確実性を下げるものすべてが入ります。
例えば下記のようなものが該当します。
要件を明確にするための検証
詳細な仕様を明確にするための検証
実際に価値を届けられたかの検証
狙ったビジネスインパクトがだせたかの検証
狙った新規市場において、どのように戦うべきかの検証
これらの検証は特定のリーダーや異質な人材でなくても実施できますし、むしろそのような人たちは、この「波を抑えるための探索」に可能な限り関与しないほうがいいと思っています。
実際、カミナシにおけるプロダクトマネジメントでも、PMのみでこれらを行おうとした際は、チームとして行うよう是正する動きをとっていますし、自分自身も意識し、可能な限り関わらないようにしています。これらの検証をするにあたっては、クロスファンクションチームを意識し進めることで、より不確実性を減らしていけると思います。
これらの「波をおさえるための探索」は組織の中でも洗練されやすいもので、カミナシでも自分が入社したころから現在(約8ヶ月)の間でも劇的に上手く進められるようになっています。
波乗り理論のカミナシでの事例は以上です。
ここで、理論の全体像を再掲しておきます。事例を読んだあとだと、より理解しやすいと思います。
最後に
今回は、人間の欲求に沿うカタチで自然と行動につなげられる『波乗り理論』を使うことで、カミナシでのプロダクト開発や、その周辺のモノゴトを前に進めていった話を紹介したのですが、皆さん参考になる部分はあったでしょうか?
ちなみに、「自己成長」にも波乗り理論が適用できると自分は思っています。
自分が昔所属していたリクルートの旧・社訓として「自ら機会を創り出し、機会によって自らを変えよ」という素晴らしい言葉があります。自己変革は「するぞ!」と気持ちを切り替えるだけではできないもので、周りの機会、環境によってなされるものです。そして、僕たちができるのは、そういう機会を作り出すことだけだから、そこに集中し、結果的に自己変革をしていこう、という意味だと理解しています。
そして、この「自ら機会を創る」というのは、まさに「波を起こす」ということと同義です。波を起こすのはリーダーだけですが、自分にとってのリーダーは自分自身です。ぜひ波を起こして、波に乗っていきましょう。
※ちなみに、カミナシには「自分リノベーション」というバリューがあります。どんどん自分やチームを変えていける人を、周りの人が応援する文化があるので、安心して波を起こすことができる環境があると思います。
さてさて、最後に当然告知したいのですが、そんな僕が所属するカミナシでは波を起こせる人、波を抑えることができる人など、あらゆるポジションで全方位的に採用を行っています。少しでも興味がある方は、まずは気軽にカジュアル面談で話してみましょう!
この記事が気に入ったらサポートをしてみませんか?