#はじめに
ジェフリー・ムーアの『キャズム』を読んで、
これって、プロセス改善にまんま使えるじゃんと思い筆（キーボード）をとりました。
キャズムとは
普及のタイミングと層
巷間、新製品や新技術の普及は、
イノベーター → アリーアドプター → アーリーマジョリティ → ・・・・
という風にすすんで行くと言われています。（cf.イノベータ理論）
次の層への普及開始がうまく進まない = キャズム
しかしながら、一つ手前の層の普及がすんだら、自動的に次の層への普及がすすむかというと、
そんなことはなく、各層の普及の間には落とし穴があります。
これを、キャズム（日本語で地面の亀裂的な意味合いです）と言います。
キャズムが一番大きいのが・・・
このキャズムが一番大きいのがアーリーアダプターとアーリーマジョリティーとの間であると書かれています。
「プロセス改善を提案し、一定の効果を得て、賛同者も集めたのに、なぜか全社的に広がっていかない」
そんな経験をお持ちではないでしょうか？
そこには、いろんな理由があるでしょうが、
事象的には「キャズムを超えられなかった」と表現できます。
ではどすれば良いのでしょうか？
キャズムを超えるために
ジェフリームーアは『キャズム』で書かれていた（自分が読み取った）処方箋は以下の通りです。
- ニッチ市場に絞り込め
- 解決されるべき問題の経済価値が高いものを選べ
- ホールプロダクトを提供せよ
以上の処方箋にどのような効能があるのでしょうか？
1. ニッチ市場に絞り込め
イノベーターは、ほとんどマニア的な存在で、常に、なんか新しいことないかなとアンテナを張っています。
この層は、ほっといていても新しい機能・技術を探し出し、勝手に検証し、採用していきます。
この層への普及にはほとんど情報提供は必要ありません。
なにができるか、何がすごいかさえ伝えれば、勝手に試して使えるところ、使えないところを選別し、
あるいは魔改造することで採用していきます。
アーリーアドプターは、自分たちの問題を解決してくれる新しい機能・技術を自ら積極的に収集しています。
この層への普及にも不十分な情報提供で問題ありません。
この人たちは、機能・技術に多少の欠陥、不十分なところがあっても、
自分たちで試行錯誤して、なんとか補い、あるいは諦めて使ってくれます。
アーリーマジョリティは、問題解決を欲していますが、
新しい機能・技術の採用に関しては、メリット・デメリットをしっかり判断します。
そして、よくわからないものには手を出しません。
また、イノベーター、アーリーアドプターに比べてそのボリュームは膨大です。
イノベーター・アーリアドプターには、不十分な説明、アピールでも普及が進みます。
ボリュームも小さいので人的に細かい対応も可能です。
しかし、アーリーマジョリティの一人一人に細かい対応はできません。
従って、来たるべきアーリーマジョリティー攻略（全体普及への天王山）のためにも
ニッチ市場に絞り込む必要があります。
プロセス改善で言えばどうでしょうか？
例えば、可読性やテスタビリティ向上のために、コーディング規約50箇条を整備したとします。
一部のレベルの高いアーキテクト層は採用し、協力してくれるでしょう
品質に高い問題意識をもつPLやリードプログラマも採用してくれるかもしれません。
しかし、一般プログラマなどはどうでしょうか？
「それやると何が良くなるの？」「納期が厳しいのに守ってられない」
なんて言われて普及しないのではないでしょうか？
しかし
「jQuryでのイベントリスナは、.Click(function(){}); ではなく、
.on('click',function(){});にしようぜ」
ならどうでしょうか？
対象者は、フロントエンドエンジニアに限られ、またその有用性についても、
「複数イベントを同時定義可能」「後から追加されたDomにも有効」と割と簡単に伝えられます。
これなら、キャズムを超えて、全社ルールにできそうな気がします。
###2. 解決されるべき問題の経済価値が高いものを選べ
イノベーター、アーリーアドプターは自ら情報収集をしてくれます。
普及させたい側としてはコアとなるコンセプト（何ができるか、何の価値があるのか）を伝えるだけでも、
十分普及させることが可能です。
しかし、アーリーマジョリティーは人数が多く、または検討する情報が非常に大きいため、
普及させたい側の活動だけでは手が回りません。
では、普及させたい側以外に、だれの活動が必要でしょうか？
この時、アーリーマジョリティー自身の口コミ活動が非常に重要になります。
解決したいの課題があって、解決できそうな製品や技術があるのに、
やたらめったら、導入事例を求める人って周りにいませんか？
それ、アーリーマジョリティです。
こういう人たちに採用を決断させるためには、導入事例というか成功事例が必要です。
それも、周りに自慢したくなる程度の華々しい成功事例が必要です。
従って、ビジネスインパクトの低い製品・技術では、着実な効果があっとしても、キャズムを超えづらいです。
年間1000円の節電効果のある製品が500円で売っていても、多分普及はしないです。
プロセス改善でも、直近で起きた細々した問題に対する改善は確かに必要ですが、
それだけやっていても、周りに波及しませんし、評価も上がりません。
自分たちのところで見つけた細々した改善は、普及に値するかどうかを判断しないと、
普及を担う人が消耗するだけとなりかねません。
###3.ホールプロダクトを提供せよ
ホールプロダクトとは、購入者が（暗黙的にも）期待している機能を備えている製品のことです。
ホールプロダクトモデルという考え方では、機能の充実度に応じて、
コアプロダクト ＞ 期待プロダクト ＞ 拡張プロダクト ＞ 理想プロダクト
と呼びます。
スマホで言えば、iOSが動く、AndroidOSが動くというのがコアプロダクトで、
動作がヌルサクだとか、待ち受けが長いとか、無くしてもどこにあるか見つけやすいとかが、
期待・拡張・理想プロダクトということになります。
イノベーター、アーリーアドプターは、コアプロダクトレベルでも採用してくれます。
不十分なところは、自分たちでなんとかします。
待ち受けが短いなら重いバッテリーを持ち歩き、動作が重ければ、定期的に使ってないアプリを掃除します。
しかし、アーリーマジョリティーはそんなことはしてくれません。
コアとなる機能ではないけど、当然付いてるでしょ？とみんなが思うような機能、
もしくは、これが付いていると目的が完全に満たせるんだけど、
と思うような機能が付いていないと、採用しません。
プロセス改善で言い換えるとどうでしょうか？
「Jenkinsってこんなにすごいんだぜ！Jenkins導入しようぜ」と言っただけでは、
導入してくれるのはイノベーター、アーリーアドプターだけです。
アーリーマジョリティーがJenkinsを導入しようと思えるのは、
- すでに構築済のJenkinsがあり、
- ある程度設定を変更するだけで自分たちに適用できるプロジェクトテンプレートがあり
- トラブルシューティングマニュアルが用意されている
そんなタイミングではないでしょうか？
キャズムを乗り越え、普及を拡大させるには、
そういった導入の手間・不安を解消させてあげる必要があるのではないでしょうか？
「なんであいつらは乗ってこないんだ。わからず屋め！」という軽蔑ではなく、
そういった人もいると認識して、必要な手を打つことなのではないでしょうか？
まとめ（個人的な仮説です）
- 新製品・新技術の普及戦略の考え方は、プロセス改善の普及に通ずるものがある
- 範囲を絞っていったほうがよい
- 改善効果の高いところを狙っていったほうが、口コミを呼び、普及が容易
逆に、明らかに改善できることでも、効果が小さければ、無理に普及活動しない方がよい - 協力者と賛同者と追随者とで、異なる対応をしよう
追随者には、導入のハードルとなりそうなところを解消する動きが必要