ソフトウェア工学には頭脳が足りない [ソフトウェア工学]
「ソフトウェア工学には頭脳が足りない」
ソフトウェア工学に人生を捧げている偉大な先生たちが聞いたら怒り心頭で、私を社会的に抹殺しようと方々に圧力をかけそうなフレーズだが（実際にはたぶん黙殺されるだけだろう）本当に言いたい事は「ソフトウェア工学、とりわけオブジェクト指向やUMLなどの著名な方法論の多くには“頭脳と方法の混同”が見うけられる」ということだ。たぶん、こう表現しても大抵の人は「何言いたいんだか分かんないや」とスルーして、問題提起されている事にすら気付かないだろう。だから敢えてケンカを売っている様なフレーズが必要になる。大事なことだからもう一度言おう。「ソフトウェア工学には頭脳が足りない」
頭脳が足りないかどうか調べるのは簡単だ。各方法論の一連の要素だけで「判断」が記述できるだろうか？もし判断の記述ができないなら、その方法論には頭脳が足りない。あるいはPDC（Plan, Do, Check）プロセスが回せるか見てみれば良い。もし、判断（Plan）と実行（Do）で同じ要素を使うようなら「頭脳と方法の混同」が起こっている。
例えばクラス図はどうだろう？関数内に判断を含める事はできる。でも関数は操作にも使うから、どうも混同が起きているっぽい。実際その通りで、操作とは"ある方法"を実行することだから、判断と操作の両方が関数に含まれている時点で頭脳と方法の混同が起きていることがわかる。
じゃあ、ユースケースはどうだろう？「アクターはPDC全部できるよ」とトンチで答える人もいるだろうが、それはつまり全部混同してるってことだ。まあそれは置いとくとしても、ユースケース図ではやはり頭脳に相当するのはアクターだけであり、判断を行う要素がシステムの外部にしか記述できない。つまり頭脳が足りない。
さて事例はこれぐらいにして、そろそろ「頭脳と方法の混同」とPDCプロセスに何の関係があるのかを明らかにしよう。
PDCプロセスの「Plan, Do, Check」は、それぞれを遂行するために「頭脳、スキル（方法）、フィジカル」を必要とする。PDCプロセスは本来は人の活動に適用される物だが、べつにソフトウェアに適用しちゃいけないわけじゃない。例えば囲碁やらチェスやらリバーシといった頭脳ゲームのコンピュータプレーヤーはこれらのプロセスを立派に回している。言換えればこれらは「頭脳、スキル、フィジカル」に該当する要素を内包している。
ところがこれをソフトウェア工学に適用しようとすると雲行きが怪しくなる。例えばUML1.xでは1つの図で「頭脳、スキル、フィジカル」に該当する要素がきちんと揃っている物がなかった。特に頭脳要素の欠落や混同が目立つ。頭脳要素を表現できているのはステートチャート図（2.xではステートマシン図）とアクティビティ図という伝統的な２つの図のみで、2.xになってようやくシーケンス図で複合フラグメントを使って制御構造を表せる様になり、全要素がそろった図が出てきたが、本来これらは処理の詳細を表す図なので全要素が表現できて当然なのだ。相変わらずクラス図やユースケース図の様な大局を見る図では頭脳と方法の混同が続いている。頭脳役のクラスやオブジェクトがいれば話は別だが、それでは設計メソッドが頭脳を表現できている事には成らない。
もちろん一部の図だけを使うわけではないから、こうした事は実用上は問題にならない。なのだが、頭脳要素が一番欠落していて、しかも頭脳要素を表現できるのが伝統的な図のみ（シーケンス図も古くからある）というのはソフトウェア工学の進化の方向性を疑いたくなる様な事態だ。どうしてこういうことになったのだろう？
そもそも、細かいコーディング時には「条件分岐」と「操作」を分けて書かない。これは明らかに頭脳要素と方法要素の混同だが、これがソフトウェア工学の方法論でも「頭脳と方法の混同」を招いている原因だろうか？。たぶん、それもあるだろう。それから「変数」や「関数」は宣言するのに「条件」や「イベント」を宣言しない事が「頭脳欠落」の原因であるとも言える。それとも「オブジェクト指向だから脳が無くて当り前」？ウィットの効いた意見だが、これはこれでなかなか的を射ている。でも、もっと根深い問題もある。
ソフトウェア工学の歴史は、人に「判断」を書かせないための歴史でもある。例えば関数呼出し（構造化設計からある）の背後にはコールスタック関連の処理が隠れているし、仮想関数にはポリモーフィズム処理が隠れている。イベント処理も然り。このようにベースシステムが頭脳役を担ってコーダが判断処理を極力書かずに済む様にソフトウェア工学は進化してきた。人の論理思考力はコンピュータに遠く及ばないから、この進化自体は間違ってはいない。しかしながら、表の「使い方（言換えればスキル）」と裏の「自動処理」は表裏一体だから、ここでスキルと頭脳の一体化、裏を返せば「混同」が起る。
そんな中でイベント処理が他と違っていたのは、「ユーザーの判断」をイベントという形でシンボル化した事にある。イベント処理はMVCモデルでViewと他の結合を緩めるために「キュー処理」を進化させた物だ。本来はユーザーの操作をシンボル化したのがイベントなのだが、このユーザーの操作にはどうしてもユーザーの意図が含まれるし、処理する側もユーザーの意図が何なのかを意識する必要があった。
この様にしてイベント処理は図らずも、それまでのソフトウェア工学の進化が「頭脳とスキルの混同」という副作用をはらんでいた事を対比的に鮮鋭化させてしまう。イベントが、人にとって判断の象徴に成りうるのは明らかだ。何しろイベントだけで制御処理を行う「イベント駆動言語」だって作れてしまう。この事からもイベントがフレキシブルな頭脳要素であることが想像できる。
ただ、現状のプログラミング言語やソフトウェア工学に慣れててしまっている人々の目にはイベントが異質で分かりづらい物にしか映らなかった。
そして、クラス・リファレンスには必ず発信イベントが書かれる時代になったのに、UMLのクラス図には未だにイベントがない。他にもソフトウェアに新たな頭脳要素をもたらす技術はたくさん登場したが、その大半が人工知能というカテゴリーで括られて、特殊な物として扱われている。これはすごく勿体ない事だ。
そしてソフトウェア工学界の技術(Skills*)偏重は、とうとうSOA（サービス指向アーキテクチャ）に至る。「サービス」というのはスキルが表に出たときの名前だ。スキルを行使すればそれは「サービス」となる。実際、SOAの扱いは関数にそっくりだ。関数は実行を担っており、「頭脳、スキル、フィジカル」の中では主に「スキル」に相当する。(*Technologyの方の技術なら偏重するのが普通だから話題にならない。）
話をSOAに戻そう。このSOA技術(Technology)とBPM（ビジネス・プロセス・マネージメント）を組み合わせれば、ビジネスパーソンが自社の業務に合ったシステムを自分たちで組めてしまう。もちろん彼らは専門教育を受けるがプログラマーに成るわけじゃない。BPMに使用するのはフロー図であり、所謂MDA（モデル駆動アーキテクチャ）の最先端事例だ。これはこれでスゴい事だが、ここで注目してほしいのはBPMの中身だ。名前から分かる様にBPMは業務プロセスを記述するためにある。そして今日、業務プロセスの基本と呼ばれているのはPDCの応用であるPDCAである。PDCの再登場だ。ついでに言えば、業務プロセスを記述することは、スケジュールの雛形を作るという事であり、Planningしてるのと同じだ。もっと言えば、BPMシステムがSOAのモジュールを呼び出す時にはBPMは頭脳として働いている！何やら面白いことになってきた。
さて、折角だからBPMの中で頭脳要素がどう扱われているか見てみよう。
BPMに使用する言語はBPIL等数種類あるが、パッと見、中に書かれた頭脳要素は「条件分岐」だけで、フローチャートの流れを汲んだ図に見える。もちろん「人」と「他システム」も含まれているが、これらはBPMシステムの頭脳ではない。でも大丈夫、「イベント」もプロセスの起動に使われている。このイベントの制限的な利用が私には不満だが、少なくともUMLに比べればマシだ。
（個人的にはUMLでもクラス図やユースケース図のように使用頻度の高く、基点に成る図には「頭脳要素」を盛り込んでほしいと思う。具体的には両図に「イベント」を追加するだけでも良い。）
さて、SOAで行き着くところまで行った感があるスキル偏重はこれからどうなるのであろうか？たぶんサービス指向に形を変えて、益々発展していくだろう。ただし、そのサービスの高度化には自動化が不可欠だ。では、自動化は今のまま「条件分岐」と「イベント」の組合わせや、人工知能等として実装していくのだろうか？それとも「ゴール指向」の様な方法論を発展させ、新たなプログラミング言語を作って頭脳要素を増やしていくのであろうか？できれば後者であってほしい。
いずれにしてもこれだけは言える。まだまだ「ソフトウェア工学には頭脳が足りない。」
この記事だけでは書ききれなかったことを別ブログを立ててシリーズ化しました。
そちらもよろしければご覧ください。
http://pdc-bsp.blog.so-net.ne.jp
ソフトウェア工学に人生を捧げている偉大な先生たちが聞いたら怒り心頭で、私を社会的に抹殺しようと方々に圧力をかけそうなフレーズだが（実際にはたぶん黙殺されるだけだろう）本当に言いたい事は「ソフトウェア工学、とりわけオブジェクト指向やUMLなどの著名な方法論の多くには“頭脳と方法の混同”が見うけられる」ということだ。たぶん、こう表現しても大抵の人は「何言いたいんだか分かんないや」とスルーして、問題提起されている事にすら気付かないだろう。だから敢えてケンカを売っている様なフレーズが必要になる。大事なことだからもう一度言おう。「ソフトウェア工学には頭脳が足りない」
頭脳が足りないかどうか調べるのは簡単だ。各方法論の一連の要素だけで「判断」が記述できるだろうか？もし判断の記述ができないなら、その方法論には頭脳が足りない。あるいはPDC（Plan, Do, Check）プロセスが回せるか見てみれば良い。もし、判断（Plan）と実行（Do）で同じ要素を使うようなら「頭脳と方法の混同」が起こっている。
例えばクラス図はどうだろう？関数内に判断を含める事はできる。でも関数は操作にも使うから、どうも混同が起きているっぽい。実際その通りで、操作とは"ある方法"を実行することだから、判断と操作の両方が関数に含まれている時点で頭脳と方法の混同が起きていることがわかる。
じゃあ、ユースケースはどうだろう？「アクターはPDC全部できるよ」とトンチで答える人もいるだろうが、それはつまり全部混同してるってことだ。まあそれは置いとくとしても、ユースケース図ではやはり頭脳に相当するのはアクターだけであり、判断を行う要素がシステムの外部にしか記述できない。つまり頭脳が足りない。
さて事例はこれぐらいにして、そろそろ「頭脳と方法の混同」とPDCプロセスに何の関係があるのかを明らかにしよう。
PDCプロセスの「Plan, Do, Check」は、それぞれを遂行するために「頭脳、スキル（方法）、フィジカル」を必要とする。PDCプロセスは本来は人の活動に適用される物だが、べつにソフトウェアに適用しちゃいけないわけじゃない。例えば囲碁やらチェスやらリバーシといった頭脳ゲームのコンピュータプレーヤーはこれらのプロセスを立派に回している。言換えればこれらは「頭脳、スキル、フィジカル」に該当する要素を内包している。
ところがこれをソフトウェア工学に適用しようとすると雲行きが怪しくなる。例えばUML1.xでは1つの図で「頭脳、スキル、フィジカル」に該当する要素がきちんと揃っている物がなかった。特に頭脳要素の欠落や混同が目立つ。頭脳要素を表現できているのはステートチャート図（2.xではステートマシン図）とアクティビティ図という伝統的な２つの図のみで、2.xになってようやくシーケンス図で複合フラグメントを使って制御構造を表せる様になり、全要素がそろった図が出てきたが、本来これらは処理の詳細を表す図なので全要素が表現できて当然なのだ。相変わらずクラス図やユースケース図の様な大局を見る図では頭脳と方法の混同が続いている。頭脳役のクラスやオブジェクトがいれば話は別だが、それでは設計メソッドが頭脳を表現できている事には成らない。
もちろん一部の図だけを使うわけではないから、こうした事は実用上は問題にならない。なのだが、頭脳要素が一番欠落していて、しかも頭脳要素を表現できるのが伝統的な図のみ（シーケンス図も古くからある）というのはソフトウェア工学の進化の方向性を疑いたくなる様な事態だ。どうしてこういうことになったのだろう？
そもそも、細かいコーディング時には「条件分岐」と「操作」を分けて書かない。これは明らかに頭脳要素と方法要素の混同だが、これがソフトウェア工学の方法論でも「頭脳と方法の混同」を招いている原因だろうか？。たぶん、それもあるだろう。それから「変数」や「関数」は宣言するのに「条件」や「イベント」を宣言しない事が「頭脳欠落」の原因であるとも言える。それとも「オブジェクト指向だから脳が無くて当り前」？ウィットの効いた意見だが、これはこれでなかなか的を射ている。でも、もっと根深い問題もある。
ソフトウェア工学の歴史は、人に「判断」を書かせないための歴史でもある。例えば関数呼出し（構造化設計からある）の背後にはコールスタック関連の処理が隠れているし、仮想関数にはポリモーフィズム処理が隠れている。イベント処理も然り。このようにベースシステムが頭脳役を担ってコーダが判断処理を極力書かずに済む様にソフトウェア工学は進化してきた。人の論理思考力はコンピュータに遠く及ばないから、この進化自体は間違ってはいない。しかしながら、表の「使い方（言換えればスキル）」と裏の「自動処理」は表裏一体だから、ここでスキルと頭脳の一体化、裏を返せば「混同」が起る。
そんな中でイベント処理が他と違っていたのは、「ユーザーの判断」をイベントという形でシンボル化した事にある。イベント処理はMVCモデルでViewと他の結合を緩めるために「キュー処理」を進化させた物だ。本来はユーザーの操作をシンボル化したのがイベントなのだが、このユーザーの操作にはどうしてもユーザーの意図が含まれるし、処理する側もユーザーの意図が何なのかを意識する必要があった。
この様にしてイベント処理は図らずも、それまでのソフトウェア工学の進化が「頭脳とスキルの混同」という副作用をはらんでいた事を対比的に鮮鋭化させてしまう。イベントが、人にとって判断の象徴に成りうるのは明らかだ。何しろイベントだけで制御処理を行う「イベント駆動言語」だって作れてしまう。この事からもイベントがフレキシブルな頭脳要素であることが想像できる。
ただ、現状のプログラミング言語やソフトウェア工学に慣れててしまっている人々の目にはイベントが異質で分かりづらい物にしか映らなかった。
そして、クラス・リファレンスには必ず発信イベントが書かれる時代になったのに、UMLのクラス図には未だにイベントがない。他にもソフトウェアに新たな頭脳要素をもたらす技術はたくさん登場したが、その大半が人工知能というカテゴリーで括られて、特殊な物として扱われている。これはすごく勿体ない事だ。
そしてソフトウェア工学界の技術(Skills*)偏重は、とうとうSOA（サービス指向アーキテクチャ）に至る。「サービス」というのはスキルが表に出たときの名前だ。スキルを行使すればそれは「サービス」となる。実際、SOAの扱いは関数にそっくりだ。関数は実行を担っており、「頭脳、スキル、フィジカル」の中では主に「スキル」に相当する。(*Technologyの方の技術なら偏重するのが普通だから話題にならない。）
話をSOAに戻そう。このSOA技術(Technology)とBPM（ビジネス・プロセス・マネージメント）を組み合わせれば、ビジネスパーソンが自社の業務に合ったシステムを自分たちで組めてしまう。もちろん彼らは専門教育を受けるがプログラマーに成るわけじゃない。BPMに使用するのはフロー図であり、所謂MDA（モデル駆動アーキテクチャ）の最先端事例だ。これはこれでスゴい事だが、ここで注目してほしいのはBPMの中身だ。名前から分かる様にBPMは業務プロセスを記述するためにある。そして今日、業務プロセスの基本と呼ばれているのはPDCの応用であるPDCAである。PDCの再登場だ。ついでに言えば、業務プロセスを記述することは、スケジュールの雛形を作るという事であり、Planningしてるのと同じだ。もっと言えば、BPMシステムがSOAのモジュールを呼び出す時にはBPMは頭脳として働いている！何やら面白いことになってきた。
さて、折角だからBPMの中で頭脳要素がどう扱われているか見てみよう。
BPMに使用する言語はBPIL等数種類あるが、パッと見、中に書かれた頭脳要素は「条件分岐」だけで、フローチャートの流れを汲んだ図に見える。もちろん「人」と「他システム」も含まれているが、これらはBPMシステムの頭脳ではない。でも大丈夫、「イベント」もプロセスの起動に使われている。このイベントの制限的な利用が私には不満だが、少なくともUMLに比べればマシだ。
（個人的にはUMLでもクラス図やユースケース図のように使用頻度の高く、基点に成る図には「頭脳要素」を盛り込んでほしいと思う。具体的には両図に「イベント」を追加するだけでも良い。）
さて、SOAで行き着くところまで行った感があるスキル偏重はこれからどうなるのであろうか？たぶんサービス指向に形を変えて、益々発展していくだろう。ただし、そのサービスの高度化には自動化が不可欠だ。では、自動化は今のまま「条件分岐」と「イベント」の組合わせや、人工知能等として実装していくのだろうか？それとも「ゴール指向」の様な方法論を発展させ、新たなプログラミング言語を作って頭脳要素を増やしていくのであろうか？できれば後者であってほしい。
いずれにしてもこれだけは言える。まだまだ「ソフトウェア工学には頭脳が足りない。」
この記事だけでは書ききれなかったことを別ブログを立ててシリーズ化しました。
そちらもよろしければご覧ください。
http://pdc-bsp.blog.so-net.ne.jp
コメント 0