制御するためには測定が要るが，制御を放棄しても計測がなければ話にならない．
まず，自らの立ち位置に対する告白から．私はソフトウェア工場というアプローチが大嫌い．かつては某有名企業がソフトウェア工場を構える湘南厚木方面に敢えて足を向けて寝ていたくらいのもので．
「測定できないものは制御できない｣は誤りだった。
平鍋氏のブログで知ったTom Demarcoのエッセイ．私も英語がカラッキシな範囲内で，読んでみた．私の英文読解力の範囲内で，平鍋氏が何か曲解しているとは思えなかった．
この記事のなかで、例えば、GoogleEarch や Wikipedia といったソフトウェアが、果たして計測と制御という管理で作られただろうか、と問うている。そして、２つの種類のプロジェクトを例にし、
- Project A: 100万ドルのコストを使って 110 万ドルの価値を作る。
- Project B: 100万ドルのコストを使って 5,000 万ドル以上の価値を作る。
「計測と制御」は、Project A の世界では有効だが、Project B の世界ではほとんど意味をなさない、と指摘している。これは、
ソフトウェア開発という活動には「計測と制御」よりもっと大切なことが多く含まれており、その中では、「工学」の概念は「ポイントを外している」
ということだ。
デマルコ先生への反論 - 計測しないで他にやること無いっしょ．
私は高校在学中の成績的には文系なのに，理系の最右翼である物理学科へ行ってしまった異端，きちんとした工学を学ぶ機会を逸したダメ野郎なのだが，古典的制御理論には open loop と closed loop っていうのがあるくらいは一般教養として知っている．ついでに，社用車のECUを書き換える程度には理想と現実を理解していて，レシプロエンジンごとき*1でさえ，closed loop の領域を増やすことがどれだけ困難なのかも非言語的に理解している．
計測の精度に比べ，それに基づく利得のレバレッジが大きくなればなるほど，closed loopでなんとかできると思えなくなる．これは，実学っていうかメシのタネとして「工学」を扱っている人たちの肌感覚として身に付いているはず．プログラマの生産性が人に依り3桁違うということに異論があまり出てこないソフトウェア開発が open loop臭いのは，真っ当な組込み技術者なら25年も前に気付いていておかしくないだろう．いや私のキャリアは高々20年弱くらいなのではあるけれども．
その辺を踏まえると，江戸っ子気質のインヘリタンスである私は「おいおいデマルコさんよ，いまさら制御とか言ってんのか，どこまで現場見てないんだよアンタ」と思わずにはいられないのだ．
ついでにもう一つ．時間に対してプロジェクトの成果の変位量が多いなら，細かくサンプリングすればいいじゃない? というのが多分制御の人たちの真っ当な考え方だろうと思う．程度の差こそあれ，アジャイルの人たちの基本理念はこの辺りにあるのだろうと思う．短期のPDCAサイクルみたいなものが強調されがちだし．
しかし，Project A と Project B の差が1.5桁程度違うとなると，瞬発的なオーバシュートを検出できるのかという素朴な疑問が沸く．そのオーバーシュートを組織が吸収できるのかというリスク管理の観点は，誰からしら考えているだろうと思うけれども，私が手に取る程度の甘っちょろいアジャイル本には載っていない．
仮に，ソフトウェア"工学"において制御が困難だったとしよう．まあ彼のデマルコ先生までもが言っているのだから間違いないのだろう．だがしかし，だからといって計測が無駄かっていう議論にはならない．2800rpm以降は open loop だから適当に過給器にブーストかけときゃパワーは出るんだ，もしくは対極に，俺らは極限を狙わないから水温計は壊れていても問題ない，という理論がアホの極みだというのは，地方の珍走団でも理解できるはず．
伝達関数が扱いづらいからといって計測より大事なものがあるだなんていうのは，工学以前のところで，ポイントを外している．そんなふうに私は思う*2．
酔っぱらっているので，この辺でシッポ巻いて青年の主張のマトメ．
- closed loop でプロセス回せると思っていたのがそもそもの間違い．古典的ソフトウェア工学は論外として，アジャイル連中も同じ轍踏んでないかしら．
- open loop だったとしても，計測無しに話始まらないっしょ．
繰り返すけれど，私はソフトウェア工場に代表されるソフトウェア工学的アプローチが大嫌いだ．
だけれども，その支柱となる主張が必要以上に自虐的になり結果としてソフトウェア開発手法がグダグダになる，なんていう将来は困る．
