はじめに
開発が見積もり通りにいかずスケジュールが遅延してしまうことってありますよね。
見積もり自体とても難しいものですが、私がエンジニア→PMを経験する中で見積もりに関する学びがあったのでそれをシェアしたいと思います。
まず、スケジュールを決める上で必要な要素の説明をしたあとに、
プロジェクトでよくあった遅延してしまう原因とそれを防ぐためのチェックポイントを3つ紹介したいと思います。
前置き：スケジュールを決める上で必要な要素
「この機能の仕様はxxです。いつまでにリリースできそうですか？」
と言われた時に、あなたならまず何から考えますか？
色々と考えることはあるかと思いますが、スケジュールで考えるべき要素は大きく分けると2つです。
それは「稼働時間」と「作業工数」です。
見積もりというと、作業工数を出すイメージがあるかもしれませんが、
実際スケジュールを見積もる際には自身の稼働時間を把握することも非常に重要です。
スケジュールが遅延する原因
原因を因数分解すると、以下のようになります。
これ以外にも細かく要素を分けることは出来ますが、今回は私が見てきたよくある事例としてまとめています。
この原因を元に、チェックポイントを3つ提示します。
チェックポイント
1. 稼働時間が正しく計算出来ているか？
リリースが遅延した際にチームで振り返った時に、
「思ったより開発に時間が取れなかった」という意見がよく出ます。
どれだけ精緻に見積もっても、実際に開発に入れる「稼働時間」がなければ
タスクを終えることはできません。
なので、「自分が作業に集中出来る時間が何時間あるのか？」を計算することが重要です。
例えば、1日7時間会社で働く時間があるとして実際に作業に集中出来る時間は何時間あるでしょうか。
スケジュール表を見返してみると、開発に入れない時間は意外と多いかと思います。
・定期MTG
・突発的なMTG
・仕様相談
・質問や相談を受け答え
・レビュー
・テスト
・雑談
...etc
このあたりが1日どの程度あるのか？から稼働時間を計算すると思ったより開発出来る時間は少ないことが多いです。
また、人間の集中力は2時間が限度だと言われている上に、集中している中で割り込みが入ると続いていた集中力も落ちてしまいます。
違う作業を平行してやればコンテキストスイッチが発生します。
そうなると、ただでさえ稼働時間がない中で集中して作業が出来る時間はさらに短くなります。
集中力自体人によっていろんなタイプがあるので、自身が業務の中でどれだけ集中する時間を取れているか？を一度測ると、
その時間が見えるので自身の食える作業がより明確になります。
稼働時間の計算作業をしておくとプロジェクトマネージャーやリーダーに、
「開発する時間が増やさないと間に合わない。そのためには、このMTGやこのタスクを減らしたいので相談したい」
など、自身からアラートをあげることも出来ます。
チーム開発であれば、チームとして無駄な時間はないか、助け合える部分がないかを検討する良い機会になるので、
そのような状態であればぜひ一度相談してみるとチームのためにもなると思います。
2. 見積もりすべきタスクに漏れがないか？
作業工数が見積もり通り行かない原因として、
「想定していなかったタスクが発生した」パターンと「想定していたよりタスクが重かった」パターンがあります。
「想定していなかったタスク」をさらに分解すると、
- 事前にわかるはずだったが抜け漏れていたもの
- 事前にはわからないもの
があります。
1は開発プロセスや仕様把握漏れ、設計漏れなどタスク自体の漏れ、2はバグやエラーから起因するものです。
(※原因分解の図ではではわかりやすいように「タスクの漏れ」と「バグやエラー」にしています）
タスク自体の漏れについては、事前に防ぐことができます。
事前に防ぐ手段1: 開発プロセスを言語化する
チームによってプロセスは違うと思いますが、ざっくり一例を出します。
・仕様把握
・見積もり
・設計
・設計レビュー
・設計レビュー修正
・実装
・レビュー
・レビュー修正
・テスト準備
・テスト
・リリース作業
このように分解した上で、それぞれ何時間ほど掛かるのか、
レビューにおいても相手にしてもらう必要があるため、相手のスキルや忙しさによって待ち時間も含め工数が変わってきます。
ここは自分1人で開発していないのであれば、相手の工数も踏まえて考慮に入れておくべきです。
まずこの段階で必要なプロセスが漏れているとその時点で遅延が発生してしまうので、
しっかり開発する上で何が必要か？を抜け漏れないようにしましょう。
もし仮に抜け漏れが発生し、作業工数が増える場合はすぐにアラートを挙げましょう。
早めの検知ができることで、リカバーできるようにチームとして動くことができます。
事前に防ぐ手段2: 実装タスクを限りなく細分化する
タスク管理をする上で実装部分をどこまで分けるかは人それぞれな部分ですが、
もし見積もり通りに行かないのであれば、限りなく細分化することをまずやってみることをお勧めします。
「限りなく」とは、そのタスクを見た時にコードが思い浮かぶレベルまで落とせると良いと思います。
例えば、
「ユーザーから1~10の範囲の数値を入力させ、その値に10を掛けた数を画面に表示する」
ものを作るとした時に、
1. ユーザーに入力させるためのテキストフィールドを作る
2. 1~10の範囲だったときに弾く処理を入れる
3. 入力値に10をかける処理を書く
4. 画面に表示させるViewを生成する
5. 値を画面に表示する
のような形です。
簡単な例だとここまでやらなくても見積れるかと思いますが、複雑なものになればなるほど
この作業をすることで事前に難しいポイントやわからないポイントも明確に出来ます。
このコンポーネントを使って、こういう関数を書けば作れるな というところまでイメージ出来ると、
見積もり精度はぐっとあがると思うので、細分化をおすすめします。
新卒の方やWeb経験者が初めてアプリを作るときなど、この分解自体難しいことも多々あるかと思いますが、
チームメンバーと一緒に設計とタスクの分解をすると認識も揃いつつ見積もり精度もあげることができるので良いかと思います。
3. 見積もりが楽観的過ぎないか？
作業工数が見積もり通り行かない原因として、
「想定していなかったタスクが発生した」パターンと「想定していたよりタスクが重かった」パターンがあります。
「想定していなかったタスク」をさらに分解すると、
1. 事前にわかるはずだったが抜け漏れていたもの
2. 事前にはわからないもの
があります。
と書いたかと思いますが、
「想定していたより重かった」パターンと、「想定していなかったタスクで、事前にわからなかったもの」パターンは、
基本的に見積もることは不可能です。
なので、素直に見積りを出すと「何もエラーもバグも起きず、タスクも想定通りの難易度でxx日です」ということになります。
普段開発していれば、そんな奇跡的な状況は・・・。なかなか無いですよね。
ただでさえ不確実性が高いプロダクト開発において、この見積もりだけで進むのは危険なので、
「PERT」を使って見積もりを出すと良いです。
PERTについてはすでにたくさん記事があるのでぜひ読んで見てほしいのですが、
ざっくり説明すると、
「悲観値」:最良の状態で進んだ場合
「標準値」:一般的な場合
「悲観値」:最悪の状態で進んだ場合
の3つで見積もり工数を出し
（楽観値+4×標準値+悲観値)/6 で計算する手法
になります。
以下の記事に具体例などがありますので、参考にしてみてください。
https://liginc.co.jp/web/useful/51382
さいごに
見積もりの精度はエンジニア個人としての信頼に繋がります。
また個人の信頼だけてなく、プロダクト視点においても計画的なリリースや適切なリソース配分がしやすくなることで
プロダクト全体へも良い影響を与えます。
最初から見積もり精度が高い人はいないので、
・自分がどう見積もったのか
・それに対してどういう結果だったのか
・結果に対してさらによくするにはどうすればいいか
をしっかり振り返り、内省して改善していくプロセスを繰り返すことで、
見積もり精度を高めていくことができます。
今回紹介した以外にも遅延の理由は組織観点やプロジェクト観点からもあるかと思いますが、
開発のタスクに絞ってご紹介致しました。
他にもこんな遅延理由があって、こんな対処しているよ！などあればぜひご教授頂きたいです。