コンセプチュアル・マネジメント

バックナンバー　https://mat.lekumo.biz/ppf/cat9922971/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

◆組織は戦略に従う

戦略と組織の間には、

「組織は戦略に従う。そして、戦略は組織に従う。」

という関係があると言われる。アルフレッド・チャンドラーが1962年に発表した「Strategy and Structure」において指摘した名言である。（※１）

※１　邦訳「組織は戦略に従う」、ダイヤモンド社（2004）
http://www.amazon.co.jp/exec/obidos/ASIN/4478340234/opc-22/ref=nosim

これは現在も事業部制において組織ガバナンスの基本になっている。

バックナンバー　https://mat.lekumo.biz/ppf/cat9922971/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

◆改めて、iPhoneはなぜ成功したのか

iPhoneもそろそろ衰退期に入ろうとしているが、スティーブ・ジョブズが開発したiPhoneを改めて見てみると、やはり最大の特徴は顧客の本質的なニーズを把握していたことに尽きるのではないかと思う。

当時、フューチャーフォン（ガラケー）は成熟期の製品だった。そのため、メーカーは目の前の顧客ニーズに応えることに最大の価値をおいていた。この５～６年くらい、ガラケーの機能はほとんど変わっていない。スマートフォンに投資し、ガラケーにはほとんど投資しなくなったからだが、それでも市場はしっかりと生きている。

そして、機能ということでいえば、スマートフォンが生まれる以前の機能からほとんど変わってないのではないかと思う。つまり、フューチャーフォンにはニーズがあり、そのニーズの本質に到達したくらいのタイミングで、iPhoneが登場し、スマートフォンという新しい製品コンセプトがが生まれたといえる。

バックナンバー　https://mat.lekumo.biz/ppf/cat9922971/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━`

◆ハイプ・サイクルとは

ハイプ・サイクル（hype cycle）は、２００８年にガートナー社のアナリストであるジャッキー・フェンとマーク・ラスキノが著書「Mastering the Hype Cycle: How to Adopt the Right Innovation at the Right Time」で提唱した特定の技術の成熟度、採用度、社会への適用度を示すサイクルである。目的は、誇大な宣伝（ハイプ）に踊らされることのない新技術採用を行うことだ。

残念ながらこの書籍は日本語に翻訳されていないので、日本ではあまり知られていないが、社会への適用の方法やタイミングで失敗しているイノベーションは多く、その意味で重要な概念である。

バックナンバー　https://mat.lekumo.biz/ppf/cat9922971/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━`

◆アルボムッレ・スマナサーラさんの指摘

先日、スリランカ上座仏教(テーラワーダ仏教)長老であるアルボムッレ・スマナサーラさんの「「忙しい」を捨てる 時間にとらわれない生き方」という本を読んでいたら、次のような趣旨の記述があり、なるほどと思った。

技術の分野は日進月歩なので、保守的ではなく、革新的でなくてはならない。日本人は本来手先が器用で、技術立国として確固たる地位を築いてきたが、今は、韓国や中国に負けている分野が目につく。これは日本人が「現状維持」を望む「保守主義者」になっているからだ。

さらに、日本人は長時間労働をしていることに触れ、その原因として

日本社会は保守主義的で自分の頭を使って創造的にアイデアを生み出そうとする人たちを抑圧するので、本来の生産性とは関係なく、長時間労働になってしまう

と指摘する。

バックナンバー　https://mat.lekumo.biz/ppf/cat9922971/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

◆なぜ、技術も美的センスもある日本人がiPhoneを作れなかったか

先日のダイヤモンド・オンラインにコンサルタントの佐藤智恵さんが、ハーバードビジネススクールのデビッド・モス教授にインタビューした記事が掲載されていた。

その中で、モス教授はイノベーションは「世界では、iPhoneのように技術と美的センスを組み合わせた製品は高く評価される。日本人には技術も美的センスもあるにも関わらず、活用できていないため、iPhoneが創れなかった」といった趣旨のことを言われていた。

今回のテーマはこの問題について考えてみたい。

バックナンバー　https://mat.lekumo.biz/ppf/cat9922971/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

◆発明とイノベーション

ワイヤードのウェブサイトにＩＴ業界の「スーパー・パパ」の異名をとるビル・ウォーカーの

「イノベーション」は「発明」ではない──飛躍を可能にする組織とは「

という記事が掲載されていた。この記事によると

発明は何か新しいものをつくり出すことだが、イノベーションはアイデアや手法の「使い方」に関する概念を提供するものだ

という違いがあるそうだ。さらに、発明はたいてい何らかの「もの」だが、イノベーションはふつう、行動や関わり方に変化を生じさせる発明を指すという。

発明それ自体がイノベーションとして成功することはめったにない。イノベーションは、（複数の）発明に基づいた既存のプロセスや使い方、または機能を、より良く進
化させたものである。つまり、発明から進化が必要なのだ。

バックナンバー　https://mat.lekumo.biz/ppf/cat9922971/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

◆イノベーションの抱えるコンフリクト

前回、イノベーションにおける組織の役割を概観したが、今回はもう少し深く考えてみたい。

イノベーションの難しさの本質は組織活動としての２つのコンフリクトにある。一つはよくいわれる不確実性があることだ。うまく行くとは限らない、思った通りに進むとは限らないことをやらなくてはならないというコンフリクトがある。もう一つは、不確実性があるにも関わらず、そこに人や金というリソースを投入しなくてはならない。つまり、二重のコンフリクトがあるわけだ。

日本企業ではまだまだ、イノベーションは個人が起こすものだと考えているところが多いと言われるが、その原因の一つがリソースを投入したくないところにあることは明らかだろう。言い換えるとイノベーションの本質としてこのようなうコンフリクトがあるといってもよい。

さらに悪いことには、既存の事業が強固であればあるほど、この傾向は強くなり、マネジャーにとってもイノベーターにとっても大きな問題になる。この問題に正面から取り組まない限り、イノベーションがどんどん起こる組織というのは考えにくい。

バックナンバー　https://mat.lekumo.biz/ppf/cat9922971/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

◆iPhoneは組織の成果！？

日本でもだいぶイノベーションは組織の問題だという認識がされるようになってきた。以前のように、放っておけば、やりたい人がやってくれるという認識から脱しつつあるのは進歩である。では、組織は何をすべきなのだろうか。今回はこの問題について考えてみたい。

日本ではまだ出版されていないが、今年、ジョブズの新しい伝記「Becoming Steve Jobs」が出版された。この本は、ジョブズの伝説的なイメージを変えるものとして話題になっている。その中の一つにiPhoneを作ったときの話が出てくる。iPhoneを市場に投入したとき、ジョブズは独立系の開発業者がiPhone向けのソフトウェアを作ることを禁止しようとした。これに対して、経営チームはジョブズに考えを改めるように説得した。

結果はご存じのとおり、さまざまな業者がアプリ開発に参入し、卓越したアプリが登場してきたことが、iPhoneの成功要因の一つになった。実は、ジョブズの態度は、Macintoshを市場に投入したときと同じものだった。３０年経っても考えが変わっていないのは立派だが、競争初期のジョブズの判断が今のWindowsPCとのシェアの差になっているといっても過言ではないだろう。そう考えると、同じ過ちを繰り返すところだったが、逆にいえば、iPhoneはジョブズ一人（や開発エンジニア）の成果ではなく、組織としての成果だといえる。

バックナンバー　https://mat.lekumo.biz/ppf/cat9922971/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

◆Whatから始めるプロジェクト

製品を開発するときには、Whatから始めることが多い。プロジェクトマネジメントの考え方でも、まずはWhat、そこにHow、How muchなどいろいろな条件を決めてプロジェクトを進めていくことになっている。また、背景情報としてWhyも考えておく。

しかしイノベーションではこの図式はとらない方がいい。特に、大きなイノベーションを起こしたい場合はそうだ。何から決めるかというとWhyである。

バックナンバー　https://mat.lekumo.biz/ppf/cat9922971/━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

◆技術統合における事例

ずいぶん、古い本の話で恐縮だが、ハーバードビジネススクールのマルコ・イアンシティ教授が「技術統合―理論・経営・問題解決」（NTT出版、2000）の中で、技術統合の必要性を示す例として興味深い事例を挙げているので紹介しよう。

ＳＧＩのレゴ・システム（グラフィック・ワークステーション）の開発プロジェクトで発生したＡＳＩＣのバグ（予想外の処理遅れ）によりシステムのハングが起こるという問題の対処に関する事例だ。

最初の段階では、ＡＳＩＣの問題だということで、ハードウエア設計チームが独断で判断し、問題源のある特定領域での解決を図ろうとし、４週間の時間と２０万ドルの費用をかけて、チップの再設計を行った。ところが再設計したチップがまた新たな問題を引き起こした。デスマーチだ。

それで問題はハードウエアのチームでは収まらなくなり、プロジェクト全体の問題になった。そこで、ＯＳのソフトウエアチームの提案は「実行遅延（待ちサイクル挿入）し，タイミングを取る」というものだった。実際にＯＳを手直してみるとそれで問題は即刻解決した。ＡＳＩＣとＯＳの２つの領域の知識の組み合わせが問題を解決したのだ。