こんにちは。G4B div Product unit でエンジニアをしている murata (@Natch___) です。

社内では toB 向けを中心としたプロダクト開発をいくつか担当しています。柴犬のアイコンを自身のシンボルマークとしています！（同じ部署にはレッサーパンダや、ぷよぷよもいるとかいないとか！？）

ところで先日、ギフティ社内の Dev横断会にて、「GCPの運用対応を半自動化してる話」というタイトルで LT をさせていただきました。

Dev横断会は、エンジニアの課題や知見の共有を目的とした部署間の知見共有会です。この会では社外秘の内容を含んだ、よりディープな話が発表されることもあります。

今回、私が発表させていただいた内容は外部公開OKとのことなので、せっかくならば知見を外部にお届けしたいなと思いました。

そこで、この記事ではその内容の抜粋をお届けいたします♪

発表内容の背景説明

ギフティには、 Giftee Campaign Platform （通称: GCP）という法人向けプロダクトがあります。

GCP は、主に「抽選で○○ギフトが当たる！」といったような抽選を主軸としたキャンペーンの施策を一気通貫で担えるシステムです。

この裏側では、 biz と dev が連携を取りながら日々の運用をサポートしています。（biz とは、主にクライアントと相対して仕事をするいわゆる弊社の営業担当のことです。）

私の発表では、biz -> dev への依頼を効率的に捌くために導入している半自動化の仕組みを紹介させていただきました。

発表内容

ここからは発表内容となります。

本記事で読みやすいように一部を要約改変しております。発表スライドを直接ご覧いただきたい場合は、下記のリンクをご参照ください。

発表スライドはこちら

こんな人向けに話をします。

「開発いらずでアレコレ自動化する方法、知ってる？」
- 自動化を支援するサービスの活用事例を紹介します。
「biz -> dev への依頼対応をどうやって捌いてる？」
- 自動化を駆使した運用フローの一例を紹介します。
「trello でもっと活用できる方法ある？」
- buttler というワークフロー自動化の活用事例を紹介します。

経緯（Why）

GCP では日常的に biz から dev へ種々様々な依頼が飛んできます。

例えば「~~~といったスキームでキャンペーン実施したいんですが、XXX機能は使えますか？」「YYYキャンペーンのZZZデータをだしてもらえませんか？」「なんかキャンペーンに参加できないユーザがいるんですけど、原因わかりますか？」など種々様々あります。

ビジネス構造上、eGift流通拡大に伴いbizメンバーは増える一方で、devメンバーは少人数でずっとサポートしています。まだ人が少ない間はそれでも十分にこなせる依頼量でしたが、工夫なしで臨むには厳しい状態に陥っていました。つまり、初期の PoC と同様のやりかたで対応できるレベルの規模では既になくなっていたわけです。

そこで、運用対応している中で感じたツラみをベースに効率改善しようと、ある日奮い立ちました。

どんな課題を抱えていたか？（Problem）

GCPの運用対応は、以下のような課題がありました。

運用フローが確立していない。
- Slackに投稿された依頼をあうんの呼吸で対応している。
運用対応できるメンバーが属人化している。
- 開発主担当が対応しがちでそれ以外のメンバーが対応できるようにならない＝一種の単一障害点となっている。
負担の偏り
- カバー範囲の広いメンバーに必然的に負担が偏っている。
運用対応の状況が見えない。
- 依頼過多のとき、対応できないまま埋もれてしまうリスクを内在している。
- 運用対応がバッティングし、片方の対応時間がロストするなど全体効率が悪い。

どんな改善ができたか？（What）

課題の裏返しですが・・・

運用フロー確立による効率・安定性の改善
- 運用フローを定め、フロー全体を半自動化しました。
  - 余計な作業ロスがなくなり効率的に運用対応をこなすことができるようになりました。
  - 自動化の恩恵で、運用上のヒューマンエラーが起きにくくなり、安定対応できるようになりました。
見えざるタスクの見える化によるリスク低減
- Trelloボード上で依頼の対応状況が可視化されました。
- 作業バッティングで時間がロストする心配がなくなりました。
対応の属人化、負担の偏りを解消
- 「担当のアサイン」を自動化しました。
  - 機械的なローテーションでアサイン（ラウンドロビン方式）
- これにより、対応メンバーのムラが軽減し、属人化・負荷の偏りを解消しました。

どう解決したか？（How）

「あうんの呼吸」運用対応を半自動フロー化して解決しました。

自動化にあたっては以下のオートメーションサービスを利用しました。

Zapier ( https://zapier.com/ )
- 各種サービスの操作などのイベントを検知し、アクションをトリガーできる
- Gmail, DropBox, Slack など様々なサービスに対応
- 様々なアクションの種類があり、カスタマイズ性が高い
Butler ( https://trello.com/ja/butler-automation )
- Trello 組込のオートメーション機能
- Trello内の操作をイベント検知し、アクションをトリガーできる
- Trello 組込みなので、当然Trelloの操作に強い

半自動化運用フロー

以下の図が構築したフローです。

1.依頼投稿
- biz が依頼を slack に投稿します。
2.対応フロー開始
- slack投稿に対し、 dev が絵文字リアクションをします。
- このslackリアクションをフックに自動化の仕組みが動きます。
Slack Event
- Action1.対応開始を告知
  - 対応開始を dev全員に告知します。
  - これにより、誰かが依頼を受けたことがわかります。
- Action2.依頼内容を Trello の Card に記帳
  - 依頼内容や当該Slackへのリンクが記載されたTrelloのカードが自動作成されます。
  - この action が次の Trello Event のフックになります。
Trello Event
- Action1.担当のアサイン
  - 上記 Action 2 で行われた Trello Card の作成をフックに起動します。
  - 作られた Card に対し、事前に定められた固定メンバーから一人をアサインします。
  - ここでアサインされた devメンバーが実際に運用対応します。
3.対応開始を報告
- タスクをアサインされた dev が対応開始を biz に報告します。
4.対応完了を報告
- タスクを終えた dev が対応完了を biz に報告します。
- これで一連の運用対応が完了します。

デモ

発表ではデモにて説明しましたが、この記事ではスクショにて流れのイメージを共有します。

1.依頼投稿 -> 2.対応フロー開始

GCPの運用は、何らかの依頼や相談事をdevメンバーグループへのメンションつきでSlackへ投稿することから始まります。

投稿を確認したdevメンバーが絵文字リアクションをすることで対応フローが開始されます。

Slack Event

絵文字リアクションをフックに「Action1.対応開始を告知」で dev が活動しているslackチャンネルに告知がされます。

その直後に「Action2.依頼内容を Trello の Card に記帳」が実行されます。

リアク字チャンネラーにより、投稿内容のプレビューおよびリンクからトレーサビリティを確保しているのもポイントの1つです。

Trello Event

直前の Slack Event をフックに「Action1.担当のアサイン」が実行されます。

ラウンドロビンメンバーというカードから一人が選出され、対象のTrelloカードにアサインされます。

文字通りラウンドロビン方式でローテーションされるため、均等にタスク配分が行われます。

3.対応開始を報告 -> 4.対応完了を報告

アサインされたメンバーが Trello を確認し、当該Slackでやりとりをして一部始終を担当します。

このフェーズでは臨機応変さを重視し、各自の責任に委ねています。

Zapier の設定

発表ではライブでお伝えしましたが、この記事では設定時のポイントだけ紹介します。詳細設定は発表スライドをご確認ください。

Zap = 1ワークフローの単位
TriggerとActionを設定
無料の範囲では、1つのZapに複数のアクションを設定できないため複数に分割

Action1: 対応開始を告知

Zap 1 (slack -> slack)
- 自動化の目的
  - 依頼があったことを dev メンバー間で共有する。
- Trigger
  - dev の誰かが依頼の投稿に絵文字リアクションをする。
- ポイント
  - Slack通知の内容にメンションを含めることで、いち早く気付けるようにしている。

Action2: 依頼内容をTrelloカードに記帳

Zap 2 (slack -> trello)
- 自動化の目的
  - 依頼内容をタスクにおこす手間を省く。
- Trigger
  - dev の誰かが依頼の投稿に絵文字リアクションをする。
- ポイント
  - 内容だけでなく、誰からの依頼かわかるようにしている。
  - 該当のSlack投稿へのパーマリンク埋め込みによって Trello -> Slack への横断を容易にしている。

Butler の設定

発表ではライブでお伝えしましたが、この記事では設定時のポイントだけ紹介します。詳細設定は発表スライドをご確認ください。

Rule = 1ワークフローの単位
TriggerとActionを設定

Action1: 担当のアサイン

Rule1
- 自動化の目的
  - 担当のアサインを人為的に行わせないことで、属人化・負荷集中を改善する。
- Trigger
  - 「運用タスク」にカードが追加される。
- ポイント
  - メンバーがローテーションでアサインされるようにしている。
  - ラウンドロビンメンバーから取り除くことで忙しいメンバーを一時的に除外できる。