炎上プロジェクトに既存メンバーと同数の新人をぶっこまれたときの話
こんにちは。マネジメントよりも開発が好きな Nash です。
この記事は「スマホゲームのバックエンドチームのリーダをしてたとき、既存メンバーと同じ数の新人をぶっこまれたときにした、施策・方針・結果についてのまとめ」の記事です。
先に概要の結果をまとめると、下記の通りでした。
-
【方針・施策】ドキュメント中心のコミュニケーション、新人にはスパルタ教育、既存メンバー保護を優先する方針。
-
【結果】さらなる炎上は防げたけど、心理的安全性を手厚く考えるべきだった。
では見ていきましょう。
※ ニューカマーがジョインするとチームに対して負荷がかかります。特に新人の場合は、なおさら負荷が高いので慎重に行うべきです。間違っても、既存メンバーと同じ人数を、同じタイミングで、しかも経験が浅い人を入れないように。全員が死にます。
炎上プロジェクトに既存メンバーと同数の新人をぶっこまれたときの話
先に背景について箇条書きで説明します。下記のような状況でした。
- すでにプロジェクトは楽しく炎上中。
- 既存メンバーはバックエンドの 3 人。
- 新たに新人がジョインすることになり、人数は 3 人。
というわけで、新人がジョインします。新人について下記みたいな感じです。
- 新人の力量はプログラミング始めて数ヶ月〜1 年くらいのレベル
- 新人の担当範囲はゲームの「バックエンド」＋「インフラを少し」
新人が入ってくるまでに少し猶予があったので、まずは方針を決めることにしました。
大方針は、既存メンバーを守ること
大方針は自分で勝手に決めました。**「既存メンバーを守る」**ことです。
すでにプロジェクトが炎上していて、既存メンバーは肉体的・精神的にそれなりに摩耗している状態です。 ここからプラスで時間的・精神的な負荷をかけると、ストレスでヤバイことになりそうです。
自分が過去に経験したプロジェクトでも「プロジェクトに新人を大量に入れられて、質問地獄に合ってストレスがヤバかった」という経験をすでにしていたのもあります。
というわけで、新規メンバーには申し訳ないが「既存メンバーを守ること」を最優先にしました。
この大方針のもと、方針・ルール・施策などを既存メンバーと会話して決めました。
１）ドキュメント文化によるコミュニケーション
新人から既存メンバーへの質問地獄を回避するために、基本的にドキュメント文化で進めることにしました。 つまり、口伝を中心にした暗黙知ではなく、ドキュメントを中心にした形式知でのコミュニケーションをメインにする感じです。
もちろん、口頭の方が速い内容は口頭で OK ですし、最初にレクチャーをするときなどは MTG ルームに集めてホワイトボード＋口頭で行いました。
ドキュメント文化にした理由
この方針の狙いの１つとしてコミュニケーションコストを減らすためです。
過去の経験上、「新人 → 既存メンバー」に来た質問内容ですが、まったく同じ内容を違うタイミングで「他の新人 → 既存メンバ」でも聞いてきます。
原因は、新人への説明漏れだと思いますが・・・。
いずれにしても、ドキュメント中心のコミュニケーションなら「既存メンバ → 新人」にドキュメントを配布すれば 1 回のコストで済む、という思惑です。
もし、新人が内容を忘れてもドキュメントを見返せば良いですし、質問に来られても「ここに、ドキュメントがあります。（リンク送る）」で一発で QA が終わるので、既存メンバーの負荷が少ないかと思いました。
ちなみに、今どきの開発現場ではどちらかといえば「口伝を中心にした暗黙知をチームで共有するには、どうチームビルディングするか？」などのマネジメントがメインな手法かと思います。
ただ、今回の大方針は「新規メンバーから既存メンバーを守ること」なので、心理的安全性や高度なマネジメントは捨ててドラスティックに進めることにしました。
QA は口頭よりも Slack
ドキュメント文化の延長として、QA は Slack を中心にしてもらうことを新人にはお願いしました。
狙いは下記の２つです。
- 質問のハードルを少し上げる
- 質問をブラッシュアップしてもらってから持ち込んでもらう
１の「質問のハードルを上げる」という点ですが、「なんかよくわからないですけど、動かないです」みたいな相談を過去に何度も受けたことがあり、その場合、既存メンバーの負荷がやばいので、質問のハードルをすこしだけ上げることにしました。
正直、心理的安全性が担保できないマネジメント方針なので、あまり好きではないチームビルディングですが。ただ、状況が状況なので、この選択肢を取っています。
２の「質問をブラッシュアップしてもらう」という点ですが、社会人経験が浅い新人だと、質問自体がまとまっていないケースが多いからです。「自分が何がわかっているのか？何をしたいのか？どこまで試したのか？何ができないのか？」など。「技術力が低い」とかは仕方がないですが、日本語力が低すぎて会話が成立しないという状況は避けたかったからです。そのため、「事前に文章化することで、自然とラバーダッキングが行われるのではないか？」を狙ってのルールです。
２）新規メンバーだけで自律的なチーム
また、新人メンバーだけでのチームとして機能することを目指しました。
理由は、新人メンバーの管理を行いだすとマネジメントコストが高くて自分の開発が全然出来ないからです。（自分はあくまで開発者のロールなんで、、、）
そのため、思い切って最初からチームを２つに分けました。
- 既存メンバーだけのチーム
- 新人メンバーだけのチーム
そして、新人チームの中でリーダーを決めて、その人が主導で新人チームの方針を決めることをお願いしました。
とはいえ、バックエンドチームとして統一すべき開発のフローなどは、自分から既存・新人メンバーに通達していたので、正確には２つのチームというよりも「既存チームの傘下に独立した新人チームを入れた」という表現が適切かもしれないです。
３）新規メンバーにはスパルタ教育
新規メンバーに対して、スパルタ方針にしました。（スパルタ教育という大義名分で、やや雑に扱うわけですね・・・）
ここまでに記載している通り、既存メンバー優先の方針にしています。例えば、新人がやや質問しにくい環境なのは、既存メンバー優先の理由だったりですね。
他にも、コードレビューの方針でも、最初から出来る限り全部を指摘する方針にしました。
コードレビューのレベル感を「最初は緩くして、徐々に厳しくする」でも良かったですが、今回は知識をガンガン詰め込む形にしました。間違った書き方やイケてないコードで OK を出すと、その書き方を今後も増やし続ける可能性が高い、などが理由です。
ここまでが、新人がジョインする前らへんに決めた方針・内容です。
新人には下記のような観点では説明するようには意識していました。
- 「なんでそう決めたのか？」
- 「新人たちには、こうしてほしい」
が、現場ではルールが増えたり変わったりしたのですべてを完全に説明しきれているかが、やや不安ですが・・・。（きちんと管理すればよかったです）
さて、これらの方針やルールでプロジェクトを進めて、結果としてどうなったのかをまとめます。
炎上プロジェクトに既存メンバーと同数の新人をぶっこまれた結果
結果として、簡単にまとめると下記のとおりです。
- 既存メンバーはストレスから守れた
- 炎上 → 大炎上 にならなかったので良かった
- 心理的安全性をもっと注力すれば良かった
では、見ていきます。
既存メンバーは守れた
先に結論ですが「大方針の既存メンバーを守る」は無事達成出来たかと思います。 ドキュメントや Slack を中心にしたコミュニケーションや、後述しますがチケット管理をプール制度にした結果、新人にかける手間がかなり減って、既存メンバーはだいぶ守れたかと思います。
もちろんトレード・オフとして新人メンバーには、やや辛い環境だったかもしれないことを考えると、申し訳ない点はありますが。 少なくとも当初の方針通りにことが進めれている点はよかったです。
また、「既存メンバーがストレスに晒されることがなかった」という意味の「守れた」もありますが、既存メンバーが新人メンバーに時間を激的には拘束されなかったので、炎上 → 大炎上にならなかったのも大きいです。
Slack での QA は難しい
結論、Slack ベースでの QA は、そこまでうまく機能しなかったです。おそらく、原因として下記あたりかと思います。
- 新人が、QA を作ること自体に時間が結構かかってしまう
- Slack への投稿に心理的安全が確保されていないので、気軽に QA が出来ない
質問地獄は回避できてはいるのですが、そもそもコミュニケーション自体が消極的になってしまったので、あまり良い結果ではなかったかな、と思っています。
色々と QA のフローを改善してみる施策を試していますが、どれもうまく機能してなかったので、次は「QA のフローをどうするか？」よりも根本的な解決を試してみたいと思っています。具体的には、「雑談を増やす」などのチーム内の心理的安全性を担保できるような施策を増やしてチームビルディングを図る、というようなものです。
厳しめのコードレビューは負荷が高い
コードレビューの厳しさを初期から厳しくしましたが、当たり前ですが、毎回指摘数が多いので新人側は精神的に負荷が高かったかと思います。とはいえ、1~2 ヶ月もすれば、指摘量もかなり減ったので、スパルタ式は悪くはない選択肢だったかと思います。
ただ、想定外だったのが既存メンバーもコードレビューをする時間的・精神的な負荷がかなり高かったです。
今回の経験と、後々調べてわかった知識なのですが、コードレビューをかなり真面目にやりだすと結構なコストがかかります。 また、レビュワーが複数いるとコードの宗教戦争が生まれやすいので、コードレビューに対しては、もう少し細かく方針を決めておくべきでした。
とはいえ、レビューを通して既存メンバー間のコードの考え方が文章化＋共有されて、「実は結構違う考え方を持っているんだなー」、という発見があったりしました。予想外なところで発見があった点も踏まえて、コストをかけた分、リターンは良かったかと思います。
チケットはプール制で、自主性に任せる
新人へのタスクチケットのアサインコストが高すぎたので、フローを変えたところ、うまく機能しました。
初期は既存メンバーが新人へのチケットのアサインを細かく行っていました。下記のようなフローです。
- その ①：既存メンバーがチケットの中から新人ができそうなチケットを探す
- その ②：既存メンバーが新人でも進められるようにタスクを細分化する
- その ③：新人にチケットを渡す
ですが、この工程だと既存メンバーのコストが多めだったのと、新人メンバーが既存メンバーがチケットを切ってくれるまで「待ちの状態」になってしまう、などの問題がありました。
そこで、新しく「プール制度」という形でチケットのフローを変えてみました。下記のようなフローです。
- その ①：プランナー・デバッカーから、タスクを既存メンバーに投げてもらう
- その ②：既存メンバーが、チケットに作業方針・優先度・難易度、などを簡単に記載
- その ③：このチケットを「誰も担当していない」というプールに放り込んでおく
- その ④：新人は、いつでもこのプールから好きなチケットを取ってタスクを進める
たいていのタスクはこのフローに沿ってみたところ、かなり快適にチケットフローは回り始めました。もちろん、影響度がクリティカルなものは、このフローには沿わないです。
また、今までは「貰ったタスクを、自分でこなす」だったのが、「自分でチケットを取って、自分でタスクをこなす」という行動の変化から、各々で責任感も芽生えたのかな？と思ったりもします。
新人チームにもっと口出しすれば良かった
新人だけのチームにつくりましたが、もっと口出ししても良かったです。
初期から「裁量権を与える」というのも、逆に選択肢が無限に広がるので、新人さんにはハードルが高すぎました。なので、「何を決めれば良いかがわからない」みたいな状態になってしまっていたように感じます。
新人だけのチームの主導権は新人だけに任せたかったので、口出しをあまりしなかったですが、悪く言えば放置しすぎてしまったように思います。
なので、もうすこし口うるさく指示出ししたほうが良かったように感じました。
ルールを無視する新人にテコ入れが出来なかった
これは、自分の反省です。
上述の通り、今回のチームの文化としてドキュメント・Slack を中心にしていました。ですが、ルールを無視する新人 A が居て、既存メンバー側にてヘイトとストレスが溜まってしまいました。
具体的には、下記みたいな感じです。
- 「ドキュメントを渡しても読まない」
- ⇒「オレオレの実装・行動や手順で行う」
- ⇒「バグや問題が生まれる」
大前提として新人 A の行動自体がナンセンスですが、それとは別に、おそらく、ドキュメントを読んでも頭に入らないタイプの人種、つまり、文章から内容を読み取る力が弱いタイプ、という人種がいるのかと思いました。
本来なら、ニューカマーのタイプに合わせて受け入れ側も柔軟に変えられば良いのですが、今回は状況がそれを許さないので、ただただ「新人 A が暴走して既存メンバーにストレスが溜まる」というイベントが何度も起きてしまいました。
何度も注意をしても行動を改めることがなかったので、既存メンバーに問題が飛び火しないように新人 A に対しては隔離するなど、施策を早めに打てればよかったです。
追記：「ドキュメントを読んでも頭に入らない人種」とかは、やはり人ごとにあるようですね。 あなたは文字派？ 聴覚派？ 6 つの「認知特性」ごとに最適な勉強法教えます！ - STUDY HACKER ｜これからの学びを考える、勉強法のハッキングメディア
新規・既存メンバーが溶け込むのに時間がかかった
端的に言えば、仲良くなるのに時間がかかってしまったような気がします。
方針として、チームは別個にする予定だったのもありますが、初期は新人に取ってはかなり心理的障壁の高いチームになってしまったのではないか？という点は否めないです。
日報という形で一日の最後に会話をするショート MTG を作っていましたが、あくまで業務の一貫という流れですね。
また、座席も既存メンバーと新人メンバーで正面にしてしまったのも良くなかったです。座席が人に与える影響から、正面は「敵対性」を生み出してしまいます。少しやりすぎ感もありますが、週次で座席を席替えして、出来る限り混ぜていけばよかったかもしれないです。
まとめ
Slack やドキュメントを中心したり、チームを分割して干渉を減らしたりししたので、コミュニケーションコストが減ったものの、少しドライすぎたので、チームとしての心理的安全性がかなり低い状態だったかもしれないです。
ドラスティックに効率性や合理性を中心にチームビルディングをすると、机上ではフローの最適化は行われますが、チームとしてパフォーマンスを出しにくい状態になってしまいます。
結論として、ドラスティックな方針だからこそ、心理的安全性を担保できる仕組みを導入するべきでした。
ただ、「炎上プロジェクトに既存メンバーと同数の新人をぶっ込まれたら、既存メンバーを優先でチームビルディングをする」という、大方針自体は良かったと思います。
なぜなら、仮に新人メンバーを中心にすると、
- プロジェクトが炎上 → 大炎上となる
- 既存メンバーがストレスで離脱
- 新人メンバーが回せなくてプロジェクト崩壊
という未来が想像できます。
そのため、次に同じ状況にあたっても、大方針は変えないとでチームビルディングをしていくと思います。
とはいえ、願わくば「次」が来ないでほしい限りですが。