読者です 読者をやめる 読者になる 読者になる

そごうソフトウェア研究所

SOA、開発プロセス、ITアーキテクチャなどについて書いています。Twitterやってます@rsogo

設計文書のうまい書き方

http://www.hyuki.com/yukiwiki/wiki.cgi?HowToWriteAnEffectiveDesignDocument

結城さんいつもありがとうございます<(_ _)>

「 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す」と、「 第 4 節に書くこと: 利点, 前提, リスク/懸念事項」はほんとに大事だけど、これが定義されていないプロジェクトって、結構ありますよね。


個人的には設計書ではマトリックス(表)を使いまくります。
例えば、システム間連携をするポイントが10箇所あったとして、各連携ポイントの名前を縦に、横軸に連携手法、プロトコル、セキュリティ方式、などなどを書き、各セルを埋めていきます。


各セルを埋めていくときに、いくつか方式が考えられるときには、それをまたマトリックスにして、メリット・デメリットを分析します。これをやっておくと、なんでこの方式を採用したかが思考の過程が記録として残るため、引継ぎをやるとき便利。


マトリックスを使うメリットは、抜け、もれ、ダブりを防げることで、自分の思考の外にあるセルを見つけることができます。

(補足)
列や行に不足が有った場合は、思いっきり抜けます。ですので、最初はなるべく大きい視点でマトリックスをして、可能な限り行や列の不足を防ぎます。