本日の投稿は、いつもの共通基盤ネタの続編（ピンポイントで言うと「開発基盤で起きた事が共通基盤でも起きるフェーズに差し掛かった感。」辺りの続き）になります。

　本投稿のタイトルである「オレオレ・フレームワーク ならぬ オレオレ・プラットフォー ム的な。」の意味は、

　共通基盤、


　と言う話です。

　そもそも、なんで、オレオレになるのか？...本投稿では、その辺りを考えて行きたいと思います。


　「オレオレ」とは、端的に言うと、「低品質な再開発」だと思います。STPのターゲッティングやポジショニングをチューニングして、企画品質を上げた上での再開発はアリだと思いますが、その辺が中途半端だと、オレオレのステレオ・タイプを付与されてしまうんだろうな。とは思います。

　最近、共通基盤に対して思ったことは以下。

• コンセプトが不明確
• ターゲッティング
• ポジショニング
• 必要なサポート運用と、
  リソースのアンマッチ
• オーナーシップ
• 体制（ジョブ）

　で、コレ...、


　と思ったんですよね。

　究極のオレオレ・フレームワークは、特定案件で作成した単なるテンプレート＆ライブラリ（制御の反転や、パッケージ化 → パッケージ・マネージャも使用していない様なモノ）ですね。コレは、通常、制限事項が多く、不特定多数の案件への横展開は不可能です。

　ソコで、制限事項を少なくして行って、不特定多数の案件への横展開を可能にして行く流れが、脱オレオレ・フレームワークの第一歩なんだと思うんですが、次に現れる障害は（、ある種、オブジェクト指向的に）、汎化を続けると、シェアを取れる可能性は高まりますが、実装も付加価値もスカスカになる。って話なんですよね。

　なので、このトレードオフを、どのようにチューニングして行くか？だと思うんですが、通常は、実装をスカスカにしてしまうと、施策としての意味が無くなってしまうので、コンセプトとサポート運用を明確にしていく必要があるのですが、コレ、ちょうど前回に書いた、オーナーシップの話になるんですよね。

　そして、実装しているのは、ジョブ側なのでコレ（オーナー不在の状態でオーナーが検討すベキ事を）を考慮してくれない。みたいな事が起きて、結局、プロジェクトは、チグハグ（な要件 → 仕様 → 設計 → 実装 → 運用）になり、プログラム上でベネフィットを発揮できずに終了する。と言う流れになりガチです。

　コレが、開発基盤の開発プロジェクトが「低品質な再開発」になり、オレオレ・フレームワーク化した流れで、Java Webの黎明期に、各社でオレオレ・フレームワークが乱立したように、昨今の潮流では、各社で取り組まれている「共通基盤」開発プロジェクトが、多数のオレオレ・プラットフォームを爆誕させる頃のように思います。