詳細設計書は必要か

ヘッダー広告
スポンサードリンク
Seirで働いていると、ほぼどの現場でも詳細設計書の作成を求められると思います。
しかし私は詳細設計書は無駄な成果物だと感じることが多いです。

詳細設計書とはどういうものか


詳細設計書には、プログラムのロジックレベルでの記載をする現場が多いと思っています。
IF文、LOOP文、変数のセットとプログラムで表わすのであれば、その1行1行全てを逃さず記載するのが、多くの現場で作成している詳細設計だと思っています。

そもそも本来の各設計書とはどういうものを記載するものなのでしょうか?

外部設計書であれば、各画面のレイアウトから、テーブル構成、大まかな処理の内容、IFファイルの形式など、ユーザーから見えやすい部分であったり、処理の基盤となる部分をその処理の目的がわかる程度に(概要レベルで)記載するものだと思います。

内部設計書では、外部設計書から踏み込んで、具体的にその処理の目的を達成するためにどうするのか、どのデータを使用して、どう処理して、何をどの形式でどんな風に出力するのかという細部まで詰めて記載するものだと思っています。
成果物で言うならば、処理フロー(本当にフロー図を作成するのではなく、文字で順番に)、DB取得条件、バッチの起動時間や順番を記載したフロー図などです。
内部設計書の注意点は、あくまでもプログラムレベルの粒度にはならずに、実現したいことをどう処理すれば良いかが分かるレベルでという記載が重要です。

最後に今回私が問題視している詳細設計書ですが、プログラムにそのまま出来るレベルでの記載かつ、例えばその変数がどういった意味を表すのかを日本語で表現したり、SQLを記載したりと実際にプログラムを作成するよりもずっと時間がかかるようなものを作成する必要があります。

分岐処理(if文)やループ処理(loop)も文章で表現します。
インデントが文章では作成しにくいので、該当処理がどの条件に一致する際に実行されるのかなどは分かりにくいと感じます。
また、複雑な機能に関する処理であれば、設計書が何枚、何十枚にもなってしまい、全て確認するのにも苦労してしまいます。

このようなものが私の思う詳細設計書になります。

詳細設計書の良い点


詳細設計書は良い点を必死に考えてみます。
ただし、その後に私なりの反論まで記載します。

プログラムが書けなくても読める


詳細設計書では、一つ一つの処理に対して、説明書きがなされます。
そのため、例えそれを読む人が実際のプログラムを読めなかったとしても、ある程度の処理は理解出来るというのは利点だと考えます。

ただし、プログラム上にもコメントを記載することがほとんどだと思うので、私としてはここは利点だとは感じないです。
また、そもそもプログラムを読めないような人が、詳細設計書のレビューをするのは無謀だと考えます。
#プログラムを理解出来ていない人の多くは、詳細設計だけでなく、要件定義から設計まで全ての工程で対応できないもしくは出来ているつもりになっているだけだと思います。

詳細設計書からコードが自動で作成できる


私の現場では、詳細設計書からコードが自動で作成できるようになっています。
もちろん全ての処理の作成を自動化することは不可能ですが、セッター/ゲッター、daoファイル、ビジネスロジックの大枠、定数ファイルなどは自動作成出来ます。
また、自動化することで、ロジックがある程度統一化出来る(個人の独自なロジックにならない)ようになります。

ここに関しては良い面も多々あると思います。
セッター/ゲッターを全て手で作成するのは馬鹿らしいですし、ある程度定型的なところなんかも自動化出来るのであればした方がずっと効率的です。

ただ自動化出来ない部分に関しては、設計書とコードで重複してしまうので、自動化出来る部分だけ詳細設計書として作成するとすると効果が高いのかなと思っています。

コーディングが正しいか判断する指標となる


コーディング内容の正当性を判断するためには詳細設計書が重要だという意見ですね。
内部設計書では、詰めきれていない部分も出てくると思うので、その部分での処理方法が正しいかを判断するには、詳細設計書が必要であるというものです。

ただここに関しては私は全くそうは思わないですね。
内部設計書とコーディングを見比べて、バグかどうかの判断が出来ないということはほぼほぼない(むしろそういう状況が今思いつかない)ですし、コーディングの段階で、ロジックの自由度は多少あっても良いと思ってます。

そのうえで処理内容が正しいか判断出来ないというのは、内部設計書から前の設計を理解していないだけだと思います。

というわけで私としてはここは良い点でもなんでもないということです。

悪い点はなにか


上記で悪い点も書きましたが、更に悪い点があるとすれば何かということです。

コードを見た方が手っ取り早い


詳細設計書を確認するくらいであれば、コードを直接見た方が理解が早いと思います。
詳細設計書は1クラスでも何ページ何十ページにもなってしまうので、1画面で確認出来る行数はそれほどなく、確認に時間がかかってしまいます。
また、EXCELが開く動作の遅さにイライラしてしまい、結局は動作の軽いテキストファイルをそのまま開いて確認するということをやっています。

(私はソースレビューの際、Eclipseを使用して確認するのではなく、テキストエディタで確認しちゃいます。)

また、アプリケーション保守を行っていると、今回の修正がどこに影響があるのかを調べるために、ソースコードをgrepで調査してします。

詳細設計書を一つ一つ読むよりも、ソースを確認した方が圧倒的に速いということが本当に分かる瞬間です。

コードと一致していない設計書がある


これは今の現場ではあまりないですが、実際のコードと設計書が一致していないことがあります。

前回の記事でも記載しましたが、EUC開発であったり、システム統制が出来ていない現場の場合には、この問題はよくあるのではないかと思います。

何回も記載しますが、詳細設計書の作成は実際にロジックを作成するよりも時間がかかりますので、緊急性の高い対応を行うような場合には、先にプログラムを修正してしまって、後々設計書を修正しようとして忘れてしまう。もしくはめんどくさくなって対応しない等があり、コードと設計書が一致しないことがあります。

こうなってしまうと設計書としての意味が全くなくなってしまいます。

むしろ設計書が正しいのかコードが正しいのかわからなくなり(多くの場合コードが正しいのでしょうが)、無駄な調査時間がかかってしまいます。

以上が私の考える詳細設計書の悪い点です。

このように振り返ってみても、やはり詳細設計書はいらないのではないでしょうか?

Sierで働いていて強く思うのですが、過去の実績に縋り付いていて、新しい取り組みには消極的だと感じます。

そのため、詳細設計書をなくすというのもなかなか出来ないのではないかと思います。

Web系の方とはお話したことはないのですが、そういった無駄なことを排除しているように感じるので、Sier企業も良い点は真似してほしいなぁと思います。

私は今後も、無駄だと感じながらも詳細設計書のレビューをしていきたいと思います。

機会があればなくせるように(減らせるように)発言していけたらなと思います。
フッター広告

スポンサードリンク



シェアする

  • このエントリーをはてなブックマークに追加

フォローする