より早く高いアウトカムを実現するために、プロダクトマネジメントの型に投資する大切さ

この記事は、LayerXのsuguruさんによって書かれた「ソフトウエアエンジニアの組織と文化」を見て、ここ数ヶ月Spir,Incで考えている事をまとめてみようと思い、書き始めたポストになります。

上記記事内では、「技術が先か、文化が先か」という観点で書かれておりましたが、この記事では「価値を届ける速さ」というテーマで書いてみようと思います。

この記事内での「早さ」とは何をさすか

「早さ」という言葉はとても便利ですね。「手を動かす早さ」「処理の早さ」「メールに対しての返信の早さ」など様々な場面で使えます。このままでは混乱に繋がるためこの記事内では「アウトカムを高める為のアウトプットの早さ」として書きます。これでもまだ抽象的ですが

なぜ「アウトカム」を高めるために「アウトプット」の早さが重要だと考えるのか

そもそもアウトカムとは、我々が生み出す価値によって顧客が生み出す価値(成果)であるという大前提で書きます。イメージしやす形で書き直すと、Spirを生み出す事、成長させる事はアウトプットで、顧客がアウトプットを利用する事で、日程調整に使う時間が減り、商談や面接数の増加する事や、新しい施策を思考・検証する時間が増加する事、極論としては利用者の企業のKGIに影響を与える事が、アウトカムを高めると書いてもいいのかもしれません。

アウトプットは我々でコントロールが可能です。アウトカムはアウトプットに比べるとコントロールは難しい物と言えます。確実にアウトカムに繋がる物だけを生み出せるのなら簡単かもしれませんが、日程調整という言葉はシンプルに聞こえますが、実態としては顧客セグメントの違いだけで、日程調整に感じている課題や、実現したい事が事なってきます。その様な不確実性が高いなかでアウトカムを高めていくためには、利用者からのフィードバック、新たな価値に繋がる可能性のアイデアなどを元に探索を行い、検証するというサイクルを高速で回し続ける事が重要になると考えられます。

Outcomes over Output: Productivityの高い組織への変革|Yoichi Tagaya|note

Outcomes over Outputとは「Output (つくったもの) よりもOutcome (成果) に目を向ける」というシンプルで本質を表した概念です。 最近邦訳版が出版されたMelissa Perri著「 プロダクトマネジメント - ビルドトラップを避け顧客に価値を届ける」では、Output志向の問題をビルドトラップという言葉で表現しています。Silicon Valley Product Groupの記事 " Product vs. Feature Teams" では、Product TeamはOutcome志向でFeature TeamはOutput志向のように対比しています。そのままのタイトルの本 " Outcomes Over Output: Why customer behavior is the key metric for business success" (Joshua Seiden著) もあります。 この記事では、Outcomes over OutputとProductivity、そして組織を結び付けて解説します。少し時間が空いてしまいましたが、2020年7月21日のDevelopers Summit (通称デブサミ) 2020 Summerで発表したスライドに説明を加える形で書いていきます。 生産性とは何を表すのでしょうか?これは人によって大きく認識の異なる言葉です。この記事では、英語のProductivityとして生産性を説明します。 元々Productivityは、動詞のProduce (生産する) に「...の性質・傾向・活動をもつ」という接尾語ivityが付加されてできた単語です。つまり、Productivityは生産する活動の度合いを意味し、それはよくOutput/Input (投入量あたりの生産量) と表現されます。 しかし、生産性をこのように認識することは辞書どおりの説明の落とし穴だと私は思います。プロダクト (Product) を開発して提供する会社では、Productivityを名詞のProductと接尾語ivityの合成語として捉えるべきと考えます。 では、Productとは何でしょうか?最も抽象度の高いレベルで言うと、Productは会社のMissionやVisionを達成するためのものです。Mission/Visionが達成するということは、Productによってお客さまの行動を変えるということです。つまり、お客さまが価値を認めて使うものがProductであり、最終的に計測される数値としてKGI (Key Goal Indicator) を上げるものがProductです。 *KGIは会社のステージ・状況により異なります。Active User数、売上、利益率などがあります。 このように考えると、ProductivityはMissionやVisionを達成するための活動の度合いを表します。それはお客さまの行動を変えるための活動の度合いであり、さらにお客さまが価値を認めてProductを使ってくれるための活動の度合いであり、最終的な数値としてはKGIを上げるための活動の度合いと言えます。 では、Outcomes over Outputの考えをProductivityと結びつけてみます。Output (つくったもの) にばかり注目していると、それはProductの成果になっているか不明な状態になってしまいます。Productがお客さまの行動を変えているか不明ですし、お客さまの価値になっていないかもしれないからです。さらに最終的にKGIを上げているかも不明です。 Outcome (成果) に目が向いている場合、それはProductが成果を出しているかきちんと認識している状態です。Productがお客様の行動を変えている、つまりお客さまがProductの価値を認めて使っている状態であり、最終的にはKGIを上げている状態です。 Inputとなる社員の仕事からOutcome (成果) まで繋げて考えると以下の図のようになります。Inputとなる社員の仕事が組織に集まり、そのOutput (つくったもの) までしか注目しないのが狭い意味での生産性です。そこからさらにOutputがOutcome (成果) になっているかまで注目するのが真の広い意味での生産性でありProductivityです。真の広い意味での生産性を得るためには、成果となるか不明瞭なOutputが成果に結びつくように事前に考えて行動をとる必要があります。 ...

Outcomes over Output: Productivityの高い組織への変革|Yoichi Tagaya|note

アウトカムを高めるためには、アウトカムをイメージする事が大切

アウトカムは提供している事業や、顧客などの組み合わせによって異なるため、汎用的な定義はなくドメインごと、企業ごとに向き合い続ける必要があることを大前提とします。

Spirが提供する日程調整を例に書いていきます。例えば採用シーンにおいて日程調整のためにメールに向き合う時間を0に近づける事ができたら、その分だけスカウトや選考プロセスなどに時間を投資することに繋がると思います。その結果としてレベルの高い人材の採用や、多くのメンバーの採用に繋がる事が、プロダクトが高める事ができるアウトカムの一つだと考える事ができます。

上記例では「採用シーン」と大きな定義にしていますが、まだ顧客セグメントとしては大きいかもしれません。もしかしたらSMBやエンプラといった規模も条件に入れてもいいかもしれませんし、WEB系や印刷系など業種という条件を入れてもいいかもしれません。このように顧客の解像度を高めていきながら、その顧客の何を高めていく事がプロダクトとしてアウトカムを高めていくことに繋がるのか、様々な視点から決めて目指す事が大事だと思っています。

やはりプロダクトを提供していると様々な顧客から大小様々なフィードバックをいただけますので、全部に答えたくなりますが、まずどこを目指すか決めていかないことには、特定の顧客の課題は解決するけど、より多くの顧客の課題には届かないなどにもつながってしまうかもしれません。

アウトカムを高めるために、向き合っている「早さ」について

高めるアウトカムをイメージしたとしても、それが本当に実現できるかはまた別の話だとおもいます。本当に需要はあるのか。需要はあっても届けられるか。届いたとしても利用してもらえるか。様々な課題が存在しています。

ここではより早くより高いアウトカムを生み出すために、Spirでのプロダクトマネジメントの流れの紹介と交えながら進めていきます。弊社では、O’ReillyのUser Story Mappingなどに書かれているOpportunity, Discovery, Deliveryというプロダクトマネジメントプロセスを利用しています。

image

atama plusさんが実施している「デュアルトラックアジャイル」にも通じる物があります。

それぞれのプロセスに関しては後述しますが、この様な型を導入している理由としては以下の通りです。

  1. ユーザ体験にフォーカスして考える事
    1. PdM、エンジニア、デザイナ、ビジネスなど異なる役割で同じ課題に向き合うと、それぞれの視点から意見が出てくると思います(いいことです)。しかしアウトカムという事を考えるとまずはユーザ体験にフォーカスして考えていくことは大事だと思っています。
  2. 属人化を無くしてサイクルを早めていく
    1. PdMやPjMなどプロダクトマネジメントに関わるメンバーが変わる毎に、チームは体制や習慣を変える事は時には正しいかもしれませんが、チームとしてのパフォーマンスは低下しています。またPdMとしてもプロダクトのWHYやWHATに集中したいところが、チーム周りの課題に向き合う頻度が増えると、PdM自体もパフォーマンスを発揮できない可能性がでてくると思っています。
  3. 不透明性を減らし納得して動ける状態にする
    1. ○○を作りましょう。UIも設計しました。あとは頼んだ!だと確かにPdMやデザイナ視点では早いと取れるかもしれません。組織によっては問題なく開発が進む可能性もあります。しかし多くの場合、開発からは「どんな体験を実現したいの?」「なぜそういう体験が重要だとおもったの?」「なぜ?」「WHY?」「なぜそのデザインなの?」「WHY?」という感じで数多くの「?」が飛び交う事になると思います。もしかしたら伝え方でそれらはなくなるかもしれませんが、いきなり決まった状態に思える場合は納得感が無くパフォーマンスも発揮できないと思います。こうなるとチーム全体としては結果的に遅い状態になる可能性がとても高いと思っています。
  4. 悩みを減らし全員の力のほとんどをプロダクトをより良くしたい気持ちに向ける
    1. 不透明性にも近いですが、プロセスへの不満や、人への不信感、今の作業は本当に価値があるのか。など様々な悩みが生まれてしまうと、パフォーマンス低下につながってしまいます。最悪ケースそのまま不満が爆発して離職につながる可能性も出るかと思います。可能な限り専門性を発揮する事に集中してもらうためには、それ以外をブラックボックス化して意識させないのではなく、なるべくコンテキストを整える事を大切にするほうが結果として集中する事に繋がると考えています。

以下最近見かけたツイート。正義!とまでは僕は言えないですが、とはいえまさにコレ。

Opportunity: 何を作り届けるか考えるための機会(Opportunity)から考える

ここではOpportunityに関して詳しく書くことは控えますが、どうしてもきになる方は先程紹介した本の「第13章「オポチュニティから始める」を見てもらえますとよりイメージがしやすいかと思います。

まだUser Storyにもタスクにもなっていない物がOpportunityだとおもってください。

  • こんな機能つくりたいよね(by 社内)
  • こんな機能(とか連携)あると嬉しいな(by User)
  • もっとこうしたらいいんじゃない?(by VC)
  • ○○が使いにくいので解約しました(ツイッターに書かれたFB)

上記のような大小様々でそのままだと何も作れない抽象度の高い物が、Opportunityだと思ってもらえると良さそうです。

チームのMissionや、もしかしたらチームで目指してるKPI、前述したアウトカムなど何かを実現するために、何に向き合うかと考えていく際に、どのOpportunityに向き合うと良さそうかを考える所から、弊社のプロダクト開発は始まります。Opportunityの選択では、ソリューションなどはざっくりしたイメージレベルまでしか行いません。次のDiscoveryを考えるかどうかを判断します。

実際にSpirとして開発した上記Slack連携を例にしますと、このとき選択したOpportunityはいかのような物になります。

  • 日程調整が確定したらメール以外で通知がほしい
  • slack連携があるとうれしい

などslack appなのか、webhookなのか手段はこの時点では見えていないですが、チームとして特定の成果を生み出すには、このようなOpportunityに向き合うことが今は大事という判断となりました。

Discovery: 選択したOpportunityを深堀り、Minimum Viable Product(MVP)を見つける

Discoveryでは、以下の順番で整理を進めます。

※こちらも簡略化して書いておりますので、Opportunity同様に書籍を見ていただけると助かります。

  1. ビジネス要件からまず土台を整える
    1. 今回のOpportunityに向き合う上では、○○が無いとビジネス上成立がしない(もしくは難しいなど)があればまず考えます
    2. どの指標がどうなれば成功とするかなど
  2. 1を大前提とした上で、ユーザ視点から考え、何がどの様になればユーザのためになるのかを明らかにしていく
  3. ストーリーマップとスケッチ・ワイヤーなどを併用しながら実現を目指すソリューションのイメージを可視化を行います。向き合うOpportunityなどによって方法は変わるかもしれません。どの様な手段を用いたとしても、ユーザ体験を主に考えるという事を忘れないことは大切です。
  4. 最小化とプランニング
    1. 1,2,3をすすめる事でとても重厚な物ができたかもしれません。もちろんすべて実現する事は理想だと思います。顧客に初めて届けるまでそこまで時間をかける事は本当に大切か。そこまで重厚にすることは本当に大切か。一度考え直しましょう。生み出したい成果に対して不要な物は確実に混ざっています。その追加されたストーリーは前のストーリー結果しだいで必要にも不要にもなるかもしれません。など問いを勧め、MVPとなる最小の状態にしていくことがとても大切になります。

image

上記は弊社でのストーリーマッピングです。こちらはslack連携の物ではないため、イメージ図と捉えていただけると嬉しいです。

Opportunityで例にあげましたslack連携を題材に書くと、以下の様なストーリーがありました。

  1. slack通知を指定したチャンネルで受け取る事ができる
  2. Aの場合は異なるチャンネルを指定する事ができる
  3. チャンネルを複数設定する事ができる

最終的には2,3は1をリリースしたあとで、本当に需要があればやりましょう。今はまずSlack通知が出来ない状態からできる状態になることがMVPとしますとなりました。

※本当はもっと色々ありますが、記事の都合上簡略化しています。

Discoveryでは記事のテーマでもある「早さ」に触れておきます。往々にしてプロダクト開発の「早さ」の話がでるときは、開発の生産性が低いとか、もっと他社比較して機能のリリースを増やしたいとか、「開発」にフォーカスが当たる事が多いと思います。それが全てダウトとは言いません。もちろん真実でもあると思っています。しかしそれが全てではないと考えています。

プロダクト開発やりたい事が多いけど、開発が追いつかないは嬉しい悲鳴ですが、やりたい事は本当にいまやるべき物がBacklogの上の方にあるのでしょうか?MVPの話で触れたとおり、もしかしたら無くてもいいものを必要と思いこんで居ないでしょうか?こういったアイテムを減らしていくことも「開発の早さ」であると考えることは大事だと思っています。我々はチームです。チームとしての早さは考える所から早めていく必要があると思っています。

Discoveryの責任

  • アウトカムに繋がるMVPを考える事(価値視点)
  • 最小手数でアウトカムに繋げられる「顧客が価値を感じる最小限のストーリー」を見つける事(生産量視点)

Delivery: MVPを顧客に届ける

Opportunity, Discoveryと来て最後はDeliveryとなります。

この時点では何故作るのか(WHY)、何を作るのか(WHAT)、それはどんな見た目や体験(UI/UX)なのか(HOW)がSyncされている状態が理想です。これらのコンテキストが共通認識となっている状態であれば、悩む事無くどうやって最小手数で開発を進め顧客に届けられるかにフォーカスする事ができます。

ここからはAgile文脈で登場するScrum, XP, Kanbanといったフレームワークが存在していますので、そちらにおまかせしようと思います。

Deliveryの責任

  • Productivityを高めアウトプットを生み出し続ける事
  • アウトプットするコードやソフトウェアの品質を高め続ける事
    • 低品質なものをデリバリしてしまうと、将来のDeliveryのブレーキやブロック要因となり返ってくる。技術的負債・バグなど。トレードオフを見極めながら選択を進めていく事が大切

最後に

文章量が多いため、後半少し曖昧な文章も増えてしまいました。長い文章でしたが読んでいただきありがとうございます。この記事ではOpportunity, Discovery, Deliveryで何をするかという事は補助的に書いたつもりではありましたが、文章が多くなってしまいました。

一連の中で一番書きたかった事としましては、アウトカムとは何かを考える所から、Opportunity, Discovery, Deliveryと役割や責任はことなるStepがありますが、全ては一つの流れということです。そして「早さ」とはどこか一つのStepの責任ではなく、全てのStepでのしわ寄せが後ろのStepに蓄積され、そして結果として遅さにつながってくるという事を意識して、一つ一つ向き合い早めて行くことが大切だと考えています。

この記事を書いている現在、Spirでは概ねこの記事のとおりの体制ではございますが、もしかしたら数週間、数カ月後全く違う形になる可能性も無いとは言い切れません。型を作った終わりではなく、そこからが始まりですので、常にふりかえり必要な変化を起こして行くことが大切だと考えています。

We are hiring

Spirはまだまだ合計14名で、エンジニアが8名とエンジニア比率は多いですがまだまだ小さい会社です。これまで以上にPLGで戦うためにどうかお力を貸していただけないでしょうか!!

以下の募集要項は「Software Engineer」ですが、現在PdMとDesignerも募集しております(募集要項まにあってません、作り次第記事を書き換えます。)

ここまでお付き合いいただきありがとうございました。

過去記事

BigQueryのLong Term Storageが高いなーとおもったので可視化と解決した
Data雑メモ
より早く高いアウトカムを実現するために、ソフトウェアの状態に向きあった結果モジュラモノリスと向き合い始めた
Spir
より早く高いアウトカムを実現するために、プロダクトマネジメントの型に投資する大切さ
Spirプロダクトマネジメント
個人でサービスを作るとしたら今ならこうかな(2022年版)
雑メモ
2021年11月末に退任してから4ヶ月の間たちました....
一つのIdP(AzureAD)で複数のGoogle WorkspaceにSAML連携してみた
雑メモコーポレートエンジニア
約2年間の在宅勤務で試行錯誤した音に関する環境変化
雑メモ
もしスタートアップ初期からJOINするとしたら(2022版)
雑メモCTOコーポレートエンジニア
35歳になる2022年から
雑メモ
コーポレートエンジニア振り返り(仮)
雑メモコーポレートエンジニア
約5年間のCTOというロールを終えて、そしてこれから
CTO
自由って難しい
雑メモ
改めて「コミュニケーション」とはを素人ながら考えてみた
コミュニケーション雑メモ
.devに「2021年も終わるので、0からREST APIを作るならどうしようかなを考えてみた(Go編)」を書いた
.devGo
WHY? WHY? WHY?
コミュニケーション雑メモ
Notionで公開してるブログにCloudflare Web Analyticsを導入してみた
Notionにcustom domainを当てたい
過去3回iPadを手放してることもあって、iPad Airを悩んでたけど。購入したらそれ以外に選択肢ないんじゃくらい満足してると言いたい。
もしスタートアップ初期からJOINするとしたら
Cloudflareに変更してドメインもついでにかえた
Work From Home(テレワーク)が始まってもう10ヶ月経過したので仕事場を振り返ってみた
アジャイル的に知識のアップデートをしてます
Hello Notion Blog
2020年これから
2019年時点のレジュメ
雑メモコミュニケーション