デザイン会社ビーワークスのプロジェクトにBacklogがなじむまで
Backlogを16年使うとこうなる 血肉となったプロジェクト管理ノウハウがすごい
100件近くのプロジェクトをさばくコツは通知設定と課題の粒度にあり
続いて同社のディレクターたちに、Backlogの利用で注意している点を聞いた。結論から先に言うと、通知のやり方、課題の立て方、課題のフォーマットをプロジェクトごとに定めて、情報をきちんと管理することだという。ディレクターの漆迫雅充氏は、「取り扱うプロジェクトやクライアントの規模感で、どれくらいの情報粒度をタスクとして切るのかが変わってきます。それぞれのプロジェクトに合わせてベストなコミュニケーションルールを設定するのがポイントですね」と語る。
メンションやコメントの付け方など、コメントコミュニケーションのルールは、クライアントとのキックオフで設定し、新たに入ってくるメンバーにも共有する。「すべてのクライアントで同じルールにはならないし、やっていくうちにプロジェクトも変わっていきます。その点、コミュニケーションのやり方をカスタマイズできるのはBacklogの大きなメリットと言えるかもしれません」と漆迫氏。リテラシに合わせてルールや設定を変えられるので、クライアントにも提案しやすいという。
また、数多くのプロジェクトをさばくのは、担当範囲と通知の設定がキモになる。その点、Backlogは、全部の課題の更新、メンションつけた課題の更新だけ、自分が起票した課題の更新だけといった具合で、細かく設定できる。「設定によって、自分がキャッチアップしなければならない課題だけを、うまくキャッチアップすることが可能」と漆迫氏は語る。PMである同氏は全部見ているが、クライアントの場合は自身が起票した課題、確実に返事をもらいたい課題にメンションを付けるように案内するケースもあるという。
Backlogのようなタスク管理ツールを利用するメリットは、ステータスと担当者の管理が確実にできる点だという。ディレクターの徳田氏は、「メールだとccに入れておいても、誰が返事すればいいのかあいまいだし、見ているのか見ていないのかもわからない。返信したらどういうステータスに進むのかもわからない。これがBacklogであれば、きちんと管理できます」と語る。
顧客とのやりとりに加え、社内の承認フローが追加されると、ステータス管理はますます複雑になってしまう。そのため、案件にあわせてテンプレートとルールを用意し、実務担当者とバックオフィスの担当者も交えて、ステータスを管理する。「誰のところでスタックしているのかが共有されるので、通知を見逃しても、周りがフォローできます」(徳田氏)。
Backlogのプロジェクト管理で自社案件を正常化 改めて価値に気づく
長らく同社ではクライアントワークでBacklogを利用していたが、昨年開催されたBacklogのユーザーイベント「JBUG」では自社のコーポレートサイトリニューアルでの利用事例が披露された(関連記事:BacklogコミュニティJBUGで聞いたプロジェクト管理のつらみ、学び、ありがたみ)。普段、クライアントにお願いしたことを自分たちでやったことでさまざまな気づきが得られたという内容は非常に興味深かった。
自社サイトのリニューアルにおいては、ある意味自社がクライアント。サイトリニューアルの予算取り、予算や担当の配分、要求仕様の策定、決裁ワークフローの設定など、今までクライアントにお願いしていた作業を自分たちがやる必要があった。この段階においては、タスク管理よりもアイデア出しや議論が中心となるフェーズだった。
ここで使ったのはTeamsやSlackなどのチャットツール。ディレクターの櫻井美貴氏は「いったん案件化してしまえば、担当や課題を作れるのですが、手前の企画段階で担当割りをしてしまうと、逆に意見が生まれにくくなってしまう。コミュニケーションの方向が明確になっている場合はBacklogが有効なんですが、その前段階はやはりチャットのようなツール。Backlogには議事録や決まったことをWiki化していました」と語る。
企画と承認を終え、決定事項を記載したBacklogをベースにプロジェクトをスタート。「クライアント案件では、クライアントの目的に向けて議論が収束するのですが、自社案件の場合はやりたいことがいろいろ出てしまい発散し、収拾が付かなくなってしまう。進捗を見える化するという意味でもBacklogを活用しました」(櫻井氏)と語る。
Backlogで課題を登録し、進捗を管理し始めたことで、「なんとなく」遅れていたプロジェクトが軌道に乗った。Backlogを使うことで「どこが遅れているか」が見えるようになり、通常のクライアント案件のような管理に戻すことができたという。「普段われわれがやっているBacklogを使ったプロジェクト管理自体が、ビーワークスが提供できる価値の1つであることに気がついたんです」(櫻井氏)。
結局、ビーワークスはなぜ16年間もBacklogを使い続けたのか?
とはいえ、ツールの使い分けは試行錯誤を続けている。ビーワークスでは慣習的に「決め事はBacklogに残す。Slackはインスタントなコミュニケーション」という指向性だったが、最近はプロジェクトごとにツールも変わっている。「たとえば、FigmaやSlackのやりとりしていたことが、いつの間にか決定事項になることもあります。案件の性質とメンバーのやり方で切り分けは柔軟に調整しています」(徳田氏)。案件や組織によってメインに使うツールが違うというのは、SaaSが増えた昨今では増えた多くの会社で見られる。一方で、「チケット化されているタスク」「終了のあるプロジェクト」「証跡を残す必要がある案件」などは、一覧性の優れたBacklogの方が向いていると感じている。
さまざまなツールがある中、なぜビーワークスは16年もBacklogを使っているのか? 三浦氏は、「ゆらぎを是とするツールだからではないか」と指摘する。最近のSaaSや外資系のソフトは、提供側の想定した使い方やルールにユーザーが合わせることで適切な効果を発揮できるツール。Backlogは、ユーザーの使い方や成長具合にあわせて、さまざまな運用が可能。ユーザー数ではなく、スペースに対する課金なので、ユーザーの増減にも柔軟に対応できる。ここがメリットだ。
三浦氏は、「かっちり決まったルールの中でプロジェクトを動かすのであれば、それはわれわれのやり方に合っていないし、事業もここまで多角化できていないと思います。その意味では、事業の多角化に付き合ってくれたツールと言えるかもしれません」と語る。多彩なクライアント案件と事業の成長に合わせて、柔軟に使える。これがビーワークスにとってのBacklogの価値だったわけだ。