先週の 1 on 1 で上司から「増田さんには合わないと思いますが(^^;」という但し書きの上で紹介されたので、逆にやる気を出して読んでみた。
amazon.co.jp
確かに反論したい箇所は多々あるものの、その主張の根本を辿るとそうでもない気はした。むしろ合うかもしれない。
想定読者を読み誤っていた
全体的にリーダー（マネジメント）視点で書かれているので、プレイヤー視点で読むと、誤解が多く非常に良くなかった。← 最後まで誤解してた人
P11
この本は、そんな識学のメソッドを元に、「若手リーダー」に向けてマネジメントのノウハウを伝えるものです。
初めて部下やスタッフを持つような人、いわゆる「中間管理職」を想定しています。
最初ここを流して読んでしまったけど、この前提を忘れて読み進めたので最後までヘイトが溜まってしまった。
特に「プロセス（過程）は評価しない」には嫌悪感さえ覚えた。プレイヤーがプロセスを軽視して良いわけがない。業務の属人性が高まるし、再現性の低いものばかりできる。そんなものはプロフェッショナルの仕事ではない…と。
P173
そこでのひとつの結論は、「 プロセス（過程） は評価しない」ということ
ここでさらにヘイトが溜まったけど、、（続く）ｗ
P214
そこで重要なのが、第４章の「プロセスに口を出さない」ということでした
ここで、逆説的にはプレイヤー視点ではプロセスが大事と言っていることに気がついた。💡
※ これ、解釈が間違っていたら前提が覆るね (^^;
P220
プレーヤーだった頃の自分を、部下たちがはるかに超えていく瞬間 。 ぜひ、それを体感していただきたいと思います。
はい、完全なマネージャー向けの本ですね。失礼しました…。
[2023-03-26-1] にも書いたけど、今は自分含めた４人チームのリーダーを任されたところで、且つ自分以外は業務委託の方々なので、想定読者ど真ん中ではなさそうだった。
エンジニア組織に合うのだろうか？
これは最後まで疑問だった。営業組織向けの本かと思っていたら、、、
P189
デザイナーやエンジニアの世界では、部下に対して、「上司が納得したらＯＫ」という設定をすることもあるでしょう。
ここでズッコケてしまった。うーん、大企業ならあるのか…？
まだ私に前職までの、スタートアップでのウェブプロダクト開発の空気感が残っているので、賛同し兼ねてしまう。これからあるのかあ…。🌀
肝心の感想
事実に対して淡々とフィードバックする。プロセスは見ない、結果だけにフォーカスする。
上司（≠プレイングマネージャー）と部下という関係なら、とても良いし、理想的とさえ思った。
本の中では 1 on 1 を否定していたけど、まさに [2023-03-26-1] の『ヤフーの１ｏｎ１ 』と同じことをしている。作者の方はダメな 1 on 1 しか見たことがないのかも。
まとめ
そういうわけで、マネージャー向けには良い本だと思う。ボリューム少ないのも良かった。２時間ちょっとで読めた（重要）。
自分用読書メモ
いいリーダーの言葉は、 「時間差」 で遅れて効いてきます。
これはそうかもね。最近小さく実感したところ（自画自賛）。
識学では、組織の成長スピードを考えたとき、「ピラミッド構造が最適であり、最速である」と考えます。
まだ自分の中で結論が出てないけど、条件付きで Yes かもしれない。
[2021-03-13-1] でも思ったんだけど、スタートアップのような能力密度の高い組織では成り立たない可能性があるから。
大阪市のような普通の人が多そうな組織で成り立つのだと思う。大企業もそうだと思う。
「この仕事はＡさんに任せた。契約に結びつけてください」 「来週の火曜の 15 時までに資料をまとめておいてください」
この辺の割り切りは自分に足りない。
大事なのは、 「機械的なほうれんそうをさせる」 ということです。
これはエンジニアだと難易度は高くないと思う。GitHub Issue/PR を淡々と更新すれば良いので。それも難しいと言われそうな気はするけど…。
個人的には世間一般で認定されてそうな「ほうれんそう」には反対。部下が上司に報告するのではなく、部下はこまめに共有し続けて、上司は必要あれば Subscirbe すれば良いだけ。多少は部下からの説明はあると思うけどね。
大きな「ほうれんそう」をぶつけるのでなく、小さくコンパクトな「ほうれんそう」を出し続けたほうが時代に合っていると思うんだよね。昭和の時代と違って、結局上司はプレイングマネージャーで、忙しすぎること多いから。