スタートアップで3年フロントエンド開発をやってみた
はじめまして、アルプでフロントエンドエンジニアをやってますmura-です！
アルプでは、SaaS/サブスクリプションビジネスにおける販売・請求管理SaaSのScalebaseを提供しています。アルプには、Scalebaseがリリースされる数ヶ月前にジョインしました、アルプのフロントエンドとしてもそろそろ3年が経とうかとしております。
ここまで紆余曲折ありましたが、アルプにおいてフロントエンドエンジニアがどのように働いているのか、現状をまとめてみようと思います。
プロダクトチームの体制
2022年5月時点では、アルプは社員44名、そのうちプロダクトチームは25名となります。プロダクトチームは3チームあり、各チームはPdM1名とエンジニア、デザイナー数名で構成されています。
各チームのミッション
3つのチーム、X/Y/Zチームにはそれぞれオブジェクティブ（目的・目標）があり、チームはそのオブジェクティブを達成するためのアクションをしています。
Xチーム: 現在のScalebaseにない、新しい機能を追加していくというテーマを持つ。契約や請求の周辺業務を含めて様々な業務領域に対応できるのかを追う。
Yチーム: 主に契約や請求のモデリングを深めるというテーマを持つ。契約や請求について、どれだけ複雑なモノを表現できるのか、お客様のビジネスモデルやBtoB SaaS市場で求められる強度を有しているのかを探求。
Zチーム: 使い勝手の良さや、業務を楽にしていくというテーマを持つ。お客様からの特に強い要望の対応や、これまで画面の機能として提供しておらず制約を与えていたところを開放していくなど。
2021年末までは、1チームでやっていたのですが、かなりコミュニケーションにコストを割いていました。フロントエンドエンジニアは、機能面だけでなくデザインや使い勝手（UI/UX）まで考慮して実装していかないといけません。デザイナーやPO、ビジネスサイドなど様々な職種のメンバーと連携するため奔走していました。
チームを3つに分けてからは、各チームにPdMやデザイナーが居るので、調整するコストが低くなり、横断的な関心事などがあればPdMが持ち帰るなど、より効果的に仕事をすすめることができるようになっています。
チーム分けの詳しい経緯についてはCTO 竹尾の記事を参照ください🙏
作る機能ではなく、whyを重視する
Scalebaseのロードマップとして実現すべき機能、お客様とのコミュニケーションであがった要望、全職種のメンバーからあがったinsightなどを元に、PdMがPRD（Product Requirements Document、製品要求仕様書）に落とし込みます。
PRDには、どんな背景か、ユーザーが困っていることが丁寧に記載されています。これが非常にありがたく、背景がわかることで適切なスコープや詳細な仕様、目指すべきユーザー体験について自分の頭で考えることができています。
PRDの作成後に機能開発に関わるメンバーが集まり仕様の確認などを行います。その中でも特にフロントエンドエンジニアはUI/UXや画面からの都合など、機能以外の要素も考慮してどのように実現するのか、という観点で意見をします。
デザイナーとのコラボレーション
会社において方針は様々だと思いますが、アルプにおいてはデザイナーが考えてきたものをそのまま実装する、ということはなく、前述のPRD読み合わせやデザイナーとの壁打ちでより効果的で現実に即したものを作り上げるようにしています。
デザイナー側も、コンポーネント指向が強く、色んなパーツを組み合わせても破綻しないように考えてデザインをしており、フロントエンドエンジニアとしてはコードに落とし込みやすくとても助かっています。
下記に弊社が取り組んでいるデザインシステムについて詳細がありますので、ぜひ御覧ください。
チームをまたいだ取り組み
フロントエンド共有会
先にお話したように3チームに分割したのですが、そうするとチーム横断的な関心事をどう解消していくのか、ということが課題になります。そこで、フロントエンドエンジニア全員で集まって議論する「フロントエンド共有会」という場を設けています。
フロントエンド共有会では、新規機能開発に直接関係のない、コードの品質を向上させるための取り組みだったり、設計方針の横断的な検討などを行います。
特に最近では、依存性をサーバーサイドから剥がしDI（Dependency Injection）をできるようにしようという活動を行っています。
WAREMADO DAY
これはフロントエンドだけではないのですが、月に一度「割れ窓タスク」というものを消化しよう、という日を設けています。
「割れ窓タスク」というのは割れ窓理論から由来しており、開発者にとって軽微だが直しきれてないものを指します。
新しい機能を開発しながらも、割れ窓を直していき、なるべくバグを未然に防ぐような仕組みを取り入れています。
フロントエンドエンジニア大募集です！
スタートアップという特にスピードが求められる環境であっても、機能開発しながら、コードの品質も追い求めていく必要があると思っています。
幸いにもアルプでは品質や設計について意志のあるメンバーも多く、日々議論しながら研鑽を積んでいます。
アルプが開発しているScalebaseは、ドメインも難しく契約や請求という業務クリティカルな部分を担うサービスなので、堅牢かつ拡張性高く作っていく必要があります。
一緒にTRYしていただけるフロントエンドエンジニアを絶賛募集しております！カジュアル面談からでも応募できますので、ぜひお気軽にお声がけください。