はじめに
こんにちは、株式会社ACES でテックリードをしている福澤 (@fuku_tech) です。
テックリードという役割は、一言で説明するのが難しいポジションだとよく感じます。企業やチームによってその役割やミッションは大きく異なり、「ACES Meet開発では、テックリードは具体的にどんなことをしているの？」といった質問をカジュアル面談などでいただく機会も多くあります。
そこで本記事では、ACES Meetの開発チームにおけるテックリードとしての役割や、日々取り組んでいる課題、戦略、具体的なアクションについてお伝えします。テックリードというポジションに興味がある方や、ACES Meetの開発に関心をお持ちの方にとって、この記事が少しでも参考になり、興味を深めるきっかけになれば嬉しいです。
ACES Meetの状況と課題
ACES Meetは、まだ完全にPMF（プロダクトマーケットフィット）を達成していない段階にあります。このフェーズでは、開発チームとして以下の課題を克服していく必要があります。
- 市場の不確実性： 顧客の課題やニーズがまだ明確に定まっておらず、仮説の精度を上げるために多くの試行錯誤が求められます。その過程で、どの仮説を優先的に検証すべきかを判断する難しさが課題となっています。
- フィードバックの速度と質の確保： 仮説検証と市場対応を迅速に進めるためには、プロダクトの改善や新機能をスピーディにリリースできる体制が必要です。そのため、開発プロセスを効率化し、フィードバックサイクルを高速化することが重要です。また、得られたフィードバックを最大限効率的にプロダクトへ反映させるためのチーム内の連携強化も欠かせません。
こうした課題に対応するため、ACES Meetでは、DevOps Research and Assessment (DORA) の調査結果を参考に戦略を検討しました。特に、フィードバックサイクルの高速化を実現するためにどの指標に注力すべきかを考える中で、「変更のリードタイム」と「デプロイ頻度」の改善が現状では最も重要だと判断しました。
DORA Core Modelに基づいたACES Meetの技術戦略
DORA Core Modelは、ソフトウェア開発における組織の成功を成果（Outcomes）に結び付けるための構造を示しています。このモデルでは、以下の3つの要素が連携して成果を導きます。
- 基盤能力（Capabilities）： 開発組織が持つスキルやプロセス、技術的な基盤。
- パフォーマンス指標（Performance）： ソフトウェアデリバリーや信頼性を評価するための指標（4keysなど）。
- 成果（Outcomes）： 商業的な成功やチームの満足度など、組織が目指す最終的な結果。
(引用元: https://dora.dev/research/?view=detail)
ACES Meetでは、このモデルを参考にしながら、「変更のリードタイム」と「デプロイ頻度」の向上に注力することが、仮説検証のスピードを上げ、プロダクトの成長を支える重要な手段だと考えています。この2つの指標は、上記のモデルが示す商業的成功において重要な役割を果たすと捉えています。
そして、「変更のリードタイム」と「デプロイ頻度」を本質的に改善するために、直近1年は以下のCapabilitiesを優先的に強化する方針を採用しています。
- コード保守性（Code Maintainability）： 安定したコードベースを維持し、将来的な変更や拡張が容易な状態を保つことで、フィードバックサイクルの持続性を確保。
- 継続的デリバリー（Continuous Delivery）： 自動化されたデプロイメントパイプラインを活用し、安全で迅速なリリースを実現。
- 小さな単位での作業（Working in Small Batches）： 作業を細分化し、迅速なフィードバックを得られるようにすることで、仮説検証のサイクルを短縮。
なお、デプロイメント自動化（Deployment automation）、継続的インテグレーション（Continuous integration）、テスト自動化（Test automation）といった項目も、「変更のリードタイム」と「デプロイ頻度」の向上に重要な役割を果たしますが、これらは過去の取り組みによって一定の改善がなされ、現在ではCIが5分以内に完了する仕組みが整備されるなど、フィードバックサイクルの高速化を支える基盤となっています。この成果を土台に、現時点では新たな注力領域にリソースを集中させています。
ACES Meet開発におけるテックリードのミッション
ACES Meet開発におけるテックリードとしての役割は、ACES MeetがPMFを達成し、継続的に価値を提供できる組織となるために、まさに上記で記載したような技術戦略を立案し、それを実行しきる責任を担うことです。*1
これまでの章で述べたように、ACES Meetが現状直面している課題を克服し、仮説検証のスピードを上げるためには、以下の2つの軸で改善施策を進める必要があります。
- 開発文化と仕組みの変革
- 成果に繋がる技術的基盤の強化
具体的な取り組み
ここまでの章で述べた通り、ACES MeetがPMFを達成し、商業的成功を目指すためには、技術戦略を具体的な行動に落とし込む必要があります。その一環として、チーム全体で議論を重ね、技術ロードマップを策定しました。このロードマップでは、以下の2つの軸に沿って取り組みを進めています。
開発文化と仕組みの変革
開発チーム全体が仮説検証のスピードを上げ、プロダクトの成長を支える組織として機能するためには、技術的な基盤だけでなく、開発文化や仕組みを進化させることも重要です。これを実現するため、以下の取り組みを進めています。
小さな単位での作業（Working in Small Batches）の徹底
タスクを細分化し、小さな粒度でPull Request (PR) を作成することで、早期のレビューやフィードバックを可能にしています。この取り組みにより、変更のリードタイムが短縮され、迅速な価値提供が実現しています。
さらに、PRが小さいことで障害発生率が低下し、リリースの安定性が向上しました。障害対応の時間も短縮され、開発チーム全体の生産性向上に繋がっています。
詳細については、以下の記事もご覧ください。
レビュー最優先の文化醸成
レビューのスピードを重視し、2〜3営業時間以内に1次返信を行うことをチームのルールとして徹底しています。これにより、PRの滞留を防ぎ、変更のリードタイムをさらに短縮しています。このルールを守ることで、チーム全体のコミュニケーションがスムーズになり、開発フローの効率が向上しています。
積極的なペアプロ・モブプロの活用
ペアプログラミング（ペアプロ）やモブプログラミング（モブプロ）を積極的に取り入れ、次のような効果を得ています。
- 知識共有の促進： チームメンバー間での知識伝達をスムーズにし、属人化を防ぐ。
- オンボーディングの強化： 新規メンバーが早期にプロジェクトに慣れることをサポート。
- 設計の合意形成： 懸念事項を洗い出しやすくし、合意形成を迅速化。
- レビューのスムーズ化： 事前に設計や実装方針が共有されていることで、PRレビューの時間が短縮。
一方、ペアプロ・モブプロのやり方については、まだこれだという形が固まっておらず、書籍や外部の記事を参考に、現在進行形でより良いプラクティスを取り入れるべく試行錯誤している段階です。
AIをフル活用した開発
ACESでは、開発プロセスの各段階でAIをフル活用する文化を推奨しています。GitHub CopilotやChatGPT Teamを導入し、チーム全体の生産性を向上させています。
これらのツールを、ユーザーストーリー作成、要件定義、設計、実装、レビュー、テストといった全ての工程で、思考の整理や開発効率化のために活用しています。ただし、現在はまだ試行錯誤の段階であり、テックリードを中心に改善を重ねようとしているところです。今後、知見が蓄積され次第、整理して記事として発信できればと考えています。
成果に繋がる技術的基盤の強化
仮説検証を高速で繰り返し、プロダクトを迅速に成長させるためには、堅牢で柔軟な技術基盤が欠かせません。この技術基盤の強化において、ACES Meetでは以下の2つの柱に注力しています。
コード保守性（Code Maintainability）の向上
コードベースの保守性を高めることは、開発者が効率よく作業し、仮説検証を迅速に繰り返すための重要な取り組みです。これを実現するため、以下の改善に注力しています。
- 技術負債の解消：
- 新旧の記述が混在し、可読性が低下している箇所を統一的なスタイルへ移行。
- 複雑度が高く、開発者がコードリーディングや機能拡張時に余計な時間を費やしてしまう箇所を重点的に改善。
- コーディングルールの明確化とアップデート：
- 設計や実装時に迷いが生じやすい箇所について、コーディングルールを明確化し、ガイドラインをアップデート。
- デザインシステム準拠の汎用UI整備：
継続的デリバリー（Continuous Delivery）の推進
継続的デリバリーの実現は、「変更のリードタイム」と「デプロイ頻度」を向上させるための重要な鍵です。現在の週次デプロイから、より頻繁な日次デプロイを実現することを目指し、以下の取り組みを進めています。
- デプロイ時の安全性の担保：
- テストカバレッジの拡充やテスト戦略の見直しを行い、リリース時の不安を減らす。
- AWS AuroraのBlue/Green Deploymentを活用し、大規模なマイグレーションが発生する場合でも、安全かつ迅速にデプロイできる仕組みを構築。
- Feature Flagの導入：
- フィーチャーフラグシステムとしてDevCycleを導入することで、リリースとデプロイの分離を可能とし、段階的なリリースやA/Bテストを容易にする。（中長期的には、トランクベース開発への移行を視野に入れています。）
- リグレッションテストの自動化：
- 現在手動で行われているリリース前のリグレッションテストの自動化を進めることで、リリースプロセスを効率化し、信頼性を向上させる。
これらの取り組みを通じて、ACES Meetは現状、「変更のリードタイム」と「デプロイ頻度」の改善に注力し、仮説検証のスピードを高めることを目指しています。この戦略を基盤に、PMF達成とプロダクトの成長に向けて着実な前進を続けています。
なお、本章で挙げた具体例は、ACES Meet開発における取り組みの一部に過ぎません。特に効果が伝わりやすいものを選んで記載していますが、これら以外にも多くの施策を並行して進めています。
また、フィードバックサイクルの高速化に関連する詳細な取り組みについては、以下の記事でも紹介していますので、併せてご覧ください。
おわりに
ACES Meetの開発チームは、顧客の課題を解決し、価値を提供するために挑戦を続けています。その中で、テックリードとして私が特に意識しているのは、日々の業務をこなすだけに留まらず、チームの文化や技術的基盤を進化させ、フィードバックサイクルを高速化し、得られるフィードバックを最大限に活用する体制を築くことです。
この記事でご紹介した内容は、テックリードとしての業務の一部ではありますが、本記事を通じてその一端をお伝えできていれば幸いです。
本記事を通じて、ACESに少しでも興味をお持ちいただけましたら、ぜひカジュアル面談でお話ししましょう！
ACESの採用情報はこちら↓ youtrust.jp
*1:これは現時点でのミッションであり、事業やプロダクトの状況に応じて見直しが必要になる場合があります。
