概要
先日、高校の同窓会に行った。ここ数年来、高校時代の先生を東京にお招きして、同級生と一緒にお話を聞いている。今回は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
- 60:要求とアーキテクチャ
- 61:要求と保守・運用
- 62:オープンソースソフトウェアと要求
- 63:要求工学のオープンな演習の試み
- 64:Web2.0と要求管理
- 65:ソフト製品開発の要求コミュニケーション
- 66:フィードバック型V字モデル
- 67:日本の要求定義の現状と要求工学への期待
- 68:活動理論と要求
- 69:ビジネスゴールと要求
- 緊急:今、なぜ第三者検証が必要か
- 71:BABOK2.0の知識構成
- 72:比較要求モデル論
- 73:第18回要求工学国際会議
- 74:クラウド時代の要求
- 75:運用要求定義
- 76:非機能要求とアーキテクチャ
- 77:バランス・スコアカードの本質
- 78:ゴール指向で考える競争戦略ストーリー
- 79:要求変化
- 80:物語指向要求記述
- 81:要求テンプレート
- 82:移行要求
- 83:要求抽出コミュニケーション
- 84:要求の構造化
- 85:アーキテクチャ設計のための要求定義
- 86:BABOKとREBOK
- 87:要求文の曖昧さの摘出法
- 88:システムとソフトウェアの保証ケースの動向
- 89:保証ケースのためのリスク分析手法
- 90:サービス保証ケース手法
- 91:保証ケースのレビュ手法
- 92:要求工学手法の再利用
- 93:SysML要求図をGSNと比較する
- 94:保証ケース作成上の落とし穴
- 95:ISO 26262に基づく安全性ケースの適用事例
- 96:大規模複雑なITシステムの要求
- 97:要求の創造
- 98:アーキテクチャと要求
- 99:保証ケース議論分解パターン
- 100:保証ケースの議論分解パターン[応用編]
- 101:要求発展型開発プロセスの事例
- 102:参照モデルに対する保証ケース
- 103:参SEMATの概要
- 104:参SEMATの活用
- 105:SEMATと保証ケース
- 106:Assure 2013の概要
- 107:要求の完全性
- 108:要求に基づくテストの十分性
- 109:システムの安全検証知識体系
- 110:機能要求の分類
- 111:IREB
- 112:IREB要求の抽出・確認・管理
- 113:IREB要求の文書化
- 114:安全要求の分析
- 115:Archimate 2.0のゴール指向要求
- 116:ゴール指向要求モデルの保証手法
- 117:要求テンプレートに基づく要求の作成手法
- 118:ビジネスゴールのテンプレート
- 119:持続可能性要求
- 120:操作性要求
- 121:安全性証跡の追跡性
- 122:要求仕様の保証性
- 123:システミグラムとドメインクラス図
- 124:機能的操作特性
- 125:セキュリティ要求管理
- 126:ソフトウェアプロダクトライン要求
- 127:システミグラムと安全分析
- 128:ITモダナイゼーションとITイノベーションにおける要求合意
- 129:ビジネスモデルに基づく要求
- 130:ビジネスゴール構造化記法
- 131:保証ケース導入上の課題
- 132:要求のまとめ方
- 133:要求整理学
- 134:要求分析手法の適切性
- 135:CROS法の適用例
- 136:保証ケース作成支援ツールの概要