The Dragon Scroll

Be just and fear not.

アジャイルDOA。

椿正明氏による、DOA(TH法)の講義を拝聴してきました。
法政大学のエクステンションカレッジが組んだ公開講座で、
全十二回です。
第一回目は、分析・設計方法論の骨格と題して、この長い連続講義の
サマリを説明したものでした。
以下、その講義を受けた感想を書いていきます。

サイエンスによるシステム開発

椿博士曰く、現状のASIS分析を記述する方法として、
サイエンスからのアプローチ、エンジニアリングからの
アプローチ、アートからのアプローチがあると。
いの一番の話が、これだったのですが、私は、まずここではっと
させられました。


サイエンス、つまり定理をもってして、ものごとが決まるということ。
原理原則に従うことで、属人性を排し、自ずと形が
定まるというもの。
一方、エンジニアリングには、サイエンスに加え、経験という
要素が入る。よって、ものごとは、自ずと決まるのではなく、
決めるという姿勢になる。
判断が伴う。
分析者によって、差が、生まれる。属人的となる。
この、個人差によるゆらぎを、椿博士は、標準化で小さくするという。
決めるという行為には、何事にも同意が必須である。
同意なくして、ものごとを決めることはできない。


この考えに従うと、サイエンスのアプローチを押されば
システム分析(モデリング)においても、モデルは自ずと定まることに
なる。
これって、衝撃的ではないですか?
誰がモデリングしても、自ずと形が決まる。
そうして決まった形に基づき、構築したシステムは、少なくとも
分析レベルの隙間や漏れのないものになるはずです。


では、サイエンスだけに従えば、良いではないか?
エンジニアリングは不要なのか?というとそうではなく、
DB設計のためのINPUTとして存在する画面や帳票、これらを
決める必要があると。
ここはサイエンスだけで解決できるものではない。
ユーザの同意が必要である。
これは、ユーザが決めなければならない要素となる。
つまり、システムを構築するにあたっては、サイエンスと
エンジニアリングの両面が必要であるというわけですね。
この辺の話を聞いて、私はひどく納得したのですが、
如何でしょうか。

アジャイルDOA

これを聞いて、考えたこと。
確かに、サイエンスだけでは事はすまないのかもしれない。
ただ、逆にいうと、画面・帳票が決まれば、データモデルは
決まるのですよね。
これは、画面・帳票という変数を、サイエンス的アプローチという
方程式に食わせることで、結果、データモデルが得られるという
ことなんですね。
画面・帳票は、まさにユーザがやりたいことが具現化されたモノ。
であれば、この部分に対する答えはユーザが握っているといえる。
ToBeの世界ですね。


ところが、肝心のユーザが、ここでゆらいでいる。
決めることができない。
ToBeが見える化されてなければ、当然のこと。
(ここに対するアプローチが要求開発?うーん。繋がった)


ユーザもビジネス要件は見えているものの、実際に画面として
どのように実現すればよいかまでは、決められないかもしれない。
であれば、一旦、とにかく動くものを作ってしまう。
既存画面・帳票があれば、ここからAsIsモデルを作成し、
ここに手を加えて、動くものを作ってしまう。
全くの新規であれば、最初から雛形を用意しておいては
どうだろう。
業務アプリケーションにせよ、BtoCサイトにせよ、独自性云々の
前に、最低限の形があるはずだ。
例えば、在庫管理システムの発注画面なんて、そう大差が
付くとは思えない。
ここは、SIerがこれまで蓄積してきたノウハウが如何なく
発揮されるところだ(蓄積していればの話)。
実際に、動くものを見て、ユーザは、自分たちのビジネス要件が
それで満たされるかを確認する。
そして、適合しない部分に対して、漸次的に改修をかけていく。
重要なポイントは、画面→モデル→プログラムの製造サイクルが
短くかつ、改修が柔軟に行えること。
方式や実装が、このプロセスに耐えうるものを選択する。
これは、まさにイテレーティブなアジャイル開発ではないか?


アジャイル開発は、そもそも、DOAなのかOOAなのかを気にする
考え方ではない。
如何に俊敏な開発を行うか、それが命題。
ユーザが決めなければならない要素が、決まるまで、イテレーション
まわす。
ひとたびIO要素(画面・帳票)が決まれば、データモデルも決まる。
画面(ページ)駆動開発といえる。

システム間疎結合の実現

椿博士が、提唱するシステムのあり方として、地動説アーキテクチャ
ある。システム間疎結合のことです。


ユーザは、新しいシステム開発を行う度に、孤島システムを生み出している
ことが多い。私も、孤島を生み出している一人だと思う。
何故か?
少なくとも、構築を担当するベンダが過去・現在において、
一社に限定されるのであれば、孤島の割合を低めることができるかもしれない。
(それでも、ユーザ側の部門間毎によるシステム開発、ベンダ自身の問題
によって、孤島になる可能性は高い)
しかし、実際には、1つのプロジェクトの中で複数のベンダがジョイント
することも多々ある。また、過去はAベンダであったが、いくつかの
いきさつによって、Bベンダが主管になっている、というケースも
よくある話だ。
そういう状況の場合、SIerは何を考えるか?
自分の身を守る。
リスクを排除しなければならない。
前提となる、あるいは、関連するシステムとは、独立して構築する
自分たちが担当しているシステムが、完成し、
売上が立てば良いのだ(否、立たせなければならないのだ)。
この結果、孤島が生まれる。SIerが孤島を生み出しているともいえる。


地動説的アーキテクチャに対して、天動説的アーキテクチャとは、
孤島システムがそれぞれが独自にシステム間連携をしている
アーキテクチャを指している。
例えば、在庫管理システムと、販売管理システム、コールセンターの
システム、そして、精算管理システムがあるとする。
この4者がそれぞれ、ピアツーピアで繋がるとすると、連携の数は
6通りあることになる。この数は、システムが増えるごとに、
2乗に比例して増えていくことになる。


これに対して、システム間連携のために、その中心にコントローラを
配したアーキテクチャを、地動説的アーキテクチャと、椿先生は呼ぶ。
このアプローチとして、昨今はESBを旗印に掲げたSOAを良く聞く
(実際の案件に携わったことはないが)。
ESBが、孤島システムを繋ぐ、コントローラの役目を果す。
それ自体が、繋ぐという機能を背負った、プロセスと考えると、
椿博士の言う、「ESBによるシステム間疎結合は、
POA(Process Oriented Approach)である」という話を受け入れることが
できる。
そして、椿先生は、このコントローラの役目を、DBに負わせるべきだと
いう(DBを通信の手段として使う)。
各孤島システムも勿論、それぞれDBを抱えているため、
DBは二段構えとなる。


私は、この具体的なシステムイメージが浮かばない。
コントローラDBには、一体何を格納するべきなのだろうか。
椿先生によると、ハイレベルなメッセージを保持するという。
例えば、在庫管理システムで入庫データが入り、在庫が保持され、
販売可能となったことを、販売管理システムにメッセージとして
渡すことを言うのだろうか。
メッセージを受けた販売管理システムは、在庫の引き当てを
どうやって行えば良い?
販売⇔在庫間で、直接やり取りするのであれば、結局それは
ピアツーピアとなる。
やはり、在庫データをコントローラDBに持つのだろうか。
それは、データの管理が難しくならないのだろうか。
この辺は、次回の講義で聞いてみることにしよう。