「詳細設計書不要」「コメント不要」について

「詳細設計書不要」「コメント不要」について。
これらは「不要な（と思われる）ものを作るのに工数を掛けたくない」「メンテの範囲を少なくしたい」という欲求からの発言であろう。

そも「詳細設計書」「コメント」も必要性があって存在する。
それを無視して一概に不要というべきではない。
無論、不要論を唱える者のはその者なりの理由があるのは分かる。

いわく、コード＝詳細設計書なのだから、コードを読めばいい。コードから詳細設計書を作ればいい。
いわく、コーディングしてみないと、出来るか分からない。
いわく、コードを修正したら、詳細設計書も修正しなければならない。でも出来ないことがあるから差異が出てしまい、意味がない。コメントも同様。意味が無いものを作る必要性はあるだろうか。いやない（反語）。

でも待ってくれ。それってオカシイと思わない？
詳細設計書の存在意義は、コーディングする前に設計するためにある。設計工程で不明点を明確にしたり、モジュール間の整合性を取ったりするのだ。（加えて言うなら、設計書からテストを起こす。本来、あるべき動作（仕様）を確認するのがテスト。コードからテストを作るのではない！）
コード＝設計仕様書なのではなく、要件定義→外部設計→詳細設計→コーディングの流れの一つの工程で結果的にコード＝設計仕様書となるだけ。時間がないから詳細設計書を書けなくてコーディングと詳細設計を同時に行い、コードから詳細設計書を作るという本末転倒なチームや顧客は居る。だけど、それはオカシイ。オカシイ作業がまかり通っているだけ。そして、そういう所は大概、品質が悪く、保守性が悪く、失敗プロジェクトが多い。
作業の意味を考えず、必要な作業をすっとばしているのだから当たり前だ。

一方、コメントは（詳細設計のように）工程の一部ではないので、入れる義務はないと思われるかもしれない。
でも、コメントは”保守性”を高めるために、機能の意味を説明するためにある。
”保守性”は工程ではなく、もっと長いスパン（システムの寿命）で必要となるものである。
「コードは読めば分かるように書く」というのは、もっともなのだが、それにはチームの文化を全員が保持しており、そのコードの保守をその文化を持ったメンバが保守できることが前提となる。
でもチームのメンバがずっと同じであることはほとんどないだろう。企業は、組織の硬直化を防ぐために、チームのメンバが変える必要がある。チームからみると構築された役割が壊され品質を下げるようなデメリットしか感じないだろうが、様々な知識や方法論を広げるという役割がある。

何にしろ、存在意義を無視して特定の条件でしか成り立たない危うい過激な意見に同意しても、益はない。存在意義を理解し、その上で改善を行い、成果物を排除できるような環境を作るってのはありかもしれないけれど、それって環境を育てるのに時間がかかるし、あっという間に壊れそうだよね。素直に詳細設計書をちゃんと作る、コメントをちゃんと入れる、メンテもちゃんと行うって確認するルールを作って運用する方がナンボも簡単だと思うんだけど。