プロダクトマネージャーとして「十分に技術的」になるには

本記事は、以下記事の要約です。2015年の記事です。
https://medium.com/@lulu_cheng/getting-to-technical-enough-as-a-product-manager-5b372513cd1c

Transcript

1. プロダクトマネージャーとして「十分に技術的」になるには 本記事は、以下記事の要約です。2015年の記事です。 https://medium.com/@lulu_cheng/getting-to-technical-enough-as-a-product-manager-5b372513cd1c 1
2. 目次 1. はじめに 2. 「十分に技術的」の定義 3. 技術的理解を深める方法 4. 即時的な価値を提供し、信頼性を構築する方法 5. 結論 2
3. 想定読者 技術的背景がない新任プロダクトマネージャー ▶ プロダクトマネージャーへのキャリア転換を検討している非技術系専門家 ▶ 技術スキルを向上させたい経験豊富なプロダクトマネージャー ▶ プロダクトマネジメント部門の人事担当者 ▶ 3
4. はじめに 4
5. はじめに PMの役割には通常、技術的背景が求められる ▶ 多くの求人では、コンピュータサイエンス学位や同等の実践経験を要求 - 技術的スキルは、エンジニアとの効果的なコミュニケーションに不可欠 - 「十分に技術的」という表現の登場 ▶ 例： 「アーキテクチャと製品の決定について、エンジニアに適切な質問ができる」 - 完全な技術的熟練ではなく、効果的な協働のための理解を強調 - PMの役割の多面性 ▶ 技術だけでなく、芸術（UI/UXデザイン） 、心理学（ユーザー行動） 、統計学（データ分析）など - 多様なスキルセットが求められる - 業界、企業規模、製品部門による要求の違い ▶ スタートアップvs大企業：技術的関与の度合いが異なる - B2B vs B2C：ユーザーニーズと技術的複雑さが異なる - 製品の性質：ハードウェア、ソフトウェア、AIなどで要求されるスキルが異なる - 5
6. 「十分に技術的」の定義 6
7. PMとして「十分に技術的」であるとは 1.ユーザーの問題を根本的な原因まで遡って理解できる ▶ 表面的な症状だけでなく、技術的な原因を特定できる - 例：ページ読み込みが遅い → データベースクエリの最適化問題 - 2.機能Aと機能Bの開発時間を見積もれる ▶ 技術的複雑さと開発工数の関係を理解している - 例：新機能追加 vs 既存機能の改善の工数の違いを説明できる - 3.提案の実装上の課題を予想できる ▶ 技術的制約やトレードオフを事前に認識できる - 例：新機能がパフォーマンスに与える影響を予測できる - 7
8. PMとして「十分に技術的」であるとは 4.技術的問題に対する潜在的な解決策を考え出せる ▶ 基本的な技術的アプローチを提案できる - 例：キャッシング、負荷分散などの一般的な最適化手法を提案できる - 5.新技術がもたらす機会を特定できる ▶ 新しい技術トレンドが製品にどう活用できるかを理解している - 例：AIやブロックチェーンの製品への適用可能性を評価できる - 8
9. 技術的理解を深める方法 9
10. 技術的理解を深める方法 1. 好奇心から始める ▶ 技術的問題に対する純粋な興味が最も重要 - 新しい技術やツールに関する記事やブログを定期的に読む - テクノロジー関連のポッドキャストを聴く - 面接プロセスで確認すべき - 候補者の技術的好奇心を評価する質問を用意する - 例： 「最近学んだ新しい技術は何ですか？それをどのように学びましたか？」 - 10
11. 技術的理解を深める方法 2. エンジニアリングの創造性を理解する ▶ エンジニアリングは創造的プロセス - コーディングは問題解決の一形態であることを認識する - エンジニアの思考プロセスを理解し、尊重する - 各機能の背後にある判断、トレードオフ、実装の詳細を理解 - なぜ特定の技術的決定が行われたのかを質問する - コードレビューセッションに参加し、議論を観察する - 11
12. 技術的理解を深める方法 3. エンジニアの頭脳を活用する ▶ 入手可能な情報を読む - 技術仕様書、アーキテクチャ図、APIドキュメントを徹底的に読み込む - チームのWikiや技術ブログを参照する - 質問リストを作成し、ホワイトボードセッションを行う - 重要な技術的概念について1対1のセッションを依頼する - 例： 「データベースのシャーディングについて説明してください」 - インテリジェントな質問をする - 基本的な理解を得てから、より深い質問をする - 例： 「この設計決定がスケーラビリティにどう影響しますか？」 - 12
13. 技術的理解を深める方法 4. 学んだことを共有可能な形式にまとめる ▶ 新しい情報を文書化 - 技術的概念の簡潔な説明を書き下す - 図やダイアグラムを使って複雑な概念を視覚化する - オンボーディングリソースとして共有 - 新入社員向けの技術概要ドキュメントを作成する - FAQや用語集を維持管理する - 他のチームにプレゼンテーション - 「Tech Talk」セッションを開催し、学んだことを共有する - 例： 「Search 101：我が社の検索エンジンの仕組み」 - 13
14. 技術的理解を深める方法 5. フィードバックとバグレポートからパターンを見出す ▶ ユーザーフィードバックを系統的に分析する - 共通の問題点や要望をカテゴリ化する - 技術的な根本原因を特定するためにエンジニアと協力する - バグレポートの傾向を追跡する - 特定の機能や技術領域に集中しているバグを識別する - バグの重要度と影響範囲を評価する能力を養う - 14
15. 技術的理解を深める方法 6. コードベースの一部に慣れ親しむ ▶ バージョン管理システム（例：Git）の基本を学ぶ - コードの変更履歴を追跡できるようになる - プルリクエストを読み、基本的な変更を理解する - 簡単なコード変更を試みる - 文字列の変更やシンプルな設定調整など、安全な変更から始める - コードレビューのプロセスを経験する - デバッグツールの基本を学ぶ - ブラウザの開発者ツールを使いこなす - ログファイルの読み方を理解する - 15
16. 技術的理解を深める方法 7. コアコンセプトに焦点を当てる ▶ 製品分野の主要概念を特定する - 検索における再現率vs精度 - データモデリングにおけるカーディナリティ - ネットワークにおける遅延とスループット - オンラインコースや技術書で基礎を学ぶ - Coursera、edX、Udemyなどのプラットフォームを活用 - 「非エンジニアのための」シリーズの技術書を読む - 16
17. 技術的理解を深める方法 8. 厚い皮膚を育てる ▶ 批判を議論の出発点として受け入れる - 技術的フィードバックを個人攻撃と捉えない - 建設的な批判から学ぶ姿勢を持つ - 会話を開始することが重要 - 不完全でも初期案を提示する勇気を持つ - 「これは叩き台です」と明確に伝え、フィードバックを求める - 失敗を学習の機会と捉える - 技術的な誤解や判断ミスを率直に認める - 失敗から学んだことを文書化し、チームと共有する - 17
18. 即時的な価値を提供し、信頼性を構築する方法 18
19. 1. データを深く掘り下げる ▶ データ流暢性はPMの超能力 - 基本的な SQL クエリを書けるようになる - データ可視化ツール（例：Tableau, Looker）の使い方を学ぶ - 以下を理解する： - フロントエンド/バックエンドのイベントログ - どのユーザーアクションがログされているか - ログデータがどのように構造化されているか - データの保存場所とクエリ方法 - 主要なデータベースの種類と特徴 - データウェアハウスの基本概念 - 19
20. 1. データを深く掘り下げる ▶ 実験結果の分析と設計のベストプラクティス - A/Bテストの基本原則 - 統計的有意性の解釈 - データに基づいた即答ができることで信頼性が構築される - 「それについてのデータはありますか？」という質問に常に備える - 重要な製品メトリクスをダッシュボード化し、定期的に確認する - 20
21. 2. チームを前進させる基本的な作業を行う ▶ 効率的な会議の運営 - 明確なアジェンダと目的を設定する - 必要な意思決定者を確実に参加させる - タイムボックスを設定し、議論がそれないよう管理する - 会議の結果と次のアクションを明確に文書化する - 過剰なコミュニケーションと文書化 - 重要な決定事項や議論を常にチーム全体に共有する - プロジェクトの進捗状況を定期的に更新する - 技術的な決定の根拠を文書化し、将来の参照に備える - 21
22. 2. チームを前進させる基本的な作業を行う ▶ エンジニアの負担軽減作業 - 詳細なバグレポートの作成（再現手順、環境情報など） - ユーザーフィードバックの整理と優先順位付け - 他部門からの問い合わせや要求のフィルタリング - 22
23. 3. 自身の経験と強みを活かす ▶ 非技術的な背景を活用 - マーケティング経験を活かしたユーザー獲得戦略の提案 - ビジネス背景を活かした収益モデルの最適化 - 小さな成功を積み重ねる - 短期的に達成可能な目標を設定し、確実に実行する - 成功事例を文書化し、チームや上司と共有する - クロスファンクショナルな協力を促進する - 技術チームと非技術チームの橋渡し役となる - 各部門の言語や優先事項の違いを理解し、調整する - 23
24. 4. 意思決定の共有フレームワークを提供する ▶ 全ての会話に明確さをもたらす - 曖昧な表現を避け、具体的な言葉で話す - 技術的な用語と非技術的な用語の橋渡しをする - 鋭い質問をする能力 - 「なぜ」を5回繰り返す手法を活用し、根本原因を探る - 仮説を立て、それを検証する質問をする - 問題、成功の測定、目標達成手順を明確化 - PRD（製品要求仕様書）のテンプレートを作成し、一貫して使用する - OKR（Objectives and Key Results）フレームワークを導入する - チーム全員がこのフレームワークを適用できるようにする - 定期的なトレーニングセッションを開催する - 成功事例を共有し、フレームワークの価値を実証する - 24
25. 5. チームに広範な文脈を提供する ▶ 他部門との情報を共有 - 営業チームからの市場フィードバックを技術チームに伝える - 経営陣の戦略的決定の背景を説明する - 競合他社の動向や業界トレンドについて定期的に情報提供する - 蓄積された文脈が将来の議論を容易に - 過去の決定事項とその理由を文書化し、アクセス可能にする - 製品の進化の歴史を新メンバーに伝えるためのストーリーを作る - 長期的な製品ビジョンと短期的な技術的決定の関連を説明する - ロードマップと技術的負債の関係を明確にする - 戦略的な技術投資の必要性を非技術的な言葉で説明できるようになる - チームメンバーが積極的にPMに情報を求めるような環境を作る - オープンドアポリシーを実践し、質問や懸念を歓迎する姿勢を示す - 定期的な「Ask Me Anything」セッションを開催する - 25
26. まとめ 26
27. まとめ 1.「十分に技術的」になることは、PMの重要なスキル ▶ 完璧な技術マスターではなく、効果的なコミュニケーションと理解が目標 - 2.技術的理解を深めるには、好奇心と継続的な学習が不可欠 ▶ エンジニアの思考プロセスを理解し、基本的な技術概念を習得する - 3.即時的な価値提供と信頼性構築が、非技術系PMの成功の鍵 ▶ データ駆動の意思決定、効率的な会議運営、明確なコミュニケーションが重要 - 4.個人の強みを活かしつつ、技術的スキルを向上させることが重要 ▶ 非技術的背景を強みとして活用し、技術チームとの協働を通じて成長する - 5.経験の共有と業界全体のベストプラクティス確立が今後の課題 ▶ 継続的な学習と知識共有が、個人とコミュニティの成長を促進する - 27
28. 用語まとめ PM (プロダクトマネージャー): 製品の企画、開発、販売戦略を統括する役職 ▶ コンピュータサイエンス: コンピュータの理論と設計に関する学問 ▶ アーキテクチャ: システムの基本設計や構造 ▶ 再現率: 検索システムが関連する全ての項目を正しく検索できる割合 ▶ 精度: 検索結果のうち、実際に関連している項目の割合 ▶ カーディナリティ: データベースにおける関係の種類や複雑さを表す概念 ▶ フロントエンド: ユーザーが直接操作するインターフェース部分 ▶ バックエンド: サーバー側で動作する、ユーザーには見えない部分 ▶ A/Bテスト: 2つのバージョンを比較して効果を測定する実験手法 ▶ PRD (Product Requirements Document): 製品の要件を詳細に記述した文書 ▶ OKR (Objectives and Key Results): 目標設定と成果管理のフレームワーク ▶ 技術的負債: 短期的な解決策の採用によって将来的に発生する追加作業や問題 ▶ 28