エンジニアのためのマネジメントキャリアパスに学ぶ、意思決定と委任とは（連載第22回/25回）

# 前回の記事
https://qiita.com/rf_p/items/6c400d06e9fb2c1b9001

# 連載の構成
- この記事は、[マネジメントについて一人で考える Advent Calendar 2022](https://qiita.com/advent-calendar/2022/management-solo)の連載記事です
    - 1記事目から読んでいただいても良いですし、気になる記事から読んでいただいても問題ありません
- 全25回分の構成は、次の通りです
    - 第1〜6回：ドラッカーの『マネジメント』を中心に解説します
    - 第7〜13回：『図解人材マネジメント入門』を中心に解説します
    - 第14〜22回：『エンジニアのためのマネジメントキャリアパス』を中心に解説します
    - 第23〜25回：私の経験談を中心に、まとめに入ります

# 意思決定と委任
- 書籍引用しながら書く記事は、この連載では最後となります
- 最後のテーマは、意思決定と委任です
- エンジニアリングマネージャー(EM)と働いていると、どうあっても時間が足りなくなっていきます
    - 前回の記事で、重要度と緊急度のお話はしました
    - しかし、どう考えても重要度が高い案件でさえ捌ききれなくなることがあります
    - その際に取るべき手段として挙げられるのは、主に次の2つでしょう
        - やらないと決める
        - もしくは委任する

# 委任するか自分でやるか

> |    |  頻繁  |  頻繁でない  |
> | ---- | ---- | ---- |
> |  単純  |  委任  |  自分でやる  |
> |  複雑  |  （慎重に）委任  |  訓練目的で委任  |

> 引用：[エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド](https://www.amazon.co.jp/dp/4873118484)

- それぞれのカテゴリについてですが、ざっくりと次の通りです
    - 頻繁で単純
        - 定例ミーティング準備等
        - これは委任
    - 頻繁でない単純
        - カンファレンスチケットの手配等
        - これは自分でやる
    - 頻繁でない複雑
        - 人員計画を立てる等
        - これは訓練目的で委任
    - 頻繁で複雑
        - システム障害のまとめ等
        - 自走できる組織とするために委任
- 特に注目すべきなのは、複雑な業務でしょう
    - 複雑がゆえに「自分しかできない」「自分でやった方が早い」となりがちです
    - 手順をドキュメントに落としたり、口頭で説明するのにも骨が折れます
    - ですがここを疎かにすると、EMに依存した組織となってしまいます
        - 次のEMが生まれづらいですし、長期休暇になった途端、業務が崩壊します
    - 表を見て分かる通り、カテゴリ上、3/4は『委任』です
    - EMがどんどん委任して新たな仕事に挑戦しない限り、EM自身だけでなく、後輩も成長が鈍化します
    - いかに委任できるかは、非常に重要です

# root(admin)権限をいつ委任するか
- 業務を委任するにあたり、慎重に考えるべきこととして"root(admin)権限"があります
    - 例えばAWS Consoleだったり、本番機のroot権限等です
- 一歩間違えればシステム障害に繋がりますし、悪意あるスタッフに渡した場合は情報漏洩や改竄等も起きるでしょう
- となると、やはり他業務とは一線を画す、単純にどんどん委任とはいかない権限・業務です
- ここに関しては、次の2つが関係してくるでしょう
    - ITエンジニアとしてのスキル
    - 人としての信用・信頼
- それらが欠けていたことを考えてみます
- もしITエンジニアとしてのスキルが欠けていたら…
    - 本番インスタンスを誤って落としてしまったら？
        - そして、その復旧手順が分からないとしたら？
        - 事業に与えるインパクトは時間の経過と共に膨らみます
- もし人としての信用・信頼が欠けていたら…
    - システムのアラートがバンバン飛んでいるのに、我関せずを貫く人だとしたら？
        - この場合も、事業に大きな影響を与えてしまうでしょう
    - また、不正行為をしたり、それを隠蔽するかもしれません
        - 最悪の場合、会社ごと無くなる原因に繋がりかねないです
- ジレンマになりやすいのは、権限を得てからでしか学べないことが多い点でしょう
    - 扱うシステムの規模が大きければ大きいほど、個人学習では限界があります
        - 冗長化をどのように実現しているか等
    - ここに関しては
        - 個人で学習し、徐々に難易度を上げていく
        - 小規模なサービスからまずは委任し、徐々に中・大規模を委任する
    - といった方法になってくるのではないでしょうか
- フロントエンドやバックエンドは、コードレビュー段階で指摘され、大事故に繋がる可能性は低いです
    - しかしインフラ領域はワンオペや属人化に陥りやすく、Terraform等でコード化されていないと余計に大変です
- そのため、状況によっては焦って委任せず、仕組みを整えるのが先になる場合もあるでしょう

# 丸投げにならないよう
- さて、ここまで委任について考えてきました
- 最後に注意すべきなのは、委任の仕方です
- あくまでも委任であり、 **丸投げにならないよう注意** しましょう
- 重要なのは、
    - 目的を伝えること
    - なぜ任せたいのか伝えること
    - 放置しないこと
    - です
- まず、目的を伝えるのが何より重要です
    - この仕事はどういう意味があって、なぜやる必要があるのか？という点です
    - ここがしっかり説明できないのであれば、まずはEM自身が目的を明確にすべきです
    - 明確にできないよくわからない業務であれば、そもそも委任せずに無くす判断も必要です
- 次に、なぜ任せたいのか伝えることです
    - 「面倒だから」とか「とにかくやれ」ではなく、どういう経験やスキルを身に着けてほしいのか伝えるべきです
    - ここを疎かにすると不満が溜まりますし、重要度が伝わらず適当にこなされてしまう可能性があります
- 放置しないことも重要です
    - 任せた以上、責任を放棄してはいけません
    - 失敗したらそのフォローをしたり、進捗が悪そうであれば声をかける等、最初のうちはしっかり見ている必要があります
- 改めてマネジメントという言葉を振り返りますが、"マネジメントとはなんとかすること"です
    - こういった細かな気配りが、何よりも重要です

# 最後に
- さて、長い連載も残りわずかです
- 最初に書いた通り、書籍をメインに扱う解説記事は以上です
- 次回から最後の3記事は、私自身のポエム的な内容、今回の連載のまとめ等に入っていきます

# 次の記事
https://qiita.com/rf_p/items/3fdb2397e3f5647554b9

- 連載記事一覧
    - [マネジメントについて一人で考える Advent Calendar 2022](https://qiita.com/advent-calendar/2022/management-solo)