前回は「組織的プロジェクト・マネジメント（OPM）」のフレームワークやプロセスについて書いてみましたが、オッサンになればなるほど「プロセス～、プロセス～」と言うようになりガチです。

　しかし、実務を軽視して、実務能力が伴わなくなると、一見、正しい戦略のように見えて、「戦術レベルで実現不可能な戦略」を造ってしまうことになると思います。と言う事で、私も、まだ若いつもりですし、今回は、フレームワークやプロセス偏重にならない、ボトムアップでのビジネス・ケースの作成方法について書いてみようと思います。

---

　先ず、前提ですが、アウトカム（成果）、ベネフィット（恩恵・便益）を得るためにアウトプット（技術情報、プロダクト・プロセス資産、施策）のレイヤは、事業やサービスのコンテンツで決まるような気がします。コレは何故か？という話ですが、単純に、アウトプットを事業やサービスで使うため、事業のレイヤに近い位置のアウトプットと親和性が高いと言う事かと思います。


　...で、サービスのコンテンツとしてはB2B、B2Cとか、そう言う軸を最初に思いつきますが、レイヤを決めるには、「商材の粒度」とか、「換金の速さ」とかの軸が有用そうです。

　例えば、「換金の速いスキルセット」を持つ人員が、「粒度の大きい商材」を売ってる会社にいるとサポート・エンジニア扱いなったりするかと思います。また、このサポート・エンジニアのポジションも、事業形態によって変わって来そうではります。

　例えば、バリューチェーン中の「主活動」に対する「支援活動」のアクティビティがより重要になるような、パッケージ・プロダクト事業の場合、サポート・エンジニアはフロント・オフィスと連動する度合いが高まるケースが多そうですが、プロジェクト型の事業の場合、バック・オフィスでリアクティブな対応を強いられるケースが多そうです。

　※ ここで、サポート・エンジニアを引き合いに出す理由としては、サポート・エンジニアが、主な、アウトプットの開発を担うため。

---

　...要するに、何が言いたいか？と言うと、


　と言う事です。

　しかしながら、ワンストップでの対応が必要と言う、（製品やサービスのユーザと距離が近い）上位レイヤの企業であれば、結局、フルスタックのスキルセットが必要にはなると思います。なので、予算が付き易くなる様に、自社サービスのレイヤに寄ったプロダクト（プロジェクト）にする必要は、必ずしも無いんじゃないか？と思います。

　...とは言え、アウトカム（成果）、ベネフィット（恩恵・便益）は求められるので、「...じゃあ、どうすればイイのか？」という話になりますが、「得意分野のアウトプット」を上位レイヤに届けるためにスタックさせる「追加の価値提供レイヤ」が必要になると思います。スタックしない下位レイヤは、いくら高品質であっても、上位レイヤから見て価値が殆ど無いケースが多いです。



　例えば、流行りのアーキテクチャに思いっきりフォーカスしてみたら、どうなるか？と言う事で、一昔前に、SPA - WebAPI - EFの素描テンプレートを制作してみたのですが、結果として、「...ゴミやんけ。」ってなった事がありました（既に、記憶の彼方で、調べたら、既に削られてた）。この感想、プロバイダ側の主観的な感想ですが、プロバイダ側がクライアント側のニーズを適切に理解していれば、双方の意見は一致すると思います（この具体例として、コチラの事例がある）。従って、こちらも素描ではなく「追加の価値提供レイヤ」が必要になります。

　...で、現在、私のプロジェクトで重要性が高まっているのは、下位スタックの「Linuxの基礎知識」だったりします。WSLやDockerでサクッとNode.jsや.NET Core用の開発・検証環境構築したいんですよ。

　...つまり、プログラム・マネジメントを行わなくても、多くのリソースを投入しなくても、自分の得意分野である下位レイヤの粒度の細かなアウトプットから、自社の事業・サービスに近い上位レイヤに向けて確実にスタックさせていけば、比較的、低いリスクで、アウトカム（成果）、ベネフィット（恩恵・便益）を出せる。という話です。