CSとエンジニアを滑らかにつなぐ、タイミーでの「割り込みタスク」の運用フロー

タイミーでバックエンドエンジニアをしている江田（edy）です。

スキマ時間にバイトができるアプリTimeeを運営しています。

【タイミー】スキマ時間にすぐ働ける！200万人が利用している単発バイトアプリ

株式会社タイミー(Timee, Inc.)は、すぐ働きたい人とすぐ人手が欲しい事業者をマッチングするスキマバイトサービスを提供しています。企業・店舗さまの申し込み、またはワーカー向けアプリのダウンロードはこちら。

https://timee.co.jp/

エンジニアとしてサービス開発に関わる中で、日々のスクラムなどで「計画的に行っているタスク」とは別に、「CSなど別チームから急に依頼されたタスク」に対して、どんな優先度で、どのように向き合っていくとよいのか頭を悩ませていました。

試行錯誤した結果、タイミーではNotionを活用してそのような「割り込みタスク」に対処する運用フローをつくり、うまく回り始めています。

今回は、CSメンバーとエンジニアを滑らかにつなぐ、NotionとSlackを使った割り込みタスクの運用方法について、その背景やプロセスをまとめていきます。

プロダクトの改善フローや、体制づくりに悩まれているPMやエンジニアの方々の力になれると嬉しいです。

これまで、「サイトの情報が古いから変更をお願いします」といった割り込みタスクは、Slack上にのみ流れていて、依頼する人によって依頼の仕方もマチマチ、依頼の方法も不明、エンジニアも都度対応するのは大変、といった状況でした。

そこで、ストック情報を扱うツールとしてNotionを活用することにしました。

Notionは普段プロジェクトやタスクの管理、ドキュメントツールとしても使っているので、割り込みタスクもNotionで管理することに。

タイミーの割り込みタスク管理は、NotionとSlackを使い「割り込み可能なチケット数」を決めて、チケット数の範囲であれば、割り込みタスクに対応していくような流れになっています。

まずは、サポートメンバーが、プロダクトの不具合や要望をNotionに起票。

割り込み可能なチケット数は、エンジニアの負担や割り込みタスクの数から、現在は2週間で14と決めています。

そのため、CSメンバーは残りチケット数を見ながら起票を進めていきます（厳密には、CSのリーダーが「チケットを使ってでも解消したい」というふうに優先度を決めてくれています。）。

割り込みタスクの種類には、3種類を用意しています。

• データ変更依頼 … 古い情報の差し替えなど
• 仕様確認 … ボタンの文言がどんなロジックで変わるか、など
• 調査依頼 … 原因がわからない不具合の調査依頼など

そして、Slackワークフローを使って、割り込みタスクをエンジニアに伝達。

また、CSメンバーはアルバイト等タイミーでの業務にまだ精通していない方々もいるため、依頼方法について共通の認識を持ち、依頼を一定の水準にするための手順書も用意しています。

データ変更依頼、調査依頼、仕様確認の3パターンそれぞれに対応するNotionテンプレートを用意しており、

エンジニアが対応する際に必要なプロパティの入力チェックボックスや背景や期限の理由などの記入欄が自動生成されるようになっています。

これにより、情報の抜け漏れ防止やコミュニケーション往復回数の削減、また情報の標準化に繋がっています。

報告した依頼内容は、要望を報告する #product_エンジニア依頼 チャンネルに流れてきて、必要な場合は担当するエンジニアがスレッドでコミュニケーションをするようになっています。

こうして、Notionには割り込みタスクがチケットごとに溜まっていきます。

エンジニアチームで、毎朝やっているDaily Standupで対応する割り込みタスクを決定し、優先度も併せてつけて対応を進めていきます。

外部の顧客に価値提供するタスクや納期が差し迫っているタスクは優先度を高くしており、社内運用向けであったり、期日の交渉が可能なものは優先度を低くして、過度に開発のスケジュールを圧迫しないように努めています。

依頼内容について、もっと細かく把握したい場合は、Slackのスレッドでやりとりをしていきます。

まとめると、

• 割り込み可能なタスクの数を「チケット数」として決める
• 依頼の際は割り込み可能な数の中で、CSメンバーがNotionに起票し、Slackで報告
• エンジニアメンバーが優先度を決めて、適宜コミュニケーション

というフローになっています。

こうして、CSメンバーはより割り込みタスクの依頼もしやすく、エンジニアメンバーも突発的なタスクに対応することがなくなりました（エンジニアの方々には多いかもしれませんが、突発的なタスクはストレスになることも多いのでなるべく避けたい...）。

普段行っている業務や、所属しているチームが異なると、どうしてもチームや職種をまたいで依頼することが億劫になったり、そもそも依頼方法が分からなかったりします。

ここまでの事例紹介でも扱った通り、依頼プロセスの入り口を日常業務で多用するSlackのワークフローに設置したことで、スイッチングコストを抑えながらシームレスに依頼手続きを開始したり、依頼方法が分からなくてもワークフローを起動すれば文言に従って情報を入力するだけで手続きが済むようになりました。

現在では、さらにNotionのプロパティをCSVでエクスポートし、過去数ヶ月でどういった種類の依頼がなされているかの定量的な分析も行っています。

頻度や削減できる工数などを総合的に判断し、必要あればエンジニアがリソースを投下して機能追加をしています。

ストック情報を活用して根本的に割り込み依頼を発生させないようなアクションを取るための意思決定材料にもなっています。

今のフローも手作業な部分もあり、改善の余地があるのですが、社内の利用者の皆さんにより素早く価値が届けられるようなフローに改良していこうと思います。