THH育てる！

かんばん RICOH IT SOLUTIONS @sandinist Tsuyoshi Maehana

失敗してますか？

成功してますか？

アジャイルしてますか？

失敗と成功

目的・目標・ゴール

達成 = 成功

未達成 = 失敗

失敗と成功

たくさんの名言がhttp://matome.naver.jp/odai/2140750220162375801

失敗は成功の素派“成功を祝うのはいいが、もっと大切なのは失敗から学ぶことだ。失敗にどう対処するかで、会社が社員の良い発想や才能をどれだけ引き出し、変化に対応していけるかがわかる。どんな会社にも、ミス

をして、それを最大限活かしたことのある人が必要だ”

~ ビル・ゲイツ

“何かをしようとした時、失敗を恐れないで、やってください。失敗して負けてしまったら、その理由を考えて反省してください。必ず、

将来の役に立つと思います。”

~ イチロー

失敗なんてアタリマエ派

“一度も失敗をしたことがない人は、何も新しいことに挑戦したことがない人である” ~ アルバート・アインシュタイン

失敗してなんぼ派“チャレンジして失敗を怖れるよりも、何もしないことを怖れろ”

~ 本田宗一郎

“失敗は必要なのです。むしろできるだけ早く、失敗するほうがいいでしょう。小さな失敗を積み重ねることによって、成功が見え

てきます” ~ 柳井正

負けなきゃ勝ち派“私の最大の光栄は、一度も失敗しないことではなく、倒れるごとに起きるところにある。私の仕事は失敗の連続であった”

~ 本田宗一郎

“世の中に失敗というものはない。チャレンジしているうちは失敗はない。諦めた時が失敗である”

~ 稲盛和夫

“失敗したところでやめるから失敗になる。成功するまで続けたら、それは成功になる”

~ 松下幸之助

失敗なんてないんだよ派

“わたしは今までに一度も失敗をしたことがない。電球が光らないという発見を、今まで二万回したのだ”

~ トーマス・エジソン

成功と失敗失敗 → 経験・学び → 成功

素早く、小さく、失敗する

諦めない

失敗なんてない

プロジェクト、チーム、組織、人生

アジャイル

agile /ǽdʒ(ə)l|ǽdʒaɪl/ 形容詞 1 すばしこい, 身軽な, 敏捷（びんしよう）な. 2 (頭の)回転が速い, 賢い. 3 活発な, 生き生きとした.

アジャイル

形容詞

状態

× Do Agile ◯ Be Agile

度合い

アジャイルソフトウェア開発

ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称

名詞

私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、

契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。

2001年 アジャイルソフトウェア開発宣言

http://agilemanifesto.org/iso/ja/

Kent Beck Mike Beedle

Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler

http://agilemanifesto.org/iso/ja/

James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick

Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

© 2001, 上記の著者たち この宣言は、この注意書きも含めた形で全文を含めることを条件に

自由にコピーしてよい。

・顧客満足を最優先し、 価値のあるソフトウェアを早く継続的に提供します。

・要求の変更はたとえ開発の後期であっても歓迎します。 変化を味方につけることによって、お客様の競争力を引き上げます。

・動くソフトウェアを、2-3週間から2-3ヶ月という できるだけ短い時間間隔でリリースします。

・ビジネス側の人と開発者は、プロジェクトを通して 日々一緒に働かなければなりません。

アジャイル宣言の背後にある12の原則

http://agilemanifesto.org/iso/ja/

・意欲に満ちた人々を集めてプロジェクトを構成します。 環境と支援を与え仕事が無事終わるまで彼らを信頼します。

・情報を伝えるもっとも効率的で効果的な方法は フェイス・トゥ・フェイスで話をすることです。

・動くソフトウェアこそが進捗の最も重要な尺度です。

・アジャイル･プロセスは持続可能な開発を促進します。 一定のペースを継続的に維持できるようにしなければなりません。

アジャイル宣言の背後にある12の原則

http://agilemanifesto.org/iso/ja/

・技術的卓越性と優れた設計に対する 不断の注意が機敏さを高めます。

・シンプルさ（ムダなく作れる量を最大限にすること）が本質です。

・最良のアーキテクチャ・要求・設計は、 自己組織的なチームから生み出されます。

・チームがもっと効率を高めることができるかを定期的に振り返り、 それに基づいて自分たちのやり方を最適に調整します。

アジャイル宣言の背後にある12の原則

http://agilemanifesto.org/iso/ja/

アジャイルソフトウェア開発

4つの価値を大切にし

12の原則を実現に向かう

そのためのやり方？

Not 方法論・プロセス

方法論というにはあまりに構造に欠けている

スクラム

かんばん

ふりかえり改善フレームワーク

http://alistair.cockburn.us/The+end+of+methodology

アジャイルソフトウェア開発

4つの価値を大切にし

12の原則を実現に向かう

集団が育つための枠組み

http://www.versionone.com

スクラム

����� ���

����� ���

4-=�0.<9

^Qf ==�0Ci�-?.=:?5

イベントと成果物

2-4週間

24時間

�������

����������

��������

07=?5

2011年10月24日月曜日

1～4週間

3@&!+��-� E\'�8

$!=86$%�

/� )��^5`�3

n%�3BKF:;7/�&_&ou|

s��2q`��2

制約内で価値の高いプロダクトとなるように要求を出す

要求をちゃんと意味のある成果物として提供し続ける

ちゃんと円滑に仕事のやり取りができるようにする

s��2q`��2

1911年10月24日月曜日https://speakerdeck.com/nawoto/summary-of-scrum-guide

育てる！かんばん

RICOH IT SOLUTIONS @sandinist Tsuyoshi Maehana

• Tsuyoshi Maehana @sandinist

• at Work: C# -> Ruby -> Objective-C

• 基幹系業務システム開発 • リコー北海道 2003~2009

• Web αサービス開発

• iOS App 開発

大きな組織• 株式会社リコー 1936年2月6日 設立

• 連結売上高 2兆1,956億円　（2014年3月期）

• 連結対象子会社・関連会社 223社（2014年3月31日現在）

• 連結従業員数 108,195名　(2014年3月31日現在）

• リコーITソリューションズ株式会社

• 従業員数 923名（2014年7月1日現在）

http://jp.ricoh.com/company/data/

https://theta360.com/

2009 2015Team

オンラインストレージ Web/iOS

その他 iOS/Server

RICOH THETA iOS

2009 2015Team

2名 6名+1+1

+1 +1-1+2 -1

5名

2009 2015Team

2名 6名+1-1+2 -1

5名

・全体では6~10チームの大きなチームの内のひとつ ・プロセスや進め方は時とともに変化し続けている

・XP, Scrum, Lean, Kanban

+1+1

+1

・主担当のコンポーネントはあるが横断的 ・各チームが開発を完了させる

・開発基盤や運用保守のチームもある

大きなチーム大きな仕事

リコーITソリューションズ株式会社リコーITソリューションズ株式会社

前鼻毅前鼻毅

大規模アジャイル開発のいま

大きなチーム大きな仕事

http://www.flickr.com/tahosock/

アジャイルソフトウェア開発セミナー2013 in 札幌Aug, 8 2013

要求元 開発チーム

構造

大きな要求の一覧を一緒に作る

構造運用監視 インフラ

開発 品質

UX 技術調査

企画

マーケ

PO

PO

L

構造運用監視 インフラ

開発 品質

UX 技術調査

企画

マーケ

PO

PO

L

TL

TL

TL

TL

TL

TL

大きな要求

チームの作業

1ヶ月

デモ

2週間

https://www.atlassian.com/

EMLauncherirc

2009 2015Team

オンラインストレージ Web/iOS

その他 iOS/Server

RICOH THETA iOS

2014/4/15 物理かんばん導入

タスク管理の変遷• Excel

• 影舞

• Trac

• Pivotal Tracker

• JIRA

https://www.atlassian.com/

かんばん•Icebox•ToDo•Doing•Deliver•Accept

ポイント

• 大きな組織の中、複数のチームが協働

• プロダクト・サービスのライフサイクルより長いチーム

• いわゆるアジャイルな開発をふつうに行っている環境

かんばん

http://limitedwipsociety.ning.com/photo/formula-kanban

http://leansoftwareengineering.com/ksse/scrum-ban/

かんばん

• リーン生産方式におけるカンバン（TOYOTA方式）

• 物理的なタスクボードを指すカンバン

• ソフトウェア開発手法としてのカンバン方式（Kanban）

かんばん方式

• スーパーマーケット方式

• 顧客の必要とする品物を、必要なときに、必要な量だけ在庫

• ジャストインタイム

• 顧客である後工程が、必要な部品を、必要なときに、必要な量だけを前工程に取りに行く

かんばん方式

http://www.toyota.co.jp/jpn/company/vision/production_system/just.html

かんばん方式

http://www.toyota.co.jp/jpn/company/vision/production_system/just.html

物理的なボード自体

かんばんシステム

• David J. Anderson によって纏められた理論

• “一言でKanbanを言うのは難しいが、2009年10月時点では、ソフトウェア開発のフローを見える化し、WIP(Work in Progress=仕掛)を制限することで、顧客価値のスループットを上げ、同時に改善を促す活動” ~ 平鍋健児

• “文化的変革がおそらく最大の利点である” ~ David J. Anderson

かんばんシステム

• 既存のプロセス（バリューストリーム）からスタート

• プロセスの変更を強制しない

• 量を制限し、流れを良くする

• フローと計測から、問題が可視化される

• 改善機会を増やせる

David J.Andersonhttps://www.flickr.com/photos/jimdo_com/8537959610

David J.Andersonhttps://www.flickr.com/photos/jimdo_com/8537959610

Nov. 2009

https://www.flickr.com/photos/jimdo_com/8537959610

Nov. 2009

Sep. 2014 David J.Anderson

2009 2015

オンラインストレージ Web/iOS

その他 iOS/Server

RICOH THETA iOS

2014/4/15 物理かんばん導入

2014年4月

導入の目的

• 可視化のさらなる向上 • タスクの流れの整理、調整 • 異常発見を容易に • 状態の追加、調整 • 計測を簡易に行う仕組みの導入

2014年5月

イテレーションの情報追加 バグレーン廃止

狙い・理由

• イテレーションの残日数と完了項目数を追加

• イテレーションゴール達成できるかどうかを考えやすくする

• バグを区別して管理する必要がなかった

• ふつうの課題と同じように対応する

2014年7月

Doneレーンを追加

ParkingLotを廃止し、Assignのレーンを追加

狙い・理由

• チームの作業が完了していることを明示するためにDoneレーンを追加

• 次の作業担当を決めることが多かったので、プロセスにあわせて調整

2014年10月

エピックレーン、ドッグフード、リリース待ちを廃止

Blockレーンを追加し、ParkingLot復活 現在のイテレーションレーンを拡大

狙い・理由

• 物理かんばんは完全にチームのもの

• チーム境界とかんばんが一致するように調整した

• 優先度が高いが、ReadyになっていないものをあらわすためにBlockレーンを追加

• 中断されている、棚上げにしていることを明示するためにParkingLot復活

半年間 ここまでのまとめ

物理かんばんの利点

• 可視性

• 常にある、視線を向けるだけで見える

• 異常がすぐに分かる（物理的制約がある）

• プロセスが全員に明確に伝わる

• 他のチームにも否応なく見える

物理かんばんの利点• 可変性

• 皆の目の前で動かせる

• 調整しやすい

• ベースとしての役割

• 集まる場所

• チームの一体感

物理かんばんの欠点

• 場所をとる

• そこにいないと見えない

• 電子と二重管理になる

• 会社の決まり事との戦い

二重管理

• DRY原則

• 役割が違った

• ストックとフロー

• パッと見で必要な情報と、伝えるためや残しておくための情報は違う

導入の結果

• 可視化のさらなる向上 → ◯ • タスクの流れの整理、調整 → ◯ • 異常発見を容易に → ◯ • 状態の追加、調整 → ◯ • 計測を簡易に行う仕組みの導入 → ◯

導入の結果• 可視化のさらなる向上 → ◯ • タスクの流れの整理、調整 → ◯ • 異常発見を容易に → ◯ • 発見した異常への対処 → △

• 状態の追加、調整 → ◯ • 計測を簡易に行う仕組みの導入 → ◯

• 計測した結果の活用 → △

かんばん本読んだ

かんばん本との比較• ① 品質に集中する

• 低い品質は最大のムダ、失敗のコスト

• ある程度できてる

• ② 仕掛りを減らす • リトルの法則、仕掛りが増えるとリードタイムが長くなる • 作業の割り込みや切り替えはムダ • もともと一人基本1つで、最大2つまで

• ③ デリバリーを頻繁に行う

• 顧客から信頼を得る

• 頻繁なリリースは品質を高める、暗黙知の劣化を防ぐ

• 定期的なリリースはできているが、毎イテレーションではない。内部リリースコストは安いが、外部リリースのコストが高い

• ④ 要望とスループットのバランスを取る • ゆとりをつくる、たゆまぬ改善を行えるように • 戦略的なリリース物で手一杯になることも

かんばん本との比較

• ⑤ 優先順位をつける

• ビジネス価値の最適化

• 優先順位は顧客と調整できている。ビジネス価値の最適化までは出来ていないのではないか。リリース後の計測をビジネス判断に活かしきれていない。

• ⑥ ばらつきの要因を解消する

• 上級のテーマ、予測可能性を向上する

• ばらつかないことなど無い

• 書籍の例は保守サービス

かんばん本との比較

2014年12月

優先度別レーンの導入（Planed, Normal, Free） 担当をレーンからマグネットへ

課題タイプの見直し（Story, Chore, Fix, Kaizen） 計測方法の見直し

目的• 生産性の向上 • ムダの削減（Fix, Choreを下げる） • 優先度や課題タイプごとの実績を計測する • 計測結果から改善を行っていく • 改善活動を行いやすくする

• デリバリリズムをつくる • リリースコストを下げる

背後にある考え

• かんばんの3種の改善機会

• Theory of Constraints (Eliyahu M. Goldratt)

• ‘Lean’ and ‘Toyota Production System’

• ‘Profound knowledge’ (W. Edwards Deming)

TOC

• The Goal 1984

• 制約条件の理論

• ボトルネックを識別し、管理することによって、全体のスループットを向上させる

• かんばんの一連の流れから、制約になる資源を見つける。制約にプロセスを合わせる、補強する。

Lean & TPS

• ムリ・ムダ・ムラの削減

• コスト削減の部分最適に偏るのは間違ったリーン（アンチパターン）

• 全体最適、価値の最適化

リーンの経済モデル

失敗のコスト、取引コスト、調整コスト

その活動はコスト？

• 「この活動が本当に価値を付加するとして、そのための時間を増やすべきだろうか？」

• 答えがNoならそれは、必要なムダか、不要なムダのどちらか

Profound Knowledge

• W. Edwards Deming

• 20世紀で最も偉大な経営科学者としばしば言われる

• 統計的プロセス制御(SPC)から品質保証、経営科学まで

• かんばんの基礎では、ばらつきがパフォーマンスに与える影響について取り上げる

ばらつきについて at かんばん本

• Walter A. Shewhart

• 偶然原因によるばらつき 内部要因

• 不可避原因によるばらつき 外部要因

• 内部要因によるばらつきを改善する

• 作業項目のサイズ、タイプ、優先度の分類を分けて管理・計測することによって、ばらつきによる影響を分けて捉える

Joy of Work

• 吉田耕作

• デミング博士の直弟子、世界に10人に満たない、デミング／マスターのひとり

• 日本に Total Quality Management (TQM) を広めている

ばらつきについて at Joy of Work

• 異常原因のばらつき

• 原因をつきとめ、是正する必要がある

• 偶然原因のばらつき

• 広範囲の問題、トップマネジメントの責任

ビーズの実験• 4000個の白いビーズと1000個の赤いビーズを1つの箱のなかに

• 1回に50個ビーズをすくい上げる、これが1日の生産量と考える。4日間繰り返す

• 赤玉3個以下という目標はどんなに逆立ちしても偶然でしか得られない。目標はむしろモチベーションを下げる

• 個人個人のパフォーマンスの最大の要因は、偶然以外の何者でもない

• パフォーマンスはシステムによって決められており、個人としてはどうすることもできないものが多い

2015年3月

課題タイプの再見直し 計測方法の再見直し

優先度別レーンから目的別レーンへ

狙い・理由• 課題タイプの再見直し、リーンのコストモデルと統一

• 計測を書く課題タイプごとにし、優先度別に見るのは止める

• 優先度別レーンによって、仕事の詰まり具合は可視化されたが、ばらつき別の管理にはあまり効果が感じられなかった

• 優先度よりも目的別（後述）を管理対象の優先においた

課題タイプ1• 価値（青） • この課題が完了すると価値が生まれるもの • 複数に分割されている場合もある • 例：機能リリースに関する課題

• 改善（緑） • コストを下げるための出来る活動、チームが嬉しい活動

• 例：CI環境構築、リリースをラクにするための活動、モヤっとをスッキリにする活動

• 失敗コスト（ピンク） • なんらかの失敗に対して必要となってしまった作業 • 例：バグ対応、技術的負債の返却

• 取引コスト（黄色） • 直接価値は生まないが、届けるために必要な作業 • 例：リリースのための作業、レビュー、プラットフォームのアップデート対応

• 調整コスト（オレンジ） • 課題を進めるために必要になる活動 • 例：事前に検討が必要な設計、技術調査、デザイン依頼、会議招集、外部チームとのやりとり

課題タイプ2

• Business レーン • ビジネス・POの視点・機能・AWC

• Development レーン • コード・技術・開発チームの視点

• Kaizen レーン • チームプロセス・やると嬉しい事・気になることをスッキリさせる・SMの視点

目的別レーン

• 朝会で1日1改善を話す • よかったことを褒める • ちいさな改善を継続的に

• Kaizenレーンを使う • 気になることや、やったほうが良いことを残す • 取引コストや調整コストを下げる活動を行いやすく

プチ改善

背後にある考え

https://speakerdeck.com/nawoto/talk-about-agile-at-developers-summit-2015

技術的負債

https://speakerdeck.com/kentaro/rethinking-technical-debt

意図的な負債は 失敗コストではなく 改善の活動にする （そのほうがモチベも 上がりやすい）

目的→結果（中間報告）• 生産性の向上 • ムダの削減（Fix, Choreを下げる）→ △ • 見なおしの観点、機会は増えた

• 優先度や課題タイプごとの実績を計測する → ◯ • 計測結果から改善を行っていく → × • その時やる課題やばらつきに大きく左右される、長いスパンで計測する見る必要がある

• 改善活動を行いやすくする → ◎ • デリバリリズムをつくる → △ • リリースの工数削減中、もうすこし！

まとめ

• 失敗と成功はひとつながり。成功はひとつじゃない

• かんばんは既存プロセスがベースなので、はじめるのが怖くない

• 自分たちで工夫し、改善していく文化を育てやすい

• かんばんを育てる過程と背後にある考え方について示した

• 改善の3つの機会

• ビジネス側面、技術的側面、チーム環境の側面 それぞれが、ともにすべて大切

多くの現場でより良いやり方を育てる助けに

学びを持ち寄って、楽しく、いきいきとさらなる学びへ

Fearless Start with Kanban to Change the World.