エンジニアリングマネージャを退いた話

この記事は、Engineering Manager Advent Calendar 2018の06日目のエントリーです。

• Engineering Manager Advent Calendar 2018

2016年某月からリーダー相当となり、さらに2018年04月から半年間、開発チームのマネージャとしてやってきた。しかしやり続けても成果を出す自信も、そもそもこれがやりたいことなのかという疑問もあったことと、なによりちょうどよくそれを託すに値する人がリファラル採用によって獲得できそうということが偶然にも重なり、マネジメントをやめたいと経営者に伝えたのが2018年10月。

そしていま現在、件の人にマネジメントしていただいており、これが機能していて、これがマネジメントなのかということを感じている。振り返るに自分には何が足りなかったか、マネジメントとは具体的になにをすることだったのか、ということを書きたい。

以下に

• [すべきだったこと] 僕ができなかったこと
• [もたらされたこと] 新マネージャが導入してくれたこと

として書いていく。

[すべきだったこと]いまチームがどの状態にあるかを知る

マネジメントに期待される事柄とは「チームをよりよくする」ことで、「企業の成長に寄与する」ことなのだと思う。ここでは後者は自明という点で無視する。前者の「チームをよりよくする」というところで考える。

「よりよくする」というからには「現在チームはどうであるか」ということを知らなくてはならない。
このとき主観的な状態、たとえば「技術的負債が……」などという ある程度認知されたつかいやすいそれっぽい言葉 が飛び交う状態はよくない。本当にチームとして知りたいのは「システムAの処理Bが非常に理解困難で改修すべきか運用でカバーするか、どちらがビジネスとして優先度が高いか」ということである。

つまりは 計測しよう ということだ。僕自身これができなかった。

[もたらされたこと]具体的な計測

大雑把でもいい。今現在チームのリソースがどのように割かれているかを知る必要がある。

• 開発
• 保守/運用
• その他

という(たとえ大雑把であっても)はじめの一歩としてのメンバーそれぞれの工数計測が必要だった。ひいてはこの計測結果がプロダクト維持に必要なリソースということになる。

• プロダクトの維持/成長のために、チームとして強化/補充すべき点はどこか

をまず知らねばならない。これはプロダクトそのものの健康診断とも言える。このあとになにを成すにせよ、チームの基準値はこの値になる。数値がよくなれば嬉しいし、悪くなれば別の方策を取る。この判断材料としての 計測が重要だと理解した。

[すべきだったこと]開発チーム内の構造/責務を明確にする

いびつな組織構造が同じ顔をしてシステム構造を制約する、というのがコンウェイの法則の警鐘点だと考える。開発チームの立ち位置、およびそれを管理するマネジメント職においても同じことが言える。

あとから考えるに僕には 制約をそのまま継承して改善しようとするという性質があるようで、本質から遠ざかったことをやっていたのだと考える。コンウェイの法則的に述べれば「いびつな組織構造を助長させている」と言えるよう思う。

組織構造は

Dev
|-- Prod-A(期待のプロダクト/比較的整理されている)
`-- Prod-B(売上主要/かなりレガシー)

となっていた。このときマネジメント職として期待される立ち位置は Dev に、メンバーは Prod-{A,B} にアサインされるべきである。また Dev に位置するマネジメント職は Prod-{A,B}の開発状況/進捗を理解していなければならない。これは当然であろう。

しかし僕の立ち位置は

• Prod-B のリーダー、およびインフラ担当としての立ち位置
• Devのマネジメント職としての立ち位置

であり、Prod-Aへの関与を最小限(というかほぼない)としていた。

また Dev という部署単位で企画されたことが部署に恩恵を与えた実感に乏しかったし、そもそも企画の数そのものが少なかった。

• 技術ブロクの開設
• 技術カンファレンスへのスポンサード

端的に言うと開発チームとして機能しておらず、また開発チームとして機能しているように見えても散発的であり積み上がっていく実感に乏しかった。

[もたらされたこと] 開発チームとしてのつながりとマネジメント職の独立

• プロダクトごとに閉じない、開発チームとしての技術要素の標準化計画
  • Prod-A において新規基盤開発で知見を得る
  • 上記知見を Prod-B へ横展開して可能な部分で切り出し改善する
• 週1回の開発チームとしてのMTG
  • タスク管理ツールの移行化計画
  • Prod-A Prod-Bを超えた進捗の共有
    • 技術要素の標準化 につながっていく期待

僕自身は上記の時間をとったことがなかった。先述した Prod-Aへの関与を最小化したことに起因する。そもそもMTGが嫌いというのと、抱えている問題が違うということからコミュニケーションコストが高いと考えたこともある。しかしそれは 管理ではなく結局のところ属人性を助長したに過ぎない。これは 「いびつな組織構造を助長させている」の具体的事例だ。

[すべきだったこと]開発チームと関連部署(ビジネス側、CS側)との責務を明確にする

たとえば Prod-Bにおいて責務は非常に曖昧なものだった。端的に申せば最終作業者にしわ寄せがくる構造といえる。2016年当初からこの点を非常に危惧しており、そして危惧すればするほど自身の開発リソースが食われるということを感じていた。その一方で危惧を改善する行動が継続せず(これもまた)散発的に終わることがほとんどだった。包み隠さず申せば「実りよりも混沌をもたらすただ声の大きい細かい人」というのが、実態だったのではなかろうか。

[もたらされたこと] 開発への希望/要望の交通整理

• 希望/要望管理ツールの統一化
  • 過去利用ツールは(ツールの問題というよりは運用上の問題で)大変使いにくい状態だった
  • 過去の濫造されたタスクがあり、「2018年10月においてこのタスクは重要なの？」という精査が全くなされていない状態だった
• 希望/要望の現時点での洗い出し
  • 2018年10月現在で必要なもの
  • 重要度の設定
  • それぞれに担当者をアサイン
• ツールを管理する交通整理者のアサイン
  • 当該担当者同士のMTGによる少人数でのビジネス的意思決定

それぞれの部署のインターフェースをきちんと定義して、責務を切り分けることに成功したように実感している。これには感謝しかない。

[本当に必要だったこと] なにかを決めなければならない

最後に根本として必要だと感じていることを述べる。それは 決めなければならないということである。決めなければならないというのが僕自身本当に苦手で、なぜ苦手かといえばその決断に 他者が影響するからである。
そもそも本当に僕が苦手なのは 他者に何かをやってくれとお願いすることである。「嫌だなあ」という相手に「必要なことだから」と伝えることが本当に苦手だ。なぜなら「嫌ならしょうがないよな」と考えるからである。

この点を踏まえると僕はいつまでたっても「いい兄貴問題」の中にいたに過ぎない。

• 局所最適化するから「いい兄貴問題」に陥る - 違反ヒントはありません

過去に書いたこのレベルから一切進歩していないということを感じている次第である。その一方でだからといってどうだということを考えるわけではない。単に向いていなかったという言葉ですませたい。

[これからできること/本当にやりたかったこと] 得意領域でプロダクトの改善を行う/マネジメントを後押しする

思うに僕のやりたかったことは

• 得意領域でプロダクトの改善を 自らの手で行う

に尽きるのだと思う。コードを書きたい、ITインフラを整備してよりクラウドネイティブにしたいなどなどを誰かに任せたいなどと言えない。この思いを抱えたままマネジメント職を両立させるのは、少なくとも僕には無理だと感じた。ので退いた次第である。

その一方でITエンジニア(というより一社員)として思うことは

• わたしたちは管理されたくないわけではない。「正しく管理されたい」だけなのだ

ということである。新しく入社された方とマネジメント職を交代し、先述した内容の数々を実施していただいたいまこそその実感がある。この状態を維持強化していきたいと強く感じ、そのためにできることはなにか探していきたい。