Backlog World 2019 見聞録 (2)

“Backlog World 2019”参加レポートのつづき（2回目）です。
1回目はこちら

小さなチームの全員マネジメントな日常

株式会社IDOM 守屋 慧さん @shigeshibu44
自社Webサービスの開発チームに在籍、長野県在住リモートワーカー

スクラムイベント
・デイリーイベント（朝・昼・夜）
　おおよそ２時間ずつのタイムスロットで実施
・ウィークリーイベント
　ふりかえり

リーダーになってから
・ボードの荒廃
・ボードにないタスクの実施
が発生

　リーダーも開発タスクを抱えて、チーム全体が忙しくなってくるとこれはありがち
　うちでは複数拠点のチームでは拠点を超えた朝会はやっていません。私の力不足もありますが、他の拠点にもプロジェクトマネジメントやスクラムに興味を持つ人がいればSkypeを使って朝会ができるのでしょうが

なぜ？
・情報の集約と分配が不適切だった（前任リーダーは情報の集約と分配をしてくれくれていた）
・スクラムへの理解が浅かった
→ 自分の無力さを悟り、本を読んだり勉強会に参加する

やったたこと
・スプリント期間 2W → 1W
・情報共有のためBacklogをきちんと使い始める
・計画と実績の見える化　少しずつ粒度を細かく

学んだこと
・何もない状態から何かをやれば改善できる
・きちんとツールを使うといろいろとツールが教えてくれる（見える化してくれる）

さらにやったこと
スクラムマスター研修に参加
・物理スクラムボード復活
・アジャイルな見積もりの導入　プランニングポーカー
・リファインメントの導入
・バーンダウンチャートの作成　手書きでホワイトボードにプロット

現れた効果
・定量化が進んみカイゼンの意欲が向上
・ミーティングが活性化
・業務フローの見直し
・モブ・ペアワークの威力で業務効率アップ

　メンバーの意識が変わったとうことは、活動によってひとりひとりが効果を実感できたからなのでしょうね。ペアプロは一見倍の工数がかかりそうですが、そんなことはないとのこと。属人化を防ぐ意味でも効果がありそうです。

まとめ
最近はカイゼンが頭打ちになっている
・上手くいっても状況が変われば、さらなる変化が必要
・変化に気づくために全員でアンテナを張る

　うまくいっていなくてもカイゼンできる実例で、守屋さんはリーダーでありながら普段はリモートワークだそうで、そういう点でも心強くなる発表でした。

Backlogでわかる炎上の見分け方、消し方

株式会社オルターブース　COO 藤崎優さん JAWS-UG 福岡コアメンバー

大量（約500）のチケットを発行して開発をスタート
受託開発で顧客と共にアジャイル開発を行うため、全体像も要件もかたまっていない。それでも、チケットを発行する。

そのためにやること
案件の作業量の見える化の作業
・最初に想定しうる作業をすべてチケット化する
・不要になるチケットもある
・追加されるチケットもある
・１〜３日作業量が１チケット
・決まっていなければ空のチケットをつくる

良い点
スタート時点でのゴールを共有できる
・初期の段階で、開発機能の調整ができる
・機能を削るか、想定した要因から追加を行うか
・日々の作業の見える化
　お客さんにも日々の作業の流れを見てもらう

炎上が起こるの大きな要因
・受注側と発注側のゴールの認識のずれ
・機能開発におけるボリュームがわからない
作業量を見える化しておくことで、追加・変更が起こった際のトレードオフの議論がスムーズになる

顧客が得られるもの
・作業量の可視化・見える化による安心感
・柔軟な対応による満足感
・トレードオフが発生した際の納得感

これで大体問題が起こりそうなことを事前に交渉できる！
炎上の見分け、消しができる！

でもこれは顧客の主要メンバーにBacklogに私事として参加してもらう必要がある。

案件におけるBacklog利用の徹底
・メールは使わない
・対応・要望は全部チケットに書く
・ダブっても構わない

チケット作成ルールの明確化
・１チケット１作業
　複数の作業をメールのように書くと終わらないチケットになってしまう
・顧客はメールのように長く書きがち
　初期は我々でチケットを分割する
　慣れてくれば自然とそのようになってくれるようになる

両者ともどんどんチケットに追加して記録を残すことを重視する

チケットの整理は？
・週一でお客様とのＭＴＧ　その前に整理している（チケット整理担当）
・スケジュール（ガントチャート）を見て、遅れている理由をチェックして、必要な再設定する
・スケジュールはマネージメントが作る

500ものチケット登録は？
・Googleスプレッドシートに記入して、流し込む

電話は？
・無視できない

メール通知は？
・お客様にはメール通知あり
・開発にはメール通知なし、Slackに流す
　名前を書くことでメンションを飛ばす

　炎上の二つの要因はその通りだと思います。炎上を防ぐための特効薬はなく、そのカギは、とにかくありったけの作業量を事前に出しておいて、開発着手後はそれ以上増やさないようにするというふうに理解しました。
　付き合いの長いお客様で、期間の長い案件の見積りで工数を見積って出すのですが、お客様の予算の関係で減額要求があり、こちらも受注したいし、工数は概算で出している関係もあって、要求を飲んでいます。このやり方をやってみたいものです。

カスタマー・リレーションとエンジニアをつなぐBacklog

株式会社オミカレ UX Developer 普段はおかやまにて勤務　前川昌幸 さん @maepon

発表資料

コミュニケーションにはたくさんのツールを使用
slack　社内
chatwork 対カスタマー
esa　Markdownが使えるドキュメント共有ツール
Backlog → GitHub 基本的に 1:1 （1:2〜3になることがある）

部門ｘ拠点＋コンサル・パートナー間のコミュニケーションのお話
いろいろなツールを使い分けていますが、それぞれで発生する料金を用立てられるのはスゴイなと思いました。
chatworkはシンプルなチャットなので顧客とのコミュニケーションにはいいと思います。Markdownが使えるesaは興味があります。今日の発表を通して、Microsoft Teamsが出てこなかったように思います。

（つづく）