フロントエンドエンジニアが語るScalebase開発の魅力

こんにちは。アルプnote編集部です。
今回の記事では、アルプのフロントエンジニアの木山にアルプへの入社経緯やフロントエンドの業務について聞いてみたいと思います。

ーーー自己紹介をお願いします
木山と申します。アルプでは主にフロントエンドを担当しています。アルプには2020年の10月に入社しました。

ーーー簡単に経歴を教えてください
新卒では、社員10人ほどのtoC向けに口コミサイトを運営している会社に入社しました。そのときはフロントエンドのみならず、バックエンドやインフラなど幅広く担当していました。

前職ではtoB向けの商談用サービスを運営している会社で、10人ほどのチームのフロントエンドのリードをしていました。

ーーーアルプへの入社のきっかけを教えてください。
決め手となった理由は2つあります。

1つ目はプロダクトは今後伸びそうだなと思ったことです。
アルプでは、サブスクリプションビジネスを行う企業様向けに、今まで手作業や自社開発だった契約や請求の管理をSaasとして提供するScalebaseというプロダクトを開発しています。契約と請求といった業務はどの仕事をしていても必ず発生する業務だと思いましたし、前職のtoBの会社でも大変さを肌で感じていました。そのような業務を効率化していくScalebaseというプロダクトに携わることで社会に貢献できるなと思いました。

2つ目はメンバー全員が真摯であることにすごく惹かれたことです。
必ず自分の持った仕事は最後までやり抜くというのがチームで徹底されていると感じました。最後までやり抜くというのは、残業してもやるということではなく、自分の持った仕事についてわからないことがあったら適宜相談して解決に導くとか、手が空いてなくて無理そうだと感じたらメンバーに協力をお願いするとか、そういう行動も踏まえて自分の持った仕事を責任もってやることができるということです。この行動を実現するために掲げている、オーバーコミュニケーションやラストマンシップといったバリューに共感しました。

ーーーアルプの現在（2021年8月時点）のフロントエンドの体制を教えてください
フロントエンドを専任している社員は2人で、あとはパートナー（副業やフリーランスの開発メンバー）2人の4人で動くことが多いです。社員の2人に関しては、役割が分かれているわけではなく、1フィーチャーで2人の力が必要そうなら2人でやるし、臨機応変に動いています。

パートナーの方は、デザイン面で新しく置き換えたいComponentの実装をしたり、Componentの置き換えのタイミングでレガシーな設計があれば新しい設計に置き換えたりなどをお願いしています。

ーーーフィーチャー開発はどのように進めているのですか？
顧客、ドメインエキスパートのヒアリング内容をPRD（Product Requirements Document、製品要求仕様書）に落とし込むタスクがあるのですが、PRDはできている前提のフィーチャーの話をしますね。まずはフィーチャーグルーミングという、ビジネス職メンバー（以下 Biz）、プロダクトオーナー（以下 PO）、デザイナー、担当予定のフロントエンド / バックエンドが一同に介して認識合わせを行うキックオフの場があります。認識合わせというのは、このフィーチャーがどういう目的で作られているのか、どういうユースケースを想定しているのか、エンジニアの簡易な実装案・見積を共有したりすることです。

多少優先度などで前後することはありますが、基本的にはフィーチャーグルーミング後すぐに実装着手することが多いです。実装では最初にバックエンドとフロントエンドでこういうAPIが必要だよねという軽くすり合わせをして、protobufでAPIのリクエストとレスポンスのinterfaceを決めています。

開発中で気づいた問題点は逐次必要なステークホルダーにすぐに相談します。これはデザイナーとの相談が必要、これはPOに相談が必要など密にコミュニケーションを取りながら進めています。

実装が終わったらPOにデモを見せながらレビューをしてもらいます。POのレビューでOKが出たらリリース可能な状態となります。

ーーーフィーチャー以外の開発ではどんなタスクがありますか？
割れ窓タスクがあります。割れ窓は小さめのUI改善やリファクタリングのことで、Bizやエンジニアが気づいたタイミングでタスク化にしています。週に1回割れ窓タスクの優先度を振り分ける会があって、優先度が高いものから着手しています。

着手のタイミングは、フィーチャーの手が空いた時や、月に1回 **改善デイ** というフィーチャーに着手しているエンジニアも含めて全エンジニアが割れ窓をする日があります。

タスクではないですが、週に1回フロントエンドの技術共有会をしています。共有会では、実装での気付きや、ノウハウの共有、自分が担当した部分で他の人に知ってもらいところ、アーキテクチャ上の課題などを話しています。

ーーーアルプならではの面白さについて教えてください
Bizとの距離が近いのが魅力的です。枠として週何回も話すタイミングがありますし、枠の時間でなくても自然と話すことがあったり、Bizが考えていること、例えば売上こうだよとか、お客様の考えていることをダイレクトに聞ける機会が多いです。自分たちが実装したものに対してダイレクトに反応がもらえる、こういうところ役に立ってるよ、毎回使っているよという話を聞くと、やり遂げたなという達成感や、やりがいを感じます。そういうところはアルプならではの面白さだなと感じますね。

ーーー技術面での面白さも教えてください
プロダクトの性質上、複雑なドメインを扱うことが多く、フロントエンドでもUIが複雑になることがとても多いです。特定の条件だけUIを出す / 出さないが発生したり、一つの選択肢によって次の択が変わるなど、分岐が多くUIが複雑になりやすいです。そういうところを洗練された設計やUIで難しさを解消していくことは面白いですね。

課題としては、設計に対して試行錯誤の歴史があるので、古い設計思想の部分が残っているというのがあります。最新の設計思想に置き換えていくのに手が足りないというものありますが、既存を大きく変えるタイミングでもドメインが複雑すぎて置き換えづらかったりなどの課題があります。

ーーー木山さんはどういう方と一緒に働きたいですか？
責任もって最後までやりとげる人と仕事がしたいです。一人で抱え込むのが最後までやりきることではないので、一人で解決できそうでないなら人に頼ることができる、受け持ったタスクに対して面倒を見るというマインドを持った方と一緒に働きたいなと思います。

技術面では、設計に対して真摯な人、考えようと努力する人と働きたいです。設計自体に正解はないです、正解がないから設計に向き合わないのは違うと思っています。真摯に考え続けることに意味があり重要だと思います。私自身、真摯に向き合って3年後に自分に作ったものを見て破綻しないモノを目指していきたいと思っています。

ーーー終わりに
アルプではエンジニアを積極的に募集しています。今回の記事を見てご興味を持ちましたら、是非以下の採用ページからご応募お待ちしております！

アルプ株式会社