ディップ Advent Calendar 2018 23日目の記事を担当させていただきます。
今年は贅沢にSREのAdvent Calendarの6日目の記事も担当させていただきました。
さらにレガシーな基盤にSREを入れるには という題で勉強会での登壇もさせていただいたり年末の忙しさは半端ないなと思いながらこれを書いております。
現在私はSREチームを率いるマネージャーとしてインフラ改善や速度改善チームなど様々なプロジェクトにかかわり活動を行っております。
活動の幅が広がるとやはり一人で業務を行ってくことは難しく、最近マネジメントについて考えることが多くなってきました。
まだまだ新米のマネージャーのため日々躓くことが多いですが、最近マネジメントについての本を読んでマネジメントの大事さをひしひしと感じている中、日々の業務で気を付けていることなどを書きたいと思います。
参考にした本は以下になります。
- [エンジニアのためのマネジメントキャリアパス](https://www.amazon.co.jp/%E3%82%A8%E3%83%B3%E3%82
%B8%E3%83%8B%E3%82%A2%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88%E3%82%AD%E3%83%A3%E3%83%AA%E3%82%A2%E3%83%91%E3%82%B9-%E2%80%95%E3%83%86%E3%83%83%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%89%E3%81%8B%E3%82%89CTO%E3%81%BE%E3%81%A7%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88%E3%82%B9%E3%82%AD%E3%83%AB%E5%90%91%E4%B8%8A%E3%82%AC%E3%82%A4%E3%83%89-Camille-Fournier/dp/4873118484/) - エンジニアリング組織論への招待
エンジニアリングマネージャーになるために
その業界で仕事をしていると日々仕事をしている中、非エンジニアの方たちと話していると中々伝わらないことと言うことが多く発生しています。
その理由としては技術的な知識、経験的な知識などいくつか理由があると思っています。
そのたびにこの単語の意味や仕組みなどを知っていればもっとうまく話が進むのになと思うことがあります。
そういった経験の中、自分自身がそう言う場面に出くわした時にエンジニアが気持ちよく仕事を進めているハブ的な役割になれればなと思いマネジメント力を身に着けたいと思ったのが私がマネジメントをやっていきたいと思っている理由の一つにあります。
ただ色んな知識を吸収し続けていくと、自分の中の常識で話し実はうまく情報共有ができていなかったり、なぜあの人はこんな事も知らないんだろう、と思ってしまっており本来の目的から外れてしまっていることに気づかされたことがありました。
そうならないために、またはそういった考えを直すためにエンジニアがなりがちなマネジメント例を挙げさせていただきます。
##エンジニアリングで陥りやすいパターン
始めに紹介した『エンジニアのためのマネジメントキャリアパス』の本に、ひどい上司としていくつか例が挙げられている中でいくつかをまとめてみました。
| 名称 | 概要 | 特徴 | 改善するために必要な事 |
|---|---|---|---|
| アルファギーク | 最先端の技術に詳しいとんがったオタク。 優れたエンジニアでありたいという思いが強く知性と技術力を重んじている。 |
・自分が知っていることはどんな技術者も知っていて当然だと思っている ・こだわりが強い ・非技術系の職種の人達を嫌う |
・教える技術を磨いていくこと |
| プロセスツァー | 手順に異様にこだわる開発手法の信奉者 | ・問題の原因はプロセスに沿わなかったことだと思い込んでいる ・柔軟な対応や想定外の対応に弱い ・ツールへのこだわりが強い |
・プロセスやツールよりも個人との対話を大事にする ・ドキュメントよりも動くソフトウェアを重視する ・計画に従うことよりも変化への対応を重視する |
| イングループ | 自分たちが得意とする職務や技術を中心に据えてチームのアイデンティティを確立する | ・リーダーを失うともろさが露呈する ・外部の考えやアイデアには聞く耳を持たない ・組織全体にとって何が最善かを考えず行動する ・柔軟性に欠ける |
・会社の文化を理解することに全力を尽くし、その文化に沿った動きのできるチームを育て上げるにはどうすればよいかを考える。 |
いかがでしょう。少なからず当てはまっている箇所などないでしょうか。ただ仕事をしていく上ではこういったことは大事なことだとは思っていますがどれも行き過ぎてしまうと結果チームが崩壊してしまうマネジメントをすることになってしまう恐れがあるのだなということがわかりました。
いいエンジニアリングをしていくために
次に、いいエンジニアリングマネジメントをしていくうえで自分の中で大切だと思うことを考えてみました。
余裕を持つ
自分に余裕がなくなると視野や視点が狭くなります。
さらにマネジメントをするうえできちんと説明を行う余裕がなくなり雑になるため、たとえ忙しくてもいったん頭を空にして、目の前だけではなくその先も見据え何をしていけば自分や相手の作業が捗り易くなるかをきちんと考え行動する必要があります。
コミュニケーションの不確実性を理解する
システムを相手にしていても一緒に仕事が人間である以上コミュニケーションの齟齬は少なからず発生します。
社会学者のニクラス・ルーマンはコミュニケーションの不確実性が3つの不確実性から来ていることを論じています。
・他者理解の不確実性：人は他人や事象を完全には理解できない
・伝達の不確実性：コミュニケーションが到達するとは限らない
・成果の不確実性：仮に理解されたとしても予想されたように行動するとは限らない
たとえ仕事の依頼を他者にしたり受けたりしても見えている部分はほんの一部だと思っています。
そのため、きちんとした形でなくてもホウレンソウを行い自分の行っていることや相手が行っていることが互いの認識からずれていないかを時折確信していくことが重要だと思っています。
自己説得をさせるように心がける
自己説得とは、直接答えを言うのではなく、思考から盲点になっている部分を見つけ出させ自ら解決策に導く方法です。
これは時には部下になぜこの人は答えを言ってくれないんだろうと、わざと意地悪をしているのではないかと思われる可能性もありますが、言った事をそのままやるだけの人間になってしまうとそこから何も成長が生まれないと感じています。
質問によってどのように考えればよいか、現在の思考では何が足りないのか指し示し促していくことで次にとる行動を見つけさせていくことが大事だと考えています。
最後に
かなり雑になってしまいましたが最近色んな本を読む中で、自分がいかに未熟なのかを思い知らされながらも、新たな発見の楽しさと、どうすればより良いエンジニアリングマネジメントを行っていけるかというのを考えることが増えてきました。
まだまだ未熟ですがこれからもエンジニアが働きやすい会社にしていくため日々頑張っていきたいと思っています。
最後まで読んでいただきありがとうございました。