設計書を横串で見る

20万ステップを越えるようなソースや、40画面以上の構築案件など、中規模から大規模な開発は結構多いと思いますが、こういったプロジェクトで実施すべきことがあります。
それは設計書を横串で見るということです。

通常、設計書は各機能単位で作成し、その単位でしか管理されません。私はこれを縦串で見ていると呼んでいます。
これに対し複数の機能を設計書の目次単位で比較することを横串で見ると呼んでいます。

設計書を横串で見ることで、以下のような開発のメリットがあります。
1. 共通機能を提供できるため、各機能を用意に構築できる
2. テスト期間を減少させることが出来る。これは共通機能を厚くテストすれば、機能を利用しているものは機能が利用されていることだけを正しく確認すればよいのです。
3. 用語の違い等を是正できます。つまり、人によって表現が違う部分を統一できます。それはつまり、設計書の品質向上に繋がります。
4. 共通機能を別設計書にし、固有の設計書は共通機能の設計書を参照することにより、設計書の修正のしやすさを向上できます。
5. どの機能がどの共通項目を利用するか、横串で確認しまとめることで、全体にわたる修正が発生したときにどの画面が対象かを即座に調査できる。逆に言えば、それをすることが横串で見るという事。


設計書は縦串で見ると、例えば画面設計書であれば以下のような目次を考えることが出来ると思います。

1. 画面の概要(だれが、どういった目的で利用するかなど)
2. 画面遷移(どの画面から遷移し、どの画面に遷移していくか)
3. 画面設計(画面のレイアウトなど。こちらは要件定義で作成したモックが多いと思います)
4. 画面項目(画面の入力項目の一覧、入力可能な文字種、文字数、バリデーションなど)
5. BL(Business Logic)呼び出し(実質の業務処理を呼び出し方や引数など)
6. セッション管理(どの情報をどのタイミングで保存したり破棄するかなど。)

こういったものを作りはじめる前から、通常は共通機能の設計が始まっていると思います。ですが、共通機能は先に実施されているという認識が一般的なため、要件定義の後、外部設計フェーズレベルから共通機能の設計が始まり、その後縦串の各機能の設計が始まります。
私の経験上、この最初に作られた共通機能の洗い出しが不十分であることが多いです。正確に言えば、共通機能を本気で洗い出していないか、洗い出すスキルがないことがほとんどです。そして、そのまま縦串の設計が始まり、共通機能の洗い出しは、以降実施されることはありません。

これに対して、私は共通機能の洗い出しは外部設計終了後に実施すべきだと考えています。
この際、上記の設計項目1〜6を複数機能で並べて見る必要があります。そうすることで、最初に共通機能を洗い出すよりも適切な洗い出しが出来ます。
そして、その洗い出しと共通機能の設計、それを外部設計に反映してから内部設計に行くべきだと考えます。
こうすることで、共通機能を外部設計レベルで適切に開発でき、開発工数を減少させることが出来ます。

ここで疑問が複数出ると思います。
A. どのレベルまで共通化したらよいのか？
B. 共通化すると、画面固有の機能が出た場合、例外が出るから共通化できないのでは？
C. 開発期間は本当に縮小するのか？

A.
私は全てを共通項目とするべきだと考えます。「え？画面固有のものもあるよ」と思う方もいると思います。
まずは画面項目や入力項目を共通化していきます。
例えば、普通は名前入力欄は各画面でtextboxとして定義するでしょうが、これを1つのタグで表現できるように共通化していきます。これを名前、住所、電話番号のように各項目の部品を作ります。
次に、複数項目を共通化していきます。例えばユーザ登録の場合、複数画面で名前、住所、電話番号を入力させる場合は、このセットを共通化項目として1つのタグで表現できるようにしていきます。
このようにしていくことで1つの画面はいくつかの意味的に分かれた項目のみのタグで表現されます。
こうすることで、画面の構築は用意されている部品を使うだけなので、全体にわたる横断的な修正に強くなります。

B.
これは二つの考えを持つべきです。
一つ目は、複数の項目を組み合わせると例外だが、各項目単体では共通化できると判断する。
二つ目は、その差を吸収できる共通化機能を作成する。
これは二つ目を優先し、一つ目は二つ目が難しい場合のみに適用するべきです。
これは、全体にわたる横断的な修正も共通機能が吸収できるため、各機能の修正の範囲を極小化させるための方策です。

C.
これは、本当はあまり変らないケースもあります。ですが、なぜか共通化されていないほうが工数が多くかかります。
これは技術云々ではありません。同じことを何度も修正させられると、人間ですので飽きたり、何でこんなことを一つにまとめられないんだと感じ、モチベーションが低下するためです。
モチベーションの低下は生産性の低下を意味します。メンバーには最小の修正で大規模な修正ができることをアピールできるほうが、やる気が出ます。


今まで、どのプロジェクトも設計書を横串で見たことがありません。つまり、いつまでも同じ開発を行って、仕様変更やバグによって今までと同じように、各画面の影響調査から入って、がんばって全体を調査し、全体の再テストを行うといったことをしているのです。
いつまでもシステム開発が属人的で、システム化されていないといえます。
そうではなく、フェーズの中で事前に影響調査に役立つ共通化というものを入れて、システマチックな開発を実施すべきだと私は考えます。

この行為は、短期的には工数の増大を招きますが、後々修正や保守フェーズに至ったときの工数抑制を考慮すると、いわゆる急がば回れになります。

どういった観点で設計書を見ていくべきか、設計者は設計書の書き方、見方、設計の進め方、リーダーはフェーズの進め方を再度検討する必要があると私は考えています。
今回のお話は難しく、意味不明なことも(説明不足もあって申し訳ありません)多いと思います。が、この設計書を横串で見るというフェーズについてはまだまだ考え方は完璧ではないので、より現実的で分かりやすいものを検討していきたいと思います。

最後に、駄文と長文で失礼しました。

Comments

読ませていただきました。
大変参考になりました。
これからも、良い情報の発信をしていだければと思います。
ありがとうございました。

Posted by 仕様書作成係 at 2010年01月26日 15:09

下記も、参考にしていただければ幸いです。

ドキュメント自動生成ツール【A HotDocument】
http://www.hotdocument.net/

Excel/chm/html形式出力のドキュメントギャラリー
http://www.hotdocument.net/gallery/

出力サンプルのダウンロード
http://www.hotdocument.net/main/downfile.html

関連サイトも書いておきます。
http://www.hotdocument.jp/ - VB、VC++、C#、Java、Access、Excel対応仕様書
http://document-csharp.com/ - C# プログラム設計書 サンプル集
http://document-cpp.com/ - C言語/C++ プログラム設計書 サンプル集
http://document-java.com/ - Java プログラム設計書 サンプル集
http://document-vb.com/ - VB プログラム設計書 サンプル集
http://document-access.com/ - Access プログラム設計書 サンプル集
http://document-excel.com/ - Excel プログラム設計書 サンプル集
http://www.coding-standard.com/ - コメント規約、コーディング規約

【A HotDocument】製品概要は下記の通りです。
http://www.hotdocument.net/product/vb7.html - VB版 仕様書 作成
http://www.hotdocument.net/product/cpp.html - C言語/C++版 仕様書 作成
http://www.hotdocument.net/product/cs.html - C#版 仕様書 作成
http://www.hotdocument.net/product/access.html - Access版 仕様書 作成
http://www.hotdocument.net/product/excel.html - Excel版 仕様書 作成
http://www.hotdocument.net/product/java.html - Java版 仕様書 作成

Posted by 仕様書作成係 at 2010年01月26日 15:10

仕様書作成係さん。コメントありがとうございます。
最近とても忙しくコメントに気づいておりませんでした。申し訳ございません。
A HotDocumentの紹介ありがとうございます。情報連携ありがとうございます。
ちなみにですが、私はDoxygenというものをよく使っております。
http://www.doxygen.jp/
最近は日本語でもしっかり出るようになりましたので、日本でも実用に耐えられるかと思います。
ただし、まだまだ日本の顧客が求めるようなきっちりした仕様書の作成まではなかなか到達していないような気がしますので、私はあくまでリバースの一ツールとして利用しています。

Posted by kiruah at 2010年02月07日 13:02