【読書】エンジニアのためのマネジメントキャリアパス
おそらく、マネージャーになったばかりのときに買った本。
オライリーの本は初めて買ったかも。
で、技術系の人の管理の仕方や管理者をいくつかの分類に分けて、それぞれの立場で「どうあるべきか」をまとめている本です。翻訳なので、ところどころの用語が日本っぽくないですが、個別の事例は十分参考になります。システム屋は全国でも同じことをしていて、同じことで悩んでるんだなと思いました。
管理者の分類
読んでいて「わかっているな」とまず思ったのは、「テックリード」と「人の管理」「チームの管理」を分けている点です。日本の情シスでも、テクニカルな部分を推進するリーダーと、マネジメントや管理に特化している人、双方いますよね。で、管理のところを読むと、こういった文章があります。
エンジニアリングリードになるとコードを書く作業に費やす時間は減るが（中略）、小規模な技術的成果物の作成（バグ処理やちょっとした機能の作成など）に携わるべきである。
この部分で「まさに！」と思いました。私自身はコードを書く側や、機器を設定する作業からは離れて久しいですが、多少のコードは読めて、どんな技術があって、、といったところのおおまかな理解はするようにしています。情シスの管理者って、判断をすることが多く、上にあがるほど判断の範囲も広くなってくるので、話が通じないと正しい判断ができないからです。さらに企業の情シスの管理者は、周囲のユーザ部門との意思疎通役（翻訳をする立場）にもなるので、技術的な知識と、自社のサービス・事業や業務など、お互いのことを知っている必要があります。
管理者の判断が明暗をわける
情シスにいると日々いろいろな判断が入ってきます。以前、大規模PJで、委託先が作成する議事録が数か月遅れるといった状況が発生したことがあります。結果「部長の許可をいただいた」という理由で納品されなかったのです。部長がそのベンダにやらせたかったタスクがあり、そのための工数が議事録と引き換えになってしまったのですが、リリース後になってエビデンスがないために瑕疵が認められないといった事象に発展してしまいました。何を優先させるか、優先させたときにどういったリスクが考えうるか、これは技術的な知識だけでも判断できず、最終的には管理者自身が行わなければなりません。
チームの盾になる
これも共感したポイントですが、障害対応も、管理者の行動によってかかる時間が随分変わってきます。数年前に、自社で提供しているサービスで、広範囲である機能が使えない事象が発生しました。原因は、別拠点にいるユーザがルールをやぶって日中に大量のマスタ更新を行いDBがロックしたことが原因だったのですが、複数のベンダがかかわっており、どこから調査するか、だれがやるかといったところから判断が必要でした。コントロールを自分がやっていたのですが、途中から部のトップの方の熱が上がり、私の席のところに来て、「今どういった状況なんだ」「今の電話は誰と何を話していたんだ」「今すぐ報告させろ」と口を出し始め、最終的には私の席の隣にずっと立っている状況になってしまいました。解決するまで5時間ほどかかったのですが、口出しがなければ1時間は短縮できたはず。。。と今でも思います。
私自身が管理者になってからは、確認をするタイミングを決めて、それ以外は基本現場には口を出させない（盾になる）ということを心がけていますが、難しいところです。
管理者としてどうあるべきかを考えられた
マネージャーになって3年目に入りましたが、最近よく思っていることは、「やるべきこと」も大事なのですが「やらないようにすべきこと」もとても大事なのだということです。手を出したくても出さない、口を出したくても黙っている、「待つ」ことが必要な場面はたくさんあります。
まだまだ、ベテランマネージャーになるには時間がかかりそうです。。。
この記事が気に入ったらサポートをしてみませんか？