【PMスタイル考】第74話:継続的イノベーションの時代のマネジメント
◆イノベーションは意思を以って起こす
イノベーションは自然に起こるものではありませんし、誰か、優秀な社員が起こしてくれるものでもありません。
イノベーションは意志を以って起こしていくものです。今回のPMスタイル考はイノベーションの話をしたいと思います。
今、イノベーションが注目されているのには戦略的な理由があります。10年前なら技術イノベーションを求めて研究開発を行い、うまく行けばその成果を使った事業戦略を立てて5~10年単位で事業展開ができていました。今でもイノベーションにはこのイメージが残っていますが、戦略を組み立てる「ネタ」になるものでした。
◆戦略=イノベーション
ところが今はそのような状況ではありません。ひとつのイノベーションによる優位性がそんなに長続きせず、競争に勝つためには次から次に連続的にイノベーションを起こしていく必要が生じています。言い換えれば、
戦略=イノベーション
と いう図式になってきました。この時代を象徴するのがアップルです。iPhoneというとてつもないイノベーションを実現したにも関わらず、毎年、新製品が 発表される度に今年はどんなイノベーションがあるのかとユーザーから期待されています。そして、その期待に答えれなければ対価に見合わないと判断したユー ザーは似て安い製品に移っていきます。
情報システムのような受注製品でも同じようなことが起こっています。ITのベンダーはこの10年、 ソリューションということを盛んに訴えてきました。ソリューションビジネスとは顧客がビジネスやサービスについて抱えている問題や不便を解消することで、 ITベンダーはそのために提供される情報システムを提供してきたわけです。
顧客のビジネスが5年、10年続いていた時代には、ソリューションは情報システムの更新に併せて提供すれば十分でしたが、上にのべたようにイノベーションが戦略として求められるようになるとソリューションもそのサイクルに併せて提供しなくてはなりません。
つまり、顧客の狙うイノベーションに併せてソリューションを提供しなくては顧客は満足せず、ここでは、
ソリューション=イノベーション
という図式ができつづあります。今後、ITベンダーが生き延びていく条件の一つにイノベーションを起こすソリューションを継続的に提供できることが間違いなく入ってくると思われます。
◆イノベーションマネジメントとプログラムマネジメント
さて、このようにイノベーションを継続的に起こしていくにはどうすればよいのでしょうか。冒頭にも述べましたように、成り行き任せではできないことは明らかです。
そこでマネジメントが必要になってきます。
イ ノベーションを起こすには2つのマネジメントが必要です。一つはイノベーションを効果的に起こす組織的活動を実現するマネジメントです。これは「イノベー ションマネジメント」と呼ばれます。具体的には戦略実現に必要なイノベーションのテーマを見つけ、資源配分を決め、イノベーションの成果をうまくビジネス に取り込んでいく戦略マネジメントです。
もう一つはイノベーション活動そのもののマネジメントが必要になります。イノベーションは通常の業務と異なり、目標が決まっても確実にその目標を達成できるという保証はありませんし、目標そのものが変わってしまう場合もあります。試行錯誤が不可欠です。
一方で、連続的にイノベーションを起こすにはリードタイムが問題になってきますので、できるだけ効率的に試行錯誤をしていく必要があります。そのためのマネジメントとしては、プログラムマネジメントが効果的です。
◆イノベーションを俊敏にするプログラムマネジメント
プログラムマネジメントの中でポイントになるのは、プログラムのデザインです。プロジェクトであれば
目的、目標、前提、制約、体制
を決めれば事足りますが、プログラムの場合はもう少し複雑になります。PMstyleの場合、プログラムのデザインの要素を以下の9つとしています。
(1)ミッション
(2)ゴール
(3)製品・サービス
(4)収益
(5)アークテクチャー
(6)プログラムシナリオ
(7)リソース
(8)投資
(9)ベネフィット
(1)のミッションは、戦略実行のためにプログラムが実現すべき事項で、プログラムが生み出すべきの総体ということになります。
(2)のゴールは、ミッションを実現するためには何をゴールにすればよいかを明確にします。
(3)の製品・サービスはミッション実現のために開発する製品・サービスなどの成果物を明確にします。
(4) の収益はプログラムで得られる収益です。プログラムはその性格上、ミッションを達成し、ベネフィットを実現すると同時に、財務的な収益も求められることが 普通です。ただし、組織変革プロジェクトのように組織内部のプロジェクトの場合には収益は必要ないケースもあります。
(5)のアーキテクチャーはプログラムのベネフィットを生み出すための個々の活動の定義です。具体的にはプログラムとして実施するプロジェクトの定義になります。
(6)のプログラムシナリオはアークテクチャーでプログラムのベネフィットが実現できる可能性を示すものです。複数のシナリオを可能性として示すのが普通です。
(7)のリソースはプログラムの実行に必要なリソース、(8)の投資はプログラムへの投資です。
(9)のベネフィットはプログラムがもたらすベネフィットですが、一般的には戦略にどのように貢献できるかだと考えていいでしょう。
◆プログラムキャンパス
この9つの要素をバランスを取りながら決めることによってプログラムをデザインします。プログラムのデザインにおいては、バランスを可視化できるようにプログラムキャンパスというツールを使います。
プログラムキャンパスは(1)~(4)を価値のキャンパス、(5)~(8)を最適化のキャンパスとして、両者からベネフィットが最大になるようにデザインするツールです。具体的には価値のキャンパスで価値を最大化し、最適化のキャンパスでリソースや投資を調整します。
プログラムキャンバスを使って構造的に考えることによって、効果的なプログラムの設計が可能になります。
コメント