前回、「Open棟梁プロジェクトの起源について。」の第1回の投稿を行いましたが、今回は、その第2回の投稿です。

　2007年から社内の横展開を開始しました。その時の名称は単に「棟梁」という名称でした。その後のOSS化に伴って2014年に名称が「Open棟梁」に変更されました。

　注意しなくてはいけない事項として、.NET案件は、Java案件より数が少なく、中小規模のモノが多かったため、社内では、投資のペイラインが問題になり易かったと言う問題がありました（簡単に言うと、「大して効果が出てないのに、なんでそんなお金かけてるの？」と言うヤツです）。このため、初めから以下の目標の実現すべく、注意してフレームワークのデザインを行いました。

• デファクト・スタンダードなレイヤを置き換えない。
• 中小規模でも通用するように、迅速な導入を可能にする。
• .NETのサポートする多種多様なアーキテクチャをサポートする。

　まず、基本中の基本ですが「デファクト・スタンダードなレイヤを置き換えない。」というのが重要です。特に、マイクロソフト系技術は、「設計からして高品質で安定しており、デファクト・スタンダードな純正品が後方互換性を維持しながら長期に渡ってサポートされ続ける。」という特徴を持つので、ココと競合するようなプロダクトをリリースすることは全く得策ではありません。このため、Open棟梁では、以下のように注力するレイヤをより上位のレイヤと定義しています。

　また、「中小規模でも通用するように、迅速な導入を可能にする。」・「.NETのサポートする多種多様なアーキテクチャをサポートする。」に対応させたのが、以前「Open棟梁プロジェクトの取組について。」に書いた「IDE + テンプレート + フレームワーク ＆ ライブラリ」という方式です。　

　このような対策が取れたのは、「この取組の前に行われた某フレームワーク開発で、APIマニュアルを提供しているだけでは、テンプレート組み立てに時間が掛かり過ぎ、小規模プロジェクトの場合、工数が掛かり過ぎるということが経験値的に解っていたため、テンプレート・ベースのメカニズムを用意することとした。」ことに起因します。

　そして、Windows Forms、バッチ（Console）など、様々なPresentation層に対応するテンプレートを追加していき、これにより、「中小規模案件にも通用し、多種多様なアーキテクチャをサポートする。」という目標は達成されました。

　球数が多く、案件規模も大きいJava界隈では、このような工夫がされ始めたのは最近のように思いますが、我々は、2007年当時からこのような取り組みを開始しています。昨今はパッケージ・マネージャーなる技術も登場し、この仕組みは更にUXを向上させています。

　以下は、NTTデータ さんの TERASOLUNA Server Framework 5.x の例で、Spring IO Platform (Spring Boot) 方式へ置き換えがされている。

　また、2005年以降、中国への一括外注が加速しており、当初は、以下の図のような「“低品質な成果物が納入され、検収時に蓋を開けてビックリ。”となる問題を防ぐための標準化を行う“ボトムアップ施策”。」ではありましたが、社内案件への導入は順調に加速していきました。


　次回に続く。