前談
本記事は エムティーアイ Advent Calendar 2021 の 2日目の記事です。
自分はプロダクトの保守開発チームのリーダー的なポジションにいるわけですが、どうやらその年間リリース計画の立て方に興味を持ってくれた人がいるようです。
なので今回は自分が年間リリース計画を立てるにあたって考えていること(または無意識にやってること)を見直して一度まとめて見る試みで書いてみました。
前提
念のために定義しておくと、自分の言う保守開発とは「既にサービスインして安定しているプロダクトを長期維持するためのメンテナンス」のことを指します。
要するにド安定稼働中のサービスの保守です。
なので新規開発はもちろんまだまだ改修がホットなプロダクトだとこうはいかないだろう、ということもあることは予め理解した上で以降を読んでください。
またここで言うリリース計画は 「1年間」の計画になります。
心得五箇条
心得としては以下の5つ
- 最低限必要な作業を定義する
- チームの体力に合わせてリリースする月を予め決めておく
- 詰め込みすぎない
- 決めた計画はマストではない
- これらを上司に納得してもらう
それっぽく書いてみましたが、内容自体は単純なので一つひとつ掘り下げて書いてみます。
1. 最低限必要な作業を定義する
自分がスケジュールを組み始めて最初にやるのが、「「まずこれだけはやらないとサービスが立ち行かなくなる」タスクを洗い出す」ことです。
例えば自分の場合、Androidなどの新OSへのバージョンアップの影響を調査する「新OS対応」というのは、怠ると機能が死んだりするので「最低限必要な作業」の一つになります。
その他には「使っているプログラミング言語のEndOfLife対応」や「ライブラリの脆弱性対応」も「最低限必要な作業」としています。
これらは対応を怠っていると、ある日突然「脆弱性が見つかった！アップデートして！」と社内が騒ぎ出し地獄が領域展開されます。やったことがある人ならわかりますが、これらはまとめてやろうとすると間違いなく何かしらコケてスケジュールを圧迫してくれます。なので直ちに「やらないとサービスが立ち行かなくなる」わけではないですが、同様に「やらないとサービスが立ち行かなくなる」内容として定義しています。
そして同時に、これらの大まかな〆切や対応時期について意識しておきます。
「新OS対応」なら、新OSが例年リリースされる 9月~10月辺りまでに対応しないといけないので、この辺りにリリースできるように逆算して作業しないとなー、位の意識です。言語のEOL対応なんかはわかりやすく、実際にEOLとなる日付が基本発表されているので、その日がデッドラインとなります。ただライブラリの脆弱性対応についてはしっかりやり始めるときりがないので、自分はこの時点では「年に1回空いているところのどこかで行う」くらいの認識です。
2. チームの体力に合わせてリリースする月を予め決めておく
最低限必要な作業を定義したら、次は1年のうち、どの月にリリースを行うか先に決めてしまいます。
リリース、と一言に言ってもいろんな人が関わり、準備も必要で体力を使う作業です。なので予め「1年間にどれくらいリリースができるか」という体力を考えてみます。例えばチームメンバーがいっぱいいて、毎月リリースしても作業する時間が取れるぜ！なんていうチームであれば毎月リリースを検討してもいいと思いますが、保守開発チームでそれはだいぶ贅沢にメンバーを揃えてくれている環境だと思います。自分なんかにはとても無理なペースなので、大体「四半期に1回」くらいのペースかな、程度に決めています。
またこの時、予めリリースフロー（自分のところでは週単位程度でリリース日から逆算して、この週に結合テスト、この週に性能試験、などと予め決めています）を定めておくと、ペース配分のイメージがしやすいかと思います。
3. 詰め込みすぎない
リリース月を決めたので、〆切から逆算してどの月に何をリリースするかを決めていきます。
例えば自分の場合は四半期に1回、年4回のリリースとなりますが、一つは毎年恒例「新OS対応」で埋まるので、残り3回を「使っている言語のEOL対応」「ライブラリの脆弱性対応」「それ以外のタスク」で詰めていくことになります。
この時考えるのは「詰め込みすぎない」こと。「それ以外のタスク」は保守開発だとバックログに積み上がっているタスクを順次埋めていくことになると思いますが、大事なのは「優先度付け」。
最初の最低限必要な作業でも考えましたが、「やらないとサービスが立ち行かなくなる」は予め先に出してあるはずで、言い換えれば残りのタスクは「無くてもいいもの」なはずです。であれば今年はこれはやる、やらないの取捨選択ができるはずです。
また最低限必要な作業に関しても「ギリギリにリリースしよう」なんて考えないことです。
保守開発は大体において計画されたタスクではなく、突発的なタスクが舞い込みます。「脆弱性見つかった！すぐ対応して！」なんて唐突に言われるとデスマーチが聞こえてくることになります。
予め余裕を持ったリリース月を設定しておけば、「しょうがないから次のリリース月にずらして割り込みを対応しよう」なんてこともできますし、万が一リリース失敗して切り戻し、なんてなっても次のリリースで挽回しよう、と対応する時間ができるので焦ることも（ほとんど）ありません。
フレキシブルにタスクの組み換えができるように「それ以外のタスク」については優先度をつけるに留め、ダメそうなら後回しにしたり切り捨てられるようにしておくと、デスマーチ演奏会は回避しやすくなると思います。
逆にどうしても最低限必要な作業だけでいっぱいになる！あふれる！という場合はチームの基礎体力が足りないことになります。上長あたりにメンバー増員の打診を検討してください（丸投げ）。
4. 決めた計画はマストではない
非常に語弊のある書き方になっていますが、そのままの意味で「年次計画を立てたからそれを必ず遂行しないといけない」と固くなるとストレスが半端ないです。前項でも書いたとおり、突発作業はくるものとして身構えておくことと、詰んだタスクはすぐ動かせる様にしておくことが大事です。もちろん何もなければ計画通りに作業をこなせるように見積もって計画は建てるべきですが。
逆に順調に進んだからバックログから計画より多くタスク消化できた！となると自分もメンバーもおそらく上長もみんなハッピーな気分になれると思います。ハッピーならストレスは（多分）ありません。簡単なことですが、どうしても詰め込んでギッチギチになって胃が痛くなる計画を死ぬ気でこなそうとすると現場の雰囲気は悪くなりやすいので、結構大事かなと思っています。
また「計画を立てた！終わり！」ではなく、四半期に1回程度でも計画を見直して見るのもいいと思います。
タスクの進捗いいからこのバックログも取ろう、前のリリースは突発案件ねじ込まれたから落ちたタスクを残りのどのリリース月ならできるだろう、なんか新しいEOLの情報とか脆弱性の情報来てないよな、などのように情報を最新にしておくことが生き残るコツかと。
5. これらを上司に納得してもらう
結局のところこれが一番大事かと思います。
いくら理想を並べてもそれを承認してもらえないと計画は動きません。
特に「この月まだ行けるんじゃない？」「まだタスク消化できるでしょ」みたいなことを言われることが多いかと思いますが、その時は「バックログから持ってきます」「サボりたくて開けてるんじゃないよ」「準備はしてあるよ」などとアピールできるといいかもしれません。
最後に
文章を書くのは不慣れながら、自分の考えを書き連ねてみました。
こんなに書くの久々だ（´・ω・｀）