活動報告
マイナビで運用する150枚以上のSSL証明書更新作業を、スクラムを用いてタスク管理してみました
こんにちは、マイナビエンジニアブログ編集部の井藁です。
今回は、自身が主担当であるSSL証明書の年末更新作業についてご紹介したいと思います。
概要
WEBサイトをセキュアに運用するために欠かせないものとして、SSL証明書があります。
マイナビでは多岐に渡るサービスを展開しており、全てのサイトに対してSSL証明書の適用を義務としています。
今回はそのSSL証明書について、マイナビで行っている更新作業にスポットをあてて紹介します。
マイナビにおけるSSL証明書
SSL証明書の役割は「通信の暗号化」と「WEBサイトの運営団体の身元証明」があります。
通信の暗号化については、どのような証明書でもほとんど違いはありませんが、運営団体の身元証明については、SSL証明書の認証レベルにによってその信頼性が変わってきます。
認証レベルは大きく分けて3段階あり、マイナビが運営する各サイトでは、最も認証レベルの高い「EV SSL証明書」を利用しております。
また、信頼性を保つため、SSL証明書には有効期限が設定されております。
国際的な権威である「CA/ブラウザフォーラム」上で、SSL証明書の有効期間を短くする議論がなされており、最大13か月の期間となる可能性があります。
上記を踏まえ、弊社では発行する全てのSSL証明書の期限を翌年末(12月31日)に統一しています。
2019年12月時点で、マイナビでは約150枚ものEV SSL証明書を利用しており、発行・更新・失効の手続きは「システム統括本部 ITソリューション部」が一括して行っています。
2019年度における年末一斉更新の課題と、工程の実施
証明書の更新作業は、その数の多さの他に、社内各所との調整や証明書発行元会社様との契約、実際の発行作業など、いくつかの複雑な作業工程があります。
作業の専門性と不具合があった場合の影響範囲の大きさから、担当者が固定され、属人化と作業の肥大化が大きな問題となっていました。
今回はこの「2019年度 SSL年末一斉更新プロジェクト」について、漏れを防止しつつ、膨大な更新時間を短縮する事を目的とし、スクラムとWBSを織り交ぜた管理法を実施してみました。
何故スクラムなのか
ここまでの話を聞くと、「固定タスクで昨年度も実績があり、期日が明確に決まっているのでウォーターフォール型が良いのでは？」と考えた方がいらっしゃるかもしれません。
自身も当初はそのように感じていましたが、今回これらの要素を取り込むことにした背景には2つの理由があります。
事業部ごとに事情が異なるので単一フロー化できない
まず前提として、SSL証明書の更新には以下のような作業段階があります。
- KEYファイル、CSRの作成
- SSL証明書の発行
- 発行されたSSL証明書をサーバに設定する
- ブラウザでの更新確認
上記の他に社内調整や発行元会社との契約手続きなど付随する作業もあり、これらは同時進行します。
加えて、状況に応じて「どこまでやるか」「どれを優先して処理するか」は逐次変化していきます。
このように複雑なプロセスを管理し、余裕を持って作業を完了するために、スクラムとWBSを織り交ぜたようなプロジェクト管理法を用いて更新を実施しました。
特に突発的な注文やフロー変更、取り消しなど様々な弊害が発生することもあり、それらの状況に対処できる手法としてスクラムを取り入れました。
スクラムの研修を受けたので実践してみたかった
ちょうど先日スクラムに関する研修を受けており、実践する題材として良さげだなと感じた、というのも一つの理由です。
自部署ではあまりアジャイル的な開発やタスク管理は行われていなかったこともあり、幅を広げる目的で取り入れてみました。
プロダクトバックログを作る際に配慮したこと
2018年以前については、特にタスクの洗い出しは行わず、通常時に行う更新フローを拡張した形で行っていました。
この手法の場合、単発の証明書発行・更新作業には向いているのですが、全ての作業が完了してから次の証明書の発行に進んでいたため、一度に大量更新をするのには向いていませんでした。
今回はスクラム的に行うということで課題を作業単位で可視化しました。
課題管理はスプレッドシートで実施。最終的には写真の数倍程度の長さの量になりました。
作成の際、今回のチームメンバーの中にはSSL証明書の更新フローの経験が浅い人が多かったこともあり、なるべく細かく分かりやすい作業単位にタスクを分解するよう意識しました。
「このシートと通常フローのマニュアルさえあれば、チームメンバーがどのような行動をとるべきか把握できる」という点を意識して作成しましたが、おおむねこの狙い通りに進んでくれたかなという印象です。
スクラム要素を取り入れて良かったと思ったこと
ここではスクラム要素を取り入れて良かったなと感じたことを紹介します。
チームのキャパシティが可視化できる
今までは日付で期限を切っていたため、リソース不足であろうともその日までに何とかする、という、チームに負荷のかかるような体制での運用をしていました。
しかし、スクラムの手法通りスプリント（単位タスク消化期間。今回は2週間としました。）を細かく区切り、そのたびにレビューと次回スプリントの見直しを行うことによって、チームキャパシティの見積もりが出来る様になりました。
結果的に、無理なスケジュールやタスク量を課すことなく、順調にノルマをこなすことが出来ました。
チームメンバー同士の交流が活性化する
今までは各チームメンバーにも役割が縦割りで与えられ、結果的に他の人が何をしていてどのくらい大変なのか分からないという問題がありました。
それに対し、今回取り入れたスクラムでは短期間で積極的に交流を図るため、リーダーとメンバー間、またメンバー同士での交流が活性化し、心理的安全性の確保や新たな進め方のアイデア創出にも寄与していたかなと思います。
今後の展望について
このSSL証明書については3年ほど携わっていますが、年々枚数が増加しており、年末更新だけでなく通常フローにおいてもコストが肥大化しています。
そのため、運用管理フローの自動化を行うようなプロジェクトの立案も行っています。
このプロジェクトでは今回よりも多くのリソースが割かれることになりますが、こちらにもスクラムを取り入れ、よりよいプロダクトの創出を目指したいなと思います。
※本記事は2020年3月時点の内容です。
