有志の善意で回していた運用依頼対応を、AIで仕組みにした話
こんにちは、iCAREでソフトウェアエンジニアをしている越川と申します。
本記事では、他部署から開発チームへ寄せられる依頼（Dev依頼）への対応の歴史をご紹介します。
Slackのメンションに有志が応えていた属人的な時代から、現在のAIによる自動プランニングまで。7年あまりのプロセス改善の変遷を、当時の実データとあわせて振り返ります。
Dev依頼とは？
私たちが提供しているCarely健康管理クラウドでは、他部署から開発チームへさまざまな調査や対応の依頼が寄せられます。
内容は仕様確認や不具合調査が中心ですが、「ログイン失敗の原因の調査」「機能化されてないデータの削除依頼」など、バックエンドエンジニアによる直接的なデータ操作が必要なケースも含まれます。
こうした依頼への対応は、大きく4つの時代を経て今の形になりました。先に全体像をまとめると、次のようになります。
それぞれの時代を順に振り返ります。
属人化と疲弊の時代（Slackメンション）
数年前まで、依頼はSlackのチームメンションで飛んでくる運用で、決まったフォーマットはとくにありませんでした。
たとえばCSのメンバーが、顧客から受けた技術的な質問をチームメンションで投げる。気づいたエンジニアがスレッドで答え、自分に分からなければ「誰か分かる人いますか」と詳しいメンバーを探す。回答がまとまったらCSが顧客へ伝えて完了、という流れです。
誰が対応するかは決まっておらず、答えられるのはシステムに詳しい一部のエンジニアに限られます。結果として、その数人が自分の担当プロジェクトを抱えながら、有志で対応を引き受ける。依頼対応は、かなり属人的なものでした。
この運用には、大きく3つの課題がありました。
1つ目は、対応が個人の善意に依存していたこと。「気づいた人が答える」方式では、忙しいタイミングで誰も反応できず、依頼が宙に浮いてしまいます。依頼者から見ると、返事が来るかどうかは運次第です。
2つ目は、貢献が記録に残らないこと。対応の履歴はSlackのスレッドに埋もれてナレッジとして残らず、似たような質問に何度も答えることになります。集計もできないため、評価の時期になっても「誰がどれくらい貢献したか」が見えない。善意でチームを支えてくれているメンバーほど、報われにくい構造でした。
3つ目は、見通しが立たないこと。依頼がどれくらい溜まっていて、いつ完了するのか、誰にも分かりません。依頼者はスレッドを追いかけて催促するしかなく、エンジニア側も自分たちの負荷をコントロールできませんでした。
CS依頼だけはIssue化されていた（GitHub Issue併用）
この時代、CSチームからの依頼に限っては、GitHubにIssueを立てた上でSlackで知らせてもらう運用が並行して行われていました。2018年10月から2021年11月までの約3年間で起票された依頼Issueは900件超。月平均で約24件、多い月には60件を超えるペースです。しかも件数は年々増えており、2019年に月17件ほどだった依頼は、2021年には月33件まで増えていました。
ただし、Issueを立てるかどうかは依頼者の裁量に委ねられており、すべての依頼がIssueになっていたわけではありません。特に仕様確認のような「ちょっとした質問」は、Issueにはならずチームメンションで飛んできます。900件はいわば氷山の一角で、依頼の全体像は依然として見えないままでした。全体量が分からなければ、対応する体制やリソースの手当てを考えることもできません。
依頼窓口の一本化（ワークフロー期）
この状況を改善するため、2021年11月、Slackワークフローを導入して依頼の窓口を一本化しました。
依頼者はフォームに依頼内容・該当機能・期限などを入力して起票し、依頼は専用チャンネルに投稿されます。エンジニアの誰かが「対応します」ボタンを押して担当を宣言し、あとはスレッドでやり取りして完了です。2023年8月からは、起票と対応の履歴がスプレッドシートに自動で蓄積されるようにもなりました。
ワークフロー経由の依頼は月平均で約60件（記録が残る約1年半だけで1,000件超）。GitHub Issueに残っていた月24件の2倍以上の依頼が、実際には飛び交っていました。しかも約3割は仕様確認などの「質問」で、これまで記録に残らなかった依頼がはじめて見える化されました。
ただし、担当の決まり方は変わっていません。誰かが「対応します」ボタンを押すのを待つ、手挙げ方式のままです。しかもDev依頼は、対応しても評価には繋がりにくく、引き受ければ自分の担当プロジェクトの進捗にも影響します。積極的に手を挙げる理由が構造的に乏しいため、実態は「誰かが押してくれるのを待つ」お見合いのような状態で、結局は責任感の強いメンバーがボタンを押すことになっていました。
約半数の依頼は1時間以内に担当が決まる一方で、誰も押さなければ依頼は宙に浮いたまま。1割の依頼は、担当が決まるまでに6日以上かかっていました。
これが課題なのは、対応するかどうかが個人の責任感に委ねられているからです。依頼者から見れば、すぐ決まるか1週間待つかは運次第。見積もりの仕組みもないため、手を挙げ続ける人に負荷が偏っても、それは誰にも見えません。窓口は一本化できても、「誰がやるか」はまだ善意任せのままでした。
チケット管理と毎日のポーカー（Backlog期）
そこで2025年1月、依頼管理をBacklogへ移行し、人による管理を一段強化しました。チケットを起票して依頼する手順や基準をCSチームとすり合わせ、依頼フォーマットを整備。依頼はすべてチケットとして一元管理されるようになりました。
運用が軌道に乗った3月からは、プランニングポーカーを導入しました。狙いは、依頼の難度をストーリーポイントとして数値化し、キャパシティを管理できるようにすること。ワークフロー期の「重い依頼を引き受けた人に負荷が偏っても、誰にも見えない」という課題への答えです。
依頼対応を担うエンジニアを4人ずつのA・Bの2チームに分け、週替わりの当番チームが毎日14時から30分の会議を開きます。新しく来た依頼にチームでポイントを付け、負荷を見ながら担当者を決める。今週はAチーム、来週はBチーム。どちらの週も、毎日4人のエンジニアが会議に集まります。
さらに、ひとりが担当できるポイントをあらかじめ月単位で設定しておき、超過した担当者には、その月は新規の依頼を割り当てないルールにしました。これによって、特定の担当者に負荷が偏ることが起きにくくなりました。
依頼対応は、こうして「善意」から「仕組み」になりました。誰がどれくらい対応したのかは後から追えるし、依頼が放置されることもない。ここまでは大きな前進でした。しかし、運用していくうちに限界が見えてきました。
毎日30分×4人、延べにすると月に約40時間。その工数は、プロダクトを前に進めるためではなく、「誰が対応するか」を決めるためだけに使われていました。
また、15時に来た依頼は、翌日14時の会議まで23時間もアサインが決まりません。実測でも、担当が決まるまでの時間は営業時間ベースで中央値約3.7時間。半数の依頼は4時間を超えて待たされていました。確実に担当が決まる代わりに、すべての依頼が「会議を待つ」時間を支払う。手挙げ方式とはちょうど逆のトレードオフを抱えることになりました。
アサイン会議の自動化（AI期）
この会議工数とリードタイムを削るため、2026年3月、アサイン会議そのものを自動化する仕組みをプロセスに組み込みました。
具体的には、Backlogに依頼チケットが起票されると、あらかじめ組んでおいたn8nのワークフローが起動します。
BacklogのAPIからメンバーごとの負荷状況を集計して空きのある担当者を計算し、並行して、過去の実績データやレビュー履歴を埋め込んだプロンプトと依頼内容をLLMに渡してストーリーポイントを算出。
「ポイント付与」と「担当者」の提案がセットでチャットツールに投稿され、エンジニアはそれを確認するだけになりました。
提案されたポイントは人間がレビューして確定し、修正の履歴は次回以降の見積もりに自動で反映されます。
結果として、月に約40時間かかっていたアサイン会議は消滅しました。担当が決まるまでの時間は中央値3.7時間から19分へ、約1/11に短縮。1時間以内に担当が決まる依頼は18%から81%に増え、4時間を超えて待たされる依頼は49%からわずか4%になりました。手挙げ方式の「速さ」と、会議方式の「確実さ」を、会議なしで両立できたかたちです。
また、n8nのワークフローには、特定のメンバーにはポイントの低い依頼だけを割り当てる仕組みや、有給休暇などで不在のメンバーにはアサインしないようにする仕組みなど、運用実態に即した改良を重ねています。
今後に向けて
こうして振り返ると、私たちは一足飛びに自動化へたどり着いたわけではありません。メンションに有志が応える運用から、GitHub Issue、Slackワークフロー、Backlogと毎日のポーカー。どの時代の仕組みも、その前の時代の課題に対する、当時なりの答えでした。
遠回りに見えるかもしれませんが、この試行錯誤が今の自動化の土台になっています。ポーカーで依頼の難度をストーリーポイントに数値化していなければ、LLMに見積もりを任せる発想はありませんでした。担当者の自動選定も、ポーカー期に作った「月単位のキャパシティ管理」のルールをそのまま仕組みに写したものです。会議工数という限界は迎えましたが、無駄になった改善はひとつもありません。
自動化には確かな手応えがある一方で、課題も残っています。ストーリーポイント付与の精度には改善の余地がありますし、組んだワークフローをメンテナンスできるメンバーも増やしていく必要があります。
さらにその先には、「Dev依頼そのものを減らせないか（顧客やCSが自己解決できる幅を広げられないか）」「依頼への対応そのものをAIでできないか」という問いもあります。7年かけて「誰が対応するかを決める」を自動化してきた私たちの、次のテーマです。
読んでくださってありがとうございました。
この記事が「なるほど」と思えたら、「スキ」や「フォロー」もらえるとうれしいです。チームにもシェアしてもらえると、次の記事のモチベーションになります。
iCAREではエンジニアを募集しています
iCAREでは、「Carely健康管理クラウド」を共に開発していくエンジニアを募集しています。 これまでの経験を活かし、複雑な社会課題の解決に技術で挑戦したい方、ぜひ下記より詳細をご覧ください。
