育てる！かんばん - bring up Kanban.
•
5 gostaram•2,697 visualizações
at Agile Japan 2015 Sapporo Satellite.
Recomendados
Mais conteúdo relacionado
Mais procurados
Semelhante a 育てる！かんばん - bring up Kanban.
Semelhante a 育てる！かんばん - bring up Kanban. (20)
Mais de Maehana Tsuyoshi
Mais de Maehana Tsuyoshi (16)
育てる！かんばん - bring up Kanban.
- 3. 失敗と成功 目的・目標・ゴール 達成 = 成功 未達成 = 失敗
- 10. 成功と失敗 失敗 → 経験・学び → 成功 素早く、小さく、失敗する 諦めない 失敗なんてない プロジェクト、チーム、組織、人生
- 11. アジャイル agile /ǽdʒ(ə)l¦ǽdʒa l/ 形容詞 1 すばしこい, 身軽な, 敏捷（びんしよう）な. 2 (頭の)回転が速い, 賢い. 3 活発な, 生き生きとした.
- 12. アジャイル 形容詞 状態 Do Agile ⃝ Be Agile 度合い
- 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, 上記の著者たち この宣言は、この注意書きも含めた形で全文を含めることを条件に 自由にコピーしてよい。
- 23. スクラム
- 27. 育てる！ かんばん RICOH IT SOLUTIONS @sandinist Tsuyoshi Maehana
- 28. • Tsuyoshi Maehana @sandinist • at Work: C# -> Ruby -> Objective-C • 基幹系業務システム開発 • リコー北海道 2003 2009 • Web αサービス開発 • iOS App 開発
- 29. 大きな組織 • 株式会社リコー 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/
- 32. 2009 2015 Team 2名 6名 +1 +1 +1 +1 -1 +2 -1 5名
- 33. 2009 2015 Team 2名 6名 +1 -1 +2 -1 5名 ・全体では6~10チームの大きなチームの内のひとつ ・プロセスや進め方は時とともに変化し続けている ・XP, Scrum, Lean, Kanban +1 +1 +1
- 37. 構造 運用監視 インフラ 開発 品質 UX 技術調査 企画 マーケ PO PO L
- 38. 構造 運用監視 インフラ 開発 品質 UX 技術調査 企画 マーケ PO PO L TL TL TL TL TL TL
- 41. EMLauncher irc
- 43. タスク管理の変遷 • Excel • 影舞 • Trac • Pivotal Tracker • JIRA
- 46. ポイント • 大きな組織の中、複数のチームが協働 • プロダクト・サービスのライフサイクルより長いチーム • いわゆるアジャイルな開発をふつうに行っている環境
- 47. かんばん
- 50. かんばん • リーン生産方式におけるカンバン（TOYOTA方式） • 物理的なタスクボードを指すカンバン • ソフトウェア開発手法としてのカンバン方式（Kanban）
- 51. かんばん方式 • スーパーマーケット方式 • 顧客の必要とする品物を、必要なときに、必要な量だけ在庫 • ジャストインタイム • 顧客である後工程が、必要な部品を、必要なときに、必要な 量だけを前工程に取りに行く
- 54. 物理的なボード自体
- 55. かんばんシステム • David J. Anderson によって纏められた理論 • 一言でKanbanを言うのは難しいが、2009年10月時点で は、ソフトウェア開発のフローを見える化し、WIP(Work in Progress=仕掛)を制限することで、顧客価値のスループット を上げ、同時に改善を促す活動 平鍋健児 • 文化的変革がおそらく最大の利点である David J. Anderson
- 56. かんばんシステム • 既存のプロセス（バリューストリーム）からスタート • プロセスの変更を強制しない • 量を制限し、流れを良くする • フローと計測から、問題が可視化される • 改善機会を増やせる
- 61. 2014年4月
- 62. 導入の目的 • 可視化のさらなる向上 • タスクの流れの整理、調整 • 異常発見を容易に • 状態の追加、調整 • 計測を簡易に行う仕組みの導入
- 70. 2014年5月
- 72. 狙い・理由 • イテレーションの残日数と完了項目数を追加 • イテレーションゴール達成できるかどうかを考えや すくする • バグを区別して管理する必要がなかった • ふつうの課題と同じように対応する
- 73. 2014年7月
- 76. 2014年10月
- 79. 狙い・理由 • 物理かんばんは完全にチームのもの • チーム境界とかんばんが一致するように調整した • 優先度が高いが、Readyになっていないものをあらわ すためにBlockレーンを追加 • 中断されている、棚上げにしていることを明示するた めにParkingLot復活
- 80. 半年間 ここまでのまとめ
- 81. 物理かんばんの利点 • 可視性 • 常にある、視線を向けるだけで見える • 異常がすぐに分かる（物理的制約がある） • プロセスが全員に明確に伝わる • 他のチームにも否応なく見える
- 82. 物理かんばんの利点 • 可変性 • 皆の目の前で動かせる • 調整しやすい • ベースとしての役割 • 集まる場所 • チームの一体感
- 83. 物理かんばんの欠点 • 場所をとる • そこにいないと見えない • 電子と二重管理になる • 会社の決まり事との戦い
- 84. 二重管理 • DRY原則 • 役割が違った • ストックとフロー • パッと見で必要な情報と、伝えるためや残しておくための 情報は違う
- 85. 導入の結果 • 可視化のさらなる向上 → ⃝ • タスクの流れの整理、調整 → ⃝ • 異常発見を容易に → ⃝ • 状態の追加、調整 → ⃝ • 計測を簡易に行う仕組みの導入 → ⃝
- 86. 導入の結果 • 可視化のさらなる向上 → ⃝ • タスクの流れの整理、調整 → ⃝ • 異常発見を容易に → ⃝ • 発見した異常への対処 → △ • 状態の追加、調整 → ⃝ • 計測を簡易に行う仕組みの導入 → ⃝ • 計測した結果の活用 → △
- 87. かんばん本読んだ
- 88. かんばん本との比較 • ① 品質に集中する • 低い品質は最大のムダ、失敗のコスト • ある程度できてる • ② 仕掛りを減らす • リトルの法則、仕掛りが増えるとリードタイムが長くなる • 作業の割り込みや切り替えはムダ • もともと一人基本1つで、最大2つまで
- 89. • ③ デリバリーを頻繁に行う • 顧客から信頼を得る • 頻繁なリリースは品質を高める、暗黙知の劣化を防ぐ • 定期的なリリースはできているが、毎イテレーション ではない。内部リリースコストは安いが、外部リリー スのコストが高い • ④ 要望とスループットのバランスを取る • ゆとりをつくる、たゆまぬ改善を行えるように • 戦略的なリリース物で手一杯になることも かんばん本との比較
- 90. • ⑤ 優先順位をつける • ビジネス価値の最適化 • 優先順位は顧客と調整できている。ビジネス価値の 最適化までは出来ていないのではないか。リリース 後の計測をビジネス判断に活かしきれていない。 • ⑥ ばらつきの要因を解消する • 上級のテーマ、予測可能性を向上する • ばらつかないことなど無い • 書籍の例は保守サービス かんばん本との比較
- 91. 2014年12月
- 93. 課題タイプの見直し（Story, Chore, Fix, Kaizen） 計測方法の見直し
- 94. 目的 • 生産性の向上 • ムダの削減（Fix, Choreを下げる） • 優先度や課題タイプごとの実績を計測する • 計測結果から改善を行っていく • 改善活動を行いやすくする • デリバリリズムをつくる • リリースコストを下げる
- 95. 背後にある考え • かんばんの3種の改善機会 • Theory of Constraints (Eliyahu M. Goldratt) • Lean and Toyota Production System • Profound knowledge (W. Edwards Deming)
- 96. TOC • The Goal 1984 • 制約条件の理論 • ボトルネックを識別し、管理することによって、全体のスルー プットを向上させる • かんばんの一連の流れから、制約になる資源を見つける。制 約にプロセスを合わせる、補強する。
- 97. Lean & TPS • ムリ・ムダ・ムラの削減 • コスト削減の部分最適に偏るのは間違ったリーン（アンチパ ターン） • 全体最適、価値の最適化
- 100. Profound Knowledge • W. Edwards Deming • 20世紀で最も偉大な経営科学者としばしば言われる • 統計的プロセス制御(SPC)から品質保証、経営科学まで • かんばんの基礎では、ばらつきがパフォーマンスに与える影 響について取り上げる
- 101. ばらつきについて at かんばん本 • Walter A. Shewhart • 偶然原因によるばらつき 内部要因 • 不可避原因によるばらつき 外部要因 • 内部要因によるばらつきを改善する • 作業項目のサイズ、タイプ、優先度の分類を分けて管理・計 測することによって、ばらつきによる影響を分けて捉える
- 102. Joy of Work • 吉田耕作 • デミング博士の直弟子、世界に10人に満たない、デミング／ マスターのひとり • 日本に Total Quality Management (TQM) を広めている
- 103. ばらつきについて at Joy of Work • 異常原因のばらつき • 原因をつきとめ、是正する必要がある • 偶然原因のばらつき • 広範囲の問題、トップマネジメントの責任
- 104. ビーズの実験 • 4000個の白いビーズと1000個の赤いビーズを1つの箱のなかに • 1回に50個ビーズをすくい上げる、これが1日の生産量と考え る。4日間繰り返す • 赤玉3個以下という目標はどんなに逆立ちしても偶然でしか得 られない。目標はむしろモチベーションを下げる • 個人個人のパフォーマンスの最大の要因は、偶然以外の何者で もない • パフォーマンスはシステムによって決められており、個人とし てはどうすることもできないものが多い
- 105. 2015年3月
- 107. 狙い・理由 • 課題タイプの再見直し、リーンのコストモデルと統一 • 計測を書く課題タイプごとにし、優先度別に見るのは 止める • 優先度別レーンによって、仕事の詰まり具合は可視化 されたが、ばらつき別の管理にはあまり効果が感じら れなかった • 優先度よりも目的別（後述）を管理対象の優先におい た
- 108. 課題タイプ1 • 価値（青） • この課題が完了すると価値が生まれるもの • 複数に分割されている場合もある • 例：機能リリースに関する課題 • 改善（緑） • コストを下げるための出来る活動、チームが嬉しい活動 • 例：CI環境構築、リリースをラクにするための活動、モ ヤっとをスッキリにする活動
- 109. • 失敗コスト（ピンク） • なんらかの失敗に対して必要となってしまった作業 • 例：バグ対応、技術的負債の返却 • 取引コスト（黄色） • 直接価値は生まないが、届けるために必要な作業 • 例：リリースのための作業、レビュー、プラットフォーム のアップデート対応 • 調整コスト（オレンジ） • 課題を進めるために必要になる活動 • 例：事前に検討が必要な設計、技術調査、デザイン依頼、 会議招集、外部チームとのやりとり 課題タイプ2
- 110. • Business レーン • ビジネス・POの視点・機能・AWC • Development レーン • コード・技術・開発チームの視点 • Kaizen レーン • チームプロセス・やると嬉しい事・気になることをスッキ リさせる・SMの視点 目的別レーン
- 111. • 朝会で1日1改善を話す • よかったことを褒める • ちいさな改善を継続的に • Kaizenレーンを使う • 気になることや、やったほうが良いことを残す • 取引コストや調整コストを下げる活動を行いやすく プチ改善
- 112. 背後にある考え
- 115. 目的→結果（中間報告） • 生産性の向上 • ムダの削減（Fix, Choreを下げる）→ △ • 見なおしの観点、機会は増えた • 優先度や課題タイプごとの実績を計測する → ⃝ • 計測結果から改善を行っていく → • その時やる課題やばらつきに大きく左右される、長 いスパンで計測する見る必要がある • 改善活動を行いやすくする → ◎ • デリバリリズムをつくる → △ • リリースの工数削減中、もうすこし！
- 116. まとめ
- 117. • 失敗と成功はひとつながり。成功はひとつじゃない • かんばんは既存プロセスがベースなので、はじめる のが怖くない • 自分たちで工夫し、改善していく文化を育てやすい • かんばんを育てる過程と背後にある考え方について 示した • 改善の3つの機会 • ビジネス側面、技術的側面、チーム環境の側面 そ れぞれが、ともにすべて大切
- 119. Fearless Start with Kanban to Change the World.