エンジニアとマネジメントと私

この記事はエキサイトAdvent Calendar 2017の5日目の記事です。

エンジニアの皆さんにこの職種を選んだ理由を尋ねると、決まって純粋に開発がしたい、ものづくりがしたい、技術で食べていきたい、などのいかにもエンジニアらしい答えが返ってくるものと思います。そんなエンジニアも組織に属して、ある程度経験を積んだところで「マネジメント」という言葉をちらほら耳にするようになってくる訳です。
当初からマネジメントを目標にしていたわけではないエンジニアにとっては、「マネジメント」にあまり良い印象はもたないのではないでしょうか。私もその中の1人なのですが、なんだかんだで、どうにかこうにか私なりの考え方が収束してきたので、どう向き合ってきたのか少しだけまとめさせてもらおうと思います。

マネジメントする人、される人それぞれに一例として興味を持っていただけるとうれしいです。

そもそもエンジニアのマネージャーって

組織や企業により様々だと思いますが、一般的に期待されるであろうコトをあげてみます。
弊社の場合がベースになっていますが、以下に挙げるものはそんなに違和感はないものと思います。

• 規模として10名未満の開発者のマネジメント（評価含む）を受け持つ
• 一つ以上のサービス（プロダクト）の運用または開発をコントロールする
• 既存の運用に限らず新規開発も行い、場合によっては技術支援のみ、または外注コントロールなども行う
• 所属メンバーのリソース管理、スケジュール管理、育成などなど

ざっくりと定義すると、期待されることはこのような感じでしょうか。
なにか書き出しただけでもうおなかいっぱいですね。
弊社の場合はセクションというエンジニアのチームをマネジメントする人がそれにあたり、セクションマネージャーと呼んでいます。

マネージャーに期待されることとして列挙してみましたが、こうしてみてもエンジニアだからという特徴は実のところそれほどないと思います。強いて言うのであれば、エンジニアを組織するので、評価や管理にはエンジニアとしてのスキルが当然のごとく必要というところでしょうか。そしてこのマネジメントってやつは経験するとすぐに理解出来ると思うのですが、教えてもらってその通りにできる訳もなく試行錯誤したあげく、なんだかやたらと時間を奪われているというマイナスイメージだけが残ります。

ですが、自分なりのやり方が見つかると、幸せになれます（たぶん）。
次からは私がなにを指針として行動しているのかをあげていきますので、もうしばらくマネジメントに対する負の感情を抑えてご覧ください。

偉くなったわけではないことを自覚し、素直でいる

変なプライドをもったマネージャほど、面倒な人はいないはずです。
不幸にもそんなマネージャをもった経験がある人もまた少なくはないでしょう。ちなみに、圧倒的なパワーで支配する（できる）自信がある人は、この話は無視してそのまま突き抜けることをおすすめします。

怠ると以下のような事が起こりがち

• 信頼関係がゆるやかに崩壊する
• 適切な報連相の機会が失われる
• コミュニケーションの場からも疎遠になる（主にマネージャーが）
• 面倒な人対処法という無駄なスキルが伸びるメンバーが誕生

質問や疑問、時には指摘などいろいろな問いかけがマネージャーによせられます。全て自分で解決する必要はなく、何かしらのアクションをもって行動することが今後の関係にも影響します。
当たり前といってしまえばそれまでなんですが、大事なのはそのときごまかしたり、うやむやにしないということだと考えています。偉いからとか偉くないからというのは言葉のあやであればよいですが、本気でそれが全てと思っているひともまれにいるので気をつけてください。それはメンバーにも理解してもらう必要があるかもしれません。

不向きな環境 or マネジメントタイプ

• 近接パワー型(技術力)マネージャー
• 超絶カリスママネージャー

情報格差というものをよく理解する

立場として上位組織と関わることが多くなると、自然とメンバーとの間に情報格差が生まれてきます。
情報が集まれば集まるほど、その格差に気づきにくいということがあると実感したこともあります。温度差を感じたときは特に要注意です。

怠ると以下のようなコトが起こりがち

• 組織目標、プロジェクトの本質などを見失う
• 意図をくみ取ることができなくなる
• 考えることをやめる
• マネージャー以上にステキな発想が出来るメンバーが埋没

共有とは一言一句同じ情報を伝えることではないとおもいます。
その場の空気感やニュアンスが情報として欠落しがちで、どう理解して欲しいか考えて加工したり要点を絞らないとダメです。伝わりかたが少し違うだけで、プロジェクトの戦略やビジョンが十分に伝わらずおかしなことになったりするので、地味に注意が必要です。
特に自立した能動的に動けるチームを目指す場合は、自分のコピーを作るぐらいの気持ちでもよいかも知れません。ある程度同じ情報を持っていないと、同じ方向性で物事を考えるのは難しいということです。

不向きな環境 or マネジメントタイプ

• 完全なる作業員を構成する独裁マネージャー
• 完璧な仕様が提供される、恵まれた環境のマネージャー

非エンジニア、またはチームの外からの見え方も意識する

情報格差はチーム間や、職種間でも表面化していきます。
チームの状況を正しく把握して外に対して発信する、伝える相手にあわせてわかりやすく共有するというのも大事なことだと考えています。ボスマネジメントをする、という観点からみても重要です。

怠ると以下のようなことが起こりがち

• エンジニアの進捗、言動に不信感をもたれる
• 助力を得る機会を失う
• 気づくと冷戦がはじまっていたりする
• 表舞台に出ないよい仕事をしているメンバーが埋没する

弊社のように一つのサービスに対し、様々な職種が協力し合って業務を進める場合お互いの理解と協力が必要です。本来強みとして働く部分ですが、あっというまに最大の弱点になってしまうので気をつけます。建設的なやりとりをするためにも受発注の関係ではなく、「得意とすることが違うだけ」ぐらいの関係値をめざしたいところです。
エンジニアのやっていることは、分からない人には本当に分からないようです。勉強しろというのはもちろんですが、その前に適切な状況報告はしておきましょう。また、組織の内側ばかりに気を配っていてもどうにもならないときもあるので、周囲の協力を得るため良いときも悪いときも日頃から発信しておいた方がよいと思います。

不向きな環境 or マネジメントタイプ

• 特命秘密組織に属するマネージャー

全ては自分のために行動する

はい、唐突にエゴの塊です。

きれい事はここまでです。
しかし誤解されると困るので先に述べておくと、組織の一員としてコンプライアンスを守り、他の不利益になるような突飛なことはしません。私の場合は冒頭で述べたようにエンジニアという職種で楽しみたいわけですから、そのための環境作りに注力します。

怠ると以下のようなコトが起こりがち

• 何のためにエンジニアをしていたのか分からなくなる
• エンジニアではないと言われる
• アイデンティティの崩壊
• エンジニアでない人にマネジメントされるメンバーが不幸になる（とおもう）

いくつかあげましたが、私にとって指針の八割はこれです。
マネジメントを任されると開発が出来なくなると言われているのは完全に間違いとはいいませんが、正しいとも思えません。仮に何かのスペシャリストを目指すのであれば、マネジメントは重荷に感じると思います。
なので、スペシャリストとしての道筋を見いだしていて努力する方向性がしっかり固まっている人は全力でマネジメントを避けることをおすすめします。しかしマネジメントを避けることができたとしてもスペシャリストと評価されるスキルと実績はそう簡単には身につかないということも覚えておいてください。

まとまった時間は取りづらくなりますが、別のものを獲得するチャンスも増えると前向きにとらえることもできます。欲しい物、利用したい物のために予算を確保したり、時には残念な企画が始動することを未然に防いだり、自らの思いつきを形にしてリリースすることもやりやすくなるでしょう。
自らが開発したい、設計したい、実装したいがあればそういうスケジュールを組めるように試行錯誤します。
それは自分が今後本当に突き詰めたい物を見つけるための機会の創出と考えています。

不向きな環境 or マネジメントタイプ

• 自己犠牲をテーマにしているマネージャ

終わりに

いかがでしょうか、マネジメントに対する負の感情に変化はありましたか。
嫌々やるマネージャーより、多少スキルが劣っていても前向きな気持ちで取り組むマネージャーはとても価値があるものだと思います。やることが増える。時間が無くなる。だけでなく上手くコントロールして出来ることもあると、少しの期待をもっていただけたらうれしいです。

結局心持ちの話だけになってしまいましたが、先人たちが築き上げた様々な手法があるのでまず実践してみるというのが一番です。注意すべき点は、読むだけ、理解するだけはまったくの無意味です。実践して適合するか判断しないとなにもわかりません。

というわけで、賛同される方は少ないと思いますがただのエゴイストだと陰口を叩かれないようによりいっそう精進したいと思います。