大規模なEOSL対応をどう進めるか。『SUUMO』の「2027年問題」に学ぶ

花島一太郎さん、松野啓一さんトップ画像

あらゆるソフトウェアに存在する「サポート期限（End Of Service Life、EOSL）」。EOSLを迎えたソフトウェアにはパッチなども提供されなくなるため、安定した運用が困難になります。メーカーからのアナウンスがあれば、より新しいソフトウェアへの移行計画を作成し、これまで動作してきたアプリケーションプログラムの稼働に影響がないかを確認し、場合によっては改修を加えるといった一連の対応が求められますが、それには多くの労力が必要です。

1つのシステムですらこれほど大変なEOSL対応ですが、賃貸を取り扱う事業、新築マンションを取り扱う事業など、複数の事業領域で構成されている『SUUMO』では、仮想化ソフトウェアのEOSLを機に「複数の異なる領域で横断的に利用される、12万以上のジョブが動作する横断バッチの移行プロジェクト」を実行、無事完遂しました。

事業に不可欠でありながら、新規サービスの立ち上げなどに比べると、地味で保守的なものと思われがちなEOSL対応。それも例を見ない規模で多くのステークホルダーが関わる横断バッチの移行を、どのように推進したのでしょうか。プロジェクトを率いた花島さん、松野さんのお二人にお話を伺いました。

※この記事は株式会社リクルートによるタイアップ広告です。記事末に、Amazonギフトカードプレゼントの告知もあります。

「ジョブ数12万件超え」の横断バッチを移行せよ
「リスクゼロ」を目指すのではなく、「リスクを前提に」コントロールする
“3つの工夫”でリスクをうまくコントロール
EOSL対応でも「ゼロをプラス」につなげるのがリクルート流
- 🎁 Amazonギフトカード1,000円分が100名に当たる！リクルートに関するアンケート 📝
- 関連記事

「ジョブ数12万件超え」の横断バッチを移行せよ

──お二人はどのようなお仕事をされているのでしょうか？まずは自己紹介からお願いできますか。

花島一太郎（以下、花島）　『SUUMO』のシステム開発のディレクションを担当しています。企画側と開発側の橋渡しをしながら要件やプロセスを設計し、開発プロジェクトを進行する役割です。前職はシステムインテグレーターで、より事業側のシステムに携わりたいと考え、2016年にリクルートに転職しました。

花島一太郎（はなじま・かずたろう）
株式会社リクルートプロダクト統括本部
プロダクトディベロップメント室販促領域プロダクトディベロップメント1ユニット（住まい）
住まい領域開発ディレクション部開発統括グループグループマネージャー

松野啓一（以下、松野）　花島の配下で、さまざまなサービスを横断する領域の開発ディレクションを担当しています。2023年に、ITベンダーからリクルートへ転職してきました。

松野啓一（まつの・けいいち）
株式会社リクルートプロダクト統括本部
プロダクトディベロップメント室販促領域プロダクトディベロップメント1ユニット（住まい）
住まい領域開発ディレクション部開発統括グループ

──大前提として、なぜ『SUUMO』でEOSL対応が必要になったのでしょうか？

花島　『SUUMO』はリリースから15年の歴史を持つサービスで、システム構成も非常に複雑になっています。これは、前身にあたる『住宅情報ナビ』などのシステムを統合した上、改築、増築が重ねられてきたからです。

そうしたシステムの基盤となる仮想化ソフトウェアのサポートが2027年4月に終了することを受け、関連するシステムを全面的に移行する社内方針を決定しました。

社内では「2027年問題」と呼んで、2020年ごろから事業全体でロードマップを作り、それに沿って賃貸、新築マンションなど『SUUMO』内の各領域で対応を進めてきました。

なかでも、今回紹介する「横断バッチ」の移行プロジェクトは難易度が高く、言うなれば2027年問題の“本丸”です。

──横断バッチの移行について、どのような点に「難しさ」があったのでしょうか？

花島　横断バッチとは、特定のシステムではなく、賃貸や新築マンションなどの複数の領域が利用するバッチ機能の総称です。

さらに、広告入稿や数値集計などの事業上重要な処理を担っているだけでなく、『SUUMO』の6領域で共通する処理を行っていたことから、影響範囲が広く、単純に「バージョンアップすればOK」というものではなかったんです。

──なるほど。対応が難しかった理由について、もう少し具体的に教えていただけますでしょうか？

花島　まず、横断バッチは、膨大なボリュームであることが挙げられます。バッチ数で3000、ジョブ数でいうと12万件を超える規模のバッチが、全7台のサーバで動いています。

松野　古くから動いているものが多いことも特徴で、中には、オーナーが分からないものもありました。

──であれば、ステークホルダーの数も膨らみそうですね。

松野　そうですね。なのでまずはそうした与件を整理し、システム全体を俯瞰するところがプロジェクトの第一歩でしたね。最初はそもそもスコープが見えておらず、「何から対応しなければならないのか」も分からなかったんです。だから、その辺りを明確にすることが最初の課題でした。

「リスクゼロ」を目指すのではなく、「リスクを前提に」コントロールする

──お話を聞く限り、雲をつかむようなプロジェクトにも思えますが、一体どこから手を付けたのでしょうか？

松野　これだけ大規模なバッチ移行プロジェクトは『SUUMO』の歴史上初めてでしたし、そもそも先行きが見通せないまま作業を進めるのは大きなリスクが伴います。そこで事前検証に時間をかけることにしました。

とはいえ、事前にどれほど問題を洗い出したとしても、リスクをゼロにはできないのも事実。それに、後続に納期制約のある案件も控えていたので、リスクがあることを前提に、生じるリスクをコントロールできる一定の範囲に抑えた上で、プロジェクトを進めていきました。

──事前検証において、どのような点に留意したのでしょうか？

花島　やはり性能の低下をいかに防ぐかというところでした。例えば、夜間のバッチ処理には数時間かかりますが、もしここで性能が低下して一時間余計にかかったとすると、全領域に大きな影響が及んでしまいます。

そこで、すでに各領域で導入されていたメモリやCPUの使用率を取得・可視化するツールを流用し、移行後にどこでどのくらい影響が出るかをシミュレーションしました。実際に、このフェーズで検知できた性能リスクもいくつかあります。

松野　一般的なシステム開発であれば、性能テストは開発終盤に実施します。ただ、その段階だと、大きな課題を検知した場合に改修コストが膨らみ、納期に影響が出ます。今回は要件定義の前段階で検証を行い、リスクを把握できていたのは大きかったですね。

──通常の開発とは違うプロセスで開発を進めた、という感じなんでしょうか？

花島　いわゆるウォーターフォール的な開発スタイルなんですが、工程を先取りしてリスクの吸い出しを行った、というイメージです。

あとは、『じゃらん』や『カーセンサー』といった他事業で過去に実施したEOSL対応の手順も参考にしました。「こうした場合には既存のアプリケーションが動かなくなる」といった情報を当時の担当者からヒアリングしましたね。

──先ほど、「オーナーが分からないバッチもあった」と語っておられましたが、ステークホルダーを把握するためにも、オーナーを割り出す必要がありますよね。どのように割り出していったのでしょう？

花島　利用頻度が低い、などの理由で担当部署が曖昧になっているケースもあったため、その機能の品質責任を担うのは誰であるべきか？を社内調整して決めにいったケースもありますし、中にはソースコード内のキーワードから関係者を洗い出すなんて場面もありました。

花島一太郎さん、松野啓一さんインタビューカット

それらを将来的にクローズする可能性があるもの、逆にどんどんエンハンスする計画があるものに仕分けして移行方針を練っていきました。

“3つの工夫”でリスクをうまくコントロール

──実際の移行作業はどのように進めたのでしょうか？

松野　3つ特徴があって、1つ目は「分割移行」です。一括移行すると開発工数は圧縮できる一方で、何か問題が発生した際の影響範囲がより大きくなり、対処できるメンバーリソースを取り合うリスクがありました。それなら、最初は小さく進め、その中で浮上した課題に対応しながら次のリリースを繰り返すほうが軌道修正しやすいだろうと。

とはいえ、最大限に対策を講じてもリスクを完全にゼロにすることは難しいですから、どれか1つは失敗する可能性を織り込んで追加レーンの分割策も用意しておきました。いざというときでも追加レーンに乗り換えれば、玉突きを起こして全体マイルストーンが崩れることを防ぎ、遅延の影響を限定的にできます。何かあっても別の手段があるというだけでも、安心感を持って進められますよね。

──そうですね。万が一トラブルが発生しても「奥の手がある」という安心感はあります。分割の単位はどのように決めたのでしょうか？

松野　いくつかパターンを作成して、「どうすればうまく当てはまるか」をパズルのように考えましたね。

2つ目の特徴として、プロジェクトの進め方という観点で、案件の優先度とコンティンジェンシープラン（不測の事態に備えた緊急時対応計画）をまとめ、各領域のステークホルダーと合意を取りました。

──「案件の優先度」とは具体的には、どのようなものでしょうか？

花島　各領域には事業戦略上のさまざまな事情があります。例えば、「この時期は繁忙期だからリリースしたくない」とか、「事業計画上重要なリリースがあるため、この時期は、開発モジュールの操作を禁止する“凍結期間”に重ならないようにしてほしい」とか。

でも、こうした個別要件について、その場その場で優先可否を検討していては、いつまで経ってもプロジェクトが進みません。

だから最初に、このプロジェクトで何を優先するのかを「五段階」で定義したんです。最も優先すべきは法令遵守やセキュリティで、もしそれに関連する問題が起きたら、プロジェクトよりも優先する。一方、あらかじめ売上計画に織り込まれた新商品などの開発計画は可能な限り取り込む、といった具合です。

もちろん、長いプロジェクト期間で、各領域で計画変更が生じる可能性はあります。その場合も、あらかじめ定めたボーダーラインの日付までであれば要望を受け入れプロジェクト側で取り込む。逆に、ラインを超えたものはプロジェクトを優先させ、各領域側でリソースやスケジュールを調整する、という形でデジタルに判断できる指標を整理・提示し、まずは各領域のステークホルダーと合意しました。

こうして最初にステークホルダーと目線を合わせていたので、動きやすかったですね。逆に目線を合わせないまま進めていたら、何か問題が発生したときに「どう対応するか」をめぐって議論が紛糾していたと思います。

松野　3つ目は、2つ目にも関連するのですが、私たちプロジェクト担当と各領域の協業体制（中央-各領域の二元体制）を整えたことです。全体のプロセスや進行状況は私たちが一元管理します。ただ、各領域固有の事柄については、私たちに知見がありませんから、そこは各領域が責任を持って対応し、品質を担保していくという形で分業したんですね。

──体制もしっかりと考えられているんですね。各領域とはどのようにコミュニケーションを取っていたのでしょうか？

松野　移行プロジェクト専用の会議体を作り、そこに情報を集約して各領域側に伝えたり、逆に領域側の課題をこちらにフィードバックしたりしてもらうようにしました。情報をこまめに共有した結果、何か起こった時のリカバリもスムーズに進められましたし、「ある領域でうまくいっていることが、本当にうまくいっているのかどうかを検証する」という品質マネジメントもできました。

松野啓一さんインタビューカット

──これだけ関係者が多いプロジェクトでは認識の相違が生じる部分もあったかと思いますが、目線を合わせるために工夫されたことは？

花島　関係者全員が参加するロングミーティングを定期的に開催していましたね。普段はリモートワーク主体ですが、会議室に集まり、私たちは「現状はどうなっているのか」「あるべき姿はどうすべきか」を、全員が見ている中で概略図にして何枚も何枚も書き、共通認識を合わせたんです。

というのも、最初は「ジョブ」という言葉一つとっても、具体的に何を指すのかが人によって違っていました。そんな状況で建設的な議論はできませんよね。

言葉の定義といった部分から細かくすり合わせたおかげで、途中で関係者が増えたとしても、プロジェクトを混乱なく進めることができたと実感しています。

また、途方もないプロジェクトの開始時から支えてくださり、計画・実行まで一緒に走り切っていただいた各社開発パートナーさんにも大変感謝しています。

EOSL対応でも「ゼロをプラス」につなげるのがリクルート流

──こうしたポイントをおさえたことで、移行プロジェクトは無事に終わったんですね。

花島　はい。トラブル0ではないですが、規模に対して比較的スムーズに移行を完了できました。

──先ほど、移行作業の進め方を詳しく伺いましたが、全体を俯瞰して、プロジェクトを成功に導けた要因は何だと思いますか？

松野　振り返りのスタイルを工夫したことかな、と思います。一般的に振り返りは全体のリリース後に実施するものですが、今回はプロジェクトが進行するなかでも分割移行の各フェーズでこまめに振り返りを行っていました。

例えば、一番最初の分割リリース時は、本番作業当日の報告の仕方や日中夜間のシフトの組み方に課題がありました。そこを改善し、最後の分割リリース時はだいぶスムーズにしました。ほかにも「こんな観点からのテストが足りなかったね」という振り返りをもとにテストを追加したり、環境起因で生じた問題をテスト内容に加えたりと、プロジェクトと領域、双方でノウハウを貯めていきました。

課題を逐一フィードバックし、その都度改善していく。そんな泥臭い動きが、プロジェクトのスムーズな進行を支えていたように思います。

花島　もう1つは、先ほども触れましたが、「リスクゼロ」を目指すのではなく「リスクを前提にコントロールする」というスタンスで臨んだことかなと思います。

──「トラブル0ではない」とおっしゃっていましたが、そもそもなぜトラブルが発生したのでしょう？

花島　非常に複雑な条件でのみ発生する障害で、プロジェクトと領域のコミュニケーションの中で発生条件の正確な認識合わせが出来ていないまま影響範囲の確認に進んでしまったことで起きてしまいました。この経験は今後のプロジェクトや日々の領域間コミュニケーションに活かしたい点です。

社内でも関係者間で振り返りを行い、モニタリング見直し等による再発防止に努めています。やはり、事前検証だけですべてをカバーしきるのは難しく、継続的なモニタリングは必須であり、もう一段、進め方に工夫のしようがあると思っています。

──なるほど。ここまで事前に緻密な計画を立てていても何かしら起こるのがプロジェクトだというのはリアリティがあります。最後に、今回のプロジェクトを通して「リクルートらしさ」を抽出するとすれば、それは何だと思いますか？

花島　EOSL対応は事業の根幹を支えるプロジェクトであるにもかかわらず、サービス立ち上げなどに比べ、ともすれば、「マイナスをゼロにする」といった保守的なイメージで語られがちです。

しかしリクルートでは、EOSL対応を通しても事業貢献を実感できます。というのも、今回プロジェクトメンバーには「単純に載せ替えるだけではつまらないから、QCDに抵触しない限り、積極的に利を取っていこう」と呼びかけていたんです。結果、EOSL対応を機に各領域でばらばらだったCI/CDなどの構成管理ツールを『SUUMO』標準となりつつあるものに統一したり、不要な機能の削除・冗長な処理の効率化を含めるなどして保守運用性も高められました。こんな風に、「EOSL対応をやってください」「はい」で終わるのではなく、「ゼロをプラスにする」ための提案・アクションにつなげるのがリクルート流ですね。

花島一太郎さんインタビューカット

松野　実は、リクルートに転職してから一番最初の大規模プロジェクトが、今回のEOSL対応だったんです。前職で経験した大規模プロジェクトでは、安全を期するためにも、たいていは要件やプロセスをウォーターフォールでガチガチに固めて開発を進めていました。

でも、リクルートの人たちは手堅く定石で進めるのではなく、（要件にフィットする）より良いやり方を模索します。例えば、分割リリースしたり、ウォーターフォールの中でも、プロジェクトの途中で改善を図るアジャイル的な動きを取り入れたり。

そのうえ、各領域のステークホルダーがプロジェクトを自分ごととして捉えているから、スムーズにコミュニケーションできる。この辺りはリクルートならではだと思います。

うまくいった前例をただ踏襲するのではなく、より良いやり方を志向し、少しでも課題があれば改善していこうというスピリットを、皆さんが持っています。EOSL対応も攻めのプロジェクトとして進められるところが、ユニークなところですね。

プロダクトディベロップメント室やリクルートに興味を持っていただいた方は、ぜひ下記もご覧ください。

		Recruit Tech Blog リクルートで働くエンジニアの様々な取り組みを掲載しています。
		RECRUIT TECH INFO エンジニアリングをはじめとしたテーマに関するイベント情報や取り組みについて掲載しています。