「チームが大きくなるにつれて、うまく回らなくなってきた」
組織を大きくする過程で、こういう壁にぶつかるリーダーは多いです。
私は現在、社員とBP（ビジネスパートナー）合わせて20名のチームを統括しています。最初からこの規模だったわけではありません。少人数から少しずつ拡大してきた経験があります。
チームをスケールする過程で、うまくいったこと・失敗したこと、両方がありました。
今回は、運用保守チームを20名規模にスケールしていく中で学んだことを、具体的に話します。
運用保守チームのスケールが難しい理由
まず、なぜ運用保守チームのスケールが難しいのかを整理します。
1. 属人化が起きやすい
運用保守の仕事は、特定のシステムや顧客を長期間担当することが多い。自然と「このシステムはAさんしかわからない」「この顧客はBさんしか対応できない」という状態が生まれます。
チームが小さいうちはこれで回りますが、スケールしようとすると一気に限界が来ます。
2. 採用・育成のコストが高い
インフラエンジニアは即戦力の採用が難しい。育成には時間がかかる。かといって育成に時間をかけると、日常業務が回らなくなる。このジレンマがあります。
3. コミュニケーションコストが増大する
5名のチームと20名のチームでは、コミュニケーションの複雑さがまったく違います。情報共有の方法、意思決定の仕組み、報告ラインの整理——これらを意識的に設計しないと、チームは機能不全に陥ります。
私がやった6つのこと
①まず「属人化の見える化」から始めた
最初にやったのは、「誰が何を知っているか」の棚卸しです。
各メンバーが担当しているシステム・顧客・業務を一覧化しました。これをやると、「このシステムはAさんしか知らない」というリスクが可視化されます。
見える化することで、「次に誰に何を教えるべきか」の優先順位が自然と決まります。
②手順書・ドキュメントを整備した
属人化を解消するには、「人の頭の中にある知識」を「誰でも参照できる形」にする必要があります。
最初は大変ですが、手順書が整備されると新しいメンバーが入ったときの立ち上がりが早くなります。私のチームでは、定型作業はすべて手順書化することをルールにしました。
手順書作成のポイントは「誰が書いても同じ結果になること」です。曖昧な表現をなくし、スクリーンショットや具体的なコマンドを入れる。これだけで、手順書の質が大きく変わります。
③「1次対応できる人」を増やした
少人数チームのときは、ベテランが障害の1次対応もやっていました。でもチームが大きくなると、これがボトルネックになります。
私が意識したのは、**「1次対応は誰でもできる状態にする」**ことです。
そのためにやったのが、「障害対応フロー」の整備です。「このアラートが出たら、まずこれを確認する」「この状況になったら、誰にエスカレーションする」という判断基準を明文化しました。
これにより、経験の浅いメンバーでも1次対応ができるようになり、ベテランは2次対応・根本原因の分析・顧客対応に集中できるようになりました。
④顧客の難易度でチームを3つに分けた
20名規模になったとき、「全員が全顧客を担当する」という体制に限界を感じ始めました。
顧客によって、システムの複雑さ・障害頻度・対応難易度がまったく違います。難易度の高い顧客を経験の浅いメンバーが担当すると、対応品質が落ちる。かといってベテランだけに集中させると、ベテランが疲弊する。
そこで私がやったのが、顧客の難易度でチームを3つに分け、それぞれにリーダーを置くという体制変更です。
- チームA：難易度高・複雑なシステム・障害頻度が高い顧客を担当。経験豊富なメンバーで構成
- チームB：難易度中・標準的な運用保守が中心の顧客を担当。中堅メンバーで構成
- チームC：難易度低・定型作業が多い顧客を担当。経験の浅いメンバーの育成の場として活用
各チームにリーダーを置いたことで、私への相談・報告が集中する状況が解消されました。「50社のすべての顧客について私が把握している」という状態から、「各チームリーダーが自チームの顧客を把握し、私はチームリーダーから報告を受ける」という形に変わりました。
また、チームCで経験を積んだメンバーがチームBへ、チームBで力をつけたメンバーがチームAへ、というキャリアパスも自然に生まれました。
⑤BPとの協力体制を整えた
20名のチームのうち、社員だけではなくBP（ビジネスパートナー）も含まれています。
BPをうまく活用するポイントは、**「社員と同じ情報を持ってもらうこと」**です。
「社員だけが知っている情報」「BPには教えない情報」という壁を作ると、チームとして機能しなくなります。セキュリティ上の制約がある部分を除いて、情報はできるだけオープンにする。これがBPとの協力体制を作る基本です。
⑥「報告・連絡・相談」のルールを明文化した
チームが大きくなると、「誰が何を知っているか」「誰に何を相談すればいいか」がわからなくなります。
私がやったのは、報告・連絡・相談のルールを明文化することです。
- 障害発生時：第一報は〇分以内、報告先はリーダー
- 作業完了時：チャットで完了報告、証跡を添付
- 判断に迷ったとき：まず自分の考えを整理してからリーダーに相談
ルールを作ることで、メンバーが「これはどうすればいいんだろう」と迷う時間を減らせます。
スケールする過程で失敗したこと
うまくいったことだけでなく、失敗したことも正直に話します。
採用を急ぎすぎた
顧客が増えて人手が足りなくなったとき、焦って採用を進めたことがありました。スキルより頭数を優先した結果、育成コストが想定以上にかかってしまいました。
採用は「今すぐ必要な人数」より「3ヶ月後に必要な人数」を見越して動く必要があります。
ドキュメント整備を後回しにした
「忙しいから後でまとめよう」と手順書の整備を後回しにした時期がありました。その結果、新しいメンバーが入るたびに教育コストが高くなるという悪循環に陥りました。
ドキュメント整備は「余裕があるときにやるもの」ではなく「チームが回っているうちにやるもの」です。
まとめ
運用保守チームを20名にスケールした方法をまとめます。
- 属人化の見える化から始める
- 手順書・ドキュメントの整備で知識を組織の資産にする
- 1次対応できる人を増やすことでボトルネックを解消する
- 顧客の難易度でチームを3分割し、各チームにリーダーを置くことで報告・管理を分散する
- BPとの情報共有をオープンにして協力体制を作る
- 報告・連絡・相談のルールを明文化して迷いをなくす
チームのスケールに正解はありませんが、「属人化の解消」と「仕組み化」が基本になることは変わりません。
「チームをもっと大きくしたい」「今のチームがうまく回っていない」と感じている方は、まず「属人化の見える化」から始めてみてください。
コメント