詳細設計書、やめませんか？

アプリケーションを開発する時のドキュメント。色々ありますよね。要件定義書・概要設計書・詳細設計書・運用設計書・テスト計画書等、様々なドキュメントを作成します。作業の前に力をいれるあまり、プロジェクトが終了した時にあまり役に立たなくなっているドキュメントがあります。

詳細設計書です。

アプリ作成の潮流の変化

ここ20年くらい、業務アプリはシステムインテグレータ（とそのパートナー会社）がドキュメントを作成し、下請けプログラマーや海外のプログラミング集団が実装を担当する　というのが多かったと思います。なぜかと言うと、儲けの仕組みが単価x人日となっており、人日を膨らまし、仕入れ単価を抑え見積もり単価を高くすることで利鞘を増やすビジネスモデルだからです。単価の安い人材を求めると、東南アジアやインドなどのプログラマー集団が良い候補となり、彼らの真面目さ等がちょうどよかったのではないでしょうか。
そのためには詳細設計までしっかり書くことが必要でした。なので、概要設計書から詳細設計書を起こすことが、お客様付きのシステムインテグレータの主な仕事になっていたわけです。

ところが。

長期プロジェクトになった時や仕様が固まりきっていない中で実装を開始した時など、詳細設計書を変更しないといけない状況が多く発生してきます。このやり取りが足かせになって、仕様書に落とすこと無く口頭やメモで仕様を伝えられたり、性能テストをやってみたところ、その仕様では性能を満たせないことが判った時等に、仕様書を修正することなくソースコードを直接修正するということが増えてきます。

もっとも、最近の潮流としてはウォーターフォール型ではなく、アジャイルに近い繰り返し型の開発が流行っていることもありますが、なおのこと、詳細設計書の立ち位置が微妙になりつつあり、アプリケーションがGo liveになった時には、最新の仕様はソースコードを見てくれ　という状態になっています。

そしてかなりの確率で、Go Live後に詳細設計書が修正されることはありません。

詳細設計書はページ数も多くなり、内容も実装レベルまで詳細になることからも書くことが非常に多く、多くの工数が費やされるのに、です。

ナレッジの継承という目的へ

そこでの提案です。

昨今の日本と海外の関係は、ドル円レートや人件費の違いなどから、むしろ日本国内で実装するほうが安い時代となっています。わざわざ海外に依頼する必要もなくなっていますし、働き方の自由度も上がってきており、お客様とのミーティングにプログラマーも参加し易い環境になってきています。
実装段階の前に作成した「概要設計書」の確からしさを確認する必要もあるはずで、概要設計書とお客様との会話から直ぐにモノを作り、認識合わせをしていくという作り方の方が生産性が高くなっているのは、皆さんも気づいているはずです。

であれば、モノを作った後に詳細設計書を書いたほうが良くないですか？

むしろ、「詳細設計書」という名前を変えて、「実装メモ」という形で、なぜそのような実装をしたのかの「理由」を記載しておく方が、後々のためになると思います。確からしさが検証されていない「設計書」には、現場の知恵である「理由」が記載されることは稀で、後から見直しても「ふーん」としか思われない文書になっているのではないかと思います。
アプリが長期間にわたって動いている場合、なおのこと「なぜそのような実装にしたのか」は人づてにしか伝えられず、配属替えなどの後にはせっかくのノウハウが継承されなかった、というプロジェクトを星の数ほど見てきています。

実装の時に判った仕様書の間違いや、言語特性や業務特性を突き詰めた時の考慮点等は、プログラマやシステムインテグレータを成長させるこの上ない栄養なはずです。デキるプログラマやインテグレータは、その実装に至った理由などをきちんと記述しています。

また、業務ロジックなどはルールエンジンを使うことで「意思決定表」というエクセルベースの表形式で表現できます。業務側が考えたことを整理し、意思決定表で意見交換するだけでも、かなりの効率化・品質向上が見込めます。実装した意思決定表をそのまま実装メモ（詳細設計書）にすることができます。

ということで、プロジェクトにおける「詳細設計書」を実装前に作成するという行為、もうやめても良い頃ではないでしょうか。
実装後のドキュメント化には、実装の可視化・工数の短縮・品質の向上・人員の成長・技術の継承等、利点しかありません！