昨今、様々な業種の企業がアジャイルを推進していますが、自社のルールに則った本番運用を見据えたアプリケーションの構築に慣れていないスクラムチームも存在します。

私が所属する組織のスクラムチームでも同じような問題で悩んでいました。この問題を解決するために私達はSREチームを結成しました。

SREは商用サービスを安定稼働させ、そのための仕組みや考え方文化として広める役割を担っています。

このセッションでは、新人SREがスクラムチームに入って活動した事例をもとに、スクラムチームが自信を持ってサービスを開発していくためにSREと関わるメリットと実際の関わり方のイメージをお伝えします。

どうすればチームが自走し、安定して組織が拡大するのでしょうか？

組織が大きくなっていくとチームの数も増えていくと思います。

DevOpsを実現できるチーム作りでは、自動化やCI/CDなどの基盤となる仕組みを作っていくところから始まります。

ではその仕組みは０から作るのでしょうか？それともうまく行っているチームを参考にするのでしょうか？

もし、チームが増えるごとに０から仕組みを作っていては基盤作りだけで何日も、へたをすれば何週間も使ってしまうでしょう。

もし、他のチームを参考にしたなら、自分たちのチームに使えそうな部分を探し出すのに膨大な時間を費やしてしまかもしれませんね。

私が所属する組織でも同じようなことが起きました。

いくつかのチームを調べた結果、原因となっていたのは各チームが作った「秘伝のタレ」でした。

私たちは秘伝のタレの製造を防ぐために、共通のエンジニアリング基盤を作りました。

この基盤によってチームは素早くプロダクトの開発に着手でき、自走できるようになりました。

本セッションでは、私の組織で実現した、チームの自走を助け、安定して組織が拡大することを実現するエンジニアリング基盤について紹介します。

デンソーでは2017年よりMaaS社会の実現に向けてスクラムを用いたシステム開発を行なっています。

いくつものプロジェクトが立ち上がる中、あるプロジェクトで商用リリースが決定しました。

しかしながら商用サービスの運用経験がないチームであったため、商用リリースを前にスクラムチームのメンバーは「で、何すればいいの？？？」状態になっています。

そこで商用システムとしての信頼性を高めるためにSREチームが発足されました。

SRE（Site Reliability Engineering）とはGoogleが提唱した役割で、システムの可用性、性能、拡張性などを向上させることを使命としています。

そして実際のところ、SREには厳密な定義はなく、会社によって役割は異なっているそうです。

本セッションでは、実際にスクラムチームでSREとして活動し、試行錯誤の末に見つけたスクラムチームとの関わり方についてお話しします。