Exercise Backlog 1

バックログの話 前編

まずは自己紹介

あんただれ

レベル： しょくぎょう： しょうごう：

28 プログラマ

はいぱーれがしー こーどくりえいた

こんにちは

マネジメントの話

詰将棋やるよ

将棋知っている人

挙手！

どう動かす？

これ盤ね

ちょっと変えるよ

三手詰めね

これだと？

ヒント：初手は馬

初手はこれ

おや？

バラバラだった 意見が一つに

ほとんど指示なしで

とりあえず解けた

指示は 「詰将棋やるよ」 「三手詰めね」 「これ盤面」

これだけ

問題が変わっても できるでしょう

普段の仕事も これだけ簡単なら いいのにね

詰将棋を出題するたび 「将棋って何種類 駒あるの？」 みたいに打合せは しないでしょ？

仕事って打合せ 多いよね

みんな打合せが 好きなの？

打合せは少なく抑えて

価値を出す作業を したいよね

なぜできる？

コンテクストの共有

将棋のルール 詰将棋のルール 駒の動き方 etc

前提の共有

「常に王手」 「n手で詰ませる」

目的の共有

「玉を詰めろ」

情報の共有

盤面の明示

これが 成り立たない場合

コンテクストの共有 の不成立

将棋を知らない 人間には無理

前提の共有 の不成立

王手にならない ３手で詰まない

目的の共有 の不成立

詰将棋を知らないと わからない

情報の共有 の不成立

盤面見ずに 解けない

つまり

マネジメントを 少ないコストで 回すには

ドメイン、前提、 目的、情報

の４つの共有が必要

これを分割

ドメイン、前提、大目標、情報

短期の目標

従来だと (主に90年代)

アジャイルだと (うちのチームの場合)

この２つがないと 打合せを何回も やることになる

MVPキャンパス 作らないと

迷う 止まる 迷走する

会議を何回も 開催する羽目になる

作るのは大変？

必要なコスト

そもそも

初めてやる作業って

時間がかかる ものじゃないの？

時間はかかる

MVPキャンパスは 遊びじゃない

短期の目的の管理は バックログで行う

今明かされる真実

バックログは

２つある

プロダクトバックログ

イテレーションバックログ

用途の違い 具体度の違い

プロダクトバックログ

イテレーションバックログ

フォーマット

[ユーザー]は xxするために ooする

[主語] [目的] [手段]

プロダクトバックログ

イテレーションバックログ

フォーマット

開発チームは xxのために oo機能を 実装する

[主語] [目的] [手段]

なぜ２つある？

UX品質を高く 保てるから

変化に強いから

低い

具体度

高い

長い

賞味期限

短い

低い

具体度

高い

長い

賞味期限

短い

ユーザー目線で考えやすい 変更コストが低い、変化に強い

低い

具体度

高い

長い

賞味期限

短い

実装には極限まで 具体化する必要が有る

具体度の低いログ ・ユーザー目線 ・変化に強い 状況は常に変化する ・具体化コストが低い 具体化にコストがかかる

ログの長期保存には

具体度を低くする

ところが

実装するためには 具体化する必要が有る

具体化しないと？

作業者が迷う

コミュニケーション コストの増大

作業サイズが 大きくなる

開発速度の低下

作業がブレる

作業の一貫性の低下

各人が好き勝手にやる

作業の集中性の低下

つまり

実装には具体化が必要

ユーザー要望 と

システム実装

背反する

低い

具体度

高い

長い

賞味期限

短い

User Desire

Dev Implement

低い

具体度

高い

長い

賞味期限

短い

User Desire

Dev Implement

プロダクトバックログ(長期)

イテレーションバックログ(短期)

食材のメタファ

食材の保存

食材の保存

保存は大きい単位で 行う

食べるには一口大 まで小さく切る

このまま食べる？

小さく切ると 食べる用途が決まる

すき焼き？ カレー？ ステーキ？

薄切りにした後で ステーキには 使えないでしょ？

保管は大きいサイズ

調理の寸前に 小さいサイズに 切り分ける

タスクが大きいと

作業開始前に 小さく分割する コストが発生する

タスクが小さいと

細かすぎて 管理するコストが 大きいし

あとから 実装手段を 変更できない

切り分けるのは 調理の寸前

イテレーション開始前に タスク分割

プロダクトバックログ(長期)

イテレーションバックログ(短期)

プロダクトバックログ

UX品質が高い

それはわかる

ユーザー目線 だからね

んん？

変化に強い？

ユーザー目線

イコール

変化に強い

どういうこと・・・

そこでこちら

プロダクトバックログ

イテレーションバックログ

[ユーザー]は xxするために ooする

[主語] [目的] [手段]

[ユーザー]は xxするために ooする

[主語] [目的] [手段]

大事なのはここ

[ユーザー]は xxするために ooする

[主語] [目的] [手段]

これは別のものでも良い

手段はどうでもいい

手段は変化しやすい

状況は変化するから

真実は次々に 明らかになるから

フィードバックで チームが適した

手段を学習するから

目的は変化しづらい

充足させたい ユーザーとその欲求は 変わりづらいから

それじゃあ

従来の形は

なぜ変化に弱い？

なぜUX品質が 悪化する？

なぜ変化に弱い？

従来のかたち (20世紀型)

タスク リスト

(アジャイルでこれを 使うやつおらんやろ)

手段しか書いていない

フォーマット

開発チームは

oo機能を 実装する

[主語] [目的] [手段]

開発チームは

oo機能を 実装する

[主語] [目的] [手段]

目的は明示されず暗黙的である

目的が暗黙的

誰がなんのために つかうの？

ユーザー欲求は 比較しやすいが

手段は比較しづらい

優先度がつけづらい

結果

「優先度の低い 　機能を削る」 ができない

また

チームは学習する

学習したチームは より適切な手段を とれるようになる

学習したチームは 状況が計画と異なる ことを検知できる

状況が変化し

陳腐化した 手段があっても

代替手段の用意が 簡単ではない

目的が暗黙的だから

手段を変えると

抜け漏れが 簡単に発生する

結果

変化が発生する

イコール

死亡フラグ

なぜUX品質＝悪化？

従来の形は

なぜUX品質が 悪化する？

従来のかたち (20世紀型)

タスク リスト

フォーマット

開発チームは

oo機能を 実装する

[主語] [目的] [手段]

開発チームは

oo機能を 実装する

[主語] [目的] [手段]

目的は明示されず暗黙的である

目的が暗黙的

誰がなんのために つかうの？

実装者によって ブレる

むしろ実装が 目的化する

UXが悪化しがち

納得感のある UXの検証ができない

UXの品質保証が困難

ちょっと 想像してほしい

「xx日までに 　この機能実装して」

実装する

提出

「なにこれ 　つかいづらいから 　やりなおしな！」

ハァ？

つかいづらい？ お前がそう思っている

だけだろ？

TODOリストの どこにその定義が あるんだよ

むしろ

このケースはまだマシ

レビュワー複数は 地獄

基準が暗黙的だから

レビュワーごとに UX品質がブレる

さらに

暗黙的なことは コミットとして 扱われづらい

結果

明示的な納期や工数の ほうが重視される

これが

つかいづらい システムができる理由

他にも主語が常に

開発チームは

oo機能を 実装する

[主語] [目的] [手段]

開発チーム

この画面はどんな ユーザーが使うの？

というのが

明示的ではない

迷子になりやすい UIを作りやすい

ふーん

つまり

TODOリストを捨てて

バックログに すればいいんだろ？

開発速度が遅い 打合せが多い

ユーザーに受けない 変化に弱い

これで全部解決

以上終わり