本稿の要約を10秒で
- チームのマネージャーが産休で不在に。代役のマネージャーを任される。
- エンジニアリングチームで開発者として働くことと、マネージャーとして働くことでは求められる役割、スキル、能力が大きく異なる。
- もとのマネージャーが復帰するまでの半年間、自分なりの創意工夫を凝らしながら代行マネージャーの職務を遂行した。
- 本稿では、その体験にもとづきながら、エンジニアリングマネージャーとしてチームを率いるうえでの4つの心得を紹介する。
エンジニアリングチームのマネージャーが産休となり…
1年ほど前、私はアトラシアンのエンジニアリングチームで新しいソフトウェアプロダクトの開発（コーディング）に励んでいた。そんなある日、チームのマネージャーが、私にこう打診してきた。
「実は私、妊娠したの。で、産休と育児休暇を半年間とるんだけど、その間、私の代役でエンジニアリングマネージャーを務めてくれない？ どうかな？」
この突然の要請に対し、私は当初、「ノー」と答えた。エンジニアリングチームで開発者として働くことが大好きだったからだ。
ただ、当時の私には2度ほどチームのマネジメントに携わった経験があった。1度目は、アトラシアンに入社する前の会社で人事担当チームのマネージャーとして働いた経験だ。2度目は、アトラシアンで数週間、チームマネージャーの代役を務めた経験である。
その経験を通じて、チームのリーダーとして働くことに面白味やプロフェッショナルとしてのやりがいを感じていた。ゆえに、ときの経過とともに今回の要請を、自分の将来に向けて貴重な経験が積める良い機会かもしれないと考えるようになった。加えて私には、自分のチームに対して強い愛着もあった。そこで1週間の熟慮のすえに、マネージャーの代役を引き受けることにした。
もちろん、チームのマネージャーと開発者とでは、求められる役割やスキル、能力が大きく異なる。そのため、マネージャーとして働くことには相応の苦労もあった。それでも、いまではマネージャーとしての経験を積めたことに感謝している。
以下、私が半年間にわたりエンジニアリングチームを率いて学んだことを4つの心得にまとめて紹介する。
心得① マネージャーは仕事が多く時間の調整に工夫が必要
チームのメンバーとの1 on 1ミーティングが、マネージャーの仕事のすべてではない。製造装置を正しく作動させるために多くの可動部分をマネージしなければならないのと同様に、チームのマネジメントには、メンバー全員の観察や支援、レポーティング、同期化、ドキュメント作りなど、成すべきことが多くある。これらによってマネージャーのスケジュールが圧迫を受けるのが通常で、私はときおり、仕事がノンストップで延々と続くような感覚に襲われた。
加えて、マネージャーは会議が多く、会議のない日が稀にあると「仕事の時間を無駄に使っているのではないか」と、少し損をした気分にすらなった。
そんな中で、自分の時間をどう調整するかは、マネージャーと開発者とでは根本的に異なる。開発者の場合、自分の時間の使い方をいかに最適化するかの判断にもとづいて取り組むタスクの候補を決めたり、仕事の予定を立てたりすることができる。
例えば、自分の記述したコードがコンパイルされ（＝コンピュータが実行可能なバイナリコードに変換され）、テストが実行され、ビルド（構築）が完了するのを待っている間、チームメイトが記述したコードをレビューしたり、別のタスクに取り組んだり、製品運用のプロセス改善を手助けしたりすることが可能だ。
それに対し、チームのマネージャーは、多くの場合、メンバーの都合やニーズに従って仕事をこなしていく。ゆえに、次の最適なタスクへの明確な道筋がないことが多い。
そこで私は、チームの各人が取り組んでいることについて可能な限り多くのコンテキストを得る作業で空き時間を埋めることにした。具体的には、アトラシアンのデジタルワークスペース「Confluence」（同製品のRSSフィード機能を使うことで、特定の人のページをフォローすることができる）を使い、メンバー各人が更新したテクニカルページを確認する時間を毎日とった。この時間の使い方は、メンバー各人が突き当たっているタスク遂行上の障壁を取り除くために、どこに注意を向けるべきかを理解するうえでとても有効だった。
ポイント② 「スクラム」はチームマネジメントを容易にする
アトラシアンが自ら採用し、かつ、あらゆる組織への普及を提唱・促進している「アジャイル方法論（以下、アジャイル）」（参考文書）は、チーム内での密接なコラボレーションとソフトウェアプロダクトのスピーディなリリース、さらにはユーザーからの迅速なフィードバック収集を重視したプロジェクトマネジメントのアプローチだ。そのフレームワークとして広く普及している「スクラム」（参考文書（英語））は、アジャイルを実践するためのプラクティスと儀式のセットである。私は、スクラムのプラクティスに情熱を注いでおり、数年前には「スクラムマスター」の資格も取得した。
この資格自体は、いまの私の仕事とはあまり関係はない。ただし、スクラムの習得を通じて得られた知識や「自律型チーム」に対する理解は、今日における私の働き方の基礎を成している。
また今回のマネージャーの代行で私が特に重視したポイントは、チームの全員が何の障害もなく、顧客価値（顧客にとっての価値）が高いプロダクトの開発、リリースに集中できる状態を維持することだった。その役割を担ううえで、スクラムに関する知識は大いに役に立ったといえる。
また、私は、自分自身をマネージャーというより、優先順位をつけながらチームの仕事を前に進めるファシリテーターと見ていた。そこで以下のような役割を主として担ったのである。
- プロジェクトに対するチーム横断のコミットメントについて、他のチームのマネージャーをフォローアップする。
- チームが他のチームとの接点を見つけ、タスク遂行の障壁を取り除く手助けができるようにする。
- メンバー各人が仕事の優先順位を決める手助けをする
- チームのメンバー各人に対し、私に対してタスク遂行上の課題をエスカレートするよう促す（かつ、課題を解決する）
- 自分自身の課題を解決するために他者の手助けが必要な場合には、自分のマネージャー（またはそのマネージャー）に問題をエスカレートする。
ポイント③ 1 on 1ミーティングは非常に有用である
アトラシアンに入社したとき、自分の上司（マネージャー）が定期的に1 on 1ミーティングを開いてくれることを知り、衝撃を受けた。ただ、私がマネージャーと共有すべき事柄が何もないと感じているときでも1 on 1ミーティングは行われ「やり過ぎではないか」とも感じていた。
しかし、そう感じた私は完全に間違っていた。特に、マネージャーとして行動するようになってから1 on 1ミーティングがいかに重要かを深く知ることができた。
1 on 1ミーティングは、チームの全員がチームの目標に集中し、知識を共有し、質問に答え、クイックにフィードバックするための素晴らしい方法である。しかも1 on 1ミーティングは、メンバーたちが私を助ける機会もつくってくれた。
例えば、私のチームのマネージャーは、プロジェクトのロードマップを管理し、誰がどのプロジェクトに取り組むかを決めなければならない。一方で、チームのメンバーたちは、私が見落としていたプロジェクトの情報を有していて、私が考えもしなかった解決策を提案してくれることがよくあった。
マネージャーがチームにおける唯一の、そして正しい情報ソースであるわけではない。チームのメンバーのほうが、マネージャーよりも良い答えを持っていることが多々ある。1 on 1ミーティングは、そうした良策をメンバーから引き出すための優れた方法でもある。
ポイント④ マネージャーはメンバーへの共感を実践しなければならない
先に触れたとおり、私はエンジニアリングチームのマネージャーになるつもりはなかった（少なくともすぐには）。ただし、かねてよりチームの各人が必要なサポートを受けられるようにはしたかった。
エンジニアリングチームにおけるマネージャーの仕事の1つは、メンバー各人の私生活やプロフェッショナルとしての仕事の状況を知り、それがチームにどのような影響を及ぼすかを理解することだ。ゆえに私は、マネージャー活動の一環として、メンバー全員の状況を知り、それぞれの仕事をどのようにサポートするかを考えることに時間を割いた。
いうまでもなく、チーム内の誰かの仕事がうまくいっていないとすれば、大抵の場合、そこに相応の理由がある。ゆえに、そのメンバーの状況を把握し、理解しておけば、より良い支援ができることになる。
そこで私は、チームの全員が自分の現状について安心して私と共有できるような居心地の良さを演出するようにした。そのうえで、各人の状況に共感し、相手の立場になって物事を考えるよう心掛けた。
実際、例えば、家族のことで大変な時期を過ごしている人に、多くの責任を伴うプロジェクトを任せるのは良策とはいえないだろう。ゆえに、チームのマネージャーは、メンバー各人の状況を知り、理解し、共感するという考え方を持つようにすることが大切だ。また、そうすればチームの燃え尽き症候群を防ぐことも可能になる。
マネージャーの代役を終えて思うこと
マネージャーとして半年間働いた後、もとのマネージャーが復帰するのと合わせて、私は開発者に戻った。半年間のマネージャー経験を経て、いまの私が大切していることは次のような事柄である。
- 集中すること：自分の時間をどの仕事にどれだけ使うかを慎重に吟味し、チームが手がけているプロダクトの顧客価値を高める仕事に集中できるようにする。
- 無駄なコミュニケーションを減らす：現在のチームでマネージャー職を経験するまでは、コミュニケーションが過多だった。ただ、マネージャー職を経験したことで、可能な限り早いタイミングで、かつ頻繁にチームの全員に伝えるべきことを伝える重要性を痛感した。
- 文書化：アトラシアンのようにチームのメンバーがリモートに分散して働く会社では、不必要な会議を繰り返さないようにすることが大切である。そのためにも、決定事項を文書化することが重要となる。
- ステークホルダーからのフィードバック：プロダクト開発においては、プロジェクトの進捗を簡潔に要領よくステークホルダーに伝えることが非常に重要である。アトラシアンでは、あらゆるチームがお互いの業務についてオープンにコミュニケーションし、仕事に関する文脈を把握することを可能にするワークマネジメントツール「Atlas」 を使ってプロジェクトに関する情報をすべてのステークホルダーと共有している。
いずれにせよ、チームワークやチームを率いること、あるいはプロジェクトマネジメントなどに情熱を持つソフトウェア開発者の方は、一時的にでもマネージャーの職務を経験することを強くお勧めしたい。
私は上述したマネジメントの経験を通じて視野を広げることができたほか、チームの力を引き出すうえでメンバー各人に対するコミットメントと情熱がいかに重要かを肌身で理解することができた。その理解は、おそらく、エンジニアリング以外のチームをリードするうえでも有効であると確信している。
