チームマネジメントの経験
技術チームのマネジメントは非常に複雑な学問だと思っている人が多いのですが、自分でチームを率いるようになってから、実は多くのことは想像ほど複雑ではないと徐々に気づきました。技術チームのマネジメントとは、突き詰めれば「人を管理する」ことではなく、チームが安定して物事をやり遂げられるようにする ことなのです。
チームを率い始めた頃は、私も回り道をしました。最初のうちは、自分の技術力さえ高ければ、多くのことは自分で手を動かせば解決できると思っていました。しかし後になって、チームの規模が大きくなると、一人では支えきれないことに気づきました。テックリードが本当にやるべきことは、チーム全体の能力を引き上げることであって、自分がチームで一番忙しい人になることではないのです。この数年間、技術マネジメントをやってきて、シンプルだけれどとても重要な経験をいくつかまとめられるようになりました。
まず物事を考え抜いてから、チームに任せる
技術チームの効率が低いのは、実はエンジニアの能力が足りないからではなく、物事自体が考え抜かれていないからであることが多いのです。以前私もこんな状況に遭遇しました。要件が来るとみんながすぐに開発を始め、開発の途中になって設計が不合理だと気づき、やり直しになるのです。
その後、私は徐々にある習慣を身につけました。プロジェクトを始める前に、必ず 設計の考え方と全体の方針を考え抜く ことです。例えば、システムがどんな機能を作るのか、システムをおおよそどう分割するのか、コアモジュールをどう設計するのか、どこがボトルネックになり得るのか。これらのことが考え抜かれていなければ、チームが努力すればするほど、方向がずれていく可能性があります。
そこで今の私は、通常まずこれをやります。問題をはっきりさせてから、チームに仕事を割り当てる。こうすることで効率が上がるだけでなく、不要なやり直しも大きく減らせます。
チームの分担は必ず明確に
技術チームでよくある問題の一つが、責任の所在が曖昧なことです。多くのシステムは一見みんなで作っているように見えますが、本当に問題が起きたとき、誰に聞けばいいのか誰も分からないのです。
やがて私は、チームがスムーズに回るためには、明確な責任の分担が不可欠だと気づきました。例えば、システムには必ず責任者が必要です。その人がすべてのコードを書く必要はありませんが、システムのアーキテクチャ、コアロジック、そしてシステムの稼働状況を把握していなければなりません。
私は通常、コアとなるシステムごとに Owner を一人置きます。例えばあるサービス、あるモジュール、あるいはある基盤コンポーネントです。こうしておけば、システムに問題が起きたとき、チームはすぐに責任者を見つけられますし、お互いに責任を押し付け合うことも避けられます。責任が明確になると、チームの効率は目に見えて向上します。
テックリードは何でも自分でやるべきではない
チームを率い始めた頃、私はつい自分で多くのコードを書いてしまいがちでした。自分で書いたほうが確かに速いし、安心できるからです。しかし時間が経つと、このやり方は実はチームの成長にとって良くないと分かってきます。テックリードが重要なことをすべて自分でやってしまうと、チームメンバーは成長しにくくなり、長期的にはチームがますます特定の一人に依存するようになってしまいます。
その後、私は自分のやり方を少しずつ調整しました。今の私はどちらかというと、チームメンバーを設計や意思決定に参加させる ことを重視しています。単に実行だけを任せるのではありません。例えばシステム設計の議論では、私一人で決めるのではなく、みんなに参加してもらいます。このやり方は最初こそ少し時間がかかるかもしれませんが、長期的に見ればチームの能力はどんどん強くなっていきます。
プロセスは縛るためではなく、効率を上げるためのもの
プロセスと聞くと、作業量が増えるだけだと感じるエンジニアは多いものです。しかし実際には、成熟したチームには必ず基本的なプロセスが必要です。例えば私たちのチームには、通常いくつかの固定の工程があります：
- 要件レビュー
- 技術設計
- コードレビュー
- テスト検証
- リリース
これらのプロセスの目的は複雑さを増すことではなく、問題を減らすことです。例えばコードレビューは潜在的なバグを事前に発見でき、技術設計はアーキテクチャの問題を回避でき、テストプロセスは本番障害を減らせます。プロセスが安定してくると、チームの協働は格段にスムーズになります。
テックリードは長期的な問題に目を向ける必要がある
チームは毎日要件の処理に追われがちで、目の前のことにばかり意識が向きやすいものです。しかし技術的負債に長期間目を向けないでいると、システムはどんどんメンテナンスしづらくなっていきます。そこで私は通常、一定の時間を確保してシステムアーキテクチャについて考えるようにしています。例えば：
- システムに性能上のボトルネックがないか
- アーキテクチャの調整が必要ではないか
- 新しい技術コンポーネントの導入が必要ではないか
これらのことは短期的には効果が見えないかもしれませんが、長期的にはシステムの安定性に大きな影響を与えます。テックリードは今日の問題を解決するだけでなく、システムの将来の発展の方向性 も考えなければなりません。
チームの雰囲気は実はとても重要
技術チームの効率は技術力だけでなく、チームの雰囲気にも左右されます。チームメンバーの間に信頼が欠けていると、多くのことが難しくなります。
私自身が特に重視しているのは、チームメンバーが技術的な問題を自由に議論できるようにすることです。人が違えば考え方も違うことが多く、そうした議論からより良い解決策が生まれることがよくあります。また、私は過度に厳格な管理のやり方もあまり好きではありません。技術チームには比較的オープンな環境のほうが向いていて、みんなが物事をやり遂げることに集中できるようにするのがよいのです。
技術マネジメントもまた一つの成長
エンジニアからテックリードへの転身は、実はとても大きな変化です。以前はコードにだけ集中していればよかったのが、今はチーム、プロジェクト、そしてシステム全体に目を配る必要があります。最初は慣れないかもしれませんが、やがて技術マネジメントもまた新しい挑戦なのだと分かってきます。それには技術力だけでなく、思考力とコミュニケーション力も必要です。
私にとって、チームを率いる最大の収穫は、チームメンバーが絶えず成長し、同時にシステムも絶えず進歩していく姿を見られることです。
まとめ
この数年間、技術チームのマネジメントをやってきて、私の最大の実感は実にシンプルです。技術チームのマネジメントとは複雑な経営学ではなく、エンジニアの集団が 一緒に物事をやり遂げられる ようにすることです。目標が明確であってこそ、チームは無駄な力を使わずに済みます。分担が明確であってこそ、問題が起きたときに引き受ける人がいます。プロセスが安定していてこそ、協働は運任せになりません。そこにチーム内の信頼が加われば、多くのことは自然とスムーズに進んでいくものです。
COMMENTS