アジャイルに行こう!

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

»

ソフトウェア工学の祖の一人である、トム・デマルコが、最近IEEE Software 誌に、過去のソフトウェア・メトリクス賛美を悔い改める記事を書いている。

「ソフトウェア工学」というコンセプト-その時が来た、そして、その時は去った。http://www2.computer.org/portal/web/computingnow/0709/whatsnew/software-r

1982年に、デマルコは有名な「計測できないものは制御できない」という一文から始まる、『品質と生産性を重視したソフトウェア開発プロジェクト技法』という名著を書いている。このドグマは、ソフトウェア工学の考え方に強く根ざしている。むしろ、すべての「工学」という活動は、科学や経験から得た知見を使って自然現象をコントロールし、人間の役に立てることをその定義としており、そこでは測定を元にしたコントロールという概念はその中核にあるものだ。だから、「計測による制御」という概念を疑うことは、「ソフトウェア工学」というものの存在、あるいは、意味を大きく問う問題でもある。

では、計測しないで制御する、という方法があるというのだろうか?

この記事のなかで、例えば、GoogleEarch や Wikipedia といったソフトウェアが、果たして計測と制御という管理で作られただろうか、と問うている。そして、2つの種類のプロジェクトを例にし、

  • Project A: 100万ドルのコストを使って 110 万ドルの価値を作る。
  • Project B: 100万ドルのコストを使って 5,000 万ドル以上の価値を作る。

「計測と制御」は、Project A の世界では有効だが、Project B の世界ではほとんど意味をなさない、と指摘している。これは、

ソフトウェア開発という活動には「計測と制御」よりもっと大切なことが多く含まれており、その中では、「工学」の概念は「ポイントを外している」

ということだ。

デマルコは、冒頭に上げた本を書いた自分を「若かったころ」という言い方をして、メトリクス賛美を実際に悔いているように思われる。

ちょっと衝撃的な記事だが、実際には、「ソフトウェア工学は誤りだった」、というよりも、「ポイントを外しつつある」というのが正しい。ソフトウェア開発にもっとも大切なのは、そこには無かったのだ。現実のソフトウェア開発は、「計測と制御」で語れる部分の「外側」に徐々にフォーカスを移動しつつある。

デマルコの最後の結論の部分を引用する。

Software development is and always will be somewhat experimental.
The actual software construction isn’t necessarily experimental, but its conception
is. And this is where our focus ought to be. It’s where our focus always ought
to have been.

ソフトウェア開発は、いつも、ある種「実験的」である。現実のソフトウェア構築は必ずしも実験ではないが、概念的にはその要素を含む。そして、それこそ我々が焦点をあてるべきところであり、ずっと焦点をあてるべきところであったのだ。

Comment(12)

コメント

ytka

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


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

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

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

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

melleo

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

january

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

平鍋

>ytka さん

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

>keis さん、

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

平鍋

>biac さん、

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

平鍋

>melleo さん、

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

平鍋

>january さん

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

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

january

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


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

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

平鍋

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

ただ、

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

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

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

コメントを投稿する