cross-functional-collaboration について
プロダクトマネージャー、デザイナー、エンジニアなど、部門横断チーム向けの協働ガイドスキルです。プロダクトリーダーの知見をもとに、役割の明確化やコミュニケーション、関係構築を支援します。
主な機能
- 01協働上の摩擦の診断
- 02役割ごとの期待の明確化
- 03チーム構成と会議リズムの提案
- 04関係者とエンジニアの直接対話の促進
- 05プロトタイプによる引き継ぎ摩擦の軽減
活用シーン
- 01PM、デザイン、エンジニアリング、データ間の責任範囲の定義
- 02エンジニアの顧客探索への参加
- 03プロダクトトリオでの意見対立の解消
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ refoundai/ lenny-skills --skill cross-functional-collaborationインストール後、Claude Code で/cross-functional-collaborationを入力して読み込まれたか確認します。
同梱ファイルreferences/guest-insights.md
詳細
部門横断のコラボレーション
Linear から Airbnb までの企業で高いパフォーマンスを発揮する部門横断チームを築いてきた、57 人のプロダクトリーダーのフレームワークを活用して、ユーザーが部門を横断して効果的に仕事を進められるよう支援します。
支援方法
ユーザーから部門横断のコラボレーションについて相談された場合:
- 摩擦の原因を特定する - 問題が役割の明確さ、コミュニケーションのパターン、または組織構造にあるかを見極めます
- 期待を明確にする - 各部門が他部門に何を期待しているかを定義できるよう支援します
- 適切な体制を設計する - チーム構成と会議のリズムを提案します
- 関係を築く - コラボレーションを機能させる人間的な側面を重視します
基本原則
功績は惜しみなく分かち合う
Camille Fournier:「エンジニアは、PM がすべての栄光を得て、自分たちの仕事が評価されないと思うことがあります。ですから、エンジニアリングチームと功績を分かち合い、チームを包摂するために、あらゆる努力をしてください。」エンジニア自身が役員や顧客に成果を発表できるようにします。
「そうですね、それに」の考え方を使う
Adam Grenier:「『そうですね、それに』という考え方で取り組めば、多くの場合、それでも真実であり続けます。この2つは同時に成り立つことがあります。あなたと私で、目標が違っていてもよいのです。」誤った二者択一を生み出すのではなく、チームごとに異なる目標を同時に認めます。
互いへの期待を書き出す
Nikita Miller:「PM、デザイン、エンジニアリング、データの各リーダーに、相手の役割に何を期待するかを書き出してもらいます。役割間の責任共有を明確にする『契約』を作成しましょう。」こうした定義を3~6か月ごとに見直します。
ディスカバリーにエンジニアを参加させる
Christine Itwaru:「初期の頃から、顧客とのミーティングにエンジニアを少しずつ多く参加させるようになりました。実際に始めてみると、エンジニアリングチームの反応はとてもよかったです。」顧客と直接接することで、技術面への共感が育まれます。
伝言役にならない
Camille Fournier:「自分が間に立って、ステークホルダーとエンジニアの間で伝言役を務めていると、それはとても煩わしく、誰にとっても時間の無駄です。」技術的な詳しい話が必要なときは、ステークホルダーとエンジニアを直接つなぎます。
毎日エンジニアと直接取り組む
Marty Cagan:「エンジニアのチームと毎日一緒に問題解決に取り組んでいないのなら、あなたはプロダクトマネージャーではありません。」仲介役として振る舞う「プロダクトオーナー」のような中間役をなくします。
真の関係を築く
Ebi Atawodi:「エンジニアリングマネージャーの誕生日を知っていますか?入社記念日を知っていますか?なぜその仕事をしているのか知っていますか?」強いパートナーシップは、人としてのつながりを土台に築かれます。
コードは共通言語
Amjad Masad:「誰もが共有する共通言語はコードです。その言語を、実際に動くプロトタイプやアプリケーションにしてはどうでしょうか?」静的なモックではなく機能するプロトタイプを使い、引き継ぎ時の摩擦を減らします。
「プロダクトトリオ」を取り入れる
Teresa Torres:「トリオとは、プロダクトマネージャー、デザイナー、ソフトウェアエンジニアのことです。うまく機能するトリオで働いた経験がない人には、これは理解しがたいものです。」意見の相違は、権限を振りかざすのではなく、より多くのデータやより良い選択肢を探して解決します。
ユーザーへの質問
- 「各部門は他部門に何を期待していますか?書き出していますか?」
- 「エンジニアは顧客ディスカバリーに参加していますか?それとも仕様を受け取るだけですか?」
- 「対立が起きたとき、誰が最終判断を下し、どれくらい迅速に動きますか?」
- 「エンジニアリングやデザインのパートナーが、個人的にどのようなキャリア目標を持っているか知っていますか?」
- 「あなたは通訳役を務めていますか?それともステークホルダーとエンジニアを直接つないでいますか?」
指摘すべきよくある間違い
- 功績の独占 - エンジニアが生み出した成果をPMが自分の手柄にする
- 伝言ゲーム - ステークホルダーとエンジニアの間で、不必要な仲介役を務める
- アイデア出しからエンジニアを除外する - エンジニアを創造的なパートナーではなく、単なるリソースとして扱う
- 役割の境界が曖昧 - 誰が何を担当するかを明確にしないことで、すべてがPMに降りかかる
- 人間的な側面を無視する - 強い協力関係を築くには、パートナーを一人の人間として知る必要がある
詳細
57人のゲストから寄せられた72件すべての知見については、references/guest-insights.mdを参照してください。
関連スキル
- 効果的な1対1ミーティングの実施
- 難しい会話への対応
- 業務の委任
- 上司との関係構築