こんにちは。PocochaでRelease Train Engineer(RTE)をしている山下です。 Pocochaでは大規模アジャイルフレームワークの一つであるSAFe®を導入しています。 どのような理由で導入したのか、どのように導入したのかについては こちら の記事をご覧下さい。 SAFe®に興味を持っていただけたでしょうか？ この記事ではスクラムやXPをすでに導入していて大規模アジャイルフレームワークSAFe®の導入を検討している方を対象に、SAFe®の心臓と呼ばれているPIプランニングを詳しく紹介します。 PIプランニングは多数のアジャイルチームが協調し、一つの大きな目標に向かって協力するためのSAFe®の一大イベントです。 この記事が私たちと同じように異なるアジャイルチームのコミュニケーションや作業の調整に課題を抱えている方の助けになれば幸いです。 それではPIプランニングを学習していきましょう。
PIプランニングの概要
SAFe®では各アジャイルチームが実践しているスクラムのスプリントやXPのイテレーションのようにリズムがあり、その単位をProgram Increment(PI)と呼びます。 組織の規模によって体制は異なるのですが一番小さなエッセンシャルという規模でも、アジャイルチームが5~10、そしてプログラムチームも入るので参加者は少なくても50名、多くて100名の規模になります。SAFe®はその1つのプログラムチームと複数のアジャイルチームに所属している参加者をアジャイルリリーストレイン(=ART)と呼んでいます。 PIは一般的に10週間から12週間程度とされていて、PI毎にARTに関わっている全員がオフラインで集まり、開発チーム全体が目線を合わせ、次のPIでやるべきことを決めるためのオフラインイベントがPIプランニングです。
Pocochaで実践して得られた知見・気付き
Pocochaでは目標をOKRで管理していて、四半期毎に設定しています。 PIもそのリズムに合わせて四半期毎に設定しました。 PIプランニングで次のPIの目標を立てるので、組織目標と期間を合わせると同期が取りやすくなります。 そして、PIプランニングは参加者全員をオフラインで呼ぶことを推奨しています。 実際にオフラインでやってみると意思決定に必要な人すべてがその場に揃っているのでスピードが段違いです。 そして同じホワイトボードを長い時間集中して見続けなければならないのですが、気が緩むことなく活発な議論が出来たのはオフラインで開催したことが大きな要因だと感じてます。
PIプランニングのアジェンダ
PIプランニングはSAFe®の心臓と言われていて、全てのチームを共通のミッションとビジョンに合わせて目線を揃えるためのSAFe®で最も重要なイベントです。 このイベントはART全員が揃ってプランを策定し8〜12週間毎に基本2日間に渡って開催されます。 Pocochaでは前回実施した時点で、PIプランニングに参加したアジャイルチームが3チームと少なかったので1日で行ったのですが、今後チーム数が増えていき1日で収めることが出来なくなってきた場合は2日開催にする予定です。
| 項目 | 詳細 | ロール |
|---|---|---|
| ビジネスコンテキスト | ビジネスの現状についての説明 | ビジネスオーナー |
| プロダクト/ソリューションビジョン | トップ10フィーチャーの説明 | プロダクトマネジメント |
| チームブレークアウト | 各フィーチャーの見積もりとPIオブジェクティブとプログラムボードの草案を作成 | アジャイルチーム |
| プランレビュー | ART全体 | |
| プログラムリスク | ART全体に依存するリスクを洗い出す | ART全体 |
| コンフィデンスボート | プログラムボードに対する自信度投票 | ART全体 |
| レトロスペクティブ | PIプランニングの振り返り | アジャイルチーム |
1.ビジネスコンテキスト
初めにビジネスオーナーからビジネスの現状についての説明や将来のビジョン・中期計画の共有があります。 リモートワークを採用している場合はオフラインで全員揃うせっかくの機会なので、プロダクトのビジョンに共感してもらえるよう情熱を持って伝えましょう。
2.プロダクト/ソリューションビジョン
次にプロダクトマネジメントから優先度付けされたトップ10のフィーチャーの説明があります。 Pocochaではフィーチャーを担当するチームは事前にプロダクトマネジメントが作成した要求仕様の草案を元にプロダクトオーナーとQAが中心になって細かく詰めていて、その内容はPIプランニング前にチームに共有されているので仕様についてすでに理解している状態になっています。 したがってこの場では他チームへの共有だけが目的となっていて、機能概要と誰のどのような問題を解決するのかの簡単な説明のみになります。
3.チームブレークアウト
ビジネスオーナーからビジョン、そしてプロダクトマネジメントからトップ10フィーチャーの説明を受けたら、チーム毎に分かれて各フィーチャーの見積もりを行ないます。 見積もりを行うためにチーム毎に1イテレーションでどれだけの作業がこなせるのかを示す、キャパシティを計算します。 PIプランニングが初回の場合は1人が業務時間の全てを開発に当てられた場合のキャパシティを1と仮設定して計算します。事務作業や雑務、定例会議がある場合はその分の時間を引いて1営業日あたりのポイントを出しましょう。開発チーム全員のポイントを加算してチームキャパシティを計算します。 2回目以降は前回のPIのベロシティを参考にして計算しましょう。
キャパシティを計算したらタスクの1ポイントの基準を決めます。そのチームで一緒に行った作業がすでにあれば、その中から作業量が少なく技術難易度が低いものを選びそのタスクを1としましょう。もし一緒に行った作業がなければ、1日で終わりそうなタスクを1とします。 見積もりのための準備が整ったのでTOP10フィーチャーの優先度の高いものから順にプロダクトマネジメントから説明を受けましょう。 説明を受けたあとプランニングポーカーなどを使用して見積もっていきましょう。 不明点があればチームメンバー内で議論し、リスクについてもこの段階で洗い出していきます。 表にあるCapacityはその先ほど計算したチームキャパシティと営業日を掛けたものになっていて、Loadは各フィーチャーの見積もりの結果を加算したものです。 ストーリータイプはユーザーストーリーの他にフィーチャーを実装する前に必要なタスクや調査を示すイネーブラーがあります。 見積りが終わったら各イテレーション毎の負荷が可視化できるので各イテレーション毎の負荷が均一になるようにユーザーストーリー、イネーブラーを並び替えます。 ユーザーストーリーをリリースできる単位でまとめてPI目標をつくります。
3.1 スクラムオブスクラムズ
RTEはチームブレークアウトの足並みを揃えるために複数回に渡り各チームのスクラムマスターを集め、チーム毎に以下のような質問を行いましょう。
- PIの各イテレーションのキャパシティを特定したか
- 最初の2つのイテレーションについて、ストーリーを特定し見積りを始めたか
- 他のチームとの依存関係を解決し始めたか
- プログラムリスクを特定したか
- PIオブジェクティブの作成に15分以内に着手できそうか
- 他のスクラムマスターと話し合うことはあるか
Pocochaでは1時間毎に1回集まり、チームブレークアウトの進捗を同期しました。
3.2 PI目標
PI目標は「いつまでに誰のために何をつくり何が改善される」のかが明記されていて誰が見ても分かるようにしてチームボードを作成します。 社長が突然見てもボードを見るだけで理解できるような内容にしましょう。
以下にPocochaのPI目標の例を示します。
- 「イテレーション1.3でリスナーが推しライバーの通知に気付けるように、フォローしているライバー毎に配信開始通知をON/OFFできるようにする。」
PI目標の中にいつ、誰に対して何のために何をするのかを含めているのですぐに理解できると思います。 チーム内でPI目標が完成したら、PI期間中に実施される予定のタスクとスケジュールを確認するためのプログラムボードにART全体のPI目標を集約します。 このときに他チームとの依存があれば依存を特定し、別チームと話し合って解決します。 Pocochaでは同じタイミングで進めるとコンフリクトを起こしそうなPI目標があったのですが、順序を入れ替えることで解決しました。
3.3 アンコミットオブジェクティブ
PI目標を作成しているときに、不確定要素が多い場合などの理由からその目標を達成する自信がない場合はアンコミットオブジェクティブとします。 アンコミットオブジェクティブはコミットメントに含まれていないため、 コミットされたオブジェクティブに対する信頼性が向上するので上手く活用していきましょう。
4.ドラフトプランレビュー
プログラムボードのドラフトが完成したら各チームがドラフトプラン、リスク、阻害要因について発表します。 ビジネスオーナーやプログラムチーム、システムアーキテクトがPI目標の達成に向けた計画を確認し、フィードバックを行います。
5.プログラムリスク
ドラフトレビューでチーム内では解決できない、プロジェクトに影響を与える可能性のあるプログラムリスクを特定しそれに対する対策を検討します。 リスクに対する対応方針は「ROAM」フレームワークを用いて整理します。
| 項目 | 意味 |
|---|---|
| Resolved(解決) | チームとしてその問題はすでに懸念事項ではなく解決していると同意できるもの |
| Owned(所有) | すぐに解決できないリスクである場合、後で解決するために所有者を決定する |
| Accepted(受容) | 合理的に対処できないリスクもあるため、 その理由を十分に理解したうえでリスク受容する |
| Mitigated(緩和) | 緩和計画を立て、リスクの可能性や影響を低減させる |
ROAMはそれぞれの単語の頭文字を取ったものです。
6.コンフィデンスボート
リスクへの対応が完了したのちに、チームのPI目標の達成に対する自信度を確認します。 Confidence Voteは5段階で行い、その平均が3以上であればビジネスオーナーやプログラムチームは計画を受け入れるべきであり、2以下のは場合、チームは計画を練り直す必要があります。 Pocochaでは一斉に手を上げて、指の本数で数を表現しました。 写真を見ての通り全員3以上だったので次のPIでやるべきことは決まりました。 これでPIプランニングで必要なアウトプットは全て揃いました。
7.レトロスペクティブ
最後に実施したPIプランニングの振り返りを行いましょう。 レトロスペクティブでは色々な意見が出たのですが特に共感の多かった意見を紹介します。
- オフラインイベントが良かった
- 3ヶ月先までマイルストーンが決まることの安心感
Pocochaで実践して得られた知見・気付き
PIプランニング後にアンケートを実施したのですが、自分達のチームが何を目指していて、2~3ヶ月後プロダクトがどうなるのかを全員で合意を取って進めていけるようになったことに対してポジティブな反応が多かったです。 そして弊社は基本リモートオフィスなのでPIプランニングがチームメンバーとの初対面になる事も多いので顔合わせも出来て、長時間議論もするのでチームワークが高まり仕事がしやすくなったのでオフライン開催は自信を持ってお勧めできます。
さいごに
いかがでしたでしょうか？ PIプランニングについての理解が深まっていれば幸いです。 Pocochaはグローバル化も進み、サービスも組織もスケールしていきます。 次回のPIプランニングではアジャイルチーム数が5つで参加者が60名となる予定で、更に拡大していきます。 この記事に少しでもワクワクしたあなた！ 是非一緒にPocochaで働きましょう！
最後まで読んでいただき、ありがとうございます！
この記事をシェアしていただける方はこちらからお願いします。