プロダクト開発をはじめてから、その後の状況の把握と、方向づけをどのように行っていくのか？ 従来のプロジェクトマネジメントではフィットしないとは感じつつも、それに代替するすべがなかなか見つからないという課題感を持っている人もいると思います。今回は、プロダクト開発に適したマネジメントを整理してみます。
マネジメントの何が課題となるか
多くの場合、特別な事情がなければプロダクト開発自体はスクラムで進めていることでしょう。スクラムに則った場合、スプリント単位での状況把握、方向づけがリズムよく行えるようになります。
一方で、中長期の視点に立ったときにどういう状態を目指すのか、それをいつ頃達成できると望ましいのかについては、自分たちで工夫する必要があります（なお前者のどういう状態を目指すのか？についてはスクラムガイド2020で提示されている「プロダクトゴール」が合致します）。
ビジネスとしての期待を背負ってプロダクト作りを進められている以上、その中長期的ゴールの時期的な期待というのは、明確にあるいはぼんやりとでもあるものです。
プロダクト開発の初期の段階ほど「時期の見立てなどできない」として、そうした期待には応えようがないと感じることもあるでしょう。しかし、初期段階としてはかなり曖昧なところにあるとしても、プロダクト作りを進める中で段々とプロダクトの輪郭、充足できそうな期待感というのが見えてくるはずです。ですから、「期待」のマネジメントとしては時間的変化を追いかけていく必要があるわけです。
なお、期待と言うと、他者（経営やステークホルダー）からの要請に基づくものと捉えられてしまうかもしれません。期待は他者からだけではなく、プロダクトチーム自身として有していて然るべきです。「自分たちの作るプロダクトの状態として何を目指し、それをいつ頃ユーザーに届けるのか」にチームとしての意思がなければ、何となく曖昧なまま進み、なかなか結果には辿り着けないでしょう。
こうした期待を捉えるために、「スケジュールを引く」というのは、従来型のプロジェクトマネジメントでは至極当然の取り組みと言えます。スクラムで運営しながら、一方で全体管理にはスケジュールを使う。違和感を覚えるところですが、自分たちの状況をメタ的に捉える（期待の経時変化を定期的に捉えて、それに基づくおおまかな方向性を可視化する）ためには、一つの方法と言えます。
と言いつつ、やはり課題となるのは、「スケジュール」では現実の状況、動きと乖離がしやすく、管理が追いつかないという点です。また、プロダクト作りのためのスケジュールは「変更する前提」としながらも、一度方向性を可視化すると、その内容に引きづられるところもあります。まだ検証が終わっていないのに、遠いゴールに忖度して、ラフに機能開発を進めてしまうなどです。やはり、別のマネジメント手段があれば望ましいと言えます。
プロダクトブイによるステートの捕捉
スケジュールのような固定された時間の概念でマネジメントができないとしたら、何に着目するべきでしょうか。見るべきは「ステート」です。ステートとしては「プロダクトの状態」と「取り巻く状況」の2つがあります。
プロダクトの状態
- 長期的なビジョンに対するプロダクトの現在位置
- プロダクトで実現できている機能、またその検証状況
- 技術的負債、その他の課題・リスクなど
取り巻く状況
- プロダクトに寄せられるステークホルダーからの期待
- 組織の方針やビジネスの醸成
- 対象ユーザーについての状況変化
- プロダクトチーム自身のコンディションなど
「取り巻く状況」にはチームのコンディションも含めています。つまり、自分たち自身も見るべきステートに含まれるということです。特に、このメタ的な状況認知を見るべきものに含めるのが重要です。
さて、問題はこのステートが変化していくことを追っていく必要があるという点です。「そろそろ確認しておこうか」という、曖昧な運用では何らかの時機を逸していても気づくことができません。ステートを確認するタイミング自体をマネジメントの対象とする必要があります。
この定点はこれもまた従来のプロジェクトマネジメントでいうと「マイルストーン」ということになります。マイルストーンとは目標地点のことを言います。もともとは、道路上で距離の間隔を掴むために置かれた標石のことです。プロジェクト上でのマイルストーンは、期待する目標を期待するタイミングで通過できるかということを確認するために置かれます。
やはり、目標自体が揺れ動く可能性のあるプロダクト作りにおいては、マイルストーンは固定的すぎると言えます。イメージとしては海に浮かべるブイ（浮標）のほうが近いでしょう。目標自体が揺れ動くものの、全くのノーコントロールで、漂流させてしまうものではない。
具体的には、ある程度のタイムボックスで「ステートを確認する」という意味をもたせたタイミングを設けましょう。プロダクト作りを進める上でブイに到達したらステートを確認し、状態と状況の変化を認識できるようにする。踏まえて、次のブイに向かうまでの活動内容や優先度をチームであわせるわけです。このタイミングのことを「プロダクト・ブイ」と呼称することとします。
プロダクト・ブイ
- ステートを確認するタイムボックスは1ヶ月～2ヶ月程度
（長すぎると時機を逸すことになり、短すぎるとオーバーヘッドになる） - 確認の対象は「プロダクトの状態」と「取り巻く状況」であり、前回ブイでの確認内容からの変化を把握する
- 不明なステートがあれば（例えば関係者からの期待など）、内容を取りに行く
- ステートを評価し、次のブイに向けての課題やリスク、その優先度を話し合う
- 以上をチームで行う
こうした確認を実際にはスプリントプランニングで行ったり、ふりかえりやむきなおりの中で行うこともあるでしょう。各イベントでフォローできていればそれに越したことはありません。ただ、メタ的な状況把握というのは、人があまり得意としない動き方だと私は見ています。あらかじめ、ブイを浮かべておくことを考えてみるのも良いでしょう。
