こんにちは、エンジニアをやっているaidyakです。 普段バックエンドをメインで書いているエンジニアがフロントエンドのコードを読みに行くときに個人的に効果的だったTipsを3つお伝えできればと思います。
この記事はギフティ Advent Calendar 2025 11日目です。
何があったのか
普段の私はRuby on Railsを用いたバックエンドの開発が主な業務になります。実務ではRubyがほとんどで、フロントエンド周りの開発にはあまりタッチしていませんでした。 そんな中で、今のプロダクトを担当するようになって1年程経ち、フロントエンドへの理解が少ないことに気づきました。 というより、漠然と「フロントのこと何も知らんな...」とは思っていましたが、目先のタスクをこなしていくことに精一杯で、後回しにしていたというのが実情でしょう。
そこで、普段フロントエンドの開発を担当しているメンバーとも話して、自分もフロント周りを触ってみたい旨を話すと「やっていきましょう！！」と温かい言葉をかけてくださりました。こうして、意気揚々とフロントエンド周りのコードを読むようになるのですが、ここからが問題でした。
個人開発と実務の壁
私自身フロントエンド周りの技術を全く触ってこなかったかというとそういうわけでもなく、個人開発ではよく触っていました。 例えばサクッとUI付きの何かを作るのに、Next.jsやReactで実装することは最高の選択肢です。 しかし、いざ実務で使用するとなると話は別で、メンテナンスの側面や効率性の観点など、多くのことを考えてコードを書く必要があります。 当然、ただ動くからヨシ！というわけにはいきません。なので、「ただなんとなく動くものが作れる」レベルから脱却していかなければなりません。 少なくとも、大規模なコードベースでなければある程度は何がどこにあるのか、くらいはわかっておいた方が良いなと、実際のリポジトリを見て思いました。
試行錯誤した4つのステップ
1. とりあえずコードを読む（失敗）
いきなりですが、これはあまり効果がなかったなというのが正直なところです。 背景知識がない状態でコードを読みに行くのは丸腰でラスボスに挑むようなものです。 「これは結局何をしてるの？このファイルって何？」という疑問が連続し、早々に諦めました。
2. フロントエンドに関するPRを古い順に読む
米マイクロソフトの牛尾剛さんが紹介されている、ディープコードリーディングというやり方で取り組んでみました。
この手法の良い点は、今のコードベースがどう構成されていったのか？の歴史を辿って理解していける点です。 いきなり完成形を見に行っても挫折してしまったのは純粋な知識不足もさることながら、構築されていった流れが見えてこなかったからというのもあります。
ただ、私の場合はこれでもまだ不十分でした。 さらっとコメントに書かれていることや当時のやりとりを見ても情景が目に浮かんできませんでした。 これがPRの数だけあれば追っていくのも一苦労です。 私自身はこのプロダクトの立ち上げ期からいるので、その時その時で「これってどういうことですか？」と聞きに行けばと悔やむこともありますが後の祭りです。自分のできることをやっていくだけです。
3. チーム内でソースコード共有会を開く
時を同じくして、フロントエンドを開発しているメンバーから「バックエンドのことをもっと知りたい」という話をもらうことがありました。 これは我々バックエンドを中心に開発しているメンバーとしても渡りに船だということで、週に1度チーム内でソースコード共有会を開くことにしました。 これはかなり好評で、チーム全体としてサイロ化してしまっていた環境から、このプロダクトを構成している各要素をキャッチアップ、あるいは復習できるような環境に変化していきました。 最初はエンジニアだけでしたが、PdMも「話を聞いてみたい」ということで参加してもらっています。
具体的には
- フロントエンドのディレクトリ構造（App Routerの構成など）
- コンポーネント配置の哲学
- 設定ファイルの意図（どういう意図でそうなっているかなど）
といった話を共有してもらうようにしました。 普段から触っているエンジニアからすれば初歩的なことでも、その領域にあまり関わらないエンジニアからすれば難しいことになります。
4. DeepWikiを使う
ギフティでは開発現場でDevinを使うこともしばしばあります。私自身は開発自体にガッツリ使うことはあまりないですがDeepWikiはよく使います。 大抵の場合、自分のプロダクトと連携するプロダクトのことを知るために使っていましたが、今回はこれを自分のプロダクトをもっとよく知るために使いました。 使い方はシンプルです。DeepWikiのモードを「Codemap」にし、以下のプロンプトを流し込みました。
「フロントエンド初心者がこのプロジェクトを見たときに、最初に見るべき箇所を教えて」
これも効果がありました。Codemapモードにすることで、コードと解説を紐づけて理解できます。 しかし、ここで感じたのは「ソースコード共有会で事前に得た知識が大きい」ということです。共有会での前提知識があったからこそ、Devinの解説がスッと頭に入り、知識を補強できました。
もちろん、もっとうまいことやればDeepWikiだけでも同様の知識を得ることが出来るとは思います。 とはいえ、自分が得た情報とその解釈が本当に意図したものか、というのは実際に手を動かしてみないとわかりません。 なので、人から聞けるのであれば聞いて腹落ちするまで理解しようとするのが良いのかなと思います。
ここまでが私が実際にソースコードを理解するためにやってきたことです。 それまではただなんとなくコードを眺めて、「結局これは何？」と疑問が逆に増えているような状態でした。 これらのアクションを通して、ソースコードを読んだときに、少なくとも「これは〇〇という処理をしていて△△という役割を果たしている」ということが理解できるようになりました。
まとめ
フロントエンドのソースコードを理解するために試行錯誤した結果、私にとって効果的だった順番は以下の通りでした。
- チーム内でソースコード共有会を開いて有識者の知見を得る
- AIを使って前提知識を補強する
- PRを古い順から読んでコードの変遷を追う
いきなりコードを読むのではなく、まず「全体像と設計思想」を理解してから詳細に入るアプローチが、馴染みのない領域のコードを理解する上で有効でした。 また、今回の経験を通して実感したのは、「コードを読む」という行為は人に聞くことやAIを活用することで効率を大きく上げられるということです。 どんどん活用して、自分の中の理解度を高めていけると良いなと思いました。
これらの手法はフロントエンドに限らず、新しい技術領域やプロダクトのコードを理解する際にも応用できると思います。 それぞれの学習スタイルに合わせて、自分なりのアプローチを見つけていきましょう。
