タスク管理を徹底してリードタイムを改善した話

こんにちは。株式会社ビズパのプロダクト開発チームの白鳥です。
こちらはビズパプロダクトブログの記事になります。下記マガジンから過去の記事を見ることができます。毎月なにかしら記事が追加されていく予定ですので、興味があれば是非フォローしてみてください！

プロダクトブログ｜Bizpa（ビズパ）｜note

さて今回は、運用チームのタスク管理の話となります。運用チームと言っても所謂インフラの運用保守ではなく、データ登録を行うチームとなります。

ビズパでは、サービスの運用にあたって広告主・媒体社それぞれに相対するチームがそれぞれいるのですが、サービスをより成長・拡大させていくため、今年の8月より商品データなどを登録するチームも開発部門の方でマネジメントすることになりました。

以前、こちらの記事でも書いた通り、ビズパの商品データはなかなかに複雑で、商品データの登録作業もコストの高いものとなっています。
開発チームとも連携して登録作業のコスト削減には取り組んでいましたが、組織体制を変更することでより強力にコスト削減を推し進めようという狙いでした。

何をしたのか

運用チームのマネジメントも引き受け、まずは全体のタスクを把握するところから始めましたところ、下記のような状況でした。

• 一部のタスクは Backlog で管理されている

• 全体のタスクは Googleスプレッドシートで管理されているが、Backlog で管理しているタスクとの連携は手動

• タスクの依頼チャネルは、ビズパ社内向けシステムの他、メール と Slack もある

このあたりはスタートアップあるあるというか、ある程度大きな組織でもよくあることだと思いますが、営業だったりカスタマーサポートであれば SFA・CRM 的なツールを入れたりすることである程度のIT化が期待できたりしますが、社内から社内への作業依頼になると依頼をするチャネルが多様になりがちです。

ビズパの商品データ登録の場合には、

• 媒体社から掲載の依頼がくる

• 広告主からの問い合わせを元に媒体社とやりとりをしていたところ、最新の資料を入手する

• 社内にてビズパのサービスを見ていた中で、登録データの不備を見つける

と、いろんなパターンで運用チームへの依頼が飛び交う形となっており、結果として依頼チャネルもバラバラになってしまっていました。

どうしたのか

ビズパではタスク管理ツールに Backlog を使っていますが、運用チームのタスク管理の一部でも Backlog を使っていたため、すべてのタスクを Backlog に集約することにしました。

Slack での依頼について

Slack での依頼については、元々専用のチャンネルで依頼が飛び交っていました。そのため、Slack Apps を使って該当チャンネルに投稿されたら投稿内容を Backlog に課題登録するようにしました。Slack はこういうところが便利で良いですね。

メールでの依頼について

Backlog にはメールで課題登録する仕組みがあり、元から一部のタスクはメールで課題登録していたので、一旦はその運用範囲を拡大することとしました。
ただし、メールでの課題登録はメール本文が Backlog にそのまま登録されるだけのもので、課題の本文としてはあまり望ましいものではありませんでした。

そもそもなぜメールで作業依頼されていたかというと、媒体社と営業とのやりとりがメールでされており、その流れでメールで商品登録の依頼もされていました。

媒体社からの商品データ登録の依頼チャネルがメールしかない、というのが本質的な課題であったため、媒体社向けの管理画面からデータ登録の依頼をできるようにし、依頼がきたタイミングで Backlog API を通じて Backlog に課題登録されるようにしました。

余談ですが、媒体社向け管理画面からデータの登録・修正依頼をできるようにしたところ、既存顧客からの依頼が増加し、意図せずサービスの情報充実にも繋がりました。

その他の依頼について

上記以外にも、社内の他のチームから運用チームへ依頼したいんだけど〜…というタスクがいくつかあり、Backlog に直接書いてもらう方式でもよかったのですが、課題のフォーマットを合わせるためにGoogleフォームを挟む形にしました。

また、依頼がたくさんあって Googleフォームで1件ずつ依頼するのは大変！という場合には、スプレッドシートにまとめて依頼してもらい、Backlog に一括登録する方法を取っています。

タスク管理を一元化して見えてくること

さて、ここまで色々と取り組んでようやくタスク管理の一元化ができました。
現場レベルでもタスクの見通しがよくなって、めでたしめでたし、ではありません。マネージャーとしてはこれでやっとやりたいことができるようになりました。

運用チームをマネジメントしていく上でやりたかったのは、

• タスク消化のボトルネックを把握し、解消したい

• タスクと現場リソースのバランスが取れているか確認したい

の2点になります。

運用チームのタスクが全て Backlog に集約されたので、今度はそれを分析していきます。

タスクの分析

Backlog API を使って Googleスプレッドシートにタスクの登録日・完了日・ステータスを転記し、タスクの種別ごとに

• 新規タスクの数

• 完了タスクの数

• 残タスクの数

• タスク完了までにかかった日数（リードタイム）の平均

を月単位・週単位で集計しました。

新規タスクと完了タスク、残タスクを見ることで現場リソースが足りているかをみることができ、またリードタイムの長いタスクを見ることでボトルネックが見えてきます。

これらを見た結果、データ登録作業そのものよりも、データ登録の前後でヒアリングや確認などコミュニケーションコストが高いことがわかってきました。

ボトルネックの解消へ

ボトルネックが見えてきたので、フローの見直しやシステム化、ドキュメント整備、タスクの分解などを進めることで、ピーク時で1ヶ月以上あったリードタイムを5日以下にまで短縮することができています。
まだまだ改善は途中で、今後さらにリードタイムの短縮を目指していきます。

余談：なぜリードタイムが大事なのか

開発にしろ、運用にしろ、要望が発生してからサービスに反映されるまでの時間をどれだけ短くできるか？という点を大事にしています。
作業者のアウトプットを最大化するという観点で考えると、例えばある程度タスクをまとめて処理をすることで効率が上がるなどがありますが、その結果リードタイムが長くなるのであれば、作業効率よりもリードタイムの短縮を優先する、というスタンスを取っています。

なぜリードタイムが大事なのか、わかりやすくするためものすごく単純化して説明します。
ビズパの場合、商品データを登録すると登録された瞬間から売上に貢献するチャンスが生まれます。

• 1つの商品が1日につき100円の利益をあげることができる

• 商品登録を1件ずつ処理した場合、1日につき10個の商品を登録できる

• 100個の商品をまとめて処理した場合、7日かかる

仮にこのような場合、1つずつ商品を登録していくと最初の1日で10、2日目に20…と商品が登録されていき、それはそれぞれ100円の利益を上げていくので、利益は 1日目が 1000 、2日目が 2000、100商品が登録される10日目には 55000円 の利益を上げている計算になります。
一方、100の商品をまとめて7日かけて登録した場合、7日目までの利益はゼロで、その後3日間で30000円の利益を上げる計算になります。

これはものすごく単純化した例ですが、作業効率を優先するあまり、逆にリードタイムが長くなってしまうというのはよくあることで、そのバランスをコントロールしていくのもマネジメントの役割だと考えています。