意外と早く第二弾。
さて、今回は「SOA＝オブジェクト指向分析（設計開発）」というテーゼ、あるいは（一部における）オブジェクト指向マンセーな風潮に反論というか、それほど「論」ではないので感情的に反対してみたい。
そもそも大半の「業務システム」にオブジェクト指向設計・開発は必要ない。ここで業務システムとは会計とか販売管理とか生産管理とかの実行系システムを指す。業務系のサブカテゴリーとして他に「分析系」あるいは「情報系」と呼ばれるようなものがあり、本当はそれらをまとめて「業務系」と呼ぶけど以下では主に「業務実行系」を念頭に話を進める。
なお「業務系」と同じレベルの別の分類として「組込系」がある。また、業務系システムのインフラを提供するミドルウェアなどそれ自体に対して、また別の分類を用意するべきだろうと思う。これを「（業務）基盤系」と呼ぶことにする。
これらの分類はこの場での思い付きであり世間一般でこういう定義が採用されているかはキニシナイ方向で。
さて、何故＜大半の「業務システム」にオブジェクト指向設計・開発は必要ない＞のか？ それは業務システムが単純な帳簿処理に還元出来るからである。つまり、業務システムは全て次のような流れのバリエーションである。まず、個々の業務処理のタイミングで帳票が発行あるいは更新される。さらに、適当なタイミング（日次とか月次）で個別の帳票がサマリーされ元帳に転記される。これら帳票、元帳はトランザクションデータであり、トランザクションデータで使われる各種の分類はマスターデータとして定義される。
業務システム自体はこのように単純なもので、どんなに複雑な業務プロセスであろうと、システム化するためには適宜分析し単純な原子的な要素にまで落とし込まなければならない。またこの原子的な業務プロセス要素同士の組み合わせも、それ自体としては単純なもののはずである、適切に分析設計されている限り。
このような業務システムの分析設計のために、オブジェクト指向が出て来る必要は無い。さきほど描出した業務システムが実現するべき原子的なプロセスは、データとそれに対する操作からなっており、そこではデータと操作は分離されているし分離されるべきである。このような要素を的確に処理するためには、30年前の構造化分析設計手法で十分であり、そちらの方がより相応しい。構造化分析設計手法はデータとそれに対する操作とを括り出しDFDにまとめるもの、とここでは単純に定義する。それに対してオブジェクト指向分析設計手法の特徴はデータと振る舞いつまりデータに対する操作とがオブジェクトとしてカプセル化されている点であるが、そのような分析設計手法を上記のような特性の業務システムあるいはそれが対象とする問題領域に適用するメリットは全く無い。
あるいは、データに対する操作もとりあえずは無視して（というのはいずれにせよデータに対する操作はCRUD、Create・Refer・Update・Deleteのいずれかしかないのだから）、データのみに着目しシステムの分析設計を進める手法を取ってもいいかもしれない。これがいわゆるDOA、データ中心アプローチになる。
それではオブジェクト指向分析設計はどこに適用されるべきか。それは前述の基盤系システムであろうと考えられる。なお基盤系システムにはStrutsなどのWebアプリケーションフレームワークなども含んでいる。
業務系システムを何も考えずにそのまま実装してもいいのだが、そうすると同じようなコードの重複などの無駄が生じる。これを処理するためのものがオブジェクト指向による分析設計だとぼくは思っている。つまり、オブジェクト指向は業務とは関係無い、システムの世界に閉じたものである。効率的に柔軟かつ堅牢なシステムを作るための仕組みがオブジェクト指向分析設計で、したがって業務に対するその利益・貢献は間接的なものに留まる。
業務の分析設計は構造化手法あるいはDOAを用いて行い、その後システムの分析設計実装をオブジェクト指向で行えばよい。ただ、個別の業務システムで行うべき「システムの分析設計」の作業はそれほど多くないはずだ。というのは、（オブジェクト指向の利点を生かした）ミドルウェアやアプリケーションフレームワークによって、個別の業務システムで行うべき開発作業は、業務の設計の結果を単純にそれらの上でパラメーターの出し入れする程度の作業をするだけになっている（はずだ）から。
ついでにオブジェクト指向を習得しないとIT業界で生き残れないかのように煽られていたりするけど、基盤系に行くコアでディープな人材以外の、業務系に関わる大多数の人間は手続き型の実装がちゃんと出来ればそれでいいはず。「コアでディープな人材」というのは基盤系の実装に関わるようなひとたちと、それらを適切に組み合わせて個別業務システムの（あるいは幾つかの業務システムに共通する）アーキテクチャーを作るようなひとたちだ。後者は「ITアーキテクト」と呼ばれている職種と一部重なる（その職種がカバーする範囲が論者によって異なるし、そもそもいずれの場合でも範囲が広大なので当然重なるわけだが）。
更に脱線すると、オブジェクト指向分析設計が業務の人間にとって分かり難いのは当たり前で、そもそも業務の人間はそんなもの分かる必要は無いのだ。UMLを使って業務の人間とお喋りしたいですぅ、と言っているひとたちが居るが、UMLに定義されたダイアグラムのうち殆どは業務の人間にとって付加価値を生まない。概念データモデルをクラス図を使って描くくらいだが、その程度は別にPowerPointでやってもいい程度の話だろう。あとは業務プロセスを記述する際にアクティビティ図が使えるが、これも別に他の記法で全然構わないし、素のアクティビティ図は使い物にならない（スイムレーンが無かったり。あるんだっけ？）。
実はこういう立論は全く独創的なものではない。上にDOAの話が出ているが、その提唱者の椿さんが既にオブジェクト指向が興隆してきたとき（1997年）に書いていること（これとかこれ）の方がこんなたわごとよりちゃんとまとまっているし、オブジェクト指向ブームが一段落した2003年には雑誌で「オブジェクト指向の補完でDOAに再び脚光！」という特集が組まれていたりしたようだ（この特集にも寄稿しているDUOシステムズのこのコラムも参照）。ぼくもこの頃（2004年前半かな）上で書いてきたようなことを考えたのだが。
最後に、なんでこんなことを書いているかというと、きっかけはこの記事。
開発標準導入の阻害要因 － ＠IT情報マネジメント
以下カッコ（「」）内はこの記事からの引用。
さて、タイトル通り、開発標準の話なんだけど、ウォーターフォール＝構造化手法＝官僚主義でプロジェクト回らない＝悪、と考えている節が見えて、カチンと来た。たしかに
[メインフレームやオフコン向けのウォーターフォール型の開発標準が]悪いというつもりは、毛頭ありません。また、「ウォータフォール型だからメインフレームやオフコン向け」という理論的な関係はありません
と書いてはいるんだけど、わざわざそんなことを言挙げしているのが嫌らしいというかなんというか。過敏な反応なのかもしれないけど。
とりあえず言いたいのは、構造化手法に基づく開発標準があったとして、それを全て捨て去って完全にオブジェクト指向手法の開発標準に取り替える必要は全く無い、ということ。開発標準と言っても色々だけど、業務のブループリントから始まるシステム開発の全工程をカバーするものだとすると、オブジェクト指向言語の採用などによって更新しなければならないのは開発標準全体の5%も無い。ついでにイテラティブ・インクリメンタルな開発プロセスに変えたとしても、開発標準自体、正確にはそこで規定された文書類自体には殆どインパクトは無いはず。どんな開発プロセスを適用したとしても最低限標準として作らなければならないものは作らなければならない。
この記事の意図自体についてもう一点コメントすると、「開発標準導入の最大の障害」はROIが測れない、つまり、初期投資を正当化する効果を設定するのがそもそも難しいし、無理矢理設定すると有効でないどころか有害なものになり得るというのはこういう二昔前のPMO的な開発作業標準化も一昔前のEAにおける標準化も全て同じで、そうだよねー、と最近開発標準にも関わっているEA担当のぼくとしてはうなずける話。
ただ、それに対して「ビジネスに関するあらゆる業務には、その競争力を高めるための改革・改善が必要」であり、システム開発も「ビジネスに関する業務」に当たるとされているようだが、それは違うのではないか。大方の業務側の人間の認識では、システム開発をコストと見なされしたがってそれを行うシステム関連部署はコストセンターと捉えている。「ビジネスに関する業務」は、あまりに粗すぎる表現であり、これは正確にはビジネスを実際に行う業務とビジネスをサポートする業務とに分けられるべきだ。システム開発を始めとするシステム関連部署の業務は後者に当たる。ビジネスをサポートする業務は「ビジネス上重要な業務、ライバルと激しい競争を繰り広げるような業務、あるいはそれらに深く関連する業務」のいずれにも当たらない。これらはビジネスを実際に行う業務になり、したがって、システム開発は重要で競争が激しいから改革・改善が必要である、とは言えない。改革・改善は必要だけど、それは重要で激しい競争に晒されているビジネスを実際に行う業務を邪魔しないように、納期通り一定の品質のシステムを決められた予算内でビジネスに提供するためだ。微妙な違いだけど、この立場の違いは重要だと思う。一部のOO厨はどうもそれが分かっていないようで、変な全能感を持っているようでキモス。あるいはソフトハウスのひとは自分たちがシステム業界で激しい競争に晒されていて、システム開発がビジネスだからこういう書き方になるのかな。
最近のコメント