|
|
『イノベーション能力成熟度モデル （Innovation Capability Maturity Model (ICMM)） 入門編』 第2章 イノベーション能力成熟度モデル（ICMM）の哲学 |
|
|
|
|
Press the 
button for going back to the English page.
編集ノート (中川 徹、2021年 2月 3日)
Darrelll Mann の本の第2章です。本ページの記述は第1章と同様で、詳細目次、導入のための簡単な解説、そして本文です。訳文中の、（ ）は著者の挿入句など、[ ]は訳者の補足です。
本章の詳細目次
第2章 イノベーション能力成熟度モデル（ICMM）の哲学
2.1 ソフトウエア開発の世界： 1980年代の状況とプロセス改善のための標準化
2.2 ソフトウエア開発分野での能力成熟度モデル（CMMI)
2.3 ソフトウェア開発の世界からイノベーションの世界へ： 新しいモデル
2.4 本書の構成： イノベーション能力成熟度モデル（ICMM)の5つのレベルと向上の「旅」
本章への導入 (中川 徹、2021. 2. 4)
著者はまず1980年代のソフトウエア開発の状況から話を始めます。それは彼自身がロールスロイスのジェットエンジン関連のソフト開発で苦労したからです（私も60年代後半から物理化学の実験解析用のソフト開発に苦労しましたので、良く分かります）。
そのソフト開発の分野で、90年代前半に、カーネギーメロン大学から、能力成熟度モデル（Capability Maturity Model （CMM）がだされ、ソフト業界の重要な指針（標準）になっていきました。そのモデルは、ソフト開発のプロセスを組織として管理していくやり方に段階的な発展を定式化しています。
このソフト開発分野のCMMは、本書のモデルの一つの先例（手本）となったのですが、イノベーションの分野にとっては、考え方として共通する部分と、異なる部分があることを著者は認識していきます。共通部分は、成功事例の普遍的モデルを創ろうとすること、組織を評価しようとすること、などです。異なるのは、イノベーションでは、技術者よりも役員室にメッセージを届ける必要があること、サイロ（縦割り・専門組織）を作ろうとするのでなく壊す（壁を無くす）必要があること、始めから終わりまでのビジネスとしての評価が重要であること、などです。
その新しい認識で、イノベーションの能力成熟度モデル（ICMM)が創られ、本書がまとめられたのです。ICMMの特徴として、主たる対象を組織のリーダー、経営幹部に向けていること、イノベーションを起すための組織のあり方・考え方として、5つのはっきり区別できる（区別するべき）段階があること、その段階を一つずつ上がっていく組織の「旅」が必要であること、などです。本書に付随した資料として「旅」のガイドを作っていると言います。[注： この、「旅」の本については、本ページの編集後記を参照ください。]
| 導入（中川） | 2.4 本書の構成 | 英文ページ |
原著第2章の和訳
第2章 イノベーション能力成熟度モデル（ICMM）の哲学
「いかなる心の単純さも、いかなる地位の曖昧さも、
私たちが信じているすべてのものを疑うという
普遍的な義務から逃れることはできない。」
W.K. Clifford
TRIZ問題解決法の主要な格言の一つは、本書ですでに使用した表現であり、深く掘り下げるにつれて疑いなく再び使用されるでしょう。「誰かが、どこかで、すでにあなたの問題を解決している。」それで、私たちが考えたのは、イノベーションプロジェクトが98％の確率で失敗しているのなら、イノベーションの世界は疑いもなく問題を持っている、ということです。これは私たちみんなが推測していることを示すかなり良い兆候です。「イノベーションはアート（技、芸術）であって、科学ではない」と。では、他に誰がそのような問題をもっていたでしょうか？
2.1 ソフトウエア開発の世界： 1980年代の状況とプロセス改善のための標準化
私が研究開発の世界で仕事を始めたのは、ジェットエンジンの制御システムを開発するコンピュータープログラマーとしてでした。1981年のことです。すべての優れたエンジニアたちと同様に、Fortran IVを使用し、また、昔ながらのエンジニアと同様に、最初に始めたときは、パンチカードを使用して貴重なプログラムコードを、部屋サイズのIBMメインフレームコンピューター（そのメモリは500KB）に持って行っていました。
言うまでもなく、バグチェッカーや事前に記述された（プログラム）コードのライブラリがない世界では、キーボードに触れる前に、自分のコードについてよく考える時間をもつのが、良い考えであることがすぐにわかりました。カードデックを落としてしまったり、重要な（計算）ジョブを一晩がかりで走らせて、翌朝戻ってきた結果を見て、自分のコードの論理に一つのエラーがあったことを発見したりするのは、もっとよく考えなくてはいけないことを学ぶ随分良い（痛い）やり方でした。
ソフトウェアライティングの世界はまだ始まったばかり（幼児期）でした。コーディングは間違いなくアートでした。アートの世界は真夜中にピザを食らうオタクたちが主に住んでいるところですが。ソフトウェア業界は（まだそうは呼べない段階でしたが）、失敗に満ちた世界でもありました。マネージャーやリーダーたちは、以前には人々がやっていた高価な仕事を、コンピューターにやらせることが大規模に盛んになる可能性を、容易に見ることができましたから、多くのプロジェクトが委託されました。悲しいかな、それらが非常に高い割合で失敗に終わりました。それらのいくつかは非常に恥ずかしい、公的支出のプロジェクトでした。こんなままで長く続くことは到底許されませんでした。
そして案の定（それ以前の幼児期産業と同様に）、1993年に、カーネギーメロン大学がちょうどいい時期にやって来ました。彼らのカーネギーメロン・モデル (後により一般的な名前で呼ばれ、「能力成熟度モデル（Capability Maturity Model （CMM）)」）が登場したのです。政府のインフラストラクチャーにおけるいくつかの屈辱的な失敗の後で、モデルは元々、政府請負業者の契約ソフトウェアプロジェクトを実施するプロセスの能力を客観的に評価するためのツールとして、開発されました。CMMは、プロセス成熟度のフレームワークに基づくもので、最初に記述されたのは『Managing the Software Process』 （Watts Humphrey、1989）の本です。その後、1993年に報告書（Ref. 1）として出版され、1995年に同じ著者たちによる本として出版されました。
2.2 ソフトウエア開発分野での能力成熟度モデル（CMMI)
CMMは初めて、コーディングの世界における「ベストプラクティス（成功事例）」の諸要素をまとめました。ソフトウェアエンジニアたちは、新しい要求仕様が持ち込まれるたびに「車輪を再発明する」ことを続ける必要がもはやなくなりました。元々の先駆者たちは、「自分たちの仕事の創造的な部分が奪われてしまう」という考えにしばしば恐怖を感じました（その考えを後のために覚えておいてください！）が、決定するのは彼らではありませんでした。マネージャーたちが決定しました。マネージャーたちの目には、車輪の再発明をしないことは、計り知れないオタクたちに壁を越えて仕様を投げるよりも、はるかにリスクの少ない提案のように、思われました。
CMMへの支持が急速に拡大し、それに伴い、トレーニングプログラムが必要になり、その後間もなく、産業界・学界・企業のパネルによって定義された評価基準に照らして、組織を認証する必要が生じました。2002年までに、組織は再び自らを再発明する必要性を感じ、CMMIが正式に世界に紹介されました。カーネギーメロン大学がいまなお所有する「 能力成熟度モデル統合（Capability Maturity Model Integration (CMMI))」は、プロセス改善のアプローチであり、その目標は、組織のパフォーマンス向上を支援することで、プロジェクト、部門、あるいは組織全体のプロセス改善を導くために使うことを意図しています。[同大学の] Software Engineering Instituteによると、CMMIは、「従来は別々であった組織機能を統合し、プロセス改善の目標と優先順位を設定し、品質プロセスのガイダンスを提供し、現行プロセスを評価するための基準点を提供する」のに役立ちます。
図2.1に示されているように、CMMIモデルは複数の異なる能力レベルで構成されています。さらに深く掘り下げると、一組の明確な評価基準があり、各レベルがその前のレベルと比較して何が違うかが定義されていることが、わかります。本質的に、そして実際に、レベルの向上が、明確で世界的に認められた一連の能力開発プロトコルと、認証プロセスを、組織に提供するように設計されました。その認証プロセスでは、組織が特定の基準に合格すると、その組織は世界（より具体的には、意図しているお客さま）に向かって、あるレベルの能力を獲得したと発表できるのです。
図2.1： CMMI（能力成熟度モデル統合）の5つの主要レベル
一見すると、CMMIは、イノベーションの世界にとって、完璧なアナロジーのように見えました。確かに、結果の観点からは、ITサービス業界とその周辺の失敗のレベルは、（まだ高いですが、それでも）1980年代後半の数分の1で進行しています。
2.3 ソフトウェア開発の世界からイノベーションの世界へ： 新しいモデル
もちろん、TRIZが私たちに教えているように、いつも多くの「Yes, But ...」の場面があり、それが一つの既存の解決策を、あるところから別のところに単純に移行することを妨げます。私たちはすぐに、[私たちの] イノベーションの世界と、[ここでの] ソフトウェア開発の世界との間の、微妙ではあるがしばしば深刻な差異を見出し始めました。
1） ソフトウェア開発は、より大きなイノベーションの世界の、ほんの一部分であることは明らかです。ある種のソフトウェアを作成することは、イノベーションの問題または機会に対するソリューションの一部を形成する可能性がありますが、イノベーションの問題は、基本的に、一つのソリューションのコーディング方法よりも、高いレベルの質問を形成します。この階層性が重要である理由は、（これまでのところ）CMMIが「プロセス改善」哲学の観点から強く運用されているためです。したがって、逆説的に、それはイノベーションの世界が180度反対していることのいくつかを、支持しています。（ここでは「これまでのところ」と言います。なぜなら、それほど遠くない将来に、CMMIは第6レベルを進化させるだろうと、私たちが推測しているからです。これは、イノベーションの世界の「直感に反する」要素のいくつかを、ITの世界に持ち込むものです。）
2） ソフトウェアプロジェクトが失敗する理由を調べると、前章でイノベーションについて説明したもの [図1.1] とは、非常に異なる分析結果が明らかになります。「市場へのルート」と「生産手段」はITの世界ではほとんど意味のない [問題にならない] 概念であり、「より理想的な製品またはサービス」も似たようなもの [あまり重要でない] です。ソフトウェア・アーキテクト（設計者）は、「問題を論理的に解決できさえすれば、いつでもコード化できる」と、よく言っています。つまり、今日のITの世界で最大の失敗モードは、「市場の需要」あるいは「適切な問題を解決することに失敗する」ことです。これは、ITとイノベーションとの、異なる階層での役割と、符合することです。…
3）…それは私たちをサイロの世界 [縦割り組織、たこつぼ] へと導きます。彼らがそれを好むかどうかにかかわらず（大多数はおそらく好むでしょう！）、ITの世界はまだ他のビジネスとは非常にかけ離れた世界です。コーダーたちはコードを書き、マネージャーたちは管理をする。そしてその二者は決して会うことがありません。ITの世界は今や（CMMIレベル5の）専門家たちでいっぱいになっているかもしれませんが、それでもなお非常に多くのITプロジェクトが失敗に終わるのを防ぐことはできていません。ITの世界は独自のサイロを創り出し、そうすることで失敗の種をまきました。
繰り返しになりますが、KISS [「単純化して考えろ、馬鹿！」] は機能しないことが示されています。すべてのIT担当者たちを一つの別の建物（または、多くの場合、一つの別の国）に配置するのは簡単なことですが、イノベーションの観点からは、ほとんどの場合、間違ったことです。「すべての錯綜した問題には、ひとつの単純な間違った答えがある」とすでに引用しました。皮肉なことに、ITインフラストラクチャの問題ほど錯綜した (complex) 問題はありません。
CMMIとイノベーションでの対応モデルとの、大きな違いの第3は、私たちのイノベーションの世界では、サイロを維持するのではなく、継続的に破壊に努めなければならないことです。これは究極的に、イノベーションは組織のCEOの責任になる必要があることを意味します。なぜなら、彼または彼女が、サイロを超越する、あるいは役に立たないサイロの除去を命令する権限を持つ、唯一の人物だからです。
4） CMMIは、要するに、「標準」を形式化するものです。「標準」は、イノベーションのアンチテーゼ （反対概念）として（私たちが得ることができる中で）最も近い言葉です。CMMIはルールたちを形式化し、イノベーションはルールたちを壊します。この二つの架け橋であるのは、そして私たちがなおCMMIを類比物として使用できる理由は、ICMM（イノベーション能力成熟度モデル）がメタレベルで動作する必要があるためです。ICMMは、「ルールを正常に破るためのルール」を形式化します。
5） ソフトウェア業界は現在X百万人を雇用しており、増加しつつあります。「イノベーションの世界」で働いているのを見ることができる人々よりも、ほとんど一桁多い人々です。一部のビジネスリーダーたちは、組織内で「イノベーション文化」を求めており、そこでは誰もが斬新なソリューションを探しており、一般に「革新的」に（ICMMレベル5でのみ完全に消滅する神話）考えている、[とイメージされています]。しかし実際には、もしすべての人がいつもこのように考えていると、実行する必要のある日常的な作業は、まったく何も実行されないでしょう。私たちはすべての人々が革新的な能力を持つことを望むかもしれませんが、たいていの時間には彼らが彼らの「実際の仕事」をこなしてくれることを望むのです。
言い換えれば、イノベーションはプロセスであり、結果であって、フルタイムの仕事ではありません。少なくとも大多数の人々にとってはそうです。世界の「イノベーション企業」の最も先進的な企業では、イノベーションスキルを適切に研ぎ澄まし、あらゆるタスクにすぐに向けられるようにするには、専任のイノベーション専門家の小さな集団を維持することが、賢明であることを学びました。確かに、私たちはすでにそのような人々のトレーニングとコーチングにかなりの時間を費やしています。しかし、（このテーマに言及しているそもそもの理由はここにありますが）現実的には、地球上のIT専門家の数とイノベーション専門家の数の間には、常に1桁の違いがあるでしょう。それが意味するのは、[ソフトウエア開発用の] CMMIは大きく考える必要がありますが、[イノベーション開発用の] ICMMは相対的にずっと小さく考える必要があります。
そこで、まとめますと、（私たちの）ICMM（イノベーション能力成熟度モデル)は、（IT分野用の）CMMI(能力成熟度モデル統合）と、同じ面と、違う面があります。
ICMMがCMMIと同じことをするのは、次の諸点です：
ベストプラクティス（成功事例）の普遍的モデルを創り出す
組織を評価し、（適切なところでは）組織を認証する
教材を創り出しし、教育し、教師を育成して、「ベストプラクティス」が普遍的に観察可能で広く理解される概念になるようにする
イノベーション専門家たちのインフラストラクチャを創り出す
イノベーション専門家たちのピアグループ・ネットワークのインフラストラクチャを創り出す
ICMMがCMMIと異なるのは以下の諸点です：
イノベーターがメッセージを役員室に届けるのを支援する必要があり、その結果、多くの内容と文脈が経営幹部用に偏っています。
それは、サイロ [縦割り組織、たこつぼ] を破壊するもので、存続せるものではないことが必要です
- 初めから終わりまでの成功の評価を基本的指針としており、ビジネスの全体的な業績の向上に重点を置いています。
（注： CMMIレベル5の認定ソフトウェアエンジニアを擁する組織は、そうでない組織よりも、収益性、持続可能性、投資収益率の点で優れた実績を持つという証拠がいくつかありますが、そこに何らかの因果関係を確認する証拠はありません。一方 ICMMおよびイノベーションでは、能力をCEOダッシュボードのすべての重要な指標に直接かつ因果的に結び付ける必要があります。）
- 比較的少数の（イノベーション）専門家が利用する価値の高いサービスに焦点を当てる必要があります。
2.4 本書の構成： イノベーション能力成熟度モデル（ICMM)の5つのレベルと向上の「旅」
これにより、本書の形式と構造がもたらされました。
何よりもまず、ICMM（イノベーション能力成熟度モデル）とは何か、そしてICMMのさまざまなレベルの能力がどのようなものか、について紹介し、全体像を示すことを意図しています。
したがって、これは主に組織のリーダー、特に経営幹部の人たちを対象とした本です。これは、本書を通じて提案されるメッセージが、組織内で目標を設定する人たちに宛てられていることを意味します。それは、すべての実現を担当する実行者のチームに引き渡す前に、進むべき方向を設定する第一義的な責任を持つ人々です。
それは、本書が実行者向けではないということではありません。彼らも自分たちがしていることを、なぜするのかを十分理解していることが、（必須ではないまでも）重要です。（そして、ICMMレベル1 [の組織] では、実行者はおそらく、目標を決める [経営幹部の] 人たちに、本書を読むように説得することすらできないことに気付くでしょう。…この点は第7章で説明しましょう。）
言い換えれば本書は、イノベーションの能力と、そのような能力を私たちがいま住んでいるこの世界で構築する必要性についての、全体的な哲学（恐ろしい言葉ですが）に関するものです。
本書は [いわば「旅」の物語の] 場面 [状況] を説明するものであり、実際のロードマップ（地図）上での [「旅」] の実行については、本書に付属する（予定の）一連の本で説明します。本書は、あなたの組織がICMMのスペクトル上でどの位置にあるのかを、あなたが理解するのに役立つでしょう。付属（予定）の一連の本は、あなたがどのようにして一つのレベルから次のレベルへと、[ICMMの向上の] 「旅」を成功させていけばよいかを、示すでしょう。
私たちはこれまでに、[組織の] イノベーション能力は、明確に区別される5つのレベルがあることを、明らかにしてきました。ですから、私たちの「旅」の本はつぎの4冊がある（予定です）。
1） レベル1からレベル2へ
2） レベル2からレベル3 へ
3） レベル3からレベル4 へ
4） レベル4からレベル5 へ私たちはこれらの「旅」を、意図して物理的に別々のドキュメントに分割して、各 [組織の] チームが手もとの仕事に最も集中できるようにしました。理論的には、初期段階の「旅」は比較的速やかに完了できますが、それでも、レベル1からレベル2への最初のジャンプでさえ、通常、そこで起こることは、数日とか数週間ではなく、何か月の単位で測る期間を要することです。
これらのすべての本の背後にある考え方は、それらが教育プログラムと並行して機能するということです。本書は、リーダーたちのためのカリキュラムの基礎を形成します。関連する「旅」の本は、実行者たちに、彼らのチームと彼らの組織を、あるレベルから次のレベルへ効率的かつ効果的に到達させるための、最善の方法を示すカリキュラムの基礎を形成します。
ICMM構造全体は、もう一つの諸矛盾の大きなセットをも解決しようとしました。すなわち、同一構造で、2人だけの小企業の責任者にも、多国籍企業のCEOにも、また、政府の中間管理職の人たちにも、関係があるようにするには、どうすればよいのか？この挑戦は確かに解決するのが難しいものでした。あなたには、ときおり、書かれていることが自分とは別の世界のことで、自分にはすぐには関係しないと思われることがあるのを、お詫びして、許容いただきたいと思います（もしあなたが、書かれていることの意味を自分の世界に当てはめて捉えなおされれば、実は自分にも関係していることだと、わかられるだろうと、私たちは思っています）。[その点を留保いただけば、] 私たちは私たちが設定したことをほぼ達成できたと思っています。それは、「普遍的なもの」と大局的な見方（全体像）に焦点を当てたことの一つの利点です。究極的に、それは私たち全員に関連するすべての問題を解明することでした。
そしてもしあなたがすでに、「イノベーション」という言葉が、自分に関連しているのか、いないのか？と悩んでいるのなら、その言葉を「チェンジ（変化・変革）」という語に置き換えてみてください。イノベーションの定義を覚えておいてください：「成功したステップチェンジ（階段状の変化）」。誰もがイノベーションビジネスに携わっているわけではありません。私たちはみんな、チェンジビジネスに携わっています。
これで全体像の概要がわかりました。いまや私たちは、イノベーションの不可解な世界をもう少し深く掘り下げる準備が整いました。まず [次章で]、いわゆるイノベーションの「普遍的なもの」のいくつかを見て行きましょう。
編集後記 (中川 徹、2021. 2. 4)
本書には、いくつもの箇所で、ICMMのレベルを一段ずつ上がっていくためのプロセスについて、「英雄の旅（Hero's Journery)」と呼んで、言及しています。きっとそれは実際に計画され、内部資料として、あるいはコンサルティングの資料として作成・蓄積されてきているのだと思いますが、いままで出版されてきませんでした。
昨年（2020年、月不詳）、つぎのものが出版されました。
”The Hero's (Start-up) Journey", Darrell Mann, FRI Press （2020）、
Growing SMEs & micro-businesses from start to sustainable success.
『英雄の旅』シリーズの最初で、レベル0 から レベル１ への「旅」にあたるものとのことです。読み始めています。
| 導入（中川） | 2.4 本書の構成 | 英文ページ |
最終更新日 : 2021. 1.23 連絡先： 中川 徹 nakagawa@ogu.ac.jp
Darrell Mann : ICMM Book 2. ICMMの哲学
