日本のパッケージベンダーが駄目な理由

ひがさんのBlogを読んで、日本のパッケージベンダーが駄目な理由が垣間見えた気がした。

スルガ銀行のIBM提訴にみるパッケージビジネスの難しさ

SIerが自動車産業をまねしようとするのはいい加減やめなさい

日本のパッケージベンダーが駄目な理由は2つある。
一つは、パッケージそのものが変化に対応しきれないこと。
もう一つは、分業化しすぎて技術力そのものが劣化していること。

金融系の勘定系システムは、大手SIベンダーのメインフレーム上のパッケージ製品が多い。
だが、それは余りにも大きすぎて、誰も仕様も技術も全部は分からない。
パラメータTblに顧客ごとの値を設定してカスタマイズすれば、すぐにできると宣伝するが、実際は、顧客の要求に合わせていくうちに、元々のパッケージと似て似つかぬシステムになる。
品質も保守性もボロボロになるのがいつものパターン。

ソフトウェアプロダクトラインの発想がそんな難問を解決するように思ってきたが、実際は、コア資産となるライブラリを抽出し再利用する所まで持ち込めない。

ひがさんの言うとおり、薄いフレームワーク上で、一からスクラッチで開発する方が早くできる。

また、ひがさんが話すように、SIerが自動車産業を参考にするのは危険だ。
自動車産業は、マフラー、エンジン、タイヤなど多くの部品単位の会社に分業化され、その部品をJustInTimeで、トヨタなど一部の大企業がかき集めて、大量に製品を作る。

SIerが分業化すると、要件定義する会社、設計する会社、プログラミングする会社などのように分かれる。
だから、多重の下請け構造が発生し、コミュニケーションロスがプロジェクトマネジメントを阻害し、更には、元請が手配師しか脳のない集団になる。
プログラムをまともに書けない会社が牛耳ると言う皮肉な構造。

最悪な元請は、自社で開発したフレームワークを開発者に押し付ける。
特にパッケージベンダーがその例に当てはまる。

大手SIerのパッケージ製品は、自社で開発した独自のフレームワークで作っているケースが多い。
そのフレームワークは、作った当初は最新だったかもしれないが、3年も経てば時代にマッチしなくなる。
それらは、Seasarの根本思想であるDIやAspect、Railsが持つREST思想なんて反映しているわけがない。
開発プロセスも、メインフレーム時代のものをオープン系に置き換えただけのドキュメント駆動型に過ぎない場合が非常に多い。

プログラマはプロジェクト単位で常駐先を転々とするから、大手SIerのプロジェクトに携わるたびに、そのフレームワークを覚えなければならない。
技術者としては、オープンソースライブラリの方がはるかに使いやすいのに、低レベルなSIerのフレームワークのAPIを覚えるのが苦痛だ。
オープンソースのライブラリならば、どこに行っても通用するのに。

現代は、自社の内部でハードやライブラリを作りこむよりも、オープンソースをうまく使う方が実は品質もコストも良いと言う時代。

その体制を作り出すには、自社の技術者が常にオープンソースライブラリを調査して、その技術の先進性を見極めるという高度な能力を必要とする。
手配師だけの会社では成り立たない。

自社で全て自前で作れるだけの技術力とマネジメント力を持ち、更にオープンソースを研究し尽くすパワーがあること。
その2つが、日本のパッケージベンダーには決定的に欠けている。