組織やチーム内のバックログ(残務・未処理の作業や案件)をつねにキレイして、チームの仕事を前に進める役割がヌーラボが考えるバックログスイーパーになる。では、 タスク管理ツール「Backlog」の開発元であるヌーラボのバックログスイーパーはどのように日々のスイーパー業務を行なっているのだろうか? ヌーラボの原彩香氏に話を聞いてみた。(以下、敬称略 インタビュアー ASCII編集部 大谷イビサ)
Backlogの開発スタンスに惚れて、ヌーラボに入社 カスタマーサクセスな日々
大谷:まずは原さんのビジネスプロフィールを教えてください。
原:ヌーラボに入社したのは5年前ですが、その前にはユーザーとしてBacklogやCacooを使っており、B2Bサービスでありつつも所々遊び心がちりばめられているサービスで面白いなあと思って注目していました。開発背景を語ったブログも読んでいましたが、当時は「管理者がメンバーを管理しやすくするのための業務ツール」が多い中、「利用者みんなが使いやすい業務ツール作り」を徹底していた点や「どんな多機能なツールでも、楽しくなければ使われないだろう」という思想をB2Bに持ち込もうというところにチャレンジを感じていたので、中の人として働いてみたいなと。
大谷:やはりBacklogを使っていたのですね。
原:はい、1社目はERPパッケージのベンダーで、Cacooで製品マニュアルを作っていました。当時はCacooのようなビジネス系のビジュアルツールがほとんどなくて、とても重宝していました。
2社目も会計システムのベンダーだったのですが、そちらではBacklogが導入されていてサポートのチケットをBacklogで起票して、開発チームとやりとりしていました。その会社ではSalesforceの構築にもBacklogを使っており、私はビジネス部門の立場からSalesforceの管理者に項目追加などの要望をBacklogで上げていました。
大谷:ヌーラボでの今の役割を教えてください。
原:現在はカスタマーサクセス部に所属しており、お客様の活用支援を目的としたオンライセミナーやクロスセルのご提案などを担当しています。最近は、お客さまの操作ログの統計情報を分析して、お客さまが詰まってしまうところを定量的に割り出し、コンテンツの提案などデジタルタッチで解決するフローの構築に注力しています。
使用上の不明点や機能的なご要望など、お問い合わせいただければお答えできるのですが、問い合わせしてくださるお客さまはごく一部です。大多数のお客さまは、活用方法に課題感を感じたとしてもなにも言わずに悩まれたり、諦めたりしてしまいます。そういった声を上げないサイレントユーザーを救いたいというのが、カスタマーサクセス担当の私のモチベーションです。
「知っている」のと「できる」は全然違う
大谷:次にバックログスイーパーになった経緯を教えてください。
原:ヌーラボは「チームワークマネジメント」を提唱していますが、社内でチームワークマネジメントの実践について突き詰めて考えたとき、やはりバックログスイーパーの存在が重要だよねと再認識したという背景があります。その後、課内で正式にバックログスイーパーを任命しようという話になり、やりますと手を挙げた次第です。
大谷:なぜやろうと思ったのですか?
原:バックログスイーパーの存在が必要なことは共感しましたし、何をすべきか、ということも経験から理解しているつもりです。しかし「知っている」と「できる」は違いますよね。改めて考えてみると、できていない部分や工夫すべき余地はまだあると感じたこともあり、「知っている」と「できる」の差を埋めるためにも、やってみようと考えましたた。
大谷:ヌーラボさんではあえてバックログスイーパーを作ることにしたんですね。
原:本来、バックログスイーパーが自然発生的に生まれるのが理想です。ただ、バックログスイーパーのやるべきことの一部分を切り取ると、ネガティブな側面もあります。タスクが遅延している人がいた場合、その人を急かすことも必要です。時には自分を棚に上げて苦言を呈する必要もあり、私も正直気が重く感じることもありました。だから自然発生的に生まれるのがなかなか難しいのも事実です。
そこでわれわれはあえてバックログスイーパーを「役割」にしました。「役割だからやる」「あの人はチームのタスクを前に進めるのが仕事」という環境を構築するんです。役割を与えるというのは、一つの方法論だと思います。
開発元であるわれわれにもバックログスイーパーは必要だった
大谷:もう1つ、ヌーラボさんってBacklogの開発元なんだから、スムーズにタスク管理をしているはず。だから、バックログスイーパーなんているの?というツッコミに関してはいかがですか?
原:バックログスイーパーには、「起票を促す」という役割だけでなく、「タスクを完了まで持っていく」という役割もあります。われわれBacklogの開発元なので、起票に関しては確かにハードルが低い。起票でつまずくことはありません。
逆に言うと起票ハードルが低い結果、課題の数が膨大になり、放置されてしまうものも出てきてしまう。だから、タスクを進めるという役割が必要。バックログスイーパーはわれわれにこそ必要だったのだと思います。
大谷:確かにタスクの量が膨大だと、そうなりそうですね。
原:すごいですよ。私も締め切り過ぎて“燃えている”課題が10~20のレベルじゃ済まないないときもあったので。ダッシュボード見切れない...みたいな(笑)。
大谷:LINEの未読数すごいみたいな(笑)。これはほかの人も同じなんですか?
原:全員常に、という訳ではないですが、立ち上げ当初のビジネス側のメンバーは身に覚えがある人も多かったと思います。開発元なのにお恥ずかしいです(笑)。
大谷:ヌーラボさんでは少ないとのことですが、起票のハードルを感じている会社もいると思うのですが。
原:はい。ハードル自体は起票の面倒くささと技術的な操作面、大きく2つのハードルがあります。これはオンボーディングで解消すべきなのですが、前者の面倒くささに関しては、まずはデータが資産であるという点に納得感を持ってもらう必要があります。ですから、地道な啓蒙活動が必要で、道のりは長いです。
後者の技術的なハードルに関しては、「導入支援プログラム」で解決できます。導入ステップが事前に課題として登録されているサンプルプロジェクトをご提供しており、実際に使いながら学べるので、さくっとハードルを越えてもらえているようです。これら2つのハードルを超えると、見える景色が変わる。「Backlogを使わずに業務を進めるなんて考えられない」と思えるようになります。この景色をお客さまに見せたいと日々考えています。
バックログスイーパーにお勧めの「Backlog技」はフィルターの活用
大谷:では、バックログスイーパーとして今やっていることを教えてください。
原:私はCS(カスタマーサクセス)課という5人のグループのバックログスイーパーをやっています。5人のメンバーのフィルターを作り、残っている課題を抽出し、ミーティングなどでチェックしています。
あとは保留状態としていったん置いておく課題と、期日厳守の業務で未着手の課題を分類するようにしています。課題を起票するのはいいのですが、緊急度が低くて、重要度が高い課題ってけっこう塩漬けにしちゃうんですよね。早くやらなければならないものを優先してしまう。
大谷:私もそうですね。緊急度の高いものをやっていったら、重要度が高いタスクは後周しになります。なので、数ヶ月残置しているタスクが出てきてしまいます。
具体的にフィルターはどのようにかけているのでしょうか?
原:大きく2つの考え方があって、1つ目は単一のプロジェクトにフォーカスを当てる場合。このときはカテゴリごとのフィルターを作って、チェックします。たとえば、私は顧客の操作からデータ分析するというタスクがあるので、CS課のプロジェクトの中でデータ分析のカテゴリでフィルターをかけて、進捗をチェックしたり、今後の予定を話します。
もう1つは複数のプロジェクトに関わっている場合です。たとえば、われわれは社内の全部署でBacklogを使っているので、自分が関与しているプロジェクトは複数あります。どの社員もだいたい30~40くらいのプロジェクトに関わっていると思います。
大谷:そんなにあるんですね。
原:はい。たとえば、新しいソフトウェアの導入プロジェクトがある場合、セキュリティチェックはIT部門、利用規約のチェックは法務部にお願いします。そのため、CS課から依頼する課題は、IT部門と法務部のプロジェクトにばらける形になり、それぞれのプロジェクトで進捗をチェックしなければなりません。
セールスチームの商談は、お客さまとごとにBacklogの課題として起票されるのですが、ポストセールスであるCS課でも日々チェックしなければなりません。ほかのチームがメインで利用するBacklogプロジェクトに起票された課題もたくさん存在しますので、プロジェクトを横断した進捗管理が必須です。こういうときにプロジェクト横断のフィルターを使うと、漏れがなくなります。
いったんフィルターを作成すれば、通知は自動化もできる
大谷:プロジェクト横断で進捗管理をする場合は、どのようにフィルター設定をするのがよいでしょうか?
原:緊急度でフィルターをかけることもありますが、自分も含めチームメンバーが担当になっている課題だけでなく、「起票した課題」を見ていくことも、プロジェクト横断の進捗管理には重要だと思います。
具体的には画面上部の「…」マークをクリックすると表示される「課題の検索」からプロジェクトをまたいでフィルター設定ができますので、私はチームのメンバー一人ひとりのフィルターを作成しています。フィルターは1回作っておけば、検索条件を保存できますので、作業自体は楽です。
大谷:チェックのタイミングはどれくらいの頻度なんでしょうか?
原:チームがやっているメインプロジェクトに関しては、残課題を毎朝Slackのボットで通知するようにしています。Slackのワークフロー機能を使って、先ほど作成したURLを載せるボットを作成し、普段見るところに通知が流れるようスケジューリングするのがオススメです。通知のために自分ががんばらなくてよいので。
他部署に関わる課題は毎日見るものでもないので、週次のミーティングや、月末月初の棚卸しでチェックしようと思っています。試行錯誤しながら、ちょうどいいタイミングを探っています。
大谷:画面を見せてもらってよいですか?
原:はい。メンバーごとの課題がわかるフィルター、マイルストーンごとのフィルター、定例ごとのフィルターなどを作っています。メンバーの関わっているプロジェクトは、いったん全部入れています。
大谷:なるほど。ほかの会社のBacklogを見るのって楽しいですよね。
原:私はすでに利用しているお客さまのBacklogの画面を見ることが多いのですが、きれいに管理されているお客さまもたくさんいらっしゃって、素晴らしいです。学びしかないです。
人の進捗をせっつくネガティブさを解消するには?
大谷:バックログスイーパーになってよかった点、成長したなという点はありますか?
原:まず、バックログスイーパーとして会社から任命されているので、言いやすさは格段に上がりました。メンバーからも「役割なんだから、チームのタスクを前に進めるのが仕事だよね」と受け入れてもらっています。会社としては、このスイーパー業務を評価に入れているかどうかも重要な観点だと思います。
あと、「人に言うからには、自分が燃えてたら恥ずかしい」という意識があります(笑)。でも、これは私にとっては大きなメリットで、タスクへの向き合い方が変わります。通知する前に、まずは自分を見るので、自分自身のタスクが管理が改善します。
正直、タスク管理が苦手だと思う人ほど、このバックログスイーパーはやってみるとよいと思います。その人自身にまず効果があります。
大谷:まずは自分が成長できるわけですね。
原:とはいえ、人の進捗遅れを指摘する時にはネガティブな気持ちになることもあります。自分の進捗なんて自分が一番わかっている。わかっているけど、進まない。「展示会やイベント登壇があって、外出が続き時間が取れなかった」とか、メンバーの事情もわかっています。そんな人に「このタスク、期限が迫っていますが大丈夫ですか?」なんて言うのは心苦しいんです。
ただ、自分がネガティブな要素を言わなければならないストレスを少しでも減らすために、最近は基本的には褒め称えるスタンスで文章を作っています。「今週こんなにタスクあったのに、1つしか燃えてません!」とか。多少をテイストを変えるだけで、言う側もちょっと楽になります。投稿ボタンの押しやすさが全然違います。
お尻たたきは極力ツールに任せつつ、苦言を呈する必要があるときは、事情は理解しているメンバーとしては「褒めるスタンス」でやるとよいかなと思っています。
理想はバックログスイーパーなしでもプロジェクトが回ること
大谷:今回は原さんのやり方を聞きましたが、いろいろなやり方ありそうですね。
原:バックログスイーパーに必要なスキルセットについては、チームの構成、会社の向かう方向性で変わってくると思います。たとえば、私は褒めるスタンスですが、チームメンバーや会社の状況によっては厳しめなピリッとスタンスが効果を発揮することもあるかと思います。
バックログスイーパー自身の性格によってもやり方は百者百様です。今度、バックログスイーパー同士で知見をシェアするイベントが社内であるので、楽しみにしています。
大谷:メンバーに変化はありましたか?
原:メンバーには「きちんと課題をこなさないと、チームに面倒をかけてしまう」という気持ちも生まれています。自分のためのタスク管理はもちろんですが、誰かに迷惑をかけないためにタスクをきれいにしようという考え方にもつながるんです。
大谷:これはツールでは難しい。人ならではのマインドの変化ですね。
原:タスクの遅れについて、「ツールが急かすべき?人が急かすべき?」個人的にはどっちも間違ってないと思っています。ただ、理想はツールや仕組み、そして文化で解決できること、つまりスイーパーを置かなくてもタスクが回る状態になることです。
弊社のバックログスイーパーは持ち回りになる予定です。チーム内でのバックログスイーパー担当が一巡したら、みんながスイーパー側の気持ちを理解し、チームの文化として健全なタスク管理が根付くはず。そうなれば、「今期はバックログスイーパー係はなしで行きましょう」という判断ができるようになるかもしれません。
大谷:確かにそうなるのが理想ですよね。
原:ただ、市場環境や会社の方針の変化やメンバーの入れ替えなどで、業務は刻々と変わります。いったんできたベストプラクティスが未来永劫続くかというと、そんなことはありません。そこは業務フローの改善やBacklogの設定変更などを試し続けなければならない。だから、「こういう条件で抽出したら、もっと効率的」とか、「この通知だとうるさすぎるかも」とか、そういう試行錯誤も、メンバー全員でできるといいなと思います。
この連載の記事
-
第7回
sponsored
桐井製作所にとってのBacklogは「発注のプロ」になるための成長ツール -
第6回
sponsored
リーダーも現場も楽になる チームワークマネジメントを成功させる5つのポイント -
第5回
sponsored
課題だらけの日本企業がチームワークマネジメントに進む理由とは? -
第4回
sponsored
多少大げさだが、Backlogを導入すれば日本企業の悩みはだいたい解決する -
第3回
sponsored
バックログスイーパーの恩田さんに、タスク管理成功の秘訣を聞いた -
第2回
sponsored
デジタルキューブ恩田さん、いかにバックログスイーパーとなりしか -
第1回
sponsored
コミュニティイベントの回し方、CMC_Centralの舞台裏を運営チームに聞いてみた
この記事の編集者は以下の記事もオススメしています
-
ビジネス
Backlogコミュニティ・JBUGは悩んでいるユーザーに優しかった -
sponsored
デジタルキューブ恩田さん、いかにバックログスイーパーとなりしか -
sponsored
バックログスイーパーの恩田さんに、タスク管理成功の秘訣を聞いた