詳細設計といえば、ウォーターフォール手法にて取り入れられる、プログラムの内部の振る舞いを定義するプロセスです。
内部の振る舞いといえば、クラスやメソッドまで全てを指しますが、近年ではこの詳細設計が不要であるという風潮が強くなってきました。
設計書を書くことにも莫大なコストがかかりますし、そもそもそんなことをするなら直接ソースコードを書いてしまった方が遥かに無駄がない、ということです。
今回は、そんな詳細設計について少し考えてみましょう。
詳細設計の役割とは
プロジェクトメンバーは、必ずしも均一な能力を持っているわけではありません。ベテランの技術者もいれば、業務経験の無い新人もいます。経験の浅いメンバーを育成していくことが大事で、そのためにベテランの頭の中を効率よく伝える方法が詳細設計書というわけです。
プログラムは自由です。実装方法に正解はなく、仕様通りに動けば何の問題もありません。
ただ、それはプロダクトの設計から実装、運用までの全てを自分一人でやる場合にのみ許されます。チーム開発において、プログラムは、限りなくシンプルで読みやすく、かつメンテナンスが容易なように記述されるべきなのです。
これは、プログラマにとって永遠の課題です。古くはGang of fourのデザインパターンに始まり、あらゆる設計の雛型が作られてきました。
話がそれましたが、つまり詳細設計書とは新人教育のための教材でもあったわけです。
ウォーターフォール
ここまで、詳細設計書の教育的側面にフォーカスして考えてきました。次に、ウォーターフォール開発手法のプロセスに焦点を当ててみることとしましょう。
細かい説明は省略しますが、ウォーターフォール手法は、要件定義、基本設計、詳細設計、製造、テストのプロセスを順に踏んでシステム開発を進める手法です。この手法には賛否ありますが、プロセスがわかりやすく、スケジュールを立て易いのが特徴です。
このフレームワークに当てはめて開発を進めるとき、詳細設計は重要かもしれません。ウォーターフォールの設計プロセスは、その後のテストプロセスに重大な影響を及ぼすからです。
ウォーターフォールの設計が要件定義→基本設計→詳細設計と進むように、テストは単体テスト→結合テスト→システムテストと進みます。この設計とテストは密接に紐付いており、テストスコープを決定付けるための有効な材料であることがわかります。
設計とテストの関係性
| 設計 | テスト |
|---|---|
| 要件定義 | システムテスト |
| 基本設計 | 結合テスト |
| 詳細設計 | 単体テスト |
こういったフレームワークに当てはめて開発を進めることは、プロジェクトマネジメントの面で非常に意味があることと言えるでしょう。
ウォーターフォール以外での詳細設計書
ここまで、ウォーターフォール手法における詳細設計書の意義について述べてきましたが、他の開発手法にも目を向けてみることにします。
アジャイルは、開発のプロセスをごく短いスパンで回していくのが基本です。その際、設計書のメンテナンス工数は省力化されていく傾向にあります。
省力化というのは、全くやらないわけではなく、大抵の場合その代替手段が用意されています。例えば、詳細設計がテストファースト手法になったり、基本設計にSwaggerを使ったりします。
画面設計等も勿論行いますが、成果物としてドキュメントを求められるウォーターフォールと違い「ドキュメントに残すことそのものを目的としていない」のが大きなポイントです。アジャイルでは開発速度が大きなファクターとなっていますから、必要最低限、「伝わること」に重きを置いているわけです。
基本設計や詳細設計のプロセスでは、各部品の振る舞いや内部処理を定義するわけですが、アジャイルではこれらを「伝わる程度のメモに残す」くらいのドキュメントしか起こしません。具体的に言えば、プロジェクト管理ソフトウェアのWiki機能に少しのメモを残す程度のものです。それだけで設計や仕様が伝わるのであれば、それ以上の労力を掛ける必要はもはや無い、という考え方です。
詳細設計書の誤解
詳細設計書は、ソースコードを日本語に翻訳したかのようなものであるという誤解を与えがちです。勿論そのような設計書もありますが、多くはクラス設計と処理の概要までを詳細設計書として落とし込んでおり、メソッドの内部の振る舞いには言及していないことが多いです。
何故詳細設計書が不要なのか
現代に至るまで、ペアプログラミングをはじめ、様々な指導方法が考え出されてきました。これらは詳細設計書を書いて渡すよりも、遥かに効率のよいやり方です。
つまり、詳細設計書が一部担っていた教育という側面は、新たな手法に取って代わられたわけです。
では、詳細設計書の別の役割は何でしょうか。これは、実装者のクラス設計や方式の設計が正しいかどうかを事前にレビューし、「クラスの組み直し」を防ぐ意図があります。コードレビューではコストが掛かりすぎてしまうというわけです。
ただ、こちらも詳細設計書を起こすコストとソースコードをそのまま記述するコストを天秤に掛けると、やはりソースコードを直接レビューしたほうが早いかもしれません。結局のところ、プロジェクトメンバの習熟度によってこの結論は大きく異なります。
もう一つ、先に述べたように、ウォーターフォール手法に当てはめて考える場合、詳細設計プロセスは意味のあるものです。フレームワークがある場合、下手にアレンジを行うよりも、愚直にその手順に従った方が、良い結果となることが多いのです。
さて、これらの使い方が本質的であるかどうかはさておき、詳細設計書も自然発生したわけではありません。ある事実があり、それに対応するために生まれたものですから、それを考えず「必要ない」と断ずることは避けなければなりません。
まとめ
かつてのハンガリアン記法がIDEの進化で過去の遺物となったように、技術の進歩によって詳細設計書も「古臭い」考え方になっていくのかもしれません。
しかし、10のプロジェクトがあれば10のやり方があって然るべきです。もし、詳細設計書の記述プロセスを採用しているプロジェクトがあった場合は、その理由について考えてみたり、質問したりすると納得のいく結果が得られるかもしれません。
また、どうしても納得出来ない場合、より合理的な方向に軌道修正するのはあなたの役目ですが、並々ならぬ苦労を強いられることは覚悟しておくべきでしょう。
いずれにせよ、プロジェクトを成功させるというのが全員の目的であることは間違いありませんから、より効率的な方法を全員で模索することが大切です。「こうでなければならない！」というやり方は存在しませんから、柔軟な思考で道を切り開いて行きたいものですね。