はじめに
マネージャー・リーダーの私にとって有益な知見が得られた書籍を、簡単な所感とともに、まとめておきます。
随時、更新していく予定です。
ここに示した書籍は、マネージャー・リーダーの経験を得た後に、自分の経験を頭に置きながら、読んでみたほうがよいと思います。
経験がない状態で、ここに示した書籍を読んでも、得られる気づきなどは少ないと思います。
書籍は、「以下の順で読むとよいかもしれない」という順に並べてみます。
また、おまけとして、以下の情報もまとめてみました。
- マネージャーとして意識的に実行していること
- マネージャーの立場で工夫してみたこと
- 書籍ではなくメンバから学んだこと
書籍一覧
「先端技術者のためのトラブルシューティング技術―組込みシステムの品質問題をこの一冊で原因究明」，金子 龍三
金子龍三さんの講演は楽しい、刺激がある。経営者やPMは、是非一度話を聞いてみるみよい。トラブルシューティングについて、体系的に知識を整理した本ははじめて見た。
本書に示されていたやり方を参考に、仮説をツリー状に（FTAのような形式で）書き共有しながらデバッグし、なんとか1日で原因特定ができた。この書籍を読んでいて本当によかった。
※参考記事
https://qiita.com/kazuo_reve/items/d8fff990b8f2e691ad74
「「派生開発」を成功させるプロセス改善の技術と極意」，清水 吉男
ソフトウェア開発（派生開発）でよくある失敗が多数言語化されている。「あるある」と思うことばかり。
書籍からではなく、SQiP研究会で清水吉男さんから直接教えていただいたこと。
- いきなり自己流でやらない。まずはそのままやる。守破離。
- ものごとを理解するためには比較をすること。
- 問題を明らかにする分析が不十分な状態で、早く問題を抽象化して表現してしまわない。
- 肯定眼。
※SQiP研究会に関する参考資料
https://www.juse.or.jp/sqip/mailnews/qualityone/sp2/index.html#03
https://www.juse.or.jp/sqip/mailnews/qualityone/sp2/index.html#02
https://www.juse.or.jp/sqip/mailnews/qualityone/sp1/index.html#08
https://www.juse.or.jp/sqip/workshop/user_voice/index.html#20180725_kashiwabara
「ソフトウェアプロセス成熟度の改善」，ワッツ・S. ハンフリー
ソフトウェア開発者（特にプロセス改善に関わる人）は必ず読むべき本。 いろいろの方が述べているが「約束の規律」「約束の作成」「約束の階層」という節は、私も感銘を受けた。また、この本を読むとSQAのイメージも変わると思う。
「人月の神話【新装版】」，Jr FrederickP.Brooks
「製作主任と技術主任を分けるべき（同一人物にすべきではない）」「有能な管理的能力と強力な技術的能力を兼備している人間はめったにいない」「技術主任の時間を圧迫せず、技術的判断を下せる権限を確立してやるべき」という主張。
不得意を互いに補い合うチームがやっぱり無駄もなくよい。
私が考える製作主任のミッションは、プロセスの能力向上（品質安定化・生産性向上、等）。
私が考える技術主任のミッションは、技術的実現性課題の解決、よいアーキテクチャの構築、メンバーへの技術伝承、優先度決め。
3章にチーム構成に関するミルズの案が登場する。私のチームも、この書籍を読んでやったわけではないが、適材適所の配置を意識したところ、同じような形になった気がする。
ミルズの案
彼は、大規模な仕事の各セグメントにチームで取り組むことを提案している。ただし、チームと言っても、全員で豚を解体するようなものではなく、外科手術チームのように編成されたチームでなければならないと言っている。
ちなみに、私のチームは以下の図のような状態であった。
「プログラミングの心理学―または、ハイテクノロジーの人間学」，ジェラルド・M. ワインバーグ
以下は実際に実感している。
どのような目標を与えるかによって、結果が大きく変わる。目標によって、困難に出会ったときの、判断・行動が変わる。目標によって、見積り結果にも影響を与える。
@kaizen_nagoyaさんから、「日本一は当たり前、世界一を目指しなさい。」という言葉をもらった。どこに目標を置くかで、確かに判断・行動が変わる気がする。
https://qiita.com/kaizen_nagoya/items/efeed472847aa4fcc835
「ゆとりの法則 － 誰も書かなかったプロジェクト管理の誤解」，トム・デマルコ
以下のような、いろいろと大切な考え方多数。周りの管理者もみんな読んだほうがよい。自分も、もう少し経験を積み上げ、もう一度読み直す。
- プレッシャーがパフォーマンスに与える影響を認識する必要あり。
- 一人の管理者が「できる」型思考と「できない」型思考を同時にもつことの難しさを認識する必要あり。
社内の仲間に紹介したら、以下の感想をもらった。
読み終わりました！繰り返し読んで心に刻んでおきたいことが沢山ありました。展開ありがとうございました！
プレッシャーやリスクに関しての考えは確かにみんなで共有したいことですね！(リスク専門の担当者いいですね。マネージャーとの両立は無理そう。)
マネージャーの仕事は、プレーヤーに自発的に動いてもらうための、環境作りと自分作りなんだなとつくづく思いました。頑張ります！
「データ指向のソフトウェア品質マネジメント―メトリクス分析による「事実にもとづく管理」の実践」，野中 誠, 小池 利和, 小室 睦
データ分析や可視化の事例が多数あり、参考にできる。
書籍の冒頭に示されている「品質データ分析の作法」も有益な知見。特に、「作法7：アクションに結びつく分析を行う」がもっとも重要だと思っている。
※参考文献
柏原一雄，松本雄太，「ゴールに繋がるアクションを生み出すデータ分析活動の事例 ～精度より成果～」，SPI Japan 2019，2019，http://www.jaspic.org/event/2019/SPIJapan/session3C/3C3_ID019.pdf
「史上最強 図解 これならわかる!統計学」，涌井 良幸, 涌井 貞美
この書籍でなくてもいいかもしれないが、確率統計のことは、知っておいたほうがいい。
この書籍には、「平均値に明日はない」というコラムがあり、印象に残っている。
「測りすぎ――なぜパフォーマンス評価は失敗するのか?」，ジェリー・Z・ミュラー
素晴らしい書籍。 みんながハマっていることが示されている。 測定と報酬の関係に注意。 この書籍で問題提起されていることを完全に解決することは難しい、定期的にに適切なやり方かを判断しないといけない。 マネージャーや運営職、経営層は、みんな読んだほうがいい書籍です。
「失敗学 (図解雑学)」，畑村 洋太郎
失敗学の考え方は、知っておいたほうがいい。
「頭のいい「教え方」すごいコツ!」，開米 瑞浩
今まで、部下や委託先を指導している”つもり”でいた。「毎回説明しているのに、なんでできないんだろう」と思うことが多かった。実際には、自分の教え方（説明の仕方）に問題があったのだということに、気づかされる本であった。 前提知識がなければPDCAサイクルを回すことはできない。つまり成長できない。事前に知識を伝えることをサボってはいけないということに気づかされた。仕事をさせながら知識を伝えればいい（OJT）という考え方がダメだったのかも。
我々のチームで考案し実行しているアプローチ・手法は、だいたい社内外に発表している。それにより、実行しているアプローチ・手法を説明できる資料（論文・発表資料）が揃っており、新しく加入したメンバにいつでも説明できる状態になっている。
「カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで」，市谷 聡啓, 新井 剛
チームビルディングのプラクティス（ワーク）が参考になる。いくつか実践してみたところ、効果がありそう。
書籍でプラクティス（ワーク）が紹介されている場合は、それを自分で実践してみて、自分なりの所見をもつとよい。
どんなプラクティス（ワーク）をやるときでも、メンバ全員がまんべんなく自分のこと・意見を話すということが大切かも。
「ソフトウェアエンジニアリング論文集80's~デマルコ・セレクション」，トム・デマルコ, ティモシー・リスター
■ワインバーグの論文
ワインバーグさんの論文で言っている以下は大切。
1 自分に対する圧力を緩め、自分の業界や分野以外に興味をもち、他の業界や分野から学ぶ時間を作る。
2 自分に対する過度の管理をやめれば、他人への過度の管理もやめられる。
■Knuthの論文
TEXを開発したKnuthがエラーログを公開してる。ただし、エラーログを記録しても、将来のエラー数を減らすために役に立つかどうかは、否定的と述べている。相変わらず同じような間違いを犯しているとのべている。
凡人でも天才でも、同じような誤りを繰り返す。自分が誤りを犯すことを認め（予見し）、誤りを探し修正することが大切。
誤りを二度と起こさないためではなく、将来自分が犯す誤りの傾向を知るために、エラーログの分析が大切。
「失敗の本質―日本軍の組織論的研究」，戸部 良一, 寺本 義也, 鎌田 伸一, 杉之尾 孝生, 村井 友秀, 野中 郁次郎
経営者やマネージャーは、読んだほうがよい。大切な考え方3つ。
1 環境適応し過ぎると環境変化に弱くなる。意図的に不均衡状態を作ることや、様々な特徴をもつ人材、異端児を組織に入れることが大切。
2 コンティンジェンシープラン。
3 組織学習。
関連記事
Qiita内で他の方が同一の書籍を紹介している記事へのリンク
「派生開発」を成功させるプロセス改善の技術と極意
人月の神話
ゆとりの法則
カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで
失敗の本質
Qiita内で他の方がマネージャー向けの書籍を紹介している記事へのリンク
エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド
プロダクトマネジメントを学びたいときに読みたい本一覧
時間が経っても「買って良かった」と思っている本
書籍の分類・分析
@hirokidaichiさんの記事「エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド」に示されていた以下の4つのマネージメントの種類で、書籍を分類してみました。一番どれに当てはまりそうかを主観的に判断しています。
- ピープルマネジメント
- テクノロジーマネジメント
- プロジェクトマネジメント
- プロダクトマネジメント
分類
| No | 書籍 | 著者 | 分類 |
|---|---|---|---|
| 1 | 先端技術者のためのトラブルシューティング技術―組込みシステムの品質問題をこの一冊で原因究明 | 金子 龍三 | テクノロジーマネジメント |
| 2 | 「派生開発」を成功させるプロセス改善の技術と極意 | 清水 吉男 | プロジェクトマネジメント |
| 3 | ソフトウェアプロセス成熟度の改善 | ワッツ・S. ハンフリー | プロジェクトマネジメント |
| 4 | 人月の神話【新装版】 | Jr FrederickP.Brooks | プロジェクトマネジメント |
| 5 | プログラミングの心理学―または、ハイテクノロジーの人間学 | ジェラルド・M. ワインバーグ | ピープルマネジメント |
| 6 | ゆとりの法則 － 誰も書かなかったプロジェクト管理の誤解 | トム・デマルコ | ピープルマネジメント |
| 7 | データ指向のソフトウェア品質マネジメント―メトリクス分析による「事実にもとづく管理」の実践 | 野中 誠, 小池 利和, 小室 睦 | テクノロジーマネジメント |
| 8 | 史上最強 図解 これならわかる!統計学 | 涌井 良幸, 涌井 貞美 | テクノロジーマネジメント |
| 9 | 測りすぎ――なぜパフォーマンス評価は失敗するのか? | ジェリー・Z・ミュラー | テクノロジーマネジメント |
| 10 | 失敗学 (図解雑学) | 畑村 洋太郎 | テクノロジーマネジメント |
| 11 | 頭のいい「教え方」すごいコツ! | 開米 瑞浩 | ピープルマネジメント |
| 12 | カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで | 市谷 聡啓, 新井 剛 | ピープルマネジメント |
| 13 | ソフトウェアエンジニアリング論文集80's~デマルコ・セレクション | トム・デマルコ, ティモシー・リスター | ピープルマネジメント |
| 14 | 失敗の本質―日本軍の組織論的研究 | 戸部 良一, 寺本 義也, 鎌田 伸一, 杉之尾 孝生, 村井 友秀, 野中 郁次郎 | ピープルマネジメント |
| 分類 | 書籍数 |
|---|---|
| ピープルマネジメント | 6 |
| テクノロジーマネジメント | 5 |
| プロジェクトマネジメント | 3 |
| プロダクトマネジメント | 0 |
分析
分類した結果、私はプロダクトマネジメントに関する知見が不足している可能性があることがわかりました。プロダクトマネジメントの知見不足により、今後壁にぶつかるまたは今まさに壁にぶつかっている可能性があります。
プロダクトマネジメントの知見をたくさん持っている方に私のチームに加わっていただけると、私のチームは更に強くなるかもしれません。
昔、@kaizen_nagoyaさんに、「自分が不得意なことは、得意な人に任せればよい」というようなことを教えてもらった記憶があります。
または、逆に、私はピープルマネジメントに関する知見が不足している可能性があるかもしれません。私はピープルマネジメントに弱みがあったからこそ、無意識に多数の関連書籍を読んだのかもしれません。私はピープルマネジメントに弱みがあったからこそ、ピープルマネジメントに関する書籍で気づきが得られ、印象に残ったのかもしれません。今も、ピープルマネジメントに関する弱みは解消しきれていないかもしれません。
所感
自分のおすすめ書籍を、何か軸で分類すると、自分の強み・弱みが見えてくるかもしれません。
ちょっとやってみて面白いなと思いました。
おまけ
マネージャーとして意識的に実行していること
以下のことをマネージャーとして、意識的に実行しています。
この中に、紹介した書籍の影響で、意識的に実行していることがあると思います。
また逆に、これらの行動により、紹介した書籍から知見が得られ、活用できたのかもしれません。
- 適材適所。
- できるだけ苦手なことは割り当てない。できるだけ一番得意な人に割り当てる。
- メンバのパフォーマンスを最大限に引き出す。
- 生産性を落とすような面倒なことは、マネージャーが引き受ける。
- 鎖は弱いところから切れる。弱いところを補強する。1か所でも鎖が切れたら、鎖としてなりたたない。
- そのとき一番苦しんでいるメンバを特定する。一番苦しんでいるメンバを重点的に補助する。
- 「鎖は弱いところから切れる。」は、どなたかから教えていただいた言葉です。
- 無駄なことはやらない／やらせない。
- みんながやっている・昔からやっていることでも、理由がわからない・納得できない・効果がないのであれば止める。
- ただ、やめること／やらないことを説明するのは、意外と大変です。
- PDCAでもCAPDoでもなくDoCAP。
- まずやってみて、やってみた結果をもとに計画を見直す。
- 気になること（手法・ツール）は、とりあえず実験的に導入してみて、やってみた結果をもとに、継続するかを判断する。
- 「DoCAP」は、@kaizen_nagoyaさんから、教えていただいた言葉です。
- 自分も一緒にやる。
- メンバにしてほしいことは自分もやる。例えば、メンバに日報を書いてほしければ、自分も日報を書く、メンバにふりかえりをしてほしければ、自分もふりかえりをする。
- 上司に助けてもらう。周りのチームに助けてもらう。そのために、先に上司を助ける・周りのチームを助ける。さらに、そのために情報収集に力を入れる。
- 自分と自分のチームメンバだけでやらないほうがよいこと・自分と自分のチームメンバがやらないほうがよいこともある。
- 情報がなければ、誰を助けられるかわからない。情報がなければ、誰に助けてもらえるかわからない。
- 笑顔・元気な声・前向きの言動。
- 嫌そうな顔、元気のない声、後ろ向きな言動は、メンバに伝播する。
- どうせやるなら、楽しんだほうがいい。
- 相手を嫌な気持にさせる可能性のあることは、アイメッセージで１対１で伝える。
- 自分が嫌な気持ちになる言葉は、人に聞かれたくないはず。
- 「私は・・・と思う」「私の経験則では・・・だよ」と、自分の考え・経験を伝える。
- あえて逆の意見を言ってみる。逆の意見を一旦肯定してみる。
- 逆の意見が、発想を広げる。逆の意見が、視点・視野・視座を変える。
- バグの混入したメカニズム・バグを検出できなかったメカニズムを自分で説明する。
- 説明しようとすることで理解が進む。
- メカニズムがわかれば、防止策が考えられる。
- 成果を発表する。
- チームの成果を発表し、チームの成果をみんなで誇る。
- 発表資料があるから、新メンバや関係者にいろいろと説明しやすい。
これらの行動の効果かはわかりませんが、ここ5,6年、プロジェクトが炎上状態になることはありません。
これらの行動の効果かはわかりませんが、プロジェクトマネージャーをするのは楽しいです。
これらの行動の効果かはわかりませんが、自分は自分のチームが好きです。
別の記事で、上記の行動についてもう少し詳細に説明させていただくかもしれません。
マネージャーの立場で工夫してみたこと
以下の記事に、マネージャーの立場で工夫してみたことをまとめた。
書籍ではなくメンバから学んだこと
今のチームにはないスキルを持っている人にチームに入ってもらう
「今は必要ないスキルでも今のチームにはないスキルを持っている人」をチームに入れるのは、「今必要なスキルを持っている人」を増やすより、長い目で見ると実は価値があるかもしれない。
同じ能力をもった人の集団より、異なる能力をもった人の集団のほうが、強い気がする。
今までと違うスキルが必要な新たな業務依頼を受けたとき、「それできますよ」と受けられ、業務範囲を広げられる可能性が生まれる。
今まで導入していなかった技術を使って、「こんなことできますよ」と提案ができ、大きくにQCDを向上できる可能性が生まれる。
うちのチームには、今の業務には必須ではないスキルをもったいろんなメンバが何人かいる。このいうメンバが、価値を生み出している・価値を生み出しそう。今その業務で必要なスキルを定義し、そのスキルを持った人材を登用するのはもちろん大切だけど、将来を睨んで、全然異なるスキルを持った人材も積極的にチームに入れていくことも大切だと思う。今まで、いろいろな特徴の異なる人達に、チームに加入してもらえてよかった。
うちのチームは、以下のような必須ではないスキルをもったメンバが揃っている。協力し新たな成果・価値が生み出せている（これらかも生み出せそう）。
- 中国語を喋れるメンバ（中国人のメンバ）
- Excel,VBA,perl,DOSコマンド,PowerShellが大好で、自動化が大好きなメンバ
- モデル検査の技術を習得してるメンバ
- チーム外の有識者者と人脈をたくさん持ってるメンバ
- 世の中にある便利なツールをたくさん知ってるメンバ
自分にはないスキルを持ったメンバとチームを組むのは、単純に面白い・楽しい。
会社の採用でも、今会社に必要なスキルを持っている人を採用するより、今会社に不足してるスキル（誰も持っていないスキル）を持っている人（入社した瞬間に、ある技術では社内NO1になる人）を採用することが重要かも。
スキルの高いメンバにはあそびの時間をもってもらう
スキルの高いメンバは、時間がフルに埋まるようにタスクをもってもらうのではなく、余裕をもってもらい、自由に使える時間を作ってもらうとよい。
スキルの高いメンバはこのあそびの時間で、マネージャーの私が、想像していなかった成果を出してくれることが多々ありました。
- タイムリーにメンバのサポートをしてくれる
- 今は必要ないが将来必要になりそうなことまで、調査し理解しておいてくれる
- 便利なツールを作ってくれる
スキルの高いメンバだけではチームはなりたたない
※決して、批判、否定ではありませんので、ご注意を。
例えば、スキルの高いメンバは、自分のスキルをもてあます面倒なことをやりたがらないことがあります。ただ、どうしても、この面倒なことをやらざるを得ないことがあります。こんなとき、面倒なことを地道に時間かけてやることを、苦にしないメンバがいると助かります。
いろいろな、特性をもったメンバが揃っているからこそ、プロジェクトがうまくいきました。
本当にチームのメンバに感謝。ありがとう。