弊部会の１サブワーキングであるOpen棟梁プロジェクトは、かれこれ10年以上の歴史を持つ開発基盤であるOpen棟梁を中心とした、開発基盤のマーケティング / 設計・開発 / プロモーションを行っています。
私の周りで10年以上、継続しているプロダクトも少なくなってきたので、disconにならずに「
様々なスタックできる施策がオープンになってくるとイイな。」と言う事で、今回は、このプロダクト（開発基盤）の設計ポイントについて言及したいと思います。
＜アウトライン＞
- プロダクトの「核」は長期に渡って変わらない。
- 新技術が前述の「核」に喰い込む事は少ない。
- 指標を適切に設計する（本質的な価値にフォーカス）。
- 業務系とはレイヤが違う（ドメインの違いを意識する）。
- ユーザの声を聞くのではなく、行動を見る。
- 開発基盤やデザイン・パターンの知識を得る。
＜プロダクトの核は長期に渡って変わらない。＞
プロダクトの「
核」を適切に設定すれば、コレを長期に渡って不変にできるため、プロダクト開発の生産性を向上させることがデキます。故にプロジェクト初期に「核」をどのように設定するかが非常に重要になってくると思います。例えば、弊プロダクトの「
核」は、開始当初から変わらず、
（１）「
標準化と共通化」
（２）「
各種支援機能（ツールやライブラリ）の再利用」
によるQCDF向上。としています。バージョン 2 から、コンセプトを「
スクラッチ開発支援」から「
サービス開発支援」に刷新しましたが、「
核」となる基本路線には、プロジェクト開始当初から大きな変更はありません。
なによりも、継続的にスタックさせる事が重要になるので、自然と、技術と事業との親和性を考慮して決定するのが重要になると思います。Open棟梁は、これらの親和性を考慮して「
IDE + テンプレート + フレームワーク ＆ ライブラリ」というタイプ（ポジション）の方式を採用しています。
...コレを書いた後に、「
核」って結局なんなのかな？と再考してみましたが、なんとなく、組織の「ビジョン」・「ミッション」に即した内容なのではないか？と思いました。「（プロダクトの）コンセプト」はその下位の概念のように思います。
＜参考＞
＜新技術が前述の「核」に喰い込む事は少ない。＞
これは、単純に、前述した「核」≠ 新技術ということです。従って、新技術に振り回されるような状況は、止めたほうがイイと思います。新技術は、UIやデータ・アクセスや、プラットフォームなどの各レイヤを刷新することは多いですが、これらはコンパチブルなことが多いです。
データ・アクセス系は、アプリケーションの
STPから何を選択すべきか？がワリと明確ですが、UI系は、クロスプラットフォーム、スマホネイティブなどの要件を無視できないことが多く、残念ながら振り回されることが多いです（過去にも多種多様なUIサブシステムとのフィッティングを行った結果のテンプレートをリリースしてきていますが、disconとなったテンプレートも多いのが実情です）。
その他の部分については、Web Forms、Windows Forms、ADO.NET、.NET Coreへの移行など、.NETは下位スタックが安定していたため、コレに助けられた気がします。
＜参考＞
＜指標を適切に設計する（本質的な価値にフォーカス）。＞
内部指標（内部市場シェアや注目の新技術）を拠り所としているモノはdisconになることが多いです。本質的な価値にフォーカスすることが重要になると思います。
- 内部市場シェア：
例えば、内部市場でシェア的に優位な技術を選択すれば、内部指標的には好調を維持可能ですが、それをオープンにして独自性を維持できない場合や、内部のステークホルダーにしか有効でない場合は、統廃合などでdisconになることがあります。統廃合の際は、機能的優劣ではなく、組織の力関係などで生・死が決定されます。 - 注目の新技術：
例えば、注目度の高い新技術へ取り組んだ場合、内部市場でのポジショニングは優位となり、予算獲得はし易いことが多いと思います。しかし、Buzz率も高く、また、オープンな技術の場合は、レギュレーション変更に近いので、施策自体の価値が低く、技術の変遷によって注目度が下がれば、自然と指標を維持できずdisconになることがあります。
＜参考＞
＜業務系とはレイヤが違う（ドメインの違いを意識する）。＞
エンタープライズ・システムの各業務毎の差異を開発基盤に取り込むべきか？と言うと、コレについてはNOと思います。絞り過ぎると、ペイラインに乗らなくなるためです。ペイラインに乗らないプロダクトの品質は上がりません。それ以前に、disconになると思います。
しかし、業務というより、ドメイン（セグメント/ターゲット）の違いは意識する必要があるかと思います。例えば、エンタープライズ向けのスタックと、ゲーム向けのスタックでは、設計思想が大きく異なります。
観測しているとゲーム系のスタックでは、Unity＋Reactive Extensions＋MessagePackと言ったスタック構成が観測できます（素晴らしい取り組みだと思います）。しかし、これは、エンタープライズのスタック構成とは大きく異なります。同様に、IoTやWebAPIのエッジ系なども設計思想が大きく異なると思います。
このため、これらのドメインに向けて、新たなプロダクトを提供しようと考える場合、コンセプトや設計思想を変えた別のプロダクトを提供するのが良いかと考えます。
＜ユーザの声を聞くのではなく、行動を見る。＞
サプライ・サイドは、デマンド・サイド（ユーザ・サイド）とは関心ごとや、注力するレイヤが大きく異なるので、デマンド・サイドはどうしても開発基盤に対する知見が薄くなりがちです。
同様にベンダ側を見渡しても、特殊なミッションを遂行している組織でなければ、デマンド・サイドが多く、サプライ・サイドの識者は殆ど居ない様に思います（上位スタックは、関連する下位スタックが多いので、其々に対する知識が薄くなるため、ユーザが下位特性を考慮した設計をするのは困難）。
https://twitter.com/manabuueno/status/1024481185261486080 従って、ユーザーのフィードバックとしては「意見」では無く「行動」に留意すべきです。上位スタックで発生した問題（対策 / 回避 / エスカレーション）の根本原因分析後にソリューションを下位スタックに実装し、適用後にUX上の問題のフィードバックを得るのが良いです。
＜参考＞
このような理屈でプロダクトの実装が進むため、開発基盤のプログラムの価値は、「規模」でなく「仕様」なのだと思います。そして、その「仕様」は、上位スタックで発生した問題を適切に回避し得るモノである必要があります。
＜開発基盤やデザイン・パターンの知識を得る。＞
最後に、当たり前と言えば当たり前ですが、
ベース・ラインとして、開発基盤の設計を行うのだから、開発基盤自体の知識があった方がイイです。また、「
IoC、AOP → DI → 依存性反転原則」などの、フレームワーク開発に役立つデザイン・パターンの知識などもあった方がイイと思います。
＜参考＞
トップページ
お知らせ
開発基盤部会
10年以上、継続するプロダクト（開発基盤）の設計ポイント
