マネージャーからマルチプライヤーへ: SOPA でチームをレベルアップ

エンジニアリング マネージャーの最も重要なタスクの 1 つは、他の人がより大きな成果を上げ、より良い成果をあげられるようにすることです。

よく使われる通常の例えは、自分自身を乗数と考えることです。チームに 5 人の開発者がいると想像してください。全員が 1 日に 1 単位の作業を行い、あなたが彼らを助けるために何もしなかった場合、チームとして 1 日の終わりには 5 単位の作業が完了します。

しかし、エンジニアが 2 倍の効率で仕事をこなせる办法を見つければ、あなたはエンジニア全員の3的倍率となり、エンジニアが 2 × 5 = 10 単位の作業を達成できるようになります。3的倍率が高ければ高いほど、チームで達成できる工作成效も大きくなります。

この記事では、この乗数を高めるための最良の步骤を表达できるように、私たちが考案した（これまでに収集したさまざまな观念を単純に組み合わせるだけで）一人の步骤をお勧めします。

この步骤は 4 つのステップで構成されます。

• 見る
• 観察する
• 優先順位をつける
• 活動

これらのコンポーネントを調べて、どのように適用できるかをよりよく了解してみましょう。

見る

物事の通体の中で自分がどこにいるのかを能够理解することは为重要です。これは、自分の影響範囲を知るのに役立ち、どの問題を这一に取り組むべきか、どの問題に取り組むのにもっと労力を要するかの優先順位を決めるのに役立ちます。この演習は十分に簡単です。少し时间はありますが、見ればとても馴染みのあるものに感じるでしょう。

このツリーでは、 Dunya が中心にいます。彼女には 1 人の直属の部下がおり、同僚のMichaelには 2 人の直属の部下がいます。Dunya とMichael はどちらもAllanに報告しており、Allan は 3 人の他のエンジニアリング マネージャーを管理しています。これらのマネージャーは他の多くの個人貢献者( IC ) を管理しています。

私たちは、あなたが影響力を行使できる度合いを表すために色分けを使用しています。あなたと 1 本の線でつながっている人々はL1です。これらの人々は、あなたが最も影響を与えることができる人々です。結局のところ、会社の CEO に助けを求めるよりも、同僚やチーム メンバーに助けを求める方が簡単です。

あなたから 2 行離れた人々はL2です。彼らに影響を与えることも可能ですが、そのためにはより多くの努力が必要です。上記の例では、 Dunya はIvanに影響を与えることができますが、彼女が望むことを強制する方法がないため、より多くの作業が必要になります。彼女は、Ivan に自分の望むことをするように影響を与えるために、説得、データなどを使用してIvanを説得する必要があります。

同様に、3 行離れた人はL3です。L3も影響を与えることはできますが、 L2 を説得するよりもはるかに多くの作業が必要になります。私の意見では、投資収益率が大幅に低下するため、これらのレベルに多くの労力を費やす価値はありません。

ここまで見てきたものは、と何ら変わりありません。唯一の違いは、プロジェクトとマークされた円です。企業内の人々は、報告ラインではなくプロジェクトを通じて互いにやり取りすることがよくあります。さまざまなチームの人々が協力するプロジェクト、移行、技術、労働力などが多数あります。このような取り組みは、楕円 (上のグラフ内) を使用して表し、その円を介してさまざまなメンバーを接続します。これにより、チーム間での個人の影響力の範囲を確認できます。上記の例では、 Bruno は同じプロジェクトで協力しているため、 DunyaのL2であることがわかります。したがって、ここでも、2 人を接続する線の数を数えているだけです。

この考え方は、誰かが同僚に与えた影響を理解するのにも役立ちます。パフォーマンスを考えてみましょう。L1、 L2 、 L3の指標を向上できた人は、明らかにより広い範囲に大きな影響を与えています。L3のみに貢献できた人は、間違ったことに集中している可能性があります (実際には自分のチームではなく、他のチームに貢献しているため)。また、 L1のみに貢献できた人は、まだ中級エンジニアである可能性があり、より大きな影響を与えるには影響範囲を拡大する必要があるでしょう。

観察する

組織内での自分の位置とやり取りの様子がわかったので、次はデータを収集し、専門知識を活用できる問題点を理解する必要があります。

集める

新しい会社に入社したり、チームを変更したりするたびに、私は必ずチーム全員（エンジニアだけでなく）と 1 対 1 で面談し、1 つの質問をします。

あなたにとって最もイライラすること、またはあなたのペースを遅くすることは何ですか?

この質問により、チームが不畏している极限の課題を能够理解することができます。これは、エンジニアリング マネージャーとして私が取り組むべき更重要な課題です。そうすることで、それらの問題を解決し、チームの研究成果を倍増させることができます。

すべての問題を集めたら、それをに入れます。さまざまなエンジニアから何度も聞かれる問題がたくさんあるでしょうが、それは問題ありません。次に、このデータベースに、カテゴリ、報告者、レベルという 3 つの列を追加します。カテゴリ列は、問題を論理的なカテゴリにグループ化するのに役立ちます。1 つの問題が複数のカテゴリに該当する場合があります。すべての問題が分類されたら、そのカテゴリの問題を聞いた回数に基づいてカテゴリを並べ替えることができます。レベル列は、この問題を聞いた影響範囲のレベルを示します。報告者列は、誰が問題を提供したかを思い出すのに役立ちます。

これにより、問題の発生頻度と、問題が発生するレベルについて差不多的な定义が得られます。

理解する

Observeの次のステップは、カテゴリを書き留めて、それぞれのカテゴリに対して( RCA ) を開始することです。RCAを実行するために任意の方法を使用できますが、5 つのなぜなどのシンプルな方法を使用することを強くお勧めします。5 つのなぜの考え方は、「なぜ」を 5 回 (根本原因を見つけるために必要な回数ではなく) 尋ねて、問題の根本原因が何であるかを理解することです。データベース内の人々と一緒にこの演習を行うと効果的です。幸いなことに、これはレポーターコラムに残されています。

この演習を実行すると、次のような結果が得られるはずです。

このマップにより、いくつかの問題の实际因为を確認できます。これらは、赤くマークされたツリーの葉になります。また、異なる实际因为間の依存関係を明らかにするのに役立つこともあります。

この視覚化は、問題とその根本原因を理解するのに役立つだけでなく、問題間の相互作用を理解するのにも役立ちます。上記の例では、「統合またはエンドツーエンド テストの過剰な使用」がツリーの 2 つの異なるブランチに影響を与えていることがわかります。つまり、この根本原因を取り除くと、かなりの症状が改善されるということです。

優先順位をつける

影響範囲を理解し、根本原因をいくつか収集したので、取り組むべき問題の選択を開始できます。そのためには、すべての根本原因を、よく知られているマトリックスにプロットします。これは次のようになります。

これは、何を優先すべきかを理解するのに役立ちます。また、 「参照」演習で使用した色分けも忘れないでください。基本的に、マトリックスを 3 次元で強化することになります。

結果のマトリックスを見ると、労力が非常に少なく、ある程度の影響があり、中レベルの影響範囲にも影響を与えるため、右端のチケットから始めるのではなく、左端の 2 つのチケットから始めるのがよいという結論に達するかもしれません。

活動

この時点で、私たちはエンジニアを支援するために何ができるかを知っています。また、これらの問題を解決することで会社にどのような影響があるかもわかっています。最後に、このような改善によって誰が影響を受けるのかについても明確に理解しています。

すべての準備が整ったので、あとは行動するだけです。