「詳細設計書F**k」「SIer、Sxxt」的なお話は定期的に（日常的に？）ネットやTwitterのタイムラインを賑わせているように思います。つい先日もそんな感じのblogエントリが少しバズっているのを目にしました。
よくdisられる感のある詳細設計書*1。これは作られるのでしょうか。必要だから？ではなぜ必要？
『最近の開発では詳細設計書は必要ない』というニュアンスの発言も耳にします。では昔は必要だったのでしょうか。そもそも何のために生まれたのでしょうか。
……話しは変わりますが、今私はちょうど、年度末のアレコレでとても現実逃避したい気分だったりします。ということで、気分転換に、昔のことを思い出しながら与太話を書いてみたいと思います。
これから書くお話は、以前 ― 正確な時期は覚えていませんがおそらくは10年前くらい ― 私がSIerに勤務していたころ、今でも尊敬している大先輩のエンジニアの方と交わした会話です。
＊＊＊＊＊
当時私は比較的大規模な開発の末端開発要員としてアサインされ、連日の深夜残業や徹夜の連続をこなしていました。 スケジュールは遅れに遅れ、ウォーターフォールのはずがダムにせき止められ時には逆流する。デスマーチが常態化していたような現場です。
そんなある晩。そろそろ日付が変わろうとしているに関わらず、いまだ熱気を帯びたまま多くの人が働いているフロア。
私はその片隅で『ソースコードから詳細設計書を起こす』という何とも矛盾した作業を行っていました*2。あまり詳細には覚えていませんが、Doxgenやいくつかのソースコード解析のツール、自作のマクロなどを使いながら作業をしていた記憶があります。
当然、愚痴の一つや二つも出てくきます。その時も軽い気持ちで、隣で作業していた先輩にこぼしました。
僕「こんな作業無駄ですよね……」
先「まあぶっちゃけ無駄だよね」
僕「じゃあなんでこんなの作る必要あるんですかね」
先「ISOだとか社内規定とかで最初にプロジェクトのアウトプットとして定義したから作らないと監査に通らないからだよ」
僕「身も蓋もないですね」
先「事実だからね」
……
僕「そもそも論なんですが」
先「ん？」
僕「詳細設計書って何のためにあるんでしょうか」
先「というと？」
僕「概要設計書とかインターフェイス設計書とかは事前にドキュメントで作ってレビューする意味はあると思うんですよ。プロジェクトの規模や進め方によるとは思うんですけど」
先「ふむ」
僕「でも、詳細設計書で書いてる内容って、先にコードに書いてコンパイル通して、そのあとコードレビューやテストしたほうが早いじゃないですか」
先「そうだね。だからこの切羽詰まった今、そうやった後から詳細設計書を起こしてるわけだからね。今まさに。」
（再度、念のため。ここ述べている詳細設計書は「ソースコードと一対一になっている、プログラムと日本語で書いたようなもの」のことです）
僕「じゃあ、なんでこんな無駄なものが成果物として当たり前に定義されちゃってるんですかね」
先「いや、これだけじゃなくて他にも無駄なモノだらけだけどね（笑）」
僕「笑い事じゃない気もしますけどね。というかそもそも、詳細設計書が『意味がある』ケースってあるんですか？」
先「どうだろう。今の、特にオープン系の開発だとあんまり思い浮かばないなぁ。最近は汎用機系は僕もやってないからそっちの分野は分からないけど」
僕「『今の』ってことは、昔はあったんですか？」
先「そうだねー。そろそろ休憩時間だし、一つ昔話をしてみようか」
（当時の職場では深夜にも休憩時間が規定されていました。チャイムが鳴っていたかどうかまでは覚えていませんが。）
－－－－－－－－
ずいぶん昔の時代。 何年前かって？もう忘れちゃった（笑）。とにかくずっと前の話し。
僕らプログラマの机の上にあった仕事道具って、なんだと思う？
ダム端末？
ブー、不正解。
正解はこう。
デジタルのお仕事してるのに、アナログだよね（笑）。
コーディング用紙って知ってる？ あ、前のXX部の仕事手伝ったときに、棚のファイルでCOBOLの奴を見たよね。そう、あれあれ*3。
当時、『コーディング』っていうのは端末に向かってキーボードをたたく作業のことではなかったと思う。 『コーディング』＝『コーディング用紙にペンで書き込む』作業を指していたんじゃないかな。もちろん手書き。
書くのも大変だったけど、もっと大変なのは『間違いや変更があった時』だった。 想像できるよね？ ちょっとのミスなら消しゴムや修正ペンで直せるけど、ロジックを前に差し挟むとか大きく変更するとか、とにかく修正対象が増えると気が滅入る。 まあ、現場によってはハサミで切り貼りしたりとかもしてた気もするけどね。今でいうカット＆ペーストだね（笑）*4
ともかくこんな状況なので、『コードを書きながらの試行錯誤』はとても効率が良いとは言えなかった。
では、どうやっていたのか。 もうわかるよね。ここで『詳細設計書』が登場するわけ。
詳細設計書を作る段階で、試行錯誤しながらフローチャートを詳細に書いて、レビューして修正して、机上デバッグする。 フォーマット的な正確さを求められるコーディング用紙より、手書きで図や注釈を入れられる詳細設計書の方が、修正の手間も少ないし試行錯誤がやりやすかった。
まあとにかく、これが出来ればあとはコーディング用紙に記述するだけ。『日本語 -> プログラミング言語』の単純な脳内コンパイルだけというわけ。
もうすこし話をすすめようか。この後このコーディング用紙がそのような道をたどって、実行可能なビット列になるかも話そう。僕が経験した現場では、概ねはこんな感じだったと思う。
- コーディング用紙の内容のレビューと机上デバッグ
- コーディング用紙をキー入力専門の「パンチャー」さんに渡す
- パンチャーさんのお仕事の結果「パンチカード」が出来上がる
- パンチカードを電算室に持って行って読み取ってもらう
- 読み取った結果をコンパイル
- コンパイル結果を実行
コーディングが終わってから実行して動作確認できるまで、これだけのステップが介在するんだ。今から考えるとのんびりした時代だったよね。ビルド中にコーヒーが飲めるどころの話しじゃあない。
これを考えると、今はすごいよね。 下手すると数日～下手すると1週間かかってたような作業が、『ちょっと部分的にコード書いてコンパイルしてデバッガで確認しながら実行』とかすぐにで出来るようになっちゃったんだから。
えっと。 昔話しちゃったけど、実は僕も詳細設計書が出来た本当の理由はよく知らない。当時は新人だったしね。 けど、少なくともこの時代・このプロセスでやってた時は、本当に意味があるものだったんだよ。 少なくとも僕はそう思ってたし、今振り返ってもそう思う。
＊＊＊＊＊
その後、その場で私が先輩とどのような話をしたかはあまり覚えていません。 （たぶん、休憩が終わって取り留めのない雑談をしながら、喫煙室を後にしたのだと思います）
この話自体は、当時の私の状況などは若干脚色を入れていますが、先輩から聞いたお話自体は、記憶している限りほぼそのまま書いたつもりです。 そしてその先輩が大嘘をついているとは思えないので、少なくとも先輩が当時いた現場では、概ね事実だったんだろう、と私は信じています。
えっと、なんでしたっけ。 そうそう、詳細設計書の話しでした。
先輩が語っていたように私も詳細設計書の存在価値がそこだけにあったのかどうかはわかりません。生まれてきた理由も同じく。でも私にはそれ以外の理由があるようにもいまだ思えません。
さて、なにをどうまとめて良いのかよく解らなくなってきましたし、そろそろ現実逃避をやめて帰ってこないと色々本気で不味いのでおのあたりで与太話は終わります。
一応、生まれて使われてきた理由があるなら、その理由が無くなったなら止めて終わらせる必要もあるよね、というごく当たり障りのないお話でした。
それではおやすみなさい。
……って、寝てはダメだった……作業せな……orz
*1:大前提として、本エントリで『詳細設計書』は、『ソースコードとほぼ一対一で、ソースコードに書くべき内容を日本語やフローチャート等で事細かく記述してたもの』というものを指します。
*3:関係ないですが、私が大学に入学した当時（90年代半ば）、大学の図書館にあったC言語プログラミングの教材ビデオ（DVDじゃないよ、VHSだよ！）ではお姉さんがコーディング用紙の一マス一マスに丁寧に「c h a r 」と書きこんでいて、萌えた記憶があります。
*4:別の汎用機系の現場の昔話で聞いた話だった気がしますが、サブルーチンや一定の処理のかかれた部分の用紙を「コピー機でコピー」して別のコードの紙束に差し込むことを、『ソースコードの物理コピーや』って言ってる人がいました。一般的な言い方かがどうかは知りませんので悪しからず。
