エンジニアからみるマネジメント基礎 - 第1回 管理の基礎
キャリアを積んでくるとマネジメントに真剣に向き合うときがくるかと思います。
先日、外部の「マネジメント基礎」研修に参加してきまして、勉強になったので、まずはアウトプットして受講内容をまとめて、WEBエンジニアマネージャー（私）の視点で考察して、自らの定着を図ろうと思います。
では教科書に則って、以下の全７回に分けてまとめていきます。
- 管理の基礎 ← 今回はここ
- 仕事の管理
- 改善と問題解決
- 人間行動の理解
- 部下の育成
- よい職場つくり
- 管理者の自己啓発
第1回 管理の基礎
1.1 管理とは
- 組織や職場の目標を達成するために（目的）
- 人・物・金などの資源を（対象）
- 効果的・効率的に活用することである（方法）
管理対象に人が含まれるということから、管理とは「人（部下）を通して仕事の成果を上げること」ということになります。
エンジニアマネージャーとして
WEBサービスを顧客に提供するために(目的)、チームメンバー(部下)と開発コストと運用コスト(費用)を使って、サービスをリリースする。
開発コストはメンバーの人件費を除けば、オフィス賃料、IDEのライセンス代金、開発用AWS費用、開発用PC、電気代などなど。
運用コストはサーバー費用や、運用者、監視ツールの費用などが当てはまるでしょう。
1.1.1 管理者の立場
トップ（経営者）→ミドル（中級管理者）→ロワー（初級管理者）→一般社員
という階層に分類される。
エンジニアマネージャーとして
ミドルからは開発メンバーに直接指示出しをできなくなり、格段にマネジメントの難しさが上がります。
ミドルでは直接ソース書いて、マージするということがしずらくなるでしょう。ロワーの段階では直接メンバーに指示を出したり、自らチケットを捌いたりなど、プレイングマネージャーとして働くことがしやすいと思います。
マネジメント職に進みたくないというエンジニアも多いですが、ロワーまでは技術指向のエンジニアでもやってくれるのではないかと思います。チームメンバーを３〜５人くらい持つイメージです。ですが、ミドルまで上がれと言われると嫌がるエンジニアは多いのではないでしょうか。強引にマネジメント職を押し付けると退職するエンジニアも多いと思うので、本人のキャリアとしっかり向き合いながら管理職を依頼しましょう。
また一方で管理職にならなくても、会社で出世していける道（エキスパートや、フェローなど）を用意しないと技術に優れたエンジニアは定着しませんので注意です。1人の優秀なエンジニアは10人の凡才なエンジニアに勝ります。それがエンジニア職の世界です。
1.1.2 管理者の役割
組織の要請と個人の欲求を調査させ統合させることが基本的な管理者の任務になる。
役割は大きくわけて仕事の側面と、人の側面にわかれます。
仕事の側面
- 仕事の管理
仕事の計画を立て、部下に仕事の割当をし、司令し、統制するという一連の仕事。円滑に勧めるために調整が必要となる。
- 仕事の改善
問題点を発見し、改善していくこと
エンジニアマネージャーとして
開発計画策定や、スクラムの運営、チケット割り振り、進捗管理などが「仕事の管理」にあたります。リファクタリングや、アーキテクチャーの改善、CI/CD導入などは「仕事の改善」にあたります。ですが、仕事の改善も常に意識していれば「仕事の管理」に含まれていくものだと思います。
エンジニアは面倒なことを嫌う人種なので、「仕事の改善」は常にしていく生き物ですし、それを高レベルでし続けられるエンジニアが尊敬されるエンジニアだと思います。逆に、仕事の改善をさせてくれない組織からは、そのようなエンジニアは離れていくでしょう（プロセスを変更できない、リファクタをさせてくれない、便利ツールを導入させてくれないのように）。
人の側面
- 人間関係
部下のやる気をおこさせて、職場としていいチームを作っていくこと
- 部下の育成
部下の能力を啓発し、育成すること
エンジニアマネージャーとして
チケットのは、部下の技術的指向や、キャリアも加味しながらアサインしないといけないでしょう。
たとえ、古いプロダクトで新技術を導入するのが困難だった場合でも、周辺ツール開発にはまだ新技術を導入する余地が残されていると思います。
そこを見つけて計画から差し込んでいきましょう。古いプロダクトのメンテナンスだけでは、エンジニアは腐ってしまいます。
エンジニアは仕事の側面というよりは、人の側面で辞める人の方が多いような気がします。転職が容易な業界だからこそ、人の側面に寄り添わなければなりませんし、ここを意識してマネジメントしないといけません。
1.1.3 管理者の心構え
原理原則の尊重
先達のノウハウを尊重しよう
エンジニアマネージャーとして
エンジニアでも、開発思想を学ぶのと同じようにマネジメント論についても、学びましょうということです。目をつぶってはいけません。
ここ数年有名な「Googleで最高のマネジャーになるための8つの習慣」に記載されていることも、今回マネジメント基礎を学んだら、結構当たり前のことを書いてあることに気づきました。ですが、Googleはこれを科学的に検証してくれたとのことで、説得力が上がりましたね。最後にはこの８つの習慣を勉強したことに当てはめてみたいと思いますので、お楽しみに。
科学的接近
常に目的を明らかにして、事実を基に本質に迫る
エンジニアマネージャーとして
これは職業柄、みんな自然とできていることかなと思います。人間を信用していないのもありますね笑
いつも証拠（ソース）を求めますし、手に入れた証拠はドヤ顔で説明しますよね。私もやります。
原価意識
効率 = アウトプット / インプット
エンジニアマネージャーとして
ここは難しい問題です。エンジニアとしては生産性ということになるかもしれませんが、何をもってして「生産性が高い」「生産性が低い」と言えるのでしょうか。
捌いたチケットの数？機能数？バグの修正数？どれをとっても説得力に欠けますね。とはいえ、厳格に管理しようとするとエンジニアは離反しますね。
そもそも機能をたくさん作ったら生産性は高いのでしょうかね？プロダクトの売上には開発した機能数は影響あるのでしょうか？
今回の記事ではこの考察はしませんが、マネージャーとしてはなんらかの解を頭に持っておく必要があるのかと思います。
個人的にもここ２〜３年のテーマは生産性です。
健全な判断
自分の経験や感覚だけに捕われず、幅広い知識や、理念に基づき判断すること
エンジニアマネージャーとして
どのような機能を追加しようか、どのように優先順位をつけようか、技術的負債を溜めてでも最短で実装するか、どの言語やフレームワークを選択するか、アーキテクチャーをどれにするか。1つのサービスをリリースするまでに、技術的な観点だけでも判断しなければならないことは山のようにあります。マネージャー自身が過去に使ったことがあるという理由だけで技術的選択をし続けていませんか？
技術的な知見を増やし続け、思想を学び続け、常に自身をアップデートした上で判断をしなければなりませんね。言っておきながら耳が痛いです。
人間性の尊重
部下１人ひとりの能力を最大限に引き出し、成長させること
エンジニアマネージャーとして
ちゃんと技術の幅が広がるようにタスクを振り分けていますか？でないとメンバーは永遠にジュニアから抜け出せません。
メンバーに様々なタスクを降って個性を引き出し成長させることが、マネージャーのもっとも重要な任務と言っても過言でもありません。
昔、できない新人を必死に指導して成長した結果、高給で転職していった部下がいました。非常に感謝されました。この業界これでいいんだなと思います（泣）
1.2 管理と組織
1.2.1組織が持つべき要件
- 共通の目標を持っていること
- 協働の意欲があること
- コミュニケーションがよいこと
エンジニアマネージャーとして
特に目標が大事だと思います。技術スタックも込みで、プロダクトを将来どうしていきたいのかについて、熱く語れるマネージャーに付いていきたいなと私は思います。ですので、マネージャーは語れるだけのものを持たなければなりません。
1.2.2 組織運営上の原則
司令系統の統一
直接司令監督する上司は１人、司令・報告は決められた司令系統を通じて行われること
エンジニアマネージャーとして
明確な指示は直属の上司からのみ来るのが理想ですね。飛び越えたりしてしまうと、メンバーは混乱します。「言っていることが違う」と。
以外と簡単ではないのかなと思いますが、管理者としては自分のチームに他のチームから指示が来ている場合には、少なくともきちんと把握しておく必要があります。
統制範囲の限界
管理者が直接管理する人数は適量であること
エンジニアマネージャーとして
マイクロサービス的には、2枚のピザを分け合えれるくらいが理想とされています。個人的にはマネージャー含めて、1チームは少なくて４人、多くて８人と考えています。少なすぎるとチーム内で相談相手がいません。多すぎると、中をさらに割る必要が出てきます。
合理的職務割当
特定個人に割当、具体的、重複させない、適量な割当をすること
エンジニアマネージャーとして
重複させないというのは難しいケースもあるかなと思います。1チケットが1開発者の中に収まらないケースはよくあります。
1つのチケットを終わらすのに、実装範囲影響範囲、実装方法などを決定するのにチーム内だけではなく、チーム外にも相談しなければいけない場合もあります。
重複しなければ、それらの決定は担当者自身の中に収まるでしょう（もちろんチーム内ではレビューするとして）。しかし実装範囲が多方面（デザイン、フロント、バック、DB、はたまたアーキテクチャー）に広がる場合には、１人でやりきるのは難しいですね。
では、人の役割をデザイン担当、フロント担当、バック担当、DB層担当、インフラ担当とはっきり分けた場合にはどうでしょうか。重複をなくすために、1つのチケットについて皆で話し合い、詳細な設計をしながら子チケットを作り、インターフェースの整合性を取り…とやっていったら非常に生産性が悪くなりますね。
私が好む方法は、4人くらいのグループを作り、大きめのチケットをグループに割り当てます。そのチームはみんなのスキルを合わせれば多方面をカバーできるように構成します。機能横断型のチーム構成と言われます。アジャイル開発で用いられる方法ですね。
こうすることにより、お互いの苦手分野をカバーしながら開発を進めていけます。1チケットに関わる人が多くなればなるほど、問題が増えるのは皆様経験済みでしょう。
1.2.3 責任と権限
- 自由裁量の幅
- 創意工夫の余地
仕事には達成しなければならない責任と、達成したら報告する義務、およびそれを遂行するのに必要な力としての権限がともなう
エンジニアマネージャーとして
エンジニアにとって、権限と言われると思い浮かべるのは「実装方法」や「技術選定」などではないでしょうか。逆に言えばこの２つとも決定権がないと、ただのコーダーって感じです。
ではこの権限をジュニアエンジニアに与えるかと言われると難しいですね。権限を渡した振りしておきながら、シニアからのレビューの嵐を受けては、決定権はないに等しいでしょう。
では私が部下だったらやる気がなくなるのかといえば、以外とそうでもないです。「この案件を、技術選定から考えて実装してください」と言われたらレビューの嵐になったといえども嬉しいですね。
どの技術にしようかということを研究検証できるのは、エンジニアにとってかなり楽しいですし、とても成長できるチャンスです。VueにするかReactにするか…。TypeScriptは…
ですので、技術を研究検証できる機会は部下にたくさん与えて上げてください。
そして管理者自身のスキル・知識を超えるような提案を持ってきたら、はにかんで「お前の自由にしていいよ」と真の権限を上げましょう。このときがマネージャーとして至福のときではないでしょうか。
1.2.4 ラインとスタッフ
直接収益に貢献する部門をライン、ライン長に助言するような部門をスタッフ
エンジニアマネージャーとして
普段開発部門にいると、経理部門や人事部門の人と接する機会はすくないのではないでしょうか。彼らがいないと会社が会社として機能しません。
もしメンバーが彼らのことを「稼いでないのにめんどくさいルールばかり押し付けて」など考えているようなら、なぜ彼らがそのようなルールを決めているかを教えてあげましょう。
開発にだけ専念できているのは、間接部門がいるからです。職責が上がれば上がるほど間接部門とやりとりする機会も増えるでしょうが、そうでないメンバーにとっては遠い存在です。会社というものの仕組みを教えるのも管理者の仕事です。
ちなみに、間接部門が決めたルールに管理者自身も不満があるなら、そのルールを変えるべく動きましょう。権力闘争しているような組織でなければ、合理的な提案なら受け入れてくれるはずです。
ただし根回しは忘れずに。それも管理者の腕の見せどころです。
1.2.5 多様化する組織形態
エンジニアマネージャーとして
事業部制を採用していながらも、ある程度会社が成長してくると、開発部門だけ独立させるという会社は多いのではないでしょうか。例えば、A事業部、B事業部、開発部となっており、開発部の中ではA事業とB事業のサービスの開発を行うなどのような場合です。
この場合には、事業そのものと開発の距離が空くので、意思疎通に時間がかかりますし、「営業はいつも無理難題を言ってくる」「開発は営業のリクエストを聞いてくれない」などの不満に繋がりやすいでしょう。これは事業部のトップと開発部門のトップが違うので、指示系統が違うことから発生すると思います。その一方で、開発メンバーからすれば開発部長が最終的な意思決定をしてくれますし、技術にも詳しいですし、部としての開発人員数もいるので工数の融通がきき、技術交流もしやすいなどメリットもあります。
では一方、A事業部内に、A事業の専用の開発課を持ったらどうなるでしょうか。営業と開発の意思疎通は格段に早くなるでしょうし、営業が望む機能を迅速にリリースできるかと思います。ですが、開発部より小さくなったA事業部開発課の開発メンバーはどうでしょうか。彼らは技術をわかってくれない事業部長に苛立ち、相談できる開発部長もおらず、孤独になるかもしれません。エンジニアにとって、技術を理解してくれない上司というのは忌避する傾向にあります。なぜなら自分たちを正当に評価できないからです。
どちらも一長一短ですし、事業部長のレベルや、プロダクトフェーズにもよります。メリットが大きい方を選択し、デメリットは別にカバーできる体制を気づきながら組織形態を考えなければいけないですね。またそれに意見していかなければならないのも我々管理者だということです。
以上、第1回管理の基礎でした。
