効果的なIPMを実践しよう！
こんにちは！
Tanzu Labs by BroadcomでPMを担当しているKenyaです。
今回は、私たちが実践しているプラクティスの１つである”Iteration Planning Meeting（IPM）”についてお話しします。
初めて耳にする方も多いと思いますが、アジャイル開発を経験された方であれば、きっと同じようなアクティビティを習慣化されていたかと思います。
まずは、「IPMってなに？」について、説明していきます。
IPMって、なに？
IPMは、「次のイテレーションで開発してほしいユーザーストーリーについてPMs/Designersから説明し、Devsに機能の価値・内容・優先順位を理解してもらい、ポイント付けをしてもらう定期的な会議」のことです。
LeanXPでは「開発者が何を作るか理解する」のに要件定義書や仕様書ではなく、ユーザーストーリーを用いています。
ユーザーストーリーについて、詳しくは以下のブログをご参照ください。
・優れたユーザーストーリーで、WhyとWhatを表現しよう！書き方編：プロダクトマネージャーの視点
・ユーザーストーリーを使って、デザインの意図をしっかり伝えよう！
伝え方編：プロダクトデザイナーの視点
・ユーザーストーリーを使って、ユーザー価値を素早く実現しよう！
使い方編：ソフトウェアエンジニアの視点
ユーザーストーリーは、プロダクトバックログというカンバン形式のリストの中で、「To Do」「Doing」「Done」がわかるような形で管理されています。
IPMの前に、PMsとDesignersは、次にプロダクトバックログに加えるべき複数のストーリーを用意しておき、IPMの中でDevsと一緒にその内容を確認します。
IPMの中で、Devsはそれぞれのストーリーにポイントをつけ、全員が同じポイントで認識を合わせられるまで話し合います。
これを繰り返して、複数のストーリーにポイントがついたら、PMsは各ストーリーをプロダクトバックログに優先順位順に並べます。全員が認識を合わせた上でこの会議は終わり、Devsはプロダクトバックログの一番上にあるストーリーから開発を始めていきます。
IPMって、なんでやるの？
変化に柔軟に対応する開発を進めていると、チームの優先事項は常に変化します。遠いゴールの達成までに必要な情報（ユーザーストーリー）を、最初から全て用意しても、何か変化が起きた時に、その用意は水の泡になります。
そうかと言って、「どうせ、変わるから。」と用意を怠ると、プロダクトがいつまでにどんな形になるかが、全くわかりません。さらには、少し先すら目指すべき場所がわからず、開発の遅延を招いて目標に素早く辿り着くことは困難になります。
そのため、イテレーション毎にやるべきことを明確にして、少しずつ、かつ素早く、目標を達成する必要があるのです。
ユーザーストーリーにポイント付けをすることで、まず「Devsメンバーの理解に大きなズレがないか？」がわかります。
加えて、そのポイントに基づいて開発を進めると、「このチームがイテレーションの中でどれぐらいのポイントを消化することができるのか？（Velocity）」が、”だいたい”わかります。
すると、「数週間後にはどれぐらいの機能が実装できていそうか？」を、”だいたい”把握することができる訳です。
また、重要なことは、ポイント付けをすることだけではなく、「チームが何を優先して開発すべきなのか？」を確認できることです。
定期的なIPMは、メンバー全員が「チームは今何をすべきか？」を常に確認する機会として、とても重要な場になります。
IPMって、どうやってやるの？
IPMに参加するのは開発を担う全てのメンバー（PMs/Designer/Devs）です。
ただし、Devsに関しては、実際に実装する可能性があるメンバーに限定して、オブザーバーとしてチームに参加しているDevsメンバーがポイント付けに関与しないように気をつけてください。
Tanzu LabsのIPMの流れは、だいたい、以下の図のようになります。
- まず、PM（またはDesigner）から今回追加したい複数のユーザーストーリーについて、大体どのような内容なのか、それぞれのストーリーの関係性がどうか、概要をクイックに説明します。
- 次に、Devsメンバーの中からポイントリーダーとノートテイカーを決めます。ポイントリーダーは、ポイントをつけるに当たって、ファシリテーターとしてメンバーに質問を促したり、ポイント付けの音頭をとります。ノートテイカーは重要な質疑の内容をメモします。
- ストーリーを書いたPM（またはDesginer）から、その詳細な内容を説明します。
- その内容について、ストーリーの”複雑さ”を判断する上で必要な質問を、Devsから書いた人へと質問をします。
- 各Devsメンバーがポイントをつけられる状態になったらポイントリーダーの掛け声の元、Devsメンバーだけで、”せーのっ”でポイントをつけます。ポイントは多くの場合、0〜3ポイントの4段階で”複雑さ”を評価します。フィボナッチ（0, 1, 2, 3, 5, 8）でつけるような方法もありますが、Tanzu Labsでは、シンプルなので0〜3ポイントでつけることが多いです。シンプルであることは非常に重要で、ポイント付けに関わらず、開発のあらゆる場面で大事にしている価値の一つです。（Extreme ProgrammingのValueにも”Simplicity”があります。）
- 各自の点数を確認したら、1人づつその点数をつけた理由を述べます。この時、その理由が技術的で詳細なことまで話す必要はなく、簡潔に伝えることが重要です。
- 全員のポイントが一致するまで、”せーのっ”を繰り返し、同じ点数の認識になればそのストーリーのポイントが決定します。③〜⑦を、予定していた時間が終わるか、または用意していたストーリーに全て点数がつくまで行います。
- 最後に、PMがポイントのついたストーリーを優先順位順にバックログに並べて、全員で「今チームが優先して取り組むべきことは何か？」の認識を合わせて会議を終えます。
IPMは、週に約１回、約１時間の時間を確保して行います。
私の感覚的には、１時間で約１０ユーザーストーリー程度（機能ストーリーが７、デザインストーリーが３ぐらい）に、ポイントをつけることができます。
また、１週間ちょうどがイテレーション期間になることが多いので、毎週月曜日の午前中や、金曜日の午後など、決まった時間に実施するようにしています。
具体的な実施方法や、行う上でのTipsについては、Broadcomが公開している「Tanzu Developer Center by Broadcom」のIPMに関する記事にも詳しく記載されています。
Iteration Planning Meeting（IPM）_Tanzu Developer Center
上記の記事を一度読んでみていただくと、さらによく理解できるかと思います。
「Tanzu Developer Center by Broadcom」には、私たちが日頃から行なっているプラクティスについてわかりやすく紹介した記事がいくつもあります。英語の記事ではありますが、是非、読んでみてください。
・・・
今回は「IPMのWhat/Why/How」を中心にこのブログを作成しました。
今度は、私がPMとして「IPMを円滑に進めるための色々なコツ」についても、またこのブログを通じてお話ししたいと思います。
それでは、また〜👋
