谷口さんのセッションについてのエントリーを読みつつ。

Backlogにちゃんと巻き込むため、H2O spaceが試したこと - 週刊アスキー
https://weekly.ascii.jp/elem/000/000/425/425859/

Backlog World 行きたかったなー、と思いつつ、この頃、余裕無かったのが悔やまれる。。。

スケジューリング力なさが全てだ。。。

タスクの棚卸し・整理作業

これを解消するためには、ディレクターが課題を整理してあげるべきだと谷口さんは提案。タスクの粒度や締め切りの見直しと再設定、関係ない話題は別タスクに分けるなど、Backlogの機能をちゃんと使ってあげることで、タスク管理のツールとしての力を最大限に引き出せる。

やろうやろうやろうやろう・・・・

あぁ、火を噴いてるタスクの多さよ・・・

GTD的な意味で言うところの依頼したタスク、みたいなのとかをどう整理していくか。
毎日時間をとるのか、２日に一度にするのか。

別ツールで依頼したタスクを管理したんだけど、そもそも二重管理になって破綻したりしたのでツールは分けない方が良さそう。

そもそもブッチされまくって別のツールが期限切れだらけになるのでやってられなくなったと言うのもある。

ブッチされる理由はなにかしらある訳なのでそこはそこで要調査事項ですね。

クライアント向け、社内向けのプロジェクトを用意する

やってしまいがちなのが、Backlogで顧客と開発者とを同じプロジェクトで結んでしまうこと。これをやってしまうと、開発側のトラブルや内輪の状況がそのままクライアントにも見えてしまい、お互いに気まずくなります。プロジェクトごとに対クライアント、対開発パートナーの2つのプロジェクトを立て、ディレクターがその間に立つことをお勧めします

個人的にはこのスタンスでやるのが基本スタンス。
翻訳するのも仕事のうち。
作業チケットを起票するのも仕事のうち。

主体的にうごく、という考えであれば１つのプロジェクトだけでやる方がいいのかもしれないけど、なかなかうまくうごかないのかな、、、と。

ただ、ディレクターの自分しか見れていない＝自分がボトルネック、になることになるので、基本的にはディレクター以外もクライアントのプロジェクトにはいっていたほうがいいのではないかとは思っている。
なので、現状では入ってもらっていることが多い。

ただし基本的な作業依頼とかは社内用のBacklogでやりとりする、と言う風にしている。

そのルールがなくなるのがリリースが近くなった時間優先になったあたりかな、というのが個人的な切り替えタイミング。

仕様の認識違いとかであればどちらに原因があるせよすりあわせがしやすくなるし、そのタイミングで来る内容はクリティカルな内容かそうじゃないかの切り分けがメインになったりするので、すぐ直す物は内容の理解については難しくないんじゃないのかな、と思っている。

実装や実装変更が難しい場合はありますが。。。

あとは、Wikiとかの情報、データ系はクライアント側プロジェクト尾に寄せておくのがよいかと思っている。

社内だけで共有しておくべき情報はあるので、そう言うのだけに限定して使うとして、それ以外の情報は全員がみれるクライアント側のプロジェクトに書くのがよいのかな、と思っている

クライアントが見るべき・話すべき粒度と、制作側が考える粒度は大小が確実に異なるので、そこら辺の意味ではプロジェクトを分けておく方がクライアントにとっても使いやすいツールになるのではないかと思っている。

クライアントと話をしているディレクターには気づきにくいかもしれないけど、クライアントとのMTG内容とかが開発メンバーからしたらブラックボックスになりがちなのかな、とも。

議事録を共有したところで温度感とかは伝えきれなかったりもするので、そういった所のフォローにもプロジェクトを一緒にする、分けることのメリットがあるのかなー、と。