締切の話、森田さんの言っている事と同じ事を違う言い方で言う感じになりそうではあるけれど、自分の考えなどを。 締切といいつつ見積もりの話だったりもするかもしれない。
昔は締切もあって見積もりもしてた
自分は15年くらい前にやってた仕事は3年とか掛けてパッケージソフトを作るめちゃくちゃ長いプロジェクトで、 きちんと計画を建てて、かなりいろいろ定量的に進めるプロジェクト管理が行われていた。 ウォーターフォールを基礎にアジャイル的な要素を一部取り入れて欠点を修正したような進め方だった。
当然締切はあったし、それを中心にプロジェクトは管理されていた。
当時の自分は、けっこう見積もりに凝っていた。 やっていた事自体は森田さんもリンクしてたマコネルの「ソフトウェア見積もり」に載っているのと大差無いけれど（自分は日本語版を読んだのでこちらをリンク）、 最終的には「見積もりはちゃんと行えばかなり正確に出来るものである」という結論に到達していた（正確の定義とかも必要になってくるのだが）。 自分はプロフェッショナルとして、ちゃんと専門性を持って見積もりというスキルを持っていると言えたと思う。
一方で専門性を持って行わない見積もりが業界には横行していて、まったくどいつもこいつもけしからんなぁ、とか思っていた。
最近は締切無い
最近の仕事は、締切はあまりなくなってきている気がする。
トップ500にチャレンジします、みたいな時は締切があったし、論文の投稿みたいなのでも締切はあるので、 締切のある仕事はある。kzysさんも締切があると言っている。 ただ、全体的には出来た所までがリリースに含まれて、間に合わなかったら次、 というスタイルになっている気がする。
今の仕事…というか自分は先日仕事をやめて無職になってしまったので、もう「今の仕事」と言えないのだけれど、 前の仕事も、締切は無かった。 大きめなアプリを長期間かけて作るという事で15年前にやってた仕事と近いはずだが。 シュリンクラップなパッケージとはやっぱり違うよねぇ。 前のプロジェクトは方針として極端に締切的な物が無かったので普通の仕事と比較しても極端にだったが。
自分の仕事とは関係ないが、Jetpack Composeも正式版がいつ出てくるのかは不明ですよね。 あんな目玉として散々宣伝して依存する人も大量に居る物が、いつリリースされるか不明って…。 困る人は結構多いと思うし自分もスケジュールくらい決めてくれていいのよ？と思っているけれど、 わからんものはわからんというのが最近のやり方ですよね。
自分はリリース信者で、リリースする過程でいろいろタフな諦めを行っていく事で製品というのは完成するものだ、 と思っていて（これは今でも思っている）、だから締切が無いといつまでも完成しないんじゃないか、とも思っていた。 でも最近は、やり方をいろいろ工夫すれば締切が無くてもリリースは出来ると思うようになった。
見積もりはしないに越した事は無い
最近はプログラマにちゃんと見積もりの専門性を要求するよりは「見積もりしないで済む」形態で進める方が良いんじゃないかと思うようになった。 見積もりが必要な時はあると思うしその時にはちゃんと行える方が良いとも思っているが、 一方で頑張ればそもそも見積もりを不要に出来る事も多い。 チームのプログラマを教育するより、見積もりしないで済むようにプロジェクトを進める方がコストが低い事は多い。
歯医者さんにかかる時、歯医者さんはあまり終わるまでの日付にコミットしない所が多いと思う。 「情報に非対称性があって客の自分よりも医者の方が詳しくてお金を払うのは自分」というのはシステム開発と同じ構造に思うのだけれど、 どれだけのお金が掛かるかをあらかじめ提示しない。 ソフトウェア開発もそういう感じに出来るんじゃないか？ 動くお金の額が桁違いなので完全に同じ形態にするのは難しい部分もあるけれど。
見積もりはコストが掛かるし難しいし不確実性もある。 しなくて済むならそのコストが浮くし、プログラマに要求されるスキルも一つ減る。
この前のDesign Docsの話でもそうだけれど、なにかを前もって予想するのは難しい。 なのに実は前もって予想する必要は無いことを慣習で無駄に予想している事はあるんじゃないか。
曖昧なものはたくさんある
作ろうとするものに複数の曖昧さのパラメータがある時「作るのにかかる時間」という曖昧さだけを過剰に固定すると、 その他のパラメータの調整余地が減ってしまう。 昔よりも、そのほかの曖昧さ、特に「何を作るか」の周辺にある曖昧さを重視するようになった結果、 締切などのパラメータをゆるくした方がいいという業界の動向があるのではないか。
時間に関わる事を固定するとプロジェクトの状態はすごくわかりやすくなる。 見積もりが得られれば実装にかかる時間に対する価値を評価出来るので、 同じ時間の中で実現出来る効用を最大化出来そうにも思える。 プロジェクトの進み方の期待値を持つ事も出来るし、 予想外のトラブルなどを早期に、しかも0-1では無く程度問題として把握出来るようになる。 相手の事がよく分からず質にばらつきのある社外の人員を使って開発をするなら、それらはすごく重要だったりもする。
でもそうしたわかり易さを得る為に失われている物を、より重視する組織もある。 これはkzysさんも同じような事を言っているように見える。 時間に関わるわかり易さや予測可能性を低下させることで、その他の曖昧だけれど重要な物の自由度を上げている。
効率的だが楽しくない
締切を決めてちゃんと尻を叩く方が短期的にはプロジェクトは速く進むと思うけれど、仕事はあまり楽しくない。 だからそういうプロジェクトには良いプログラマがあまり集まらず、 結果として長期的にそういうプロジェクトは生き残っていないのではないかという気もする。
GoogleやAmazonは質の高いプログラマを良い待遇で集めて大規模プロジェクトを行う。 質のばらつきのある安い外注を集めてうまく管理して大規模プロジェクトを行うというスタイルは、 そこでは幸いな事に主流では無い。
個人的にはちゃんと進めるやり方が劣る方法論という気はしていないのだが、 我々プログラマがそうじゃない方の肩を持った結果、より楽しく働く側が勝利をおさめた気がする。 コミュニケーションとか人を増やす難しさに対抗する為に一人あたりの能力を最大に引き上げる方が全体としては良いとか、そういう事情もあるのだろうけれど。
前回の仕事はその辺すごく意識的で、リーダーが楽しく働けるという事を重視していた。 サボるかもしれないとか、個人がトラブルを抱え込んで発覚が遅れるとか、そうした様々なリスクを理解した上で、 それよりも毎日楽しく働ける方が重要という判断をして、締切もタスクの管理的な事も意図的にゆるく行われていた。 あれではスケールはしないと思うけれど、少人数では上手く回っていたように見える。 むしろ割と歴史のある開発組織であれだけのゆるさを維持するのは随分頑張っているなと感心した。
仕事の効率の為には適度なプレッシャーがある方が良いと思うけれど、 それで失われる物を昔より重視するようになった気がする。 「楽しく働けてそこそこの成果」くらいでバランスを取る方が、 長期的には良いプログラマが集まってきて良いんじゃないかなぁ。