こんにちは。
サービスプラットフォーム部 SRE チームの谷合です。
普段はメガネ集めと、毎日のビールを楽しみながら生きています。
2025年11月に入社してから今日まで、浮いているボールや浮きそうなボール、あるいはすでに落ちているボールを拾うことを、意識的にやってきました。
ちなみに、あとから振り返ってみると、その姿勢の背景には、Kyash 執行役員 VP of Engineering の Konifar さんの記事の影響があったように思います。
「ボールは落とさない」という考え方に以前から強く共感していましたが、入社後はそれを一段階進めて、「なら拾いにいこう」と思ったきっかけが、まさにこの記事でした。とてもいい記事なので、皆さんも是非ご覧ください！
今回のブログでは上記のKonifarさんの記事をもっと紹介したいところですが、私が入社後どんなボールを拾って、どんな結果になったかをご紹介します。
拾ったボール
SREチームは、日頃から様々な依頼を他チームや他部門から受けることがあります。 SREチームは割り込みタスクが発生しやすく、タスクが業務時間から溢れてしまいがちです。効率よく捌いたり、発生そのものを抑制する努力が大切です。 ですので、新入社員の私は先輩社員をサポートするためにボールを拾いまくる決断をしました。
そんな私が感じたのは SREチームの新入社員こそ浮いたボールを拾った方が良い ということでした。
自発的に課題を見つけて倒しに行く過程で、既存SREメンバーやその他の社員にとっては当たり前のことでも、新入社員の視点から見ると トイル であると気付くことができます。
また、浮いたボールを拾いまくることで、現状の歴史的経緯やコンテキストにも多く触れることができ、自身の成長にも繋がります。
実際に拾ってきたボールを、定常業務の巻取りと、参加する過程で見つけた改善のボールに分けて記載します。
まず、定常業務は浮いていたわけではありませんが、依頼量が多くて大変だったため、積極的に参加しました。
- AWS IAMユーザやグループ追加
- GitHubリポジトリ、チーム追加
- SREチーム内のコードレビュー
- 定例会議のファシリテーション
- ベトナム法人 ANDPAD VIETNAM (アンドパッドベトナム) のエンジニアのIaCレビューもしくはインフラ実装
一方で、参加する過程で「ここは改善できそうだ」と感じた部分は、浮いていた課題としてボールを拾って対応しました。
拾った結果
現在、弊社ではIAMユーザからAWS IAM Identity Centerに移行し、さらにIdPと連携させることでSSOへの移行を進めています。
しかし、まだ完全移行が完了していないため、前述したようにAWS IAMユーザの払い出しやグループへの追加申請は、SREの業務を圧迫することがよくありました。
各種アカウントやユーザ発行、グループ追加などの申請業務フローにSlackワークフローが使われていて、１つのチャンネルに様々な依頼が集まっています。
そのため、月末月初の入退社対応、開発に必要な権限払い出しや、グループ追加、GitHub関連の依頼が集まるチャンネルはカオスな状態でした。
このチャンネルにくる依頼の難しいところは、SRE以外のチームが対応する依頼も含まれるといったことです。
そんな無数の依頼に対して、SREチームはチャンネルを自発的に見に行き、対応すべき依頼を目視で見つけている状況でした。
申請が羅列されているので、SREチームが対応すべき依頼を探すのが大変だったため新入社員の私はこれを何とかできないかと考えました。
さらに、IAMユーザの払い出し後は初期プロファイルを手動でDMしていました。
加えて、弊社ではAWSで二要素認証を必須としているため、DM後にその設定がうまくできない人からの個別問い合わせが日本とアンドパッドベトナム両方で発生していました。
これらが結構なトイルとなっていたのです。
SREチームの稼働を圧迫していたボールを拾いまくった結果、以下のトイルが見えてきました。
- SREの対応すべき依頼を見つけるための目視
- IAMユーザの初期プロファイルを手動DM
- 二要素認証の設定個別対応
トイル解決へ
見つけたトイルに対して私は以下のアプローチをとりました。
依頼を見える化
当初、 SREチームが対応すべき依頼を目視確認 している状況について、以下のように一覧を自動作成する改善を検討しました。
- 対応すべきタスクを Slack リスト化
- 対応すべきタスクをスプレッドシート化
ところが、弊社の依頼が集まるSlackチャンネルのワークフローが作成する投稿のメッセージでは、リアクションをトリガーにできませんでした。
また、アンドパッドベトナムのエンジニアは独自のSlackワークスペースを持つため、このチャンネルにSlack Connectで接続しています。
Slackの仕様上、 外部の人が参加しているチャンネルではキーワードトリガーは設定できないため、 SRE といったキーワードを持つ依頼をトリガーにできませんでした。
そこで、「一覧の自動作成」以外の道を模索すべく、チャンネルの管理者にコンタクトをとり、一緒にソリューションを検討しました。 まず、弊社の依頼は以下のフローで処理されていました。
- 依頼者が専用のワークフローで依頼すると、チャンネルに依頼が投稿される
- 依頼を上席が承認する
- 管理者が投稿をSREに依頼する
- 目視で確認すべき数が多いため、対応漏れが発生する
そこで、以下のようにチャンネルの管理者に変更してもらい、SREが対応すべき依頼をfeedとして集約することで可視化できました。 このフローは今では上手くいってますが、SREから細かくFBをしてチャンネル管理者と一緒に連携してオペレーションを変更するなどして作り上げていきました。
- 依頼者が専用のワークフローで依頼すると、チャンネルに依頼が投稿される
- 依頼を上席が承認する
- 管理者が投稿をSREに依頼する
- SRE用の依頼を、別の feed チャンネルへ通知投稿するワークフローが動く
- feedの通知投稿には、依頼元投稿と依頼元スレッドリンクが記載される
- 依頼元で
対応するボタンを押すと対応者の名前がメンションされ、通知投稿に対応中スタンプが自動で押される - 対応後は
対応しましたボタンを押すと、通知投稿に対応完了スタンプが自動で押される
このようにSREだけでなく、他チームにいるSlack管理者を巻き込んで 会話 でトイルを解決しました。
また、このフローの副次的なメリットも生まれました。
以前は1つの依頼に対してオーナーを可視化する術がなかったので、依頼が対応中であることを知らずに複数の担当者で対応してしまうことが発生していました。
今回のフローに変更することで対応者の名前がメンションされることでオーナーが可視化でき、2重対応がなくなりました。
プロファイルの送信自動化
ここまでは申請をどのように可視化するかという問題に対して、目視によるトイルを他チームと連携して会話で解決するアプローチをご紹介しました。
ここからは、 IAMユーザの初期プロファイルを手動DM をどのように自動化してトイルを倒したかをご紹介します。
アンドパッドでは、IAMユーザはTerraformで管理しているのでコードを開発者に書いていただき、PRを起票いただくことでユーザを払い出しています。
その後、以下のフローで後処理を手動で実施していました。
- 初期パスワードをマネジメントコンソールで作成
- 初期パスワードとIAMユーザ名、マネジメントコンソールのURLをSlackへDM
毎月の月初には日本のみならずアンドパッドベトナムの新入社員のIAMユーザ払い出しが発生するため、累計するとそれなりに時間を要する作業でした。 さらに、人間がDMで初期情報を送っていたため、二要素認証の設定でつまずいたユーザーはそのDMで直接問い合わせてくることが多く、SREメンバーへの個別対応が頻発していました。
これを技術の力で解決しました。
まず、IAMユーザを作成した時に、CloudTrailで CreateUser イベントが発生します。これを Amazon EventBridgeで検知します。
Amazon EventBridgeはAWS Lambdaをトリガーし、以下の流れで処理を行います。
- アンドパッドのポリシーに沿ったパスワードを、初回ログイン時の変更を強制した上で文字列として作成
- aws/aws-sdk-go-v2パッケージのCreateLoginProfile関数でパスワードを登録
- AWS Systems Manager Parameter Storeに事前登録したSlack Bot Tokenを読み出す
- slack-go/slackパッケージを使用し、Slack Bot経由でDM
シーケンス図で書くと以下のようになります。
この仕組みのおかげで、IAMユーザの作成後は以下のDMが自動送信できるようになりました。
なお、弊社は日本だけでなく、アンドパッドベトナムもあるため、日本語と英語を併記しています。
Bot経由の自動送信に切り替え、メッセージ内で「問題が発生した場合は申請スレッドで問い合わせてください」と案内することで、問い合わせがオープンな場に集約され、個別DM対応のトイルも解消しました。
この自動化を実装したことで、SREは余剰の時間を別のタスクへ充てられるようになり、チームの生産性も改善しました。
さいごに
ここまで私がボールを拾いまくって、いつの間にかSREチームの長年のトイルを「会話」と「技術」で解決した話をご紹介しました。
ボールを拾うのはとても勇気が必要ですし、「できなかったらどうしよう」とか「自信がないな」とか色々と考えて一歩踏み出せないですよね。
でも、拾った先には所属チームから感謝されるし、自分の成長にも繋がります。何よりも数をこなすことで誰も気づかないチームの問題点にも気づくことができるようになります。
ボールを拾って、問題点を解決するなんて素敵なアクションにも繋がるので、是非臆せずに行動してみてほしいです。
浮いたボールにはチャンスがあるぞ！
We are hiring!
アンドパッドでは、「幸せを築く人を、幸せに。」というミッションの実現のため、一緒に働く仲間を大募集しています。アンドパッドのSREチームにご興味がありましたら、以下のページからご応募ください。カジュアル面談も実施しています。
