どうも、身内の音楽イベントで社会人になって初の合唱をしてきたオムそばです。
皆で歌うのって、楽しい。
前回に引き続き、JBUG主催の、Backlog World 2019 というイベントのレポートを書いていきたいと思います。
backlogworld2019.jbug.info
前回の記事はこちら
■Backlogでわかる炎上の見分け方、消し方 藤崎 優(株式会社オルターブース)
本セッションでは、課題作成作業から見えるタスク粒度や顧客とのコミュニケーションなどから炎上の見分け方、消し方、もっというと炎上する前にボヤをけすにはどうすればよいか、について、講演されていました。
以下、講演時のメモ。
- 受託開発において、プロジェクトスタート時に、約500の課題チケットを切る。
- 受託開発で、顧客と共にアジャイル開発するため、要件定義と設計・開発が並行に行われ、全体像が見えづらくなる。
- まずプロジェクトスタート時点で、案件の作業量を見える化する。プロジェクトにおいて想定しうるすべての作業を洗い出す。この時点では内容の精度はあまり問わない。不要チケットなどが発生することももちろんある。
- 案件の作業量の見える化することで、ゴールまでのボリュームが見える。この時点ですでに想定リリース日をオーバーする見積もりがでることもある。しかし、初期段階でそれが見えているため、顧客との調整がしやすい。絶対に外したくない機能や、調整可能な機能などを取捨選択することができる。
- Backlogで日々の作業の見える化をすることで、クライアントに安心感を与える。
- 炎上が起きる大きな原因は二つ。「受託側と発注側のゴール認識のずれ」「機能開発におけるボリューム感がわからない」
- Backlogで全体の作業を見える化することで、顧客側は安心感を得られる。また、柔軟に対応してくれることによる満足感や、リリースを調整した際の納得感が得られる。
- Backlogを使ってもらう際、「メールは使わない」「対応・要望は全部チケットに書く」「ダブてもかまわない」。これをすることで、記録を残しながらクライアントと調整できる。
- チケット作成ルールの明確化("1チケット1作業"など)。使い慣れていない人は、チケットを長く書きがちなので、その際は慣れている側が分割していく。
- 受注側、発注側ともにどんどんチケットに追加して記録を残すことを重視する。そうすることで、"言った言わない論"がなくなっていく。
- 質疑応答1：チケット500件以上に対し、どうさばいていくのか？放置されるものとかないのか？
⇒毎週棚卸会議を内部で行い、タスクを整理していく。除外するものはあるが、放置されるものはない。 - 質疑応答2：500以上のチケットを立ち上げる時に、1件1件手で登録しているのか？
⇒スプレットシートから一括でアップロードしている。 - 質疑応答3：メールは無視しているが、電話も無視している？
⇒さすがにとる。 - 質疑応答4：メール通知は？
⇒開発側はメール通知しない。クライアント側はメール通知する。開発側はAPIを導入し、自分が主担当になったときにSlackに通知がくるようになっている。 - 質疑応答5：お客様と共同でBacklogを使う際、お客様から抵抗はあったか？
⇒一番最初は、大量の要望が1チケットに登録され、そこに対し追加の要望が出て、いつまでもcloseしなかった。そこを分解することで改善した。あと、メール文化のところに導入する際、しつこくBacklogに登録するように促した。 - 質疑応答6：途中で想定していない問題が発生して、計画通りにスケジュールが進められなかった場合、チケットを切り直しなどをするのか？
⇒毎週スケジュールを伸ばしていくと、どの段階でオーバーするのかが見えてくるため、見えた時点で削減などの交渉に入る。
今回の全セッションの中で、一番質疑応答があったのではないでしょうか(私も質問しました)。
自分の業務に適用したくなる、Backlogの良い活用方法であると感じました。
それにしても…。
写真と別人じゃないかっ…！！(多分髪型のせい)
■カスタマー・リレーションとエンジニアを繋ぐBacklog 前川 昌幸(株式会社 オミカレ)
本セッションでは、遠隔地で一緒にリモートワークしていく中で活用しているツールについて、講演されていました。
以下、講演時のメモ。
- 婚活サイトは「オミカレ」。
- 地理的に分かれており、かつ企画や営業などとエンジニアの拠点が離れている場合のコミュニケーションのツールやルールを紹介する。
- 以下の2チームが存在する。
- カスタマーリレーションチーム(CRT)：営業、サポート、企画、マーケティング。
- エンジニア(DevT)：実装、保守、カイゼン、刷新 - 東京と岡山に2拠点ある。フレックスタイム制、リモートあり。
- 活用しているツールは6種類(Backlog、Slack、G Suite、Chatwork、Github、esa)
- Slackでは、とにかくなんでも書く、システムアラートも届く。隣同士でもSlackでやりとりする。
- Chatworkでは、コンサル・パートナーとのテキストコミュニケーションに使っている(心理的安全性の面や、相手側の使用頻度に合わせて)。
- GSuite でスケジュール管理など。
- Github ソースコード管理
- esa では、開発チームのドキュメント共有。Markdownで簡単に書ける。日報、議事録、メモ、手順書などに使う。
- 社外との情報共有はBacklogのwikiを使う。
- Backlogでは、社内/社外のタスクを管理している。
- 社内外のタスクはすべて集約し、誰が持っているかを担当者にちゃんと割り振る。
- 週に一度「Backlogグルーミング」をする(リーダーがチェックする)。
- エンジニア属性は、GithubのIssueでいいんじゃない？と思っている人もいると思うが、オミカレでは、ビジネスベースの課題をBacklogに、実装ベースの課題をGithubで明確に分けている。そうすることで、DevTはエンジニア語でissueを書くことができる。
BacklogとGithubのissueの共存のさせ方や、Backlogグルーミングというネーミングはぜひ現場で活用させたいと思いました。
課題の流れ。
次回が最後のレポートになると思います。
ではまた。
※記事中に不快な言い回しや、誤った表現などございましたら、遠慮なくご指摘ください。
