【前回の記事】では、受託開発からキャリアを切り拓いた小原さんと松尾さんの転換点について伺いました。小原さんの語る「事業をエンジニアリングする視点」や、松尾さんの武器である「言語化能力」は、受託開発企業で働くみなさんの今後のキャリアのヒントになったはずです。

後半となる今回の記事は、イベント後半のパネルトークの内容と当日の参加者から届いたリアルな質問へのお二人の回答をご紹介します。

現場のリアルなモヤモヤに対し、受託開発出身の先輩であるお二人が自身のキャリアを振り返りながら、後輩へのエールを込めて回答してくださいました。

質問一覧
Q：文系出身、SES所属の4年目です。「サービスを引っ張るエンジニア」を目指していますが、自社開発企業へ行くべきですか？
Q：受託開発と自社開発、それぞれに向いている人の傾向はありますか？
Q：受託開発から自社開発企業に転職したときに感じた一番大きなギャップはなんでしょうか？
Q：受託開発と自社開発、マネージャーが抱える悩みは違いますか？
Q：プレイングマネージャーの業務比率はどのくらいですか？
Q：生成AIの台頭で受託開発の需要が減ることを懸念し、自社開発企業への転職を検討していますが、どう思われますか？
Q：面接で「この人と一緒に働きたい」と思うエンジニアの特徴は？
Q：自社開発企業へ移った後、受託開発での経験がメリットになったことは？
Q：「良いコードと良いシステム」とは何か。ご自身の答えは見つかりましたか？

株式会社レンガ
取締役CTO 兼 マンションノート事業責任者
小原 和磨
2004年にシステム開発会社へ入社し、エンジニアとしてのキャリアをスタート。2009年に事業会社のエニグモへ転職し、2012年に株式会社レンガを共同創業。現在は「マンションノート」の事業責任者も務める。

株式会社サーバーワークス
アプリケーションサービス部　ディベロップメントサービス2課 課長
松尾 優
文系学部を卒業後、2009年に大分県の地元SIerに入社し、約13年間、金融機関などの受託開発やECサイトの運用保守を担当。2022年にサーバーワークスへ転職し、現在はプレイングマネージャーを務める。

自社開発への憧れの正体と、後悔しない選択

受託開発エンジニアが一度は抱く「自社開発企業」への関心。しかし、隣の芝生が青く見えるだけなのではないかという不安もつきまといます。

Q：文系出身、SES所属の4年目です。「サービスを引っ張るエンジニア」を目指していますが、自社開発企業へ行くべきですか？

松尾：まず「サービスを引っ張る」という言葉をもう少し掘り下げてみてください。技術的に幅を広げたいなら多様な案件に触れる受託開発が近道かもしれませんし、一つのサービスを全うしたいなら起業という道もあります。

私自身は「AWSにもっと触れたい」という思いからAWS特化の受託開発企業に転職し、やりたいことが叶っています。自社開発企業のどこに魅力を感じているかをより具体的に言語化することで、面接官にもより魅力的に映るのではないでしょうか。

小原：「自社開発だと思ったら実態は社内で受託開発しているのと一緒だった」という話も聞きます。なので、まずは「サービスを引っ張る」を徹底的に具体化することで、適切な会社選びがしやすくなるのではないかと思います。

また、20代半ばなら、興味があるなら一度自社開発企業へ行ってみるのも良いと思います。後々「経験しておけばよかった」と後悔するコストをなくせますから。ちなみに、自社事業・自社開発の弊社は、エンジニアを絶賛募集中です。

Q：受託開発と自社開発、それぞれに向いている人の傾向はありますか？

松尾：感覚的なものにはなりますが、技術的な「横の広がり」を求めるなら受託開発、安定した技術で「運用」の安定化に注力したいなら自社開発がフィットしやすいと思います。

一概には言えませんが、自社開発企業で働いていた方が、運用の負荷が大きく再び受託開発企業を目指すケースもあるので、運用のイメージが抜け落ちたまま自社開発を目指すとギャップがあるのではないかと思います。

小原：エンジニアリングの「手法」自体が好きなら受託開発、その先の「成果（アウトカム）」に関心があるなら自社開発という基準もありますが、個人的には仕事に対する価値観に合っている環境かどうかの方が重要だと感じます。

例えば、フィードバックループを高速で回してプロダクトや事業の価値を高めていくことに関心があるのか、確実かつ効率的な開発手法を用いて強い開発組織を作ることに関心があるのかでは、仕事の仕方は大きく異なります。自社開発でも受託開発でもどちらの考え方の会社もありますし、それらと違う考え方の会社もあるでしょう。

また、最初に働く会社なら、今時点の自分の価値観よりも、こんな風になりたいという理想像の価値観で判断出来るとより良い選択ができると思います。

Q：受託開発から自社開発企業に転職したときに感じた一番大きなギャップはなんでしょうか？

小原：主なギャップは、周囲の人が「何を意識して仕事に取り組んでいるか」の違いです。
受託開発にはクライアントと決めた「正解の要件」がありますが、自社にはありません。正解がない中で、事業に良い影響が出そうな施策を次々と投入するスピード感は、受託開発の「安全・確実」とは全く別の筋肉を使います。

ピープルマネジメントとの向き合い方

キャリアを重ねればどこかで出会うであろう「ピープルマネジメント」という選択。お二人はマネージャーの役割をどう捉えているのでしょうか。

Q：受託開発と自社開発、マネージャーが抱える悩みは違いますか？

松尾：「人、時間、コストなど限りある資源をどう最適化して、どう成果に結びつけるのか」というリソース管理の悩みは共通です。また、企業によってマネージャーに求められることやマネジメント方針にも違いがあるので、面談などを通して積極的に質問してみるのが良いと思います。

小原：受託開発は「納期までに要件を満たすためのリカバリー」に苦心することが多かったです。一方、自社開発企業では「事業目標やユーザー課題に対し、どの優先度で判断していくか」という、経営に近い悩みになりました。そして、どちらにも共通していたのは、「その判断をメンバーに納得してもらうこと」です。

Q：プレイングマネージャーの業務比率はどのくらいですか？

松尾：私の場合、だいたい「マネジメント4：開発3：その他3」のイメージです。開発の比率は下がりましたが、「全くやらなくなった仕事」があるかといえば答えはNoです。弊社の場合は、マネージャーの中にもほぼ開発作業に入らない方から逆にガッツリ開発もしている方まで様々いて、自分の裁量で調整できます。

生成AIに仕事が奪われるという漠然とした不安

生成AIの台頭によって、「受託開発やそもそもエンジニアという仕事自体がなくなるのではないか」という不安に対しても、前向きな展望が語られました。

Q. 生成AIの台頭で受託開発の需要が減ることを懸念し、自社開発企業への転職を検討していますが、どう思われますか？

松尾：今まさに過渡期ですね。「他社が提供するSaaSと同等の機能を自社で内製したい」というニーズも聞きますし、自社開発への一定の需要は感じています。一方で、生成AIが生成したものを運用・維持していく際の負荷が、少し軽視されている印象もあります。

エンジニアに求められるスキルセットは、コーディング以外の部分が増していくと感じています。
生成AIを使ったとしても「何を作るのか」「生成されたものが期待を満たしているのか」「成果物が継続な運用に耐えうるのか」を判断する上流工程のスキルは変わらず求められますし、それは受託開発でも自社開発でも変わらないと考えています。

小原：どうなるかわからないというのが正直なところです。「エンジニアの仕事が不要になる」可能性も否定できませんが、「どのようなシステムが上手く問題解決できるかを構想し判断する役割は必要」という声も聞きます。

現状の雰囲気では、後者に傾く可能性が高いという感覚で、役割は変わってもエンジニアのニーズは受託開発・自社開発問わず今後もあると思います。

ただ、生成AIが予想以上のスピードと精度で進化しているため、「エンジニアリングの素養がない人でもシステム的な判断ができる」レベルで生成AIがサポートする未来も想定されます。そうなると本格的にエンジニアが不要になる可能性も出てくるため、その時は身の振り方を考え直す必要があるかもしれません。

いずれにしろ「決められたものを構築する仕事」はなくなっていくでしょう。
しかし、現実の課題を生成AIに適切に指示し、そのアウトプットを評価する「判断力」があれば、むしろ人手不足問題の解消や、今まで受注できなかった案件の獲得など、チャンスも生まれるはずです。

面接官（先輩）は「ここ」を見ている

市場価値を高め、新しい環境に飛び込むために必要なマインドセットについても伺いました。

Q. 面接で「この人と一緒に働きたい」と思うエンジニアの特徴は？

松尾：自己学習や自己研鑽が「習慣」になっている方です。履歴書にGitHubのリンクなど書いていただく方もいるのですが、継続的にコミットがあり日常的に継続して技術に触れていることが伝わると魅力的に映ります。

小原：「与えられた役割をこなしたい」タイプよりも、「自分からやりたいことを見つけ、幅を広げていきたい」という意志を感じる方です。特に小規模な組織では、その自走能力が重要になります。

Q. 自社開発企業へ移った後、受託開発での経験がメリットになったことは？

小原：アウトプットをたくさん出し続ける受託開発の現場で鍛えられた「開発スピード」は大きな武器になりました。自社開発企業に移って、吸収したいことが大量にある状況でも、技術的な部分で負荷が少なかったのは、受託開発を経験したからこそだったと思います。

また、大規模開発を経験したことで培われた「設計の筋肉（地力）」は、一度の開発規模が小さい自社開発では得づらいものであり、大きなメリットでした。

エンジニアとして問い続けたい「良い」の定義

最後に、小原さんが若手時代から自身に問い続けている「良いコード・良いシステム」についての回答をご紹介します。

Q. 「良いコードと良いシステム」とは何か。ご自身の答えは見つかりましたか？

小原：これはいつまでも最終的な回答を出せない部分ではありますが 、現時点での考えとしては、「目的や課題やソリューションについての、開発組織の見解が過不足なく表現されているか」が良いコードの評価基準なのかなと思っています。

また、システムやプロダクトのレイヤーにおいては、「目的 ⇔ 課題 ⇔ ソリューションがそれぞれ過不足なくフィットしているか」が評価基準だと感じています。あらためて書いてみると当たり前のことのようですが、現実の業務判断では意外と見落とされがちな本質的ポイントだと感じます。

キャリアは「自分で選べる」

お二人の話に共通していたのは、受託開発で培った「顧客の課題に向き合う力」や「意図を正確に言語化する力」は、生成AI時代においても、そしてどの業態へ移ったとしても、エンジニアを支える武器になるという確信でした。

キャリアの選択に正解はありません。しかし、日頃からアンテナを張り、自分の理想に近い環境を自ら選び取ることこそが、市場価値を高め続けるための、最も確実な方法だといえます。

今回お話いただいた株式会社レンガ・株式会社サーバーワークスは、転職ドラフトエージェントの利用企業です。
もっと話を聞いてみたい！と思われた方は、ぜひ以下のリンクから面談をご登録ください。
https://job-draft.jp/agent

また、イベント「受託キャリアのその先」は以下のリンクから視聴できます。ぜひご覧ください。
受託開発キャリアのその先【オンライン・ランチ開催】