うちの会社でもいわゆる「MBO」式の目標設定と評価制度を運用しているが、まぁこれが義務的で面白くないわけで、でもなかなか時間使う業務なので、せっかくならもっと前向きに有用に取り組むヒントはないかと思い読んでみました。
対話、リズム、集中、アウトカム、などアジャイルのエッセンスが目標づくりとその運用に応用されるイメージが沸いたので、義務的じゃなく成長と成果に結びつく目標づくりのヒントになりました。
内容粒度については、目標づくりに役立つ幅広いプラクティスが簡潔に紹介されていて、例えば「インセプションデッキ」と言うプラクティスがてでくるが具体的な実践の仕方については触れられない。
なので、
- これまでいろんなアジャイル関連の本を読んできた人にとっては「あーあれをここで使うのか」と知識の応用のきっかけになる
- まだそんなに事前知識がない人にとっては「これ気になるから深掘りしてみよう」と、いろんなプラクティスへの入り口になる
という感じかなと受け取りました。
また、読み進めていくと人としてうまく行くための心や姿勢のあり方の話も多くて、目標設定の枠を超えて、人やチームや組織の中でうまく仕事をするヒントも得られました。
刺さったポイントサマリ
お互いをしろう
インセプションデッキ
- インセプションデッキはそれを作り上げていく過程にも大きな意味がある
- まずはチームの前提を揃えることにフォーカス
- 誰かが残念な思いをしてしまうかもしれない、ということに気を配り対話を避けてしまうと、チームの焦点がぼやけることに
ドラッカー風エクササイズ
- 互いの強みを知る
Disagree and Commit
- チームとして最終的に決定した方針には全員でコミットする
ワーキングアグリーメント
- チームが仕事を進める上で守るべきルールや基準
- チームにとっての当たり前が新しいメンバーにとって当たり前じゃない可能性がある
- 定期的に見直す
わくわくする目標をつくろう
SMART
OKR
- 昨対比はなぜその目標を目指すのかを明確に
- 要求の不確実性、そのKRを達成したらOを達成するのか
- 技術の不確実性、そのKRを達成する方法は道筋が立っているか
- CFR、対話、フィードバック、承認
- OKRをツリーにすることに無理があるならツリーにこだわらない
- Google Re:WorkのOKRスコアカードがおすすめ
- 目標は絞る、どれも大事、はどれも大事じゃないように扱うのと同じ
チームのリズムをつくろう
- チャレンジングな目標を立て、達成しやすい小さな中間目標を設定する
開発サイクル中の成果
- 開発サイクルのゴールとしてクイックウィン、目標とのギャップを埋める小さな成果を明らかにする
- レビューは褒める会じゃなくて生み出した成果から学びを得る場
ふりかえり
- 新しいアクションを生むKPT
- Small starfish ある程度チームが成熟してきたら、新しいアクションよりも既存のアクションの更新を
マインド面での変化をもたらす
- Fun Done LearnのLearnが少ないのはチャレンジか足りてないのかもしれない
チームで余白を持つ
- 木こりのジレンマ
- 業務時間内の自己研鑽をしつこいくらいに奨励する、ためらいを持つ人は多い
チームのマインドを育てよう
- 責務とは行為にある。その結果にあらず。行動には全力を尽くすが、その行為の結果には執着しない
- とはいえ失敗は怖いので、小さく失敗する
- 失敗は、この方法はうまく行かないということの発見
- 経験→省察→概念化→実践 = 結果→分析→仮説→アクション
- 成功体験と同じように失敗体験とその学びを共有する
- 意見が対立した時は認知の4点セットで掘り下げる
- 一見ネガティヴな行動の、その人の肯定的意図を捉えてその目線で話す、リフレーミングでポジティブに見方を変える、ただしわかった風に考えない
- 善意からの行動で情報対称性や主体性を毀損することがある(忙しいだろうからやっとこうとか)
- 心理的安全性が低い状況ではまず匿名でフィードバックを集める
目標の共同所有
- 全員で達成すれば良いいうマインドの醸成
- 個人の評価はピアフィードバックやこまめな擦り合わせなど対策
ウィンセッション
- どうしてうまくいかなかったのか、ではなくどうやったらもっと上手く行くか
戦略とは今やるべき3つの優先度リスト
- 迷った時に立ち返れる優先度リスト、なぜその順位なのか徹底的に考え抜く
- 曖昧な部分があれば、より良い目標を作る良い機会となる
助け合えるチームになろう
- 関係の質が低いまま成果にこだわるサイクルにはいると、成果の圧により対立や無関心といった歪みを産む
- 好き嫌い表でチームメンバーの得意不得意、興味関心、成長機会を知る
- 費用対効果の大きなアクションをほぼほぼやってしまった時にチームは停滞感を感じる。勇気を持って労力の大きなタスクに向き合うときかもしれない
チームの開発生産性を測ろう
- Four Keys とDevOps Capability とSPACE
- VSMは暗黙知や特定の人しか知らない情報を引き出すことも目的
- 測定、数値達成を目的化すると本来の目的が歪む
- OKRでOを達成した時に、結果としてどのような変化が生まれているか、という問いへの答えとしてKRを設定する
- 開発生産性の向上を独立した目標とするか、既存の目標に関連する成果指標とするか
チームの外と向き合おう
- 解空間内の探索、あらゆる可能性を検証する
- 解空間を狭める、Oに対する相対的な立ち位置を明らかにするメトリクスを定め、計測結果から注力ポイントを探る
- 最初は注力ポイントを探ることがKRとなり得る
- ビルドトラップ、顧客のニーズではなく、自分たちの都合を優先し不要な機能をリリースする行為
- スコープの調整では「why now」で今やることで得られるもの、今やらないとどういう問題があるのかを明らかにする
ゴールにたどり着いたその先に
- 自分たちが大切にしている要素をインセプションデッキやOKRから洗い出し評価し、次のアクションについて話す
- 結果から行動を変化させていくシングルループ学習、行動の背景にある前提やメンタルモデルまで変えていくダブルループ学習、インセプションデッキの更新はダブルループ学習を活用する良い機会