「マネジメントは嫌いですけど」を読んで
こちらの本を読んでの感想をつらつらと書いていきます。書評という高尚なものではなく、単純に自分自身の感想文として書いています。
関谷雅宏 著 「マネジメントは嫌いですけど」
目次や著者の情報は上記のサイトから確認できますので、そちらをご参照ください。
感想
全体を通して、自分が今感じていることに近しい感覚を著者の方が持っていて、内容に非常に共感できる部分が多かった。
基本的には著者の自伝的要素が多く、中小企業での役員経験と大企業でのVP経験それぞれの視点でのマネジメントを通して、マネジメント自体は嫌いでも、「今より良くしていくために何ができるのか」を追求してきた結果が、エッセイ色強めに述べられている。
個人的には、このエッセイ風の記載が非常に読み進めやすかった。
アウトプットは60%の力(時間)で行う、初心者をどう教育していくか、維持・メンテナンス予算が取りにくいのはなぜか、といったマネジメントを行う中で気になるポイントを自身の経験をもとに、どう立ち向かうと良いのかを方法論ではなく考え方として進んでいく。
随所に頷きポイントがあり、定期的に読みたいなと思う一冊。
ここからは気になった部分をピックアップして、自分の感想も交えて書いていきます。
「やりたくない」というのなら、マネジメントはいらないのでしょうか？
そんなわけはない、誰かがやらないといけないこと。では、やりたくないなりにもやりようはあるのでは？もちろんこれが、本書の主題。
(かくいう私も「やりたくない」派の人間です。)
マネジメントの目的は「現実に変化を起こすこと」
今の組織が上手く動いているように見えていても、手を挙げたら負けの文化や、できる人に仕事が寄ってしまう、というような現実があるとして、これで将来この組織は上手くいくのか？
この環境を変え、未来を変えることがマネジメントの目的。これにはもちろん、時間・教育・お金など様々な要素が絡んでくるので、そこを上手く立ち回るのがマネージャーである。
仕事は頼んだ方にも責任がある
これをマネージャーが意識してくれているだけでも、部下は働きやすい環境を手に入れられる。
そして、これは日頃タスクをお願いする時に気をつけていることで、間違ってなかったのかなと少しホッとした。
今現在ないものを作るのだから、失敗しても今より悪くならない
これくらいの気持ちでいないとシステム開発はやってられないよなと。別の部分でも、上手くいくかどうかは、50%の確率で表か裏のどちらが出るかくらいのものでしかないとも言っている。
マネージャーになっても技術を追いかける
マネージャーになったら技術は関係ないわけではない。むしろ、権限のあるマネージャーなのだから、打ち合わせの取捨選択をしながら、技術を追いかける時間を確保することも重要。
「マネージャーになると技術から離れてしまう」からマネージャーになりたくないという技術者に向けて、技術を追いかけ続けている姿を見せるのもマネージャーの役割。
技術を追いかけることで、技術者とのコミュニケーションもとりやすくなる。マネジメントの中に「技術を学ぶにはどうすればいいかの『ディスカッションの材料』を提示していく」ことを入れてしまうのも、一つの手段。ただし、やり過ぎて邪魔になるのはダメ。
アウトプットは個々の力で計るのではなく、全体の総和として考える
個人が頑張って対処できる問題には限界がある。だから、チームとして問題に対処し、チームとして解決できたかどうかを判断する。そうすることで、ナレッジのシェアにもなり、初心者のレベルアップ・有識者のアウトプット(教師役)としての成長機会の創出などの良い効果しかない。
そして、明確にアウトプットは60%の力で行い、残りの40%を技術の底上げ・コミュニケーションに割り当てることで、長期的にチームがバリューを出せる力を蓄える。
自分の足りないところは公開したほうが解決しやすい
自分の弱い部分を部下に公開する方が、相手がどう動けばいいかも分かるのでスムーズに事が進む。
この方は事務処理が苦手だったから、得意なメンバーに依頼していた。結果としてチームからの事務処理依頼も受け入れ、チームがスムーズになった。得意な分野で感謝してもらう場を考える。
犬はワンと鳴き、猫はニャンと鳴くのだから、逆はやめて
無意識に犬にニャンと鳴かせようとしてないか。得手不得手があり、それが他人からはっきりと分からないのが人間。自分の想定通りに動かないことが当たり前なのだから、そこに固執しない。
組織で生かしにくい技術者の例
ここはぜひ読んでいただきたい。特に技術者として生きている方。
- 自分だけで問題を解決しようとするタイプ
- 最新の技術を追いかけるタイプ
- 技術的な好奇心を満たすためにいつまでもやめようとしないタイプ
自分自身ドキッとする記載もあるが、それはそうだよなと納得した。もちろん新しい技術も必要だが、今の事業とのバランスをきちんと見極める事が大事。
学び合ってもらう
教育の唯一の方法は教師に教えてもらう。ただし、外部の教師は一般的なことは教えられるが、社内での具体には踏み込みづらい。どこかで社内の教育サイクルに移す必要がある。OJTなどもその例ではある。
さらに効果が出たことの例として、「教材を作ってもらう」、「勉強会を開催する」、「実機を使って訓練する」、「仕事として必要なことなのだとういう認識をどう作るか」。特に最後の認識は部門外の長から認識してもらう、もしくは社外から客観的に評価してもらう事が大事である。
コラムで、社内に向いている時間が長いと技術への判断能力が身につかないと記載されていて、今社外のコミュニティ活動をしている身からすると、これだ！と感じた。これまでも外部からいろんなエッセンスが得られるから、と思ってはいたが、「技術への判断能力が身につかない」という言葉がピッタリだなと思った。
何を報酬とするか
ここが一番課題かなと思った部分。
技術者の評価はチームで動いている以上、個人の評価にはしにくい。賃金として報酬を与えるにも、これは外部の経済状況によって左右されるものであり、いちマネージャーがどうこうできる部分でもない。ではマネージャーは何を報酬として技術者に与えられるのか。
例では、役員レベルに技術者が優秀であるということを直接見せ、評価を上げてもらうチャンスを作る。そして、技術者としての成長の機会を提供する。それによって社員が別の企業に移ったとしても、その企業で内外から評価されることでゆくゆくは元の会社の評価にもつながると割り切る。
そのために、20%は技術の底上げに割り当て、研修などは積極的に参加するような仕組みにした。その間の障害対応などは原則禁止するよう調整した。
プロジェクト予算を疑う
プロジェクトごとにサーバーを調達していたが、年間の概算で一括購入した方が遅延のリスクや割引などでメリットが出せる。というように、これまでのプロジェクトの予算という考え方を見直すことで、組織・プロジェクト運営がスムーズに動くこともある。
維持する予算は何かを作るときよりとりにくい
これはどの会社でもそうなのかと思った。維持する予算は確実に減らされる一方で、それが原因で何かと理由をつけて無限にプロジェクトを発生させることになる。
組織に完成はない
組織に完成を求めること自体がナンセンス。つまり、マネジメントも組織に合わせて変化すべきものだから、完成はない。各種のマネジメント手法が提起されているが、各社の前提が異なるのでTipsの一つとして使っていくことが大事。
マネジメントはだれかがこなさなくてはならない役割にすぎない
『マネジメントはだれかがこなさなくてはならない役割にすぎないことを忘れないでいるということです。そして、その役割を果たしている人間に特別な価値はない。』
そんなことないよ、な締め。
ただ、「マネジメントが嫌いな人」はそれくらい割り切って、描いた未来とのギャップを埋めるため、自分がコントロールできる範囲でメンバーに対して何ができるのか考え、遂行するだけだと感じた。そして、これは技術者というバックグラウンドを持っている方がやりやすいのだと、全体を通して感じた。
最後に
単なる感想をダラダラ書いただけでした。。
マネージャーになりたくないけど現状は変えたい自分からすると、非常に刺さるものでした。
背表紙に書いてある、「自分がしてほしかったことを探すなら、やりたくなくてもなんとかできる」とは、まさにこの本を表しているなと感じました。
全体的に非常に読みやすく、おそらくシステム開発に携わる多くの方のキャリアを考える上で参考になるものだったのではないかなと思います。機会があればぜひご一読ください。
Discussion