概要
先日、高校の同窓会に行った。ここ数年来、高校時代の先生を東京にお招きして、同級生と一緒にお話を聞いている。今回は72歳になられた化学の藤沢先生に、仏教と量子力学の類似性などについて「物質は“もの”ではない」と題して様々な考えるヒントを教えていただいた[1]。今回はその話題のいくつかをまず紹介し、次いでゴール指向[2]の背景にあると私が考える「目的思考」について紹介する。
この理由は、モデリング手法は技術であって、技術だけ知っていてもそれはあくまでも道具であり、道具を使いこなすのは結局、人間だと考えるからだ。藤沢先生のおかげでモデリング手法と思考法には相互に深いつながりがあることに気づいた。この場を借りて、先生と同級生の皆さんに感謝したい。
量子力学
まず、量子力学である。
アインシュタインのe=mc2の式が意味するように、物質はエネルギーと相互変換できる。つまり、我々が普段なにげなく、形があると思っているものが、実は形のないエネルギーからできているということになる。
たとえばビッグバンという考え方がある。全宇宙が何百億年も前の大爆発によって生じたという説だ。すべての物質は大爆発というエネルギー現象の変化した姿ということになる。そして今も変化し続けている。
また人間の体もある時間が経てば、物質としてはまったく別の物質に置き換わっているにもかかわらず、人体の機能や脳の記憶が継承されている。この話をきいた別の酒好きな先生が、それならいくら飲んでも肝臓は再生されるから大丈夫なんだといったそうだが、肝臓の機能障害も維持されるから、そんな都合のよい話はないのだそうだ。
このように形があり不変であると思えるものも実は絶え間なく変化するシステムと考えることができるのである。
このように、構成要素はまったく入れ替わっているのにシステムとして維持されるようになっているところは生物とはすごいものだ。
昨日の私は今日の私ではないが、私は依然として私だ。
ITシステムは、なかなかまだそこまでいかない。ちょっと何かを入れ替えるとシステム全体がおかしなことになったりすることが良くあるものである。システムの構成要素がすべて互いに依存しあっていて、単独では存在し得ないにもかかわらず、要素に分解して個別要素だけを入れ替えても全体に影響することはないと考えてITを捉えてしまっているところに原因がありそうだ。最近のITシステムはネットワークで相互に結合され、個々の要素に分解できなくなってきていることにもっと留意する必要がある。
色即是空
般若心経に出てくる言葉だが、意外に本当に意味を知らないのが「色」と「空」だ。なんとなくまったく別のことを想像している人も多いかもしれないが、システムとは何かを考えさせてくれる言葉である。
「色」とは、天地万物・森羅万象のことで、物質とエネルギーの世界に属し、自然科学の対象となりうるものだそうだ[1]。これに対して「空」とは、大宇宙・大自然の背後にあって天地万物を創造し、それらを統御・支配している姿・形のない、「根源的な力」だそうだ[1]。
試しにインターネットで「色即是空」を検索すると同様の説明を知ることができる。いずれにしても、姿・形のある「色」が、「空」つまり大宇宙を支配する根源的な力ということはエネルギーによって互いに関係付けられているということではないだろうか?あらゆるものが相互に関係付けられるという考え方は、ものの間に「縁」が「起」こっていることでもある。つまり「縁起」だ。いまでは「縁起がよい」「縁起が悪い」などと日常語になっているが、本来の意味はすべてのものには関係があるという考え方のことだ。ITシステムにも縁起があるといえそうだ。とはいえ、そんなことをいっていると縁起でもないと叱られるかもしれない。
「量」:インドの知識基準
ところで、このような先生の話を聞いた帰りの電車の中で、そういえば、10年以上前に岩波講座「宗教と科学」という全集を買ったことを思い出した。
家に帰って早速、引っ張り出して拾い読みしていたら、その第1巻第8章に「仏教徒の場合」というのがあり、その中で、インドの知識基準には次の3つがあると述べられていることを知った[3]。
◆聖言量 聖典に記されている知識
◆比量 理性による正しい推論によって得られる知識
◆現量 現実・所与の対象で感覚によって確かめられる知識
これが結構、ITシステム開発にも当てはまるのだ。たとえば、ベストプラクティスを集めたパッケージを信じ込むのは、聖言量を信じて、現場の仕事のやり方としての現量を無視することかもしれない。こういうことは良くあるのではないか?
また、なんとなくどこの会社もやっているからということで合理的な意志決定をしないのは、比量ができていないからかもしれない。
実際、最近もこういうことを聞かれた。
「RFPをちゃんと正しく書いたのだが、ERPを使ったシステム開発がうまくいかず、納期延伸、費用超過に陥った。なぜなのか?」
この理由は、聖言量と現量を使って説明すると次のようになる。
「ERPが正しいのだから現場の業務をERPにあわせなさい」と聖言量の知識で強要したところで現場の知識を考慮しないといけないというのが現量である。結局ERPを現量にあわせてカスタマイズするためにアドオン開発することになるのは明らかだ。
西洋でも同じようなことはあるので、たとえば、ガリレオの実験がそうだと書いてある[3]。
ガリレオがピサの斜塔から砲弾と羽を落としたとき、周りにいた人は、「アリストテレスが間違っているはずはない。砲弾が先に落ちるはずなのに、そう見えないのは、自分たちの目が間違っている」と言ったそうだ。
「ERPが間違っているはずがない。現場が間違っているのだ」と言いそうなコンサルタントがいそうだ。
なかなかできないからこそ「現量」が大切だということだろう。いずれにしろ、インド人は2000年も前からこういう知識の根本を議論してきているから、ITにも強いのかもしれない。
目的思考
先ほど述べたように、ITシステム開発の「目的」をゴール指向で明確に定義しても、失敗することがあるかもしれない。たとえば、図1(a)に示したように、組織の限界やそれをとりまく境界の制約を無視して目的が計画されていると、目的は明確でも実行は不可能になるだろう。したがって、図1(b)に示した組織を取り巻く境界の制約を考慮して、組織が達成可能な目的を計画することが重要になる。

図1 なぜ計画が失敗するのか?
目的、組織、境界について何をどのように考えるのかを表1にまとめた。

表1 目的思考を実現する9つの力
目的
- ・展開力
- 目的を具体的に詳細化する
- ・実行力
- 目的を着実に遂行する
- ・評価力
- 目的の達成可能性と結果を客観的に評価する
これは、よく言われているPlan、Do、Seeに対応する。重要な点は目的が現実の組織に即して現量に基づいて具体的に計画され着実に実行されることだ。机上の計画だけでは、聖言量だ。
組織
- ・協働力
- 組織間の連携を強くする
- ・責任力
- 組織や担当者の役割と責任を明確にする
- ・判断力
- 合理的・客観的に意志決定する
組織間の壁を越えて連携するということは、縁起につながる。相互関係を大切にすることは、個々の組織の役割を明確にすることになり、責任範囲が明らかになる。また合理的に判断することができない組織は説明責任が問われるだろう。「比量」によって責任力や判断力が測られることになる。
境界
- ・情報力
- 経営層、取引先、現場、ベンダなどの情報を着実に収集する
- ・想像力
- 目的・行為に対してどんな事象が発生するかを想定する
- ・守備力
- 最低限守るべきシステムの目的・境界を明確にする
情報力がないと関係者の意見の収集が不完全になり、システムが完成して現場で運用するときになって、不具合や改善要望が多発することになる。また想像力がないと想定外の事象に驚くことになる。情報を収集しあらゆることを想定した上で、最低限何を保証するかを決めるという点で守備力はとても重要な考え方だ。ともすればあれもしたい、これもやりたいとなるから、なにもできなくなることが多いものだ。境界を明らかにすることは「現量」を知ることにつながる。
ところで、図2に示すようにこれらの9つの思考力はまた相互に関係する。たとえば情報力がなければ展開力が不十分になる。このような思考法は、ゴール指向が目的を形として表す「色」とすれば、それを背景で支える知力であり「空」といえるだろう。

図2 相互に関係する目的思考の力
ゴール指向モデリングを成功させる上で重要な思考法が、今回紹介した「目的思考」だ。ところで、目的思考の9つの力を見てもらえば分かることだが、当たり前の考え方であって、ゴール指向にとどまらず、日常の人間活動プロジェクトを支える力でもある。逆に言えば、だからこそ難しいということもある。目的を可視化するモデリング技術が目的思考を補完することだろう。
■参考文献- [1] 藤沢洵、量子論的物質観~物質は“もの”ではない、2007
- [2] 山本修一郎、システム要求管理技法―ゴール指向による、ソフトリサーチセンター、2007
- [3] 武藤義一、仏教徒の場合、岩波講座「宗教と科学」第一巻、1994
- 1:要求工学の概要
- 2:第12回要求工学国際会議 RE2004
- 3:要求仕様
- 4:要求工学プロセス
- 5:要求抽出
- 6:要求分析
- 7:要求確認
- 8:要求管理
- 9:要求追跡
- 10:要求工学の課題
- 11:ジャクソンの問題フレーム
- 12:シナリオ分析
- 13:要求工学国際会議RE2005
- 14:ゴール分析
- 15:iスター・フレームワーク
- 16:要求インタビュー
- 17:ゴール分析 応用編
- 18:ゴール分析 応用編つづき
- 19:ゴール分析の視点
- 20:ソフトシステム方法論 再考(その1)
- 21:ソフトシステム方法論 再考(その2)
- 22:ソフトシステム方法論 再考(その3)
- 23:非機能要求
- 24:信頼性要求
- 25:コミュニケーションの構造
- 26:組織とコミュニケーション
- 27:論理思考プロセスと現状分析ツリー
- 28:対立解消図と未来実現ツリー
- 29:前提条件ツリーと移行ツリー
- 30:特性要因図とゴール思考分析
- 31:i*フレームワークの書き方
- 32:i*フレームワークの危険な曲がり角
- 33:目的思考
- 34:要求工学の研究動向
- 35:アジャイル開発の要求工学
- 36:アジャイル開発の要求工学
- 37:要求レビュ
- 38:要求の曖昧さ
- 39:アクタ関係分析
- 40:要求工学の現状と課題
- 41:セキュリティ要求工学
- 42:ソフトウェア品質要求工学
- 43:イノベーションと要求工学
- 44:Wikiと要求工学
- 45:要求工学プロセスの改善
- 46:アクタ関係から見るユースケースと要求獲得
- 47:要求エンジニア
- 48:要求モデリングと誤り
- 49:要求を軸としたこれからのソフトウェア社会
- 50:ゴール指向とアスペクト指向要求工学
- 51:サービス指向要求工学
- 52:要求質問
- 53:試験工程での要求発見
- 54:要求とテスト
- 55:すりあわせの技術と価値星座
- 56:学生からの質問
- 57:SysMLの要求図
- 58:アシュアランスケースとGSN
- 59:組込み要求工学
- 60:要求とアーキテクチャ
- 61:要求と保守・運用
- 62:オープンソースソフトウェアと要求
- 63:要求工学のオープンな演習の試み
- 64:Web2.0と要求管理
- 65:ソフト製品開発の要求コミュニケーション
- 10G-EPONの概要 その4-10G-EPONの課題と今後の動向-
【新ネットワーク】 - やっぱりおかしいよね?メモリの使い方
【通信ソフトウェア開発】 - 猿でもわかる”フレッツテレビ”その2
【猿でもわかるICT】 - 10G-EPONの概要 その3-10G-EPONの特徴2-
【新ネットワーク】 - 10G-EPONの概要 その2-10G-EPONの特徴1-
【新ネットワーク】 - 開発支援ツール
【通信ソフトウェア開発】 - 猿でもわかる“フレッツテレビ”その1
【猿でもわかるICT】


