プロダクトの計画を行う為に取り組んでいるコト

計画はなぜ必要なのか？

プロジェクトの初期段階で行う見積もりは精度的にかなりのブレがあります。 プロジェクトの初期段階で行った見積もりには 60%から160%ほどの誤差が生じると言われています。
下の図は見積もりの難しさ、計画づくりの難しさを表したもので「不確実性コーン」と呼ばれています。

見積もりは難しいです。それでも計画や見積もりがなぜ必要なのでしょうか。

まずは会社に属していると会社から見積もりを求められます。
経営者の気持ちを考えれば「いつ開発が終わるかわからないプロダクト」に投資をするのはリスクでしかないですし、アクセルを踏むのかアクセルを抜くのかの意思決定を行うことができません。会社から求められる見積もりは、会社の経営者としてプロダクトの意思決定を支援するような見積もりになっている必要があります。

余談ですが過去の経験から初期段階の見積もりを提出する時は2〜3パターンの見積もりを作っています。不確実性コーンからもわかるように初期段階の見積もりは不確実なことが多く、60%から160%ほどの誤差が生じます。

• めっちゃうまくいったときパターン
• 普通にいけばこれぐらいパターン
• 最悪パターン

プロジェクト初期段階ではこれぐらいの見積もり誤差が生じる可能性がありますと伝えます。

計画に対しての間違った認識

計画に対して、ありがちな間違った認識だなーと思うことがあります。

1. 計画をしたらそれで終わり
2. 計画を見直すタイミングをおかない

計画はあくまで計画で、そのとおりに進むコトのほうが少ないです。
プロダクト開発においては、計画通りにはほぼ進まないコトを前提にした上で、計画を見直すタイミングをあらかじめ決めておき、計画を修正していくコトが大事です。

計画を常にビジネスサイドと共有しておくコトも大事です。開発者だけで進捗を把握しているのは、プロダクト開発においてメリットが無いです。
1ヶ月リリースが遅れるコトが3ヶ月前にわかっているのと、リリースの直前たとえば1週間前にわかるのでは意味が大きく違ってきます。どれだけ事前に把握できるかで、プロダクトやビジネスにおいて取れる選択肢が変わります。経験上、開発者側だけでスケジュールを見ている場合、ギリギリまでなんとかできると思い込んで直前でやっぱ 無理でしたなんてパターンが結構あるのかなと思います。僕自身もそういった経験がないわけではありません。

• 計画を立てるコトは重要だが、見直しを行うコトがより大事
• プロダクト開発は開発者だけではないので、ビジネスサイドと計画を共有していくコトが大事

プロダクトの計画は週次で更新し、週次の定例MTGでビジネスサイドも含めた関係者全員に計画がわかるようにしています。

定例MTGは報告するコトがなくても開催します。「今週は報告するコトがないのでスキップする」は絶対にしないようにしています。これをやるとそのうち形骸化していってしまうコトが自身の経験上多いです。

良い計画とはどんな計画か？

「プロダクトにおける様々な判断をできる計画」が良い計画だと思います。「プロダクトはこの時期には完成するのでいつまでに販売戦略や価格設定を行う必要があるな」と行動に移せるとか、マーケティングやキャンペーンの準備などもそこからわかると更に良いです。

これらの判断するには、いつ頃に何がリリースできるのかわからないと決めれないコトが多いかと思います。

良い計画とは意思決定を支援できる計画です。プロダクト開発の初期段階では、どうしても詳細なリリース日のようなものは出てこないです。はじめは「2022年3Qリリース予定」のような四半期単位くらいでよいかと思います。プロダクト開発が進んでいくにつれて、どんどんと正確なものになってくるので、計画への反映を常に行い、共有していくコトが大事です。四半期単位から月単位、週単位、日単位と明確になっていきます。

• 良い計画とは意思決定を支援できる計画である
• 計画はプロダクト開発を進めていくとどんどん正確になってくる

PLAN-Bではスクラム開発を行っており、プロダクト開発は１週間スプリントで進めています。チェックタイミングをスプリントに合わせることで、計画の見直しを毎週行うようにしています。

良い計画をする為の取り組み

プロダクト開発のはじめから終わりまで状況が変化しないことはありません。あるかもしれませんが僕は出会ったコトがないです。

良い計画を行うためには、一度作って終わりではなく状況の変化を受け入れる準備をしているコトが大切です。PLAN-Bでは複数のプロダクトが並行で数本はしっており、四半期毎にリリース計画を作成しています。リリース計画に上がってくるモノはプロダウトやアウトカムによって様々で、きっちりと決まっている場合もあれば、フワッとしたモノもあります。

どちらにせよ調査や見積もりを行うために、ユーザーストーリーを作成したり、技術調査が必要な場合は調査を実施したりして計画を作成します。それをビジネスサイドと共有し、週次で追いかける仕組みに乗せていくんですが、運用に乗せるコトが難しいことがあります。

できたばかりのチームだとなかなかうまく回りません。社内のアジャイルコーチや他チームのスクラムマスターを呼んでスクラム開発のオンボーディングをしてもらったり、週のふりかえりに加えて四半期に1回はチーム外のメンバーも入れたふりかえりをしたりなどしています。チーム内にスクラムマスター役をおいていますが、他ロールや他チームと兼任になっており、組織の課題だと思っています。 できれば兼任をといていく形でチーム作りをしていきたいです。

• 計画は新たに課題が見つかれば変化するというコトを認識する
• 四半期でリリース計画を行い、スプリントに組み込む (週次で計画をアップデートしていく)
• フワッとした要求・要件などはユーザストーリーとして整理する
• チームでプロダクト開発をしているが、他チームの良いところも取り込む

まとめ

PLAN-Bのプロダクト開発の計画作りについて書きました。大事なポイント以下になるのかなと個人的には思っています。

• はじめに行った計画どおりに進むプロダクト開発はほぼない。変化に対応する計画行うコトが大事
• 計画づくりが重要。計画を作ったあとに定期的に計画を見直すコトが大事

と考えています。より良いプロダクト開発を行うためには良い計画づくりが必要なので今後もブラッシュアップをしていきます。