iwashi のポストから、LeadDev の Staff+ engineers must rebuild team culture を読んだ。James Socol が 2026年8月18日に書いた記事で、ツイート側はすでに日本語の箇条書きになっている。ただ、大事なのは本文のほうだった。以前のチームがどんな空気だったか、会議がなぜ無駄になったか、文化がどこで定着していたか。そこまで含めて翻訳し、まとめたうえで、自分の意見を書いておく。
記事が言っていること
Key takeaways は3つに要約されている。
- AIで仕事が並列になると、チームの条件だった共有ゴール・相互依存・安定が削られ、出荷は増えるのに孤立する
- 文化は日常の共同作業で形になる。AIが同僚との問題解決を代替すると、規範を定着させていた共有体験が消える
- かつて自動で起きていたことを、Staff+ が意図的に作り直す。望ましい行動を称賛する、チャーターを書く、協働を自分でやって見せる
本文は、この3点を「以前のチーム」と「いまのチーム」の対比から始めている。
出荷は増えた。空気は変わった
1〜2年前のチームは、スプリントにゴールが1つか2つしかなく、みんなでそれを分解して並列に進めていた。詰まった人がいれば、すぐ誰かが手を貸した。会議は前向きで、技術的負債も払いながら実験のデータを集めていた。雰囲気は協力的だった、と著者は書いている。
いまは、AIのおかげで以前より多く出荷している。スプリントのゴールはエンジニアの人数ぶんある。1つの機能を並列に進めるのではなく、実験そのものを並列にしている。空気が変わった。
詰まったときに助けを探すのが難しい。会議は時間の無駄だと思われている。実際その通りで、みんなで問題を解くのではなく、各自が自分に関係のないステータスを読み上げ、残りは半分しか聞いていない。自分のゴールには影響しないと分かっているからだ。
チームか、個人の集まりか
ここが記事の骨格だ。過去25年の研究が、チームを個人の集まりから分ける印として挙げているのは次の3つである。
- 共有ゴール。 成功も失敗も集団のもの。一部だけ成功して一部が失敗できるなら、それはチームではない。各自のゴールが優先され、協力より競争が合理的になる。ゴールが少なければ、一緒に達成するインセンティブが残る。
- 相互依存。 補完するスキルがあり、共有ゴールに向かう途中で互いを必要とする。スキルが重なっていても、コードレビューのような習慣が相互依存を担保してきた。
- 安定したメンバーシップ。 Verizon の Richard Dalton の言葉として、チームは immutable な構造だ、と引いている。メンバーが変われば別のチームになり、forming-storming-norming-performing をやり直す。安定しているほど、performing に長く居られる。
AIは、エンジニアが機能全体を一人で出荷できるようにした。その代償が孤立である。独立性は摩擦を減らす。その摩擦の中身が、コミュニケーションと協働だった。文化は、そこで伝わっていた。
文化は「この辺りのやり方」で、共同作業が定着させる
文化を、著者は “the way we do things around here” と言っている。称賛される行動、許容される行動、禁止される行動の集まりだ。規範は、メンバー同士の日常のやり取りで確立され、定着していく。
個人の集まりには、共有文化がないことがある。各自のやり方が違い、仕事のどこを大事にするかも違う。ゴールが独立していると、助け合う意味も見えにくい。以前は人から答えをもらうとき、その裏に物語と戦傷と教訓がついてきた。いまは、AIが蒸留した答えだけで日々が完結する。共有体験が減る。
Staff+ が文化を動かす手段
Staff+ は組織からお手本として扱われる。成功している人が取る行動は、他の人も真似したくなる。文化が「やり方」なら、ある行動を奨励するか、やめさせるかで文化は動く。
記事が具体的に挙げているのは3つだ。
称賛する。 チーム内の短い shout-out でも、Slack の #kudos のような広い場でも、誰かの選択を褒めることは「組織はそれを増やしたい」というメッセージになる。複数チームを見ているなら、外に話を出すと、その働き方が正規化される。場がなければ作ればいい。Slack チャンネルでも、セレモニーの中の shout-out でもいい。極端な例として、前職では会社の価値観を体現した人に、2週に1回の全社 all-hands で Legend 賞が IC から IC へ渡っていた、と書かれている。
書き残す。 チームチャーターや working agreement を、意見を募りながら書く。文化の会話が起きるし、あとから意思決定の指針として指差せるものになる。ただし write-only にしない。参照し、必要なら更新する。
やって見せる。 組織の中のリーダーとして、自分の動きは「真似してよい」と読まれる。称賛の習慣を作りたいなら、自分から shout-out する。判断のプロセスを説明すると、チームは同じ価値観の当て方を見られる。“it depends” が、現場ではどう見えるかを学べる。
リモート移行と同じ種類の変化
最後に、著者は急なリモート移行と重ねている。同じ空間にいることで自動的に起きていた交流を、当時も意図的な仕組みで置き換える必要があった。いまも同じだ。ペアリング、共有ゴールに仕事を寄せること、一緒に計画し設計すること。以前は自動で起きていた文化づくりの機会が、いまは選択しないと起きない。
Staff+ はもともと、チームの中と横断の接着剤である。コミュニケーション、文書化、計画、共有、レビュー。その時間を、チームのやり方を確立し定着させる機会として使えばいい。高パフォーマンスなゴールをはっきり持ったうえで、習慣と規範を作る機会を自分で取りに行く、というのが結びだ。
読んで思ったこと
ツイートの箇条書きは正確だった。ただ、本文を読んで残ったのは「出荷量の話」より、「ゴールを人数分にした時点で、チームを解散している」という感じのほうだった。
000101 では、職能横断はチーム単位ではなく、個人がロールを変えながら動く形になってきている、と書いた。この記事は、その裏側を突いている。個人が強くなり、一人で機能を出せるようになると、チームである必要が薄く見える。薄く見えることと、薄くしていいことは違う。
自分は受託で、ほぼ一人で案件を回す期間が長かった。レビューの文化が薄い、という言い方を以前もしている。一人で出荷できるのは強い。その代わり、判断の経緯と失敗の感触が、次の人に残らない。AIはその穴埋めを、さらに個人の中で完結させる。同僚に聞く代わりに、蒸留された答えを受け取って次へ進む。速い。ただ、速さの代金が「このチームのやり方」の消失なら、あとから高くつく。
会議が無駄になる理由も、技術の問題ではない。自分のゴールに関係ない更新を聞かされているだけだからだ。ゴールを共有していない会議は、最初から協働の場ではない。ステータスの読み上げは、個人の集まりがチームのふりをしている時間だと思う。
Staff+ という肩書きの話に読まなくていい、とも感じた。記事が言っているのは、影響のある人が、望ましい行動を言葉にして、自分でもやって見せる、ということだ。称賛する、チャーターを書く、判断のプロセスを説明する。派手なオフサイトより、Slack の一言と、なぜそうしたかの言語化のほうが先にある。自分のブログに手順を残すのも、CLAUDE.md に書くのも、同じ種類の仕事だと思った。勝手に伝わらない前提で、残す。
リモート移行の比喩はしっくりきた。当時は雑談がなくなった。いまは相談がなくなった。どちらも、同じ空間や同じ課題の中で勝手に起きていたものを、仕組みに置き換える話だ。AIで並列に出荷できるようになったあとに戻すべきなのは、昔の会議体そのものではない。共有ゴールと、助けを頼める相互依存と、判断の共有体験のほうだ。
並列でエージェントを走らせるときも、同じことが起きる。000136 で書いた通り、チームメイト同士はリーダーの会話履歴を引き継がない。確実に渡るのはリポジトリに置いたファイルだけだ。人間のチームでも、AIのチームでも、文化に相当するのは「たまたま話した内容」ではなく、参照できるやり方のほうだと思う。
000097 では、意思決定はトップダウンだけの話ではなく、各自がやる／やらないを言葉にすることがチームの空気を変える、と書いた。この記事の「やって見せる」は、その延長だ。決めた理由が見えないと、他の人は同じ価値観を再現できない。再現できない判断は、文化にならない。
出荷量は、もう個人でも伸ばせる。残る問いのほうが大きくなっている。この集まりは、まだチームなのか。自分は接着剤側に立てているか。その確認を、意図的にする時期だと思う。
参考