- さまざまな分野の専門家が集まる環境では、リーダーは技術的な細部の知識よりも、問題をつなぎ、解決の方向性を定める役割を担う
- リーダーシップでは単なる技術知識より、翻訳力とソーシャルスキルが重要であり、対立する状況を調整し、共通の目標を強調しなければならない
- 重要なのは各自の深い専門性そのものより、実際の問題定義と解決の方向性を明確にし、議論がユーザーの要求と成果へつながるようにすること
- 効果的なリーダーは何でも知っているふりをせず、「分からない」と言う勇気を持ち、専門家たちが主体的に貢献できる場を整える
- リーダーの真の価値は、視点の翻訳、問題の文脈提示、協働の場づくりにあり、これは最高の成果を引き出す中核的な要素である
最近の気づき
- ひとつの会議室で、さまざまな分野の専門家である開発者やプロダクトチームと一緒に仕事をしている
- 私は特定の技術において最高レベルの専門性を持つわけではないが、リード開発者の役割を担っている
- 専門家たちの間でリーダーとしての私の役割は、すべての答えを知っていることではなく、答えを見つけて結びつける能力にある
Technical Leadership
- リーダーは技術知識の深さよりも、チーム間のコミュニケーションを活性化する効果的な翻訳者の役割を果たす
- バックエンド開発チームのスケジュール説明や、プロダクトチームの要件をそれぞれの視点から通訳し、チームの協働を引き出す
Leading is a Social Skill
- 技術的な信頼性だけでは十分ではなく、ソーシャルスキルこそが本当の生産性を生み出す
- 開発者同士の議論を読み取り、いつ議論を仲裁するか、あるいは前に進めるかを判断する能力が必要だ
- 効果的なコミュニケーションは文書だけでなく、積極的な対話によって成り立つ
Leading is Remembering the Goal
- 専門家ほど技術の細部に没頭しがちだが、リーダーは全体の目標に集中しなければならない
- 技術的な議論そのものではなく、ユーザー体験の本質的な問題とビジネス上の目的を明確に定義する役割が重要である
- 問題の本質を明確に定義しなければ、チームメンバーはそれぞれの分析方法に従って本当の課題を見落とす可能性がある
- リーダーには、チームが問題を正しく理解し、同じ目標を見るように翻訳する責任がある
Leading is Saying "I Don't Know"
- すべての答えを知っているふりをするより、"分からない、一緒に調べよう"という姿勢のほうが、信頼と開かれた文化を生み出す
- この姿勢は専門家たちに疑問や議論の余地を与え、それぞれが能力を発揮する機会を提供する
- リーダーはテーマごとの専門家に決定権と発言権を与え、議論を生産的な方向へ導く
- 2人の専門家が実装方法で意見を異にするとき、リーダーの役割は"正解"を選ぶことではなく、トレードオフとユーザーへの影響という観点で枠組みを与えることだ
The Translation Challenge
- リーダーは開発者の言語、プロダクトの言語、経営陣の言語を状況に応じて翻訳できなければならない
- 開発者: "認証サービスに適切なサーキットブレーカーがなければ、高負荷時に連鎖障害が発生する可能性がある"
- プロダクトチーム: "ログインシステムに問題が起きるとアプリ全体に影響するため、保護策の導入が必要で、スケジュールは1週間延びる"
- 経営陣: "このスプリントではシステムの安定性を優先し、ビジネスリスクを下げる"
- 専門家に他部門の言語まで学ばせる必要はなく、リーダーがその隔たりを埋める橋渡し役を担うべきである
Beyond "Because, that's why!"
- "自分がリードだからこうする"という決め方は、信頼と協働の文化を損ない、チームの生産性を落とす
- チームを対等な大人として扱い、判断の理由と文脈を明確に説明することが重要である
- "保守的なアプローチを選ぶ理由は、失敗したときのコストが高いからで、その後に繰り返し改善できる"
- "追加作業のように感じるかもしれないが、アーキテクチャ目標に合致しており、次の機能開発に役立つ"
- "この方法は最もエレガントな解決策ではないが、決められたスケジュール内で自信を持ってリリースできる"
- 専門性への執着を手放すほど、本当のリーダーシップの発揮が可能になる
リーダーがチームに提供すべき価値
- 明確な問題定義の提供
- 判断の文脈に関する十分な説明
- チーム間の視点の違いの翻訳
- 不要な複雑さからの保護
- 最良の結果のための環境づくり
結論
- 専門家組織における技術リーダーシップは、命令と統制を超えて、つなぐことと文脈を与えることに焦点がある
- リーダーは自ら楽器を演奏する奏者ではなく、オーケストラが一つの曲を完成させるのを助ける指揮者のような存在である
- これは、ただ部屋でいちばん賢い人になることよりも、はるかに興味深い挑戦である
4件のコメント
逆に考えると、専門家がいない環境では自分自身が専門家になるしかないのだと思います。
もちろん、技術的なリード以外のリーダーシップも発揮したいと思うことはありますが、知見の共有がうまくいかないチームメンバーに出会うと、それさえ難しいのが現実で、状況によって違うように思います。
素晴らしい視点ですね
こう働かなければならないと思った
Hacker Newsの意見
私はチームのリーダーとして、「自分がリードなので、こうすると決めた」という形の判断はできるだけ避けるが、必要ならためらわずに使うべきだと強調したい。全員の意見を聞き、慎重に判断するために時間をかける一方で、チームが本質的でない細部について終わりのない議論に陥ったときは、リーダーとして秩序を作らなければならないと気づいた。スティーブ・ジョブズが「みんなを幸せにしたいなら、リーダーではなくアイスクリームでも売れ」と言ったという話を思い返す。こうした場面が過ぎた後は、必ず信頼を再構築し、なぜそのように行動せざるを得なかったのかをチームメンバーに説明することが重要だ
私もこの教訓を苦労して学んだ。最初にマネージャーになったときは、いつも全員の合意を導き出せば自然にチームがまとまるとナイーブに考えていた。優れたチームでは最初はうまくいったが、その後、別のチームの25年前のやり方に固執するエンジニアたちと働くことになり、合意点を待つあまり多くの時間を無駄にした。結局、チームメンバーが十分に意見を述べた後には、リーダーが方向を定めて決断しなければならない瞬間が来るのだと悟った
私の経験では、数年間F50で働きながら似たような状況を経験した。3人のキーパーソンがいるドメインで、A案は見た目にはよさそうでも実際には多くの問題があることを私たちだけが知っていたが、説明してもチームを説得できず、結局は投票を無視して上司と話した末に正しい判断ができた。この過程で、実際に結果を直接引き受ける人が望む方向（C案）ではなく、多数意見（A案）に従うと、プロジェクトに問題や遅延が継続して発生することを痛感した。重要なのは、責任と結果を直接負う人たちは人気投票ではなく「拒否権」を持つべきであり、それによってプロジェクトに推進力が生まれるということだ。大規模プロジェクトでは複数のリードが各ドメインごとに意思決定を行い、行き詰まったときだけ上司が明確に決断すべきだ。リーダーが決断を避けると、誰もが不満を漏らすだけになり、チームの士気が深刻に低下するといういら立たしい経験をした
スティーブ・ジョブズがチームを一部屋に閉じ込め、共通のビジョンが見つかるまで議論させたという逸話も思い出す。全員を同じ方向へ導くのは難しいが、失敗すれば実行力は大きく落ちる。また、チームメンバーの意見を無視すれば、無視されたと感じさせてしまうので、結果が重要だとしても長く続けられるやり方ではない
「全員の声を聞くこと」と「全員に拒否権を与えること」はまったく別だという点が印象的だった。リーダーとして膠着状態を断ち切るのは不可欠な役割だと思う。もちろん、あらゆる問題でリーダーが決めなければならないのだとしたら、それは管理上の問題やモチベーションの問題、あるいはチームが戦略を理解していない兆候だ
私が好むやり方は、「もし自分が直接の担当者なら、どんな決定を下すか私に教えてほしい」と言うことだ。リーダーの役目は常に自分で決めることではなく、必ず決定が生まれるようにすることだ
私はこの分野で多少の専門性があると思っている。以前に3回も失敗していたプロジェクトのリーダーに任命され、各チームから選ばれた最高のエンジニア6人と一緒に働いた。全員がはっきりした意見と確かな理由を持っていたが、「失敗している敵を邪魔するな」という言葉になぞらえて、「友人が優れたことをしているときは邪魔するな」という姿勢を取ろうとした。「自分の担当でない部分なら、自分が得意な別の何かを作ればいい」という考え方だった。自然に役割分担が生まれ、互いに穏やかに影響を与え合い、あまり重要でない部分は完璧でなくても受け入れるなど、柔軟に進めた。結果として成功し、才能ある人たちが集まるチームの中で互いに学び合い、本当に議論が必要な部分にだけ集中する構造を作れたことをとても誇りに思っている
あなたの経験は、Servant Leadership（関連Wikiリンク）と呼ばれるリーダーシップに近いと思う。私が好むリーダーシップの形でもある
優れたエンジニアたちに過度に介入せず、彼らが主体的に自分のアイデアを展開できるようにするには、リーダーとして本当の信頼と自制心、そして自信が必要だと思う
プロダクトチームが「簡単な」機能を求めるたびに、私の頭には少なくとも3つのチームが必要で、それぞれのマイクロサービスを更新しなければならないという現実が浮かぶ。そういう意味で、現代のWebシステムが本当に嫌になることがある
ここでの問題は現代のWebそのものというより、「簡単な」機能1つが3つのマイクロサービスに分割され、依存関係が散らばっているアーキテクチャだと思う。結局のところ、より大きな原因はシステム設計の失敗だ
だとすると、ほかにどんな代替案があるのか気になる
私の経験では、「自分がリードだ」という発言は自信のなさのように見えることがあるので避けたほうがよく、むしろ情報をすべて集めて判断したうえで、「では、こう進めよう」あるいは「こうしてほしい」と自信を持って言えるべきだ
問題の核心は誤解ではなく、互いへの信頼不足だ。あるチームが何かに2週間かかると言うと、別のチームは1日で済む仕事だと思って信じない。十分な信頼があれば、相手チームのほうがその分野に詳しいことを受け入れられるが、現実には見積もりが本当に必要な作業量ではなく、余裕を確保するための計算ではないかと疑ってしまう。こういうとき、十分な説明と根拠を共有すれば信頼を高める助けになる
最近リード開発者に昇進してから1年ほど経った。自分の役割と責任が何なのか混乱していたが、原文に出てきた内容と似た考え方で働いてきたようで安心した。数日前には「非開発者の視点でチュートリアルを読む方法」という記事に触れて共感したが、自分が正しい方向に進んでいるように思える
私もソフトウェア周辺の製品開発チームで、リードが高圧的に引っ張った事例を3回経験したが、毎回よい結果にはならなかった。何度か自分でチームリードをやってみて、自分は「指揮官」ではなく「ハブと仲裁役」であるべきだと気づいた。チームメンバー同士の衝突があれば対立を解き、質問があれば不安を和らげ、アイデアが出れば実現可能性と価値を評価し、リソースが必要なら必要な相手が誰であれ探しに行けるよう助ける。問題が起きたら責任を引き受け、解決に向けてチームを励ます。こうしたことを学ぶのに10年以上かかった。私は最高の人間でもなく、自分の名前もたいていの人には知られていないが、チームの「一員」として働くときのほうが結果もよく、人材流出も少なかった。そしてリーダーとして「自分にもよく分からないが、一緒に答えを探そう」と言えることは本当に重要だと感じる。専門家に不確実さを許し、防御的にならないようにし、ひとりではないと感じさせられるからだ。以前のリーダーたちのもとで疎外感や交換可能な部品のように感じたことがある人は、どうか慰められてほしい。リーダーがチームを長くうまく導きたいなら、機械のように考えるのではなく、互いをきちんと思いやる姿勢が必要だと感じる
著者が本文の音声を自分で録音したことに感心した
「It's because that's why」というフレーズが好きだと述べつつ、この分野に関心があるならVanessa Van Edwardsの本は、状況に応じた温かさや専門性のシグナルをどう出すか学ぶのに役立ち、とても助けられたと紹介している。1人ですべての答えを出すのは難しいが、いくつもの前向きな経験があったという
意思決定については、「必ず決定が下されるようにすること」以上でも以下でもあると感じる。第一に、できる限りほかの人が自分で決めるようにしたほうがよい。Apple時代のJean-Louis Gasseeは、対立を持ち込んだマネージャーたちに、2人とも嫌がりそうな決定を下してみせることがあり、すると2人は自分たちで合意できる代案を見つけて戻ってきた、という逸話を語っている。第二に、すべてのメンバーが本当にその決定に納得するようにしなければならず、まず自分自身がそうでなければならない。これは風向き次第で動くタイプのマネージャーには非常に難しいことだと付け加える。法学生は常に慎重で分析的に考えるが、弁護士は断固として主張し、全員を説得する姿勢を持たなければならない、という比喩も出している。理想的に合意が得られるとは限らないので、顧客や成果目標のような具体的な基準点を置くと、意思決定を前に進め、実行を引き出しやすくなるという助言も共有している