こんにちは、プロダクトマネージャの田原です。
この1年間で、tunaの開発プロジェクトを0から立ち上げ、社内・社外問わず力を合わせ、プロダクトを今の形に持ってきました。
そして突然ですが、プロダクト開発の視点でその過程を振り返ってみると、成熟したプロダクトでなく、これから成長を目指す若いプロダクト開発に関わっているからこそ経験できたこと、と強く感じることがあります。それは
0からプロダクト開発をすることで、当たり前のように使ってきた開発スタックの解決してきた課題を追体験することができる
ということです。
それにより、組織・プロダクトのフェーズに合わせて適切な選択・決定をするために「必要な課題とその解決に必要なもの」の本質的な理解ができる、と感じています。
何もないところから全てを決めていく
0からプロダクト開発を行う、0からエンジニアチームを立ち上げる、そいった場面で決めるべきことは当然ですが山ほどあります。
- 技術スタックの選定
- 開発に使用するツールの選定
- インフラ・アプリケーションアーキテクチャの決定
- メンバー同士のコミュニケーションの取り方
- 用意するドキュメント
- 協業して行う開発タスクの進め方
etc...
そして、0からの立ち上げであれば最初から全てを理想的な状態に持っていくことは難しく、0地点から見える景色に基づいて必要と思われる決定をしてくことになります。そこからプロジェクトが立ち上がり、フェーズは常に変化していきます。開発チームはその度に様々は課題に直面します。
解決の前に課題がある
時が経つにつれ開発は進んでいきます。その過程で様々なフェーズを経て、プロダクトは変化していきます。そしてそれに伴ってエンジニアチームも変化していきます。
「プロダクト」・「それを作る人」が変化すれば、それに伴って今まで感じていなかった課題も生じることになります。いくつか例を挙げると
①数名規模から十数名規模になることでそれぞれの開発タスクの進捗が見えにくくなる
②人数が増えればコードベースの品質管理の難易度があがる
③プロダクトの機能が増える、リリースのサイクルが短くなることでテスト・デプロイの管理が煩雑になる
④ユーザー数の増加に伴い少しずつシステムが負荷に耐えられなくなっていく可能性
etc...
そして、ざっくりこのような課題に答える取り組みとしては、
①→タスク管理ツールの最適化(弊社ではGithub Projectを使用してます)
②→コーディングルールのドキュメント化
③→CI/CDの導入
④→コードベースの見直し、負荷の高い部分の非同期処理化、インフラ設計の見直し
など特に目新しいものはありません。ネットや書籍を漁ればいくらでも落ちていますし、多くのエンジニアの方にとってそういった「解決策」は既知のものでもあると思います。
ただ、このような課題を既知のものとして対策できているプロジェクトに参画した場合、認識は
解決策→課題
の順番になります。一方で0から開発に参画し、課題が未知のものである場合、認識は
課題→解決策
となります。
- なぜ、どういう時にそのツールを選択すべきなのか?
- どういう時にそのデザインパターンを採用すべきなのか?
- どのくらいのフェーズでどのようなインフラ設計をすべきなのか?
etc...
といった部分の本質的な理解は、エンジニアとしての戦闘力の底上げに大きく影響するなと感じています。
まとめると・・・
上記のような経験は僕にとってとても貴重な経験です。
スタートアップでの開発は整っていない部分が多い分大変なことも多いですが、上記のような経験は今後のエンジニア人生において大いに役立つと感じています。
少々遠回しになってしまいましたが、
- 自身の経験で直面する課題を解決していきたい
- 戦闘力の高まる環境で成長したい
と感じる方、7gardenのプロダクトや開発に少しでも興味を持っていただけた方は是非お気軽にご連絡ください!(本当に言いたかったことはこれです。笑)
引き続き7gardenをよろしくお願いいたします!