Timee Product Team Blog

タイミー開発者ブログ

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

※このブログは Cocoda さんに寄稿したものです。

タイミーでバックエンドエンジニアをしているedyです。 スキマ時間にバイトができるアプリTimeeを運営しています。

timee.co.jp

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

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

お客様のサポートをするCSメンバーは、Notionに起票後、Slackのワークフローを使ってエンジニアメンバーにお知らせ

起票を受けたエンジニアは、「対応可能なチケット数」に応じて、対応するかどうかや、優先度を決定し、解消に向かう

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

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

不定期な割り込みタスクは見落としやすく、振り返りづらい

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

過去のSlackのみの運用(2019年頃) スレッドの件数がかさむことがしばしば発生していました。

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

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

Slack + Notionで、割り込みタスクを管理する

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

CSメンバーはNotionに起票後、Slackで報告

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

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

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

割り込み可能なチケット数は、Notionの計算機能を使って「14 - 現在のチケット数」で算出しています。

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

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

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

Slackワークフローでは、手順書を読んだかどうかとNotionのURL、依頼内容を簡潔に伝えてもらうように。

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

依頼の際は、必ずこれを見てもらい、依頼をしてもらうようにしています。

データ変更依頼、調査依頼、仕様確認の3パターンそれぞれに対応するNotionテンプレートを用意しており、エンジニアが対応する際に必要なプロパティの入力チェックボックスや背景や期限の理由などの記入欄が自動生成されるようになっています。

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

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

エンジニアメンバーは、Daily Standupで優先度をつけ着手

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

割り込みチケットの一覧。各ページ内に、割り込みタスクが入れられています。

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

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

「priority」のプロパティで、1~5の5段階で数字を割り振り、5が最も優先度の高いタスクとして扱えるようにしています。

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

実際のやりとりの例

まとめると、

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

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

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

職種をまたいだ依頼フローをもっと整えたい

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

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

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

頻度や削減できる工数などを総合的に判断し、必要あればエンジニアがリソースを投下して機能追加をしています。 ストック情報を活用して根本的に割り込み依頼を発生させないようなアクションを取るための意思決定材料にもなっています。

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