大手SI屋のフレームワークはどこまでヤルのか

マフラーだけを作るソフト部品会社、タイヤだけを作るソフト部品会社と、システムインテグレータと呼ぶシステム組み立て会社に分業化することで、インテグレータはソフト部品会社から調達した部品を組み合わせてシステムを構築する。
黒船の大砲がソフト業界に構造改革を迫る：田中克己の針路IT：ITpro

自動車だと、同じマフラーを作り続けることができるけど、システム開発の場合は、同じマフラーを作ることは意味がない。同じプログラムを作り続ける意味がないからね。
SIにあてはめると、外部設計を作り続ける会社、内部設計を作り続ける会社、プログラムを作り続ける会社に分業化するってことでしょ。
今と一緒ジャン。そして、インテグレータが上澄みをはねていくと。
SIerが自動車産業をまねしようとするのはいい加減やめなさい - ひがやすを blog

んー、そういう話じゃないような気がします。単に「自社のフレームワークを作ります。今まではコンポーネントも自社で開発していました。これからは他社やオープンなコンポーネントを積極的に利用して行きます。」みたいなことじゃないかと。確かに、未だに水平分業してる会社は多い（というかほとんどだ）けど…。

これって現状でもプロジェクト単位では既に当たり前にやってることだけど、如何せん知識や手法がプロジェクト単位で閉じてしまい、全社的な基盤と成り得なかった。もしくは優れたフレームワークという商品に成り得るはずだが、既存プロジェクトでは限られた業務への業務パッケージ品としてしか商品化できなかった。こんな課題を解決しようとしてるように読みました。

ただ、これは簡単にはいくのかどうか。

意思決定のスピードとか、フレームワークの不具合対応の体制とか、多岐に渡る案件に対してそのフレームワークはどこまで対応できるのかとか、そしてそもそもフレームワークは商品として成り得るのかという疑問もあり、かなり難しい仕事だと思う。商品化したところで「フレームワークを売るための案件」なんて出た日には本末転倒も甚だしいし。フレームワークにマッチさせた要件定義だなんて、ロクなことはないｗｗ

「フレームワークを適用する」と一言で言っても、実際はその思想に沿った設計やプログラム、はたまたプロジェクト管理方法や契約形態まで求められたりして、結局プログラム・ライブラリ群として一部利用されるだけに終わる可能性もあるし。

これらのSI業界全体として引きずってる課題やソフトウェア屋に本質的に潜在する課題にどこまで対処するつもりなのか、対処できるのか。

んー、あんまり期待しないけどね。