この記事はクラウドワークス Advent Calendar 2023 シリーズ2 の 20日目の記事です。

こんにちは。
クラウドログの開発チームでエンジニアをしている寺島です。

普段は、プロダクトの機能開発を進めながら、お客様からの問い合わせに対する技術的なサポートを行っています。

私のいるチームは、技術的なサポートを担当しているという理由からリリース予定の決まった開発はあまりやらないチームだったのですが、ここ最近リリース予定の決まった開発＋素早い技術的なサポートを行なっており、結構泣いています。

そういう背景から、ここ最近、業務の属人化についてちょっと考えることがあったのでつらつら書いてみようと思います。

業務の属人化とは？

業務の属人化とは、特定のメンバーや個人しか業務の進捗や進め方について把握できていない状態を指します。

一般的に以下のデメリットが挙げられます。

業務がブラックボックス化し、品質が不安定になる
特定メンバーが不在の場合、業務のボトルネックができやすい
特定メンバーの退職や休職などで、培われた技術や知識が失われる可能性がある
特定メンバーに業務負荷が偏る
新たなやり方・アイディアが生まれない

このような状況になると、例えばその人しかできない作業を その人がいないとき にやりたい場合、困ってしまいます。

場合によっては、「専門知識が深化する」や「意思決定の迅速化」などのメリットも存在します。しかし、基本的に属人化のメリットは短期的なものが多く、長期的に見れば組織にとってのデメリットの方が目立つことの方が多いです。

クラウドログの開発チームは？

クラウドログの開発チームも例に漏れず、いろいろな属人化問題を持っています。

例えば、次のようなものがあります。

特定のメンバーに問い合わせの技術的なサポート対応が偏っている
特定のメンバーにリリース作業が偏っている
特定のメンバーに旧システム¹に関する開発や保守のノウハウが偏っている
特定のメンバーにインフラ・セキュリティ・パフォーマンス等の専門知識やノウハウが偏っている

簡単に考えられるだけでもこれだけありました。深掘りすると、もっと見つかるんだろうな。一般的にどこのチームもこのような属人化問題を大なり小なり抱えていると思います。

なぜ属人化が起こるのか？

じゃ、なぜ開発チームで属人化が起きるんだろうか？という理由を考えてみました。

■ 属人化の影響を感じられていない説

属人化することによる悪影響や解消することで、どれだけ自分たちにメリットがあるか意識できていない状態。
そのため、現状維持を目的としたもの（関係者だけ読む前提）だったり、さらなる属人化を生み出すようなドキュメントが作られたりするのでは？という予想しています。

■ 知識や手順を整備できていない説

ドキュメントができていない（＝一般化されていない）ケースが多いため、担当メンバーの頭の中に手順がある状態。

■ 知識や手順を活用できていない説

ドキュメントは整備できているが、それをうまくチームに説明し運用できていない状態。

他にもありそうですが、特に大きい理由だと思われるものを挙げてみました。どの状況が当てはまっても、業務の属人化が進んでしまいます。当然ですね。

属人化を解消するためにできること

ここまでの内容から、私の独断と偏見で属人化を解消するためにすべきことを挙げてみることにします。（アイデアレベルのものも含む）

■ 属人化を防ぐメリットについてチームで話し合おう！

一番最初は、属人化を自覚するところから始まると思っています。

まず属人化の状況について確認し、どのようになっているのか把握する。

そして、属人化に課題感を持つメンバーが、「何で属人化に問題があるのか？」「何で属人化を解消しなければいけないのか？」を周りのメンバーに伝えましょう。

全員が最初から同じ課題感を持つことは、とても難しいことです。まずは、問題提起から始め、課題感の共有から始めます。

属人化を防ぐことが最終目的ではないです。

「属人化が解消されると、チームにとってこれだけメリットがあるんだ！」ということをチームとして理解しすることが重要だと思います。

目的がずれていると、「とりあえず、ドキュメント作ったらいいんでしょ」などと、検討外れなドキュメントが量産され、必要な情報が埋もれてしまう可能性すらあります。

■ 業務の一般化を推進しよう！

業務をできるだけ一般化する。一般化とは、業務プロセスを明確に定義し、自動化や効率化を図ることです。

一般化によりチーム全体が同じルールに基づいて作業できるようになるため、作業品質のブレをなくすこともできます。また一般化は、一つ一つの業務の依存度が低下し、メンバーの負荷軽減や柔軟な人員配置も可能になります。

クラウドログでは特に、特定メンバーの頭の中にだけある業務プロセスをまずはアウトプットする必要があるかなと思っています。これをしないと、自動化や効率化もハードルが高いです。

ただし、ただ単に手順書を作るだけはNGだと思っています。「属人化を防ぐためにドキュメントを書こう」と意気揚々と書き始めたとしても、単なる手順書だと伝わるものも伝わらないです。

価値を感じてもらいづらい汎用的なドキュメントは、人に興味を持たれないものです。

手順よりも先に、「なんでこの手順書が必要なのか」を文章化して共有する。要は、「目的・価値」をしっかりデンタツ²しながら一般化を推進するのが大切かなと思っています。

■ 持ち回り式にして作業できる人を増やそう！

安直ですが、必要なこと。人に依存しない状況を作り、誰かが動けなくても他の誰かが対応できる！という組織を作ることが重要かなと思います。

ただ、今まで特定のメンバーしかできなかった作業を、突然明日から１０人が作業できる状態にするのは無理があります。
多くの人に伝えようとすればするほど、色々な人に対応する必要があり、うまくいきません。

んーーじゃあどうすればいいのか？

ドキュメントを読んだだけではなかなか身につかない。実際に体験してもらうのが１番だと思っています。
ということで、担当者を決めてあえて役割を回してみるのはどうか？作業担当者として実際に手を動かすことで、以下のメリットがあるかなーと漠然と考えています。

経験値を積むことができる
責任感を湧かせることができる
ドキュメント不備など、できる人を増やす上で足りない部分の発見につながる

これであれば、徐々にできるメンバーを増やしていく方式になるので、既存メンバーへの負荷もそこまで大きくならずに段階的に増やせるかなと考えています。

持ち回りが一周した後、全員が作業の責任感を持っている状態が理想ですね。

まとめ

こんなことを考えながら、今は「問い合わせ対応ができる人を増やす」に挑戦中です。
まだまだ試行錯誤している部分が多く、属人化解消には至っていませんが、やり遂げてみせるぞー！！という意気込みで取り組んでいます。

将来的には自分が関わる部分だけでなく、チームに蔓延る属人化が解消される未来を目指して頑張っていきまーす。

ここまで読んでいただき、ありがとうございました!

クラウドログは現在、旧システムから新言語によるリニューアルを進めています。 ↩
「デンタツ」とはクワウドワークス用語です。成果＝結果＋デンタツ。結果を出しただけでは、その結果はどこにも、誰にも届きません。結果を相手に伝えて、初めて評価を受けます。 ↩