毎日2000件来ていたアラートを精査し、20件にまで減らした話：リクルート流、SREコトハジメ（2）（2/3 ページ）

[小見山勝，ITmedia]

　SRE部は、コンピューティングリソースや全サービスが利用する機能を共通化しつつ、事業会社の個別要件に適宜対応できることを目指した組織です。それまでインフラの構築や運用を担ってきたメンバーを再配置し、各事業会社を担当する4つの「事業別SREグループ」と、オンプレミス共通基盤とクラウド共通基盤それぞれを管理する2つのグループで構成しています。

　共通基盤を管理するグループは、RAFTEL管理担当者が実施してきた業務を主とし、事業別SREグループは事業会社と一緒に案件を進めつつ、共通基盤を管理するグループとも連携します。

システム構成の新旧比較

共通基盤の姿も大きく変わった。専門分野による班分けから事業別のユニットになっていることが分かる

新しい部のミッションへと、メンバーの意識を徐々に変えていく

　こうしてSRE部が発足したわけですが、組織ができても、すぐにSRE活動ができるかというとそうではありませんでした。組織の形も変わりましたし、ミッションも基盤運用の効率化から各事業部門のニーズに迅速に、そして確実に応えることに変わりました。何よりそれに合わせてメンバーの意識も変えていかなければなりません。ここからは、幾つかの観点から、どのように組織作りを行っていったかをみていこうと思います。

ミスを許容し、バラバラになっていた作業手順をまとめる

　まずは、作業手順を統一するところから始めました。共通基盤を管理するグループは1つになりましたが、インフラ（班）ごとに作業手順を個別に管理していたため、これをまとめなければ依頼への対応をスムーズに行えません。

　手順の統一作業を始めた当初は、「手順は既にあるから、まとめれば良いだけでしょ」と考えていたのですが、甘い考えでした。確かに手順書はあるのですが、それは“完璧”なものではありませんでした。各班のメンバーは、記載されていない作業手順を頭の中で補完し、実施していることが浮き彫りになってきたのです。

　「それならば、手順を書き換えればいいのでは？」と思うかもしれませんが、インフラの運用を行ってきた人たちは、「ミスは許されない」と教育されていることが多いのです。手順を更新することで、発生するかもしれない作業ミスを恐れて、なかなか手順書の更新が進みませんでした。

　そのため、私たちは「進化の過程で起こるミスは許容します。ミスを恐れて進めないことが一番問題です」と宣言しました。そこから徐々に、各班のメンバーから実際に行っている手順の情報が集まり始め、手順書の更新も進んでいきました。現在は、業務上で得たノウハウやプロジェクトの情報を、アトラシアンの企業向けWiki「Confluence（コンフルエンス）」にまとめています。

　さらに、現場メンバーによる、自発的な手順の一部省略や自動化なども進みました。ミスを許容し、新しいことに取り組める環境にすることで、現場のモチベーションも上がるという効果も生まれました。