笑顔を創りたいWebディレクターの日常

某事業会社勤務のWebディレクター。つまり「なかのひと」やってます。Web業界からひょんなことで専門学校の先生に。そしてまたWeb現場に戻ったWebディレクターのブログ。

Backlogのコツは”制限”だと思う。

【スポンサーリンク】

こんばんちは、スーパー太っちょWebディレクターです。
スーパーは太っちょにかかります。

さてさて、この記事は Backlogアドベントカレンダー2024 by #JBUG の12月7日分の記事として書いておりますのです。

僕はWebディレクターとして割と長いことBacklogを使ってきて、受託にも事業会社にもいたりして、さまざまなところからBacklogと接してきた気がする。

そーーーんなさまざまなところでBacklogを使ってきた経験から、ちょっとしたコツのようなものがあるよなぁと。

そんな感じのことを、Advent Calendarを見つけていつもだいたい激しく後悔して良い機会だと思って、それを書いてみようとそういう記事であります。

そんなわけで、うぇぶぎょうかいのむめいでぃれくたーのお時間です。

 

■目次

 



 

Backlogはたくさんの機能がある(すばらしい〜)

使ってる人はもちろんご存知と思うけど、Backlogにはたーくさんの機能があるますね。あるます。ある。そのすべてを使い切るのは難しいほどにある。あるよな?と思って公式サイトを見てみたら、本当に知らない機能まであった。

※Backlog公式サイトより(2024/12/07時点)

バーンダウンチャートなんてあるんか!知らなかった・・・。大魔王じゃん。バーンだけに。

そういえば、Backlogは(その技術力からすると)しばーーーーーーらくスマートフォン(アプリもしくはスマホ版サイト)対応をしていなかった記憶があって。たとえばチャットツールなど、世のビジネスツールがどれもこれも、すでにスマホでも閲覧できるようなサービスを展開していたのにも関わらず。

ワイ、あれは「いやいや、世のエンジニアやクリエイターよ、そんな、土日やプライベートの時間まで仕事したらいかんよ、な?」っていうヌーラボさんからのメッセージだったんではないかと勝手に思っている。

だから、モバイルアプリがリリースされたときは、とうとうBacklogもあっち側のブラック沼にいかれてしもうたか・・・と勝手に思った。ほんと勝手すぎる。でも便利。休日見ないけど。

余談が過ぎた。

ええ、だから本当に、プロジェクトを管理するための機能が、本当に豊富に揃っている。本当に便利。プロジェクトをしっかり管理しようと思えば思うほど、ナイスな機能が揃っている。
※なんかBacklogを褒め称える流れになってしまったが、お金は一切もらっていませんw

 

しかし、自由に使っていると破綻する

そんなたくさんの機能、あるのは便利なのだけど・・・。

だけど、これを全部使いこなそうとすると、たぶん破綻する。

いや、目的を持った上で使うなら大丈夫なのだろうが、おそらく"目的を持って使えばこそ"、全部の機能を使い切るということはないと思う。

というのも、たとえばBacklogには課題やコメントへの「ファイル添付」という機能がある。
まあ、そう珍しい機能でもなく、そのへんの掲示板的なものにはだいだいあるし、チャットツールにも、メールにすらある。

だけど、僕がプロジェクトマネージャーをやるときは、基本的にこの機能は使わせないです*1

なぜか。
ファイルやデータの最新管理ができなくなるから。

コメントの添付はとっても便利で、渡す方もコメントを書いてるその画面にドラッグ&ドロップするだけでアップできるし、受け取る方も今読んでいるそのコメントの画面からすぐにダウンロードできる。便利。とても便利。

だけど、それは「いまそのコメントを書く人/読む人」に限られた便利さで、あとからそのファイルやデータを探す人からすると、いちいちその課題スレッドを見つけなきゃいけないし、その中のどれが最新なのかもわかりづらくなる。

というか、課題スレッドがたくさんあり、課題タイトル(件名)から"たぶんここにあるだろう"と類推できないファイルだと、もはや見つけるのは不可能と言ってもいい。

また、仮にそのファイルを見つけても、それが実は古いファイルである可能性もじゅうぶんにある。なんか課題スレッドの最後のコメントに貼り付けられてるから、これが最新ファイルなんだろうなと思ってダウンロードしたら、実は最新ファイルは別の課題スレッドに添付されていたりして。

これは、「最新ファイルの在処を常に固定し、共有していない」から起きる。

 

backlogを適切に使うには、制限が必要だと思う

だから、僕はどんな小さなデータやファイルでも課題スレッドへの添付はルールで禁止して、同じBacklogにある「ファイル」に置かせたり、もしくはGitやSubversion配下に置くようなルール設計をします。

デザインデータであろうが、設計ドキュメントであろうが、依頼者からの素材データであろうが、すべて「最新のデータはここにあるのである」とするために。

なので、べつにBacklog内である必要もなく、GoogleドライブでもDropboxでも、何ならどっかのレンタルサーバーにFTPでアップロードするでも良いと思います。
※さすがにサーバーにアップするのは今はやらないけど、Backlog使ってない大昔はやってました。

 

無論、ファイル管理だけじゃなく他にもいくつかルール=制限を設けたり。

たとえば他にこんなものも(一部)*2

  • 課題の粒度は「1お題に対して一つずつ起票」
  • 親課題に具体的なタスクや依頼は記載しない
  • 「担当」は毎回変える(基本は返答が欲しい相手を担当に)
  • 必ず期日を設定する(ある程度テキトーでもOK)
  • 「カテゴリー」や「種別」は勝手に増やさない
  • 「〜様」や「お世話になって〜」などは無しでOK

たとえば「親課題に具体的なタスクや依頼は記載しない」は、ちゃんと決めないと意外とできない人が多い。

親子課題を作るのは良いのだけど、親課題に具体的なタスクを記載してしまうと、そこに書いてあるタスクは完了しているのに、連なっている子課題が完了してないので、完了にできない。
「親課題」として完了にできないのは良いが、しかしそこに書かれているタスクは完了しているのに、それを誰も把握できなくなる。タスク(課題)管理のツールなのに、それができなくなるんじゃ本末転倒で。

これでは、親子課題を設定した意味がない。

だから、僕は親課題には具体的なタスクは書かせないようにしています。具体的なタスクは子課題に記載し、子課題がぜんぶ完了になったら、やっと親課題も完了として閉じる。

このように、Backlogは多機能だからこそ、目的をもって適切に制限をかけないと、逆にプロジェクト管理が破綻すると僕は思っています。

なぜなら、ある人はコメントにデータを添付し、ある人は課題に複数のタスクを書いて、ある人は勝手にカテゴリを追加して。そんなことをしていたら、データの所在もわからなくなるし、いま何の課題(タスク)が残っているのかもわからなくなるし、そのカテゴリが何を意図してるのかもわからなくなって、逆に内容がわからなくなるから。

そんなことをしていて、プロジェクトが破綻しない方がおかしい。

 

実はWebだって同じ

「多機能ゆえに、きちんと目的を設定して使わないと破綻する」

という話なのだけど、これはBacklog特有の話ではなく。僕らWeb制作や開発に関わる者としては、そもそも「Web」がそうなんですよね。

Webというのは本当に多機能だけど、何も考えずに使ったらまあだいたい失敗する。

 

たとえば、「メディア」としての機能がある。

Webサイトに文章や写真、動画を掲載して、来訪した人に何かを伝える。それで楽しんでもらったり、次のアクションを起こしてもらったりする。

 

たとえば、「チャネル」としての機能がある。

「モノを売る」という行為において、その場は実店舗だけじゃなく、ECとしてWeb上で販売することも可能になったりする。

 

たとえば、「ツール」としての機能がある。

カレンダーに予定を登録して、時間が来たら通知が来たり、未来の自分の予定を管理したり、過去の自分の予定を振り返ったりできる。

 

それぞれが完全に独立しているわけではなく、一つのWebサイトがチャネルとして機能しているときもあれば、誰かにとってはツールとして機能していることもある。

だけど、これだけ多機能かつそれらが複数組み合わさる複雑性を持っているからこそ、「そのWebは、何のために生まれ、どう使われるのか」をきちんと定義しないと、まず成功することはないわけで。

結局、Backlogに限らず、多機能なものと向き合うときはいつだって同じだよな、と僕は思います。

 

何のために、何の懸念や課題を解消するために、Backlogのその機能を使うのか。

ひるがえってそれは、Backlogのその機能はどういう能力があり、どういうデメリットがあるのかをきちんと把握することだとも思います。

それはもちろん、Webだって同じなんですけどね。

 

 

Backlogを使うとき、大切にしている心得

いままで書いた事がそれなんだけど、それを一言でまとめたものを、僕はよくフレーズとして使っています。

 

「プロジェクトを管理するのはBacklogではない。アナタだ。Backlogは、それをサポートしてくれるだけ」

 

多くの(とくにプロジェクト管理の大切さをわかってない)人が、よく勘違いをしていて。

「Backlogを使えば、あとはよしなにやってくれるんでしょ」

とか。

大いなる勘違いで、Backlogは「プロジェクトを管理しきるという覚悟をもった者」を助けてくれるだけで、なんとなくBacklogに投げておけばプロジェクトを管理してくれるなんてことは、絶対にない。

また同様に、そういう人はだいたい「Backlogって難しいからムリ。使いづらい。もっと使いやすいツールがいい」と言ったりする。そんなツールがあれば僕が知りたいw おそらく世の中のプロジェクト管理ツールにおいて、Backlogはかなり「わかりやすい方」だと思う。
※余談だけど、BacklogのあのかわいいポップなUIは、非エンジニアの人に対するとっつきやすさにおいて結構良い仕事をしていると思う。

 

Backlogが難しいと思うのなら、それはBacklogが難しいんじゃなくてプロジェクトを管理することが難しいのであって。そもそも難しいものだという理解がないから、そういう発言になる(同様に、管理しきる覚悟がないからそういう発言になる)。

 

このプロジェクトを管理しきるのだ、という覚悟を持った者のみが、Backlogを適切に使えるのだ、と僕は思っています。

 

 

 

 

だから僕はなるだけBacklogの画面を見たくないっ。

 

カクゴナンテ( ゚д゚)モチタクネエ ダロ

 

*1:一方的な命令というんじゃなく、プロジェクトのルールとして合意のもとに設定します。

*2:当たり前だけどこのルールも「添付禁止」も一例であって常にそれが正しい、というわけでなく。プロジェクトの性質によって変えるべきだと思います。