最近、思ったんですが、日式のお偉方のマインドってベネフィットよりQCD重視なんですかね？なんて思ったりしました。下らない反論を生まないように、事前に断っておきますが、
「QCD軽視と言う訳では無くて、QCDは当たり前なので、次のステップに行かないとね。」
と言う意味においてです。
何故かと言えば、以前、
予算系の諸問題の話をしましたが、予算の評価は ≒ 予算達成（QCD） + KPI計測で、ベネフィットと言う観点で評価されているケースを見たことが無いので。
また、
以前、書きましたが、昨今、
「営業（短期の売上）よりサポート（長期的なCS向上）が重要になって来ている。」
のと同様に、予算達成（QCD） + KPI計測より、施策の産み出すベネフィットの計測と評価が重要になって来ていると思います。そう言う事もあり、私基準だと、
「施策が産み出すベネフィットの中長期的な評価が無いため、バズワードに飛びついたダケのような予算が立案されて、その予算達成だけで終了する。」
と言うのが日式標準で、「"まともな施策"をやれてる組織は、非常に少ない。」と思っています。
tweetを漁ると、
どちらかというと保守的な大企業が、このままじゃいかん、新しい技術も追って行かねばということで、技術に明るい人を集めて組織を作り、当座流行っているプロダクトを検証してサンプルアプリを作りまくる。自分は大企業に勤めてながら、これが一番嫌いだった。
みんなが「すぐ役に立つもの」に飛びつく時代だから「すぐには役に立たない」ことを楽しんでやってきた人が活躍する。するとそれを見て「すぐ役に立つ」と思って同じことを真似するけど、「すぐには役に立たない」ので挫折する。時間軸を長く取れないヒトがこのサイクルを繰り返すと何も残りません。
等を観測できますが、日式標準とは、
丁度、こんな状況では無いでしょうか。
私は、このベネフィットが産み出せていない状況は、プログラム・マネジメントに問題がある、...というより、プログラム・マネジメントという概念自体が、まだ、日式企業に浸透していないタメだと思っています。と言うのも、私自身、以下の様な経験を持っているからです。
以前、所属していた組織では「Java、.NET、JavaScript、Smartphone、Microsoft関連、各種Automation等々」の技術毎に施策リーダーなるものがアサインされ（私もこの施策リーダーの一員でした）、予算 → 実績を要求されます。
すると、施策リーダー同士、狭い社内マーケット（？）の中でシェアバトルを始めたり、KPIの悪用を考え始めたりと、私がよく言う「スタックしない。」という状況が発生します。この時点で、「プログラム・マネジメントなんて無い。」というのが解るかと思います。
また、社内を対象とした場合、施策の自助努力で実績が伸びる訳ではないので、社内で採用されている数が多い技術に関連した施策のKPIが良くなるに決まっていて、更に、工夫することと言えば、如何に、KPIを伸ばすか？ということで、KPIを「数値的に」伸ばす工夫が始まります。
しかし、これでは、KPIを用いた評価と、実際に産み出すベネフィットの評価は大きく乖離してしまいます。翌々考えると、私、この社内に限定したKPIが馬鹿らしくて2014年度にOSS化をしたんでした。
...と言う事で、施策同士を上記のようなKPIで競わせたら、上記の様に、お互い悪さしますし、また、プログラム・マネジメントとしても成立していないですよね。これにより、個々の施策は、ベネフィットを産み出すこともなく、最終的にはdisconに至ります。...長くなったので、次回に続きます。
Open COBOL Solution WG
QCDよりベネフィット。プログラム・マネジメントの必要性（前編）
