ITコーディネータの吉田聖書です。
今回はシステム開発の話題です。
発注元からの値下げ圧力によって、
システム開発上必要な工程が
省略されることがあります。
特に省略されやすいのが
詳細設計という工程ですが、
今回はその是非について考えたいと思います。
情報システムの開発に携わったことがないと
馴染みが無いかもしれませんが、
一般的なウォーターフォール型開発の場合、
要件定義→設計→実装→テスト
というような工程を実施します。
各工程についての説明は割愛しますが、
設計工程はさらに
基本設計→詳細設計
のように分割して実施されます。
別の表現として
外部設計→内部設計
という言い方もありますが、
いずれの呼び方であっても
前者が利用者視点の仕様を定義するのに対し、
後者は開発者視点の仕様を定義します。
いずれも要件からプログラムへの
橋渡しをする役割があり、
一定以上の品質が求められる場合、
実施しなくてはならない工程です。
いずれも必要な作業なのですが、
発注者からの値下げ圧力により、
工程を省略するように
要請されることがあります。
そして、省略されるのは
大抵の場合は詳細設計です。
なぜなら、基本設計は
利用者視点で仕様を定義したものですので、
発注者としては、
最終的に手に入るシステムが
どのようなものであるかを事前に知る
唯一の手掛かりとなるからです。
一方の詳細設計は
開発者視点で仕様を定義したものですので、
発注者が見ても理解できないことが多く、
そのドキュメント（詳細設計書）に
価値を見出しにくいためでしょう。
しかし、省略するとは言っても
やらなければならないタスクであることに
変わりはありません。
プログラムを書くためには、
プログラムをどのように組み立てるかを
考えなければならないからです。
それこそが詳細設計で行うことであり、
詳細設計書というのは、その考えた結果を
表現したものにすぎないのです。
「詳細設計を行わない」ということが
その言葉通りの意味だとするなら、
プログラムをどのように組み立てるかを考えずに
プログラムを書くということになります。
果たしてそんなことができるでしょうか。
ですので「詳細設計を行わない」
というのは詭弁でしかありません。
仮に「詳細設計を行わない」というのが
詳細設計書を作成しない
という意味だとする場合もあります。
その場合は、
プログラムをどのように組み立てるかを
考えてプログラムを書くけれども、
どのように考えたかを文書化する手間を
削減するという発想です。
これはある程度の品質を犠牲にできるなら
工期の短縮には効果が期待できます。
ただ、簡単なシステムならともかく、
複雑で大規模なシステムの場合は
詳細設計書がないと
ソースコードを読まない限り
プログラムの仕様を把握できない
ということになります。
プログラムを書いた人が
ずっと面倒を見るのであれば
それも取りうる選択肢かと思いますが、
とても現実的ではないでしょう。
代替案としては
詳細設計書を書く代わりに
ソースコードに充分なコメントを付与する
というやりかたもなくはないですが、
プログラムを書いてからしか評価できないため
システムの方針と乖離があった場合、
いくらかの手戻りは覚悟する必要があります。
もちろん、詳細設計をやれば自動的に
品質が高くなるというものでもありません。
詳細設計が意味を成すのは、
先行する要件定義や基本設計の成果物が、
充分な品質を備えている場合に限ります。
いずれにせよ、
工期を短縮し、コストを削減するために
工程を省略するという発想は、
多少の低品質を許容できるのでない限り
採用すべきではないと考えます。
関連記事
プロマネの右腕
プロジェクトマネジメントの支援を行っています。
新サービスの企画を任されたけど どう進めていいか悩んでいる担当者、
部下に新しい企画を任せたけど このままで大丈夫か不安な管理職の方、
以下のサイトをご参照ください。
https://www.crossidea.co.jp/services/right-hand-pmo.html
YouTubeにて動画配信中！
プロジェクトマネジメントのノウハウをYouTubeで配信しています。
ブログと併せてご活用ください。