今から１年半ぐらい前、嫁友の義父（御歳75）からソフトテニスに誘われて、やってまして、先日、テニス後に昼から酒を飲んだんですが、その中の話題で、やっぱ、日式って
- 「プロフィット優遇で、ベネフィットには金を払わんので良くない。」
- 「案外、ボトムアップじゃ無い。問題が下から上に上がらない。」
...と認識が、世代は30年以上離れていますが一致して、なんと言うか、「
これって、ある意味、日式的な文化なんだろうな。」なんて、思ったりしました。
そして、
先日言及したプログラムに関する決裁の取得で、また、色々考えなければイケナイ状況が発生していて、今、考えているんですが、
先ず、固定費内の資産計上って、資産計上する施策の経験が有るか無いかの問題で、それ自体は、財務会計上と言うか、業績的に問題にならないんですよね。経験の有・無と言う意味だと、プロフィットとベネフィットを区別して考えたことの無い組織の場合、面倒な事が多いと言う問題はあるかもしれませんが、こう言う話は「現象的な問題」だと思います。
じゃあ、「本質的な問題」ってなんだ？と言う話ですが、コレは、
「流動性が無いから、組織内の固定費 = 組織の成果と、組織内で閉じているからか、考えた範囲で結構沢山の問題が発生している。」
と言う所なんじゃないか？と思います。
以下に具体的な問題の例を何点か列挙してみます。
- 自前主義、出金を嫌う、調達が困難。
- エコシステムやコラボレーションが育たない。
- 工場文化の「工場リソースの有効活用」と変わりが無いので、
マーケットインするような施策は、なかなか出来なさそう。 - ベネフィット創出ではなく、予算達成が目的化する。
（結果、関心を持つステークホルダーの不在に繋がる）。
...と、こんな形で、ベネフィットのサプライサイド側も色々と問題を持っているンだなぁ。と言うことが解るンですが、これ、逆に考えると、ベネフィットのデマンドサイド側（≒ プロフィット側）も問題を持っており、何かと言えば、プロフィットにリーチするまでに必要な段数が少ないベネフィット（施策の成果）を要求するんですよね（費用対効果を短期で求める）。
...で、コレ、原因は既に解っていて、以前も「
ICT認知症のICT介護」の話の中で言及しましたが、ポートフォリオ → プログラム → プロジェクトとブレークダウンを日常的に行っていないので、逆ルートのベネフィット → プロフィットも上手く辿れないと言う話だと思います。
前回も書かせて頂いた
「ポートフォリオ → プログラム → プロジェクト → アウトプット（プロダクト）→アウトカム（ベネフィット）→ インカム（プロフィット）」
ですが、そう言えば、
昔、管理職の東某さんが、
「アイツ等、恐竜の脳位の繋がりしか理解できないんだよ。」
とか、disってたのを思い出したりしました。
（将に、その原因を掘り当てた感ありますｗｗｗ）
...と言う事で、コレも以前から言及している「
担ぐ系」と言うものが出て来るのですが、我々、開発基盤部会は、どちらかと言えば、デマンドサイドに近い立ち位置に立っているので、特定の商材（、例えば認証系なら、特定の認証系商材）を担ぐ位なら、プロトコル（SAML2 と OAuth2 / OIDC ）自体を勉強した方が良くない？と思うことが多いです。
...と言うのも、プロジェクトのデマンドサイドに立つと、使用する製品はケースバイケースで、昨今、有力な製品であってもパートナーに対する影響力が低下している気がします。これには、
- ベンダもパートナーの依存度を減らすように
セルフサポート化の情報開示を進めていると言う事、 - システムの高度化・多様化により、１つの製品で
出来る範囲が相対的に少なくなったと言う事、 - 同様の機能を持つ多数の製品・OSSが存在する事
等が原因としてありそうです。
と言う事で、今回のオチとしては、次回の決裁の際は、このベネフィットがどうやって、プロフィットに関連するか？と言う点を中心にして、説明をしてみたいと思います。前回（2014年のOSSとしての開示決裁の取得）は、これもベネフィットではありますが、QCD向上での説明だったので、違う形で説明してみようと思います。
Open COBOL Solution WG
こないだ、昼から友人（75歳）と酒を飲んだ話。
