IT 業界というか SIer の枠組みの中で働いている人であれば、一度は詳細設計書ないし詳細仕様書というドキュメントを見たか書いたことがあるだろう。
Excel 方眼紙の悪夢
詳細設計書の話の前にちょっと触れておきたいのが「Excel 方眼紙」 これまでのプロジェクト経験とネットの情報を見る限り、詳細設計書はほぼ 100% コレで書かれている。Excel 方眼紙がどのようなものかは こんな感じ である。典型的な使われ方は 【図解!!コレが方眼紙Excelだ！】:島国大和のド畜生 がわかりやすい。
「Excel 方眼紙」でググるとわかのだが、コイツは猛烈に嫌われている。一発作り捨てならば、図や表を交えたドキュメントをそこそこ作りやすいという利点はある。プレゼンや紙印刷を考えないならば、個人差はあれど PowerPoint 並の使い勝手を覚える人はいる。
がしかし、Excel 方眼紙はそのメリットを遥かに押し潰す問題がありまくりである。私見だが、一言で言えばメンテナンス性が強烈に悪いことにあると思う。追記、修正、レイアウト変更、印刷時向け手入れ……本来やりたい修正作業そのものは大したことがなくても、そのために必要な Excel 方眼紙をキレイにする作業がその都度発生し、結果的に膨大な時間がかかってしまう。
プログラミングに必要だと誰かが言うけれど、邪魔にしかならない詳細設計書
詳細設計書の話に入るがこれに何が書かれているかというと、暴論承知で言うと、プログラムのコードと一対一で対応する自然言語の記述である。ただし実態は、一対一で対応する「ことになっている」というだけの代物である。プログラミングするにあたっては役に立つことはあまりないどころか邪魔になる。詳細設計書の問題点については、比較的最近のエントリでは 詳しすぎる詳細設計書 - SiroKuro Page が参考になる。
Excel 方眼紙と詳細設計書の極悪な蜜月関係は少なくとも 2001 年頃には認識されている*1。想像ではあるが、90 年代には既に Excel 方眼紙と詳細設計書でソフトウェア開発回すのはムリがあるんじゃないの、とはみんな薄々感づいていたのではないかと思う。問題点ありまくりのこれらはそろそろ退場していてもいいはずなのだが、今でも方々から悲鳴の声が聞こえてくる。というか、俺もつい数ヶ月前まで悲鳴を上げていた。
詳細設計書は現代版コーディングシート
俺が詳細設計書に出会ったことがあるのは、三つの異なるプロジェクトで三回。それぞれ取引関係なんかは全くことなる三つの元請の下でのとである。しかし、要求される詳細設計書は細部は違えどほとんど同じものだった。最初に出くわしたのは 10 年ほど前で、そのとき既にイライラしながら書いていた詳細設計書を、つい最近書かされることになって頭がどうにかなりそうだったのを良く覚えている。
10 年前も詳細設計書にイライラしていたのを良く覚えていて、以来、詳細設計書とは何なのか？ なぜ書かなければならないのか？ という疑問はずっと無くならなかった。それで、三つの異なるプロジェクトで「なぜ詳細設計書が必要なのですか？」と先輩や上司に聞いたことある。返ってきた答えは「詳細設計の工程では詳細設計書を作ることになっているから」「元請が詳細設計書を要求しているから」だった。新人のころは「それがソフトウェア開発というものだ。新人のお前にはわからないだろうが 10 年泥のように働けばそのうちわかる」というのはちょっと脚色入ってますがそんなような有難い説教を賜った記憶すらあります。
それで、詳細設計書は何なのかという問いに対する俺の仮説なのだけど。詳細設計書はコーディングシートなのではないか？ と考えるようになった。この前提を置くといろいろなことに辻褄があうような気がするのです。
コーディングシート*2というのは、ソースコードの一行一行を紙に書いたものである。こう書くと、特に若い層はそんなもんが何故必要なのか疑問しか浮かばないだろうけど、コンピュータを利用することが高価だった時代には必須のものだったのである。ごく簡単に言えばコンパイルするのにすら金がかかったので、まず紙の上で完璧なソースコードを作り上げていたわけです。もちろん紙に書かれたコードなので動作させようがないのだけど、人よりもコンピュータのほうが高かった時代にはそれが最も効率的なプログラミングだったわけです。
この時代においてのプログラミングとは、紙の上で動かないソースコードを如何に完璧に作り上げるかがキモだったわけです。それを踏まえた上で詳細設計書を見ると、詳細設計書はプログラムと一対一で対応する日本語で書かれている（ということになっている）。 紙にソースコード、Excel に処理概要を記した日本語、という相違はあるが、その根底にある思想―完璧なドキュメントが作られればプログラミングは完了したも同然―はすごく似ていると考えられる。さすがに Excel 方眼紙にソースコードを書くことは無くなった*3だろうけど、この思想の一致が、詳細設計書はコーディングシートなのではないか？ という仮説の根拠なワケです*4。
詳細設計書が Excel 方眼紙の升目に埋め込まれるのも、あれはコーディングシートの名残、と思えばある程度納得がいくわけです。
詳細設計書は百害あって一利なし……作る内容によっては一利ぐらいはあるかもだけど。コンピュータの性能が上がり利用コストが劇的に下がった現代においては、詳細なロジックを実行不可能な自然言語で記述して人間が逐一検証するより、とっととコンピュータ上で動作してコンピュータで検証できることはガンガンコンピュータにやらせたほうが合理的だ、との意見に異を唱える人はまずいないでしょう。なので、このエントリでは詳細設計書は要らない理由についての記述は、これ以上は省略したいと思います。
今までそうだったから、これからもそうなる
次に、なぜ詳細設計書が無くならないか？ について考えたい。その前に最近はてブで話題になった 優秀な技術者が「無能化」していく悲劇 日本半導体が陥った「組織のジレンマ」とは：JBpress(日本ビジネスプレス) を読んでおきたい。正直、これを読んで頭がクラッと来た。特に、256MビットDRAMの工程フローは複雑になっている理由の下り。256MビットDRAMの工程フローを作成したインテグレーション技術者は64Mのフローにあったからという回答をし、64Mの工程フローを作ったインテグレーション技術者は16Mのフローにあったからという回答をし、16Mの工程フローを作ったインテグレーション技術者は4Mのフローにあったからという回答をした、のくだりにはかなりショックを受けた。
俺にはこれは「元請が詳細設計書を要求しているから」と似たような現象に見えた。恐らく、元請の中の人に聞いてもせいぜいが「開発標準でそういうことになってるから」以上の回答を得るのは難しいんじゃないだろうか。今までそうだったから今もそうしている、以上の理由はおそらく存在しないのではないだろうか。
そう考えると、詳細設計書は現代にまで生き残ってしまったコーディングシート、という仮説もそんなには外してはいないと思う。今までそうやって開発をしていた人が開発技術から離れて上に立ってソフトウェア開発を指揮するため、今までのやり方でソフトウェア開発を指揮することになる。その連鎖がずっと続いて、コーディングシートまがいの詳細設計書が今でも生き延びてしまっている。下記の引用文のうち、DRAM や微細化の進展といった半導体業界の用語を SI の世界の用語に置き換えても大して遜色は内容に思える。
「何ということだ、DRAMの工程フローは、数学的帰納法で作られているのだ。また、DRAMの工程フロー全体を誰も理解していない。そして、微細化の進展、新構造や新材料の採用により、工程が増えることはあっても、決して減ることがない！」
優秀な技術者が「無能化」していく悲劇 日本半導体が陥った「組織のジレンマ」とは：JBpress(日本ビジネスプレス) より抜粋
組織のジレンマを越えない限り詳細設計書は滅びない？
今までというか例の記事読むまでは、こうした組織のジレンマは SI 業界特有の現象だと思っていた。35 歳定年説ってヤツで「そろそろキミも技術ばかりにかまけてないでマネージャーを目指しなさい」といって、順繰りに皆課長になっていく。大企業ほどこの現象は顕著らしいんだが、給与と地位が連動している以上、どうしてもこうなってしまうようだ。ただ、これは例の記事にもあるように、どんな会社にも起こりうる「ピーターの法則」とのことだ。
技術はどんどん複雑・発展しているのに、仕事はぜんぜん減少しないどころか増え続けるのは、そして詳細設計書が無くならないのは、どうもこのあたりに理由がありそうだ。
昔は「詳細設計書なんてアホなもん作ってもプログラミングには何の役にも立たないんだよふぁっきゅー！」と言い続けるのが、詳細設計書を滅亡させる手段だと思っていたけど、どうも事態はそんな簡単じゃぁないっぽい。
じゃあ一体どうすればいいのかってのはマッタク思いもつかない。まぁカンタンに無くなるもんだったらとっくの昔に滅びてるわけだしねぇ……もし、解消することが出来たら、ないし処方箋を思いつくことができたら、いつか blog に書きたいです。
