Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
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
度合い
アジャイルソフトウェア
開発
ソフトウェア工学において迅速かつ適応的に
ソフトウェア開発を行う軽量な開発手法群の
総称
名詞
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウ...
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
http://agilemanifesto.org/iso/ja/
...
・顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。
・要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。
・動くソフトウェアを、2-3週間から2-3ヶ月という...
・意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。
・情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。
・動くソフトウェアこそが進 の最も重要な尺...
・技術的卓越性と優れた設計に対する
不断の注意が機敏さを高めます。
・シンプルさ(ムダなく作れる量を最大限にすること)が本質です。
・最良のアーキテクチャ・要求・設計は、
自己組織的なチームから生み出されます。
・チームがもっと効率を高めること...
アジャイルソフトウェア
開発
4つの価値を大切にし
12の原則を実現に向かう
そのためのやり方?
Not 方法論・プロセス
方法論というにはあまりに構造に欠けている
スクラム
かんばん
ふりかえり改善フレームワーク
http://alistair.cockburn.us/The+end+of+methodology
アジャイルソフトウェア
開発
4つの価値を大切にし
12の原則を実現に向かう
集団が育つための枠組み
http://www.versionone.com
スクラム
イベントと成果物
2-4週間
24時間
1∼4週間
制約内で価値の高い
プロダクトとなるよ
うに要求を出す
要求をちゃんと意味
のある成果物として
提供し続ける
ちゃんと円滑に仕事
のやり取りができる
ようにする
1911年10月24日月曜日
https://speakerdeck.com/na...
育てる!
かんばん
RICOH IT SOLUTIONS
@sandinist
Tsuyoshi Maehana
• Tsuyoshi Maehana @sandinist
• at Work: C# -> Ruby -> Objective-C
• 基幹系業務システム開発
• リコー北海道 2003 2009
• Web αサービス開発
• iOS Ap...
大きな組織
• 株式会社リコー 1936年2月6日 設立
• 連結売上高 2兆1,956億円 (2014年3月期)
• 連結対象子会社・関連会社 223社(2014年3月31日現在)
• 連結従業員数 108,195名 (2014年3月31日現...
https://theta360.com/
2009 2015
Team
オンラインストレージ
Web/iOS
その他
iOS/Server
RICOH THETA
iOS
2009 2015
Team
2名 6名
+1
+1
+1 +1
-1
+2 -1
5名
2009 2015
Team
2名 6名
+1
-1
+2 -1
5名
・全体では6~10チームの大きなチームの内のひとつ
・プロセスや進め方は時とともに変化し続けている
・XP, Scrum, Lean, Kanban
+1
+1
+1
・主担当のコンポーネントはあるが横断的
・各チームが開発を完了させる
・開発基盤や運用保守のチームもある
大きなチーム
大きな仕事
リコーITソリューションズ株式会社リコーITソリューションズ株式会社
前鼻毅前鼻毅
大規模アジャイル開発のいま
大きなチーム
大きな仕事
http://www.flickr.com/tahosock/
アジャイルソフトウ...
要求元 開発チーム
構造
大きな要求の
一覧を一緒に作る
構造
運用監視 インフラ
開発 品質
UX 技術調査
企画
マーケ
PO
PO
L
構造
運用監視 インフラ
開発 品質
UX 技術調査
企画
マーケ
PO
PO
L
TL
TL
TL
TL
TL
TL
大きな
要求
チーム
の作業
1ヶ月
デモ
2週間
https://www.atlassian.com/
EMLauncher
irc
2009 2015
Team
オンラインストレージ
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
https://www.flickr.com/photos/jimdo_com/8537959610
David J.Anderson
https://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レーンを追加
• 中断されている、棚上げにしていることを明示するた
...
半年間
ここまでのまとめ
物理かんばんの利点
• 可視性
• 常にある、視線を向けるだけで見える
• 異常がすぐに分かる(物理的制約がある)
• プロセスが全員に明確に伝わる
• 他のチームにも否応なく見える
物理かんばんの利点
• 可変性
• 皆の目の前で動かせる
• 調整しやすい
• ベースとしての役割
• 集まる場所
• チームの一体感
物理かんばんの欠点
• 場所をとる
• そこにいないと見えない
• 電子と二重管理になる
• 会社の決まり事との戦い
二重管理
• DRY原則
• 役割が違った
• ストックとフロー
• パッと見で必要な情報と、伝えるためや残しておくための
情報は違う
導入の結果
• 可視化のさらなる向上 → ⃝
• タスクの流れの整理、調整 → ⃝
• 異常発見を容易に → ⃝
• 状態の追加、調整 → ⃝
• 計測を簡易に行う仕組みの導入 → ⃝
導入の結果
• 可視化のさらなる向上 → ⃝
• タスクの流れの整理、調整 → ⃝
• 異常発見を容易に → ⃝
• 発見した異常への対処 → △
• 状態の追加、調整 → ⃝
• 計測を簡易に行う仕組みの導入 → ⃝
• 計測した結果の活用 ...
かんばん本読んだ
かんばん本との比較
• ① 品質に集中する
• 低い品質は最大のムダ、失敗のコスト
• ある程度できてる
• ② 仕掛りを減らす
• リトルの法則、仕掛りが増えるとリードタイムが長くなる
• 作業の割り込みや切り替えはムダ
• もともと一人基本...
• ③ デリバリーを頻繁に行う
• 顧客から信頼を得る
• 頻繁なリリースは品質を高める、暗黙知の劣化を防ぐ
• 定期的なリリースはできているが、毎イテレーション
ではない。内部リリースコストは安いが、外部リリー
スのコストが高い
• ④ 要望...
• ⑤ 優先順位をつける
• ビジネス価値の最適化
• 優先順位は顧客と調整できている。ビジネス価値の
最適化までは出来ていないのではないか。リリース
後の計測をビジネス判断に活かしきれていない。
• ⑥ ばらつきの要因を解消する
• 上級のテ...
2014年12月
優先度別レーンの導入(Planed, Normal, Free)
担当をレーンからマグネットへ
課題タイプの見直し(Story, Chore, Fix, Kaizen)
計測方法の見直し
目的
• 生産性の向上
• ムダの削減(Fix, Choreを下げる)
• 優先度や課題タイプごとの実績を計測する
• 計測結果から改善を行っていく
• 改善活動を行いやすくする
• デリバリリズムをつくる
• リリースコストを下げる
背後にある考え
• かんばんの3種の改善機会
• Theory of Constraints (Eliyahu M. Goldratt)
• Lean and Toyota Production System
• Profound knowle...
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環境構築、リリー...
• 失敗コスト(ピンク)
• なんらかの失敗に対して必要となってしまった作業
• 例:バグ対応、技術的負債の返却
• 取引コスト(黄色)
• 直接価値は生まないが、届けるために必要な作業
• 例:リリースのための作業、レビュー、プラットフォーム...
• 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.
育てる!かんばん - bring up Kanban.
育てる!かんばん - bring up Kanban.
育てる!かんばん - bring up Kanban.
育てる!かんばん - bring up Kanban.
育てる!かんばん - bring up Kanban.
育てる!かんばん - bring up Kanban.
育てる!かんばん - bring up Kanban.
育てる!かんばん - bring up Kanban.
Upcoming SlideShare
Loading in …5
×

育てる!かんばん - bring up Kanban.

1,959 views

Published on

at Agile Japan 2015 Sapporo Satellite.

Published in: Technology
  • DOWNLOAD THI5 BOOKS INTO AVAILABLE FORMAT (Unlimited) ......................................................................................................................... ......................................................................................................................... Download Full PDF EBOOK here { http://bit.ly/2m6jJ5M } ......................................................................................................................... Download Full EPUB Ebook here { http://bit.ly/2m6jJ5M } ......................................................................................................................... ACCESS WEBSITE for All Ebooks ......................................................................................................................... Download Full PDF EBOOK here { http://bit.ly/2m6jJ5M } ......................................................................................................................... Download EPUB Ebook here { http://bit.ly/2m6jJ5M } ......................................................................................................................... Download doc Ebook here { http://bit.ly/2m6jJ5M } ......................................................................................................................... ......................................................................................................................... ......................................................................................................................... .............. Browse by Genre Available eBooks ......................................................................................................................... Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Cookbooks, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult,
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

育てる!かんばん - bring up Kanban.

  1. 1. THH 育てる! かんばん RICOH IT SOLUTIONS @sandinist Tsuyoshi Maehana
  2. 2. 失敗してますか? 成功してますか? アジャイルしてますか?
  3. 3. 失敗と成功 目的・目標・ゴール 達成 = 成功 未達成 = 失敗
  4. 4. 失敗と成功 たくさんの名言が http://matome.naver.jp/odai/2140750220162375801
  5. 5. 失敗は成功の素派 “成功を祝うのはいいが、もっと大切なのは失敗から学ぶことだ。失 敗にどう対処するかで、会社が社員の良い発想や才能をどれだけ引 き出し、変化に対応していけるかがわかる。どんな会社にも、ミス をして、それを最大限活かしたことのある人が必要だ” ~ ビル・ゲイツ “何かをしようとした時、失敗を恐れないで、やってください。失敗 して負けてしまったら、その理由を考えて反省してください。必ず、 将来の役に立つと思います。” ~ イチロー
  6. 6. 失敗なんてアタリマエ派 “一度も失敗をしたことがない人は、何も新しいことに挑戦した ことがない人である” ~ アルバート・アインシュタイン
  7. 7. 失敗してなんぼ派 “チャレンジして失敗を怖れるよりも、何もしないことを怖れろ” ~ 本田宗一郎 “失敗は必要なのです。むしろできるだけ早く、失敗するほうがい いでしょう。小さな失敗を積み重ねることによって、成功が見え てきます” ~ 柳井正
  8. 8. 負けなきゃ勝ち派 “私の最大の光栄は、一度も失敗しないことではなく、倒れる ごとに起きるところにある。私の仕事は失敗の連続であった” ~ 本田宗一郎 “世の中に失敗というものはない。チャレンジしているうちは 失敗はない。諦めた時が失敗である” ~ 稲盛和夫 “失敗したところでやめるから失敗になる。成功するまで続け たら、それは成功になる” ~ 松下幸之助
  9. 9. 失敗なんてないんだよ派 “わたしは今までに一度も失敗をしたことがない。電球 が光らないという発見を、今まで二万回したのだ” ~ トーマス・エジソン
  10. 10. 成功と失敗 失敗 → 経験・学び → 成功 素早く、小さく、失敗する 諦めない 失敗なんてない プロジェクト、チーム、組織、人生
  11. 11. アジャイル agile /ǽdʒ(ə)l¦ǽdʒa l/ 形容詞 1 すばしこい, 身軽な, 敏捷(びんしよう)な. 2 (頭の)回転が速い, 賢い. 3 活発な, 生き生きとした.
  12. 12. アジャイル 形容詞 状態 Do Agile ⃝ Be Agile 度合い
  13. 13. アジャイルソフトウェア 開発 ソフトウェア工学において迅速かつ適応的に ソフトウェア開発を行う軽量な開発手法群の 総称 名詞
  14. 14. 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 2001年 アジャイルソフトウェア開発宣言 http://agilemanifesto.org/iso/ja/
  15. 15. 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, 上記の著者たち この宣言は、この注意書きも含めた形で全文を含めることを条件に 自由にコピーしてよい。
  16. 16. ・顧客満足を最優先し、 価値のあるソフトウェアを早く継続的に提供します。 ・要求の変更はたとえ開発の後期であっても歓迎します。 変化を味方につけることによって、お客様の競争力を引き上げます。 ・動くソフトウェアを、2-3週間から2-3ヶ月という できるだけ短い時間間隔でリリースします。 ・ビジネス側の人と開発者は、プロジェクトを通して 日々一緒に働かなければなりません。 アジャイル宣言の背後にある12の原則 http://agilemanifesto.org/iso/ja/
  17. 17. ・意欲に満ちた人々を集めてプロジェクトを構成します。 環境と支援を与え仕事が無事終わるまで彼らを信頼します。 ・情報を伝えるもっとも効率的で効果的な方法は フェイス・トゥ・フェイスで話をすることです。 ・動くソフトウェアこそが進 の最も重要な尺度です。 ・アジャイル・プロセスは持続可能な開発を促進します。 一定のペースを継続的に維持できるようにしなければなりません。 アジャイル宣言の背後にある12の原則 http://agilemanifesto.org/iso/ja/
  18. 18. ・技術的卓越性と優れた設計に対する 不断の注意が機敏さを高めます。 ・シンプルさ(ムダなく作れる量を最大限にすること)が本質です。 ・最良のアーキテクチャ・要求・設計は、 自己組織的なチームから生み出されます。 ・チームがもっと効率を高めることができるかを定期的に振り返り、 それに基づいて自分たちのやり方を最適に調整します。 アジャイル宣言の背後にある12の原則 http://agilemanifesto.org/iso/ja/
  19. 19. アジャイルソフトウェア 開発 4つの価値を大切にし 12の原則を実現に向かう そのためのやり方?
  20. 20. Not 方法論・プロセス 方法論というにはあまりに構造に欠けている スクラム かんばん ふりかえり改善フレームワーク http://alistair.cockburn.us/The+end+of+methodology
  21. 21. アジャイルソフトウェア 開発 4つの価値を大切にし 12の原則を実現に向かう 集団が育つための枠組み
  22. 22. http://www.versionone.com
  23. 23. スクラム
  24. 24. イベントと成果物 2-4週間 24時間 1∼4週間
  25. 25. 制約内で価値の高い プロダクトとなるよ うに要求を出す 要求をちゃんと意味 のある成果物として 提供し続ける ちゃんと円滑に仕事 のやり取りができる ようにする 1911年10月24日月曜日 https://speakerdeck.com/nawoto/summary-of-scrum-guide
  26. 26. 育てる! かんばん RICOH IT SOLUTIONS @sandinist Tsuyoshi Maehana
  27. 27. • Tsuyoshi Maehana @sandinist • at Work: C# -> Ruby -> Objective-C • 基幹系業務システム開発 • リコー北海道 2003 2009 • Web αサービス開発 • iOS App 開発
  28. 28. 大きな組織 • 株式会社リコー 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/
  29. 29. https://theta360.com/
  30. 30. 2009 2015 Team オンラインストレージ Web/iOS その他 iOS/Server RICOH THETA iOS
  31. 31. 2009 2015 Team 2名 6名 +1 +1 +1 +1 -1 +2 -1 5名
  32. 32. 2009 2015 Team 2名 6名 +1 -1 +2 -1 5名 ・全体では6~10チームの大きなチームの内のひとつ ・プロセスや進め方は時とともに変化し続けている ・XP, Scrum, Lean, Kanban +1 +1 +1
  33. 33. ・主担当のコンポーネントはあるが横断的 ・各チームが開発を完了させる ・開発基盤や運用保守のチームもある
  34. 34. 大きなチーム 大きな仕事 リコーITソリューションズ株式会社リコーITソリューションズ株式会社 前鼻毅前鼻毅 大規模アジャイル開発のいま 大きなチーム 大きな仕事 http://www.flickr.com/tahosock/ アジャイルソフトウェア開発セミナー2013 in 札幌 Aug, 8 2013
  35. 35. 要求元 開発チーム 構造 大きな要求の 一覧を一緒に作る
  36. 36. 構造 運用監視 インフラ 開発 品質 UX 技術調査 企画 マーケ PO PO L
  37. 37. 構造 運用監視 インフラ 開発 品質 UX 技術調査 企画 マーケ PO PO L TL TL TL TL TL TL
  38. 38. 大きな 要求 チーム の作業 1ヶ月 デモ 2週間
  39. 39. https://www.atlassian.com/
  40. 40. EMLauncher irc
  41. 41. 2009 2015 Team オンラインストレージ Web/iOS その他 iOS/Server RICOH THETA iOS 2014/4/15 物理かんばん導入
  42. 42. タスク管理の変遷 • Excel • 影舞 • Trac • Pivotal Tracker • JIRA
  43. 43. https://www.atlassian.com/
  44. 44. かんばん •Icebox •ToDo •Doing •Deliver •Accept
  45. 45. ポイント • 大きな組織の中、複数のチームが協働 • プロダクト・サービスのライフサイクルより長いチーム • いわゆるアジャイルな開発をふつうに行っている環境
  46. 46. かんばん
  47. 47. http://limitedwipsociety.ning.com/photo/formula-kanban
  48. 48. http://leansoftwareengineering.com/ksse/scrum-ban/
  49. 49. かんばん • リーン生産方式におけるカンバン(TOYOTA方式) • 物理的なタスクボードを指すカンバン • ソフトウェア開発手法としてのカンバン方式(Kanban)
  50. 50. かんばん方式 • スーパーマーケット方式 • 顧客の必要とする品物を、必要なときに、必要な量だけ在庫 • ジャストインタイム • 顧客である後工程が、必要な部品を、必要なときに、必要な 量だけを前工程に取りに行く
  51. 51. かんばん方式 http://www.toyota.co.jp/jpn/company/vision/production_system/ just.html
  52. 52. かんばん方式 http://www.toyota.co.jp/jpn/company/vision/production_system/ just.html
  53. 53. 物理的なボード自体
  54. 54. かんばんシステム • David J. Anderson によって纏められた理論 • 一言でKanbanを言うのは難しいが、2009年10月時点で は、ソフトウェア開発のフローを見える化し、WIP(Work in Progress=仕掛)を制限することで、顧客価値のスループット を上げ、同時に改善を促す活動 平鍋健児 • 文化的変革がおそらく最大の利点である David J. Anderson
  55. 55. かんばんシステム • 既存のプロセス(バリューストリーム)からスタート • プロセスの変更を強制しない • 量を制限し、流れを良くする • フローと計測から、問題が可視化される • 改善機会を増やせる
  56. 56. David J.Anderson https://www.flickr.com/photos/jimdo_com/8537959610
  57. 57. David J.Anderson https://www.flickr.com/photos/jimdo_com/8537959610 Nov. 2009
  58. 58. https://www.flickr.com/photos/jimdo_com/8537959610 Nov. 2009 Sep. 2014 David J.Anderson
  59. 59. 2009 2015 オンラインストレージ Web/iOS その他 iOS/Server RICOH THETA iOS 2014/4/15 物理かんばん導入
  60. 60. 2014年4月
  61. 61. 導入の目的 • 可視化のさらなる向上 • タスクの流れの整理、調整 • 異常発見を容易に • 状態の追加、調整 • 計測を簡易に行う仕組みの導入
  62. 62. 2014年5月
  63. 63. イテレーションの情報追加 バグレーン廃止
  64. 64. 狙い・理由 • イテレーションの残日数と完了項目数を追加 • イテレーションゴール達成できるかどうかを考えや すくする • バグを区別して管理する必要がなかった • ふつうの課題と同じように対応する
  65. 65. 2014年7月
  66. 66. Doneレーンを追加 ParkingLotを廃止し、Assignのレーンを追加
  67. 67. 狙い・理由 • チームの作業が完了していることを明示するために Doneレーンを追加 • 次の作業担当を決めることが多かったので、プロセス にあわせて調整
  68. 68. 2014年10月
  69. 69. エピックレーン、ドッグフード、リリース待ちを廃止
  70. 70. Blockレーンを追加し、ParkingLot復活 現在のイテレーションレーンを拡大
  71. 71. 狙い・理由 • 物理かんばんは完全にチームのもの • チーム境界とかんばんが一致するように調整した • 優先度が高いが、Readyになっていないものをあらわ すためにBlockレーンを追加 • 中断されている、棚上げにしていることを明示するた めにParkingLot復活
  72. 72. 半年間 ここまでのまとめ
  73. 73. 物理かんばんの利点 • 可視性 • 常にある、視線を向けるだけで見える • 異常がすぐに分かる(物理的制約がある) • プロセスが全員に明確に伝わる • 他のチームにも否応なく見える
  74. 74. 物理かんばんの利点 • 可変性 • 皆の目の前で動かせる • 調整しやすい • ベースとしての役割 • 集まる場所 • チームの一体感
  75. 75. 物理かんばんの欠点 • 場所をとる • そこにいないと見えない • 電子と二重管理になる • 会社の決まり事との戦い
  76. 76. 二重管理 • DRY原則 • 役割が違った • ストックとフロー • パッと見で必要な情報と、伝えるためや残しておくための 情報は違う
  77. 77. 導入の結果 • 可視化のさらなる向上 → ⃝ • タスクの流れの整理、調整 → ⃝ • 異常発見を容易に → ⃝ • 状態の追加、調整 → ⃝ • 計測を簡易に行う仕組みの導入 → ⃝
  78. 78. 導入の結果 • 可視化のさらなる向上 → ⃝ • タスクの流れの整理、調整 → ⃝ • 異常発見を容易に → ⃝ • 発見した異常への対処 → △ • 状態の追加、調整 → ⃝ • 計測を簡易に行う仕組みの導入 → ⃝ • 計測した結果の活用 → △
  79. 79. かんばん本読んだ
  80. 80. かんばん本との比較 • ① 品質に集中する • 低い品質は最大のムダ、失敗のコスト • ある程度できてる • ② 仕掛りを減らす • リトルの法則、仕掛りが増えるとリードタイムが長くなる • 作業の割り込みや切り替えはムダ • もともと一人基本1つで、最大2つまで
  81. 81. • ③ デリバリーを頻繁に行う • 顧客から信頼を得る • 頻繁なリリースは品質を高める、暗黙知の劣化を防ぐ • 定期的なリリースはできているが、毎イテレーション ではない。内部リリースコストは安いが、外部リリー スのコストが高い • ④ 要望とスループットのバランスを取る • ゆとりをつくる、たゆまぬ改善を行えるように • 戦略的なリリース物で手一杯になることも かんばん本との比較
  82. 82. • ⑤ 優先順位をつける • ビジネス価値の最適化 • 優先順位は顧客と調整できている。ビジネス価値の 最適化までは出来ていないのではないか。リリース 後の計測をビジネス判断に活かしきれていない。 • ⑥ ばらつきの要因を解消する • 上級のテーマ、予測可能性を向上する • ばらつかないことなど無い • 書籍の例は保守サービス かんばん本との比較
  83. 83. 2014年12月
  84. 84. 優先度別レーンの導入(Planed, Normal, Free) 担当をレーンからマグネットへ
  85. 85. 課題タイプの見直し(Story, Chore, Fix, Kaizen) 計測方法の見直し
  86. 86. 目的 • 生産性の向上 • ムダの削減(Fix, Choreを下げる) • 優先度や課題タイプごとの実績を計測する • 計測結果から改善を行っていく • 改善活動を行いやすくする • デリバリリズムをつくる • リリースコストを下げる
  87. 87. 背後にある考え • かんばんの3種の改善機会 • Theory of Constraints (Eliyahu M. Goldratt) • Lean and Toyota Production System • Profound knowledge (W. Edwards Deming)
  88. 88. TOC • The Goal 1984 • 制約条件の理論 • ボトルネックを識別し、管理することによって、全体のスルー プットを向上させる • かんばんの一連の流れから、制約になる資源を見つける。制 約にプロセスを合わせる、補強する。
  89. 89. Lean & TPS • ムリ・ムダ・ムラの削減 • コスト削減の部分最適に偏るのは間違ったリーン(アンチパ ターン) • 全体最適、価値の最適化
  90. 90. リーンの経済モデル 失敗のコスト、取引コスト、調整コスト
  91. 91. その活動はコスト? • 「この活動が本当に価値を付加するとして、そのための時間 を増やすべきだろうか?」 • 答えがNoならそれは、必要なムダか、不要なムダのどちらか
  92. 92. Profound Knowledge • W. Edwards Deming • 20世紀で最も偉大な経営科学者としばしば言われる • 統計的プロセス制御(SPC)から品質保証、経営科学まで • かんばんの基礎では、ばらつきがパフォーマンスに与える影 響について取り上げる
  93. 93. ばらつきについて at かんばん本 • Walter A. Shewhart • 偶然原因によるばらつき 内部要因 • 不可避原因によるばらつき 外部要因 • 内部要因によるばらつきを改善する • 作業項目のサイズ、タイプ、優先度の分類を分けて管理・計 測することによって、ばらつきによる影響を分けて捉える
  94. 94. Joy of Work • 吉田耕作 • デミング博士の直弟子、世界に10人に満たない、デミング/ マスターのひとり • 日本に Total Quality Management (TQM) を広めている
  95. 95. ばらつきについて at Joy of Work • 異常原因のばらつき • 原因をつきとめ、是正する必要がある • 偶然原因のばらつき • 広範囲の問題、トップマネジメントの責任
  96. 96. ビーズの実験 • 4000個の白いビーズと1000個の赤いビーズを1つの箱のなかに • 1回に50個ビーズをすくい上げる、これが1日の生産量と考え る。4日間繰り返す • 赤玉3個以下という目標はどんなに逆立ちしても偶然でしか得 られない。目標はむしろモチベーションを下げる • 個人個人のパフォーマンスの最大の要因は、偶然以外の何者で もない • パフォーマンスはシステムによって決められており、個人とし てはどうすることもできないものが多い
  97. 97. 2015年3月
  98. 98. 課題タイプの再見直し 計測方法の再見直し 優先度別レーンから目的別レーンへ
  99. 99. 狙い・理由 • 課題タイプの再見直し、リーンのコストモデルと統一 • 計測を書く課題タイプごとにし、優先度別に見るのは 止める • 優先度別レーンによって、仕事の詰まり具合は可視化 されたが、ばらつき別の管理にはあまり効果が感じら れなかった • 優先度よりも目的別(後述)を管理対象の優先におい た
  100. 100. 課題タイプ1 • 価値(青) • この課題が完了すると価値が生まれるもの • 複数に分割されている場合もある • 例:機能リリースに関する課題 • 改善(緑) • コストを下げるための出来る活動、チームが嬉しい活動 • 例:CI環境構築、リリースをラクにするための活動、モ ヤっとをスッキリにする活動
  101. 101. • 失敗コスト(ピンク) • なんらかの失敗に対して必要となってしまった作業 • 例:バグ対応、技術的負債の返却 • 取引コスト(黄色) • 直接価値は生まないが、届けるために必要な作業 • 例:リリースのための作業、レビュー、プラットフォーム のアップデート対応 • 調整コスト(オレンジ) • 課題を進めるために必要になる活動 • 例:事前に検討が必要な設計、技術調査、デザイン依頼、 会議招集、外部チームとのやりとり 課題タイプ2
  102. 102. • Business レーン • ビジネス・POの視点・機能・AWC • Development レーン • コード・技術・開発チームの視点 • Kaizen レーン • チームプロセス・やると嬉しい事・気になることをスッキ リさせる・SMの視点 目的別レーン
  103. 103. • 朝会で1日1改善を話す • よかったことを褒める • ちいさな改善を継続的に • Kaizenレーンを使う • 気になることや、やったほうが良いことを残す • 取引コストや調整コストを下げる活動を行いやすく プチ改善
  104. 104. 背後にある考え
  105. 105. https://speakerdeck.com/nawoto/talk-about-agile-at-developers- summit-2015
  106. 106. 技術的負債 https://speakerdeck.com/kentaro/rethinking-technical-debt 意図的な負債は 失敗コストではなく 改善の活動にする (そのほうがモチベも 上がりやすい)
  107. 107. 目的→結果(中間報告) • 生産性の向上 • ムダの削減(Fix, Choreを下げる)→ △ • 見なおしの観点、機会は増えた • 優先度や課題タイプごとの実績を計測する → ⃝ • 計測結果から改善を行っていく → • その時やる課題やばらつきに大きく左右される、長 いスパンで計測する見る必要がある • 改善活動を行いやすくする → ◎ • デリバリリズムをつくる → △ • リリースの工数削減中、もうすこし!
  108. 108. まとめ
  109. 109. • 失敗と成功はひとつながり。成功はひとつじゃない • かんばんは既存プロセスがベースなので、はじめる のが怖くない • 自分たちで工夫し、改善していく文化を育てやすい • かんばんを育てる過程と背後にある考え方について 示した • 改善の3つの機会 • ビジネス側面、技術的側面、チーム環境の側面 そ れぞれが、ともにすべて大切
  110. 110. 多くの現場でより良いやり方を育てる助けに 学びを持ち寄って、楽しく、いきいきとさらなる学びへ
  111. 111. Fearless Start with Kanban to Change the World.

×