PMstyleプロデュース

バックナンバー　https://mat.lekumo.biz/pmstyle/cat9984019/　━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

◆本質を考える思考はチームの方が適している

PMstyleでは、「コンセプチュアルなチームを創る」という講座をやっています。この講座で掲げているコンセプチュアルなチームのイメージはこちらを参考にしてください。

【ＰＭスタイル考】第１２６話：プロジェクトチームがコンセプチュアルであるとはどういうことか
https://mat.lekumo.biz/pmstyle/2017/08/post-78b8.html

この講座で、ある受講者から、本質を考える思考はチームの方が適しているのではないかという指摘がありました。

その通りです。

◆コンセプチュアル思考はチームとしてもできなくてはならない

コンセプチュアルスキルはもともと経営者のスキルとして位置付けられていたので個人の思考スキルのようなイメージがありますが、実はそうではありません。確かに、７０年前には経営者が一人で様々なことを考えなくてはならなかった時代にはそうだったかもしれませんが、今は経営そのものをチームで行う時代です。

従って、コンセプチュアル思考は、個人ができるだけでなく、チームとしてできる必要があるのです。

そこで、コンセプチュアル思考をチームで行い、本質を共有するにはどうすればよいのかを考えてみましょう。

バックナンバー　https://mat.lekumo.biz/pmstyle/kimagure

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

◆はじめに

プロジェクトやマネジメント、ビジネスでは多くの問題に遭遇します。遭遇した問題をどのように解決できるかで、成果は大きく変わってきます。

成果を大きくするためには、本質的な問題が何かということを適切に見極め、本質的な問題に対して、プロジェクトの目的を考えて手を打つ必要があります。

◆橋を架けてくれと依頼された

たとえば、みなさんが島に住む住人から、橋をかけてくれと頼まれたとします。この時点では問題は「橋がないこと」だと考えているわけです。

あなたは、この依頼をゼネコンにつなぎました。ところが、予算的に折り合いません。

バックナンバー　https://mat.lekumo.biz/pmstyle/cat9747239/　━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

◆まねる

イノベーションが注目されるようになって、まねることが再び、注目されるようになっている。イノベーションは既存のアイデアの組み合わせであると言われており、まねることと非常に強い関連性があるからだ。

いい意味でも悪い意味でも、日本人はまねることが得意だといわれてきた。良い悪いは別にして、実際にまねから始めて、発展させ、新しいものを生み出してきたのは確かだろう。高度成長期はまさにそのような時期だったといえる。このあたりの話は、井上達彦先生の

「模倣の経営学 実践プログラム版 NEW COMBINATIONS 模倣を創造に変えるイノベーションの王道」、日経BP社（2017）

を読んでみるとよい。トヨタやセブン-イレブンが採った、手本とする他社の本質を見抜き、自社で生かせる儲かる仕組みを抽出する創造的な摸倣の方法を体系的にまとめた一冊だ。また、井上先生が翻訳された

オーデッド・シェンカー（井上達彦、遠藤真美訳）「コピーキャット―模倣者こそがイノベーションを起こす」、東洋経済新報社（2013）

もお勧めである。

しかし、一方で、まねはしてもイノベーションが生まれなくなっているという現実もある。どうしてなのだろうか。

そこにはまねるとはどういう行為なのかという問題があるように思える。今回のＰＭルスタイル考は、この問題について取り上げてみたい。

◆なぜ、ITプロジェクトは混乱するのか

次のようなプロジェクトを考えてみよう。

ある通販会社で経営層から「ロイヤルカスタマー戦略のテコ入れによる収益向上」と
う戦略が打ち出された。その実行の一環としてロイヤルカスタマーへの新たな働きかけをする、これまでにはない仕組みの構築を課題としたプロジェクトを実施することになった。

これまではロイヤルカスタマーに対する値引きは行っていたが、即日配送、特別な情報提供などできそうなことはいくらでもある。加えて、これまでには行われていない方法を取ることを前提にすれば、考える範囲はほぼ制約がない。一方でコストは決まっているので、その制約は守らなくてはならない。

このようなプロジェクトにおいて、いきなり、具体的にどのような仕組みを持たせるかを決めようとしても、新しい独自の仕組みを固定的に考えることは非常に難しく、試行錯誤してみなくては決まらない可能性が高い。また、強引に決めてもプロジェクトを進めていくうちに、実現できない、予算が足らないといった問題に直面することが多い。

そもそも、ロイヤルカスタマーの定義は今のままでいいのかといった話にもなってくるだろう。

たとえば、注文の仕組みを変えて、ロイヤルカスタマーになれば他の人に商品を奨めた場合のロイヤリティが入る仕組みを取り入れようとした。ところが、ロイヤルカスタマーがそれなりに満足するにはどういう仕組みにすればよいかは実際にやってみないと分からない部分が多い。仕組みによって、システムの仕様だけではなく、範囲も変わってくるだろう。

このようにシステムとして開発すべき範囲や仕様を明確にした上で、システムを開発するという方法が通用しにくい「ITプロジェクト」が増えている。

にも関わらず、要求仕様を強引に決めようとする。プロジェクトを進めていくうちに、結果として要求仕様は変化し、ステークホルダーの間でプロジェクトの目的に対する共通の認識がなく、また、チームにおいても指針がなく開発を進めていくケースが増えている。

従来のプロジェクトではプロジェクトの目的はシステム目的によってほぼ決まっていたし、システムの要求仕様もプロジェクトの初期で決まっていたので、あえてプロジェクトの目的を意識する必要はなかった。

ところが、問題としているタイプのITプロジェクトでは、プロジェクトの目的とシステムの目的は必ずしも一致しない。つまり、明確なゴールを設定しないままで、プロジェクトを開始することになる。

プロジェクトのゴールが明確になっていない状況でプロジェクトを進めると、プロジェクトは例外なく混乱する。これが、いま、ITプロジェクトが混乱しているもっとも大きな原因である。