いいかげん性能改善の仕事にも飽きてきたのでクールな新機能とかやってみたいなーと思ったりもするけれど、いまいち勇気が出ない。というのもクールな新機能ってだいたい締切あるじゃない？
締切のない世界
自分は今の会社に入ってこのから 10 年以上、締切のある大仕事をしたことがない。最初にやっていた新しいAPIをウェブ標準に入れる仕事はろくに仕様もわからないまま一年くらい過ぎていたし（仕様を決めるのも仕事と言えば仕事だったんだけど）、標準化団体にせよ呉越同舟のオープンソースにせよ制御不能な要素が多すぎて誰にも締切なんて決められなかった。
そのあとやっていた巨大リファクタリングみたいなやつも、やはり締切はなかった。今思うとこれは締切があっても良かった気がするが、まわりに締切という文化がなかった気がする。この頃の自分は「この会社には締切ないんだな」と理解していた。これは若干主語が大きすぎだけど、そういう人が沢山いたのもまた事実だと思う。
隣の締切
そのあとスマホの電子書籍アプリのチームに移ってみたら割と締切が幅を利かせていてすっかりビビってしまい、全力で新機能の仕事から遠ざかった末にたどり着いたのが性能改善だった。性能バグ、まあすごいヤバイ遅さは直さないと出荷できないけれどそういうのは稀（当時だと年に一回とか）で、基本的にはあるリリースに間に合わなかったら次のリリースで出せばいい。
以前はどんな機能も「リリースに間に合わなかったら次のリリースで出せばいい」と思っていたし今も理想的にはそうあるべきだと思うけれど、 世の中には年末商戦だったり広告出稿のタイミングだったりパートナーとの契約だったり、色々と融通の効かない都合もある。だから締切があるのは仕方ないなと考えを改めた。あたりまえだとおもったあなたは正しい。
ただチームのどこかに締切があるのと自分に締切があるのは別。何らかの都合で誰かに締切があるのはまったく構わないが、自分の締切は困る。Not in my back-yard ならぬ Not in my bug-tracker みたいな。
自分がいまいるチームは特定電話機付属のソフトウェアを開発しており、これは電子書籍とか目じゃないレベルで締切が難しい。ハードウェアの締切、ハードウェアに載せる OS の締切、電話機出荷初日 OTA の締切。こういうのは自分の都合では全く動かない。そして出荷ブロッキングな性能バグの量も、これまでの仕事に比べると随分多い。だからそこそこ忙しい。
ただ性能バグというのは基本的に自分以外の誰かがやらかしたことなので、こちらにできる予防措置は必ずしも多くない。（監視の強化とかあるにはあるけど。）修正自体もできることは限られており、性能担当にできるのは小細工ばかり。大きな書き換えは開発者本人がやらざるをえない。だから仕事は悪く言えば受け身で、個々の仕事に使う時間も短い。性能問題解決の手が大変更以外にない新機能は次のリリースに見送られて、自分以外の誰かががんばって直すことになる。
結果として締切がいっぱいある割には残業して睡眠削ってデスマ、みたいな経験をしていない・・・少なくとも自分は。自分以外の誰かがデスマしている可能性はあるんだけど 17 時に退社してるとその後何が起きたか知るよしもないし、自宅勤務ではなおさら他人の事情はわからない。
締切の遠い記憶
これは締切との戦いと聞いてかつて自分が想像したものとは違う: 厳しい締切と戦おうと思ったら、きちんと計画を立て、見積もりをして、更には生産性を測定し進捗を調整しつつ前に進む・・・というものだと理解している。これはトップダウンなプロジェクトでもアジャイルでも大まかには変わらない。
残業して睡眠と精神衛生を削ってデスマな仕事をしていた十年以上前は、締切と戦う計画と見積もりのスキルはすごく重要なものに思えた。自分はマメさが足りず計測や予測はヘタクソだったけれど、それでも下手なりに こういう本とかあるいはこれとかを読んで勉強し、planning poker で story point みたいなことをしていた。
そういうの、今は一ミリもしていない。
「締切無いとか会社員としてダメなのでは」という罪悪感から過去に何度か真面目に見積もりをしようとしたことがあるが、あまりに報われない、つまり見積もりを活用する機会がないので、いずれも長続きしなかった。最近は (T)PM がちゃんとした人なので「仕事だいじょぶ？ spreadsheet の見積もり埋めてね？間に合わなそうだったら助けを探すとかするから」などとチームに声がけをしてくれるが、これにしても何かを間に合わせるためにやっているというより、ムリに間に合わせようと締切間際に生焼けのコードを突っ込む人がいないよう睨みを効かせている色が濃い。
今日の締切
でもさ、見積もり真面目にやってないの自分だけじゃないと思うんですよ。ここ十年、ソフトウェアエンジニアが見積もりについて（たとえばデザインとかと同程度に）真面目に議論してるの見たことない。Design doc に書かれた見積もりにしたって勘としか思えない数字がバンと書いてあればまだマシで、レイテンシとかメモリ使用量の見積もりに見られる rigor のカケラもない。最近ちょっと巻き込まれている新機能関係ミーティングでの会話も「間に合いそう？」「ムリかも」「じゃあ次にしますか・・・」みたいなかんじ。
かわりにどうするかというと、新機能を N 個企画してき、そのうち半分くらいは間に合うでしょ、みたいにしておく。N 個の半分くらいは以前からの持ち越しで、ある程度見通しが立っている。一番のウリの機能みたいのはさすがに沢山は用意できないけど、かわりに適用範囲を絞って着地させたり、電話機発売には間に合わないけど年末までには出るよ、と言ったりする。つまり締切は変わらないが締切に出ていくものが変わる。
別の言い方をすると、ソフトウェア開発の制約 Scope, Time, Cost のうち Scope を割と大胆に調整している。もっというと Scope を調整する文化の上に製品が作られている。Timing にしても先にリンクした 10 年以上前の本が想定するよりはリリース頻度が高いので、辻褄が合わせやすくなった。
そういう世界だとソフトウェアエンジニアの見積もりが雑でいまいち締切を守れなくてもなんとなるのではないか。つまり締切にビビらず新機能の仕事をやっても案外大丈夫なのではないか。一方で、締切が怖くないという概念をいまいち信じられない自分もいる。
というわけで: みんな締切どうなの？あるの？ないの？大変なの？守ってるの？
チームの人に聞いてみてもいいけどなんとなく藪蛇の恐れがあるのでここで聞いてみたい。