SSブログ

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

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

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

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

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

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


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

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

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

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

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

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

REA_relationship.jpg

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

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

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

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

REA_relationship002.jpg

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を違う視点で捉えたいと思っている人は必見だ。

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


ビジネスパターンによるモデル駆動設計

ビジネスパターンによるモデル駆動設計

  • 作者: Pavel Hruby
  • 出版社/メーカー: 日経BPソフトプレス
  • 発売日: 2007/08/13
  • メディア: 単行本



ユースケース導入ガイド―成功する要求収集テクニック

ユースケース導入ガイド―成功する要求収集テクニック

  • 作者: ダリル クラク
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2002/09
  • メディア: 単行本



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

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

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



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

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

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



nice!(0)  コメント(0)  トラックバック(0) 
共通テーマ:パソコン・インターネット

nice! 0

コメント 0

コメントを書く

お名前:
URL:
コメント:
画像認証:
下の画像に表示されている文字を入力してください。

トラックバック 0

この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。