丁度、先月末ぐらいから、本ブログで、ステークホルダー・エンゲージメント・マネジメントの問題を書こうと思っていたのですが、下書きの時点でカナリ回りくどくなってしまったので、4/22 リリース予定だったブログは削除してしまって、今回、イキナリ（、某弊部会の考える）、「ステークホルダーも納得するポートフォリオ・プログラムを再定義」してみようと思います。
＜ステークホルダーの問題＞
「ステークホルダーも納得」と言いますが、
コチラでも触れましたが、簡単に言って、
コチラに書いたように、
「事業のポートフォリオ・プログラムは、既存事業のラインナップ強化・拡充という方向性では（、比較的）、動きますが、コレらは、難易度 ＆ 効果が低い"担ぐ系"に走りガチのように思います。もう少し高度な、"バリューチェーンを伸ばす"ための、自社事業に必要となる全社系のプロジェクトは、適切なプロセスでプロジェクト選定ができておらず、ステークホルダーが立ち難いです。」
と言った様な問題を抱えていると考えています。
この分析、最近、以下の様なニュースもあったので大枠で合っている気がします。
大企業にありがちな、専門性の低い担当者による新事業案の否定
全社系もそうですが、新事業でも同様に、投資・回収を、いきなり既存事業の原価・売上と比較されたりしているんじゃないか？などと考えます。この状態では、難易度の高いプロジェクトが立ち上がらないので、競争力の観点で問題になるんじゃないか？と。
聞いた所によると、VC（Venture Capital）は赤字でも、芯が残るため、投資している企業を買うらしいです。「投資していない会社は、最終的に芯が無くなる。」と言う事でしょうか？
また、昨今は、CS（Customer Satisfaction）が重要になって来ていて、営業（短期の売上）よりサポート（長期的なCS向上）が重要になって来ているようです。確かに、昨今、「顧客満足度の向上に取り組むことがサブスクリプション化を成功させるために重要。」などと言われています。
しかし、これは、
前回にも書きましたが、現時点では、日式企業に、「CSに対する投資」と言っても「？」なんじゃないでしょうか？しかし、翌々考えると、サポートもバリューチェーン上の重要なコンポーネントではあります。そんなこんなで、日本のソフトウェアは海外で採用されないみたいな話もあり、以下の記事では、「"意思決定プロセス"と"プログラマーの立ち位置"が問題だ。」とされていました。
日本では、サラリーマン経営者が、市場調査と長時間の会議で作り上げた「誰が見ても作るべきエビデンスの揃った製品」の仕様書を子会社に丸投げして、それを劣悪な労働環境に置かれたIT土方たちがプログラムに落とし込むという形でソフトウェアが作られている。
また、「"CS重視"の時代に垂直統合も無いだろう。」という話ですが、垂直統合な経営を続けていれば、当然、垂直統合な営業経路しか持っていませんし、そんな中で投資・回収を、いきなり既存事業の垂直統合プロダクトの原価・売上と比較されたりするので、ナカナカ、プロジェクトが立ち上がらないのかもしれません。
...で、こういう問題を解決するタメに、「ステークホルダー・エンゲージメント・マネジメント」が必要なんじゃないかな？等と思っている昨今だったりします。
じゃあ、ステークホルダー・エンゲージメント・マネジメントって何をすればイイのか？という話ですが、先ずは、ステークホルダー自体の教育が必要のような気がしています。しかし、決裁者 ≒ 上役の人間を教育することは難しいので、決裁文書に対して「"決裁者なのに解らない"と言う事自体がNGっポイ雰囲気を醸し出すように決裁文書を作成する。」なんて言うテクニックを駆使する必要があるのかもしれないな。等と考えたりしています。
＜ポートフォリオの考え方＞
個人的には、以下が参考になりましたが、「強みの上に築け（Build on strength）」のような話かと思います。上か横かはわかりませんが。
某弊部会の場合、この「強み」というのは、
この辺に書いた通り、インテグレーション・レイヤに関する周辺のスキルなので、
以前、以下の様な図を書いてみましたが、コレはチョット違うな...と。
特に、「ビッグデータやAIなどの要素技術」と「Open PaaSなどのプラットフォーム」は利用する分野ではあるものの、注力ポイントでは無いんですよね。また、
CIはSI系のライフサイクルにハマらないという結論です。
と言う事で、どちらかと言えば、コッチの方が近いですね。
...で、
ココや
ココにも書いたのですが、コレが 「サービス開発基盤 = 汎用認証サイト + 汎用モバイルバックエンド」施策に（、一応）、繋がっており、もうチョット先、例えば、v3.0を見越すと、「これは（、センサー → デバイス → エッジ → サーバと繋げる必要のある）、IoT系かなぁ？」という気がしてきました。
しかし、単純な繋ぎ目だと差別化困難なので（コレは、「生産性向上と言う意味で、みんなが出来ない所を先回りしてやっておく。」的な意味で）、注力ポイントは、もう少し、手を動かして / 調査して / 特定しておく必要はあるかな。と思います。
パッケージ・サービス系も、既に様々なベンチャー企業や、著名なサービスと戦う必要のあるレッドオーシャンだと思うので、そう考えると、残るのは、事業系のスクラッチ開発と、各種インテグレーション（統合）です。開発基盤部会、≒ インテグレーション部会なんじゃないか？と言う気もしています。
ちなみに、v1.0の時の機能は、大規模な情報システムのスクラッチ開発の生産性向上を達成するアプリケーション開発基盤でした。こちらは、メンテナンス・フェーズに差し掛かっていますが、昨今、この手の基盤を開発している「暇」があるような人も少なく、競合もないので、ぼちぼち使っていって頂けると良いのではないか？と思ったりしています。
SI事業からだと、どうしてもスタートはステップ生産性云々になるので、それすらできてない組織が次のステップ（ポートフォリオ、プログラム・マネジメント）に行ける訳が無いと言う気がします。
＜参考＞
Open COBOL Solution WG
ステークホルダーも納得するポートフォリオ・プログラムを再定義する。
