シン・スケジュール制約がある開発で気をつけたいポイント

こんにちは。人事労務領域のSaaSのPMをやっているhiroki_mです。
以前、「スケジュール制約がある開発における進め方のポイント」というnoteを書きました。あれから2年近くがたったので、
あらためて「シン・スケジュール制約がある開発で気をつけたいポイント」という題でnoteを書いてみます。
なお、このnoteはアジャイルに開発を進めていることと、継続するチーム・プロダクトで開発をしていることを前提としています。

1.機能レベルでコミットしない

機能レベルでやることをコミットするのはなるべくやめましょう。（なるべくと書いたのは、止むに止まれぬ事情で機能レベルのコミットが必要という状況もありえるためです。）
コミットするのであれば「目指すべき状態」をコミットするべきです。プロダクトビジョンとミッション、与えられたスケジュールとリソースを踏まえ、目指すべき状態を言語化しましょう。
定量的な目標を置くのであれば、実現可能性があるのかどうかを検証するためのアクションを行ってみたいところです。無理なら頑張るしかない。

2.不確実性についての認識をステークホルダーと合わせる

完璧な計画なんて立てようが無いことを皆が認識する必要があります。ステークホルダーと以下の認識を揃えましょう。

• 予測は外れる、外部要因によって計画は崩れる

• 事実があるから予測ができる

• 予測の精度は経験によって積み重ねた事実によってあがる

3.ざっくりとした計画を立てる

プロジェクトの初期で立てる計画は不確実であることを認識した上で、計画を立てましょう。得たい状態を実現するためにやることについて、重要度が高いものからざっくりとボリューム感を見積もり、優先度をつけます※。
現時点でのベロシティからみての到達点の予測をし、認識をステークホルダーと合わせます。コミットはしないこと。

※相対的な見積もりの基準を見つけるために何度かスプリントを回したいところ。

4.進捗とチームの状況を透明化する

重要なポイントです。スプリントごとに生み出した価値と、チームの状況についてしっかりとステークホルダーに伝えていきましょう。チームの状況とは、ベロシティや得た学びなどです。この手の話、プロダクト開発に直接関わる人以外は興味が無いと思われがちですが、毎週共有していると結構自然言語化していくものです。
ここをおろそかにすると、計画を見直す際に無駄なカロリーを多く使うことになります。しっかりやっていきましょう。

5.計画の見直しを透明化する

これも重要なポイントです。ベロシティが変わるのに伴い、計画も見直していきます。見直した計画についてステークホルダーと合意を取っていきましょう。4で書いたことがうまくできていると、5でハレーションが起きることはそんなに無いです。
プロジェクトの期間や大きさによりますが、計画は先々まで決めすぎない方が良いです。
7ヶ月の開発の場合、3ヶ月先までのやることの見通しを立てる。位が感覚的には動きやすかった感じです。

6.形を崩すのは最終手段。だけど一時的には壊すのもアリ

どんなにきれいごとをならべても、スケジュールの直前になって「止むに止まれぬ事態」が発生することは往々にしてあります。
急に降って沸いたやらざるを得ないことを目の前にした時に、一時的にでもスクラムのルーティンを壊してどうにかなるのであれば、それも選択肢に入れて良いと思います。
私のいるチームの例ですが、1週間だけプランニング、レトロスペクティブ、リファインメントを一切やらず、ステークホルダーとのMTGも全て無しにして、せざるを得ない開発をやり切ったことがあります。
状況に応じて、チームで合意した上で形を壊すのはありです。しかし、壊すのが当たり前になると、結果オーライが横行して学習するチームに戻れなくなるので最終手段として捉えておいた方が良いです。

以上、スケジュール制約がある開発で気をつけたいポイントについてざっくりまとめてみました。つまるところ、不確実性をみんなで許容していこうぜ、そのための透明性をしっかり担保していこうぜということです。
なおこのnoteに関連する書籍として、エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリングがとてもおすすめです。

Meetyをやっているのでよろしければ質問などどうぞ。
また、SmartHR社ではPMを募集中です。ご興味がある方ぜひご応募をー