SESで現場経験を積んできたエンジニアの中には、「このまま客先常駐を続けていていいのだろうか」と考えたことがある方もいるのではないでしょうか。技術力は上がっている実感がある。でも、自分たちで仕様を決めて、設計して、最後まで責任を持って納品する——そういう経験がなかなか積めない。

Codenceは今、SES事業を軸にしながら受託開発事業をゼロから立ち上げようとしています。この記事では、「受託開発の立ち上げフェーズに参加する」ということが、エンジニアのキャリアにとってどういう意味を持つのかについて書いてみます。

SESの現場で得られるもの、得られないもの

まず前提として、SESの仕事を否定したいわけではありません。私自身、Railsエンジニアとして複数のSES現場を経験してきました。そこで得たものは大きい。

SESでは、さまざまな業界のシステムに触れることができます。金融、物流、EC、公共——業界ごとにシステムの設計思想やデータの持ち方が違う。金融系ではトランザクション管理やデータの整合性に対する要求水準が極めて高い。EC系では大量のアクセスをさばくためのパフォーマンスチューニングが日常的に求められる。こうした業界ごとの違いを肌で知っていることは、エンジニアとしての引き出しを確実に増やしてくれます。

技術スタックの幅も広がります。Javaの現場もあればC#の現場もあり、フレームワークやインフラ構成も現場ごとに異なる。ある現場ではSpring Bootでマイクロサービスを組み、別の現場ではASP.NET Coreでモノリシックなシステムを保守する。「この技術しか知らない」という状態になりにくいのは、SESの強みです。

それに、短い期間で多くのチームと仕事をするので、人との関わり方も自然と鍛えられます。現場ごとにコミュニケーションのスタイルが違う中で、すぐに適応してチームに溶け込む力。初対面のメンバーと短期間で信頼関係を作る力。これらは意識しないと見落としがちですが、エンジニアとしてかなり大きな武器になります。

一方で、SESの構造上どうしても経験しにくいことがあります。

要件定義の最上流から関わること。技術選定の判断を自分たちで下すこと。品質に対して最終的な責任を負うこと。クライアント先のチームに合流する形で働くSESでは、これらの経験は限定的になりがちです。もちろん現場によっては上流工程に関われることもあります。ただ、「自分たちのチームとして、プロジェクト全体を回す」経験とは性質が違います。

SESの場合、プロジェクトの成否に対する責任は基本的にクライアント側が負います。だからエンジニアは与えられたタスクに集中できる。それはそれでメリットではあるのですが、「プロジェクト全体を俯瞰して、何を優先すべきかを自分で判断する」「スケジュールが遅れたときに、どこを削ってどこを守るかを決める」という経験は、どうしても積みにくい構造です。

3年、5年とSESを続けてきた方の中に、「技術力は上がったけれど、プロジェクトを動かす力がついている実感がない」と感じる人がいるのは、この構造的な問題が背景にあります。技術力は申し分ないのに、転職面接で「プロジェクトマネジメントの経験は？」「要件定義に関わったことは？」と聞かれると答えに詰まる。そういう方は少なくないのではないでしょうか。

受託開発では、クライアントから「こういうシステムを作ってほしい」という依頼を受けて、自分たちのチームで設計・実装・テスト・納品まで一貫して行います。

この「一貫して行う」という点が重要です。

要件定義では、クライアントのビジネス課題を理解し、それをシステム要件に落とし込む必要があります。「何を作るか」を決めるフェーズです。SESの現場では、この部分がすでに決まった状態で合流することがほとんどですが、受託開発ではここから関わります。クライアントが「こうしたい」と言っていることの裏に、どんな業務課題があるのか。本当に必要な機能は何で、「あったらいいな」レベルの機能はどれか。予算とスケジュールの制約の中で、何を優先して何を後回しにするか。ここを正しく整理できるかどうかで、プロジェクト全体の方向性が決まります。

設計では、要件を満たすアーキテクチャを自分たちで選びます。どのフレームワークを使うか、データベースの設計をどうするか、外部サービスとの連携方式をどうするか。「Spring Bootで行くのか、別の選択肢があるのか」「RDBMSで十分か、NoSQLを検討すべきか」「この規模なら認証はどのサービスに乗せるのがコスパが良いか」——これらの判断を、自分たちの責任で行います。SESの現場では「この技術スタックで」と決まった状態から入ることが多いですが、受託開発では技術選定そのものが仕事の一部です。そして、その選定が間違っていればプロジェクトが苦しくなる。この緊張感の中で判断を重ねることが、エンジニアとしての設計力を鍛えます。

実装フェーズでは、設計した内容を実際のコードに落とし込みます。ここはSESの現場と共通する部分も多いですが、「自分たちが設計したものを自分たちで実装する」という一貫性があるのは大きな違いです。設計の意図を理解した上でコードを書けるので、「なんでこうなっているんだろう」と思いながら手を動かす場面が減る。逆に、設計段階での見落としがあれば、自分たちの責任として対処しなければならない。「設計が悪かったからこの実装が辛い」という愚痴を言う相手は自分自身です。この経験を一度でもすると、設計フェーズでの検討の深さが変わります。

テストと納品では、品質に対して最終責任を負います。「動けばいい」ではなく、クライアントに納品して、本番環境で問題なく稼働することを保証する。テスト設計の抜け漏れは、そのまま自分たちに返ってきます。納品後にバグが見つかれば、対応するのも自分たち。この責任感の中で仕事をした経験があるかないかで、コードに対する姿勢そのものが変わります。テストを書くモチベーションも、ドキュメントを残す意識も、品質への責任を一度でも自分で背負った人は根本的に違ってくる。

つまり、受託開発で得られるのは「部分的な実装経験」ではなく、「プロジェクトを回す力」です。これは、キャリアの方向性として技術のスペシャリストを目指す場合でも、マネジメントに進む場合でも、どちらにも効いてくる力です。

受託開発の経験を積みたいなら、大手のSIerや受託企業に転職するという選択肢もあります。実際、そちらのほうが案件数も多く、教育体制も整っているかもしれません。

では、なぜCodenceなのか。

Codenceは設立1年未満の会社です。SES事業で売上の基盤を作りながら、並行して受託開発事業の立ち上げを進めています。つまり、受託開発のチーム編成も、案件獲得の営業フローも、開発プロセスも、品質管理の仕組みも、まだ何も固まっていない状態です。

これを「不安定」と感じるか、「面白い」と感じるかで、Codenceに合うかどうかは分かれると思います。

大手の受託企業に入れば、確かに受託開発の経験は積めます。でも、すでに完成されたプロセスの中で、決められた役割をこなすことになります。要件定義のテンプレートは決まっている。見積もりの方法も決まっている。レビューのフローも決まっている。それは効率的ですし、プロセスの品質も高い。ただ、「なぜそのプロセスなのか」を考える機会は少ないし、「もっとこうしたほうがいいのでは」と思っても、組織が大きくなればなるほど変えるのは難しい。

Codenceの今のフェーズでは、そのプロセス自体を自分たちで作ります。

見積もりの精度をどう上げるか。要件定義で何をどこまでドキュメントにするか。コードレビューの基準をどう設定するか。テスト工程をどう設計するか。クライアントとのコミュニケーション頻度はどのくらいが適切か。進捗管理のツールは何を使うか。納品物の品質基準をどこに置くか。これらの問いに、初期メンバーとして自分の意見を反映できます。

「前の現場ではこういうやり方でうまくいった」「この工程は自動化したほうがいい」「ここはもっとクライアントと密に連絡を取るべきだ」——SESの現場で見てきた良い事例も悪い事例も、全部活かせる。「このやり方のほうがいいんじゃないか」という提案が、そのまま会社の標準プロセスになる可能性がある。

大手のSIerで10年働いても得られないかもしれない「仕組みを設計する」経験が、今のCodenceにはあります。事業の仕組みそのものを作る経験は、完成された組織の中ではまず得られません。そしてこの経験は、将来どこに行っても通用する力になります。自分でプロセスを設計した人は、既存のプロセスの問題点も改善点も見えるようになる。それは技術力とは別の、しかし技術力と同じくらい市場で求められるスキルです。

ここまで読んで、「じゃあ入社したらすぐに受託開発だけやるのか」と思った方もいるかもしれません。そうではありません。

Codenceのアプローチは、SES案件で安定した収入と現場経験を確保しながら、受託開発事業の立ち上げにも並行して関わっていくという形です。

「いきなり受託だけで食べていく」のはリスクが高い。特に立ち上げ期は、案件の量が安定しません。営業体制もこれから作っていく段階ですし、最初から大型案件を取れる保証もない。だからこそ、SESという安定した基盤を持った上で、受託開発に挑戦する。この両立ができるのは、SES事業をメインに据えている会社だからこそです。

具体的には、SES案件の合間や、社内の開発時間を使って受託案件に取り組みます。最初は小規模な案件から始めて、チームとしての練度を上げていく。見積もりの精度、クライアントとのコミュニケーションの質、コードの品質、納品までのスピード——これらを実践の中で一つずつ磨いていきます。

その過程で、各メンバーの得意領域や開発スタイルを互いに把握しながら、受託チームとしての形を少しずつ作っていきます。誰が設計に強いのか、誰がクライアント対応に向いているのか、誰がテスト設計に秀でているのか。こうした役割分担も、実際にプロジェクトを回す中で自然に見えてくるものです。

いきなり完璧を目指すのではなく、小さく始めて、実績を積み上げていく。地味ですが、これが一番確実なやり方だと考えています。そして、この「小さく始める」フェーズに最初から関われることに価値がある。実績がゼロの状態から、チームとしての信頼を積み上げていく過程を経験した人は、将来どんな規模のプロジェクトでもチームの立ち上げができるようになります。

技術面では、JavaまたはC#の実務経験が3年以上ある方を想定しています。Spring BootやASP.NET Coreでの開発経験があれば、受託案件でもすぐに力を発揮してもらえるはずです。もちろん、Javaが書けなくてもC#の経験があれば問題ありません。言語が変わっても、設計の考え方やシステム開発のプロセスは共通する部分が多いからです。

ただ、技術力以上に大事にしているのは、「事業を作る側に回りたい」という意志です。

SESの現場で3年以上やってきた方なら、技術力はすでに一定の水準にあります。コードを書く力、設計を読む力、チームで開発を進める力——これらは現場で十分に鍛えられているはずです。その上で、「自分の技術を、誰かの指示で使うだけでなく、何を作るか・どう作るかを自分たちで決める側に立ちたい」と思えるかどうか。

正直に言うと、完成された環境を求める方には向いていません。手厚い研修プログラムも、整備されたドキュメント体系も、今のCodenceにはありません。足りないものがあれば自分たちで作る。うまくいかなければやり方を変える。そこに面白さを感じられるかどうかが、一番の分かれ目です。

「自分はまだ経験が足りないから、もう少し大きな会社で学んでから」と思う方もいるかもしれません。その判断は間違いではないと思います。ただ、「整った環境で学ぶ」ことと「自分で環境を作りながら学ぶ」ことは、得られるものの種類が根本的に違います。前者は効率的ですが、後者でしか身につかない力がある。どちらを選ぶかは、自分がどうなりたいかによります。

逆に言えば、「SESで経験を積んだからこそ見えてきた、次のステージに進みたい」という方にとっては、ちょうどいいタイミングだと思います。SESで培った現場対応力と技術力を持ちながら、受託開発の上流から下流まで経験できる。しかも、事業の仕組みそのものを作る側に回れる。

こういう機会は、キャリアの中でそう何度もあるものではありません。

受託開発事業のゼロからの立ち上げに関わるというのは、簡単な話ではないです。うまくいかないこともあるだろうし、試行錯誤の連続になる。でも、その過程で得られるものは、完成された環境で何年働いても手に入らないものだと考えています。

SESで培った経験を活かしながら、次のキャリアを一緒に作っていきたいという方は、ぜひ一度話を聞きに来てください。