ぼっちエンジニアになる前までは、５年くらいフィールドマネージャとしてメンバ管理もしていました。

スケジュール遅延と見積もりについて書きます。
運用・機能追加のフェーズではアジャイル的に回していくと思いますが、締め切りは出さないといけないことが多々なので、そんな時です。

スケジュールは絶対的なもの

守りましょう。死ぬ一歩手前まで頑張ってでも。

見積もりを立てた後に案件がスタートしているにも関わらずスケジュール通りに終わらない！

よくあります。
遅れるのは問題なかったり、ボリュームを調整すればなんとか。最悪でも人を入れる。でもなんとか。
割となんとかなるので、なんとかなった場合はスケジュールが遅れたわけではなく、最適な解決を見出せた。ということになります。

問題なのは理由なき遅延です。

なにもせずに放置して、期限が来てしまったものは最悪です。死ぬ手前まで頑張って辻褄を合わせましょう。本来そうならない為に、やるべきことをやってないので、仕方なしです。
周りからしても、「えっ、今言うそれ。あと1週間なのに、2ヵ月分も残っているのw」となります。開発メンバとのコミュニケーションが足りてなかったせいや、開発へのヒアリング不足もあるでしょうが。他人ごとではなく自分事としてエンジニアサイドから発信・調整をしていきましょう。

締め切りに意味がない(意味があるのは商品ロンチに合わせたり、イベント施策で会期が決まっている。など、リリース日に重要な意味がある)場合は、積極的にリスケの相談をしていきましょう。
意味があるリリース日は、案件の目的やゴール（達成したいこと)を理解した上で、ボリュームの調整をしましょう。

見積もりとスケジュール

見積もり項目として、

事前検証
要件定義
設計
開発
検証
環境構築
リリース

は絶対に入れた方が良いです。入れる必要が無くとも項目としてはテンプレ的に検討を必ずします。
技術的にわからない部分が大きい場合は見積もるために検証や調査を行なった上で算出すべきです。

見積もりが乖離してしまうと、スケジュールは遅れます。
可能であれば、見積もる時はできるだけタスクに落とし込みます。整理・明確化することでより精度が上がっていきます。

また、開発内部では見積もり通りの工数で出しておき、開発の外に工数を伝える時は最低でもx1.2しましょう。稼働8割の見積もりになります。
これは、１週間の稼働が5日として、大体稼働が 4人日/週の計算になります。1日潰れてもなんとかなるかな。という算段になります。
毎日２時間MTGをしたら、そうなります。こうして出来上がったものが工数になります。

スケジュールに落とす際に、開発以外の要因を追加します。

要件定義にかかる時間
デザインにかかる時間
機材調達にかかる時間
確認や承認にかかる時間

など。

さらに、まだある未知なるものに対応すべく、バッファを積みましょう。
これは全体を20%した結果を目安にして、5日、10日、1ヵ月、3ヵ月と見比べます。あまりに数値が大きい場合は、ここまでバッファが必要かをよく考え、20%した結果よりも少なめにできそうなら気持ち少なくして、よくわからないことが多いから増える！という場合は、事前に潰して20%になるように努力します。
スケジュール上、バッファと書くか、各工程にこっそりバッファを入れるか、最後にどかっととるか。見え方が良いように調整しますが、自分の好みは最後にどかっと、全体バッファをのせます。(バッファがスケジュール上に入っているとそれを当てにしてしまったり、遅延が見えなくなってしまうので、最後に載せます)

そしてリスク要因(技術難易度、人の相性、個人スキル)を洗い出し、加算してから、人数での稼働見積もりを出します。
人数での稼働見積もりは実際に開発に当てられる時間を計算します。

1人: 多少のリスクはありますが、仕様理解・設計・開発ともに、1人で完結するのでちゃんとした人ならそのままスケジュールに落とします
〜5人: ちょうどいい人数ですが、コミュニケーションロスがあるので 20%加算
それ以上: もはや、多いのでユニットに分けて、20%加算した上にバッファを30%で見積もり直します

これでようやくスケジュールをが引けます。
かなり膨れたスケジュールになり、目を見開く人もいますが、膨れたスケジュールより早く終われば良し。ですし、スケジュール通りだったらそれも良しです。
ただ、遅れてはダメなので、ここで引いたスケジュールが承認されない場合はボリュームを調整するか人を追加しましょう。

ちなみに、3人でやると、

(工数)

開発見積もり: 1人月
x1.2した見積もり: 1.2人月
人数加算: 1.5人月

で、30人日になります。(10人日増えた！)

(スケジュール≒かかる日数)

0.5ヵ月 (1.5/3=10日)
バッファ 0.1ヵ月 (2日だけど最小は5日)

となって、スケジュール的には15日かかることになります。

ここで開発マネージャが追うべきスケジュールは、バッファなしのものになります。
また、余裕を見ている(はずの)スケジュールになるので、開発の出した工数に近づけることを目指して進行していきます。

遅延の各種要因と対応

スケジュールが遅れる要因について考えます。
大体、これらのケースに当てはまるはずです。

基本、というか、

ウルトラCを見つける
ボリューム調整
スケジュール調整
リソース追加

くらいしかやれることがないです。

ウルトラCはやり方を変える。考え方を変える。で、それまでやるしかない。と思っていたことが見方を変えたら、実装が少なく済んだとか、やろうと思っていた機能実装が、フルコーディングじゃなくてちょうどいいライブラリを見つけた！というやつですが、稀ですね。ほぼそんなケースはないです。

外的要因

基本、心に余裕を持ちましょう。
外的要因の場合はむしろチャンスです。

外的要因で遅れそうなことが見込まれる場合は、スケジュールを先に伸ばしておきましょう。
(外的要因の場合、見込みで入れるのは大変だったりしますが)

どんどん企画が膨れ上がって、あれもやりたい！これもやりたい！となって、収集がつかなくなる時。

ビジネス的にもユーザメリット的にその要件がやるべきと共感できたなら、リスケをしましょう。
そう思わなければ、ロンチ後に回すか、ボリュームを小さくするか、そもそもなかったことにしちゃいましょう。

やる場合、3日で終わるな。と直感的に思っても、チャンスなので 10日くらいの見積もりで出してスケジュールを伸ばしましょう。
お願いされる方の立場になるので、大きく出やすいです。取り下げてきたら、それはそれで良しです。

早く終わったら、「やり方を工夫したら、すぐ終わりました」とだけいって、残った日数をバッファか、遅れを取り戻す為に当てましょう。
伝えた通り10日くらいかかったら、心の中でよかった。と呟きます。

差し込みが多い

もはやエンジニアの責任ではないですね。
それが過去に担当エンジニアが作ったものに対するバグ改修の依頼でも、会社の体制の問題です。

差込なので今やっている作業が止まります。
口を酸っぱく周りに伝えて、一方のスケジュールを伸ばしましょう。
ちっちゃいタスクが細切れにある場合は、管理・整理しやすいですがざっくりと進行しているような場合(自分がこのスタイル)は、差込が来ると別なやつが思いの外、遅れますが、なるべく正確に見積もって見積もり通り終わらせるように努めましょう。

もし、2〜3日残業して影響が少なくなるのであれば、その期間は少し頑張りましょう。
その姿は周りが見ていますし、スケジュールを伸ばし便りも早く終わったらバッファとかにあてられます。

そもそも残業しまくっているよ！みたいな時は、まずタスクを細分化して作業を整理し明確にしましょう。
細分化する時間を無駄とは言わずに、やるべきです。整理していない状況でそうなっているので、やり方を変えないと同じ状況が続いていきます。
もはや、それでも無理と悟った場合は、整理した結果を元に周りにヘルプを出すかリスケや調整しましょう。頑張りとかの問題ではありません。
理由や相手がボリューム理解していないと調整しにくいのですが、整理されていれば調整しやすいです。

開発にはいれない

待っても待っても、資料が来ないことがあります。
MTGの時間を無理やりとってでも、積極的にヒアリングをしましょう。要件・仕様はそこでまとめてしまえば良いのです。
余計っぽい時間がかりますが、一緒にまとめた分、理解が深まりドキュメントを読み込む時間が減ります。

デザインが来ない時もあります。
先に構成だけ同意をとって、作れるところから作っていきましょう。その際、60%くらいの完成度を目指して作っていきます。
どうせ、デザインが上がったタイミングで別なものが出てきます。半分くらい別物になりますが、コードはコピペできたり、少し改修すれば大丈夫だったりします。

もはやもうやることがない。ときや、自分の範疇(機材が来ないとか、クライアントの承認待ちとか)を超えた待ち時間は自由時間です。
もちろん、待っている分は遅れることを了承してもらい、あとは自己研鑽に当てましょう。ラッキータイムです。
仕事中何しても大丈夫でしょうが、周りを見たらヒィヒィ言っているチームがあるかもしれません。その時は積極的に助けてあげてください。
同じチーム内でタスクを持っている人がいたら、まだ自由時間はきていないのでチーム内のヘルプに入りましょう。

自己要因

はじめてがいっぱい

チャレンジは全体の30%くらいに収めましょう。

実は年を重ねると初めてやることが減ります。
これまでやってきたものでなんとかなるのがほとんどだったり、過去の案件の流用ができるようになります。
そんなエンジニアはすでにうまくやっていると思いますが、それでもチャレンジは抑えていきましょう。

アーキテクチャを変える: 1０％くらい
ライブラリを変える: 10%くらい
開発言語を変える: 30%くらい
新規プラットフォーム: 30%くらい
難易度が高そうで、初めて触る技術要素（AIとか): ５0%くらい

見積もりにいれて大丈夫なので事前の検証は行なってください。
やりたいことが出来ることを確認出来き、異常系まで確認できるのがベストなのですが、そこまで手が回らない場合はやりたいことが出来るところまでは必ず確認してください。
これができていないと、後々スケジュール遅延や残業の多さに跳ね返ってきます。

思いの外やることがたくさん

積もり積もってやることがたくさんある場合です。最悪のやつです。
気付いた時点で、タスクを整理しましょう。絶望的な気持ちに負けず、まずは整理して現状を把握することです。
リソースをやりくりしても終わらない場合は、調整しかありません。
自分だと、上から順に試しますが、「残業して頑張る」はその時のメンバやチーム状況にもよります。

ボリュームを落とす
残業して頑張る
スケジュールを伸ばす
リソースを追加する

解決できなそうな壁にぶつかった

環境依存など正しく動かない場合

ハードウェア依存とか、端末依存は、時間をかけて取り組む。というよりも、一旦スケジュール優先にしましょう。
正しく動かない対象をチェックできる方法(XXXのメーカだとダメとか)を探して、正しく動かないとプログラム的に判定できる場合は、代替手段をとってください。
機能の導線を消す。ペライチの画像でごまかす。ケースバイケースですが、これ系は探るとハマりやすく、スケジュールに大きく影響します。

スキル的な問題

それがコア機能でどうしても回避できない場合は、諦めるとそこで案件自体が頓挫してしまいそうなので、担当を変えましょう。
それでもダメな場合は、どこまでできるかを見極め、機能の調整をしましょう。
自分みたいにぼっちの場合は、死ぬ気でやりましょう。なんとか見えるものですし、泥臭く頑張るしかないです。

まったく新しく誰もやっていない！といものは、先にあたりをつけてから受けましょう。
無理っぽいなー。やっぱ無理だったかー。と半年くらいかけた後に言われてもドンびくだけです。

やむなしですが、スケジュール的に余裕がある場合はどこかで辻褄を合わせるように動きましょう。
余裕がない場合は早めの共有が必要です。

外部ライブラリのバグ

自分が一番嫌いなやつです。
回避方法をなんとか探すしかないですが、２つ平行させられれば、平行させましょう。

回避・根本解決を探る人
別ライブラリに置き換える方法を探る人

どうしても解決できない場合は、仕様を調整するしかないので残りの日数と見比べて調整するかどうかを決めましょう。
ただし、調整にも「何ができるか」を把握していないと調整ができないので、そこは把握できるように努めましょう。

そうは言ってもどうにもならないこともあるんですけどね