ユーザーが自ら運営するコミュニティイベントでも、ここまでできる。昨年、パシフィコ横浜で開催されたBacklogのユーザーコミュニティイベント「Backlog World 2024」の運営メンバー3人に、Backlogをフル活用したイベントの運営経験を語ってもらった。前半に引き続き、後半はコミュニティならではの留意点や「使い切った」と評価するBacklog運用のノウハウ、そしてチームワークマネジメントとの関連について聞いた。（以下、敬称略 インタビュアー ASCII大谷イビサ）
Backlog World 2025の会場となったパシフィコ横浜
コミュニティでの情報の粒度は会社で使うより細かくなる
大谷：今回のBacklog Worldはコミュニティイベントということで、運営においては組織を越えたやりとりが必要になったと思うのですが、なにか違和感とか、所属組織の違いはありましたか？
清家：今回の運営メンバーは「Backlogを使うのが上手」という共通点はあったのですが、「使い方はけっこう違った」というのは気づきでしたね。
最初に感じたのは、課題の進め方や報告の仕方が違うこと。途中から進捗が見えないことがあったので、早い段階で導入したのが、都度の1on1ミーティングです。課題をベースに「この時期までにここまでやりたいです。ただ、現状ではこれがまだ進んでないです」みたいな話し合いを持ち、課題を進めるにはどうしたらよいかをチーム単位で聞いていました。
大谷：課題の進め方をサポートしていたわけですね。
清家：特に報告の仕方は、会社ごとにけっこう違かったのですが、それを揃えに行きました。だから、後半になればなるほど、報告のタイミングはある程度揃ってきたと思います。
一方でBacklogの使い方で、僕たちにはもっていない上手さを持っている方もいたので、それはそのままやってもらいました。峠さんなんかはそのタイプです。最後の方は、峠さんにワークショップを担当してもらっていたのですが、試行錯誤の過程も含めて情報のまとめ方が素晴らしくて、僕は完全に任せることができました。
Backlog World 2024 実行委員長を務めたFusicの清家史郎氏
大谷：いわゆる企業とコミュニティでの使い方の違いってなにかあるのでしょうか？
清家：僕は、コミュニティの方が「情報の粒度が細かくなる」と思っています。理由としては、やはりボランティアだから。本業の方が当然関わっている時間も長いし、時間の使い方も濃い。社内でコミュニケーションをとった上で課題化しているので、ある意味雑なところもあります。
その点、コミュニティは本業以外の時間の活動ですし、半年間プロジェクトをやっているからといって、内容が全部頭に入っているわけではない。だから、Backlogを見れば、プロジェクトがすぐに把握できる状態になるのが望ましいと思います。粒度は細かい方がよいし、会話のログも残っている方がよい。全部できていたとは思わないけど、会社よりも細かくコミュニケーションするようには心がけていました。
井上：プロジェクトの進め方での反省点は「時間帯」です。コミュニティメンバーで運営するBacklog Worldは当然、業務時間外の活動になるので、ミーティングも遅くなりがちで、デザイナーさんにご負担をかけてしまいました。いっしょにノベルティをやっていた担当が「この時間帯のミーティングは非常識ですよ」と言ってくれたので、すごく反省しました。
「Backlogを使い切ると、ここまで到達できるんだ」という気づき
大谷：実際にBacklogのイベントをBacklogで回してみてどんな感想でした？
井上：普段、僕も業務でBacklogを使っているのですが、どっちが使いこなせているかというと、絶対的にBacklog Worldの運営チームの方なんです。Backlogのヘビーユーザーが集まっているので、「そりゃそうだよね」という話ではあるんですけど、今回の運営チームの使い方はある意味「理想型」だなと思いました。上手な使い方を間近で見られるのは、本当に勉強になります。
峠：僕も同じことを感じていて、Backlogを「使い切る」とここまで行き着くんだという驚きがありました。
自社はエネルギー会社なので、フルリモートという就業形態自体がない。その点、Backlog Worldの運営はほぼフルリモートでプロジェクトです。フルリモートでのプロジェクトで運営メンバーになると、フルリモートだとどんな情報が必要で、Backlogでどこまで補えるのかがわかります。
Backlog World 2024の運営を担当した北海道ガスの峠幸寛氏
大谷：具体例を教えてください。
峠：たとえば、1つの課題に対して、なぜその課題を解決しなければならないのかといった理由や、背景情報のドキュメントが付けられていると、人は動きやすい。「あの資料どこだっけ？」から始めるのではなく、それぞれのタスクになにをすべきかが登録されているので、すぐに作業レディの状態になれる。これがフルリモートで働ける条件なんだと悟った瞬間、楽しくもあり、反省も生まれ、伸びしろも感じられました。
フルリモートでない会社の人間が、フルリモートで成果を出し続ける組織の仕事のやり方を体験できる。このような夢のような体験をさせてもらって、会社に持ち帰ると、会社での使い方がブーストされるんです。「まだまだ伸びしろあったんだ」「使い切れるんだ」と体感できるこの心地よさは、運営をやらなければ気づきませんでした。
大谷：「組織を越えたプロジェクトだから大変」だと思っていましたが、現実には共通の関心軸があれば、かえって組織外とのやり取りの方が楽だし、学びもあるという話かもしれませんね。
井上：今回は運営のメンバーはみなさんBacklogの使い方もうまいし、優秀なので、「普通はこんなに理想的なBacklogの使い方できへんで」と思います。たとえば課題を自発的にいい感じに作ってくれるとか詳細の書きっぷりを工夫してくれる、みたいなことは普段の業務ではなかなかありません。このあたりは自社でもできるようにしていきたいと思っています。
峠：ふつうの会社のように、会議後に議事録を見てマネージャーが担当とタスクを割り振るのではなく、会議中に各自がどんどん課題を切って、終了後には「誰が」「なにを」「いつまでにやる」というのが決まっているスピード感は良かったですね。なにを話すかのアジェンダはいるのですが、ログとしての議事録はもはや不要になる。これってすごいなあと。
Backlog World 2024の運営を担当したドリーム・アーツの井上拓也氏
ふらっと相談するように課題を立てることの意味
大谷：ほかのメンバーの使い方を見ての気づきや学びってありましたか？
峠：課題の作り方やルールも、通常はWikiに記載しており、わざわざルールを覚える必要があった。でも、清家さんがやっていたみたいに、テンプレートにルールを書いてしまえば、課題を切る度にその場でルールをすぐに参照できるから、ユーザーも迷わずに登録できるし、粒度も均一化してくる。この上手さ、この気づきですよね
確かにちょっとの工夫なんですよ。でも、これで浸透の速度が変わってきます。だから、違う組織でのBacklogの使い方を見られたのが、個人的には楽しかったところです。
大谷：なかなか機能の星取り表では見えないところですよね。
峠：あと、遊び心のあるBacklogの機能をあまり社内で使ってなかったなあという感想はあります。たとえば、恩田さんは、行き詰まっているところをコメントでフォローしつつ、進捗しているところにはスターを付けてくれます。スターのうれしさ、言葉ではないコミュニケーションの大切さを実感したので、これは社内に持ち帰りたいと思いました。
大谷：ほかの方でも、「この使い方すごいな」という工夫ありました？
井上：1つ思い出したんですけど、最初に振られた課題の中に「オープニングムービーを作る」というのがあったんです。僕は全然聞いてなかったので、恩田さんに「これやるんですか？」と聞いたら、「やってくれたらうれしいな（ハート）」みたいな答えが返ってきて、リクエストが課題の形で飛んでくるのが面白いなと思いました。
清家：同じような話ですが、僕に実行委員長を振ってくれたJBUG福岡の勝毛さんって、めちゃくちゃライトに課題を立てるんですよ。ホントに、ただの相談を課題として立ててきます（笑）。
でも、相談の段階で課題になっていると、立てた人が悩んでいること、考えていること、個人の観点などがわかるんですよね。あれはよかったです。これは真似しなきゃいけないと強烈に思いました。
大谷：課題としてFIXしたものではなく、相談から登録されて、その後「課題成り」するんですね。
清家：普段、課題を立てるときって、自分の中である程度ブレストして、「これって必要だよね」くらい練った事項を課題として起票します。その点、勝毛さんの場合は、「これってどうしようかな？」くらいの相談から課題化されてくるんです。でも、その相談をメンバーがそれを見た段階で、これって課題化すべきだよねというコンセンサスを経て、本当の課題になります。今回はこの過程を何回か体験しました。
