TRIZ 論文

赤、緑、そして青 - Southbeachを使って状況を改善する

Howard Smith (CSC European Group、イギリス)、
BPTrends (Business Process Trends)、2011年 1月 4日

Southbeach Solutions Ltd., White Paper

和訳: 中川 徹 (大阪学院大学)、2013年 6月 6日
掲載:2013. 6. 9      [著者の許可を得て掲載]

Press the button for going to the English page.

編集ノート (中川 徹、2013年 6月 7日)

本稿は、2週間前に掲載しました「Southbeach Modeller」という汎用のモデリングソフトウエアの開発者が、その開発の思想・哲学を書いたものです。「状況」とはいろいろな問題・課題・矛盾を抱えている現状であり、それを改善して、望ましいものにすることが、著者の基本的な目的です。そのために、汎用の「モデル化の方法」、「モデルの表現法(Southbeach 表記法)」を創りました。また、そのモデルを使った「思考法」、モデルを使った共同作業による「合意の形成法」についても、きちんと説明しています。

状況を表現するには、 「箱と線」のダイアグラムを使っています。箱でものやことを表し、線(矢印)でそれらの関係を表します。赤色で有害なもの(例えば、問題)を表し、緑色で有用なもの(例えば、解決策)を表し、状況を多様な角度から表現・分析できます。そして、問題解決のために合意した行動を青色で書きます。一貫した表記法で、豊富な機能を持っています。

私が最も感銘を受けたのは、このモデル表現をつかって、対立する意見をきちんと表現していくことが、合意の形成を推進することです。そのことを、いろいろな例を使って、論理的に説明しています。著者は、IT と ビジネスプロセスマネジメント (BPM) の専門家であり、TRIZの矛盾の概念を学んでこの仕事に取り入れたといいます。 (技術分野の事例でなく) ビジネス分野の一般的な事例で矛盾や問題解決について話していますが、新鮮で、深い洞察を持った説明です。文科系の人たちに分かっていただけるとよいと思います。

問題解決、共同意思決定などのためのたくさんの技法に対して、このモデル化を汎用的に使えるというのは、素晴らしいことです。私自身この1年、「創造的な問題解決のための一般的な方法」を作り上げることを提唱してきていますが、そのような「一般化」「汎用性」がこのモデル化技法で支えられているのは心強いことです。

本稿の和訳掲載、および原文での掲載を許可いただきました 著者Howard Smith 氏と BPTrends 誌に感謝します。
英文ページ:  紹介(中川)、 原論文 (PDF)    BPTrends URL
和文ページ :  和訳論文(中川 徹訳)

なお、本稿の和訳ページに示しています図は、(英文の図を見て) 中川自身がSouthbeach Modeller で作成したものです。1日足らずの作業で完了し、その ソフトのわかりやすさ、使いやすさに感心しました。

Southbeach  表記法と そのソフトウエア Southbeach Modeller  について、調査・紹介し、情報交換するページを作りました。「Southbeach 表記法とモデリング: 紹介・情報交換・評価のページ」を参照ください。

 

原論文(英文) PDF 

 

目次

概要

1. 赤と緑

2. やさしく学べる

3.  ダイヤグラムを超えて

4.  Southbeach ワークショップ

5.  適用事例 ― IT システムの変換 

6.  チームを方向づける -- コンサルタントの役割

ケース1: 同じ言葉/異なるもの
ケース2: 同じ言葉/同じもの
ケース3:  異なった言葉/同じもの

7.  意見の相違は有用だ

8.  前進し続けよ

9.  あなたの創造性

10.  矛盾は至る所にある

11.  どこから始めるか?

例1: 良い点/悪い点の分解
例2: 根本原因の鎖
例3: 目標達成と障害のダイヤグラム

12.  仕事を構造化する

13.  青 - 差をつける

著者について

付録A:  Southbeachのためのソフトウェア

付録B:   参考文献

付録C:  Southbeach 表記法の仕様

 

 

本ページの先頭 論文先頭

1. 赤と緑

2. やさしく学べる

3. ダイアグラムを超えて

4. ワークショップ

5. 適用事例

6. チームを方向付ける

7. 意見の相違

8. 前進

9. あなたの創造性

10. 矛盾

11.  始める

12. 構造化する 13.  青−行動 付録 原論文

Southbeach Modeller 紹介

Southbeach フォーラム 英文ページ

 

赤、緑、そして青 - Southbeachを使って状況を改善する

Howard Smith (CSC European Group、イギリス)、
BPTrends (Business Process Trends)、2011年 1月 4日

Southbeach Solutions Ltd., White Paper

和訳: 中川 徹 (大阪学院大学)、2013年 6月 6日

 

概要

あなたの「チーム」が報告を上げて来ない。彼らが日々何をしているのかを直接コントロールすることはできない。 あなたの組織がどちらに行く必要があるかをあなたは知っているが、一体他の誰が同じように分かっているだろうか? 急いで考えてみよ。 時間はどんどん過ぎてゆく。 あなたのマネージャとあなたのクライアントは結果を期待している。 「みんなが私のプランを買ってさえくれれば」というのは解決策にはならない。 ゲームにおける利害関係者たちは、それぞれ自分のリソースとプランと目的を持っている。 みんながばらばらの方向に進んでいるように見える。あなたはそれらをまとめることができるか?

われわれはみんな絵を描くことができるけれども、プロセスモデルも、アーキテクチュアダイヤグラムも、組織図も、世界の現状を描いているか、あるいはあるべき姿を描いているに過ぎない。「ここ」から「そこ」にどのようにして行けるのか?

あなたに必要なのは、あなたのチームをテーブルに着かせ、重要な問題や挑戦に集中させて、来るべき変化に向き合わせることではないのか? 問題解決や変化の管理のための可視化技術を持っていて、みんながどんな分野の出身であっても理解できて、重要なことを細大漏らさずに実行できれば、大いに助けにならないだろうか?

「状況」というのは、改良あるいは変革しなければならないものについての一つの見解である。その例は、ビジネスの要求に合わないプロセス、ほどいて再編成しなければならない組織的なもつれ、および、悪い振る舞いに向かわせている一連の方針、などである。

状況を改善することは、ビジネスにおける有用な要素をいかにして増大させ、有害な要素をいかにして減少させるかについて、利害関係者たちの合意を得ることを意味する。もしチームが、「すべてのものは有用であり同時に有害である」ことを認識することができれば、進展するだろう。

本論文は、そのような厄介なプロジェクトを遂行するのに、「Southbeach ダイアグラム」 をどのように使えるかについて説明する。 このアプローチは、どんな産業においても、創造的なコンサルタント、ビジネスアナリスト、プログラムマネージャ、および変革の専門家たちに訴えるものである。

科学、工学、将来展望、公共政策などにも適用可能であるが、本稿ではビジネスコンサルティングに主たる焦点を合わせる。
それは、経営コンサルティングに携わっているSouthbeachユーザたちの最近の実践に基づいている。

 

1.  赤と緑

世の中のすべてのものが有用でありかつ有害である。 われわれが変えようとするものにはすべて長所があり短所がある。 いつも表があり、いつも裏がある。 グラスに半分入っていて、半分空である。 何を見るにも、二つの見方がある。 陰と陽。Southbeachでは、これらを見解 (perspectives) と呼ぶ。それらを赤と緑の箱で示す。 例を示そう。


このモデルで、「工業開発」が二つの要素に分解されている。一つは有用、一つは有害である。実際的なモデルはずっと多くのブロックを含むだろうが、その原理は同じことである。 この状況は、一つの矛盾を示している。 工業開発が増大すると、経済成長をより多く生み出すが、それはまた環境への影響を増加させる。

Southbeachモデルは、単一の「真実」を表すとは主張しないし、また一つの「世界」視点から描かれることもめったにない。 上のモデルは産業主義者が描いたものだ。 その見解は、工業開発が有用だとしている。 環境主義者の見解からの同じモデルはつぎのようであろう。


環境主義者(彼をLuke と呼ぼう)は過剰な工業開発を有害であると見、他方、産業主義者(彼女をJaneと呼ぼう)はすべての産業を有用だとみる。 それにもかかわらず、両者は、経済成長の必要性について同意しており、工業が環境に有害な影響を与えることについても同意している、という事実がある。 この同意によって、モデルをさらに詳しくすることができる。 ここに、詳細を追加して記述した。


各ブロックをさらに二つのブロックに分割した。一つは有用、一つは有害である。この単純な技術は強力である。 「状況のすべての面は有用でありかつ有害である」という明快な思考法を涵養する。有害な環境への影響でさえ有用である、持続可能な解決策への刺激を提供するから。

そこで、違った見解からやってきたにもかかわらず、Jane と Luke はさらにもう一つのダイアグラムを描くことができる。結局、生活の質と持続可能な結果の必要に反対する人があるだろうか?Jane と Luke はまた、コストが産業にとって有害であり、環境を保護する産業の能力に対して有害であることにも同意することができる。同様に、Lukeが地球のために資源使用を削減したいと思っているように、資源使用を減らしたいと 思っていないような会社の取締役がいるだろうか?

モデルが展開するにつれて、Jane と Luke は次第に結論に近づき始めることができる。

次のモデルでは、ブロックは同じであるが、一つの因子から他の因子への影響を示すために線で結んでいる。
Jane にも Luke にも明確になってきたのは、「資源の利用」が「生活の質」に反対に働き、環境変化の「将来のコスト」が「経済成長」を危険にさらすかもしれないことである。


このようなモデル中の矢印は、効果の「増幅」を意味する。 横線をつけた矢印は、その効果に反対に働くことを示す。 例えば、増加する将来のコストは経済成長を減少させるだろう。

経済成長の増加は、資源の使用を増大させ、生活の質を減少させるだろう。 これらの影響を描き加えることによって、Jane と Luke はこの状況中の矛盾について意識するようになってきている。 モデルが明らかにしたのは、将来のコストのために経済成長を譲歩するといったことをすべきでないなら、工業開発が環境への影響を考慮に入れなければならないことである。

いまやあなたはSouthbeachダイアグラムの4つのコア概念を知った。有用要素、有害要素、増幅する影響、そして打ち消す影響である。 これらで十分多くの有用な仕事をやりあげることができる。 これらの4要素はワークショップでしばしば使用される。 それらは最も困難な問題を解決するには不十分だが、問題に着手し、合意に向けて仕事を進めるにはいつも十分である。

本論文を読み進めるにつれて、あなたは Southbeach のもっと多くの機能を学ぶだろう。ただしその言語は豊富で、すべてをカバーすることは到底できない。

 

2.  やさしく学べる

Southbeachは単純だが強力だと、われわれは思っている。その表記法は、複雑なアイデアを表現するのに、学びやすい約束ごとを使っている。例えば:

 ・ 破線は「不十分」なことを意味する。それは箱にも線にも使える。 それで、「Aは不十分にBをつくる」と表現できる。

・ 点線は「潜在的」なことを意味する。何かが、将来存在するか、明らかにされるか、あるいは実現するかもしれない。例えば、「もしAであったら、われわれはBを増加させ、Cを打ち消すことができよう」。

・ 黄色はモデル中の「焦点」のものを強調するのに使う。 どんな状況にも、鍵になる要素がしばしば存在する。 それらを強調するのに黄色を使う。

前節のモデルを基にして作った新しいモデルで、Southbeachの他の要素のいくつかを示したものがここにある。


「環境への影響」の二重線は、(その害が)「ひどい」ことを意味する。青色の箱は提案された解決策 (アクション、行動)である。「持続可能な結果のための刺激」の周りの破線は、それがまだ達成されていないこと (潜在的) を意味する。六角形は「知識」あるいは他のブロックのための文脈を示す。菱形は、選択を行うべきことを図示するのに使う。「生活の質」は、下線を引いて箱を緑色に塗って示している。それが本システムの主要な目標であることを示している。

Southbeachはまた、「逆効果(dysfunctional)」、「歴史的」、「リスク」などの概念に対する視覚的な慣用を提供する。「課題(主題)」や「選択」をも提供する。 これらの視覚的な効果は、互いに組み合わせて使うことができ、(あまり)あいまいさを導入しない。 例えば、不十分な目標は、緑に塗った箱に入れ、破線の枠で囲まれるだろう。

Southbeachは重大な仕事をするのにも十分豊かであるが、それでいて学び適用するのに十分単純である。 普通の形、色、単純なスタイルの線を使っているので、その図はナプキンの裏にでも、フリップチャートにでも描くことができる。 多くのコンサルタントたちはたった2本のペンでなんとかやっていく。

・ 赤: 有害

・ 緑:   有用

Southbeachのペンの完全なセットは次を含む。

・ 青: 行動

・ 黒: 中立

・ 黄: 焦点/強調

記述用、ホワイトボード用、およびフリップチャートマーカー用の、通常のペンセットの多くがこれらの色を使っている。 それらのペンを持てば準備完了で、Southbeachを使い始められる。 ソフトウェアツールもまた使うことができる。

 

3.  ダイヤグラムを超えて

どんなSouthbeachのダイヤグラムも、何らかの見解 (perspective) から描かれる。「真実のただ一つのバージョン」などは、たとえあってもまれである。この貴重なあいまいさが創造性をもたらす。

もしAが有用なら、そういう人は誰でももっと多くのAを望む。もしBが有害なら、Bを減少あるいは消滅させることが有用なことは自明である。 もし有用なAが有害なBを作り出すなら、われわれは前進するべき方法を直ちに思いつくことができる。

・ A.を変更せずにBを減少させる方法を見つけよ。

・ より少ないBをつくるようにAを変更する方法を見つけよ。

・ B がまったくつくられないようなA の代替法を見つけよ。

・  など

簡単なルールを使って、すべてのSouthbeachモデルが、改善を前進させるプロセスを助ける。ダイヤグラムは一層重要な意味を持つ。 それらは変化のための計画である。 ダイヤグラムはチームの方向付けと状況の改善のための強力な道具になる。

 

4.  Southbeach ワークショップ

あなたは今までに、ワークショップで、みんながそれぞれのアイデアを出しているときに並行して、アーキテクチュアダイアグラムやプロセスモデルを描いてみたことがあるだろうか? しばらくすると、その過程は管理し得なくなる。 みんなはお互いを見回して、「白板のダイヤグラムは間違っている」 ということに同意する。 現在のダイヤグラムを一旦捨てて、初めから描きなおすことがしばしば必要になる。 Southbeachダイヤグラムでは、他のタイプのダイアグラムに比べて、この状況はそれほど起こらない。 どうしてだろうか?

Southbeachダイヤグラムは、「追加可能な意味論」を持っている。 新しい情報をモデルに追加するとき、他の要素や効果を壊したり矛盾したりせずにできる。新しい知識が明るみに出ると、モデルはそれを無効にすることなく拡張される。

下記のモデルを見てみよう。 ブロックの右下の数は、ワークショップの間に各ブロックが追加された順番を示す。 その順番にモデルを読むと、ワークショップの間にモデルがどのように発展していったかがわかるだろう。


線の色もまた、その影響が有益か有害かを示していることに注意されたい。
これは「from」ブロックの色、効果のタイプ、および「to」ブロックの色からの自然な結果である。

 

5.  適用事例 -- IT システムの変換

Southbeachを適用するのは、一人でも、少人数でも、あるいは大人数のグループでもよい。 チームで仕事をする場合でも、顔を合わせてやってもよいし、遠隔に離れていてもよいし、あるいはそれらの組み合わせでワークスタイルとプロジェクトの必要に最も適するように選べばよい。

小さいモデルから始めるのは、よいことである。 最初はあまり厳密にしようとしないほうがよい。 みんなで共有するモデルを作ることに参加するように奨励しよう。

そのような作業から生まれた複数のモデルは、後で互いに結合することができる。 それらはもっと大きな、もっと構造化したワークショップの出発点になる。 通常、ひとりが責任を引き受け、同僚にインタビューし、クライアントと話をし、要素を統合して、その上でモデルを配布してコメントを求める。 大きなプロジェクトでは、複数の見解からのそのようなモデルを多数作成することを予期すべきである。 モデルの中には数十あるいは数百のブロックを含むものもあるだろう。

以下、あるIT 変換プロジェクトでSouthbeachがどのように使われたかを紹介する。そのプロジェクトのファシリテータ/コンサルタントの話である。

「私は30人の人たちのワークショップを行い、この6週間で13のSouthbeachのモデルを作った。 そのうちの9つを大きな紙に印刷したが、大体卓球台6台分の大きさになった。 私は参加者を二つのチームに分け、それぞれに赤緑青のペンを渡して、有用な活動、リソース、効用、目標などを書き加え、さらに、制約、阻害要因、有害な副作用、そして、望ましい将来の状態を達成するためのアクションを書くようにした。 私たちは社内の4部門の見解に沿った4つのモデルを吟味していった。それらのモデルは、わたしが各部門の責任者に個別にインタビュしてあらかじめ作成しておいたものである。それからわれわれは、彼らのビジョンを達成するために克服しなければならない主要な課題を示した一つのモデルを作っていった。 それから、そのモデル中の9つのブロックを掘り下げていった。

「最初に私は概要として、課題、選択肢、各選択肢の有用および有害な派生効果、そして、なぜいくつかの推奨をしたのかについて説明した。 それから私は参加者たちを2チームに分けてそのモデルをさらに改良させるようにした。 10分後に私は、チームを交替させて、互いに他チームのコメントをレビューしてコメントさせた。 そして二つのチームが集まって、その次のモデルについての私の説明を聞いた。 すべてのモデルを検討したのちに、われわれは今後どのように前進させていくかについてグループ討論をし、それを私が一つのモデルに記述していった。 参加者たちは、そのモデルを高く評価した。 彼らの多くが私のところに来て、その日のことを非常に有益だったといって感謝した。そしてわれわれは、モデルの中のアイデアを現実に変えるにはどうすればよいかについてさらに話を進めていった。

「これらのクライアントの大部分は、Southbeachをそれまで見たことがなかった。 彼らがブレインストーミングした最初のモデルについては少し遅かった。 第2のモデルでは、彼らはすでに要領をのみ込んでいた。 このテクニックが、異なったグループから来た多くの人々を、それまでに経験したことがないやり方で協力させることを可能にした、とみんなが同意した。 Southbeach表記法がこの会話を可能にした。 彼らはそれを楽しんだし、彼らの将来のプロジェクトのための可能性を考えて興奮していた。」

このプロジェクトでは、コンサルタントとチームとで作ったさまざまなモデルは、全体の状況を異なる側面/見解から表現したものであった。 これは、プロジェクトとその後の実現の間、チームが仕事を組織化するのを助けた:。

・ 構造によって: IT における異なった階層 (例えば、インフラストラクチャ、アプリケーション、ビジネス、など)

・ 時間によって: 現在、将来、そして「どのようにしてそこに到達するか?」 

この種の仕事は、状況改善の努力のスーパーストラクチャだと考えるとよい。

以下のセクションでは、この例のようなプロジェクトで使われるテクニックについてもっと説明する。 もちろんどんなプロジェクトも、単一の経路に従って進むわけでないし、すべてのテクニックを使用するわけではない。 Southbeach表記法は、流動的で柔軟なアプローチであり、チームメンバがすでによく知っている既存の創造性手法や問題解決技法の多くをサポートしている。 しかしながら、そのようなプロジェクトのただ一つの共通点は、Southbeachダイアグラムを主要な焦点として、また作業の生産物として使用し、作業をガイドしていることである。

 

6.  チームを方向づける -- コンサルタントの役割

人々が基本的に意見を異にするとき、私たちに何ができるだろうか? 解決に向かって進むのを妨げている、特定の意見の違いを解消する一つの道を見つける必要がある。 要するに、見解の違いを解決するか、解消する (なしにする)かしなければならない。

Southbeachはいくつかの有用なアラインメント技法を含んでいる。[訳注: 原文で Align という語を使っており、並べる、調整する、同じ立場に置く、提携するなどを意味する。方向づけると訳しているときもある。] 優れたファシリテータは、偉大な魔術師のように、使っている技術について言及することさえほとんどない。 それはワークショップの一部になっている。 次節にそのようなテクニックを三つ提示する。

哲学的に言えば、世界に「問題」などは存在しない、あるのは関係者の間のリソースの再配置だけである。 (例えば) 製品のコストは顧客には有害であるが、供給者には有用である。 「コスト」がなければ、製品は決して供給されえない。コストは本当の意味では、「有害」ではない。 それは顧客と供給者の両方にとっての一つの解決策である-- たとえ彼らが初めにそうは考えなくても。

いくつかの簡単なルールに従うことで、意見の対立の大部分を容易に解決できる。

ケース 1
意見の相違が Jack と Gill の間に 起った。 実際には、彼らは互いに違ったことについて話していたのだが、同様のあるいは同じ言葉を使っていたのだ。 例えば、Jack はその事業戦略が有用だと主張したが、Gill はその戦略は誤りだと考える。 後に分かったのは、彼らが二つの異なる戦略について話していたことである。「会社」が下した戦略が、それぞれの事業部門で異なって解釈されていたからである。 実際、彼らが話していたのは、二つの異なる事業部門レベル戦略だったのである。

ケース 2
Jack と Gill は、同じ (あるいは同様の)言葉を使っている。 彼らは同じことについて話しているが、それについて非常に異なった見方を持っている。 例えば、Jack は、その戦略が有用だというが、Gill は有害だと考える。 彼らが異なった見方を持つ理由は、その「戦略」を部分に分解していない[で話している] からである。 Jack は戦略の一つの側面について話していて、Gill は別の側面を話している。 これが起こる一つの理由は、それぞれが自分の仕事の文脈で、その戦略がどう表れるかについて話しているからである。

ケース 3
Jack と Gill は、ちぐはぐなことをいっている。 二人とも同意しているように見えるが、その状況を記述するのに同じ言葉を使っていない。 例えば、Jack は「その開発計画が有害である」といい、他方 Gill は「問題はインセンティブと目標にある」と考えている。 後で分かったのは、彼らは二人とも同じ計画について話していたのだが、彼らの異なるビジネスバックグラウンドからの言葉で話していたのである。

Southbeach の赤と緑のブロックは、Jack と Gill が一つの共通のモデル上に並ぶことを助け、したがって、状況に対する一つの共通の理解に達することを助けることができる。 その方法を理解するために、これら三つのケースをさらに詳細に調べよう。 Southbeach を使うと、合意がついには得られるはずである。

ケース 1.    同じ言葉/異なるもの

下図のモデルを見てほしい。 それは、Xが有用であり、かつ、有害であると言っている。 そのようなことは、Xの異なる側面については真であるかもしれないが、(Xの) システムレベルでは絶対に真ではありえない。 システムにとってX が有用であるか、そうでなければ有害である。 彼らは違ったものについて話しているのだろうか? そうだとすれば、彼らはそれぞれを有用な要素と有害な要素に分解することができる。 どうなるかを見るために、順番にそれぞれが分解して、何が起こるかを見よう。 4つのブロック、YU、YH、ZU、およびZHは、お互いに似ているか? Y と Z は同じものか、あるいは違ったものか?

ケース 2.   同じ言葉/同じもの

一つの合意された見解においては、一つのもの(オブジェクト)が有用であり同時に有害であるのは、それをその(複数)部分に分離したときだけである。 下のモデルを見てほしい。 この図がいっているのは、Jack はX を有用であると見、Gill はXを有害だと見ている。 もし、彼らが同じものについて話しており、それがシステムにとって有用であるか有害であるかについて意見が一致しないのだということに合意するなら、彼らはそのものの「(複数)部分」について話しているのに違いない。 分解してより詳しく見よう。


「部分」 という語を狭義に取るべきでない。 それは物理的な部分ではなく、見方のことかもしれない。 これらの「分離」はSouthbeachにおいて重要である。 X をその有用な「部分」と有害な「部分」に分解するあらゆる方法を考えてみよう。

・ もしかすると、Jack は過去にあった (そして現在に外挿してきた) X について考えており、一方 Gill は、将来のXについて (ものごとがなかなか変わらないと思いつつ)考えているのかもしれない。 これは「時間による分離」と呼ばれる。 Jack と Gill が、Xについて、その過去、現在、および未来をもっと明確に考えることによって、同じ立場に立つことができないだろうか?

・ Jack がXの一部分(構成要素)について話しており、Gill は別の部分について話しているのだろうか? 構造による分離?  例えば、契約書のA節と同じ契約書のB節。

・ Jack はX が別の部品の上にあるときのことを考えており、Gill は何か別の構造の内部にあって孤立しているときのことを考えているのだろうか? 空間による分離? 彼らは同じシステムを設計しているが、構造における諸要素の配置について考えていないのだろうか?

・ Jack はXの一つの側面 (例えば、色) を見ているが、Gill は別の側面 (例えば、重さ) を見ているのだろうか? この「側面による分離」はずいぶん微妙なことがある。 議論している話題やものの多くの詳細が、大急ぎのワークショップとしばしば使用される緩い言語のために、混乱してしまう。 出席者はしばしば、なぜかを説明せずに、あるものについての一つの立場を取ることがある。何かに関する見解で取ることができる。 状況の多くの側面を分離してから、何が有用で何が有害かを判断することが重要である。

・ Xに関する Jack と Gillの役割と責任をもっと明確に分離することによって、Xに関する彼らの見方を調整するといったことができないだろうか? ビジネスでは「役割による分離」は重要なパターンである。 例えば、役割Rを Gill に与えて、役割Qを Jack に与えると、Xがいまや両者に有用なのではないだろうか? プロセス設計における作業割当てによって、しばしば同様の結果を達成できる。

・ Jack はあるひとつの状況下でのX について話し、同時に Gill は別の状況下でのX について話しているのだろうか? 「状況 ( 条件) による分離」?  考えているものが置かれている状況が違えば、容易に意見の不一致に至る。 例えば、Xが有用であるのは、ビジネスがその目標Tに達した場合だけである。

・ Jack と Gill は、Xが有害である確率について、異なる見解を持っているのかもしれない。 例えば、ビジネスにおけるリスクおよび相対リスク。 「確率による分離」を使えば、彼らは同意できるのかもしれない。 例えば、Xが有害なのは、ときどきだけである。

・ Jack と Gill は同じXについて話しているが、システムの異なった状態あるいは反復段階について話しているのだろうか? 「バージョン」による分離? 例えば、Jack は新しいXについて話しており、Gill はXをアップデートする現在のプランを知らないで、以前のXについて話しているのかもしれない。

・ あるいは、彼らの見解がそもそも異なっているのか? ...  Jack はXを「好まず」、他方、Gill はXが「大好きだ」。そんな場合に、われわれはこれ以上見る必要があるだろうか? 意見の相違はなぜ存在するのか?
助言: X を多数のしかた (時間、側面、役割、など)で分離してみて、Jack と Gill が同意できる要素を見つける。

時間、構造、空間、局面、役割、状況(条件)、確率、バージョン、あるいは見解による分離は、急速に動いているプロジェクトで言葉が合意を歪めることができる主要な方法である。 モデルは、システムの分解を明示することによって、人々が合意するのを助けることができる。 システムをどのように分離すべきかが明確になると、Jack と Gill が、Xの特定の「部分」について有用(あるいは有害)と合意できるようになるだけではない。それはまた、X が全体として(すなわちXを内包する全体システムの文脈において)有用か有害かについても彼らが合意することを助けるだろう。

すべてのものは有用でありかつ有害である。


Jack と Gill は、Xが上位システムにとって (すなわち、プロセス、組織、設計などにとって) 有用であることに同意した。 彼らはともに、Xがある点では有用であって、他の点では有害であることを理解した。 彼らはそれが有用である点、そして有害である点をリストアップした。 これは彼らが前進することを許し、システムをどう改良しなければならないかについて合意して、可能な解決策を探し始めることを許すだろう。 彼らはすでに、調査するべきいくつかの経路を持っている。

・ 合意された有害要素(たち)を減少または消去する方法を見つけること。

・ システム全体を、有害機能を含まない/示さない代替システムで置き換える方法を見つけること。

・  など

ケース 3.  異なった言葉/同じもの

Jack と Gill は異なった言葉を使用して同じものを指しているが、そのことに気づいていない。 例えば、Jack は、「戦略」について話していて、その「仮定」が有害であると言う。 Gill は、「計画」について話していて、「要求獲得フェーズ」が適切にされなかったと言う。実際は、彼らはともに同じ計画の基礎について話していて、仮定と要件という言葉を使っているのである。 彼らの用語を調整すれば、彼らが前進するのを助けるだろう。 そしてチームは、問題を分解して、解決する方法を見つけ始めることができる。

下のモデルで、Jack はXについて話し、Gill はYについて話している。実際は、二人ともZについて話しているのである。これに気がつけば、彼らはZを分解し始めることができる。

 

7.  意見の相違は有用だ

チームが単一のモデルで作業をするのがいつも可能であるというわけではない。 しばしば、異なったチームが、あるいはチームメンバが、自分たち自身のモデルを作成していきたい、そして状況に対する異なった見解 (すなわち、分離)を表現したいと望むだろう。例えば:

・ 過去を示している一つのモデル、そして将来を示す別のモデル。

・ 全社レベルの見方のためのモデルと、事業部門の見方のための別のモデル。

・ トップレベルのモデルと、各部分のための複数の詳細モデル。

・ など

ビジュアルモデルは、みんなが言いたいことを言うための強力な方法である。 さまざまな利害関係者たち、あるいは異なる分野や機能から来た諸チームは、彼らがそれぞれ部分にしかすぎない全体システムを理解するのに、ビジュアルモデルが有用であることを見出すだろう。 しかし、人間の性が勝つとどうなるだろうか? もしチームが単一のモデルを作りたくないとしたら、どうなるだろうか?

みんなが合意した一つのモデルを作るのが不可能なときには、Southbeachは不一致を明示的に視覚化することを許している。 そのようなモデルは、議論のための出発点として何も悪いことはない。

コンサルタントたちの典型的なやり方は、異なる利害関係者たちにインタビュして、異なるモデルを作成し、それから彼らに彼らの見解がいかに違っているかを見せる。 ずいぶんと異なる複数のモデルをチームに突きつけることは、啓発的であり、面白いものである。 本論文では扱えなかったさまざまなテクニックを使うと、これらの複数モデルを結合して単一のモデルを作ることができる。

一つのテクニックは、格子を使って、彼らの分離に応じて諸要素を配置することである。 格子は違ったものを一緒に持ってくるが、それでもなおそれらが描かれた諸見解を認識する。

Southbeach表記法は、1次元格子と2次元格子をサポートしている。下図のモデルは2次元格子を使っていて、「科学」と「政治」との相互作用を、「地球温暖化理論の支持者」の見解からと、その科学的分析の基礎に疑問を呈している「懐疑論者」の見解とから示している。 モデルは、産業界への規制と管理の程度について、彼らの意見が一致していないことを明瞭に示している。

 

8.   前進し続けよ

「状況」というのは、チームが改良したいと望んでいるあるものについての、一つの合意された見解である。有用な要素を増大させ、有害な要素を減少させたいのである。本稿の最初の事例を使うと、産業主義者Jane と環境論者Lukeは、おそらく下図の目標(緑色に塗った箱)に合意できるだろう。

「リソースの利用を最小にする」というブロックは、両方の見解からの一つの目標である。 しかしながら、疑いなく、「工業開発」が有害だということには、彼らは意見を異にするだろう。 それでも彼らがすでに同意しているのは、開発が有益な「経済成長」と有害な「環境影響」を生み出すことである。 そこでその(工業開発の)ブロックをモデルから除いて、単に、産業が(環境への)衝撃を緩和する解決策を実現しようと試みているということを受け入れよう。 モデル中でこれを明示するには、(言及せずにおくのではなく) Southbeachは二つの重要な構文を提供する。 「歴史的」(箱全体のX印) と「 行動」(青色の箱)である。 行動は示唆された介入である。


以下の節での説明のために、このモデルがいま「同意された」と仮定しよう。 モデルは状況を改善するための方向を示唆することができる。 その示唆はモデルの開発の間、いつでも思いつくことができる。 出力はモデルの開発をガイドし、問題解決のための方向に揃えさせることができる。 ここに、いくつかの例がある:。

1. 「リソースの利用」を制限するのに「新しい産業アプローチ」の有効性を増加させる方法を見つける。

2. 「リソースの利用」の増大に対して「経済成長」を制限する方法を見つける。

3. 「経済成長」を作るのに「工業開発」を増幅する方法を見つける。

4. 「環境への影響」の増大に対して「工業開発」を制限する方法を見つける。

5. 「持続可能な結果のための社会的刺激」をつくるのに「環境への影響」を増幅する方法を見つける。

6. 「生活の質」をつくるのに「持続可能な結果のための社会的刺激」を増幅する方法を見つける。

7. 「生活の質」をつくるのに「経済成長」を増幅する方法を見つける。

8. 「生活の質」の減少に対して「リソースの利用」を制限する方法を見つける。

9. 「将来のコスト」の増大に対して「環境への影響」を制限する方法を見つける。

10. 「経済成長」の減少に対して「将来のコスト」を制限する方法を見つける。

11. 「将来のコスト」の制限における「新しい産業アプローチ」の有効性を増大させる方法を見つける。

12. 「環境への影響」の制限において、「解決策提供への産業の動き」の有効性を増大させる方法を見つける。

13. 「解決策提供への産業の動き」をつくるのに「工業開発」を増幅する方法を見つける。

これらの示唆はどこから来たのか?それらはSouthbeach 表記法に「焼きつけられている」のか?

 

9.  あなたの創造性

Southbeachモデルにはルールを追加できる。 個々のコンサルタント、あるいは一緒に働いているチームが、彼らのモデルにルールを追加する。 (ルールが)生成する出力は、彼らの仕事をガイドするのを助ける。 前節での13行の出力は、4つのルールを使って生成したものである。すなわち、

つくる( ,有害)「{to} の増大に対して {from} を制限する方法を見つける」

打ち消す( ,有用) 「{to} の減少に対して {from} を制限する方法を見つける」

つくる( ,有用) 「{to} をつくるのに {from} を増幅する方法を見つける」

打ち消す( ,有害) 「{to} を制限するのに{from}の有効性を増大させる方法を見つける」

示唆された指示のいくつかが互いに矛盾していることを見ることができる。 例えば:

5. 「持続可能な結果のための社会的刺激」をつくるのに「環境への影響」を増幅する方法を見つける。

9. 「将来のコスト」の増大に対して「環境への影響」を制限する方法を見つける。

「環境への影響」を減少させ、それを同時に増大させるのはどうしたらできるのだろうか? 出力中に矛盾があることは、チームがまだ解決していない問題がモデルに含まれていることを示す。

複雑な状況においてすべての矛盾を指摘することは簡単ではない。 それにはチームがその状況を複数の異なる見解から吟味したり、モデルを十分詳細なレベルまで分解したりすることが必要になるだろう。 良いファシリテータはこれらのことを「白板上で」取り組むことができるだろう。 もっと複雑なプロジェクトになると、ソフトウェアツールが必要になるだろう。

また、ルールを使ってモデルをインタラクティブに発展させるよう導くことができる。それにはチームが望ましい方向にモデルを発展させるのを導くように質問をしていくのである。いまこのモデルに、二つのブロック「産業事故」と「公共の認識」を追加した。

モデルにこれらの追加要素を含めた結果、モデル中の矛盾のリストはつぎのようになる。

1.  「工業開発」、「経済成長」、「環境への影響」

2.   「工業開発」、「解決策提供への産業の動き」、「環境への影響」

3. 「経済成長」、「生活の質」、「リソースの利用」

4. 「環境への影響」、「公共の認識」、「産業事故」

5. 「産業事故」、「公共の認識」、「将来のコスト」

このリストは次のルールで生成された。

有用 (&a=*, &b=*) 有害 (&a, &c=*) 「{&a} {&b} {&c}」

ルールはどのようにして開発されるか? ルールの標準セットが出現し始めており、どんなモデルにも適用可能である。 それらは実践コミュニティを反映し、特定の方法や創造性ツールを実装したものである。それらの方法には、根本原因分析 (RCA)、TRIZ、制約理論、デボーノの方法、SWOT、その他多数ある。 いくつかのプロジェクトではルールはあらかじめ開発されるが、他のプロジェクトでは進行中にオリジナルに開発される。 コンサルタントやアナリストは誰でも、過去に有用だと見つけた質問や主張の(しかたの)リストを持っていることが分かった。 それらを簡単なルールとしてコード化し、再利用することができる。

 

10.  矛盾は至る所にある

「矛盾」の概念はTRIZの実践者たちによって非常によく理解されている。
一つの矛盾を露見させたとき、そこに一つの問題があるのだということを、あなたは知っている。
(矛盾には) 二つの主要なタイプがある。


「技術的矛盾」はシステムの設計から生じる。設計についての何かで、有用な出力を増大させようとすると、有害な効果が増大する場合である。 例えば、エンジンがもっとパワーを出すようにすると、より多くの熱を生じる。

「物理的矛盾」は現実の性質そのものから起こる。 例えば、あるものXは、一つの空間の内部にあり、そして同時に同じ空間の外部にあるということはできない。 何か熱いものが同時に冷たいということはできない。 など。

矛盾を見つけて、扱っているのがどちらのタイプであるかを理解することは、問題解決にとってきわめて重要である。

矛盾に直面すると、妥協を図ろうとする誘惑がある。 矛盾を解決して、それをシステムから除くことは、ずっと難しいことである。それは、制約や要求の複雑なセットに直面した技術者がだれでも知っていることである。 それでもなおわれわれは、前進したいと望むなら、それらを解決しなければならない。

システムの一部が「上に」と同時に「下に」と要求されているとしよう。 これはどのようにして可能であるか? これを試みよう。 時間によって分離する! いつそれが最上部にある必要があるのかを尋ねる。 いつそれが最下部にある必要があるのかを尋ねる。
これは根本要求分析 (RRA) と呼ばれる。 この場合、それは一つの解決策を示唆する。 設計を変更してその部分を動けるようにし、最上部にあることが必要なときにはそこにあり、その他のときには最下部にあるようにする。 このような機械的な解決策はビジネスから遠く離れていると見えるが、緩く考えてみると、それらが当てはまることがあなたにも分かるだろう。 これらの「機械的な」アナロジや問題解決のパターンがTRIZのコミュニティで文書化されており、それらはビジネスや社会のようなよりソフトな文脈においても強力なアプローチである。

種々の分離について考え始めると、解決策が豊富に出てくる。 部分ではなく、観点の方を動かすのはどうだろう? そうすると、必要に応じて/必要なときに、それは「上に」あり、また「下に」ある。

ある人たちには、これらの解決策が自然に出てくる。 「水平思考」のマインドを持っている人もあるだろう。 他の人たちには、参考図書に記録された示唆や、ソフトウェアアプリケーションによる示唆の助けを必要とする。

Southbeachのモデルに諸ルールを追加でき、それによって多数の様々に異なるタイプの示唆を生成できる。 - ブレインストーミングのための「創造的な」アプローチである。 矛盾に直接取り組むルールを追加することによって、ブレインストーミングと問題解決のための「創造的な」指示を多数生成することができる。 このモデルを取り上げよう。


「環境への影響」に焦点を合わせると、ダイヤグラムは以下のように示唆する。

以下のように尋ねたら、どんな解決策が思い浮かぶだろうか?

1. 「産業事故」なしで「公共の認識」の効用を得るにはどうしたらよいか?

2. 「環境への影響」は本当に「産業事故」をつくるか?  私たちは正しい問題を見ているか? 「産業事故」は何か他のものでつくられるか?

3. 「環境への影響」が「産業事故」をつくることに介入してその能力を制限する方法があるか?

4. 「環境への影響」が「産業事故」をつくることを完全に阻止する方法があるか?

5. 「環境への影響」が「産業事故」を作っている間にも、後者を取り除く方法を見つける。

6. 「産業事故」はどの程度の問題であるか?  「産業事故」に対処していく方法を見つけられるか?

7. 「産業事故」の有害な効果をしばらくの間延期できるか? 将来、「産業事故」にどのように対処するだろうか?

8. 「産業事故」を何か害のより少ないものに変換できるか?

9. 「環境への影響」がつくる「産業事故」の有害な効果を打ち消すな何かを導入できるか?

10. 「産業事故」あるいはその効果を取り除くことができないと仮定すると、「産業事故」の積極的な使用を見つけることができるか?

11. 次世代の「産業事故」とはどんなものであろうか?

12. 「環境への影響」を変更して、「産業事故」をより少なくつくるようにできるか?

13. 「産業事故」をつくっている「環境への影響」の部分を見つけて、その部分を除去し、「環境への影響」が「公共の認識」を作る能力に影響を与えないままにできるか?

14. 「環境への影響」を何か他のものと組み合わせて、「産業事故」がもはや問題でないようにできるか?

15. 「公共の認識」を何か他のものと組み合わせて、「産業事故」がもはや問題でないようにできるか?

16. 「環境への影響」の設計を変えて、それがもはや「産業事故」を全くつくらないようにできるか?

17. 「環境への影響」の代替を見つけ、「産業事故」をつくらず、それでいてなお「公共の認識」をつくるようにできるか?

18. 「環境への影響」が「産業事故」をつくることが、有害な効果を持つには不十分であるように、システムを変更する方法があるか?

19. 「産業事故」は「公共の認識」にとって問題であるか? 「環境への影響」あるいは「公共の認識」を「産業事故」から分離して、異なるシステムに入れることができるか?

20. もし「産業事故」がつくられることが不可避なら、「産業事故」を隔離して、それがシステムに害を及ぼさないようにできるか?

21. 何かをシステムに追加して、「産業事故」を減少あるいは消去できるか?

22. 何かをシステムに追加して、「公共の認識」をもっと有用にし、その結果「産業事故」が問題としてより少なく認識されるようにできるか?

23. 何かをシステムに追加して、「公共の認識」の必要を最小化し、それによって「環境への影響」の必要が減少し、またそれによって「産業事故」がつくられることが減少するようにできるか?

24. 「公共の認識」よりほかの理由で「環境への影響」を必要とするか? もし必要としなければ、「環境への影響」を取り除き、「産業事故」を避けることができる。

25. 将来のことを考えよう。 「公共の認識」を別の方法で得るだろうか?  したがって、「環境への影響」の関連性が少なくなり、「産業事故」の問題が解決するだろうか?

26. 「公共の認識」に対する要求は将来どのように変化するだろうか? それはなお「環境への影響」から獲得され、したがって、「産業事故」がやはりなお問題だろうか?

27. 次世代の「公共の認識」はどのようなものだろうか?

28. 「公共の認識」の必要を減らすことができるか? そうだとすれば、「環境への影響」の使用を減少させ、「産業事故」をつくることを減らせる。

29. 「公共の認識」の代替で、「公共の認識」の効用を持ちながら、「環境への影響」に頼らないものを見つける。

30. 「公共の認識」を含むシステムの次世代は、どのようなものか?

31. 「公共の認識」を必要とするか? そうでなければ、「環境への影響」を取り除いて、「産業事故」 を避けることができる。

示唆された方向のいくつかは意味をなさないように見えるが、それぞれが有効な問題解決の方向である。 Southbeachモデルからの出力を吟味することは、チームが彼らのモデルを改良し、問題に共同して取り組み、解決策を見つけるのを助ける。

 

11.  どこから始めるか?

Southbeachダイヤグラムは、その中核は、簡単な「線と箱」の図である。 箱はその状況に関して何が重要かを述べ、そして、線はそれらの間の効果や影響を定義する。 何が有用で、何が有害で、何が不十分かなどを定義することによって、前進するための方向が生成される。 しかし、真っ白なキャンバスに向かったとき、どこから始めればよいのか?

例1:  良い点/悪い点の分解

Southbeachモデルはテンプレートとして働き、特定の問題解決法や改善法の適用のための出発点になる。 ここで、一つの単純なモデルを使って、状況を有用要素と有害要素に「ブレイクダウン」しよう。 ここでの各線は増強効果を示す。 すなわち、一つの要素を増大させると、その出力(矢印の先)のすべてが増大する。 したがって、モデル中の各ブロックは矛盾する状況を表している。


例2:  根本原因の鎖

つぎのダイヤグラムでは、コンサルタントは一つの異なるアプローチを採用した。 ここでは、リスクを理解するために、寄与している原因の連鎖を逆戻りして辿っている。


例3:  目標達成と障害のダイヤグラム

もう一つのよく使うアプローチは、状況あるいはシステムを目標という目で見ることである。 このモデルでは、主たる目的に貢献するサブ目標たちが、有用な要素として表現される。 目標の達成を妨げる要素が、有害な要素として示される。

これら三つの例はSouthbeachがさまざまに異なったモデル化のアプローチをいかにサポートできるかを実証している。 表記法の詳しい記述を読めばその他の多くの可能性が広がる。 単一のツールを多くの異なった文脈で使うことができるのである。 さまざまに異なったワークスタイルを反映する種々のルールが開発されている。 例えば:

目標 「どんなサブ目標が {これ} に貢献するか?」

リスク 「 {これ} の原因は何か?」

有用 「 {これ} は有害な何を作るか?」

など

Southbeachは単一の「自動化された」方法論ではない。 どんな分野でも問題解決に成功するには深い経験を必要とする。 Southbeachはチームが、より方法論的で、より完全で、より目標指向であるように助けることができる。 その表記法は異なったバックグラウンドを持ったチームメンバーたちに容易に理解される。

 

12.  仕事を構造化する

Southbeachは、「問題」(有害なもの)と「解決策」(有用なもの)を記述するための言語である。 緑の箱が解決策を示す。 赤の箱が問題を示す。 修飾子が状況をさらにはっきりさせる。例えば:


・ 点線は「可能性」を意味する。例えば、われわれが必要とする解決策、生じるかもしれない問題、など。

・ 破線は「不十分」を意味する。例えば、部分的にしか働かない解決策、対処可能な問題、など。

・ (一つの箱全体に対する大きな) X 印が「歴史的」を意味する。例えば、もはや利用可能でなくなった解決策、すでに解決されたか消滅した問題。

・ など

したがってSouthbeachは、具体的な状況だけでなく、状況を解決するのに使おうとしている抽象的なプロセスをも記述できる。

下図のモデルを見られたい。 これが説明しているのは、潜在的な問題がいかにして現実の問題になるか、生じるかもしれないリスクとその根底にある根本原因を理解することがいかに必要であるか、である。 モデルは害を緩和する行動と介入の位置づけを示す。


チームがSouthbeachモデルを使うのは、特定の状況を示すだけでなく、その問題を解決するのに使う方法をも示すためである。 上に示したようなダイアグラムはさらに詳細を拡張することができる。 関係するステップを定義できる。生じる問題を明示することができる。 各ステップで適用できる諸方法を強調できる。

Southbeachの図の六角形は、サポートする「知識」を意味する。 ここではそれは一連の問題解決方法を示している。 根本原因分析 (RCA) では、原因のリンクをサポートする事実や理論を示すことができる。

 

13.  青 − 差をつける

典型的なプロジェクトでは、チームは彼らが取り組んでいる問題やチャレンジに対する焦点を作るためにSouthbeachを使う。 輻輳した要因や解決策のアイデアが見出されるにつれて、行動が計画され、その実現のために各人に割り当てられる。 Southbeachはそのような行動を表すために、青の箱を提供する。 「歴史的」の印(X) とともに、ダイアグラムを作り上げる順序が、分析、問題解決、解決策開発、および行動の積み上げを示す。問題 (とその解決) のライフサイクルを可視化できる。
この単純なアイデアがSouthbeachによる変化の管理の基礎である。

・ 問題 (複数可) を持って始める。

・ 解決策 (複数可) を加える。

・ 行動 (複数可) について決める。

・ 行動 (複数可) が完了するに応じて、どの問題 (複数可) が解消されたかを図に示す。

ここに、一つの有用なシステム(黄色で強調)を示している。 それはさまざまな問題(赤の箱)を含んでおり、システムのリスク(赤く塗った箱)に導く。 問題のうちの一つは微小である(破線表示)。 それを無視してもよいだろう。 一つは重要である(二重線表示)。 リスクを(赤く塗った箱で)示しており、それが問題の原因である可能性がある(?は疑問の余地を示す)。

このモデルをさらに発展させて、可能性のある解決策を加え、リスクを緩和するために、あるいは過剰な問題領域に取り組むために、われわれが実施する必要がある活動をも書き加えることができる。 つぎのモデルでは、元のモデル部分に影をつけ、そして、新しい箱を書き加えた。

実装したい解決策を決めたので、モデルはさらに進展する。 その次のモデルで、解決策2をきちんとできれば、その下流の問題は解決されるので、解決策3は必要ないと決定した。 また、微小な問題は無視できると判断した。 解決策1と解決策2はいまやしっかり計画された(それらはもはや「潜在的」ではない)。 さらに、リスク因子と深刻な問題との間の疑わしかったリンクを確認し (疑問のマークを消し) た。

そこでわれわれは、合意した解決策群を実装するために必要な行動(介入)を書き加えることができる。 これらを青の箱で表現した(有用とみなす)。 計画のこの段階で、われわれが提案した解決策1が一つの副次課題を含んでいることを見出した。 状況から生じるどんな「課題」も、長円の箱で記述される [訳注:原著の菱形の箱は誤り]。 したがって、われわれは解決策1を実現するプロジェクトの間、一つの取りくみ行動を加えた。


プロジェクトが進展するにつれて、Southbeachダイヤグラムをアップデートでき、これまでの進展と新しく生じてきた課題を示すことができる。 つぎのモデルでは、解決策2の実現が完了し、モデルの左側の諸問題を解消した。 われわれはリスクを緩和したが、解決策1の副次課題が当初の予想よりも深刻であることが分かった。 主要な行動を強調して示した(青の太線)。


モデルを展開してきたこのシーケンスは、Southbeachプロジェクトが最後までやり抜く一つのやり方を示している。 われわれは今まで「解決策」、「問題」、「リスク」といった抽象的な語を使ってきた。現実のプロジェクトからの具体的な語で置き換えると、このシーケンスはもっとよくわかるだろう。 それはこのようである。

プロジェクトの終点が何であるにせよ、プロジェクトには出発点がある。
Southbeachモデルはベストプラクティス、テンプレート、あるいは作業支援を記述するのに使うことができる。
下記の例は、一人のコンサルタントがSouthbeachワークショップをどのように始めたかを示している。
このモデルは参加者たちに、あらゆる大きな変革プロジェクトに関わるチャレンジを思い起こさせる。
モデルはモデリングのための出発点として有用なだけでなく、プロジェクトの努力が正しい立脚点に立って始まることを保証するのを助ける。

 


著者

イギリス。Howard Smith は同僚 Mark Burnett と共同で Southbeach表記法を開発した。

Howard は CSC European Group の Chief Technology Officerである。彼はCSCのOffice of innovationにフルタイムで勤務している。 彼はLeading Edge ForumのためのSenior Research Associateである。

Howard はビジネスプロセスマネジメントとイノベーション実践に関する多数の記事の著者である。彼の仕事は2冊の本を含んでいる。

Business Process Management: The Third Wave
IT Doesn’t Matter? Business Processes Do.

付録A: Southbeachのためのソフトウェア

本稿に記載の Southbeachダイアグラムは Southbeach Modeller を使って作成した。Southbeach Solutions Ltd. が開発した無償の製品である。

ソフトウェアに関する情報は下記参照。

http://www.southbeachinc.com

[訳注: このソフトウエアは、2013年4月に、 Southbeach Modeller 3.0 としてリリースされた。無償でダウンロード可能であり、作成されたモデル (多数の事例ライブラリあり、ユーザ作成のものも)を見ることができ、多数のドキュメントと内臓機能の詳細を知ることができる(ビューア機能、「Player Mode」)。ただし、モデルを作成するには、「Editor Mode」のライセンスの取得が必要である (68 英ポンド)。ソフトの概要は別ページに紹介した。] 

付録B:  参考文献

本稿はSouthbeachでできることのほんの表面をなぞっただけであり、典型的なプロジェクトで使われる技法の一部を紹介している。 さらに学ぶには、つぎのリソースが助けになるだろう。[訳注: これらのサイトには非常に豊富な情報が蓄積・公開されている。]

http://southbeach-examples.blogspot.com    

http://southbeach-creativity.blogspot.com    

http://southbeach-idioms.blogspot.com    

http://southbeach-screenshots.blogspot.com  

http://www.linkedin.com/groups?mostPopular=&gid=2340200  

http://trizmethods.blogspot.com   

付録C:  Southbeach表記法の仕様

Southbeach 表記法の仕様 (0.8版)は2008年5月にBPTrendsによって発表された。そのドキュメントは下記で入手できる。

http://tinyurl.com/3xfe6mf

更新した仕様 (Southbeach(0.9版)) を2011年にリリース予定である。

[訳注: ”The Elements of Southbeach Notation 0.9" by Howard Smith & Mark Burnett, BPTrends, Jun. 2011 ==> Sothbeach社の White Paper の欄 、BPTrends のページ (PDF 56頁)]

 

BPTrends Linkedin Discussion Group

われわれは最近、LinkedInでBPTrends Discussion Groupを作った。われわれのメンバー、読者、および友人たちがBPMに関連した様々な話題について自由にアイデアを交換できるようにするためである。 この論文について、あるいはあなたが興味を持っているBPM関連の話題について、新しい議論を始めたり、既存の議論に寄与したりするように、あなたにお願いしたい。 Linkedinに行って、BPTrends Discussion Groupに加入しよう。

 


 編集後記 (中川 徹、2013年 6月 7日)

このモデル化の方法は素晴らしいと思います。いろいろな場で、このようなモデルを作って、状況の理解を進め、建設的な合意が作れていくとよいと思います。そのためにも、このモデル化のツール(Southbeach Modeller) を使える人が多くいて、良いモデル表現を作り、人々に見せることができるとよいと考えます。

別ページに、「Southbeach フォーラム: Southbeach 表記法とモデリング: 紹介・情報交換・評価のページ」を作りました。今後それを親ページにして、いろいろな紹介をしていきます。

 
本ページの先頭 論文先頭

1. 赤と緑

2. やさしく学べる

3. ダイアグラムを超えて

4. ワークショップ

5. 適用事例

6. チームを方向付ける

7. 意見の相違

8. 前進

9. あなたの創造性

10. 矛盾

11.  始める

12. 構造化する 13.  青−行動 付録 原論文

Southbeach Modeller 紹介

Southbeach フォーラム 英文ページ

 

総合目次  新着情報 TRIZ紹介 参 考文献・関連文献 リンク集 ニュー ス・活動 ソ フトツール 論 文・技術報告集 教材・講義ノート フォー ラム Generla Index 
ホー ムページ 新 着情報 TRIZ 紹介 参 考文献・関連文献 リ ンク集 ニュー ス・活動 ソ フトツール 論文・技 術報告集 教材・講義 ノート フォー ラム Home Page

最終更新日 : 2013. 6. 9    連絡先: 中川 徹  nakagawa@ogu.ac.jp