締切ないのはすごいなあ。私の仕事は締切があることが多々あって、そのための見積もりもよくやっている。
自社が持っているわけではないオープンソースソフトウェア、例えば containerd とかで締切が決めにくいというのは、確かに一理あって、そこに関しては細かい締切はたてていない、でも今週中に実装おわって最初のプルリクエスト出せますよ、くらいは話すかな。
自社が持っているオープンソースソフトウェアとか、表側に出るサービスとかでは、普通に締切もあることが多くて、規模の大きいものだと、関係者各位を集めた定期進捗報告ミーティングに出たりもする。
会社全体だと How is software developed at Amazon? (2019) にある、OP1 / OP2 も、締切 + 見積もりという面がる。
Every year there are two docs OP1 and OP2 (Operating Plan). Every organization level writes a 6 page document about what they want to do next year. In the plan you say what you would do if you had flat resources and incremental resources.
あとは「今回のスプリントではここまで作ります」みたいな、チームの中に人工的に発生させる締切もある。
締切がある vs. 締切を守る
ただ、締切があるのとそれを守るのはちょっと別で「締切は死守! 残業と休日出勤で間に合わせます!」という真摯さがあるかというと、うーん、もちろん真面目に働いてベストをつくしてはいるけれど、一方で、無理なものは無理という諦めはどこかにある。
これは私の個人的な環境の変化 (独身 -> 結婚子持ち) もあるし、大企業への転職にともなう変化もある。結局のところ大企業には、投資家向けのデモに間に合わせないといけない機能とか、株主総会の資料になぜか記載されるリリース予定日とかは、あまりない。
歴史的には、ソフトウェア産業の変化による、要するに CD-ROM を箱詰めして出荷しなくなったものもあるんだろうけど、私はそもそも最初の仕事から Web 2.0 時代だったので、正直ここには実感がない。
もうちょっとマシな理由としては、昔にチームにいたシニアなエンジニアが「顧客は社内の締切なんて知る由もないが、可用性や速度についてはわかる。社内の締切のために品質を妥協するべきではない。」といったことを言っていて、私がそれを信じているから、というのもある。締切も品質もチーム全体で守るものだけど、締切をずらすことのまずさはマネージャーが、品質を妥協することのまずさ、例えば「この変更がどのくらいハックか」はエンジニアがよりよくわかっているはずで、私は締切と品質だったらまずは品質のほうを守りたいなあと思っている。
見積もり
そういったわけで、私の世界には締切はあって、見積もりしていて、するからには、可能であれば正確でありたいと思っている。
ただ、個人的にはプランニングポーカーも、ストーリーポイントで見積もってポイントの時間換算をいじる相対見積もりも、いまひとつ成功経験がない。結果として、小さめのタスクに分割して、それぞれにかかりそうな日数をえいやで決めて、チームの皆さんからのツッコミを待つ、という非常に雑な見積もりをしてしまっている。でもこれは雑なだけで現代的とは言い難い。
スコープの調整はできる。できるのだけど、一方でエンドユーザー向けのアプリケーションに比べると、私の関わるような製品には依存関係が色々とあって「この API めっちゃ遅いですね」「これは 2021 Q2 に X という機能が追加されて、そっちの API を叩くと速くなる予定です」「じゃあ速くなる前提で、2021 Q4 に出るサービスから使いますから…」みたいなことをしていると、結構自由度はさがってしまう。まあそれでも無理なものは無理なんですが…