...と、コレまで再三に渡って、
プログラム・マネジメントの必要性を説いてきましたが、「（プログラム・マネジメントによって結果が出た）実例なんてあんのか？」的な質問をされる可能性がある気がするので、それについて答えて行きたいと思います。
先日、同僚と、施策の展開に関する話をしていて、その中で、
某弊部会のトップページにも貼ってある、以下の戦略に沿った話を幾つかさせて頂きました。
実は（？）、某弊プロジェクト、
- v1.0では、エンタープライズ・システム開発基盤
- v2.0では、サービス開発基盤
- v3.0（予定）では、IoT、ビッグデータ開発基盤
と、結果的にではありますが、
イノベーション・パターン ＋ 段階的パターンのプログラムを組んで進めています。
こういう「バックボーン」を持って、
前回に述べた施策リーダーと対話して、改めて自覚したことは、個々の施策レベルしか把握していないと、戦略レベルが大きく欠如すると言う事です。
前述の「バックボーン」と言うのは、具体的には、2014年度以降にOSSプロジェクトのオーナー経験をもって獲得した、自分なりの
- マーケティング
- プログラム・マネジメント
- ステークホルダ・エンゲージメント・マネジメント
- プロモーション
に関するスキルと言ったトコロでしょうか？
同僚はWeb系フロントエンド・エンジニアの類なんですが、単に「フロントエンドでWebアプリが（、上手く）、組める。」って言っても、正直、あまり響かないですよね。なので、全体のプログラムを見せて、
- 現状、我々を取り巻く、組織体の環境要因は、XXX。
- STPで言うターゲット（T）については、XXX。
- ステークホルダ・マネジメントについては、XXX。
- だから、この辺と連携するとイイんじゃないか？
（これが、≒ プログラム・マネジメント） - そして最終的にどういうポジション（P）を取るか。
みたいなことを説明した気がします。
すると、全体のスケールが見えてきて、自信が無くなり、意気消沈してしまう訳です。なるほど。フロントエンドはナンボでもプログラムに組み込める流行りの技術だケド、技術やプロジェクト単体しか見えて無いと、ある程度の粒度の結果が期待出来無い。逆説的に言えば、大きめの戦略が無いとプログラムにならんのなぁ。などと思ったりしました。
...と言うのが、まぁ、解り易い事例でしょうか。
反面、現在、私が進めている、スマホ系フロントエンド・エンジニアとの連携は上記のプログラム（バックエンド、認証、フロントエンド）をベースにしてスタック＆コラボレーションさせているので、なかなか上手く進んでいると思います。
...と言う事で、今回、色々と書いていて思いましたが、日式の予算方針って、戦略性が殆ど無いんじゃないですかね？
理由ですか？この理由は、
「予算方針が個々の予算取りに利用されていて、実質的なプログラム・マネジメントの観点が無いから。そして、評価が実質的なベネフィットではなく、予算達成（QCD）と、あまり本質を捉えていないKPI計測で終わるから。」
と言ったトコロでしょうか。
Open COBOL Solution WG
QCDよりベネフィット。プログラム・マネジメントの必要性（後編）
