- 「一人で行けば速く、共に行けば遠くまで行ける」 という格言は、スタートアップを駄目にする可能性がある
- 効率的な協業は、運転中のナビゲーション支援程度であるべきだが、ほとんどの会社は 過剰なフィードバックと役割分散 によってスピード低下を経験している
- PostHogは 「あなたがドライバーだ(You're the Driver)」 という価値観のもと、自律性と高いオーナーシップ を重視し、不要な協業を最小化 している
- 協業過多の原因は、助けたいという気持ち、包括性を重んじる文化、不明確なフィードバック依頼、
let's discuss の乱用、責任回避 などにあると分析される
- 解決策は、即時デプロイを優先、責任者の明確化、必要な人にだけフィードバックを依頼、リリース後のフィードバック、不要な協業は即座に遮断 という実践的なアプローチ
協業の落とし穴
- 「速く行くなら一人で、遠くまで行くなら一緒に」 という言葉は、会社をじわじわと蝕む
- これは 過度な協業を正当化する罠 である
- 有用な協業は 運転中の道案内や周辺情報の提供 程度でよい
- しかし多くの組織は、ハンドルを代わる代わる握るような非効率な協業 に陥っている
- 適切なフィードバックは目的地へ素早く到達させてくれるが、過剰なフィードバックは速度を落とし、望む場所にたどり着けなくなるリスクを招く
フィードバックの逆説：フィードバックが上手いとは、いつ与えないべきかを知っていること
- PostHogでも成長に伴い、価値を付け加えない、あるいは投入時間に対する価値が小さすぎる協業 が増えてきた
- 「あなたがドライバーだ(You're the driver)」 はPostHogの中核的価値観であり、「優秀な人材を採用し、邪魔をしない」という考え方を意味する
- デッドラインはなく、調整は最小限で、マネージャーが指示を出すこともない
- その代わり、極めて高い当事者意識と、一人で多くのことをやり切る能力 が求められる
- マーケターがコードをデプロイし、営業担当がバックアップなしで技術的な質問に答え、プロダクトエンジニアがフルスタック全体で作業する
- ほとんどの場合、自分より上手くできる人がどこかにいるので協業したくなる誘惑はあるが、協業はドライバーに減速を強い、背景・文脈・考えを説明させる
- こうした傾向は、いくつかの典型的な表現として現れる
- 「Xがどう考えるか気になる」
- 「Yの意見を聞きたい」
- 「Zと一緒に進めるべきだ」
- これらは 時に価値ある洞察につながるが、常にドライバーのスピードを落とす
- ドライバーの動機、自信、効率を蝕み、最終的にはリリース量の減少につながる
協業が悪いなら、なぜ人はそれをするのか
- 全員が原因の一端を担っている
- 人は助けたがる：誰かがSlackに進行中の作業を投稿すると、フィードバック文化のために、他の人たちはコメントすべきだと感じる
- 逆に、特定の人にフィードバックを求めるのは包括的ではないと感じて、依頼しないこともある（実際にはその方が役立つのに）
- どんなフィードバックが必要なのか十分に具体的でない：そこに協業が入り込む余地が生まれる。ある機能の実装についての議論が、製品ロードマップ全体の再評価にまで広がることもある
- 誰かが良いアイデアを出すと、「それをやろう」ではなく「議論しよう」 がデフォルトの反応になる
- その証拠に、Slackでは
let's discuss が数え切れないほど乱発されている
- これは実行から議論への転換を意味する
- 人々は忙しすぎて実行できない、あるいは面倒で、ただ話したいだけ になっている
- PR → Issue/RFC → Slack（今は大半がここ）→ 「議論しよう」へと移っていく
- 誰がオーナーなのか明確でない（あるいは、議論中のものを誰も所有したがらない）
- 腹立たしいことだが、時には 一人の人間が最初から最後まで十分な品質でShippingできず、ただ出して反復すればいいというわけではない場合もある
- 壊れたコードは直せるが、ニュースレターは再送できない
協業を打ち壊す方法（そしてもっと速く、もっと遠くへ進む方法）
- 協業を敵とみなすなら、どう打ち負かすべきか
- 基本は実行優先：Pull request > Issue > Slackメッセージ
- 協業が過剰なときは、「あなたがドライバーだ、決めて」 と明確に線を引く
- フィードバックは、誰に何を求めているのかを具体的にタグ付け し、漠然と投げないこと
- リリース前レビューよりも、リリース後（次の反復の前）のフィードバック提供を好む：事前フィードバックは、疑似的な承認プロセスに変わり得る
- リーダーはフィードバックを控え、「とにかくやってみればいい(you can just do stuff)」 という姿勢を保つ
- 各人は 「情報を持った船長(informed captain)」 として、
- フィードバックを聞くことはできても、決定は自分で下す
結論
- すべての協業を根絶できるわけではなく、一部の協業は有用である（このニュースレターもIanとAndyが編集している）
- それでも、基本的には協業を減らそうとする努力 が必要だ
- 意識的に協業を減らそうとしなければ、デフォルトで協業しすぎている可能性が高い
- 協業は本質的にスピードを落とすため、
協業が少ないほど、より遠くへ、より速く進める
- （泡は協調的すぎるので）炭酸水が嫌いなCharles Cookによる執筆
12件のコメント
一緒に働くのが正しいです。
その人が不在（死亡、病気、休暇）になったら、クライアント対応はしないのですか？
私はとても小さな会社で働いていて、勤務しているのは私一人だけです。なので一人で保守して、一人で開発しています……。この状態があまりにも長く続いているので、人と一緒に働きたいという気持ちにもなります。一人で働くのはとても寂しいです……
かなり煽りの強い文章ですね。
筆者の個性があまりにも強すぎて、他の人とうまくやっていけないのでは？
1つの機能を作るにも
デザイナー、企画、プロジェクトマネージャー、フロントエンド、バックエンド、QAなどの役割がどうしても必要になるものですが
自分が認識している問題を浮き彫りにするために、あえて過激な主張をしているように見えます。
協業とは、アゴラのような方式で進めることを意味しているわけではないでしょう。
ただし、
let’s discussの乱発と責任回避、この2つの要素には確かに問題があります。しかし多くの場合、洞察のあるリーダーや担当者が存在しないために起こっています。
こうしたことに対処するために、研究したり、人を育てたり、採用したり、ソリューションを買ったりするわけです。
言うことをよく聞くメンバーだけでチームを作ってしまうと、さらに助長されることもあります。
これは協業や一人で働くことが生み出す問題ではないように思います。
Posthog はいつもこのように強い言い回しの記事を書くので、その点を踏まえて読んでください。
あまりにも語調が強いため、ときどき主題を行き過ぎてやや脱線しているように見える文章があります。
（炭酸水がどれだけ良いものか!!!）
炭酸水って、あれハイボールの発射台じゃないんですか、えへん
Hacker Newsの意見
コラボレーションが発生するたびに「人数が多すぎる、Xがドライバーなんだから君が決めて」と言え、という助言があった
しかし管理職が「君が決めて」と言っておきながら会議には来ず、後になって「自分なら違うやり方をした」と言って修正を求めると、社員は去っていく
マネージャーの上司がいつもこういう言い方をしていて、私がPRを出すと結局全面的なリデザインを求めてきた
結局どんなプロジェクトでも最初から書き直しになると分かっていたので、仕事そのものが怖くなった
上司があまりに頻繁に判断を覆すと、チームメンバーはわざとあらゆる決定を上司に丸投げするようになる
結局、上司は自分自身の統制欲に窒息することになる
しかし「管理職は指示するな」という文脈では一貫している
終わりのないピクセル調整、レイアウト修正、フルスタックの全面的な作り直し提案が続いたからだ
問題の核心はコラボレーションではなく意思決定の構造だと思う
フィードバックは学びの機会だが、最終決定を誰が下すのかが不明確だと速度が落ちる
迅速な意思決定のためには決定権者を明確にし、大半の決定は取り返しがつくという認識を持つべきだ
コラボレーションが減れば学ぶ機会も減る
決定権者は明確に指名されるべきだが、フィードバックには耳を傾けるべきだ
また、可逆的な決定は素早く下すほうがよい
コラボレーションは速度を落とすと言われるが、実際にはその過程で品質が上がる
反対のための反対をする人もいて、最終的にはアイデアの所有権を奪おうとする
最終決定者が明確でも意志が弱ければ、結局は多数の合意に流される
「変更依頼」を付けると皆がそれに従わなければならず、結局コード品質が悪化した
良い人材を採用し、決定権を委譲するほうがはるかによいと思う
方向性、優先順位、フレームワークを示し、チームが自分たちで判断できるようにすべきだ
筆者の炭酸水嫌いには同意しないが、コラボレーションの問題を公に扱っているのは歓迎したい
複数の会社で、コードレビュー中の些細なスタイル指摘のせいで実装そのものの3倍の時間を費やしたことがある
「それが気に入らないなら自分で直して知らせてくれ」という立場だ
関連動画も共有されていた
コードレビュー段階で扱うには遅すぎる
周囲のコードスタイルに合わせない人が問題だ
リンターか文化で解決すべきだ
コラボレーションなしで一人で作った機能は、保守時に大きなリスクになる
自分がいない時にシステムが落ちたなら、コラボレーション不在の問題が露呈する
筆者は行動バイアスを強調しているが、コラボレーションを排除するとサイロ化と過信が生まれる
「私はXをやろうと思う、強い反対はありますか？」という形で尋ねるSlack文化が効果的だった
だから実際に物事が進む
以前、GitHub関連の本を書くために取材した際、一部のチームはコードを書く前に空のPRを上げて設計承認を得ていた
これは進行中のコラボレーションではなく、計画段階のコラボレーションだ
良い文章力とコミュニケーションがあれば、コラボレーションは速く効果的になる
AI時代にはこうした能力がさらに重要になるだろう
会議や共有がなければ功績は見えない
問題を防いでも誰にも分からないので、あえて「問題が起きるままにしておく」文化すらある
計画だけでは実装を想像しにくい
記事の最後の一文の通り、「良いコラボレーションは存在する」
タイトルはクリックベイトだが、PostHogはもともとこういうスタイルで有名だ
「コラボレーション」というミームを批判的に見るよう促してくれる
この記事は間違った思考実験だ
問題はコラボレーションではなく決定権の不在だ
一人が明確に決めなければならず、その権限を下に委ねるほど速度は上がる
こういう記事は言葉を歪め、必要な概念を無価値化する有害さがある
誰かが行き詰まるとすぐ「Bobに聞いて」と言う文化も問題だ
短期的には速いが、長期的には学習機会の喪失と業務過多を招く
私は同僚が自分の仕事に関心を持ってくれるのが好きだ
「君の好きにして」は実質的に「私は関心がない」という意味だ
問題はコラボレーションではなく非効率なコラボレーションだ
PRには具体的な成果物があるので、議論が明確になる
コラボレーションは二人のときに最もうまく機能すると感じる
二人ならコードベースを一緒に理解し、互いのPRをレビューできる
だが三人以上になると組み合わせ的複雑性が爆発する
だから私はプロジェクトを2人チーム構造で設計したい
参考リンク
記事の比喩のように、F1レースは極端にコラボレーティブなスポーツだ
ドライバーはレース中ずっとコーチと交信している
ソフトウェアでこういう例があるのか気になる
コメント欄、なんだかおかしいですね。記事の要約を見る限り、一人で働け、チームメンバーは不要だと言っているのではなく、チームメンバー間の過度なコラボレーションを減らそうということのようですが
同意します
釣りタイトルと、本文をきちんと読んでいない読者が組み合わさった結果のようですね
こういう文章だけでなく、YouTubeでさえタイトルだけ見てコメントする人が多いようですね。
新しいことを始めるとき、あまりにも安全策を取ろうとして、必要以上に周囲にレビューを求めてしまうことがあります。実際には、周りの人やチームはその内容をよく知らず、良いフィードバックを返すのが難しいこともあります。結局のところ、まずは何かを作ってみて、たとえ方向性が間違っていたとしても、その後で具体的なフィードバックを受けて作業し直したほうが、全体として時間を節約できる、という話のようです。