エンジニアリングマネージャを支援する


:::note info
[LITALICO Advent Calendar 2022](https://qiita.com/advent-calendar/2022/litalico) 18日目の記事です
:::

こんにちは、LITALICOの福田です。障害者向けウェブサービスの4つの事業/プロダクトを支える30人ほどのエンジニアをマネジメントしています。
私自身は昨年10月にLITALICOに参画し、約1年が経過しました。この1年を振り返ると、エンジニアリングマネージャを支援することに多くの時間を割いてきたなぁということに思い当たり、今日はそれについて書いてみます。

# 弊社の環境

本稿で触れるエンジニアリングマネジメントにまつわる周辺環境は、以下のような所です。

* 担当事業は、新規事業が多い。各事業ごとに、成長ステージ、市場ドメイン、事業経営スタイルが異なる。事業部全体で約40-50人くらい。エンジニアリングは、プロダクト開発だけでなく事業全体をカバーしている。
* 各事業ごとに、だいたい5~10名ほどのエンジニアが在籍し、1-2名のエンジニアリングマネージャが配置。チーム在籍の平均年数は2-3年ほど。フルサイクル型で、グループ内でほぼ全業務を完結させる。プロダクトマネージャ、デザイナーと共に、開発チームが組成される。
* エンジニアリングマネージャは、プロダクト、エンジニアリング、ピープル、テクニカルのマネジメントを担当。予算策定などの事業関連も行う。ジョブディスクリプションをきっちり引いて役割分担というより、マネジメント的な役割を1人に集中させるタイプです。

# エンジニアリングマネージャを支援するとは？

各グループのエンジニアリングマネージャと部門長は、組織構成上は縦ラインに該当するので、マネジメントする・マネジメントされる関係性です。
一方、各事業による違いが大きく、各事業・プロダクトにおける最適解も異なる為、グループのエンジニアリングマネージャが担当範囲で自ら考え運営していく事が求められます。
そのため、部門長の立場からは、単なるラインマネジメントだけでなく、エンジニアリングマネージャを支援するという概念を併せ持つようにしています。
(弊社では、エンジニアリングマネージャのことを、単にマネージャ、マネジメントと呼んでる事が多いので、以下の記載もそちらで統一します)

# マネージャと環境の相互作用を理解しよう

支援するとなった時に、まず最初に何から始めるのがよいのでしょうか？
参考になるのが、「障害は、個と環境の相互作用から生まれる」(https://junior.litalico.jp/about/education/ )という、発達障害のお子様を支援する「LITALICOジュニア」でも採用してるアプローチです。この構図は、マネージャにとっても当てはまるところが多いなと思い、勝手な解釈で援用させてもらいました。其の図がこちらです。

![アドカレ用 (2).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2985474/963c5916-0b03-2260-f1ed-9ba6822e4887.png)

図にある、「マネージャの特性」と「マネージャのスキル」と「取り巻く仕事環境」は、様々な情報から構成されますが、理解や準備が不十分な状態のまま支援を始めるケースは、仕事の現場では少なからず起きてしまってるのではないでしょうか。

- 不十分になりがちな一例
    - マネージャのこれまでのキャリアを知っているか？
    - マネージャの人となりや仕事上での振る舞いを知っているか？
    - マネージャのスキルの広さと深さは、どれくらい？ 求めるポジションに依存しない、強み・弱みは知っているか？
    - マネージャを取り巻く、部門、事業部、メンバー、事業ドメイン、技術、業界、など(広義の)ステークホルダーがどんなものかを把握しているか？
    - マネージャが何に困っているかを把握できているか？

マネージャの特性が仕事環境と合ってなかったり、スキルが足りない中で奮闘するも周囲からのサポートが足りてなかったり、そういうGapがマネージャ配置には付き物です。むしろ何の問題も無い配置を目にする方が稀です。
なので、Gapあるのが当たり前と捉えて、Gapが生まれやすい歪みはどこから出てきてるのだろうという事に関心を寄せましょう。
次の項で取り上げる思考に比べて、この図で取り上げてる要素は、知るためのハードルが低い事ので、情報が欠けている箇所があるなら、早めに補うようにしましょう。

仕事の中での作り上げていく関係性なので、お互いに理解しきってから業務をスタートできるなんてことは、現実ありえないです。折に触れ気になったら掴みにいくというのは大切にしつつ、徐々に理解のカバレッジは上げていきましょう。

# マネージャの思考を辿ろう

マネージャは自律的に行動するために、思考することが仕事というポジションです。なので、マネージャ支援に向けて思考を理解するのは不可欠です。
とはいえ、マネージャは、長い社会人経験での実績を元にお任せしてる事が多く、この思考の量は膨大になり、支援する側から把握するにも、一筋縄ではいきません。
そのために、私の場合、以下のようなスタイルで「書き出し」をやってもらう事が多いです。書き出しを、簡単に図解しました。

![アドカレ用 (1).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2985474/48d245ee-2974-ef78-7e39-f622fbf3baa7.png)

#### 図の説明
* 行の方向が、マネージャが取り扱う各テーマです。
  * テーマは、図に記載したようなラインナップを使うことが多いです。もしマネージャやグループでこれまで使ってきたものがあれば、そちらを活用する事もあります。
* 列の方向が、過去、現在、未来という時間軸を表します。
  * 例では、半年を境目に見てますが、事業/プロダクト/グループのこれまでの時間軸に合わせて調整します。長い歴史がある場合、過去を段階的にするのも良い方法だと思います。
  * 逆に、未来は、粗い時間軸で十分です。緻密に書いても、だいたい変わる為、頑張りすぎないのが吉です。
* 各セルは、それぞれのセルに思考を全て書き出す。
  * 目安は、「アタマの中を書き出す為に、もう書けないところまで書く」 。ここは、気合と根性です笑
  * セルの中身は、構成、MECE、質、事実と思考の仕分け、は、最初は気にしないです。キレイな結論を書くことが目的ではなく、マネージャの今の思考が知りたいからです。
* それぞれに根拠(数値、発表、資料リンクなど)をできるだけ付けるようにしましょう。
  * 思考が感覚的なものか事実をベースにしてるかは区別できるならしておきたい為です。
* 現在→過去→未来の順に書くのが書きやすいのでオススメです。
  - 現在 -> 今ある事実を洗いざらい書く
  - 過去 -> 現在の事実が生まれた因果を書く
  - 未来 -> 過去から現在を踏まえて、想像して書く
* セルは、全てを一気にやる必要は必ずしもありません。
  * 「行単位で見て、問題が大きそうなところからやる」「未来は考えにくいので、現在と過去だけとりあえずやってみるか」、はありですし、よくそうしてます。

この図は、全体を一気に埋めるより、都度必要な部分に切り出して使っています。
マネージャ自身が書き出すことによって初めて自分の思考を理解するケースもあるので、一石二鳥です。(手間も時間も掛かるので、無理やりそう捉えています)

正しくor広く考えられているかより、どう考えてきたのか？またどこまで考えているのかを掴むことを狙いとしています。
マネージャが各テーマについて、どんな事実を見ていて、どう解釈・思考しているのかを辿れるようになればOKです。
この分析後に「彼だったら、この場面だったら、絶対●●●って言うだろうな」のような(脳内)再現が少しずつできるようになるといいと思います。


# マネージャが考え続けることを後押しする

書き出しまで済むと、あとは対話を通じて思考を積み重ね、仮説を磨き、行動で検証していきます。いわゆるPDCA型の検証です。
各テーマごとに、週次の1on1でモニタリングと対話をしつつ、ひたすら検証ループを回します。サイクルは週だったり3ヶ月だったりテーマにより様々です。

ここまでは支援側とマネージャとの協働でしたが、ここからはマネージャによる活動が主で、支援側がサポートに回ります。
サポートする際に大切にしているのは、マネージャの流儀を踏まえることです。
丁寧なお手本を見せれば良いタイプ、共感が欲しいタイプ、課題の明示が欲しいタイプ、機会だけ与えれば良いタイプなど、様々な流儀があるので、そこに合わせて接していきます。
支援側におすすめの方法があるとしても、それはサンプルとして提示するに留め、マネージャの流儀を尊重するようにしています。
緊急かつ重要な問題が発生している場合は例外ですが、そうでも無い場合、効率的なソリューションを最速で適用して問題解決することより、試行錯誤するプロセスを挟む方が、半年で見ると伸びが大きいと感じています。

ただ、流儀に合わせるだけで上手くいかないこともあり、以下のポイントは見守り続けるようにしています。

* 小さく回せているか？
  * テーマ、期間、目的、関係者など、なるべくサイズを小さく区切れているか、をチェックしてます。
  * 上手に失敗して、次に生かしていくサイクルを作る為に、見ています。
* 手段が目的化してないか？
  * 過去にその組織で取り組んだ改革があった場合、その当時のやり方を無意識で踏襲したりします。そこはチェックしましょう。
  * 検証を進めると、検証を進める活動そのものが環境に好影響を与えて状況が改善したりという、ことがままあります。そういう場合、別に最後まで進めきる必要はありません。そういう合理的な判断ができるかをチェックしましょう。
* 危機感は健全か?
  * 取り扱うテーマに対して、危機感が「ありすぎる」場合、極端な意思決定や安易な飛躍をしがちなので、注意してみます。逆に、問題から逃避するという場合もあるので、要注意です。
  * 危機感が「なさすぎる」場合、整理した事により満足して何もしなくなります。それだと何も変わらないので、そこも要注意です。

考え続ける工程は、マネージャである限り長く続ける活動です。
そのため、マネージャにとって無理無く続けられて、しかも、取り組む中で学びが増え、組織が自然と改善していくサイクルを整えたいところです。
それが一番後押しになると考えています。

# 最後に
マネージャを支援する方法として「マネージャと環境の相互作用を理解しよう」「マネージャの思考を辿ろう」「マネージャが考え続けることを後押しする」という3点をご紹介してきました。
根底にある考えとして、「エンジニアリングの現場の最適解はマネージャ自身にしか見つけられない」というものがあります。
どこかに転がってる理想論や過去の経験値で一発OKがでる程、簡単なマネージャ業は無いですよね。
だからこそ、今後もマネージャ支援の質を上げていきたいと個人としても考えており、今回まとめてみました。
私自身もまだまだ試行錯誤の身ですが、どなたかの参考になれば幸いです。

:::note info
明日は[LITALICO Advent Calendar 2022](https://qiita.com/advent-calendar/2022/litalico) 19日目の記事です。
[@joy04d](https://qiita.com/joy04d), [@mayushibata](https://qiita.com/mayushibata) が担当します。どうぞお楽しみに！
:::