Entry

詳細設計書はソースに書いてあるとか言っている人はよほど立派なソースを書くんだろうなと思った

2008年08月15日

なんかものすごくいい加減なことを言っている人を見つけたので,ちょっと書いておきます。

現在は、コーディングは詳細設計であり、ビルドやCD-Rに焼くことが製造になります。

(snip)

この「手戻り」は多いともともとの基盤レイアウトが良くなかったということですが、ある程度は「設計」という作業を行うに当たって必要な手戻りであり、「手戻りは悪」とすると試行錯誤を禁止された設計者は良い設計ができません。

[cppll_novice:1266] Re: UML の虚構

この頃は,簡単な言語も増えてコーディングのコストが低くなっているから,設計と製造の境界が曖昧になっている,というのは分かります。しかし,「コーディングは詳細設計」というのは,少なくともウォーターフォールモデルで開発を進める限り,正しくありません。

なぜか。それは,プログラムだけではその動作が正しいのか,検証できないからです。現状のプログラムが正しいか検証できないプログラムは,保守性が極めて低くなります。

例えば,「水温が30度を超えたら,赤いランプを点灯させてユーザにメールで知らせ,超えた時間と温度をログファイル書き出す。」なんて仕様があったとします。メールのあて先やログファイルのフォーマット,水温を測るタイミングなんかは,下位仕様として仕様化されているとして(あたしが知る限り,そういう仕様があることも稀なんですが),問題はそのデータの持ち方(データ構造)やアクセス方法(例えばアルゴリズム)です。この例で言うと,水温をサンプリングするアルゴリズムや,メールのあて先を管理するデータ構造,内部バッファの作成や破棄のタイミングといったもの。これを策定するのが,本来的には詳細設計(またはプログラム設計)の領域とされています。

詳細設計工程では,成果物として詳細設計書やアルゴリズム仕様書なんてもんが作られます。つまり,プログラムの「正しい動き」が書面化されるわけです。

一方,こうした書面がない場合,特に派生開発では混乱します。プログラム上,正しいとも間違っているとも判断がつかないところ ―― バッファを使い終わったのに,かなり遅いタイミングで解放しているとか,同じデータを2回参照/書き込みしているとか ―― の動きが「正しい」のか,判断がつかなかったりするからです。現バージョンではおかしくても,次バージョンで必要になるプログラム仕様なのかもしれない……とか,2回参照しているのは別スレッド/プロセスから書き込まれる可能性があるからかもしれない,とか,いろいろ考えなくちゃいけないわけです。こんなことを考えさせる成果物は,少なくとも「設計」と呼べるもんではありません。かなり遅くメモリを解放している箇所をいぢれないせいで,仕様追加で必要なメモリを確保できなかった,なんてお粗末なこともありうるわけです。もちろん,適切なソースコードには,コメントのひとつも入っていそうなもんですよね。しかし,(本来的な意味での)製造工程ですることは,コメントを書く作業ではなく,もっぱらコーディングです。

または,こう言い換えてもいい。詳細設計工程の成果物は,プログラムのソースコードだ,とする主張は,「目の前にあるプログラムが『それ自体で』設計上も正しい」ということを主張することと同じです。しかし,ソースコード上でそれ(要求仕様に対応する設計/実装であること)を,十分に表現できるのかを考えると,かなり疑問です。突き詰めて言えば、お客さんや改修担当に「設計はソースで,それが全てですから,納品後の検収や改修見積りに当たってはソース読んでください」と言えるのか,ということになるわけですけれど,社会的なマナーとしてそんなことは言えるわけがないし,現に実装的にも設計的にも完璧なソースコードなんてもんを読んだことがない。実装的にも設計的にも完璧なソースコードってのは,きっと「文芸的プログラミング」みたいな話になるんでしょうが。

また,引用中「必要悪としての手戻り」なるもんについても,設計者の能力の低さを隠す方便に過ぎないと考えています。

これは結局,「作って動かしてみなくちゃ正しいか分からない」ってことなわけで,こゆのはただの実験だし,できて動いたものを,後になって仕様なり設計なりに仕立て上げるってのは,設計ではなく現状追認(動いてるんだからいいじゃん)に過ぎないからです。家を建てる前に,「建ててみなくちゃ設計書が書けません」とか「地震が起きてみないと倒れるか分かりません」とか言ってたら,クライアントからぶっとばされるはず。何のための設計図面と構造計算書なんだ,と。それと同じ理屈です。こんな理屈が平気でまかり通る現場ってのは,ソフトウェア業界くらいじゃないだろうか。

もちろん,特許化するようなレベルの新規開発で,できるかできないかが本当に分からない開発ってのはありえます。しかし,こういう開発(パイロット開発)は,設計だけでなく工数見積りや開発手法からして,そもそもウォーターフォールの開発モデルに沿いません。そうだからこそ,その一環での現状追認も許されるわけで,こちらを原則にするのは本末転倒です。問題なのは,技術的な課題がほとんどないような通常の案件でも,パイロット開発並みに「作ってみなくちゃ分からない」とか言っていること。おそらく,本当に作ってみなくちゃ分からないんでしょうけど,そういうのは設計者としての能力に疑問を持つべきであって,ウォーターフォールを逆流させることを正当化する理由にはなりません。正当化できるのは,手戻り分のお金が出るときだけ。見積りはウォーターフォールにしたがって行われているはずですから,普通はありえませんけど,なんならお客さんに「試行錯誤したい(失敗するかもしれない)からもっとお金ください」と言ってみろ,という話になる,と。

さらに,

UMLにしろ日本語にしろ英語にしろ、コンピュータの動作を完全に記述出来る言語ではありません。

「仕様」や「概要」は記述できても、「詳細設計書」をあいまいさや漏れ無く書くことはできないのです。

http://d.hatena.ne.jp/methane/20060417/1145291859
<引用>
コーディングが設計作業だという証明は簡単に出来ます。

  1. コーディングから創造的な作業を無くすほど完全な設計書があったと仮定する。
  2. その設計書には完全に動作が記されているので、人間がコーディングしなくてもその設計書のコンパイラを作ればその設計書通に動くソフトウェアが作成できる。
  3. その設計書は、コンパイラで変換できるので、ソースコードである。
  4. その設計書はソースコードなので、その設計書を書く作業はコーディングである。
  5. 1.と4.は矛盾するので、1.の仮説は間違い。

[cppll_novice:1266] Re: UML の虚構

この話も非常に詭弁的です。この話の論理で,コーディングが設計だと言うのに抜けているのは,次の命題です。

  • 設計とは創造的な作業を言う。
  • 創造的な作業は設計である。
  • コーディングとは非創造的な作業を言う。
  • 非創造的な作業はコーディングである。

しかし,誰もコーディングは非創造的だとは言っていないし,現にそうでもない。設計にしても同じで,何でもかんでも好きなものを作っていいわけではない,という意味では,非創造的です。つまり,前提からしておかしいです。この理屈で言えることは,コーディングが創造的なものである,というところまでで,コーディングは設計であるというところまでは言えません。

設計フェイズでも製造フェイズでも,少なからず創造的な作業が入り込むわけですけれど,考えなくちゃいけないのは,それぞれのフェイズの目的です。詳細設計フェイズで完全な設計書を必要としないのは,外でもなく,詳細設計の目的が実装工程のそれと異なるからです。その目的は,実装工程の進捗に役立てることはもちろん,将来の保守担当に対して有益なドキュメントを残すことでもあり,納品先の検収担当者に「正しい動き」を理解してもらうためでもあり,良質なテスト仕様書のネタを作るためでもある。

反面,以上が詳細設計ですべきことなのだから,その目的が達せられる以上,それより細かい部分については,プログラマの裁量に任せてもいいことになります。ここがプログラマの創造的作業の場です。「バッファを確保し引数として渡す」とだけ書いてある詳細設計書は,「渡し方」についてプログラマに裁量を与えている(授権している)と言ってもいいでしょう。プログラマは,バッファをポインタで渡そうと,参照で渡そうと,イテレータで渡そうと,好きにしていい,と。

詳細設計書がプログラムの動きを全て記述できないことなんてのは当たり前の話。しかし,それでもって詳細設計書が不要であるとかいうのは,エンジニアリングプロセスについて,何か勘違いしているとしか思えません。

また昨今,エンジニアリングにおいて創造的でない作業はどんどん自動化される傾向にあります。実際問題として,RDB や OOP それに XML なんかの世界では,スキーマコンパイラなんてのがあるので,設計書がそのままソースコードになっています。こゆとこにプログラマは要らないし,その作業を「コーディング」と呼ぼうが「設計」と呼ぼうが,実はどうでもいいことだったりします。

なんつか,どうにかして「手戻り」を正当化しようとする理屈が,あちこちにあるんですけれど,お客さんからみたら,どれも言い訳じみたものばかり。こんなこと言って,お客さんにしばかれたりしてないんだろうか……すごく疑問です。

Trackback
Trackback URL:
Ads
About
Search This Site
Ads
Categories
Recent Entries
Log Archive
Syndicate This Site
Info.
クリエイティブ・コモンズ・ライセンス
Movable Type 3.36
Valid XHTML 1.1!
Valid CSS!
ブログタイムズ

© 2003-2012 AIAN