基本設計の基礎

基本設計の基礎

そこでここでは、基本設計の基礎を解説する。Part1では、基本設計を取り巻く環境の変化を改めて示したうえで、基本設計とは何か、ITエンジニアが身に付けるべく基本設計のスキルとは何かを提示する。Part2とPart3ではそれぞれ、DOA（データ中心型アプローチ）とオブジェクト指向による基本設計の基本を解説する。さらにPart4では基本設計で用いるパターンを、Part5では基本設計フェーズのドキュメントのレビュー方法をそれぞれ取り上げる。

Part1　今こそ「基本設計」のスキルを見直す
Part2　設計手順の基本を身に付ける
Part3　オブジェクト指向の基本設計を理解する
Part4　方式設計で利用できる「パターン」を知る
Part5　基本設計におけるレビューの勘どころ

  

Part1　今こそ「基本設計」のスキルを見直す 

「ベテランのエンジニアは基本設計の一般的な手順は理解しているが、高度化・専門化した実装技術を駆使したアーキテクチャの設計でとまどう。一方、若手エンジニアは実装技術には詳しいものの、肝心の基本設計の基礎的な方法論を理解していないことが多い」――。

　こうした悩みは、多くの開発現場に共通する。これは、基本設計そのものが難しくなっているからにほかならない（図1）。

図1●難しくなる一方の「基本設計」

 

　メインフレーム時代は、ウォーターフォール型の開発プロセスと自社の製品の知識さえあれば基本設計をこなせた。しかし、システムがオープン化した現在は、膨大な技術・製品を組み合わせて最適な設計をする必要がある。その分、基本設計の難度は上がっている。

　さらに、ユーザー側の環境変化のスピードが速い、システムがビジネスそのものと一体化している――などの理由により、基本設計の入力情報、すなわち要件定義で作成する機能要件や非機能要件、制約条件もあいまいになっている。

　要件定義があいまいな場合、要件定義書の内容を基本設計で改めて明確にする必要がある。その分、基本設計の仕事量は増えるし、要件を明確化するには業種・業務知識が必要になるため、必然的に基本設計の難度は上がる。

　さらに、組織横断型のシステムが増えたことで、多くのステークホルダー（利害関係者）との仕様調整が発生。このことも基本設計を複雑化させている。加えて、設計書そのものをより詳細に記述する必要も出てきた。詳細設計やプログラミングなどの作業を海外に委託するオフショア開発が増えてきたからだ。

　このように基本設計は複雑化する一方だが、「ITエンジニアの基本設計のスキルはむしろ低下している」と指摘する声は多い。大規模な新規開発案件が減少し、代わりに保守案件や中小規模のWebシステムの開発案件が増えたからだ。このため、きちんとした基本設計を実施する機会が減った。

多岐にわたる基本設計の範囲

　ここまで、「基本設計」という言葉を説明なしで使ってきたが、そもそも基本設計とはどこまでの範囲を指すのだろうか。“釈迦に説法”かもしれないが、ここで基本設計の定義を改めて説明しておこう（図2）。

図2●「基本設計」の位置付け

基本設計は大きく、ハード／ソフトの構造（アーキテクチャ）や実装方針を決定する「方式設計」と、システム全体をモジュールに分割して機能や画面、データなどを決定する「機能設計」から成る。そのほかにも、性能や信頼性、セキュリティなどを設計する必要がある

 

　一般的なシステム開発では、「要件定義」、「基本設計（外部設計とも呼ぶ）」、「詳細設計（内部設計とも呼ぶ）」、「プログラミング／単体テスト」、「結合テスト」、「システムテスト」などのフェーズから成る。

　このうち「基本設計」では、要件定義フェーズの成果物である機能要件、非機能要件、制約条件に基づいて、「方式設計（アーキテクチャ設計）」と「機能設計（アプリケーション設計）」を実施する。

　方式設計は、ハード／ソフトの構造（アーキテクチャ）や実装方針を決める作業である。例えば、ハードウエアやミドルウエア、フレームワークといったシステム基盤、アプリケーション全体の構造、開発標準やテスト方式などを設計する。一方の機能設計では、アプリケーションとして実装する機能やデータベース、画面や帳票などを設計する。

　基本設計ではこのほか、システムの非機能要件で定義されたパフォーマンスや可用性などを満たすための性能・信頼性設計や、不正アクセスや情報漏えい対策といったセキュリティ設計、新システムへの移行方法を定義する移行設計、業務とシステムの両面から運用方法を決定する運用設計なども実施する。

 

正しい手順を理解する

　上で述べたような基本設計の作業を迅速かつ確実に実施するには、基本設計の正しい手順や方法論、作成すべき成果物とその役割、効率的で確実な方式設計の方法、そして基本設計の成果物の正しいレビュー方法を理解しておかなければならない。これらを理解していなければ、高品質、短納期というユーザーの要求には応えられない（図3）。

図3●基本設計の手順や方法、成果物の役割、レビューの方法などを理解していないと、高品質、短納期の要求に応えられない

 

　言うまでもなく、基本設計の正しい手順を理解していなければ、設計作業を効率的に進められず、結果的に品質の低下につながる。

　実際、こうしたプロジェクトは多い。数多くのWebシステムの基本設計を手掛けてきたあるアーキテクトは、「Webシステムにかかわる多くのエンジニアは、画面のデザインには凝るが、その裏側にある機能やデータベースを十分に考慮していない。その結果、保守性が低く変化に対応できないシステムになってしまう。基本設計の正しい手順を理解していれば、こんな問題はなくなるはずだ」と語る。

　また、作成すべき成果物の種類や役割を理解していなければ、詳細設計以降の作業負荷を増大させてしまう。例えば、Webシステム開発で画面レイアウトをExcelで作るケースはその典型例である。画面レイアウトをExcelで作っても、詳細設計以降につながらない。画面設計をどう詳細化するのかを知っていれば、後のフェーズですぐに使える形（HTMLなど）で、画面設計の成果物を作るはずである。

　方式設計に関しても、自分だけの経験に頼らずに、先人が体系化した方式設計の“ひな型”である「パターン」を使うなど、効率的に作業を進めるべきだ。経験だけに頼って方式設計を実施すると、システム全体に不整合が生じ、プロジェクトが取り返しのつかない危機に陥る。安易にTomcatやStrutsといったミドルウエアやフレームワークを導入してアーキテクチャを構築したと思ってはならない。先人のパターンを参考にしながら様々なトレードオフを考慮しないと、システムの土台がゆがんでしまう。

　さらに、設計書のレビュー方法を知らなければ、欠陥を含んだ成果物がそのまま詳細設計以降に渡される状況を招いてしまう。

身に付けるべき3つのスキル

　では、ITエンジニアとして今どんなスキルを身に付ければよいのか。取材を通して浮かび上がった主なスキルは、次の3つだ（図4）。

図4●基本設計を成功に導く3つの必須スキル

 

1つ目は、機能設計や方式設計を、正しい手順に則って進めるスキルである。手順だけではなく、アプリケーションを適切にモジュールに分割する構造化設計といった、設計の「基本中の基本」も、当然ながら理解しておく必要がある。

2つ目は、方式設計で「パターン」を適切に適用できるスキルである。具体的には、外部システムとの連携方法のパターンである「インテグレーション・パターン」やシステム全体の分割方法を示した「アーキテクチャ・パターン」、具体的な実装方針を示した「アプリケーション・アーキテクチャ・パターン」を理解しておく必要がある。これらを適材適所で利用すれば、方式設計を迅速かつ確実に進めることができる。最近はこうしたパターンをパッケージ・ソフトやミドルウエア、フレームワークが実装している場合が多い。このため、パターンに関するスキルは必須となってきている。

3つ目は、成果物を正しくレビューするスキルである。設計者自身が設計書をチェックするスキルを持つことで、例えば、設計時に結合テスト用のテストケースを作成すれば、机上で設計仕様書のテストができる。ウォークスルーやインスペクションといった基本的なレビュー方法についても、設計者が理解しておくべきだ。

ITエンジニアにとって、これらのスキルの習得は、まさに“待ったなし”の状況にある。詳細設計以降のフェーズは海外にシフトし、一方でユーザーは今まさに要件定義を内製化する動きにある。となれば、ITエンジニアには、基本設計に関する専門性の高いスキルがますます要求される。

　そこで以降のパートでは、ITエンジニアが最低限身に付けておくべき基本設計の基礎と実践について解説する。まずPart2で、日本IBMの開発方法論である「ADSG」をベースに、一般的な基本設計の手順と成果物を解説する。

　続くPart3では、反復型開発プロセス「UP（Unified Process）」を例に取って、オブジェクト指向における基本設計の勘どころを説明する。

Part4では方式設計を迅速かつ確実に実施するために利用できる「パターン」について解説する。方式設計に携わるエンジニアには必ず参考になるはずだ。締めくくりとなるPart5では、確実に欠陥を発見し、防止するためのレビューのプロセスと方法を紹介する。

Part2　設計手順の基本を身に付ける

Part2では、多くのシステム開発で実績を持つ日本IBMの「IBM-DOA」に基づく外部設計フェーズの手順を説明する。ここで紹介するDOAに基づく複合／構造化設計手法は、どんなプロジェクトにも応用できる基本的なアプローチだ。基本をしっかりと身に付けてほしい。

DOA（Data Oriented Approach：データ中心型アプローチ）は対象システムの「データの流れ」の把握に重点を置きながら、要件定義や設計を進めていくアプローチである。

DOAには様々なタイプがあるが、日本IBM独自の「IBM-DOA」では、主に業務全体をデータの流れに着目して図で表現するDFD（Data Flow Diagram）を使って業務を分析・設計していく。Part2では、この「IBM-DOA」に基づく外部設計フェーズの進め方を説明しよう。「今さらDOAか」と思わないでほしい。最も基本的で一般的なアプローチなので、どんなプロジェクトにも応用が利く。ぜひしっかりと理解してほしい。

中心的な役割果たすDFD

IBM-DOAで中心的な役割を果たすDFDは、アプリケーションの要求を仕様としてまとめるのに向いており、データを中心に明確であいまいさの残りにくい仕様を作成できる。

　後続フェーズへの連続性もDFDの大きなメリットである。実際、要件定義フェーズの成果物として作成したDFDは外部設計のインプットとなり、外部設計ではDFDを基にサブシステム分割を行ってプロセスやデータの実現方法を決定していく。

DFDでは、業務全体を「データフロー（データの流れ）」、「データストア（データの蓄積）」、「プロセス（処理）」などの要素で表現する（図1）。IBM-DOAではこの表記法に従って、4つのDFDモデルを作成する。現行業務のデータの流れを表す「DFD現物理モデル」、そこから本質的なデータの流れのみに絞った「DFD現論理モデル」、新システムへの要件を加えた「DFD新論理モデル」、そしてアーキテクチャなどの物理的な特性を加味した「DFD新物理モデル」である。このうちDFD新論理モデルまでは要件定義で作成し、DFD新物理モデルは外部設計で作成する。これらのDFDモデルは、最も抽象度の高いレベルから段階的に詳細化していく。

図1●DFD（Data Flow Diagram）の表記法

表記法には、トム・デマルコ氏が考案した「デマルコ式」と、クリス・ゲイン／トリッシュ・サーソン氏が考案した「ゲイン／サーソン式」がある。日本IBMではゲイン／サーソン式を採用している

　要件定義では、DFD新論理モデルの中の「データストア」に含まれるデータ項目をリストアップした「データストア記述」、「データフロー」に含まれるデータ項目をリストアップした「データフロー記述」、「プロセス」の内容をIPO（Input Process Output：入力-処理-出力）形式で記述した「処理機能記述」も作成する。DFD新論理モデルとこれら3つの仕様書を「DFD4点セット」（図2）と呼び、外部設計への重要なインプットとなる。

DFD4点セットのうち「データストア記述」はデータの正規化とER図作成を経てデータベース設計に、「データフロー記述」は画面や帳票設計に、「処理機能記述」はプログラムの機能仕様に直接つながる。このように、要件定義の成果物を無駄なく機械的に外部設計のインプットにつなげられる点が、IBM-DOAが特に大規模開発において実績を上げている大きな理由の1つである。もちろん、このアプローチは、中小規模のプロジェクトにも十分適用できる。

図2●DFD4点セット

DFDに加えて、データストアの内容を示した「データストア記述」、データフローの内容を示した「データフロー記述」、プロセスの内容を示した「処理機能記述」の4つを、要件定義フェーズで作成する

 

複合／構造化設計を知る

IBM-DOAは1980年代の初めに確立されたものであり、設計手法としては、アプリケーションを分かりやすいまとまりに分割する「構造化手法」をベースとしている。構造化手法に馴染みのない読者もいるかもしれないので、はじめに構造化手法について説明しておこう。

　構造化手法は60年代後半からの「構造化プログラミング」に始まり、今日までにいくつかの手法が確立している。代表的な手法としてはDFD、データの正規化、データ項目の集まり（エンティティ）とエンティティ間の関連を図で表現するER図（Entiry RelationshipDiagram）、複合／構造化設計（Composite/Structured Design）などがある。

複合／構造化設計は、G.J.マイヤーズらが1970年代に体系立てたソフトウエア構造の設計手法である。IBM-DOAでもこの複合／構造化設計の考え方が根底に流れている。

　実際、外部設計におけるサブシステム分割やシステム機能仕様の作成では、複合／構造化設計のモジュール分割手法がベースになっている。複合／構造化設計は、外部設計の基本中の基本」なので、以下で、より詳しく説明しよう。

モジュール強度と結合度

　複合／構造化設計では、アプリケーションを適切にモジュールに分割するために、(1)モジュール分割の良否を判定する尺度と(2)基本的なモジュール分割技法を定義している。

1つ目のモジュール分割の良否を判定する尺度としては、「モジュール強度」と「モジュール間結合度」がある（図3）。

　このうちモジュール強度は、1つのモジュール内の構成要素間の関連性の強さを示す尺度であり、最も弱い「暗号的強度」から最も強い「機能的強度」まで7種類が定義されている（表1）。モジュール強度は強いほど良い。モジュール分割では、特定のデータ構造のみを扱う機能をまとめた「情報的強度」や、単一の機能のみを実行するために結び付いた「機能的強度」を目指すべきだ。

図3●複合／構造化設計におけるモジュールの定義と分割の良否を判定する尺度

モジュール分割の良否判定は、「モジュール強度」と「モジュール間結合度」で決定する

 

表1●モジュール強度とモジュール間結合度

 

　一方のモジュール間結合度は、モジュール間の関連性の強さを表す尺度であり、最も弱い「データ結合」から最も強い「内容結合」まで6種類が定義されている（表1）。モジュール間結合度は、弱いほど良い。モジュール同士が強く結びつく「内容結合」、「共通結合」、「外部結合」は、保守や部品化、再利用を阻害する大きな要因となる。モジュール分割に当たっては、結合度が弱い「スタンプ結合」や「データ結合」を目指すべきである。

　モジュール分割を、モジュール強度が強い「情報的強度」や「機能的強度」に、結合度が弱い「スタンプ結合」や「データ結合」にすることは、保守の容易化と部品化／再利用化を促進する。この考え方を推し進めるとオブジェクト指向設計に近づく。

　複合／構造化設計による基本的なモジュール分割技法としては、(1)「STS（源泉／変換／吸収）分割」、(2)「トランザクション分割」、(3)「共通機能分割」がある。

1つ目のSTS分割は最も代表的なもので、設計対象のデータフローを詳細に分析して入力処理、変換処理、出力処理のまとまりに分類したうえで、「入力から変換へ」、「変換から出力へ」と大きく変わる個所（これを「最大抽象点」と呼ぶ）でモジュールを分割する（図4上）。2つ目のトランザクション分割は、データフローからトランザクションが分岐する個所を見つけてモジュールを分割する方法である（図4下）。最後の共通機能分割はプログラムの全体構造から共通機能を括り出して1つのモジュールとして切り出す方法だ。この3つの分割方法は、設計の基本中の基本なので、しっかり理解しておいてほしい。

図4●複合／構造化によるモジュール分割

代表的なSTS分割とトランザクション分割の例を示した

 

外部設計フェーズの手順

　ここからは図5に示したプロセスに従って、日本IBMにおける外部設計の主な作業を説明していこう。

図5●日本IBMにおける外部設計フェーズのプロセス

 

　外部設計の目的は、「要件定義書」に基づいて、新システムの「外部仕様」を作成することである。外部仕様とは「システムの外から見える機能やインタフェース」のことだ。具体的には、サブシステム構成や各サブシステムの機能仕様、画面や帳票といったユーザー・インタフェース仕様、サブシステム間や他システムとのインタフェース仕様、データベース仕様、移行仕様、運用・障害対策仕様、セキュリティに関する仕様などがある。

サブシステムの定義

　最初に実施する作業は、新システムのプラットフォーム要件や要件定義の成果物である「DFD新論理モデル」などに基づいて、サブシステムを定義することである。

　大規模なシステムを開発する場合、全体を1つのシステムとして開発するのではなく、関連性の高い機能をサブシステムとして分割し、各サブシステムの開発を並行して進めるアプローチを取る。いくつかのサブシステムに分割することで、見通しのよい設計ができるほか、開発対象をコントロール可能なサイズに抑えられるからだ。

個々のサブシステムは異なるチーム、異なるスケジュールで開発されるため、独立して開発できるように分割すべきであり、サブシステム間は限定されたインタフェースでのみアクセスするようにすべきだ。この考え方は、複合／構造化設計と同じである。

　これを実現するためには、システマチックな方法が必要となる。IBM-DOAでは、業務の大まかな括りとオンライン処理／バッチ処理などの区分を考慮しながら、高い抽象度のDFD新論理モデルの中でデータフローが最も簡素な（データの流れが最も少ない）境界で切断する（図6）。DFDモデルを基に機械的に分割するため、サブシステムの境界は現行の業務区分とは必ずしも一致しない。

図6●不適切なサブシステム分割と適切なサブシステム分割

サブシステムは、安易に機能や業務単位で分割するのではなく、必ずデータの流れを洗い出し、データの流れが最も簡素な境界で分割する

 

　サブシステムを分割した後は、各サブシステムに名称を付けたうえで、サブシステムごとの「処理機能記述」とサブシステム間のインタフェース仕様（データ項目、発生サイクル、トランザクション量など）を記述する。さらに、各サブシステム間の接続方式も、システム全体のアーキテクチャを基に確定する。

システム機能仕様の作成

　サブシステム分割が済んだら、サブシステムごとに「システム機能仕様」を作成する。まず、要件定義で作成したDFD新論理モデルを基に、アーキテクチャなどの物理的な特性を加味した新物理モデルを作成する。具体的には、処理形態（オンライン／バッチ処理など）や処理サイクル（リアルタイム、日次、月次など）といった物理的な特性を考慮して、DFD新論理モデルの「データストア」、「データフロー」、「プロセス」を統廃合・分割・追加する。

　プロセスをモジュールととらえれば、プロセスの統廃合・分割・追加はモジュール分割にほかならない。ここでも、複合／構造化設計の考え方が適用できる。ただし、DFD新物理モデルを作成する段階では、プロセスはあまり詳細化しないことがコツだ。例えば、メニューの選択や検索条件の入力といった個々の画面操作のレベルまでは分割しない。画面操作レベルまでプロセスを分割するのは内部設計フェーズの作業となる。

DFD新物理モデルが完成したら、それを基にすべてのトランザクション入出力／バッチ入出力を抽出して、一覧表としてまとめる。この情報は後でシステムのキャパシティ・プランニングを実施する際の基礎データとして利用するため、高トランザクションな処理を中心に詳細に記述しておく必要がある。加えて、要件定義フェーズで作成したデータディクショナリから、コードを付加するデータ項目を抽出したうえでコードを整理・体系化し、体系化したコードをデータディクショナリに登録しておく。

適用業務フローの作成

　システム機能仕様の作成と並行して、「適用業務フロー」を作成する。適用業務フローは、利用部門の処理の流れを業務フローとして記述したものである。この作業は通常、利用部門が主体となって実施する。

　適用業務フローは、ユーザーが容易に理解できる表記法で記述した方がよい。日本IBMでは主に「LOVEM（Line of Visibility Enterprise Modeling）」を利用している（図7）。

図7●LOVEMによる適用業務フローの例

システムに着目したDFDだけでは、エンドユーザーとスムーズな交渉ができない。画面設計やプロトタイプ作成を円滑に進めるには、一連の作業の流れや担当者とシステムの役割分担を明確にした適用業務フローを必ず作成すべきである

ユーザー・インタフェース設計

　システム機能仕様と適用業務フローを作成したら、ユーザー・インタフェース設計に入る。具体的には、DFD新物理モデル、適用業務フロー、サブシステム間のインタフェース仕様に基づいて、サブシステム単位で画面を設計していく。同様にDFD新物理モデル、現行の帳票・ファイルを基に帳票も設計する。この段階では、入出力データはDFD新物理モデルとデータディクショナリという形で既に洗い出されている。このため画面設計では、DFD新物理モデルの中でユーザーとやりとりする部分を、物理的な実装方法に合わせて、メニュー構成、画面遷移、画面のフォーマット、データのチェック仕様といった成果物に落としていけばよい。

　画面設計はユーザーから細かい要求が出る部分であり、実際に操作してみないとイメージがつかみにくい。このため、プロトタイピングで画面レイアウトと画面遷移をユーザーに確認してもらうべきだ。Web系の開発では実際にHTMLを使って擬似的に遷移する画面を作る。

Webアプリケーション開発の場合は、プログラムに対するネーミングルール（JSP名、サーブレット名など）やサイトのURL構造（アプリケーション・サーバー上のディレクトリ構造）も定義する。

データベースの設計

　ユーザー・インタフェース設計と並行して、新システムのデータベース設計を実施する。先に述べたように、IBM-DOAではこの段階でシステムを流れるすべてのデータを洗い出しているため、あいまいさがない正確なデータベースを設計できる。

　データベース設計では最初に、データディクショナリ内の各データ項目に対してシンボル名（英字名）を付与する。次にデータベース・テーブルの洗い出しを行う。RDBMS（リレーショナル・データベース管理システム）を利用する場合、正規化済みのデータストアから作成したER図のエンティティがテーブルの候補となる。

　このとき、テーブルに対するアクセス頻度、ボリューム、業務での利用方法などを考慮して、非正規化を実施するかどうかも検討する。　

　テーブルの検討が終わったら、各テーブルに対して列とインデックスの設計を行う。列の設計では列名、データ型、長さ、NULLの可否、デフォルト値などを検討する。また、インデックスの設計ではテーブルに対するアクセス方法を十分に検討したうえで、主キーおよび副インデックスを設計する。

　インデックスの設計はデータベースの性能に直結する作業であるため、アクセスが集中するようなクリティカルなテーブルに対しては、必ずデータベースの専門家によるレビューを実施すべきだ。

　データベース設計の結果は「テーブル定義書」と「インデックス一覧」にまとめておく。さらに、各テーブル間の基本キーと外部キーの関係をER図を使って整理しておく。

システム機能の記述

　システム機能仕様の作成、ユーザー・インタフェース設計、データベース設計が終わったら、個々の機能をIPO形式で記述する（IPO形式は図2を参照）。

　例えば、トランザクション処理については、アーキテクチャやフレームワークなどの物理的要素を考慮し、外部入出力やデータベースへのアクセス、画面仕様を確認しながら、1つひとつのトランザクションごとにIPO形式で処理を記述していく。

　ただし、システムの内部仕様（プログラムの処理ロジック）までは記述する必要はない。あくまでもユーザーが知らなくてはならない機能を示すための最小限の記述に絞る。

　複数の処理が使う共通機能を抽出する作業もこの段階で行う。共通機能についてもその処理内容をIPO形式で作成しておく。

　以上、日本IBMにおける標準的な外部設計の作業を説明した。要件定義の成果物であるDFDとデータディクショナリをインプットに、標準的かつ定型的な作業で設計を進められることがお分かりいただけただろう。

　ここで解説した作業のほかに「移行の設計」、「運用・障害対策・セキュリティの設計」、「プラットフォーム構成の確認」といった作業を実施し、最終的に「外部仕様書」として外部設計で作成した成果物全体をまとめることで外部設計フェーズは完了する。表2に外部設計における設計タスクの成果物についてまとめておいたので、参考にしてほしい。なお、日本IBMではシステムの規模や特性に応じて様々な手法を組み合わせることが多い。今回は、日本IBMの開発プロセスである「ADSG」をベースに、一部「ADSG for e-business」（囲み記事参照）を取り込んだ形で紹介したことを付け加えておく。

表2●外部設計フェーズにおける設計タスクと成果物（アプリケーション設計に関する部分を抜粋した）

 

Webアプリ向けの開発プロセス

　ADSG for e-businessは、日本IBMのWebアプリケーション向けの開発プロセスとツール群の総称である。UMLを標準の表記法として使用し、オブジェクト指向で設計する。

　ADSG for e-businessでは、要件定義の段階でデータ項目を整理してER図を作成する。これにより、データの一貫性／整合性を確保しながらクラス設計やデータベース設計を進められる。

　また、ADSG for e-businessでは新システムの要件を、「コンポーネント・モデル」（アプリケーションの機能をUMLのクラス図、シーケンス図、パッケージ図などで表したもの）と「オペレーショナル・モデル」（システム構成をIBMの標準表記法であるADS＝Architecture Description Standardで表したもの）という2つのモデルで定義する。

　非機能要件、運用・障害要件を考慮して、要求される性能・容量を満たすシステム資源量を見積もったうえで、本番稼働に十分に耐えうる「システムアーキテクチャ」を策定するのも特徴。システムアーキテクチャとは、システム全体の設計図であり、使用する技術、フレームワーク、アプリケーションのグランドデザイン、ハードウエア／ネットワーク構成を含む。

Part3　オブジェクト指向の基本設計を理解する

Part3では、オブジェクト指向に基づく基本設計の方法論を、UP（UnifiedProcess）をベースに解説する。下流工程で試行錯誤を繰り返さないためには、「実行可能なアーキテクチャ」を構築することと、アーキテクチャの利用方法を解説した「アーキテクチャ説明書」が極めて重要になる。

Part2では、主にウォーターフォール型開発プロセスとDOA（データ中心型アプローチ）に基づいた基本設計の手順を示した。だが、最近はWebシステム開発を中心に、反復型開発プロセスやオブジェクト指向設計を採用するケースが増えている。

　そこでPart3では、オブジェクト指向設計に基づく代表的な反復型開発プロセスであるUP（Unified Process）を例にとって、オブジェクト指向設計における基本設計の勘どころを解説しよう。

動くアーキテクチャを作る

UPでは「方向付け」、「推敲」、「作成」、「移行」という4つのフェーズが定義されており、それぞれのフェーズで「要求」、「分析」、「設計」、「実装」、「テスト」という5つの作業を実施する。推敲フェーズを2回、作成フェーズを2回というように、あるフェーズを何度か繰り返すこともある。このために、UPは「反復型開発プロセス」と呼ばれる。

UPの最大の特徴は、プロジェクトの早い段階で実際に“動く”アーキテクチャ（開発プラットフォーム）を構築することだ（これをUPでは「アーキテクチャ駆動」と呼ぶ）。また、機能要件については、「ユースケース」をベースに分析・設計・実装していく点も、UPの大きな特徴である（これを「ユースケース中心」と呼ぶ）。

　一般的な開発プロセスでは、システムの全体像を「基本設計」という形で表現し、基本設計に準拠してその後の詳細設計フェーズや実装フェーズに進む。実装が進んだ時点では、よほどのことがない限り基本設計を大きく改変することはない。

　オブジェクト指向の開発プロセス、特にUPでは「基本設計」という言葉は使わない。とは言え、もちろん基本設計に該当する作業がないわけではない。基本設計に該当する作業は、UPでは主に「推敲フェーズ」で、要求・分析・設計・実装・テストから成る一連の作業を通じて実施する。中でも中心的な作業となるのが、「機能設計」に相当する「ユースケース仕様書の作成」と、「方式設計」に相当する「アーキテクチャル・ベースラインの確立」である（図1）。

図1●UPにおける基本設計の位置付け

UP（Unified Process）では、主に推敲フェーズで「基本設計」に相当する作業を実施する

　アーキテクチャル・ベースラインとは、「実行可能なアーキテクチャ」（詳しくは後述）と、実行可能なアーキテクチャの利用方法について記述した「アーキテクチャ説明書」という2つの成果物の初期リリースを合わせたものである。

　推敲フェーズの最大の目的は、主要なリスクに対処しながら「試行錯誤を終えること」だ。このため、リスクへの対策が織り込まれたアーキテクチャル・ベースラインの確立が、推敲フェーズの終了基準（マイルストーン）となる。このマイルストーンの達成が確認されることで、推敲フェーズ、つまり基本設計が完了したことになる（図2）。

図2●UPにおける基本設計の流れ

「ユースケース仕様書」と環境／制約条件、および過去の類似プロジェクトを入力情報として「アーキテクチャル・ベースライン」を確立する。アーキテクチャル・ベールラインは、実行可能なアーキテクチャと「アーキテクチャ説明書」から成る

 

　そして、推敲フェーズの成果物である実行可能なアーキテクチャに準拠して、次の作成フェーズでユースケースが分析・設計・実装されることとなる。これが一般的な詳細設計フェーズ、実装フェーズに当たる。ソフトウエア開発において「試行錯誤を終える」ことがどれほど難しいか、システム開発に携わっている読者はよくお分かりだろう。UPでは、その答えはアーキテクチャル・ベースラインにある。

イベントフローが成果物の中心

　実行可能なアーキテクチャおよびアーキテクチャル・ベースラインについては後述するとして、まずは機能設計に相当する「ユースケース仕様書の作成」について、具体的な作業の流れと成果物について説明しよう。

　ユースケースは、ユーザーの要求を記述するためだけのものではない。ユーザーと合意しながら詳細化することで「システム仕様」となる。

UPでは、ユースケースの定義を反復を繰り返しながら徐々に詳細化していく。この作業の前半が、一般的な開発プロセスにおける「要件定義」に当たり、後半が「基本設計」、すなわち「機能要求を仕様化する」作業となる。

　この作業で最も重要な成果物が、「イベントフロー」である。UPにおけるイベントフローの定義は「特定のアクター（ユーザーやシステム）に対して明確な価値を提供する一連のアクションを定義するもの」となる。簡単に言えば、各ユースケースの処理の流れを文章で表したものだ。

　例えば、銀行口座の取引履歴照会というユースケースのイベントフローを次のように記述したとしよう。

1. ユーザーは表示する期間を指定し、ボタンを押す

2. システムは、指定された期間の明細と残高の一覧を表示する

　このイベントフローを、アクターとシステムとの具体的な相互作用が明確に表現されるよう、次のように詳細化する。

1. ユーザーは、ドロップダウンで表示される1日・1週間・1カ月から期間を選択し、［一覧表示］のボタンをクリックする

2. システムは、［日付］、［明細］、［残高］について、指定された期間の内容を最大30行まで一覧表示する

　イベントフローをここまで詳細化したら、補足情報として「画面レイアウト」を作成する。この際、イベントフローの項番から画面レイアウトを特定できるトレーサビリティも確保しておく。さらに、けた数やデータ型、未入力の可否、バリデーション（内容チェック）の有無などを記述した「データ項目」も補足情報として添付しておく。データ項目は、画面レイアウトから特定できるようにしておく（図3）。

図3●ユースケース仕様書の構成

ユースケース仕様書は、ユースケースごとに処理の流れを示した「イベントフロー」、画面イメージを示した「画面レイアウト」、データの内容を定義した「データ項目」から成る

 

　実際の開発現場では、「ユースケース仕様書」としてイベントフローのみを作成しているケースが多く見られる。だが、イベントフローを中心的な成果物として作成したうえで、補足的な成果物として「画面レイアウト」（出力先が画面ではなく帳票の場合は「帳票レイアウト」、ファイルや他のシステムの場合は「インタフェース仕様」）と「データ項目」を添付し、これらの成果物一式を「ユースケース仕様書」として扱うことで、分析／設計での手戻りや再調査を最小化できる。

APIを用意したプラットフォーム

　次に、「方式設計」に当たるアーキテクチャル・ベースラインの説明に移ろう。

　先述したように、アーキテクチャル・ベースラインとは、「実行可能なアーキテクチャ」と「アーキテクチャ説明書」という2つの成果物の初期リリースを合わせたものである。

　「実行可能なアーキテクチャ」と言っても、ピンと来ない読者がいるかもしれないので説明しておこう。

　実行可能なアーキテクチャ（以下アーキテクチャ）とは、単なる「アーキテクチャの設計文書」ではない。ユースケースの実装時にイベントフローをそのまま表現できるAPI（Application Program Interface）が用意された「開発プラットフォーム」のことである。ここは重要な点なので、しっかりと理解してほしい。

図4に、UPにおけるアーキテクチャの構造を示した。図に示すように、アーキテクチャは非機能要件を満たすコンポーネントが実装された「システムソフトウエアレイヤー」と、汎用的なコンポーネントが実装された「アプリケーション汎用レイヤー」で構成される。システム固有のユースケースをコンポーネントとして実装するのは「アプリケーション固有レイヤー」だが、このレイヤーはアーキテクチャには含まない。

図4●アーキテクチャの構造

汎用性の高いコンポーネントを実装した「アプリケーション汎用レイヤー」と、ミドルウエアやＤＢといったインフラから成る「システムソフトウエアレイヤー」で構成される

 

　アーキテクチャには、(1)ユースケースで表現された機能要件を、高い抽象度で実装することができる、(2)アーキテクチャに可用性や性能などの非機能要件を実装することで、それらのメカニズムがユースケースの実装時に隠蔽される――という2つの目的がある。例えば「口座」というAPIがアーキテクチャに用意されており、そこにトランザクション管理のメカニズムまで実装されていれば、詳細設計や実装を担当するエンジニア（以下開発者）は安心してユースケースのイベントフローの実装に専念できる。

　ソフトウエアには「動作させなければ完全な検証はできない」という特性がある。設計文書だけで開発を進めるのはリスクが大きすぎるのだ。UPでは早期に“動く”アーキテクチャを構築して検証することで、プロジェクト前半の推敲フェーズで深刻なリスクを排除できる。

　アーキテクチャの構築は、「ソフトウエアアーキテクト」（UPが定めたエンジニアの役割の1つ、以下アーキテククト）が責任を持つ。アーキテクチャの構築に際して、「ユースケース仕様書に記述された内容を、一貫性があり最小コストで実装可能な環境を準備する」ことが、アーキテクトのミッションだからだ。

　開発者がユースケースのイベントフローで表現されたシステムの振る舞いを、自らが試行錯誤することなく、できるだけ設計しやすく実装しやすい環境を提供することが、アーキテクチャを構築するアーキテクトの目標となる。間違っても、オープンソースのフレームワークを組み合わせて、「これがアーキテクチャです」などと簡単に言ってはならない。作成フェーズ以降、開発者が「迷うことなく」、「安心して」ユースケースの実装に専念できる環境が構築されれば、アーキテクトの作業は8割方終わったようなものである。

開発者にアーキテクチャを説明

　アーキテクチャル・ベースラインを構成するもう1つの成果物が「アーキテクチャ説明書」である。この文書は構築されたアーキテクチャ以上にプロジェクトに与える影響が大きい。

　アーキテクチャ説明書は、ユースケース実装時のアーキテクチャの活用方法を中心として、複数の観点からアーキテクチャの利用方法について記述した文書である。アーキテクチャを正しく利用するための、開発者向けの開発マニュアルや開発ガイドラインという位置付けだ（表1）。

表1●アーキテクチャ説明書に記載する項目

アーキテクチャ設計書は、作成フェーズ以降に携わる開発者に対して、アーキテクチャの利用を促進し、その特徴や構造、利用方法などを正しく理解してもらうために作成する極めて重要なドキュメントである

 

　アーキテクチャ説明書の目的は2つある。1つは「アーキテクチャの適切な利用」であり、もう1つは「一貫したシステム構造の維持」だ。

　開発者は、アーキテクチャに含まれる再利用可能なコンポーネントを活用し、効率的に開発を進めるために、アーキテクチャ説明書の記述に従ってユースケースの設計・実装を進めていく。

UPにおける作成フェーズ以降の開発では、複数の開発者が並行して設計・実装する。また、開発プロジェクトの期間中や開発終了後には修正／機能追加の作業も含めて開発者の入れ替えが発生する。こうした前提で、開発者がアーキテクチャを適切に理解し一貫性を持った開発を進めるために最も重要な文書が、アーキテクチャ説明書なのである。

　このアーキテクチャ説明書によって、アーキテクチャ上にAPIとして準備されているコンポーネントを適切に選択し、適切に利用することが可能となる。その結果、様々なユースケースを複数の開発者が並行して実装する場合にも、アーキテクチャ上のAPIの利用場面、利用方法に一貫性がもたらされる。

　このアーキテクチャ説明書もアーキテクトが記述する。この際、開発者が迷わず適切にアーキテクチャを利用できるよう、複数の観点からアーキテクチャの活用方法をできるだけ具体的に記述することに注力するべきだ。

　試行錯誤を終えた（推敲フェーズを終えた）作成フェーズ開始後も、推敲フェーズの時点では想定できなかった変更はもちろん存在するだろう。このため、UPではシステムが開発・維持されている期間を通して、継続的にアーキテクチャおよびアーキテクチャ説明書を更新し、変更履歴の管理を行うことになっている。

アーキテクチャ構築の手順

　ここからは、アーキテクチャル・ベースラインを構築するための手順を具体的に見ていこう（図5）。

図5●アーキテクチャの構築手順

 

ステップ(1)
重要なユースケースの選定

　最初に、既に作成されているユースケースから以下の観点で「アーキテクチャ上重要なユースケース」を複数個選定する。

(1)最も重大なリスクを緩和するために役立つユースケース

(2)システムのユーザーにとって最も重要なユースケース

(3)典型的なシステムの振る舞いを表現するユースケース

(4)システム上重要な機能を漏れなくカバーするために役立つユースケース

　アーキテクチャの初期リリース（ベースライン）では、ここで選択したユースケースが利用可能な機能として動作している状態となる。システムによって異なるが、目安としては、総ユースケース数の1/5～1/10程度が適切だろう。ここで多くのユースケースを選んでしまうと、アーキテクチャ構築にかかるコストが大きくなりすぎる。選択したユースケースの一覧は、アーキテクチャ説明書の項目の1つである「アーキテクチャの実現項目」に記述しておく。

　アーキテクトはこの時点で、システムがどのように利用されるのか、システムの位置付けや目的が何なのかをしっかりと認識しておかなければならない。そうでなければ適切なユースケースを選択することはできない。そのために、できれば方向付けフェーズから積極的にプロジェクトに参加し、システムの目的や重要な機能について把握しておくべきである。

ステップ(2)
アプリケーション汎用レイヤーの設計

　次に、選定したユースケースのイベントフローから、アーキテクチャに含まれる「アプリケーション汎用レイヤー」として実装すべきクラス（分析クラス）を抽出する。

　抽出の基準は、対象となるビジネス領域全体で使用できるかどうかである。例えば、「口座」、「顧客」、「株式」など、ビジネスにおける一般用語で表現され、複数のユースケースやサブシステムから同じ意味として扱うことができるクラスを選択する。その結果、抽出されたクラス間の関連を表現した「分析モデル」が出来上がる（図6）。

図6●アプリケーション汎用レイヤーのための分析モデルの作成

ユースケースのイベントフローからビジネス全体に共通する用語をクラス（分析クラス）の候補として選定。クラス同士の関連や他のクラスとの関連を考慮して「分析モデル」を作成する

 

　この時点では、技術的な観点は絶対に含めてはならない。常にビジネス領域の観点からクラスを抽出して分析モデルを作成する。分析モデルは、アーキテクチャ説明書には「アーキテクチャの構造」という項目に記述しておく。

　作成した分析モデルに対しては、アーキテクチャに実装するクラスと、個別のユースケース実装時に作り込むクラスのバランスが取れているかどうかを慎重に検討する必要がある。アーキテクチャに実装するクラスが多すぎると、アーキテクチャが肥大化して理解しづらく使いづらいものとなる一方、少なすぎると個別のユースケースの実装が複雑になってしまうからである。

ステップ(3)
システムソフトウエアレイヤーの設計

　アプリケーション汎用レイヤーの分析モデルを作成したら、次に非機能要件を満たすコンポーネントを実装するシステムソフトウエアレイヤーを設計・実装する。

　このレイヤーには、分散オブジェクト通信、障害回復、ロギング、トランザクション、キャッシュなどのほか、ユーティリティやフレームワーク、プログラミング言語など、ビジネス領域に依存しないコンポーネントがすべて含まれる。

　システムソフトウエアレイヤーとしては、可用性、性能などの非機能要件および制約の観点から技術を選択して、実現可能な構造を構築する。この際、「JIS X 0129」や「FURPS+」といったガイドラインを活用することをお勧めする。システムソフトウエアレイヤーで実現する非機能要件の一覧は、「アーキテクチャ説明書のアーキテクチャの実現項目」に記述しておく。

　システムソフトウエアレイヤーの設計では、J2SE（Java2 Platform, Standard Edition）などの標準APIをはじめ、ライブラリやコンポーネント、フレームワーク、さらに自作のクラス群を用いて、「非機能要件の充足」および「アプリケーション汎用レイヤーからの利用のしやすさ」という観点でAPIを定義する。

　ここで、採用する製品の最終的な選定を行う。実際にはプロジェクト開始当初から選定されていることがほとんどだが、厳密に合理性を考えると、言語の選択も含めてこの段階で行うべきである。アーキテクチャ説明書では、「アーキテクチャの構造」の項目にシステムソフトウエアレイヤーを構成するコンポーネントやサブシステム間の関連を表現した設計モデルを、「アーキテクチャの実装要素」および「アーキテクチャの物理的配置」の項目に物理的な構造を記述しておく。

　「Struts」などのフレームワーク、「Apache」や「Tomcat」のようなWebサーバーやWebアプリケーション・サーバーは、このシステムソフトウエアレイヤーとして位置付けられる。つまり、ビジネスに直接関係しないコンポーネント群は、基本的にすべてシステムソフトウエアレイヤーに包含される。

　ユースケース実装時のシステムソフトウエアレイヤーの利用方針も決定しておく。例えば、アプリケーション汎用レイヤーのAPIを使うのか、システムソフトウエアレイヤーのAPIを直接利用するのか、といったことだ。重要なのは、これらの決定事項も必ずアーキテクチャ説明書の中に表現しておくことである。ユースケースの実装時に直接フレームワークを呼ぶのであれば、アーキテクチャ説明書の「ユースケースの実現」という項目に、その旨を記述しておかなければならない。

ステップ(4)
アーキテクチャの実装

　システムソフトウエアレイヤーを設計・実装したら、そのAPIを使って、先述した分析モデルをアプリケーション汎用レイヤーとして設計・実装していく。

　ここで重要になるのが、アプリケーション汎用レイヤーからシステムソフトウエアレイヤーを利用する方法を確立・パターン化し、アーキテクチャ説明書に文書化することである。具体的には、アーキテクチャ説明書の「アーキテクチャの構造」、「アーキテクチャの振る舞い」、「アーキテクチャの実装要素」および「アーキテクチャの物理的配置」という項目に記述する。こうすることで、将来システムに手を入れるであろうまだ見ぬ開発者に対しても、アーキテクトが意図した形でアーキテクチャを利用してもらえる。

　最初のビルド（ソースコードをコンパイルして実行可能なプログラムにすること）で構築されたアーキテクチャは、ユースケースに定義されたすべての機能は実装されていない「骨格」の状態と言える。

　この時点でシステムソフトウエアレイヤーのAPIの利用に無理が生じるようであれば、アーキテクチャを利用する開発者に混乱を招くだけでなく、間違いなくシステム構造の一貫性が保てなくなり、保守が困難なシステムが出来上がる。そこで、デザインに無理はないか、レイヤー間の境界は適切か、利用技術は適切か、非機能要件は満足できるか、システムソフトウエアレイヤーは適切に隠蔽できているか、といった様々な観点で十分に検証する。この最初のビルドでの試行錯誤が、システムの将来を決定すると言っても過言ではない。

ステップ(5)
重要なユースケースの分析・設計・実装

　最後に、最初のステップで選択した「アーキテクチャ上重要なユースケース」を実際にアーキテクチャを利用して実装することで、アーキテクチャを検証する。選択したユースケースに対して、要求・分析・設計・実装・テストという一連の作業を実施して、アーキテクチャとして不足している部分はないか、冗長なコンポーネントはないか、分かりやすく使いやすいAPIとなっているかどうかを検証するわけだ。

　同時に、開発者にとって最も重要な指針となるアーキテクチャ説明書の「ユースケースの実現」という項目に、実際にアーキテクチャを利用してユースケースを分析・設計・実装するためのガイドラインを記述する。開発者は、ここに記述された設計指針に従って、各自が担当するユースケースを分析・設計・実装するため、例えば「口座情報を更新する場合は、必ずCustomer.getModifiableAccount( )によって取得した変更可能な口座インスタンスに対して行うこと」というように、なるべく具体的に記述する。

ステップ(6)
アーキテクチャルベースラインの確立

　「いかに開発者に機能のみの実装に集中してもらえるか」――。アーキテクトはこうした観点で、選択したユースケースの分析・設計・実装を試みなければならない。もしアプリケーション汎用レイヤーに重要なクラスの見落としがあれば、この時点で再度アプリケーション汎用レイヤーを分析・設計・実装する。システムソフトウエアレイヤーで担うべき処理、例えばコネクションの確立などの実装が新たに必要であれば、システムソフトウエアレイヤーに立ち戻って定義する。

　選択したユースケースを実装する際は、開発者自身が「このクラスはアーキテクチャのAPIにあるはずだ」、「これは自分で作り込む処理だ」といった判断ができるレイヤー境界の設定、レイヤー間の役割分担にこそ最も気を配りたい。それがシステムの一貫性を保ち、ひいては保守性・品質・再利用性につながる。

　適切に選択したユースケースに基づく安定したアーキテクチャがあれば、作成フェーズでの残りのユースケースの実装コストが大幅に軽減される。またここでの作業結果は、開発者によるユースケース実装の作業コスト見積もりの基礎情報にもなる。選択したユースケースの実装作業が終われば、アーキテクチャル・ベースラインが確立したことになる。

開発者に優しいアーキテクチャ

　以上、UPにおける基本設計の流れと成果物について解説してきた。巨大で理解しにくいというイメージがつきまとうUPだが、“動く”アーキテクチャを構築することによりプロジェクトのリスクを軽減する、という基本設計の目標は認識していただけたのではないだろうか。

UPは、高品質のシステム開発を目指す一方で、システムの規模や複雑さに比例して責任範囲が増加し様々な負担が増大している開発者の現状を改善することも目指している。

　今後、アーキテクトとしてアーキテクチャ構築に携わる機会があるなら、機能を実装するためのアーキテクチャの構造に気を配るだけではなく、そのアーキテクチャを使うメンバーに優しいアーキテクチャを作るという観点を持って臨んでほしい。

Part4　方式設計で利用できる「パターン」を知る

高品質で変化に強いシステムは、アーキテクチャの良し悪しに依存する。だがアーキテクチャの設計は、外部システムとの連携や性能・信頼性の確保など考慮すべき点が多く、困難を極める。そこで利用したいのが、先人たちが生み出した方式設計のひな型である「パターン」だ。

　ここ数年で、「パターン」という言葉がよく使われるようになった。読者も耳にしたことがあるだろう。

　そもそも「パターン（Pattern）」とは、ある問題の解決策をテンプレート（ひな型）として記述したものである。問題を解決する手順や方法が記されているため、パターンを利用することで、迅速かつ確実に問題を解決できる。採用したパターン名をお互いに伝え合えば、メンバー間のコミュニケーション・ギャップも少なくなる。ただし、何でもパターンになるわけではない。再利用の価値があるものだけがパターンとなる。

　パターンそのものの起源は古く、1970年代に米カリフォルニア大学のC.アレキサンダー教授が著した「パタン・ランゲージ―環境設計の手引」と「時を越えた建設の道」（ともに鹿島出版会刊）という書籍に始まる。この中で、建築のセオリーをいくつかのパターンにまとめ、その有効性を提唱したのだ。

　このパターンを、ソフトウエアの分析、設計、実装に適用したのが「ソフトウエア・パターン」だ。具体的には、「XP（eXtreme Programming）の父」と呼ばれるケント・ベック氏らが、1987年にソフトウエア開発にもパターンが有効であることを初めて発表。この業績が、1993年に発足した「Hillside Group」と呼ぶパターンに関するコミュニティや、「PLoP」というパターンのイベントに受け継がれた。

　そして日本でも、1999年にソフトウエア・パターンのコミュニティ「JPLoP」が発足。2003年には情報処理学会のソフトウエア工学研究会内に、「パターンワーキンググループ」が発足した。ここで、ソフトウエア・パターンに関する様々な研究・啓蒙活動が行われている。

　こうしたコミュニティやワーキンググループ、実際の開発現場において、ソフトウエア・パターンの有効性は既に実証されている。

　ただ注意すべきなのは、すべてが「パターンありき」ではないことだ。筆者も昔そうだったが、パターンを覚えたての頃はとかくパターンを使いたがる。だがパターンは「問題」に合わせて適材適所で利用すべきものだ。何にでもパターンを使えばよいわけではない。重要なのは、パターンの特徴を正しく理解し、システム開発の各場面によって使い分けることである。

　そこでPart4では、基本設計フェーズで利用できるパターンの種類や特徴について解説していこう。基本設計に携わっているエンジニアはしっかりと理解してほしい。ある程度の知識を持っているエンジニアも、復習のつもりで読んでいただきたい。

基本設計で使える3パターン

　一口にソフトウエア・パターンと言っても、開発フェーズごとに利用できるパターンは異なる（図1）。基本設計フェーズで利用できるパターンとしては、（1）「インテグレーション・パターン」、（2）「アーキテクチャ・パターン」、（3）「アプリケーション・アーキテクチャ・パターン」の3つがある（表1）。

図1●分析・設計・実装のひな型となるソフトウエア・パターン

パターン（Pattern）には様々な種類があり、開発プロセスの各フェーズで適用できる

表1●基本設計フェーズの方式設計（アーキテクチャ設計）で利用できる主なパターン

 

　これらのパターンは、基本設計フェーズの中でも特に方式設計（アーキテクチャ設計）で利用価値が高い。方式設計では、要件定義フェーズで定義した機能要件や非機能要件、制約条件を実現するために、ハード／ソフトの構造（アーキテクチャ）を明確にし、具体的な実装方針を決定する。ここで、上に挙げた3つのパターンが有効に利用できる（図2）。

図2●方式設計におけるパターンの適用イメージ

外部システムとの連携方法は「インテグレーション・パターン」、対象システムの内部分割は「アーキテクチャ・パターン」、分割した名要素の実装方針は「アプリケーション・アーキテクチャ・パターン」を適用できる

 

1つ目のインテグレーション・パターンは、外部システムとの連携方法を決定するためのパターンである。

　方式設計では、最初に外部システムとの連携手段を決定する。外部システムがメインフレームであればELT（Extraction Load Transformation）と呼ぶファイル転送の仕組みを選択できるし、外部APIやプロトコルが明確であれば、外部呼び出しによる連携が可能だ。場合によっては、外部システム側に連携手段を持たせることも検討すべきだろう。こうした外部システムとの連携手段をパターン化したのがインテグレーション・パターンだ。最も代表的なものは、グレガー・ホペ氏の「Enterprise Integration Pattern（EIP）」である。

外部システムとの連携手段が明確になったら、対象システム全体を「実行上の役割」に応じていくつかの「要素」に分割する。例えば、Webシステムでよく利用される「3層アーキテクチャ」では、ユーザー・インタフェース層、ビジネスロジック層、データアクセス層に分割する。このようにシステム全体を実行上の役割で分割する方法を示したのが、2つ目の「アーキテクチャ・パターン」である。最も代表的なパターンは、F.ブッシュマン氏の「Pattern-OrientedSoftware Architecture（POSA）」だ。

　システム全体を要素に分割したら、各要素の実装方針を決定する。アーキテクチャ・パターンの1つであるMVCパターン（ビジネスロジック＝Model、表示＝View、制御＝Controllerの3つに分割するパターン）を採用する場合は、ViewとControllerにソフトウエア・フレームワークの「Struts」を利用するという具合だ。こうした実装方針を明確にしておかないと、後でシステムに不整合が生じやすい。このような各要素の実装方針をパターン化したのが、3つ目の「アプリケーション・アーキテクチャ・パターン」である。最も代表的なパターンとしては、Webシステムとオブジェクト指向を対象にしたM.ファウラー氏の「Pattern of EnterpriseApplication Architecture（PoEAA）」がある。

外部連携の手段を4つに分類

　それでは、3つのパターンの代表例について詳細に紹介していこう。まずは、インテグレーション・パターンの代表例であるEnterprise Integration Pattern（EIP）だ。

EIPは、外部システムとの連携手段（インテグレーション・スタイル）を、（1）「ファイル転送」、（2）「DB（データベース）共有」、（3）「リモートプロシジャ呼び出し」、（4）「メッセージシステム」という4つのパターンに分類している（表2）。

表2●EIPで定義している4つのパターン

EIPでは、外部システムとの連携方法を大きく4つに分類している。このうちメッセージシステムに関するパターンについては、さらに61種類の詳細なパターンを定義している

 

1つ目のファイル転送は、外部システムとファイルをインポート／エクスポートして連携するパターンである。メインフレームとの連携でよく利用されるが、一般的に連携のタイミングを制御するのが難しく、連携速度が遅いという欠点がある。

2つ目のDB共有は、外部システムが扱うデータベースのテーブルを公開し、そのテーブルを対象システムから参照・更新するパターンである。外部システムと連携するためのプロトコルを対象システムが保持していない場合は、このパターンを使うことが多い。

3つ目のリモートプロシジャ呼び出しは、外部システムが持つ連携用のAPIやプロトコルを利用して連携するパターンである。SOAPを利用したWebサービスのプロシジャ呼び出しは、このパターンの典型例だ。

構成要素ごとにパターンを定義

　最後のメッセージシステムは、メッセージ（電文）通信で連携するパターンである。電文は、ファイル転送よりも容量が小さく、リアルタイム性が求められる場合に向く。メッセージシステムでは、構成要素を6つに分類し、それぞれについて詳細なパターンを定義している。EIPの提唱者であるグレガー氏は、この6つの要素の表記法（グレガーグラム）も定めている。

1つ目の構成要素は、外部システムと連携する電文を指す「メッセージ（Message）」である。メッセージについては、メッセージが持つ意味（機能の呼び出し、電文の送信、イベントの発生など）に関するパターンや、送信順序の制御に関するパターン、要求と返答の関連に関するパターン、メッセージの有効期限に関するパターンなど、全部で10種類のパターンを定義している。2つ目は、連携するシステムとの接続インタフェースを指す「エンドポイント（EndPoint）」だ。エンドポイントについては、メッセージの到着・確認のタイミングに関するパターンや、受信するメッセージのタイプに関するパターンなど、全部で12種類のパターンを定義している。

3つ目は、メッセージシステムの送信経路を表す「チャネル（Channel）」である。チャネルに関しては、接続先の数に関するパターンや、不正／無効メッセージの処理に関するパターン、メッセージ同士の接続に関するパターンなど、全部で10種類のパターンを定義している。4つ目は、メッセージの種類によって複数のチャネルにメッセージを振り分ける機能である「ルーター（Router）」だ。ルーターについては、メッセージの振り分け方法（メッセージの内容やチャネルの状態に応じた振り分けなど）に関するパターンや、メッセージ内容の分割・統合に関するパターン、メッセージの処理順序の制御に関するパターンなど、全部で14種類のパターンを定義している。

5つ目は、メッセージを受信側が理解できるよう変換する機能である「トランスレータ（Translator）」だ。例えば、送信側が「姓」と「名」を分けてメッセージを送信したら、受信側は「姓名」という1つのメッセージとして受信するとしよう。このときにメッセージの変換を行うのがトランスレータの役割である。トランスレータについては、メッセージの内容にデータベースの情報を付加するパターンや、メッセージ内容を一時的に削除するパターン、削除した内容を元に戻すパターン、メッセージを正規化するパターンなど、全部で7種類のパターンを定義している。

　最後は、メッセージやチャネルの状態などを監視する機能である「モニタリング（Monitoring）」である。モニタリングでは、監視対象（メッセージの処理状況やチャネルの状況など）に関するパターンや、監視結果に伴う動作（メッセージの保存やチャネルの変更など）に関するパターン、テストメッセージの利用方法に関するパターンなど、8種類のパターンを定義している。

図3に、例としてチャネルのパターンの1つである「データタイプチャネル」と、メッセージのパターンの1つである「フォーマットアイデンティファイ」を示した。

図3●メッセージシステムの代表的なパターン

EIPでは、「グレガーグラム」と呼ぶ表記法でメッセージシステムのパターンを定義している。ここでは、61種類あるパターンのうち、代表的なデータタイプチャネルとメッセージアイデンティファイをグレガーグラムで示した

 

　「データタイプチャネル」は、メッセージの種類ごとにチャネルを用意するパターンである。チャネルが増えて管理しにくくなるが、メッセージの種類を判定する必要はない。チャネルの数を増やすことで、メッセージの複雑性も解消できる。

　一方の「フォーマットアイデンティファイ」は、ID情報をメッセージに含めて送信し、ID情報に従ってルーターがエンドポイントに適切に振り分けるパターンである。

要素分割の方法を体系化

　次に、アーキテクチャ・パターンの代表例である「Pattern-Oriented Software Architecture（POSA）」について説明しよう。

　方式設計は、開発の初期段階で実施するため、システム全体が混沌とした状態にある。ここで、全体を大きな1つの固まりとしてとらえると、どんなに優秀なエンジニアでも混沌の中に飲み込まれるだろう。そこで、システム全体をいくつかの要素に分割し、その集合として全体を表現する方法を体系的に示したのがPOSAである。

POSAでは、（1）「構造」、（2）「分散システム」、（3）「対話型システム」、（4）「適合型システム」という4つのカテゴリに分類し、各カテゴリごとに要素の分割方法をパターンとして定義している（表3）。

表3●POSAで定義している主なパターン

POSAのパターンは、これまで使われてきたソフトウエアの基本構造を、典型的な特徴によって整理・分類したものである

 

　最初の「構造」カテゴリのパターンとしては、システムをレイヤーで分割する「レイヤーパターン」、アプリケーションを処理（フィルタ）とデータの経路（パイプ）で分割する「パイプ＆フィルタパターン」、アプリケーションを部分的な問題を解決する複数のコンポーネントと、それを協調動作させるコンポーネントに分割する「ブラックボードパターン」がある。

　例として図4にレイヤーパターンの代表例である「OSI基本参照モデル」を示した。OSI基本参照モデルでは、ネットワーク全体を物理層からアプリケーション層までの7つのレイヤーに分け、それぞれのレイヤーの役割や、隣接するレイヤーとやり取りするためのプロトコルを決めている。

図4●POSAのレイヤーパターンとブローカパターンの例

　レイヤーパターンで重要なことは、各レイヤーは直接隣り合うレイヤーしか認識しない、ということだ。OSIの例で言えば、ネットワーク層（3層）は物理層（1層）とプロトコルをやり取りできない。こうすることで、混沌としたネットワーク全体を整理し、秩序を作り出しているわけである。

2つ目の「分散システム」カテゴリは、グリッド・コンピューティングやWebサービスなど、複数のコンピュータ上のサービスがネットワークを介して連携するケースを想定している。

　このカテゴリでは、「ブローカパターン」を定義している。これは、各サービスの内容を「ブローカ」に登録し、クライアントがそのブローカを経由して分散するサービスを検索・実行するパターンである。分散するコンピュータ同士が独自の方法で連携し合うとシステム全体が非常に複雑になる。これに対してブローカパターンを利用すると、各システムはブローカとの接続だけを考えればよいので、システム全体がシンプルになる。

　ブローカパターンの代表例としては、分散したサービス同士を連携させるSOA（Service Oriented Architecture）で、各サービスを「ESB（Enterprise Service Bus）」で結ぶケースが考えられる。この場合、ESBがブローカに当たる。クライアントはESBにあらかじめ登録されたサービスの情報を参照して利用したいサービスを呼び出せばよいので、各サービスの透過性は一気に高まる（図4下）。

変更の影響を局所化

POSAの3つ目のカテゴリである「対話型システム」と4つ目の「適合型システム」は、変更に強いアーキテクチャを構築するためのパターンと言える。

　対話型システムは、WordやExcelなどのように、GUI（Graphical User Interface）を使って対話的に処理を進めるための構造をパターン化したものだ。このカテゴリのパターンとしては、アプリケーションを入力と表示を実現する「Presentation」、ビジネスロジックを実現する「Abstraction」、両者を制御する「Control」の3つに分割するPACパターンや、先述したMVCパターンがある。いずれも変更を受けやすいユーザー・インタフェースをその他の機能と分離し、変更による影響を局所化するのが目的である。

　一方の適合型システムでは、より変化の激しい分野でシステム全体の拡張性を高めるためのパターンを定義している。具体的には、「マイクロカーネルパターン」と「リフレクションパターン」の2つがある。

　マイクロカーネルパターンは、中核となる機能や連携手段を「マイクロカーネル」として独立させるパターンだ。代表例としては、UNIXやLinuxなどのカーネル（基本機能）がある。リフレクションパターンは、アプリケーションをコンポーネントの構造や振る舞いを定義した「メタレベル」と、それに基づいてコードを生成する「ベースレベル」に分類するパターンである。アプリケーションの構造や振る舞いに変更があっても、メタレベルの変更だけで対応できる。代表例としては、JavaのReflectionがある。

Web開発で不可欠なPoEAA

　最後に、アーキテクチャ・パターンで分割した各要素の実装方針を決定するアプリケーション・アーキテクチャ・パターンの代表例である「Pattern of Enterprise Application Architecture（PoEAA）」を紹介しよう。PoEAAは、Webシステム開発では欠かせないパターンになりつつある。

PoEAAで定義しているパターンは、オブジェクト指向によるWebシステム開発を対象としており、大きく（1）「ドメインロジック」、（2）「O/Rマッピング」、（3）「Webシステム」、（4）「分散システム」という4つのカテゴリに分類できる（表4）。

表4●PoEAAで定義している主なパターン

PoEAAでは、Webシステムをオブジェクト指向言語で開発する際の実装方針を定義している

 

1つ目のドメインロジックは、ビジネスロジックの実装方針を示すパターンだ。特に、トランザクション単位でビジネスロジックを記述し（データは持たない）、それをオブジェクトとする「トランザクションスクリプトパターン」や、ビジネスロジックとデータを1つのオブジェクトとして記述する「ドメインモデルパターン」が有名である。また、モジュールが持つクラスにDBのテーブルと同じ属性を設定し、メソッドがレコードを特定できるIDを引数として利用できるようにする「テーブルモジュールパターン」というパターンもある（図5上）。

図5●PoEAAのドメインロジックパターンとO/R構造パターンの例

 

2つ目のO/Rマッピングは、オブジェクトとRDB（リレーショナル・データベース）をどのように結び付けるのかをパターンとして定義したものである。データベースのアーキテクチャに関するパターンや、オブジェクトとデータベースのライフサイクルの違いを配慮して整合性を保つためのO/R振る舞いパターン、「継承」などのオブジェクトとデータベースの構造の違いを配慮してマッピングするためのO/R構造パターンなどがある。

　例えば、O/R構造パターンの1つである「シリアライズLOBパターン」は、複雑な階層構造を持つオブジェクトをそのままファイル化（シリアライズ）し、LOB（Large OBject）と呼ぶデータ型でRDBのカラムに格納するパターンである（図5下）。

3つ目のWebシステムでは、Webシステム特有の問題を解決するためのパターンを定義しており、Webシステムの画面をどのように分離し、各画面を具体的にどう実装するかを示したWebプレゼンテーションパターンと、主にHTTPの入力をどう処理するかを示したセッションステートパターンがある。

　最近は、Webシステムとして携帯電話もサポートするケースが増えている。この場合、Webプレゼンテーションパターンの1つである「ツーステップビューパターン」を利用できる。これは、最初のステップでパソコンと携帯電話の双方で共有できる画面を作り、その後携帯電話のキャリアごとの画面を作成するパターンだ。

　最後の分散システムは、分散している様々なロジックをどう連携させるかを示したパターンである。

　分散環境では、ネットワークのトラフィックを考慮してリモート呼び出しを最小限に抑える必要がある。だが通常は、オブジェクトの柔軟性を高めるために各オブジェクトの粒度が小さくなっており、結果的にリモート呼び出しが増える傾向にある。分散システムでは、この問題を改善するために、「ファサード（門）」と呼ぶオブジェクトを通じて分散するオブジェクトを機能単位で束ねてリモート呼び出しする「リモートファサードパターン」と、「DTO（Data Transfer Object）」と呼ぶオブジェクトを通じて分散するオブジェクトのデータを抽出する「データ変換オブジェクトパターン」を定義している。

　以上、方式設計で適用できる3つのパターンについて解説してきた。設計において重要なことは、網羅的に考え、複数の解を検討し、決定することだ。そのためにも、自分自身の経験だけでなく、先人たちが生み出したパターンを知り、実際に開発現場で活用することは極めて重要である。この記事を参考にして、さらにパターンに対する理解を深めていただければ幸いである。

Part5　基本設計におけるレビューの勘どころ

Part5では、基本設計フェーズにおける成果物の品質を向上させる施策について解説する。カギは、欠陥を除去するとともに欠陥を防止する仕組みを確立すること。重要な成果物については有識者を交えて「インスペクション」を実施することも大切だ。

　「考慮していない外部システムとの連携が詳細設計で見つかった」、「仕様間の不整合が実装フェーズで発見された」――。どんなに基本設計をしっかりやっても、その後のフェーズで「欠陥」が見つかれば意味がない。欠陥が発見されれば手戻りが発生し、進ちょく遅れや収益悪化といったプロジェクトの混乱を招く。

　そこでPart5では、基本設計フェーズにおける品質向上のプロセスや成果物のレビュー方法について解説しよう。

「欠陥防止」を徹底する

　改めて言うまでもないが、基本設計の成果物の品質を向上させるプロセスは、（1）設計作業を実施する、（2）成果物をレビューして欠陥を洗い出す、（3）発見した欠陥を除去する――という3つのステップを踏む。このサイクルを繰り返し、すべての成果物に欠陥がないことを確認してユーザーからの承認を得られれば、基本設計が完了する。

　ところが、この品質向上プロセスにとらわれすぎて、逆に品質が上がらないプロジェクトが目立っている。と言うのも、設計作業の後でレビュアー（評価者）が成果物を評価するため、設計した本人が「どうせ後でレビューしてくれるのだから、これぐらいの内容でいいだろう」と考えてしまうことがあるからだ。つまり品質向上プロセスを徹底させることで、逆に設計者自身の成果物に対する責任を低下させ、問題を先送りにする体質が身に付く可能性がある。

　こうした問題を招く最大の原因は、品質向上プロセスの目的を「欠陥を除去する」ことだけに置く点だ。より大切なのは、「欠陥の除去」とともに「欠陥の防止」のための仕組みを確立することである。防止策を施すことで、設計者の品質に対する意識も変わってくる。

7つの準備を怠らない

　欠陥を防止する仕組みとは、「欠陥を作り込ませないための施策」を意味する。具体的には、次の7つの事前準備を基本設計フェーズの初期段階で実施する必要がある（図1）。

図1●レビュー効果を高めるために実施すべき主な事前準備

これらの事前準備を怠ると、時間をかけてレビューしてもなかなか欠陥の除去や発生防止につながらない。まずは事前準備を徹底することを心掛けるべきだ

1つ目は「レビュー体制の明確化」である。これは、ユーザー企業側、ベンダー側双方のレビュアーや、成果物を承認するためのルートを明らかにする作業だ。

2つ目は「進ちょく管理方法の確認」である。ここでは、EVMをはじめとする進ちょく管理手法や、基本設計のマイルストーン（終了基準）を明確にする。

3つ目は、「レビュー・ミーティングの種類と進め方の決定」である。これは、どんなレビューをどの時期に実施するのかを決める作業だ。レビューには、（1）設計者自身で成果物を検証する「セルフチェック」、（2）プロジェクト内で成果物を検証する「デザインレビュー」、（3）品質保証部門が抜き取りで成果物を検査する「ドキュメント探針」、（4）品質保証部門が全ドキュメントの合否を判定する「ドキュメント検査」、（5）設計プロセスとマネジメント・プロセスが正しく機能しているかどうかを検証する「プロセス評価」、そして（6）ユーザーが成果物の内容を承認する「顧客レビュー」――の6種類がある（表1）。これらのレビューをどのタイミングで実施するのかを明らかにする。

表1●基本設計フェーズにおける6つのレビュー

（1）～（4）、および（6）については成果物（ドキュメント）に対するレビューを行うが、（5）については設計プロセスおよびマネジメント・プロセスに対する評価を行う。これらのレビュー作業をプロセスに埋め込むと同時に、基本設計フェーズ終了後に実際にうまく機能したかどうかを検証することが重要である

 

4つ目は、「入力情報の確認と品質の確保」だ。基本設計の入力情報は、要件定義で作成した機能要件や非機能要件、制約条件である。だが、こうした入力情報が基本設計フェーズの初期段階で詳細になっているケースはまれだ。そこで設計作業に入る前に要件定義書を吟味し、不足している部分については改めて作成する。

5つ目は、「キックオフミーティングによるメンバー同士の意思統一」。これは、メンバー全員がプロジェクトの目的や基本設計の役割を共有し、コミュニケーションをスムーズに取れるようにするのが目的だ。

「設計ルール」を確立する

6つ目の「各種基準の整備」と、最後の「書き方に関するメンバー教育の実施」は、事前準備の中で最も重要なので特に詳しく説明しよう。

　基本設計における各種基準とは、設計に関する「ルール」のことである。プログラミング時に「コーディング規約」があるように、基本設計にも守るべき「ルール」が存在する。書き方に関するメンバー教育は、このルールに従って成果物を作成することを周知徹底するために実施する。

　基本設計の基準には、「成果物の種類」や「モデルの表記法」、「設計書のフォーマット」のほか、システム開発上使用するビジネス用語の意味をまとめた「ネーミングルール」、単語の表記（漢字・カナ・ひらがなの使い分けなど）を示した「用字・用語集」などがある。このうち成果物の種類やモデルの表記法については、ほとんどのケースで定義できているだろう。また、設計書のフォーマットについても、全社・グループ標準のフォーマットや、ユーザーから指定を受けたフォーマットを用いれば問題ない。

　忘れられがちなのは、ネーミングルールと用字・用語集をきめ細かく整備することだ。ネーミングルールや用字・用語集を侮る人がいるが、これほど重要なものはない。なぜなら、DFD（Data Flow Diagram）やER（Entity Relationship）図、クラス図など基本設計で作成すべき成果物のほとんどが、モノ（プロセスやデータ、オブジェクト）が何か、モノとモノの関係（リレーション）がどうなっているのかを示す。当然、モノを表す言葉が本来の意味と違っていたり、成果物間で表記がバラバラになっていたりすると、詳細設計以降で必ず問題が発生する。

内部レビューを徹底する

　これらの事前準備を徹底したうえで、ようやく実際のレビューを実施する。先述したように、レビューには目的によって6つの種類があるが、大別すると、「プロジェクトの内部によるレビュー」、「第三者機関によるレビュー」、「ユーザーによるレビュー」に分類できる。

　このうち最も重要なのは、プロジェクト内部、つまり自分たちで行うレビューだ。まずは自らが成果物の品質を高めるという姿勢を持つことが必須だからである。

　具体的なレビューの方法には、成果物の作成者とレビュアー（チーム・リーダーやメンバー）が一緒になって成果物を評価する「ウォークスルー」と、社内の有識者（特定の業種や技術に詳しい専門家、類似プロジェクトの経験者など）を集めて専門的な視点で成果物を監査する「インスペクション」の2種類がある。

　ただし、「有識者」を集めるインスペクションは、時間的、コスト的な制約があるために、共通性の高い、あるいは中核となる重要な機能についてのみ実施するケースが多い。

　ウォークスルーでは、専門的な視点が乏しく致命的な欠陥を見つけられないことがある。メンバー同士による「読み合わせ」が中心のウォークスルーでは、成果物そのものや成果物同士に矛盾がなければ、そのままレビューを通過することが多い。

　そこで、ウォークスルーを実施する際には図2に示すような視点でレビューする。まず、指定された設計書のフォーマットや表記法に従って作成しているかどうかをチェックする。また、モノの種類や名称、モノ同士の関連も確認する。

図2●レビュー時の主なチェックポイント

要件仕様を入力値とし、かつ決められた基準に則って設計されているかどうかを中心にチェックする

 

　このとき事前に作成したネーミングルールや用字・用語集に準じているかどうかについては、徹底的に検証したい。ユーザーによるレビューで、ユーザーがまず最初に見るのは、この「言葉遣い」である。自分たちが普段使っている呼称と違う単語が出てくるとすぐに気付く。しかも意味の取り違いや表記のブレがあると、それだけで成果物全体の品質が低いと判断されることが少なくない。

　このほか、「この成果物からテストケースを作れるか」という視点を持つことも重要だ。これは、IEEE830で定義している「ソフトウエア要求仕様の品質評価項目」の1つである「検証可能性」を評価することを指す。具体的には「何を」、「どのように」、「どうする」という入力、処理、出力の内容が明確になっているかどうかを確認する。

議論するインスペクション

　特に重要な機能については、ウォークスルーだけではなくインスペクションも必須となる。

　ただし、一般的なインスペクションでは、レビュアーが事前にチェックして発見した問題点を挙げ、それをリストアップして設計者に返すに過ぎない。有識者による解決策の議論は、あくまでインスペクションの対象外になっているのだ。

　これでは、せっかく貴重な時間を割いて集まっている有識者の「知恵」と「経験」を無駄にしてしまう。そこで日立製作所のように、有識者が議論しながら作業効率と確実性を高めるインスペクションのプロセスを体系化する取り組みも始まっている（図3）。

図3●日立製作所が体系化したインスペクションの手順

多忙な有識者を何度も集めることは困難なため、重要な問題点についてはインスペクションの中で5分程度の議論をするようにした。またレビュアーによる事前チェックと、問題点の収集をツールで行い、作業の効率化と確実性を高めた

 

　日立製作所におけるインスペクションのプロセスは、大きく「レビューの準備」、「レビューの実施」、「フォローアップおよびフィードバック」から成る。

　レビューの準備では、「レビュー計画の策定」、「チーム・リーダーによる成果物配布前の完成度チェック」、「レビュアーへの成果物の事前配布とレビュアーによる成果物の事前チェック」を行う。

　レビューの実施では、欠陥コメントの確認後、対策について議論する。具体的には、各レビュアーがあらかじめ洗い出しておいた問題点の内容を確認。それを基に問題点を解決するための方法を議論したうえで具体的な対策を決める。

　後はその対策が講じられたかどうかを追跡し（議事録配布と懸案事項のフォローアップ）、欠陥の傾向やレビュー時間当たりの欠陥摘出効率、成果物当たりの欠陥密度などを評価して品質向上プロセスを見直す（プロセス評価とフィードバック）。

プロセス評価を忘れない

　ここまで、プロジェクト内部によるレビューを中心に解説してきたが、もちろん「第三者機関によるレビュー」と、「ユーザーによるレビュー」でも考慮すべき点はある。

　例えば、品質保証部門やPMO（Project Management Office）などの第三者機関によるレビューで大事なのは、「プロセス評価」である。そもそもレビューの対象は、成果物だけではない。品質の高い成果物を生み出すための設計プロセスとマネジメント・プロセスもレビューの対象になる。仮に成果物自体には何の問題もなかったとしても、特定の設計者に作成作業が集中していたり、ほぼ徹夜漬けで成果物を作成していたりする状況になっていれば、設計プロセスやマネジメント・プロセスに何らかの問題があることが多い。

　一方、ユーザーによるレビューでは、時間軸に沿って3つの視点でレビューに臨むべきだ。

　まず基本設計フェーズの初期段階では、レビューの目的を「事前ヒアリング」と考える。これは、入力情報の不明点を明らかにしていくレビューと言える。

　基本設計フェーズの中盤では、「品質上の問題点の発見と是正」と位置付け、図2に示したチェックポイントを確実につぶして提出する。そして、基本設計フェーズの終盤のレビューの目的は、ご存じの通り「承認」となる。

　最初から「承認」のために、ユーザーによるレビューに臨んでいないだろうか。レビューの目的は「通す」ことではなく、あくまで「欠陥の除去」であることを忘れないでほしい。