見出し画像

トップダウンの機能要望とチームの納得感を両立させて、プロダクト開発の社内受託感を解消しようとした取り組み

akinatada

トップダウン型のプロダクト開発組織において、チームの社内受託感を解消するために行った取り組みを紹介します。
具体的には、トップダウンで降りてくる機能の顧客価値を明確化することで、チームの前向きな共通認識を醸成しました。

CEOのイノベーションを支えるために奮闘するポジションの方や、納得感のない機能追加に慣れてしまっている方にとって少しでも刺激になれば嬉しいです。
※このnoteは事前に社長に公開許可をもらっています😅


はじめに：トップダウン型プロダクト開発組織の課題

当社は、気候変動の領域で自社アプリ開発を行っている創業6年目のチームです。社長、私、そして開発メンバー（うち1名がデザイン兼務）の約10名で構成されており、私自身は何でも屋的な立ち位置にいます。

現在は、フェーズと組織文化によって、トップダウンの意思決定でプロダクトの機能開発を進めています。
創業者主導のトップダウンで機能開発を進めるメリットは、スピード感とイノベーティブなアイデアの追求にあると考えており、当社でも創業時はその利点を生かし、迷うことなく開発を進めてきました。

しかし、メンバーの入れ替わりや事業のピボットを重ねるにつれ、次第に「社内受託感」を感じ始めました。本来開発スピードが高まるはずが、方向性がわからず能動的に動きづらい状態に。デザイン（UI）のフィードバックを求め合っても、判断基準がなくコメントができない。新規開発ではモメンタムがあってほしいのに、受動的な雰囲気を感じていました。

取り組み内容：「ビジョン」と「機能要望」の間を「顧客価値」で埋める

そこで、社長の抽象的な「ビジョン」と具体的な「機能要望」の間のギャップを、「顧客価値」の観点から埋める取り組みを行いました。

社長の発言は抽象度が高く、具体的に手を動かしているメンバーにとっては「なぜつくるのか？」がイメージしづらい状況でした。
そのため、「顧客にどんな価値を与えたい機能なのか」という観点でビジョンと機能要望のギャップを埋めることが、メンバーの納得感を高めると考えました。

【注】めちゃくちゃ極端な例を書いています


「社長がやりたいことの実現」と「メンバーの納得感」の両立を考慮した結果、例えば以下のような取り組みを行いました。

・機能要望について、「誰の」「どんな課題を」「どうしたい」のかを言語化。※ビジョンと機能とのギャップが大きく考えづらい場合は、ChatGPTとさまざまな角度から壁打ちを繰り返すのがおすすめです。

・言語化の際、チームで自然と共通認識として持っている用語に着目する。例えば当社では「楽しくしたい」というキーワードがよく出ていましたが、「楽しい」は人によって解釈が分かれるものです。この目線を合わせるために、「この機能における楽しいとはどういうことか」を深掘り。

・メンバー間での認識をより合わせるために、この機能によって実現する顧客の理想の状態を会話形式で可視化。

・それらを踏まえ、アプリの体験デザインで大事にしたいことを明確にし、それが実現された場合のUIイメージを作成。

毎日大量のやりとりをしていました
どうしたらみんなで同じイメージを持てるか？の試行錯誤

詳細は省きますが、これらを何度も行き来し、練り直し、最終的に以下のようなストーリーを完成させました。

「この機能はなんのための機能か」についてのストーリー
・そもそもこれはなんのアプリか
・どういう好循環を生み出したいアプリなのか
・でも、実際はこんな課題がある
・その課題を解決するのが、今回の機能である（社長の要望）
・私たちはこれらの機能によって課題を解決し、顧客をこんな状態にし、好循環を生み出していきます
・それによってこんな世界になります（ビジョン）

「その機能はどんなUIなのか」についてのストーリー
・チームですでに共通認識であるキーワードに着目する
・それを今回の機能と掛け合わせるとどういうことなのか
・つまりアプリとして大事にしたいことは何か
・そうするとこんなUIになるのではないか

この一連のストーリーを、社長と参加してくれたメンバーとでディスカッションしました。

取り組みの成果：共通認識ができ、機能開発について意見が出し合えるように

結果として、少しずつ「私たちはこんなふうに価値を提供しようとしているのだ」という共通認識をベースに、機能開発の優先順位やデザインを議論できるようになったように感じています。
UIについても納得感を高めてもらうことができ、入社以来一度もUIに言及したことのなかった開発メンバーが意見を出してくれるようになりました。これはチームにとって大事な成果で、とても嬉しかったです。
まだまだ理想の状態には程遠いですが、小さいながらも前向きな変化を感じています。

また、社長も自身の想いを言語化しきれていなかったようで、今回作成した図や言語はピッチ資料にも採用されました。

おわりに：同じ方向を向けるレベルまで言語化を諦めない。そして何度でも作り直していく。


締めの前に…

そもそも、なぜこんな記事を書いたのか？

プロダクトマネージャーの方々の以下のようなツイートで、機能開発の理由が「社長の指示で」で止まってしまっている人たちがいることを知ったからです。

会社を背負っている社長の気持ち、
「社長が言うから」と諦めたくなるメンバーの気持ち、
「それじゃだめだよ」と呆れるベテランプロダクトマネージャーの気持ち、
全員の気持ちがわかります。

立場が違うと見ている視点も異なることから、お互い汲み取ることが難しい場面も多いと思います。それでも諦めずに、みんなが同じ方向を向けるよう言語化を追求してみることをおすすめしたいです。

ちなみに過去の私は、チームの納得感のために、なによりお客様のためにという名目で「No」を言って衝突することがよくありました。「その機能より今はこうするほうがいい、なぜなら…」などと大量の資料を作っての提案も何度もやりました。事業を、組織をより良くしたい一心からです。

そんな状況を経ていまの取り組み（「Yes」で進める）に変わったのは、結局、組織文化に合ったやり方を試行錯誤していくのがチームが前に進むための最も近道なのだと気づいたからでした。つまり「社長の要求の実現」と「チームの納得感」の両立です。
浅いレベルで、「社長が言うから、トップダウン文化だから」「仕方ない」で思考停止していたのは自分自身です。


ところで、この取り組みは半年前の話で、現在のプロダクトのストーリーは変化しています。お客様の業務や日常にフィットするまでは仮説でしかなく、新たな要望があるたびに今回のようなフローを大なり小なり取り組んで、チームの共通認識をアップデートしていっています。

今後も、自分たちに合った方法を追求しながら、お客様に喜んでもらえるプロダクト開発を進めていきます。



この記事が気に入ったらサポートをしてみませんか？