こんにちは、大石です。
先日、某所にてソフトウェアエンジニアの方向けに
「どうやってイノベーションを起こすのか？」
というテーマでの講演を依頼され、私の考えをお話する機会がありました。
私たちもそうですが、イノベーションに対する渇望というか、現状を打破するパワーとしてのイノベーションに期待する向きというものは非常に強くなっていると思います。特に米国ではAppleをはじめAmazon, facebookなどイノベーションを起こし続けている企業がまさにITの世界を席巻しつつあり、そうしたパワーに対する対抗策としても「日本でもイノベーションを！」という期待が高まるのは至極当然のことに思えます。
実は当社も「ソフトウェアによるイノベーション」を目指してCloudworksをリリースしたワケですが、途中で誤りに気付いて現在の事業にピボットしたという経緯があります（スライドのP16-34）。私たちがイノベーティブかどうかは自分たちで評価できませんが、少なくても「クラウド × ソフトウェア ＝ イノベーション」を目指した一人として、自分たちの考えやチャレンジを明らかにすることに一定の意味があると思い、このようなお話をさせて頂きました。
イノベーション ≠ インベンション（発明）
イノベーションとは、社会に大きな変革をもたらすことであり、実行の問題だということ。つまり、発明などと違い特別な才能などが不要だということを意味しています。
タイミング
イノベーションの種は、それだけを見ても「それがイノベーションを引き起こすものかどうか」を予見することは難しいと思います。それまで実験台に蓄積されたパワーに応じて、大きく崩れて突如市場に現れることもあれば失敗となって実験台に積み重なるだけのこともある（スライドP64-69）。つまりイノベーションを起こそうと思うのであれば、「打率を上げるのでは無く、多くの打席に立たなくてはいけない」ということが言えると思います。
制約を乗り越える力
イノベーションは発明ではないので、既に存在する制約からスタートするのが手っ取り早いと思います。登山家には山が必要なように、組織をリードする人がイノベーションを起こそうと思ったら、メンバーに登るべき山（制約・ゴール）を指し示す必要があります。そしてリーダーには「登る山は指し示す。登るルートや登り方は任せる」というアプローチが必要になるのだと思います。
具体例として、Amazonが「組織を縦割りにして会話を断絶させるという制約を課すことでイノベーションを起こしたケース」を採り上げました（P75-78）
私たちも「クラウドというアイディアを世の中に拡げる」というチャレンジをしている最中です。そして過去のいろいろなチャレンジが、実験台に静かに積み重なり、去年になって一気に市場に流れ出したという感触を得ています。
私たちの経験が、イノベーションを起こそうとお考えのみなさんの一助になれば幸いです！
