ITコーディネータの吉田聖書です。
今回は、前回の補足です。
前回の記事には思いの外反響があり、
もう少し掘り下げた方がいいかなと思った次第です。
私がこれまで関わった開発プロジェクトについて、
SE時代にまで遡ってふりかえってみると、
大変だったかどうかは置いておいて、
品質の良かったシステムは
詳細設計をきちんと書いていたなということです。
「きちんと」というのは、
詳細設計書を書いたというだけで
実質的な設計が行われていないケースがあるためです。
最近のシステム開発は、
年々要求されるスケジュールが厳しくなってきており、
それだけに仕様書を書くぐらいだったら
先にコードを書いてしまった方が早い
という圧力が強まっているという実感があります。
でも逆に、そういう圧力のせいで
充分な詳細設計を行わずに
プログラミングに着手してしまうと、
担当者によって書き方がバラバラであったり、
共通モジュールがあるのに
使う人と使わない人が出てきたり、
同じような処理をそれぞれで書いたり、
結果としてそれらを調整する工数が膨大になります。
それでもなぜか、
詳細な設計を行わずにプログラムを書くことが
絶対に正しい前提となり、
コードレビューをしっかりやろうとか
そういう方向に向かってしまいます。
そんなコードレビューは散々であり、
レビュアの負荷が高くなるので見逃しも増えます。
プログラミング担当者にもよりますが、
レビューでの指摘を完璧に取り込めない人もいて、
レビューして修正して、
再レビューして再修正して、
再々レビューをして…と、
そんなにレビューに工数をかけるのであれば
同じ工数をかけて詳細設計をやればいいのに
とさえ思ってしまいます。
確かに、詳細設計書を作成した場合、
そのメンテナンスのコストも課題になります。
いわゆる「仕様バグ」が発生した場合、
設計書が無ければコードを修正するだけで済みますが、
設計書がしっかり書かれていればいるほど
修正にかかるコストがかかることになります。
なので、最近では詳細設計書を作る代わりに、
完成したプログラムから
モジュールの仕様書を吐き出すようなツールが
もう10年以上も前から使われています。
しかし、そのようなツールは「後付け」であり、
設計の品質が悪ければ、あまり意味がありません。
アメリカのソフトウェア工学者、トム・デマルコは
「デッドライン」という書籍の中で次のように述べています。
コーディングの段階になってほんとの設計をやっている。コーディングの最中に、だ。そのころになって、実際のモジュールをどうするか、実際のインタフェースをどうするか決めてるんだ。しかも、そういう結果はレビューされない。
トム・デマルコ著「デッドライン」（日経BP社）・180ページ
また、設計として特に意味のある点は、
「インタフェースの定義」だと述べられています。
画面や帳票などのユーザインタフェース、
ファイルやデータベースなどのレイアウトだけでなく
モジュールのインタフェースにも言えます。
よく見かける設計の記述として、
処理のロジックについては書かれているけれども、
インタフェースについては
充分に書かれていないケースが多いです。
（私が過去に書いた設計書の中にも、不充分だったと思い当たるものがいくつもあります。反省）
しかも、テスト工程において
デバッグに苦労するのは、
そういったインタフェースの不整合に
起因するものが多いのです。
（ちなみに、どのシステムでも共通して
バグが多いなと思うのは
日付と時刻に絡む処理ですが、
インタフェースの不整合に比べれば
デバッグは容易です。）
コードレビューも
コーディング標準に従っているかとか
業務ロジックがコードに反映されているかが中心で、
モジュールレベルの詳細設計が無ければ
インタフェースの整合性の指摘は困難です。
インタフェースの不整合というのは
「私はこう思っていた」という
担当者間のすれ違いですので
本当の詳細設計で潰しておきたいところです。
例外として、
既存のコードをほぼ流用するような開発の場合、
同じような設計を一から実施するのは無意味ですから、
コードと一緒に詳細設計書も流用した方が良いでしょう。
関連記事
プロマネの右腕
プロジェクトマネジメントの支援を行っています。
新サービスの企画を任されたけど どう進めていいか悩んでいる担当者、
部下に新しい企画を任せたけど このままで大丈夫か不安な管理職の方、
以下のサイトをご参照ください。
https://www.crossidea.co.jp/services/right-hand-pmo.html
YouTubeにて動画配信中！
プロジェクトマネジメントのノウハウをYouTubeで配信しています。
ブログと併せてご活用ください。