こんにちは！エンジニアのaboyです。これは自戒であり私の学びです。
コネヒト Advent Calendarの他の記事もお楽しみください。
私が携わったとある施策がありました。その施策はできるだけすぐに実現したかったので、当時思いつく仕組みで作りました。また、その後も不定期的に発生することが分かっていたので運用フローを定めました。
AIエージェントやツールによる段階的な自動化
その運用フローがこちらです。
- 👤 営業）Google Sheetsに指定項目を記入して、開発チームに連絡する
- 👤 開発）情報集約用のGitHub Issueを作成し依頼内容をまとめる
- 👤 開発）Issueの内容をもとに2つのリポジトリで実装する
- 👤 開発）Pull Requestをレビュー → マージ → デプロイする
- 👤 開発）担当者に完了連絡をする
最初に大枠の仕組みを作っておいたので、手順3で必要な実装というのは、2つのGitHubリポジトリ内に保持している定数を変更・追記するだけでOK。実装内容は数行程度なのでラクチンです。
数回繰り返すうちに、よくやるし対応方法も決まっているし簡単なので、手順3をラクにするためにAIエージェントに実装をさせるようにしました。その運用フローがこちらです。
- 👤 営業）Google Sheetsに指定項目を記入する
- 🤖 Zapier）1日1回、対応すべきものを検知してSlackに通知する
- 👤 開発）情報集約用のGitHub Issueと実装用のsub-issueを作成する
- 🤖 GHA※）sub-issueの対応をDevinに指示する（※GitHub Actions）
- 🤖 Devin）sub-issueの分だけDevinが起動し実装する
- 👤 開発）Pull Requestをレビュー → マージ → デプロイする
- 👤 開発）担当者に完了連絡をする
コネヒトのママリ事業部では、要求管理用のGitHubリポジトリにIssueを立てて、細かいタスクはシステム毎のリポジトリにIssueを立てるという方法がよく取られます。GitHubにはsub-issueという仕組みがあるので、Issueに紐づいているsub-issueの対応を一括でDevinに依頼できるワークフローを作りました。Devinのような自律型AIエージェントは、複数のリポジトリでの作業が必要なIssueに対して、それぞれのリポジトリごとに独立したセッションで仕事を進めてくれるのでとても便利です。
実装内容がシンプルということもあり、Devinは毎回完璧に実装してくれました。これで、営業メンバーが開発メンバーに連絡する手間と、開発メンバーが複数リポジトリで実装してPull Requestを出す手間が削減できました。
この運用で数回繰り返すうちに、今度GitHub Issueを人間が作成する手順3が無駄に思えてきます。どんなIssueを作るかというパターンは決まっています。この手順をGoogle Apps Scriptを用いて自動化した運用フローがこちらです。
- 👤 営業）Google Sheetsに指定項目を記入する
- 🤖 GAS）1日1回、対応すべきものを検知してGitHub Issueとsub-issueを作成する
- 🤖 GHA）sub-issueの対応をDevinに指示する
- 🤖 Devin）sub-issuesの分だけDevinが起動し、Pull Requestを開発チームに出す
- 👤 開発）Pull Requestをレビュー → マージ → デプロイする
- 👤 開発）担当者に完了連絡をする
以前の手順2,3をGASに置き換えました。Zapierだとsub-issueを作成する標準アクションが無かったため、どうせAPIリクエストを組み立てないといけないのであればこのタイミングでコネヒトで全員が使えるGeminiから直接コード生成ができるGASに変えました。地味にアクセストークンの管理などで考えなきゃいけないことがあったため、この過程でGASから自社のGitHubを操作するための簡単な仕組みも用意して、社内に展開しました。
さて、ここまででできた運用フローと、一番最初の運用フローを比べてみると、人間が行う作業は確実に減りました。
- 👤 営業）Google Sheetsに指定項目を記入して、開発チームに連絡する
- 👤 開発）情報集約用のGitHub Issueを作成し依頼内容をまとめる
- 👤 開発）Issueの内容をもとに2つのリポジトリで実装する
- 👤 開発）Pull Requestをレビュー → マージ → デプロイする
- 👤 開発）担当者に完了連絡をする
↓
- 👤 営業）Google Sheetsに指定項目を記入する
- 🤖 GAS）1日1回、対応すべきものを検知してGitHub Issueとsub-issueを作成する
- 🤖 GHA）sub-issueの対応をDevinに指示する
- 🤖 Devin）sub-issueの分だけDevinが起動し、Pull Requestを開発チームに出す
- 👤 開発）Pull Requestをレビュー → マージ → デプロイする
- 👤 開発）担当者に完了連絡をする
営業メンバーが入稿し、機械が実装し、開発メンバーがデリバリーするという運用フローになりました。やったね。
ある日、チームメンバーから「これって管理画面でできたほうがいいんですかね」という意見を貰いました。
現状の最適化か、あるべき姿の実現か
「た、たしかに〜」と思い、”管理画面から設定できる”をゴールに設定し、そのゴールをどうすれば実現できるかという観点で色々と見直してみました。
見直した結果、管理画面から設定できるようにするには、データストアも含めた5つのシステムに関連する改修が必要だろうということが分かりました。
やることは多いけど「できる」ということが分かりました。
もちろん、できるはできるが、果たして今やるべきことなのかどうかは判断しないといけません。ただこうして一歩引いて考えられたことは良いことでした。
管理画面からできるようにすることが本当にやるべきことなのか、というのも考えないといけません。管理画面からできるようにした後の運用フローというのは、この施策が世の中に価値を提供するまでの流れの中の開発メンバーの介入にしか影響しておらず、まだ営業メンバーの介入が残っています。
- 👤 営業）管理画面から入稿する
そもそも、この施策は誰にどんな価値を提供したかったのか。当時はイージーな方法で実現しましたが、改めてこの問いについて考えてみると、全然違う言葉のほうがこの施策を適切に表しているんじゃないかと思ったりしてきます。何十回と行われ、今後も行われるため、持続可能性の向上も考慮する必要があります。
未来を見据えて適切に課題を設定し、それに伴う変化をリードすることこそが私がすることだったのに、当時の意思決定から地続きの現状起点で考えていて、いつしか近視眼的になっていました。
ゴールを決めるとそのゴールに向けた方法がたくさん思い浮かんできます。「XXという作業を自動化する」というゴールを決めた場合、生成AIの普及も手伝って自動化する方法は本当にたくさんあります。今ある業務を効率化するという観点では便利なツールがたくさん存在しますが、仕事における「誰にどんな価値を提供するのか」「なぜこれを課題に設定したのか」そういったコンテキストを操作する思考を忘れたくないな〜という自戒でした。
