» 【第110号】方法論の違い

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第110号】方法論の違い

ロッテが勝ったり、すっきりした秋晴れの少なかった10月が終わりました。
弊社はこの10月3日で、創立20周年を迎えることができました。1990年
以降、情報システム衰退の10年といった傾向の中、皆様のご支援をいた
だき、おかげさまでなんとか生き延びることができました。
10月24日、DOA+コンソーシアム第3分科会では、弊社堀越が、THモ
デルについて、「処理が読める」などの特徴を交えて、紹介いたしました。


■出発点から決まる方法論の骨格
コンピュータが登場して、ざっと40年が経過します。この間システムはいろ
いろな方法論に基づいて作られてきました。優れた先人の経験で作られた
アセンブラーやPL/Iの、まだ現役で勤めているシステムもありますし、
ERPシステム、OOで開発されたJavaの最新のシステムもあります。それ
ぞれ独自の目的と方法論によって作られてきたわけですが、企業活動を支
えるシステムである限り、孤立していて良いものはないはずです。ハード・
ソフト環境、ツール、課題、方法論、担当者、文化の違いを超えて、システ
ムは相互にコミュニケーションする必要があります。

このようなシステム横断−最近はApplication to Applicationと言う意味で
A2Aと言っていますが−のコミュニケーションを確保するための条件を考
えるに際して、方法論の違いとは何か、どう違うのか、なぜ違うのか、など
を考えました。実証することの難しい問題ですが、方法論を考えた人が、
初めに取り組んだ環境・課題の影響が大きい、骨格はほぼそれで決まる、
と言うように感じました。
初めに取り組んだ仕事が、SIerにいて、業務要件がほぼ決まっていて、課
題の主体が開発であった、と言う場合と、ユーザ企業にいて、業務要件を
決め発注をする、と言う立場ではシステムスコープや実装独立についての
感覚がちがいます。私は30年前に「プラントメーカーの機能設計から現場
工事管理までを一貫してつなぐには」を課題として取り組んだために、当初
からA2A、したがって一元化リソースDBのDOAを追求してきたものと思わ
れます。
■分かりにくい種々の方法論
1990年代以降、ダウンサイジング、ERP、アウトソーシングなどの波によっ
て、方法論はかなり衰退していったようですが、ここへ来てJavaにはOO、
上流にはDOAと復活の兆しが見られます。オブジェクトの識別に客観的基
準がないため、「OO技法は人の数だけある」などとも言われますが、DOA
にも、IE、IDEF、渡辺式、TM(旧T字形)、THなど種々ありその特徴を把握
するのに苦労します。
ひとつは用語の違いです。それぞれによって「概念」、「論理」、「物理」に微
妙な違いがあります。われわれは実装独立の意味で「概念/Conceptual」
を使いますので、物理ファイルに実装されない、中間加工データやチェック
データ(注)も定義し扱いますが、これを扱わない方法論が大部分であるこ
とが分かりました。また、OOでは「概念」と「概要」とほぼ同じ意味で使って
いる場合があるようです。そして、われわれは「分析」はAsIsに対してしかな
い、と考えますが、OOでは「分析」をToBeに対しても使うようです。こうして、
「何か話が食い違うな」と思っていると、用語の意味が違っていることを発見
したりします。
(注)A>Bをチェックする場合、C=A−Bを定義して、C>0かどうかで判定
することができます。このときAとBから加工されるCをチェックデータと呼び
ます。在庫水準をチェックするために、X=在庫数/安全在庫数―1のような
チェックデータを定義すれば、正か−1より大きいかなどによって、在庫水準
を判定することができます。通常暗黙的な処理の仕様として扱われるものが、
形式的なデータの仕様として規定できます。
もうひとつは、前提が隠れているためです。当該対象システムだけを考える
か、これを取り巻く全体システムに位置づけてA2A/B2B(Business to
Business)まで考えるかが、暗黙的になっている場合が多々あり、誤解の原
因となります。通常、前者の場合は当該システムの1階層アーキテクチャで
すが、後者の場合は当該システムとシステム横断の2階層アーキテクチャ
で考えることになります。カットオーバーまでが勝負と考えるSIer、およびこ
れを想定した方法論は、前者を取るでしょう。システムの運用・維持管理を考
えなければならないユーザ企業は、後者をとらなければならないはずですが、
「EAIやSOAによって後付で解決すればよい」と1階層で考えているユーザ
企業が、まだ大部分のようにも思われます。またリポジトリをどう位置づける
かもはっきりしないテーマです。開発段階のツールなのか、以後のメンテに
どう活用するのか。モデル図との整合性、システム横断の整合性など、明示
していない方法論が大部分のようです。
■方法論の切り口
そこでこれらの方法論を理解するに当たってのチェックポイントとして、次の
5項目を考えてみました。
(1)概念/実装
(2)AsIs/ToBe
(3)概要/詳細
(4)1階層アーキテクチャ/2階層アーキテクチャ
(5)開発ツールのリポジトリ/開発保守ツールのリポジトリ
(1)は概念と実装をどのように扱っているかです。かつてはシステム規模も
小さく、「当面課題としているシステムを、与えられた環境において、拙速で
もよいから動かしたい」と言うニーズから、いきなり実装設計に入るケースが
多かったと記憶します。しかし昨今ではシステム規模が大きくなり、寿命も
長くなることから、やはり「初めは概念設計」を標榜するものが多くなってき
たように思われます。OOのクラス図も当初は実装従属のデータを記述して
いたようですが、今は「初めは実装独立のデータを書く」という考え方が出て
きているようです。しかし「どう転んでも環境はRDBとJAVA」ということから、
「チェックデータなど、RDBにストアされないデータは識別しない」など、妥協
した方法論も多く見られます。
(2)はAsIsの分析をどこまでやるかの問題です。現行システムに携わって
きた仲間が中心になって、再構築を行うような場合、「AsIsは分かっている
から」といきなりToBeに入りたがることはよくあります。しかしその分かって
いるはずのAsIsを「図表として表現してください」と言って、全員正しく記述
できることはめったにありません。ドキュメント作成に慣れないこともありま
すが、思ったより現状や問題点の理解に差があるからです。神様のように
優れた人がいて、あとはついていくだけと言うプロジェクトならば別ですが、
凡人が智恵を出し合って進めていくプロジェクトでは、AsIsを可視化しなが
ら、理解を深め、広げ、共有をはかっていくのが有効です。データの仕様は
AsIsとToBeは90%以上一致しますので、無駄な作業が発生することはあ
りません。
(3)は最終的には詳細を規定するとしても、概念やAsIsの工程でどこまで詰
めておくかと言う問題です。DOAではまずデータが問題になるわけですが、
一般的には「実装工程に入り、プログラム設計の過程でデータ仕様が確定
してくる」と言ったケースがあるやに聞きます。われわれは「AsIsには、ToBe
で不要なデータも含まれているので、骨格となるデータに絞りますが、ToBe
では概念レベルにおいて、すべてのデータを識別し、その中で整合性問題
−加工加工元データ整合性を含む−をすべて解決すべき」と考えています。
(4)は所与のアプリケーションを、孤島としてとらえるのか、全社システムの
ひとつとして捉えるのかの問題です。システム化の初期の段階は、他シス
テムの状況も不明で、全体を考えることが難しかったわけですが、全体最適、
スピード対応の求められる昨今、全社スコープで考えるべき企業が多くなっ
てきていると思われます。しかしこれはユーザ企業のトップでなければ手の
下せない問題であるため、トップの目覚めに今しばらくの時間がかかるかと
思われます。
(5) は今後とりくむべき、技術的かつマネジメント的難問です。情報システム
のあるべき姿が、図と表により分かりやすく表現され、ユーザと開発担当が
合意したとして、これは機械が解釈できるように、リポジトリ/システム開発
DBに表現されるべき、と筆者は考えます。今はこれをプログラマが解釈して
機械に教えていますが、プログラマを介することなく業務モデルを機械が解
釈できるように、リポジトリは設計できるはず、すなわちこのような開発ドキュ
メントを位置づけた開発方法論を指向しなければならない、と考えているわけ
です。この場合システムの機能はリポジトリのコンテンツで決まりますので、
機能に関するシステムテストを不要にするなど、技術的課題がまだ残されて
います。これができれば、システムテストは性能のテストだけになり、保守地
獄は大きく解消されるはずと期待されます。
■方法論を超えて
方法論はいずれも、課題解決のために生まれたものです。したがってこの
設定された課題に適合する問題はうまく解決できますが、そうでない問題に
はあまり有効でないと言う場合があります。多くの問題を解決してきた方法
論は、それだけこなれており多くの場面で有効です。また、方法論は、使う
人がこれに使い慣れているかということも重要です。仮に日本語より英語の
方が優れているとしても、英語に切り替えたら却って効率が落ちると言うこと
は誰にでも理解できます。したがって、すでに優れた方法論を身に着けて問
題解決に支障を感じていないのであれば、これを変えるメリットはあまりなく、
むしろいろいろな方法論で作られたシステム間のA2Aのデータのやり取り
を如何にシームレスにするかに注力すべきものと思われます。先の5つの
切り口は、これを誤解なく効果的に進めるために、お役に立てればと考える
次第です。