JBUG東京#6「プロジェクトマネジメントを “習慣化” しよう!」に登壇しました

2018年11月03日

2018年11月2日の話ですが、backlogのユーザ会イベント「JBUG(Japan backlog User Group)」のイベントにお声がけいただき、名村やWeb制作・ホームページ制作会社である株式会社サービシンクがどの様に「Backlog」を使っているか?という話をさせていただきました

JBUG (東京#6) プロジェクトマネジメントを “習慣化” しよう!

JBUG (東京#6) プロジェクトマネジメントを "習慣化" しよう！ (2018/11/02 19:30〜)

connpass

# 更新情報 * 2018/10/30 参加人数を増枠しました！ * 2018/10/16 参加人数を増枠しました！ * 2018/10/15 イベントページを公開しました！ # イベント概要 Backlogのユーザ...

今回登壇をさせていただくことになったのは、数か月前にヌーラボのMeggyさんこと五十川さんとお会いする機会があり、そこで名村のBacklogの使い方をお伝えしたところ、

そんな使い方している人、聞いたことありません・・・

と、いい意味なのか悪い意味なのか分からないのですが(笑)、かなりまれな使い方例だったらしく、「いつかJBUGで話をしてください」ということから今回の登壇になりました。

トリッキーに使おうと思ってそうなった訳ではなく「バグチケットシステムを使い慣れていないクライアントにも利用をに強力してもらえるために」という思案して考えた方法でした。

ありがたいことに、この会がJBUGさんでの過去最多の参加者になったらしく、2度の増枠を経て、合計40名以上の方がご参加いただけました。

当日20分の登壇でスライド80枚(笑)

別にスライドの数は関係ないのですが、バグチケットシステムの使い方を伝えることを考えると多少図示したほうがわかりやすいよな・・・と思って作ってたらかなり多くなってしまいましたが、別にそれほど急いで発表をしたって感じではなく出来ました。

当日のスライドは下記に配置しました

SlideShareにあげようとしたのですが、上がらなかったので、こちらに当日のスライドの公開可能版をアップさせていただきました。

もしよかったらご覧ください。

盛り上がっていた観客の方のツイート

Meggyさんが最初に「こんな使い方してる人知らないです」と言ってくれたみたいに、当日のツイートでは名村の使い方についてそこそこ受けていたみたいで、盛り上がっていました(笑)

いくつか抜粋させていただきます!

プロジェクト管理ツールを使ってない方からすると、
メールでも事足りている、と感じている。

それを前提に。#JBUG pic.twitter.com/WtKWh5w2Ah
— you (@youtoy) 2018年11月2日

「種別」で進捗を表示&可視化させる #JBUG pic.twitter.com/A4zmAkDBtb
— TK(kimoto) (@TKimotoshi) 2018年11月2日

進捗の状態を「種別」に落とし込んだ!進捗で変化させる。その発想はなかったーーー #jbug
— Angela @ ぬ (@posi0202) 2018年11月2日

Backlogの種別を、進捗がどのマイルストーンに対しての状況として使ってる。ので、種別はどんどん変更されていく。これなかなか真似したい感あるね。 #JBUG
— Yu Morita (yuu) (@securecat) 2018年11月2日

クライアントが、プロジェクトはWBSの積み上げとリレーションであるって理解する必要がないってのは、概ねの場合そうだよね。となると、締切の積み上げとして分解したほうがいいわけで。 #JBUG
— Yu Morita (yuu) (@securecat) 2018年11月2日

完了にするのはクライアントの担当だそうで。それもいいね。クライアントが自分事としてプロジェクトに参画するって、結局そういうことだなと思う。すべてのタスクはプロジェクトの完了(成功)のためにあるわけなんだし。 #JBUG
— Yu Morita (yuu) (@securecat) 2018年11月2日

これが一番受けたらしいのですが、名村は「種別」で進捗管理が分かるようにしていました。
理由は「課題の一覧」を見たときに、誰が持っているどの状態のチケットなのか?をすぐに分かるようにしたかったためです。

これについてはスライドにも書いていますが「子タスクの意味」とかは十二分に理解をしていますが、バグチケットシステムにそんなに触れていないクライアントの方にもできるだけ理解をしてもらえるように・・・と考えた結果でした。

このことは当日Meggyさんが改めてツイートで、

この「種別」でのステータス運用、ほんと珍しいんですが、聞いたことないんですが、クライアントの使いやすさって目線でいうと納得する。。。 #JBUG
— Meggy Nulab (@Megumi_Isogawa) 2018年11月2日

と書いてらっしゃって、それをみて「そんなに珍しいのか・・・」と改めて思っていた次第です。

2019年10月1日追記 この仕様自体は「課題の状態」で本来やるべきだったのですが、2018年当時はそれが出来ませんでした。「種別」の変更はチケット自体の修正が必要でもあったので地味に手間だったのですが、当時としては一覧上で「どういう状態なのか?」がパット見て分かる状態だったので採用していました。

ですが、2019年9月26日にヌーラボさんから下記のリリースが出ました。

【リリース予告】Backlogの課題の状態が“自由に追加”できるようになります!〜タスク管理や運用をラクラクに〜

「課題の状態」自体をカスタマイズするようにできるみたいで、これまでの「未対応・処理中・処理済み・完了」以外も追加ができるようになります。

そうなると、名村が種別で行なっていたことは「課題の状態」側に持ってこられると思います！

Backlog を使う文化にする。

しかし、
メールで連絡が来たり、
Backlog を見てません、
という事例が。

その対策。#JBUG pic.twitter.com/oJI5Y0kiBi
— you (@youtoy) 2018年11月2日

業務フローにツールを強制的に入れ込むのは強制力すごい。でもこれサービス提供者じゃない人がやってるのがスゴい。 #JBUG pic.twitter.com/vxr500WpXX
— TK(kimoto) (@TKimotoshi) 2018年11月2日

件名は、詳細を見なくても概要がわかるように。
また、コメントの書き方も、分かりやすく!#JBUG pic.twitter.com/hDs04QS7l3
— you (@youtoy) 2018年11月2日

と最後の引用ツイートは名村のブログを御覧の方は知っていると思われる「誰がどう見てもそうとしか受け取れない文書術」の延長の話です。

「プロジェクト憲章」を最近作ることを始めているのですが、そのことを紹介していたら、ヌーラボの中の人であるAngelaさんとMeggyさんから、

名村さんのミニマム版の「文章作成術」、二次配布可能にしていただきたい!!!!!!! #JBUG https://t.co/ufQSjZqWfz
— Meggy Nulab (@Megumi_Isogawa) 2018年11月2日

と言われたので、会場で作ってアップしたら喜んでもらえました。

作りましたよー!
「プロジェクト管理方針」の部分をBacklogのwikiの「テキスト整形のルール」形式でのテキストファイルです。
Backlogのwikiの設定が上記であれば貼り付けたらスライドと同じ形式で表示されます。
二次配布してくれて構いません。https://t.co/r9J1meXmLR #JBUG
— 名村晋治@サービシンク (@yakumo) 2018年11月2日

ただのテキストファイルですが、Backlogのwikiにコピペして使えるテンプレート、利用してみたい方は下記をご利用ください。

ミニマム版のプロジェクト管理方針(wikiへのコピペ利用可能版)

* 課題管理
- Backlogプロジェクト「◯◯◯◯◯◯◯」を使用して、プロジェクトにおけるタスクや課題をチケットとして管理する。
* 時間管理
- Backlogの時間管理を利用して、保守タスク管理のチケットの見積もり時間や実績時間を管理する。
* 要約
- 体言止めを禁止する。次のアクションを明確に「〇〇の仕様を決定する」「〇〇の仕様を調査する」と具体的に記入する。
- 要約は一覧表示で分かりやすいように明確なアクションする事で、詳細の確認に時間を費やすことを防止します。
- 以下が望ましくないケースとして認識する。
-- AAA_BBB-001 - 更新する前の会員の状態の確認について
-- AAA_BBB-002 - 公開不具合に関して
-- AAA_BBB-003 - リンク設定でラベルを登録しない場合は登録エラーを表示させる
* 説明・コメント
- 説明には質問や未決事項を記入して、最終的な回答や決定事項は、説明欄に起票する。
-- これは第3者が閲覧した時にコメントを追って、回答や決定事項の確認に時間を費やすことを防止します。
- テスト実施時の説明欄に記入する項目は、別途定義する。
-- 画面名(URL)
-- 操作手順
-- 発生事象
-- 期待する結果
-- OS(バージョン)
-- ブラウザ(バージョン)
- 条件マトリクスや処理パータンを議論する場合は、文章に頼らず速やかに図表にまとめる。
- 指示代名詞は嫌いです。仕様認識齟齬の温床だと思って下さい。
- 長文も嫌いです。箇条書きするなど相手に簡潔に正しく伝えるための思いやりを持って下さい。
-- 不具合など急いで起票して、詳しく後で書こうなんて思っても、絶対書かないと思います。
-- 不具合調査は、初動の情報量で対応速度が大幅に変わるので、慌てず騒がず落ち着いて起票して下さい。
- 投稿する前に深呼吸して、推敲してから投稿して下さい。
* 添付ファイル
- チケットに添付するファイルの命名は、何の資料かが判断できるように命名する。
- 添付ファイルの内容を修正してもファイル名は変更せずに同一のファイル名で添付する。
- 履歴からいつだれがアップロードしたかが判断できる。
* 用語集
- 用語が統一されていないために、指示代名詞で誤魔化してしまうと齟齬が多発するので、みんなで用語集を作りましょう。
- [[プロジェクト用語集]]