こんにちは！カイポケリニューアルのサービス提供管理チームでバックエンドのエンジニアをしている清田です。ここ3ヶ月はフロントエンド開発をしています。
この記事ではバックエンドを主戦場とするエンジニアがフロントエンド開発に挑戦して学んだこと、見えてきた風景について紹介します。 (以降、バックエンドを BE 、フロントエンドを FE と略します)
また私の個人的な体験ですが、FE 開発に貢献するためどのように学習したのかについても共有します。
BE エンジニアの FE 開発への挑戦、おすすめです！
なぜ FE 開発をするようになったのか
私が FE 開発に挑戦するようになった背景には、いくつかの要因がありました。
チーム編成の変化
まず、チーム編成が職能別からユーザーへの価値にフォーカスした編成に変わったことが大きいです。
カイポケのリニューアルプロジェクトでは、ドメイン毎のサービスで構成されたアーキテクチャで開発を行っています。 私は居宅介護支援事業所のケアマネジャー向けのケアプラン作成に関するドメインの中で、BE の機能開発を行うチームに属していました。
カイポケのリニューアルプロジェクトの開発チーム全体で LeSS が導入されたことにより、 2024年12月に居宅介護支援の領域では「サービス提供管理チーム」という名称で、デザイン、 FE 、 BE 、QA それぞれの職能に強みを持つメンバーが同じ1つのチームになりました。 (※ 導入理由などについては、LeSS の導入で変わるマネージャーの役割 に詳しくあります)
この編成の狙いの1つには、将来的には希望するメンバーについては職能を横断して別領域に挑戦しながら、チーム全体で提供できるユーザーへの価値を高めていくことも含まれています。
チーム構成の課題
チーム内での FE, BE それぞれを強みとする開発者の人数比率がアンバランスになった(FE:BEの人数比が 1:3 だった)こと、タスク量が FE のものの方が当時は多かったこともあり、FE の開発ができるメンバーを増やす必要がありました。 (現在は他チームからのメンバー移動などもあり人数比率は FE:BE でだいたい 1:1 です)
そのため、FE の主力の開発者(以降 FE メンバー)が新機能開発や難易度の高い開発に注力し、 BE メンバーが細かなバグ対応のような難易度の低いタスクや、そもそも GraphQL schema を定義し共有することで連携が必要だったエラーハンドリング系のタスクなどを一気通貫でこなすことになりました。
個人的な挑戦
私自身、 FE 開発に挑戦したいという思いがありました。BE から FE まで一気通貫で開発できるようになりたかったからです。
また、エス・エム・エス入社前は開発言語としては Java メイン、入社後も Kotlin を書いていたので、言語的に TypeScript での開発体験は気になっていました。 加えて React での component をベースにした開発を経験することで、BE の開発で求められる頭の使い方とは違うものを吸収して、ものづくりをする際の考え方の視野を広げたいとも考えていました。
そのため、FE 開発に挑戦することにしました。
足りていない知識は何なのか
今回の FE 開発の挑戦には、担当するプロダクトは変わらないため BE 開発時代に得たドメイン知識はそのまま活用することができました。その上で FE 開発を始める前に自分に足りていない知識や経験は次のものでした。
- FE の技術スタックの複雑さ(清田個人の知識の積み上げがないという意味です)
- 開発環境が異なる(=Visual Studio Code を使用する)ことによる負荷
FE の技術スタックの複雑さ
私の FE のスキル感は、2021年ごろに JavaScript Primer と 『りあクト！ TypeScriptで始めるつらくないReact開発 第3.1版』 を一周やったことがあるくらいで、業務ではしっかりと FE に触れたことがありませんでした。
そのため、 HTML、 CSS の基礎と TypeScript の書き方と Next.js の概要についてキャッチアップが必要と考えました。
開発環境が異なる(=Visual Studio Code を使用する)ことによる負荷
これまでの BE 開発の経験から IntelliJ をずっと使っていたため FE 開発でも IntelliJ を使うという選択肢もありました。 ただし今回は以下の理由から Visual Studio Code(以降 VSCode) で開発することにしました。
- FE 開発では VSCode が一番使われていること
- FE メンバーはみな VSCode を使っており気軽に知見を聞けること
- 『達人プログラマー（第2版）』 の「第3章 基本的なツール」の 「職人のように常に道具を増やすことを心がけてください。」に従って開発時のインターフェースとしての道具も増やしてみたかったため
どうやってキャッチアップしたか
個人的な体験ですが、BE エンジニアが FE 開発に挑戦した際にどのようにキャッチアップしたかを共有できればと思います！ (もちろん現状でキャッチアップできたとは思っておらず、以下に挙げるものは今も継続的に取り組んでいることです！)
技術スタックを知る
まずは、プロダクト開発をするにあたっての前提として必要な HTML、 CSS、 TypeScript、 React、 Next.js の基本的な知識について以下の内容を手を動かしてキャッチアップしました。
HTML、CSS については、MDN ドキュメントの 入門モジュールとコア学習モジュール の中でプロジェクトの開発で知識として必要そうな箇所
TypeScript については、『プロを目指す人のためのTypeScript入門 安全なコードの書き方から高度な型の使い方まで』で基本的な文法と型の種類について
React、Next.js についてはチュートリアル(React Foundations、App Router)を実施
次にプロジェクトで使われているライブラリについて先に軽く調べておきました。
ただこちらはそれぞれを動かして試す時間はないため、導入されている意図を予測し、 〜をつかうことで〜が嬉しい！？ みたいなフォーマットで自分なりに導入理由を想像してメモを残すに留めました。
VSCode ホームポジションから動かずにソースコードを行き来する
個人的な好みの問題なのですが、ソースコード内を移動する時にホームポジションから動かずに操作したい派です。
既に実装がある程度進んでいるプロダクトの開発時ではソースコードを読む時間が一定あります。 一貫性を持った実装にするために参考にするべき実装を探す時や、 component の階層が深くなっていった際の定義の移動を、思考の流れを止めずにホームポジションで行えることは既存のコードを理解するためにとても重要です。
コードリーディングに着目してショートカットを紹介している記事 【VSCode】コードリーディング特化のショートカット集 が本当に参考になりました！
あとは IntelliJ ではショートカットを覚えるほどではないものについては Find Actions を多用する派なので、VSCode でも Command Palette は多用しています！
モブプロでの学習
最初の開発については、FE メンバーとFEに挑戦するメンバーでモブプロで進めました。
- FE の実装においてはどのようにソースコードを追うのか
- ディレクトリ構造
- TypeScript のちょっとした文法
- テストの書き方(どの粒度でどのように書くのか)
などの疑問点を同期的に質問しながら作業することで開発の流れや実践的なスキルを学ぶことができました。 なお、最初の開発以降は、初めて取り組む実装の際は必要に応じて FE メンバーに協力をお願いしてペアプロやモブプロで開発することもあります。
プロダクト開発を通じた学習
実際にプロダクト開発することは何よりの学びになりました。
修正箇所の Figma のデザインやアプリケーションの操作から、コードを書くべき場所に当たりをつけてソースコードを読んでいく過程で component を組み合わせて画面が作られていることを実感しました。
個人的に FE 開発に限らず意識していることですが、少しずつ違う性質の実装タスクに取り組むことで担当できる領域を広げていきました。 そして、プロダクト開発を通じて以下のようなことを段階的に学んでいきました。
- Figma から情報を読み取って実装に反映する
- CSS の box model の style の調整について(margin、padding の使い方)
- Figma の Dev Mode で確認して実装したものと DevTools で対象の element を選択して Computed したものを見比べて style が正しいか確認する
- Testing Trophy の考えに従い、 component 単位でテストを書き、ユーザの動作を保証することについて
- エラーを表現する component の新規追加
- component の props で ReactNode を渡すようにして JSX で柔軟にエラーに関する情報を渡す
なによりこれらは FE メンバーに PR にて提案や指摘をいただいて学べたことです。ありがとうございます！
FE メンバーの PR をみる
バックログリファインメントに参加し実装背景や実装方法の方針がわかっているタスクについては、FE メンバーの PR を覗いて、TypeScript らしい書き方や自分では思いつかない実装方法や考え方について学ばせていただきました！
FE 開発をやって良かったこと
BE エンジニアが FE 開発に挑戦して学んだこと、見えてきた風景について紹介します。
システムの使われ方をより明確にイメージできるようになった
FE 開発でユーザーに近い部分を実装したため、ユーザーが実際にカイポケを使用する時のことがよりイメージできるようになりました。 FE のタスクとしてエラー時の UI や表示するメッセージを考える時だけでなく、BE で API (GraphQL server の実装)を追加する際にも、クライアントでどのようにそれが使われるのかを以前よりも解像度高く考えることができるようになりました。
デザインへの興味がでてきた
FE 開発の中で学んだこととして、
Figma の Dev Mode で確認して実装したものと DevTools で対象の element を選択して Computed したものを見比べて style が正しいか確認する
をあげたのですが、実際は多くの場合は Figma と社内 UI ライブラリで提供されている component の名前が一致しており、デフォルトの値が指定されているので細かな調整をすることは少なかったです。 これはデザインシステムを整備いただいていたからのようです！ (詳しくは デザイナーとエンジニアで育てる組織の共通言語としてのデザインシステム )
この驚きを機に UI の世界の共通言語やそれを表現する component に興味が出てきて、いろんなライブラリの component を眺めたり、他社のデザインシステムをカタログ感覚で見るようになりました〜
shadcn/ui、Tailwind CSS、Chakra UI の提供する component を見たり、プライベートで shadcn/ui を使用して画面を作ってみたりしています！
FE 系の話題について目に留まるようになった
日々ちょっとした時間にチェックしている、はてなブックマークのテクノロジーの人気エントリーや Zenn の Trending で流れてくる FE 系の話題について、表面的ですが何について書かれているのかわかるようになりました！プロダクト開発をした経験により見える世界が広がりました。
VSCode での開発に慣れた
道具を増やすことを意識して VSCode を使い始めたのが功を奏して、 Cursor を使用したり、最近盛り上がっている Cline を動かしてみたりといった新しい開発体験をプライベートの開発でカジュアルに試せるようになってきました。 (変わらず IntelliJ のことも好きなので JetBrains の Junie も楽しみにしています！)
また、VSCode を不自由なく扱えるようになったことで他の言語の開発やソースコードリーディングに対するハードルも下がりました！
ソースコードリーディングの力がついた
画面の表示や操作から仮説を立ててコードを追っていき修正箇所を見つける、という経験を通じてソースコードリーティングの力がつきました。 ユーザの操作 → API 呼び出し(FE の実装) → BE の実装 まで一気通貫でソースコードを追って問題を見つけられるようになりました。
BE の技術の幅も広がった
プロダクト開発とは関係がなくなるのですが、 TypeScript と VSCode での開発に慣れたのでプライベートで Hono を使用した実装の素振りもしました。 (RPC の開発者体験がとても気持ちよかったです)
(広く浅くにはなりますが)別言語や別の思想の Framework を触ることで、自分のスキルセットの中でメインで使っている技術の書き方にも活かせたり、扱える技術の幅を広げることができたのでよかったです。
FE 開発に挑戦したことでチーム開発に貢献できたこと
これまでに BE エンジニアが FE 開発に挑戦したことによる個人的な収穫について記載しました。 ここではチーム全体で提供できるユーザーへの価値を高めていくために貢献できたことについて紹介します。
FE メンバー(FE の主力の開発者)が実装難易度の高いタスクや新機能の開発に注力できるようになった
BE メンバーが、細かなバグ対応やエラーハンドリングのタスクを一気通貫で実装できるようになったことで、FE メンバーがよりインパクトの大きい開発に注力できるようになりました。 (今後は BE メンバーも徐々に実装の難易度が高いものにも挑戦していく予定です！)
なお、最初の2週間はモブプロの予定をたくさん入れていただき、BE メンバーが自走するまで手厚くご協力いただきました。今でも詰まってしまった際にサポートいただいています。ありがとうございます！
バックログリファインメントでの BE/FE の対応状況を整理しやすくなった
FE のタスクについてバックログリファインメントを行う際に BE メンバーがいることで、 BE の対応状況や使用する API について共有することができるため、タスクの見積もりの確度を高めるのに貢献できました。
FE、BE どちらもローカル時の困りごとの解消を手伝えるようになった
BE では単体テストや Subcutaneous Test で動作を保証しながら開発をしているため、 これまでは FE をローカルで起動していませんでした。 (ユーザの動作は dev 環境で確認していました)
FE 開発を機に初めてローカル起動するようにしたことで、BE の起動方法の知見と紐づけて以下のようなちょっとした手伝いができるようになりました。
- 特定の branch で BE を起動して動作確認する方法をドキュメント化して共有
- ローカルで BE のデータセットアップが不足していてエラーになるのを解消する
最後に
FE 開発は BE エンジニアにとって新たな世界が広がり、スキルセットを拡げる絶好の機会です。 また BE と FE の垣根を越えることでチーム内での協力体制を強化しつつ、プロダクト開発全体の効率化に貢献することもできるはずです。
この記事が FE 開発にも興味がある BE エンジニアの方にとって役に立てれば何よりです。以上です！
