短期も長期も両方大事
この文章は、Yves Hanoulle編纂 "Tips from the agile trenches" に寄稿したエッセイ(tips!)を元に、概要を日本語にしたものです。書籍はLeanPubで購入できます。
私がスクラムマスターとして一緒に働いたチームの話です。そこのプロダクトオーナーは、ユーザーの獲得と知名度向上に注力していました。その点では非常に上手くいったのですが、1年も経たないうちに企業合併の影響で製品は破棄され、ブランド名だけ残してビジネスが継続されることになりました。私個人の感想としてですが、目の前に注力しすぎて、将来を形作れなかった事例として印象に残っています。
また別の機会に、半分アジャイルコーチ半分開発者というかたちでスクラムチームに参加しました。開発者はみんな経験豊富なエキスパートで、自動テストはキッチリ、アーキテクチャも十分、コードはソリッドでした。メンテナンス性が将来の成長を支えるカギだと、みんなわかっていました。プロダクトオーナーは情熱に裏打ちされたプロダクトビジョンを持って、優れたユーザーストーリーを生み出していました。約1年後、スポンサーはこのプロジェクトの中止を宣言しました。1年たってもユーザーが10人に満たなかったのが理由のひとつです。開発スピードが遅すぎたとも言えるし、直近の課題に対応しきれなかったとも言えます。いずれにせよ、目の前の人々を満足させられなかったのは間違いありません。
アジャイルは長期的な成功を目指す。チームは現在と未来と両方とも価値を提供しなくてはなりません。未来を作るなら、今を生き延びないといけません。足元をいま整えないと、衰退した未来を迎えることになります。
- チームは動作する機能を現スプリントで実装しなくてはならない
- そのうえ、未来のスプリントのためコードをリファクタリングしておかなくてはならない
とか、
- プロダクトオーナーはステークホルダーを今すぐ満足させられるPBIを選ばなくてはならない
- そのうえ、未来のユーザーを満足させられるPBIを選ばなくてはならない
とか、
- このチームでなくては、現行製品を成功させられない
- そのうえ、このチームでなくては、社運を賭けたイノベーションを任せられない
とか、ある意味ムリゲーな話です。
長期的に勝つための2つの基本的考え方
シンプルさは昔からアジャイルの武器の1つでした。いまある問題を解決できる、もっともシンプルな解法を選ぶ。リファクタリング、機能の変更や削除を通じて、常にその状態を維持する。こうすることで、予期せぬ変更に対して最小の手間で対応できる状態を維持することになります。
もうひとつがビジョンです。計画とプロダクトバックログはビジョンを実現するための(終わりなき)道になります。計画があれば長期的になにをすべきかわかり、今やっている作業の位置づけも明確になります。なにより、今すぐやらないといけないことは何か、それは何故か、明確になります。
計画から始める。計画を変更し続ける。
ウォーターフォールでは計画から始めます。アジャイルでは計画から始めます。違いは計画の取り扱い方にあります。アジャイルでは現実に合わせて計画の方を変更し続けるのです。更新されている計画を見れば、次に何をすべきかはすぐにわかります。
プロダクトバックログが計画のすべてとは限りません。他にもUXリサーチ、技術研究、チーム拡大、ピボット判断、ステークホルダーマネジメントなど、たくさんの計画要素があり、プロダクトバックログには載っていないかもしれません。(プロダクトバックログではなく)計画全体をチームメンバー全員に共有しましょう。計画づくりにはメンバーに参加してもらいましょう。
計画は未来を分割したものではない。未来を実現する計画を作ろう。
将来達成したいビジョンには、誰かがなにかのメリットを享受する、そこに自分のプロダクトやサービスが関わっている、という様子が含まれているはずです。本当に達成したいのは誰かのメリットなのですから、それを実現する方策を考えないといけません。そのための機能をリリースするだけでは足りません。戦略的見地から、順序立ったシナリオを考案しましょう。
プロダクトバックログに載せるのは、完成品の部分だけではありません。ほしい機能をひとつずつ作っていくようなものではないのです。人に使ってもらう状態に到達するには、多様な情報も、使ってもらうための努力も必要です。使うのは誰か、なぜ使うのか、どう使うのか、使いやすいのか、他にいいやり方はないのか……そうした情報の獲得、フィードバックの収集、仮説検証はすべてPBIです。知識はアジャイルが生きるのに必須の栄養素です。知識を増やすように計画しましょう。
今を大切に。 目先に振り回されないように。
今を生き延びなければならない。そのため現在に集中しましょう。致命的になりうるリスクを見つけ、情報を集めて評価しましょう。プロダクト自体から収集できるデータは貴重なので、そのための機能や仕組みは早期に構築しましょう。チームメンバーやステークホルダーも重要な情報源です。
ちょっとしたコツを紹介します。みんなに「明日の天気」を聞いてみるやり方です。晴天快調問題ないと答える人がいるかもしれないし、しばらく向かい風で進捗厳しいですと答えるかもしれないし、中には進路に真っ黒な嵐雲が見えている人がいるかもしれません。アイスブレークでも使える小技です。
私の経験した失敗として、スポンサーが親切で優しいあまり、ビジネスで厳しい判断をする人だと見通せなかったことがあります。ステークホルダーの人々について、どんな危険をもたらしうるか、その人自身の責任や、モチベーション、判断基準などを理解するように努めましょう。
目の前というのは把握しやすく、今やるべきことを見つけやすいので、気持ちを奪われがちです。未来が把握しにくく、やるべきことを見つけにくいからと言って、未来が重要ではないわけではありません。むしろ未来の観点で考えましょう。今やるべきそのタスク、未来へのインパクトはどのくらいか？ 後回しにしたらどうなるでしょうか？ また別の、効果が出るのはずっと先になるけれど未来のインパクトは大きいタスクと比べて、本当に今やるべきはどちらでしょうか。
目先のことでいっぱいいっぱいになっていたら、敢えて時間をとってみんなで一息入れ、目先ではない少し先のことを話してみましょう。
未来への一本道
2種類の麺を鍋でゆでる必要があるとします。短い方の麺は3分でゆで上がり、長い方の麺は10分かかります。どちらを先にゆでますか？ おそらく、長い方を早くゆで始め、7分後に短いほうをゆで始めるはずです。それが計画づくりというものです。ここで、さらにもう1種類の麺をゆでると思ってください。この麺、ゆで時間がわかりません。さて、長い方とわからない方、どちらを先にゆで始めますか？ それはなぜですか？
短期と長期のバランスを取ればいいという話ではありません。いつなにをすべきかという決断の話であり、イコールいつまでに何をデリバーしたいのかという、ビジョン実現の1ステップの話です。価値創造もソフトウェア開発も難しいものです。チームとして、難しい状況に直面し続け、決断し続けていくと、その足跡は過去から現在への一本道になります。実のところ道は未来まで延びているのですが、見ることはできません。次の一歩も、今を大事にしながら、望ましい未来を作る、最善の決断となります。
短期、長期というのは相対的です。次スプリントより来月のほうが長期で、来年はもっと長期です。ことによると何年、何十年にわたり、決断は影響を及ぼすかもしれません。あなたの決断が、長く長く尾を引きながらたくさんの人々に影響していくことを頭に刻みながら、未来を作ってください。
