テクニカルリーディングに関する一考察

役割のバランスを見つけるために、雇用者は流動的な人事構造を採用する必要がある。技術職と管理職の道は隣り合わせでなくてはならない。心理的安全なしに、本当の効果的な成長を遂げることはできない。問題とシナリオについて話せる良きメンターは非常に貴重だ。これらは、Redgate Softwareでテクニカルリードを務めるJulia Hayward氏が示した、テクニカルリーディングに関する一考察の一部だ。

Agile in the City Bristol 2018で、Julia Hayward氏は1年間のテクニカルリーディングにおける内省について語った。InfoQでは、このカンファレンスをQ&Aとまとめ記事で紹介している。

テックリードになることがキャリアリスクを伴うものであってはならない、Hayward氏は主張する。理由を語らずとも、技術的業務に役割を戻せるべきだ。

Hayward氏は「技術リーダーとして、あなたは自らの影響を評価する必要があります。チームが生み出してきたものと、あなたなしでチームが生み出したであろうものとを比較しましょう」と語る。

あなたが自分のチームを信頼していないなら、それはリーダーとしてのあなた自身の問題だ。チームの問題ではない。それに対処するための解決策を見つけるために、彼女はコーチングを受けることを提案する。

講演の後、InfoQはHayward氏にインタビューした。

InfoQ: 開発者とマネージャとの間に亀裂をもたらすアンチパターンに少しふれていましたが、どんなものですか？

Julia Hayward: 一番大きな亀裂が生まれるのは、マネジメントと開発をまったく異なるスキルセットだと見なし、2トラック構成にしている企業です。つまり、有能な開発者を純粋に技術的な役割に縛り付けようとして、そうでない人に彼らを管理させるのです。私のキャリアの初めの頃、こうした状況に遭遇しました。私は「コーダーとして非常に価値がある」という理由で昇進を拒否され、後輩のセールスマンが私を飛び越えて昇進しました。もちろん、純粋に技術的な職に留まりたい開発者もいます。その人の意思に反して、管理的な役割を押しつけられることを私は望んでいません。しかし、このように2トラックのシナリオでは、「私たちと彼ら」という文化が生まれます。そこでは、十分な技術的背景なしに、多くの意思決定が下されます。開発者はより大きな責任を担う機会がなく、視野を広げてスキルアップすることができません。コミュニケーションエラーが否応なく発生し、疑念と冷笑を生み出します。

二番目のシナリオは、技術の人間がマネジメントの責務を担う機会はあるのですが、それが一方向のプロセスになっている場合です。役割の管理的な面が優位に立ち、技術的な面を排除します。また、地位や給与と結びついている場合が非常に多いため、新米マネージャがその役割に合わないと気づいても、技術的な役割に戻るのは非常に困難です。技術の人間がマネジメントに踏み出すことをリスクのあるキャリアステップだと考えると、たとえそれがポジティブな動きであっても、多くの人は引き受けるのを敬遠するでしょう。

InfoQ: そうしたアンチパターンに対する治療法は？

Hayward: 雇用者はもっと流動的な構造を採用して、人々が役割のバランスを見つけられるようにする必要があります。技術の人間には、自らのスキルセットを広げ、ある程度のマネジメント責務を担ってもらうことを奨励すべきです。ただし、安全な環境で。管理職の役割があるのは、価値を生み出す開発者のために尽くしサポートするためでなくてはなりません。そして、技術職と管理職の道は隣り合わせであり、成長するにつれてどちらの方向にもピボットできるべきです。

InfoQ: Redgateにおけるテックリードの役割は？

Hayward: 2016年の大きな組織変更のあと、Redgateは技術構造を完全に見直し、事実上ゼロから新しいテックリードの役割を考え出しました。私はテックリードとして、時間の半分を、自分のチームとのハンズオン（コーディング、コードのレビュー、サポート案件の調査など）に費やしています。残り半分は、ラインマネジメント、社内他部門との連携、チームの擁護、自己啓発の支援などが混ざっています。私は私自身の開発リードと非常に緊密に仕事をしています。彼は私のマネジメントスキルを伸ばす上で優れたメンターであり、私の技術的専門知識を非常に信頼してくれます。それは非常に興味深い役割で、私が楽しんでやれることを中心にキャリアが築けるように、そして徐々に知らないことに踏み出せるように、幅広い視野を私に与えてくれます。たとえば、Redgateが今年初めの社内カンファレンスにトライする機会を私に与え、優しくプッシュしてくれるまでは、自分がカンファレンススピーカーになるとは思いもしませんでした。

InfoQ: テックリードとしてどんな教訓を学びましたか？

Hayward: もっぱら技術的な役割から移る中、基本的に、主に3つの罠に陥りました。1つは、新米マネージャとして、私の人生は予測可能で線形なものではなくなり、私のレーダーに引っかかるタスクの範囲は急速に広がりました。当初は、人に任せるのが困難でした。安全にチームに任せられるのは何か、私のスケジュールに入ってくるのをどれくらい押し返す必要があるのか、わからなかったためです。タスクの相対的重要性について理解を深めている間、優先順位づけは1桁困難でした。私はたびたび、リンゴとナシを比べようとしている気持ちになりました。あらゆるものの価値を見定めて、積極的に自分の時間を守ることは、私にとって現在進行中の教訓です。

2つ目の罠は、非常にチャレンジングなコードを引き受ける熟練開発者でありたい、といまだに思っていることです。「自分でやればもっとはやいのに」という誘惑にかられるのです！ どれだけ素早く確実に機能を完成できるかで自らを評価するのをやめて、チームのアウトプットに対して自らの目に見えにくい貢献を評価するのは、難しいことでした。チームのためにより周辺の小さな技術的問題を細切れのスケジュールに入れて片付け、チームが非常に難しい問題に全力で取り組める環境を作り出すと、チーム全体がベストの状態で機能することを学びました。それに、彼らが絶対的に信頼できるドメインエキスパートに成長するのを見るのは、とても素晴らしい気分です。

最後に、私がその役割を引き受けたとき、楽しくないと思うあらゆる仕事からチームを守る、寛大なマネージャになるというビジョンを抱いていました。それが彼ら自身のスキルを磨く良い機会を与えていないこと、そして、将来のテックリーダーを考えている人に準備をさせるには、思慮深く任せることが重要であることを理解するのに時間がかかりました。また、今も自分の役割を楽しんでいることを確認し、自分の技術スキルが錆びついていないことを確かめ、自分の自己啓発に時間を費やす必要がありました。

InfoQ: チームにとって心理的安全を作ることがそれほど重要なのはなぜですか？

Hayward: 心理的安全なしに、本当の効果的な成長を遂げることはできません。成長するには、自分のコンフォートゾーンの外側に定期的に踏み出し、感情的に傷つきやすい状況に身を置く必要があります。私は自分のチームで実験を行いました。年齢別にチームボード上にポストイットで色分けして、彼らが先延ばしにしたタスクとその理由を理解しようとしました。チームが特定のアイテムを拾いたがらない要因の一つは、想定される失敗の影響でした。例えば、バグを拾ったのに自分の手に負えないことに気づき、みんなの前でそう言わなくてはならない、そんな人には誰もなりたくありませんでした。チームが完全に安全な環境にいるという自信を持つことによって、話題を提起するなど新しいスキルを使って実験し、成果が確実でないところで技術的なチャレンジをし、互いにずっとオープンになることができます。ふりかえりはずっと率直で誠実なものになりました。そして、私たちは2年前には敬遠していたであろう野心的なプロジェクトを試みています。

InfoQ: 技術的バックグラウンドと経験を持つ人が技術リーダーになりたいとき、どんなアドバイスをしますか？

Hayward: 自分のスキルセットを広げるために、あらゆる機会を利用しましょう。また、対人関係のスキルは難しいことを忘れないでください。問題やシナリオについて話せる良きメンターを持つことは、非常に貴重です。あなたが優れた開発チームメンバーなら、すでに知っていることの多くは、優れた技術リーダーになることへとつながります。現在、あなたが活躍できている環境について理解しましょう。なぜなら、あなたのリーダーとしての仕事は、そうした環境を再び作り出し、チーム全体が活躍できるようにすることだからです。個々の貢献者と同じくらい、チームの成功要因になれるように行動しましょう。そして、全員の成功を祝福することを学びましょう。チームが協力して大きなことを成し遂げると、最高の気分になります。たとえ、自分が一役買ったところはここだとはっきり言えなくてもね！