発端はこのツイート
スナップショットはこちら（ロードするたびに割合がかわってしまうので）
前提条件
いろいろ議論が発散してしまうので、前提条件を確認しておきます。
「詳細設計」というのは、PMBOKの「Detail Design」にあたる、とします。
・要件定義
・概要設計、外部設計、基本設計、画面設計
・詳細設計、内部設計
・実装
・各種のテスト
PMBOKで云うと概要設計と基本設計が同じになります。最近は「基本設計」の方が言われることが多かった（多分、新聞などで使われることになったからだと思う）のですが、いわゆる顧客からの要件定義を受けて、システムを構築するための設計のことです。
実は、大手の会社でもここの分類が分かれるところで「自社だと違う」というパターンが多いでしょう。実際に画面設計（ユーザーインターフェース）やネットワーク設計などの仕様書が必要になることが多く、PMBOKが規定する分類にあてはまるとは限りません。
この分類は、漠然としたものではなく「誰が誰のために作るのか？」という視点で分けるとわかりやすいです。
「要件定義」は、顧客の要望を文書化したものです。顧客自身が書いてもいいし、請け負った会社が書いても構いません。
概要設計（基本設計や画面設計やネットワーク設計など）は、要望をどのように実現するのか？を記述していきます。これは、要件定義と対になるもので、いわゆるプロジェクト予算を作るときに利用します。ただし、実際のITプロジェクトの契約では、要件定義段階で契約することが多く、概要設計を作らずに（あるいは概要の概要みたいなものは作る）契約してしまうことも多いのですが、これは別の問題なのでここでは議論しません。
詳細設計は、概要に従ったものを具体的にクラスやフレームワーク、関数や、シーケンスなどを考慮して記述していきます。近年「詳細設計」を飛ばしてしまうことが多いのは、概要設計から実装（WEBの各種フレームワークやプロトタイプ、ノンコーディングできる実装環境など）が繋ぎやすいところにあります。いわゆる、スクラッチビルドが試せる環境が整っていたことがあります。逆に言えば、プロトタイプビルディングができない環境である場合は、詳細設計が必須です。
実装は、実際にコーディングをして動かす部分です。これに対しても以前はモジュール設計、クラス設計などを記述して分離させていた時期もあるのですが、最近では詳細設計に入れてしまう場合が多いです。これは会社のプロジェクトによって異なるところです。
UMLは、かつては概要設計と詳細設計の両方で使われる可能性があったのですが、現在はあまりUMLで書いてある仕様書を見かけません。これは有償のケースツールの衰退もあるのと、UML自体が細分化されてしまって、忌諱されてしまったためでしょう。
UMLを記述する場合は、最低限
・クラス図
・シーケンス図
・オブジェクト図（これはなくてもよい）
・状態遷移図
・ユースケース記述
だけ覚えればOKでしょう。これは時間と具象/抽象の４象限でわけたものです。
ただし、これ自体はここでは議論しません。
詳細設計は誰のためにつくるのか？
さて、詳細設計は誰のために作るのか？をパターン分けしておきましょう。先のアンケートを分類すると、
- 詳細設計書と実装が別の人
- 詳細設計書と実装が同じ人
- 詳細設計を書かず、実装のみ
のパターンに分けられています。それぞれ、意味があるので何がよいという訳ではありません。ITプロジェクトの状態に沿った形で、詳細設計を書くかあるいは省略するかすればよいのです。
詳細設計と実装が別の会社の場合
契約上、詳細設計と実装が異なる会社の場合があります。かつての中国オフショアなどがそれで、日本で詳細設計書を書いて中国のプログラマに発注していた時期があります。オフショアに限らず、子会社は外注に出すパターンはこの組み合わせが多いです。ただし、WEBサイト開発のような場合は、概要設計や画面設計から実装へ進む場合も多いので、これは情報システムや銀行系の場合に多いですね。
それぞれの会社が別なので「瑕疵」という契約が発生します。どのような場合に「瑕疵」となるのか、不具合をどのように直すのか？が問われるところなので、契約のために「詳細設計書」が必要になります。
別の会社であっても、派遣社員や準派遣の場合は、発注会社が責任を持つことが多いので、詳細設計書を省略しても契約上問題ありません。
詳細設計と実装が同じ会社（人）の場合
同じ会社であり同じ人であるならば詳細設計を作らずに、画面設計からいきなり実装に移ることも多いでしょう。保守運用的に詳細設計を残す或いは残さないの判断もあるのですが、実装する人の経験が浅かったり、ロジックが複雑怪奇であったりする場合には、詳細設計書を書くのがベターです。
詳細設計といっても、コードと逐一同じものを書くのではなく、UMLなどを使いながら簡略化していきます。
私の新人教育では、
・箇条書きで詳細設計を行う
・シーケンス図を記述する
ことにしています。シーケンス図はプログラムコードが入り組んでいた時、タイミングが微妙なときを考察するのに便利です。基本的に詳細設計は使い捨てです。そのままコードのドキュメントとして残すか（文芸的プログラミングのように）、単なるメモ書きとして記録しておくだけでよいでしょう。
コードレベルの詳細設計は書かない
先のアンケートの結果を見ればわかる通り、私は「コードレベルの詳細設計」は書きません。しかし、場合によってはシーケンス図のような詳細設計を書きます。
このアンケートで答えた人がどの位の「詳細設計書」を考えているかわかりませんが、分布としては形式的な詳細設計書はなくなっていく傾向にあります。
ここで注意しておきたいのは、
・アジャイル開発だからといって、詳細設計が存在しない訳ではない
・ウォーターフォール開発だからといって、詳細設計が必須な理由はない
ということです。ITプロジェクトのスタイル（アジャイル開発、計画駆動、イテレーション開発などなど）に問われるものではありません。アジャイル開発においても「設計書」は情報共有のために必要となるので、そこに囚われる必要はないでしょう。
設計書からコードを出力するツールはあるのか？
あると言えばあるんですよ。
記事を見ると解る通り、みずほ銀行の件は失敗しています。失敗していますが、詳細設計書からコードを出力するツールはあるんです。あるんですが、失敗しています、ということを覚えておくことが重要です。
個人的には MDA の復活になると思うのですが、それがいつ頃になるかわかりません。Scratch とか Node-RED のツールとかがそれに近いです。各種のノンコードツールもそれに近いものがあります。ノンコードツールの延長線上にあるとは思えないのですが、一種ではあると思われます。
参考先
図解即戦力 PMBOK第6版の知識と手法がこれ1冊でしっかりわかる教科書
図解即戦力 アジャイル開発の基礎知識と導入方法がこれ1冊でしっかりわかる教科書 Kindle版
図解入門 よくわかる最新 システム開発者のための仕様書の基本と仕組み
