エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド


本記事は、Engineering Manager Advent Calenderの１日目です。
# はじめに
エンジニアリングマネージャ(EM)と呼ばれる職務を設置する企業が増えてきました。

私たちの主催したイベントEOF2019でも700名近い方に参加していだき、また多くの方にご協力いただき成功裏に終わることができました。

EM Meetup/EM.FMなどのムーブメントの中心の一翼を担わせていただき、その高まりを感じる一方で不安も感じます。このエンジニアリングマネージャという職務は非常に多岐にわたるケースが存在していますし、必要だとされるスキルもまちまちです。そして、多くの場合、その企業のステージや状況ごとに求めるものは違います。また、求めていることを明文化することすらされていないケースも存在します。

このことから、エンジニアリングマネージメント自体が一時的な潮流として消費され、消えていってしまうのではと危惧しています。このようなバズワードとしての消費は、同時にソフトウェアエンジニアリングの全体にとっての損失になるだろうと考えています。エンジニアリングマネージメントは、継続的なソフトウェア/デジタル技術関連するシビジネスを開発部隊にとって重要なスキルだからです。

また、もう一角としてプロダクトマネージャと呼ばれる職種を採用する企業も増えてきました。これは、ソフトウェアを構築する際に、「何を作るか」「なぜ作るか」を担当するような職務で、マーケット理解からソフトウェア要件に関する理解までと多彩なスキルが求められます。それに対して、エンジニアリングマネージャは「どう作るか」。そこには、「いつまでにつくるか」「どうやって品質と効率を上げるか」「どうやって人を育てるか」といった要素が入ってきます。

なぜ、なにを、どのようにつくるかは連続的なものです。ですから、複数の知識体系から必要に応じて適切な知識や手法を採用することが求められます。


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35671/08403b82-884a-0bb2-3a82-351859858433.png)

このようなスキルセットは、ソフトウェア開発のための知識体系にも昔から存在します。

たとえば、[BABOK](https://amzn.to/35KrUX2)/[PMBOK](https://amzn.to/33s9Wak)/[REBOK](https://amzn.to/2qXZHgH)/[SWEBOK](https://amzn.to/2r054vJ)/[SQuBok](https://amzn.to/37QG1fc)などの知識体系は、プロダクトマネージャやエンジニアリングマネージャにとって基礎的なスキルやフレームワークを提供してくれるはずです。

しかし、SoEに近い領域の自社開発を行うプロダクトマネージャやエンジニアリングマネージャにとって、SoR的な大規模エンタープライズのシステム開発の請負などに比べて、複数の関連会社とのプロジェクトのリソースマネジメントや調達管理をするスキルは内製開発ではほとんど必要とされませんし、複数のステークホルダー分析や、レポーティング文書や受け入れのための証跡管理のスキルも重視されません。

とても複雑な要件定義書を書いたり、1000や2000のユースケースを業務分析から漏れのないようにタスク出ししたりすることも、段階的に仮説検証するために小さくなったストーリーでは必要がないことが多いです。

むしろ、いかにして要件自体を小さくするかというマーケティング知識や仮説構築能力がプロダクトマネージャの本懐とも言えるでしょう。

ですが、ソフトウェア要件の書き方の訓練ができていないプロダクトマネージャでは、SaaSやソーシャルゲーム、決済サービスなど高度なトランザクションや複雑な機能要件を定義することができず開発の足を引っ張ってしまいます。

EMもPMも現在は残念ながら、異なる技術や知識体系から自社の今のステージにとって、必要なものを再構成して、適用していく能力が求められることになります。そうであるがゆえに難しく楽しいものではあるのですが。

本稿では、２つの新しいマネジメント職に向けての、この知識体系の柔軟な運用が可能になるような読書のガイドラインを作ることで、健全な業界発展の一助になればと思っています。

# EMとはなにか

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35671/e743ea18-f600-181a-b700-17332acf627f.png)

以前、１００名のエンジニアリングマネージャ(および技術系管理職)にアンケートを行い、どのような責務を任せられているのかということ分析しました。

得られた結果としては、ピープルマネジメントのスキルを中心にしながらも、プロジェクトマネジメント、テクノロジーマネジメント、採用活動、要求定義やプロダクトマネジメントといった多岐にわたる責務を担っていることがわかりました。

## 「弱めのEM定義」と「強めのEM定義」
このような事実から、EMの定義を１つに集約することは難しいことがわかります。

試しに、すべてのEMが求められるような共通部分だけをくくって、「EMの弱い定義」をつくり、関係部分のすべてをさして、より多くのことを求められるものを「EMの強い定義」を作るということを試してみましょう。

「弱めのEM定義」は、「エンジニアのマネジメントスキル」としてのピープルマネジメントスキルとテクノロジーマネジメントのスキルを持っているキャリアになります。

これだけでも、結構難しいものです。というのも、ソフトウェアエンジニアの業界変化ははやく、また転職市場も流動的ですから、常にキャリアになる仕事を提供したり、専門的な知見をもったエルダーとしてアドバイスを行う必要があります。また、その人のキャリアを見越した上での人事評価やスキル評価も難しいため、新しい専門職のチームには「弱めのEM定義」に当てはまるような役職をつけることが少なくありません。

たとえば、フロントエンドエンジニアやアプリエンジニアなど、１つの会社にサーバーサイドエンジニアほど多くいない時期がありました。このような時期に、それぞれのスペシャリティを考慮に入れながら、人事評価や適切なプロジェクト配置を行うことが現実的に難しいという事情から、EMを配置することも少なくありません。

最近では、データサイエンティストや、MLエンジニアなどのキャリアなどを考慮に入れるために専門家集団のエルダーとしてのEMという場合も増えてきました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35671/a946b370-e329-adcd-3711-8cbdce30e8ad.png)

一方で、「強めのEM定義」ではどうでしょうか。ピープルマネジメントに加えて、テクノロジーマネジメントのみならず、プロジェクトマネジメントやプロダクトマネジメントの一部の要件定義能力などが求められることもあります。

つまり、SQCD(スコープ、品質、コスト、納期）という４つのトレードオフや課題をマネージメントしながら成果を出すことが求められます。非常に難易度の高い仕事と言えます。

さて、これらすべてに優れた人というのはなかなか採用できるものではありませんし、現実にチームにいなければ分業体制や協力しながら、これらの責務を成し遂げるしかありません。しかし、チームメンバーの期待するマネージャというのは、これらすべてを成し遂げてくれる人であったりします。

このギャップが「マネージャにスーパーマンを求めてしまう現象」です。
そうはいっても、マネージャ職なのだから「高い給料」をもらっていて、それくらいはできて当然だと考える方もおられるかもしれません。

ソフトウェア開発の現場では、技術的なスキルの高い個人に対しての給与制度も用意されていることが多く、マネージャよりも多くの給与もらっているメンバーを管理することもありふれたことです。（事実、私が初めてマネージメントしたチームは、ほぼ全員が私よりも給与が高い状態でした。）

日本の旧来企業が持っている給与の労使境界がはっきりした人事制度のもとでは、このような考えも成立したかもわかりませんが、ソフトウェアエンジニアの働くチームではこのようなことはなかなか成立しません。

実際に「強いEM」定義と「弱いEM」定義が採用されるケースはどのような違うがあるかというと、チームのタスク型ダイバーシティの高さに由来することが多いです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35671/99f0ca58-c606-a394-e341-d05ce6a93a16.png)

タスク型ダイバーシティとは、同一のチームの中にどれだけいろいろなスキルの人が存在するのかを指します。

タスク型ダイバーシティが低いとマネージャは、その専門職の経験値の高い人を当てる傾向があります。誰が何をやっているのかをはっきりとわかるため、マネジメントがしやすいです。一方で仕事全体のスコープが、市場そのものと接するというより、会社内を顧客とした仕事になりがちです。そのため、短期的な目標に関してのコミットメントに対して意識が弱くなるといったことが起こります。一方、その専門性を発揮して内部人材の育成を強化したい、自社でのキャリアを形成できるようにしていきたいというフェーズに適しています。

タスク型ダイバーシティが高いとマネジメントしているメンバーの専門職のスキルが全部わかるということはなくなってきます。でも、大筋わかっていないといけないので、様々なものが求められながらも、価値をとどけるために「強いEM定義」が求められるようになります。プロジェクトやプロダクトのプレッシャーが掛かるため、短期的な目標に対して目が行きがちになります。イノベーションや成果を生みやすい反面、ソフトウェア品質や人材育成から目が離れてしまうことがあります。

この際のEMは、プロジェクトと品質、文化などのトレードオフを見ながら適切な投資をする能力が求められます。

ですが、そうした場合、「専門職としての経験」を軸にマネジメントを行うことが難しくなるため、結果的にサーバント・リーダーシップや、コーチングなどを通じて、チーム全体が１つのミッションを達成するためのピープルマネジメントスキルが必要になってきます。

# 各種スキルと読書ガイド
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35671/5afefd65-b1b8-2432-e284-31493ac4b305.png)

弱いEMから強いEMにかけての、知識体系をまとめるとこのようになります。自分自身のキャリアや足りない部分などを見つめ直して、インプットするのに使えるとよいかもしれません。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35671/a2845788-3436-a02b-652f-ca875f67d959.png)

また、それぞれのコアな知識を学んでいくと、学際的な領域にフォーカスがあたった知識が隠れていることが理解できます。

たとえば、ピープルマネジメントとテクノロジーマネジメントの境界線には、DevOps的な思想やツール群が見え隠れします。このトレンドを正しく理解するには、ソフトウェア品質とピープルマネジメントやチーミングについて学ぶ必要があるでしょう。

たとえば、プロジェクトにおける依存関係や不確実性について理解すると、交換可能なモジュールやオプションを組み上げて効率的なデザインを行うことのプロジェクトへのポジティブな影響やネガティブな影響を理解できるでしょう。

この他にも、隠れた共通項・学際領域が隠れており、別分野の知識があるのとないのでは理解の深さが異なってきます。

**重要なことですが、全てを読む必要はありません**

必要に応じて、段階に応じて「このような世界があるんだなー」と認識しておき、行き詰まりを感じたときに深堀りをしてみるといいかもしれません。

**また各書のリンクは主にshort url作成のためにアフィリエイトリンクを用いています。それらに不快感をお持ちの方は、書名からの検索をお願いします 
非アフィリエイトリンクを個別に作成してくださる編集リクエストもお待ちしています。**
 
## ピープルマネジメント
### 1on1/メンタリング
ピープルマネジメントの基本的所作である１：１のマネジメントスキルは、究極のところカウンセリングの技法や、精神科医の実践的治験によるところが大きい。実際の所作を獲得することを考えるとこういった書籍が最もわかりやすい。

+ [コーチングのすべて](https://amzn.to/2GqAA8Y)
+ [認知行動療法による対人援助スキルアップ・マニュアル](https://amzn.to/2H0BpXb)
+ [マイクロカウンセリング技法](https://amzn.to/2rFNNrE)
+ [傾聴の心理学](https://amzn.to/2E4fDi0)
+ [プロカウンセラーの聞く技術](https://amzn.to/2pRluCd)
+ [リフレーミング―心理的枠組の変換をもたらすもの](https://amzn.to/2E6qxnw)
+ [短期間で組織が変わる　行動科学マネジメント](https://amzn.to/2GnwApI)


### ファシリテーション
１：１での行動変容をうながせるようになったら、会議の場でのファシリテーションからプロジェクトファシリテーションなどのステークホルダーの広い場所での行動変容を学んでいくと実際の仕事に活用しやすい。

+ [ザ・ファシリテーター](https://amzn.to/2E3lnIR)
+ [問題解決ファシリテーター](https://amzn.to/2J2yxJM)
+ [ファシリテーターの道具箱](https://amzn.to/2E4k2l2)
+ [プロジェクトを変える12の知恵― ケンブリッジ式 ファシリテーション](https://amzn.to/2L3TOp2)

### チーミング
心理的安全性や目標をどのように維持・獲得・達成していくのかの関係性をバラバラに抑えてしまうと、目的と手段が転倒しやすい。なので、OKRなど目標管理と心理的安全性については、同じタイミングで読書すると理解が進む。

+ [なぜ弱さを見せあえる組織が強いのか ](https://amzn.to/2E5OviJ)
+ [チームが機能するとはどういうことか ](https://amzn.to/2GoUuRs)
+ [はじめてのリーダーのための 実践！ フィードバック 耳の痛いことを伝えて部下と職場を立て直す「全技術」](https://amzn.to/2E6pDY1)
+ [Measure What Matters 伝説のベンチャー投資家がGoogleに教えた成功手法 OKR ](https://amzn.to/2QQhwJ7)
+ [THE TEAM 5つの法則](https://amzn.to/2L97OOt)
+ [THE CULTURE CODE ](https://amzn.to/33A86nU)
+ [具体と抽象 ](https://amzn.to/33EKNte)

## テクノロジーマネジメント
### ソフトウェア品質
ソフトウェアプロジェクトの成否を決めるほど強い要素でありながら、しばしば理解が及んでいないことがあるのがソフトウェア品質に関する知識です。様々なファクトとデータ分析が積み重なっている分野でもあり、これらの知見はエンジニアリングマネジメントにとって必要不可欠と言えます。

+ [ソフトウェア品質知識体系ガイド -SQuBOK Guide-(第2版)](https://amzn.to/2OyvIVH)
+ [データ指向のソフトウェア品質マネジメント―メトリクス分析による「事実にもとづく管理」の実践](https://amzn.to/2LaA974)
+ [初めて学ぶソフトウエアメトリクス~プロジェクト見積もりのためのデータの導き方](https://amzn.to/2OC4cqt)
+ [ソフトウェア品質の経済的側面](https://amzn.to/35O410N)

### XP/DevOps
XPの習慣とDevOps的なアプローチは、ソフトウェア品質のための、協調・創造の文化と自動化の技術、プログラミング的習慣によって構成されている。直接的なファクトが得られづらいが、実践を積み重ねることによって高度な技術チームを作り上げることができる。

+ [テスト駆動開発](https://amzn.to/37PUCYv)
+ [モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める](https://amzn.to/2r0Oa01)
+ [The DevOps ハンドブック 理論・原則・実践のすべて](https://amzn.to/2R4Rhin)
+ [LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する ](https://amzn.to/34uSinD)
+ [レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス](https://amzn.to/37QT68t)

### SRE/モニタリング
ソフトウェア品質は、事前と事後の品質が存在する。リリース事後において発見されるバグというのは、ソフトウェアライフサイクルの中で非常に大きい割合を占める。以下にして、安定した運用を実現するのかという技術や文化、習慣の理解がないと、事前品質と事後品質のトレードオフやメトリクスが理解できなくなってしまう。

+ [SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム](https://amzn.to/2L9qnlv)
+ [入門 監視 ―モダンなモニタリングのためのデザインパターン](https://amzn.to/2R6Wtlx)
+ [Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス](https://amzn.to/2RaYQEh)
+ [詳解 システム・パフォーマンス](https://amzn.to/34Bfel1)

### アーキテクチャ
継続的にソフトウェアの開発効率を維持し、バグの起こりにくい・起きてもクリティカルになりにくいといった性質を実現するためには、アーキテクチャの素養がなければならない。ソフトウェアプロジェクトマネジメントの場合、アーキテクチャやソフトウェア品質に関する理解があるとないとでは、打ち手の幅が全然変わってくる。モジュール化の理論は、プロジェクトマネジメントと同じく不確実性とオプションの数理で構成されていることがわかってくると、プロジェクトマネジメントとソフトウェアアーキテクチャの隣接点が浮かび上がってくる。

+ [ソフトウェアシステムアーキテクチャ構築の原理 第2版](https://amzn.to/2syVJvD)
+ [Clean Architecture 達人に学ぶソフトウェアの構造と設計](https://amzn.to/2susE4d)
+ [エンタープライズアプリケーションアーキテクチャパターン](https://amzn.to/2OAMxzm)
+ [アプリケーションアーキテクチャ設計パターン](https://amzn.to/2P1QH1U)
+ [.NETのエンタープライズアプリケーションアーキテクチャ第2版　.NETを例にしたアプリケーション設計原則](https://amzn.to/2L8gAw2)
+ [進化的アーキテクチャ ―絶え間ない変化を支える](https://amzn.to/33zYj15)
+ [Design It! ―プログラマーのためのアーキテクティング入門](https://amzn.to/35PaJ6Q)
+ [実践ドメイン駆動設計 (Object Oriented SELECTION)](https://amzn.to/2DwCKE3)
+ [モジュール化―新しい産業アーキテクチャの本質 (経済産業研究所・経済政策レビュー)](https://amzn.to/34Cr8eq)

## プロジェクトマネジメント

### PMBOK
プロジェクトファシリテーションの知見やチーミングが理解できていると、プロジェクトマネジメントのプラクティスの理解が早くなる。PMBOKなどの知識体系はとても広い。ソフトウェアだけではないプロジェクトマネジメントの一般的な性質について理解してから、ソフトウェアに戻ってきたほうがポイントが抑えやすい。

+ [図解入門よくわかる 最新PMBOK第6版の基本](https://amzn.to/35JUY0X)
+ [図解 これ以上やさしく書けない プロジェクトマネジメントのトリセツ](https://amzn.to/2Y4stIF)
+ [プロジェクトマネジメントの基本　この１冊ですべてわかる](https://amzn.to/2YaF3q1)

### 不確実性分析・クリティカルパス
プロジェクト管理の手法の背後には、統計的な不確実性の取り扱い方や、依存関係の取り扱い方と言った統計数理と離散数理がついてまわる。自分たちがリスクという不確実性の管理を行っているという見方を広げていくと、プロジェクトマネジメントのレベルが一弾上がるはず。

+ [不確実性分析](https://amzn.to/33z5W87)
+ [計画の科学](https://amzn.to/33vP4iw)
+ [ピープルウェア](https://amzn.to/35MpkzN)
+ [熊とワルツを　リスクを愉しむプロジェクト管理](https://amzn.to/2L5tavS)

### CCPM
CCPMは、納期に向けてのプロジェクト管理でありながら、バリューストリームの最適化のToCなどの理論を背景に持つ管理手法。バッファを統合し、バッファの消費率でプロジェクトの健全性をチェックするなど、不確実性を見える化して進むプロジェクト管理の重要手法。

+ [クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか? ](https://amzn.to/35QZU4f)
+ [進む! 助け合える! WA(和)のプロジェクトマネジメント―――プロマネとメンバーのためのCCPM理論](https://amzn.to/2q3X7oW)
+ [アジャイルCCPM: プロジェクトのマネジメントを少し変えて組織全体のパフォーマンスを大きくのばす](https://amzn.to/2R6R0ev)
+ [品質と生産性を重視したソフトウェア開発プロジェクト技法―見積り・設計・テストの効果的な構造化](https://amzn.to/2GlOEQT)

### 見積もり
ソフトウェアプロジェクトにおける不確実性の原因の１つは、見積もり誤差から生じる。この見積もりにというものについて、人々はどのような歴史を持ち、どのような手法を分析してきたかを理解するとソフトウェアプロジェクト管理の半分が手のうちに入る。

+ [アジャイルな見積りと計画づくり ～価値あるソフトウェアを育てる概念と技法](https://amzn.to/37MGFud)
+ [ソフトウェア見積り](https://amzn.to/2rAHfLd)
+ [ソフトウェア見積りのすべて 第2版 ―現実に即した規模・品質・工数・工期の予測](https://amzn.to/2L8AEON)

### アジャイル/リーン
これまでのソフトウェアプロジェクト管理の流れから、どのようにしてスクラムやアジャイルなどの手法が生まれてきたかを理解すると、ポイントがおさえやすい。逆に最初からスクラムだけを学ぼうとしたり、リーンだけを学ぼうとすると躓くことがある。従来のプロジェクトマネジメントの知見を理解してそのうえにアジャイル開発を捉えたほうがいい。

+ [アジャイルサムライ](https://amzn.to/2Y11ihP)
+ [大規模スクラム Large-Scale Scrum(LeSS)](https://amzn.to/2qXSmxH)
+ [エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド (Object Oriented Selection) ](https://amzn.to/33xqeyJ)
+ [アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント](https://amzn.to/2OjSctr)
+ [リーン開発の本質](https://amzn.to/2OVMJYY)
+ [アジャイルイントロダクション：Agile開発の光と影](https://amzn.to/35IOAXy)
+ [知的創造企業](https://amzn.to/2L5m8r4)

### CMMI
経験主義的チームの管理手法は、スクラムだけではない。ケイパビリティではなく成熟度モデルと経験主義的工数管理がCMMI/PSP/TSPなどの知識体系として存在したことを思い出していくと、よりソフトウェアプロジェクトマネジメントの理解が進む。

+ [図解 はじめての「開発のためのCMMI」とプロセス改善 第2版](https://amzn.to/37RP9jZ)
+ [PSPガイドブック ソフトウェアエンジニア自己改善](https://amzn.to/2qY4dfa)

## プロダクトマネジメント

### ビジョンマネジメント/ビジネス分析
プロダクトマネジメントは、プロダクトの各フェーズごとに不確実性のジャンルが異なります。
顧客理解であったり、コンセプトであったり、ビジネスモデルであったり、デザインやマーケティングであったり。

多くの場合、フェーズと自分の得意分野がミスマッチしてしまっても、新しいステージでの学習が進まず成長が飽和してしまうことがあります。自分の事業のフェーズ認識とそのビジョン共有がプロダクトマジメントの最も難しいポイントです。

+ [リーン・スタートアップ](https://amzn.to/33CRMCG)
+ [起業の科学 スタートアップサイエンス](https://amzn.to/33xqmhH)
+ [ビジネスモデルの教科書: 経営戦略を見る目と考える力を養う](https://amzn.to/2R3588C)
+ [ビジネスモデル for Teams 組織のためのビジネスモデル設計書](https://amzn.to/33ylTv5)
+ [バリュー・プロポジション・デザイン 顧客が欲しがる製品やサービスを創る](https://amzn.to/2P2pk8b)
+ [INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント](https://amzn.to/37QHOB5)


### ソフトウェア要求/仮説検証
また、現在では単純だがWebメディアだけでなく、複雑な業務用件を満たした上で複数社に同じサービスを提供するようなB2B SaaS型/B2B2C型マッチングのサービスを開発していく企業が増えました。

これまで、画面仕様書をざっくり書いて伝わっていたことが、正確に要求を分析した上で定義していくことが求められるようになりました。また、まだ見ぬ複数の顧客に提供しても勝ちがあるかどうかが重要なファクターですから、仮説検証的に「最小限度の価値のある単位」に分割して、顧客の応答を求めていくような開発要件定義も必要になります。

このあたりは「開発キャリア型のプロダクトマネージャ」か「BizDevキャリア型のプロダクトマネージャ」で、スキルにギャップが現れるところです。

+ [【改訂第２版】［入門＋実践］要求を仕様化する技術・表現する技術 ～仕様が書けていますか？](https://amzn.to/2r1kYpF)
+ [ソフトウェア要求と仕様（電子版）: 実践，原理，偏見の辞典](https://amzn.to/2OB4sFY)
+ [要求工学実践ガイド: REBOKシリーズ2](https://amzn.to/2swI6No)
+ [アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス ](https://amzn.to/2DxeIZA)
+ [アジャイルソフトウェア要求](https://amzn.to/2rJFc7i)
+ [正しいものを正しくつくる　プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について](https://amzn.to/2Y6dQ7Q)
+ [モデルベース要件定義テクニック](https://amzn.to/34zkS7f)


### プロダクトマーケティング/プロダクトセールス
プロダクトマネジメントのフェーズが、PMFに到達する前後でセールスラインやプロダクトマーケティングがプロダクトマネージャの主な関心事になります。自社のセールスモデルかマーケティングモデルが、フィットしているかを検証しながら、グロースをすすめるための基礎的な知識をもつ必要があります。

これまで、0-1で開発チームとの時間を長く過ごしたプロダクトマネージャがマーケティングチームとつきっきりになるため、組織問題を生み出しやすい時期でもあります。


+ [THE MODEL（MarkeZine BOOKS）](https://amzn.to/2Y0uYfb)
+ [カスタマーサクセス――サブスクリプション時代に求められる「顧客の成功」10の原則](https://amzn.to/37LVLAl)
+ [サブスクリプション――「顧客の成功」が収益を生む新時代のビジネスモデル](https://amzn.to/2P2pBbd)
+ [［改訂４版］グロービスＭＢＡマーケティング](https://amzn.to/2R8hs7I)
+ [マーケティングリサーチの論理と技法 ](https://amzn.to/2OCaqGF)
+ [最新マーケティングの教科書2019 ](https://amzn.to/2OAHYVC)
+ [プロダクトマネジャーの教科書](https://amzn.to/35NFI31)

### UXデザイン/ユーザビリティ
プロダクトマネージャとエンジニアリングマネージャにとって、デザインやUXの知識はプロダクトの成否を分けるほど重要な知識です。

デザイン的思考法とUIコンポーネントやユーザビリティ、総合的なUX

+ [ユーザーエクスペリエンスの測定 : UXメトリクスの理論と実践](https://amzn.to/2QEKPOO)
+ [ユーザビリティエンジニアリング : ユーザエクスペリエンスのための調査、設計、評価手法](https://amzn.to/2pHRSuT)
+ [デジタルプロダクトのためのデザインシステム実践ガイド](https://amzn.to/2OvGP08)
+ [エンジニアのためのデザイン思考入門](https://amzn.to/34FqNYx)
+ [ユーザーインタビューをはじめよう](https://amzn.to/34E0RMT)
+ [デザイン組織のつくりかた](https://amzn.to/33e5wnp)
+ [デザインリーダーシップ](https://amzn.to/2QIzM7d)
+ [ユーザーストーリーマッピング](https://amzn.to/2KN3Dre)
+ [ノンデザイナーズ・デザインブック　［フルカラー新装増補版］ ](https://www.amazon.co.jp/gp/product/B00JX4E5CI)
+ [デザイニング・インターフェース 第2版 ―パターンによる実践的インタラクションデザイン](https://amzn.to/33uWCSw)
+ [マイクロインタラクション ―UI/UXデザインの神が宿る細部](https://amzn.to/2R6m1zy)
+ [Running Lean](https://amzn.to/2OXzozj)
+ [一人から始めるユーザーエクスペリエンス](https://amzn.to/2OyCk6l)

# おわりに
繰り返しになりますが、すべての本を読む必要はありません。
マネジメントは様々なスペシャリストと対話をしながら適切な意思決定をしていくための機能です。
なので、スペシャリストとの会話ができるような各分野への関心とリスペクトを持ち続けることが最も重要です。