「アウトカム思考」の布教活動から始める。「やみくもな機能リリース最優先」から脱却する方法

プロダクトマネージャー（以下、PM）の皆さんの中には、「アウトカム」の重要性を理解していても、所属する組織全体が機能の数やリリース速度といった「アウトプット」を評価する文化に染まっていてアウトカムの追求にリソースを割けない、というジレンマを抱える人が多いのではないかと思います。

僕自身もPM、事業責任者、そしてCPOという役割を経験する中で、こうしたジレンマには何度もぶつかってきました。特にこの１年間、CPOとして「アウトカム思考」を組織全体に広めるべく、試行錯誤してきました。本記事では、僕の経験を踏まえ、PM1人でも始められる、「アウトカム思考を組織に浸透させるためのアプローチ」を紹介します。

• keyboard_arrow_down 「機能リリース優先」がプロダクトや組織の成長を阻む
• keyboard_arrow_down なぜ、アウトプット偏重から抜け出せないのか
• keyboard_arrow_down 「アウトカム思考」を組織に浸透させるためのロードマップ
• keyboard_arrow_down 仕組みがうまく機能しているかどうかを測る方法
• keyboard_arrow_down 組織づくりの目線で考える、アウトカムと目標設定の接続
• keyboard_arrow_down まとめ

はじめに、アウトプット偏重の組織が抱える問題について整理していきましょう。

プロダクト開発においては、機能をリリースすることが目的化しがちです。「どう使われるか」を考えるより「それっぽい機能」を出すことが優先され、使われない機能が増えていきます。それらは負債として積み重なり、コードの複雑化を招きます。結果として、開発スピードが低下するだけでなく、将来的なイノベーションや大規模な機能拡張を困難にしていくのです。

PM自身はというと、個別の機能における「点」でのユーザー体験にばかり目が向いてしまい、プロダクト全体の体験設計が疎かになります。顧客からの好意的なフィードバックも得られないまま、自分たちの仕事が事業に貢献しているという実感は薄れていきます。ユーザーに継続的に利用してもらうための本質的な価値創造が後回しになるため、プロダクトは持続的な成長が阻害され、競争優位性を失っていくでしょう。

その影響は組織全体に及びます。開発チームは「なぜつくるのか」を問う機会を失い、ただ機能をつくるだけの「フィーチャーファクトリー」と化してしまいます。さらに、チーム間の連携も機能開発が中心となり、事業全体の価値向上に向けた協働は困難になってしまうのです。

上記のような問題の解決が難しいのは、なぜでしょうか。

僕はこの要因を、大きく2つの側面から捉えています。まず「不確実なものより確実なものを評価する」という人間の心理的な傾向です。抽象度の高いビジョンや不確実な「アウトカム」を追いかけるよりも、目の前の手順が明確な作業をこなし、「これだけの機能をつくった」という分かりやすい成果を出すことで評価されたいという心理が働くのです。

もう一つは、組織の制度や文化です。既存の評価制度やKPIが「リリース日」や「機能数」といったアウトプット指標に偏っている場合、改善サイクルをじっくり回す文化が根付かず、常に短期的な成果ばかりを求めてしまうのです。そもそも、ユーザー価値の向上が事業にもたらした影響を定量的に示すことは簡単ではありません。PMが数字の「確からしさ」を求めすぎるあまり、可視化自体を諦めてしまったり、それをもとにステークホルダーと対話することに難しさを感じたりするケースは多いと思います。

では、こうした根深い課題に対し、PMから変革のきっかけをつくることは不可能なのでしょうか。

決してそんなことはありません。アウトカム思考の浸透は一夜にして成し遂げられるものではありませんが、ここからは、組織を少しずつ、しかし着実に変えていくための具体的なアプローチを見ていきましょう。

アウトカム思考を広めるためのアプローチを「認知を広げる」「周囲を巻き込む」「仕組みとして定着させる」という3つのステップで解説します。

ステップ1：アウトカムという言葉の認知を広げる

まず必要なのは、「アウトカム」という言葉と考え方を、組織の共通言語にしていく地道な活動です。アソビューでは全社共通で「GPKa」という目標管理フレームワークを導入し、部署ごとに目標を設定しているのですが、開発部門の目標に「アウトカム」という言葉を入れ、全社員の目に触れる場所に掲げました。さらに、全社で戦略を共有する場で、「プロダクトとプロジェクトの違い」「アウトプットとアウトカムの違い」について何度も解説しました。

インプットの材料を提供する際には、最新トレンドを追うのではなく、自分たちの現状に合わせた資料を用意します。もちろんトレンドをキャッチアップすることは重要ですが、基本的な概念の理解が追いついていない段階でそれを伝えても、「自分たちの課題とは遠い、どこか別の世界のすごい話」と捉えられてしまい、「自分ごと化」しにくいのです。

これはアウトプット偏重な組織にありがちな状況なのですが、アソビューには「プロジェクトマネジメント」や「アウトプット」という言葉に対しては一定の理解がある、という人が多くいました。そこで、アウトカムの概念を説明する際は、プロダクトマネジメントの名著や著名なプロダクトマネージャーによる過去の名作記事を積極的に引用し、すでに持っている知識と比較しながら理解を深めてもらえるようにしました。視覚的に整理する工夫として、書籍『プロダクトマネジメントのすべて』の図を活用したこともあります。

こうした取り組みの上で、アウトカム思考がなぜ組織や個人にとって必要なのか、会社のミッション達成にいかにしてつながっているのかを、繰り返し解説し続けるのです。

ステップ2：周囲を巻き込んでアウトカムについて話せる環境をつくる

アウトカムの概念理解が少しずつ広がってきたら、いよいよ周囲を巻き込み、仲間を増やしていくフェーズです。

いきなり経営層に話をしに行くのはハードルが高いと思うので、まずは直属の上長と話すことから始めるだけで十分です。もし、あなたの上長がPMのマネージャーや部長クラスであれば、アウトカムの重要性について既に理解があるはずです。

ただし、この悩みを抱える方の多くは、社内にPMが自分を含め数人しかいないケースではないでしょうか。その場合、上長は事業責任者や技術部門のトップであることが多いでしょう。以前のコラムで触れたステークホルダーマネジメントの手法を活かし、1on1などで、上長が会社で成し遂げたい目標を聞きに行くことが、最初の一歩となります。彼らのミッションは、「事業を成功させること」に関連しているはずです。それが聞けたら、事業成長とアウトカム思考とを結びつけて説明すればよいのです。

営業やマーケティングのメンバーには、理屈よりも「体感」で伝えることが効果的です。彼らが経験した過去の失敗事例を起点に話をしてみましょう。例えば、顧客の要望通りに急いで機能をリリースして受注したものの、短期で解約されてしまうケース。「もし機能開発の前に『顧客が本当に解決したい課題は何か』というアウトカムを一緒に深掘りできていれば、違う結果になったかも」などと伝え、開発側とアウトカムをともに目指す姿勢を伝えましょう。

ちなみに、開発チームにアウトカム思考を浸透させるのは、それほど難しくありません。なぜなら、彼らは、根源的に「自分がつくったもので誰かを幸せにしたい」という、ものづくりにおける源泉ともいえる想いを持っているからです。したがって、僕たちがすべきことは、新しい概念を教え込むことではなく、その「つくり手」の気持ちを思い出してもらうことです。PMが、多くの会社が掲げるような「顧客に満足してもらう」といったミッションやバリューに触れながら語りかけることで、開発メンバーはアウトカムという言葉を自分自身の思いとつなげられるようになります。

ステップ3：アウトカムを追求する「仕組み」をつくる

アウトカムについて話す土壌ができたら、「仕組み」へと昇華させる最後のステップです。浸透度を測りながら、目標設定やふりかえりのフローに取り入れていきます。

まず「想定アウトカム」の言語化です。施策を打つ際に、「半年でどれくらいの価値（売上、あるいは事業の重要指標）を生み出す想定か」といった想定アウトカムを数値で示すことをチームのルールにしましょう。フォーマットは、初めから統一する必要はありません。チームごとにやりやすい形で始めればよいのです 。大切なのは、期初や仕様変更のタイミングで関係者とすり合わせ、月次で進捗を確認するという運用サイクルを確立することです。

施策実施後のふりかえりでは、「想定アウトカムは達成できたか？」を必ず議題に上げます。あらかじめ定めた評価指標をもとに結果の読み合わせを行い、「ふりかえり結果から何を学び、次にどう活かすか」をディスカッションします。PMがファシリテーションする際に注意すべきは、自分だけが話しすぎていないかという点です 。エンジニアも含めたメンバー全員で、アウトカムについてディスカッションできている状態が理想です。開発側のメンバーから意見が出てこない場合、それは彼らに一次情報（顧客の声など）のインプットが足りていないサインです。

とはいえ文化を変えるのは難しい

３ステップで解説しましたが、その過程は試行錯誤の連続です。僕が最も乗り越えるのに苦労したハードルは、「期日意識、期日徹底コミット」という文化でした。もちろん、品質を多少落としても期日通りにリリースすることが必要な場面もあります。しかし、その前提となるべき「最大のアウトカムを得るための、最速のアウトプットは何か？」という議論のないまま期日だけが優先されると、「想定日にリリースできていれば開発は順調」という捉え方が当たり前になってしまいます。実際、一見その名前の機能がリリースされているものの、ふたを開ければほぼ手運用みたいなケースが散見されました。

これに対して一番効果的だったのは、実際にアウトカムの数字を出すことでした。思った成果につながっていないという事実を明確に突きつけられると、チームは「このままではいけない」と自然と改善し始めます。PRD（プロダクト要求仕様書）の段階でアウトカムを算出する方法とその目標数字をすり合わせ、それをベースにふりかえりを徹底することが、この文化を変える一番の近道だと感じています。

仕組みを定着させるには、やはり成功体験が不可欠です。成功体験をつくるには、プロダクトバックログアイテム（PBI）の詳細を提示するのではなく、「半年でCVRを130%にします」というように、まずはアウトカムベースの高い目標を宣言します。もちろん、ステークホルダー相手の場合、ただ宣言するだけでは不安になりますから、「そのためにデザインリニューアルや主要導線の刷新、A/Bテストによる改善などを想定しています」と、具体的な施策の方向性もセットで伝えましょう。プロダクト開発は終わりがないからこそ、このようにある種、強制的に区切りを設けて宣言するのが大切です。あとは目標に向かって徹底的に改善していきましょう。

かつて僕がPMだった時も、この手法で3つのプロジェクトを同時に進め、目標を達成しました。このように、チームにとっての成功体験をつくることで、アウトカム思考が自分たちの血肉となっていくのです。

仕組みをつくったら、うまく機能しているか、文化として浸透してきているかの「手応え」がほしいものですよね。基本は、1on1などを通じてメンバーに直接聞くことです。同時に、間接的な声にも耳を傾けます。Slackでのやりとりや普段の会議で、「アウトカム」「想定アウトカム」といった言葉が、PM以外のメンバーからも自然に出てきているかを観察しましょう 。もし、そうした言葉を様々な場面で聞くようになったら、それは文化として根付いてきている証拠です。

いちPMとしての取り組みの先には、組織全体の仕組みを変革していくステップがあります。全社共通の目標管理フレームワーク「GPKa」のもと、CPOとして各部の戦略方針を決定する際には、その最重要項目を「アウトカム」に設定しています。

実際のアウトカム指標は事業によって異なるため、事業責任者やPMとすり合わせて決定し、そのアウトカムを達成することをエンジニア一人ひとりの目標にも接続されるように設計しています。ここでも途中段階でふりかえりを実施する仕組みを設けることが重要です。

僕自身、PMとはほぼ週次で進捗をすり合わせ、その内容をエンジニアにも必ず共有するように促しています 。チームによっては、アウトカム指標の進捗がデイリーで確認できるダッシュボードを作成し、常に自分たちの現在地を意識できる工夫をしています 。

AIによってプロダクト開発のコストが下がっていく中で、エンジニアが「How（どうつくるか）」だけでなく「Why（なぜつくるか）」「What（何をつくるか）」の領域に越境していくことが、とても重要だと思っています。

アウトカムを出す方法を考え続けるうえで必要なのは、顧客や社内のメンバーと直接話すことで得た「一次情報」だと思います。PM以外の開発メンバーが積極的に一次情報を取得し、一緒にどうすればこの人たちが幸せになれるかを考え続けることがアウトカム思考の精度を高めることにつながります。

関わるメンバー全員が一次情報を得て、Why、What、Howを完全に共通認識化した状態で開発が進められるようになって初めて、「最速で価値あるものが届けられるPDCA」を回せると思っています。

一方で、世の中でたくさん語られているようなプロダクトマネジメントのベストプラクティスと自身の環境がほど遠いと感じられている方はまだまだたくさんいると思います。

インプットすればするほど、現実との乖離に不安になる＿＿。

僕も1年前はそうでした。

しかし、ソフトウェア開発を成功させ、事業を成功させるためにはプロダクトマネジメントは必須だと思います。今いる環境でその変革をできれば、それはきっとあなた自身の大きな財産になると思います。

プロダクトマネジメントの環境が整っている会社でプロダクトマネジメントできる人よりも、その文化がない会社で変革を起こせる人材の方が市場価値が高いと思います。まずは一歩、想いを持ち動き続けましょう。そして社内だけじゃなく、社外にも仲間を見つけましょう。そうすればきっと今いる環境ももっと楽しい場所になっていくと思います。