2023年4月にSaaS事業の1人目のエンジニアとして入社しました、プレックスの石見です。
SaaS事業の立ち上げにおいて、1人目のエンジニアが1年目に何をやったかをまとめます。
- 経歴について
- SaaS事業について
- 4月、SaaS事業は「機能がないと始まらない」
- 5月、3ヶ月後の未来に備える
- 6月、変化を予期して、起こす
- 7月、「正しさ」を正解にする
- 8月、1人からチームになる
- 9月、プロダクトチームになる
- 10月、開発速度の躍進
- 11月、「個の最大値」をチームで超える
- 12月、次のステージへ
- 1年目を生き残っての感想
経歴について
DeNA（新卒） -> YOUTRUST -> プレックスとなります。
▼「なぜプレックスに入社したのか？」は、以下の記事をご覧ください。
SaaS事業について
現場作業が伴う事業者向けの業務効率化SaaS「サクミル」を運営しています。
2022年末からの大幅なピボットを経て、事業化に至ったタイミングで私が1人目のエンジニアとして入社しました。
4月、SaaS事業は「機能がないと始まらない」
- 入社
- ドメインのキャッチアップ
- 既存コードのキャッチアップ
- 写真台帳機能のリリース
- ChatGPTとCopilotを福利厚生に追加
入社して最初にドメイン（市場・顧客・競合）について学びました。良い設計、良いソフトウェア、良い実装は、特定の前提条件において「良い」ものになります。ドメイン（市場・顧客・競合）を知らなければ良いエンジニアにはなれないため、特に重視しました。
そして、プロトタイプのサービスがあったため、既存コードのすべてに目を通して理解をしました。現状はすべて過去の「当時の最善」の意思決定によって作られているので「なぜこの技術選定なのか」「なぜこの実装なのか」までを過去の議事録に目を通してキャッチアップしました。
また、写真台帳機能という大きめの新機能をリリースしました。
最後に、ChatGPTとCopilotを福利厚生に加えるように会社に提案をして受け入れていただきました。
5月、3ヶ月後の未来に備える
ピボットの関係で、現状と合っていないデータ構造が見られたため、テーブルスキーマを整理しました。テーブルスキーマが正しければアプリケーションコードはシンプルなものだけで良いため、事業検証の速度と開発の速度が担保できます。そのため、当たり前な機能の開発が主となるSaaS事業の立ち上げでは「テーブルスキーマの正しさ」は特にこだわった方が良いと考えています。
合わせて、アプリケーションコードのリファクタリングも行いました。
そして、事業進捗の速度を考えた時に私1人での限界が予想できたため、インターン生を採用することにしました。「なぜ業務委託でなくてインターン生なのか？」については、立ち上げ期の混沌においてはスタンスが固まり切っていない学生の方が適応力が高くパフォーマンスすると考えたためです。また、シンプルな機能実装でも学生にとっては貴重な機会となるため、学生のキャリアに貢献できるのも良いと考えました。
インターン生を採用するに当たって「なぜ採用するのか？」「どのような学生を採用したいか」「どうやって確かめるか」「何をお互いに合意した上で採用とするか」を決めました。
6月、変化を予期して、起こす
インターン生の採用をはじめました。育成前提で経験を問わなかったこともあり、結果として60名ほどの応募が来ました。ほぼ全員と面接を行いました。
事業と技術の両軸に関心がある学生を見極めるために、抽象的な技術課題を設けました。抽象的な課題であることから質問を可能としていたため、質問対応を行いました。技術課題を提出をしていただいた学生には必ずフィードバックをすると決めていたため、提出された技術課題を読み込んでフィードバックを行いました。
また、サービスのパフォーマンスの改善を行いました。
そして、プロトタイプから脱却をするためにフロントエンドのリニューアルの計画をしました。私がフロントエンドの専門性が高いエンジニアではなかったため、フロントエンド周りの技術のキャッチアップを行いました。技術の変遷を理解するのは非常に面白かったです。
最後に、スケジュール機能のためのカレンダーの実装をしました。
60名の方との面接を1人で行ったこともあり、喉を激しく痛めてしまいました。人事の方をより尊敬しました。
7月、「正しさ」を正解にする
- フロントエンドのリニューアル
- インターン生の採用決定
フロントエンドのリニューアルを行いました。Next.js 13（App Router）を採用して、アーキテクチャにはBulletproof Reactを採用しました。「事業立ち上げ期で機能の境界が固まり切ってないことから、featuresはroutingごとに切る」などの規約も多く策定してESLintで担保されるようにしました。
リニューアルやリファクタリングは「本当に必要なの？」と言われることもありますが、自分だけが見えているリスクやコストを整理して、提案と説得をして、結果として「正しさ」を事業の正解にするのがアーキテクトやテックリードの責務だと考えています。
また、インターン生1名の採用を決めました。本当に素敵な学生と出会えて運が良かったです。採用方針や技術課題の内容も非常に良かったことを実感しました。
既存のサービスの開発をしながらリニューアルに向けて、とにかく意思決定をして手を動かしていました。
8月、1人からチームになる
- フロントエンドのリニューアルのリリース
- インターン生の受け入れ
- スプリント開発とチケット管理の仕組みの構築
ついに、フロントエンドのリニューアルをリリースしました。サービスとしても非常に見栄えが良くなりました。開発体験としても適切な切り分けと規約によって意識する箇所が減り、開発速度が大きく向上しました。
そして、インターン生が来てくれました。1人でなくなった喜びもありつつ「未経験の学生をどうやって伸ばしていくか」というマネジメントと向き合いました。開発体験が向上してキャッチアップが容易になっていたこともあり、月末には1人のエンジニアとして活躍していただいていました。
また、1人でなくなったため、スプリント開発とチケット管理の仕組みを構築しました。
9月、プロダクトチームになる
- スケジュール機能のリリース
- チケット管理の仕組みを改善
- ドキュメントの整備
スケジュール機能をリリースしました。少しだけ大変でした。
チケット管理の仕組みにPdMの領域を取り入れました。これによって、要望 -> チケット -> 仕様 -> 進捗 -> PRまでが可視化されるようになりました。可視化されたことで、開発速度が向上しました。
最後にドキュメントの整備を行いました。
個人的には「プレイヤーとマネージャーの切り替え」に苦しみましたが、事業としては「パーツが揃った」と感じました。
10月、開発速度の躍進
フロントエンドのリニューアルから2ヶ月が経過して、一部の機能において想定と異なっていた箇所があったため、リニューアルを行いました。
また、不要な機能の削除を行いました。定期的な引き算は非常に大事だと実感しました。「また必要な時に考えて、再実装する」で良いです。
そして、前提が変わった箇所もあったためテーブルスキーマの整理とアプリケーションコードのリファクタリングを行いました。この際に日本語で表現する概念図とテーブルスキーマを表現するテーブル図を作成しました。これによって、サービス内の概念と表す単語と関係性の共通認識が取れるようになり、議論の質と速度が向上しました。
さらに、インターン生をもう1名採用しました。活発な2名の学生のおかげでチームに活気がつきました。学生から学ばさせていただくことは多いと実感しました。
最後に開発速度の向上によってリリース内容の把握が難しくなったため、リリースフローの整備を行いました。
開発速度が大きく向上しましたが、レビューや実装方針の決定など私がボトルネックになってしまうことが増えました。
11月、「個の最大値」をチームで超える
- スケジュール機能の追加リリース
- テーブルスキーマの整理
- コミットとPRの仕組みの構築
- ドキュメントの整備
スケジュール機能を拡張して追加リリースしました。こちらはインターン生の主導で開発をしていただきました。非常に良い機能になりました。
テーブルスキーマの整理を行いました。今回は概念の整理ではなくて、項目を増やしたりなど機能の拡張を行いました。
また、コミットとPRの仕組みを構築しました。これによって、レビュー工数が減り、リリースノートが自動で生成されるようになり、リリースフローの管理がより詳細になり、より容易になりました。
最後にドキュメントの整備を行いました。
チームとして最大値が出せるようになりました。
12月、次のステージへ
原価粗利管理機能をリリースしました。繊細な機能でしたが今までの仕組みと開発体験の向上のおかげもあり、楽に実装ができました。今後の複雑な機能も素早く丁寧に開発ができると確信しました。
テーブルスキーマの整理を行いました。今年中にすべてのテーブルの整理を終わらせるのが目標だったため、気合で進めました。
また、独自ドメインからのメール配信の対応を行いました。セキュリティの対応もあり、学ぶことが多かったですが、無事に対応ができました。
最後に、プロトタイプの完全廃止を行いました。
1年目を生き残っての感想
まず、本当に楽しい1年でした。人生の中で1番楽しかった。
個人としては「SaaSは1人でも実装できる。」を実感しましたが、事業の速度に追いつくには「1人では無理だ。」も実感しました。
この「事業に置いてかれないように、自分を拡張できるか。」という恐怖と「自分の理想を実現できるか。」という挑戦と、ずっと闘った1年でした。
そして「今の自分を乗り越える」「市場と顧客に貢献できる」「メンバーのキャリアを広げる」といったことが非常に楽しかったです。
来年はさらなる飛躍を控えているので、引き続き事業と技術に向き合っていきます！
「事業で勝てるエンジニア」「事業と技術の両軸」を志している方は、ぜひ連絡をください。
折れないで、一緒に闘いましょう。私はまだ闘い続けます。
