技術リーダーとして学んだ意外な教訓

みなさん、こんにちは！しばらく執筆活動を休止していましたが、また執筆活動に復帰し、調子を取り戻そうとしています。このスペースで共有する経験は、私の学問的および職業的経験に基づいていることを強調したいと思います。したがって、ここで説明されている内容は現実のほんの一部に過ぎず、特定のプロセス、手順、またはサービスの決定的な公式として解釈されるべきではないことを覚えておくことが重要です。

私は現在、自分のキャリアのこの新しい段階にとても興奮しています。私は多くのことを学びました。そして、この旅の一部をコミュニティと共有したいと思っています。ここで提示する情報が読者にとって非常に価値のあるものになることを願っています。

人材第一 - ソフトスキルの重要性

数年前、初めて選考プロセスに参加したとき、人事担当者との面接、実技試験、技術リーダーとの面接、そして最後にマネージャーとの面接という、ほとんど退屈な手順を踏んだことをはっきりと覚えています。開発者としてのキャリアを通じて、さまざまなモデルとの面接を何度か受けてきました。当時は、人事担当者との面接にいつも居心地の悪さを感じていました。その理由がよくわからず、「技術試験で求められていることができれば、そのポジションに十分な能力があることを示している」と考えていました。

技術開発リーダーとしての役割を引き受けたとき、私の責任の 1 つは、バックエンド領域で働き始める 2 人の候補者に対する技術テストの準備と面接形式の定義において、人事部 (そう、私が選考プロセスに参加する理由を理解していなかった同じ人々) と協力することでした。バックエンド領域の初心者開発者が何を提供するべきか、テストで何が差別化要因と見なされるかはすでにわかっていると思っていました。しかし、コードの重要性にもかかわらず、プロジェクトの実施以外にも、コミュニケーションの観点から候補者を評価する方法、候補者がそのポジションにどのような関心を持っているか、候補者が示す状況が提案されたポジションへの適性にどのように影響するかなど、他の要求が生じたことは予想していませんでした。これらの質問やその他の質問は、両方の候補者が提示したコードと同じくらい重要であることがわかりました。これは、開発者としての初期の頃には考慮したことのなかったことです。

最終決定を下すために会議のテーブルに着いたとき、各候補者の技術的スキルについてほとんど議論されていないことに少し驚いたことを覚えています。その理由の一部は、彼らがエントリーレベルの候補者であったため、技術的スキルがそれほど発達していないことは予想されていたためであり、この点は議論の主な焦点ではありませんでした。

しかし、より高度な求人、特に上級レベルのポジションの場合でも、コミュニケーション、文書作成、適応性、積極性、その他よく挙げられるスキルを考慮することが重要です。これらのソフトスキルは基本的なものであり、技術的なスキルに加えて、その役割で成功するかどうかの決定的な要素となる可能性があります。実際、これが私の次のポイントです。

ジュニアとシニアの境界線（いいえ、ミドルレベルではありません）。

「シニア」などの経験レベルに関連する用語の意味と分類については、多くの議論があることは承知しています。「シニアは経験年数で定義される」と言う人もいれば、「会社によっては 1 年でシニアの経験が得られる」と主張する人もいます。また、「ジュニアとシニアの間に明確な区別はない」や「シニアはコード レビューと PR の承認のみを行う」と言う人もいます。これらの発言の中には滑稽なものもあれば、一理あるものもあります。実際、「シニア」の概念は非常に多様であり、普遍的な基準を定義するのは私の仕事ではありませんが、より個人的な方法でこの分類を理解するためのガイダンスを提供することはできます。

シニアになるには、技術的な知識だけが必要なわけではありませんが、これは間違いなく非常に重要です。真のシニア、または少なくとも優れたシニアとは、コードとシステム アーキテクチャの両方の観点から複雑な問題を解決できる人です。コードの品質を維持し、優れた開発プラクティスに従い、プロジェクト管理の知識を持つことは、非常に重要な側面です。

重要な違いは、シニアはこれらすべてを自律的に実行でき、さらに重要なことに、さまざまなレベルや部門のチームと協力して、可能な限り最高のプロジェクトを実現できる必要があることです。さらに、真のシニア (少なくとも最高のシニア) は、チームを率いて指導するだけでなく、他の開発者を育成し、新しい役職や責任を引き受けられるように準備します。

プロジェクトを率いた初めての経験

最初のプロジェクトを引き受けたとき、上司は私がこれまでに他のプロジェクトを率いたことがないことを知っていました。私は開発に参加し、経営陣とのコミュニケーションの面で開発を促進するいくつかのことを検討しました。彼が私に尋ねた最初の質問は、 「プロジェクトを補完するには何人の人員とどのような人材が十分でしょうか」でした。すぐに答えはわかりませんでした。非常に複雑な質問でした。プロジェクトは概要のみだったため、スタック、各タスクの完了にかかる時間、および上位の人々が関心を持つその他の指標について何もわかりませんでした。翌日に提供できるように、いくつかのプロジェクト管理方法論（Pert、Planning Poker）を徹底的に調査し、最も適したものを共同で選択して、挑戦が始まりました。チームの各メンバーにとって、最適な開発プラットフォームは何か、使用する最適なスタックは何か、システムアーキテクチャはどのように機能するか、市場の他のソリューションを研究し、各開発者のレベルを監視し、経営陣との会議、会議、さらに会議を行いました。

いつの間にか、私はコードからどんどん遠ざかっていました。私の役割は、プロジェクトが機能するように、または少なくとも開発者が開始するための強固な基盤を提供するために、改善を提案し、いくつかの重大なバグを修正することになりました。残りの仕事は、開発者とのコミュニケーション、タスクの分割、指標の監視、そして基本的に、片方の目は Asana (プロジェクトの納期を見積もるため) に、もう片方の目は Meet に目を配り、マイクがオンになっていないこと、不要なものが「誤って」漏れていないことを確認することでした。

結論と過去を振り返る - 愛情を込めて主人へ

私は開発インターンとしてキャリアをスタートしましたが、興味深いことに、そして少し矛盾しているように思われるかもしれませんが、ジュニア、フル、シニア開発者として分類されるような具体的な経験がありませんでした (少なくとも雇用記録に正式に記録されていません)。私が得た経験の多くは、個人的なプロジェクトや大学での研究から得たものです。それは、自分のスキルが初期の頃から進化していることに気付くまで、徐々に進んだプロセスでした。

しかし、確かに私はさまざまなレベルの開発者として熱心に働き、キャリアを通じてさまざまなタイプの上級専門家に会う機会がありました。

1. 非常に有能で有能な上司だが、コミュニケーションが取れず、自分のアプローチについて説明せずに問題を解決した。
2. 先輩はコミュニケーション能力と指導能力に優れていますが、緊急の業務に圧倒され、指導する時間がないことがよくあります。
3. 過剰なエンジニアリングと技術の集中化に熱心だったが、期限を守り、約束したことを実行した先輩。

最も重要なことは、正当な欠点があるにもかかわらず (可能ではありますが、要求のバランスを取るのは非常に困難です)、これらの専門家全員が貴重なことを教えてくれたことです。これらの経験は私のキャリアの形成に役立ち、システム開発で何が機能し、何が機能しないかを明確に理解することができました。