優れた開発チームのリーダーになるために役立つスキルは何ですか?

こんにちは。私の名前はアレクサンドル・グゼンコです。私は大企業の 3 つのフロントエンド開発チームのチーム リーダーです。最近、従業員の一人が私のところに来てこう言いました。どこから始めればよいですか?」 これがこの記事のアイデアが生まれた方法であり、後でガイドとして彼に送ることを約束しました。

この記事では、私がどのようにしてチームリーダーになったのか、このポジションに欠かせないスキルは何か、そして「普通の」開発者である場合にチーム管理スキルを向上させる方法について説明します。

チームのリーダーは誰ですか? 彼は何を担当しますか?

まずは理論から始めましょう。この理論がなければ、なぜ開発を管理することにしたのに、代わりにプロジェクトの予算を数えたのかを理解するのは難しいでしょう。

古典的な意味では、チーム リードは開発チームのリーダーです。これは真実ですが、いくつかの留保があります。

今日の状況では、チーム リーダーにはプログラマーだけでなく、デザイナー、アナリスト、テスター、SEO スペシャリスト、さまざまな IT 専門家や IT 以外の専門家も含まれています。したがって、ここでは特に開発者に焦点を当てますが、チーム リードを同じ役割を共有する従業員のグループのリーダーとして定義する方が正確です。

第二に、チームリーダーは単なるチームリーダーではなく、従業員と経営陣の間の主要なつながりです。これは重要な追加事項です。その理由を以下で説明します。

第三に、チームリーダーの責任を理解するには、役割とポジションを区別することが重要です。

チーム リーダーの役割には、主に次の管理タスクが含まれます。

• 重要な問題に関する経営陣の立場を伝える。
• 組織変更を実行する。
• 従業員間でタスクを分散し、実施を監視します。
• 現在のチームの質問に答える。
• 紛争を解決する。
• チーム内に快適な雰囲気を作り出す。
• 各チームメンバーの特性を考慮する。

たとえ求人サイトの責任リストに別の記載があったとしても、純粋な形でその役割が見つかることはほとんどありません。

チーム リードのポジションは、チーム リード、テクニカル リード、リード開発者など、複数の役割を同時に組み合わせることができます。このポジションでは、スペシャリストが自らコードを作成し、チームの作業を管理し、技術的な部分を担当することがよくあります。

• プロジェクト開発戦略を作成します。
• 建築を設計する。
• 特定のタスクおよびプロジェクトのテクノロジー スタックを定義します。
• 関連するライブラリのバージョンを監視します。
• コードの品質に責任を負います。
• 技術的負債のレベルを管理して、プロジェクトにとって致命的とならないようにします。

チームリーダーとテクニカルリーダーが一人の方がビジネスにとって非常に便利です。実際には、大企業であっても、チームリーダーのポジションには、3 つの役割すべてが異なる割合で組み合わされています。したがって、チームリーダーが何をするかについての考えは異なることがよくあります。

さまざまな企業の開発者にチームリーダーの責任は何かと尋ねると、おそらく答えは異なります。チームリーダー自身の間でも同様の範囲の意見があるでしょう。これを確認するには、求人検索サイトにアクセスして、さまざまな求人における責任のリストを確認してください。

誰がチームリーダーになれるでしょうか?

開発チームを率いるには、本格的な能力と経験が必要です。したがって、チームリーダーになるための最も一般的で正しい方法は、まず上級レベルに上がってから、初めてリーダーの地位を目指すことです。しかし、これは常に起こるわけではありません。

チームが中堅プログラマーのみで構成されており、その中にすべての事項を認識し、プロジェクトをサポートするイニシアチブ社員がいれば、彼は優れたチームリーダーとなるでしょう。確かに、彼は先輩よりも技術的スキルが劣っていますが、チームに上位の選手がいない場合、彼の能力は十分にあります。

同時に、すべてのシニアがチームリーダーのポジションに適切なキャリアパスを見つけられるわけではありません。リーダー的な立場で働くことは本当に興味深いものでなければなりませんが、そうでないと管理上の仕事量の多さに萎えてしまう可能性があります。

自分がワークロードに対処できることをどのように理解すればよいでしょうか?

短い答え:試してみてください。マネージャーに、追加の責任を無料で引き受けたいと伝えて、どうなるかを見てください。これは双方に利益をもたらすスキームであるため、通常、経営陣は喜んで協力します。

チームリーダーが勝ちます。誰かが彼のために仕事をしてくれます。

ビジネスの勝利: 仕事は完了しますが、そのためにお金を支払う必要はありません。

チームリーダーの研修生にも利点があります。このモードで数か月から 1 年働くと、自分が成功するかどうか、そして自分がリーダーシップを発揮するのが好きかどうかを自分で理解できるようになります。そして、それぞれの点に対する答えが「はい」であれば、この方向に成長することを真剣に考えることができます。

チームリーダーになるには: 成長戦略

選択肢は 2 つだけです。 1 つ目は、社内の他の開発者全員を外して、「最年長」の従業員としてチームのリーダーになることです。ただし、「古い」という単語を引用符で囲む必要がなくなる可能性があります。 2つ目の選択肢は、自分からイニシアチブを取ることです。

私にとってはどうだったのかお話しします。卒業証書によれば、私の職業はマネージャーで、大学での学業と並行してプログラミングを独学で勉強しました。そこで、プログラマーとして最初の仕事に就く前から、開発チームのリーダーになろうと決めていました。

最初は中小企業で働いていました。私がコツを掴み、ジュニアから強力なミドルプレーヤーに成長するまでに2年かかりました。プログラミングの経験がなければ、優れたチームリーダーになることはできません。開発プロセスがどのように機能するのか、どのような間違いや落とし穴があるのかを理解する必要があります。

数年後、私は大企業に勤めるようになり、すぐにチームリーダーになりたいと言いました。大企業では、通常、半年または 1 年に一度、マネージャーが従業員と会い、近い将来の個人の成長計画を一緒に構築するパフォーマンスレビューを実施します。そのような会議のたびに、私はチームのリーダーになりたいと言いました。初めて彼らは私にこう言いました。「何もかも素晴らしいけど、まずは経験を積んでください。」私はリーダーとしての経験を積むことができるよう、能力開発計画を作成しました。

私は約半年間、チームリーダーと一緒にタスクを評価・分解し、従業員に配分することに努めました。私たちの仕事の質が多かれ少なかれ同等になったとき、会社はちょうど新しいフロントエンド開発チームを結成し、私がそのチームを率いていました。大企業であれば、それほど長く待つ必要はありません。

チーム リーダーの育成には 2 つの重要なマイルストーンがあると言われています。1 つ目は従業員数が 2 ～ 6 名で、2 つ目は 7 名以上です。最初は従業員が 1 人だけでしたが、現在は 3 つのフロントエンド開発チーム (従業員 12 人) を率いています。

私はただ率先して経営陣の前に姿を現し、機会が来るとすぐにチームリーダーに任命されました。

成長を待つか、それとも別の会社に転職しますか?

チームのリーダーは社内で任命されることが多く、これを考慮することが重要です。今の仕事で成長の見込みがあるなら、思い切ってマネージャーの役割に挑戦してみましょう。しかし、チーム全体がフロントエンドとバックエンドであり、全員が自分のチームリーダーである場合、奇跡を期待すべきではありません。より大きな会社に転職し、将来的には指導的な立場に就きたいと表明した方がよいでしょう。プロセスを調査し、プロジェクトのビジネス ロジックを理解するには時間が必要です。しかし、社内に適切なポジションが空くと、社外者ではなくあなたを選ぶ可能性が高くなります。

優れたチームリーダーになるために役立つスキルは何ですか?

チームリーダーの立場では、ハードスキルとソフトスキルの両方が同様に重要です。開発者は通常、ハード スキルに何が欠けているかを知っています。さらに、これらの要件は専門分野と技術スタックに強く結びついているため、普遍的なリストはありません。私が製品と会社にとって重要だと考えるソフトスキルについて話します。

プロセス内の問題を発見する能力

開発の速度と品質、ひいてはコストは社内のプロセスに依存しますが、それらが理想的であることはほとんどありません。

たとえば、バグを修正し、ビルドをスタンドに持ち込む準備ができたら、ビジネスが待っています。ただし、これを行うには、5 つのパイプラインを通過し、関係者全員から承認を集める必要があります。あなたは責任者に手紙を書きます - 沈黙してください。あなたは彼らを引っ張り始めますが、返信するためだけに正式なメッセージが届きます。誰もが時間がありません。修正版がスタンドに届くまでに最大 6 時間かかる場合があります。そして、このすべての時間を同僚と連絡を取るために費やすことになり、企業は損失を被ることになります。

もう 1 つの例は、さまざまなシステム、プログラム、スタンド、リポジトリへの膨大な数のアクセスです。銀行は通常、これに悩まされます。人は仕事に来て、プロジェクトを理解する必要がありますが、最初の1か月半はまったく何もできません。そうです、アクセスがないからです。アクセスに関するもう 1 つの問題は、アクセス数が多く、名前を覚えられないことです。たとえば、ディレクトリには「リポジトリへのアクセス」の代わりに A32B18KZ があります。これを探してみてください。

私は、開発者が 1 ～ 2 か月間作業を開始できなかった実際のケースを知っています。その間ずっと給料をもらっていたが、幻滅して辞めた。つまり、会社は従業員を探すのに 6 か月を費やし、2 か月分の給与を支払い、その後採用プロセスを最初からやり直す必要がありました。

このようなプロセスの問題は作業を複雑にし、速度を低下させます。チームリーダーの仕事は、それらを見て、正確に何がうまく機能していないか、どこで障害が発生しているかを理解することです。

問題を解決する能力、または問題をビジネスに正しく伝える能力

プロセスの問題を見つけるだけでなく、解決策を提案することが重要です。いくつかの困難には、管理者に関与せずに自分で対処できます。たとえば、あるチームが都合の悪い州マネージャーに悩まされているとします。プロジェクトが小規模であるか、まだ始まったばかりの場合は、電話を手配し、最適なオプションを見つけて、損失なく新しい州マネージャーを段階的に導入する方法の概要を説明できます。解決策は見つかりましたが、企業は問題の存在すら知りませんでした。

しかし、ほとんどの問題は上級管理職の助けがなければ解決できません。たとえば、スタンドへのビルドのリリースを迅速化するには、すべての部門に良好なコネクションを持ち、意思決定者にアクセスできる人を特定し、その人を承認プロセスに参加させることができます。他の部門の同僚からのフィードバックがない場合、誰に手紙を書けばよいかを知っており、プロセスを手動で設定できます。ただし、そのような仕事には別のポジションが必要なので、会社の経営陣の承認を得る必要があります。

アクセスの問題も同様に解決されます。ほとんどの開発者は同じシステムとプログラムを必要とします。たとえば、フロントエンド開発者 (リポジトリ、スタンド、Jira など) の場合、標準のアクセス パッケージを作成して、少額の給与を要求する人を雇ってみてはいかがでしょうか。しかし、これには企業トップの意思も必要です。

したがって、チームリーダーの主要なスキルの 1 つは、問題の本質をビジネスに正しく伝えることができることです。ここにはいくつかの秘密があります。

• 一度では不十分です。最初の連絡後に問題が解決されることはほとんどないため、一定の間隔で経営陣のところに行き、「これはチームの士気を低下させています」「生産性が低下しています」と問題を思い出させる必要があります。

  
  

• チームの問題とビジネス上の利益がどのように関連しているかがわかった場合は、この箇所を参照してください。たとえば、重大なバグがあり、作業にかかった時間は数時間しかなかったにもかかわらず、修正に 2 日かかり、その結果、ビジネスは損失を被りました。あなたは経営陣のところに行き、ビルドの調整の問題について話し合います。このようなとき、企業は提案を可能な限りオープンに受け入れます。ただし、解決策はすでに準備されている必要があります。

ビジネスと同じ言語を話す

最も確実な方法は、経営陣に問題を持ち込む前に、その問題が会社にどれだけの損失をもたらすかを計算することです。

私はフロントエンド チームのリーダーとして、定期的に従業員からのフィードバックを収集しています。たとえば、開発者はタスクの説明が不十分であると常に不満を抱いています。このため、問題の作者が何を望んでいたのかを知るのに長い時間がかかります。次に、テスターが開発者のところに来て、何が行われたのか、正確に何をテストする必要があるのか、さらにその連鎖に沿って理解しようとします。その結果、誰もがそれぞれの方法で本質を理解したままになり、バグが発生します。

私が計算したところ、チームは平均して作業時間の 40% をバグの修正に費やしています。私たちはチームとともに遡及分析を実施し、これらのバグの半数は問題の本質を誤解したためにのみ発生したことがわかりました。つまり、タスクの説明が不十分であるために、開発者の作業時間の 20% が無駄になっています。これは管理者に連絡する必要がある番号です。それをお金に換算するのは簡単です。これはビジネスが理解できる言語と同じです。

チーム内に良好な環境を作り出す

人々がお互いに楽しく働くと、あらゆるやり取りがよりスムーズに進みます。なぜスクラムはこれほど人気があるのでしょうか?これは文書に関するものではなく、人々に関するものです。同僚が答えを文書化し、すべてを詳細に説明するまで 2 日間待つよりも、2 分間電話をかける方が効果的な場合があります。そのため、チーム内に相互理解と相互支援の雰囲気があれば、人々はお互いに連絡しやすくなります。たとえば、コードの一部を見つけましたが、それが何をするのか理解できなかったとします。チーム内の状況が良くない場合、電話して尋ねることを単に恐れるでしょう - 「彼は私が愚かだと思うでしょう。」

チーム内の良好な関係を維持するために、私は週に一度、1時間程度の電話会議を行っています。今回は3回に分けてお送りします。 1つ目は「リラックス」です。私たちはミームやジョークを共有します。 2 番目の部分は問題についての議論です。時々、私たちはミロで一緒にカードを投げますが、それは誰もが好むわけではありません。そうすることで、何が彼らの動きを遅らせているのかを正確に把握することができます。その後、解決策の選択肢を考え出し、経営陣に働きかけていきます。そして、私たちは再び「リラックス」して終了します。映画やその他のことについて話し合うことができます。このようなミーティングは前向きな雰囲気を生み出し、リーダーとしてチーム内にどのような痛みがあるのかを理解できるようになります。

代表者

新しいチームリーダーによくある間違いは、作業プロセスを自分自身に集中させることです。この場合、チームリーダーが急に病気になったり休暇に入ったりすると、作業が停滞し始め、常に引っ張られることになります。これを防ぐには、チームの誰かにチーム リーダーの責任の一部を実行するよう教えることができます。たとえば、月に 1 回タスクを配布するように他の人を信頼します。こうすることで、チームの他の誰かがこのスキルを持ち、チームリーダーは自分なしでは何も壊れないことを知って、落ち着いて休暇に行くことができます。

おそらくこれは、チーム リーダーの仕事を評価するための良い基準です。チームから外されたとしても、1 か月間は安全マージンが十分であるはずです。

チーム内で責任領域を適切に分散する

開発では、プロジェクトのリスクを管理するためにバス係数などの指標が使用されます。これは、プロジェクト全体を停止させるために、何人のチーム メンバーが架空のバスに轢かれなければならないかを示しています。バス係数= 1 の場合は、重大な問題が発生しています。

たとえば、私たちは複雑なプロジェクトを開発しています。洗練されたモジュールを備えており、その仕組みと処理方法を知っている開発者は 1 人だけです。この人が病気になったり、退職したり、休暇に入ったりした場合、このモジュールの変更は非常に時間と費用がかかる手順となり、プロジェクト全体に悪影響を及ぼします。これを防ぐには、他の従業員に複雑なモジュールやライブラリを扱う方法を徐々に教える必要があります。

チーム リーダーは、プロセスを 1 人に限定したり、プロジェクトにとって重要になったりすることなく、チーム内で責任を正しく分散できなければなりません。

プロジェクトの戦略的ビジョン

チームリーダーは、プロジェクトがどこに向かっているのか、どのような問題があるのか、そしてそれらをどのように解決するのかを理解する必要があります。たとえば、チームの総作業量は週 100 時間です。そして、企業は100時間すべてに自分の願いを投げ込みます。現時点では、プロジェクトに技術的負債が蓄積しており、これに対処する時期でもあります。チーム リーダーの仕事は、技術的負債が重大になる直前を追跡し、チームが現在の問題の解決に時間の一定の割合を費やすように管理者に働きかけることです。

チームリーダーとしてどのような問題に遭遇する可能性がありますか?

チームリーダーが警鐘を認識するために燃え尽きている理由を最初に知っておく方がよいでしょう。

業者側の誤解

これは最も一般的な問題で、毎月、経営陣に連絡を取ろうとし、問題と既製の解決策を考え出すのに、上層部は問題を未処理のまま放置するだけで何も起こらない場合です。理由はいくつか考えられます。 1 つ目は、ビジネスに対して間違った言葉を使っているため、アプローチを変える必要があるということです。 2つ目は、上司が「すべてを一番よく知っていて」、すべてを自分のやり方でやり続けるということです。この場合、最善の解決策は会社を変えることです。

財源不足

簡単な例: チームは常にタスクに圧倒されており、人手が足りなくなっています。中小企業には、新しい従業員を雇用するための資金がない可能性があります。この場合、システム アナリストの役割などの追加の役割を引き受けて、作業をより迅速に進めるためにタスクの説明を開始できます。大企業では、おそらく資金はありますが、意思決定の連鎖が長すぎます。また、第 3 レベルと第 4 レベルの上司の間を猫が通り抜けず、そのためにプロセスが停滞しないという保証はありません。ここでは、経営陣の誰かを自分の側に引き入れようとするか、ただ待つことしかできません。

仕事の成果が目に見えない

たまたま会社に来て、戦略を立て、計画を立て、仕事に情熱を注いでいたのに、時間が経っても何も変わらない、ということはあります。ここで落胆するのに時間はかかりません。「誰がこんなことを必要とするのか？」この場合、遡及分析を実施して、プロジェクトが進まない理由を理解できます。 「もしかしたら、私は間違った目標を達成し、間違った問題を解決しているのではないか?」と自問してください。

目標を達成するためのツールが不足している

これは、あなたがリーダーの立場に置かれ、責任を与えられているにもかかわらず、制御手段を与えられていないときに起こります。たとえば、独自にインタビューを実施して、チームに参加する開発者を募集する方法はありません。ここでの選択肢は 2 つだけです。企業に連絡して自分の立場を示すか、企業を変えるかのどちらかです。

上級管理職への直接アクセス

製品を開発し、チームの現在の問題を解決するには、チームのリーダーは意思決定者と常に連絡を取り合う必要があります。 「トップ」へのアクセスが閉ざされてしまうと、問題は解決されず、有望な開発戦略も語られず、働く意欲も失われてしまいます。燃え尽き症候群にならないためにも、経営陣と人間関係が築けないなら会社を変えたほうが良いでしょう。

永続的な緊急モード

場合によっては、タスクが多すぎて、チームが入ってくるフローに対処できなくなることがあります。常に緊急事態が続く状況では、通常の通話は背景に消えていきます。この時間をバグの排除に費やすことができるのに、誰がミームや空虚なおしゃべりを必要とするでしょうか。その結果、チーム全体が追い込まれるようになり、遅かれ早かれ力が尽きて人材が辞め始めます。チームリーダーができることは、人員を強制的に増員するか、タスクをキューに入れることだけです。

チーム内の雰囲気が悪い

これは、誰もがお互いを憎み合うすでに確立されたチームに参加した場合に発生する可能性があります。有害なコミュニケーションスタイルがすでにチームに根付いており、相互支援についての話はありません。そうなると、チーム全体を解散して、再度募集するしかない。

問題が何であれ、有利な結果が得られる可能性は常にあります。最初の失敗でも諦めないでください。少し待ったり、アプローチを変えたりする価値があるかもしれません。しかし、すべてを試してみて、何もない壁にぶつかっているように感じるのであれば、辞めるという決断が唯一の正しい選択となるでしょう。

結論

問題を解決する能力は、チームリーダーの重要な資質です。しかし、残念ながら、いつもうまくいくとは限りません。しかし、1 ～ 2 年は時間をかけていて、自分はそれに何の影響も及ぼせないと感じているが、成長したいのであれば、会社を変えることは悪い考えではありません。変化を恐れないでください。転職するのは普通のことです。