はじめに
エンジニアが仕事をする中で、切っても切り離せないものの一つに見積もりとスケジュールがあります。
一般的に見積もりに失敗してスケジュールに遅延が発生すると、評価が下がるのではないでしょうか?
しかし、考えてみると見積もりという予測が外れただけで、プロジェクト失敗の烙印を押されてしまっています。
これはとてももったいないことだと常々思っているので、ここではエンジニアやマネージャーとして不確実性を減らすためにできることを説明していき、
世の中の開発環境が少しでも良くなってくれたらと良いと思います。
前提
ここではよくあるパターンとして、既存のサービスと連携する新規のサービスを作ることを想定します。
大まかな流れとして
既存のサービスの調査 → 新規サービスの設計、技術選定 → 見積もり → スケジュール → 開発 → リリース
とします。
本題の通り見積もりとスケジュールで、エンジニアとマネージャーの視点で不確実性を減らすためにできることを考えていきたいと思います。
エンジニア視点の見積もり、スケジュール
新規サービスの設計、技術選定が終わった段階でマネージャーから見積もりとスケジュール(どのくらいで終わるか)を求められるのではないでしょうか。
世の中には不確実性コーンというものがあり、初期段階で正確な見積もりをすることは不可能です。
引用元にある通り、要求も完了していると言い難いので、スケジュールには最大で1.5〜2.0倍の遅延が発生することをマネージャーに伝えましょう。
他に不確実性を減らすためにできることとして、新規サービスにエンジニアとして使ったことがない技術がどれくらいあるかも重要になります。
使ったことがない技術が1つなら、調べながらなんとかなることが多いですが、2つ3つと増えていくとかけ算でどんどん不確実性が増えていきます。
自身やチームのスキルと相談しながら、あまりに使ったことがない技術が多い場合は、減らすことも検討したほうが良いと思います。
マネージャー視点の見積もり、スケジュール
見積もりとスケジュールはエンジニアが出してくれます。
ではマネージャーとしては見積もり、スケジュールに対してどのように不確実性を減らすことができるでしょうか。
1つは人のアサインです。先程のエンジニア視点でもあったとおり、使ったことがない技術が多い場合、それだけ不確実性が増えていきます。
もしもチームにその技術を使ったことがある人がいればそれだけ不確実性を減らすことができます。
逆に一番やってはいけないことは1人1プロジェクトを割り当てることです。
新規サービスを作る場合、インフラからアプリケーション、CI/CD、監視、運用と考えなくてはならないことが多いです。
全部できるよと言うエンジニアはいるかもしれませんが、本当に高いレベルで全部できる人はほとんどいないのではないでしょうか。
動くレベルが作れる人と今後の運用も考えて開発できる人とではアウトプットに雲泥の差があります。
直近は良いかもしれませんが、今後の開発速度の鈍化に大きく影響しますので、チームでカバーすることをおすすめします。
開発時にお互いに協力できること
スケジュールは一度引いたら終わりではありません。日々変化するものです。
ここでは開発時によく起こる事象からお互いに協力できることを考えていきます。
一つは見積もりとコミットメントの認識をそろえることです。
見積もりと言っても人によって見積もりの認識が違います。
見積もりをコミットメントだと考えている人もいれば、見積もりを予測だと考えている人もいます。
先程の不確実性コーンにある通り、長期の見積もり(1ヶ月以上)を確実に終わらせられる保証はありません。
ただ、1週間のタスク、更に小さく一つのタスクだけをコミットメントすることはかなりの確率で終わらせることができるのではないでしょうか。
コミットメントを約束できれば、確実にプロジェクトが進んでいることが保証できるので、それを積み上げていくことでおおよそのプロジェクトの終了時期が見えてきます。
他によくある例として、エンジニアがスケジュール通りに終わらなそうだと思っても放置をしてしまうことがあります。
これはスケジュール通りに終わらないと評価が下がるので、言い出しづらかったり、別に良いかと諦めてしまっているためです。
放置は一番悪いことです。早めに報告することによって、人をアサインすることもできるし、スケジュールを遅らせることもできるし、機能を削ることによって、期日に間に合わせることもできます。
まとめ
エンジニアやマネージャーとして不確実性を減らすためにできることについて解説をしました。
開発をするにあたり、考えなければならないことは不確実性を減らすことだけではありません。
属人性の排除やアウトプットの最大化、プロダクトの課題の特定などです。
このような内容を色々考慮にいれて開発をすることが大変なため、最近はフレームワークとしてスクラムが流行っています。
スクラムでは1sprintを1週間で行ったり、チームで開発することによって極力不確実性を減らすようになっています。
Webアプリケーションを作成するのにも1から全てを作るのではなく、ほとんどの人が考えることを減らすためにフレームワークを使っていると思います。
ぜひ、導入を検討してみてはいかがでしょうか。