こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。

カミナシに入社して 5 か月ほどになりますが、プロダクト開発のことをキャッチアップしつつ、開発の一連のライフサイクルの中で生まれた不要なリソースを削除し続けていました。

ここで言う不要なリソースとは、次のようなモノを指しています👇

• 検証のために作ったけど、クリーンアップされずに放置されている AWS リソース

• リクエストがまったくないけど放置されているコンピュートリソース

• 放置されている Stale ブランチ

• オープンしたまま何か月も放置されている Pull requests や Issues

• メンテナンスされずに失敗し続けている CI やビルド

どこのエンジニアリング組織にも大なり小なり存在するのではないでしょうか？

過去のコンテキストを知らない新入社員からすると、これらの不要リソースは認知負荷が高く、オンボーディングの妨げになることもあります（一例を挙げると、カミナシの開発用 AWS アカウントには名前の似通った新旧の ECS クラスタが存在し、初見ではどちらが使われているのか分かりませんでした）。

新入社員は認知負荷の高さに気づいていますが、手間を考えると削除するのをためらいます。そして少しずつ治安が悪くなっていきます。いわゆる割れ窓理論で語られているような状態ですね。

これまでの経験から、不要なリソースは放置すればするほど対応するコストが雪だるま式に膨れていきます。そのため、カミナシに入社してから強い気持ちでコツコツと削除してきました。

今回は、具体的にどのようなステップで進めてきたのかご紹介します。例として、多くのエンジニアリング組織で使っているであろう GitHub と AWS を取り上げています。

進めるための心構え

具体的なステップをご紹介する前に、少しだけ脱線して心構えについて書きます。

こういった改善は普段の業務の中で少しずつ進めていくことになると思います。課題感からスタートするわけですが、成果が見えづらいわりに面倒な作業なので心が折れそうになることもあります。

なので、自分は次のような心構えで取り組んでいます。

• 一気にやろうとしない。一日一善の気持ちで少しずつ改善する

• 時間ができたらやろうと思わない。そんな日は未来永劫やってこないので、気づいたらすぐに行動する

• ユーザーに迷惑をかけない限りは「許可より謝罪」の精神でやる

誰かのためと思ってやるとだんだん辛くなってくるので、気楽にコツコツとやっていくのが良いと思います。

不要なリソースを削除していくステップ

後から簡単に戻せるものは即削除する

手始めに後から簡単に戻せるものは、気づいたらその場で削除していきましょう。たとえば、GitHub だと次のようなリソースのことです。

• 放置されている Stale ブランチ

• オープンしたまま何か月も放置されている Pull requests や Issues

ついでに、リポジトリの設定にある “Automatically delete head branches” を有効にしてマージ済みのブランチを自動的に削除したり、GitHub Actions を使って放置されている Pull requests を自動的にクローズすると良いでしょう。

• 検証のために作ったけど、クリーンアップされずに放置されている AWS リソース

クリーンアップされずに放置されている検証用の AWS リソースなども、Terraform や CloudFormation でコード管理されているのであれば後から簡単に戻せるので削除してしまって良いでしょう。

• メンテナンスされずに失敗し続けている CI やビルド

ずっと失敗しているような CI やビルドは治安を悪くするだけです。直せそうならすぐに直す、もしくは不要なら削除してしまいましょう。

ドキュメントや Slack を追いかける

上で AWS リソースの話を例に出しましたが、ちゃんとコード管理されていれば過去のコンテキストは追いやすいです。ただ、手動で作られているケースも往々にしてあります（だからこそ、不要リソースとして残ってしまっているわけです）。

そういう場合は、ドキュメントや Slack を追いかけて手がかりを見つけます。

カミナシは Notion をメインに使っていますが、実際のリソースを見て思い付く限りのキーワードで検索します。たとえば “xxx-batch” というリソース名であれば、次のような感じです。

• スペース区切りで “xxx batch”

• 日本語に変換して “xxx バッチ”

• 意味を変えて “xxx 非同期処理”

ドキュメントが残っていなくても、Slack には何かしらのやり取りが残っていることもあります。 Slack は高度な検索ができるので、手がかりを見つけやすいです。

ログやメトリクスを確認する

本番環境に関連するリソースは、使われていないと分かっていても削除するのは怖いです。ただ、そういう不要なリソースこそ後回しにすべきではないのです。

今やれば 30 分で終わるかもしれませんが、1 年後に先延ばしにすればもっと時間がかかるのはエンジニアなら容易に想像できると思います（uptime が非常に長い Linux サーバを止める感覚に似ている気がします 笑）。

• リクエストがまったくないけど放置されているコンピュートリソース

AWS のコンピュートリソースであれば、CloudWatch のメトリクスや CloudTrail のイベントログを丁寧に追いかけていきます。 ALB や CloudFront のようにログを出せるサービスであれば、それも合わせて確認します。

あとは、そのコンピュートリソースがユーザーからアクセスできる状態なのかも確認します。 ALB などのロードバランサであれば、いきなり削除するのではなく、まずは Security Group でインバウンドルールを絞って様子を見てみるのも一つの手です。

成果を共有する

不要なリソースを残さないカルチャーを作っていくためには、周りの協力も必要になってきます。そのために、何をやってどういう効果があったのか共有して周りの理解を得ましょう。

不要リソースの削除によるコスト削減などは分かりやすい例ですね。塵も積もれば山となるで、AWS re:Invent に一人参加できるくらいのコスト削減に繋がりました 🙌

不要リソースの掃除というと一見地味ですが、認知負荷が高い状態というのは少しずつ開発スピードを落としていきます。そして、溜まれば溜まるほど手を付けるのが億劫になります。

年末の大掃除シーズンですし、あなたの身近にある不要なリソースを削除してみてはいかがでしょうか？🧹

最後に宣伝です 📣
カミナシでは絶賛採用中です！ 一緒に強いチームを作っていく仲間を募集しています！