「マネジメントは嫌いですけど」を読んで

4章までの目次の抜粋

1章 マネジメントできるのは未来だけ

 1.1 解決病にかかってしまう問題

 1.2 未来から逆算して考える

 1.3 マネジメントの目的は「現実に変化を起こすこと」

2章 理想を描いて余裕をつくる

 2.1 何が問題か? 何を目指すべきか?

 2.2 アウトプットは「60%」の力でおこなうこととする

 2.3 技術の底上げと訓練に「20%」を使用する

 2.4 残りの「20%」の使い方

 2.5 マネージャーになっても技術は追いかける

 コラム 進捗は塗り絵のように面積で考える

3章 部下は思いどおりに動いてくれない

 3.1 正解はない、だから試行錯誤する

 3.2 好かれていようが、嫌われていようが、部下は意地悪なテストをしてくるものだ

 3.3 自分の足りないところは公開したほうが解決しやすい

 3.4. 犬はワンと鳴き、猫はニャンと鳴くのだから、逆はやめて

 3.5 信用も信頼も、するのは相手ではないだろう

 3.6 属人性も人材の流失もリスクの1つにすぎない

 3.7 組織で生かしにくい技術者の3つのタイプ

 コラム 新しい世界の布教とこれまでの世界の維持も大切な技術

4章 学べる仕組みを実装する

 4.1 人を育成する悲しくも唯一の方法

 4.2 教え合ってもらう

 コラム 社内に向いている時間が多いと、技術への判断能力が身につかない

 4.3 「問題を解く」のではなく「問題を作る」

 コラム プロセスで品質を上げるために必要なこと

 4.4 科学の力を利用できるようにする

 4.5 妄想するな、計測しろ

 コラム 計測し続けていた技術者

私について

以下の自慢記事に色々書いている:

印象的だった内容と感想

本に書かれていた言葉で印象的だったものを挙げてみる(純粋な引用ではないのでご勘弁を。●が本の言葉、◯は僕の感想)

  • 仕事がうまく行く確率は半分

  • 最初に一番ロジカル(数学的)ではない言葉かもしれない。けどそんなもんだよなとも思う

  • 部下の意地悪テストにはそういうものと思ってフラットに対応すれば良い

  • ITのお仕事ってよく批判される多重下請けで成り立っている事が多い。自分も新しい委託先の方が来ると多分こっちの能力を確かめたいんだろうなという質問をされる

  • 結局人の防衛本能なんだからそういう質問は仕方ないし、わからないことはわからないと答えるしかないのだからフラットに対応すればよいとのことに何回か救われている

  • 足りないところはまわりに知らしめよう

  • エンジニアは人の欠点を見つけるのが好き(ソフトのバグ出すの好きでしょ?)

  • 欠点を隠すような振る舞いをすると信用されにくい。足りないことは足りないと打ち明けてしまったほうが双方良い。チームとしてもフォローし合ったほうが効率的

  • 人はそれぞれ得意不得意があるのだから、比較優位性で得意なものに集中した方が全体効率上がる

  • これは本当にそう思う。できないことはできない

  • まあそれじゃ終わらんから難しいんですけどね

  • あと属人化するリスクもあるよなあ。理想はこれだけど、スーパーマンがいない限り難しい

  • 他人を自分が思う通りに変えることはできない

  • 教育と洗脳はわける、後者で部下が変わって自分が教育したと正当化する人が多い

  • これも本当にそう。筆者は「教育」は負の感情が生まれないとしている。それは、できないことを双方が認識し、できるようになることを目標とし、そのため方法を考えるから。

  • 結局「教師のもとに放り込む」が最強の教育

  • 本当に現在の良い教師がいる環境に感謝している

  •  妄想するな計測しろ

  • これも本当にそう(システムでもバグが出たらログ見るでしょ?)。マネジメントとなった瞬間感情論として捉えてしまうけどそうではなくてもいい。

結局、混沌とした中で正解はないのだから試行錯誤して自分なりの成功を見つけようということですね。筆者はロジカルと諦感でマネジメントの仕事に向き合う方なんだなという印象を受けました。

僕のお気持ち

自分は前職の上司がこの筆者と正反対の人だったのもあり、マネジメントというと、

  • 一般にコミュニケーションが高いとされる人が、

  • 上の立場に人にごまスリスリして、

  • 下の立場の人にバレないように、文句を言わせないようにパワハラチックなことをして、

  • 目標を達成させたこととすることをかっこよく言ったもの

と思っていました。なので自分はマネジメントという仕事に敵意さえ感じていたし、若手でマネジメントしたい、リーダーしたいという人には警戒心を持っていました。

この本を読んだことで、マネジメントというのもただの役割の一つで、技術と向き合うときによく使うロジカルな思考・コミュニケーション能力でできるものという印象を持てたのがすごく良かったです。

ここからは今の自分のお仕事の話になるのだけど、最近小さいチームのリーダー業務のお試しみたいなのをやらされています。結局自分のリーダーや別の有識者に頼りっぱなしで、自分がやったことは何?状態になってしまっているのが実情ではあるが。

非常に大雑把に言うと自分のリーダーもこの本の筆者の考えを含んでいる気はしている。なので前半で抜粋したことを無意識にやっているんだなあとよく感じる。これに加えて、自分のリーダーから教わったことでよく覚えているのは(他にもあったと思うが)

  • 事実を見よう(計測しよう)

  • メンバーから進捗が良くない原因がほんとにそうなのか。それは事実なのか調べる

  • メンバーのモチベーション(本音)を大切にしよう

  • 頑張っても無理なものは無理

  • 諦めて怒られる準備をするとか、とにかくがむしゃらに頑張るみたいな思考停止しないということ

  • 目標を考えたときにとり得る選択肢で何が最適かちゃんと考えましょうということと理解している

ということ。

結局、技術者としてもマネージャー的にも優れている人ってこんな考えに行き着くんですかね。自分は「ロジカルでないことを言われることへのストレス」が非常に大きい人間だと思っているので、今こういうロジカルなチームにいられているのは大変ありがたいです

Share:Post

関連記事