進むために、止まる。

2019年10月19日（土）に開催されるDevLOVE様主催『それぞれの現場の「正しいものを正しくつくる」』発表資料です。

Transcript

1. 進むために, 止まる。 株式会社ナビタイムジャパン 小田中 育生
2. 小田中 育生 (おだなか いくお) (株)ナビタイムジャパン 開発部 部長 ACTS(研究開発) ルートグループ責任者 ミッション ・経路探索のR&D ・全社的なカイゼン活動
3. Recent Works 106 223 352 606 749 1864 30704 1 10 100 1000 10000 100000 0 200 400 600 800 1000 1200 1400 1600 1800 2000 10 60 110 160 距離[km] 距離と探索時間 GPU Kepler GPU Volta CPU CPU 階層1のみ 指数関数的な 計算時間増大を克服
4. いかに正しく作るか Slideshare「正しいものを正しくつくる」本とはなにかより
5. 正しくつくるチーム
6. チームが同じ方向を向いている
7. アジャイルなカイゼンサイクル プロダクトがあって、 ユーザーが使い、 フィードバックをうけ、 何をつくるかを決め、 開発し、届ける。
8. これらは自然には発生しない
9. 一人ひとり方向性や前提は異なる
10. 高速化したい コードをきれいに 書きたい 経路の質を あげたい 新しい機能を つくりたい
11. 何を、なぜつくるのか 我々はなぜここにいるのか 気持ちを揃える ↓ チームビルディング
12. 「5分でわかった気になるインセプションデッキ」@TAKAKING22 https://www.slideshare.net/TakaoOyobe/5-45195080 例えばインセプションデッキ
13. 何を、なぜつくるのか 我々はなぜここにいるのか チームの優先順位は何か チームで対話する
14. 高速化したい コードをきれいに 書きたい 経路の質を あげたい 新しい機能を つくりたい 経路探索を よくしたい 経路探索を よくしたい 経路探索を よくしたい 経路探索を よくしたい
15. 高速化したい コードをきれいに 書きたい 経路の質を あげたい 新しい機能を つくりたい 経路探索を よくしたい 経路探索を よくしたい 経路探索を よくしたい 経路探索を よくしたい 「経路探索をよくしたい」が メンバーの共通項だった ↓ 対話により方向性が揃う
16. カイゼンサイクルを回すには プロセスの中で 「正しいもの」が再定義される 今、何を優先して 開発するべきか どう開発するかを決める プロセスに着目しカイゼンする モチベーションの維持・向上
17. 正しくつくるために チーム ビルディング 計 画 レ ビ ュ ー ふ り か え り
18. チームビルディング 計画 レビュー ふりかえり 開発の手を止め、「たちどまる」
19. たちどまることが できているか
20. よく相談される悩み 忙しくなると、 ふりかえりが 省略されちゃう チームビルディング したいけど 時間がとれません…
21. 現場で起こっていること プランニング時に内職 そもそも参加しない
22. 「どうしてわかってくれないんだ」 そう思ってしまうことが あるかもしれない
24. いまこそ対話を重視するとき。 なぜ、たちどまれないのか 耳を傾けてみる
25. 時間がない?
26. コーディングに集中したい?
27. 手を止めることが、怖い?
28. 小田中 育生 (おだなか いくお) (株)ナビタイムジャパン 開発部 部長 ACTS(研究開発) ルートグループ責任者 ミッション ・経路探索のR&D ・全社的なカイゼン活動 自分自身、過去には コーディング以外に時間が取られる ことに抵抗があった それが、なぜアジャイルを 推進するようになったのか?
29. 計 画 ふ り か え り コーディングに(見かけ上) 集中できる環境
30. 計 画 ふ り か え り コーディングに(見かけ上) 集中できる環境 時間がかかりなかなか開発できない 途中で変更しづらい
31. 計 画 ふ り か え り コーディングに(見かけ上) 集中できる環境 ・終盤でわかる認識の齟齬 ・計画の遅延 ・リリースしたけど使われない
32. 計 画 ふ り か え り コーディングに(見かけ上) 集中できる環境 改善しようがない課題ばかりが出る 険悪な空気 「ふりかえり、いらないよね」
33. そんなときに見つけたスライド https://speakerdeck.com/ryuzee/sukuramufalseji-chu?slide=4
34. 小田中 育生 (おだなか いくお) (株)ナビタイムジャパン 開発部 部長 ACTS(研究開発) ルートグループ責任者 ミッション ・経路探索のR&D ・全社的なカイゼン活動 このスライドとの出会いをきっかけに アジャイルの導入を決意し 自分の現場での経験をきっかけに アジャイルの推進をはじめた
35. 時間がない コーディングに集中したい 手を止めることが怖い どう向き合ったのか
36. 1. 客観的事実の提示 https://speakerdeck.com/ryuzee/sukuramufalseji-chu?slide=4 「多くの機能が使われない」 この事実は驚きがあり、 また説得力がある コーディングの時間を 使ってでも立ち止まるべき、 と理解してもらえた
37. 2. タスクの整理 「やらなければいけない」と思っている タスクリストの棚卸し 集中した時間がとれるスケジューリング 必要性の薄いMTGの欠席 「時間がない」メンバーに対しては 個人単位でこういったサポートを実施
38. リリースごとに作成していた資料 Release x.x.xでの変更点 関係者へ送付
39. リリースごとに作成していた資料 Release x.x.xでの変更点 関係者へ送付 資料作成、時間かかるので 見直したいんですけど
40. リリースごとに作成していた資料 Release x.x.xでの変更点 関係者へ送付 資料作成、時間かかるので 見直したいんですけど 見てないから なくても大丈夫です 見てないから なくても大丈夫です そんな資料 あったんですね！
41. 作ったものが使われないのは、悲しい。
42. なぜ必要か、誰がいつ使っているかを 精査すれば省略できるタスクは見つかる。
43. 3. 変化の見える化 なによりも「成果」で示すことが大切。 たちどまることで起きる変化を見える化する。
44. 0 2 4 6 8 10 12 14 16 8月 9月 10月 11月 デプロイ数 デプロイ数 例えば、デプロイ数の増加
45. 外部の具体的な成功事例を見せるもよし
46. それぞれの視点で課題と向き合い たちどまる勇気を持つ
47. たちどまりながら走るチームができた そしてまた新しい壁にぶつかる
48. チーム ビルディング 計 画 レ ビ ュ ー ふ り か え り ふりかえり、あまり 意味がないのでは? レビューの時間、 いりますかね
49. 「どうしてわかってくれないんだ」 ふたたび
50. 「いや、これはスクラムでは必要なプラクティスなんだ」 そういって押し切ってしまうと、 みかけだけ参加して内職する 「静かな反抗」が始まってしまう。 なぜやるのか理解してもらう必要があるし、 なぜそう思ったのか理解する必要がある。
52. いまこそ対話を重視するとき。 なぜ、そう思ったのか 耳を傾けてみる
53. チーム ビルディング 計 画 レ ビ ュ ー ふ り か え り ふりかえり、あまり 意味がないのでは? レビューの時間、 いりますかね マンネリ化してる カイゼンにつながってない 形骸化してる 基準があいまい
54. メンバーの声から課題を抽出し、 プロセス自体のカイゼンにつなげる。
55. チームAのプロセス変遷 2週間スプリント 月～金 ・朝会15m (everyday) ・プランニング 2h ・レビュー 1h ・ふりかえり 1.5h 1週間スプリント 水(午後)～水(午前) ・朝会15m (everyday) ・プランニング 2h ・レビュー 1h ・ふりかえり 1h 1週間スプリント 水(午後)～水(午前) ・朝会15m (everyday) ・プランニング 2h ・レビュー 1.2h ・ふりかえり 0.8h 1週間スプリント 水(午後)～水(午後) ・朝会15m (everyday) ・プランニング 2h ・レビュー 1.2h ・ふりかえり 0.8h 1週間スプリント 水(午後)～水(午後) ・朝会15m (everyday) ・プランニング 1h ・レビュー 1h ・ふりかえり 1h 2週間スプリント 水(午前)～水(午前) ・朝会15m (everyday) ・プランニング 1.25h ・レビュー 0.5h ・ふりかえり 1.25h
56. チームBのプロセス変遷 2週間スプリント 月～金 ・朝会15m (everyday) ・プランニング 0.5h ・レビュー 0.5h ・ふりかえり 1.0h 2週間スプリント 月～金 ・朝会15m (everyday) ・プランニング 1.0h ・レビュー 0.5h ・ふりかえり 1.0h 2週間スプリント 水～火 ・朝会15m (everyday) ・プランニング 1.0h ・レビュー 1.0h ・ふりかえり 1.0h 2週間スプリント 水～火 ・朝会15m (everyday) ・プランニング 1.0h + リファインメント 1.0h(スプリント折返し時) ・レビュー 1.0h ・ふりかえり 1.0h
57. 自分たちで立ち止まり、ふりかえり、実験する 同じスタートを切ったチームでも それぞれのやり方に変わってゆく
58. ある瞬間にうまくいっていなくても 自分たちでカイゼンできる 自分たち流に進化する
59. 変化するチームは、 立ち止まっている
60. ところで
61. いかに正しく作るか Slideshare「正しいものを正しくつくる」本とはなにかより
62. 開発の現場にとって 「正しいもの」は与えられるものか?
63. チーム ビルディング 計 画 レ ビ ュ ー ふ り か え り 「正しいもの」をつくれているか 自らアプローチしていく姿勢
64. 現場で起こっていること ・プランニングでの課題 ・あいまいな受け入れ基準のままスプリントを始める ・レビューでの課題 ・動くソフトウェアがないまま判断してしまう
65. 自分たちでカイゼンできるチームが なぜ正しいものをつくれないのか
66. チーム ビルディング 計 画 レ ビ ュ ー ふ り か え り カイゼンの向き先が プロセスにのみ向いている?
67. チーム ビルディング 計 画 レ ビ ュ ー ふ り か え り 動くソフトウェアが出せるサイクルと スプリント期間があってない?
68. チーム ビルディング 計 画 レ ビ ュ ー ふ り か え り ステークホルダーの期待からずれた アウトプットに執着している?
69. ステークホルダーからは こう思われているかもしれない
70. 「どうしてわかってくれないんだ」
71. うまくいっていると感じていても チームの外からそう思われているとは 限らない
72. Recent Works 106 223 352 606 749 1864 30704 1 10 100 1000 10000 100000 0 200 400 600 800 1000 1200 1400 1600 1800 2000 10 60 110 160 距離[km] 距離と探索時間 GPU Kepler GPU Volta CPU CPU 階層1のみ 指数関数的な 計算時間増大を克服 目覚ましい成果は 確固たるビジョンと 立ち止まれるチームから生まれてきた
73. チームは、自分たちだけではなく 外部とも向き合う必要がある。 そのために何ができるだろう。
74. チームの約束と向かい合う 「5分でわかった気になるインセプションデッキ」@TAKAKING22 https://www.slideshare.net/TakaoOyobe/5-45195080 3ヶ月に1度見直し、 行動も見直す
75. ゴールに辿り着くためのカイゼン 2週間スプリント 月～金 ・朝会15m (everyday) ・プランニング 0.5h ・レビュー 0.5h ・ふりかえり 1.0h 2週間スプリント 月～金 ・朝会15m (everyday) ・プランニング 1.0h ・レビュー 0.5h ・ふりかえり 1.0h 2週間スプリント 水～火 ・朝会15m (everyday) ・プランニング 1.0h ・レビュー 1.0h ・ふりかえり 1.0h 2週間スプリント 水～火 ・朝会15m (everyday) ・プランニング 1.0h + リファインメント 1.0h(スプリント折返し時) ・レビュー 1.0h ・ふりかえり 1.0h チームBは求められている成果を 出すためにリファインメントを始めた
76. 2週間スプリント 月～金 ・朝会15m (everyday) ・プランニング 2h ・レビュー 1h ・ふりかえり 1.5h 1週間スプリント 水(午後)～水(午前) ・朝会15m (everyday) ・プランニング 2h ・レビュー 1h ・ふりかえり 1h 1週間スプリント 水(午後)～水(午前) ・朝会15m (everyday) ・プランニング 2h ・レビュー 1.2h ・ふりかえり 0.8h 1週間スプリント 水(午後)～水(午後) ・朝会15m (everyday) ・プランニング 2h ・レビュー 1.2h ・ふりかえり 0.8h 1週間スプリント 水(午後)～水(午後) ・朝会15m (everyday) ・プランニング 1h ・レビュー 1h ・ふりかえり 1h 2週間スプリント 水(午前)～水(午前) ・朝会15m (everyday) ・プランニング 1.25h ・レビュー 0.5h ・ふりかえり 1.25h チームAは開発スピードにあわせ スプリント期間を2週間に戻した 開発サイクルのみなおし
77. 期待とずれにくい目標設定 OKR Objective (目標) Key Results(主要な結果) 4月から導入、月イチで見直し
78. ん? トップダウンで 動くしかないってこと?
79. OKRは双方向。 ボトムアップのインプットが重要
80. 例えば、自分たちの開発環境。 ゴールからの逆算では 課題が見えづらい。
81. 共用のテスト用サーバー ・待ち行列が発生 ・意図しない環境の変更がある 個人用のテスト用サーバー ・待ち行列なし ・個別に環境を維持できる エンジニアが発案したカイゼン
82. 最前線で開発するエンジニア だからこそ気付けることがある ↓ 気付きをとりこむチーム文化
83. ・カイゼンの向き先が内向き ・サイクルのミスマッチ ・期待とのズレ 「正しいもの」は、「正しくつく」れば 簡単にできるものではない。
84. 「正しいもの」をつくるうえで 課題になっていることと向き合う。 「正しく」つくるプロセスと 本質は同じ。
85. 正しくつくるために 我々は立ち止まる必要がある。
86. 立ち止まることは怖い。 今、目の前の仕事を脇に置いていいか 悩んだことのない人などいるのか?
87. なので、 「どうしてわかってくれないんだ」 と嘆くのではなく
88. それぞれの視点で課題と向き合い 立ち止まる勇気を持つ
89. 「正しいもの」を作っているか。 これも、開発の現場にとっては 重要な問いかけだ。
90. 進むために、止まる。 それこそが 正しいものを正しくつくる 原動力である。
91. Thanks!