「受託って、結局SIerの下請けで雑用やるだけですよね？」
転職活動中のエンジニアと話していると、こういう言葉を本当によく聞く。
正直に言うと、その認識は半分正しくて、半分は間違っている。
僕は株式会社K.Platinumの沼田と言います。スタートアップITコンサルを経て、24歳で会社を立ち上げ、今は3期目・27歳。今日は「受託開発」という言葉に染みついてしまっているネガティブイメージと、その内側にある本当の構造について、現役の経営者として正直に話してみたい。
求職者と話していて一番もったいないと思うのが、「受託開発の会社＝上流に関われない」と決めつけて、最初から選択肢から外してしまうことだ。じゃあ実際、僕らみたいな受託の会社で働くエンジニアは何をやっているのか？答えをひとことで言うと、要件定義から設計、実装、運用まで全部やっている。むしろ事業会社のエンジニアより上流に深く入っているケースも少なくない。
なぜ「受託＝下流」というイメージが生まれたのか
まず誤解を解く前に、その誤解がどこから来ているのかを整理しておきたい。このイメージは、別に求職者のせいじゃない。構造的にそう見えてしまう理由がちゃんとある。
ひとつ目は、多重請負構造の問題。エンドユーザー（発注元の事業会社）→元請けの大手SIer→2次請け→3次請け、と仕事が流れていく中で、下のレイヤーに行けば行くほど「決まったものを作る」仕事になる。要件定義は元請けがやっていて、降りてくるのは「この仕様書通りに実装してね」というタスク。これでは上流もへったくれもない。
ふたつ目は、SES（準委任契約）モデルとの混同。エンジニアが客先常駐で月額単位で稼働を売る「SES」という働き方が、なぜか「受託開発」と一緒くたに語られている。SESは「人月で時間を売る」ビジネスで、受託は「成果物を納めて報酬をもらう」ビジネス。本質的に別物なんだけど、両方とも「自社サービスじゃない」という理由で同じ括りに入れられてしまっている。
3つ目は、メディアやSNSでの発信の偏り。「自社開発はクリエイティブで楽しい」「受託は消耗する」みたいな図式が、ここ10年で完全に定着してしまった。実際にそういう受託会社が多かったのも事実だし、今もある。だから求職者の認識が間違っているわけじゃない。
つまり「受託＝下流」というイメージは、特定の構造で働いていた人たちの体験談が広がった結果であって、受託というビジネスモデル自体の必然じゃない。ここを切り分けて考えないと、いい会社まで選択肢から外してしまうことになる。
K.Platinumが実際にやっている上流工程の仕事
じゃあ僕らK.Platinumが実際に何をやっているのか、もう少し具体的に話したい。
直近1年で僕らが手掛けた案件をざっと挙げると、製造業向けのAI一元管理プラットフォーム構築、5,000人規模で使う営業支援アプリ、再生可能エネルギーの買取契約管理システム、研修管理システム、受発注DXプラットフォーム——大体こんな感じだ。
これらの案件、どこから入っているかというと、ほぼすべて「課題ヒアリング」「業務フロー整理」「AS-IS / TO-BE設計」の段階から関わっている。お客さんから「こういうシステムを作って」と言われて作るんじゃなくて、「こういう困りごとがあるんだけど、どう解決すればいいか一緒に考えてほしい」というところから始まる仕事が多い。
たとえば製造業のAI案件では、最初の3ヶ月くらいは現場ヒアリングと業務分析で、コードはほとんど書いていない。「現場のオペレーターが何に困っているのか」「既存システムの何がボトルネックなのか」を整理して、初めてアーキテクチャ設計に入る。そこから実装フェーズに移って、最後は運用までうちが見る。
これはエンジニアにとって何が起きているかというと、「自分が決めた設計を、自分の手で動くものにしている」状態だ。要件と設計と実装の責任が分断されていない。だから完成したときに「ちゃんと使われるかどうか」までが自分の責任範囲になる。これがめちゃくちゃ面白い。
しんどさもある。要件定義からやるということは、お客さんと向き合って曖昧さに耐える時間が長い。仕様書の通りに作ればいい仕事と比べると、認知的な負荷は確実に高い。でもその経験は、エンジニアとしての市場価値を確実に押し上げる。これって、事業会社のエンジニアでも、年次が浅いうちはなかなかやらせてもらえない仕事だから。
興味が湧いてきたら ▶︎ K.Platinumの求人を見てみる
「ITコンサル × 開発」二刀流ポジションの正体
K.Platinumを一言で説明するなら「ITコンサル × 開発の二刀流」だと思っている。これ、実はかなり珍しいポジショニングだ。
世の中の会社をざっくり分けると、こうなる。
戦略系のITコンサル会社（アクセンチュア、ベイカレント、PwCなど）は、上流の戦略・要件定義は強いけど、実装は別のSIerに発注する。コンサルとエンジニアが分業されている世界だ。
逆に大手SIer（NTTデータ、富士通、NECなど）は、上流から下流まで全部やるけど、組織が大きすぎてエンジニア個人としては「設計フェーズの一部」「実装フェーズの一部」しか経験できない。1案件で何百人も動くから、自分の担当範囲が必然的に狭くなる。
事業会社のエンジニアは、自社プロダクトの責任範囲は広いけど、扱うドメインが固定されるし、案件ごとに「ゼロから何かを立ち上げる」経験は意外と積みにくい。
僕らみたいな小さなITコンサル会社は、規模が小さい分、ひとつの案件にコンサルとエンジニアの両方の役割で深く入れる。要件定義もやる、設計もやる、実装もやる、運用もやる。これを「ぜんぶ別の人がやる」のがSIer業界の常識だけど、僕らは「ぜんぶ同じ人が責任を持つ」というスタイルでやっている。
二刀流ができる前提条件は、エンジニアの母数を絞ることだ。今うちは17名（うち高専出身者8名）。1人ひとりに広い責任を持たせるには、大人数では成立しない。だから無理に拡大しないし、案件もちゃんと選んで取っている。
このポジションの何が嬉しいかというと、エンジニアが「自分が考えたものが、ちゃんと世の中で動いている」という体験を積めることだ。これは本人の自己効力感にもなるし、転職市場での評価にも直結する。
上流から関わるメリット — エンジニアのキャリアにとって何が変わるか
ここまでの話を抽象化すると「受託でも上流から関われるよ」という話なんだけど、もう一段踏み込んで、それがエンジニア個人のキャリアに何をもたらすのかを話したい。
いちばん大きいのは、「ビジネス側の言葉と技術側の言葉を翻訳できる人」になれることだ。これは想像以上に希少なスキルになる。多くのエンジニアは「与えられた要件を実装する」訓練ばかり積むので、ビジネス側のあいまいな悩みを設計に落とす練習を積んでいない。逆に多くのコンサルタントは技術の解像度が粗いので、絵に描いた餅で終わることが多い。両方が分かる人は、どこに行っても重宝される。
次に大きいのが、「失敗の責任を取る経験」を積めること。下流だけ担当していると、要件が間違っていてもそれは上流のせいだ、で終わってしまう。でも上流から関わると、自分が決めた要件が違っていたら、自分が直しに行くことになる。この経験を10案件くらい積むと、設計判断の精度が劇的に上がる。これがいわゆる「設計センス」と呼ばれているものの正体だと僕は思っている。
もうひとつは、自分の市場価値が単価ベースで可視化されやすいこと。受託で上流から入る案件は、人月単価がSES案件より大幅に高い。それを担当しているエンジニアは、業界水準で見ても「上のレンジ」で評価される。具体的な金額はここでは書かないけれど（採用ブログで単価を書くと色々ややこしいのでルールにしている）、転職市場での評価は確実に上がる。
逆にデメリットも書いておくと、上流に深く入る分、お客さんとの直接対話が増える。コードだけ書いていたい人にはストレスになる場合もある。あと、ドメイン知識をゼロから学ぶ必要が頻繁にあるので、好奇心が薄い人には向かない。「決まったタスクを淡々と消化したい」タイプには、たぶん合わない働き方だ。
受託で上流を経験するために、会社選びで見るべき3つのポイント
最後に、転職活動中のエンジニアに具体的なアドバイスをひとつ。受託会社を選ぶときに、上流から関われるかどうかを見極めるポイントは3つある。
ひとつ目は、「元請けかどうか」。多重請負構造の下のほうにいる会社は、構造的に上流に関われない。エンドユーザー直契約の比率が高い会社を選ぶこと。面接で「直契約案件の比率」を遠慮なく聞いていい。出せない会社は、たぶん答えにくい構造になっている。
ふたつ目は、「エンジニアと営業の距離感」。エンジニアが営業同行する文化があるか、要件定義の場にエンジニアが入っているか、これが上流関与の現実的な指標になる。組織図でエンジニアと営業（あるいはコンサル）が完全に分かれている会社は、構造的にエンジニアが上流に入りにくい。
3つ目は、「案件選択制があるか」。会社から一方的にアサインされる方式だと、どれだけ上流案件があっても自分に回ってこないことがある。社員が案件を選べる仕組みになっていれば、自分のキャリアに合わせて意図的に上流案件を取りにいける。うちは案件選択制をやっていて、これは社員の声を反映した制度。やるからには中途半端にしない、というのが僕のスタンスだ。
この3つを面接で確認すれば、その会社が「受託」という看板の中で本当に上流から関われる場所なのか、それとも「受託」のステレオタイプ通りの会社なのか、だいたい見抜ける。
まとめ — 「働き方」より「関わり方」を選ぼう
受託か自社開発か、SESか正社員か、こういう「働き方の形」だけで会社を選んでしまうと、本当に大切なものを見失う。
エンジニアにとって本質的に大事なのは、「どのレイヤーから、どこまで責任を持って関われるか」という"関わり方"のほうだ。受託でも上流から関われる会社はあるし、自社開発でも狭い領域しか担当できない会社はある。看板の言葉に惑わされず、内側の構造を見るクセをつけてほしい。
K.Platinumは、たまたま受託の形でビジネスをしているけど、エンジニアの関わり方としては「上流から下流まで責任を持って一貫対応する」スタイルを選んでいる。それを実現するために組織サイズも案件選定も意図的にコントロールしている。
「受託の枠の中で、上流からモノづくりをやってみたい」「ビジネスと技術の翻訳者みたいなエンジニアになりたい」——そう思ってくれた人がいたら、ぜひ一度カジュアルに話しに来てほしい。
筆者プロフィール
沼田 海斗（ぬまた かいと）
株式会社K.Platinum。沖縄高専卒→トヨタ自動車→スタートアップITコンサル→24歳で起業。現在3期目・27歳。受託開発でも上流からエンジニアが責任を持つ会社を作ろうとしている。趣味はキックボクシングとママチャリ日本一周。
K.Platinumでは一緒に働くエンジニアを募集しています。「実力で正当に評価される環境」「上流から関わるモノづくり」に興味がある方は、ぜひ採用ページをご覧ください。カジュアル面談からでもどうぞ。