スクラムチームがアウトカムって結局何なの？となった時に読む記事

はじめに

こんにちは。PharmaXでエンジニアリングマネージャーをしている古家(@enzerubank)です。

スクラムチームが順調にデリバリーできるようになった頃に、このままではビルドトラップに陥るのでアウトカム志向の開発をしようと言われることがあると思います。

色んな登壇資料でもアウトカムのためのプロダクト開発をすべきで、アウトプットだけに固執してはいけないという趣旨の内容を見かけることがあります。

今まで自分自身、アウトカム=ビジネス上の成果や結果という曖昧なイメージしか持っていなかったので、「アウトプットよりアウトカムを目的にしよう」という話はそれはそうだよなと思いつつ、解像度が低すぎてそれ以上に思考を発展させることができていませんでした。

本記事では同じような課題意識を持つエンジニアやエンジニアリングマネージャーの人向けにアウトカムについてまとめた記事になります。参考になれば嬉しいです。

アウトカムの定義について

前提としてアウトカムといった言葉は組織によって捉え方が異なっており、共通の定義はありません。

ただ参考になる考え方はあり、アウトカムに関して調べていると、下記ブログの図をよく見かけます。本記事でもアウトカムはこちらの定義を参考にしています。

引用: https://blog.crisp.se/2019/10/16/christopheachouiantz/output-vs-outcome-vs-impact

さて改めて上記の図を元に定義を整理すると以下のようになります。

• アウトプット
  • 顧客に提供した機能
• アウトカム
  • 顧客のやりたかったことや課題が解決したか？
  • 顧客のために新しい可能性を創造したか？
  • 顧客の行動を変化させたか？
• インパクト
  • 売上・利益の増加
  • 顧客への価値が向上した結果としてもたらされるもの

アウトカムが顧客にとっての価値であり、インパクトが会社にとってのビジネス的な価値であるという分け方と言えます。組織によってはインパクトをアウトカムにまとめているケースもあるので、各用語の定義よりも全体の関係性を把握しておくことが大事です。

またアウトカムとインパクトは直接コントロールすることはできず、従業員が直接生み出すことができるものはアウトプットだけになります。アウトプットによってアウトカム、アウトカムによってインパクトが生み出されるという関係です。

そのため、アウトプットを生み出すことができているという事自体は素晴らしく、アウトプットが少ないチームはまずはアウトプットできるようになりましょうという所がスタートになります。

アウトカムの設定と計測

アウトカムを設定する上で重要なのは「誰を顧客とするか」です。

例えばtoC向けのプロダクトを作っている場合、実際に有料ユーザーとして使ってくれている人を顧客として、アウトカムを測りたいと思うのが自然だと思います。

ただ実際にユーザーのアウトカムを正確に測るにはユーザーログ等のデータを計測したり、ユーザーインタビューを実施していく必要があります。まだこれらのデータを貯めていないような企業の場合は、その基盤から整えていく必要があり、それだけで数ヶ月はかかってしまうかもしれません。

また施策の企画時点での設計も重要です。仮説を立て、検証するために必要な指標の定義から、計測方法まで決め、リリース後の分析作業とその評価を行う必要があります。

ここまでの手間をかけたとしても、分析した結果、「サンプル数が足らず有意な結果は得られませんでした」という結果になることもあります。

アウトカムの計測事例を調べると上記のように本格的にデータ分析を実践している例が目につきますが、既に説明した通り、上手く実践するには潤沢な人材と基盤が必要となります。

そのため他社の事例をそのまま鵜呑みにせずに、自分たちの会社の今の段階では「誰の何のアウトカムを測るのが一番生産性がよいか」を考え、自分たちに合ったやり方を考えることが大切になります。

実際にアウトカム志向の開発に変えていくにはどこから始めるべきか？

さてでは、これからアウトカム志向の開発を行う状態にしたいと考えているチームは何から始めたらよいでしょうか。

まずは最終的に欲しいインパクトからどんなアウトカムが必要になるのかを逆算していきます。
最終的に欲しいインパクトは事業売上や利益なので、事業定例の資料などを参考にします。

次にそのインパクトに必要なアウトカムを考えるわけですが、事業のKPIをそのまま使うと粒度が大きすぎる場合は、自分で分解していく必要があります。

ここで参考になるのがロジックモデルという思考ツールです。詳しい解説は省きますが、アウトカムを最終アウトカム・中間アウトカム・初期アウトカムという構造に分けて考えます。

参考: ロジックモデル作成ガイド

こうして考えていくと事業目標になっている数値が最終アウトカムで、開発の目標は初期アウトカムの直近のものになってるな。中間アウトカムが無いかもといったようなことに気づけるので便利です。

アウトカムを分解していくと最終アウトカムのために開発が影響を与えられる打ち手はどこなのか、逆に開発以外の打ち手には何があるのかについて理解が深まり、ビジネス・開発のコミュニケーションも促進されます。

もちろんアウトカムは一度分解して定義したらOKというわけではなく、実行をしながら得たフィードバックを元に絶えずアップデートしていく必要があります。

いきなり理想形を求めるのではなく、まずは叩きを作ってビジネスサイドと対話した上で、やってみて学習し、できるようになったらまたアップデートすればいいです。経験から学んで徐々に精度を上げていきましょう。

まとめ

以下が今回の記事のまとめです。アウトカムってよくわからないというエンジニア・EMの方の理解が少しでも進む一助になれば幸いです。スクラムチームがよりアウトカムに向けた開発を行っていけるように頑張っていきましょう。

• アウトプット→アウトカム→インパクトの全体の関係性を把握しておくことが大事
• アウトカムはアウトプットから生み出されるため、まず安定したアウトプットを出せるチームが必要
• アウトカムは他社事例を鵜呑みにせず、自分たちにとって生産性の高いものを考えることが大事
• アウトカムの分解にはロジックモデルという思考ツールが便利
• アウトカムを分解すると打ち手が可視化され、ビジネスと開発のコミュニケーションが促進される
• アウトカムも最初から理想を求めず経験から学んで常にアップデートすることを忘れない