ここ、数週間は、この投稿に繋がる布石を打って（≒ プログラム・マネジメントのシナリオ・ライティングによってコンセプトを練る効果に関する説明をして）来ましたので、ソロソロ、題記の件について言及して行きたいと考えています。...で、ｖ３コンセプトに入る前に、ｖ１・ｖ２のコンセプトを今一度、振り返ってみたいと思います。
＜ｖ１＞
ｖ１は、2006年から開発を始めて、2007年に業務系、RDBMSアプリケーションの開発基盤としてリリースした治工具系プロダクトに端を発しており、ソコから大きくコンセプトを変化させずに、機能追加に終止し、2012年位で、大枠やり尽くして、2014年にOSS化。...で以降、2016年頃まで、ブラッシュアップを行いました。
この結果で見えてきた事は、
過去、データ項目辞書を中核とした、設計＆自動生成型のツール等、SIer独自の治工具（
統合CASEツール）がありましたが、コレは疾うの昔にオワコン化しており、昨今の開発基盤の主流は、IDE＆パッケージ＆テンプレートだな。
と言った感じの新事実でした。
と言う事で、本方式で確実にスタックしていくことが結果を出すのに最も明快な道筋であるにも関わらず、周囲を見渡してみるとそう言う施策はあまり見つかりません（disconになったモノが多い）。
これ、実際、どうなの？というと（、出来ない理由は幾つも挙げられると思いますが、企業としてコレ等を突破する方法の検討＆実践が出来ないと言うのは）、ヤヴァいでしょ。と言う事かと思っています。コレが明確化されたのが本バージョンの最大の収穫だったように思います。
これ以降、ｖ１リポジトリは、基本ライブラリ置き場として、ｖ２向けの新規機能を提供するライブラリを格納したり、または、依頼された機能の追加、.NETバージョンアップへの追随等の諸作業をしています。前述のような結論から、まだまだ、disconにはぜず、コミュニティで、現役を継続の予定です。
＜ｖ２＞
＜2.0－＞
ｖ２は、2016年に行ったスタートアップ試行を経由して、Webサービス開発基盤という名称で2017年にリリースを行いました。こちらの中核は、OAuth2 / OIDC、SAML2（に加え、FIDOやFAPI）などの機能も含め実装したAutheNtication / AuthoriZation Serverである「汎用認証サイト」となっています。これをベースとして、Client や Resource Serverを加え、OAuth2 / OIDCアーキテクチャのモデルとなるようなIDE＆パッケージ＆テンプレート群をリリースしています（今後も、CIBAのADや、Device Flowの実装等の継続案件あり）。
ｖ２プロジェクトの遂行によって見えてきたことは、弊部会のコンセプト的に「繋ぎ目部会」と言うエイリアスの発生です。
そして、
- 「スタック＆コラボレーション」の重要性
- 「プログラム・マネジメント」の重要性
が発覚したことでしょうか？
ココ数年の分析結果によると、この変化は、「要素技術のコモディティ化に起因し、多くのベンダが、サプライサイドからデマンドサイドへのシフト」、コレに加えて、「デマンドサイドのデマンドの多様化」に起因しているように思います（メーカーが自前主義を捨てる...それ、もう、メーカーじゃなくね？云々のコンテキストも、同じようにココに起因していると思います）。
＜2.5－＞
ｖ２の後期は、昨今、無視出来なくなって来た、コンテナ技術（Docker＋K8s）のトレンドに乗せて、既存のアセットをコンテナ化したリポジトリの作成を行っています。
特筆スべきは、シナリオ・ライティングをベースに、Web系のCI/CD → DevOpsプラクティスとSI系のCI/CD → DevOpsプラクティスとの差異の明確化を図っている点になると思います。多くのケースで、シナリオ・ライティング部分の欠如によって、STP的にフィットしないテクノロジの（他業界からの輸入的な）導入で失敗するケースが後を絶たないと感じています。
なお、現時点では、Docker Composeのマニュフェスト定義が完了していますので、今後、コレ等をK8sマニュフェスト → Helm Charts → Rancher Chartsとアップグレードしていく予定です。
＜ｖ３＞
長くなってしまったので、
後編に続く。
Open COBOL Solution WG
「Open棟梁」v3コンセプトの青写真が見えて来た（１）
