詳細設計書は死んだ。とっくの昔に死んでいる。でも生き返る必要はある - L'eclat des jours(2014-03-11)

_ 詳細設計書は死んだ。とっくの昔に死んでいる。でも生き返る必要はある 流儀や呼び名はいろいろあるだろうが、ここでは3種類あることにする。 ・要件定義書 要件を定義したもので、ユースケースについて記述したものだ。 ・機能設計書 要件を機能として記述したものだ ・詳細設計書 機能を実装に落とし込むものだ で、詳細設計書って何それおいしいの？ ということだが、もちろん不味い。むしろ毒だと言うべきで、そんなものを記述するよりさっさとプログラムを書けば良いし、その時間を使ってテストプログラムを書けばさらに良い。 特に、1990年以降、オブジェクト（あるいはクラス）ライブラリが拡充され、APIがほとんどなんでもやってくれて、コンポーネントがそこら中に転がり始めてからは、単にそれらをグルーでつないでいくのがほとんどなのだから、そんなものを書いてもまったく意味がない。 しかし、実はそう単純でもない。 問

[zetamatta]

まぁ、しかし、ビジネスロジックの毒を DSL を外だしにしても、独自DSLであれば、結局、いにしえの言語よりも始末に負えなくなってしまうと思うんだが、どうだろう。

[yyamano]

汎用言語でうまくDDDすれば同じようなことは実現できるけど、よりシンプルな記述ができて、ソリューションドメインの実装と分離できる仕組みがないと、うまく運用していけないってことなんだろう。

[suginoy]

“詳細なビジネスルールというのは、2種類に分けられる” "1つは、上でもあげたが、計算式だ。" "もう1つは、データの組み合わせ方法だ。" "そこでわかることがある。後者は実際問題としてそれほど問題とならない。"

[habuakihiro]

割と同感するのだけど、MDAを思い出してしまったｗ　時代は遅々として進まないもんだなぁとか感じたりもする。

[rryu]

評価順序などの未定義な部分を残さずにDSLの仕様書を作れるなら、有用な詳細設計書も作れそうな気がする。

[tarchan]

＞システムのアーキテクチャがWebではない20年後の何かになろうが、ビジネスルールを記述したDSLの実行エンジンをその言語で実装すれば良いのことになる。

[mfluder]

"今、Javaで記述したシステムが20年後に動いていることをおれは想像できない。しかし、細粒度のビジネスルールが20年後でも同じことは想像がつく"

[taguch1]

そして20年後、詳細設計書を開こうとしてすでにExcelがなかった。

[FTTH]

一連の話の中でDFDとか状態遷移図とかクラス図とかいう言葉をあまり見ないのは謎い

[r-west]

20年も経ったら、そんなレベルの仕様書なんてどういう根拠で信頼できるのよ？

[kitaj]

素晴しい記事．artonさんすごい!

[yohei]

この件関連で一番本質に触れてる記事だと思った。artonさんすごい。プログラムで表現できないモノ(ここでいうビジネスルール)といかに上手く付き合うか。文書名はともかく。

[holypp]

主旨は同意＞会計は長く、プログラミング言語の流行（生存期間）は遥かに短い。会計の長さとためを張れる寿命を持つのは自然言語だ。今、Javaで記述したシステムが20年後に動いていることをおれは想像できない。

[tgk]

データ生成の制約束縛が網羅されたドキュメントが必要という話。粒度的に詳細設計書が該当してしまうが、そこには制約束縛以外のゴミみたいな情報も書くのが約束になっているのでよろしくない

[TokyoIncidents]

細粒度のビジネスルールはいつ設計書に書き起こされることになっているんだろう？設計書に書き起こすことが困難と言っているような気がするので矛盾を感じる

[msykt]

“そのくらいスコープを取って考えないと意味ないよ。”

[ledsun]

「そこで、COBOLを……読めない。」でワロタ / 「詳細設計書は無いけど、動いてるソースあるからシステム更改して」って発注されたら、リスク考えて3倍で見積もる。それでやるって言われたら、初めて本気出す。

[iR3]

ふむふむ 寿命の長さに合わせてドキュメント化のニーズは異なると

[joker1007]

実装と同程度の粒度で顕在化するビジネスルールなら、ソースコードにコメント付けて、自動でドキュメント化すれば済むんじゃないかなと思った。でも、ちゃんとコメント書くのは難しいしなあ…。

[bobbyjam99]

"今、Javaで記述したシステムが20年後に動いていることをおれは想像できない。しかし、細粒度のビジネスルールが20年後でも同じことは想像がつく。"

[p260-2001fp]

『問題は詳細なビジネスルールにある。本来ビジネスルールは要件なのだが、ユースケースで考えると、詳細なビジネスルールはユースケースレベルとして記述するのが難しい。』

[Dryad]

その手の細粒度の詳細が数十年以上に渡って生き続けてること自体が問題な気がしなくも。

[YaSuYuKi]

そのような設計情報は、ドキュメンテーションコメントとして埋め込むのが良い気がする。ただ、複数のモジュールにまたがる場合は難しくなるが/ドキュメントが正しいことをソースを読まずに確認する方法は？

[kabisuke]

きちんとメンテナンスされていれば意味あるんでしょうけどね…所詮Excelで書かれた詳細設計なんてメンテナンスが追いつかなくて結局ソースコード読んだほうがマシってことになる。

[hfu]

「プログラミング言語の寿命は短い。」