こんにちは。Strategic Products Engineering Unit SREグループの辻田です。2年半ほどお世話になった研究開発部Architectグループを卒業して、今年6月にSREグループへ異動してきました。
先日、名刺メーカーの開発チームメンバーとオフラインで集まり、ワークショップとモブプロ大会を行いました。
なお、本記事は【Strategic Products Engineering Unitブログリレー】という連載記事のひとつです。
目的
名刺メーカー開発チームは6月にメンバーが4人加入し、合計7人の2チーム体制となりました。SREを含めると10人です。3人→10人という急激なメンバー増加により、チームのコミュニケーションや課題の共有が難しくなっていました。
そこで、次の目的で1Day合宿を実施しました。
- チームメンバーの変更に伴い、メンバー間の親睦を深め、働きやすい環境を構築する。
- 各チームが抱える課題を短期間で改善する。
場所
メンバーは東京本社と関西支店の拠点に分かれています。技術本部総会で東京に集まる機会があったため、その際に合宿を実施しました。
チームラーニング（10:00-11:00）
チームラーニングとは
チームラーニングとは、マッキンゼーでプロジェクト開始時に行っているチームビルディングイベントです。
引用 https://www.persol-group.co.jp/service/business/article/393/
上の図はジョハリの窓という図です。この図は、自己開示の度合いによって、他者との関係性を表現したものです。図のように、開放の窓の面積が広い人ほど一緒に仕事をしやすいと言われています。気をつかわず、意見をぶつけ合える環境を作ることが大切です。
開催の様子
各メンバーが自分の取扱説明書を発表します。フリースペースにみんなで集まり、オンラインメンバーと共にわいわい*1と開催しました。
- 毎日17:00に上がりたい。
- 出社したほうが集中できる。
- ご飯は夕食だけでいい。
など、働く時間帯や環境、仕事のスタイルなどを共有します。人によってそれぞれ違う考え方があるので、それを共有することで、チームがより円滑に働ける環境を作ることが目的です。
ランチ（11:30-12:30）
チームラーニングが早めに終わったため、オフライン組は全員でランチに出かけることにしました。雑談に花を咲かせながら、おいしいご飯*2をいただきました。やはりみんなでご飯を食べるのは楽しいですね。
モブプロ大会（12:30-16:00）
午後はがっつり開発の時間にしました。次のような形でモブプロを実施しました。
- Aチーム、Bチーム、SREチームに分かれてモブプロを実施。
- 各チームが自由にテーマを設定し、短期間で改善したい課題に取り組んだ。
- 翌日に成果発表会で成果を発表。
モブプロ大会で取り組んだテーマと期待される成果
各チームが取り組んだテーマと期待される成果は以下の通りです。フロント、バックエンド、インフラにおいて、今後の開発に向けたリアーキテクチャの内容でした。顔を合わせて議論したほうが効率的なため、合宿に適したテーマとなりました。
| チーム | テーマ | 背景 | 期待される成果 |
|---|---|---|---|
| Aチーム | フロントエンドのV2アーキテクチャの理解を深める。 | 現在のフロントエンドはまだ既存メンバーのV2アーキテクチャへの理解が浅いため、オフラインで集中的に共有する機会としたい。まずは名刺一覧画面をリファクタしながら理解を深める。 | V2アーキテクチャのメンバーへの浸透。名刺一覧画面のリファクタ（ロジックとビューの分離）。ドキュメントの作成。 |
| Bチーム | バックエンドV2を作る！ | 開発を進めるために、早期にバックエンドV2の改修案や実装を作成したい。関係者がまとまった時間を取れて、顔を合わせて議論できる合宿が適している。 | 既存の集約（User）をV2で作成する。エンティティを作成する。post, get, putのAPIを作成する。ドキュメントを整備する。 |
| SREチーム | Terraformの差分0にする大作戦 | 適切な運用がされていないTerraformを早期に改善し、開発チームに触ってもらうために差分を解消する必要がある。短時間で改善を進める良い機会である。 | 構成やリソース名の方針が決まり、READMEに記載されていること。本番環境のplan結果がno changesになっていること。 |
成果発表会
合宿後は関西に戻るメンバーもいる*3ため、翌日に成果発表会を実施しました。各チームの実際の取り組み内容と成果を発表し、全体で共有しました。
短い時間でしたが各チームリファクタの方針やコード修正が進み、PRも出せました。
SREの取り組みについて
この合宿でわれわれSREチームは「Terraformの差分0にする大作戦」に取り組みました。
そもそも何でそんなことになっているんだ、という話ですが、
- 開発チームの運用に適した構成を考慮できていなかった
- 開発チームにIaCの重要性を説くことを怠っていた
- 開発チームと一緒に作業する時間を取れていなかった
などの原因が考えられます。今後は、開発チームとのコミュニケーションを密にし、適切な構成にしてハードルを下げることが重要です。
TerraformのTips
実リソースとTerraformを一致させるために、ひたすら地味で泥臭い作業*4を行いました。その際に得たTerraformのTipsを共有します。
applyしていい内容の場合
把握している変更内容や、listの順番の入れ替わりなどの変更がある場合は、通常通りそのままapplyして問題ありません。
コンソール上に存在する、かつ、コードに存在するリソース
これはstateに入っていないことが原因です。stateに入れるためには、terraform importを使います。
例えば、Google Cloud Monitoringのalert policyをimportする場合は次のようにします。
# アラートポリシー一覧を取得し、IDを確認 gcloud alpha monitoring policies list # terraform importでリソースをインポート terraform import google_monitoring_alert_policy.{resource_name} projects/{project_id}/alertPolicies/{alert_policy_id}
整理されたterraformコードの場合はimportブロックを使うほうが良いです。今回は対象が大量にありコードに全ての履歴を残すと大変なことになるため、コマンドを使いました。
コンソール上に存在するがコードにない or コンソール上に存在しないがコードにあるリソース
これは直接コンソールで作成 or 削除をしてしまった場合に発生します。現状一致させるためには、状況を確認してimport, destroy, rmで対応します。
おわりに
今回の合宿を通じて、各チームが抱える課題を短期間で解決し、メンバー間の親睦を深めるための第一歩ができました。リモート中心のため、貴重でありがたい機会でした。
これからも引き続き、チームの心理的安全性を高め、効率的に成果を上げるための取り組みを進めていきます。
