Lumada・Uvance・BluStellarから見るエンジニア採用と働き方の変化

日本の大手SIerは、いま大きな転換点にいます。

日立製作所は「Lumada」、富士通は「Uvance」、NECは「BluStellar」というブランドを掲げ、従来のSIビジネスから、より価値提供型・成果創出型のビジネスモデルへ移行しようとしています。

これまでのSIerは、ざっくり言えば「エンジニアを何人、何か月投入するか」という人月計算モデルが中心でした。

しかし、今後は単に人を出して開発するだけではなく、

顧客の経営課題や業務課題に対して、どのような価値を提供できるか

が重視される時代になっていきます。

この変化は、SIerの事業モデルだけでなく、エンジニアの採用基準や働き方にも大きな影響を与えます。

Lumada・Uvance・BluStellarとは何か

まず、各社の取り組みを簡単に整理します。

日立製作所の「Lumada」は、データ、テクノロジー、知見、人材を組み合わせて、顧客や社会の課題解決を支援するデジタルソリューション群です。日立はLumadaを、顧客との協創を通じて価値を生み出す仕組みとして位置づけています。

富士通の「Uvance」は、ビジネス課題や社会課題の解決を目的としたソリューション群です。富士通は、データ、AI、変革技術を活用し、顧客に実際のインパクトを届ける方向性を打ち出しています。

NECの「BluStellar」は、DXを実現するプロダクト＆サービス、それらを組み合わせたオファリング、さらに経営課題軸で型化した「BluStellar Scenario」で構成される価値創造モデルです。NECは、顧客との共創事例や自社の実践経験からDX成功要因を抽出し、オファリングの組み合わせやアプローチを型化していると説明しています。

つまり、3社に共通しているのは、個別開発をゼロから請け負うだけではなく、過去の成功パターンや技術アセットを再利用し、顧客の成果につなげるモデルを強化しているという点です。

従来の人月計算モデルとの違い

従来のSIビジネスでは、売上の基本は「人月」でした。

たとえば、

Javaエンジニアを5人、6か月アサインします
C#エンジニアを3人、設計からテストまで投入します

というように、エンジニアの人数と稼働期間をもとに売上が決まるモデルです。

もちろん、このモデルにもメリットはあります。
顧客側は必要な人材を確保でき、SIer側も安定した売上を立てやすいからです。

しかし、人月モデルには限界もあります。

人を増やさないと売上が増えにくい。
優秀な人材に依存しやすい。
案件ごとにゼロから開発するため、再利用性が低い。
そして、顧客から見ると「結局、何の成果が出たのか」が分かりにくい。

そこで各社は、オファリング型・価値提供型のモデルへ移行しようとしています。

オファリング型ビジネスとは何か

オファリング型ビジネスとは、簡単に言えば、

ある業務課題に対する解決策を、あらかじめサービスやソリューションとして型化して提供するモデル

です。

たとえば、以下のようなものです。

顧客課題	オファリング例
老朽化した基幹システムを刷新したい	モダナイゼーション支援
データを活用して経営判断を早くしたい	データ分析基盤・BI導入
問い合わせ対応を効率化したい	生成AIチャットボット
工場の稼働状況を可視化したい	IoT・データ連携基盤
セキュリティリスクを下げたい	セキュリティ運用・監視支援

このモデルでは、毎回ゼロから開発するのではなく、過去の成功事例、テンプレート、クラウド基盤、AIモデル、業務ノウハウを組み合わせて提供します。

つまり、

人を売る
から
解決策を売る

への転換です。

エンジニア採用はどう変わるのか

この変化によって、エンジニア採用の見られ方も変わります。

従来は、

Javaが何年できるか
C#が何年できるか
SQLが書けるか
詳細設計、製造、テストの経験があるか
常駐先で問題なく稼働できるか

といった点が重視されやすい傾向にありました。

もちろん、これらのスキルは今後も重要です。
しかし、それだけでは差別化しにくくなります。

今後は、以下のような観点がより重要になります。

従来重視されやすかった点	今後より重視される点
言語経験年数	業務課題を理解する力
製造・テスト経験	要件定義・改善提案の経験
指示された作業の遂行	顧客への価値提案
個別開発スキル	標準化・再利用の視点
常駐先での安定稼働	チームで成果を出す力
技術単体の知識	AI・クラウド・データ活用の組み合わせ

つまり、これから求められるのは、単なる「作れる人」ではありません。

業務課題を理解し、技術を使って成果に変えられる人です。

「エンジニア」は「ソリューション人材」に近づく

オファリング型・成果ベース型のビジネスが進むと、エンジニアの役割も変わります。

従来のエンジニアは、主に仕様書をもとに設計・実装・テストを行う役割でした。

しかし、今後はより上流に近い動きが求められます。

たとえば、

顧客の業務課題をヒアリングする
業務フローを整理する
どこにAIや自動化を使えるか考える
クラウドやSaaSを組み合わせて解決策を設計する
導入後の効果をKPIで確認する
改善案を継続的に提案する

といった動きです。

これは、従来の開発エンジニアというより、ソリューションエンジニア、DXエンジニア、業務コンサル寄りSEに近い役割です。

今後は、以下のような職種がより増えていくと考えられます。

職種・役割	主な仕事内容
ソリューションエンジニア	顧客課題に対して、既存サービスやクラウド、AIを組み合わせて提案・実装する
DXエンジニア	業務改善、データ活用、AI導入、システム刷新を支援する
モダナイゼーションエンジニア	老朽化した既存システムをクラウド・API・マイクロサービス前提に刷新する
データ／AIエンジニア	業務データを活用し、分析・予測・自動化につなげる
テックリード／アーキテクト	再利用可能な設計や標準化をリードする
業務コンサル寄りSE	業務課題を整理し、システム要件や改善施策に落とし込む

働き方は「常駐型」から「チーム・サービス型」へ寄る

働き方にも変化が出ます。

従来のSI・SESでは、顧客先に常駐して、現場の指示に従って作業する働き方が多くありました。

しかし、オファリング型では、自社が持つソリューション、テンプレート、クラウド基盤、AIサービス、業務ノウハウを活用して、チームとして顧客に価値を提供します。

そのため、働き方は以下のように変わっていきます。

従来の働き方	今後の働き方
顧客先常駐が中心	自社チーム・リモート・ハイブリッドが増える
個人単位でアサイン	チーム単位・サービス単位で提供
案件ごとにゼロから開発	共通部品・テンプレート・オファリングを活用
開発して納品したら終了	導入後も継続改善・運用支援
指示されたタスクを実行	課題発見・改善提案まで担当

つまり、人を貸す働き方から、価値提供チームとして動く働き方に寄っていきます。

人月モデルは完全になくなるのか

では、人月モデルは完全になくなるのでしょうか。

結論から言うと、すぐにはなくなりません。

現実のSI案件では、個別開発、保守運用、システム改修、テスト支援など、人手が必要な仕事はまだ多く残ります。

また、顧客側の予算管理や契約形態も、すぐに成果報酬型へ変わるわけではありません。

そのため、しばらくは、

人月型
準委任型
請負型
サブスクリプション型
成果連動型
オファリング型

が混在する状態が続くはずです。

ただし、大手SIerの成長戦略としては、明らかに

個別受託開発
から
オファリング化・高付加価値化・継続収益化

へ向かっています。

評価されやすくなるエンジニアの特徴

この流れで評価されやすくなるのは、以下のようなエンジニアです。

評価されやすい特徴	理由
業務理解ができる	顧客課題を技術に落とし込める
要件定義に関われる	成果につながるシステム設計ができる
改善提案ができる	価値提供型の仕事と相性が良い
AI・クラウド・データに触れている	オファリングの中核技術になりやすい
運用改善の経験がある	導入後の継続改善に活かせる
標準化・共通化の視点がある	再利用可能なソリューションを作れる
顧客と会話できる	課題発見や提案につながる

逆に、以下のようなタイプは評価が伸びにくくなる可能性があります。

指示待ちで作業だけをする
業務理解に興味がない
技術をビジネス成果と結びつけられない
新しい技術に触れようとしない
テストや保守を単なる作業としてしか語れない
自動化・改善・標準化の視点がない

重要なのは、製造やテスト、保守運用の経験が不要になるわけではないということです。

むしろ、それらの経験を、

品質改善
業務効率化
運用改善
自動化
標準化
顧客課題の解決

という文脈で語れる人は、今後も強いです。

SESエンジニアはどう対応すべきか

SESエンジニアにとって、この変化は危機でもあり、チャンスでもあります。

なぜなら、ただ「現場で作業しました」と見せるだけでは、今後は作業者として見られやすくなるからです。

一方で、現場で顧客業務を見てきた経験は大きな武器になります。

SESエンジニアは、さまざまな現場で、

業務システムの課題
現場の非効率
テストや運用の問題
部署間の認識ズレ
古いシステムの使いにくさ
データ活用の遅れ

を実際に見ていることが多いです。

これを単なる作業経験で終わらせず、

現場課題を理解し、改善提案やシステム改善につなげた経験

として整理できれば、DX推進やソリューションエンジニア寄りのキャリアに転換しやすくなります。

職務経歴書ではどう書くべきか

今後の採用では、職務経歴書の書き方も変える必要があります。

たとえば、以下のような書き方は少し弱いです。

詳細設計、製造、単体テスト、結合テストを担当。

もちろん事実としては必要ですが、これだけだと「作業範囲」しか伝わりません。

より強く見せるなら、以下のように書きます。

業務システム開発において、仕様理解、設計、開発、テスト、運用保守まで一貫して対応。テスト結果や運用上の課題をもとに改善案を提案し、品質向上および業務効率化に貢献。

さらにDX寄りに見せるなら、以下のような表現も有効です。

顧客業務や既存システムの課題を把握し、システム要件や改善施策に落とし込む経験を積んできました。今後は、クラウド、生成AI、データ活用を組み合わせ、顧客の業務変革やDX推進に貢献したいと考えています。

ポイントは、担当工程だけでなく、何を改善したのか、どんな価値につながったのかを書くことです。

これから身につけたいスキル

Lumada、Uvance、BluStellarのような価値提供型モデルを意識するなら、今後は以下のスキルを伸ばすと有利です。

分野	身につけたいスキル
業務理解	業務フロー整理、課題分析、要件定義
クラウド	Azure、AWS、GCPの基礎、クラウド設計
AI活用	生成AI、RAG、AIチャットボット、業務自動化
データ活用	SQL、BI、データ分析基盤、可視化
モダナイゼーション	既存システム刷新、API化、クラウド移行
提案力	課題整理、改善提案、資料作成
運用改善	監視、障害対応、手順化、自動化
標準化	テンプレート化、共通部品化、ナレッジ化