OKRとチケット駆動開発を組み合わせたチームでの取り組み

location_city Online schedule Sep 18th 02:25 - 02:45 PM JST place A Hall people 2 Interested

チームの一体感を OKR にて演出し、チケット駆動開発にて定量的な評価をすればよいのではないかという考えのもと、四半期を1サイクルとした OKR を5サイクルまわし、6サイクル目に入っています。
4サイクル目までは失敗の連続で、5サイクル目にてようやく「やってよかった」というような、ふりかえりをチームで行うことができました。
OKR の設定に苦しみ、失敗しながらも進めた OKR にて得られた知見についてお話します。


2019年に転職し、配属となったチームでの違和感を
1年ほど掛け「チケット駆動開発」にて、少しずつ解消していきました。

なぜ「チケット駆動開発」を導入しようと思ったのか
https://d.zinrai.info/public/okr-tidd-case/tidd-motivation/

チケット駆動開発を導入するために行った取り組みについては、
Redmine Japan 2020 にて、発表しています。

チケット駆動開発がまわりはじめるまでの取り組み
https://speakerdeck.com/zinrai/okr-tidd-case

チケット駆動開発の導入により、
「誰が」「何を」「いつまでに」は見えるようになりましたが、
人事評価の仕組みにてメンバーに割り当てられた役割が、
日々の業務としてチケットになっているという状態でした。
チームとしてありたい姿を共有し、進んでいくというような一体感は無く、
これを演出するための仕組みが必要ではないかと考え、 OKR を導入しました。

「チケット駆動開発」を導入しての成果と課題
https://d.zinrai.info/public/okr-tidd-case/results-introducing-tidd/

 
 

Outline/Structure of the Talk

  • OKR 導入のモチベーション
  • OKR とチケット駆動開発との組み合わせ
  • OKR を適用した範囲
  • どのような OKR を設定し、どのような結果を得たか
  • 得た結果から、次の OKR 設定・運営し、どのような結果を得たのか
  • 6サイクルの OKR にて得られた知見

Learning Outcome

  • チームの一体感を得られない OKR 運営の回避
  • OKR の教科書にない OKR 設定の知見

Target Audience

OKR に取り組んでいる人、これから取り組む予定の人

Prerequisites for Attendees

  • OKR の導入を考えている
  • OKR の設定に頭を抱えている
schedule Submitted 1 year ago

  • Satoshi Okami
    keyboard_arrow_down

    Satoshi Okami - スケーラブルなチームの作り方

    45 Mins
    Talk
    Intermediate

    "チームメンバーの離脱によるチームのサービスレベルの低下を防ぐにはどうしたらよいでしょうか?"

    "誰が抜けても機能し続けるチームは、どうしたら作れるでしょうか?"

    "チームメンバーの増減の影響を抑えて、ベロシティを維持するにはどうしたらよいでしょうか?"

    "人事異動に柔軟で、個人に依存せず、長く機能するチームは、どうしたら作れるでしょうか?"

     

    こうした問いに対するヒントを提案します。

     

    引き継ぎをなくすことで、これらの問題は解決します。

    結果として、チームメンバーの増減に柔軟なスケーラブルなチームができます。

     

    では、引き継ぎをなくすには、どうしたらよいでしょうか?

    それは、属人性をなくすことです。属人性には種類があります。

    • ワークフローの属人性

        ex. 必須レビュアー

    • 業務知識の属人性

        ex. 認証認可の知識 etc

    • 役割の属人性

        ex. リーダー、ファシリテーター

     

    また、属人化したタスクの存在は、以下の問題も発生させます。

    • 業務量が偏り、なぜか特定のメンバーだけ忙しい
    • エンゲージメントの低下
    • 有給を自由に取得できない
    • 常務遂行上の単一障害点の発生

     

    こうした属人性の問題をシステム(仕組み)によって解決します。

    開発プロセスをマネージメントすることで、チームはスケーラビリティを獲得すると同時にアジリティも獲得します。

    だって、お休みやMTG、異動で人が抜けたとしても、他のメンバーが代わりにできるのだから素早く対応できるでしょ?

     

    では、どのようなシステム(仕組み)を開発プロセスに組み込めばよいでしょうか。

    これについては、クラウドコンピューティングの考え方やティール組織の組織論、経営戦略や経営理論など

    多岐に渡る分野の書籍を引用して、解説します。

     

    また、属人性をなくす過程で、チームメンバーのエンゲージメントと心理的安全性が高まることや

    チームの成果を最大化させるために実践した、たった1つのことも紹介します。

     

    組織に属する1つ1つのチームが、スケーラブルとなれば、組織はスケーラビリティを獲得します。

    スケーラビリティは、組織の人的リソースの再配置を可能にします。

    つまり、組織のダイナミックケイパビリティは大きく前進します。

     

    組織というマクロなスケールで考えると、スケーラビリティの獲得は、ビジネス環境の変化に柔軟に対応できる組織基盤の構築に結びつきます。

    そうした組織を作るために、まず、チームというミクロなスケールで、24ヶ月間チームがしてきたことをお話します。

     

    ~~~~~~~~~~~~~~~~~~~~~~

    ▪️ チーム紹介

    メンバー構成:5名の混成チーム(日経社員3名(1年後1名増員)、協力会社社員2名)

    日経社員は兼務しています。

    専任の社員だけで構成されたチームより、安定したベロシティを出すのは、少し難易度が高いです。

help