過去の賢人に学ぶ、インフラ運用チームのマネジメント失敗事例

gumiアドベントカレンダー9日目です。
今回はちょっと技術的なことを離れて、チームマネジメントまわりのことを書いてみようと思います。

1.チーム背景

私の所属しているチームは、主にAWS環境の運用を行っています。
チームメンバーは、ほぼ私が1人で対応していた時期から、数人規模のチームを推移してきました。

「愚者は経験に学び、賢者は歴史に学ぶ」とはよく言ったもので、残念ながら私は完全に前者になってしまいました。
改めて自分の失敗を振り返ると、良書と呼ばれる本には、失敗内容に関連した内容が記載されています。

特に、【Team Geek】の内容は、以前読んだ筈なのに全く実践できていなかったなあと。。。
【参考】『Team Geek』を読んだメモ

今回は、私のチームマネジメント失敗事例やそこから学んだことを徒然なるままに書いてみようと思います。

2.失敗したこと

2-1.メンバーの増加タイミング

チームマネジメントの経験が浅いリーダーは、ビジネスが急速に成長しているときでも、人を急激に増やさない方がよいです。
メンバーが1人増えると、コミュニケーションパスはN(N-1)/2で増えていきます。
この現象は、チームマネジメントをする上でかなり大きな問題となります。

何が起きたか？

問題認識のギャップ

どんなに優秀な方でも、組織に馴染むには時間がかかります。未成熟な組織には、技術的負債が残っている環境がありつつ、暗黙的にリスク対策している環境もあったり、問題の対応方法が世間一般の対応方法とは違うこともあります。リーダーはリスクの重要度や優先度をメンバーに説明する責務を負いますが、急速にメンバーが増えてしまうと、どうしてもフォローしきれない場面や問題が出てしまいます。

通常運用と運用改善のタスクバランス崩壊

インフラ運用のタスクには、セキュリティ対策、監視、バックアップなど、改善結果がすぐに見えにくいタスクもあります。リーダーとメンバー間だけでなく、メンバー間でも問題認識のギャップがあると、 「何故そのタスクの優先度が高いのか」をチーム内で共有できていない状況が発生し、チームの信頼関係が崩壊します。

見積もりミスの増加

自分が今までやっていたタスクを新規メンバーに行ってもらうときには、自分が担当するのと同じぐらいの作業見積もりをすると、確実に納期に間に合いません。「このタスクを新メンバーに任せる！」と決めた際は、通常以上のバッファを取る交渉を関係各署にしてから、メンバーへのタスク振りをするなどの調整をしないと、タスクが納期に間に合わないことが生じ、チームに対しての信頼を失うことにつながります。

関連図書

2-3.リーダーが現場のボールを持ち続ける

私はどちらかと言うと、現在も手を動かしながらのプレイングマネジメントスタイルとなっています。
私自身、手を動かすことは好きなので、手を動かすリーダーのままでもよいと考えているのですが、チームが成熟してきたら、リーダーはいずれ課題を与える側に周り、現場の課題解決は極力メンバーに任す方がよいです。リーダーがリーダーの仕事をしなければ、チームが方向性を見失うことになります。

何が起きたか？

暗黙知の引き継ぎ不足

最近では、chefやansibleなどによって、サーバの構築方法はコード化されてきていますが、障害対応方法やアーキテクチャの設計背景については、ドキュメント化されていないものも多く、会社特有のアーキテクチャに伴う経験が必要になってくるときがあります。
また、ドキュメント化されている運用フローがあったとしても、メンバーが実際に手を動かすことがなければ、その運用フローにメンバーが問題意識を持つのが遅れ、運用改善のタスクに移るタイミングが遅れることになります。

船頭なき航海

チームで動くには、現在の課題解決だけでなく、将来像を描く人が必要不可欠です。いつまでもリーダーが現場のタスクで忙殺されて、将来の舵取りが不在になれば、現場が部分最適のタスクばかりをこなすことになり、徐々にチームが疲弊していきます。
少ないメンバーで成果を出すには、必要なタスクだけでなく、全体最適を行う際に不要なタスクも見極めなければなりません。 タスクの取捨選別での注意点としては、「組織・技術・ビジネス」のそれぞれの成長速度は違うため、リーダーは3者の速度を見定めることが重要です。
リーダーは、将来と現在をつなげることを意識し、不要なタスクをメンバーが行わなくてもよいようにする必要があります。

関連図書

3.現在、試みていること

失敗例ばかり書いてみましたが、いくつか成果があった話や現在試みている話も書いておきます。

3-1.メンバーに強みを与える

こちらの施策は、特にインフラの運用経験が浅いメンバーが入ってきたときに効果的だと思われます。インフラ運用チームとしては、ある程度の基礎スキルをもった上で、誰でも依頼内容や障害に対応できる状況が望ましいです。しかし、現実は採用タイミングによって、どうしても基礎スキルがバラバラのメンバーでチームを形成せざるを得ない状態が生じます。
そのようなときは、例えば、Chef,監視ツール,AutoScalingといった、日々稼動しているツールのプロになってもらうといった対応がよいと思います。特化した技術を担当してもらうことで、その技術の周辺技術や比較対象の技術に詳しくなり、チームメンバーへノウハウを教えることもできるため、新規メンバーが自信をもってチームのタスクをこなせるようになります。

3-2.チームでメンバーの成長を応援する

日々のタスクにチームが忙殺されては、個人としてもチームとしても成長が止まってしまい、エンジニアのモチベーション低下につながります。そのため、メンバーのスキルやメンバー間の信頼度がある程度高くなり、定常運用が安定期に入ってきた時期には、チームのノウハウ共有やチーム外の人との交流を兼ねて、勉強会などで各自の成果をアウトプットする環境を作った方がよいです。
最近、私たちのチームでは、週の始めに週のどこか1日を使って、各自が技術検証を行えるような日（TechDayと呼んでます）を極力設けるようにしてみました。こちらの施策については、その日までに依頼期日があるタスクや、当日起きた障害を他のメンバーがカバーすることで、技術検証中のメンバーが集中して検証を取れるようにチームでカバーし合える環境が前提となるため、ある程度チームが成熟したときになって初めて実施可能な施策だと思われます。

4.まとめ

当然ですが、1人ではチームのリーダーになれません。リーダーは不安を感じつつ、指示を出しており、実際に現場にいるメンバーから学ぶことが多々あります。
Team Geekにも記載されていますが、

• 謙虚(Humility)
• 尊敬(Respect)
• 信頼(Trust)

これらの3本柱は、アプリチームだけでなく、インフラ運用チームでもとても重要な要素だと最近改めて感じています。
私よりも素晴らしいリーダーは世の中にたくさんいる中で、このような記事を書くのも恐縮ですが、今後インフラ運用チームのリーダーを任される方にとって、何かの参考になれば幸いです。