[ThinkIT] 第8回：「ドキュメントとプログラムソースの量産」の実現とは (1/3)

TOP＞プロジェクト管理＞「ドキュメントとプログラムソースの量産」を実現する「スペックパターン」という考え方

経験が物語る実践型プロジェクト管理

第８回：「ドキュメントとプログラムソースの量産」の実現とは
著者：イマジンスパーク深沢隆司 2006/6/1

1 2 3 次のページ

「ドキュメントとプログラムソースの量産」を実現する「スペックパターン」という考え方

   今回説明する「ドキュメントとプログラムソースの量産」という考え方は過去にあまり例がないことと思います。筆者がIT業界に入ったおよそ20年前には、「ソフトウェア工場」という言葉が盛んに言われていましたが、その時の説明に使われていた図はベルトコンベアの工場でした。

   このイメージは、現在ではきっと初心者でも疑問に感じると思いますが、当時はすぐにでも実現できるかのごとくいわれていました。筆者が業界で当たり前のようにいわれていることや「これからはこれ！」というような開発手法の紹介記事などに疑いを持った最初の考え方がこの「ソフトウェア工場」です。

   日本人は、欧米人のいうことをあまり深く考えずに受け入れてしまっているように思えます。そのため、せっかくのよい部分を活かし切れていないことも多く感じます。

   ソフトウェア開発（特に業務システム開発）において品質や効率はソフトウェアそのものについてだけに求められるわけではありません。いうまでもなく、「ドキュメント」にも高い品質や効率が求められます。特に「効率」はドキュメントを作る効率だけではなく、ドキュメントを基にして行われるコミュニケーションの効率（スピード）、つまり使われる際の効率が極めて重要です。

   拙著「デスマーチよ！さようなら！」「SEの教科書」で解説している「スペックパターン開発プロセス」は、シンプルな考え方でドキュメント使用時の高い効率を実現しています。

   ただ、「ドキュメントとプログラムソースの量産」という考え方については今一つうまく説明できずにいました。「ソフトウェア工場」とは根本的に違うものですが、品質と効率の高いドキュメントを実現し、結果としてシステム開発全体のスループットを大幅に向上させることができるものになっています。まずはこの点について、説明したいと思います。

暗号でわかりやすくする？

   例えば暗号の仕組みを考えてみてください。英語のアルファベットを対応表によって別のアルファベットの文字に置き換えて暗号化するという、とても単純な方法です。

   「スペックパターン」というものはこの考え方に似ています。まず代表的な画面について、コンピュータの専門家ではない人にも理解できる表現で、個々の入力項目の画面上での動作を詳細に文章化します。その上で、それを実現するリリースレベルでの実装（モデルソース作成）をプログラマの代表であるインプリメント・リーダーが丁寧に行います。

   モデルソースの中で個々の項目定義の動作にあたる部分と、その項目を文章化したものとを対応表のようにセットで捉えて「スペックパターン」と呼ぶわけです。ただし、セットといっても何か物理的に1つのものになるわけではありません。

   自動化を目指すなどして、あまりにも厳密な一体化を実現しようとすると、様々な面でバランスがくずれます（例外処理などへの対応によってドキュメント・システムそのものが複雑になりすぎ、プロジェクト全体としての効率が一気に落ちることになります）。

   個々の項目定義の詳細外部仕様記述と1対1でプログラムソースの組み合わせを実際に行って、実装するのは仕様策定者やプログラマがその能力を発揮して行うべきことです。これによって「システム開発機能全体の柔軟性」を確保します。

   ということで、個々の項目定義の詳細外部仕様記述と具体的なプログラムソースが1対1でセットになるという、とても単純で当たり前の構造が「スペックパターン」です。あまりにも当たり前すぎる話になりますが、これまでになかった「使う側の立場に立ったドキュメントの量産」という考え方を実現するには、考慮しなければならないことが沢山あるのです。

参照性（コレだけ）: 各項目に共通する情報を別資料にまとめるという方法を用いるのは極力避けなければならない
保守性: 極めて高いドキュメントの保守性を実現しなければならない（表計算アプリケーションではダメ）
対応表: 同じ動作の項目については、一字一句同じ仕様書記述を確実に実現（ドキュメントシステムの高い保守性によって実現）
高い精度: 量産してしまってから、それぞれの表現を変更しないで済む事を考える（徹底的に丁寧な上流工程を行うことで実現）

表1：ドキュメントの「量産」を実現するにあたって考慮すべきこと

これらを考慮して、「モデルソース」を含む「スペックパターン」を実現するためにソフトウェアの選択や開発プロセス全体を考えたのが「スペックパターン開発プロセス」です。ここまでで紹介した「モックアップ」「深沢式会議法・議事録術」「徹底的な顧客業務理解」「徹底的な顧客業務分析」「顧客業務理解のレビュー」はここでいう「高い精度」を実現するためにあるのです。

1 2 3 次のページ

著者プロフィール
株式会社イマジンスパーク深沢隆司
株式会社イマジンスパーク代表取締役
陸上自衛隊少年工科学校第25期生。対空戦闘指揮装置の修理要員として自衛隊に勤務。退職後に一部上場企業や官庁でのシステム開発等で仕様策定、プロジェクトマネジメントに従事し、独自の手法で成功に導く。著書は『SEの教科書』他。

INDEX
第8回：「ドキュメントとプログラムソースの量産」の実現とは
	「ドキュメントとプログラムソースの量産」を実現する「スペックパターン」という考え方
	最初から高い精度で臨むことが肝心
	仕様書を作っている人にしかわからない情報が引き起こす問題