そもそも論：ソフトウェア工学には頭脳が足りない：SSブログ

	ブログをはじめるログイン

責務駆動設計はオブジェクト指向か？　[そもそも論]

まず最初にお詫びしなければならない。
前のブログでは次回予告として「イベントシステムを扱う」と告げたのだが、それより先に責務駆動設計の文章が降りて来てしまったので、予定を変更してそちらを先にお届けする。

じつは先週の3/5に「ドメイン駆動設計」の勉強会に行ったのだが、そこで責務駆動設計の６つのロールの話が出て来たので、それをキッカケに色々と連想が広がってしまったのだ。この手の文章は書ける時に書いておかないと筆がさらに遅くなるから、イメージが湧き上がっている時に書くのが一番だ。というわけで「イベントシステム」の話を期待してた方はご容赦願いたい。

擬人化設計技法への誘い
というわけで今回は私の好きな「責務駆動設計」の話だ。
ただし、ここで責務駆動設計が何かという説明をするつもりはない。世間にはたくさんの責務駆動設計の解説があるので、ググってほしい。今回の話題は次の一点に尽きる。

「責務駆動設計はオブジェクト指向か？」

答え：責務駆動設計を世に広めた立役者「レベッカ・ワーフスブラックとアラン・マクキーン」がその著書「オブジェクトデザイン」でオブジェクト指向と言っているのだからオブジェクト指向である。以上、終了。

オブジェクトデザイン (Object Oriented SELECTION)

作者: レベッカ・ワーフスブラック
出版社/メーカー: 翔泳社
発売日: 2007/09/13
メディア: 大型本

.......ま、それで済むなら記事になんかしないわけで、ちょっと引っ掛かっているからこそ、こうして話題にしているのだが、まずは本人たちの意見を尊重しておこう。

ただし、である。
お気付きの方もいるだろうが、このブログでは責務駆動設計のことを、世間のように「オブジェクト指向の主流」あるいは「一種」として扱ったことは一度もない。読み返してもらえば分かるだろうが、すべて「擬人化（指向）設計技法」の一種として扱っている。

とはいえ「オブジェクト指向ではない」と見なしているのかと言うと、そういうワケでもない。

オブジェクト指向という恐竜
皆さんは「獣弓類」と「竜弓類」というのをご存じだろうか？どちらも原始的な爬虫類だが、「竜弓類」は典型的な巨大恐竜に進化し、「獣弓類」は哺乳類へと進化した。「責務駆動設計」はこの「獣弓類」に似ている。

「オブジェクトデザイン」の原著は2002年発行だが、ワーフスブラックらの活動はOOPSLA'89 の論文『Object-Oriented Design: A Resposibility-Driven Approach』まで遡る。これはJavaの1995年より古い。当時もC++などのいくつかのオブジェクト指向言語は存在したが、オブジェクト指向が普及していたとは言えない状況だった。逆に言えばオブジェクト指向の方法論を確立しようと多くの流派がしのぎを削っていた時期だ。

「獣弓類」は恐竜とは違う系譜なのに、姿が似ている「竜弓類」と同じ「原始恐竜」の仲間に入れられた。それと同じように、「責務駆動設計」は「オブジェクト指向」という「恐竜」の仲間に入れられている。いやレベッカ・ワーフスブラック自らが「恐竜」だと宣言してしまっている。これはある意味仕方がないことだ。「じつは別系譜ですよ」なんて後からだから言えることで、始祖の獣弓類だって自分を周りの竜弓類と同類だと思っていただろう。

ただし、私は違いが気になるので、獣弓類は獣弓類と呼ぶし、責務駆動設計は「擬人化設計技法」の一種だと位置付けている。

　→ 獣弓類は学問的には恐竜ではない
　→ 擬人化設計技法も厳密にはオブジェクト指向ではない（と言われるようになるだろう）

擬人化設計技法の仲間たち
「擬人化設計技法」の見分け方はわりと単純だ。
まず、設計技法であって実装技術には成っていない。それは本来のオブジェクト指向との大きな違いである。例えば、今もネットワーク系や社会シミュレーション系でしぶとく生き残っている「エージェント指向」や私が勝手に提唱している「新エージェント指向」は実装技術を含むので、同じく擬人化を基点としていても、ここで除外される。まぁ、それらの設計技法だけは広義の擬人化設計技法と言えなくもない。（特にうちのはまだ大した実装ではないから設計技法みたいなものだ。苦笑）

それから技法の解説のかなり初期に、そのものズバリ「擬人化」という言葉が出てくる。仮に擬人化という言葉を使ってなくても、それに類することをやっていれば「擬人化設計技法」と言える。
例えば、ここで扱っている「PDC＆BSP」をソフトウェア設計にも活かそうという技法（名前はまだない）だと「人のメタファ」という言い方をしている。

また、「ロール（役割）」という言葉が出て来たら「擬人化設計技法」にほぼ確定だ。先の「オブジェクトデザイン」でもロールを説明するために「擬人化」という言葉が登場している。

ロールとは責務の集合であるが、同時にそれは責務を負う存在でもある。ロールには様々なタイプがあるが、人とイメージが重なるものが多い。先の「オブジェクトデザイン」を例にとると「記録保持役、構造役、サービス提供役、制御（頭脳）役、調整役、インタフェース（窓口）役」という６つを基本ロールとして挙げており、他のロールもこれらの基本ロールのいずれかに分類できるとしている。このうち「構造役」だけは人が演じる役として連想できないが、他は何らかな形で人のイメージと重なることができる。（それでも、人と重ねようとしないコンピュータオタクもたくさんいるだろうが（苦笑）それはとりあえず置いておこう。）

６つの基本ロール
　・記録保持役
　・構造役
　・サービス提供役
　・制御（頭脳）役
　・調整役
　・インタフェース（窓口）役

ジル・ニコラ等の「ストリームラインオブジェクトモデリング」にも「擬人化」や「ロール」という言葉が出てくる。例えば2.1.1 オブジェクト思考には「原則７　オブジェクトを擬人化せよ」という項がある。その後も原則13までは擬人化やロールについての原則だ。原則は全部で98個あるので率的には多くないが、その後も人やロールと言うキーワードは随所に出てくる。それに原則1~6が「原則中の原則」だから、それに次ぐ重要度を与えられていると言って良いだろう。だから私は「ストリームラインオブジェクトモデリング」も擬人化設計技法の一種と見なしている。少なくとも擬人化設計技法が大きなウェイトを占めているのは確かだろう。

ストリームラインオブジェクトモデリング―パターンとビジネスルールによるUML

作者: ジルニコラ
出版社/メーカー: ピアソンエデュケーション
発売日: 2002/12
メディア: 単行本

原則１　「なぜ」の「どのように」は、「なに」である
原則２　オブジェクトモデリングの視点
原則３　新ビジネスのオブジェクトモデリング
原則４　プロセスエンジニアリングのためのオブジェクトモデリング
原則５　ユースケースの前にオブジェクトモデリング
原則６　オブジェクトモデリングによって複雑さを管理する

原則７　オブジェクトを擬人化せよ
原則８　オブジェクトに責任を与えよ
原則９　オブジェクトの責任
原則10　オブジェクトであるかのように会話せよ
原則11　人の原則
原則12　コンテキストの原則
原則13　ロールの原則
・
・
・

これらの設計技法が生まれた背景は、おそらく、業務ソフトが扱う問題の多くが実社会と密接に関わっており、その実社会の中の「人」を無視できなかったからだ。

最近話題の「エリック・エヴァンスのドメイン駆動設計*」にしてもそうだが、彼らの関心の中心は実装技術ではなくドメイン（問題領域）にある。そして、そのドメインは実社会を写し取ったもので、大抵は人が含まれる。

（*モデル駆動設計が中心の本だが、責務駆動設計が終盤の美味しいところで登場する。また、オブジェクト指向と責務駆動設計を同一視しているフシがある。）

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

作者: エリック・エヴァンス
出版社/メーカー: 翔泳社
発売日: 2011/04/09
メディア: 大型本

つまり、これらを考えた人にとって「オブジェクト指向かどうか？」は正直どうでも良くて「一番、親和性が高かったから」ぐらいの感覚で「オブジェクト指向」を選択したのだろう。

おそらく、オブジェクト指向より社会性に優れた実装技術が出て来ていたら喜んでそちらに乗り換えただろうが、残念ながら、「エージェント指向」や「関数型言語」は乗り換え先に選ばれなかった。

ソウコウ、しているうちに今日では「責務駆動設計こそがオブジェクト指向の中心」という人たちまで出て来たので、さすがにこれから良い実装技術が出て来ても、乗り換えるのは難しいかもしれない。（そうでもないかな？）

ちなみに今日、責務駆動設計が重視される様になってきたのは、ドメインに再び注目が集まっているからでもあるが、同時に、要求が高度化されて従来のオブジェクト指向では対応できないことが増えて来たからでもある。

進化への圧力
iPhoneのSiriのように「強い人工知能」が次第に登場して来ている今日では、顧客の要望もそれに合わせて次第に難しくなって来ている。皆さんにも顧客から「手に余る」高度な処理を要求されて困った経験を持つ人がいるだろう。

こうした時、「伝票」とか「オブジェクト」とかだけで考えていると高度な処理が浮かばなくて困るのだが、人間とは不思議なもので、擬人化して考えると結構色んなアイデアが浮かんでくる。それはおそらく高度に振舞う人間のことを私たちが良く知っているからだろう。

それにしても「擬人化」というのはオブジェクト指向信者にとって何とも都合の良い言葉だ。擬人化思考中に考えているのは、「人」のことであって「オブジェクト」のことではないはずだが、「擬人化」という言葉を使うことで、全てがオブジェクトの範疇内であるかの様にすり替えることができる。

しかし、これはあくまでレトリックだ。
例えが適切か分からないが、エージェント指向とオブジェクト指向の違いは「頭脳」の扱いにある。つまり「知能」と「コントローラ」は類似性はあってもレベルが全く違う。そこまで極端でなくても、同種の違いが擬人化設計技法と本来のオブジェクト指向の間にもある。エージェント指向の問題点は一般のプログラマーが必要とする様な設計論や技術を提供できなかったことだが、今日では普通のアプリ開発者にも高度な処理が求められるようになって来ていて、ちょうどそこにハマったのが責務駆動設計などの擬人化設計技法だ。ではこの先、もっと高度な処理が普通の開発者に求められるようになるとしたらどうなるのか？

さながら恐竜の絶滅期のように、リーマンショック以降の案件激減はソフトウェア業界に少なからぬ爪痕を残した。スマートフォンやソーシャルメディアに活路を見出したところも多いだろうが、それは暖かい地域に逃げ出したことを意味する。それはそれで正しい経営判断だが、厳しい冬を凌いでいる人たちはどうするのだろう？高度な要求に応えるために、獣弓類から哺乳類に進化するのだろうか？仮に進化するとして、その哺乳類が暖かい地域にも進出したらどうなるのだろうか？

擬人化設計技法という「獣弓類」が「哺乳類」に進化するには、実装技術の存在が必要不可欠だ。恐竜（オブジェクト指向）に成れ（慣れ）なかった小さい生き物が、恐竜たちの中で生き抜くために責務駆動設計を「隠れ蓑」として利用するのも悪くないが、せめてDSL（ドメイン制限言語）で良いから「哺乳類」に登場してほしいものだ。今日、哺乳類に相当する様なDSLってどれぐらい誕生しているのだろう？いくつか、あっても良い気がするが。

もちろん、私は哺乳類が誕生することを願っている。というか、自分でも作ろうとしている。それは弊社の「新エージェント指向宣言」を見ても明らかだ。ただこれは私個人の力で何とかなる範囲を大きく超えている。あまりに先走ったことをし過ぎて、逆に私の方が絶滅しそうだ。というわけで現在「お仕事募集中」である。恐竜的案件でも構わないから、試しに使ってやろうと言う方は是非ご連絡をいただきたい。もちろん、いっしょに哺乳類を生み出そうと言う話は大歓迎である。

例え話が過ぎて話が逸れた。

責務の定義からの考察
責務駆動設計についてだが、私や世間の分類がどうであれ、やはり名前の通り、本質は「責務」にある。ロールは無視されることもあるが、責務を無視した責務駆動設計などあり得ない。
その「責務とは何か？」については、第２回で触れた。もう一度ワーフスブラックらの定義を見てみよう。

・オブジェクトが行う行動
・オブジェクトが持つ知識
・オブジェクトが他に影響を与える主要な判断

これを踏まえた上で最初の問いに答えよう。
「責務駆動設計はオブジェクト指向か？」...全ての項に「オブジェクト」と言う言葉が並んでいるから、オブジェクト指向と見なせる。が、同時に旧来の「オブジェクト指向的発想」では抜け落ちてしまう「判断」が含まれる。これは擬人化の証だ。そして注意深く書かれた一文が示すように「判断」は「協調」において効力を発揮する。つまりこの責務の定義はコラボレーションにおける「判断役」を暗示している。これは擬人化設計技法にとって大切な「進化の萌芽」だ。基本６ロールを上手く使えば、この芽を育むことができる。もちろん「PDC＆BSP」もそれを助ける。

（私はつい妄想してしまうのだが、擬人化設計技法に実装技術が伴うまでに進化した時、はたして責務の定義に「オブジェクト」と言う言葉は残っているだろうか？....まあ、その答えを出すのはやめておこう。大事なのは言葉じゃなくて進化そのものだ。）

今回はここで終わるが、責務駆動設計は簡単には語り尽くせないテーマなのでこれからも取り上げるつもりだ。次に扱う時にはGRASPパターンと擬人化設計技法を対比しよう。GRASPはオブジェクト指向の文脈で責務駆動設計を行うには外せない重要な概念だが、擬人化とは根本的に相容れない部分もある。そこを深堀して行こう。

さて、次回こそイベントシステムを分解する。執筆速度が遅いくせに、書きたい記事が目白押しで、キツい日々が続くが、あと最低10回分ぐらいは続けたいので頑張って行こう。

タグ：責務駆動設計オブジェクト指向エージェント指向ドメイン駆動設計

2012-03-10 13:24 nice!(0) コメント(2) トラックバック(0)
共通テーマ：学問

このシリーズを始めた動機と意義　 [そもそも論]

今回はもう少し先で述べる予定だった事を、先取りする形で扱おうと思う。
そうする理由はゴールを明確にするためだ。

このシリーズは既存のソフトウェア工学にケンカを売る事が目的ではない。
5年後、10年後の未来のために今すべき事を明らかにすることが目的だ。

とは言えケンカを売りたい気持ちもゼロじゃない。
だから、頭と気持ちの整理をしたいと思う。

細かい話に付き合う気が無ければ、最後に「まとめ」を書いてあるので、そこだけ読んでもらえば良い。

おそらく読みづらいところもあるだろうし、この回を読まなくても話が分からなくなると言う事もないから、人が怒っているのを見るのが嫌いな人はパスしたほうが無難だ。
でも、もし、そういう事を気にしないなら、しばしお付き合い願いたい。

キッカケ
薄々感じている人もいるだろうが、このシリーズは私の個人的な「憤り」から始まっている。
何しろ、元はユースケース図等に憤慨して、一気に書いたブログがキッカケだ。
だからこのシリーズを私の個人的な不満をブチマケタだけの矮小なものだと判断している人もいるだろう。
まあ、万人に届く言葉など無いのだから、これはこれで仕方が無い事だ。

ただし、これだけははっきり言える。
私は怠け者で情報発信が正直言って苦手だ。
だから、単なる私憤であれば、せいぜいtwitterで愚痴って終りだ。
マトモなブログなど書くはずが無い。

つまり、このシリーズは少なくとも私が義憤だと思っているからこそ始まっている。
（CGソフトShadeのコミュニティに出没していた頃から私をご存知の方ならお分かりだろう。苦笑）
今回はそうした事を俯瞰的に眺めてみよう。

REAモデルにツマズいた
まずは憤りの原因から。
直接的なトリガは、ユースケース図の定義を確認して改めて不満を憶えた事だが、（これは前回書いた）
噴火するほど不満を大きくした原因は、REAモデルが想像と違っていた事だろう。

そもそも、それ以前に（責務駆動設計以外の）オブジェクト指向やデザインパターン、UMLと、それらを有り難がっているソフトウェア工学の関係者にも違和感を覚えていたが、そのストレスを限界スレスレまで高めてしまったのがREAモデルである。

REAモデルはまだテーマとして取り上げていないが、私が知る限り、ソフトウェア工学界、最大の「判断と実行の混同」が見られる。
日本では関連書籍も「ビジネスパターンによるモデル駆動設計」１冊しか無く、情報が不足してるREAモデルだが、Eコマースの国際標準規格を決める際にベースになったほど有力な概念だ。
しかも弊社の「ReTeMoモデル」や、武道の「心技体」によく似たモデルだから、きっとこれらはつなげられると思っていたのだが、実際には「心技」が混同していた。それも徹底的に。

こうした場合、欧米の徹底ぶりは実に見事だ。
REA、即ち「Resource, Event, Agent」は基礎概念なので、書籍に載っている２５パターンのどれを見てもREAの定義に則っていて、当然のことながら「判断と実行の混同」が見られる。

混同が起きているのはEventだ。
イベントには「キッカケ」と言う意味と「出来事」と言う意味がある。
GUI等で使われるイベントシステムは前者の意味だが、REAでは一貫して「出来事」のことを意味している。出来事には「キッカケ」も「起った事」も含まれるから、その中には当然「判断と実行」も含まれる。

もちろん言葉の使い方としては間違ってないし、REAモデルの方が大抵のイベントシステムより古いのだから、普通ならこれぐらいの混同は看過されるべきだ。それは分かっているのだが、「判断と実行の混同」がREAモデルの抱える「分かり難さ」等の原因になっているのは事実だし、何より私はREAモデルがPDC（Rlan, Do, Check）プロセスと統合できる事を期待していた。

そう、そもそも私の期待値が大き過ぎたのだ。

PDCプロセスが「ビジネスの基本」と言われているのは多くの人がご存じだろう。前回のユースケースの回で述べた様に、これらは行為であって、PDCには仕掛けや結果が必ずセットになっている。武道の「心技体」はその仕掛けを表している。もし心技体とREAが同義なら、PDCとREAをセットにすればビジネスの動的な面と静的な面の両面がカバーできることになる。イベントが「心（頭脳）」役というのが納得できない人もいるだろうが、「決定を下す要素」だと思えば少なくともメタファとしては許容できるだろう。
そのイベントが「キッカケ」なら、上の「私の想像」のほうの図にあるように、エージェントが「人」と「技」を兼ねることになるが、この混同は現実に即している、そう思っていた。エージェント＝人は何と混同しても現実社会とのシンクロを強め、問題になるどころかイメージを強固にしてくれる。でも実際には混同が起きていたのはオブジェクト指向と同じ「判断と実行」に於いてだった。これだとPDCとシンクロしない。

もっと遡ればCGアニメーションシステムに対する不満が原点にあるのだが、今回はこの話はやめておこう。

若者には最新の英知を
噴火の直接的なキッカケを作ったのは弊社で企画した上流工程セミナーだ。上流工程をテーマとして扱うならユースケースは外せない。例え不満があるとはいえ、他人に教える以上は基本に忠実であるべきだ。だからUMLでのユースケースの記法を改めて確認したのだが、結局は「こんな物を教えてどうするんだろう？」とゲンナリさせられた。

前回のユースケースに関する記事を読んだ人はお分かりだろうが、私はむしろユースケース駆動開発信者であって、問題視しているのはユースケース図だけである。まだデザイナーだった頃にダリル・クラク等による「ユースケース導入ガイド　成功する要求収集テクニック」を読んで感銘を受け、デザイナーの先輩には注意されながらも導入して以来、上流工程では使わなかった事がないから、かなり筋金入りのユースケース駆動信者の部類に入ると思う。

それからオブジェクト指向やUMLにもお世話になった。C++を学び始めた当初こそ苦労させられたが、元々はデザイナーだった私がここまでソフトウェア技術に詳しくなれたのは間違いなくオブジェクト指向やUMLのおかげである。しかし、そんな私でも擬人化設計技法について考える様になった後ではオブジェクト指向やUMLの副作用が気になる様になってしまった。副作用を極力排してオブジェクト指向やUMLの良いところだけを抜き出そうと頑張っているが、上流工程に関していえばそれはかなり難しい。

上流工程だと「顧客」や「管理職」など所謂"素人さん"を相手にする事が増えるが、オブジェクト指向のノウハウの多くは実装からのボトムアップで、そのまま伝える事が難しいし、第一、技術者自身が下流工程の考え方から脱せない。つまり上流工程的な発想に切換えられない。使用する言葉は思考に大きく影響するのでこれは看過できない。上流工程ではドメイン（問題領域）の人や会社等の組織を扱うことが増えてくるから、それらを直接扱う思考（及び言語）を身につける必要がある。

責務駆動設計などの擬人化設計技法が素晴しいのは、それが上流工程でも下流工程でも使えることだ。詳細設計を高度化しようとして擬人化設計技法に取り組めば、人間社会のシステムについて考える時でも同じ思考回路が使える。ただし、自分の思考（つまり旧来のオブジェクト指向）に合わせて擬人化設計技法の言葉を取り入れると、第二回に取り上げた様に「判断と実行の混同」という副作用が残ってしまう。

逆に上流工程向けに擬人化設計技法を憶えても、それは下流工程でも活きてくる。例えばオブジェクト指向設計には「コマンドとクエリ分離原則」とか「Tell, Don't Ask（求めるな、命じよ）」という教えがあるが、これらは「判断と実行の混同」がなければ、わざわざ原則にする必要がない。

もちろん擬人化設計技法を下流工程で使う際に副作用が無い訳ではない。ただし、それは人とコンピュータの違いに由来するのでノイマン型コンピュータを使う限り避けられない物がほとんどだろう。つまり設計技法では根本解決しようがない問題だ。ITに関わる人間は、例えビジネスパーソンであってもこの違いを認識しておかなければならない。

話を元に戻そう。
私は上流工程と下流工程で極力同じ言葉が使われる事を望んでいる。これは決して私だけの望みではない。そしてそれがある程度可能である事は「ドメイン駆動設計」や「責務駆動設計」を知ってる人ならご存じだろう。

話を図に限定すれば、確かに「ドメイン駆動設計」や「責務駆動設計」を世に広めている先生たちも図にはUMLを使っている。でも、それはUMLが標準だからであって、最も優れているからではない。事実、もっと良い記法があるならそれを使う事を推奨している。

このシリーズではPDCとBSP（Brain, Skills, Physical）をよく扱うが、それはこれらが擬人化設計技法の本質だからだ。それに加えて問題領域ではこれらの思考フレームワークが汎用的に使える。そして「PDCとBSP」と「組織に属する人間」には「判断と実行の混同」が許されない。（少なくとも建前上はそうだ。）一方、旧来のオブジェクト指向をベースにしているUMLには「判断と実行の混同」が発生するリスクが常につきまとう。であれば「PDCとBSP」の考え方をベースにした作図ルールを定めた方が理にかなっている。

BPM（とSOA）の例を見れば分かる様に、近未来では上流工程がソフトウェア開発の中心になって行くだろう。そうした時代に活躍するはずの若手に向けて旧時代の遺物を教える気にはなれない。それをやったら今度こそ日本のソフトウェア産業は世界に大きく遅れを取るだろう。

以上、まとめると

私のストレスの増大原因は「REA」と「PDC」がシンクロしなかったこと。
私は筋金入りのユースケース駆動開発信者だ。
オブジェクト指向やUMLが無ければ今日の自分はない。
それでもUMLを今更使ったり教えたりするのは問題だ。
　擬人化設計技法とドメイン駆動設計がこれからの時代の礎であるべき。
　オブジェクト指向には「判断と実行の混同」のリスクが常につきまとう。
　（「コマンドとクエリ分離原則」がそれを象徴している。）
　図だけオブジェクト指向と言った一貫性の無い事は推奨しない。
ビジネスパーソンを巻き込むべきだし、そのためには「PDCとBSP」を使いこなすべき。

つまり
擬人化設計技法やドメイン駆動設計をメインストリームに据える。
旧来のオブジェクト指向を下流工程の一部に封じ込める。
上流工程向けの作図ルールを刷新する。
「PDCとBSP」モデルを広める。

それらが実現できたら、このシリーズにも意義がある。

さて、今回はここまで。
次回はMVCモデルを扱う。
前回述べた様にMVCとBSPは大きくモデルが違うが、だからこそ補完し合う関係にある。
両者を合わせて考える事でようやくシステムの全体像が見えてくるだろう。
MVCの不完全性や複雑さに納得できない人や、MVCを違う視点で捉えたいと思っている人は必見だ。

というわけで、次回もお楽しみに。