4レーン体制への移行とチームの結びつきを強めるオフサイトの全記録

はじめに

こんにちは、患者さんと薬局をつなぐコミュニケーションプラットフォームであるPocket Musubi の開発ディレクターをしている松本です。

開発チームが大きくなるとき、必ずぶつかる問いがあります。「チームの生産性をどう高め、保ち続けるか」、そして「そのために最適な組織はどうあるべきか」。

Pocket Musubi の開発チームは、この8ヶ月でメンバーが19名から23名に増え、開発レーンを1つから4つに増やしました。この記事では、その体制変更とセットで設計した全員参加オフサイトについて書きます。

なぜレーンを分けたのか

8ヶ月前、私たちは機能開発1レーン＋SREという体制でした。当時は1つのレーンに多くのメンバーが集中して肥大化し、レーン内のコミュニケーションコストが高くなっていました。加えて事業の要請として、性質の異なる複数のテーマを同時に進める必要も出てきていました。

検討の結果、「3〜4名のスモールなレーンが1案件に集中する」体制を選択しました。狙いはスループットの最大化ではなく、アジリティの改善です。少人数にすることで意思決定のスピードを上げる狙いがありました。さらにこの体制を技術面で支えているのが、仕様駆動開発（OpenSpec）と、社内セキュリティ基準を満たした Claude Code などを活用したAI駆動開発です。仕様を構造化して共有することで認識のズレが減り、少人数レーンでも非同期の協働と開発ペースを保てます。実際にやってみると、大きなテーマを並列で進めながら、各レーンが自律的に動ける手応えがありました。

あわせてEMの着任や各レーンのリードエンジニア体制など、マネジメントラインも整備しました。「誰が何を見るか」が明確になったことで、規模が大きくなってもチームの見通しを保てています。

スケーリングで向き合う課題 — 横のつながりが薄くなる

もちろん、レーンに分けると向き合うべき課題も出てきます。代表的なのが、コミュニケーションがレーン内に閉じることです。

レーンが増えるほど、隣のレーンが何をしているか・どんな人がいるかが見えなくなる。さらに直近数ヶ月で4名の新メンバーがジョインしており、「同じチームなのに話したことがない」という状況が増えつつありました。

これを放置すると、ナレッジの分断・レーン間連携のコスト増・帰属意識の希薄化につながります。だからこそ、体制変更とセットで、FY26の頭に全員参加のオフサイトを設計しました。

オフサイトの設計 — 2つの目的に絞る

23名と多めの人数が参加するオフサイトなので、散漫にならないよう設計する必要があります。そこで目的を2つに絞りました。

レーン横断の相互理解（チームビルディング）
半年の成果の全員での振り返り（貢献の再認識）

この2つにした理由は明確で、どちらも「レーン内では完結できない」からです。レーン内の振り返りはスプリントごとのKPTで回っている。足りないのは横方向でした。

セッション1: NASAゲーム — 合意形成をレーン横断で体験する

オープニングのアイスブレイクは、定番のコンセンサスゲーム「NASAゲーム」。月に遭難し、母船までは約200km、手元に使えるアイテムは15個——どれを優先するかを1〜15で順位づけし、NASAの模範解答との近さで採点します。まず個人で順位を決め（10分）、その後グループで合意形成（30分）、最後に答え合わせ（15分）という流れです。

このワークにおけるポイントは2つ。チームをレーン横断で編成したことと、「多数決禁止」「デバイス（PC/スマホ）禁止」というルールを設けたことです。勝敗ではなく「普段一緒に働かない人と議論して合意する」体験そのものが目的なので、結論を急がず討議の質を優先しました。

狙いどおり、ここで場が一気に温まりました。アンケートでも「場が温まった」「話し始めるいいきっかけになった」という声に加え、「前提の置き方や意見の出し方に、その人の考え方の特徴が出ていた」という気づきが目立ちました。順位づけという共通の土俵に立つと、思考のクセや人となりが自然に見えてくる。後続セッションへの助走として効果的でした。

セッション2: 開発テーマ振り返り

メインの振り返りは2段構えです。まず全体で、前期に各レーンが取り組んだテーマ（薬局業務を効率化する外部連携機能、調剤報酬改定対応、運用基盤の信頼性改善など）と成果を共有。そのうえでレーン別の分科会に分かれ、模造紙と付箋を使ってKPTで深掘りし、最後に各レーンの学びを全体に持ち帰りました。

このセッションの価値は、職種をまたいで振り返れたことでした。PdM・PMM・エンジニアが同じ場で「事業価値・顧客価値 × 技術的挑戦」を語ると、同じ案件でも見えている景色が違うことがわかります。アンケートでも「職種を超えて案件の振り返りを聞けた」「実装以外の部分での気づきが多かった」「自分がいなかった時期も含めて“歴史の共有”になった」といった声が並びました。立ち止まって半年を振り返る時間そのものが、普段はなかなか取れていなかったのです。

セッション3: ストレングスファインダー — 強みベースの相互理解

最後は、事前に全員が受けたストレングスファインダー（ギャラップ社の才能診断。34資質のうち上位5つが「Top5」として出る）を題材にした相互理解ワークです。レーン横断の4チームに分かれ、進め方はこうしました。まず各自が「他のメンバーのTop5」を読み込み、その強みを体現していたエピソードや気づきをメモする（個人ワーク）。次に一人ずつ、メモした内容を本人に向けて共有する（グループワーク）。最後にチーム代表が「メンバーの意外な一面」を全体に持ち帰ります。

ポイントは、自分の強みを自分で語るのではなく、他者が具体的なエピソードで裏づけて伝える構造にしたことです。診断結果という抽象的なラベルが実際の行動と結びついて腑に落ち、同時に「自分が周りからどう見られ、何を期待されているか」が言語化されます。アンケートでも「診断結果が周りの見え方と一致していて面白かった」「予想以上に評価されていた領域があった」「普段より直接的に賞賛を伝えられた」といった声が目立ちました。

狙いは、心理的安全性と横の関係を強めつつ、「このテーマならこの人」という共通認識をつくり、強みベースの役割分担が自然に起こる状態にすることです。直近で4名の新メンバーが加わり、新レーンも生まれたタイミングだからこそ、効果の大きいワークでした。

学びと今後

アンケートでは推奨度が平均 8.8 / 10.0、全員が「目的を達成できた／まぁまぁ達成できた」と回答し、オフサイトの手応えは十分でした。一方で改善点も見えています。レーン横断の編成は相互理解に効きましたが、強みの体現エピソードや具体的な振り返りは「普段一緒に働くメンバー」同士の方が深まる場面もありました。

まとめ

この8ヶ月でチームの分割について学んだことを、3点に絞ります。

分割の軸は「速さ」ではなく「小回り」。スモールレーン＋仕様駆動開発（OpenSpec）は、スループットよりアジリティを取りたいフェーズと相性が良い。
デメリットのない組織変更はほとんどありません。組織を分割するほど横のつながりは希薄化しやすくなります。目的や課題の解決のために組織を変えることを恐れず、同時にデメリットへの対策も講じる——そのバランスが大事になってくる。
対策は単発で終わらせず、仕組みにする。オフサイトのような場も、普段のスプリントやKPTでは届かない「横方向」を補うものとして、定期的に続けてこそ効く。