与え合い、取り合い：エンジニアとプロダクトマネージャーが互いに助け合う6つの方法

エンジニアとプロダクトマネージャーの間の競争について聞いたことはすべて忘れてください。それは消えるべきパラダイムです。今日のテクノロジー界は速すぎて、前進する唯一の方法は協力し合うことです。この記事では、エンジニアとPMが頭をぶつけ合うことを避け、ミッションに集中し続けるための6つの方法を明らかにします。

1. PMは大局を共有する; エンジニアは技術的制約を共有する

与える: PMは、プロジェクトの背後にあるビジネス目標と顧客のニーズを明確に理解することで、エンジニアを助けることができます。これにより、エンジニアは特定の機能や締め切りがなぜ重要なのかを理解できます。早期にコンテキストを共有することで、エンジニアは自分の仕事をより広い目標に合わせることができます。

受け取る: 逆に、エンジニアはプロジェクトに関わる技術的な制約や複雑さをオープンにコミュニケーションするべきです。見た目には小さな機能が大きなバックエンドの変更を必要とする場合、これを事前に説明することで、PMは優先順位付けやタイムラインについてより良い決定を下すのに役立ちます。

例: PMが、ある機能が大きなクライアントを獲得するか、競争上の脅威に対処するための鍵であると説明すると、エンジニアはそれを優先するのに役立ちます。同様に、エンジニアがスケーラビリティの問題のために機能に追加の時間がかかると共有すると、PMは期待を調整することができます。

リソース

プロダクトマネージャー向け：『実践プロダクトマネジメント』マット・ルメイ著 - 製品目標の理解と伝達に関する包括的なガイド。

Where the World Designs Electronics

Break down silos and enhance collaboration across all aspects of electronics development

Find Out More

エンジニア向け：『プラグマティックプログラマー』アンドリュー・ハントとデビッド・トーマス著 - 開発プロセスにおけるコミュニケーションと技術的意思決定を強調した書籍。

2. PM：マイクロマネジメントを避ける；エンジニア：アイデア出しプロセスに積極的に関わる

与える：プロダクトマネージャーは、製品の実行のすべての詳細をコントロールしようとする衝動を抑えるべきです。技術的な側面をエンジニアに任せ、問題を彼らの方法で解決するためのスペースを与えてください。過度に規定的な管理は創造性を損ない、関与を低下させる可能性があります。

受け取る：エンジニアは、アイデア出しプロセスで主導権を取るべきです。尋ねられるのを待たずに、製品の改善方法に関する提案やアイデアを提供してください。多くのエンジニアは、製品の機能、性能、またはデザインを向上させることができる貴重な洞察を持っています。積極的に行動することは、コードを書くこと以上に製品の成功に投資していることを示します。

例：PMはビジネス目標を概説し、エンジニアに機能の実装方法を指示するのではなく、意見を求めます。一方、エンジニアは積極的に技術的な解決策を提供し、ブレインストーミングセッションに貢献します。

リソース

Design Better, Together

Experience flexible controls for team management and project visibility.

Explore Solutions

プロジェクトマネージャー向け：『Empowered』Marty Cagan と Chris Jones 著 - この本は、製品実行の所有権をチームに与える方法を探求しています。

エンジニア向け： 『Creative Confidence』Tom Kelley と David Kelley 著 - 製品アイデアに創造的に貢献したいエンジニアにとって素晴らしいリソースです。

3. プロジェクトマネージャー：寛大にクレジットを与える；エンジニア：製品決定を公にサポートする

与える： エンジニアからの一般的な不満の一つは、プロジェクトの成功に対してクレジットを受けるのはプレゼンテーションをリーダーシップに行うことが多いPMだということです。PMは、エンジニアリングチームとの信頼を築くために、クレジットを共有し、エンジニアが自分たちの仕事をプレゼンテーションする機会を与えることで支援できます。

受ける： 逆に、エンジニアは、他のチームやステークホルダーにプレゼンテーションする際に、PMの決定をサポートすることができます。一部に同意しない場合でも、製品の決定を公にバックアップすることは統一感を示し、協力的な文化を育むことにつながります。

例： 成功したローンチの後、PMはエンジニアを招いて技術的な成果を発表させます。その見返りとして、エンジニアはステークホルダーミーティングでPMの製品決定を公にサポートします。

リソース

プロジェクトマネージャー向け：『Radical Candor』Kim Scott 著 - 強い関係を築き、適切な場所でクレジットを与える洞察を提供する本です。

エンジニア向け：「Crucial Conversations」Al Switzler、Joseph Grenny、Ron McMillan 著 - 同僚やリーダーシップとの効果的でサポート的な会話の方法を学びます。

4. PM（プロジェクトマネージャー）は技術的負債に関する議論にオープンであるべきです；エンジニアはタイムラインについて現実的であるべきです

提供： PMは、技術的負債やメンテナンスについての会話にオープンであることでエンジニアを支援できます。新機能を優先するのは魅力的ですが、技術的な基盤を無視すると、より大きな問題につながる可能性があります。必要なコードのリファクタリングやインフラの改善に時間を割くことは、長期的な製品の健全性を理解していることを示します。

受け取り： エンジニアも、物事がどれくらいの時間がかかるかについて現実的であるべきです。あまりにも保守的な見積もりを出すと、PMはタイムラインに対してプッシュバックを感じるかもしれません。正確なタイムラインを提供し、遅延を早期に伝えることで、PMは効果的に計画を立てることができます。

例： エンジニアは技術的負債のリスクを伝え、PMはリファクタリングのための時間を許可し、エンジニアは期待を管理するために現実的な時間見積もりを提供します。

リソース

PM向け：「Technical Debt 101」ThoughtWorks 著 - 技術的負債を理解し、それを管理する方法についての素晴らしい入門書です。

エンジニア向け： 『フェニックス・プロジェクト』ジーン・キム、ケビン・ベア、ジョージ・スパフォード著 - 技術的負債とビジネス優先順位のバランスの影響を描いた小説。

5. PM（プロジェクトマネージャー）はエンジニアを顧客フィードバックに参加させるべき；エンジニアはビジネスの優先順位を尊重すべき

提供： PMは、顧客フィードバックを直接エンジニアと共有することで支援できます。エンジニアは、顧客が製品をどのように使用しているか、どのような問題に直面しているか、どの機能が気に入っているかを聞くと、製品により強く繋がりを感じることがよくあります。

受け取り： 逆に、エンジニアはPMがバランスを取っているビジネスの優先順位を尊重すべきです。完璧ではない機能をローンチすることにフラストレーションを感じることもあるかもしれませんが、それが競争力を維持するために時には重要になることがあります。

例： PMがエンジニアを顧客フィードバックセッションに参加させ、エンジニアは一部の機能のローンチが重要であることを理解し、いくつかの側面がさらに洗練される必要があると感じてもそれを受け入れます。

リソース：

PM向け： 『リーン・プロダクト・プレイブック』ダン・オルセン著 - 顧客フィードバックを理解し、それを実行可能な製品開発戦略に翻訳するための実践的ガイド。

エンジニア向け： 『マン・マンスの神話』フレデリック・P・ブルックス著 - この古典的な書籍は、ソフトウェア開発のタイムラインとビジネスの期待に関する課題を取り上げています。

6. プロジェクトマネージャー：明確で達成可能な目標を設定する；エンジニア：解決志向であること

与える： プロジェクトマネージャーがエンジニアにできる最も価値あることの一つは、明確で達成可能な目標を設定することです。あいまいな要件や絶えず変わる優先順位は、フラストレーションの原因となります。成功とは何かを定義し、それらのパラメータに固執することで、プロジェクトマネージャーはエンジニアが集中し、効率的に作業するのを助けることができます。

受け取る： エンジニアは、解決志向のマインドセットで問題に取り組むべきです。何かができない理由を挙げる代わりに、代替案や回避策を提案してください。建設的であることは、プロジェクトマネージャーとチームが技術的な障害によって立ち往生することなく前進するのを助けます。

例： プロジェクトマネージャーがプロジェクトの成功指標を明確に提供し、技術的な制約が生じたときにエンジニアが実用的な解決策を提供する。

リソース

プロジェクトマネージャー向け： 『重要なことを測る』ジョン・ドーア著 - チームの努力と一致する明確な目標と測定可能な主要成果指標（OKR）を設定する方法を学びます。

エンジニア向け：「データ集約型アプリケーションの設計」マーティン・クレップマン著 - エンジニアがスケーラブルで信頼性の高いシステムを構築する方法を考えるのに役立つ技術リソースであり、製品要件のバランスを取りながらです。

実世界の例：イーロン・マスクの内部官僚制を削減するための5ステップアルゴリズム

イーロン・マスクは、TeslaやSpaceXでの大胆な経営スタイルでよく知られています。内部官僚制を切り抜けるため、マスクはウォルター・アイザックソンによる最近の伝記で詳述されている5ステップのアルゴリズムを開発し、プロセスを合理化するための実行可能なフレームワークを提供しています。

1. すべての要件を問い直す：マスクは、「賢い人」から来た要件であっても、すべての要件に挑戦するよう助言しています。各要件に名前を付け、それが本当に必要かどうかを絶えず尋ねます。必要なければ、それを排除します。
2. プロセスの一部を削除できるものはすべて削除する：マスクは、シンプルさが鍵であると強調しています。不要なステップを削除します—思った以上に進んでください。少なくとも10％を戻さなければならない場合、十分に削除していません。
3. 簡素化して最適化する：不要なステップを排除した後にのみ、残ったものを簡素化して最適化します。最初から存在すべきでないプロセスを合理化する間違いを避けてください。
4. サイクルタイムの加速：プロセスが合理化されたら、それを速めることに注力します。マスクは、冗長または不必要なプロセスの部分を加速する時間を無駄にしないよう警告しています。
5. 最後に自動化：マスクの最終ステップは自動化ですが、それはプロセスを徹底的に問い直し、削除し、簡素化した後にのみ行います。早すぎる自動化は不必要な複雑さを招く可能性があります。

マスクの方法は、PM（プロジェクトマネージャー）とエンジニアが協力して非効率性に挑戦し、ワークフローを合理化し、生産性を最適化する方法の強力な例となることができます。仮定を絶えず問い直し、プロセスを簡素化することで、製品開発チームは内部の障害を劇的に減少させ、協力を強化することができます。

ストレスが少なく、情熱が増す

サイモン・シネックが賢く言ったように、「私たちが気にしないことのために一生懸命働くことはストレスと呼ばれ、私たちが愛するもののために一生懸命働くことは情熱と呼ばれます。」これは、エンジニアとPMの関係にも当てはまります。相互尊重と情熱を持って協力するとき、素晴らしいことが起こります。この与え合いの精神が、チームの次の大きな製品リリースを推進させましょう。