※この記事は、2025 Speee Advent Calendar5日目の記事です。 昨日の記事はこちら

こんにちは、デジタルトランスフォーメーション事業本部 開発基盤グループの長谷川です。

まず私が従事している開発基盤グループについて簡単に紹介しますと、開発基盤グループは、「SRE観点とPlatform Engineering観点を併せ持ち、デジタルトランスフォーメーション事業本部の各プロダクトと開発組織のQCDを最適化するために問題解決・技術コンサルティング・仕組みづくりを主導すること」をミッションとして、複数事業部のインフラ基盤の構築やサービス品質の保守を実施している部署になります。

デジタルトランスフォーメーション事業本部には6つ以上のサービスが存在しており、開発基盤には様々な依頼や運用のための業務が発生しています。今回はその中でよく発生していたGCPの権限追加に関する省人化を企画〜運用まで実施した事例を紹介します！

目次はこちら

• トイル削減を何から手をつけるべきか
  • 直面した課題
• Step 1：現状の可視化とデータ収集 （準備フェーズ）
  • 問い合わせフローの整備
  • 依頼種別のラベリングによる構造化
• Step 2：ボトルネックの特定と要件定義 （企画フェーズ）
  • 2-1. 問題の特定: どのような依頼がどれくらい来ているのか
  • 2-2. 課題の抽出: BigQuery の権限追加フローの何がよくなかったのか
  • 2-3. 対策の整理(要件定義)
• Step 3：アーキテクチャの実装と組織連携 （実施フェーズ）
  • Azure ADとGWSを連携させた新フロー
  • プロジェクトを整理できていたことで、他部署の巻き込みがスムーズに
• 結果と学び
  • 成果の定義が、要件をシャープにする
  • 成果の定義が、確信を持った開発に繋がる
• 最後に

トイル削減を何から手をつけるべきか

そもそもトイルとはなんでしょうか。トイルとは、SRE（Site Reliability Engineering）において、エンジニアが本来注力すべき創造的な時間を奪う運用上の反復的なタスクを指します。Googleはこのトイルについて、以下のように定義しています。

トイルとは、手作業、繰り返される、自動化が可能、戦術的、長期的な価値がない、サービスの成長に比例して増加する、といった特徴を持つ作業です。

SRE の原則に沿ったトイルの洗い出しとトラッキング | Google Cloud 公式ブログ

つまり、サービスの維持には不可欠ですが、長期的には改善を生まないため、自動化によって排除すべき「人間がやるべきではない単純作業」です。開発基盤グループでも、こうした差し込み作業が日々の開発業務のノイズとなっていました。

直面した課題

ただ、SREに関しての書籍や記事でも日々の業務でもトイルを削減した方が良いことはわかっているのですが、トイルとなるものは大量にあるため全てを自動化しきることは現実的で⁨⁩はありません。焦点を絞る必要はあるものの、何から着手したらいいかわからない。

感覚的に「この作業が多い」「ここで時間が取られている」といったアタリをつけることはできます。しかし、あくまで感覚値であるため、「本当にインパクトがあるのか？」「投資対効果に見合うのか？」といった問いに対し、自信を持って答えることができませんでした。

特にこういった内部オペレーションの省人化や品質改善のリファクタリングなど、外部のユーザーに直接価値が届かない部分の改善は得てして狙う成果と投資対効果が曖昧になりがちです。手応え感を持ってプロジェクトを推進するために、まずはトイルの状況を定量的に可視化する ところから始めました。

Step 1：現状の可視化とデータ収集 （準備フェーズ）

問い合わせフローの整備

トイル削減に向けて、まず着手したのは問い合わせフローの整備です。

開発基盤グループではSlack にて依頼が飛ぶ形にしていましたが、そこにルールはほぼなく、特定のチャンネルで開発基盤グループのメンバーに向けて通知を行うというものくらいでした。そのため、実績として何にどのような依頼が来るかが一目ではわかりづらく、形式も揃っていないため微妙な認知負荷も乗り続ける状態でした。

◇Before

◇After

依頼種別のラベリングによる構造化

フローの整備に合わせ、分析を見据えて「依頼種別ラベル」を導入しました。依頼者が申請時にラベルを選択することで、データを構造化して蓄積できるようにしました。

（＊1ヶ月間で発生がなかった項目は除外しています）

* AWS/GCPの利用に関する相談* 権限に関して - BigQuery* 権限に関して - AWS/GCP* 権限に関して - DB(MySQL)* 権限に関して - Redash* 権限に関して - SendGrid* 権限に関して - iDaaS* 権限に関して - その他* ドメイン・DNSレコード追加管理依頼* メール認証レコード設定依頼 (SPF/DKIM)* その他

問い合わせフローは実行後に Google Spreadsheet に記録されるようになっているため、あとは集計するだけです。

Step 2：ボトルネックの特定と要件定義 （企画フェーズ）

準備が整ったところで、約1ヶ月間のデータを集計し、解決策の立案（企画フェーズ）に入ります。

2-1. 問題の特定: どのような依頼がどれくらい来ているのか

集計結果は以下のとおりです。

明らかにBigQuery の権限追加 が多いことが分かります。「AWS/GCPの利用に関する相談」というのも大半が BigQuery の権限追加に関しての依頼だったため、実質的には4割程度は BigQuery の権限追加に関する依頼でした。これでインパクト評価の土台が整ったので、次はこれが解決可能な問題なのかを特定していきます。

2-2. 課題の抽出: BigQuery の権限追加フローの何がよくなかったのか

では、なぜ BigQuery の権限追加の依頼が増えていたのでしょうか。当時のフローを整理すると、以下の構造的な課題が見えてきました。

抽出した課題：

• ① 基本的に複数のデータセット（サービスAとサービスBや、サービスAとサービスCなど）を閲覧するが申請は一つずつになっている（＝運用と実態が乖離している）
• ② 依頼経路が複数存在している（Slack上と、作業依頼を出せるツール）ことで、作業が自動化しきれていない
• ③ 依頼者のGWSアカウントに対して個別で権限を付与するため、毎回付与作業が発生する
  • ＊この時点でCLIコマンドを実行するだけの状態にはなっていましたが、それでも1作業あたり2、3分程度かかっていました。

現状のフローを整理する前までは頭にありませんでしたが、整理してみると運用と実態が乖離している状況になっており、それにより本来必要のない作業が発生していることがわかりました。

2-3. 対策の整理(要件定義)

課題を踏まえ、以下のように対応方針を整理しました。（ほぼ課題の裏返しですが）

• データセットとしては分かれているが実際は一緒に使用されているものをパッケージ化し一回の申請で共有できるようにすること
• 権限付与作業を一本化した上で、そこからの申請を自動化すること
• ユーザー個別で設定している権限をGoogleグループ(メーリングリスト)に対して付与することで権限管理を単純化すること

暗黙的に求められている要件も踏まえ、要件定義として整理すると次のようになります。

## 機能要件- データセットとしては分かれているが実際は一緒に使用されているものをパッケージ化し一回の申請で共有できるようにすること- 権限付与作業を一本化した上で、そこからの申請を自動化すること- ユーザー個別で設定している権限をGoogleグループ(メーリングリスト)に対して付与することで権限管理を単純化すること- 責任者による承認を得ることができること## 非機能要件- 現状会社内で使用している承認を得るツールを使用することで、申請者のツール使用コストや確認コストを減らすこと- BigQueryの権限追加に限らず、他のトイル削減に対応しやすい拡張性があること

ここまで要件が固まればあとは設計・実装のみ。

Step 3：アーキテクチャの実装と組織連携 （実施フェーズ）

Azure ADとGWSを連携させた新フロー

最終的に構築したアーキテクチャは以下の通りです。

申請フロー：

1. 申請者 Azure はアクセスパッケージを申請
2. アクセスパッケージが割り当たると Azure 上のグループに追加される
3. Azure のグループにプロビジョニング設定されており、対応しているGWSのグループに追加される
4. GWSグループにはあらかじめBigQuery権限が付与されているため、即座にアクセスが可能になる。

Speee で使用している Azure のアクセスパッケージを軸に申請・権限付与フローを作成しました。このフローでは開発基盤グループの作業が不要となっています。

プロジェクトを整理できていたことで、他部署の巻き込みがスムーズに

このアーキテクチャを実現するには、GWSグループの作成権限など、開発基盤グループ単独では持っていない権限が必要でした。

このような他部署を巻き込んでの実施はこれまであまり経験はなかったのですが、ここまでの一連のプロセスをドキュメンテーションしプロジェクトの定義を明確にしていたことであとは説明するだけの状態になっており、非常にスムーズに協力を得ることができました。

結果として、情報システム部の方々に迅速に対応いただくことができ、想定よりも早く上記のアーキテクチャに変更することができました。（情報システム部の皆さん、ありがとうございました）

結果と学び

リリースから半月ほど経過しましたが、今のところBigQueryの権限追加に関する問い合わせは0件 です。 開発基盤グループが抱えていた単純作業の約半分を自動化できた計算になり、差し込み作業が減った実感もあります。

今回のプロジェクトを通じた学びをまとめます。

成果の定義が、要件をシャープにする

トイルの分析から始めていたことで「ここは無理に実施しなくていいんじゃないか」「逆にここは必須」という判断基準が明確になり、チーム内でも対応スコープを明確にする会話がスムーズにできました。

機能要件もですが、将来的なトイル削減の成果を考慮して非機能要件もシャープにできたことが、成果定義を実施していたことの利点を強く感じました。

成果の定義が、確信を持った開発に繋がる

エンジニアとして開発するにあたり「これは本当に価値はあるのか？」がわからなくなり不安を抱えながら開発することも少なくないと思います。それに対して、自分の中で「ここまでやればこういった結果が出る」というのが明確になっていることで自信を持って進めることができました。

最後に

トイル削減についての一つの事例を紹介しました。Speee ではどのレイヤーに携わるエンジニアでもアウトカムを意識し技術を活用していく文化があります。そのことが読んでくださった方に伝わると嬉しいです。

そんな Speeeでは一緒にサービス開発を推進してくれる熱い仲間を募集しています！

新卒の方はこちら より本選考に申し込みが可能です！キャリア採用の方はこちらのForm よりカジュアル面談も気軽にお申し込みいただけます！

Speeeでは様々なポジションで募集中なので「どんなポジションがあるの？」と気になってくれてた方は、こちら をチェックしてみてください！興味がある方は一緒に働きましょう！