以前、「開発支援ツールとは？ その種類と特徴を、まめてみした。」というタイトルで投稿を行いましたが、この時作成したスライドを少々弄ったら、「Open棟梁プロジェクトの取り組みについて」説明するのにイイ感じのスライドになったので早速シェアしようと思います。

---

　・・・フレームワークには以下のものがあります。フレームワークという言葉、いろいろな解釈をされるので定義してみました。

　フレームワークは、特定のユースケースを抽象化します。この抽象化によって、「スタック（積み上げ）」が可能になります。
　※ 抽象化 = 「簡単に説明する。」・「ブラックボックス化する。」など。

　フレームワークを別の言い方で表現すると、PMBOKの「企業知識ベース」でしょうか。ソフトウェア開発の範囲で言うなら（フレームワークより上位の概念ですが、）「開発基盤」という言葉もフィットする気がします。この構造は、下図のように表せるのではないか？と思います。

　　　　　　　　　┌ ビジネス企画 > BABOK関連の企業知識ベース
 ● 企業知識ベース  ┼ プロジェクト管理 > PMBOK関連の企業知識ベース
　　　　　　　　　└ プロダクト設計・開発 > 開発基盤 > Software Framework

　昨今、特に「ソフトウェア・フレームワーク」などの場合、クローズドなプロジェクトと比べると、オープンソース・プロジェクトとした方が圧倒的にスタックし易いと思います。また、オープンソース・プロジェクトに企業として貢献した場合、「企業知識ベース」に対して貢献に等しいのだから、貢献の評価方法が明確になっていくと良いかもしれません。

---

　・・・と、「スタック（積み上げを）」せずに「DRY（Don't repeat yourself）」に逃げても、なにも改善はしないので、「どんどんオープンソースなプロダクトをアウトプットして、更に、それをパッケージ・マネージャーに放り込む。」などまでできるようになると、労働集約的な日式 SIer 業界も少しは良くなるんじゃないか？などと思ったりします。

　しかし、実際の所、オープンソース・プロジェクトと言えども、単に個人や組織間で連携するというのは難しく、始めは、なかなか上手く行かないと思うので、引き合わせでスタックすると言う戦略を実現するような「KPIと施策」を意識的に決定するのがイイんじゃないか？などと考えています。そして、エコシステム形成のために「ステークホルダー・マネジメント」を始めるのが良いかもしれません。最終的には、ソレが、企業内での「組織的プロジェクトマネジメント (OPM)」へと繋がっていくと良いかと思います。

＜参考＞