Tebiki では Datadog のアカウントを Terraform で管理しています。そのため、入社時などに Datadog のアカウントを発行するには、Terraform の定義を変更する PR を作成し、レビュー後に apply する必要があります。
作業そのものは難しくありません。ただし、依頼が来るたびにエンジニアの誰かの手が止まります。
Slack のメンションに気づき、必要な情報を確認し、リポジトリを開き、コードを変更し、PR を作成する。1 回あたりの作業は小さくても、こうしたコンテキストスイッチは集中力を少しずつ削っていきます。
・・・
こんにちは、プロダクトエンジニアの鈴木です。
Tebiki では最近 Devin が活発に使われていて、Slack 連携などの土台も整ってきています。
普段から触れているうちに、先ほどの「小さいけれど誰かの手を止め続ける業務」も Devin でなんとかできるのではないかと考え、この定型業務を再設計することに取り組みました。
結果、出来上がったものは「依頼者が Slack Workflow のフォームに必要情報を入力すると Devin が対象リポジトリで PR を作成してくれる」というシンプルなものです。
抱えていた課題
従来の業務の流れは次のようなものでした。
- 依頼者が Slack でエンジニアに Datadog アカウント発行を依頼する
- 気づいたエンジニアが Terraform の PR を作成する
- 別のエンジニアが PR をレビューする
- PR 作成者が deploy (terraform apply + PR merge) する
見ていただくとわかる通り、すべてのステップでエンジニアの作業が必要な状態です。Terraform を理解しているエンジニアにしか PR を作成できないので、これは当然のことでした。
私自身、何度も対応したことがありますが、作業リポジトリを切り替え、依頼内容をもとに変更を加えて PR を作ることは、小さなストレスとなっていました。
私がこの業務に感じていた課題は、次の 2 点です。
- 依頼者への返信や PR の作成など、エンジニアが同期的に作業しなければならないことが多い
- そのため、アテンションを取られ、コンテキストスイッチによって集中力を奪われる
返信の内容も作成する PR の内容も似たようなものなので、情報さえ集まれば「どのような PR を作ればいいか」は決まっています。
それにもかかわらず、依頼者自身が PR を作れないために、エンジニアが対応するしかない状況でした。
Devin を使えば、依頼者自身が PR を作成できる
Devin をはじめとした Coding Agent は、自然言語でプログラムの作成を依頼できます。
つまり、Terraform を知らない依頼者でも、Devin に依頼すれば PR の作成まで行うことができるようになるということです。
依頼者にとってやりたいことは、「このメールアドレスのアカウントがほしい」だけです。しかし実際に PR を作るには、どのファイルの、既存の並びのどこに、どんな形式で定義を足すか、という Terraform の作法を知っている必要があります。
この「やりたいこと」と「コードの作法」の隔たりこそが、エンジニアにしか PR を作れなかった理由でした。Devin は、リポジトリの文脈を読み取ってこの隔たりを埋めてくれます。
これは、「Terraform を理解しているエンジニアにしか PR を作成できない」という前提を覆します。
依頼者とコードの間にある隔たりを Devin が埋めることで、エンジニアが PR を作る手間そのものをなくせるのです。
Slack Workflow で、依頼受付と同時に Devin へ依頼する
とはいえ、「Devin を使えば PR を自分で作れるので、今後はそちらに依頼してください」というフローにはしませんでした。
依頼者は「Devin に何ができて、何ができないか」を知らない状態です。この状態で依頼を投げても、成果物にムラが出てしまい、結局はエンジニアによる修正が必要になってしまうことを避けたかったからです。
そこで、単に Devin へ丸投げするのではなく、依頼の受付を Slack Workflow に置き換え、必要な情報をフォームで収集する形にしました。
Slack Workflow で受付をした後は、入力内容をもとに毎回同じ構造のプロンプトで @Devin に作業を依頼します。
これにより、依頼者はフォームを埋めるだけでよくなり、Devin も毎回同じ形式の依頼を受け取れるようになりました。
同時に、対象リポジトリに「Datadog ユーザー管理用の Skill」を追加しました。どのファイルを編集するか、どのような操作を受け付けるか、変更後に確認すべき観点などをここにまとめ、Devin が依頼を適切に処理できるようにしています。
こうしてフォームと Skill の両方で入力と手順を揃えることで、作られる PR の質がより安定しました。
結果として、エンジニアへのメンションはなくなり、受付対応でアテンションを奪われる機会も減りました。Devin の成果物も安定しており、エンジニアが手直しすることはほぼなくなっています。
Approve された PR を自動で deploy する
Devin が PR を作るようになると、次は「Approve されても deploy されない」という事象が起きました。
Tebiki では、PR を merge / deploy するのは「PR の作成者」というルールになっています。Datadog の PR だけレビュアーが deploy するのは、運用ルールがちぐはぐになるため避けたいところです。
かといってこのままでは、せっかく PR 作成を自動化したのに、エンジニアが Approve 済みかを見に行って deploy する、という手作業が残ってしまいます（この仕組みを作ったのが私だったので、当初は私が都度 deploy していました）。
この課題は GitHub Actions を使うことでシンプルに解決できました。
Terraform を管理しているリポジトリには、deploy ラベルを貼ると apply + merge が実行される仕組みが導入されています。
そこで、Devin が作成した PR については、Approve されたら自動で deploy ラベルを貼るようにしました。こうすることで、運用ルールを変えることなく問題を解決できました。
まとめ
以上のようにして、「Datadog のアカウント発行」という定型業務で、エンジニアに残る作業を「Devin が作った PR のレビュー」だけにすることができました。
いまや、非エンジニアがソースコードを生成するのは珍しいことではありません。弊社でも、QA エンジニアが E2E テストを書いたり、デザイナーが軽微なデザイン修正の PR を出したりすることが、当たり前のように行われています。
プログラムを作るという仕事の障壁が下がってきたからこそ、これまで手を動かしてきた業務に対して「これは本当にエンジニアがやらないとできない仕事なのか？」と問い直すことが大切だと気付かされる取り組みでした。
そして、さまざまな業務が自動化されていく中でも、成果物の正しさを判断する役割は、引き続きエンジニアが担っていく必要があると考えています。
We are hiring!
Tebiki では、こうした業務改善や開発生産性向上に興味のあるエンジニアを募集しています。
プロダクト開発だけでなく、開発者体験の改善、社内業務の自動化、AI エージェントの活用、SRE 的な仕組みづくりに関心がある方は、ぜひ募集要項も見てみてください。
