将来的にテックリードやエンジニアリングマネージャーを目指したいと思っていても、これまで「指示される側」としてしか開発チームに関わったことがなく、いざ自分がリードする立場になったときに、どんなリーダー像を目指せばいいのか分からない。実装の進め方やレビューの基準まで、細かく指示を出すのがリーダーの仕事だと考えていないでしょうか。
実は、開発チームにおいて成果を出しているテックリードの多くは、指示を出して管理するのではなく、メンバーが力を発揮できるように環境を整える「支える」リーダーシップを実践しています。この記事では、管理型のリーダーシップだけではうまくいかない理由と、メンバーを支えるリーダーシップの考え方・具体的な実践方法を解説します。
- 開発チームで「管理型」のリーダーシップだけでは、うまくいかない理由
- メンバーを「支える」リーダーシップという考え方
- チームが自分たちで動けるようにするための工夫
- リード職でなくても実践できる、支えるリーダーシップのあり方
<この記事もおすすめ！>
「管理する」スタイルのリーダーシップは開発チームではうまくいかない
実装の方針からレビューの観点まで、リーダーがすべてを細かく指示する進め方（管理型）は、一見するとチームを統率できているように見えます。しかし、開発チームにおいては、この管理型の進め方が思わぬ弊害を生むことがあります。ここでは、その理由を2つの観点から見ていきましょう。
細かく指示すると、メンバーが自分で設計判断する力が育ちにくい
たとえば、新しいログイン機能を実装する場面を考えてみましょう。
- 管理型の指示：
データベースのテーブル構成からAPIの引数の型まで、リーダーがすべて指定し、メンバーはその通りに実装するだけ - 起きること：
メンバーは「言われた通りに正確に作る」ことには慣れるが、「なぜその設計にするのか」を自分で考える経験が積めない - 結果：
次に似たような機能を任されたときや、リーダーが不在の場面で、自分で設計判断を下すことに強い不安を感じてしまう
変化の速い開発現場は、実装に近いメンバーの判断のほうが早いことが多い
もう一つの理由は、開発の現場では仕様変更や想定外の技術的制約が頻繁に発生し、その都度リーダーの判断を仰いでいると、対応のスピードが落ちてしまうことです。たとえば、連携している外部サービスの仕様が急に変更され、実装担当のメンバーがそれにいち早く気づいたとします。
対応方針の候補まで考えられる状態であっても、「リーダーの確認が下りるまでは動けない」というルールになっていると、確認待ちだけで半日以上の遅れが生まれることも珍しくありません。実装に直接触れているメンバーのほうが、リーダーよりも早く問題に気づき、対応の選択肢を把握できていることも多いのです。では、リーダーはどのような役割を担えばよいのでしょうか。
メンバーを「支える」、テックリードのリーダーシップという考え方
管理型のリーダーシップの限界を踏まえて現在注目されているのが、メンバーを管理するのではなく、支えるという考え方です。ここでは、この考え方を2つの視点から説明します。
テックリードの役割は指示することではなく、開発を妨げる障害を取り除くこと
支えるリーダーシップにおけるテックリードの役割は、実装の細部まで指示を出すことではなく、メンバーが開発を進める上で妨げになっている障害を取り除くことにあります。開発現場でよくある障害と、テックリードの動き方の例は次の通りです。
- 障害の例①：
本番相当の環境で動作確認したいのに、必要なアクセス権限の申請が数日止まっている → テックリードが担当部署に直接掛け合い、申請を進める - 障害の例②：
他チームとの仕様調整が停滞し、実装が前に進められない → テックリードが調整役を引き受け、方針を早期に確定させる - 障害の例③：
環境構築や依存関係のエラーで、そもそも作業に着手できない → テックリードが原因の切り分けを手伝い、詰まりを解消する
こうして障害を取り除くことで、メンバーは足止めされずに実装作業に集中できるようになります。
メンバーが設計で詰まっているときは、答えを出すのではなく質問で整理を手伝う
メンバーが設計や実装の方針で悩んでいるとき、支えるリーダーシップでは、すぐに答えを提示するのではなく、質問を投げかけてメンバー自身が考えを整理する手助けをします。たとえば、あるメンバーがデータの持ち方について悩んでいる場面では、次のような問いかけが有効です。
- 「このデータ、将来的にどんな条件で検索されることが多くなりそう？」
- 「今の設計だと、データの件数が増えたときにどんな影響がありそう？」
- 「他にどんな持ち方を検討して、なぜ今の案にしたの？」
答えを与えるより時間はかかりますが、メンバーが自分の頭で考えを整理し、次に似た場面でも自力で判断できる力を積み重ねていく上では、このプロセスが欠かせません。この考え方を、実際のチーム運営にどう落とし込めばいいのか、次に見ていきましょう。
チームが自分たちで動けるようにするための、具体的な工夫
支える考え方を理解した上で、実際にチームが自分たちで判断して動けるようにするための、具体的な工夫を2つ紹介します。
設計方針や優先順位の判断基準を共有し、細かいレビュー確認を減らす
すべての実装をリーダーが逐一レビューして確認する体制では、リーダー自身がボトルネックになってしまいます。あらかじめ、次のような判断基準をチーム全体でドキュメント化して共有しておくと、メンバーが自分の判断で実装を進められる範囲が広がります。
- パフォーマンスと可読性、どちらを優先するかの基本方針
- セキュリティやデータ削除に関わる変更は、必ずリーダーのレビューを通す
- 影響範囲が特定の機能内に収まる変更は、担当者の判断で進めてよい
こうした基準があらかじめ共有されていれば、メンバーは「これは自分の判断で進めていい範囲か」を都度確認しなくても行動でき、細かい確認のためのレビュー往復を減らすことができます。
失敗しても責められないという安心感を、日々の言動で示す
メンバーが自分で判断して動くためには、判断を誤ったときに厳しく責められるのではないかという不安がないことが前提になります。たとえば、リリース後に不具合が見つかった際の振り返りミーティングを例に、話し方の違いを比べてみましょう。
- 責める振り返り：
「なぜこの見落としに気づけなかったのか」と、個人の注意不足を問い詰める話し方 - 支える振り返り：
「次に同じ見落としを仕組みで防ぐには、どこにチェックを入れればいいか」に焦点を当てる話し方
こうした支える話し方を日々の言動で示し続けることで、メンバーは安心して自分の判断で行動できるようになります。ここまではテックリードの視点で説明してきましたが、支えるリーダーシップは、リード職でなくても実践できる考え方です。
支えるリーダーシップは、リード職でなくても実践できる
支える姿勢は、役職やポジションに関係なく、チームの誰もが日々の関わり方の中で実践できます。
後輩や同僚が相談しやすい雰囲気を、自分から作ることもリーダーシップの一つ
役職についていなくても、後輩や同僚が困っているときに気軽に相談できる雰囲気を自分から作ることは、立派な支えるリーダーシップの実践です。たとえば、後輩がコードレビューで厳しい指摘を受けて落ち込んでいる様子に気づいたときに、「そのミス、自分も入社したての頃によくやっていたよ」と一声かけるだけでも、相談しやすい空気が生まれます。
困っているメンバーに気づいたら、指示ではなく問いかけから始める
もう一つ実践しやすいのが、困っている様子のメンバーに気づいたときに、いきなり解決策を提示するのではなく、「今どのあたりで止まってる？」「どこまでは分かっている状態?」と、状況を一緒に整理するところから始めることです。すぐに答えを渡すよりも、こうした問いかけから始めるほうが、相手が自分の状況を言葉にする過程で、解決の糸口に自分で気づけることも少なくありません。
まとめ：引っ張るリーダーから、支えるリーダーへ
開発チームにおいて、実装のすべてを細かく指示する管理型のリーダーシップは、メンバーの設計判断力を育てにくく、変化の速い現場では対応のスピードを落とす要因にもなります。テックリードに求められているのは、指示を出すことではなく、開発を妨げる障害を取り除き、メンバー自身が考えて判断できるように支えることです。判断基準の共有や、失敗を責めない姿勢を日々の言動で示すことに加え、こうした支える関わり方は役職に関係なく、誰もが日常の中で実践できます。
