システム基盤の移行と社外システム連携を同時に目指す

今回は、少し入り組んだ背景と経緯を持つプロジェクトを取り上げます。どの辺りが入り組んでいたかというと、元は別々に進められていた2つのプロジェクトを途中から1つのプロジェクトにまとめ上げたという少し特殊な事情があったのです。

このプロジェクトは当初、リクルートのとあるサービスを社外の提携先企業の別のサービスと連携させるという目的の下にスタートしました。しかしその後、某社において世間を大きく騒がすセキュリティ・インシデントが発生し、リクルートにおいてもWebサービスのセキュリティに対する要求が一段と厳しくなりました。そこで、リクルートのWebサービスのセキュリティ基盤をより強固にするためのプロジェクトが別途立ち上がりました。

当初、この2つのプロジェクトは要求元や目的、納期も異なる別プロジェクトでした。しかし、自社サービスを社外サービスと連携した後にセキュリティ・インシデントが発生した場合、自社サービス単体で運用していた時よりも被害の範囲は一層拡大してしまいます。そのため、社外サービスとの連携を実現するには、あらかじめ強固なセキュリティ基盤を構築しておくことは必須であるという機運が高まりました。

そこで、この2つのプロジェクトを統合して、リクルートのWebサービスの基盤をよりセキュリティ対策が強固なものへと移行させつつ、社外サービスとの連携も実現するという、2つのゴールを同時に目指すことになりました。

移行にはサービス停止が必須という高いハードルがあった

当時、私たちが目指したセキュリティレベルを達成するには、システム基盤に根本から手を入れる必要がありました。それには、大小合わせて50ほどあるリクルートのWebサービスを、旧システム基盤から新システム基盤へと一斉に移行させなければなりません。

そのためには、どうしてもある程度のサービス停止時間を設けることは避けられませんでした。しかし、サービスを停止するということは、それに伴う売上減少や機会損失が発生するということでもあるため、プロジェクトを成功させるには各サービスを運営する事業会社の理解と協力が不可欠でした。

この点の解決策として、各サービスを運営する事業会社の理解と協力を得るために、彼らとコミュニケーションを取るための専門チームを立ち上げました。そして、このチームのメンバーが、各事業会社の経営層から中間マネジメント層、現場のキーマンに至るまで、社内のあらゆる階層に対して今回のプロジェクトの目的を丁寧に説明しました。その結果、本プロジェクトの意義を理解してもらえたとともに、その後の事前検証やテストなどでも各社の協力を得ることができました。

社内システムと社外システムのリスク対策を分けて考える

このプロジェクトを困難なものにしたもう1つの要因が、冒頭でも紹介した通り、セキュリティ強化と同時に「社外サービスとの連携」という別のゴールも設定していたことでした。これは単に開発・テストのスコープが広がって人手やコストが掛かったというだけではなく、「リスクマネジメントのスコープ設定」という面でも難易度が上がることを意味していました。

リクルートグループ内のWebサービスについては、その詳しい内部構造や開発経緯を私たち自身が把握することができていたため、そこにどんなリスクが潜んでいるかも大体把握できます。そのため、「ここはリスクが高いから重点的にテストを行おう」「この部分はリスクが低いから工数を割かなくても大丈夫だろう」といった柔軟な判断を下すことができました。

しかし、社外サービスとの連携となると、そうはいきません。他社が構築・運用するサービスの内部構造や開発経緯について、私たちはまったく知る由がなく、完全にブラックボックスだったため、具体的にどの辺りにリスクが存在するかの判断がつきません。したがって、社内システムのようにリスクを細かく分類して優先順位を付けることができなかったのです。

そこで今回のプロジェクトでは、社内システムと社外システムとでリスク対策を完全に分けて考えることにしました。具体的には、社内システムに関しては各サービスや機能ごとに細かく優先順位を設けました。

例えばシステム移行時に何か問題が発生した場合に「このサービスは何が何でもサービスイン前に移行させる」「このサービスは最悪の場合サービスイン後での移行もやむなし」といったように、状況に応じて柔軟に対応できるよう準備をしておいたのです。一方、社外システムとの連携に関しては、連携先のシステムがブラックボックスであるため、そこまで柔軟な対応は実施できません。そこでリスクを最大限に見積もり、何らかの問題が起きた際は、最悪のケースとしてシステム連携自体の取りやめも視野に入れた上で、コンティンジェンシー・プラン(緊急事態用の対応計画)を組み上げる方針としました。

しかし、社外システムとの連携を取りやめることによって社内システムの基盤移行まで取りやめになってしまっては、後日あらためての移行が必要となり、再びシステム停止に伴う機会損失が発生してしまいます。そこで、万が一社外システムとの連携が失敗したとしても、社内システムの基盤移行に影響が及ばないよう、社外システム連携部分のみを元の状態へと切り戻せるコンティンジェンシー用プログラムを別途開発しました。こうした手を打っておくことで、2つのまったく異なるレベルのリスクをそれぞれ切り離してコントロールできるようにしたわけです。