この記事は RevComm Advent Calendar 2024 の 12日目の記事です。

はじめに

こんにちは、バックエンドエンジニアの矢島です。普段は主にバックエンド領域の開発・保守・運用を行っていますが、チームのサブマネージャーとして組織の運用改善なども行っています。

多くのソフトウェア開発チームが1度は直面する課題の一つに「属人化」があります。特定の機能や領域の知識が特定のメンバーに集中してしまい、その人が不在の際に対応できない、あるいは新機能の開発スピードが落ちてしまうといった問題です。

この記事では、弊社のプロダクトMiiTel の開発チームで実施した、属人化の解消への取り組みについて紹介します。

属人化の解消の背景

RevCommでは、電話・Web会議・対面での全ての会話を最適化する音声解析AIのMiiTelを開発しています。

中でも私が所属してる電話のデータを解析・可視化するMiiTel Phone Analytics は、RevComm創業当初からあるプロダクトで様々な機能拡張が行われてきました。製品の成長に伴い多くの機能を保守・運用することに加え、プロダクトの改善も行う必要があります。そこで半年のうちに3名のメンバー増員があり、以下のような課題に直面しました。

各機能の仕様や実装の複雑化による新メンバーの学習コストの増加
特定のメンバーしか対応できないことによる開発や問い合わせ対応のボトルネックの発生
一部メンバーへの負担の集中や、チーム全体の生産性の低下の恐れ

これらの課題に対し、「チームの全メンバーが全ての機能の調査・開発を行えるようにすることで中長期視点でのチームの生産性を向上させる」というミッションを設定し、約半年間かけて属人化の解消の取り組みを実施しました。

属人化の解消への取り組み

現状の把握と効果測定の方法を決定

属人化効果を測定するため、以下のようなアンケートを属人化の解消の取り組み前と、1ヶ月単位のスプリント終了時に実施することにしました。

各機能への経験を選択してもらう
- 「該当の機能の存在を知っているか」、「機能を使ったことがあるか」、「ドキュメントを読んだことがあるか」、「レビューをしたことがあるか」、「問い合わせ対応をしたことがあるか」、「実装したことがあるか」という複数回答可の選択項目を用意しました。
各機能への対応における精神的な負担度を5段階で評価してもらう
- 取り組み始めた当初は、精神的な負担が属人化に繋がるメインファクターであると考えており、各機能の理解が進むことで、機能対応時の精神的負担が減り、属人化解消に繋がると考えていました。この考えは後で更新されることになります。
機能ごとの理解度や不安要素を自由記述してもらう

施策1：機能共有会の実施

施策としてまず取り組んだのが、各機能の詳細な共有会の実施です。タイムパフォーマンスを考えた時に全ての機能の共有会を実施することは好ましくないため、アンケートから特に属人化している機能や新機能についての共有会を実施しました。

特に複雑な機能については、機能の概要・設計思想とシステムアーキテクチャ・コードリーディングのように複数回に分けて共有を行いました。

施策2：意図的なタスクのアサイン

学習のレベルにおいても、知っていることよりも行うことのほうがより高いレベルに位置付けられるのと同じで、ドキュメントを読むよりも実際に手を動かす方が理解が進むということはよくあると思います。そこで実際に普段触れる機会の少ない機能について、本来は優先度が高くないものも含めた以下のようなタスクを作成し、意図的にアサインしました。

既存機能の単体テスト追加：コードリーディングができることに加え、テストケース作成を通じて機能の仕様理解・コードの品質向上と保守性の改善を図れます。
エラーハンドリング改善タスク：コードリーディングができることに加え、保守・運用の改善を図れます。
音声ファイル処理バッチの改善：データフローの全体像の把握ができ、パフォーマンスチューニングも実現できます。

なかでも単体テストの追加は、実際のコードを動作させながらテストを書くことで、自然と機能への理解が深まるという効果がありました。顧客影響がないコードを追加できるという点でも、属人化の解消を推進するタスクとしてはおすすめです。

アンケートの結果からチームに施策の相談

施策1, 2 を実施したところで2回のスプリントが終わり、アンケートも2回実施しました。

当初の取り組みでは、精神的負担の軽減という指標で効果を測定していましたが、アンケート結果に改善が見られなかったため、チーム全体で相談の機会を設けました。そこから新たな施策やこれまでの取り組みの改善の発案がされ、実際に以降の取り組みに活かすこととなりました。

アンケートの改善

精神的な負担が属人化に繋がるメインファクターであると考えてアンケートを作成していましたが、「精神的負担」という指標よりも「各機能に対応できるか」という具体的な指標の方が、属人化解消の目的に適していることが明確になりました。この気づきを基に、アンケートの設計を以下のように見直しました。

各機能への対応における精神的な負担度を5段階で評価してもらう → 問い合わせ調査やバグフィックスを依頼されたときに対応できるかを判断してもらう
- 「わからない」「対応できない」「内容の指示を貰えば対応できる」「基本1人で進め」「必要に応じて質問しながら対応できる」「1人で対応できる」という選択項目を用意しました。

これにより、対応できはするけど精神的に負担はあるという状態があっても、より属人化の解消という目的に即した効果測定が可能になりました。

施策3：オンコール制の導入

アンケート項目に問い合わせ対応経験を聞く項目があったことから、一次対応を当番制にしてよいのではないかという意見があがりました。

そこで、業務時間中に発生する問い合わせに対して迅速な一次対応と、問い合わせ対応を通じたキャッチアップの促進を行うための仕組みとして、オンコール制を導入しました。週替わりで2名のエンジニアがメインとサブに分かれてオンコールの担当となり、問い合わせ内容の初期調査や必要に応じて適切なチームメンバーへのエスカレーションを行うようになりました。

この制度により、問い合わせ対応の効率化だけでなく、各メンバーが様々な機能についてキャッチアップする機会が増えました。「問い合わせ対応を通じて自然と機能理解が深まった」という声がメンバーからも出るようになり、結果として属人化の解消にも貢献しました。

施策4：カオスエンジニアリングの実践

最後の比較的大きな施策として、意図的に障害を発生させ、その調査や対応を通じて理解を深める「カオスエンジニアリング」を実施しました。

カオスエンジニアリングとは、本番環境で起こりうる障害や異常な状態を、制御された環境で意図的に再現し、システムの回復性や耐障害性を検証する手法です。Netflixが先駆けとなり、現在では多くの組織で採用されています。

RevComm でも各開発チームでカオスエンジニアリングの取り組みが定期的に行われており、私も別チームで行ったことがありました。属人化解消の取り組みを行うチームでは行ったことはありませんでしたが、この手法を知識共有の手段として活用することにしました。

通常のカオスエンジニアリングは本番環境の堅牢性や可用性を確認する目的で行われますが、私たちの場合は開発環境で実施し、障害対応を通じた学習に重点を置きました。これにより、メンバーは実際の障害対応に近い形で、システムの動作原理や障害発生時の調査方法を学ぶことができました。

具体的良かった点は以下の通りです。

チーム全体での障害調査と解決プロセスの実践・調査手法やログの見方を実践的にキャッチアップできる。
チームメンバー間での知識共有が促進される。
システムの挙動確認と知識の共有・システムの依存関係や連携フローを具体的に把握できる。
トラブルシューティングのノウハウを蓄積できる。

この取り組みは特に効果的で、振り返りでは「新鮮な体験で機能理解が大きく進んだ」という評価を得ました。

結果と考察

約半年間の取り組みによって、以下のような結果が得られました。

アンケートでは4つの施策を通して精神的負担が下がることはなかった。
一方で、メンバーが対応できると言える機能が増加し続けた。
対象としていた機能については「わからない」「対応できない」と回答するメンバーはゼロとなった。

当初設定していた「精神的負担」という指標では改善が見られませんでしたが、業務の属人化の解消は十分実現できていると考えられる結果となりました。

まとめ

この取り組みを通じて、以下のような重要な学びが得られました。

目的に合った適切な指標を設定することが重要。一方でOKRの Key Result のように途中で指標を変えることも必要に応じて検討することで進みながらの改善が可能。
ドキュメントやコードリーディングよりも、実際の体験を通じた学習の方が効果的。
個人の努力だけでなく、チームで会話し継続的に実施・改善していくことが重要。

今後は、これらの学びを活かしながら、新しい機能や技術が導入された際にも、スムーズに知識を展開できる体制を維持していきたいと考えています。また、この経験を他のチームとも共有し、組織全体としての改善にも繋げていければと思います。

属人化の解消は、一朝一夕には実現できない課題です。しかし、明確な目標設定と複数の施策の組み合わせ、そして適切な指標による効果測定を行うことで、着実に改善を進めることができます。皆様の組織でも、本記事で紹介した取り組みが何かしらの参考になれば幸いです。