開発チームにメンバーをアサインする時に考えていること

開発チームのマネージャーや、組織上の強い権限がある方はメンバーへプロジェクトや開発チームへの参加を依頼したり、ちょっとしたタスクをお願いすることがあるかと思います。基本的には手が空いていてお願いできそうかを何となく考えている気はしますが、改めて整理してみると学びがありそうです。最近どのチームの仕事を誰に任せるかを考えることが多かったので、今日はチームにメンバーをアサインするシーンで気にかけているポイントを自分なりにまとめようかと思います。

前提

自分が所属しているスマートバンクでは、チームで特定のミッションの達成を目的としたプロジェクトに取り組んでいます。

エンジニアが10数名の組織なので、プロジェクト3本（1チームのエンジニアが2 ~ 3名）程度をこなせるチームが存在している形です。今日のエントリーは上記の規模感のスタートアップチームが前提で teamtopologies.com に紹介されるStream-aligned teamへのアサインをイメージしています。

では、ここから3つのポイントについて触れていきたいと思います。

1. 要件を把握する

当たり前ですが、チームへの参加をお願いするにあたってどのような性質のプロジェクトなのかを把握していないと、適切な人選やメンバーへの説明責任を果たせないので、お願いする側が解像度高く取り組むべきイシューや開発する内容を押さえておくことが大事かと思います。

自分が実践している内容を振り返ってみました。

時間軸と規模感の把握

プロジェクトの起こり方はいくつかパターンがありますが、ほとんどが事業計画に根ざしたものに取り組むことになります、取り組む時期や内容は事業進捗を確認するMTGの場やステークホルダー（CEOの場合もあれば事業責任者、PM）と直接話したりして掴む様にしています。最低限、どの時期に何人ぐらいの開発者（チーム）が必要かをイメージし、社内で開発のケイパビリティがない場合は、既存メンバーで対応できる様に準備（育成）する、できる人を採用するなどのアプローチを考えます。
※ 少なくとも1年先ぐらいまで

Why の把握

スタートアップでは、取り組むべき課題や優先度が変わったりすることは度々あります、突発的にエンジニアをチームにアサインして欲しいというケースも実際よくあります。自分が納得したいというのもありますが、任されるエンジニアへの納得感や期待値にも大きく関わってくるので、優先度をあげる理由や狙いを把握するようにします、what / how までイメージできれば良いですが、自分の場合、ほとんどはチームに任せることが多いです。

開発箇所の把握

プロジェクトのアウトラインが掴めたら、ざっくりシステムのどの箇所に影響があるかをイメージするようにしています。これは影響箇所によって、適任のエンジニア（過去に影響範囲の開発に携わっていたなど）がいる場合があるからです。システム規模が大きくなると把握が難しくなってくると思いますが、どのコンポーネントを触る必要があり、どういったものを新規で作るのかをざっくり掴む様にしています。
※ 開発の現場から遠ざかりつつも、ある程度社内の開発事情をキャッチアップしておく必要がありますね

2.メンバーを知る

プロジェクトやチームへの参加に誰をアサインするか、適材適所なアサインを可能にするにはメンバーのことも知っておくことが大事でしょう。個人のスキルセットや、キャリアの方向性、興味領域、性格など細かく知るアクションが大事かと思います。自分はこのあたりの情報は 1on1 MTGでヒアリングするようにしています。

スキルマップの把握

スマートバンクではスキルマップを運用していて、技術要素とドメイン知識2軸で誰がどれぐらい把握しているのか、ざっくり分かるようにしているので参考にしています。新入社員が増えたり、技術ドメインが追加された時に更新するようにしています。

プロダクトの規模が大きくなるにつれて、認知負荷や認知限界が訪れるので早いうちに誰が何を知っていて、どういうことが得意なのかを可視化しておくと良いですね。任せたいチームの開発スコープに必要なドメイン知識（過去に担当した開発）が多いメンバーにお願いするという流れになるのが一番多いかと思います。

Will の把握

個人的には、ここを一番重視しています。個人がどんなことをやりたいか、何に興味があるかを知り、できれば参加する開発の中でそれとアラインできるようにするのが良いアサインと捉えています。やりたいことのレベルは、人それぞれだと思いますが、可能な限り 1 on 1 などで短期 / 長期的にやりたいこと、メンバーの思いを聞く様にしています。
※ 以下はアサインの一例です。

will	アサイン候補
複雑で難易度が高いアーキテクチャの設計がしたい	技術要件が複雑で、社内でも識者がいない開発プロジェクトへアサイン
インフラを触れる様になりたい	SREチームと共同で動くインフラとアプリ両方を触るプロジェクトへアサイン
入社したばかりなので、早く開発に慣れて成果が出したい	仕様が決まっていて、納期コントロールが用意、且つ開発難易度が高くないBugfixタスクをアサイン

また、自分は生煮えで、まだ組織上の決定ではない状態でも、自分の意見や組織の方向性などは可能な限り共有するようにしています。メンバーが持つ情報量が増えることの方がメリットがあり、やりたいことやTryしてみたいプロジェクトの参加に繋がりやすくなると思っています。こういった考えに至ったのは、下記の本を読んでの影響が強いので、興味ある方は読んでみることをオススメします。

ＡＬＬＩＡＮＣＥ　アライアンス

Amazon

3.アサインをイメージする

実際にチームを組成する際は、上記の1と2を重視している気がしますが、もう少し細かい要素がある気がしたので、書き出してみます。

社歴のバランス

これはシンプルに、社歴の浅いメンバーを社歴の長いメンバーと一緒のチームにするということです。ドメイン知識の移譲を目的にするのが大きいですが、新入社員は早く開発の現場に慣れてもらったり、信頼関係を構築してもらいやすくするといった意図もあります。逆にエンジニアが少なくても良いチームには、ベテランのメンバーが1人という状況もあるでしょう。

キャリアのバランス

こちらは上記とほぼ同じですが、キャリアが若いメンバー（新卒社員など）はOJTができるメンバーやフォロー気質が高いメンバーが揃っているチームがいいでしょう。

リード & フォローのバランス

メンバーの性格や気質的にチームのリードが得意な人もいれば、リーダーをフォローし助けるのが得意というメンバーもいると思います。プロジェクト課題の抽象度が高いチームであれば、What の部分に対してエンジニアが関わっていく機会も多いので、積極的な発言や開発の方針を明確にして進めることができるリーダー気質な人の方が向いているだろうとか、ある程度課題がクリアになっているチームであれば、POやPMを助けるフォロー気質のある人が向いているだろうというようなことも考えています。

まとめ

まとめると、チームにメンバーを決めるステップは概ね下記の要素のバランスで決めていました。

1. プロジェクトミッションを達成する上で必要な、スキルやドメイン知識が多い

2. 個人のやりたいことや、willにマッチしている

3. メンバーの社歴や気質のバランスがいいか

良いアサインをするために必要な要素を大雑把に振り返ってみました。もっと上段の話として組織戦略やビジョン（目標）、コミュニケーションパスをどうしていくかという議論が前提にあって、どのようなチームを組成するかが決まるので、今日のエントリーは一段ブレイクダウンした内容だと思います。

最近チーム編成や突発的なメンバーのアサインを考えることが多かったので、まとめてみましたが、良い棚卸しをする機会になりました。