- この記事内での「早さ」とは何をさすか
- なぜ「アウトカム」を高めるために「アウトプット」の早さが重要だと考えるのか
- アウトカムを高めるためには、アウトカムをイメージする事が大切
- アウトカムを高めるために、向き合っている「早さ」について
- Opportunity: 何を作り届けるか考えるための機会（Opportunity）から考える
- Discovery: 選択したOpportunityを深堀り、Minimum Viable Product（MVP）を見つける
- Delivery: MVPを顧客に届ける
- 最後に
- We are hiring
- 過去記事
この記事は、LayerXのsuguruさんによって書かれた「ソフトウエアエンジニアの組織と文化」を見て、ここ数ヶ月Spir,Incで考えている事をまとめてみようと思い、書き始めたポストになります。
上記記事内では、「技術が先か、文化が先か」という観点で書かれておりましたが、この記事では「価値を届ける速さ」というテーマで書いてみようと思います。
この記事内での「早さ」とは何をさすか
「早さ」という言葉はとても便利ですね。「手を動かす早さ」「処理の早さ」「メールに対しての返信の早さ」など様々な場面で使えます。このままでは混乱に繋がるためこの記事内では「アウトカムを高める為のアウトプットの早さ」として書きます。これでもまだ抽象的ですが
なぜ「アウトカム」を高めるために「アウトプット」の早さが重要だと考えるのか
そもそもアウトカムとは、我々が生み出す価値によって顧客が生み出す価値（成果）であるという大前提で書きます。イメージしやす形で書き直すと、Spirを生み出す事、成長させる事はアウトプットで、顧客がアウトプットを利用する事で、日程調整に使う時間が減り、商談や面接数の増加する事や、新しい施策を思考・検証する時間が増加する事、極論としては利用者の企業のKGIに影響を与える事が、アウトカムを高めると書いてもいいのかもしれません。
アウトプットは我々でコントロールが可能です。アウトカムはアウトプットに比べるとコントロールは難しい物と言えます。確実にアウトカムに繋がる物だけを生み出せるのなら簡単かもしれませんが、日程調整という言葉はシンプルに聞こえますが、実態としては顧客セグメントの違いだけで、日程調整に感じている課題や、実現したい事が事なってきます。その様な不確実性が高いなかでアウトカムを高めていくためには、利用者からのフィードバック、新たな価値に繋がる可能性のアイデアなどを元に探索を行い、検証するというサイクルを高速で回し続ける事が重要になると考えられます。
アウトカムを高めるためには、アウトカムをイメージする事が大切
アウトカムは提供している事業や、顧客などの組み合わせによって異なるため、汎用的な定義はなくドメインごと、企業ごとに向き合い続ける必要があることを大前提とします。
Spirが提供する日程調整を例に書いていきます。例えば採用シーンにおいて日程調整のためにメールに向き合う時間を0に近づける事ができたら、その分だけスカウトや選考プロセスなどに時間を投資することに繋がると思います。その結果としてレベルの高い人材の採用や、多くのメンバーの採用に繋がる事が、プロダクトが高める事ができるアウトカムの一つだと考える事ができます。
上記例では「採用シーン」と大きな定義にしていますが、まだ顧客セグメントとしては大きいかもしれません。もしかしたらSMBやエンプラといった規模も条件に入れてもいいかもしれませんし、WEB系や印刷系など業種という条件を入れてもいいかもしれません。このように顧客の解像度を高めていきながら、その顧客の何を高めていく事がプロダクトとしてアウトカムを高めていくことに繋がるのか、様々な視点から決めて目指す事が大事だと思っています。
やはりプロダクトを提供していると様々な顧客から大小様々なフィードバックをいただけますので、全部に答えたくなりますが、まずどこを目指すか決めていかないことには、特定の顧客の課題は解決するけど、より多くの顧客の課題には届かないなどにもつながってしまうかもしれません。
アウトカムを高めるために、向き合っている「早さ」について
高めるアウトカムをイメージしたとしても、それが本当に実現できるかはまた別の話だとおもいます。本当に需要はあるのか。需要はあっても届けられるか。届いたとしても利用してもらえるか。様々な課題が存在しています。
ここではより早くより高いアウトカムを生み出すために、Spirでのプロダクトマネジメントの流れの紹介と交えながら進めていきます。弊社では、O’ReillyのUser Story Mappingなどに書かれているOpportunity, Discovery, Deliveryというプロダクトマネジメントプロセスを利用しています。
atama plusさんが実施している「デュアルトラックアジャイル」にも通じる物があります。
それぞれのプロセスに関しては後述しますが、この様な型を導入している理由としては以下の通りです。
- ユーザ体験にフォーカスして考える事
- PdM、エンジニア、デザイナ、ビジネスなど異なる役割で同じ課題に向き合うと、それぞれの視点から意見が出てくると思います（いいことです）。しかしアウトカムという事を考えるとまずはユーザ体験にフォーカスして考えていくことは大事だと思っています。
- 属人化を無くしてサイクルを早めていく
- PdMやPjMなどプロダクトマネジメントに関わるメンバーが変わる毎に、チームは体制や習慣を変える事は時には正しいかもしれませんが、チームとしてのパフォーマンスは低下しています。またPdMとしてもプロダクトのWHYやWHATに集中したいところが、チーム周りの課題に向き合う頻度が増えると、PdM自体もパフォーマンスを発揮できない可能性がでてくると思っています。
- 不透明性を減らし納得して動ける状態にする
- ○○を作りましょう。UIも設計しました。あとは頼んだ！だと確かにPdMやデザイナ視点では早いと取れるかもしれません。組織によっては問題なく開発が進む可能性もあります。しかし多くの場合、開発からは「どんな体験を実現したいの？」「なぜそういう体験が重要だとおもったの？」「なぜ？」「WHY？」「なぜそのデザインなの？」「WHY？」という感じで数多くの「？」が飛び交う事になると思います。もしかしたら伝え方でそれらはなくなるかもしれませんが、いきなり決まった状態に思える場合は納得感が無くパフォーマンスも発揮できないと思います。こうなるとチーム全体としては結果的に遅い状態になる可能性がとても高いと思っています。
- 悩みを減らし全員の力のほとんどをプロダクトをより良くしたい気持ちに向ける
- 不透明性にも近いですが、プロセスへの不満や、人への不信感、今の作業は本当に価値があるのか。など様々な悩みが生まれてしまうと、パフォーマンス低下につながってしまいます。最悪ケースそのまま不満が爆発して離職につながる可能性も出るかと思います。可能な限り専門性を発揮する事に集中してもらうためには、それ以外をブラックボックス化して意識させないのではなく、なるべくコンテキストを整える事を大切にするほうが結果として集中する事に繋がると考えています。
以下最近見かけたツイート。正義！とまでは僕は言えないですが、とはいえまさにコレ。
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同様に書籍を見ていただけると助かります。
- ビジネス要件からまず土台を整える
- 今回のOpportunityに向き合う上では、○○が無いとビジネス上成立がしない（もしくは難しいなど）があればまず考えます
- どの指標がどうなれば成功とするかなど
- 1を大前提とした上で、ユーザ視点から考え、何がどの様になればユーザのためになるのかを明らかにしていく
- ストーリーマップとスケッチ・ワイヤーなどを併用しながら実現を目指すソリューションのイメージを可視化を行います。向き合うOpportunityなどによって方法は変わるかもしれません。どの様な手段を用いたとしても、ユーザ体験を主に考えるという事を忘れないことは大切です。
- 最小化とプランニング
- 1,2,3をすすめる事でとても重厚な物ができたかもしれません。もちろんすべて実現する事は理想だと思います。顧客に初めて届けるまでそこまで時間をかける事は本当に大切か。そこまで重厚にすることは本当に大切か。一度考え直しましょう。生み出したい成果に対して不要な物は確実に混ざっています。その追加されたストーリーは前のストーリー結果しだいで必要にも不要にもなるかもしれません。など問いを勧め、MVPとなる最小の状態にしていくことがとても大切になります。
上記は弊社でのストーリーマッピングです。こちらはslack連携の物ではないため、イメージ図と捉えていただけると嬉しいです。
Opportunityで例にあげましたslack連携を題材に書くと、以下の様なストーリーがありました。
- slack通知を指定したチャンネルで受け取る事ができる
- Aの場合は異なるチャンネルを指定する事ができる
- チャンネルを複数設定する事ができる
最終的には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も募集しております（募集要項まにあってません、作り次第記事を書き換えます。）
ここまでお付き合いいただきありがとうございました。