こんにちは。藤井 @yoshiyoshifujii です。
来る 2022/10/07(金) Chatwork が主催するオンラインカンファレンス『Chatwork Product Day 2022』が開催されます 🎉
カンファレンスまで、あと10日です。ふるってご参加いただけますと幸いです。
今回、私が投稿するのは、過去に投稿いたしました以下の記事の続編となります。
当記事では、プロダクトオーナーを最近、どうやってるの？ってあたりを紹介したいと思います。
- 戦略的ゴールと中間ゴール
- プロダクトバックログ(エピックレベル)の運用
- プロダクトバックログ(ストーリーレベル)の運用
- スプリントバックログの運用
- プロダクトバックログの運用(イニシアティブレベル)の運用
- まとめ
戦略的ゴールと中間ゴール
EBM Guide - エビデンスベースドマネジメント に基づいて Chatwork のリライトプロジェクトにアプローチしています。
EBM Guide によりますと、
- 戦略的ゴール
- 組織が達成したいと考えている重要なものである。
- このゴールは⼤きく遠く、その道のりには多くの不確実性がある。
- よって組織は経験主義を⽤いなければならない。
- 戦略的ゴールは、⾮常に⾼い⽬標であり、その道のりは不確実であるため、組織は、⼀連の実⽤的なターゲットを必要とする。
- 例えば、以下の中間ゴールを利⽤する。
- 中間ゴール
- 達成することで、戦略的ゴールに向けて組織が進捗していることを⽰すものである。
- 中間ゴールまでの道のりは、まだ不確実なことも多いが、完全にわからないわけではない。
- 即時戦術ゴール
- ひとつのチームまたは複数のチームによるグループが中間ゴールに向けて取り組む重要な短期⽬標である。
- 開始の状態
- 取り組みを開始する時点での戦略的ゴールに対する組織の状態を指す。
- 現在の状態
- 現在時点での戦略的ゴールに対する組織の状態を指す。
といったモデルがあり、
戦略的ゴールに向かって前進するために、組織は実験を⾏う。こうした実験には、現在の中間 ゴールに向かうための仮説を作成することも含まれる。これらの実験を⾏い、結果を収集しな がら、得られたエビデンスを⽤いてゴールを評価し、ゴールに向かって進むための次のステッ プを決定する。
といったアプローチを取ると書かれています。
図で表すと以下。
こういった考え方を取り入れて、現在は、以下のような戦略的ゴールと中間ゴールを設定しております。
戦略的ゴール
「2025年の事業計画に合わせて、生産性を維持・向上できるプロダクトと組織が構築できている」
※ Chatworkのリライトプロジェクトをやっている - Chatwork Creator's Note で記載していた内容と同じです
中間ゴール
「1つのコンテキストについてサブシステムができている」
※ 抽象的に書いています。実際は具体的です。
この戦略的ゴールを達成できているかどうかを計測する指標については、 EBMの4つの重要価値領域 を考えに取り入れて、 アウトカム を計測します。
即時戦術ゴールや、中間ゴールを達成したときに、戦略的ゴールの アウトカム がどう変化したかを計測することで、ゴールに近付いているかを判断していきます。
リライトプロジェクトという特性上、アウトカムの計測が困難(全部終わらないと計測できない、途中で達成しても値が変わらない)なところもありますので、先行指標を置いて仮説・実験・検査・適応を回していきます。
活動によって作成されたアウトプットが出来ていくことだけでなく、それが戦略的ゴールに対するアウトカムに反映されているのかを確認することにトライしていきたいと考えています。(まだできていない)
中間ゴールの達成のタイミングでは、アウトカムを計測できるようにしておきたいなぁ…とぼんやり思っています。
いまのところですが、戦略的ゴールのアウトカムを計測する指標として、ここはやはり、 Four Keys になるかなぁと考えております。
とはいえ、リライト前と後で、 Four Keys がどう変化したか、単純に比較して見ていいものかどうか、このあたりの取り扱いがどうかなぁと。
チームの構造もガラっと変わることを想定しており単純な比較でやったーと言うて良いものかどうか、認識を合わせる必要があると考えています。
このあたりは、近々、整理していく予定です。
プロダクトバックログ(エピックレベル)の運用
アウトカムの計測方法が未定なまま進めているのですが、とはいえ、リライトですので、今あるプロダクトを置き換えるということで、アウトプットをしていくことは可能なのです。
ということで、現行のシステムを分析したうえで、エピックレベルのプロダクトバックログを作成してスクラムチームを運営しています。
バックログの作成や見積り、エピックやストーリーの使い分けについては、以前、 スコープとスケジュールを継続して計画する方法 - Chatwork Creator's Note で書きました。
今回は、エピックアイテムの運用方法について書きます。
エピックのライフサイクルを出来るだけ短くする
スコープとスケジュールを継続して計画する方法 - Chatwork Creator's Note で紹介した手法を用いて換算して全体を見積り、バーンアップチャートを書いてスプリントを継続していくと、全然終わらないエピックアイテムに出会うことがありました。
なぜ終わらないのかというと、
- 換算していたエピックをストーリーに分解して実際に取り組むと足りない要素が見つかりエピックに紐付くタスクが増える
といったことが起こっており、それがどんどん膨らんでエピックが終わらない状態になっていました。
ここでエピック、ストーリー、タスクの使い分けですが、 エピック、ストーリー、テーマ、そしてイニシアティブ | Atlassian を参考にしております。
かつ、ストーリーとタスクについては、ストーリーについては What寄りのもの 、タスクは How寄りのもの といったざっくりとした使い分けをしています。
つまり、エピックを考えてストーリーに分解して実装を進めていくと、当初想定できていなかったHowからのフィードバックが出てきます。そのフィードバックがストーリーの想定範囲内に収まらなかったとき、それをタスクとして切ってリファインメントに回していくことになります。
そのタスクを元のエピックに紐付けていくと、概算の見積りとストーリーレベルで精緻に見積もったものと差分が出るようになり、全体の見積りがなんだか曖昧なものになっていくのです。
そこで、対策として、そういった後から増えたタスク関係は、別のエピックとして管理するようにしました。
エピックの名称は何でもいいから、とにかく、元のエピックの見積りは変えないで新しいエピックとして管理します。
一度、精緻な見積りをした見積り済みのエピックはイミュータブルに扱うぞ、といった感じです。
すると、エピックはどんどん終わるし、新しいエピックは増えるんだけどそのエピック自体の着手についても大きなレベルで優先順位を考えられるようになるし、精緻な見積りをした後にブレるようなことが無いので全体の見積りがボヤけることもないしで、とても管理しやすくなりました。
このあたりは、エピックを換算して運用することで全体像を早く見れる利点を得られる変わりに、精緻さが失われてあとどれぐらいで終わるのかの着地点がボヤけてくるという弊害に対策できている、という感じになります。
ですので、私の運用方法においての対策となり、なかなか伝わり辛いかなーと書きながら思ってます。
もちろん、タスクが増えることやそのサイズが小さくなるようなこともなく、結局はやらないといけないことに変わりはないのです。
ですが、全体の見え方、見せ方として、エピックを小さく運用することで、進んでいる感が醸成されて区切って進んでいるなーと実感することができるのです。
プロダクトバックログ(ストーリーレベル)の運用
エピックレベルのPBLについては、プロダクトオーナーがステークホルダーと対話する際に話しやすい粒度で運用をしています。
ストーリーレベルのPBLについては、スクラムチームと対話する際に話しやすい粒度で運用をしています。
リファインメントでは、エピックに基づいて大体、こんなストーリーが必要だろうとPOが想定して準備をしておきます。
エピックについてチームで対話した後、ストーリーを1つずつ確認していきます。
リファインメントは、プランニングレディな状態にストーリーを持っていくことを目的としています。
プランニングレディな状態とは、
- 完了条件が明確になっていること
- 見積りができていること
の2つを満たしていることとしています。
なので、リファインメントでは、ストーリーを1つ取り上げては、これを完了している状態ってどういう状態ですかねーといったことからチームで話しをしていきます。
様々な視座から議論がされたうえで、完了条件を自然言語で記述します。
その内容に合意が得らた時点で、相対見積りをします。
相対見積りは、完全に一致するところまでせず、連続する3つの数値の範囲に収まっておれば、平均を取って終了します。
そうやってプランニングレディな状態になったストーリーを、プランニングの場で再度、議論します。
プランニングレディとしましたがそこから状況が変わっていることは何か、それによって完了条件は変わっていないか、見積りは変わっていないか、変わっているとしたら再度リファインメントが必要だが、この場でその差分を吸収できるならぱっとやってしまいますし、無理そうなら次のリファインメントの場に見送ります。
スプリントバックログの運用
プランニングによって、ストーリーレベルのバックログのどれに取り組むのか決定した後、プランニング第2部に入ります。
ここでは、ストーリーを見て、さらにサブタスクに分解していくことで開発者が運用しやすい粒度に変えることで、スプリント全体で具体的にどう動いていくかの認識をそろえていきます。
ストーリーレベルで考えていたら行けそうだと思っていても、詳細に検討してみると認識がズレていることが見つかったりします。
一度、限られた時間内の机上の議論で詳細レベルまで落とし込んだ議論をすることで、解像度を上げます。
そのうえで、スプリントに収まりそうだと判断ができれば、そこからスプリントゴールの言語化をします。
スプリントゴールは、プランニングの前から、大体こーゆー感じかなーというのをプロダクトオーナーとしては持っています。
ですが、それを開発者が咀嚼する前に先に出すのではなく、自分の役割の範囲においてこのスプリントをどう過ごすのか、どこまで行くのか、ぼんやりと認識できてから言語化することで、共通認識の度合いが上がると考えています。
イメージとしては、限られた時間において、トップダウンから限りなく底まで机上でいってみて、ボトムアップでスプリントゴールを一緒に作る、という感じです。
プロダクトバックログの運用(イニシアティブレベル)の運用
エピックよりさらに荒い粒度でイニシアティブレベルを置いてます。
経営層とクオーターに1回進捗を確認し合う会があり、そこでの対話につかうレベルを意識しています。
サイズ感としては、大きくてもクオーター(3ヶ月)で終わるぐらいの粒度としています。
戦略的にスコープと時期感を見て、リソースを先んじて調整していくための指標に使っています。
まとめ
- 2021年4月からプロダクトオーナーをやって1年半が経ったよ
- その間にいろいろあったよ
- ゴールの運用に EBM を取り入れようとしているよ
- プロダクトバックログの運用にいろいろと工夫しているよ
- イニシアティブ、エピック、ストーリー(タスク)、サブタスクのレベルわけでいろんな人と対話しているよ
といったことを書けたかなーと思います。
Chatworkのリライトプロジェクトも盛り上がってきておりまして、詳しいお話を聞いたうえでジョインしたいよーって方を大募集しております。
カジュアル面談にご興味にある方はぜひ以下のリンクをポチっていただければ幸いでございます。
