特別企画：分析設計技法「三要素分析法」集中講座（1）

ユーザーと共通理解できる“システム観”が必要だ

渡辺 幸三
2005/10/20

企業システム開発では、しばしばユーザーの思いどおりのシステムに仕上がらないことがある。その大きな原因の1つが、ユーザーの“要求”と開発者の“理解”のズレだ。ユーザーと開発者が共通認識にたどり着くには、何が必要だろうか？（→記事要約<Page2>へ）

　業務システム向けの分析設計技法としてさまざまなやり方が提唱されています。有名なところがUMLを用いた「オブジェクト指向分析・設計手法」です。しかし、開発現場で実際に利用されているのは、昔から無批判に繰り返されてきた古めかしいやり方だったり、せいぜい「UMLもどき」とでもいえそうな案件ごと独自に「工夫」されたやり方です。

　UMLは、バラバラだったオブジェクト指向系の表記法を統一するための体系として鳴り物入りで登場しましたが、必ずしも当初の期待どおりの効果を挙げているわけではありません。それは、システム開発においてボトルネックになっているのが「システム開発者同士が標準的な形式でコミュニケーションできるかどうか」などではなく、いまだに「システム開発者とユーザーとが要件や仕様について分かり合えるかどうか」だからです。

　「技術者同士の意思疎通」よりも「技術者とユーザーとの意思疎通」の方が大事というのは、指摘されるまでもなく当たり前のことです。いくら各国に散らばる技術者同士が理解し合えたとしても、システムの当事者であるエンドユーザーがその在り方を理解できないのでは無意味なのですから。何よりも優先されるべきは「技術者とユーザーとの意思疎通」であって、それを意図した結果として「UMLもどき」になったのなら、それはそれで意味のあることかもしれません。

　本稿で紹介する分析設計技法「三要素分析法」はまさに「技術者とユーザーとの意思疎通」と「開発現場での実用性」を重視したやり方です。筆者がこのように主張する根拠は以下の2点です。それぞれを説明しましょう。

• 実践で練られた明快なシステム観に基づいている
• 専用のモデリングツールとそれで閲覧できる設計コンテンツが提供されている

-	「三要素分析法」のシステム観

　「分析設計手法なんてものはしょせん道具なのだからどんなものでもいい」という意見をよく聞きますが、そのいい方は正しいようで実は正しくありません。

　分析設計手法は「世界観」ならぬ「システム観」を設計者やユーザーに提供（強制）するもので、プロジェクトが生み出すシステムの基本構造はその枠組みに規定されます。それぞれの手法は異なるシステム観を背景にしているので、どの手法を選び取るかというのは決定的に重要です。その意味で分析設計手法は、気軽に手にされるべき「道具」ではなく、慎重に選定されるべき「目」です。

　三要素分析法は「業務システム」の論理要件を捕捉して視覚化するための方法です。「業務システム」とは企業活動を支援するデータベースシステムのことで、「基幹システム」とか「情報システム」とも呼ばれます。典型的な例が「販売管理システム」「生産管理システム」「会計システム」「人事給与システム」です。

　つまり、この手法はゲームソフトや組み込みソフト、OSといったドメイン（問題領域）を扱えるようにはできていません。その点はこの手法の弱点といえるでしょう。しかし、そもそもこれらの異質な分野を同等に扱えるような分析手法があったとしても、それを使うことに実利があるとは筆者には思えません。業務システムとゲームソフトや組み込みソフトの開発者が住む世界はまったく異なっていて、これらの技術者が分かり合わなければいけない局面などめったにないからです。

　三要素分析法が「業務システム」に特化しているということは、そのドメインに固有な特性を扱えるように最適化されているということです。では、ゲームソフトや組み込みソフトなどのほかのドメインと比較した場合、「業務システム」の特徴はどんなところにあるのでしょう。筆者は次の3つだと考えています。

• 帳簿組織（データベース）が中心に置かれている
• 多様なユーザーや取引先といった社会的な文脈を伴う
• 企業や実装技術の変化に追随する

　三要素分析法の「システム観」にはこれらの特性が反映されています。その様子を説明しましょう。

　まず図1を見てください。「実装」のブロックが、「論理要件」と「物理制約」という2つの礎石に載っています。これはシステムの実物（実装）が、「論理要件」と「物理制約」という2つの要素のせめぎ合いの結果として生み出されることを表しています。「論理要件」とはいわゆる「基本設計」のことで、システム開発の上流工程における主要な成果物です。「物理制約」はシステム開発過程での与件とされるさまざまな制約を表します（後述）。これらのブロックによる構造は、現実のシステムを見るときの基本的な枠組みです。

図1　「論理要件」と「物理制約」の礎石に「実装」のブロックが支えられている

　3つのブロックには「奥行き」があります。それを示したものが図2です。「データ構成」「機能構成」「業務構成」という3つのアスペクトが図1のブロック構造を縦断している様子に注意してください。「実装」も「論理要件」も「物理制約」もこれらのアスペクトで区分することで、システムの実体として理解しやすくなります。この3つのアスペクトこそが筆者のいう「業務システムの基本3要素」で、「三要素分析法」の呼称はここから来ています。

図2　3つのブロックには奥行きがある

　3つのブロックと3つのアスペクトを組み合わせることで9つの要素を切り出せます。それぞれをざっと見ましょう。

-	「三要素分析法」の9つの構成要素

　「データ構成」の「実装」である「データ実装」とは、実際のデータベースのことです。「機能実装」はプログラムのロードモジュールのことで、「業務実装」は業務手順の遂行能力を持つ実際の要員のことです。

　それらの実装物を下から支える礎石の一方が「論理要件」です。論理要件はアスペクト別に「データモデル」「機能モデル」「業務モデル」の3種類に区別され、それぞれ独特な図法を用いて視覚化されます（本連載の続編で説明します）。

　システム開発の上流工程の目標は、これら3種類のモデルを取りまとめることです。それも設計者が技術的な整合性を図りつつまとめるだけでなく、ユーザーがそれらを理解して検収できるようでなければなりません。したがって表記法としても、技術的にあいまいでなく、かつシステムの素人にとっても理解しやすいモデルとなるようなものが用意される必要があります。そのような表記法と、それぞれのモデルをまとめるための手順とがセットになった体系が、「三要素分析法」です。

　「実装」のブロックを支えるもう一方の礎石である「物理制約」を見ましょう。図2では隠れて見えないので、ブロックの位置をちょっとずらします（図3）。「データ構成」の物理制約は選定されたストレージ技術やDBMS（Database Management System）のことです。「機能構成」の物理制約は開発で利用されるプログラム言語やフレームワークといった実装技術やネットワーク技術に相当し、「業務構成」の物理制約は社風、評価制度、実要員や実組織といった経営資源に相当します。

図3　「実装」に影響を与える「物理制約」には社風や評価制度も含まれる

　以上が「三要素分析法」の「システム観」です。この見方に比較できるものとして、日本政府が推奨しているEAの4階層モデルや、ザックマン氏が提唱するフレームワークがあります。それらと比較してみても面白いでしょう。

	参考リンク
		ITアソシエイト協議会報告「業務・システム最適化計画について〜EA策定ガイドラインVer.1.1〜」（通商産業省）
		各府省情報化統括責任者（CIO）連絡会議報告「業務・システム最適化計画策定指針（ガイドライン）第4版」（e-Gov）
		ジョン・A・ザックマン論文「A framework for information systems architecture」（IBM > IBM Systems Journal）
		ジョン・A・ザックマンほか論文「Extending and formalizing the framework for information systems architecture」（IBM > IBM Systems Journal）

1/2

index 特別企画：分析設計技法「三要素分析法」集中講座（1） ユーザーと共通理解できる“システム観”が必要だ

Page 1 「三要素分析法」のシステム観 「三要素分析法」の9つの構成要素 　 Page 2 「方法論主導」から「コンテンツ主導」へ