倉貫さんのブログや、名著！『アジャイル開発とスクラム』でも取り上げられてて、
ちょっと話題になっていたので読んでみた。
結構なボリュームなので、以下に抜粋しながら引用する。
ソフトウェア開発では，「すべて」が設計プロセスの一部になっているという大きな問題があります。 コーディングは設計であり，テスティングとデバッギングも設計の一部であり，私たちが一般的にソフトウェア設計と呼んでいるものもやはり設計の一部なのです。
ソフトウェア設計はコーディングが完了し，「かつ」テストされるまでは完璧にならないのです。 そして，テスティングは設計の検証と洗練を行うプロセスにおける礎となるものです。 上位レベルの構造を設計しただけでは，完全なソフトウェア設計とは言えません。 これは詳細設計に向けた単なる構造上のフレームワークでしかないのです。 そして，上位レベルの設計を厳格な形で検証できるほど，私たちの能力は優れていないのです。 詳細設計は，少なくとも詳細設計以外の要因と同じくらい上位レベルの設計に影響を与えます。 設計におけるすべての側面が，設計サイクルを通じて洗練されなければならないのです。
なるほどー！ 以前のブログで書いたけれど、
設計にＤｏｎｅがないのは、その後工程も「すべて設計」だからなのだ！
設計に考慮漏れが出てしまうのも「まだ設計途中」だからなのだ。
「テストやデバッグも設計」というのは、
「設計」 「製造」 と、工程を分断して考えてしまっている者にとっては、ちょっとした衝撃である。
さらにこうも書いてある。
私たちは経験することによって正しい方向に向かうことができるのです。 これが技芸というものなのです。 （中略）その後で，管理された洗練プロセスによって，私たちが得たものをより良いものにしていくべきなのです。 それが工学というものなのです。
工学とは（中略），あなたがどのようにプロセスを実践するのかということなのです。（中略）プログラミングとビルド/テスト・サイクルが，ソフトウェア開発における工学プロセスの中心となるのです。 私たちは，これらの作業を正しく実践していく必要があるわけです。
（中略）ソフトウェア・システムは現実的にどのようなものでも表現できるという事実を考えた場合，ソフトウェア設計を検証できるような汎用手法が見つかることなどあり得ないのです。 私たちはプロセスを改善できるだけで，この状況から抜け出すことなどできないのです。
先のブログで、
いつもいつも「どうしたら考慮漏れをすくえるのだろう？」と思うのだけど、明解な答えは出てこない。
と書いたけど、答えはわかっていたじゃないか。
やはり「動かさないとわからない」のだ。
動かすことでソフトウェアを設計し検証する。それでいいじゃないか。
私はどちらかと言えば、紙の上で考えながら仕事をするタイプ。
プログラムをつくるのを「めんどくさい」と思ってしまうタイプだ。
デバッグは「考えたことを検証する場」になっていた。
これからは、もっと素直に、そして真面目に、「設計としてのデバッグやテスト」を考えていこう。
「動かしてみる」そして「早く失敗する」ということは、思ってる以上に、実は奥が深かったのだ。
