エンジニアリングマネージャーがコードを書くことは、矛盾する2つのことを求められる訓練に近いでしょう。
マネージャーになりたての皆さんは、恐らくこれまでは専門職、いわゆる Individual Contributor (IC) として、コードの質や量の成果によって評価されてきたのではないでしょうか。マネージャーの成果はこれまでとは違う指標で評価されるため、日々の仕事も大きく変化します。マネージャーがコーディングするなんて無駄だと言ってくるメンターがいる一方で、コードを書き続けていないと技術が錆びつくリスクがあると言う人もいます。また、エンジニアリングマネージャーが IC の仕事を行うことを企業文化として奨励し、昇進の基準として明文化している企業もありますが、逆にこれがペナルティとなる企業もあります。どっちつかずでストレスのもとですね !
私の場合、管理職になってからは、頻度に差はあるものの、IC の仕事を基本的に四半期に1回はやり遂げるようにしています。この記事では、エンジニアリングマネージャー1としてコーディングする際の課題や利点、対象範囲が絞り込まれた手掛けやすいユニコーンプロジェクト (希少な、幻の意味から理想的なプロジェクトを指す）の見つけ方など、これまでに私が学んだことをご紹介します。
SVG SILH の Ruby star rainbow sparkle
チーム (Team) に「I (自分)」はなくても、ユニコーン (Unicorn) には「U (あなた)」と「IC」の両方がある。ただの私のつぶやきにすぎませんが。
マネージャーがコードを書くことの大変さ
エンジニアリングマネージャーが IC の仕事を行う上での課題は、幅広いトピックへの対応と優先順位付けです。
管理職には幅広いトピックに対応する能力が求められます。人員計画の戦略のアイデア出しの会議に出ているかと思えば、同僚からの厳しいフィードバックを受け止め、はたまたカンバン形式の会議の進行役を務めたり。一方で、コーディングには数時間にわたって邪魔されずに作業 (ディープワーク) できる環境が必要です。会議の合間の30分でコードを書こうとしたことのある人には、こんな状況になることをわかってもらえるはずです。
import numpy as np import pandas as pd # pull data here If n in list(TODO): # look this up, used to know how to do this
リーダーとして優先順位の高い仕事はチームメンバーのサポートでしょう。キャリア面談やフィードバックのほか、創造性が高く大きなインパクトを残せるような仕事ができるようにチームをサポートすることなどが業務に含まれます。面談方式で実施することも多いですが、フォローアップ会議や関係者とのチェックインなどの時間も必要です。チームの人数が増えてくると、小さなプロジェクトのコーディングを完成するのに必要なたった数時間でさえ確保するのが難しくなり、週40時間の勤務時間では足りなくなってきます。
コーディングの時間を確保すべき理由2
1つ目のメリットは、IC プロジェクトのコーディングをすることによって、チームメンバーや、彼らが業務で使用しているツール、抱えている課題などに共感できるようになる点です。具体的に言うと、メンバーの1人と一緒にプロジェクトの作業をしたのですが、それによって、Indeed のいくつかのサービスとその課題について直に学ぶことができました。その結果、後日行われた会議では、以前より具体的な内容を自信を持って話すことができました。メンテナンスチームに要望を提出したことで、アップデートの優先順位を上げてもらうことができ、自分のチームに大きなメリットがありました。
次に、コーディング (数週間ぶりだったり数か月ぶりだったりしますが) をすることで、チームメンバーに助けを求める必要に迫られます。先日、私はデータラングリングで for 文のネストが1重や2重で終わらず、3重になってしまった問題を解決しようとしていました。それを見たチームメンバーが Big O Notation (ビッグ・オー記法) に「OH NO」があるからだと冗談を飛ばしたりしていましたが、私が皆に素直に助けを求めると、チーム内で協力して、コードの複雑さを解消できました (し、大いに笑いました)。私の経験上、人は誰かの役に立ちたいと思っていますし、悪戦苦闘している上司を助けられるという状況には特別なものがあります。マネージャーとしては、チームメンバーには困った時には周囲に助けを求められるようになってほしいと思います。リーダー自身が弱みを見せて助けを求めることも、チームメンバーに対するお手本となるでしょう。
最後は、コードを書き上げることで気分が上がるという利点で、これはマネージャーのメンタルヘルスにとって一番大切なことです。管理職の仕事は、完了できたという達成感につながりにくく、自己不信に陥ることも多いものです。IC の仕事は単体で成果がわかりやすいことが多いので、自分の手で何かを作り、「見て ! あれは私が作ったんです。悪くないでしょう ?」と胸を張って言うことで達成感を得ることができます。
マネージャーのコーディング作法
大まかに言うと、マネージャーとして IC の仕事をすることは、次のような点に気をつけるということです。
- チーム内で緊急事態が起きていないことを確認する
- 明確でシンプルなユニコーンプロジェクトを見つける
- ディープワークの時間を確保する
- 引き継ぎを念頭に置いて着手する
これから、一つずつ具体的に説明します。
チーム内で緊急事態が起きていないことを確認する
緊急案件に苦戦しているチームメンバーをよそにコーディングすることは、ローマの大火を眺めながらヴァイオリンを奏でていたという皇帝ネロと同じくらい危機管理に問題があるだけでなく、チームのサポートというマネージャーの重要な役目を果たしていないということにもなります。IC プロジェクトの作業範囲について考える前に、チーム内の物事が比較的落ち着いていることを確認しましょう。
明確でシンプルなユニコーンプロジェクトを見つける
プロジェクトを適切な作業範囲で引き受けていたら起こらなかった失敗例を挙げてみます。
一度、新しいプロダクトのチームを手伝おうと張り切って、その四半期末までに開始したい A/B テストをいくつか引き受けたことがありました。その A/B テスト自体は問題なく管理できるシンプルなものでしたが、管理職の業務が忙しくなってきた時に状況は一変しました。そのうち Product Manager が尻拭いをする羽目になり、最後には、マネージャーと私は A/B テストを他の人に任せて完了してもらいました。PM を失望させることになり、落ち込みました。
逆に、マネージャーにとって理想的な IC プロジェクトとは以下の通りです。
- 時間的制約が厳しくない
- 規模がかなり小さい
- 依存関係がない
- 「あれば助かる」、つまりチームが優先順位を上げる必要があるほど重要ではないが、クオリティ・オブ・ライフ (QOL) が向上してよい影響をもたらす可能性がある
- 自分の強みを活かせる
つまりそれがユニコーンです。ユニコーンプロジェクトは常に存在するとは限りませんが、そもそも何を探すべきなのかをわかっていなければ、見つかりません。
例えば、数年前にデザイン上の問題に対処していた時のことですが、UX のチームメンバー達が、「Y クエリに対する X が常に分かるわけじゃない。それが可能になるツールがあれば便利だね。」と話していました。求められているツールはかなり小さかったので、数時間で手際よく Ishbook を構築したのですが、いまだにサイトでユーザー行動を理解するツールとして利用されています。
このようなユニコーンプロジェクトを見つけることで、チームも恩恵を受けることができます。
また、IC プロジェクトは自分の強みを活かせるものであることも重要です。しばらく使っていないとコーディングスキルは落ちてしまい、以前よりコードを書くのが遅くなるため、ただでさえ落ち込んでしまいがちです。その結果、IC の仕事へのやる気を維持しにくくなり、このブログ記事と私自身も、皆さんのお役に立てなくなってしまいます。
アンケートや測定バイアスの分析、A/B テストのサポート、うまく設計したグラフの構築などが、私が通常行っている IC プロジェクトです。なぜそれらをやっているかというと、こういったことが好きで、得意な分野でもあり、気持ちも上がるからです。皆さんも、私と同じように感じられる IC プロジェクトを選べば、短時間でより質の高い成果物を生み出すことができるでしょう。
ディープワークの時間を確保する
30分ずつ細切れの時間を使ったとしても、有意義なディープワークにはつながらないことが多いものです。私はマネージャーになってから毎週、午前中の数時間を押さえてディープワークに充て、コードを書いたり、専門分野の最新情報を読んだりしています。習慣づけておくことで、皆私が集中して作業にあたっている時間に予定を入れる前にメッセージをくれるようになりました。もちろんどうしても出席しなければならない会議も時にはありますが、コーディングのピーク時間はなるべく会議を避けるようにしています。ディープワークのために押さえた時間帯の会議依頼は自動的に欠席にしてくれるというGoogle カレンダーの新しい不在機能が追加されたので、さらに積極的にこの習慣を実行しています。
私もディープワークを優先できない週もあれば、いつもより時間がとれる週もあります。毎週 IC の仕事に時間がとれないことに自分を責めるマネージャーを見てきましたが、やめましょう。それは現実的な目標ではありません。Ben Edmunds はマネージャーのコーディングについて著書の中でこう解説しています。「自分にとっての成功の形を再定義してみましょう。(中略) 毎日のタスクは動かせないものではないことを理解し、マネージャーとして流動的になる必要があります」。私もその通りだと思います。
引き継ぎを念頭に置いて着手する
マネージャーのコーディングは皿回しのようなもので、管理職としてのさまざまな業務を素早くこなしつつ、同時進行で行っていく必要があります。プロジェクトのコーディングだけに時間を湯水のように使えるわけではないため、何を作ったとしても、プロトタイプのような物になってしまうことは避けられないかもしれません。マネージャーとして IC プロジェクトのコードを書く場合には、その後を他人に任せられるミニマル・バイアブル・プロダクト (MVP) とはどんなものかを具体的に頭に描いておきます。ヒント: 適切なコメントがあるコードとペアプログラミング。この MVP を最終目標に掲げておきましょう。
マネージャーになってから作ったもののひとつに、Indeed の求人検索プロダクトで多変量 A/B テストをより厳密に実施できるツールがあります。質が良くないことはわかっていましたが (なんと、Google スプレッドシートからデータを取り込む仕様)、チームが必要としていた作業は可能であり、何もないよりはましだったのです。その後、このツールをチームメンバーに引き継ぐことができました。
これは2つのよい結果をもたらしたと思っています。まず、自分のチームメンバーが私の専門知識から学ぶ機会を作れたことです。彼女は、多変量 A/B テストの統計的有意性の評価について、理解を深めることができました。2つ目に、彼女は私が作ったツールを元にしつつ、ずっと優れたものに仕上げました。私のプロトタイプはフォントが Comic Sans でしたが、彼女のバージョンではご覧のとおり美しくて理解しやすいグラフがあり、厳密に統計的アプローチが取られています。彼女のツールの V.1 は素晴らしい出来のプロジェクトであり、今でも活用されています。
まとめ
エンジニアリングマネージャーがコードを書くべきかどうかについては相反する意見が溢れていますが、コーディングをすることで共感が生まれ、チームメンバーとの信頼が築けるので、結果としてより仕事のできるリーダーになれるのは間違いないでしょう。専門職時代と同種類のプロジェクトを引き受けたり、会議の合間にコーディングを詰め込もうとしたりすると失敗への道に突き進んでしまうので、手掛けるコードの種類は大枠から見直しましょう。また、ディープワークに集中する時間を捻出することが大切です。そして、小規模で、緊急度が低く、引き継ぎが可能なユニコーンプロジェクトを探し、自分の強みを生かしてチームに価値をもたらしましょう。
注釈
- ここで言う「エンジニアリング」とは、ソフトウェアエンジニアだけを指しているのではなく、データサイエンティストや QA をはじめとした、IC の仕事がコーディングにある程度関わる職種も含みます。(トップに戻る)
- エンジニアリングマネージメントの分野はまだ始まったばかりで、これをテーマにした書籍は最近までほとんど出版されていないと思います。本記事で引用したエビデンスの多くは個人の経験に基づくものであり、強みや経験は人それぞれだと思います。例えば、マネージャーとしてコーディングすることについて、「逆境を生き抜く力」を持つ助けになるという仮説を聞いたことがあります。しかし、私は最近 Git リポジトリで職場で恥をかくようなことをやってしまったばかりで、コーディングすることで本当にそのようなスキルが身に付いたかどうかは正直分かりません。そのため、この記事ではその部分は割愛しました。ただ、他のマネージャーの経験には興味があります。ソフトウェアエンジニアリングやデータサイエンスの分野で IC の仕事をする利点や欠点についてのデータを、質と量ともにさらに徹底的に集め、実証的に考えてみたいと思っています。興味のある方はぜひ私にご連絡ください。いくつかアイデアを温めています。(トップに戻る)