詳細設計書について思うこと 続き
前回の記事の続きです。
注意：結構身内ネタが含まれていてコンテキストがわからない人はなんのこっちゃってなるかもしれません。
今回は@kyon_mm君の設計書論争での独り言についてです。
前回の記事を書いて@kyon_mmの記事を読んだ翌日、みんなで議論をしました。
メモ書きを元にしてるのでまとまってなく記憶違いもあるかもしれませんが、
議論の内容と、僕の意見を書き残しておきます。
僕が@kyon_mmの記事を読んだ限り僕が否定するような主張はほとんどないが、僕の記事をミスリーディングにしてるのでは？と思う節はあった。
具体的には、
プログラミング言語が十分に読み易くなった現代では不要という主張
http://d.hatena.ne.jp/kyon_mm/20120809/1344442163
の内容。
僕の記事では、「”設計書”とは本来ソースコードのことではないのか。」とした上で、「わざわざ自然言語で設計書を作ることに意味が薄れてきている」と主張したが、
ドキュメントの存在（言うまでもなく設計書だけがドキュメントではない）や、それに記述する自然言語や図については一切批判していない。これは記事の最後でもくどい位に言っている。
さらにいうとアプリケーションドメインとソリューションの差が縮まったといってるだけで、ソリューションドメインのすべてを形式言語で記述するべきという立場はとっていない。
ソースコードの話に限定したとしても、コメントばかりのソースコードは批判するが、コメント自体の存在を否定しているわけではない。
ソースコードの意図や制約について説明する必要があるなら、自然言語や図を使うことはいいことだと思う。
僕の主張することは、ソリューションドメインを記述するための中心的なドキュメントは、
@irofさんの記事のようなExcelによる詳細設計書ではなくプログラミング言語などの形式言語であるべきだということに過ぎない。
僕は”詳細設計書”という名前と、その実態（一例としては@irofさんの記事のようなもの）をセットで批判しているので、
@kyon_mmが必要だと主張する意図や境界を記述するドキュメントは、要件定義書や仕様書などと呼べばいいと思う。
そして僕の批判した実態は、そうではなくソリューションドメインを自然言語で記述しているものである。
@kyon_mmの論法は次のように思える。（もし@kyon_mmの記事が僕の記事への批判だと仮定すれば）
- 僕は詳細設計書の一例をあげて、それについて批判をする。
- @kyon_mmは詳細設計書を僕の定義したものから拡大解釈して（僕はドキュメント自体は批判しないと念を押しているにもかかわらず）、僕の言っている主張との矛盾点を作り上げそれに対して批判を行う。（きょん君いわく僕の記事への批判じゃないそうだが僕はそう感じた）
この構造は、わら人形論法そのもの。
それが意図的かどうかはさておき、僕が[”設計書”とは本来ソースコードのことではないのか。]という主張をWhat is Software Designの引用だけで済ませてしまったというところには、僕にも落ち度はある。
これについてはこの記事（→"”設計書”とは本来ソースコードのことではないのか。"の説明）で、もう一度まとめようと思う。
”つくるべきものの意図が十分に伝わっていない設計書にいかほどの価値があるのか？(意図が伝わる設計書にすべきである)」”について
これに関しては、僕への批判ではないと思っている（多分）
ただし、付け加えて言うならできるだけ意図をソースコードという設計書に含める努力はするべきである。
近年のプログラミング言語の発達により、C言語のような高級言語の皮をかぶった低級言語を使うよりソースコードに意図を多く含められるようになったと感じる。
たとえば
- ガベージコレクションなどの技術で意図に関連しない記述を減らす。
- 命名規約で関数名や変数名に意図を反映する。
- Design By Contract（契約による表明）
- 関数型プログラミングによる制御構造の抽象化（インテンショナルプログラミングに通ずるものがある）
- アプリケーションドメインに対するDSLを定義する（@kyon_mmもこれは主張してるよね？）
です。
もちろんそれだけで補えない部分を、コメントやワークフローなどの図で表現することは多いに賛成。
ソースコードからAPI一覧やクラスダイアグラム、ワークフローを自動で出力する技術についても賛成。
DSLの話。
アプリケーションドメインをどう表現するかの話でDSLについても盛り上がった。
僕は、アプリケーションドメインとソリューションドメインの距離が縮まりはすれど、決して同一にはならないと主張すると次のような意見がでた。
・現在は技術的な課題はあるが、それが解決すればアプリケーションドメインのすべてがDSLによって記述することができる(@bleis, @kyon_mm)
→ ハードウェア制約は？(@otf)
→ 将来的にそれを考慮する必要はなくなる(@bleis) → たしかに今でも昔にくらべれば富豪プログラミングという側面はあるよね(@otf)
→ UXなどのアプリケーションドメインは？(@otf)
→ ここでいうアプリケーションドメインは形式的に記述できるものと定義する(@bleis)
→ 形式的に定義できるアプリケーションドメインを仮に、”アプリケーション代数”と仮定すれば、
アプリケーション代数とソリューション代数が同一になることは直感的*1に正しいと思う(@otf)
→ DSLについては技術的な課題があるし、証明されたわけでもないと思うのであくまで”直感的に”という話だね（一同）
「なんでリバースエンジニアリングと要件定義一緒にやってんの。。。」について
これはもしかしたら僕の仕事で書いたコードで@kyon_mmにそうさせているのかもしれないと思いました。
そのときのコードは、自分の技術不足でコーディングに無駄な時間をかけてしまい、
そのような苦労を押し付けてしまったと思っています。
ですが、決してドキュメントを書かない主義ではないということを主張しておきます。
"”設計書”とは本来ソースコードのことではないのか。"の説明
歴史的経緯を無視した、〜べき論の話になりますが、
設計書という名前がつけられているからには、それはソフトウェアの設計を表していると思います。
ということで、まずは設計とは何か・何であるべきかということから議論する必要があります。
ExcelやWordなどを使い自然言語と図で記述するドキュメントを書くアクティビティを設計とし、
ソースコードを記述するアクティビティを製造とする文化があると思いますが、
それによっていくつかの弊害が現れます。
例えば、
- "信じられないほど巨大かつ複雑なもの"を管理と検証が難しい自然言語で記述しなければいけないこと
- "完璧な設計*2となっている場合，製造チームは設計者からの介入を一切受けることなく，その製品を生産できる"という誤解を生みやすいこと。（これは自動車業界など他業種における工学のアナロジです。）
です。
逆説的に、完璧な設計があれば、製造を完了することができるものが設計だとすれば、
ソースコードが設計であるといえると思います。
さらに製造とはソースコードのビルドになります。
そうすれば上記のような弊害はなくなります。
前回の記事でも言いましたが、ビルドが非常に低コストで行えるというのがソフトウェア工学の特徴の一つです。
つまり、ビルドが完了したあとのアクティビティであるテストによる結果をすぐに設計に反映してイテレーションを高速にまわすことにつながるわけです。
補足ですが、テストはビルドを行ったあとでないとできませんが
数理的モデルの検証や証明はビルドを行わなくても可能です。（AlloyやCoqなど）
ここで説明したことはWhat Is Software Design（和訳）の要約みたいなものです。実際いくつかの文は、ほとんどそのまま引用しています。
最後に
基本的に@otfに向けた記事
http://d.hatena.ne.jp/kyon_mm/20120809/1344442163
という内容の記事で
設計書否定するなら、ここにある事くらい論破するくらいの人じゃないと一緒に仕事したくない。逆に、ここに同意するくらいなら設計書否定すんなよ。自分の仕事を呪え。
http://d.hatena.ne.jp/kyon_mm/20120809/1344442163
とまで言われたら僕への批判ではないといわれても、
その記事を僕の主張への批判だと受け取るほかない。
名指しでかつ、”設計書否定するなら”に僕が当てはまっていたので、この記事で自分の考えを書きましたが、
もしそれ自体が勘違いであればごめんなさい。
もちろん、僕への批判だと主張しながらこの記事に対しての反論することは大いに結構だと思います。
技術的な話なので、その点については僕への社交辞令は必要ないです。
