年明け「
SI事業って今後どうなっていくのか？を考えてみた。」みたいな投稿をしましたが、一見あまり関係ないように見える前回の「
ReactにFragmentのPKCEを実装してて思った事、要件のコンテキストが違う。」と言う技術的な話と、結構リンクしてんな。...と思い、ちょっと筆を執ってみようと思いました。
私、以前から、「
技術でもSTP的な、セグメンテーション・ターゲットがあるんだよ。」みたいなことを言ってきた気がしますが、SPA系のフレームワークの開発を行ている会社、基本的に、サービス系の会社なんですよね。具体的には、Google（Angular）とFacebook（React）です。なんで、SI系にハマらないのは当然と言えば当然だと思います。
以前にも書きましたが、トレンドに乗ってるタームは、そんな感じで、セグメントやターゲットが異なっているケースが多い様に思います。
「クラウド、スマホ、WebAPI、フロントエンド（Native、Hybrid、SPAなど）、認証技術、コンテナ技術、Open PaaS、IoT、ビッグデータ、AI」
そんな中で、
技術的負債と言う言葉を聞く機会が増えてきている気がしますが、これって、結局、
- 「ゲーム・チェンジに伴う、レガシー事業の収益性の低下に起因している。」気がするんですよね。何故なら、メーカーのホスト（ハード・ソフト）が売れて、COBOLのSIで潤沢に儲かっているなら、そんな「負債があーだ、こーだ。」と言う話も出てこないと思うので。
- また、SIでも技術的なトレンドに流されますので（例えば、ブラウザなども、IE固定は通用しなくなってきていて、モダン・ブラウザをサポートに加える必要が出てきている）、新技術を使わざるを得ないケースが増えてきていますが、「セグメントとしてハマらない → マンパワーに対するステップ or FP 生産性は高くない → 開発にかかる費用も高騰」している。
みたいな感じで、みんな困っているンだと思います。
まとめ：
まとめると、
技術的負債云々は、現行の事業の収益性が下がっているが、（事業企画が難しい。設備投資ができない。などの）諸事情あり、このゲーム・チェンジに追随できない。という辺りに問題が在るように思います。
この辺、企画・設備・事業と、"
三位一体、天地人"的な対応が必要になると思うので、設備面だけで、コミットできないと嘆く必要もないかもな。等と思ったりします。ただ、そういう意味では、企画・設備・事業のプログラム・マネジメントと言う形で任務を遂行していく必要があるのかもしれません（しかし、まぁ、それが、全然、出来ていないんですがね。）。
Open COBOL Solution WG
今更、受託開発からサービス開発へのゲームチェンジの話
