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

バックナンバーはこちら　https://mat.lekumo.biz/ppf/conceptual_pm/━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

◆プロジェクトマネジメントは制約の中で成果を最大化する

今回は、５番目のポイントである

（５）トラブル発生時の厳しい制約の中で、創造性に富んだリカバリーのアイデアを出す

について考えてみる。

本誌の有料版のＰＭ養成マガジンプロフェッショナルで、２００５年の秋からＰＭサプリというシリーズをはじめて、もう１０年になる。このシリーズはＰＭ力強化につながる読むサプリをコンセプトにこれまでに４００話強を書いてきたが、その中で出てくる単語ベスト５の中に、プロジェクトとか、マネジメントとかと並んで出てくるのが「制約」という言葉である。

プロジェクトマネジメントのトライアングルが示すように、プロジェクトマネジメントはプロジェクトの制約を守りながらプロジェクトの成果を最大化するための活動で
ある。

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

◆リーダーシップとマネジメント

このメルマガではイノベーティブ・リーダーという言葉を使っているが、ある人がリーダーというのは本来イノベーティブなものではないかと指摘されたことがある。

そのとおりで、新しいことをする人がリーダーだということを強調するために敢えて「イノベーティブ」という言葉を使っている。

今更だが、今回の戦略ノートはメルマガで使っている「イノベーティブ・リーダー」という言葉の共有をしたいと思う。

まず、最初に皆さんはリーダーシップとマネジメントの違いをどのようにお考えだろうか。いろいろな意見はあるが、今、もっとも一般的に受け入れられているのは

マネジメント：現在のシステムを機能させ続けるために、複雑さに対処することリーダーシップ：現在のシステムをよりよくするために、変革を推し進めること

というものである。

マネジメントは現在のシステム（ルール、プロセス、ビジネスモデル）を機能させ続けることが目的であり、新しい問題が起こったときに、どのように現在のシステムの範囲で対応するかという問題解決を行う。一方で、システムそのものを変えようとする変革を行うことがリーダシップである。

一例をあげると、よく稟議のスピードが問題なるが、あるプロジェクトで今の稟議のルールではどうしても時間がかかって納期が厳しいということで稟議の際には事前に予定を告知し、持ち回りすることにした。これはマネジメント的な対応である。

別のプロジェクトでは、同じ問題に対してルールそのものを変えて稟議の決裁者数を少なくした。これはリーダーシップ的な対応である。

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

◆自動運転車というイノベーションはなぜ起こるのか

前回技術とイノベーションの関係について書いたが、技術プッシュの問題の根底は戦略にある。企業の活動をどのように見るか、現実をどのように見るかという問題はあるが、企業（カンパニー）の活動を部分最適を目指す活動の集合とみれば、イノベーションの課題は前回のように部分として技術と顧客ニーズをいかに統合するかという議論になる。

現実の度合い、事業の広さなどの問題はあるにせよ、企業活動を全体最適を目指すものだとみれば、イノベーションは（事業戦略）にしたがって行われるものだということになる。イノベーション戦略ノートの第１１話に

「経営戦略とイノベーション」

という記事を書いたが、この世界になるわけだ。

今回のイノベーション戦略ノートはその上でという話である。

こういう文脈では出てこないイノベーションというのがある。たとえば、今、自動運転車で大きな話題になっているグーグルのイノベーションを考えてみよう。

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

◆技術はＡ級戦犯か？

日本の製造業は長年技術だけを価値創造の手段として捉えてきた。技術プッシュを伴うプロダクトアウトである。そして、その戦略は行き詰まり、マーケットインの戦略をとるようになった。つまり、市場や顧客の声を十分に聞き、それを実現することによって新しい価値を創造しようとした。

顧客のニーズの中には技術開発が必要なものも多かった。そのような技術開発をしてまで対応したが、うまく行かなかった。エレクトロニクス業界のようにたどり着いたところはガラパゴスという業界もあった。

このような経験から、イノベーションとは技術革新を意味しているわけではない、技術では価値創造できない、イノベーションとは組みわせにより新しいビジネスモデルを作り上げることだといった考えが中心になっている。

技術が日本に革新的な製品やサービスが生まれないＡ級戦犯になりつつある。

しかし、技術で価値創造しているところに問題があるわけではない。問題はその価値創造のやり方にある。

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

◆伊藤穣一さんの名言

「イノベーションを増やしたいなら失敗のコストを下げなければならない」

これはＭＩＴメディアラボの伊藤穣一さんの指摘である。名言だし、極めて真っ当な指摘であるが、残念ながらこのような発想のマネジメントには日本ではなかなか、お目にかからない。

発想の近いマネジメント手法がないかというとそういうわけでもなく、たとえば、日本でも徐々に普及してきたリーン製品開発と呼ばれる手法の中に、セットベース開発という手法がある。

セットベース開発とは、構想段階で多くの代替案を並行検討し、徐々に絞り込み、最終的には一つの案に集約する開発方法である。普通に考えると、代替案の個数は開発コストに比例するが、セットベース開発では、初期の段階で代替案の検討を低コストで行う方法を検討し、その方法で検討を行う。さらに、採用されなかった代替案の検討で得られた情報は知識として共有され、他の開発に活かされる。この２つの工夫により、コストを抑えることができる。

見方によっては失敗した技術経験を知識化し、活用しており、これだとかなり大胆な製品仕様ができ、イノベーションに失敗を活かすには合理的な方法になっている。

バックナンバーはこちら　https://mat.lekumo.biz/ppf/conceptual_pm/━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

◆本当に経験から学べるのか

今回は、４番目のポイントである

（４）プロマネやエンジニアとしての過去の経験を活かす

について、振返りや、応用力など、いくつかの観点から考えてみたいと思う。まずは、振返りと学習という観点から考えてみたい。

よく経験から学ぶというが、本当に経験から学べるのだろうか。たとえば、２０００年のＩＰＭＡのカンファレンスの論文で教訓がどの程度活用されているかを大規模な調査で調べた論文があるが、これによると

・教訓を誰かに伝える　５０％
・教訓を活用する　２５％

とある。つまり、教訓を実際に使っているプロジェクトは４つに１つに過ぎないというのだ。なぜか。

一つの原因は経験を情報としてそのまま取り扱っていることにあるように思う。つまり、必要なのは経験から学ぶことではなく、

経験を振り返ることで学ぶ

のだ。学ぶ鍵は振返りにある。プロジェクトマネジメントに関する学びも例外ではなく、そこにある。

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

◆イノベーションにワクワク感はない

４年くらい前に、「プロジェティスタ研究会」という研究会をやっていて、その研究会主催で「仕事をワクワクする」というテーマでワールドカフェを行ったことがある。ワクワクというのは、内発的な動機、ダニエル・ピンクのいうところのモチベーション３.０である。東京で２回、関西で１回行った。

そのときに印象に残ったのは、ワクワクする状況として、新しいことをやるとか、社会に貢献するといったワードが少なかったことだ。逆に

・主体的にできる
・成果が実感できる

といった発言が多かった。研究会としては、これを承認欲求であり、内発的動機ではないと判断した。

つい最近、ある場で同じような話を聞いた。「イノベーション」という言葉にはワクワク感を感じないという話だ。ずっと頭のどこかに引っかかっていた話だったので、やっぱりそうかというのが正直なところだった。

僕はもともと技術者なので、（いろいろなレベルがあるが）人がやってしまったことは興味がないとか、社会に役立たないことはやりたくないといった発想が強い。だから、イノベーションという言葉には社会を影響を与えるという意味でワクワク感を感じるし、感じない人の感覚は理解できない。

バックナンバーはこちら　https://mat.lekumo.biz/ppf/conceptual_pm/━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

◆コンセプチュアルな計画とは何か

さて、今回のテーマは３番目のポイントで

（３）実行できる計画を作る

をコンセプチュアルな計画という視点から考えてみる。

そもそも、コンセプチュアルな計画とは何かというと、

目的の本質を見極めた計画

である。

◆標準と計画とテーラリング

ＩＴプロジェクトや製品開発プロジェクトのように、日常的な業務をプロジェクト行っている場合には、そのプロジェクトで対象となる業務の標準が決まっている場合が多い。さらに、ＩＴの場合には見積もりについても標準を決めている場合がある。この２つを組み合わせると、業務標準で段取りを決め、見積もり標準で所要工数やコストを決めるというのが計画の方法になる。

これでうまく行くのであれば問題ないが、一般的にいえば、同じようなプロジェクトは回数を重ねるほど高い生産性が期待されるため、いずれ標準的なやり方では制約の枠内に入らなくなってくる。

そこで標準には個々のプロジェクトの事情に合せてテーラリングをしてもよいといった注意書きがついていることが多いのだが、どうテーラリングをすればよいかが問題になってくる。

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

◆はじめに

イノベーションリーダーの質問力のシリーズが途中で止まってしまっているが、このような質問を生み出すときに欠かせないのがコンセプチュアルスキルである。

そこで並行してコンセプチュアルスキルについて考えてみたい。一部の議論はイノベーティブリーダーの思考法の中でしているが、改めて別の枠組みで考えてみる。第１４話で、

第14話　イノベーティブ・リーダーの思考法（６）～抽象と具象の行き来

という記事を書いたが、この記事に拡張と深掘りだと考えて戴ければよい。

この記事では抽象と具象の行き来から、経験を新しい場面に活用するという趣旨であった。この場合のコンセプチュアルスキルは抽象と具象の行き来ということになる。

これも含めてコンセプチュアルスキルは以下の５つの要素について、両極を行き来するスキルである。

（１）抽象的／具象的
（２）主観的／客観的
（３）直観的／論理的
（４）大局的／分析的
（５）長期的／短期的

それぞれの軸の意味は以下の通りである。

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

◆はじめに

前回は、製品の感情的な問題についての質問を考えた。これまでに製品について考えた質問は

（１）新しいトレンドをどうすれば利用できるか
（２）顧客の煩わしさを取り除き、ユニークなベネフィットを与えるにはどうすればよいか
（３）私たちの製品によって顧客はどのような感情的、精神的、立場的なベネフィットが得られるか
（４）私の製品のどんな機能が顧客の情熱をかきたてているのか

の４つだ。

今回は、イノベーションについてもっとも本質な組み合せの問題について考えてみよう。