1. 改善ってどうやんの実際? 2017/12/9 Agile Tour Osaka 2017 Kiro Harada Attractor Inc.
3. Version History 2016/10/14 Version 0.1 Agile Conference Vietnam HCMC 2016/10/16 Version 0.2 Agile Conference Vietnam Hanoi 2016/10/28 Version 0.3 Agile Tour Bangkok 2016/11/2 Version 1.0 Public Release 2016/11/19 Version 1.0.1 Agile Tour Hong Kong (香港) 2017/1/12 Version 2.0 Regional Scrum Gathering Tokyo 2017
4. 改善? (名詞)スル 物事をよい方に改めること。
7. 自転車の乗り方を 子供に教える方法を 教えられる?
8. 教えられる: 1. ヘルメットをかぶせる。必要に応じて、ニーガード、エルボーガードを 2. 正しいサイズの自転車を選ぶ (両足が地面にしっかり着くこと) 3. ペダルを外す(ペダルなし自転車を使っても良い) 4. 広く安全な場所で練習する(少し傾斜があると良い) 5. 足で蹴って、足をつかずにできるだけ長い距離バランスをれるように練習する 6. 5メートル以上バランスを取れるようになったら、ブレーキを使って止まる練習をする 7. ブレーキで止まれるようになったら、ペダルをつける 8. 自転車に乗れるようになっている
9. やらない! Training wheels Don’t hold your kid bike from behind. https://www.flickr.com/photos/sahdblunders/8644936719
11. 新しいことをできるように なるには? 安全を確保する 安心できる環境で 一つずつ練習する 練習の成果を感じられるように
14. あなたは? チームは改善してますか? 組織は改善してますか? 会社は改善してますか?
15. あなた個人は? 自分はどうでしょう? 改善してますか? 何か上手になって行っていますか? 忙しすぎて改善する暇がない?
16. 継続的って? 継続的, いつも いつでも おわりなく 改善に終わりはない。チームに完璧はない。
17. 危険な思い込み 業績が良くないのは、まだやり足りないからだ。もっ とやらなくては。 まだ成果が足りないのは、まだ自分がやれてないこと があるからだ。もっと達成するために、もっとやらな くては。
18. オーバートレーニング症候群は、選 手が故障する一番の原因である。 プロ選手がコーチを雇 うのは、練習量・パ フォーマンスを第三者 に見てもらうため。 自己評価はあてになら ないので、デバイスを使 う。
20. 無停止杼換式豊田自動織機(G型) http://commons.wikimedia.org/wiki/File:1924_Non-Stop_Shuttle_Change_Toyoda_Automatic_Loom,_Type_G_1.jpg
21. 織機の特徴: 縦糸や横糸が切れると、自動的に停止し、不良品を作らな い 良品のみを製造する オペレーターは、いつでも休憩を取ることができる 一人のオペレーターが、最大60台の織機を同時に動かせる
22. 改善 が継続しないのは? 今のやり方をもっとやれさえすれば、問題を解決す ると思っているから 今のやり方をそのままにして、さらに別のやり方を 足すことで、問題を解決しようと思っているから 問題はやり足りないだけだと思っているから
24. 改善してませんでした タイムゾーンの違う顧客で、コーチング、コンサル ティング、トレーニングをたくさん 寝る暇がない 実際、楽しかったのです。本当に。
27. 計測できないものは、 管理できない 計測できた方が、管理しやすい。
29. ムリ - ムラ - ムダ ムリ 過負荷・過重 Muri ↓ ムラ ばらつき Mura ↓ ムダ Muda 無駄 ムダを無くしたいなら、ムリしないこと
30. チームは改善してますか? 改善したいなら、まずはムリを減らしましょう。 できてないなら、まずはチームメンバーのムリを減ら すことから
31. 改善ってどうやんの実際? 始めましょう でも、どこから?
32. ゆとりを作る ゆとりがなければ、何をやってもパフォーマンスを 落としてしまう。あそびのない機械はすぐ壊れる。 オーバートレーニング症候群? 自分が何をやっているかを理解する時間をとりま しょう。
33. 通常の仕事を止める時間。 走りながらでは、靴紐を直 せない。 カレンダーに「休み時間」 1番の優先順位で登録しよ う。
35. チームの対話 チームメンバー全員がゆとりを持てるようになった ら、みんなで集まって対話できる機会を定期的に持と う 対話には、十分な時間をかける そのうち、品質についての対話が行われるようになる
36. 課題に合意する チームの対話を続けていると、チームメンバー全員が 解決したいと思っている課題が浮かび上がる 課題をドキュメントにして残そう。残したら、何が 起こるかを観察しよう
37. 課題・問題の例? ソフトウェアの品質が悪い スクラムがうまくやれていない CI / CD / TDD … がうまくやれていない DevOps やらないと
38. 事実と意見 問題 解決 計測 事実 (観測事象) 仮説 実装 意見 設計
39. 解決策がないことが 問題ではない 解決策が行われていないことは問題ではない。解決 策を実行できたかを測っても意味がない 問題を観測可能な事実として説明すること 観測可能な事実として問題を記述できれば、問題 が解決したかを測る方法は自ずからわかるように なる
43. 小さな実験 Photo by woodleywonderworks. CC-BY-2.0 https://www.flickr.com/photos/wwworks/3058182308
44. 見える化 https://visualizationexamples.com/
46. セットベース設計 https://www.flickr.com/photos/arenamontanus/3212655985
52. 障害を分析する James R. Tourtellotte, CBP, U.S. Dept. of Homeland Security
55. 動的な安定したプロセス Photo by Stephen Morris. CC-BY-2.0 https://www.flickr.com/photos/nonlin/4297013382
56. チームの良いやり方 チームの標準 The Training within Industry Report
57. メンタリング By Lisamarie Babik - Ted & IanUploaded by Edward, CC BY 2.0, https://commons.wikimedia.org/w/index.php?curid=9546406
61. 改善パターン ゆとり 個人スキ を作る ルの向上 セットベース スキルマトリ 小さな 対話 価値の流れ のマップ ひとつ 実験 づつ チームの チームの 標準 よいやり方 事実 やめる と意見 課題を 共有 設計 クスを作る チームの 他チームと 合意 一緒にやる 順番を変える メンタリ シンプルに ング 測定を 継続的 学習 設計する 動的な 不具合を 助けを 安定したプ 早く見つ 呼ぶ ロセス ける 見える化 品質を 不具合を 分析 作り込む 継続的 改善
63. Training Within Industry 日本へ1950年に紹介さ れた。紹介映画のタイト ルが、 「改善への四段階」
64. ゆとりあります? まずは、小さく始めましょう 1日15分 1週間に1時間 1ヶ月に2時間