クラウド移行を推進する専門チームは何をしてるの？1日の働き方を紹介します！

アイスタイル Advent Calendar 2024の11日目です！👏

はじめに

こんにちは、アイスタイルのクラウド推進チームに所属している白田(shiratah)です。

この記事では、私が所属するクラウド推進チームのエンジニアが一日にどのような業務を行っているかを紹介します。
これまでチームの紹介をする機会があまりなく、この機会に社内、社外の人たちにクラウド推進チームのことを少しでも知ってもらえたらと思います。

アイスタイル開発基盤Rebornプロジェクトの紹介

チームの紹介の前に、最近のアイスタイル全体での取り組みについて紹介させてください。
アイスタイルでは、数年前から開発基盤Rebornプロジェクト(以降、Rebornプロジェクト)として、AWS化を進めています。
少し前まではアプリケーションのAWSへの移行（リフト）がメインでしたが、最近はSQL ServerのTiDB移行やセキュリティ強化のための取り組み（InfoSec）など、インフラ全般に関わる業務が増えています。
こちらの記事にて紹介していますので、興味があればご覧ください。

クラウド推進のチーム紹介

Rebornプロジェクトの中でもクラウド推進チームは、主にAWSを使った開発共通基盤の構築や運用を担当しています。
現在は40個以上のAWSアカウントが存在し、AWS Organizations を使ったマルチアカウントの運用を行っています。
オンプレミス、Google Cloud など、他の拠点との接続も行っており、組織全体のネットワークが実質的な守備範囲となっています。
AWS 以外にもセキュリティ、オブザーバビリティ、開発チームからのAWSアーキテクチャの相談、コスト最適化など、インフラ全般に関わる業務を広く行っています。

現在はCCoE（Cloud Center of Excellence）のような動きがメインですが、最終的にはアイスタイルのSREチームとしての役割を担うことを目指しています。（アイスタイルにはまだ専任のSREチームは存在しません）

他企業のよくあるインフラ部署と少し異なる点としては、一般ユーザー向けサービスの運用保守を担当していない点です。
AWSアカウントとネットワーク構築後は、アプリケーション開発チームが自立して開発・運用できる状態を目指しています。
そのためオンコール対応など、サービスのインシデント発生時の対応は開発チームが行っています（もちろん障害発生時は早期解決のために協力します）

アイスタイル Advent Calendar 2024 10日目担当の itohisさんが紹介していた「クラウド領域に特化したサポートチーム」がまさに我々クラウド推進チームです。
「他者の助けを借りよう」クラウド移行準備のエピソード #Cloud – Qiita

自立したサービスの開発・運用ができるようになるため、全てのアプリケーション開発チームと連携し様々な支援を行うためインフラ以外の知識も必要とされます。
そのため、チーム内のスキル平準化を図りながらクラウド推進をするためにスクラムを採用しています。

チームメンバーは私含めて 10 人です。

プロダクトオーナー(PO) 1 名
スクラムマスター(SM) 1 名
エンジニア(DEV) 8 名

クラウド推進チームでは、様々な種類のタスクが発生するためタスクを大きく２種類に分けて定義しています。

プロジェクトワーク … ビジネスに直結するプロジェクトに求められているタスク
トイルワーク … プロジェクトワークを進めるうえでビジネスインパクトとしてはプライオリティが低くなるが運用上必要な業務

スプリントごとにトイルワーク担当者を決めてローテーションしています。
トイルワークは、Site Reliability Engineering（SRE）の考え方に基づいています
Eliminating Toil https://sre.google/sre-book/eliminating-toil/

具体的には、以下のような作業が含まれています。

チーム外からの各種問合せ対応
SSOユーザーの発行やDNS設定変更などの作業依頼
棚卸などの定型作業

運用上必要な業務ですが、自動化やセルフサービス化を駆使し、プロジェクトワークに割く時間を増やすことを理想としています。
スプリントでトイルワーク担当する人をトイラーと呼んでいて、現在は1スプリント2名体制でローテーションしています。
それ以外のメンバーはプロジェクトワークに専念しています。

この体制を取る前は、特定のメンバーに問い合わせが集中して改善系タスクがあまり進まないという課題がありました。
トイラーをローテーションすることで強制的にチームメンバー全員がトイルワークに関わることができ、問い合わせや定型作業の属人化を防ぐことができています。

1年ほど前にチームが発足し、初期からスクラム開発を続けていますが、日々の業務の進め方やチームの運営方法はメンバー全員で改善しながら進めています。
具体的な改善の取り組みについては、後ほど1日の流れの中で紹介します。

主に使用する技術はこの辺です。

AWS … インフラ構築、運用（特にOrganizations, Transit Gateway, Direct Connect）
Terraform … インフラ構築
GitHub … ソースコード管理
GitHub Actions … CI/CD
New Relic … モニタリング
Slack … コミュニケーション
Google Meet … リモートワーク
Backlog … タスク管理
Confluence … ドキュメント管理

それでは、朝の始まりから見ていきましょう！

朝の始まり（10:00~11:00）

クラウド推進チームの朝は、10:00のデイリースクラムから始まります。
在宅勤務やフルリモートのメンバーがほとんどなので、Google Meet を使用しています。

デイリースクラムは、大きく3つのタイムボックスを定めています。

10:00~10:15 トイルデイリー① … トイルワークの状況確認、AWSからのメール確認、コスト異常の確認、システムアラートの確認（PO,SM, トイラーのみ参加）
10:15~10:30 デイリー … プロジェクトワークの進捗確認、課題の共有など（全員参加）
10:30~10:45 トイルデイリー② … トイルデイリー①の中で、全体に共有したほうが良さそうなことを共有（全員参加）

当初は全体で30分のデイリースクラムを行っていましたが、メール確認やアラート確認などの確認作業を全員が参加する時間内に行うと効率が悪いため、トイルデイリーを分けることで効率化を図り今の形になりました。
結果的に全体で15分デイリースクラムの時間が伸びていますが、メリハリがあるため、全体の効率が上がっていると感じています。

スプリント内のタスクの担当割は、各々が取り組みたいタスクを取るといった進め方をしています。
そのためデイリーでは「このタスク取ろうと思ってるけど全然わからないので詳しい人教えてください！」や「やってみたけど方向性合ってるか見てもらいたい」など、積極的にコミュニケーションを取りながら進めています。

デイリースクラム後の10:45~11:00 は、週に2,3回のペースで輪読会を行っています。
輪読会は、チーム内の知識平準化とAWS環境の理解を深めるため、自分達が提供するAWS環境の設計書や開発者向けのガイドラインなどの既存のドキュメントを読んでいます。
自分達が作成した既存のドキュメントを読み返すことで、最新の設計と乖離がある部分があれば、それを改善する機会にもなっています。

デイリーが終わると、それぞれがタスクに取り組みます。

午前の業務(11:00~12:00)

自分の場合、午前中はタスクを進めることに集中していることが多いです。

タスクの進め方は人それぞれですが、ある程度形になったタイミングで50％レビューを実施し、途中の段階で他メンバーからフィードバックをもらう文化があります。
スプリントの最終日に、スクラムイベントとしてのレビューも行いますが、レビュー効率化のためにあらかじめ他メンバーに見てもらい、問題点を洗い出しておくことで、最終日のレビューではPOへの成果物の発表だけにするのが浸透してきました。もちろんPOも途中段階で見てもらっているため手戻りも少なくなっています

チームレビュー用のチャンネルでレビューをしています。

これも当初は、普段のコミュニケーション用のチャンネルでレビューを行っていましたが、コミュニケーションが早すぎてレビュー用のスレッドが流れてしまうという課題があり、レビュー専用のチャンネルを作成しました。

お昼休み(12:00~13:00)

決まったお昼の時間はないです。自分のペースでお昼を取ることができます。
ここはあまり書くことがありません。

午後の業務(13:00~18:00)

1日の流れがわかるブログにしたいのでこの構成にしてみたのですが、やることは正直午前とあまり変わりません。

あえてここではチームのイベント日について紹介します。

スプリントの最終日(初日)をイベント日として設定しています。
現在は、1スプリント２週間で回していて、イベント日は隔週火曜日になります。
このイベント日だけは1日のスケジュールが特殊で、ほぼミーティングだけで1日が終わります。

10:00~10:45 デイリースクラム … 先ほど紹介したものと同じです
10:45~12:15 スプリントレビュー … プロジェクトワークの成果物をPOに発表
13:30~14:30 スプリントレトロスペクティブ … スプリント内での振り返り、次回スプリントの改善点を議論
15:00~17:00 スプリントプランニング … 次回スプリントのタスクを決める
17:00~18:00 トイル引き継ぎ … 次回トイラーに引き継ぎ（トイラーのみ参加）

リファインメントは、スプリントプランニングの前日に行っています。
当初プランニングでのみプランニングポーカーを行っていましたが、議論が活発で時間が足りなくなったため、最近はリファインメントの中でプランニングポーカーを行うようになりました。
ちなみに、プランニングポーカーは、メンバーが自作してくれたツールを使っています。（土居さんありがとうございます！）

プロジェクトワークのタスクは、マイルストーンレベルはPOとSMが中心となって決めていますが、細かいタスクはDEVメンバーが各々にタスク化しています。
チームで取り組んだ方が良さそうな課題を発見したら、Slackやデイリースクラムで共有し、自主的にタスク化しています。

スクラムイベント以外にも、タスクを進捗するためにメンバー間でSlackやGoogle Meetを使ってコミュニケーションを取りながら進めています。

終業前のまとめ(18:00~19:00)

自分は、この時間には集中力が限界に近いので、込み入った作業は避けて、他メンバーのタスクをレビューしたり、Slackの未読を片付けたりしています。
チームメンバーに子育て世代が多いため、この時間には子供のお迎えや家事をするために早めに切り上げるメンバーもいます。

仕事終わり(19:00~)

1日お疲れ様でした！

1スプリント(２週間)のタイムスケジュールはおおよそこのような感じです。
ぱっと見ではミーティング時間が少ないように感じますが、チーム内でのスキル平準化をコンセプトにしているため、他の人が担当するタスクの情報共有・レビューに充てる時間がそこそこ多い印象です。（どんどんスクラムらしくなってきています！）

それ以外の時間は、自分の担当のタスクを進めたり、次のスプリントのタスクを個人でリファインメントしたりしています。

終わりに

クラウド推進チームの1日の流れを紹介しました。
私たちも日々スクラムが上手くできているか、組織全体に価値を提供できているか検査と適応を繰り返しながら進めています。
開発組織全体のRebornをしながら、自分たちもRebornを続けていきたいと思っています。

今回紹介していない取り組みがいくつもあるので、また機会があれば紹介したいと思います。

最後まで読んでいただきありがとうございました！