PMプロの知恵コーナー
先号   次号

ゼネラルなプロ (8)

向後 忠明 [プロフィール] :6月号

 スキームモデルの最初の段階では必ずしもプログラムの具体的な「明確化されたミッション」はありません。
 前月号で例として挙げた大きなミッションである「新興国の発展と日本の技術を考えた産業振興」と言った漠然とした要求に対して「明確化されたプログラムミッション」が「インフラの海外輸出」であり、その結果出てきたビジネスモデル(プログラムモデル)が高速道路や高速鉄道、下水等の公共事業、ITC関連事業、水道事業等々でした。
 すでに前月号でも説明したように、我々のような請負を主たる事業とする者が対象とするミッション(使命)は、いくつかのビジネスモデル(プログラム)を含む「明確化されたプログラムミッション」がほとんどだと思います。
 そこから、対象となる「ビジネスモデル(今後はプログラムと称する)」まで絞り込むための戦略的アプローチがあり、そしてアーキテクチャ・マネジメントプロセスを経て、プログラムを構成するプロジェクト群が生成されることになります。

 スキームモデルの中でもミッションプロファイリングのプロセスが非常に重要であることはすでに読者諸君には分かってもらえたと思います。
 すなわち、錯綜し、混沌とした状況を“ありのままの姿”としてインタビュー、現場取材、資料分析等を通して調査し、その結果を分析し、「状況問題」を抽象的なものから具体的に処理できるよう「課題化」し、それを“あるべき姿”として「明確化されたプログラムミッション」を描くプロセスです。

 すなわち、複雑な事象を調査結果に基づきストリーとして、そこにある「あるべき姿」に展開するシナリオに作成することであり、その方法には各種の手法があり、例えばKJ法、仮説検証法そしてケプナー・トリゴ法等があります。
 以下に示す例は、ケプナーのラショナルシンキングの手法例に従って、プロファイリングのプロセスを見ていきたいと思います。

  すなわち、ミッション(使命)に沿って、現状把握としての調査を行った結果を以下のステップにてチームを作り、複数の人達による自由な発想による議論も加え、検討をおこないまとめていく方法です。
関心事の列挙
与えられた大きなミッションを対象に現状の「ありのままの姿」を「何とかしなければ」、「気になっていること」、「おかしいと感じていること」、「手をうたなければならないこと」等々直面する状況の一覧を作る。この時、幾つかの下記に示す注意するいくつかの点がある。
状況調査による結果だけでなく、過去の経験や先入観にとらわれずゼロベース思考で行う。
状況分析をする業務やプログラムの範囲分析範囲を決める(例)対象分野/業界/企業規模/所属単位
要点を箇条書/簡潔にする
「列挙」に際して事項の評価はその時点ではやらない。
関心事の具体化と分離
 錯綜する状況や抽象的な問題を取り上げ、具体的な「課題」とする際には、「分離」、「分解」と言う考え方が有効である。
 例えば、大きな問題である場合、それを一挙に解決できる場合とそうでない場合がある、その場合はその関心事を分離または分割して列挙するか、または、もっと高い位置(会社レベル、事業部レベル・・)で考えれば一挙にその問題が解決できるのであれば一挙に「関心事」として列挙するとかを考える。
例えば次のような趣旨でまとめるのも良い方法である。
どんな事実を根拠として、それを言っているのか。
具体的に言うと何なのか。
対象をもっと絞れないか。
もっと処理しやすい「部分」に分けるとどうなるのか。

ステートメント化と優先順位の設定
 ステートメント化とは分離、分解された「関心事」を実現可能または処理しやすい課題に展開し、分析課題、実施課題として整理する。なお、優先順位は言うまでもなく複数のステートメント(課題)がある場合、お互いの関係を見ながら、複数課題の優先度(重要度/緊急度/傾向)に応じて分類する。もちろんステートメント間に何らかの関係が存在する場合は、その関連性も考慮する。

処理方法の選択
「関心事』から「ステートメント化」そして「優先順位」までの思考作業では具体的解決または選択の議論はなされていないが、問題としての「あるべき姿」は浮き上がってはいる。
 すなわち、抽象的あるいは漠然とした問題の事実関係がある程度読め、かつ優先順位化された課題のみに対し、これからはその対応策を考えれば良いところまで来ている。

 これが「P2M」で言っている「あるべき姿」となり、これを基に具体的なミッション表現、すなわち幾つかのプログラムを含む「明確化されたプログラムミッション」ができるわけです。
 ただし、ここで生成されたプログラムミッションと実際の求めるべき姿との間にギャップがある場合もあります。すなわち、この「明確化されたプログラムミッション」と自社の現状との間に“オーナーまたは経営トップの考えと同じか、達成可能か、人材はいるのか、資金が潤沢か、経験があるのか”と言った「現状の問題」と「求められる願望」に対し、実行する前に、再度次のような対策を第3者の眼で講ずる必要がある。すなわち、
先入観からの「的外れ」や短絡した考えがないか
何故、このプログラムミッションを設定したのか、その原因は何か
斬新性、新規制そして将来的持続性に問題はないか 等など
 これら心配事も、前項の状況分析と同じように、将来のあるべき姿も考慮しながら問題点のステートメント化「課題化」を行い、問題点を明瞭化し、特異点の発見、心配事の原因の推定、絞り込みそして対策の選定と言った順に手作業を行います。
 ここまでくればミッション達成に問題となる原因も除去され、問題と願望が一対となり、問題点も原因分析によりクリアーされ、将来性もある「明確化されたプログラムミッションとなる。
 「明確化されたプログラムミッション」には複数のプログラムを含んだり、単一のものであったりします。このように、前月号の図7.1に示すプロセスにていくつかのプログラム(図7.1ではビジネスモデル)を含む「明確化されたプログラムミッション」が構想されます。

 ここで構想されたプログラム群を絞り込む必要が出てきます。基本はミッション(使命)に示された内容に沿ってそこに求められる基本的な要求条件をプロファイリングにて設定された課題を「市場、人、組織に関する状況変化を展望し、将来を含め自社としてどのような位置付けとし、そしてどのように進めていくか」と言った戦略的思考が必要となります。
 すなわち、調査結果に基づく自社の製品、サービス、技術を市場にうまく導入し競業他者より優位に立つかと言ったマーケットを含めた事業戦略も立てる必要がある。そこには必ず投資戦略、組織戦略、技術戦略、人事戦略、そして場合によっては国際戦略等も関連してきます。
 そこで機能するマネジメント手法がSWOT分析やポートフォリオ分析です。
 そして、上記で示したプロセスおよび自社を取り巻く環境(外部環境)を眺めながら戦略的に処理優先順位を決定します。
 その結果、処理優先順位に従って絞られたプログラムを、取り巻く各種環境調査を踏まえて、自社/他者の経営資源を組み合わせると言ったエンジニアリング手法により、プログラムの全体構造とそれを構成するプロジェクト群を構想します。

 上記に示すビジネスマネジメント手法はチャ―ルス・H・ケプナーが発案した「ラショナル思考プロセス」の一部であり、この手法はP2Mで解説しているプロファイリングのプロセスに良く似ているので、参考に取り上げてみました。

 次にアーキテクチャマネジメントの解説に入ります。
 P2Mではアーキテクチャの定義を以下のように説明しています。

 アーキテクチャは、プロファイリングの結果を基にその具現化に向けて①基本要求②ライフサイクル③全体構造④全体機能⑤全体操作性を与えるデザイン思想である

 プロファイリングの結果、ビジネスモデル(プログラム)はさらにいくつかの複数のプロジェクトに分割され、プログラムを構成するために必要なプロジェクトの優先順位を付け、そこに機能(役割)を与え、プログラムの全体構造(機能)を決めます。
 そして、プロジェクト群の構造化とその機能が決まれば、これまで検討してきたプロジェクトの優先順位を考えたシナリオに従ってプログラムの機能を発揮できるようにすればよいでしょう。それが、プログラム運用上のルールであったり、ロードマップであったりします。
 一方、プログラムを構成する各プロジェクトはそれぞれ価値を生まなければなりません。これは意思決定には最も重要な要素となります。
 具体的には何をするのでしょう。
 プロジェクトの目的によって価値算出の方法は千差万別です。
 P2Mではプロジェクトの価値評価としてその各種のモデルを羅列していますが、本コーナの対象事業は前月号でも説明したように社会基盤系、生産設備系、総合エンジ系、IT/情報通信系であることから、投資対効果の観点からの検討で良いと思います。
 すなわち、実現の価値としてのDCF(Discount Cash Flow)法やIRR(Internal Rate of Return)法と言った投資キャッシュフロー分析および外部測定指標としての経済的効果からの検討を行えばよいと思います。
 この結果、プログラムを構成するプロジェクトの価値がすべて規定以上であれば問題ありません。しかし、それが各単体プロジェクトとして適切であっても、プログラムの視点での整合性がなければなりません。

以上が、スキームモデルに関する筆者のつたない経験からの解釈です。
 いずれにしても、このスキームモデルに関しては、P2Mの対象とする分野、業界がかなり広範囲であることから、本書を読む人にとっては非常に内容が難解になってしまいます。そのため、ここでは上記に示した業界に絞ってまとめてみました。

 ここまでがスキームモデルの作業ですが、このプロセスをまとめることのできるプログラムマネジャーがいまだに多くは育っていません。この育成が今後の大きな人材育成の課題となってきます。
 何度も言いますが、スキームモデルに示すプロセスでの仕事は顧客サイドでも困難をきわめています。そのためコンサルタントを起用することが多いですが「仕事に結果責任を持ち顧客満足を達成できる人材」と言うことになると、次のフェーズであるシステムモデルおよびサービスモデルまでできなければならないことを考えると、今のコンサルタント人材でも十分とは言えません。

 次月号からは、プロジェクトの価値算出の投資対効果について説明していきます。
ページトップに戻る