よろしくお願いします。
私たちのミッションを一言で言えば、「プロダクトの信頼性と成長を、技術基盤で支えること」です。具体的には、次の4つの軸があります。

1．安定稼働（可用性）：システムを安定的に稼働させること
2．拡張性：ユーザーの利用拡大に耐えられる拡張性や構造をつくること
3．セキュリティ：脆弱性対策や権限管理
4．開発の加速：エンジニアが開発業務に集中できる環境づくり

今はSalesforceをメインにしつつも、AWSを中心としたクラウドインフラの強化も進めています。特にマルチプロダクト化が進む中で、複数のプロダクトを横断して標準化された基盤を提供することが、私たちの大きなミッションです。
また、SREの視点を活かして、言語選定や機能設計といった開発の上流にも踏み込み、設計から運用まで一気通貫で関わっています。

一般的なインフラ担当は、環境の設計や構築・維持管理が中心になることが多いです。対してSRE（Site Reliability Engineering）はその名のとおり、エンジニアリングの仕組みによって信頼性を担保しながら、開発を加速させるところまでが領域です。

例えば、これまで手動で行っていた作業をコード化（IaC：Infrastructure as Code）して自動化したり、CI/CD（継続的インテグレーション／デリバリー）の仕組みを整えて、安全かつ高速なリリースを実現したりします。「作って終わり」ではなく、土台が壊れないように、そして運用負荷を下げ続けられるように仕組み自体をアップデートしていく。そこが大きな違いですね。

そうなんです。
脆弱性スキャンを自動化したり、エラーログの出力を設計して障害時の原因究明をスムーズにしたり。普段は表に出にくい部分ですが、これがあるだけで開発チーム全体の安心感とスピードが劇的に変わります。プロダクトの品質を左右する、非常にクリエイティブな仕事だと思っています。

当社には複数のプロダクトラインがありますが、基盤に求められるものは共通なんです。そのため、事業部を横断しているPOに所属しています。
それによって、特定のプロダクトに偏ることなく、全体最適の視点で一貫した基盤品質を提供できます。
また、POにはサポートの最前線から開発チームまでが揃っているので、SREが土台を固めることで、各チームがプロダクトの進化に集中できる環境をつくれる。この組織構造は非常に合理的だと思いますね。

チームスピリットのSREは、新しいシステムの基盤をゼロからつくっていける環境があります。決められた役割をこなすのではなく、自分で課題を見つけ、どう動いたらもっとよくなるか、思考をフル回転させて仕組みを構築できる。これは非常にやりがいがありますね。

直近ですと、マルチプロダクト体制が進む中で、AWSからのメンテナンス通知の量も増えてきたので、通知内容のサマリー作成や担当者への連絡をAIで自動化しました。こういう変化を捉えて先回りで仕組みをつくれるのが面白いですね。

最初はオンプレミス環境でインフラの保守運用を担当していました。その後、SIerで6年間開発を経験する中で、後半は運用の自動化にも取り組んでいました。
チームスピリットに入社したのは、課題を自分で定義し、自由度高くゼロベースから携われる環境に惹かれたからです。

まずは、クラウド基盤の底上げです。IaCによるインフラのコード化を徹底し、すべてのシステムが「標準化された土台」の上で動く状態を確立します。
そして、新規開発が始まる段階からSREが参画し、監視や自動化が最初から組み込まれた状態でスタートを切れるようにしたいですね。
プロダクトの価値を最大化するために、技術的な統括視点で設計をリードする。より上流からプロダクトに関われるSREチームにしていきたいですね。

チームスピリットは、今まさに基盤を整えて拡大するフェーズにあります。
「もっとこうすればよくなるのに」と、自ら課題を見つけて動くのが好きな方や、決まった正解がない中で、最適解を模索することを楽しめる方、一段上の視点からシステムを支えたい方には、これ以上ない面白い環境だと思います。

やるべきことは多いですし、スピード感も求められますが、「SREとはこうだ」という固定観念は必要ありませんので、ぜひいろんな方とお会いしたいですね。