最近、某プロダクトのサブシステム開発をしていた、若手と一緒に、
以前、言及したプロダクトの開発の仕事をしていますが、教えることがワリと沢山あります。
この中で、「日式メーカーのプロダクトってキャパシティ低いんだろうなぁ。」というのをヒシヒシと感じたりします（個人の能力という話ではなく、仕事のやり方とか、事業スキームの話です）。
まぁ、噂では（、昔、ナントカ developerさんが言っていた様に）、リファクタリングを許さない汚いコードベース。みたいな話を聞くので、間違いなく、キャパシティは低いんでしょう（昔、
ココにも書きましたが）。
こういう話を聞いて思うのは、「やっぱり、ソフトウェアを受発注で開発している限りこの問題は解決できない。」と言うような事です。何故なら、キャパシティを上げることに、発注先がメリットを感じないからです。
...と言うのを、以下、別件で、色々と分析していて思ったのですが、
＜参考＞
...タイトルにもある「日式メーカーは何故、垂直統合をやめられなかったのか？」については、「悪循環（負のスパイラル）に陥ったから。」だと思います。
具体的...と言うか、単純に言うと、キャパシティの上がらない中で、国際競争を行うオープン化の方向に舵を切ることができず、垂直統合に引き篭もってしまったことが、更なる収益性やキャパシティの低下を産んだんでしょう（他にも、
コチラに書いたように、1980年代に発生した前提条件と言うか制約条件が、原因としてあったのかもしれません）。
...で、ですね、コレは未来の話ですが、昨今、以下のように、様々な「ちゃぶ台」返しが横行しているので、
＜参考＞
このような、問題にも終止符が打たれるかも知れません。
簡潔に言うと、SI起点の垂直統合事業が終わり、プロダクト / ソリューション / サービスの内製化にシフトするかも知れないということです。まぁ、5年 / 10年かかるのかも知れませんが、もっと早いかも知れません。
...と、言う事で、皆さん、備えましょう
♨。
Open COBOL Solution WG
