専任チームが存在しないカミナシでどうやってインフラの改善を進めているのか？

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

カミナシでは職能別のチーム分けをしておらず、エンジニアのロールは基本的に全員ソフトウェアエンジニアです。フロントエンドやバックエンドにとどまらずインフラやセキュリティも含めて、サービス開発チームがすべてを担っています。

CTO の言葉を借りるなら「システムのライフサイクル全体を見る」のがカミナシにおけるソフトウェアエンジニアであり、単一のチームで顧客への価値提供ができる体制を目指しています。

type.jp

しかし、個々人のスキルマップを見るとインフラ領域を得意とするメンバーが少なく、インフラの改善は後回しになっていました。

私は前職で 6 年ほど SRE として働いていたので、入社時点からインフラの改善にも着手しなければと感じていました。しかし、専任チームが存在しないカミナシでの取り組みは、まさに試行錯誤の連続でした。

今回は、そんなカミナシでどのようにインフラの改善を進めているのかご紹介させてください。

直近 1 年で取り組んでいたこと

まず最初に、カミナシで直近 1 年くらいの間に取り組んでいたインフラ領域の改善をリストアップしてみました。改めて振り返ってみると、試行錯誤しながらも継続して改善を進めることができました（3 〜 5 月が空いているのは大きめのリリースがあったり、チームの体制が変わったためです）。

日付	改善内容
2023 年 2 月	ECS に Auto Scaling を追加
2023 年 6 月	MySQL の文字セットを utf8 から utf8mb4 にマイグレーション
2023 年 8 月	ECS クラスターの式年遷宮
2023 年 9 月	Aurora MySQL の KMS キーの差し替え RPO 改善のためのバックアップ見直し
2023 年 10 月	TLS 1.1 以下を廃止
2023 年 11 月	Aurora MySQL 2 から 3 へのアップグレード
2023 年 12 月	IAM ユーザーの撤廃
2024 年 1 月	ARM アーキテクチャへの移行（順次）

繰り返しになりますが、カミナシにはインフラの専任チームは存在しないため、新たな機能開発や不具合修正などをやりながら上記のような改善を行っています。

また、リストには挙げていませんが、リソース削減やコスト最適化は継続的に実施しており、円安に苦しみながらも適切な範囲に抑えることができています。

note.com

改善を進めるための 3 つのスタイル

では、ここから具体的にどういうふうに進めていったのか見てみましょう。

カッとしてシュッとやる

1 つ目は、自分自身が手を動かして改善していくスタイルです。現状を良しとせず、カッとしてシュッと直す。自分が入社直後によくやっていたのはこのスタイルです。

この「カッとしてシュッとやる」というのは前職の freee の開発文化のひとつですが、いまだに自分の行動原理として根付いています。

答えが明確で一人でも解決できる課題については、このスタイルがとてもマッチします。当初はこういった課題がゴロゴロ転がっていたので、隙間時間に次々と倒していくことができました。短期間で目に見える成果が出るので、やっている方も割と楽しいんですよね。

そんなある日、CTO の @toricls さんからこんなことを言われました。

「その進め方には組織としての再現性はありますか？他のメンバーは成長していますか？」

この言葉にハッとさせられます。カミナシのサービス規模が大きくなれば、個人のやる気に頼ったこのスタイルではいずれ限界が来ます。また、いつまで経っても他のメンバーのスキルが向上しないため、チームとしてスケールさせることができず自分がボトルネックになってしまうのです。

時にはひとりでカッとしてシュッとやることが良いときもありますが、次のチャレンジとして他者と成果を出すスタイルを模索し始めました。

学びの機会を作って仲間を集める

2 つ目は、インフラのことを学びたい仲間を集めて一緒に改善していくスタイルです。

去年、aoman さんが記事を書いてくれた ECS クラスターの式年遷宮プロジェクトはまさにこのパターンです（本来の式年遷宮には宮大工の技術継承という側面もあるそうなので、そういう意味でもぴったりのネーミングだと思っています）。

kaminashi-developer.hatenablog.jp

インフラを学んでみたいと思っている人たちが挑戦しやすく、成果としても実感しやすい（普段のサービス開発の延長線上にある）課題にフォーカスしました。

たとえば、インフラ初学者にとってメンテナンスを挟まずにゼロダウンタイムで切り替えるというのは、程よいストレッチと緊張感が得られる絶好の機会になると考えました。一方で、VPC ネットワークの再設計まで含めてしまうと一気にハードルが上がってしまうので、そこはあえてスコープから外しました。

このように課題を言語化し、やることとやらないことを明確にすることで、インフラを学びたいという人をうまく巻き込んでいくことができるようになりました。

上記で紹介したデータベース関連の改善は、ほぼインフラ未経験の若手エンジニアと一緒に進めていましたが、最近ではインフラの改善に前のめりで参加してくれるようになりました。まだまだチームとして安定的に改善を回せる状態ではありませんが、1 年前と比べれば確実に底上げできていると感じています。

スクラムに持ち込む

3 つ目は、正攻法としてスクラムにインフラの改善を持ち込むスタイルです。

先に紹介した 2 つのやり方は、通常の業務に +α として取り組んでいるケースがほとんどでした。もちろん成果としてちゃんと評価してくれていますが、有志のやる気に依存しているという点ではサステナブルではありません。

そこでインフラの改善もプロダクトバックログに積み、サービス開発の一環として取り組もうとしています。

バックログに積む上で難しいのが優先順位づけです。 EOL を迎えるようなケースだと否が応でもやらざるを得ないので意思決定しやすいのですが、AWS Well-Architected にあるようなベストプラクティスに向けて改善する場合などはサービス開発のライフサイクルの中で優先順位を付けるのが難しいです。

先ほどの例を出すと VPC ネットワークの再設計などは、before / after でユーザーに対する価値が見えづらいため、なぜやるのかをきちんと言語化し、社内のステークホルダーとも対話を重ねる必要がありそうです。

このスタイルはまだ取り組み始めたばかりですので、これから成果に繋げていけるように工夫していきます。