牛尾さんの「納期がなぜ生産性をぶち壊しにしているのか？」という記事を読んで考えたこと。あるいはインターネットが屑情報ばかりになってしまう現象への個人的な抵抗。
牛尾さんの記事では、特に日本では重視されがちのようにみえる「納期」というものがソフトウェアエンジニアの生産性に悪影響を与えるということ、現所属および周囲の北米企業では「納期」の少ない良い環境であることを示している。その論には強い異論はないのだけれども、「納期」というキャッチーな（？）用語を使ってしまっているので、論点の見通しが少し悪いようだ。
そこで、いろいろな見方があると思うが「文化」の話と「現場」の話に分けて、関連書籍などを紹介しながら論じてみたい。
エンジニアリングモデルとコントラクタモデル（文化の話）
納期という単語に反応すると「それは契約の話なのでは」となってしまいがちだが、もう少し抽象度を上げると企業文化の話になるだろう。というわけで「要件最適アーキテクチャ戦略」で紹介されているエンジニアリングモデルとコントラクタモデルについて紹介したい（なおこの本自体は正しくモノリスを作るDDDの本である。詳しくは以下の過去記事を参照）。
ちょっと長いが引用してしまおう。ちなみに引用部分を書いたのはリーン開発本で有名なMary Poppendieckさん。
この機会に、コントラクタモデルの対極にあるエンジニアリングモデル手法をソフトウェア開発に取り入れるという考えを紹介したい。まず、典型的なコントラクタモデルについて考えてみよう。このモデルでは、従業員と実際の請負業者のどちらで使われるとしても、開発者には担当する作業が正確に指示され、少しの失敗も許されない。エンジニアリングモデルでは、仮説に基づく実験を使って、学習と改善を行いながら複数の選択肢を検討する。
SpaceX とTesla はエンジニアリングモデルを採用している。対照的に、ほとんどのソフトウェアプロジェクトはコントラクタモデルを採用している。この対立する2 つのアプローチを並べてみた場合、ソフトウェア業界全体での1 人あたりのイノベーションを最大化するのがどちらであるかは明らかである。
SpaceX はペイロードを宇宙に打ち上げるコストを劇的に削減し、ブースターロケットを回収して再利用するという主要目標を――― 予定を大幅に短縮した上で達成した。どうやってなし遂げたかというと、SpaceX は近年まで宇宙探査の唯一の資金調達法とされていた政府との請負契約を結ばなかった。（中略）というのも、あらゆることについて耐えがたいほど詳細な検討を重ねるのではなく、とにかくいろいろなことを試して未知の未知を発見しようとしたからである。エンジニアリングのアプローチとしてはかなり典型的なものだが、コントラクタモデルでは決して許されないものだ。SpaceX チームによれば、墜落させて問題を見つけ出すほうが、リスクがなくなるまで待っているよりもずっと安上がりだったそうだ。
要件最適アーキテクチャ戦略（P.43）
私の理解する限りにおいては
ということだろうと思う。「要件最適アーキテクチャ戦略」ではもちろん目指すべき形はエンジニアリングモデルとされている。一方でエンジニアリングモデルを選択するということは企業の戦略であり、文化の変革の話であり、リスクを取る選択をすることになるだろう。このリスクが取れるのであれば「納期のないエンジニアリング」は実現できるのだ。
逆に言えば、リスクを取らずにコンストラクタモデルの文化を続ける会社で「納期のないエンジニアリング」を実現するのは（不可能ではないだろうか）難しい。
（ちなみに、Space Xがめちゃくちゃリスクを取っている話は自伝「イーロン・マスク」に描かれている。波乱万丈すぎて面白い本だった）
納期と期日と目標（現場の話）
牛尾さんの記事で気になったのは、以下の箇所である。
日本にいた時には何でも納期が付いて回ってた気がする。凄ーくちいさな仕事を頼まれても「〇〇日までにお願いします」と納期が付いてくる。今からするとなんにでも納期が付いて回る感覚だ。
納期がなぜ生産性をぶち壊しにしているのか？｜牛尾 剛
「〇〇日までにお願いします」は、わたしの感覚で解釈すると期日か、単なる要望である。これを納期と捉える感覚には違和感がある。
ただ、実際には特に日本の現場ではこういった言葉の誤用・乱用が多いのも事実だ。例えば納品物と成果物、善管注意義務とプロマネ義務、プロトタイプとMVPなどなど。ソフトウェアエンジニア的には様々な用語の定義に敏感であってほしいものだが、仕様と技術用語以外はルーズになってしまうのは割と不思議である。
実際のところ、納期（または納品日）は契約で定めるものであり、守らなければならないコミットメントである（これを守らなければ債務不履行になる）。逆に言えば納期だけは特別な約束であり、それ以外の日付はそこまで厳格なものではないし、調整余地も多いはずである（もちろん納期だって適切な手続きを取れば変更できる）。納期（コミットメント）を達成するためには様々なタスクに分解しマネジメントする必要があるが、分解したタスクの終了予定日は納期ではない。遅れたら他で取り返せば良いし、そういったリスクも含めて管理する方法はいろいろあるだろう（個人的にはTOC理論が好き）。
ちなみに現在も有用な古典的名著である「ソフトウェア見積り 人月の暗黙知を解き明かす」では第1章で「見積り、ターゲット、コメント」は異なるものだと言っていた。同じ話だ。
辞書にある「見積り」の定義は、厳密な意味では正しい。見積りとは、プロジェクトにかかる期間やコストを予測することだと言ってよい。だが、ソフトウェアプロジェクトの見積りとは、ビジネスのターゲットと、コミットメントと、コントロールとの間の相互作用である。（中略）
ターゲットが実現したいビジネス目標の記述であるのに対して、コミットメントとは、定義された機能を、特定の品質レベルを確保しながら期日までに納品するという約束を意味する。コミットメントと見積りが、同一のものを指すこともあるが、コミットメントが見積りより挑戦的だったり保守的だったりすることもある。言い方を変えると、コミットメントと見積りが同一でなければならないと考えてはいけない。そもそも同じものではないのだ。
ソフトウェア見積り 人月の暗黙知を解き明かす （P.4）
雑なまとめ
というわけで
- 所属する企業の文化を確認しよう。コントラクタモデルな文化の企業やプロジェクトで納期不要論を主張しても仕方がない。転職しよう
- 日付の話が出たらそれは「納期」なのか「期日」なのか「目標」なのかをちゃんと確認しよう。勝手に目標を納期と誤解してあたふたするな（相談すればなんとかなることもあるよ）
そんじゃーまた
