リリース遅延しなくなる！実践的開発スケジューリング方法

2020年7月9日仕事スケジューリング, 見積もり

対象

本記事の対象者

新人や若手のwebエンジニア　とくに自社サービスや準委任契約などの開発見積もりが契約内容に直結しない働き方をしている人にフィットしやすいです

本記事を読むことで解決できる課題

本記事を読むことで下記の課題が解決できます。

• いつもリリースのスケジュールをリスケしてしまい、周りに迷惑をかけてしまう
• スケジューリング下手が原因で開発がギリギリになり、品質やプロセスに問題を抱えている

上記の課題はwebエンジニアとして働くと必ず当たる壁だと思います。

経験を積んだエンジニアは、上記の課題をそこまで意識しなくなってくると思います。しかし、はじめての開発内容だったり、開発規模が大きくなってきた場合に、気を付けないとすぐに同じ問題にぶつかりかねません。

そうならないようには、できるだけ言語化して意識しておくのが重要です。

スケジュール遅延が起こる主な原因

スケジュールずれの発生する主な原因は下記の2つです。

• 見積もり精度の低さ
• 想定外の事実の出現

それぞれ説明してきます。

見積もり精度の低さ

開発経験が浅いうちは、実装を2人日で見積ったものの、いざ実装してみると詰まって4人日程度かかることがよくあります。

最初のうちは見積り精度の低さから、スケジュール遅延することが多々あります。しかし、見積もりは過去の経験やデータを元に考えるものなので、何度も開発案件をこなしていればそれに比例して精度が高まっていき、この原因で悩むことは減っていきます。

想定外の事実の出現

案件では見積もり時には予測できなかった課題が後ほど判明・発生しがちです。

たとえば下記のトラブルはよくありますよね？

• サーバー間の穴あけ作業を見落とす
• 知らないバッチが出てくる

想定外の事実の出現は開発経験を積んでいけばある程度は予測できますが、開発案件に時間の制約がある以上完全に回避するのは難しいです。

さらにこの原因のやっかいな点はいつ出現するのかが読めないところにあります。開発の後半でインパクトの大きい問題が発生した場合は、見積りがずれるのはもう避けられません。その場合はいかに傷口を広げないようにするのかという動きをするしかありません。

スケジューリング遅延の具体的な対応策

原因が分かったところで、それぞれの課題に対して対応策を打ちましょう。

私がwebエンジニアになってから今までで、実際に試してよかったスケジューリング遅延対策を紹介します。

見積もり精度の低さに対する対応策

周りに見積もり・スケジューリング自体のレビューをしてもらう

自分の見積もり精度が低いのであれば、周りの人を利用しましょう。

最初は自分が出した見積もりと先輩や上司に手直しされた見積もりの差分が大きいと思いますが、案件数を重ねるうちに差分がなくなってきます。

差分がみられなくなった頃には、見積もり精度の低さで悩むことはなくなっているでしょう。

各フェーズの進捗が遅延したら、すぐに周りに相談する

開発案件では開発手法問わず、設計/実装/テストといったフェーズがありますが、各フェーズで予定よりも遅延が発生したらすぐに周りに共有しましょう。

以下のように進めるとスムーズにいくかと思います。

• スケジューリングのずれと、可能であればその挽回プランを考えて周りに共有
• 周りと相談しながら挽回プランを決定する

見積もり精度が低いうちは当然挽回プランの見積もりもずれがちなうえに、スケジュール遅延を早く取り戻したい気持ちで焦っています。周りの冷静な目で一度、挽回プランを見てもらったほうが無難です。

たとえば案件が始まる前に、先輩エンジニアや上司と遅延したときにどのように共有・相談するか決めておくと協力を得やすいでしょう。

予想外な事実に対する対応策

懸念点はなるべく早く調査する

当然ですが、見積もりやスケジュールに影響を与える可能性が高いところは、調査ができる状態になり次第、できるだけ早く調査するべきです。

不確実な点を調査して、例え不都合な事実が出てきたとしても、不確実な点を後回しにしたまま案件を進めるよりは全然マシです。

たとえば早い段階で根本的見直しの必要性が判明すれば、かけた時間が短いため、傷が浅く済みます。しかし、案件後半では時間をかけてしまっているので、他の案件参加者やステークホルダーは当然不満に思うはずです。

見積もりとスケジュールは別のものとして考える

もしも見積もりの結果、明日から10人日でリリースできそうだからぴったり2週間（10営業日）後にリリース日を設定する。というやり方だと何かあったときに必ずリリース日をずらさなくてはいけなくなります。

見積もりで出した作業が完了したらすぐにリリースしないといけないように考えがちですが、必ずしもそうではないはずです。

バッファーを見積もりに含めるかどうかは置かれた状況などによりますが、少なくともバッファーが置けるなら2,3日は置いたほうが無難です。

前提が変わったら見積もりをすぐに作り直す

見積もりは調査フェーズで一度作ったら、もう作らないと思いがちですが、当然前提が変わったら見積もり修正も必要です。

見積もり時はわからなかったこと、予期することができないことはたくさんあるので、見積もりに影響を与えかねない新しい事実が分かれば、すぐに見積もりを見直しましょう。

その結果たいしてスケジュールに影響を及ぼさなさそうであればラッキーだし、影響が出る場合であっても、早めにステークホルダーへ連絡できるため、いいこと尽くしです。

その他の対応策

もしも延期せざるを得ないのであれば、絶対に出せる日付を提示する

それでもリリース日を延期しないといけないときがあります。そのときは絶対にリリースできる日を提示するべきです。

何度もリスケをするとそのたびに案件のステークホルダーは予定を調整しなくてはいけなくなります。今後あなたが出したリリース日を信じてもらえなくなってしまわないように、少し遅く感じても必ず出せるリリース日を提示しましょう。

おわりに

ここまででスケジュール遅延に対応する方法を伝えてきました。webエンジニアを職業として続けている人にとっては全然目新しいことはない、いたって当たり前な話だと思います。

しかし、意外と現場ではスケジューリングの話はちゃんと教えてもらえないので、駆け出しエンジニアがそれを学ぶには経験頼りになりがちかなと感じています。

そういう人たちが次の開発案件からさっそくこの記事の内容を役立ててくれると嬉しいです。