はったりエンジニアの備忘録

freee ではインフラチームに所属し、主に AWS 周りの構築や改善を担当しています（5 月に入社したばかりでキャッチアップするのに精一杯ですが）。

今回はインフラを改善するときに心がけている考え方をまとめてみました。これまでの仕事で経験したことがベースになっていますが、freee の開発文化とそんなに乖離していないと思います。

あえて 1 → 100 倍の改善を目指す

インフラの仕事はミスしたときの影響範囲が大きいので、何事にも慎重で小さな改善になりがちです。プロダクトを安定稼働させるというミッションを背負っているので慎重になるのは当然といえば当然です。なので、ユーザーや開発者が「おっ！」と感じるような改善はなかなか難しいのです。

だからこそ 1 → 2 倍の改善ではなく 1 → 100 倍の改善を目指す ようにしています。実現できるかどうかは別にして、最初から 2 倍を目指すのと 100 倍を目指すのでは大きな差が現れます。

普段からコツコツと改善することは大切ですが、チャレンジしていかないとただの運用エンジニアになってしまいます。安定期であればそれでいいのかもしれませんが、freee のように急成長を遂げているプロダクトでは非連続的な改善が必要です。

変化を恐れずに進化する

上の話の続きになりますが、インフラエンジニアは現状維持バイアスに陥りやすいです。プロダクトが安定稼働してくると現状に満足してしまい、「問題なく動いているものを変えたくない」という気持ちが芽生えてきます。エンジニアなら誰しも心当たりがあるのではないでしょうか？

ですが、周りを取り巻く環境は進化を続けています。 AWS のリリース回数を例に取ると、2008 年は 24 個だったものが 2014 年は 516 個になり、さらに 2015 年は 722 個ととんでもないスピードで新サービスや機能改善がリリースされています。

クラウドはオンプレミスのようにハードウェアの減価償却が済むまでリプレースできないという世界ではありません。現状維持にきっぱりとノーを突きつけ、変化を恐れることなく 1 ミリでも前へ進化し、プロダクトを支える必要があるのです。

人が運用しなくてもいいインフラ

自分が言うのも変な話ですが、インフラエンジニアにとってベストなインフラは 運用しなくてもいいインフラ だと思います。 AWS の設計思想に近いのですが、障害発生時の一次対応や定常的な運用は良しなにやってほしいのです。これはフルマネージドサービスを活用することはもちろんのこと、アプリケーションのアーキテクチャも含めて考える必要があります。

この点を考慮せずに無計画に構築してしまうと運用に人手がかかり、プロダクトの拡大に対してエンジニアの数が追いつきません。サーバーリソースをスケールアウトさせるのは簡単になりましたが、優秀なエンジニアを増やすことはますます難しくなっています。だからこそ、人が運用しなくてもいいインフラを目指す必要があるのです。

Facebook や Instagram がまだベンチャーだったころ、少数精鋭で運用していたのは有名な話です。クラウドという巨人の肩に乗るからには、この感覚は忘れずにいたいです。

最後に

所信表明みたいな内容になってしまいましたが、これから freee をもっと良くしていきたいと思います！