三要素分析法の位置づけ 三要素分析法(TEA Method)は企業システムに特化した設計方法論です。つまり、「企業システム」という特定ソフトウエア領域の特性に合わせてまとめた手法であるため、森羅万象を扱えるような万能の分析・設計手法ではありません。個々の企業システムのあり方を押さえるために、三要素分析法では「企業システムの3要素」に注目します。 |
|||||||||||||||
「企業システムの3要素」とは
上流工程の成果物である「基本設計書」には何が盛り込まれるべきなのでしょう。流行の経営戦略用語を散りばめた社長受けする作文でしょうか。それとも、一見わかりやすそうに見えて実は曖昧で観念的なポンチ絵でしょうか。それとも、厳密ではあってもコンピュータの素人には了解不能な専門的な図面の山でしょうか。これらのどれでもありません。 個々の企業システムの様相を端的に示すために、「三要素分析法」では、「仕事のあり方を記述するための一般的な視点」として次の3つの側面に注目します。
企業システム向けのこれら3つの要素を明らかにすることが、システム開発の上流工程での課題です。これらを基本設計書で明確に示すことによって、下流工程において、移行済みデータベースと、それを処理するためのプログラム群、そしてそれらを用いて仕事を進めるための業務マニュアルや訓練された組織を実装できるようになります。 |
|||||||||||||||
どんな図法を使うのか 設計方法論であるからには、捕捉すべき対象だけでなく、それらの表現方法(図法)を明らかにしなければなりません。図法次第で分析の質や効率、またユーザーの仕様理解度に大きな差が出てくるからです。すなわち、分析対象が、エンドユーザに了解可能であると同時に詳細設計担当者にとっても曖昧でない――そのような表現方法が選定されなければなりません。三要素分析法では以下の4つの図法を用います。 データフロー図(DFD) 業務フローを描くための図法。業務フローは1回の「モデリングセッション」における分析課題の広がりを眺めるための図面で、三要素全体の連係様式を表す ER図(ERD) データ構成を視覚化するための図法。データ項目間の論理関係(項目間の関数従属性とテーブル間の多重度)が示される。描かれた図面はデータモデルと呼ばれる アクションツリー図 業務構成を視覚化するための図法。業務単位(ひとりの担当者が遂行する仕事のまとまり)毎に作業手順(プロトコル)が示される。描かれた図面は業務モデルと呼ばれる 機能展開図 機能構成を視覚化するための図法。あらかじめ定められたパターンにもとづく機能の入出力イメージと呼出関係が示される。描かれた図面は機能モデルと呼ばれる
|
|||||||||||||||
どんな手順で進めるのか
分析対象とそれらの表現形式を明らかにするだけでも、じつは十分ではありません。求められている図面を効果的・効率的に描き広げるための手順が必要です。標準的な手順は以下のとおりです。 概要設計 ユーザーの発言にもとづき、ひととおりのサブジェクトエリア(業務の意味のあるまとまり)毎に業務フローをその場で手書きでまとめる(ただし、構造化分析手法のようなDFDの階層化は不要) モデリングセッション ユーザーの発言にもとづき、それぞれのサブジェクトエリア毎にデータモデル、業務モデル、機能モデルの順にその場で手書きでまとめる とりまとめ 大量の手書き図面を整理して、その内容をX-TEA Modeler等の設計情報管理ツールに登録する レビュー 設計情報管理ツールを用いて妥当性をユーザーや同業者にチェックしてもらいながら、モデルを改善する 大きな特徴は、(1)モデリングがユーザとの打ち合わせのその場でなされる点、(2)現行システムを「発想の出発点」にしない点、そして、(3)同業者を含めた多様な関係者によって妥当性が検証される点、の3つです。それぞれを説明しましょう。 特徴(1)モデリングがユーザとの打ち合わせのその場でなされる 「三要素分析法」では、ユーザとの打ち合わせのその場で、ホワイトボード上にモデルを描き上げてしまうやり方をとります。それは、ユーザこそが基本設計情報の手がかりを得るためのもっとも重要な鉱脈だからです。これを根こそぎ利用するためには、ユーザの頭の中を短時間でいろいろな角度から探れる「その場方式」が適しています。その反対に、ヒアリングしたことをメモして自分の席に戻ってから描くやり方(持ち帰り方式)では、散漫なモデルが緩慢に生み出されるばかりです。大げさな「価値分析」や「要件定義」も実施しません。現場の技術者が知っているとおり、そこらへんの成果物は、システムが出来上がってしまえば、読むのが気恥ずかしい「ポエム」でしかないからです。 特徴(2)現行システムを「発想の出発点」にしない 現行のパネルや帳票があるとしても、モデリングセッションでは意図的に無視されます(*1)。なぜなら、「あるべき姿」は現行システムの仕様の中ではなく、せいぜい業務担当者や管理者の頭の中に漠然とあるだけだからです。現行仕様を出発点とすれば、建材だけが最新のものに置き換わった竪穴式住居のようなシステムが出来上がるかもしれません。これを発注者が望むのでない限り、設計者は日々仕事を遂行している業務担当者や管理者との対話を通して、「システムの本来あるべき姿」を探ってゆかねばなりません。 特徴(3)同業者を含めた多様な関係者によって妥当性が検証される 一般に企業システムの設計情報は複雑かつ膨大です。それゆえに、これまで設計者の仕事の出来不出来はなかなか問題にされることがありませんでした。しかし三要素分析法では、設計内容が第三者にもわかりやすく様式化されるため、(開発企業の)社内の技術者を集めたピアレビューを実施できるようになります。個々の案件は技術者全員の「批判と学びのネタ」となって、プロジェクトの設計品質が高まるとともに、設計ノウハウの横展開が促進されるでしょう。 *1.現行のパネルや帳票は最後まで無視されるのではなく、「レビュー」以降のタイミングで、モデリング結果とつき合わされて「漏れ」や「余分」がないかをチェックするために利用されます。 |
|||||||||||||||
より深く学ぶために ユーザーとの対話だけにもとづいてその場で設計するこの方法は、「現行システム調査の要らない安直な方法」などではありません。むしろ、幅広い業務知識の学習や現場での俊敏さが求められるという意味で、専門家としての自覚や技量が問われる厳しい方法です。それだけに経済価値の高い技能であるため、ソフト技術者がキャリア形成してゆくための核となってくれるでしょう。 業務知識や技法をより深く学ぶための書籍を挙げておくので参考にしてください。販売、会計、生産といった代表的な業務分野をモデリング例とともに解説しているものが[1][2][5]、三要素分析法の方法論全体や設計パターンを説明しているものが[3]、自習用問題集が[4]です。 [1]業務別データベース設計のためのデータモデリング入門, 渡辺幸三, 2001, 日本実業出版社 [2]生産管理・原価管理システムのためのデータモデリング, 渡辺幸三, 2002, 日本実業出版社 [3]業務システムのための上流工程入門, 渡辺幸三, 2003, 日本実業出版社 [4]業務システムモデリング練習帳, 渡辺幸三, 2006, 日経BP社 [5]販売管理システムで学ぶモデリング講座, 渡辺幸三, 2008, 翔泳社 また当社では、この手法にもとづくモデリングツール「X-TEA Modeler」や、開発ツール「X-TEA Driver」を提供しています。さらに、それらのツールで扱えるレファレンスライブラリー「CONCEPTWARE」を用意しています。ご活用ください。 |