プログラミングの思想を活用してマネジメントに領域展開する

この記事はAteam LifeDesign Advent Calendar 2023の6日目記事です

はじめに

今まで、バックエンドエンジニアをしていた人間が
EMの役割を経験した際の気付きをまとめてみました。

EM(エンジニアリングマネージャー)とは

そもそもマネジメントとは

彼のドラッガーはマネジメントを以下のように定義しています

「組織をして成果を上げさせるための道具、機能、機関」
引用：明日を支配するもの

EMの領域について

その中でもEMの役割・領域は以下の４つで語られることが多いと思います。

• プロダクトマネジメント
• プロジェクトマネジメント
• ピープルマネジメント
• テクニカルマネジメント

そして、その全てを求める場合もあれば、
特定の領域に特化するケースなど、企業によって特色は様々です。

参考:

領域展開の難しさ

さて、ここからが本題です。

七海さんは領域展開を

私の到達できなかった呪術の極地
引用：呪術廻戦第30話

と表現しています。

役職として"EMになる"ということ自体はそんなに強力な
手段を手に入れることとは全然違いますが、

しっかりとマネジメントを理解・実現できるスキルを身につければ
エンジニア市場でも強力な武器になりますし、
そのためにはジョブチェンジと同じくらい難易度は高いと感じました。

何が難しいのか

中でもエンジニアがマネジメントに領域を広げる際に
課題になるのがピープルマネジメントだと思います。

とある、先輩社員がその難しさについて

エンジニアは普段システムを相手にしているから
人を相手にするのに慣れていない

と話していました。

確かに。

そこで、大抵の弱みは強みに変換できると思っている私は、

エンジニアは普段システムを相手にしているということは
そこで得た知見をピープルマネジメントにも活かせれば良いのでは。

そしてそれは他職能にない強み（領域に付与する術式）となると考えます。

活用できる術式（原則・考え方）

プログラミングで利用している原則や考え方の中で、
人や組織を扱うピープルマネジメントに使えそうなものをいくつか挙げます。

参考:

SOLID原則

言わずと知れた原則ですが
これを人や組織に当てはめると以下のような解釈ができます

• ▼単一責務
  • 人や組織でちゃんと役割分担をしましょう
  • 行動や指示の一つ一つに多くの目的を設定しない
• ▼開放閉鎖の原則
  • まわりのアドバイスはみんな聞きましょう
  • その上で、どう変わるべきかは自分・自チームで考えましょう
  • そのスタンスをメンバーにも求めましょう
• ▼リスコフの置換原則
  • チーム内で以下のようなことは、共通認識を持ちましょう
    • 他チームに対するコミュニケーション
    • "よくある事象"に対する振る舞い
      • 緊急時のレポートライン
      • チケットの進め方
      • 重要な情報の保存先..など
  • 誰かが休んでも他メンバーが入れるバックアップ体制を作りましょう
• ▼インターフェース分離の原則
  • ルールや方法を無闇に強要しないために
    • ルールなどは言語化してナレッジ化しましょう(人に依存させない)
    • なんとなく"みんなこうしてるから"で決めない、強い気持ち
    • 不要なルールは消したり変更できる状態を作りましょう
• ▼依存性逆転の原則
  • 自分・自チームを上位モジュールとすると
    • 他者や他チームに対して、どういう形や流れで質問やリクエストを投げて欲しいのか(インターフェース)を提供する
  • 自分・自チームを下位モジュールとすると
    • 他者や他チームが、どういう形や流れで質問やリクエストを投げて欲しいのか(インターフェース)を聴く

驚き最小の原則

この原則を組織や人に当てはめる場合は
新しいメンバーがオンボードを受けた時に
ギョッとしないか..ということかと思います。

• 一般名詞と全然違う意味の、社内・チームでの独自用語を作らない
• 誰も理由のわからないルールや業務を無くす
• 嘘をつかない・嘘のないナレッジ
  • 悪意がなくても、更新が遅れたナレッジなどは驚きにつながることがよくありますよね

など

DRY原則

処理が分散すると
保守が辛くなるのは人の処理も同じです

• 組織やプロジェクトに合わせて、意思決定者・意思決定機関は一つにする
• タスクやissueは一元管理する
• 人事的な評価者・評価機関を分散させない

ピープルマネジメントだけでなく、プロジェクト・プロダクトマネジメントにも重要ですね。

KISSの原則

(Keep It Simple, Stupid)

これはむしろ元々IT外から来た用語かもしれないですが、

• 複雑な管理や業務フローを設計しない

あれもしたい、これもしたい、という要望から
複雑化してしまいがちですが、
天才を除いて凡才の私たちはそんな複雑なものを作っても扱いきれません。

これはピープルマネジメントにおいても同じだと思います。

• 複雑な目標設定をしない・させない
• 組織はできるだけシンプルに、兼務も避ける

複雑でいろんなことができる人・組織を作っても
その組織を使いこなせるマネージャー・経営者は天才だけです。やめておきましょう。

YAGNI原則

(You ain't gonna need it)

• 無闇に人や組織を増やさない

ビジネスや会社のロードマップに対して
必要性をもとに設計しましょう

リファクタリングの手順

(原則では無いですが)

全く保守されていない関数があったとして、
リファクタリングを行うとなった場合、
大抵は以下のような流れでリファクタリングを進めるかと思います。

1. 要件の整理
   • そもそもこの関数で何を実現したかったのか
2. テスト配備
   • 期待する挙動を検証できる状態を作る
3. 内部修正
   • テストコードが通るようにコードを修正する

この流れは組織を変える場合やメンバーの入れ替わりが
発生した場合にも利用できます。

1. 要件の整理
   • 対象の組織・人が達成すべき目的の整理
     • 会社や周りから何を期待されていたのかのヒアリングや言語化
2. テスト配備
   • どんな指標やミッションを達成すれば、期待に応えられたと言えるか
     • 定量的な目標設定
3. 内部修正
   • 2を達成できる状態を維持しつつ、人や組織を変化させる

まとめ

処理や仕組み・データを体系立てて扱えるのは
エンジニアの強みです。

ただ、
ここまで「プログラミングの思想」を活用した考え方をまとめましたが、
もちろん、プログラムと人は全然違います。

相手が人であれば
感情や思いやりといった変数が必要です。
その大前提はある上で、
エンジニアがマネジメントに興味を持つキッカケや、
考え方の一つの参考になればと思います。

後書き

プログラムにおける原則や法則は、抽象的に捉えれば
処理や情報をどう扱うと「アンチパターンを踏まずに済むのか」
ということだと思います。

であれば、コンウェイの法則のように
組織とシステムは入れ替えて考えられる
と思ったのがこの記事を書いたキッカケでした。

こういう考え方もある、この法則も知っておくと良いよなど、
ご意見・ご質問あればコメントお待ちしております。

また、こういった記事を通してEMの方と繋がれたら嬉しいです。
読んでいただき、ありがとうございました。