エムスリーテックブログ

エムスリー(m3)のエンジニア・開発メンバーによる技術ブログです

個人を活かしてチーム力も最大化する、属人性解消への取り組み方

こんにちは。SREチームのチームリーダーをしている後藤です。

このブログはSREチームブログリレーの2日目の記事になります。

私がSREチームのチームリーダーに就任してからもうすぐ3年になります。 その間に様々な課題に取り組んできたのですが、中でもチームの属人性について考える機会は多くありました。 本記事ではSREチームが属人性の解消に向けてどう向き合ってきたか振り返りまとめていきたいと思います。

属人性についてディスカッションする動物たち generated by Gemini

SREチームについて

私の所属しているSREチームは横断的な取り組みを実施するチームで、社内ではコアSREと呼ばれています。 対して、開発チームに所属して担当サービスのSREを担うメンバーはチームSREと呼ばれており、役割が分かれています。

チームの役割については、SRE NEXT 2024の登壇資料をご覧ください。

(余談ですが今年のSRE NEXTは予定が合わず参加できませんでした。来年はぜひ参加したいです。)

speakerdeck.com

SREチームは私を含めて6名のチームなのですが、次のような特徴から属人性が高めのチームです。

  • 少数精鋭かつ担当している範囲が広い
  • ほとんどの業務は担当者が1人で取り組む
  • メンバーのバックグラウンドが多様で得意領域が異なる

チームリーダーとしての気づき

私がリーダーに就任してすぐに、属人性が高い点はチームの課題だと感じました。

一般的に属人性は次のような理由から望ましくないとされているかと思います。

  • 特定のメンバーの不在時に業務が遂行できなくなるリスクがある
  • 個人に知識が偏りチーム内に暗黙知が増える
  • 他のメンバーがその業務に触れる機会が失われ成長機会が偏る

これらのデメリットはその通りで、就任当時の私もすぐに属人性を解消しなければと躍起になってあれこれ考えていました。 しかし、考えるにつれてただ急いで解消していくことが本当に正しいのかという迷いも段々と大きくなっていきました。 チームのマネージャとして一番のミッションは言わずもがな、チームの成果を最大化することです。 その目的を考えたときに属人性の解消をひたすらに目指すことは必ずしもチームの成果を上げるばかりではないと思うようになりました。

属人性との向き合い方

抽象的になりますが、属人性解消のために各メンバーの良さが消えて結果として小さくまとまったチームになってはいけないと考えています。 全員がどんな分野のどの業務でも同じレベルで完璧にこなせるという状況が理想的な状態ですが、そんなことは絶対にないので適度に属人性を解消しつつ、チーム力を最大化していくという向き合い方が必要です。

試行錯誤をしていくうちに、属人性への向き合い方は大きく3つに分けられるのではないかと考えました。

  1. 仕組み作りで積極的に解消していくべき属人性
  2. 中長期のスキルアップを目指しつつ解消していくべき属人性
  3. 解消を目指す必要のない属人性

それぞれについてSREチームでの具体例を交えつつご紹介します。

仕組み作りで積極的に解消していくべき属人性

まずは仕組み作りで積極的に解消していくべき属人性についてです。

これについては、高度なスキルを要求しない業務、定常的に発生する業務、チームとして必要があれば常に実行できなければいけない業務、業務負荷の偏りや不公平感がでる業務などが挙げられます。 より具体的にいうと、他チームからの権限申請の対応、サービスのリリース、オンコール対応などになります。

こういった属人性は過去からの経緯でずっと同じ人が対応していたなど仕組みがないことにより生まれてしまうことが多いので、シンプルにローテーションを組んだり、ランダムアサインをしたりすることで解消できます。 SREチームでも、オンコールはもちろん、入社時の権限等の手続きやサービスの定期リリース、社内開発環境の定期バージョンアップなどはローテーションを組んで対応しています。

また、自動化によって業務そのものを特定個人がやらなくてよくすることも効果的だと思います。 ただ自動化の仕組みを作った人にしかわからないという新たな属人性も発生しがちなので、そこはドキュメンテーションなど注意が必要です。

中長期のスキルアップを目指しつつ解消していくべき属人性

続いて、中長期のスキルアップを目指しつつ解消していくべき属人性です。

これについては、Aさんが得意な領域だからずっとAさんが担当してきているといったように、特に高度なスキルを要求される業務について発生しがちです。 こういった業務については、ローテーションや無理なアサインを実施してもすぐに解消できないどころか、知見不足による作業ミスのリスクや、アサインされたメンバーの疲弊などでチームのアウトプットを低下させる懸念もあります。 また、得意領域でハイレベルな成果を挙げてもらうことは個人にもチームにも大事なことなので、属人性のためだけに業務の水準を落とすようなことも望ましくありません。

このような場合は、各自が強みを最大限発揮しつつ、他のメンバーもその高いレベルを目指してキャッチアップしていくような動き方が必要だと考えています。 例えば次のようなものになります。

  • ペアでの業務推進
    • 特定のスキルを持つメンバーとそれ以外のメンバーが2人組で業務にあたることでキャッチアップします。コードレビューだけでなく、実際の障害対応や構築作業などもペアで行うことで、口頭だけでは伝わりにくいノウハウや思考プロセスを共有できる。
  • チーム内での積極的な知見の共有
    • 各メンバーが担当している業務の知識や学んだことを積極的に共有するのも有効です。夕会でのライトな共有や、チーム定例でのディスカッション、ドキュメントベースでの共有などいくつかのパターンがあります。
  • とりあえずやってみる
    • 新しい技術や複雑なシステムに対しては実際に手を動かすことが一番理解を深められます。作業リスクは考慮した上で積極的に取り組むことは個人のスキルアップ、ひいてはチームの属人性解消につながります。

SREチームでの具体例をあげると、HWリプレイスのプロジェクトにおいて詳しいメンバーとそうではないメンバーをペアでアサインしてキャッチアップしつつ新環境に詳しくなってもらったり、CI/CD実行基盤のトラブル対応を詳しくないメンバーがサポートを受けつつ実施して、その内容をチーム内にシェアするなど実施しています。

解消を目指す必要のない属人性

最後に、解消を目指す必要のない属人性についてです。

これについては、必要性があって個人に依存している業務や、そのままにしておいても影響が小さい業務が挙げられます。 前者の例を挙げると、root権限のような強い権限を要する業務や機微情報を扱う業務などを意図しており、これらはその業務の特性から誰でもできるようにするのは望ましくありません。 権限分掌の話になってきますが、これもある種の属人性だと思います。 後者の例としては、業務の頻度が低かったり、作業内容のキャッチアップが非常に簡単な業務となります。 これらは何かあったとしても、すぐに替わりの担当を立てられるのでリスクも小さく無理に解消していかなくてもよいと考えています。

まとめ

「属人性」という言葉にはネガティブなイメージがあり、実際にもマイナスに働くことが多いかと思います。 しかし、ただひたすらに属人性をなくしていくのではなく、重要なのは属人性とどう向き合いどのようにチーム全体の成果に繋げていくかという考え方だと学びました。 今後もチームメンバーがスキルを発揮しつつ、チームとしてのレベルも成果も上げていくことを目指していきたいと思います。

We are Hiring!

エムスリーではSREを募集中です。 もしSREの仕事に興味をお持ちいただけたなら、ぜひ以下のリンクから詳細をご確認ください。

エンジニア採用ページはこちら

jobs.m3.com

カジュアル面談もお気軽にどうぞ

jobs.m3.com

インターンも常時募集しています

open.talentio.com