Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Backlogを立ち上げる前に失敗している?
コミュニケーションレイヤー細分化の悲哀
2017/9/29
株式会社テンタス
小泉智洋
JBUG#2 東京「俺みたいになるな!Backlogのアンチパターン」
2
最初に
今回の事例は、
関係者それぞれの見ている方向性やレイヤーが異なる
為に生まれてしまったコミュニケーション差分を説明
するためであり、
決して特定の方(グループ)をけなす目的ではありま
せん。
というエクスキューズ
3
株式会社テンタスの
腕力系プロデューサーです。
(仕事上の)座右の銘は
「お金で解決できることはお金
で解決しようよ」
重要
では、自己紹介
4
チケット単位で課題やスケジュールを管理できる、
プロジェクト管理には無くてはならないツール
です。(よね?)
Backlog って?
5
クライアント/代理店/制作会社/開発会社/外部ベン
ダーなどなど、多く人間が関係しており、それぞれの
コミュニケーションレイヤーで
求める情報は細分化されます。
でも、プロジェクト関係者って
6
今回はそんなコミュニケーションレイヤー
細分化による失敗3事例をご紹介
1.代理店案件失敗事例
2.ビックプロジェクト失敗事例
3.グローバル案件失敗事例
7
1.代理店案件失敗事例
長期スパンで顧客と接している為に
日々のコミュニケーションは完全に
顧客向けにカスタマイズされており、
プロジェクト進行に必要である
“明確”で”端的”な情報伝達を
嫌がる傾向にあります。
8
PJの成功 < 途中のコミュニケーション
代理店が...
顧客の要望=正解ではないことが多くあるので、
本来は議論をすべきことも、
そのままスコープになってしまったりします。
9
クライアント 代理店 制作サイド1WAY
コミュニケーション
これってできる?
絶対やってください
納期?変更ないよ
それ...
10
クライアント 代理店 制作
進捗をガントで報告
サマリー
コミュニケーション
パワポの報告書にして?(見てない)
クライアントはチケット毎の管理を行うまでの時間
がない為、課題をまとめた報告書での報告が求めら
れます。
その結果、作成労力...
11
このようなコミュニケーションを
フォローするために
コミュニケーションマップは
次のようなカオスになりました。
【3つのバックログ】
【課題管理表】
【進捗サマリ】
を作って管理しました。
12
クライアント上長
代理店担当者
クライアント担当者
ディレクター
プログラマー
マークアップエンジニア
デザイナ
SE
PM
制作サイド
クライアントサイド
代...
13
・完了担当が不明でチケットがゾンビ化
・ガントチャートから課題管理表への転記転記転記。毎週転記
・サマリーを作っている間に本体のBacklogとの乖離
・正となるチケットやスケジュールはなに?どこ?だれ?
このPJで起きたこと
14
・完了担当が不明でチケットがゾンビ化
→バックログのメンテだけおこなう、バックログ番長を設置
・ガントチャートから課題管理表への転記転記転記。毎週転記
→マンパワーで解消
・サマリーを作っている間に本体のBacklogとの乖離
→マンパワ...
関係者ごとに
知りたい情報の粒度が異なる!!
15
問題の本質は
Backlogは
求める情報の粒度が異なる
ユーザーを一同にまとめて
報告/管理するのには
(あまり)向いていない。
16
わかったこと
17
2.ビッグプロジェクト失敗事例
では、続きまして、、、
ビッグプロジェクトは関係者が
さらに多くなります。
18
とあるサイトのリニューアルプロ
ジェクトの事例ですが、
コミュニケーションマップは
さらにカオスに!!
スケジュールツール(Brabio)
頭おかしいと思います
よね?
私もそう思います。
19
クライアント上長
代理店
内勤系担当者
クライアント
IT系担当者
プログラマー
運用担当
デザイナPM
制作サイド
クライアントサイド
制作進行/全体...
膨大な
コミュニケーション
コストが発生
20
PJで起きたこと
→お金で解決
→マンパワーで解決21
どうやって解決したか
膨大な
コミュニケーション
コストが発生
22
3.グローバル案件失敗事例
最後も胸やけしそうなので簡潔に
国をまたいだプロジェクトは
さらに複雑化します。
その結果(以下略)
23
ビッグプロジェクト案件失敗事例 ~原因&結果編~
ここは迷宮かな?24
クライアント上長(日本
代理店
サイト制作担当者
クライアント
サイト担当者
ディレクター デザイナ
PM
制作サイド
クライアントサイド
アナログ報告書(週次報告書、課題...
25
今回ご紹介した3事例は全て同
じ課題がベースにあります
おさらい①
プロジェクトが大型化すればす
るほど、関係者は多くなり
26
おさらい②
それぞれが求める
情報の粒度は異なります
全チケットを把握しないと
プロジェクト全体管理でき
ないし!
自分のチケットはきっちり
把握!
進捗どうですか?
飲みに行くけど
なんか問題あったら呼んで
27
おさらい③
その解消/同期には莫大な
コミュニケーション労力が必要
28
おさらい④
これらの解決方法は?
29
お金で解決
正直無駄ですが、
現状ではこれでしか解決できない
プロジェクトがあることも事実です。
30
31
ありがとうございました
32
さすがにこれだけでは
アレなので、
プロジェクトの登録者別に
見せる情報を制限する機能や
他Backlogとの連携
(という機能追加)
制作担当
代理店
外部ベンダー
クライアント
〇
〇
×
〇
〇
〇
×
×
〇
×
×
×
×
×
〇
×
ガント
チャート 親課題 子課題
...
×何を見せるか?
〇何を見せないか?
34
これが
コミュニケーションレイヤーの
細分化を防ぐ為の
必要なファンクションです。
35
プロジェクト管理
+
コミュニケーション管理
最強だよねって話でした。
が、できたら
36
失敗事例とはいいましたが、
1と2の事例はちゃんと無事故で
リリースしております。
ありがとうBacklog!
ちなみに
3は絶賛炎上稼働中!
37
こんな案件ばかりやってる私達ですが、
手伝ってもいいよ!
って奇特な方がいらっしゃれば
後ほどご挨拶をさせてくださいませ。
最後に
38
今度こそ本当に
ありがとうございました
Upcoming SlideShare
Loading in …5
×

JBUG#2 コミュニケーションレイヤー細分化の悲哀

1,675 views

Published on

Backlogユーザーグループ東京#02
「俺みたいになるな!Backlogのアンチパターン」セッション
「Backlogを立ち上げる前に失敗している?コミュニケーションレイヤー細分化の悲哀」

Published in: Business
  • Be the first to comment

  • Be the first to like this

JBUG#2 コミュニケーションレイヤー細分化の悲哀

  1. 1. Backlogを立ち上げる前に失敗している? コミュニケーションレイヤー細分化の悲哀 2017/9/29 株式会社テンタス 小泉智洋 JBUG#2 東京「俺みたいになるな!Backlogのアンチパターン」
  2. 2. 2 最初に 今回の事例は、 関係者それぞれの見ている方向性やレイヤーが異なる 為に生まれてしまったコミュニケーション差分を説明 するためであり、 決して特定の方(グループ)をけなす目的ではありま せん。 というエクスキューズ
  3. 3. 3 株式会社テンタスの 腕力系プロデューサーです。 (仕事上の)座右の銘は 「お金で解決できることはお金 で解決しようよ」 重要 では、自己紹介
  4. 4. 4 チケット単位で課題やスケジュールを管理できる、 プロジェクト管理には無くてはならないツール です。(よね?) Backlog って?
  5. 5. 5 クライアント/代理店/制作会社/開発会社/外部ベン ダーなどなど、多く人間が関係しており、それぞれの コミュニケーションレイヤーで 求める情報は細分化されます。 でも、プロジェクト関係者って
  6. 6. 6 今回はそんなコミュニケーションレイヤー 細分化による失敗3事例をご紹介 1.代理店案件失敗事例 2.ビックプロジェクト失敗事例 3.グローバル案件失敗事例
  7. 7. 7 1.代理店案件失敗事例
  8. 8. 長期スパンで顧客と接している為に 日々のコミュニケーションは完全に 顧客向けにカスタマイズされており、 プロジェクト進行に必要である “明確”で”端的”な情報伝達を 嫌がる傾向にあります。 8 PJの成功 < 途中のコミュニケーション 代理店が重視するポイント
  9. 9. 顧客の要望=正解ではないことが多くあるので、 本来は議論をすべきことも、 そのままスコープになってしまったりします。 9 クライアント 代理店 制作サイド1WAY コミュニケーション これってできる? 絶対やってください 納期?変更ないよ それって 意味あるんだっけ。。。 よくあるパターン1 1WAYコミュニケーション
  10. 10. 10 クライアント 代理店 制作 進捗をガントで報告 サマリー コミュニケーション パワポの報告書にして?(見てない) クライアントはチケット毎の管理を行うまでの時間 がない為、課題をまとめた報告書での報告が求めら れます。 その結果、作成労力や、作成リードタイムによりチ ケットとの差分が生まれてしまいます。 よくあるパターン2 サマリーコミュニケーション
  11. 11. 11 このようなコミュニケーションを フォローするために コミュニケーションマップは 次のようなカオスになりました。
  12. 12. 【3つのバックログ】 【課題管理表】 【進捗サマリ】 を作って管理しました。 12 クライアント上長 代理店担当者 クライアント担当者 ディレクター プログラマー マークアップエンジニア デザイナ SE PM 制作サイド クライアントサイド 代理店上長 外部ベンダー等 案件共有用バックログ 制作進行/全体スケジュール管理用バックログ 開発/テスト管理用バックログ アナログ報告書②(進捗サマリ) アナログ報告書①(課題管理表)
  13. 13. 13 ・完了担当が不明でチケットがゾンビ化 ・ガントチャートから課題管理表への転記転記転記。毎週転記 ・サマリーを作っている間に本体のBacklogとの乖離 ・正となるチケットやスケジュールはなに?どこ?だれ? このPJで起きたこと
  14. 14. 14 ・完了担当が不明でチケットがゾンビ化 →バックログのメンテだけおこなう、バックログ番長を設置 ・ガントチャートから課題管理表への転記転記転記。毎週転記 →マンパワーで解消 ・サマリーを作っている間に本体のBacklogとの乖離 →マンパワーで吸収 ・正となるチケットやスケジュールはなに?どこ?だれ? →マンパワーで同期 どうやって解決したか
  15. 15. 関係者ごとに 知りたい情報の粒度が異なる!! 15 問題の本質は
  16. 16. Backlogは 求める情報の粒度が異なる ユーザーを一同にまとめて 報告/管理するのには (あまり)向いていない。 16 わかったこと
  17. 17. 17 2.ビッグプロジェクト失敗事例 では、続きまして、、、
  18. 18. ビッグプロジェクトは関係者が さらに多くなります。 18 とあるサイトのリニューアルプロ ジェクトの事例ですが、 コミュニケーションマップは さらにカオスに!!
  19. 19. スケジュールツール(Brabio) 頭おかしいと思います よね? 私もそう思います。 19 クライアント上長 代理店 内勤系担当者 クライアント IT系担当者 プログラマー 運用担当 デザイナPM 制作サイド クライアントサイド 制作進行/全体スケジュール管理用バックログ 開発/テスト管理用バックログ アナログ報告書(週次報告書、課題管理表、スケジュール、説明用パワーポイント、案件サマリー) クライアント マーケ系担当者 クライアント 広報担当者 代理店 広告系担当者 案件共有用バックログ 案件共有用バックログ クライアント 法務担当者 ベンダー内部バックログ 運用差分吸収用 スプレットシート SE 外部ベンダー等 ディレクター
  20. 20. 膨大な コミュニケーション コストが発生 20 PJで起きたこと
  21. 21. →お金で解決 →マンパワーで解決21 どうやって解決したか 膨大な コミュニケーション コストが発生
  22. 22. 22 3.グローバル案件失敗事例 最後も胸やけしそうなので簡潔に
  23. 23. 国をまたいだプロジェクトは さらに複雑化します。 その結果(以下略) 23
  24. 24. ビッグプロジェクト案件失敗事例 ~原因&結果編~ ここは迷宮かな?24 クライアント上長(日本 代理店 サイト制作担当者 クライアント サイト担当者 ディレクター デザイナ PM 制作サイド クライアントサイド アナログ報告書(週次報告書、課題管理表、スケジュール、説明用パワーポイント、案件サマリー) クライアント マーケ系担当者 クライアント 広報担当者 代理店 営業担当者 クライアント 法務担当者 海外制作会社(LA) クライアント 海外支社 クライアント上長(海外 クライアント IT部門担当者 制作進行/全体スケジュール管理用バックログ(日本語) メールとパワーポイント(日本語、英語) テスト管理用バックログ (英語) テスター SmartSheet スプレッドシート(英語)
  25. 25. 25 今回ご紹介した3事例は全て同 じ課題がベースにあります おさらい①
  26. 26. プロジェクトが大型化すればす るほど、関係者は多くなり 26 おさらい②
  27. 27. それぞれが求める 情報の粒度は異なります 全チケットを把握しないと プロジェクト全体管理でき ないし! 自分のチケットはきっちり 把握! 進捗どうですか? 飲みに行くけど なんか問題あったら呼んで 27 おさらい③
  28. 28. その解消/同期には莫大な コミュニケーション労力が必要 28 おさらい④
  29. 29. これらの解決方法は? 29
  30. 30. お金で解決 正直無駄ですが、 現状ではこれでしか解決できない プロジェクトがあることも事実です。 30
  31. 31. 31 ありがとうございました
  32. 32. 32 さすがにこれだけでは アレなので、
  33. 33. プロジェクトの登録者別に 見せる情報を制限する機能や 他Backlogとの連携 (という機能追加) 制作担当 代理店 外部ベンダー クライアント 〇 〇 × 〇 〇 〇 × × 〇 × × × × × 〇 × ガント チャート 親課題 子課題 自チケッ トのみ 33 BacklogAPIでも出来るけどね…
  34. 34. ×何を見せるか? 〇何を見せないか? 34 これが コミュニケーションレイヤーの 細分化を防ぐ為の 必要なファンクションです。
  35. 35. 35 プロジェクト管理 + コミュニケーション管理 最強だよねって話でした。 が、できたら
  36. 36. 36 失敗事例とはいいましたが、 1と2の事例はちゃんと無事故で リリースしております。 ありがとうBacklog! ちなみに 3は絶賛炎上稼働中!
  37. 37. 37 こんな案件ばかりやってる私達ですが、 手伝ってもいいよ! って奇特な方がいらっしゃれば 後ほどご挨拶をさせてくださいませ。 最後に
  38. 38. 38 今度こそ本当に ありがとうございました

×