Kanban! お客さんの視点に立ったアジャイルなやり方

Kanban!お客さんの視点に立った

アジャイルなやり方

2011/12/13 @ PASONA TECHShibuya.trac #13

1

2011年12月10日土曜日

何者？

@kompiro こんぴろこと近藤寛喜と申します。

Change Vision.Inc,のエンジニア

アジャイルコーチではありません。

チームを率いるリーダーでもありません。

1プログラマでござる。

とある事情でKanban本の翻訳に携わってます。

時間がかかってすみません。

Tracに出戻りました。2


Kanban本とはこれ。

3


Kanban本の著者

David J.Anderson師

@agilemanager

Lean & Agile

日本に何度かいらしてます

元々はTOCの人みたい

4


なので、

翻訳中なので意図的に最近のAgile本を読んでません。

翻訳がブレるのを防ぐため。

最近のScrumは良く知りません。

一応5年前に2年くらい実践してました。

会社を代表して話をしている訳ではありません。

Kanbanを全て実践している訳でもないです。

5


今日お伝えしたいこと

Kanbanってなに？

見積に関するお話

この先は時間があればやります。

プロジェクトのゆらぎとサービスクラス

お客さんの視点に立ったプロジェクト運営とは？

6


Kanbanの解説に入る前にいくつか質問を

7


http://www.flickr.com/photos/oregondot/4132135156/sizes/o/in/photostream/

Scrumを知っていた人？

8








Scrumをやったことがある人？

9








プランニングポーカーが大好きな方？

10








プロジェクトに作業見積がないなんてありえない!?

11







どーん！！

12


見積を無くしたら上手く行った事例あり〼。

13


後ほどとりあげます。

14


Kanbanってなに？

15



Kanbanってよく分かんない方？

16







Kanbanとは？

17

アジャイルな開発のやり方の一つです。

今から簡単な例を使って見ていきましょう。

登場人物は

お客さんはTwitterのクローンを作りたい！と考えていた・・・。


実現したい機能はこんな感じ

18


これをKanban Systemを使って開発します。

19


最初にお客さんが3つ選びます。

20

選ぶ


開発スタート

21

作業をPull


WIP制限

22

一度に3つの作業は行えない


作業が完了（DONE）していれば次の作業へ

23

完了

作業をPull


空なので作業を補充

24

選ぶ


テストでバグ見つかる

25

戻す

作業できないので赤札に


テストでバグ見つかる

26

戻す

作業できないので赤札に

WIPオーバーなので赤札優先


フローが安定してきた

27


フローが安定してきた

28

なかなか補充されない


WIPが空いたので改善

29


DONEが溜まったのでリリース

30


フィードバックを次のキューへ

31


Kanban用語ケイデンス

32

補充→リリースの回数


Kanban用語リードタイム

33

補充→リリースまでの平均時間


Kanban用語スループット

34

補充→リリースできた量


見積りを無くしたら上手く行ったプロジェクト編

35


某M社の事例

36

アメリカに本社を置く最大手の某M社

2004年のことでした。

CMMI Lv5のインドのソフトウェアベンダを下請け

お願いした仕事は完璧に仕上がります。

定義した通りに仕事が納品され

品質は最高でした。

でもこのプロジェクト、社内の評判は最悪でした


最悪のプロジェクトとなぜ言われたのか？

リードタイムとスループットが最悪

要件定義から納品まで5ヶ月（リードタイム）

1月あたり、7個の要件を解決（スループット）

欲しいと思った機能が届くのが半年後

しかも、できあがる量が少ない

37


原因（1）作業割り込みが多い

製品マネージャからの割り込みが多かった

見積り依頼の割り込み

要求が産まれると見積りが依頼された。

その度に開発作業を中断した。

仕様書変更の割り込み

テスト時の検証のため

38


行った対策（1）

仕掛かり中(WIP)の仕事を制限した。

開発者は作業を完了するまで次の仕事に手をつけないようにした。

仕事の流れの整理を目的にしていた。

要求が届く→開発する→仕様書修正→テスト

手元の作業が無くなったら新たに仕事に手をつける、プル型の開発にやり方を変えた。

要求を一時的に溜めるキューを用意した

バックログのように要求を全部つっこむのではなく、依頼者が空になるタイミングで追加

39


これはいわゆるKanbanと言われるやり方

40


原因（2）

定義した要件をインドに見積を依頼

インドからは48時間以内に返答

インド側はできる限り正確に返答していた。

ただし、仕事時間の3割以上が見積りに

41


行った対策（2）

見積りを止めさせた

ただし、投資対効果の計算に問題がありそう

直感で15日以上かかりそうな要求には連絡を求めた

どの要求も25日以内にリリースするように保証を求めた

42


実績

43

リードタイム

0 37.50 75.00 112.50 150.00

対策前対策後

スループット

0 7.50 15.00 22.50 30.00

対策前対策後

3倍以上 9割削減2011年12月10日土曜日

そんでもってバックログも無くなったんだってさ

44


でも僕らみたいな凡人がそんな風にはなかなか

できないよ

45


某M社の事例

46

Kanbanの最初の事例(2004年)

CMMI Lv5のインドのソフトウェアベンダを下請け

リードタイムとスループットが最悪

要件定義から納品まで5ヶ月（リードタイム）

1月あたり、7個の要件を解決（スループット）

だけど、品質は最高。

定義した通りに納品。バグはない。


僕らがこの事例から学ぶべき事

47


常識にとらわれない

48


本当に必要なプロセスか？を考えませう

49


ちなみにこの事例では

50

まずは対策を考えるために、作業の流れをスケッチに書き出しまとめてみた。

→見積りや、仕様書の修正に無駄が発生している事が可視化された。

対策を打ってみた→上手く行った（ただし15ヶ月かかった）


ここまででご質問はありますか？

51


ここまでのまとめ

52

WIPの制限と作業をプルするように運営する事がKanbanの第1原則

コンテキストスイッチを減らし、作業の流れが整理されます。

リードタイムが短くなり、フィードバックを受け付けやすくなります。

見積りは必須とは言えない場合もある。

プロジェクト管理の常識が正解とは限らない。


Kanban翻訳本レビューを受け修正中

53


ご清聴ありがとうございました。

54


と言う事で、続きましてプロジェクトのゆらぎとサービスクラスについて

55


Kanbanはなぜうまく行くのか？

56


見積→計画でうまくいかないのはなぜか？

57


プロジェクトのゆらぎとは？（1）

58

プロジェクトには「ゆらぎ」がある

例えばメンバーが

事故に遭うかもしれない

結婚してハネムーンに行くかもしれない

病気になるかもしれない

不幸な事があるかもしれない

辞めるかもしれない

等々、プロジェクトのリスクと呼ばれるもの



作業にも「ゆらぎ」がある

思ったよりサクサク進んだ。→OK

やり始めた。スマートな方法あるやん。→OK

やり始めた。考慮漏れあるやん。→NG

以前の実装がクソすぎて使えない。作り直しじゃない＞＜→NG

等々、作業の進捗と呼ばれるもの

59



作業には「大きさ」があり、ゆらぎます。

製品の特徴と言う「フィーチャやエピック」

ユーザから見た機能と言う「ストーリー」

日々の作業という「タスク」

エピックレベルだと月単位、ストーリーだと週単位、タスクだと日単位で遅れ/進みがある

60


こういった「ゆらぎ」がプロジェクトの計画を狂わして

きたのです。

61


Kanbanではこれらのゆらぎとは戦いません。

62


代わりにお客さんを裏切らないようにします。

63


それがサービスクラスの導入です。

64


飛行機のサービスを例に説明してみましょう

65


ファーストクラス

66

By garybembridge

By garybembridge

By garybembridge

専用のチェックインゲートとかありますよね


http://www.flickr.com/photos/tipsfortravellers/






エコノミークラス

67

By nekotank

シートとか全然違うじゃないですか。


シート代に対して提供サービスが異なりますよね。

68


この考えを応用したものがサービスクラスです。

69


サービスクラス毎にサービスレベルを保証します。

70


お客さんになって考えると

71

実は、納期はそれほど重要ではない場合も多い

システムの稼働が遅れると困る場合の代表例

広告を打つ日付が決まっている

外部システムと連携があれば、そちらに迷惑がかかる

etc...

それよりも、約束していた事が守られない事が腹立たしい。


「納期」以外の契約の方がお客さんにとって望ましい

事もあります。

72


その一つがサービスレベル保証契約

(SLA)です。

73

一昔前のレンタルサーバーでありましたよね


Kanbanのサービスクラスの例

74

特急クラス

締切クラス

スタンダードクラス

ブロックしているクラス

その他


クラス毎に一定期間内のサービスレベルを保証し、

契約します。

75


では、それぞれのクラスについて見ていきましょう。

76


特急クラス

即対応が必要な要求や作業に割り当てます。

何でもかんでもすぐにできる訳ではありません。

カードウォール上に唯1つというWIP制限

お客さんはすぐに必要なものを依頼できますが、依頼できるのは開発チームに唯一つ、という状態を保てます。

特急クラスがどの程度迅速に対処されるかは、サービスレベル保証契約によります。

77


締切クラス

一般に言われる「納期」とは異なります。

ここで言う「締切」は、それを守れなかった時に具体的なコストが発生する場合を指します。

例えば「確定申告」や「連携する外部システムの停止が分かっている」とか、「JavaのEOL」とか。

ペナルティがあったり、自前で脆弱性など全てサポートしていかなければならなくなったり、と言った「コスト」が発生するクラスです。

WIPは制限し辛いですが、直近の状況や忙しさが見える化されます。

78


スタンダードクラス

緊急性のない要求に対するクラス

1ヶ月など、一定の期間内にどれだけ実施されたか、スループットを測定し、保証します。

サイズによるゆらぎが起きやすいので、それぞれのサイズごと（エピック、ストーリー、タスク）にサービスレベルを保証するパターンも考えられます。

79


ブロックしているクラス

他の作業をブロックしている要因を書いたクラス

WIPが制限されているので、ブロックされると他の作業に手をつけられない。

そのため、このクラスの作業が発生すると、優先度高めに対処したくなる。

80


その他のクラス

作業者の手が空いてしまった時のための要求

例：新しいビルドツールを試す

プロジェクトの運営には必須と言えないが、投資をすることで効率化を図れそうな要求のためのクラス

81


ところでKanbanと聞くとこんなのをイメージしてたのではない

でしょうか？

82


83


カードを貼った壁をKanbanではカードウォールと

呼んでいます。

84


アナログは、視覚に訴えるのでとてもいいです。

85


86


カードに書かれた作業に注釈を追記するのも簡単

です。

87


こんな感じで、サービスクラス毎に異なる色のカードを用意し、作業を明記していきます。

88


Kanbanプロジェクトでは毎月Kanbanの運用状況をレ

ビューし、サービスレベルを保証できたか、検証するそ

うです。（未）

89


今日のまとめ

90

見積りは必須とは言えない場合もある。

プロジェクト管理の常識が正解とは限らない。

WIPの制限と作業をプルするように運営する事がKanbanの第1原則

コンテキストスイッチを減らし、作業の流れを整理する

プロジェクトにはリスクや進捗のゆらぎがある。

Kanbanではサービスクラスと契約によってゆらぎからの影響を極力避けている。


Kanban翻訳本レビューを受け修正中

91


ご清聴ありがとうございました。

92


Documents

Kanban! お客さんの視点に立った アジャイルなやり方

Kanban! お客さんの視点に立ったアジャイルなやり方