「それ、僕がやっておきますよ！」―その善意、マネジメントできていますか！？
「よし、任せてください！手が空いているので、僕がやっておきます！」
困ったときにすぐ手を貸してくれるエンジニアがいると、チームは本当に助かります。そんな頼もしい存在がいるとプロジェクトが順調に進んでいるように感じますが、実はそこに危険が潜んでいることもあるのです。
プロジェクト運営やチームの管理で、個人の善意や自発的な行動に頼る場面は意外と多いものです。一見すると助かるし、いい雰囲気に見えることもあります。
しかし、リーダーがそういう人に甘えていると、思わぬ落とし穴にはまる可能性があります。
今回は、そんな"善意頼み"がもたらす危険性と、それを回避する方法について掘り下げてお話ししたいと思います！
善意に頼るプロジェクト運営の危険性
開発現場では、こんなことがよくあります：
トラブルが起きたとき、Aさんが自主的に夜遅くまで残って対応。
Bさんが自主的に便利なツールを作ってチーム全体の作業をサポート。
Cさんが後輩のフォローにまわって、なんとかスケジュールに間に合わせる。
こういった行動自体は素晴らしいものです。
チームの誰もが「ありがとう！」と感謝します。
でも、これが続くとどうなるでしょうか？
① 計画が成り立たない
私が経験した、あるプロジェクトでの話です。チーム内にはゲームのエラーを自発的に調べて、適切な対処までしてくれるエンジニアがいました。
問題が起きるたびに、彼が率先して対応してくれるので、チーム全体が安心して仕事を進められました。一見すると、ヒーローのように見えます。
しかし、その作業は彼自身の担当業務には含まれていませんでした。また、彼はいつも遅くまで残業をしていました。その結果、予定していた本人のタスクが後回しになり、全体のスケジュールにも影響が出てしまいました。
なぜ、誰も彼を注意しなかったのでしょうか？
それは、彼がいつも遅くまで周りのサポートをしてくれているので、「スケジュールの遅れを注意するのは申し訳ない」という空気があったからのように思います。
このように、善意に頼るだけでは計画の整合性が崩れてしまうことがあるのです。
② 残業が当たり前になる
同じチームでの、別の例です。チームには、他のメンバーからよく相談を受ける先輩エンジニアがいました。彼はいつも親身になって話を聞き、適切なアドバイスをしてくれます。その結果、若手メンバーは安心して作業を進められていました。
しかし、彼の担当業務はそういったメンターではなく、「UIの実装」だったのです。週に５日実装作業をする前提でスケジュールの見積りをし、それをもとにタスクが割り振られています。後輩が相談に行けば行くほど、彼自身の作業時間は削られていました。
彼は笑顔で「大丈夫ですよ」と言いながら、いつも遅くまで残業していましたが、日に日に疲れが見え始めていました。どれだけ優秀でも、限られた時間内で全てをこなすのは難しいものです。
先ほどの例とは異なり、彼は残業によって自分の作業をしっかりスケジュール内に終わらせていたので、問題にはなりませんでした。しかし、疲弊は大きかったのではないかと思います。
③ 雑用の押し付けにより、不公平感が生まれる
また、善意で対応しているうちに、いつの間にかその人が「担当者」として扱われるケースもあります。例えば、あるエンジニアがサポート業務を積極的にこなしていると、次々に依頼が舞い込むようになり、本来の業務時間がどんどん削られてしまっていました。
一時的にサポートをしている仕事内容が、その人の希望の仕事では無かったり、スキルアップにならない可能性があります。
「あの人ならやってくれる」という期待が積み重なることで、「良い人」に雑用が次々と押し付けられると、不公平感が生まれてしまうのです。
このような状況が続くと、チーム内のモチベーションにも悪影響を及ぼします。
善意を計画に組み込む方法
では、どうすればいいのか。善意を適切に活かすためには、工夫が必要です。
① 工数をちゃんと確保する
例えば、あるプロジェクトでは、
「全員、週に1日はサポート業務に充てる時間を作ろう」
というルールを導入している話を聞きました。
ツール作成や後輩フォローといった善意の行動も、計画の一部として取り入れるのです。
また、私がリードプログラマーを担当した時には、ミーティングへの参加、コードレビュー、後輩のメンター等をメインの業務として時間を事前に確保しておき、実装作業は隙間時間でできるような小さな作業だけに留めていました。
もし、こういった業務配分ができないほど人が足りていないのだとしたら、それは人数に対するプロジェクトの規模が間違っている、と考えています。
② 明確な役割を作る
特定のメンバーだけに負担が集中しないよう、役割を分けることも大切です。例えば、以下のように決めることができます。
開発環境を整えるエンジニアを専任で設置する
メンターやコードレビューも業務として、工数に計上する
ゲームの不具合チェックと報告はデバッグチームに任せ、対処は実装者本人の業務とする
「困ったらFさんに相談しよう」ではなく、「このタスクはGさんの役割」と明確にすると、全員が動きやすくなります。
残業に頼らない文化を作る
残業前提で計画を立てるのは、やはり避けるべきです。
① 残業しなくても回る仕組み
例えば、プロジェクトの計画段階で「本当に必要なタスク」だけを洗い出し、無理なく定時内で終わるスケジュールを作ること。これを意識するだけで、チームの負担がかなり軽くなります。
② 残業時間をインプットに充てる
どうしても残業をしたい！仕事をたくさん頑張りたい！という人がいる場合は、残業時間をアウトプット（作業）ではなくインプット（学習や分析）に使ってもらうことを、私は推奨しています。
例えば、以下のことがあります。
技術書を読む
社内のテクニカルレポートを読む
CEDECやGDCの公演を見る
他社のゲームを遊んで研究する
世の中の技術も、ゲームのトレンドも、目まぐるしい速度で変わっていきます。アウトプットを頑張るだけでは、いつの間にか時代から取り残されてしまうかもしれません。
開発環境エンジニアの重要性
チームが大きくなると、開発環境を整える専門職の重要性が増します。
① 効率化の影響が大きい
例えば、100人規模のチームで「毎日1人10分の作業を自動化するツール」を作ったら、全体で16時間の節約になります。こうした効率化を進める専任ポジションがあるだけで、善意に頼る状況がかなり改善します。
② 適切な人数を配置する
個人的な経験では、100人規模なら2~3人、300人規模なら4～6人の開発環境エンジニアが必要でした。（もちろん、担当者の能力によって必要人数は変わります）
専任の開発環境エンジニアがいると、チーム全体の負担がぐっと軽くなります。
まとめ
善意だけでプロジェクトが回っているように見えたら、いったんその人には感謝しつつも、マネジメントとしては危険信号だと考えています。
その状態を放置せず、以下のような取り組みを進めましょう：
善意の仕事を計画的に実行する。
専任者を配置して負担を分散する。
残業に頼らない文化を作る。
これらを意識するだけで、チーム全体の働き方が大きく変わると思います。
気に入っていただけたら、ぜひフォローしていただけると嬉しいです！
Xでも情報発信をしていきますので、よかったら覗いてみてください！