（アジャイル開発）プランニング会議とリファインメント会議の違いをストーリー形式で説明してみる

きっかけ

アジャイルチームの支援をしていると、プランニングとリファインメントの違いが分からないという相談を受けることが良くあります。両会議の目的や内容が理解しやすいように、ストーリー仕立てで説明してみることにしました。
※同じようなことを既に実践されており、かつ私の例より分かりやすく書かれている方も多いのではと思いますが、自分の言葉で記載することで頭の整理もできればいいなと思い、残すこととします

あらすじ

むかしむかしある所にプロジェクトマネージャがいました。
当然、プロジェクトを成功させたいので、一生懸命要件を詰めて、詳細な見積もり情報を根拠に計画を立てました。
しかし、残念ながらプロジェクトは失敗してしまいました。
成功したいがあまり、要求が増大し、大規模になったプロジェクトは見積もりと実体の乖離が大きく、計画時に想定できなかった問題や変化が沢山発生し、予定通りにいかなかったのです。
プロジェクトは炎上し、製造とは関係のない仕事が増え、要員は疲弊し、責任の押し付け合いが始まり、高スキル技能者から順番に離任していってしまいます。
結局プロジェクトは中止せざるを得なくなりました。
どうしてこうなってしまったのか…プロジェクトマネージャーは考察してみました。

考察

。ο 〇
何が問題だったのだろうか・・・
色々な問題があると思ったが、一番は計画の問題な気がしていた。

まず考えたのが、計画との乖離（≒遅延）が生まれた時にもっとうまくキャッチアップできなかったかだ。
先のプロジェクトでは、計画通りに進んでいることがプロジェクトが順調であることを示す唯一の手段であった。そのため、計画遅延には対策を打たなくてはならない。実際に、人を増やしたり、新しいルールを作るといった対処をしたが、余計に混乱を生んだり、引継ぎなどの新たなコミュニケーションコストを生む結果に繋がり、大した成果にはつながらなかった。ブルックス先生が「人月の神話」において「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである」と述べていたが、まさにその通りのことが起きた。そもそもの計画の作り直しでもできない限り、つまり品質か予算か納期かスコープを変更できない限り、遅延対処は困難であるような気がした。

次に考えたのが、計画の精度をもっと上げることだ。
先のプロジェクトでは、計画段階で沢山時間をかけて見積もりを行った。
ドメイン知識やシステム知識が豊富な有識者も呼んだ。それなのに計画通りにプロジェクトは進まなかった。ここまで力を入れたのに、何故精度が上がらなかったのだろう。
思い出してみると、思ったよりも実装が大変だった、思ったよりコミュニケーションの時間が必要だった、思ったより技術検証には時間が掛からなかった、思った以上に若手が早く成長した、体調不良などにより思ったより稼働時間が確保できなかった、思ったより要件に効果がなく変更する必要があった、といったような現象は、良いことも悪いこともしょっちゅう起きていた。
これはすなわち、現場では計画から乖離する圧力が常に発生しているということだ。これが計画の達成を難しくする一番の要因だった。つまり、当初見越すことのできなかった「不確実性」と言われる要素によって、計画の達成が困難になっていたのである。
不確実性を無視してプロジェクトを突っ込むのは、地雷原を素足でダッシュするのと一緒で、それがどんな結末になるかは今回身に染みて分かった。
計画とは、ある時点で未来を予想したスナップショットであり、予知能力者でもない限り、不確実性を排除することはできない。これは計画に内包される不都合な真実だった。

ふむ。では不確実性を排除することはできないとしても、可能な限り小さくすることはできないだろうか？
そこで１つ思いついたのは、不確実性を制御できるレベルまで計画を小さくしたらいいのではないだろうか、ということだ。例えば１週間や２週間単位で計画を作るのはどうだろう。
プロジェクト期間が１年だったとしても、１～２週間レベルの計画を何回も繰り返すことによって、目標とする価値実現に近づいていこうという考え方だ。
計画を小さくすることができれば、現実的に達成しやすい計画が作りやすいし、プロジェクト期間中に計画づくりを何度も行うことになるから、今までの経験から得られた知見を次の計画に活かすことによって、精度も徐々に向上していくことが期待できそうである。

これは是非やってみよう。この短いスパンの開発を何回も繰り返すことから、１つ１つの開発期間をイテレーションを呼ぼう。

ただ、そうなると１～２週間より先がどうなる見込みなのかが見えないことがネックになる。
いくらなんでも１～２週間先までしか見通しができないというのは、ステークホルダーとの調整や、ユーザの準備面等で問題があるし、今後のビジョンも見えづらいからプロダクト開発自体が露頭に迷う可能性もある。対処が必要だ。

これは簡単な話だった。１～２週間より先についても見通しを立てればいいのだ。ただ、取扱は注意しなくてはならない。精度を高めることを目的の１つとして計画スコープを短くしたのに、不確実性が多分に含まれる長期間の見通しに対しても「達成にコミットする」ようなことをしてしまうと、先の失敗プロジェクトの二の舞だ。「今のままプロジェクトが進むとこうなりそう」という期待値とし、その期待値は、プロジェクトの最新動向に基づき、常に最新化をしよう。この長期スパンの計画を全体計画やリリース計画と呼ぶのがしっくりくる。

そもそも、プロジェクトの目的は価値の実現であり、計画の達成ではないはずだ。プロジェクトを進めている間に価値実現に寄与する情報が得られたら、その情報を活用して、計画を適応することは理にかなっていると思う。短いスパンの計画は達成に確約する、それより先のスパンの計画は目安とする。これを関係者と合意できるかがミソだ。

でもそうなると、イテレーションと全体の２種類の計画を継続して作り続ける必要があるな。

イテレーションの計画は、各イテレーションの冒頭に立てれば良いな。確実に達成を続けていくことで、ステークホルダーからの信頼を勝ち取りたい。なのである程度精緻な計画を作りたい。だから、開発対象の要求事項が達成したいビジネス価値のイメージをチームで共有したり、その要求事項を実現するために必要なタスクを全て洗い出して、それがイテレーション内に収まるかチームで判断する時間にしよう。

次に全体計画はどうしよう。イテレーション計画づくりの場は、達成に確約する計画の作成に集中したいし、そもそも計画に求める粒度や期待値も全体計画とは異なるから、混同を避けるためには一緒にはしたくない。
なので全体計画には別の場を使うことにしよう。
そもそも全体計画を作成する場における議題を考えると、大体次のような内容にたどり着きそうだ。

• 現チームの進捗スピードの確認（イテレーション毎にどれだけの要求をこなせるか）

• 要求事項リストの最新化（要求事項の追加・削除・変更、優先順位の再設定）

• 要求事項の見積もり

全体計画策定の場にプランニングという名前を付けても良いけど、この会議で本来達成したいことを改めて良く考えてみると、価値実現に向けた長い目での見通しを立てることにある。なのでプランニングというより、価値実現のスタート地点である要求リストの最新化をすることに主眼を置いて、「リファインメント」と名付けよう。
この場なら、見通しを立てるための見積もり情報も要求リスト最新化のための情報の１つであるという意識が持ちやすいし、見積もりに確約をするわけではないという意識も同様に持ちやすい。その見積もり情報をもってそもそものバックログの順序の入れ替えなどを行えるから、常に価値実現にフォーカスしてプロジェクトに適用できる。会議として一石二鳥だ。

リファインメント会議の本質は要求リストの最新化であって、見積もりではない。つまり見積もり作業だけで会議を終わらせるわけにはいかない。短時間で見積もりをする必要があるが、それには「規模の要素」と「期間の要素」が含まれている「時間」の概念で見積もりするのではなく、規模か期間かどちらかにだけ着目して見積もりすることでスピードアップが狙えそうだ。規模の見積もりなら、要求リスト毎の大きさを相対的に比較することによって導出できそうだ。規模の大きさを示す指標は何でもいいが、TシャツサイズのようにS,M,Lだったり、単位のない数字の羅列（例えばフィボナッチ数列）を使うことにしよう。

見積り情報が揃えば、今までの開発実績（イテレーション毎の平均or中央開発量）をベースに、例えば一か月先や半年先の到達目安が見える。これが分かれば、ビジネス上の調整は進められそうだ。

これならいけるのではないか？

まとめ

プランニング

• イテレーション計画を作成する

• イテレーション初日に行う

• 計画達成に確約する

• 要求事項の達成目標を確認・共有する

• 細かくタスク分解する（粒度は半日程度が良い。不確実性を下げるためや、問題を見える化するため）

• 実際に達成できるか否かを判断するために、タスク分解をした後に見積もり情報を最新化したりする

リファインメント

• 要求事項リストを最新化する

• イテレーションの中日などに継続的に実施する

• 要求を確認する際に、合わせて見積もりも行う

• 見積りは１要求５分などを目安にサクサク行う

• 見積りは相対見積もりを意識するとスピードと精度を生みやすい

リファインメントの会話イメージ

※これが正解！というわけではなく、こんな話がされることもあるよね、くらいの一例と受け取っていただければ幸いです。

PO 「今考えている新要求α の説明をするよー。かくかくじかじかの理由でこんな状況を達成したいのさー」
DEV 「ふむふむ。という事は現状、ユーザさんはこういう所で困っているわけね。POさんがイメージしている状況を達成するには、こんな機能を用意すればいいかなー」
PO　｢そうそう、そんな感じ。問題が解決できるなら手段にはこだわらないよー」
DEV「イメージつきました。ではDEVの皆さん見積もりしてみましょうか」
DEV「この間全員で対応した要求Aを基準に大きさを出してみるとやり易そうだね。皆よろしく」
DEV「結果でました。見積もりは５ポイントだね」
PO　｢思ったより小さいね。じゃあちょっと優先順位上げようかな。大体このへん－」
DEV「おｋ」
PO　｢じゃあ次、要求βも話すねー。（省略）こんな状況を達成したいのさー」
DEV「やりたいことは分かったけど実装が難しいかも。DB構成に変更が入りそうだね」
DEV「確かに。しかも性能を意識すると新しいインデックスはらないとダメそうだけど、他のSQLの影響が気になる」
DEV「あれ、あのTBL使ってるSQLってどれくらいあったっけ。ソースみてみないと分からないから探すか‥」
DEV「ちょい待ち。この要求は実際にいつやるかまだ分からんし、今精査したり詳細設計した内容がそのまま使えるかなんて分からんよ。何より見積もり作業に必死になりすぎて、肝心の要求を掘り下げる話する時間が無くなるから今はある程度TBL構成を弄る前提くらいの見積もりでいいんじゃない？」
PO 「その通り。詳細化はもっと時期が近づいてからでいいし、最終的な確約は今じゃなくてイテレーションプランニングの場でお願いね」
DEV「確かに。じゃ見積もりしましょー」
DEV「3,5,5,5,8」
DEV「ちょっとずれたね。僕は機能Ｂの開発をした時にTBL構成弄りつつ対応した事例があったので、あれを参考にポイントだしましたー。」
DEV「なるほどーもう一回やりましょ」
DEV「5,5,5,5,8」
DEV「私は８出しましたが、皆さんの意見も理解できるので、この場は５で大丈夫です」
DEV「8に寄せるでもいいけど、今回は5にしましょうか。では次いきましょー」
PO 「私から持ってきた新ネタは以上です。DEVの皆さんからも何かご意見ないですか？」
DEV「そういえば、私たちも最近このシステムを使っていて、このあたりのユーザインタフェースが不便だなと思うのでこんな感じで改善したいんですよね。あと、良く更新が入る機能Ｚのソースが汚れてきてしまったので、こちらのリファクタリングもしたいです。見積もりした結果、ポイントはそれぞれ３と５です」
PO「なるほど、提案ありがとう。機能Ｚの機能拡張はこれからも入る予定だから、リファクタリングは早めにやっておいた方が良さそうだね。詳細な時期は調整するけど、優先順位は高めに設定すると思います」
DEV「よろ」
全員「全体通して追加確認事項はなさそうなので、今日のリファインメントはここまでー。まだ次回ね」

Fin