はじめに

初めまして、23卒エンジニア職内定者の丸山司と申します。

2022年9月7日から1ヶ月弱、サイバーエージェントのAI事業本部にある小売DX アプリ運用センターという部署で、サーバーサイドエンジニアとして内定者としてアルバイトをさせていただきました。

私は、開発者の生産性を向上させるためのあらゆるDevOps技術に興味があり（トランクベース開発、フィーチャーフラグ、自動テスト、リリースエンジニアリング等）、上記のようなDevOps技術を1つ経験することと、現場で働く中でエンジニアとしての目標を引き直すことを目的に内定者バイトに参加しました。

この記事では、実際に行った業務と学んだことについてまとめたいていきたいと思います。

アプリ運用センターとは

 

サイバーエージェントでは現在、小売/行政/医療などのドメインにおいて様々な企業様と提携し開発を行うDX事業に取り組んでいます。

アプリ運用センター（通称アプ運）はその中でも小売事業を展開されている企業様向けにアプリ開発/データ基盤構築をはじめとした開発を行う事業部です。POSシステムやAIカメラ、ビーコンなどの多岐にわたるテクノロジーを連携し、アプリ単体ではなく購買体験全体のUXを高めるアプリ開発を実現して行きます。（詳しくはこちらでご確認ください）

取り組んだこと

今回のインターンでは、バックエンド開発チームのFour Keysの計測と可視化を行いました。

Four Keysとは

Four KeysとはDevOps Research and Assesment (DORA) チームが実施した 6 年間の研究で明らかにしたソフトウェア開発チームの健全性を示す以下の4つの指標です。[1]

• リードタイム：組織による正常な本番環境へのリリース頻度
• デプロイ頻度：commit から本番環境稼働までの所要時間
• 変更失敗率：デプロイが原因で本番環境で障害が発生する割合（%）
• 復元時間：組織が本番環境での障害から回復するのにかかる時間

DORAの研究結果によると、Four Keysは開発チームの生産性だけではなく、サービスや企業の収益にも強い正の相関があると結論づけています。[2]

また、Four Keysは、CI/CDなどのDevOpsの実践と組織の開発文化が成熟しているチームほど優れた数値となっていることが明らかにされています。Four Keysの数値をきっかけに、開発チームの文化やDevOpsの実践について振り返ることが計測の目的です。

[1] エリート DevOps チームであることを Four Keys プロジェクトで確認する | Google Cloud Blog

[2] Nicole Forsgren Ph.D 他 『Lean と DevOps の科学』

計測の概要・流れ

現状、計測可能な「デプロイの頻度」と「変更のリードタイム」を計測しました。インシデントを管理できていないため、変更の失敗率や復元時間については、計測不可能でした。（実質、Two Keysです）

• GitHub Webhookから送信されるイベントを集計して計測
  • mainブランチへのプッシュイベント
  • GitHub Actionsのデプロイワークフロー完了イベント

計測基盤の実装

計測基盤は、OSSであるGCP/fourkeysをベースに構築しました。

• GitHub Webhook から送信されるイベントを受け取るサーバー（Event Handler）
• イベントをパースしてBigQueryにログを吐くサーバー（Data Parser）
• 各指標を可視化するGrafanaダッシュボード（Dashboard）

既存のOSSをベースとして、一部修正を行いました

• 既存のOSSでは受け付けていない、GitHub Actionsの実行イベントをBigQueryに保存する処理を追加（Data Parser）
• Grafanaダッシュボードを社内IPからのみアクセスできるアクセス制限を追加（Dashboard）

エリート DevOps チームであることを Four Keys プロジェクトで確認する | Google Cloud Blog より拝借

アプリ運用センターならではの計測

BtoBtoCという業態に由来する長い仕様決定のリードタイムがボトルネックとなり、頻繁なリリースが現状求められていません。短期的には、継続的なインテグレーションを目的として、マージを基準とした指標も計測した方がいいと考えました。1つの修正のサイズ（PRの大きさ）を小さくすることや、コードレビューを速くすることなどにより、マージを基準とした指標を改善することができます。

計測後の運用

私が内定者バイトを終えた後、「誰もダッシュボードの見方や活用方法がわからない」「継続的に数値を振り返えることを誰もしない」という懸念がありました。そこで、Four Keysがどう重要であるかやダッシュボードの見方、計測内容から改善が必要な箇所の提案などのドキュメントとして残しました。

Four Keys自体は、明確な開発のボトルネックを見つけることはできないので、開発プロセスを改善して、メトリクスの変化を評価するという改善サイクルを継続的に行っていく必要があります。入社後に、運用・改善を任せてもらって、チームの課題と対峙したいと思います。

学び・感想

内定者ランチで学びがたくさん

サイバーエージェントには、内定者バイトの学生と先輩エンジニアがランチに行って、技術や社内のことなどざっくばらんに話す文化があります。今回のインターンでは、AI事業本部含めて、社内の多くの先輩エンジニアとランチに行って、記事や書籍では知ることのできない技術的なお話をたくさんすることができました。

特に、私が最近気になっている技術・考え方であるトランクベース開発を実践されている江頭さんに、たくさん質問をさせていただきました。トランクベース開発は開発のアウトカムを向上させるプラクティスですが、多くの技術が下支えしていることを学びました。

技術的な広がり

ソフトウェアの設計やコード規約などのチーム課題、CI/CDの実現、リリースエンジニアリングなど、さまざまな技術が開発の効率を上げるために地続きでつながっていると感じました。

例えば、トランクベース開発で目的とする「重要なデプロイの心理的ハードルを下げる」ためには、Progressive Deliveryなどのリリースエンジニアリングを充実させたり、自動テストの適用範囲を広げたりなど密接に関わっています。ソフトウェアエンジニアとして大成するためには、繋がりを意識しつつ、技術習得をしていくことが大事だと感じました。

技術以外の部分・小売DXの面白さ

今回のFour Keysの計測をする中で、開発の生産性は技術的な部分に限らないことも感じました。例えば、企業様とやり取りをする業態の場合、企業様とどう仕様をすり合わせるかといった部分が開発のアウトカムを向上させる上で重要となります。

開発チームのマネージャーである後藤さんとお話した際に、「BtoBtoCという業態でのアジャイルを実現したい」とおっしゃっていて、小売DXドメインの面白さを垣間見ました。（後藤さんのインタビュー記事でも同様の内容をおっしゃられています）

最後に

アプリ運用センターはエンジニアの挑戦を歓迎している雰囲気があり、今回少し難しい課題でも挑戦させていただきました。また、技術習得にも積極的で、コミュニケーションもとりやすく、非常に働きやすい環境でした。メンターの坂上さんをはじめ、先輩の社員の方のサポートのおかげで、充実した1ヶ月を過ごすことができました。短い間でしたがお世話になりました！ありがとうございました！