Backlogは未来を楽にする 最初は手間だけど、1年後は使った自分を褒めたくなる
2024年12月14日、BacklogのユーザーグループであるJBUG（Japan Backlog User Group）は「Backlog World 2024 in YOKOHAMA」を開催した。Webプロジェクト、イベント運営、新規事業、オンボーディング、ミーティング、ワークスペース統合など多種多様なBacklog活用事例が披露された。 【もっと写真を見る】
2024年12月14日、BacklogのユーザーグループであるJBUG（Japan Backlog User Group）は「Backlog World 2024 in YOKOHAMA」をパシフィコ横浜ノースで開催した。プロジェクトマネジメントに関わるすべての人の祭典を謳うとおり、開発やWebプロジェクトのみならず、イベント運営、新規事業、オンボーディング、ミーティング、ワークスペース統合など多種多様なBacklog活用事例が披露された。 「覚えないため」、いっそ「忘れるため」に使うのがBacklog Backlog Worldは、ヌーラボのプロジェクト管理サービス「Backlog」のユーザーグループであるJBUGが開催する「プロジェクトマネジメントに関するすべての人の祭典」で、年に一度開催されている。昨年は福岡でオフライン開催のリブートを果たし、通算5回目となる今年は「Grow Together」をテーマにかかげた。 会場は横浜のパシフィコ横浜ノース。普段ユーザーグループのイベントではお目にかからないような広くて美しい国際会議場で、10時からイベントはスタート。冒頭、実行委員長であるFusic 清家史郎さんがGrow Togetherというテーマに込めた想いや、JBUG、イベント自体の説明が行なわれた。 開会式の後、「チームを楽に、プロジェクトを早く進めるためのBacklog」というタイトルで登壇したのはサービシンク 代表取締役 名村晋治さん。サービシンクはWeb制作やシステム開発を手がける新宿のIT企業で、2006年からBacklogを利用している。名村さんは、4年前からWebクリエイターの質問に応えるPodcastを配信しており、昨日はヌーラボの橋本代表も参加したという。 まずは前提の話として、「私の話は正論だと思いますが、正解ではない」と名村さん。Backlogは「未来を楽にするツール」。だから、「未来は苦労してもいいと思っている人」や「今の苦労は我慢できないという人」にはBacklogは向かない。ただ、「1年後には続けてきた自分を褒めたくなるはず」と名村氏は語る。 そして本題は「Backlog、そもそも使いたくない人いるんじゃないの？」というユーザー会に似つかわしくない問いからスタートする。そんな名村さんも、2006年に使い始めた当時は、実は使いたくないと思う立場だった。「なんでこんなことやらなければならないの、面倒くさい」「Excelでなんとかなるでしょう」「『マネジメントで必要だからやりなさい』って、知るか！」「起票する間に作業終わる」と思っていたという。 しかし、それから紆余曲折あり、5年経った2011年頃、あれだけいやがっていたBacklogの利用に腹落ちした経験があった。「書いておくって、そういうことか」「これ使わないとやばい」「これを使っていてマジよかった」となり、これ以降Backlogに起票しないという選択肢はなくなった。今では名村さんも「うちの会社でも人一倍Backlogに書けと言います（笑）」という存在になった。 そんな「未来を楽にするツール」であるBacklogだが、情報共有の手間を減らすことで、「今」も楽にしてくれる。Backlogのようなチケット管理システムをなぜ使うのか？ 名村さんは、「覚えないため、もっと言うと忘れるため」だと語る。「記憶に頼っている限りは、忘れることがある。当然抜け漏れもある。だから、いっそ忘れるために、Backlogに書いた方がいいと言っている」（名村さん）。 タスク管理ツールの謳い文句が現場ユーザーに響かない理由 ほとんどのタスク管理ツールでは謳い文句が決まっている。「タスクの担当者・期日が明確になり、確認漏れや遅延を防ぐ」「複雑なプロジェクトや日常教務に最適」「プロジェクト全体、それぞれのタスク状況をチームで共有し、プロジェクトの進行を支援」などだ。「プロジェクトマネージャーであればこれで納得するが、ほとんどの人には響かない。だから、使うの面倒くさいにつながってしまう」と名村氏は語る。 現場のユーザーが求めているのはメールでも、チャットでもいいから、明確な指示だという。デザイナーはデザインが仕事だし、プログラマーはコードを書きたいはず。指示書やドキュメント作成は本来の仕事ではないし、「エディタで2文字直して、FTPでアップするための作業にわざわざチケットいる？」「使うだけ手間も面倒も増える」という声もわかる。つまり、プロジェクト管理は人によって重さが違うのだ。 そもそもチケット管理ステムを初めてプロジェクトで導入すると、使い始めはまったく楽にならない。1ヶ月経っても、記入する意味を見いだせない。しかし、1年経つと便利さを実感できるという。これは「書きためた情報がナレッジになってくるから」にほかならないという。 時間が経つとなにが変わるのか？ たとえば過去の経緯、同じ作業・似た作業のやり方もわかる。「うちの会社の場合、エンジニアはSQLの内容と結果まで貼り付けています。1年前にやっていた調査もわかるし、新人はSQLを貼り付ければいい」と名村さん。細かく起票することで、引き継ぎも少なくなる。なにより、Backlogに起票しておけば、Backlogだけ探せばよくなる。「調査や繰り返し作業が出てきたとき効果は絶大」と名村さんは指摘する。 ただし、この状況を実現するには、Backlogにすべての情報が集約されなければいけない。メールの連絡や資料、電話での連絡、個別チャットでの連絡、定例での口頭での話など、基本はBacklogにコピペしたり、起票する必要がある。かなりハードだが、ここまでやらないとチケット管理システムを導入する意味は見いだせないという。「すべては記憶に頼らず、覚えないため」（名村さん）だ。 Backlogに業務の履歴が残るようにするためには、チャットでコメントのやりとりは絶対しないという意識が必要になるという。「探している時間は仕事の時間じゃないからねと言います。Backlogにまとめて書いておけばいいのに、メールやチャットを探すなんて時間がもったいない」と名村さん。 そのため、サービシンクでのチャットのやりとりは、対応と依頼にBacklogのリンクを張るだけの簡素なやりとりになる。「これだけ見ると仲悪いみたいに見えてしまう。『メール送りましたー』という電話しているみたいで、ちょっとモヤモヤする（笑）」と名村さんは語る。 今の1分が未来の1時間を救うかもしれない 名村さんにとってプロジェクト管理ツールは、「過去を未来に渡すツール」だという。「今の最適解だけ必要なら口頭でのやりとりでいいかもしれない。でも、プロジェクトは半年、1年続いていく、うちの会社の場合は10年続いているプロジェクトもあります。こうなると、一大ナレッジになります」と名村さん。 Backlogでナレッジを溜めるためには、情報はどのように登録すべきか？ 名村氏は、まず最低限「状態」「担当者」「マイルストーン」「開始日・終了日」は必須項目として登録すべきだという。これらは全員ができるまで、何回でも注意を行なって、徹底させる。その上で、業務のパス回しの際に担当者と状態を変更し、最後にチケットを終了させるというフェーズまで持ち込む。 また、あとで「読み返す」ことを考慮しなければならない。そのため、英語表記とカタカナ表記のような揺れ、特定の人しかわからない「オレオレ単語」、一見してわからないタイトルなどを排除する入力が必要になるという。 続いてBacklogのWikiだが、名村氏は「そもそも複数人で構造まで手を出してはいけないツールなので難しいと思っている」と指摘する。そこで同社ではプロジェクトごとにフォーマットを用意し、コピペして利用している。中身がないところはグレーで、中身があるところには色が付くので、色を埋めていくように入力を進めている。「だからどのプロジェクトを見ても構造が同じ」（名村さん）だという。 最後に「ここにいる人は大丈夫だと思いますが、Backlogを使うのをいやがらないでいただきたい」と訴える名村さん。「確かに手間がかかる部分があるが、今だけを管理するツールと考えないでほしい。今の1分が未来の1時間を救うことになるかもしれません」と語る。もちろん、手間は少しの工夫で乗り切ることもできるし、なによりこのツールは自分と仲間のために存在している。「今使わなければならない理由、未来の自分と仲間を救うための理由を考えてほしい」と語り、自社で利用しているWikiのテンプレートを案内して、登壇を終えた。 Web制作プロジェクトをととのえよう プロクモの事例 続いて登壇したのはプロクモ 執行役員 クリエイティブチーム 統括マネージャーの丸野美咲さん。プロクモはマーケティングコンサルティングを本業とし、2021年に入社した丸野さんはPM・Webディレクターを経て、現在はWebサイト制作チームを統括する立場だ。「Webサイト制作に関わっていない方も多いと思いますが、なんらか業務フローを作る際の参考になれば」とセッションをスタートさせた。 今から約4年前、Webサイト制作のフローが整備される前、「いつ・誰がやるの？の大量発生」という問題が起こっていた。新規案件が来ても、ヒアリングした代表がその場でメンバーアサインする場合もあるし、見積もり作成と契約回りからスタートする場合もある。また、Webサイトの提案で必要なワイヤフレームの制作においても、「パワーポイント派」と「Adobe XD派」の派閥に別れており、使うツールが違っていたという。 さらに、新入社員に対する業務レクチャーに時間をとられていたのも大きな課題だった。「1on1やレビューなどの時間を抜いて、業務を教えている時間だけで月に20時間を費やしていた」（丸尾氏）とのことで、1日約1時間はレクチャーに充てられていた。 これはさすがにまずいということで、Webサイト制作のフロー整備がスタート。各チームの代表3名で「制作フロー標準化プロジェクトが立ち上げられ、Backlogでガントチャートが作成された。その上で、メンバーのアサイン、目的・ゴールの認識合わせ、完了期日の決定、進行スケジュールの決定が行なわれた。 続いて、各Web制作プロジェクトで行なわれているタスクをメンバーと洗い出し、必須のタスク、オプション化できるタスク、マージできるタスクなどを検討。洗い出しができたら、これらのタスクをスプレッドシートに登録して一覧表示できるように。上から順番にタスクをこなせば、プロジェクトが完了するという流れに登録したという。 タスクを洗い出し、ひたすら協議 利用のPDCAも丁寧に ここまで来たら、「あとはひたすら協議」（丸野さん）というフェーズ。「なにがどこまでできていればタスクが完了するのか」を数ヶ月に渡ってメンバーと協議し、営業、エンジニア、ディレクターなどそれぞれの目線でタスクの分岐点やヒアリング項目を決めていった。 最後はアウトプットになる。まずは全タスク一覧のスプレッドシート。フェーズ、大タスク、小タスクのほか、推進する職能、実際に切ったBacklogのチケットなどの項目も記載されており、これを上からこなしていくとプロジェクトが完了するようになるという。また、今まで各自で作成していたヒアリングシート、要件定義書、調査書などテンプレート、タスクの進め方を記したBacklogのWikiも用意された。 ここまで来れば、あとは社員への周知とフローのブラッシュというPDCAのフェーズになるのだが、「実はここが一番難しい」（丸野さん）という。 まずはフローを整備した目的や運用方法を説明する研修を実施し、メンバーの理解を深めてもらうことにした。とはいえ、1回の研修で理解されるものでもないので、つどつど勉強会を開催し、徐々に理解してもらえるようにしたという。 続いては実際の案件でやってみる。Wikiを見ながらフローに添って進め、フロー通りにできなかったタスクは都度振り返る。チームでは週次定例会を行なって、フローについての課題をいったん「発散」させ、課題を解決するためのフローは都度検討して、見直していく。メンバーに改善を任せることもあるという。 取り組みの成果、制作フローが確立され、月に20時間かかっていた先輩社員の教育工数が約13時間を削減された。業務フローに関してもWikiを見るという文化が拡がったという。 朝から始まったイベントは、さまざまな事例セッションのほか、ワークショップ、スポンサー展示、2024年のもっとも素晴らしいプロジェクトを表彰する「Good Project Award」や、JBUGへの貢献者表彰など行なわれた。いろいろなユーザーのプロジェクト管理の知見が凝縮されたセッションが多く、イベント名の通りプロジェクトマネジメントに関わるユーザーであれば、なにかしら学びが得られる内容だったと思う。いくつかのセッションは別途でレポートしていく。 文● 大谷イビサ 編集●ASCII
