計画の極意 “ツッコミどころ” を探せ！ まずは「前提要因」に着目しよう（1/2）
計画上手と評判の高い人たちは、懐に “ツッコミどころ” を忍ばせています。
彼らの “ツッコミどころ” は、ある時は計画の参加者たちをさらに深い議論へと導き、またある時は凝り固まった議論や偏見に満ちた議論に警鐘を鳴らします。
ところが、計画に不慣れな人たちが自分なりの “ツッコミどころ” を手に入れるには、かなりの経験を要してしまいます。それだけではありません。漠然と計画経験を積み上げただけでは、一生手に入れることができない可能性すらあります。
そこで私は、初心者向けに3つの “ツッコミどころ” を準備しました。
［計画の初心者に贈る3つの “ツッコミどころ” ］
1. 何が前提要因なのか？ （どんな前提条件があるのか？）
2. 何が重点要因なのか？ （いつも失敗するのはどこか？）
3. 何が新規要因なのか？ （これまでとは何が違うのか？）
たったの3つですが、最初はこれで十分です。これを梃子（てこ）に計画を繰り返すうちに、皆さんなりのツッコミの得意技が身に付くはずです。
また、私は計画を「全体計画」と「詳細計画」に分けて考えていますが、全体計画がツッコミにとって最良のタイミングである点も忘れないでください。
さて今回は、その1つ目「何が前提要因なのか？」の話をします。
計画には、その立脚点となる前提があるものです。計画の前提とは、計画の目的、根拠、背景などのことで、時にはステークホルダー（利害関係者）の意向、利害関係や依存関係のある他の事案などが影響を与えます。
私はこれらを「前提要因」と呼び、計画する上で最も初歩的で重要な “ツッコミどころ” として位置付けています。
私が「前提要因」と呼ぶのは、計画において間違いを引き起こしがちな前提条件のことです。
詳細計画に突入したら、私たちは目の前の細々としたことに気を取られてしまい、全体を俯瞰することが難しくなります。
特に前提要因は、いったん受け入れてしまうと、それ以降、これらを疑う機会はまず巡ってきません。詳細計画にまい進する私たちには、そんな心の余裕はないからです。
残念なことに、私たちが前提条件の間違いに気付くのは、大きな失敗が発生した後です。
こんな例を考えてみましょう。
開発部門の中堅社員である鈴木はある日、経営陣に呼び出されました。
経営陣 「鈴木さん、ご存知のように私たちは業界の2番手に甘んじています。次の主力商品の開発はあなたに任せるので “ナンバーワン” を目指してください」
鈴木 「承知しました。ご期待に沿えるようにがんばります」
鈴木と彼のチームは寝る間を惜しんで開発に没頭し、どこにも負けない性能を実現しました。 鈴木は “ナンバーワン” という目標を見事に達成したわけです。ところが新商品のシェアは業界2位だった先代商品に遠く及びませんでした。
鈴木は経営陣のひとりに、別れ際にこう言われました。
経営陣 「がっかりしました。あなたを抜擢した私たちに見る目が無かったということです。シェアナンバーワンどころか、いまや3位に後退してしまった。わが社のお先は真っ暗だ。」
そのときはじめて、鈴木は、自分が任された商品開発プロジェクトの真の目標に気付きました。それは “性能ナンバーワン” ではなく “シェアナンバーワン” だったのです。
長い設計者人生を通じて “性能こそ競争力だ” と叩き込まれてきた鈴木にとって “ナンバーワン” は “性能ナンバーワン” の意味でした。しかし、事業環境は昔とは様変わりしていたのです。
鈴木のチームは業界初の高性能を実現するために製造コストを犠牲にしました。そのため、販売価格は先代に比べて10パーセントもアップしていました。時代の潮流はすでにグッドイナフ（機能や性能は今のままで十分だ）にシフトしていました。鈴木たちが開発した商品の価格は、戦いの場を価値創出に、戦いの前提を低価格に絞り込んだ他社の価格を大幅に上回るものでした。
鈴木は “ナンバーワン” という言葉を耳にしたとき、これまでの延長線上で「わが社の戦略は高級志向だ」と勝手に思い込んでしまいました。この言葉で燃え上がった技術者魂は、その真意を見抜く冷静さを彼から奪ってしまったわけです。
鈴木は商品開発責任者であったにも関わらず、経営陣の言葉が前提要因であることを見過ごし、結果的に目標を見誤ってしまいました。
実は、この話には、もっと深い洞察があります。
この商品が世に出るまでには、経営陣によるレビューが何度か実施されました。当然、そこでは価格も話題となりました。価格アップに難色を示す幹部もいなくはありませんでしたが、大半は “性能ナンバーワン” に賞賛の声をあげました。
つまり、経営陣も同罪なわけです。
鈴木が早合点しなかったとしても、きっと結果は同じだったはずです。
この状況を深読みすれば、鈴木が疑うべきだった前提要因は「幹部が何を要求しているか」ではなく「顧客は何を求めているのか」だったということです。
これは、設計で腕を磨いてきた鈴木にとって簡単ではありません。しかし、鈴木が、自分は “製品開発責任者” ではなく “商品開発責任者” であることをもっと自覚してさえいれば、もしかすると、このトラップに引っ掛からずに済んだかもしれません。「製品開発＝性能追求」であったとしても、商品開発は企画力であり市場分析力だからです。
話が横道に逸れましたが、この例が示すように、前提要因を疑うときは、自分たちが置かれた状況をかなり深読みしなければなりません。
前提の間違いは、詳細計画フェーズでの見落としや勘違いとは違い、結果に対して大きな影響力を持ちます。
これは、それまでの努力をすべて水の泡としかねません。
★★★ 概念化.com を立ち上げました ★★★
★★★ ぜひ、お立ち寄りください ★★★
この記事が気に入ったらサポートをしてみませんか？