グローバルなプロダクト開発を支える開発フローとカルチャー
こんにちは、amptalk 株式会社 CTO の鈴木です。
amptalk の開発組織は７割以上を外国籍メンバーが占めており、アジア、アメリカ、ヨーロッパ、アフリカなど様々な国から来たメンバーで構成されている非常にグローバルなチームとなっています。
開発チームでは英語をメインで使う一方、ビジネスサイドは大半が日本人で、業務では日本語を利用しています。こうした言語の壁が存在しているなかで、ツールや LLM を駆使してビジネスとエンジニアリングをシームレスに繋ぐ取り組みやカルチャーについて書きたいと思います。
以下のような方の参考になれば幸いです。
グローバルな開発組織を実現・検討されている CTO / VPoE / EM / PdM / HR の方
グローバルな環境での開発に興味があるエンジニア・デザイナーの方
amptalk の開発フローが気になっている方
amptalk の開発組織
前回の投稿から気づいたら２年が経ってしまっていまいましたが、その間にシリーズAの調達を行い、会社の規模も３倍以上に大きくなりました。開発組織も 10 名を超え、シンガポールを始めとして様々な国からエンジニアがジョインしてくれています。
amptalk としてグローバルなチームにすることを目的に据えていたわけではないのですが、創業初期から「採用は日本に絞らないようにしよう」と決めていた結果、それが自然とカルチャーになっていったと感じています。
来日経験がない中で日本に移住して入社してくれるメンバーもいて、その優秀さには日々驚きを通り越して圧倒されています。
採用についてもどこかで話したいと思いますが、今回は特に開発フローに着目して、amptalk のカルチャーをお伝えしたいと思います。
開発フロー
要望の起票から開発・リリースまでのフローを紹介します。全体像は下のイメージの通りで、個別に分けて説明していきます。
起票
カスタマーサクセスやセールスなどの Biz チームは機能要望がある場合、Slack のワークフローに従って起票します。
このワークフローでは
この機能によってどんな ISSUE が解決されるのか？
この機能を必要としているのは誰なのか？
を必須項目として指定しています。これは amptalk のバリューの中でも最も大切とされている ISSUE DRIVEN に基づいたものです。
Slack 上には Azure OpenAI と連携した自作の Bot が常駐しており、自動的に英訳を投稿してくれます（なおこの Bot は開発フローに限らず、全社案内などにもメンションをつけると勝手に翻訳してくれるのでとても便利です）。
バックログアイテム化
バックログの管理には Linear を採用しています。Linear と Slack の連携が充実しており、プロダクトオーナー（PO）は投稿からバックログアイテムを作成することができます。
なお Linear ではこの作成された１つのアイテムのことを「Issue / イシュー」と呼びますが、ISSUE DRIVEN の指す Issue と呼び分けがややこしいので社内では「Card / カード」と呼びます。
後述しますが Linear のカードは Slack のスレッドと紐づいているため、Slack 上から開発の進捗状況を辿ることができます。
Linear カードではテンプレートを設定することができ、エンジニアも
この機能によってどんな ISSUE が解決されるのか？
この機能を必要としているのは誰なのか？
を意識できるよう、テンプレートに沿ってこれらの項目を必ず埋めながら機能概要を作成していきます。
なおここはあえて完全に自動化はせず、人（PO やエンジニア）の目を挟みます。顧客の真のペインを解決するためには、要望された機能をそのまま作るのが正しいとは限らないためです。
作成されたカードはすべて、ROI を元に優先度順に並べられていきます。
開発
Dev チームはバックログを優先度順に着手していきます（Dev チーム内部の詳細なフローについてはまた別の機会にします）。
Linear は GitHub と連携することができ、
ブランチが作成されたらステータスを「進行中」に変更
GitHub でプルリクエストが作成されたら「PR」に変更
プルリクエストがマージされたら「マージ済み」に変更
というようにステータス管理を自動化できます。これにより、開発中は目の前のコードに集中できます。
PR が作成されると数千件の自動テストが実行され、すべてに合格するとマージができるようになります。amptalk ではテスト駆動開発を標準としており、これらのテストが品質の高さと開発速度の両立に貢献しています。
検証環境 → ステージング環境 → 商用環境までのリリースは GitHub Actions によって自動化されています。商用環境にリリースされると semantic-release によって、コミット履歴を元にリリースノートが自動で作成されます。
リリース通知
GitHub 上にリリースノートが作成されると、Zapier によって内容が整形され、Slack に通知が送られます。起票時とは逆に、Slack に常駐している bot が自動的に和訳まで行ってくれます。
また Linear カードは Slack のスレッドと紐づいており、ステータスが完了になると機能要望のスレッドに自動的に完了を通知してくれます。
Biz チームはリリースの内容を確認して、ユーザへの周知などを行います。
開発フローからみる amptalk のカルチャー
以上 amptalk の開発フローを、特に Biz - Dev 連携の観点からまとめてみました。
もともと OpenAI の登場前からグローバルな組織ではあったのですが、こうした LLM のおかげで日本語 - 英語間の障壁が取り払われ連携が非常にスムーズになったのを感じます。いまとなっては LLM なしでの組織作りは考えられません。
また今回は言語の壁に対する取り組み以外にも、Biz - Dev をシームレスに繋ぐ様々な自動化の仕組みを紹介しました。
自動化の実現にはツールの活用はもちろん大事ですが、自動化を支える根底には「徹底的な言語化とドキュメンテーション」の文化があると考えます。
たとえば Biz チームは機能要望を起票する前に ISSUE を整理して言語化する必要があり、Dev チームはリリースノートが正しく生成されるよう、正確なコミットメッセージを残す必要があります。
日本語は非常にハイコンテクストで、私自身も日本語で話していると「言わなくても通じる」「よしなにやっておく」が通用してしまうのを感じます。
一方で amptalk ではメンバー１人１人の母国語も文化も異なるのでそうはいかず、明確な言語化が求められます。こうした背景から言語化やドキュメンテーションが求められるカルチャーが醸成されてきました。
この言語化のプロセスは一見もどかしいように思えるかもしれませんが、
本当に解決すべき ISSUE はなんなのか？なんとなくでやることを決めてしまっていないか？を考え直すきっかけになる（ISSUE DRIVEN）
他のメンバーの正しい顧客理解につながる、後からジョインするメンバーの理解の手助けになる（EMPATHY）
というように amptalk のバリューである ISSUE DRIVEN や EMPATHY を実現する大事な要素になっています。
余談
私は amptalk 起業前は英語を全然話せなかったのですが、英会話を日課として課すようにしてきました。サボり防止のために自分の times チャンネルに毎日成果を貼るようにしていたのですが、ただの英会話 Bot になっている時期もあったので他のメンバーにはミュートされているかもしれません。
最近ようやく合計時間が 10,000 分を超えたのがこの記事を書き始めたきっかけです。
最後に
amptalk に少しでも興味を持っていただいた方は、ぜひご連絡ください。
グローバルな環境でのプロダクト開発に興味がある方はもちろん、英語には自信がないという方でも大歓迎です。必要なものは、プロダクト開発に対する熱意のみです。
採用ページから、もしくは私の X アカウントまでお気軽にお問い合わせください。