この投稿は、
ココの続きなんですが、
前回の投稿を執筆していて、
「十把一絡げにするつもりもないけど、末端プログラマの愚痴って、それを真摯に受け止めてスタックさせていっても製品・サービスのニーズにリーチしない事が多い気がする。」
...と言う事を思いました。
実際、何かしらのdisりのような意見を頂いて、その意見を真摯に受け止めて改善しようと思っても、そもそも、意見の中身は改善提案でも無いですし、ディティールも無いので、何をしたら良いか、全く解らず（と言っても実際は、何もしなくて良いと言う事は解っている）。
...と言う事で、実際の案件でコアに使用しているユーザのQ&A以外の意見が、品質向上（Quality Improvement）に役立った事は一回もありません。なので、ステークホルダー・マネジメントなのか、共生マーケティングなのか解りませんが、何れにせよ、コレ等の主張の見極めが重要になるんじゃないか？と思います。
以下、具体例を2つほど列挙します。
例えば、
前回は、最新アーキテクチャ(笑)
の問題について書かせて貰いましたが、
「それ、最終製品・サービスの付加価値になる訳じゃ無くて、単に、お前が個人的に新しモノ好きなダケだから...。」
と言う事かな...と。
実際に、イノベーター理論、キャズム理論における、イノベーター、アーリーアダプターは新しモノ好きらしいです。アーリーマジョリティ以降の層は、実用性や安心感を重視するので、キャズムを超えられるのは、最低限、実用性のあるものなんだろうな。と思います。
同様に、
生産性10倍オジサンの問題などもあると思います。生産性、10倍オジサンの主張の問題は、
「それ、最終製品・サービスの原価が低減できる訳じゃ無くて、単に、お前が個人的に早く帰れるダケだから...。」
と言う事かな...と。
色々と振返ってみると、利用しているOS、開発言語やエディタ、インデントの話、フレームワーク、ライブラリ云々、趣味で話しているだけならイイですが、ユーザのニーズにリーチしないので、結局、製品・サービスに貢献しません。
なんとなく、エンジニアには
（、明確な用語の定義はありませんが）、
- インカムを得るためのエンジニア
- 原価としてのエンジニア
- アウトカムを造り込むエンジニア
が居るように思いました。
「...で、この手の主張は、主に長年、原価としてのエンジニアに留まっている人から発せられるケースが多いように思います。」
エンジニアのキャリアパスは、原価としてのエンジニアを経験した後、インカムのエンジニア、アウトカムのエンジニアへと分岐して行きます。
Open COBOL Solution WG
ステークホルダーの主張の背景の見極めが重要かも。
