プロダクトマネージャーに必要なシステム設計理解
まとめ
プロダクトの長期的なゴールについて考え抜く必要があるプロダクトマネージャーは、システム設計における要素技術やその選択によるトレードオフを(なるべく)理解すべき
とはいえ、短期間で理解するのは不可能なので、基礎的な事項を把握して、エンジニアと対話しながらキャッチアップしていくことが大事
前提
インドの最大手ECであるFlipkartなどで働かれている方が書いた記事の読書メモ
#ぜひ原文を読んでください
#この記事ではプロダクトマネージャー=PMなので、PMと略します副題の"Contributing to software design and architecture as a PM"が良い
本論
全てを解決する完璧なシステムを設計することは不可能であり、必ず何らかのトレードオフがある。そのトレードオフについて理解することで、より良い意思決定ができるようになる
ソフトウェア設計について知っておくべきこと
変更可能性を考慮した設計の原則
「関心の分離」（責務の分離、Separation Of Concerns／SOC）
高凝集度
低結合度
#日本語記事では、こちら↓が勉強になりました
アーキテクチャの要素技術とパターンについて知っておくべきこと
下記のよう内容について基礎的な知識をもっておくべき
コンポーネント技術：データベース、インメモリデータベース、キャッシュ、キュー、ロードバランサーなど
パターン：サーバークライアント、MVC、マイクロサービス、メッセージ・ブローカー、レイヤードアーキテクチャなど
ある程度わかっておくと、エンジニアにアーキテクチャについての質問ができるようになり、キャッチアップが進んでいく
「なぜこのアーキテクチャを採用したのか？何がメリットで、何がデメリットなのか？」
また、システムの制約についても質問するべき。特に非機能要件。
例えば、データストアの場合。そのデータベースはどれくらい速いか？SLAを満たしているか？この特定の情報をクエリで取得できるか？複雑なクエリにも対応できるか？どのくらい拡張性があるのか？
ドメインについて知っておくべきこと
エンティティ、ワークフロー、コンポーネントはしっかりレビューできるようにする。PMがコンセプト（業務）を一番理解しているべき
技術負債について知っておくべきこと
以下のようなタイプの技術負債があることを念頭において、案件優先度を考慮する
開発コスト：開発が遅くなる
運用コスト：デバックや修正に工数を取られる
機会コスト：本来リリースできたら得られたリターンを失う
事業コスト：障害等により、事業がストップする
「問い」を共有するというスタンス
システムについて詳しくないPMは、ソリューションよりもまず先に、解こうとしている「問い」について、エンジニアと会話すべき
エンジニアのほうが、ソリューションの選択肢はたくさん出せるし、問題解決のオーナーシップをもってもらうことにもつながる
「なぜ今か？」「今解決する必要がある問いはどれか？」を問うことで、要件がより明確になり、エンジニアが自律的に設計についての検討ができるようになる（例えば、作り込み具合など）
最低限の要素を学び、日々エンジニアと対話を重ねていくことで、プロダクト開発について見通しが立ちやすくなり、ロードマップを検討するときにも役立つ