生粋の国内企業勤務なのだがいっとき非日本語話者な上司の下で働いたことがある。まあそれは何かの間違いだったきすらする。しかし国内有名IT企業をハシゴしたというその上司が、超ご機嫌に教えてくれたアジャイルソフトウェア開発の教科書的動画がある。多分めちゃくちゃ良い動画。
その後最近、動画を改めて覗いたら日本語サブタイトルが付いていた！ なので、サマリしつつの彼からの私の学びを共有しておきたい。という代物...
Agile product ownership in a nutshell
概要
プロダクトオーナーの視点からアジャイルソフトウェア開発を見てみるというもの。
引用: https://www.dropbox.com/s/ph3spbc3evgoh3m/PO-in-a-nutshell.png
動画を見進めると、以上の図が完成する。
全文は以下
要点のみ
ストーリー
-
パットという女性が「プロダクトオーナー」として役割を果たすストーリー。
-
ステークホルダーは、開発中のシステムを使用したりサポートしたり、また何らかの形でシステムの影響を受ける人たちである。パットとコミュニケーションを取る。
- ステークホルダーのニーズはユーザーストーリーとして表現される。
-
システムをビルドするのが、開発チーム。
- アジャイルのチームなので、最終的に大々的なリリースを行うまで延々と作業を続けたりすることはない。短期間でのリリースを繰り返す。
- ペースを維持し、そして手動のリグレッションテストによる作業の停滞を起こさないために、チームはテストの自動化と定期的な統合作業を行う。
問題
-
問題は、なんでもかんでも求めるステークホルダーが多いこと。もし私たちが彼らの要求をすべて叶えようとするとどうなるか？オーバーフローする。プロダクトオーナーの仕事は、この世に存在し得るすべてのストーリーの中から次にどの4～6件を作成するかを決めることだ。
- 例えばかんばん方式とは仕掛品の数を制限することである。例えば負荷がかかり過ぎない状態で全員が作業をしている状態を維持するちょうどよい量として、チームが同時に作業するストーリーの最適数を5件と定める。スクラムではこれをプロダクトバックログと呼ぶ。
-
**待ち行列が収拾がつかない状態にならないようにする方法は1つしかない、ノーと言うことである。**これはプロダクトオーナーにとって最も重要な言葉。プロダクトオーナーにとって最も重要な仕事は、ビルドしない要件を決め、その判断の結果に責任を持つことである。
-
プロダクトオーナーは作業するものとしないものを決定する。そして今ビルドするものと後でビルドするものといった作業の順番も決定する。これは難しい仕事だし、チームやステークホルダーと協力して行う必要がある。
- ユーザーストーリーの評価とサイズはパットが合理的に優先順位を判断するために役立つ。
- しかしちょっと待て。彼女はどうやってストーリーの評価を把握するのだろう？そしてどのようにサイズを把握するのか？ バッドニュース。彼女は把握していません。これは推測ゲームなのだ。
-
**パットはステークホルダーの価値観を知るために定期的に彼らと対話する。**彼女はチームが実装作業の観点から何を重視して何を瑣末なものと考えるのかを知るため対話する。これらは相対的な推測であり、絶対的数値ではない。私にはこのリンゴやあのイチゴの重さはわからない。
- しかしりんごの方が少なくとも5倍は重いことや、いちごの方がおいしい（私にとって）ことは間違いないと思う。パットがバックログの優先順位をつけるために知る必要があるのはこれだけ！素晴らしい。
もちろん推測は簡単ではない
- 新しいプロジェクトが始まったばかりの時点では私たちの推測はまったくひどい。**でも大丈夫。一番大切なことは実際の数値よりも実は対話にある。**そしてチームが現実のユーザーに何かを納品するたびに、私たちは何かを学んで評価とサイズの双方を推測する力が向上する。このために私たちは継続して優先順位をつけて予想を立てるのだ。
- 最初からすべてを正しく行おうとするのはとても愚か。私たちはほとんど何も知らない。フィードバックの繰り返しである。
- パットは毎週水曜日の11:00～12:00にバックロググルーミングワークショップを開催している。たいていチームの全員が参加しますが、時々ステークホルダーも数人参加します。議題は様々で、予測、ストーリーの分割、そしてストーリーの受け入れ基準の作成についてなど。
コミュニケーション！
-
プロダクトオーナーシップの要はつまりコミュニケーションなのだ。経験豊富なプロダクトオーナーに成功の秘訣を聞くと、彼らは総じて情熱とコミュニケーションを強調する。アジャイルマニフェストの最初の原則に「Individuals and Interactions over Processes and Tools（プロセスやツールよりも個人と対話の方が大切である）」 があるのは偶然ではない。
-
**パットやチームが決定するべきトレードオフは多数ある。**異なるタイプの評価の間でトレードオフが発生する。プロジェクトの初期には不確実性とリスクが私たちの障害となる。
- 私たちがビルドしているのが適切なものかというビジネスリスクもある。チームメンバーがビルドできるのかという社会的リスクがある。実行ターゲットのプラットフォームで動作するか、スケールするかという技術的リスクがある。また、妥当な期間と金額でプロダクトを完成させられるかというコストとスケジュールのリスクもある。
- 価値とは、知識の価値＋顧客価値を意味する。そして私たちはこの2つの間のトレードオフを決める必要がある。火消しと防火のバランスを絶えず調整する必要がある。
- スピードを重視することは大切だ。なぜならフィードバックのサイクルが短ければそれだけ学習が早まり、何が適切なのか、そしてどのように要件を適切にビルドするかをより早く理解できるからだ。しかしすべてが大切なこと。常にバランスを意識するようにする。
- 最後に、新プロダクトの開発と既存プロダクトの改善の間のトレードオフがある。プロダクトバックログは紛らわしい用語だ。この言葉はプロダクトが1つしか存在しないことを暗示する。プロジェクトも紛らわしい用語だ。なぜならプロダクトの開発が「終了する」ことを暗示するからだ。しかしいずれも1つのプロダクトは決して「完成」することはなく、プロダクトがその寿命を終えて運用停止するまで常にメンテナンスと改善を必要とする。
- プロダクトオーナーは定期的にこれらの項目間のトレードオフを決める必要がある。
要望の管理
-
プロダクトオーナーとしてパットは要望の管理も担当する！現実的な要望の管理である。これは嘘をつかないということだ。これは大変なことだ。私はアジャイルが簡単であるとは言っていない。
- 要望の管理。大切なのは、予測に希望的観測ではなく経験的なデータを使うことだ。そして彼女が確信のないことに関して正直であることだ。あなたの会社が事実と公正さを好まないのであれば、アジャイルを好まないともいえる。
- 注意としてチームが技術的負債（Technical debt）を積み重ねていけば、つまりテストを記述したり定期的にアーキテクチャを改善したりしなければ、時間が経つにつれて作業速度はだんだん低下して、ストーリーのバーンアップ曲線は横ばいになる。そうなれば予測がほぼ不可能になる。チームは持続可能なペースを維持する必要があり、パットは彼らにプレッシャーをかけて近道をさせるようなことを避けなければならない。
まとめると
-
作業量管理、ステークホルダーとのコミュニケーション、ノーと言えるプロダクトオーナー、バックロググルーミングが必要である。
- 作業速度は全アウトプットの合計であり、予測に使用することができる。もしチームごとに個別の予測をする方が理にかなっているなら、そうしても良い。
- しかし、複数のチームで作業をする状況では、プロジェクトオーナーの担当に重要な仕事が加わる。お互いに話し合うということ。チームとバックログは依存関係を最小にするように構成するべきである。
まとめ
上司はその後、腰を痛めたりなんやかんやでチームを離れてしまった...
きっとこういう不確実性に対処するのが大事なのだろう、プロダクトオーナー的には。
オフィスにハロウィンの飾り付けをしたりチーム用の給湯器を置いてくれたり愉快な方だったのだが、おっと、本筋と離れるのでこのへんで。
以上参考になればさいわいです。