株式会社に転職しました)。万以上の事業所で使われています。つのサービスを提供しています。人は情シスが専門です)。今回は、少人数でこの規模のインフラを支えるために心がけていることを書いてみたいと思います。はじめとしたクラウドコンピューティングサービスのおかげで、コンピューティングリソースをスケールアウトさせるのはオンプレミスと比べて圧倒的に楽になりました。人やチームはそう簡単にはスケールアウトしません。どこのスタートアップ企業もエンジニア採用に苦労していると聞きます。採用にはかなり力を入れていますが、やはり苦戦しています。いう状況なので会社の成長とともにエンジニアの頭数を増やすような考えでは、現場の負担がどんどん大きくなり、あっという間に疲弊してしまいます。そのうちいい人が見つかるだろうなんて考えていると、疲弊した社員はさっさと転職してしまいます。仮に採用がうまくいったとしても、人数が増えればコミュニケーションコストも増えるので、チームとしてスケールアウトさせるのは難しいのではないでしょうか。実際に人数をどんどん増やした結果、うまく回らなくなってしまったチームをこれまでの職場で見てきました。場合はまったく逆の発想で、サービスの成長に合わせてインフラエンジニアの人数を減らしています。人は開発チームへジョインしています)。サービスの成長とともにインフラエンジニアを減らすというのは一見大変そうに思いますが、少人数でも運用できる下地を作ることこそがインフラエンジニアの腕の見せ所ではないでしょうか。「あえて、共有する」という価値基準があります。共有する人とチームを知る。知られるように共有する。オープンにフィードバックしあうことで一緒に成長する。自分はこの考えがとても気に入っていて、インフラのことをあえて共有するというのを心がけています。割くらいで、大半はインフラ未経験で苦手意識を持っています。自分もプログラマーからインフラエンジニアになったので、最初のころに感じていた漠然とした不安や恐怖はよくわかります。開発とインフラに距離があると悪い結果を招きます。スケールアウトしにくい設計になっていたり、非効率な処理でサーバに負荷をかけたり、意図せず単一障害点を作り出していたり...。これらは、お互いがお互いの領域を知らないために起こる不幸なことです。そこで、自分が得意とすることを積極的に伝えていくことにしました。認定試験に合格しました!)。短期的に見れば、手間がかかるだけで自分に直接的なメリットはありません。興味を持ってもらって、おもしろいと思った人が自ら勉強してくれれば、先に書いたような不幸は防げるかもしれません。使ってくれるユーザーに価値を届けられます。開発チームに首を突っ込む上に書いたことにも共通するのですが、開発チームにどんどん首を突っ込んでインフラの知見を共有するように心がけています。場合はインフラエンジニアも企画段階から参加しますが、ある程度実装できてから相談に来られることも稀にあります(最近は気軽に相談してもらえるようになってきました)。そこで手戻りや見直しがあると、開発スピードが落ちてしまいますし誰もハッピーになりません。いうことを防ぐために、自分のリソースが許す限り、開発チームに首を突っ込むようにしています。会計データを取り込む」機能は自分も関わっていたのですが、積極的に首を突っ込んでうまく回った事例です。インフラエンジニアの仕事はともすれば受け身になりがちですが、御用聞きのように積極的に首を突っ込んでみると仕事がより楽しくなります。繰り返しになりますが、自分たちの持っている知見を共有することは、長い目で見れば運用コストを下げ、少人数でも運用できる下地へと繋がっていきます。年になりますが、運用をうまく回すのは技術力だけではダメだということにやっと気づいてきた今日この頃です。インフラ設計が得意分野。モットーは「はったりエンジニア」。upLoginユーザーは見つかりませんでした。