スタートアップで1人目エンジニアとして学んだこと
はじめに
私は前職でスタートアップ企業に 1 人目のエンジニアとしてジョインしました。その時に学んだことをここに書き記そうと思います。
私について
ジョイン時には、以前システムエンジニアをしていた時に React を使った業務が少しあった程度と、React, TypeScript, Redux を用いて個人開発の経験がありました。コードを書く分には不足はありませんでしたが、保守性や設計についてを考慮しての開発経験が乏しかったです。
Slate.js については当プロジェクトで初めて触りました。
サービスの概要
社内向けの情報共有ツールの開発におて、フロントエンドエンジニアとして Web サービスの開発に携わりました。
開発したサービスは、チーム内の情報ギャップをなくし、暗黙知を可視化することを目的とした、ドキュメントによるコラボレーションツールです。
主な特徴として以下が挙げられます。
-
ドキュメント同士のリンクをシステムが自動生成することで、情報のたどりやすさを向上
- ドキュメント内に出てきたワードと同一のドキュメントが存在していたら、自動で該当するドキュメントへのリンクとリンク先・リンク元の一覧をドキュメント内に自動で作成する
-
WYSIWYGエディターを基本とし、一部ではMarkdown記法にも対応して柔軟性を提供
-
#による見出しや-によるリスト等、ドキュメント作成に使用頻度が高い Markdown 記法を提供し、Markdown 記法への慣れ・不慣れに関わらず高いクオリティのドキュメントを作成可能にする
-
技術スタック
- React
- Next.js
- TypeScript
- Redux
- Slate.js (エディター開発)
- AWS Amplify (ホスティング)
以降、私がプロジェクトに携わっていた期間をフェーズごとに分けて紹介していきます。
プロジェクトの最初期
チーム状況
私がジョインした時はプロジェクトが立ち上がったばかりでした。
まだコードは 0 で、サービスのコンセプトや指針といった「何を作るのか」が明らかになったばかりでした。
会社のメンバーは、経営メンバー 2 名と週に数時間参加してくれる開発アドバイザーに、開発メンバーは私 1 人でした。
後述する体験版の開発にバックエンドを使用しないとの決定があったため、バックエンドエンジニアは体験版のリリース後に募集開始するとのことでした。
何をしたか
私が入って最初の仕事は、「何を作るのか」を詰めていく、すなわちアイデアを出してそれらを要件として詰めていくことと、どうやって作るかを要件から仕様に起こしてコードを書くためのドキュメントを作成することでした。
その他、アドバイザーと共に利用するライブラリの選定をしました。
少人数のチームで経営陣と密接に業務を行う中で、会社経営について学び、身近に感じることができました。
また、サービスの設計段階から携わる機会を通じて、システムの作り方について、知識だけでは得られない実践的な経験を積むことができました。
体験版の開発
体験版で実装する要件や作る機能が定まった段階で、VC から出資を受けるために必要な体験版の開発に取り掛かりました。
ここでいう体験版とは、実際に使用するのと大差なくユーザーが使用できるアプリケーションのこととします。
期日までにシステムを完成させなければ資本金を受けられず事業の継続が難しいという状況であり、もともとサーバーサイドの実装は体験版リリース後もとい資金調達が決定してからということだったことと、後述する要件を鑑みて、フロントエンドだけで体験版を実装することとなりました。
何をしたか
定義した要件を機能ごとにプロダクトバックログへと起票し、要件や仕様が曖昧なものに関しては経営陣と相談しながら詰めていきました。
アドバイザーから頂いたアーキテクチャを元に、Next.js / React / TypeScript でプロダクトの実装を進めました。
次の複雑な要件を満たすために仕込んでおいたサンプルデータをもとに CRUD する機能を Redux で作り込むこととなりました。
要件
- あくまで体験版のため実際に使用しないので、サインアップ・ログイン機能を取り除く(VC・見込み客からの要望)
- それぞれのユーザーごとにドキュメントの CRUD が行える
- msw の利用を考えたが Read しか行えないため断念した
- ブラウザをリロードすれば元のサンプルデータに戻る(開発都合)
- localStorage を利用するとリロードしても初期値にもどらないので断念
また、コア機能であるエディターの機能を最小限に抑えながら、独自機能であるドキュメント同士のリンクの開発に特に力を注ぎました。
結果として資金調達を目的として投資家向けに開発した体験版が評価され無事に投資を受けることができました。自らの手でシステムを完成させ、会社にとって大きなメリットとなる成果を直接的に生み出せたことは、非常に誇りに思っています。
ただ、この時は体験版を完成させて出資を受けることが目的となってしまい、その先のユーザビリティや保守性にまで目を向けられていませんでした。
ベータ版の開発
体験版のリリースを終えて VC から出資を受けられることが決まり、体験版から機能を追加したベータ版の開発が始まりました。
新たにバックエンドを書けるエンジニアを迎えてバックエンドの実装も始まりました。自分以外のエンジニアがフルタイムで入ってきてくれたことがとても心強かったことを覚えています。
何をしたか
まず初めに新しく入って来てくださったエンジニアからのレビューを受け、それなりに大きな改修をしました。
Redux のアーキテクチャに寄せすぎてしまい、このままではバックエンドとのインターフェイスの複雑化が予想されたため、全体的に Redux での状態管理の量を減らすことにしました。
アーキテクチャ規模での改修が済んだ後、エディターの機能を充実させるための開発がメイン業務になりました。
エディター開発に使用した Slate.js は、React および TypeScript との相性が良かったため採用しました。しかし、公式ドキュメントに基本的な使い方しか記載されておらず、独自要件に対応するための実装には苦労しました。この過程で、ライブラリの機能外での実装を TypeScript で行うことが多く、結果として TypeScript の知識が深まりました。
製品版のリリースとプロジェクトの終了
ベータ版の開発が進むにつれて徐々に開発メンバーも増えベータ版のリリースもでき、次は運用に耐えられかつ安全に利用できる製品版リリースに向けて進みましたが、不運が重なり会社を離れるメンバーが続出してしまいました。
最終的には私と CEO の 2 人だけで製品版の開発をすることになり、なんとかリリースまで漕ぎ着けたものの、会社を経営することが困難となりプロジェクトは終了となりました。
失敗から学んだこと
設計の経験不足
初期の段階では、設計の経験不足から苦労しました。具体的には、必要以上に変数を Redux の store 持たせてしてしまい、不要な Reducer が増え、コードが複雑化してしまうミスを犯しました。この失敗を機に、設計の重要性を認識し、設計スキルの向上に努めるようなりました。
自動テストの未実施
当時は自動テストについての知識がなく、テストコードを書かずに開発を進めていました。そのため、TypeScript で書いた関数をデバッグする際、ブラウザ操作やログ確認といった手間のかかる方法を使用していました。また、デグレーションが発生するたび原因究明に時間を要しました。
現在では自動テストを学び、自動テストが設計を改善するための助けにもなることを理解しています。
最後に
結果として事業はうまくいかずに終わってしまいましたが、経営陣のお 2 人は経験の浅かった私にも責任の大きい仕事を任せてくれたうえでしっかりフォローしてくれてました。それにより自分のスキルや経験を大きく成長させることができました。特に、アプリケーション設計に関する経験は、システムをバグを少なく、素早く作成する能力を磨く大きな機会となりました。
また、チームメンバーがみな人の話をきちんと聞いてくれる環境があったことも誇りに思う点です。
いわゆる報・連・相が苦手だったのですが、仕組みとしてこれらを適切に行う環境を作ってくれました。
私の機能の提案や質問に対して、メンバーはしっかりと耳を傾け、適切に対応してくれました。この心理的安全性を高く保つ取り組みが、成果に繋がったと感じています。
この時のメンバーにはいまでも感謝しかありません。
Discussion