小規模開発チームの作り方: メンバーとの関わり方

ある程度エンジニアとして現場に出ていると、マネージャー（またはマネージャー代理）としてチームを作るようになっていきます。最初は小規模な、2〜5人のチームを担当することになりますが、今回はマネージャーのファーストステップとして何をすれば良いかを紹介します。

二つの関わり方

マネージャーというのはチームを動かすことが仕事です。人を動かすコツがあるように、チームを動かすのにもコツがあります。（才能に依存しない、ということです。）

チームを動かす際、マネージャーとして二つ関わり方があります。

一つ目は点で関わるパターンです。よりマクロな視点で、例えばメンバー別に向き合い問題解決・ヒアリング・メンタリングを行うことを指します。
二つ目は面で関わるパターンです。チーム全体に向けた合意形成や方針伝達、文化づくりなどです。

今回は一つ目、メンバーとの関わり方を少し紹介します。

あなたが何かの施策を思いつき、それをチームで実践する方法を考えてみてください。行動を明示し実践させることはできますが、あまり質の高いマネージメントとは言えません。マネージャーは常に「チームの成長になるかどうか」「チームのモチベーションをつけれるか」という観点で、正しく委譲する必要があるからです。

チームの成長になる委譲というのは、

難易度は簡単すぎず、難しすぎない程度で
介入はあくまで萎縮させない

という観点を指しています。つまり委譲内容です。

チームのモチベーションをつけれるか、というのは

メンバーがその仕事の目的に納得感を持てるのか
メンバーの自己実現につながるのか

という観点を指しています。委譲方法・プロセスにあたると考えて良いでしょう。

一つずつ見ていきます。

委譲内容

難易度について

チームが得意とする領域や、まだ経験の浅い領域を分析することで、今後受け渡すタスクがチームにとってどれほどの難易度なのかを判断しましょう。

受け渡すタスクが簡単すぎると、単純作業となりチームの士気を削いでしまいます。難しすぎても、無力感や失敗体験によりフォローアップにコストがかかります。

丁度良い難易度を解説する前に、まずは観点をおさえましょう。難易度調整を気にする理由とは

メンバーの成長
モチベーションの維持
挫折の回避

つまるところどれも、未来のマネジメントコスト軽減に繋がります。この観点で、例えば自社サービスのコアチームに渡すタスクを考えてみましょう。

チームのスキルというのは大雑把に言えば「色々なベクトルに点在する経験値」ですが、カテゴリーに分けてみると

扱える抽象度の高さ
扱える技術（おそらく一番馴染み深いもの。純粋な実装力を指し、大抵のエンジニアはクリアしています。）
技術の選定能力の高さ（時間軸を考慮した技術選定や設計・実装ができるのか。技術の高さと混同されがちなので注意。）
抽象度を落とす能力の高さ（どれくらいの曖昧さから実装まで落とし込めるのか。適切な関係者に辿り着き、ヒアリングなどができるか。）

に大きく分けられます。丁度良い難易度を考える時には、

どの領域に伸び代があるのか
マネージャーとして、どの領域を優先的に育てたいか

を考慮します。

は数値化しづらいように思えますが仕事力は経験値に依存するので、試しにタスクなどをアサインしてリサーチするか、過去の仕事などを参考にある程度推論しましょう。エンジニアは技術力自体は過不足ないので、ここは遠慮せず広めに移譲しましょう。逆に時間軸を踏まえた設計や、他チームのヒアリング込みでの問題解決力は（ベンチャーやマネージャー職を経ていない限り）低い状態で始まることが多いので、最初はサポートを手厚くしましょう。
は、自分の今後の動きをどうしたいかもあわせて考えましょう。上に書いたカテゴリーは、私がマネージャーとして「チームに、今後こんな仕事を任せられると捗るな・メンバーも市場価値も上げられ、活躍幅も広がりそうだな」と考え重視しているポイントです。あくまで自分の理想像を常に考え、そこまでのパスとして便宜的にカテゴライズしてください。また、Googleによる記事（Google re:Work - ガイド: OKRを設定する）も参考にしてみてください。

新米マネージャーにありがちな動き方

マネージャーは人数的に少なくボトルネックとなりやすいため、現場に出る比率を落とし続ける必要があります。マネージャーになりたての人は、つい良かれと現場の仕事を総取りしがちですが、（PMFを目指している初期の段階などを除き）これはチームの成長やリソース分配、ポジションの仕事全てにおいて不適切なので注意したいところです。

介入について

ある程度の難易度での内容や渡し方を実践したとしても、都合よくとんとん拍子で仕事が終わることはありません。これ自体はコントロール不能なことであり、むしろ理想と現実を知れる貴重なフィードバックなので、どんどん受け入れて良いものです。

ですが、このフィードバックを受けた時の動き方は注意が必要です。下手をすれば1〜2ヶ月ほどチームの生産性にデバフをかけてしまうことになり、マネージャーとして酷いコストを背負うことになります。

チームに任せた仕事が期待通りでなかった時のアンチパターンをいくつか共有します

仕事を巻き取る
対処可能な内容に噛み砕かずに、ただネガティブな反応をする（何気ない一言から、感情の露呈まで幅広く。）

巻き取りについて

仕事を巻き取ることは最大級の介入で、メンバーの納得感を慎重に抑えないとモチベーションにかなり悪影響を及ぼします。（読者の中にも、突然巻き取られて不愉快な思いをした方は多いと思います。）

より専念したいタスクが他にあり、更に適任者が居る、というような場合は納得感のある巻き取り方ができるでしょう。納得感が必ず必要というのは過言に聞こえるかもしれませんが、悪意のあるメンバーが居ないという前提であれば、話し合いで納得させることができないタイミングで巻き取ってしまうのは、大抵「マネージャーの早とちり」となっていることが多いので気をつけましょう。

ネガティブフィードバック

ネガティブフィードバックは悪いことではありませんが、プロとしてフィードバックをする場合は必ず

自分が課題とする箇所はどこなのかを定める（事象と課題は別であることが多い）
課題とする箇所のうち、コントロール可能な部分を見つける
行動変容が可能な可能な部分のうち、変容までにかかる期間や難易度（コスト）を考え、優先度をつける
適切な場所やタイミングを決める。タイミングは問題が起こってからなるべく早く、できれば当日中がおすすめです。（メンバーのフォローにもなるからです）

問題とは、理想とのギャップのことを言いますが、まずは相手がこの「理想」「ギャップがあったこと」を両方認識しているかどうか確かめましょう。特に理想が伝わっていない場合は、日頃から期待値調整をするのもおすすめです。（私の場合は、毎週30分ほどの1on1で軽く伝えていますが、状況をみて声をかけてみることもあります。）

また、伝える前にある程度前捌きを行いましょう。「あなたの仕事は微妙でした」というフィードバックが無意味なのは、

意図している行動変容を起こさない
もはやマネージャー自身も何を求めているのかがわからない（言語化コストを一切払っていないから）
メンバーのモチベーションを傷つけてしまう

という理由からです。

問題があった場合は、上に注意し

自分が課題だと仮説を持っている箇所を決める
課題とする箇所はあくまで「マネージャーの力量で解決できる範囲」「観測・計測可能なもの」に絞り、解決方法は「短期、中長期」でカテゴライズする
その仮説を確かめるために、ヒアリングを行う
相手と、理想やギャップがあることの認識をすり合わせ、相手にも利益であることを伝え解決法を提示する
あくまで相手に解決法を選ばせる。つまり納得感が無ければあまり長続きしない&コミットメントが生まれないので、相手に決断を促す。

といった勘所をおさえておきましょう。

また、何か施策を行なったのであれば、その後の経過観察も行いましょう。施策が常に当たることはないので、望んだ通りの結果が出なくても焦らず、「自分の知らなかった相手の状況・特性」を知れるチャンスだと思い丁寧に方向転換をすると、ロスも少なく効果的です。

おわりに

今回は新米マネージャー向けに、「メンバーとの関わり方」を解説しました。

開発の現場とは違い、扱う問題の抽象度／視野／視座も徐々に変わり始め、最初は自信がなくなりますが、それはコンフォートゾーンから抜けている証拠でもあります。

実際「エンジニアリング」というのは、コードに限らず広義に「曖昧なものを整理し問題解決をする」わけですから、ある意味対人関係やチームをエンジニアリングする段階にあたります。これは非常に奥が深くインパクトが見込める仕事なので、ご活躍に役立てば幸いです。