フロントエンドとバックエンドは分業すべきか？

法人・団体専用のパーティー会場検索サイト「会場ベストサーチ」を運用する株式会社アイデアログの取締役CTOの松川と申します。

今回はフロントエンドの開発とバックエンドの開発は担当者を分けて分業すべきかというテーマについて書きたいと思います。

当社の課題感

僕自身が古い人間なので、前提として機能ごとに担当してもらった方が、習得しなきゃいけない技術の幅が広くなると考えています。そのほうがエンジニアとしても成長できるし、機能をまるっと担当した方が出来上がったときに達成感もあるだろう、と思いから、基本的には当社のエンジニアには、「機能」を担当してもらっていました。
一方で別の考え方として、フロントエンドとバックエンドで担当を分けて、開発を進めてゆくという進め方もあります。これは専門（得意）分野に注力できるので、生産性は高いと思う反面、フロントエンドとバックエンドの結合の際にコミュニケーションやドキュメンテーションコストがかかることがあります。悪い場合には責任の押し付け合いや、要件のお見合い（向こうがやると思っていた）などの問題にケアが必要だな〜と思っていました。
結果的に、うちでは「みんなにはフルスタックエンジニア（一人でなんでもできちゃうニュアンス）になってもらいたいから、機能単位で担当してもらって、いろんな技術を幅広く習得してほしい」と現場で言い続けてきたわけです。

他社さんの状況

ここ最近、他社のCTOさんやVPoEさんと交流する機会を増やしているのですが、「みんなフルスタックになる」という方針の漢気には共感いただくことが多かったです。しかし、それは現在少人数の開発チームで数個のプロダクトを開発している状況ではうまく行っても、組織のグロースやマルチプロダクトを運用するにあたっては新規採用などの面で現実的ではないのでは？分業が現実的では？という意見をいただきました。
確かに、現在10名前後の規模ですが、50人のチームにグロースさせてゆく、ということを考えるとハイスペックなフルスタックエンジニアを短期間にそんなに採用できるか？となるとGAFAMやメガベンチャー並みの知名度と採用ブランド力が必要かもしれません。そのような組織に成長することを目指していますが、現段階ではそのような力はまだまだありません。

そもそもどのようなエンジニアを育成したいか

アイデアログの開発チームが育成したい人材は高利益率の事業を支えるシステム開発を推進する「主体性のあるエンジニア」です。定められたこと、指示されたことを実行できるだけではなく、自社の成長戦略を理解した上で、事業計画に沿った戦略的なプロジェクトのメンバーとして自分の頭で考えアウトプットをできるエンジニアを育てていきたいと考えています。現在在籍しているメンバーはこの素養を備えています。

人材育成と事業計画の関係性（人材の育成の先に目標達成を置く）

事業を推進してゆく上で、企業活動である以上、高い目標をセットして、それを達成できるように計画を推進してゆくわけですが、当社では目標達成にあたって重視している点があります。
それは、メンバーの成長の先に、目標達成があることです。
プロジェクトの目標が達成され、期日通りにプロダクトがローンチできたとします。しかし、一部のメンバーだけに負担がかかり、リードして稼働を上げたが、他のメンバーが全く成長していない状況や、難しい部分はパートナーさんに助けていただき社内にノウハウが全く蓄積しておらず、類似のプロダクトであっても内製で対応できない、などの結果は当社ではNGと考えています。
仕事を通して成長や自己実現を達成してほしいと考えていて、その結果目標達成できて会社としても満足、というのがWin-Winな関係なのかと思っています。

では、フロントエンドとバックエンドは分業すべきなのか？

結論、「条件付きで」分業はありだと今は考えます。
条件とは何かというと、システム開発について幅広く原理原則の理解と業務実経験を有する者が得意分野、さらに深めたい分野を掘り下げてゆくときに「分業」はあり、と考えています。

具体例を出すと、フロントエンド開発もバックエンド開発もインフラ構築も運用保守経験などオールジャンルについての業務経験と原理原則の理解（表面的なテクニックや流行のフレームワークの理解ではない）がある方が、自分はやっぱりフロントエンドの開発が好きで没頭できるし、もっと深めたいと考えていたとします。そこで、今回のプロジェクトにおいては、その方がフロントエンドのテックリードをして、成果物もどんどん作るよ、というのはありだと思っています。このような方はバックエンドやインフラで問題が発生していても、得意分野ではないけど、ある程度のレベルでトラブルシューティングができることが多いです。

逆に当社ではNGと考えているのが、まだ経験が浅く自分が何に向いているか、どのような分野に夢中になり、技術を深めたいかわかっていない方に、「君はバックエンドエンジニアだから、とことん極めてほしい。他の技術は気にしなくていい」としてしまうことと思っています。

ここまで極端でなくても、なりゆきで明確な意思や計画なく、ただただプロジェクトの効率だけ考えていると、気づけば長年ずっとバックエンドを担当してもらっている、技術の幅が狭くて他のプロジェクトにアサインしづらい、といった状況は他社のマネージャーさんも思い当たる節がある方もいらっしゃるのではないでしょうか？

かくいう私も同じ人にずっと同じような役割のアサインを続けてきたことがあります。その方が生産性があがり、プロジェクトの進捗に寄与するから楽なんです。ただ、マネージャーである以上、メンバーの人生を預かっているわけですから、このような仕事のアサインではダメなのかな？と私は思います。

広く種をまき、芽が出たところを伸ばす

何か得意分野を見つけて、「自分はこれを極めたい」「この仕事には没頭できそう」という「芽」が出るまでは、広く「種」を撒き続けるのが、人材育成に対して真摯に向き合い考えた私の答えです。（2025年現在です。来年変わっていたら訂正記事を書きます。）
フロントエンド開発もバックエンド開発もインフラ構築も運用保守経験などなど様々な分野を満遍なく、学び経験し、それぞれの「必修科目」の範囲は一定のレベルを担保しながら、目が出たら注力する、というのがいいんじゃないかなと思います。

AI時代の考慮

「フロントエンドエンジニア」なんて言葉は20年前は存在しなかったように、求められるエンジニアの専門性は開発ニーズによって変わってくるものだと考えます。
特に現在はAIの台頭がすさまじく、AIエージェントがコードの修正案を出してくれて、それを人がレビューするというスタイルが標準になってゆこうとしています。そうすると、人が担うのは「事業戦略を理解して、専門知識をもとにAIに的確に指示をする（翻訳する）」「AIが生成したコードを専門知識を活用してチェックし、自社の要件にあっているか吟味・改善する」「継続的なプロダクト成長に導く（責任を持つ）」などの分野となるのではないでしょうか？
であれば、より一層「原理原則」「主体性」というキーワードは重視されるかと思うわけで、しっかりとした育成計画によって「足腰の強いエンジニア」を育てる、というのが当社の開発チームの人材育成スタンスです。