『リーダーの仮面――「いちプレーヤー」から「マネジャー」に頭を切り替える思考法』を読んで
『リーダーの仮面――「いちプレーヤー」から「マネジャー」に頭を切り替える思考法』という書籍を読んだ個人的な感想戦を書き残す。
新宿のジュンク堂でたまたま視界に入って、ちょうど「マネージャって結局自分にとって何なんだろうなぁ」とか思っていたタイミングだったので、読み始めた。わりとメインのプレーヤーとして関わるプロジェクトも完遂し、「チームの主たる成果を出すいちプレーヤー」を終えた節目だったり、上半期評価のタイミングで、組織の中の個人の振り返りをしていたタイミングでもあった。
識学をベースとした、新任マネージャ・中間管理職のマネジメント手法の解説本
この書籍はタイトル冒頭にあるが「識学」という考え方をベースにし、それを普及することを仕事としている方が筆をとって書かれている。具体的にはこの会社の社長さんである。
識学は、生産性が高い組織運営を実現するためのマネジメント理論です。
識学は「意識構造学」という学問からとった造語であり、20年以上前に提唱された組織運営理論です。識学はこの原理論を体系化し、弊社の基幹理論として整備したものです。 識学は、なぜ生産性向上を実現できる組織と、そうでない組織があるのか、どうすればいかなる組織でも生産性向上を実現できるのかを追求しています。
「識学」自体はこの会社独自のマネジメント理論であるがゆえに、当書籍における参考文献の記述は少なめ。ゆえにこの人の感想に近いことを思った。
https://www.amazon.co.jp/gp/customer-reviews/R11PXDF6CTBA69?ASIN=4799105868
モチベーションに関する記述等、なるほど！と、思う面もありますが、全体的には、少々極端だなと思う点もあります。
本書を読んで、そのまま適用すれば良いとも思えないです。
読んだ人事にそれぞれ感想があると思うが、個人的に「なるほどね」っておもったところだけ、自身の考察を発展させるきっかけとして、たらたらと垂れ流す（本書に書いていたことみたいなまとめは一切していないので、ここに書いてあることが本書に書いてあるという期待は持たないでいただきたい）。
いいお兄ちゃんになるな的な話
表現を丸め過ぎかも知れないが自分が解釈した話としては、好感度だけを狙って、労ったり寄り添ったりするようないいお兄ちゃんはいらんのだよっていう話と解釈した。
これ自体はよく主張される話だが、本書では「部下とは距離を取ることで平等性を維持する」といった理由が示されている。まぁ、特定の人だけ贔屓で評価されてる、みたいな感情論で評価してるんかあいつ？みたいにならないようにねっていうことだとおもう。
モチベーションを気にしすぎるな
モチベーションを気にするようなマネジメント手法に対して、成果がモチベーションにつながるんだからっていう立場を取る主張であった。
個人的には「どういうモチベーションで働いていてその人の関心につながっていたり腹落ちできているか」について、マネージャーになる前からかなり気にしていた。しかし、最近は確かにある一定成果を出すことで後から振り返ってよかったなって思ってもらうほうが当人のためになることもある、と思うこともあるので、半分くらいは同意した主張であった。
自由すぎるのはストレスになるから、ルールを決めるが仕事
これは、現職でもたま〜に見受けられる事象だった。
ルールが明確でないことは、部下にとってストレスになります。リーダーの顔色をうかがい、空気を読みながら行動しないといけないからです。
ベンチャー企業だと、ルールがないことに慣れている人も多く、無いなりに自分で作る側に回る傾向が高いと思っているが、ある程度会社の規模が大きくなると「ルールを決めてほしい」側の人間も増えてくる傾向にあるのも事実である。
ピラミッド型組織にいるならピラミッド型なりの振る舞いをしたほうがいい
ピラミッド型組織のメリットデメリットを再評価した上で、ティール型組織等の別形態の組織体系内でワークするマネジメント像をそのままピラミッド型でやってもうまくいかんよそりゃ、的な話を語っていた。それはそう。
自分の価値観ではなく淡々と事実を
フィードバックなんかもそうだが、「俺の仕事観ではこういう価値がある」みたいなモチベーションの付け方は微妙だし無駄だぜって話をしていた。仕事の価値観がメンバーとずれていた場合に「まぁあなたの中ではね...」としかならないって言う点。それはそう。
これに対しては当人が目指す像があるならそのペルソナの共有はひとつ選択肢として取れるのかなと思ったりする。フィードバックなんかも「その人がペルソナに近づくためには」という視点で見たほうが腹落ち度が上がるんじゃねって思うので、そういうペルソナを明確にするようなことは試行錯誤していきたいなと思ったりしている（書籍にはないことを喋っているし、書籍とは逆行している考え方）。
適度な「不足」ストレスを感じる課題設定を
これはそうだよねって最近おもうが、「自分の現在のスキル・能力では足りていない課題」であることは大事ですよね。
言い方を変えればコンフォートゾーンから意識を抜け出すための支援として、多少今のままでは「不足」をしていてINPUTをふやすなり「がんばらないといけない」課題や役割・期待の設定によって個人の成長を促す、とかはしていかないといけないですね。
余談: 業務でミクロな視点に、時にマクロな視点に
これは同僚が最近、ミクロ・マクロという言葉をよく使っているものからインスパイアされて書いている。普段業務では締切やスケジュールを達成するために「やらねば〜」で頑張ってくださっているとして、ときに個人の役割の変化とか、チームの変化とか、チームへの貢献の仕方とか、当該組織関わらず目指す人物像に対する差分の再確認とか、個人としてもマクロな視点で考える時間とかが定期的に訪れると、組織貢献の形に対して今どうかとかも考えられるし大事にしていきたいですよね。1on1は関係づくりの場とか色々言われていたりするが、そういった「個人にとってマクロな視点に立ち返る」という場の設計とかを個人的には考えいかんとねぇって思う。
特にソフトウェアエンジニア界隈だと、それなりにハイスキルだったり給与レンジが高い役割・期待・スキルの人であればあるほど、「その先ってなんだろう」ってのがわりともやもやしている気がしている。これは新卒育成みたいなニュアンスでも言えるだろうし、むしろハイスキルな優秀な方が組織にいるときのほうがより考えないといけない課題なんだろうなと思う。
組織としてはキャリアが続く道・受け皿を広げていくこともしっかり組織の形と連動して考察していかないといけない。
余談: 組織にとって必要なことをする「中間管理職」は特に悪かもしれない
本書とは全く関係ない話。
「今必要なことをやりますよ」っていうスタンスで働いてきたが、ことマネージャへのロールチェンジに関しては、これが微妙になることもあるかも知れないと最近感じている。
「必要なことをやる」は積極的にビジョンを持ってノリノリのテンションでやってる分にはいいんだけど、そうじゃない場合「ただ受身の姿勢」になってしまうことが悪い点。自分がノリノリじゃないと言っているわけではないのだが、これまでのアーキテクト志向とかのプレーヤー目線の場合には「チーム開発のためにこういうことやらんとな」っていう目的・ビジョンからの逆算があった。
マネージャーの場合は、組織像とか個人としての像とかそういうビジョンがあったうえで必要なことを「手段」として行っていく事が前提である。
開発エンジニアのチームのマネージャーだけであれば、明確な数字を持ちにくい。「滞りなくものごとをすすめる」とかの進行責任であれば、Engineering Program Managerのような役割がいるのであればその役割の人達に権限ごとまるごとproxyして委譲される形になる。コード品質面においてはTech Leadの役割がいるのであればその人に権限ごと委譲したほうがよい。
そうした場合に個人のキャリアだったり、しっかり組織として評価され組織外に出ても活躍できるようにキャリア支援していくような、ピープルマネジメントが残る形になる。
「チームが働きやすい形に合わせて自身の職域・職責に制約をいい意味で与えて、最終的な責任は己が持つ」という点ではいい。しかし、たとえば3階層でM - EM(me) - memberのような「中間管理職」の構造の場合には、すでに既存のMがやっていることから、積極的に役割・仕事を剥ぎ取っていく姿勢が大事である。
最近の己を振り返ったときに、チームメンバーが働きやすいように身を引いて「待ちの姿勢」を取るということは意識していたが、一方で中間管理職としての「マネジメント領域を広げていく」方向には、受動的担っていたことに気がつくなどをした。
この記事が気に入ったらサポートをしてみませんか？