20年近く、ずっとクライアントワークをしてきた。SESで客先に入り、SIerで受託開発を回し、今は外資系コンサルでクライアントの案件に関わっている。自社サービスを作る側には、一度も身を置いたことがない。
その自分が、自社開発に興味を持った時期がある。
ただ、この記事は「自社開発に行きたい」という話ではない。実際に転職先として検討した結果、自分には受託の働き方の方が合っていると結論を出した。その過程で見えた両者の違いを書く。
「自社開発の方が上」「受託はきつい」という単純な図式ではない話として読んでもらえればと思う。
自社開発に興味を持ったきっかけ
きっかけは、自社サービスを持つクライアント側のエンジニアと一緒に働いたことだった。
自分は外から入った立場で、彼らはそのサービスを作っている当事者だった。一緒に進めていく中で、仕事の捉え方が自分とはっきり違うことに気づいた。
彼らは、自分たちのサービスを企画段階から一貫して対応していた。
何を作るかを決める段階にいて、設計も開発も自分たちでやり、リリース後の反応も見ている。その全部が一つの線としてつながっていた。企画で出た意図が、そのまま実装の判断につながり、リリース後の数字で検証されて、次の企画に戻っていく。
これは新鮮だった。20年やってきて、こういう形で仕事をしている人たちを間近で見たのは初めてだった。
もう一つ印象に残ったのは、彼らがサービスの全体感を持って取り組んでいたことだ。自分の担当機能の話をしているときでも、サービス全体のどこに位置する機能なのか、なぜその優先度なのかが前提として共有されていた。部分の話をしていても、常に全体が見えている状態だった。
クライアントワークでは、企画はすでに決まっている
比較して考えると、クライアントワークの構造がはっきり見えた。
受託の仕事は、基本的に何を作るかが決まった後から入る。要件はクライアントが持っていて、こちらはそれを形にする。もちろん上流から入れば要件定義にも関わるが、「そのサービスをなぜやるのか」という最上流の判断は、クライアント側にある。
これは能力の問題ではなく、契約の構造だ。発注する側が何を作るかを決め、受注する側がどう作るかを担う。だから受託側は、企画段階の意思決定からは原理的に少し遠い場所にいる。
もう一つの構造的な違いは、案件が終われば関係が切れることだ。
20近い現場を見てきたが、自分が関わったシステムがその後どう使われたのか、本当のところはほとんど知らない。リリースして、保守に引き継いで、次の案件に移る。作ったものがユーザーにどう受け止められたか、数字がどう動いたかを追い続ける立場にはいなかった。
この二つ——企画段階から遠いこと、作ったものの行き先が見えないこと——が、クライアントワークの構造的な制約だと思っている。
実際に自社開発への転職を検討した
興味を持った時期に、転職先として自社開発企業を実際に検討した。求人を見て、条件を比較して、自分のキャリアと照らし合わせた。
検討してみて、いくつか現実的な問題が見えてきた。
一つは、自分の経験が自社開発の文脈でどう評価されるかが読みにくいことだ。20年の経験は、クライアントワークの文脈で積み上げたものだ。要件を整理する力、納期と品質を調整する力、関係者をまとめる力。これらは受託の現場で評価されてきたスキルで、プロダクト開発の文脈でそのまま通用するとは限らない。
もう一つは、プロダクトと自分のキャリアが連動することだ。自社開発は、そのプロダクトが伸びているかどうかが自分の環境を直接左右する。サービスが縮小すれば、自分の仕事の幅も縮む。受託なら案件を変えればリセットできるが、自社開発では簡単に切り替えられない。
これはどちらが良いという話ではなく、リスクの形が違うという話だ。
それでも受託を選んだ3つの理由
最終的に、自分にはさまざまな案件を経験できる働き方の方が合っているという結論になった。理由は3つある。
①案件の多様性そのものが自分の資産になっている
20近い現場を見てきたことで、「この手の問題はこう転ぶ」というパターンが蓄積された。炎上プロジェクトの兆候、要件が膨らむときの前触れ、人が抜けそうなときの空気。これは一つのプロダクトに長くいても得られない種類の経験だ。自社開発を選べば、この蓄積の仕方は止まる。
②業界知識を横断できる
金融を中心に、銀行・生保・損保・決済と業種をまたいできた。業務知識が重なる領域を複数持っていることが、今の市場価値の中核になっている。一社のプロダクトに専念すると、この横断性は増えない。
③環境を変える手段として転職が使える
自分は2度の転職で年収を上げてきた。「環境が合わなければ変える」という選択肢を持ち続けられることが、自分にとって重要だった。受託側は案件単位でも環境を変えられるため、その自由度が高い。
自社開発と受託、どちらが上位ということではない
結論として、自社開発への興味は残っている。企画から一貫して関わる経験は、自分のキャリアに足りていない領域だという認識はある。機会があればやってみたいと今でも思っている。
ただ、「足りていない経験がある」ことと「そちらに移るべき」ことは別だ。
よく「受託は下請け、自社開発が上」という語られ方を見かける。実際に両方を近い距離で見た感覚としては、そういう階層の話ではない。得られる経験の種類が違うだけだ。
自社開発は、一つのものを深く、長く、全体で見る経験が積める。受託は、多様な環境と業務知識を横断する経験が積める。どちらを選ぶかは、自分がどちらの経験を資産にしたいかで決まる。
自分は後者を選んだ。それは自社開発を低く見た結果ではなく、20年かけて積み上げてきたものが前者寄りではなかったという、現実的な判断だった。
よくある疑問への回答
Q. 受託から自社開発への転職は難しいですか？
難しいというより、評価のされ方が変わると考えた方がいい。受託で評価されてきた調整力や管理力は、プロダクト開発の文脈では主要な評価軸にならないことがある。一方で、要件を整理する力や複数の業務領域を理解する力は、プロダクト側でも通用する。自分の経験のどの部分が移植できるかを言語化しておくことが準備になる。
Q. 自社開発の方が技術力は身につきますか？
一概には言えない。自社開発は同じ技術スタックを深く使い続けるため、特定領域の深さは出やすい。受託は案件ごとに技術が変わるため、広さは出るが深さは案件次第だ。「技術力」をどちらの意味で捉えるかによって答えが変わる。
Q. 興味があるなら一度は経験した方がいいのでしょうか？
キャリアの時間が残っているなら、試す価値はあると思う。ただ「興味がある」だけで動くと、環境が変わっただけで何も得られないことがある。自分の場合は、検討した上で「今積み上げているものを止める方がコストが大きい」と判断した。試すかどうかは、今持っている資産と天秤にかけて決めるのが現実的だ。
まとめ：興味を持つことと、選ぶことは別
自社サービスを持つクライアント側のエンジニアと働いて、自社開発に興味を持った。企画段階から一貫して関わり、サービスの全体感を持って仕事をする。その姿は新鮮だった。
実際に転職先として検討もした。それでも最終的には、さまざまな案件を経験できる働き方の方が自分には合っていると結論を出した。案件の多様性、業界知識の横断性、環境を変えられる自由度。この3つが、自分のキャリアの核になっていたからだ。
興味を持つことと、それを選ぶことは別だ。興味を感じた領域について、構造を理解した上で「今は選ばない」と判断することも、キャリアの設計の一部だと思っている。
機会があればやってみたい。その気持ちは、今も残したままにしている。
コメント