マネジメントをエンジニア的な思考で考える、という方向性では、ベストセラーのエンジニアリング組織論1が有名だが、こちらも、スタートラインは同じ。より、現場感というか、泥臭い感じ。
私は、「技術職を経験しているマネジメント」の人間がもっとたくさん、自然に増えるといいと願っています。なぜなら、技術者の常識が、マネジメントに必要だからです。
はじめに
インフラ、特に間接部門のような位置でインフラをやっている人には共感できることが多いと思う。基本的にはマネージャー向けだが、ちょいちょい「マネージャーの苦労もわかってくれ」的なメッセージも感じなくもない。
今となってつくづく不幸だと思うのは、技術者たちの貢献を享受する側が、何も問題が起きないということにどれだけ彼らの貢献があるか評価する術を持たないということです。
第5章 5-1
残念ながら、古くて先のない技術の保守へ未経験者を入れることも耳にするようになりました。しかし、その未経験者たちが経験を積んでも、その先に技術者としてのキャリアは望めないように思います。
第5章 5-5
以下、感想メモ
エンジニアは何かしらの技術で問題を解決する。これは自然と「解決できる問題だけに対応」する解決病にかかってしまいやすい。解決病にかかると、人がたくさんいれば良いと考える、短期的な視点になる、OJTが教育の主軸となる、などなど、未来に向かうマネジメントを行う余裕がなくなってしまう。今の状態を前提にするのではなく、あるべき未来に向かってどうすればいいのか、と未来から逆算して考えるのが良い。
アウトプットは60％の力で行う。60％くらいの時間で終わらせられるようにしていない人間には注意する＆評価しない。チームはアウトプットを出すのと同時に、チーム全員の技術力を向上させる必要もある。そこで、20％を技術の底上げと訓練に、残り20％をナレッジ共有や緊急タスクに振る、としている。後者はSREのError Budget2に似ている。
属人性の人材流出リスクの1つ。そもそもマネージャーが担当の仕事に対する取捨選択を自分の都合でどうこうしようと言うこと自体が間違っている。結局は組織の平均レベルを上げていくことた大切。この前提でマネージャーが生かすことができない技術者のタイプは ①自分だけで問題を解決してしまおうとするタイプ ②最新の技術を追いかけるタイプ ③技術的な好奇心を満たすためにいつまでもやめないタイプ、の3つを上げている。みんな個性的ておそらく優秀な技術者だが、こと平均値を上げるという目的に関しては、価値観が共有できていない、ということなんだろう。
スクラムとMBO (目標管理制度）は矛盾している。 “スクラムが組織内で定着するかどうかは、人事評価の対応をおこなうかどうかが９割を占めると思います。 (5-7)” この辺りの論理はとても面白かった。
予算を取ると言うこともある意味では技術の1つ。①購買部門や顧客と交渉し都度発注から年間の概算で予算を立てる ②削減する方向ではなく伸びていく方向で予算を立てていく。マネージャーの仕事は、利益を生み出すための資産となるかどうか、予算管理部門に理解してもらうことが仕事である。自社の決算資料は読めるようにしておき、技術がないとわからない投資・費用を見える化して財務・経理に飲み込める形に落とし込めるか考える。
マネジメントはだれかがこなさなくてはならない役割にすぎないことを忘れないでいるということです。
第8章 8-3