Edited at

60 万事業所が使うクラウドサービスを 3 人で運用するために心がけている 3 つのこと

More than 1 year has passed since last update.

この記事は freee Engineers Advent Calendar 2016 の 2 日目です。

こんにちは、freee 株式会社でインフラエンジニアをしている @manabusakai です。

今年の 5 月から freee で働いています(参考: freee 株式会社に転職しました)。

freee が提供する「会計 freee」は、おかげさまで 60 万以上の事業所で使われています。

インフォグラフィック

会計ソフトのイメージが強い freee ですが、ほかにも「給与計算 freee」や「会社設立 freee」など全部で 5 つのサービスを提供しています。

これだけ多くの方にご利用いただいているサービスですが、実はインフラエンジニアは 3 人しかいません(チームは 5 人ですが、1 人はデータ分析、もう 1 人は情シスが専門です)。

今回は、少人数でこの規模のインフラを支えるために心がけていることを書いてみたいと思います。ちなみに、技術の話はまったく出てきません :sweat_smile:


人やチームはスケールアウトしないことを肝に銘じる

AWS をはじめとしたクラウドコンピューティングサービスのおかげで、コンピューティングリソースをスケールアウトさせるのはオンプレミスと比べて圧倒的に楽になりました。

ですが、人やチームはそう簡単にはスケールアウトしません。

どこのスタートアップ企業もエンジニア採用に苦労していると聞きます。 freee も採用にはかなり力を入れていますが、やはり苦戦しています。こういう状況なので会社の成長とともにエンジニアの頭数を増やすような考えでは、現場の負担がどんどん大きくなり、あっという間に疲弊してしまいます。そのうちいい人が見つかるだろうなんて考えていると、疲弊した社員はさっさと転職してしまいます。

仮に採用がうまくいったとしても、人数が増えればコミュニケーションコストも増えるので、チームとしてスケールアウトさせるのは難しいのではないでしょうか。実際に人数をどんどん増やした結果、うまく回らなくなってしまったチームをこれまでの職場で見てきました。

freee の場合はまったく逆の発想で、サービスの成長に合わせてインフラエンジニアの人数を減らしています。もともと 5 人いたインフラエンジニアを、今年の 10 月から 3 人に減らしたのです(2 人は開発チームへジョインしています)。

サービスの成長とともにインフラエンジニアを減らすというのは一見大変そうに思いますが、少人数でも運用できる下地を作ることこそがインフラエンジニアの腕の見せ所ではないでしょうか。


インフラのことを知ってもらう努力を怠らない

freee には「あえて、共有する」という価値基準があります。


あえて、共有する

人とチームを知る。知られるように共有する。オープンにフィードバックしあうことで一緒に成長する。


自分はこの考えがとても気に入っていて、インフラのことをあえて共有するというのを心がけています。

freee には 70 名ほどのエンジニアがいますが、インフラを得意とする人はだいたい 1 割くらいで、大半はインフラ未経験で苦手意識を持っています。自分もプログラマーからインフラエンジニアになったので、最初のころに感じていた漠然とした不安や恐怖はよくわかります。

でも、開発とインフラに距離があると悪い結果を招きます。スケールアウトしにくい設計になっていたり、非効率な処理でサーバに負荷をかけたり、意図せず単一障害点を作り出していたり…。

これらは、お互いがお互いの領域を知らないために起こる不幸なことです。

そこで、自分が得意とすることを積極的に伝えていくことにしました。先日は AWS を触ったことがない初心者向けに、AWS のアカウントを作るところから手取り足取りハンズオン形式の勉強会を開催しました(ちなみに、このハンズオンに参加してくれたうちの 1 名が AWS 認定試験に合格しました!)。

短期的に見れば、手間がかかるだけで自分に直接的なメリットはありません。でも AWS に興味を持ってもらって、おもしろいと思った人が自ら勉強してくれれば、先に書いたような不幸は防げるかもしれません。そうすれば freee のサービスがさらに安定し、まわり回って freee を使ってくれるユーザーに価値を届けられます。


開発チームに首を突っ込む

上に書いたことにも共通するのですが、開発チームにどんどん首を突っ込んでインフラの知見を共有するように心がけています。

freee の場合はインフラエンジニアも企画段階から参加しますが、ある程度実装できてから相談に来られることも稀にあります(最近は気軽に相談してもらえるようになってきました)。そこで手戻りや見直しがあると、開発スピードが落ちてしまいますし誰もハッピーになりません。

そういうことを防ぐために、自分のリソースが許す限り、開発チームに首を突っ込むようにしています。

受け取ったメールを転送して取り込む」機能や「Excel から freee に会計データを取り込む」機能は自分も関わっていたのですが、積極的に首を突っ込んでうまく回った事例です。

インフラエンジニアの仕事はともすれば受け身になりがちですが、御用聞きのように積極的に首を突っ込んでみると仕事がより楽しくなります。繰り返しになりますが、自分たちの持っている知見を共有することは、長い目で見れば運用コストを下げ、少人数でも運用できる下地へと繋がっていきます。


まとめ

「インフラのことを知ってもらう努力を怠らず、自ら積極的に首を突っ込んでみる」

インフラエンジニアになって 3 〜 4 年になりますが、運用をうまく回すのは技術力だけではダメだということにやっと気づいてきた今日この頃です。

freee のインフラに興味のある方、ゆるく話をしてみたい方は @manabusakai までメンションするか、freee の採用サイトからご応募ください!

明日は、いつ見てもカレンダーが埋まっているのに、困ったときに颯爽と現れて問題を解決してくれる執行役員エンジニアの @yo_waka さんです!