Backlogを利用してデザイナーと上手く共創した話
はじめに
以下の文章は1月22日のJBUG大阪で登壇した「Backlogを利用してデザイナーと上手く共創した話 〜LoveStory風味〜」の補足記事です。発表はLTだったので、そこで喋りきれなかった話について書いてます。
尚、この記事はやたら長いです。書いたネタは1年くらい溜めこんだモノを全部解き放ってるし、図とか絵はスライドに使ってるので、記事中には全く載せてません。なので、きっと途中で読むの辞めたくなると思います。
大丈夫、それでいいんだ。
でもでもでも、JBUG大阪での発表は8分くらいに短く纏めて喋ってるので良かったら見てください。（僕の出番は15分過ぎぐらいからです。）
オンライン開催！！
Posted by JBUG on Friday, January 22, 2021
序文とあるある
そもそも僕はデザイナーと仕事するのが好きです。デザイナーは僕が持ち合わせてない感性とか美的センスとか持ってるのが最高に羨ましいです。いつも「なんでこんなに洒落たものを作りだせるんだ？」とか思います。生まれ変わりルーレットで「デザイナー」引いたら「お、いいじゃんうれしい」と思う程度には憧れています。なので、単純に会話するのもペアデザするのも楽しいのです。ですが、進捗管理やタスク管理、という目線で見ると、どうにも開発と同じ土俵に乗っかりにくい問題があると思ってました。
（以下、僕が経験したあるあるパターンを書きます）
あるあるパターン①
1. デザイン課題が溜まる
2. 粒度が細かいので開発のガントチャートに乗らない
3. 独自に課題を纏めたエクセルとか作りだす
4. エクセルを使い慣れてなくて纏めるのに時間をロスする
5. そもそもエクセル見にくい
6. 放置
あるあるパターン②
1. 粒度が細かいので、複数のタスクを纏めた課題にしたりする
2. 纏めたタスクの一部完了状態が長く続く
3. 忘れる
4. よくわからないので一旦完了にしちゃう
5. タスク消える
6. 抜け漏れ発生
あるあるパターン③
1. 有能なデザイナが途中で他プロジェクトに抜かれる
2. 残課題の状態が不明になる
3. 一部完了のタスクとかはマジで意味不明
4. もう面倒だから一からやり直しになる
おぉ、あるある、という声が聞こえます。（知らんけど）
とはいえ、そもそもデザインの仕事はタスクの粒度も違うし、別にそんな致命的な問題じゃないし、まぁ、別にいっか。みたいなので済ませてたんですが、デザイナーと仕事するのが好きな僕としては、なんかもっと上手く仕事を回したかったのです。
Backlogのボード機能とひらめき
そんな時、ちょうどBackLogのボード機能のニュースが入ってきました。
それを読んだときに「あ、コレや！」的な閃きがありました。
ボード形式なら、
「粒度と期限に依存することなくタスクが見える」
つまり、上述のあるあるを解決できるのではないか？と思ったのです。というのは嘘で、本当は「なんかわからんけど上手いこといきそうな気がする」という感覚的な閃きでした。上記の理屈は後づけです。
（そこに最初から辿り着けるノウミソが欲しい）
とはいえ、そこは自分の感覚を信じよう、と思って、実際のプロジェクトでカンバンボードを使ってみました。その時の運用方法をざっくり纏めると以下のような感じです。
・ タスク優先度はボードの並び順（ルールを徹底）
・ 期日管理はわりと緩めにする （Mustなタスクについては入れるが、それ以外は必須としない）※1
・ タスクの粒度も特に定めない ※2
・ タスクの登録はデザイナ側、開発側の双方で実施
・ デザイナとマネージャで週1ペースで課題の棚卸しを実施。棚卸し時にボールの位置確認し担当者を変更する ※3
・ 状態：（実装保留中）を作成、実装の優先度が低くデザインが完了してるものを入れる箱を作る
・ 開発者は手が空いたら実装保留中の箱の一番上からタスクの実装をする
※1…デザインタスクは期日が決まってないことも往々にしてあるので登録時に無理に入れない。（実装時期が決まったら期日入れます。でないとガントチャートに乗らなくて困るので）
※2…デザインタスクは工数予測が難しい場合がある。とはいえ1週間引っ張ることは稀。なのであんまり気にしない。
※3…実はこれだけでいいのかもしれない。とはいえこの棚卸し作業時、ボード機能は非常に役立つ。
運用してみた結果（良かったところ）
上記ルールで半年ほど運用してみたところ、概ね満足できる結果となりました。良かったところをそれぞれの目線で書きました。
開発者・マネージャー目線
・デザイナの仕事が外から見えやすくなる ※1
・ デザイン課題が常に整理された状態になる
・ デザイン依頼のフローが確立される（依頼入口と出口の一本化）※2
・ デザイナと開発者の間で優先度が一致する ※3
・ 抜け漏れが発生しにくい
※1…存外デザイナの仕事はまわりから見えづらく、なんでこんな時間かかるの？とか、なんか変にこだわってるんじゃないの？みたいな指摘をPOあたりから受けがちです。どっちの気持ちもわかるけど、そういう指摘や誤解はプロジェクト全体の士気に関わるので、未然に防ぎます。これを防げるのは進捗仕切ってる人だけの筈なので。そういうの大事（と僕は思ってる）
※2…デザインタスクの依頼が乱れ飛ぶと誰も得しません。混乱しかありません。一本化することに何の迷いがあるでしょう。しかも課題を登録したら見える化にもなる。あったりまえの話ですけど、大事なことだと思います。
※3…デザイナの考える優先度は成果物の優先度と一致しないことも往々にしてありますが、デザイナが修正して欲しい箇所を修正することにより、デザイン的なブラッシュアップが発生する確率が上がると思ってます。一見どうでもよさそうなところが修正されることによって、デザイナにしか見えない何かが繋がってハジケて革新的な何かが生まれる可能性があるのです。（発生しない事の方が多いけど）後で考えても関連性見つけるのが難しいし、これがそうだ、という実証もできないけど、無下にしないほうが良い要素だと僕は考えています。
デザイナ目線
・ ボード機能が認識合わせにすごく便利
・ Backlogはデザイナからしても使いやすく（エクセルとか嫌い）助かる
・ タスクの詰め込まれ具合をガントチャートで確認可能
・ 「今この課題はどういう状態？誰がボール持ってる？」を気にしなきゃ
いけないPJTに向いてる
・ チケットにファイル添付できるのが便利。デザインの共有が楽
運用してみた結果（イマイチだったところ）
もちろん良い事ばかりではなく、課題もありました。以下の通り。
・ Backlogのボード機能じゃなくても定期的な棚卸しだけやってたら成立するのかも？ ※1
・ 課題やコメントに複数画像を添付すると課題そのものの添付ファイルとしてデータを持たれてしまうので、決定稿がどれか混乱してしまうケースがあった。 ※2
・ デザインのやり取りをBacklogのコメントでやると、コメントが増えたとき、それぞれが個別に折りたたまれてしまい見返すのに不便。Backlog使うのやめようかな、と思うぐらいに不満…。 ※3
※1…棚卸しについては、まぁ普通の話です。実際ツールなんて不要で、これだけで上手く回す事もできると思います。とはいえ個人的には自分が忘れっぽいのと、ツールがある方が話しやすいので両方必要だと思ってます。
※2…Backlogにつけるのは楽だけど、本来は別のツールで管理するべきなのかもしれないです。とはいえ本文に画像ついてると分かりやすい、というメリットもあるのは事実。結局ここはCreativeCloudFilesでのファイル共有に切り替えました。
※3…これはデザイナとの共創に関わらず全体的な使い方の問題のようにも思います。Backlogは期日移動したりすると延々とコメントが長くなる傾向があるので、そこはしんどい気がします（なんか設定あったっけ？もし知ってたら誰か教えて下さい。）とはいえ、コメントが増えた時の問題については例えばGithubのIssue等でも同じ問題があって、折りたたむか、長々とスクロールするかの違いでしかないので、どっちもどっちな気がします。あんまり解決方法知らないので、誰か知ってる人いたら教えてほしい。
（蛇足）なぜボードで上手くいったのか
冒頭のあるある3パターンの問題点を纏めると以下になると思います。
①開発とデザインタスクのスケジュールが合わないため、ガントチャートだとデザインタスクが過去日に取り残されたりする
② デザインタスクの粒度が細かい。その粒度で全部課題にした場合、ガントチャートの行数が増えすぎる。
③ 他タスク待ちやタスクを纏めた課題がある場合、一部完了状態が長く続きタスクのスピード感が損なわれ、最悪タスクの抜け漏れに繋がる
④ ガントチャートで表現できないので他ツールを使わざるをえなくなり、管理が煩雑になる。
①、②については上述の通り「粒度と期限に依存することなくタスクが見える」というボードの特性で解決できる部分です。逆に言えばガントチャートが苦手な要素ですね。
③については「実装保留中」状態を作ることで解決した部分です。これに加えてデザイナ・開発間での優先度の共有もできたので、運用ルールで上手く解決できたと思います。
④はガントとボードを両方使えるBacklogの強みだと思います。デザインタスクにマイルストーンかカテゴリを設定しておけば、デザインタスクに絞り込んだ状態でボードを見ることができるので、無意識のうちにガントチャートを触って壊してしまう、みたいなこともありません。
全体所感
POと開発とデザイナの間を取り持つ僕の立場をBacklogがツールとして助けてくれてる感じがありました。自分がやりたかったことをビジュアル化して、会話とタスク管理の溝を上手いこと埋めてくれる感じ。まさにそういう働きを期待してたので、これに関しては文句なしです。
そもそも自分はカンバンボード形式の管理が苦手というか上手く使えてなかったのですが、ガントチャートで上手く管理できない課題にぶち当たった事で、カンバンボードの特性をきちんと理解できた感じがします。ボードの特性はD&Dで”ToDo”から”Done”に移動できる、ということでは無い、という（まぁそれも特性の1つですが）当たり前の事が腹落ちして理解できてなかった。そういう意味でBacklogのボード機能実装は、自分にとっては非常にありがたい気付きを与えてくれたものでした。マジ感謝。
ということで、もし僕と同じような悩みを持つ方に、ボード機能での管理はオススメです！（別にBacklogじゃなくてもTrelloとかでも同じですし！）
さらに蛇足
アーカイブの動画を見てくださった方へ。
僕のスライドにちょいちょい出てくるラブストーリーシーンの台詞はすべて Mr.Childrenの楽曲「ありふれた Love Story ～男女問題はいつも面倒だ～」の歌詞です。
1996年のアルバム「深海」に収録されています。僕にとって「オトナになったらきっとこんな恋をするんだろうな。チッ…面倒そうだぜ…」と思ってたけど実際には全然そんなことなかったし、むしろそんなんやってみたかったわ！と思わざるをえない名歌詞です。昔の歌だけど古さは感じないし良い曲なので聞いてみてください。
この記事が気に入ったらサポートをしてみませんか？