こんにちは、MA部MA開発ブロックの@gachi-muchi-engineerです。
私の所属するMA部で7月に開発合宿を実施しました。一般的に、開発合宿は開発者が集まって新しいサービスや機能を開発しますが、今回の開発合宿では開発しない開発合宿という形で実施しました。本記事では、今回行った開発合宿の目的と結果を紹介します。
開発合宿をおこなうことになった経緯
MA部ではシステム運用での課題がありました。その課題の原因を紐解くと人的な要因（システム理解や意識の問題）が大きく関わっていることがわかりました。そのため、メンバー全員が集まり、課題に取り組むことで、システム理解を深め、意識を統一することを目的に開発合宿を実施することにしました。
システム運用での課題とは
MA部では日々の業務の中でアラート対応業務を行っています。アラート対応は、システムエラーなどの異常を検知し、ユーザー影響が出る前に対応する重要な業務です。
週ごとのアラート当番制を採用しておりメンバー二人体制でアラート対応業務を行っています。
以前大幅にアラートを減らすことに成功しましたが、その後もシステム構成の変更や新しいシステムの追加やシステムの利用状況が変わったことにより、またアラートが増えてきました。
以下はアラートを減らしたときの記事です。
状況としてサンプリングした月のアラートの発生回数は、月に244回で1日平均8件発生しています。MTTRは約3時間弱です。アラート当番だけでなく、該当システムに詳しいメンバーもアラート対応に参加するケースがあるため、チーム全体のアラート対応時間が長くなります。これは、日々の作業時間を奪うだけでなく、夜間対応等で、メンバーの生産性も下げてしまっています。
このような状況になっている要因は、アラートが発生した場合、一次対応後に根本対応ができていない状態が続いていたことです。
なぜ根本対応ができていないのか、その原因を調べると以下のような課題が浮かび上がりました。
【人的課題】メンバーのシステム理解・把握が不十分
MA部では、15名弱のメンバーで運用しています。対応メンバーの在籍年数を見ると40％強が1年未満で75％のメンバーが3年未満になっています。
MA部では、3つの部署（それぞれブロックと読んでいます）が合わさって部を形成しています。ブロックごとにシステムが分かれているわけではないので、メンバーがすべてのシステムをある程度把握し、アラート対応業務を行う必要があります。
そのためシステムの数が多く、在籍年数が若いメンバーはシステム理解が十分にできているとはいえない状況でした。結果として、根本の原因調査等に時間がかかってしまう場合や原因を調査しきれないケースが見られました。
以下は過去に紹介したMA部が管轄しているシステムの一部です。
【人的課題】マインドセットが統一されていない
MA部は、アラート当番によりすべてのメンバーがアラート対応をする環境となっています。ですが、アラートや監視に関して部内でしっかりとマインドセットが整えられていないと感じていました。具体的には、人によって一次対応で行うべき内容や、アラートの重要度を判断する基準が異なっていました。
結果として、監視やアラートに対して、部内のメンバーの意識が揃っていないので、アラート当番のルールの徹底がおろそかになってしまいます。
また、弊社の環境としてフルリモートのため、コミュニケーション面でも以下の課題がありました。
- 実際に会ったことがないメンバーとのコミュニケーションが取りづらい
- チームを跨ぐとコミュニケーションを取る機会が少ない
そのため、当番で一緒になってもお互いに一歩引いてコミュニケーションがうまく取れていないケースがありました。
【システム課題】監視が不適切なケース
監視を設定した当初から、システムの状況に合わせて見直しや調整ができておらず、適切な監視になっていないものがありました。そのため、過剰に反応してしまうケースや、検知タイミングが遅れてしまっているケースが見られました。
結果として、確認作業が増えて開発の時間が削られたり、重大なインシデントにつながってしまうことがありました。
課題のまとめ
システムの利用状況、構成の変更やメンバーの入れ替わりにより、アラート対応において課題が発生していることがわかりました。特にこの数年でメンバーの増員が多かったため、人的課題（育成やナレッジ蓄積、意識の統一など）が顕著になっていることがわかりました。
課題への対策
それぞれの課題に対して、以下のような対策を検討しました。
- メンバーのシステム理解を深める
- アラートや監視に関してスキル・知識の拡充とマインドセットを整える
- 実際に会って会話・作業をすることで、コミュニケーションの活性化を図る
これらの対策を効率良く行う方法を検討し今回は、開発合宿を実施することにしました。開発合宿と書いていますが、日々の業務を離れメンバー全員が集まり課題に対して集中的に取り組むことで、効率よく課題解決を図れると考えました。
また、開発合宿を実施しただけでは、中長期的に同じ状況に陥ってしまう可能性があると考えられました。
そのため、アラート当番が終わった後にテックリードによるアラート対応時のレビューをする仕組みを取り入れることにしました。
これの目的は、アラート対応のスキルアップを図ると共に、根本対応が行われない状況に陥らないような継続的な仕組みを作ることです。
開発合宿の内容と準備
今回の開発合宿は、1泊2日で実施することにしました。作業時間から逆算すると合宿中に課題を複数設定するのは現実的でなかったので、メインの課題をシステム理解に設定しました。得意分野が異なるメンバーを集めた4、5人程度のチームを3つ作り、お互いに教え合いながらシステムレポートを作成してもらうことで、システムの理解を深めてもらうようにしました。マインドセットの統一に関しては、合宿前にシステム運用に関しての図書を読んでもらい、合宿の最初にレクリエーション要素も含めたコンテンツとしてテスト形式で理解度を確認することにしました。
以下は、合宿のスケジュールです。
課題の準備について
システム理解
依存度の高いシステムをグループに分け、そのシステムグループごとにチームを割り振り、システムレポートを作成してもらうようにしました。システムレポートは、事前にまとめてほしいポイントをまとめたテンプレートを用意し、資料を作るコストを減らして、システム理解に集中してもらうようにしました。
今回テンプレートに含めた理解してほしいポイントは以下の通りです。
- システムの目的
- このシステムの目的や背景など、なんのために存在するのかを書いてください。
- システムアーキテクチャ
- ポイントに関しては以下のとおりです。
- アプリケーションの動きについて（図で表現できると良し）
- データの流れについて（図で表現できると良し）
- システムやアプリケーションの特徴や気をつけるべきポイント
- 外部システム/他システムとどのようにつながっているか？
- 外部システムがどのような状況になるとどのような影響があるか？
- ポイントに関しては以下のとおりです。
- モジュール
- モジュールに関してそれぞれ簡単にまとめて、特徴や概要をまとめてください。
- システム監視・サービス監視・メトリクスについて
- 現状行われているシステム監視・サービス監視についてまとめてください。それぞれにその監視が入っている意図やその監視がなるとどういうことになるのかを分かる範囲でまとめてください。
- メトリクスをどうやって確認するか、特徴的なメトリクスなどを分かる範囲でまとめてください。
- システム課題/対策
- 足りてない監視、監視のチューニング、頻発アラートの根本改善案などを分かる範囲でまとめてください。
以下は、システムレポートのテンプレートの一部です。
チーム分けでは、テックリードやリーダー陣は、チームには組み込まず、いつでも質問を受け付けられるようにしました。
これはメンバーの理解度を底上げしたかったためです。各チームには、メンバー同士で議論しながら資料を作成してもらいました。メンバー編成としては、システムグループごとに複雑なところであれば、経験者を混ぜたり、今後の中長期的に携わっていってもらうメンバーを配置したりするなどしました。また、メンバーのコミュニケーションの相性も考えながら、編成をしました。
チームには、班長というチームの進捗管理などを行ってもらう役割を設けました。
マインドセットの統一
今回はシステム運用アンチパターンを合宿までに読み込んでもらい、当日にテストを実施しました。こちらの技術書の選定とテスト作成・実施解説に関しては、テックリードにお願いしました。本に書かれいている一般的な問題から、MA部や、弊社特有の問題まで様々な問題を用意してもらいました。
以下は、テストの一部です。
テスト形式は、Yes/No形式で問題毎に正解の発表と解説をしました。こうすることで、全員が理解しながら正答を確認し一喜一憂するようにしたかったためです。また、成績優秀者には、表彰状を用意し、1日目の夜に表彰式を行いました。
実施にあたっての準備
課題以外では実施場所、食事の手配、社内調整や申請系のフォローアップなども行いました。
開催場所の候補はいくつかあったのですが、今回の合宿はおんやど恵様で実施しました。開発合宿に必要な準備をサポートしてくれる合宿プランで予約し、宿の皆様の丁寧なサポートにより昼食のお弁当の手配や各種設備のレンタルなどもスムーズに進めることができました。
それ以外にも、社内の申請系の調整を行い参加メンバーが合宿前後で行わないといけない申請のまとめやフォローアップの準備をしました。
準備まとめ
合宿の準備としては、やってもらう課題の設定とボリューム感がオーバーワークにならないように注意しながら、いろいろなレベルのメンバーがいることを想定して設計・準備をしました。運営側として携わることは初めてだったので、過去に参加したことがあるメンバーや、テックリードに協力を仰ぎながら進めていきました。
実際に実施した合宿の様子
1日目
まず全員揃うか心配でしたが、無事に集まりました。合宿の最初に、合宿の目的やスケジュール、ルールや注意事項を説明しました。特に羽目を外しすぎないように、合宿の目的を忘れないように注意を促しました。
その後、システム運用アンチパターンに関する理解度テストを実施しました。ある程度場が盛り上がったところで、昼食を食べながら、システム理解の課題に取り組んでもらいました。最初のコンテンツでレクリエーション的な要素を交えながら行ったあとに、メインの課題に取り組んでもらう流れは緊張もほぐれ、とても良かったと思います。
定期的に各チームに足を運びながら困っていること、詰まっていることはないか、まったく進捗していないチームがないかを確認しました。どのチームもコミュニケーションを取りながら、進めていたので、運営側としてはホッとしておりました。
1日目の最後には、各チームから中間発表してもらいました。大きく方針が間違っていないかなどをチェックするとともに、いくつかアドバイスや、追加で調査してほしいところなどを伝えて1日目の終了としました。
2日目
2日目は、朝から引き続きシステム理解の課題に取り組んでもらいました。1日目の中間発表から、アドバイスを受けていたチームは、アドバイスを元に進めていきました。
1日目と同じく、定期的に各チームに足を運びながら、進捗を確認や困っていることがないかなどを確認しました。
ここで、資料を作ることがゴールになりだしていると感じられたためリーダー陣と相談し、最終発表では資料の投影はなし、口頭のみで説明してもらうことにしました。これは、システムを理解できていたら、資料がなくても説明できるはずだという考えからでした。
最終発表では、1チーム30分で全チームが発表しました。質疑応答では、システム特有の仕様や、歴史的な背景から課題になっているところなどを理解しているか確認しました。リーダー陣以外からも各チーム間でも質疑応答が行われ、議論が行われていました。
最終発表が終わった後に、MA部の部長から合宿でのMVPを選出してもらい、表彰式を行いました。その後、各自解散の運びとなりました。
合宿の結果
合宿後にアンケートを実施して、今回の合宿の目的が達成できたかを調査しました。
全体的にポジティブな意見が多かったです。システム理解に関しては、全員がシステムの理解を深められたと回答してくれました。
今後のアラート対応において、システム理解が深まることで、アラート対応にかかる時間が短縮されることが期待できるという意見もありました。
マインドセットの統一に関しても、アンケートの回答では、アラートや監視に関して、意識が統一されたと回答してくれました。テストは比較的簡単だったようなので、次回の機会があれば、もっと難易度を上げてもいいかもしれないとテックリードからのフィードバックもありました。
特に年次が浅いメンバーは実際にメンバーに会う機会も多くなかったので、コミュニケーションの強化や知見があまりないシステムに関して理解を深めるいい機会にしてもらえたと思います。
総じて、なかなか日々の業務の中でまとまった時間を確保して取り組むことが難しいシステム理解という課題に対して、開発合宿を通して集中して理解を深めることで、効率よく対策できたと感じました。
合宿での課題
進め方/ゴールに関して
システムレポートを作ることがゴールになってしまっていたケースがありました。今回は、そこを起動修正するために最後の発表を資料なしという形を取りましたが、最初からここを想定しておくべきでした。
また、なかなかリーダー陣に質問が飛んでこないことも課題だと感じました。もっと定期的に確認しに行く頻度を上げる、リーダー陣にも質問を促すようにするなどの工夫が必要だと感じました。
チーム編成/役割
リーダー陣の役割を明確にしていませんでした。その結果質問を待っているだけになってしまい、ワークしていたとは言いづらい状況だったと思いました。次回はリーダー陣の役割を明確して、よりワークするようにしたいと思いました。
また、チーム編成はうまくできたと思いますが、班長の役割を明確にしなかったため、任命しただけで終わってしまったと感じました。もっと具体的な動きなどを伝えてチームがワークするような動きを取ってもらえるような準備をするべきだったと思いました。
最終発表/質疑応答
満足行くまで調査しきれなかったチームや、質疑応答でチーム間での議論が活発に行われなかったなどの課題もありました。次回は、作業時間の工夫や最終発表での各メンバー1つ以上質問をするようにするなどの工夫が必要だと感じました。
今回の課題への効果
開発合宿の実施後のアラート対応の状況は以下のような変化が現れました。
まず、MTTRが大幅に改善されました。システム理解が進んだことで、アラート対応にかかる時間が短縮されました。
次に、インシデントの総数も減りました。テックリードによるアラート対応のレビューにより、根本対応がしっかりと実施される仕組みがワークしているため減少させられました。
これは、合宿でのシステム理解の深まりや、マインドセットの統一の効果とテックリードによるアラート対応のレビューの効果があったためと考えられます。
まとめ
今回運営側として初めて開発合宿を企画・運営しましたが、大変学びが多かったです。
特に、普段の業務を離れてメンバー全員で1つの課題に集中して取り組む機会を作ることは、とてもいい手段で、非常に効果的なやり方だと思いました。また、準備が非常に大切なことも痛感しました。今回はたまたま準備がある程度できていたため、メンバー全員が集中できる環境の準備はできたと思いますが、もしできていなかった場合はグダグダになってしまっていたかもしれません。もし次の機会があれば、もっと準備に時間をかけるようにしたいと思いました。
開発合宿の成果という点では、今回のケースでは定量的なものはなかなか出しづらいものでもありました。そこは、今回の合宿を実施しただけで終わらせないようにフォローアップを行っていこうと思いました。
今回実施して感じた課題などは、今後実施する機会があれば開発合宿の設計として活かしていきたいと思いました。
最後に
ZOZOでは一緒にプロダクトを開発してくれるエンジニアを募集しています。ご興味のある方は下記リンクからぜひご応募ください！
