以前、担ぐ系のラインナップ拡充をdisりましたが、これプログラム・マネジメントとも実は違うんじゃないか？と思ったりします。なんとなく、これが、
前回に書いた「垂直統合事業的文化は、営業面など含めてわりと残っている気がします。」なんじゃないかな？と。
具体的なTO-BEはイマイチ解りませんが、以下のスライド（一週間経たずに2万PVにリーチした、かなーり凄いスライド）を見ると、何かしら、答えに近づいた気がしました。
アジャイル ＆ DevOps的なタイトルですが、内容は、
「個々の事業（プロジェクト）のマネジメントと言う意味では、プログラム・マネジメントっぽいな。」
なんて、P22辺りを見て思ったりしました。そして、下記は、冒頭のP11と最後のP109のサマってみたものですが、
- 自分の頭で考える
→ それが成立している前提条件を自分の頭で構造として捉える。 - 前提を意識する
→ ビジネス構造の理解、組織力学（の理解） - 眼の前の現実を起点に考える（べき論からはじめない）
→ うまく行っている仕組み、取り組み、文化、制度
（≒ 持続している企業・事業）にはそれが成立する前提がある。 - 振る舞いが安定してから名前を付ける
→ 「○○さんの動きかたをプロダクトオーナーとしましょう」とか。 - アウトカムにフォーカスする
→ フロー効率性とリソース効率性、再入門 #devlove #devkan
https://www.slideshare.net/i2key/devlove-devkan-103489350 - 決定を遅らせる
→ PDCAではなくて、OODAみたいな話。
この例は、結局、
「教科書通りの適応型ライフサイクル（アジャイル）と言うよりも、アジリティ高めのVモデルのマネジメント手法を新規事業開発に用いる事でベネフィットを提供している。」
と言う事だと思います。
やはり（、当たり前のことですが）、（基本的には既存）事業にどのようにベネフィットを提供しているか？が重要なんでしょう。これを某弊部会自身に当てハメて考えてみると、
「個々の技術をスタックさせ開発基盤（治工具）を構成する。」と言う活動は、既に、頭打ちな感じになっているので、「マーケティングと技術の両面でコラボレーションを実現してベネフィットを産み出していく。」的な活動にシフトして行く感じで、某弊「開発基盤部会」の「繋ぎ目部会」化が必要なんじゃないか？
と思ったりしました。このトランスフォーメーションについては、おいおい考えて行きたいと思います。一方で、「担ぐ系」については、
ラインナップ拡充しても、売れ筋か否かで、甲板の上か船底か的な差が出ますし、一部が売れても、全体としては「働けど働けど猶わが生活（暮らし）楽にならざり、ぢっと手を見る」的な感じ（≒ XXXソリューションと言っても、XXX系のサポート全般を引き受ける訳では無い）なので、その辺を考慮して、全体のプログラム・マネジメントが必要なんじゃないか？
と思ったりします。確かに、昔は、「ラインナップの無い所にサポートが必要。」と考えていましたが、元々、ソリューション系の組織が、社内向けにKnowledge baseなんて公開しないですし、昨今、技術の多様化もあってか、
「ラインナップがあってもサポートは無いので、その辺は、ちゃんとサポート・プロジェクトのプログラムに組み込まないとイケナイんだな。」
って思いました。この背景には、昨今、営業（短期の売上）よりサポート（長期的なCS向上）が重要になって来ていると言う事もあるんじゃないか？と思っています。
なお、こちらのスライドを作成された方は、過去に大手SIerで官公庁の（重厚長大な）システム開発に携わっていたらしく、プロフィールは、以下に掲載されていてコチラも参考になります。
＜参考＞
トップページ
お知らせ
開発基盤部会
担ぐ系のラインナップ拡充とプログラム・マネジメントの違い
