これはHubble Advent Calendar 2025の8日目の記事です。

1. はじめに

こんにちは、Hubbleでフロントエンド開発を担当している @ksakae1216 です。2025年10月、開発体制の見直しにより、私はLead EngineerとしてValue-upチームに所属することになりました。

この記事では、Lead Engineerとして主に担当している仕様検討と設計書レビューの業務において、私が大切にしていることを共有します。

体制変更の背景

Hubbleでは、プロダクト開発のスピード向上と品質担保の両立を目指し、開発フローと体制を見直しました。主な変更点は以下の通りです。

標準フローと大規模フローの導入

開発フローを2つに分けました：

大規模フロー: 新規プロダクト開発や全社アーキテクチャに影響する案件向け。多段レビューで品質と戦略整合を優先
標準フロー: 機能追加や改善を迅速に進めるプロセス。CTO室やCTOは原則関与せず、スピード重視

つまり、大規模フローはstepが多く、標準フローはstepが少なくスピーディーといったところです。

Lead Engineerの設置

各SquadにLead Engineerを配置し、以下の役割を担います：

仕様レビューでの技術的実現可能性や依存関係、非機能要件、将来的なリスクの評価
プロジェクト組成時の技術的観点からの助言
開発フェーズでの大きな技術判断やアーキテクチャ選定のリード

今までとこれからの違い

今まで（体制変更前）

Tech Leadがプロダクト全体に対して広範な責任と役割を担っていた
技術的判断やレビューがTech Leadに集中し、ボトルネックが発生しやすかった

これから（体制変更後）

Lead Engineerが各Squadに配置され、仕様検討の段階から技術的観点を提供できるようになった
Tech LeadはDev eXなど横断的な部分に注力し、プロダクト開発のスピードが向上
標準フローと大規模フローを使い分けることで、案件規模に応じた適切なレビュー体制を実現

今までは普通の開発までTech Leadがレビューしなければいけなかったのですが、エンジニアの人数が増え、全てのレビューをするのが難しくなってきたので、必要な時のみ、Tech Leadに依頼し、基本Lead Engineerが責任を持ってレビューするようになりました。

次のセクションでは、Lead Engineerとして大切にしていることを、そしてその後のセクションでは、仕様検討と設計書レビューそれぞれで具体的にどのような点を重視しているかを紹介します。

2. Lead Engineerとして大切にしていること

私は、Lead Engineerの前に、Frontend Engineerとして、ユーザーに素晴らしい体験を提供したいと思っています。

ユーザーが直感的に画面を操作し、ストレスなくやりたいことが完了する。シンプルだが難しい、このことを求めて日々開発しています。

そして、最高峰の体験については、弊社の @kohets がNoteの記事で言及していますし、先日、グッドデザイン賞を受賞することができました。

@kohets の記事「最高峰の体験を目指して」では、Hubbleのデザインについて語られています。日常に溶け込むデザイン、会話が生まれる場所、必要な時だけ見える、説明のいらない使い心地、軽くやさしく疲れない体験。このような考え方が、Hubbleのデザインの根底にあります。

Lead Engineerとして仕様検討や設計書レビューを行う際も、この「ユーザーに最高峰の体験を提供する」という視点を常に持ち続けています。技術的な実現可能性やアーキテクチャの妥当性を評価するだけでなく、ユーザーにとって本当に良い体験になるかという観点からも、仕様や設計を見ています。

3. 仕様検討で大切にしていること

フロントに関する仕様検討は、PdMともう一人のLead Engineer @moneyan9 さんと私の3名で行います。

仕様検討で最も大切にしていることは以下の2点です。

この課題に対しての、ソリューション（解決策）はこれで良いのか？という視点

仕様を策定してくれるPdMではないからこそ、第3者の目として新鮮な思考（前提知識のバイアスなし）を持っているからこそ、最初に立ち返り「他にソリューションは無いのか？」と考えるようにしています。

第3者として「そもそもこの課題は何だったっけ？」と立ち返り、別のアプローチがないか考えることが大切だと思っています。

UI/UXの妥当性

今までのHubbleの体験と合っているか？
他のサイトでこの課題をクリアしているものは無いか？

上記の視点でFigmaのデザインを見るようにしています。

グッドデザイン賞を受賞したHubbleの体験を損ねないよう、既存のデザイン言語との整合性を常に確認します。また、業界のベストプラクティスを参考にし、ユーザーが既に慣れ親しんでいるパターンを活用することで、学習コストを下げることも意識しています。

4. 設計書レビューで大切にしていること

フロントエンド、バックエンド両方の設計書をレビューしており、特に他の機能との違いや考慮漏れは注意して見るようにしています。

他の機能との違い

他で似たような機能があるのに、異なる実装を予定している時は、その理由を聞きます。

似た機能が、開発の都度、異なる実装になるのは明らかにおかしい。もし今回異なる実装にするのであれば、他の類似機能もリファクタすべきです。

過去、正解だと決めたものが、時間が経ち正解じゃないかもと思うことはあるので、上記は問題ではありません。問題なのは、明確な理由なく実装方針を決めることなので、その点に気をつけています。

「前回はこうだったから」という理由だけでは不十分です。なぜ今回も同じアプローチなのか、あるいはなぜ変えるのか、その理由を明確にすることで、一貫性のある設計を保つことができます。

考慮漏れ

これは設計者本人より、他者が気づきやすいところです。設計書を見るときに、「あれ？ここフワッとしてるな」とか「ここどうなるんだ？」と初めて見る設計書で且つ、他者なので気づきやすいです。

例えば最近だと以下の点を指摘しました：

マルチセレクトボックス（セレクトボックスに複数の値をセット）の項目に対してCSVアップロードする時のフォーマットはどんな形を想定します？
このAPI、PUTになってますが、他の似た機能はPOSTですよ。

設計者は全体像を把握しているがゆえに、細かい部分が「当然こうなる」と省略されがちです。しかし、実装する側やレビューする側から見ると、その「当然」に対して不明確なことがあります。そんな「フワッとした部分」を指摘することで、考慮漏れに気づくことができます。

理由を説明する

最後にレビューで気をつけているのは理由を説明することです。

「この方がいい」のような理由が無い指摘はしないように心がけています。

「〇〇だからエラー処理が必要」のように発言するようにしています。理由があるからこそ、相手もそれに対して、賛成、反対の意見を出すことが大切です。

理由がなく、「この方がいい」だけだと、相手はどうすることもできません。レビューは対話であり、一方的な指摘ではありません。理由を明確にすることで、建設的な議論が生まれ、より良い設計につながります。

5. 今後やっていきたいこと

今後は、以下の3点を目指していきたいと考えています：

最高の体験を損ねない
QAチェック時の仕様漏れ発覚を防ぐ
レビュー指摘事項の減少

最高の体験を損ねない

冒頭にも記載しましたが、グッドデザイン賞を受賞できたHubbleというプロダクトの体験を損ねることなく、提供し続けることができるよう、仕様検討では、ソリューションとデザインにこだわっていきます。

妥当な設計とレビュー指摘事項の減少

設計書レビューは、妥当な設計（実装方法、考慮漏れ無し）にすべく実施しています。

理想は、レビューでの指摘が0に近くなることです。そのため、理由を添えた指摘、今までの経験を全員に共有し、共に成長することでレビュー指摘事項が減少し、QAチェックでも仕様漏れが無いという状態を目指したい。

レビューは「指摘する」ことが目的ではなく、「良い設計を作る」ことが目的です。チーム全体で知識を共有し、設計の質を上げていくことで、レビュー自体が不要になる日が来ることを目指しています。

6. 最後に

この記事で日々思ってることを言語化することで、自分が大切に思ってることを整理することができました。

私個人だけでなく、チーム全体で成長していくことで更に良いプロダクトを作っていこうと思います。

この記事が誰かの役に立てたり、Hubbleのプロダクト開発に興味を持ってくれたら嬉しいです！

明日は、CREの @beyan125 さんです！！