【開発文化紹介】Googleやメルカリのいいとこ取り。世界的エンジニアと創るSales Markerの開発文化
はじめに
CrossBorder株式会社CTOの陳です。Sales Markerをリリースして1年半が経ち、半年前まで2人だった開発チームもいつの間にか12名を超え、Google, Microsoft, Indeed, メルカリ, Woven Planet, Line,TikTok,SmartNews…
エンジニアなら誰もが一度は憧れる、世界的な企業出身のエンジニアたちが集結してきました。
Sales Markerの急成長を支える開発組織と文化は、この多彩なバックグラウンドから生まれつつあります。しかし、創業〜シリーズAのスタートアップの内部がどのように機能しているのか、外部からはなかなか見えにくいものです。
どうすれば持ち前のパワーを最大限に発揮できるのか。
今回は、そんなSales Markerの開発組織や意思決定プロセスなど、スタートアップCTOから見る景色を皆さんと共有したいと思います。
業界トップ企業からエンジニアが集結！各企業の開発文化をいいとこ取り
CrossBorderには、本当に優秀なメンバーが集まってくれており、毎日刺激を受けています。世界的なトップ企業で培った経験を持つグローバルなエンジニアと、日本から革新的なサービスを提供しているイノベーティブなエンジニアが互いに影響し合い、個々の足し算ではなく、相乗効果を生み出しています。
なぜ彼らがCrossBorderに転職を決意してくれたかは、後日別記事で公開予定なので楽しみにして下さい！
開発文化とは何か
各社毎に色々な解釈があると思いますが、自分は”共通の価値観と行動規範”と捉えています。
一度根付いた開発文化を変えるのには時間がかかる傾向があり、だからこそ初期の文化形成時期は組織にとって最も重要な時期だと考えています。開発チームの初期採用にはとことんこだわり、なるべく幅広いバックグランドを持ったメンバーを集めたのは、組織形成時期に様々な意見を取り入れたいと思ったからです。
進め方、マネジメント、コードスタイル。
なんでもフィードバックください
これは、私が初期メンバーに対して与えた最初のミッションです。折角優れた企業文化を経験したメンバーが参入してくれたのに、ただ合わせてもらうのはあまりにも勿体無いと思ったからです。
勿論、大企業とスタートアップでは根本的に違うので全てを受け入れるのではなく、あくまでCrossBorderの全社目標が存在している上で、我々独自の開発文化を生み出していくにはどうしたらいいかをディスカッションしながらいい所をどんどん吸い込んでいきました。
Sales Markerの開発文化
オープンで、チャレンジング
リモートがメインなのでSlackで日々コミュニケーションをしておりますが、基本的にDMはせずにオープンなチャンネルで話し合います。テキストで伝わりづらい場合、そのままSlackのハドルでクイックにディスカッションを始めるのはよく見かけます。
多国籍なチームで新しい技術に敏感なメンバーが沢山在籍しており、新しい情報が日々Slackでシェアされています。使えそうだと思ったらすぐに検証プロジェクトを立ち上げ、実際に適応された事例も多々あります。
特に昨今ではLLM技術が目まぐるしい進化を遂げているので、常に最新情報をキャッチアップしチャレンジしていく事を大事にしています。
チームは大きくアプリケーション開発、Data&AIとありますが、基本的にはプロジェクトに対して誰がどこを担当してもOK。フロントエンドのエンジニアがバックエンドのAPIを開発するのはよく見ますし、バックエンドエンジニアがインフラやプラットフォーム、AI周りのタスクもこなしています。
大企業で決まった分野を担当するのに飽き、より幅広く活躍したいエンジニアにはピッタリの環境だと思います。
異なる視点や専門知識を持つメンバーと連携することで、より効果的な意思決定や多様なソリューションを生み出せるチーム体制となっています。
1は0に勝る
Something is better than nothingと言う諺がありますが、1は0より遥かに価値があると我々は考えます。
特に日本では完璧主義が多く、気の済むまで作り込んで機能リリースする傾向にあります。しかし変化の激しい市場を1日も早く勝ち取るにはそれでは遅れをとってしまいます。細かく、早くリリースサイクルを作り、改善を重ねながらプロダクトを作っています。満足のいくまで作り込んだ結果、市場に受け入れられない機能だった方がリスクだからです。
細かくリリースを重ねていけば途中で方向転換やフィードバックを得られ、最終的にはより市場に合った機能に仕上がった社内事例が幾つもあります。
週次サイクルを採用し、毎日のスタンドアップ、週に一度のプランニング、月に一度のレトロスペクティブのみを定例として実施しています。ミーティング時間を最小限にしプロダクト開発に重点を置ける環境を整えています。
直近の事例で、新機能を開発する過程でデータサイズが一定を超える場合、あるバグを踏んでしまう事がわかりました。バグにパッチを当てて修正したり、実装方法を変えたりと方法は色々あると思いますが、どれも時間がかかりリリースを延期せざる終えません。
そこでメンバーとディスカッションし、”本当にそのデータサイズをサポートする必要があるのか市場に判断してもらおう”と結論し、データサイズに制限をかけた状態でリリースに踏み切りました。
結果、ユーザーが使用したデータは制限を超える事なく、対応しなくてもいい事がわかったのです。逆にこの機能を待ち望んでいたユーザーから早くリリースできた事に感謝のお言葉をいただきました。
裁量とオーナーシップ
ロードマップをプロジェクトに細分化し、全員が幾つかのプロジェクトリーダーを担当しています。各プロジェクトは背景、現在の状態と期待するアウトプットの定義のみ記載されており、具体的な進め方や期間は全てプロジェクトリーダーに決めてもらっています。
プロジェクトリーダーは、ビジネス背景や利用シーンをしっかり把握し、どのような機能であればより使いやすくなるのか？どう実装するべきなのか？を考え、プロジェクトキックオフ会を実施し正式にプロジェクト開始します。自分が実装まで担当することもできれば、設計だけを行って実装は他のメンバーに委ね、期日管理だけを行うこともできます。
プロジェクト・ライフスタイルは、プロジェクトがプロジェクトリーダーに割り当てられた後、プロジェクトが完了するまでに何が起こり、プロジェクトリーダーは何をすべきかを表しています。
上の図では、それぞれの色が異なるフェーズを示しており、フェーズが異なれば、そこにフォーカスする役割も異なります。
赤）計画フェーズ：管理者はこのフェーズにフォーカス
黄色）設計フェーズ：プロジェクトリーダーがこのフェーズにフォーカス
緑）実施フェーズ：プロジェクトメンバーはこのフェーズにフォーカス
青）リリースフェーズ：リリース管理者**はこのフェーズにフォーカス
プロジェクトリーダーの役割は、期待されている成果物に対してビジネスの背景を理解し、機能の設計と期日の設定を行い、EM（エンジニアリングマネージャー）やTL（テクニカルリーダー）と合意を得ることです。その後、安定したリリースまでしっかりと管理することが求められます。
プロジェクトの優先度、緊急度によりリーダーのアサインを決めるので、ジュニアメンバーでもリーダーになる事は多いです。こうする事で、普段ビジネスとあまり関わりのないエンジニアでも実装方法や利用方法をしっかり理解し、ビジネスとの緊密な連携を築くことができ、強固な関係を築いています。
よくあるソリューション設計からではなく、ビジネスプロブレムから関われる部分はチームメンバーから好評です。何故今この機能が必要なのか、どう言う時間軸で開発しなければならないのかをメンバー自ら考えて決める事で、実装方向とスケジュールへの納得感が生まれます。
達成した後は、皆んなで祝う
大きなプロジェクトを達成に際して、EMがお祝いのちょっと良いお菓子を買ってきて朝会でささやかなお祝いしたり、ロードマップを達成したらちょっといいお店でエンジニア飲み会してお祝いしたりします。
CrossBorderのバリューの中で”感謝”がありますが、本当に讃えあう文化が全社で根付いており、新しいリリースには毎度ビジネスサイドから感謝の嵐が飛び、お客様からのありがたいお言葉もしっかりシェアしてくれるので、実装した甲斐が感じられます。
最後に
本当に優秀な仲間が集まり、色んな文化を持ち込んでくれて凄く良いチームができつつあります。
一方でプロダクトの成長率が目まぐるしく、実現したい事も盛り沢山で開発チームもまだまだ人が足りておりません、
各ポジションで絶賛募集中なので、Sales Markerの開発チームに少しでも興味を持って頂いた方は是非一度お気軽にご相談ください！
募集中のポジション
この記事が気に入ったらサポートをしてみませんか？