ごあいさつ
こんにちは。クライアントサービス開発部の吉次です。兼務先の品質系の部署やQAエンジニアの肩書きで記事を書くこともありましたが、同一人物です。 さて、今回は2024年6月28日（金）を持ってサービス提供を終了した『サラリーズ』について、チームやプロダクト内に眠る資産のサルベージとメンバーへの還元をテーマに振り返ってみることにします。
報酬水準データサービス『サラリーズ』の誕生から終了まで
世界の歴史を見てみると、盛者必衰・栄枯盛衰は世の常です。Webサービスの世界でも同じように、新しく生まれるものもあれば、終わるものもあります。
『サラリーズ』は、企業向けに労働市場の報酬水準のデータを提供することで、「フェアな処遇」の実現を目指す、というコンセプトのサービスで2021年5月14日に正式版の提供を開始しました。
もし良かったら開発物語も見てみてください。
サービス提供開始以降、順調に利用企業数を伸ばしていたところでしたが、経営方針に基づき2024年6月28日を持って終了しました。
ご利用いただいた顧客への感謝、約3年の歴史を振り返ったときの嬉しい思い出や苦労や寂しさ、コンセプトとビジネスを両立させる難しさなど色々な気持ちが入り混じってその日を迎えました。
今振り返ってみても、決して長くない歴史のサービスでも終わるときには色々な物語があったと感じます。
サービス終了時のエンジニアの作業
本題に入る前に、「Webのサービスが終了するときにどんなことが起こるのか」を軽くご紹介します。自分が開発しているサービスの終了に立ち会うという経験は誰もができるわけではない、ある意味貴重なものなので、何かしら参考になれば幸いです。
- 解約処理
- データ削除
- クラウドインフラ環境の削除
- ソースコードのアーカイブ
- ログの一定期間の保管
- アクセスされた際のリダイレクト対応やDNSレコードの削除
- ドメインの継続保持・終活の計画
- 各種ダッシュボードの削除
- 各種ツールの解約
ざっと思いつくだけでもこのようなものがあります。開発している最中に終わるときのことを考える機会もあまりないと思いますが、いざ終わりが来たときに行き当たりばったりだと対応が漏れるものが出てくるのは間違いないと思うので、終了することが決まったタイミングで早めに整理しておくようにしましょう。
プロダクトや開発チームに眠る資産の棚卸
さて、ここからが本題になります。先ほどは、
決して長くない歴史のサービス
と書きましたが、約3年は決して短くもありません。その期間の継続的な開発で形成された資産はたくさんあります。大雑把なカテゴリ分けと、カテゴリごとの例を挙げてみます。
| カテゴリ | 資産の例 |
|---|---|
| 技術要素 | アーキテクチャ、設計、実装など |
| プラクティス | プロジェクトマネジメント、運用ルールなど |
| 関係性 | 開発チーム内の相互理解、職種を超えた繋がり、開発組織の信頼残高など |
眼前のタスクをこなすのに夢中になっている日常の中では、例示したようなものがチームの資産として形成されていることには気づかないかもしれません。
開発チームのメンバーに資産を還元するための取り組み
せっかくの資産をサービス終了とともに捨ててしまえば無価値になってしまいます。このような資産をメンバーに還元することは、開発チームのリーダーの重要なミッションであり、かつ会社への貢献であり、『サラリーズ』そのものへの報いであると考えた私は、『サラリーズ 資産サルベージプロジェクト』を遂行しました（私が勝手に名付けて私だけが呼んでいただけで、表向きには単に『振り返り』としていましたが）。 今回はその中からいくつかの取り組みをご紹介しようと思います。
レトロスペクティブ
ここでは便宜上レトロスペクティブと呼ぶことにしますが、すごくカジュアルなディスカッションです。開発をしてきた中で感じた純粋な疑問点や気になっていた事の経緯などを事前に付箋に書いてもらいました。
その後、オンラインミーティングを開催して、テーマを1つずつピックアップしながら、知っている人が説明したり、みんなで意見を出し合って議論するという活動を行いました。
30近くものテーマが挙がり、大盛況となりました。改めてメンバー全員で率直な疑問点を挙げて議論したことで、色々な気づきがありました。
大きな問題がなく業務が成立していると改まって聞くタイミングがない
特にジョインして日が浅いメンバーについては、「なんでこの技術選定になっているんだっけ？」とか「なんでこういうルールになってるんだっけ？」みたいなことを改めて聞くタイミングがなかなかないものだなと思いました。業務上困ることがなければ尚の事ですね。
時間とともに育まれたチームの文化に対して意外と無自覚
チーム文化について、客観的に見たときのチーム文化に意外と無自覚になっていました。特に長くチームにいるメンバーほどその傾向が出るよう思います。これは良くも悪くもそうなのですが、当たり前・無自覚に成立していることこそそのチームの文化であるという気付きが得られました。この記事を読んでいるあなたのチームも、一歩引いてみると意外なところに良い文化・悪い文化があるかもしれません。
再現性を抽出することの価値
印象的だったのが、開発チームとして取り組んだ施策や技術選定など、過去に行った意思決定ついてのフィードバックを求める内容が多かったことです。先ほど例として挙げたディスカッションテーマの一部もその傾向が見て取れます。
「アーキテクチャ決定時の判断材料」や「Atomic Designわりと上手く行った気がするけどどうだったか？」みたいなテーマは典型的なのですが、2種類の問いに大別できそうです。
- 他者の意思決定の根拠を問うもの
- 自ら主導した取り組みに対するフィードバックを要求するもの
この問いに対してチームで答えを出すことは、チーム内で生まれた取り組みや意思決定の再現性を抽出する作業であるように思います。他者の意思決定の根拠を吸収して仮想的に自らの経験として蓄積することは将来的に自分が意思決定する場面で役立ちます。また、自ら主導した取り組みに対するフィードバックを得ることで、将来の課題解決の際に確信を持って同じやり方をしたり、過去の反省を生かしたやり方に進化させることができます。
インフラ再設計ワーク
次に紹介するのはインフラ再設計ワークです。
「今からサラリーズが立ち上がるとするならどう作る？」というコンセプトで、インフラの設計をチームみんなで実施しました。過去の技術選定・設計の反省点やGoogle Cloudの最新情報を踏まえたうえで改めて設計してみると、かなりシンプルな構成になりました。
3年間のサービス運営を通して、個々人のスキルのレベルアップも感じられる取り組みとなりました。
このワークは知識のアップデートと学び直しとしてうまく機能したように思います。実際に別のサービスでGoogle Cloudに新しくインフラを構築する場面でこのワークでの学びが大いに役立ちました。
せっかくなので、具体的にどんな設計になったかを一部抜粋して紹介したいと思います。
主なポイントを整理してみます。
サーバレスコンピューティング環境
オンライン処理系のサーバはApp Engineを利用していたところをCloud Runに置き換えました。サラリーズの開発着手は2021年だったのですが、当時から比べるとCloud Runの進化が目覚ましく、今では敢えてApp Engineを選択する理由はほとんどなくなってきているように思います。
Google Cloudのドキュメントにも以下のような記述が見られます。
Cloud Run は、App Engine のエクスペリエンスを改善するために設計されており、App Engine スタンダード環境と App Engine フレキシブル環境の両方の多くの最良の機能が組み込まれています。
詳細はリンク先のGoogle Cloudのドキュメントを参照いただければと思いますが、Cloud RunにはCPUやメモリなどのリソースやリージョン選択の柔軟性の高さなど多くのメリットがあります。
サーバレスコンピューティング環境とVPCの接続
実稼働していた構成ではServerless VPC Accessを使って、App EngineやCloud RunからVPCに接続していましたが、Cloud RunのダイレクトVPCを使って接続するようにしました。名前の通り、Cloud Runから直接VPCにつなぐことができるため、構成のシンプル化に一役買いました。
マイクロサービス構成と認証機構
実稼働していた構成では、ロードバランサのバックエンドサービスとして、フロントエンド（Next.js）・コアAPI（Node）・ファイル処理系API（Python）のサービスを接続し、パスルールによってアクセスを振り分けるという構成でした。
また、認証はコアAPIサービスにある認証APIによってcookieが発行され、認証が必要なAPIを呼び出す際にそのcookieを用いて認証状態のチェックをすることで実現していました。この認証チェックの処理が、コアAPIとファイル処理系APIそれぞれに存在していたため、それぞれの言語の違いも相まって、若干の煩わしさがありました。
再設計では、Next.jsで構築したフロントエンドサービスにカスタムサーバを追加し、BFFと位置づけました。BFFの責務としてユーザ認証を集約し、BFFとコアAPI・ファイル処理系API間のマイクロサービス間の認証は、Cloud Runのサービス間認証を適用しました。
また、マイクロサービス間の通信は内部トラフィックとして扱い、Cloud RunのIngressを内部トラフィックに限定することで、通信の経路を限定しました。
今回のワークでは設計までで実際に動かすところまではいってないので、もしかすると想定通りにならない部分もあるかもしれませんが、有益な取り組みになりました。
終わりに
以上のように、終了したサービスから資産をサルベージしてメンバーに還元することができました。この記事では書ききれていない内容もあるのですが、すごく価値の高い取り組みだったように思います。
このような取り組みは、サービスが終了せずともやってみると良さそうです。技術負債の返済やメンバーのスキル向上、開発プロセスやプラクティスの質向上に繋がる可能性を感じました。
さて、サービス終了後のサラリーズの開発メンバーはというと、別のサービスの開発現場で大活躍してくれています。終了したサービスからサルベージした資産はメンバーに還元され、メンバーが別の場所でその資産を活かす、という具合に資産が循環して新しい価値が生まれている様子を肌で感じことができ、喜びもひとしおです。
最後まで読んでいただき、ありがとうございました！
吉次 洋毅 Hiroki Yoshitsugu
クライアントP&M本部 プロダクト統括部 クライアントサービス開発部 シニアエンジニア
2014年に高専専攻科を修了後、飲食店検索サービスを提供するWeb企業に入社。PHPをメインにバックエンドの領域の開発やプロジェクトマネジメントに従事。2016年にインテリジェンス（現パーソルキャリア）に入社。doda AIジョブサーチの開発などを経て、現在はSalariesの開発やQAエンジニア組織の立ち上げや運営などを担当している。
※2025年2月現在の情報です。
