Beatrust techBlog

Beatrust 株式会社の公式開発者ブログです。

スタートアップ創業期にリモート主体で進めてきたプロダクト開発チームの軌跡

はじめに

Beatrust VPoEの Ryo(長岡 諒) です。

Beatrust は2020年3月創業で現在3年目となりました。創業当初は3名だったのですが、現在社員は16名で業務委託の方も含めると30名以上の組織体となっており、初期からリモートワーク主体でした。しかし、リモートワーク主体の組織では意志を持って取り組まないとコミュニティのつながりが薄れサイロ化し、セールスとプロダクトなど各チームでのセクションの境界が強まり情報や意思決定の断絶が起こりがちです。我々も最初期は全員で議論していましたが、人数やチーム課題の変化に伴い共有・議論の仕方は進化しており、どんな変遷を経て行き着いたのかその過程から共有することで参考になるものもあるかと思いまとめました。

チーム開発においてどういった会議体・プロセスでプロダクト開発を進めようか試行錯誤している方や、リモートワークが主体となりチームサイズも拡大する中での取り組みに興味がある PdM(Product Manager)、エンジニア、創業メンバーなどの参考になればと考えています。もし気になった点などあれば、末尾の連絡先から連絡いただくか Twitter などでつぶやいていただけると反応できるかなと思います。

前提の補足

  • 社員16名は20代 ~ 60代(CEO が還暦超え)で転職者のみで構成されており、インターンシップの学生さんが2名いますが新卒の方は現在いません。
  • プロダクト開発チームとしては現在10名の社員(PdM + Designer + Marketing + App / SRE4名 + ML / Data2名 + EM)、週4日以上関わってくれている業務委託のエンジニアさんが2名、スポットで関わってくれている方が数名います。
  • 毎週金曜に"オフィスに来れる人は来て一緒に仕事をしよう"という任意出社の日を設けています。
  • 開発プロセスとしては スクラム開発 の手法を取り入れており、1週間の開発サイクルで進めています。
  • Beatrust は、組織内における従業員同士の自律的な協業を促進し「タレントコラボレーション」を実現するプラットフォームを提供している会社です。

本記事で伝えたいこと

本記事では Beatrust で発生した様々な課題の変化とそれにどう対応したかを振り返りまとめていますが、その中でも特に重要と感じており伝えたいことは以下です。

  1. チームサイズの拡充に伴い共有と議論のバランスをとって会議体を進化させる中で、全員で合議制にするのではなく意思決定のオーナーを明確にしつつ議論の流れに誰でも参加可能な環境を構築する。
  2. 社内外の方と目的を持った定期ミーティングを入れて次のミーティングまでに準備・検討することを明確にすることで、そこに向けてお互いに進捗を作りにいく。
  3. 創業初期のITスタートアップにおいて「フルリモートでも仕事はまわる」ことはこの2年で証明されてきたと感じます。そんな中で「たまに同僚と近いところで働くことでコミュニケーションを取りやすくなる」と感もじており、組織が拡大する中で最適解は模索し続けますが、心理的安全性や生産性向上のためにもオフィスに来れる方が集まりやすくする日を設ける価値はある。

また、本記事はここ2年 + αの Beatrust での取り組みを変遷からまとめていますが、最終形だけ知りたい場合は最後にまとめを記載しています。

プロダクト開発組織の変遷

約半年毎にチームサイズや周辺環境の変化に伴いプロダクト開発の進め方は進化しており、各タイミングでどういった変遷を辿ったかまとめました。

プロダクト開発サイクルの変遷

創業前(~2020年3月)

Beatrust の創業は2020年3月ですが、本格的に全員がフルタイムになる前に長い"準備期間"がありました。
各人 Beatrust 以外で本職を持ちながら時間を作って進めており、もともとは CEOの原共同創業者の久米Google 時代に着想を作り、有志で書かれた Angular × Firebase の MVP がある中でわたしは久米に誘われ2019年1月頃から関わりだしました。

現在 Beatrust は BtoB の Enterprise SaaS の領域での導入実績を伸ばしていますが、当時の対象は BtoC の利用者を想定しており、Angular のコードを引き継いで育てたり、コロナ前だったので有志で Yahoo! LODGE に集まり開発を進めたり、知り合いを集めて仮説検証を兼ねた meetup などをしていました。令和元年になった2019年の GW には沼津のわたしの家にみんなで集まり開発合宿なども行いました。

BtoC 時代の Beatrust 。裏側は全然別ですが当時のエッセンスが今も残ってます。

本職を持つ中で新しいことへの取り組みを手弁当で継続的に行うことは本当にエネルギーのいることで、意識的に集まる場を作りその手前で準備したり当日集まって作業を頑張る場を繰り返すことで徐々に検証を進めていました。最終的に現在の BtoB の形へ pivot する方向で考えた後、その課題が存在するかの仮説検証を数十社の友人知人にヒアリングした結果、解くべき課題だと検証できたため正式に創業していく流れとなりました。

当時の MVP のコードを育てるか一度捨てて再構築するかは考えましたが、今後中長期的にプロダクトを伸ばしていくにあたり Angular × Firebase より React × NestJS の方が技術面でも採用面でも有利と考え抜本的にアーキテクチャをきれいに刷新する意思決定をしました。BtoB での 1st リリースを極限まで早めるためには育てるという選択もありましたが、その後の成長を考慮すると正しい意思決定だったかと思います。

また、2019年9月ごろまでは Facebook の Messenger で関わる方やトピックごとに少数のグループを作成していましたが、通知も見づらく検索性も悪いので Slack を導入しました。

創業初期(2020年前半)

創業初期は、プロダクトの 1st リリースに向けて継続的にユーザーヒアリングをしつつ並行してチームビルディングも進めます。最初フルタイムの開発者はわたしだけでしたが、業務委託のエンジニアさんとして昔からのつながりの方でパートタイムが2名・知人からの紹介でフルタイムが1名(後に社員となった Neo)見つかり手伝ってもらいました。デザインは創業前からずっと関わってくれている業務委託のイギリス人デザイナーさんがいるのですが「昔ながらの業務システムのようなデザインでなく、日本国内だけでなくグローバル展開した際の多様なユーザーにとっても使いやすい UI / UX のプロダクトにしたい」と伝えてデザインしてもらっています。

プロダクトとしては BtoC に向けて作っていたものと全く異なるわけでなかったので最低限の土台はありましたが、BtoB で MVP をリリースしていくにあたり複数の大きな機能のうちどの優先度を高く開発するか、どれを不要とするかは以下のように決めることがありました。複数人で大きな方針の認識合わせをする際に使えるので、今でもたまに使っています。

  1. 事前に洗い出した機能に対して想定される工数概算とリターンを入れる。
  2. 各人の主観で5段階くらいの優先順位案を記述し、優先順位の平均と標準偏差を付ける。
  3. 平均で並び替えた後に標準偏差が大きいものは前提の認識にずれがある可能性が高いので議論する。
  4. 各機能の最終的な優先順位の合意を取りつつ記入していき、その機能が本当に必要なのか / 無いと死ぬ・検証できないというもの以外は Nice to Have として開発しない意思決定を行う。

当時実際に作った SpreadSheet、当時 Nice to Have としていた機能(Teams連携・検索ハイライト・多言語対応・組織図・Newsletter配信機能など)はチーム拡充に伴いリリースできています。

当時はプロダクト開発でどの機能をどう開発するかは、上のような認識合わせをしたのち、共同創業者でセールスを見ている久米とわたしで具体化しつつ、隔週で業務委託の方も含めた全員に現在の状況を共有していました。人数も少なく業務自体は進むのですが直近の仕事の話しばかりとなるため、週次で意識的に最近の仕事以外の話題をする雑談ミーティングであったり、どうしても短期目線になりがちなので月に1回目線を上げるために1 ~ 2年後やさらに先の Beatrust について考える Cooling down ミーティングなどを開催していました。

調達後の拡大(2020年後半)

7月の調達 の後に9月~12月は毎月社員が入社して人数が増えてきたため、週次で全社員が参加して先週からの進捗や今週取り組む内容などの各種共有を行うミーティングを作りプロダクトとセールス両関係者で共有し合うようにしていきました。

この時期から、業務上密に関わる方と 1on1 を定期的に開催することが自然と文化として根付いてきました。1on1 に関しては明確になにかの課題があって導入されたというより、各人の過去の経験に基づき相互理解や信頼関係の構築といったチーミングのために自然と発生しており、情報共有であったり困っていることの相互支援のためにも役立っていると考えています。

また、専門領域に関する知見のある社外の方との定期開催の check point ミーティングを意識的に入れるようにして、プロダクト面のアドバイザリーの方とは週次で PdM Check-In としてプロダクト検討の壁打ちを、セキュリティまわりは月次でセキュリティまわりを専門としている会社さんにお願いして定期ミーティングを入れてセキュリティや個人情報まわりの相談をしやすくしました。有識者に相談しやすくなるという目的とともに、次のミーティングまでの Next Action を明確にしてそれまでに進捗を作りやすくなる効果も意図しています。

この時期に行った別軸で重要なこととして、プロダクトの 1st リリースをして間もない10月に情報セキュリティマネジメントシステムの国際規格認証である ISMS を取得しておいたのはその先のエンタープライズ企業への導入に寄与しています。BtoB のプロダクトを作るにあたり、経験豊富な少数のエンジニアがセキュリティを意識しつつ構築することで一定安全なプロダクトは作れますが、拡大の過程でお客さまから外部監査は求められます。創業初期はそんな余裕がないということも重々理解しますが、初期のうちにプロセスを整備しておいた方が後からの変更より楽でもあり、ISMS 取得の過程で脆弱性診断を受けることになるためよりセキュアなプロダクトとなります。BtoB SaaS の立ち上げ期に初期から準備することがおすすめで、他にはマルチテナント環境でのセキュリティ担保やその先に向けて ISO 27017 や SOC2 などなど多様なトピックもありますが本題と逸れるのでぜひ DM などで聞いてください。

チーム化(2021年前半)

社員が増えチームも大きくなるにつれ、2020年12月時点の社員は7名で業務委託の方も含めて20名を超える所帯となってきたこの時期にいくつかの会議体が生まれました。

  1. 毎週様々な良いことや改善点が出てきますが全ては取り扱えないため、チームで改善サイクルをまわしていくためにプロダクト開発チーム全体で隔週で KPT を行い、類似の Problem をまとめた後に次の KPT までに取り組めるTryを2~3個決めて取り組む場を作りました。(Keep にその期間で良かったことを記述するのですが、毎回大量の Keep が出てポジティブな気持ちになるのはとても良い文化だと感じています)
  2. 週次での共有の場は存在しましたが人数も増え短期の話しに集中してしまうため、さらに広いスコープで先月の対応と今月のフォーカス / 目標を共有する All Hands という月次の全社ミーティングを設けました。成果を讃える場でありつつ、各チームで毎月何にフォーカスしていくのかを明確にして振り返りやすくする目的もあります。
  3. リモート主体の開発チームにおいて、「大きなリファクタリングや改修をどう / いつ実施するか」「Python のライブラリを統一したい」「ログのフォーマットを整備したい」「こういった方を採用したい」など、Slack では決めづらく調整の手間もあるけど全員で議論すれば 5 ~ 10 分というトピックは発生します。そのため Notion に「議論が必要で相談したいこと・共有しておきたいこと」を記述しておきオフィスに人が多く集まる日に 30 ~ 60 分集中して議論して方向性を決める Dev Team Sync という定例ミーティングを作り、毎週開発チームで議論しています。

現在、集中して作業する時は Google Calendar に作業時間として予定をブロックするようになりなくなりましたが、上記のようなミーティングに加えてユーザーからのフィードバックを聞いたり採用面談が発生するなどミーティングが増えてきて開発に集中ができないという課題が KPT であがった際には、試験的に日中 14:00 ~ 17:00 に極力ミーティングを入れないようブロックするなどの取り組みも進めていました。

Miro を用いた前回開催の KPT の図。赤が Keep で青が Problem、グルーピングして★をつけたものから Pick して Try 案を黄色で書いています。右下のアイコンは健康診断で胃カメラをした者による悲鳴。

この時期は、全体での方向性はみんなで話しつつ共同創業者の久米とわたしでどんな機能を開発するかの検討を進めていました。しかし開発含めた他の業務を行いながら優先順位の整備や要件の検討を行っていくことに限界を感じ、何をなぜどの順で作るかの決定をミッションとする PdM(Product Manager)の Role を作り、PdM は未経験ではありましたが、当時 BizDev 担当だった地頭のとても良い Rei にお願いしました。その後、専任の方を正式に採用しようと取り組み、2021年3月には同様に PdM 未経験で元 UX デザイナーの Aya に引き継いでいきました。

さすがに SpreadSheet での優先度整備はカオスになってきたため、PdM の Role ができる前頃から ZenHub という GitHub の Issue を用いてスクラム開発における開発生産性を向上するためのサービスを導入し、Kanban 形式の Board で優先順位を並べ替えたりステータス管理を行いやすくするなど進化させていきました。

スクラム化(2021年後半~現在)

ここまで書いて今さらですが、、、この時期まで「なんちゃってスクラム」な進め方だったと思います。 なんとなくイテレーション期間としている1週間の範囲で対応することを決め、対象の機能を開発する複数人で日々集まってミーティングをしていたのですが、大きな機能が数週間ずっと"対応中"として進むこともある状態から以下のように徐々にプロセスを整備していきました。

  1. スクラム開発での進め方として、大きな機能は極力 Epic(複数の Issue をグルーピングする仕組み)として管理してそこに小タスクとなる Issue を紐付けることで「今スプリントではこの Issue まで対応する」など進捗や対応内容が見えやすくなるよう整備していきました。(先に述べた ZenHub の機能で Epic と Issue を紐付けて管理できます)
  2. PdM が CSPO の研修を受けた2021年11月後半から、該当機能を対応する人だけに PdM や開発責任者から仕様を説明して進めるのではなく、大きな機能は 仕様説明会 を開催したり、プロダクト開発チームが毎週1時間集まり Sprint Planning として各人の対応内容の認識をあわせ翌週のチームとして何を達成するかという Sprint Goal を明確にする場を作りました。
  3. 稼働日は10:00からプロダクト開発チーム全員が集まり、前営業日で対応したこと・本日対応すること・Blocker(進めるにあたっての障壁)がないかを全員で15分以内で話す Daily Standup を行うようになりました。それまでは対象の機能開発をする人たちだけで集まっていたのですが共有にもなるので全員集まるようにして、Blocker の解消はその場が終わった後に必要な人が残って話したり別の場で解消するなどしています。

初回のSpring Planning。オンラインの方も含めてみなで全体に関して話し合い、その後必要であれば各機能のチームで追加で話し合う。

また、PdM によって Product の Roadmap の整備や優先順位の検討は進むのですが、KPI の解像度を上げたり次の大機能や市場においてどの領域に注力していくかなど、複数人が関わる中長期的な視点のトピックを意思決定する場が必要になってきました。社員も10人を超えて全員で議論して合意形成を作るのは難しい規模でしたが、大きなトピックに関しては誰がオーナーシップを持ってどう進めるか明確にし、直近の大きな機能に関してどういった優先順位で進めるかなどを決定する場として隔週で Product Roadmap ミーティング を開催するようになりました。 このミーティングはあくまで意思決定をする場としており、数名の必須参加者がいて各トピックのオーナーとなり議論を進めて方向性を決定して Next Action を明確にするのですが、誰でもそのミーティングに参加してコメントしたり内容は Notion でメモを残しあとで誰でも閲覧可能という形にしています。プロダクトカンパニーにおいてプロダクトに関する重大な意思決定は会社全体に影響を与え、重大な意思決定が社内の限られたメンバーだけで決められて経緯もわからないと、決まったことをただ作るだけ・もしくはその方針に違和感があった際にそのことを共有しづらい人が発生してしまう可能性があるため場の設計には特に注意しました。

時期は遡りますが、その他に2021年5月中旬はプロダクトの MVP の 1st リリースから1年弱を経て細かい「優先度は低いけど重要な対応」が負債として溜まってきました。そこで、大きなものは開発スプリントの中で対応し、Kaizen Day という1日以内のボリュームのタスクを開発者自身が優先度を決めて対応できる場を毎週1日作りました。機能開発や他の対応で忙しい時には参加しないことも選べ、毎週 Slack で Kaizen 用の Channel を作成するのですが、対応できそうなものを選び、対応することをチームに宣言した後に作業を始めるという文化が生まれました。 この Kaizen Day によって、放置されてしまっていたちょっとした不具合の解消や各種高速化やライブラリの更新などを「今度の Kaizen Day で対応しますね」などとして対応しやすくなったかなと思います。

その他、我々はユーザーフィードバックを重要視しており、リリースした機能の顧客フィードバックの場や事例共有の場にエンジニアも参加しています。個人的にとてもうれしい話で、2020年に MVP をリリースした後に各利用企業において Beatrust を必要としてくれるお客さまは一定以上いたのですが、2021年の秋〜冬あたりからユーザーフィードバックの質が変化し、明らかに熱狂している・感動しているお客様の利用事例が増えてきたと感じています。BtoB Enterprise SaaS の立ち上げはほんと時間がかかるものですが、個人的に潮目の変化を感じた時期でした。

まとめ

最後に、現状の会議体まとめとこれからの取組みについて記述します。

現在のプロダクト開発プロセス

各種課題を解決するために整備してきた会議体に関して全体像をまとめると以下のようになります。その他不定期でユーザーフィードバックがあったりセールスチームのミーティングなども別途ありますが当記事では割愛しています。

各種会議体の現状整理(2022年4月時点)

おわりに

ここまで読んでいただきありがとうございます。
現在のプロダクト開発の進め方が100%正解と言うわけではなく、日々改善しつつ進めているものです。本記事を読んでいただいた方からのフィードバックも楽しみですし、チームでよりよい開発サイクルを構築して今後さらにどう進化したかもまた共有できましたら幸いです。

また、本記事では Beatrust の文化を支える以下の場に関してはあまり記述できていないので、別途共有できればと考えております。

また、読んでいただいて Beatrust に興味を持ったり、プロダクト開発組織の進め方について議論したい方などおりましたら、ぜひ Twitter DM や meety などでご連絡いただけましたら幸いです。