「全員がリーダー」のエンジニアチーム(前編)

Gergely Orosz
Uberのエンジニア。過去、Skype、Microsoft、Skyscannerなど、多くの成功企業でのエンジニアリングとリーダーのキャリアを持つ。自身のブログでは、成功した製品・プロジェクトを構築してリリースするための実践的なアプローチを発信し、多くの読者を得ている。
この記事は、著者の許可を得て配信しています。
https://blog.pragmaticengineer.com/a-team-where-everyone-is-a-leader/

次の記事: 「全員がリーダー」のエンジニアチーム(後編)

10年間、様々な企業でエンジニアとして働いてきましたが、ほとんどのソフトウェアチームには「マネージャー」と「技術リーダー」や「シニアエンジニア」がいるということに気付きました。こういった人たちは、すべてのプロジェクトをリードする意思決定者です。多くのエンジニアは、このような人たちに「どうしたらいいと思いますか」「次は何をしたらいいか教えてもらえませんか」と聞きます。そして許可を求めます。トップの人々に許可を取らずに先に作業を進めると叱られます。このような環境では、技術的なリーダーになることは他の人にとっては大変なことです。特に既存の技術的なリーダーがチームにいる限りはそうです。大企業では、優秀なエンジニアが別のチームでトップに立つ機会を得るために、社内でチームを入れ替えるのを見たことがあります。

エンジニアリングからエンジニアリングマネジメントになった際には、誰もがリーダーになれるチームを作りたい。誰もが主体主として行動できるようなチームを作りたいと考えていました。具体的には、メンバー全員がスキル、自信を持ち、エンパワーメント(個人の自律性を促進したり、能力を開花させたりすること)を理解し、率先して行動・意思決定をし、他のメンバーを導くことができるグループです。チームが問題に直面したとき「この問題を解決するために、私が先頭に立ってみよう」とそれぞれが考えるようなチームです。私がこういうチームを作ってみたいと思ったのは、それがより良い実行力、より仕事の速いプロとしての成長、そして人々がより長くチームに留まることにつながると信じていたからです。

当初、私が所属していたチームは、若い世代や自分よりも先輩の社員を含む8人のエンジニアで構成されていました。2年後には、その3倍の規模のチームの担当になりました。そのチームのほとんどの人が重要なプロジェクトを率いてきた人たちばかりです。より経験豊富なリーダーからメンターシップ/コーチングのサポートを受けています。プロとしての成長をし続け、元チームの8人全員が他の数人と一緒に次のレベルに昇格しました。辞めていく人も少なく、チームにいるのが好きな人が多いようです。

この記事では、チーム内でプロジェクトリーダーとしての責任をローテーションすることで、全員がリーダーとなるエンジニアリングチームを構築するために私が使用してきたアプローチとツールをまとめています。それには、私のチームが使用しているプロジェクト管理の予測 Google Docsガイドの共有が含まれています。また、このようなアプローチをしたことで、もちろん痛い目を見たこともありました。このアプローチがどれだけ普遍的に通用するかは、私には分かりません。しかし、私の結果に基づいて考えると、エンジニアリングリーダー、特にフロントラインマネージャーは、オプションとして考えることをお勧めします。

インスピレーション

より多くの人がチームを率いることができるようになるための私のインスピレーションは、主に3つの場所から来ています。個人的なニーズを満たしたい気持ち、本、ポッドキャストです。

個人的にずっと気になってどうにかしたいと思っていたのは、私がチーム内のプロジェクト管理のボトルネックになり始めたことです。私が2016年に入社したときは、それまで大きなプロジェクトを率いてきたエンジニアはほとんどいませんでした。私は、たくさんの経験を積んでからその企業に入りました。Skypeではスクラムマスター、Skyscannerではチームリーダーをしていました。私は、私たちの環境で十分に機能するプロジェクトマネジメントの基本的なフレームワークを設ける人になりました。しかし、同時に多くのプロジェクトを実行しすぎていることに気がつきました。Uberでは、当時プロジェクトマネージャーがいなかったので、他のエンジニアを巻き込むことにしました。最初の一歩として、私はエンジニアリング・プロジェクト・マネジメント・ガイドを作成しました。それから、プロジェクトのリーダーに数回指導をしたりもしました。

私が1チームに1人の 「メインの」テックリーダーの体制を打破するきっかけとなった本は「Turn The Ship Around」という本です。これは、海軍の大尉が、従来のトップダウンの作戦を、ボトムアップのイニシアチブ型に反転させた結果、軍隊の他のどのチームよりも優れた結果を得たという物語です。これは、実話に基づいた物語であり、原子力潜水艦の複雑な詳しい話も書かれていて、非常に読みやすい本です。隊長は一見取るに足らないような些細なことから文化的変革を始めました。命令をただ待ち、何も考えずにその命令に従うのではなく、すべての文章を「これとこれをするつもりです、なぜなら...」から始めるようにと部下に言い渡しました。

私の心に響いたポッドキャストは、ミシガン大学ロス・スクール・オブ・ビジネスの教授であるSue Ashford氏とのHBR IdeaCastのインタビューで、そのタイトルは「なぜ誰もが自分自身をリーダーとして見るべきなのか」です。彼女は共有されたリーダーシップについて学んだことや、このモデルを採用した組織がどのように効率的であったかについて語っています。特に印象的だったのは、「リーダーとしてのアイデンティティを持てば持つほど、リーダーとしてのリスクが減り、リーダーとしてのアイデンティティを身につけることができるのです」という部分です。

Sue氏は、物事の動きが速く、複雑で、多くの依存関係があるような場所では、共有型のリーダーシップが多くの利益をもたらすと言いました。このような場所では、リーダーのような行動をとる人の方が、効率的なのです。彼女が話していたことは、まさにソフトウェア開発についてのことのように聞こえました。彼女は、このような行動を促す方法を提案しました。「すべてのマネージャーは自分の周りのリーダーを成長させることができます。上に立つ人の戦略の一つとして効果的なのは、公共の場でアイデンティティを付与することです」これは、私が取ろうとしていたアプローチを裏付けるものになりました。

1つのプロジェクトには1人のエンジニアリングリーダー

私のチームは8人のエンジニアで構成されており、当時は2-3のプロジェクトを並行して進めていました。私が最初に決めたことは、1つのプロジェクトにつき1人のエンジニアリーダーを公表することでした。これは、主体性を明確にするために行ったもので、Sue Ashford氏が公共の場でリーダーのアイデンティティを付与することを提案していたのと似ています。私は、プロジェクトのリーダーに決定を下す自律性を与えたいと考えていました。しかしそれと同時に、下した決断にも責任を持ってほしいとも考えました。

エンジニアリングマネージャーとして、私はチームがプロジェクトを遂行する上でその言動に対する責任や節女責任を負う立場にあります。私は責任者として任命されました。どのように物事を進めるかを決定する役目です。しかし、説明責任も守りました。プロジェクトが失敗に終わり、誰かがトラブルに巻き込まれたとしても、それはプロジェクトリーダーではなく、私の責任です。

リーダーへの期待の設定

ここまでは、私はチームの特定のプロジェクトの「プロジェクトリーダー」でした。経験豊富なエンジニアの一人と次のプロジェクトのリーダーをお願いしたとき、彼らの最初の質問は、私が彼らに何を期待しているのかということでした。私はストレートな答えが分からなかったので、私が本当に求めていることは何なのか、自分の考えをまとめるために時間をくださいとお願いしました。

私は結局、チームが編集可能な文書に期待値をまとめることにしました。私が最初のバージョンを書きました。その後、チームは各プロジェクトの後にこの文書を修正することになりました。修正のほとんどは、追加したり微調整したりというものでした。これらは、私がプロジェクトリーダーにお願いした7つの待期項目です。

1. コラボレーション - コラボレーションのためのフレームワークを設定する。

2. マイルストーン(仕事を進める上で中間となる目標や、工程などの節目) - プロジェクトをマイルストーンごとに区切り、それぞれに見積もる。

3. コミュニケーション - プロジェクトの関係者プロジェクトの状態を伝える。

4. リスク - リスクを管理し、指摘する。

5. 任せる - チームの船を助け、(チーム全体や上にも)任せる。

6. 動機付け - プロジェクトが完了していないチームのモチベーションを高める。

7. 品質 - 出荷された製品の全体的な品質と信頼性を確保する。

マイクロマネジメントを避けるために期待値を設定することにしました。具体的に実行するようなことではなく、自分が求めている成果を設定するようにしました。例えば、私は毎日のスタンドアップミーティングを実行するのが好きで、これはいつもチームで行ってきました。しかし、これは私がリーダーに期待していた成果ではありませんでした。私は単にチームと定期的に情報をアップデートできることを期待していただけなのです。やり方やいつ終わるかは彼ら次第です。ミーティングをせずに情報を共有を好むチームもあれば、週に3回のスタンドアップミーティングを好むチームもあります。私は、彼らが選択できるアイデアを追加しましたが、彼らが望むものは何でも選択できるようにしました。

メンタリング、そして最初の数人のリーダーのコーチング

最初の数人のプロジェクトリーダーは経験豊富なエンジニアで、以前にプロジェクトをリードしたことがあるか、他の人がそうするのを見たことがある人達でした。私はすべてのチームの状況アップデートミーティングに参加し、新着状況を見ていました。私は、プロジェクトリーダーとの立ち上げ後のキャッチアップを頻繁に行い、フィードバックや提案を行いました。プロジェクトの初期段階では、プロジェクトリーダーとの1:1ミーティングを頻繁に行い、他のチームメンバーからのフィードバックを集めました。

プロジェクトが始まって数週間が経つと、新しいリーダーは自分の役割に違和感を感じなくなりました。彼らはよりイニシアチブを取り、私の役割はメンタリングからコーチングへと徐々に変化し、何の制約もない自由な質問をするようになりました。

毎週の書面による更新を通した透明性と説明責任

私のようなリーダーがプロジェクトのリーダーシップを任命する際に直面する課題は、物事が正しい方向に進んでいるかどうかを確認することです。プロジェクトの雲行きが怪しくなった場合でも、私には責任があります。しかし、私は、プロジェクトのリーダーが成長するためのスペースを与え、日々の業務に関わりすぎないようにしたいと考えていました。見守ってはいたいと思いましたが、干渉はしたくなかったのです。

リーダーやチームが自分自身に責任を持つように強力なツールの1つが、毎週チームから送られる短いメールで書かれたステータスアップデートでした。このアップデートには、次のマイルストーンに向けた進捗状況、前回とのプロセスの変化、前週の進捗状況がまとめられています。リスクや遅延については、緩和するための計画とともに明確に指摘されます。このアップデートは、私、主要な関係者、チームメンバー全員に電子メールで送信されます。

この文章による更新は、強力なプロジェクトリーダーを育てる上で欠かせないツールであることが分かりました。まず、対象となる関係者を念頭に置きながら、簡潔で良い文章を書く必要があります。エンジニアのリーダーの立場であれば、良い文章を書くことは重要なスキルとなります。第二に、それはプロジェクトのリーダーが、エンジニア的なマインドセットから一歩踏み出し、関係者が気にすることについて共感せざるを得なくなりました。プロジェクトの関係者は通常、マイルストーンの見積もり、それらの見積もりに向かって行われている進捗状況の根拠を気にします。リスクおよび規模の変更の場合には、関係者は規模の変更がビジネスのための変更であることを気にします。最終的に、関係者は頻繁にプロジェクトのリーダーに直接ping送信するのをやめました。こうすることで、リーダーが関係者を管理するスキルが強化されました。


コメントを読む

新着ピック  










山本 聡山本 聡8時間前フリーランスWebフロントエンドエンジニア




山本 聡山本 聡9時間前フリーランスWebフロントエンドエンジニア








新着ニュース

文書データ活用ソリューション「SPA」と手書き文字認識エンジン「DEEP READ」が連携したオンプレミス版を提供開始 | Ledge.ai

AIによるコンテンツ著作権侵害抑止サービス「RighTect」 | Ledge.ai

がんばっている企業を応援したい!最大3ヶ月無料『シフト作成応援キャンペーン』リリースのお知らせ | Ledge.ai

シリコンスタジオ、アイシン精機と「CEDEC2020」にて共同発表リアルタイム3DCGを用いた駐車場シミュレータ開発で協力 | Ledge.ai

ホークスを応援する四足歩行ロボ「Spot」とPepperのダンス、1分37秒の動画で見てみたら

新海誠監督の映画『天気の子』Ver.ピンクのスーパーカブが手に入るチャンス

セガから「アストロシティ ミニ」出ちゃうかもー!

ニコンが年内に新型ミラーレスカメラ、Z7sとZ6sを発表するかも

TikTokは米国での禁止に直面し、中国政府の統制が強まる香港からの撤退を発表 | TechCrunch Japan

オリィ研究所が分身ロボット利用の新しい働き方を開拓するプロジェクト公開、パイロットを募集 | TechCrunch Japan

JR東日本の公式アプリ、山手線駅の混雑予測に対応 まずは池袋・渋谷・秋葉原など27駅

ロボットが駅構内を消毒、荷物を搬送 JR東が高輪ゲートウェイ駅で実験

気象庁、公式サイトにWeb広告掲載で収益確保へ 「持続的・安定的な情報提供を維持するため」

AI+RPAで住宅チラシを自動作成 約2880時間分の作業を削減 オープンハウスが開発

[GCP]課金の有効化エラーに対応してみた | Developers.IO

[小ネタ] Cacooで描いた図を画像ファイルにエクスポートする際に「余白」を良い感じに付ける方法 | Developers.IO

1週間でスパコンを完全に理解する | Developers.IO

Fitbitのタッチ決済「Fitbit Pay」日本上陸--ソニー銀行のVisaデビットが対応

「わたしでもMEO対策ができた!」を実現する解析多機能ツールが本日発売 | Web担当者Forum

株式会社ブイキューブのHubSpot実践ノウハウ(第1回) 『失敗しないインバウンドマーケティングの始め方』 | Web担当者Forum

記事をPICKする
会員登録
Register
記事をPICKする

会員登録すると、もっと便利に利用できます。