以前、「Open棟梁プロジェクトの取組について。」と「垂直統合型事業モデルのスタックしない問題について。」という2つの投稿を行いましたが、現在、今後の「ソリューション化」に向けての決裁文書を作成していて、「そもそも某弊部会がどのような背景で、このような取り組みをしているのか？」を、改めて纏める必要が出てきたのでココに書いてみました。


　Linuxコンソーシアムが前身となるOSSコンソーシアムは、プラットフォーム（クラウド、ビックデータなど）や、要素技術（認証, AI, IoT, Robotics, Automotiveなど）などを事業で取り扱っている企業の参画が多いですが、弊部会は少々毛色が違って「スクラッチ開発のQCDF向上（ ≒ 生産性向上）」的なミッションが起源となっています。

　この界隈の活動や施策は、あまり表立っていませんが、基本的に各社のコスト・センターが担っていると思います。「生産技術部」や「技術サポート部」などのような名称で呼ばれている部署が各社にあるのではないでしょうか？

　しかし、このようなミッションを持った組織は、昨今のオープン化でミッションの遂行が難しくなっているように思います。技術情報やツールなども、Stack Overflowやら、Qiitaやら、GitHubなど、インターネット上に大量の技術情報やツールがありますので、「クローズドでこれらを開発する意味は既に無くなっている」と思います。そして、これにより、恐らく、「多様化する技術への追随も困難になり、予算面も厳しくなって来ているのではないか？」と思います。

　...とは言え、「IT システムを作り上げるためのソフトウェアを開発する技術に対しても、変化・多様化を続ける要求への柔軟な対応と、変化に即応する迅速で高品質なシステムのデリバリーが求められるようになってきた。」と言うような文言をネットで「サラッと」発見できる昨今、「QCDF向上なんてどうでもイイ。」とも、なかなか言えないのではないでしょうか？

　※ QCDFとは、Quality, Cost, Delivery, Flexibilityの頭文字をとったもので、それぞれ「Q=品質、C=コスト、D=納期、F=柔軟性」を意味する。元々、自動車業界の経営管理論であったQCDに、変化の早い現代の市場で要求されている柔軟性（Flexibility）を加えてQCDFとなった（フォードとGMの逸話が有名）。また、安全性（Safety）を加えたQCDSなど発展を見せている。

　...と言う事で、弊部会では、上記のスライドに記載したような方法で、

　「プロジェクトのエクスパンドとゴーイング・コンサーンを確実なものにします。そして、技術情報やOSSなどのプロダクトをスタックさせることで、スクラッチ＆アドホックな開発のドメインを、汎用汎化＆労働約的な形から、専用特化＆知識集約的な形にシフトさせつつ、よりデマンド・サイドの要求に適合する形にソリューションを変化させていきます。」