BOOK Preview 新訳 ソフトウェアプロジェクトサバイバルガイド 第10章 アーキテクチャ設計 マイクロソフトプレスの書籍紹介ページ 書籍情報のページ 2005/08/16

Page1 Page2

本コーナーは、.NET関連の新刊書籍から主要なチャプターをそのまま転載し、その内容を紹介するものです。 　同書は『Code Complete 第2版』などで著名なSteve McConnell氏による、開発プロジェクトを失敗させないための本です。プロジェクトを最後まで存続させるための基本的なサバイバル術となる、要求管理、プロジェクト計画、進捗状況の追跡、品質保証、変更管理などのマネジメント技法が平易かつ具体的に示されています。 　同書は、1998年に発行された書籍の新訳版（PMBOKに基づいて用語等が見直されている）ですが、その内容は現在でもまったく色あせておらず、プロジェクト開発の本質を突いていることに驚かされます。例えば、現在では主流となりつつあるアジャイル開発という言葉は当時まだありませんでしたが、ここでは「ステージ別納品」という、アジャイル開発の源流ともいえる開発方法が紹介されています。 　本稿は、「第10章 アーキテクチャ設計」の転載です。ここではまず、優れたアーキテクチャとはどのようなものかについて解説されています。そして、ベストプラクティスに基づいたアーキテクトの必須作業項目をコンパクトにまとめ上げています。アーキテクチャ設計にとって大切なポイントはミニマリズムとシンプルであると述べられていますが、本書の特長もまさにそれであるといえます。 　なお、書籍の詳細については書籍情報のページをご覧ください。

ご注意：本記事は、書籍の内容を改訂することなく、そのまま転載したものです。このため用字用語の統一ルールなどは＠ITのそれとは一致しません。あらかじめご了承ください。

　ソフトウェアアーキテクチャはプロジェクトの技術的基盤である。適切なアーキテクチャを設計しておけばプロジェクトのその後の作業が楽になり、不適切なアーキテクチャを設計するとその後の作業を進めるのはほとんど不可能になってしまう。優れたソフトウェアアーキテクチャ文書には、プログラム全体の構成、アーキテクチャで変更をサポートする方法、他のシステムから再利用するまたは他社から購入するコンポーネント、および標準機能を設計するときの方針などを記述しておくことが必要である。また、下流で発生し得るコストを最小限に抑えるために、アーキテクチャでそれぞれのシステム要求に対応する方法を列挙しておくことも大切である。

　建築にたとえれば、アーキテクチャ設計のフェーズは、実際に建築を開始する前に､縮尺模型と青写真を使用して建物の全体的な設計を詳細に練っていく段階に相当する。鉄骨やコンクリートなどの建築資材を使って建築を始める前に､縮尺模型と青写真を使っていろいろと変更点を検討した方が、コストがかからずにすむということだ。

　ソフトウェア開発の場合、アーキテクチャ設計のフェーズでは、設計図とプロトタイプを使用して、ソフトウェアの構造を明確にしていく。建物を建築する場合と同じように、アーキテクチャ設計のフェーズでは比較的低コストでいろいろな可能性を検討することができる。アーキテクチャは「システムアーキテクチャ」、「設計」、「概要設計」、「最上位レベル設計」などとも呼ばれ、通常は「ソフトウェアアーキテクチャ文書」と呼ばれる文書に記述される。

　アーキテクチャ設計のフェーズでは、作業を担当するアーキテクチャチームがシステムを主要なサブシステムに分割し、サブシステム間のすべての相互作用を定義し、ソフトウェアに関する最上位レベルの技術計画を文書化する。また、エラー処理、メモリ管理、文字列の保存など、システム全般にまたがる設計上の主問題についても検討する。アーキテクチャは、後の詳細設計で使用する構造を定義し、詳細設計作業に引き継がれる。

　小規模のプロジェクトではアーキテクチャと設計を1つの作業にまとめても構わないが、ほとんどのプロジェクトではアーキテクチャ設計を1つの独立したアクティビティとして扱う。『The Mythical Man-Month』の著者であるFred Brooksは次のように報告している［注10-1］。「システムアーキテクトを決めておくことは、アイデアの一貫性を確保する最も重要なステップである。・・・20回以上にわたってソフトウェアエンジニアリングの研究所で指導を行ってきた結果、私は学生で構成する4人程度の小さなチームでもマネジャーとアーキテクトを決めるべきだという結論に至った。このような少人数のチームできっちりと役割を決めることは多少行き過ぎだと思われるかもしれないが、私が観察したところでは、役割分担は十分に機能しており、設計成功の一因になっていることは確かであった。」

注10-1 『The Mythical Man-Month, Anniversary Edition』（Addison-Wesley、1995年、和訳書『人月の神話　新装版― 狼人間を撃つ銀の弾はない』ピアソン・エデュケーション、2002年、瀧沢徹、富沢昇、牧野祐子訳）

　本章の説明は少人数のアーキテクトがチームとなってソフトウェアアーキテクチャを開発することを前提にしている。実際にアーキテクトという役割を割り当てるかどうかは別にして、本章で触れる諸点は、詳細設計と構築に進む前に注意深く検討し対応すべき課題である。

アーキテクチャ設計の開始

　アーキテクチャ設計は、要求開発が80%くらい終了した時点で開始すべきである。アーキテクチャ設計を開始する前に要求を100%解決することは通常不可能であり、無理にそうすればプロジェクトの進行を遅らせるだけである。要求が8割方判明するころには、プロジェクトの基礎はソフトウェアアーキテクチャを作成できる程度に固まっているものである。8割というのは経験に基づく大まかな目安であり、それぞれのプロジェクトではプロジェクトリーダーが要求開発の進捗状況を見極め、独自の判断に基づいてアーキテクチャ設計の開始時期を決定する。

　ただし、アーキテクチャチームが本格的にアーキテクチャを設計し始める前に、プロジェクトチームと経営上層部、顧客による計画チェックポイントレビュー（第4章を参照）を開く必要がある。プロジェクトの予算が承認されないうちに、いきなり全面的なアーキテクチャ設計作業に突入しても無意味だからである。

優れたアーキテクチャの特徴

　アーキテクチャ設計を本格的に開始すると、まず設計の核となる問題に直面する。これらはアーキテクチャで対応すべき問題である。

システムの概要
　システムアーキテクチャでは、システムの概要を説明する必要がある。システムの概要が説明されていなければ、膨大な詳細説明、あるいは1ダースのモジュールやクラスが個別に示されても、これらを結び付けて一貫したソフトウェアの姿を想像するのは困難を極める。システムアーキテクチャにはこの他に、検討した主な代替設計案についての概説、現在のアプローチを選択した理由、他の選択肢が選ばれなかった理由なども含めなければならない。

コンセプトの一貫性
　アーキテクチャの目的は明確に述べなければならない。修正しやすさを第1の目的とするシステムの設計と、妥協のない性能を第1の目的とするシステムの設計とでは、たとえ2つのシステムが同じ機能を持っていたとしても、その内容は異なるのが当然である。優れたアーキテクチャは、システムが解決しようとしている問題に適したものでなければならない［注10-2］。アーキテクチャ設計に数日間あるいは数週間知恵を絞れば、問題解決に最適のアーキテクチャが作成できるはずである。他人がそのアーキテクチャを見たときに、「これ以外はあり得ない自明の解決策だ」と言うようなアーキテクチャを作成すべきである。Harlan Millsはこのような資質を「深奥なる単純性（deep simplicity）」と呼んだ。アーキテクチャは複雑なほど質が悪くなる。

注10-2 アーキテクチャがどの程度問題に適しているかを数値化して評価する方法については、『IEEE Software』（1997年9月／10月）のTom Gilb著「Impact Estimation Tables：Understanding Complex Technology Quantitatively」が参考になる。

　したがって、問題の詰め込み過ぎには注意しなければならない。気付いたすべての問題について考えられるあらゆる側面に対応しようとするアーキテクチャは良くない。でき上がったアーキテクチャは、アーキテクチャチームができる限り単純な手法を用いたことが明らかであるようなものでなければならない。アーキテクチャの単純さの度合いはアーキテクチャ文書から推し量ることができる［注10-3］。最良のアーキテクチャ文書は、ダイアグラム中心の短いもので、平均でも100ページに満たない。

注10-3 Grady Booch 著『Object Solutions: Managing the Object-Oriented Project』（Addison-Wesley、1996年、和訳書『オブジェクトソリューション―オブジェクト指向プロジェクトの管理新装版』、ピアソン・エデュケーション、2002年、石川克己訳）から引用

　ソフトウェアエンジニアリングに関する書籍でこれまでに最高の評価を得ている『The Mythical Man-Month』では、その中心テーマとして、大規模システムにおける最重要課題は「コンセプトの一貫性（integrity）をいかに維持するか」であると強調している［注10-4］。アーキテクチャは、それを見たときソリューションの自然さと簡便さに満足できるようなものであることが大切である。問題とアーキテクチャが辻つま合わせに見えるものであってはならない。

注10-4 Frederick P. Brooks Jr.著『The Mythical Man-Month, Anniversary Edition』（Addison-Wesley、1995年、和訳書『人月の神話　新装版―狼人間を撃つ銀の弾はない』、ピアソン・エデュケーション、2002年、瀧沢徹、富沢昇、牧野祐子訳）

サブシステムとその構成

　アーキテクチャでは、プログラムの主要なサブシステムを定義する。サブシステムとは機能を大別したもので、たとえば、出力の書式設定、データの保存、分析、ユーザー入力などの単位に区分される。一般的なシステムで理想的とされるサブシステムの数は、5〜9個である。これ以上多くすると、システムが複雑になり過ぎてアーキテクチャレベルで理解するのが困難になってしまう。図10-1は、適度に複雑な相互関係を持つアプリケーションプログラムのサブシステム構成を示している。

図10-1サブシステムのアーキテクチャダイアグラムの例。ほとんどのアーキテクチャは最上位レベルのサブシステム5〜9個から構成される。優れたアーキテクチャは、サブシステム間の相互作用が比較的少ない。

　図10-1に示したようなダイアグラムに加えて、アーキテクチャでは各サブシステムが受け持つ機能の範囲を説明し、各サブシステムに含める予定のモジュールやクラスを暫定的にリストアップする。このリストは、詳細設計と構築の作業の中で最終的に完成する。

　さらに、アーキテクチャでは、異なるサブシステム間でどのようなデータのやり取りを認めるかについても説明する。図10-1のダイアグラムでは、サブシステム間のデータのやり取りはほんの一部しか認めていない。サブシステム間のデータのやり取りの指針になる規則を決めないとどのようなことになるか、図10-2に例示する。可能な限りすべての組み合わせのサブシステム間でデータがやり取りされ、複雑性を最小限に抑えるという目標を達成できていない。優れたアーキテクチャは、サブシステム間のデータのやり取りを最小限にとどめるものである。

図10-2 サブシステム間のデータのやり取りを制限する規則を決めないアーキテクチャの例。データのやり取りを制限しないと、アーキテクチャが複雑になるのをコントロールできない。

　サブシステム間のデータのやり取りに対する制限は、通常、標準的なソフトウェア開発ツールでは自動的に強制することができない。したがって、アーキテクチャ設計の指針を守るためには、詳細設計とコードレビューに使用するチェックリストに、この点についての1項目を加えておくべきである。しかし、アーキテクチャ設計を重視するプロジェクトで作業をしたことのない開発者は、自分のコーディングがアーキテクチャによって制限されることに反発することがあるので注意が必要だ。

アーキテクチャの目標は複雑性を減らすことにある。 ソフトウェアに組み込む機能ばかりでなく、組み込まない 機能についても十分に吟味しなければならない。

表記法

　大規模なプロジェクトであれば、BoochとRumbaughのUML（Unified Modeling Language）のような標準的な表記法を採用すべきであるが、小規模のプロジェクトの場合には、ダイアグラムの意味をすべての人が理解できるようにし、ダイアグラムを公開していつでも参照できるようにしておけばよい［注10-5］。

注10-5 UML（Unified Modeling Language）については、http://www-306.ibm.com/software/rational/にアクセスして、IBMのWebサイトの中のRational Softwareのページを参照

　アーキテクチャ設計に続く詳細設計では、アーキテクチャで使用したのと同じ表記法を使用することも、あるいは詳細設計に適した表記法を採用することもある。しかし、アーキテクチャにUMLを使用するなら、これを全作業で使用した方がよいだろう。あるいは、個々のルーチンの構造を表現するために疑似コードを使用するようになるかもしれない。どのような表記法を選択するにせよ、表記法に関してはアーキテクチャ設計時に合意を図り、プロジェクトに参加する全員が同じ表記法を使うようにしなければならない。

INDEX
	新訳 ソフトウェアプロジェクトサバイバルガイド
	1. 第10章 アーキテクチャ設計（1）
	2. 第10章 アーキテクチャ設計（2）

　

「BOOK Preview」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）