2017年 05月 14日 ( 1 )

課題展開図からプロジェクトへ

Kさん、追伸です。

長文のメールを差し上げたばかりなのに、すぐに追伸とはお恥ずかしい話ですが、ちょっとだけ補足しておきたいことを思い出しましたので。それは、もう一つの経営戦略の視点、つまり、「What(何を目指すか)」から「How(いかにアプローチするか)」への話です。
(サイト読者への注:前々回「中堅エンジニアのための経営戦略入門」http://brevis.exblog.jp/25732183/ 、および前回「中堅エンジニアのための経営戦略入門(2)」http://brevis.exblog.jp/25754847/ の記事を参照のこと)

経営者の仕事とは、ざっくり言ってしまうと、次のようなステップから成り立っています。

(1) 企業の「ありたい姿」(使命・ビジョン・ゴール)を示す
(2) 「あるがままの姿」(現状)とのギャップ=課題を明らかにする
(3) 課題解決の方途(戦略)を決める
(4) 経営資源を再配置する(組織の変更を含む)
(5) 遂行をウォッチし問題解決を支援する
(6) 結果として新たな経営資源を獲得・蓄積する
(7) 適時(1)に戻る

課題という言葉の意味については、ずいぶん以前にご説明しましたが、覚えていらっしゃるでしょうか(「超入門・問題解決力 - 問題とは何か、課題とはどう違うか」http://brevis.exblog.jp/12188859/ )。課題とは能動的なもので、“あるべき姿”を思い描いて、現実をそこに向かって変えていくためのポイントです。一方、問題とは、(意識的にであれ無意識であれ)“期待していた状況”と、現実の状況のギャップを指します。上記の(2)で言っているのは、まさに課題の方です。能動的な課題設定は、経営者の重要な職務の1つです。

ついでに言うと、マネージャーの仕事も、大なり小なりこれの縮小版である、と考えることができます。ただし、違いは、中間管理職の場合、主たる使命・目標は「上から与えられる」ことでしょう。逆に言うと、自分で目標設定ができない・ビジョンを生み出せない人は、どこまで出世しても、内実は中間管理職であるといっていいかもしれません。こういう人は未来志向ではない訳で、つまり主体的に生きていない事になりますね。じつはよく見かけるタイプですけれども、
・言われたとおりのことをします、という受注型(受け身型)エンジニア
・正解だけを追いかけたがる入試型秀才
・世間から与えられた競争のモノサシでひたすら勝とうとする競走馬型人間
といった人たちで、環境が大きく変わると絶滅していってしまうのです。

さて、(3)のステップで使う道具立ての一つに、『課題展開図』があります。これは最上位の課題を1番上に書き、その課題を解決するための部分的課題をその次にかき、さらに部分課題を解決するための方策を次のレベルにおく、といった形で作られる図です。例をご覧ください。
e0058447_22061180.jpg
この例ではわかりやすいように、最上位の課題として、「会社の競争力再生」をおいています。そしてその次の中間課題として、「販売力の向上」と「コストの削減」をあげました。販売力の向上という課題を解決するために、2つのプロジェクトが生まれます。1つは新製品開発で、もう一つは海外市場の開拓です。さらにコストの削減という課題を解決するためには、生産合理化と物流改革という2つのプロジェクトがあげられています。スペースの関係で非常に単純な図になっていますが、構造はご理解いただけると思います。

ここであげているプロジェクトは、すべて自発型のものです。例えば新製品開発プロジェクトの目的は、販売力の向上であり、その目標としては、6ヶ月以内に新製品を出荷する、性能を3割以上向上する、が挙げられています。プロジェクトの目標は、具体的な数値をもとに、客観的に成否がはかれる形にすることが望ましいのですが、目標設定は当然ながら課題解決の目的に合致したものでなければなりません。ですから、1年以上かけてじっくり開発するとか、外観を変更するだけで性能はちょっぴり変えるとか、あるいは最小の開発予算で出荷するとかいった目標設定は、不適切だということになります。

さて、ここでどうしても『プログラム』という概念について、ご理解いただかなくてはなりません。プログラムとは、プロジェクトの上位概念です。通常はひとつのプログラムの中に、複数のプロジェクトを包含します。ちなみに米国の「アポロ計画」は、英語では"Apollo Program"でした。プログラムは、配下のプロジェクトを有機的に連携させながら進めることによって、目的を達成する活動です。課題展開図をご覧ください。この例では、「販売力の向上」を達成する活動群が、一つのプログラムに該当します。プログラムは、単なるプロジェクトの集合体ではありません。当然ながら、コンピュータのプラグラムとは全く別の概念です(よく混同されるのでこまるのですが^^;)。
プログラムとは、企業組織が新しい能力を得るために行う、時限的な営為です。これはじつは、英国政府が作成した標準書である"Managing Successful Programmes”(通称MSP)の考え方です。英国では、政府自らがこうしたいろいろなマネジメントに関する標準的解説書を制定して、例えばオリンピックや、鉄道網の敷設といった大規模公共事業を成功させるべく、適用しているのです。

プログラムは能力獲得が目的ですから、通常は、経営資源・設備の増強や、その質的向上を伴います。しかし設備を作ったり、人や組織を増強するだけでは、仕事は終わりません。設備や人が新しい「能力」を獲得して、はじめて目的が達成されるのです。そのためには、プロジェクトの結果(アウトプット)を、能力(アウトカム)につなげるチェンジ・マネジメントが重要な仕事になります。MSPではプログラム・マネージャーは、チェンジ・マネジメントの責任者と歩調をとって働くべし、と規定されています。何か大きな成果物や箱物を作って、それで一丁上がりとはならないのです。

プログラム・マネージャーの仕事は、大きく分けると4つあります。
・必要なプロジェクト群の構想・設計
・各プロジェクトの起動・完了(+中止)
・プロジェクト・マネージャーの任命と経営資源の配分
・プロジェクトの成果物を活用した、価値の具現化(課題解決)

なお、図の例では、経営レベルの最上位課題が、いきなりプログラム・レベルの中間課題に展開されていますが、これは企業組織の規模によりけりだと思ってください。大企業ならば中間に複数のレベルがあるでしょうし、中小企業なら経営課題からいきなりプロジェクトにつながるケースもあるでしょう。ともあれ、経営課題を解決するための手段(戦略)として、プログラム/プロジェクトがあるのだ、という点を理解いただきたいのです。

なお、ついでにいいますと、プログラムの上位概念に、『ポートフォリオ』があります。ポートフォリオとは、企業内、あるいは独立したビジネス・ユニット内で、互いに経営資源を取り合う関係にあるプログラム/プロジェクトの集合体です。経営資源(リソース)とは、人・設備・資金などを含みます。

経営者の仕事の(4)にあげたように、限りある経営資源の配分は、とても重要です。ポートフォリオに含まれる様々なプログラムを、適切に優先順位付けを行い、優先度の高いものから配分していきます。優先順の判断には、費用と効果のマトリクスをよく使います。ポートフォリオ・マネジメントの目的は、必要なリソースの配分ですから、企業内でポートフォリオをくくり出す際には、あまり部門単位(研究所・IT部など)の断面だけで集合体をとらえてはならなりません。研究→開発→マーケティング→生産準備という風につながって、はじめてビジネスの成果を生み出すのが普通だからです。

課題展開図に話を戻しますと、よくある間違いを二つだけあげておきます。一つめは、最上位の経営課題を次のレベルに展開する際、その設定を間違えることです。しばしば、そこに既存組織の単位をおいてしまうのです。たとえば「競争力の再生」なら、「営業部門の課題」「製造部門の課題」という風に分解してしまう。こうしたやり方がなぜ間違いかと言うと、現組織がカバーしていない問題が抜け落ちてしまうからです。また、組織間にまたがる問題が見えなくなりがちです。

もう一つのありがちな間違いは、重複や漏れがあるような改題展開をしてしまうことです。MECEな課題展開をしなければなりません。MECEとは、Mutually Exclusive and Completely Exhaustiveの略で、「漏れもなく、落ちもない」状態を表す略語です(もともとはロジカルシンキングで使われていた用語です)。日本全国の地図を、47都道府県にわけた場合、そこには漏れも重複もありませんよね。あるいは製品を部品表(BOM)に展開する際は、上位の親品目を下位の子部品が漏れも重複もないようにカバーする訳です。これがMECEです。

だから課題展開図とは、企業の経営課題のBOMだといっていいかもしれません。BOMの作り方によって、製造のしやすさや効率性は大きくかわります。上手な課題展開こそ、経営戦略の腕の見せ所なのです。Kさんも、ぜひこういった視点を持ちながら、製品開発の仕事を進めていかれることをおすすめします。ああ、すみません、また長くなってしまいました。最初に「ちょっとだけ補足します」なんて書いたのに(-_-;)。今度ぜひまた、会ってお話できる機会が持てるといいですね。


<関連エントリ>
 →「超入門・問題解決力 - 問題とは何か、課題とはどう違うか」http://brevis.exblog.jp/12188859/ (2010-02-21)
 →「中堅エンジニアのための経営戦略入門」http://brevis.exblog.jp/25732183/ (2017-04-28)
 →「中堅エンジニアのための経営戦略入門(2)」http://brevis.exblog.jp/25754847/ (2017-05-07)

by Tomoichi_Sato | 2017-05-14 22:06 | プロジェクト・マネジメント | Comments(0)