■ 1. 目標設定への苦手意識
- 長年の苦手意識:
- スプリントゴールやクォーター目標、半期目標など、毎回これでいいのかと悩んできた
- しっくり来ないまま走り出してしまったこともある
- 型を見出せない理由:
- マネジメント本を読んでも、目標設定はチームの役割や状況に依存する部分が大きい
- 自分の中での型や正解を見出せないでいた
- 『Outcomes Over Output』との出会い:
- Josh Seiden 著の書籍で、"Outcomes" という言葉の捉え直しによって一気に霧が晴れた
- 1つのシンプルな言語化で自分の開発メンタルモデルを大きく変えられた
■ 2. うまくいかなかった目標の2パターン
- 機能を期限までに出す型:
- わかりやすいが、チームの熱量や主体性が上がりづらい
- 出すこと自体がゴールになり、なんのために作っているのかという視点が抜け落ちる
- クォーター単位などでは途中で優先順位が変わることも多い
- 交渉の余地が少なく、言われたものを作るだけの空気になりがちで、理想のエンジニアチーム像との乖離が大きい
- 利用率を X% 改善する型:
- アウトプットよりアウトカムという定説を理解しないまま適用し、ビジネスの成果に寄せてしまっていた
- 開発に閉じない広い視点は得られるが、不確実性が大きくチームとしては扱いづらい
- ビジネス的な大きい KPI は、チームの手が届くところから遠すぎる
- 達成でも未達でも、開発チームの要因か営業やマーケの要因かを切り分けられない
- ふりかえりが毎回ふわっとして、改善点も曖昧になり、次につながる学びが残りづらい
- 距離感の問題:
- 近すぎても息苦しく、遠すぎても迷ってしまう
■ 3. プレスリリース目標の成功と後ろめたさ
- 手応えのあった「プレスリリースを n 本出す」:
- プレスリリースという区切りが、何を目指せばいいかを決めてくれる
- 期限もちょうどいい粒度で切れる
- 出せたかどうかを確実に判定でき、出せなかった要因もチームの外に散らばらないのでふりかえりが機能する
- 発信のためにどんな機能を作ると良いかを開発チームから提案・交渉でき、主体性を持ちやすい
- ビジネスチームや広報チームと協力してフローを整備・改善する良いチーム状態になっていた
- 歴代でいちばん納得感のある目標設定だった
- 当時抱えていた後ろめたさ:
- 「アウトプット志向は良くない」という呪いを、自分で自分にかけていた
- プレスリリースの本数はどう見てもアウトプットの目標であり、ダサい目標かもしれないと思っていた
■ 4. インパクト・アウトカム・アウトプットの定義
- インパクト:
- 組織として得たいビジネス上の利益
- 例は売上の増大やコストの削減
- アウトカム:
- インパクトを出すために起こしたい、ユーザー行動の変化
- 例はユーザーがメールを開くようになること
- アウトプット:
- アウトカムを起こすために作る、プロダクトの変化
- 例は開きたくなるメール通知
■ 5. アウトカム＝ユーザー行動の変化
- 観察できる形への落とし込み:
- ふわっとした「価値」ではなく、人が何をするようになるかという観察できる形になっている
- 「価値を届けられたか」は解釈が割れるが、「こう動くようになったか」は観測すればはっきりする
- 目標として追いやすく、チームで目指すものの認識も揃う
- 手段を決めつけない性質:
- 行動の変化という目標は、どう実現するかを決めつけない
- その行動をどう起こすかはチームに委ねられ、解決策を工夫する余地と主体性の余地が残る
- ビジネスとの接続:
- ユーザーの行動の変化なら何でもよいわけではなく、ビジネスの利益につながるものだけがアウトカムと呼ばれる
- その行動が変わるとなぜ利益につながるのかという問いが自動的についてくる
- 目標としての利便性:
- 観察でき、かつビジネスと密接なので、チーム内外への宣言内容としてかなり便利
■ 6. プレスリリース目標の再解釈
- 3段階での整理:
- インパクトはアポ（商談）を増やすこと
- アウトカムはプレスリリースを見て興味を持つ人が増えること
- インサイドセールスがプレスリリースをきっかけにコール対象を増やすこともアウトカム
- 営業が商談でプレスリリースにまつわる話をすることもアウトカム
- アウトプットはプレスリリースを出すこと、およびプレスリリースで好評そうな機能を作ること
- 見た目はアウトプットでも機能した理由:
- インパクトまでの因果が短くつながっていた
- プレスリリースが増えれば、見る人や話せるネタが増え、アポが増える
- そうした変化に効く機能は、チームで模索でき作っていける
■ 7. 良い目標の2つの基準
- 基準1:
- チームが自分の手で動かせるものか
- 基準2:
- インパクトへの因果が短くつながっているか
- 失敗した目標に欠けていたもの:
- 「機能をいつまでに出す」は手で動かせるが、インパクトへのつながりを説明できない
- 「利用率を X% 改善」は因果の先端だけを掴んでおり、チームの手で動かせない
- ちょうど1つずつ欠けていた
- 雑すぎる一般化への反論:
- 「アウトプット志向は良くない」というのは雑すぎる一般化である
- 2つの基準を満たすことが、自分が作りたい開発チームの目標設定
- ユーザー行動の変化は因果のちょうど真ん中にある観察可能な中継ポイントであり、目標の中心に置けば2つの基準を満たしやすくなる
- 言語化できたことの価値:
- なんとなく良いと感じていた目標の良さを、自分なりにきちんと言語化できたことが最も嬉しかった
■ 8. ユーザーはエンドユーザーに限らない
- 同僚はカスタマー:
- 本の後半に組織変革へアウトカム思考を適用する章 Outcomes for Transformation がある
- 「Your colleagues are your customers」というルールが出てくる
- エンドユーザーから遠い仕事でも、誰かの行動を変えようとしていることに変わりはない
- プラットフォームチームでの失敗:
- ビジネスモデルを SaaS 以外に広げる事業基盤を作るプラットフォームチームの EM をしていた
- 目標設定と組織運営にずっと失敗し続けたという自認がある
- エンドユーザーから遠く、事業という長い目線での変化や不確実性を扱う必要があった
- 何をクォーターで追う目標に置いてもしっくり来なかった
- 3段階での整理:
- インパクトは SaaS×マッチングという新しいビジネスモデルの立ち上げ
- アウトカムはエンジニアが開発の重複を避け、新しいプラットフォームの上で業務をするようになること
- アウトプットは共通でデータを扱えるような新しい基盤の提供
- 整理によって見えること:
- 基盤を作りきること自体はゴールではない
- エンジニアが移って初めて、新しい事業の開発が回り出す
- 使っていなかった人が使うようになる 0→1 の変化なので、起きたかどうかは明白で移行した人数で測れる
- チームの打ち手で動かせる
- ユーザーである社内エンジニアの事業上の課題に目を向け、最初に作るべき変化を見出しやすくなる
- Everything is an outcome:
- どんなチームの活動も、結局は誰かの行動を変えるためにある
- 自分たちのユーザーが誰なのかを特定できれば、この考え方はそのまま使える
■ 9. 目標設定を超えた広がり
- 適用範囲の広さ:
- 本ではこの視点を目標設定に限らず計画づくりや組織構造に活かせると説明されている
- チーム目標は今後もインパクト、アウトカム、アウトプットの3段階で設計していく
- 長期のプロダクトロードマップや個人・チーム・組織の役割分担設計もアウトカム起点で描きたい
- 組織文化のユーザー中心化:
- 仕様の議論やデザインのレビュー、施策の計画やふりかえりで「それでユーザーの行動の何が変わるのか」と問う
- その問いを置くだけで、価値を受け取る主体を自分たちからユーザー側に移せる
- 職種を問わずアウトカム起点で語れると、最小の工数でビジネス成果を出す道を探しやすく、工夫の余地も生まれる
- 書籍の推薦:
- 職種を問わずいろんな人にこの本を薦めてまわっており、社内のデザイナーもすぐに買っていた
- 日本語版がないのは辛いが、コンパクトに纏まっていてサクッと読める
- 日本語訳されていない名著へのファーストチャレンジにも適している
- 結び:
- 何を作ったかより、ユーザーの行動の何を変えたかでチームと自分を語れるようになりたい