Pairs事業部全体での「カンバン」を作成しました。
みなさん、お疲れ様です。 エウレカでAgileコーチさせて頂いております梶原です。
Pairs事業部全体での「カンバン」を作成することになりまして、その様子について共有したいと思います。
なぜ「カンバン」なのか
今までの組織体制
今までは事業部として。ひとつのプロダクトバックログを運用しておりました。
Pairsプロダクトのサービス運営・向上するために目的別の組織体制を組んでおりました。チームはクロスファンクショナルチームではあるものの。目的別にチームが組織されていました。
目的別チームとは、UIを改善しユーザのUXを向上させる事を目的にしたチームや、ユーザの不具合や不便を解消することを目的としたチームといった具合です。
各チームの目的・目標を明確にすることができて、各個別のチームにとって最適化された組織構成で組織されていました。
目的別組織の課題について
目的別チームは「部分最適」である。
目的別組織はチーム単体では最適化されているものの、事業の視座に立ったときには必ずしも最適ではありませんでした。
いかに優れた部分最適も全体最適には勝てない byピーター・ドラッカー
下記の通り、プロダクト・バックログの優先順位が目的別チーム・Ａに偏った時などに発生していました。
- 目的別チームＡのユーザーストーリー１
- 目的別チームＡの検証バックログ
- 目的別チームＡのユーザーストーリー２
- 目的別チームＢのユーザーストーリー１
- 目的別チームＣのユーザーストーリー１
- 目的別チームＢのユーザーストーリー２
事業部としては、「目的別チームＡ」が担当するべき案件を優先したいものの、「目的別チームＢ」と「目的別チームC」は自担当のユーザーストーリーを紹介しているという状況でした。
事業部として一貫した優先順位でバックログを消化したい
目的別チームを廃止して、プロダクト・バックログの優先順位を忠実に消化できる組織構成に変更する事にしました。
それと同時に、事業部全体のタスク管理をカンバンに持たせ、事業で一貫した開発の流れを俯瞰出来るように管理を始めました。
また、この変更のタイミングで技術的負債もこのカンバンで取扱いを始めることにしました。カンバンに載せることで、事業的なバックログと技術的なバックログを俯瞰し、優先順位をプロダクト・オーナーやステークホルダーとディスカッションできるようになって、そのバックログの順番について、関係者全員で合意を得やすくなりました。
PairsJPのカンバンの全容はこんな感じ
新しく検証のレーンを追加
仮説検証を実施して、課題検証とソリューション検証を実施してから、バックログに追加される運用を開始しました。これでプロダクト・バックログの精度が上がり、思い込みによる開発が無くなる事が期待できます。
まずは完了の定義について話しあう
事業部全体でカンバン管理するときの注意点としては、各レーンで完了に移す時の基準が各チームで解釈がズレていたら、品質にバラつきが出てしまいます。
そのため、まずは完了の定義について話し合いを行いました。それによりお互いの認識のすり合わせをすることができます。
また、各ステータスで実施しておきたいこと（Readyの条件）などのすり合わせを行って、変な忖度を無くし明確に共通的な認識を持つことができます。
ミスコミュニケーションや、手戻りを減少させることが期待できます。
完了の定義は、最初に盛りすぎてもアジリティとのトレードオフになってしまうので、まずは「必ず必要なもの」を定義します。
その後、一度プロセスを流してレトロスペクティブの中から追加しても良いので、まずは迷ったら辞めておくという温度感で定義していきました。
私たちは「Pairsがあったからこの人と出会い、結婚することができた」という人を増やし、 プロダクトを通じて誰かの人生をより可能性にあふれたものにすることを目指しています。
一緒に創り上げていけるエンジニア募集中です
