「測定できないものは制御できない｣は誤りだった。-- by Tom Demarco

> ソフトウェア開発という活動には「計測と制御」よりもっと大切なことが多く含まれており

このもっと大切なことがなんなのか、そしてそれを開発現場で活かす方法を考えていかないといけないですね。開発現場では、良くも悪くもメトリクスのようなわかりやすい、見えやすいものに頼りすぎてしまって、間違った方向に進んでいることが多いように思われるので（少なくともうちの場合は。。）

それにしてもデマルコさん、すごいですね。あれだけの方が、素直に自分の誤りを自ら正すなんて。素晴らしいです。

引用部分の２センテンス目ですが、ソフトウェアの"construction"と"conception"を別の行為として対比しているのではないでしょうか：
「実際にソフトウェアを構築する行為は必ずしも実験的ではないが、ソフトウェアの構想を作る行為は必ず実験的である」
私の深読みしすぎかしれませんが、ご参考まで。

タイトルの 『「測定できないものは制御できない｣は誤りだった。-- by Tom Demarco』 からは、 DeMarco が 「測定できないものでも制御できる」 と言っているように受け取れます。 しかし、 件の記事には、 そんなことは書いてないですよね?

> ソフトウェア開発という活動には「計測と制御」よりもっと大切なことが多く含まれており
もっともだ。
普通に考えて普通にやるということすらできていない人が多すぎる状況だから、工学を適用する以前の問題だ。もっとみんなが普通のことをやるようになって分野が成熟してから計測について考えた方がいい。

この記事を知人に教えてもらって知りました。
ソフトウェアもビジネスも、常に実験的であり、閃きや爆発があって大きな変化が産まれていくのだと思います。
もちろん、計測し、制御していくことも必要なことなので、
・「計測する人たち」が「計測できないものたち」を否定しないこと
・「計測すべきもの」「そうでないもの」を見極めていくこと
が必要なんでしょうね。

>ytka　さん

そう、ぼくも、「変わる」ことの重要性を強く思いました。

>keis さん、

ありがとうございます、その対比が正しいと思います。

>biac さん、

鋭いですね。論理的にその通りです。当たっています。「そんなことは書いてないです」。強いて言うと、 『「測定できないものは制御できない｣と言ったぼくは間違っていた。』 です。題名が釣りになってしまって恐縮です（意図的です）。でも、「大切なフォーカスが移ってしまった」は、誤り、とは言わなくても大きなインパクト、ということで。

>melleo さん、

その通りだと思います。でも、本当に成熟するのでしょうかね？成熟しないまま（それが本質）ということもありえます。

>january さん

内容をしっかり捉えられたコメントですね、まったく同意します。両視点を分けるべきでしょうかね？

ある方がこの記事に mixi の方で、SE（ソフトウェア工学）とIS（情報システム学）を分けることで分かりやすくなる（米国の教育ではそうなっている）、というコメントを頂きました。それによって、SEがQCDに専念するのは良いことだ、と。

不勉強のため、IS という言葉を知りませんでした。
なるほど、IS がゴールで、SE が手段という関係のようですね。で、IS に軸足を置こうということなんですね。

>現実のソフトウェア開発は、「計測と制御」で語れる部分の「外側」に徐々にフォーカスを移動しつつある。
の部分をようやく理解できた気がします。ありがとうございます。

計測は、TQMやシックスシグマなど欧米の管理手法のベースですね。遡れば、分析的哲学に端を発しているように思います。事実、これら管理手法による成果もあがっています。一方、日本のカイゼンでは計測より現地・現物・現実に重きを置きます。また、品質工学（タグチメソッド）では、「品質が欲しければ、品質を測るな」と言います。価値工学や品質機能展開など設計品質向上手法は計測＆分析的アプローチをとりません。西洋医学と東洋医学の違いにも似ています。計測で手に入らないものは、ビジネス上の価値向上（魅力的品質）でしょうか。しかし、その前に、欠陥の無いものをキチンと作るという、あたりまえ品質を満足させてからだと思います。

HiroAoさん、
確かに、東洋・西洋ににた捉え方は含まれていますね。

ただ、

「しかし、その前に、欠陥の無いものをキチンと作るという、あたりまえ品質を満足させてからだと思います。」

この部分が、ソフトウェアを製造業と捉えるかサービス業と捉えるか、のような違いに思え、ぼくの意見とは異なります。つまり、「欠陥の無いものをキチンと作る」というよなことが、定義できる領域（つまり欠陥が何で仕様が何で、何を作ったら顧客は満足して対価を支払うか）では可能ですが、ソフトウェア開発はそこからずいぶん離れた領域に広がっている、というのが主旨な気がしています。Webをサービスとして使う開発がその典型です。

「静力学」、として解ける問題であればいいのですが、実は「動力学」であり、作っていくそばから要求が動いていくような開発だと、もうアジャイル的なやり方しか本質的に解けない（というか、解けないので、近似的に追っかけていってなんとかベストを尽くす）のではないかと。