こちらはエムスリー Advent Calendar 2024 10日目の記事です。
エンジニアリンググループ、プロダクトマネージャーの岩田(@a___iwata)です。 以前、「目指すは企業価値最大化！？ グループ会社支援チームのご紹介」というタイトルでグループ会社でのエンジニア・デザイナー組織作りの記事を書きました。
組織ができあがったら、次はプロダクト作りです。ということで、（やや強引ですが）グループ会社のTRANSFORMを題材とします。
- 前提：TRANSFORMとは
- イノベーションには実験が不可欠！ - 言うは易く行うは難し -
- プロダクトチームへの信頼こそが、ジレンマを突破するためのほぼ唯一の解
- 今作ろうとしているものからイノベーションを生み出す
- 継続的にイノベーションを生み出す組織、仕組みづくりを推し進める
- まとめ
- We are hiring!!
前提：TRANSFORMとは
ここでいうTRANSFORMとは、マーティ・ケーガン氏の書籍「TRANSFORMED」が記載している内容とします。
要約すると次のようなことを指します。詳細は本書をご参照ください。
- プロダクトこそがその企業の売上、利益の源泉となっている
- 顧客に愛されビジネスにとって有効なプロダクトが継続的に生み出されている状態である
- 特に”顧客に愛され”の部分に強く意識が向いている
- これを達成するために必要な仮説検証の実施や権限がプロダクトチームにあり、またプロダクトチームはその期待に対して実績を以て応えている
- プロダクトチームはイノベーションと呼べる発明を継続的に生み出している
この状態を目指さなければなりません。さて、どう頑張っていくか。
イノベーションには実験が不可欠！ - 言うは易く行うは難し -
イノベーションを生み出すためには実験、仮説検証が必要不可欠となります。 従ってプロダクトチームには実験するために必要な権限や環境が必要となります。
という言説自体に疑いを持つ人は少ないはずです。「我が国にはイノベーションが足りない。それは失敗を許す風土が乏しいことが原因だ！」といった言説はそこかしこで目にするでしょう。
ただし実際にこれをやるとなると、そう簡単にはいきません。
「TRANSFORMED」にも書かれていますが、いたるところで「それはそれ、これはこれ。実験は確かに大事だけど、それより先にこっちやってほしい」という要望や「え…？ 開発者なのにお客様に会うの…？（営業の私に何もメリットないからやめてほしいなぁ）」という（やんわりとした）反発が発生します。
先に申し上げると、こうした要望や反発を蔑ろにすることはアンチパターンです。機能要望を上げてくる人も、営業も、それぞれの立場や目標に従って動いています。こうした人達を「分かってないなぁ」などと腐したところで何も生まれません。TRANSFORMのためには社内のあらゆる関係者の理解と協力が必要となります。腐すということは、何も生まないどころか、マイナスになるリスクも高いです。
とはいえ現状を肯定するだけでは、TRANSFORMは永遠に実現されません。このジレンマを踏まえつつイノベーション実現をする必要があります。
プロダクトチームへの信頼こそが、ジレンマを突破するためのほぼ唯一の解
このジレンマを突破するための方策は突き詰めれば1つしかありません。プロダクトチームが実際にイノベーションを起こすことです。
「なんか急に脳筋みたいなこと言い始めたな」「イノベーション生むためにはイノベーションが必要って、何言ってんの？」と思ったそこのあなた、その通りです。まずイノベーションが生まれるための組織や権限作りがあり、その結果イノベーションは生まれる。そう思いたくもなります。原因があって結果が生まれると思いたくなります。
しかしこれには大きな落とし穴があります。時間がかかりすぎるのです。
例えば従業員が100名の企業があるとします。前述の通りTRANSFORMのためには企業の多くの部門を巻き込んだ取り組みが必要となります。であればなぜTRANSFORMするのか、なぜイノベーションが必要なのか、それをどうやるのか、なぜ今やるのかといった疑問に対する説明をほぼ全従業員に対して行い、一人一人が深い納得する必要があります。果たしてこれは現実的でしょうか？（ベンチャーの起業時は数名しかいないことが殆どであるため、創業者が夢や世界観を語ることで納得を得ることはむしろ鉄板の方法となりますが）
一人一人にはそれぞれの人生があります。イノベーションが必要というところまでは合意できたとしても、それをなぜ今やるのか、それをなぜその方法でやるのか、そのためになぜ自分はこの仕事を新たに行わなければならないのか、それぞれの疑問に対して、実績無しで完全に納得させることは不可能ではないでしょうか。「鋼の錬金術師」のホーエンハイムのように途方もない寿命と時間があれば数十万人の一人一人から信頼を得ることはできますが、我々の寿命はせいぜい100年程度です。
現実的な時間軸でTRANSFORMを実現するには、プロダクトチームがイノベーションを起こす必要があります。
今作ろうとしているものからイノベーションを生み出す
前提として、グループ会社支援ではすでにある事業やプロダクトを更に成長させる仕事が多いです。つまりすでにそこにプロダクトはあり、プロダクトバックログや要望一覧も存在しています。「よっしゃイノベーション起こすぞ！」といってプロダクトチームがいきなり既存のバックログや要望を放り投げてしまったら社内は大混乱です。時には大混乱を覚悟の上で推し進める必要もありますが、積極的に用いる手法ではないと思います。
従って今作ろうとしている機能・サービス・プロダクトのQCDを圧倒的に高め、周囲の期待を超えることが現実的なイノベーションの第一歩であると考えます。ここはプロダクトマネージャーとして一番頭を捻らないといけないところです。これまで培ってきた知見や経験をフル動員します。手前味噌ですが、こんなことをしてきたよのパターンをご紹介します。
2割の工数で8割の効用を達成
私の中ではこれが鉄板です。今あるバックログを工数の降順で並び替え、従来比2割以下の工数で8割以上の効用が達成できるアイデアを出し、これをリリースします。
うまく言葉にできないのですが、意外とそういうバックログはあります。目を皿にしてバックログを吟味しましょう。エッジケースに”愚直”に対応するために複雑な仕様になっているとか（エッジケースを無視しろということではない）、タスクコヒーレンス（ユーザーが、昨日行ったことを今日も行う可能性は高い）を意識した導線を入れるだとか、私も様々な方法でこれに取り組んできました。
余談ですが、なぜ2割の改善で8割の効用が得られるのかは以下の書籍が詳しいです。
ユーザー満足度を取る・あげる
ユーザー満足が大事であることに異を唱える人はいません。しかし、常にユーザー満足度を意識し続けられているかというと、必ずしもそうではありません。
ユーザー満足度調査をしていない、していてもかなり昔のデータしかない、という状況であればまず調査を実施します。これに反対する人は殆どいません（もちろん、営業やCS等、顧客に接している人の業務を邪魔しないように調整すれば、の話ですが）。NPSでもなんでも構いません。これもうまく言葉にできないのですが、ユーザーの生の声に接することで素晴らしいアイデアが生まれることは意外と多いです。
継続的にイノベーションを生み出す組織、仕組みづくりを推し進める
当然ですがイノベーションは1回出せば終わり、ではなく継続的に生み出し続ける必要があります。これを実現するための組織やプロセス作りのエッセンスは「TRANSFORMED」に書かれています。これを粛々と進めていきましょう。思わぬトラブルや障害は必ずあると思いますが、へこたれずに頑張っていきましょう。私も頑張ります。
まとめ
- イノベーションを継続的に生み出す組織作りのためには、イノベーション創出が必要というジレンマがある
- 今作ろうとしている機能・サービス・プロダクトからイノベーションを生み出すことで、最初のイノベーション創出を実現できる可能性がある。知恵を振り絞る
- 継続的にイノベーションを生み出せる組織作り、仕組みづくりを推し進める。必ずトラブルはあるけど、へこたれずに頑張る
We are hiring!!
エムスリーエンジニアリンググループでは、一緒に働く仲間を募集しています！ まずはカジュアル面談から、以下URLよりご応募をお待ちしています。
