7月25日（木）に開催された

JBUG 福岡 #9 webディレクターのBacklog利用事例 (2019/07/25 19:30〜)
https://jbug.connpass.com/event/134594/
# 更新情報 * 2019/6/14 イベントページを公開しました！ # イベント概要 Backlogのユーザーコミュニティ、 JBUG(Japan Backlog User Group) です。 今回は福岡で9回目の開催となるJBUGのオフラインイベントです。 今回はフリーランスでWebディレクターとライターをおこなっている野村幸子さんがクライアントとのやりとりにBacklogを導入してどういうメリットがあったか、また失敗をしたかのお話を中心にお話いただきます。 後半では4〜5人が1組となって、ヌーラボ社が作ったボードゲーム「PROJECT THEME PARK」...

こちら…

JBUG 福岡 #9 webディレクターのBacklog利用事例 に参加しました！

JBUGに参加したのは今回で…えっと3回目？くらい??

と思ってたら 2回目だったｗｗ

BacklogWorld2019のスタッフだったのであと何回か出てるような気になってただけで、実質2回めだったのは自分でも驚きでした。

今回のテーマは…

webディレクターのBacklog利用事例

ということで、フリーランスの Webディレクター、ライターをされていらしゃいます 野村幸子さんからお話しいただきました。

…と本題の前に、JBUG福岡恒例のピザで乾杯です！！

…恒例って知ってるくらい来てるはずなのにJBUGは2回めって…おかしいなぁ（笑）

さぁて、始まりました！！

司会の西嶋さんからご挨拶

JBUG 福岡 は今回で 9回目とのこと。

JBUG とは…
Japan Backlog User Group です。

西嶋さんいわく、福岡がイマイチ盛り上がっていない…とのこと。
このあと、ハッシュタグ「#JBUG」をつけてー と今後の予定を紹介して…本題へ

ちなみに今回のツイートはこちらにまとまっています！！

#JBUG 福岡 #9 webディレクターのBacklog利用事例
https://togetter.com/li/1380305
2019/7/25 @ヌーラボ福岡オフィス7FJBUG 福岡 #9 webディレクターのBacklog利用事例のツイートまとめ

本編「クライアントを巻き込み『2つのBacklog』でプロジェクトをとりまとめた話」はじまりました！

野村さんが実際にプロジェクトマネジメントで行った
「2つのBacklog」の事例をもとに成功談と失敗談を語ってくださいました。

細かい事例は実際に JBUGに来て聞いてほしいなぁ〜と思いますので、この記事では感想とこれから自分なりにしていきたいこととしてまとめようと思います。

Backlogにクライアントも参加してもらおう

プロジェクトを管理していくと「ここはあとでクライアントさんに確認してもらおう」ということがよく出てきます。

そういった部分を直接やり取りするためにもBacklogが有効ですよ…という話し。

メールでのやり取りやチャットでのやり取りだけだとこういった問題が起こりがち

  • 新規参加者が情報を後追いするのは大変
  • メンバー全員が見られる環境にない
  • 要件が1つのメールに複数込められたりするので取りこぼしが起こりがち

クライアントも巻き込むことで双方で進捗の確認がタイムラグなしに出来るのがメリット。

Backlog で課題の粒度に気をつけて課題を作成していくと「潰す快感」があり、モチベーションが上がる。

ただ、これだけだと問題が…

言いたいことが言える社内Backlogとクライアントとの社外Backlogを分けた

打ち合わせでよくある場面…

『会議中にクライアント側のひとりひとりの意見が対立しその場でもめはじめた』

…あるあるですが、こんな無駄な時間はありませんよね。

それは自社側にも言えることで、Backlog が1つだとそのやり取りを「クライアント」にも見られてしまうわけで…

言いたいことも言えないこんな世の中じゃぁ〜ポイズン

状態に陥ってしまうんですよね。

そこで、2つに分けた運用がおすすめ！

なんでも言える社内Backlog

1つめは「社内Backlog」、こちらで進捗管理や問題の洗い出しなどを行い、Wikiに最新情報をまとめておく。

2つめの「社外Backlog」でクライアントとのやり取りを行う。

そのため、常にまとめた結果を「社外Backlog」で共有することが出来、話しがそこからとなる。

「社外Backlog」は書き込む担当者を決めたほうがよさそう。各社の代表だけが書き込むことで責任が生まれ、ブレが少なくなる。

2つのBacklog これから標準になりそうなくらい、良いこと聞きました！！！

自社では運用ルールを遵守。

クライアントさんにはやさしくルール順守を先導。

これが導入の基本のようです。

3つのBacklogで失敗…

今度はプレイヤーが3つになって失敗した例です。

ひとつは 「クライアント」、ひとつは「自社」、ここまでは変わりません。

もうひとつ、自社の並列に「他の開発会社」が入った際に失敗した…とのこと。

3つのBacklogで2つのBacklogに加えて

自社と他の開発会社間で「開発Backlog」を作ったそうです。

ところが…

他の開発会社は 自社からすると並列にある会社だったため、 「強く言えない」（受注と発注の関係ではないため）ことが多々あったそう。

また、「それを言っちゃあおしめえよ〜」って感じでもありますが、文化が違う…ってことも。

他社の開発については口出しするような形になってしまいがちなのかな…と思いました。

そこのやり取りは密接になる期間だけ…とか、ある一部分だけとかでやったほうが良さそう。

クライアントと他社の関係も知らない状態ならなおさらですね。

「フォローにも限界がある！！」

っておっしゃってました（笑）

感想まとめ

プロジェクト管理は「管理しないのが究極のプロジェクト管理」って誰かが言ってましたが（笑）

そのとおりだと思っていて

「各自が自分ごとで参加する」ことを徹底しないとダメだと思いました。

Backlogを使って管理する場合も同じで、全員が自分の仕事をまっとうするための管理ツールとしてBacklogを使うならプロジェクト管理は楽だし見通しがよくなりますね。

そのために、モチベーションをあげるためのツールとしてBacklogがある…って思うと

いかに Backlogを楽しく使うことが出来るか？ っていうことをクリア出来たらプロジェクトマネジメントがうまくいくってことになりそう…と思いました。

自分なりの…「やってみよう！リスト」

  • 課題の粒度を 1課題1タスクにして作る
  • 課題の消化を褒めあう（笑）※大事ｗ
  • 現在の状況がわかるように Wiki にまとめて更新する（週1程度からはじめたい）
  • 1つのプロジェクトに対して2つのBacklogで管理したい（社内用、社外用）
  • とにかく未完了課題0を目指す！

このくらいから始めたら楽しく出来るんじゃないかな…って思います。

JBUGに参加すると Backlogがうまくなる

Backlogがうまくなる って変な表現だけど、JBUGに参加してたらBacklogをうまく使えるようになると思いました。

1回目より2回目、Backlogをこうして使うと…っていうアイディアももらえますし、こうして使うとこうなったっていうお話しも聞けますし。

「こういうときどうしました？」っていう質問も出来る！

JBUGって良いコミュニティーよね。

ありがとうございました！！！

次のページは プロジェクトテーマパークをやってみたよ！ です（笑）

この記事が気に入ったら
いいね ! しよう

シェアする
ツイートする
Twitter で