この記事は LabBase テックカレンダー Advent Calendar 2023 の 8 日目です。
はじめに
こんにちは、株式会社 LabBase で SWE やっている上久保です。みんなからはリコピンと呼ばれています。この１年の仕事を振り返ってみると、今年はほとんど新規事業の立ち上げプロジェクトに参加していました。私は現在エンジニア歴 5 年目ですが新規事業プロジェクトに参加したのは今回が初めてで、上手くいかずに悩んだことや学んだり反省したことが多かったのでこの記事にまとめてみることにしました。
経緯
自分が参加した新規事業プロジェクトでは、エンジニアとデザイナー、あとは PdM やビジネス寄りの人 といった感じの少人数のチームで動いていました。コミュニケーションは毎日朝と夕方に 15 分~30 分程度の進捗確認と、集中的に議論をしたい場合は都度時間をとっていました。弊社では開発など作業の日は基本リモートワークをしているのですが、議論が必要なと時はオフラインで集まって効率的にやっていました。この辺りはいいバランスで出社・リモートを使い分けられていた印象です。
進め方
動き方としては、キックオフ時にチームのミッションを認識あわせしたのちに PMF を目指して価値検証のサイクルを繰り返し回す流れでした。PMF の定義、どこまでこのチームでやるかについてはこちらの記事がとても参考になりました。 具体的には議論して出たアイデアを形にして顧客に出したり、エンドユーザにインタビューをしたりして検証を繰り返し行っています。
学んだこと
なんでもやる
小さいチームなので当然フロント・バック・インフラの区別はなく、エンジニアリングに関しては自分が裁量と責任を持つという意識で取り組みました。例えばフロントエンドでは何度もコーディングを行う中で、一々言語やフレームワークの仕様を調べながら進めるということがなくなり、結果的に実装速度が向上しました。後、Figma のデザインをコーディングする際にはこの VS Code の拡張機能が便利なのでみなさん使いましょう。
インフラに関しては社内の SRE の協力で POC のデプロイ設定をテンプレート化したり、CI/CD 周りを素早く整備して開発の速度感を落とさないように努力しました。また、プロジェクトの後半では DB や社内のリサーチエンジニアが開発している API を利用するため、チーム外のメンバーとも必要に応じて主体的にコミュニケーションを取る必要がありました。
また今回のプロジェクトの開発の中で、サブタスクとして技術検証も同時に行いました。具体的には Svelte で開発したりしていたのですが詳細は別の記事で書きます。社内の中〜大規模なプロダクトに導入する前のサンドボックス的な役割も果たしていて技術のキャッチアップにも行うことが出来ました。
さらになんでもやるというのはエンジニアリングだけにとどまらず、デザインの議論や企業との商談なども出来るだけ同席してワンチームで動くことが大事だと思います。基本的には専門外の業務については最終的にプロの人を頼っていいと思いますが、任せっきりで何も考えないのは良くないです。各メンバーの動きが常に見えていることで信頼と一体感が生まれることをプロジェクトを通じて実感しました。
なんでもはやるな
上記とは矛盾しますが、このプロジェクトで一番やりたいことは何かを見失わないように常に振り返ることが大切だと感じました。開発しているとシステムの全体設計として最適なのかどうか、他のプロダクトの棲み分けが正しいかなどが気になりがちですが、あくまで今開発しているプロダクトに価値があるかどうかを探索することが最重要なので上手く優先順位を付けることが大事だなと思いました。作ったものを後から壊して一から作ることを嫌がらずに、価値のあるプロダクトを開発することにフォーカスするように心がけています。
また、私は議論を組み交わすのが好きな部類の人間なのですが、それだけに良い議論が出来た事に満足してはいけないということを学びました。チーム内での認識あわせが上手くいって、良いアイデアがまとまったとしても開発が間に合っていなければそれは机上の空論になってしまうからです。とにかく手を動かせという言葉を私は上司に何度も言われ続けていました。
チームで仕事をするといういこと
実は今年は複数の新規事業プロジェクトに参加していたのですが、その中のあるプロジェクトで当初高いモチベーションで参加していたにも関わらずプロジェクトの方針についてメンバーと意見が反発してしまい、結果思うような結果が残せずモチベーションが下がってしまったことがありました。その原因の一つには 最終的に誰がどうやって決定するか という部分が曖昧になっていたことがあると思います。その後は反省を生かして、チームメンバーは PdM に対して自分の意見を全て伝える義務があり、PdM はそこから方針を決定する責務をもつ という共通認識を最初に確認するようにしました。さらにチームメンバーは PdM の決定を信頼し、たとえ自分と違う方針に結果的に決まったとしてもそれに従うことが求められます。これは相手をリスペクトしていて、「この人の決断なら信用できる」と本心で思っていない難しいことなので、日頃からメンバーの仕事に関心を持ってリスペクトすることが肝心だと学びました。逆に、エンジニアリングに関しては自分が責任を持ち、信頼してもらえるように行動で示さなくてはならない訳ですが、そうして お互いにリスペクトし合える良いチームが出来ると感じました。
新規事業の面白さ
ここまで色々と学びや反省について書いてきましたが、それを上回る面白さが新規事業の立ち上げにはあると私は思います。１つは 自分が思うプロダクトの理想を考えてメンバーに伝える機会が多いことで、俗に言う「夢を語る」 ことです。会社やチームのミッションを達成するためには何が今のプロダクトだと足りないかを考え抜く中で、あれもこれもやってみたいとアイデアを出す時間は楽しいです。そして積極的に他人にぶつけてみることでどんどんブラッシュアップされて、地に足がついたものになっていきます。メンバーごとに少しずつ見えているものは違いますし、大切にしている価値も違います。さらには会社視点や顧客視点なども加わりさまざまな観点からの意見をぶつけ、それらの妥協ではなくいいとこ取りができるように頭を悩ませ続けるのが難しく面白いと感じました。
もう１つは 「夢を現実にする」 作業ができることです。プロダクト開発における全ての裁量を自分が握っていてやりたいようにやれる、そうして作ったプロダクトのリリースで喜んでくれる顧客やエンドユーザの存在はチームにとって何よりの励みになると実感しました。
まとめ
新規事業は不確実性が多く、中々成果に結び付かず辛い側面はあると思います。しかしプロダクト・サービスの未来について夢を語るのが好きで、それを自分の手で作っていきたいと思っているエンジニアならばそこに面白さを見出して高いモチベーションを維持することが出来ると思います。将来のキャリアとしてプロダクトマネジメントを視野に入れているエンジニアは特に経験しておくと有利な仕事だなと思いました。
ただし、最新技術の導入やパフォーマンス改善などプロダクトの質を高める中でエンジニアとしてのスキルを向上させることも同時に重要で、本来新規事業のプロジェクトだと待っているだけでは中々取り組む機会はないと思います。ここに関しては開発速度を極力落とさない前提で技術の導入を継続的にトライすることでスキル向上につながり、エンジニアリングの観点でもモチベーションを保てるのではないかと思いました。（こうしてテックブログに書くことも増えるので一石二鳥ですね！）
おわりに
明日のアドベントカレンダーはうちの CTO が書いてくれます。お楽しみに！
Discussion