大規模サービスあるある、”属人化”解消のための開発体制パターン
初めまして。@izmrと申します。2015年2月にエウレカに入社して、プロジェクトマネジメント的な仕事や開発体制の整備や改善などを行っています。
今回は、開発体制を整える中で見えてきた”属人化”という課題に対して、どのようなアプローチで対処してきたか、ということを、ちょっとしたストーリー仕立てで説明させていただきます。
課題と出会うシチュエーション
あなたは、スタートアップ企業で新規サービスの開発に携わるエンジニアです。
担当するサービスは、リリース当初は売上規模が少なかったものの、メンバー達の必死の開発と運用によって徐々に成長し、紆余曲折を経て、今では億単位の売上規模を誇る大サービスになりました。
エンジニアは、当初は1〜2人だったのが、今では15人以上の開発体制になりました。サービスの仕様は複雑になる一方で、様々な開発が同時並行で走っているので、今では全ての仕様を理解できる人はほとんどいません。
担当するサービスの成長と共に、チーム自身も変化を迫られ、少数で開発していた時には無かった「組織の成長痛」のような大変さを実感しています。
そんな中、ある問題が浮上します。
「開発が遅れてる！”あの人”しか分からないタスクが積もっている。ヘルプを出そうにも、誰もやり方が分からないので、”あの人”の進捗を待つしかない」
特定の人しか分からないタスクが増え、それが開発進行上のボトルネックになることが多くなってきました。
課題：”属人化”
「属人化タスクを抱えた人」のパフォーマンスが、開発全体の進捗状況を決める要因になり得る状況です。「属人化タスクを抱えた人」は、スケールアウトできないので、開発プロジェクトにおける人的SPOF(単一障害点)と言えます。
属人化は解消したいですが、多くの場合、人的SPOFな人は常に忙しいので、話を聞く余裕はありません。
ほとんどの場合、ドキュメントも残されていないか役に立たないため、誰も引き継げません。
属人化タスクは、「優先度：高」の場合が多く、対応速度が優先されて人的SPOFな人にアサインされ続けることも少なくありません。
結果として、ナレッジが他に人に伝わらず、属人化は残り続けます。
どうしたら良いでしょうか。
対策1：”運命共同体”チームを作る
属人化が解消されない根本原因は、属人化タスクの「遂行する責任」が、特定の個人に固定化してしまうことです。
解消のためには、属人化タスクの遂行責任を「個人」ではなく「チーム」に変える必要があります。
属人化タスクがボトルネックになっている場合に、「その人のタスク完了をただ待つ」ではなく、「チーム全体が助け合って属人化タスクのサポートをする」ように行動を変えなければなりません。タスク遂行のためにチーム内で助け合うモチベーションがあれば、複数の人が自然に属人化タスクに向き合うことになるため、ナレッジの共有を促進することができるはずです。
「チーム内で助け合うモチベーション」を意図的に作ることが対策1において重要です。
対策1の進め方
そもそも適切な「チーム」が存在しない場合は、チームを作りましょう。
ただし、10人以上のチームの場合、統率を取るための管理に比重が置かれ、お互いに助け合える雰囲気がなくなってしまう可能性があります。
「自主的にお互い助け合える」環境のためには4〜6名のチームが理想的です。チームの人数が多すぎる場合は、チームを分割しましょう。
そして、タスクアサイン時は、特定の人物にバイネームでアサインするのではなく、チーム全体にアサインして、その割り振りはチーム自身にお任せするべきです。マネージャーがマイクロマネジメントに走ると、「管理者と作業者」の関係性が強まってしまい、チーム内でオーナーシップをもって属人化タスクに取り組む、という雰囲気が消えてしまいます。チームの自主性と問題解決能力を信じましょう。
対策1の促進：振り返り会を実施する
単純に、「チームを作ってタスクをチームにアサインする」だけだと、チーム内の連帯感が不十分な場合は、お互いを助け合うような動きが生まれにくいかもしれません。
チーム内の連帯感を生むためには、ランチや飲み会などのカジュアルなコミュニケーションの場を設けるのも良いですが、振り返り会を設定して「チーム内の問題の認識合わせをして、一緒に解決策を考える」ような場を作ると効果的です。手法はKPT法など、なんでも構いません。
振り返り会を設定して問題を共有しあうと、”属人化”に関する問題がかならずメンバーから出てきます。作業のボトルネックが属人化に起因することをメンバー全員が理解して、「どうすれば属人化を解消できるか」を検討し合うことが重要です。
ペア作業をする、ドキュメントを用意する、成果物をレビューし合う、など、色々な解決方法が出てくると思います。それだけで属人化が解消するわけではないかもしれませんが、「問題共有→相互理解→解決」のサイクルを回せるチーム体制ができれば、どこかの段階で属人化は解消されるはずです。
振り返り会は、「業務に直接関わりがない」という理由で後回しにされることがあるので、初めから定例化しておくのがオススメです。
対策2：人的SPOFに最適化する
「逆に考えるんだ。『属人化解消しなくてもいいや』と考えるんだ」
という感じで、”属人化”解消をあえて諦めるパターンです。
「属人化タスクを抱えている人」の持っているタスクの内、「属人化されてないタスク」を他のメンバーが全て巻き取ることで、「属人化タスク一本に集中してもらう」体制です。
開発体制で言うところの「パワープレイ」にかなり近いものがあります。
参考：スクラムはもうだめぽよ!新しい開発手法『パワープレイ』をお姉さんが教えてあげちゃう!
「属人化タスクの専門性が高すぎて、特定の人以外理解しようが無い」場合や、「とにかく緊急の案件で、属人化解消を待っていられない」場合に適しています。
TOC(制約条件の理論)で言うところの、「制約条件を徹底活用する」「その他の全プロセスを制約条件に従わせる」に近い考え方と言えます。
対策2の進め方
具体的な施策を挙げると、以下のようなものが出てきます。
- まず、人的SPOFのタスクを全て洗い出しする
- 洗い出したタスクの内、誰でもできるタスクを他の人にアサインする
- 洗い出したタスクの内、頑張って調査すれば他の人でも進捗できるタスクを他の人にアサインする
- 人的SPOFのタスク管理を他の人が担当する(秘書を用意する)
- 人的SPOFへの直接の問い合わせをシャットアウトして、代わりに別の人が問い合わせ一次受け付けを行う
- 人的SPOFへの直接の問い合わせをシャットアウトして、代わりに「依頼シート」に問い合わせ事項を書いてもらう(問い合わせの非同期化)
などなど。とにかく、「属人化タスクだけに集中してもらう体制」を作ることが重要です。
対策2の注意点
対策2のアプローチは、瞬間的なパフォーマンスでは進捗速度アップが期待できますが、属人化そのものは全く解消しないため、遅かれ早かれ同じ問題がまた発生します。
また、「特定の人物がボトルネックである」ということは、その人は多方面から「早く仕事を終わらせてくれ」というプレッシャーを受けているはずなので、常に忙しく、精神的に休まらない状態が続きます。
つまり、対策2は非常に体力を使うアプローチなので、長期間この状態を続けるのは好ましくありません。
短期的なプロジェクトや長期プロジェクトの最終局面で一時的に採用するのは問題ないですが、常にこれで解消しようとするのは負担が大きすぎて長続きしません。
まとめ
というわけで、基本的には「対策1：”運命共同体”チームを作る」を開発体制の基本にするのが望ましいと思います。
しかしそれが唯一の正解というわけではなく、実際には様々な局面が存在するので、緊急事態時に「対策2：人的SPOFに最適化する」に移行できる柔軟性を持つこともプロジェクトマネジメントの観点では重要だと思います。
一番重要なことは、チームメンバーがチーム全体の状況を理解した時に、例えば「人的SPOFがヤバい。チームを作って属人化解消すべきじゃないか？」と判断したら、「即座に声を上げられる」ことだと思います。
「薄々問題は感じているけど、声を上げる場が無いからスルーする」状態が一番好ましくありません。チームメンバーの課題感が出てきやすい、風通しの良い開発現場を作ることが理想的ですね。
最後までご覧いただきありがとうございました。
