「始めるのをやめて、終わらせることを始める」ことを始めた開発チームの話 / Rakus Meetup Osaka 2020-02-05

Rakus Meetup Osaka #5 の発表資料です。
https://rakus.connpass.com/event/182082/

Transcript

1. 始めるのをやめて 終わらせることを始める 開発チームの話 RAKUS Meetup Osaka #5 株式会社ラクス 吉元和仁
2. 自己紹介 • 所属・氏名 • 株式会社ラクス 第二開発部 • 吉元和仁（よしもとかずひと） • 仕事 • メール配信サービス「配配メール」の開発担当
3. 話すこと • 開発チームが抱える問題を原理原則から紐解き、「始め るのをやめて、終わらせることを始める」ことで、開発 チーム力アップに取り組んでいます。 • 開発チームの改善の取り組み、「カンバン」によるシス テム開発の不確実性との向き合い方など、システム開発 の原理原則をおりまぜてご紹介します。
4. Agenda 1. 無秩序な開発チームと割れ窓理論 2. 計画の不確実性の話 3. マルチタスクの話 4. 開発プロジェクトを見直した話 5. まとめ
5. 無秩序な開発チームと 割れ窓理論
6. 1年半前
7. 開発チームの構成 マネジメント 開発メンバー I joined
8. 開発チームの課題
9. ルールやチェックリストが 形骸化
10. ずさんなドキュメント管理
11. 無秩序なウォータフォール 要 件 定 義 概 要 設 計 詳 細 設 計 実 装 受 入 結 合 試 験
12. 割れ窓理論
13. 割れ窓理論とは 建物の窓ガラスが 割れたまま放置されていると、 管理人がいないと思われ 凶悪な犯罪が増えるという理論。 ジョージ・ケリング （米国の心理学者）
14. 開発チーム 正常化プロジェクト発足
15. ５S活動 5S 整理 整頓 清掃 清潔 躾
16. 改善内容 • ドキュメント・ルールを徹底的に整備・整頓。 • 開発工程の定義書を作成して、スコープや完了基準を明 文化。
17. 活動の成果 • チェックシート整理できた。 • ドキュメントがすぐに見つけれるようになった。 • 開発プロセスが正常化できた。 （ウォーターフォール型の開発ができるようになった）
18. 特にしつけが重要 5S 整理 整頓 清掃 清潔 躾
19. チェックシートを 印刷して毎日回覧
20. 計画の不確実性の話
21. 5S活動後に見えてきた 開発チームの課題 21
22. リリーススケジュール 延期が慢性化 22
23. 永遠の進捗90% 23
24. ホフスタッタの法則 • いつでも予測以上の時間がかかるものである。 • ホフスタッタの法則を計算に入れても。 ダグラス・ホフスタッタ （認知科学者・人工知能学者）
25. 90対90の法則 コードの最初の90%が開発時間の 90%を占め、残りの10%がさら に90%を占める。 トム・カーギル （ベル研究所）
26. 計画どおり進めることは 難しいんです
27. なぜ計画が難しいのか？
28. 計画の不確実性 • コードと深く向き合っている人でしかわからないことが 多い。
29. 計画の不確実性 • 楽観主義などの要因により、コストを低く見積もる傾向 がある。 書籍「人月の神話」より
30. 悲観的に見積もるべきか？
31. 計画の不確実性 • 仕事の量は、完成のために与えられた時間をすべて満た すまで膨張する。 「パーキンソンの法則」より シリル・ノースコート・パーキンソン （英国の歴史学者・政治学者）
32. 計画の不確実性 • 見積りは、あくまで予測です。 • 予測を「ノルマ」にした途端、それを達成するための過 負荷な労働が生まれ、クオリティが下がってしまいます。 • あるいは、スケジュールの予測精度はどんどん下がって しまいます。 書籍「エンジニア組織論への招待」より
33. 計画の不確実性 • 「ノルマ」にした結果 • 計画を守るための周りのプレッシャーに負け、予定 通りと報告してしまう。 • その後、ある段階で、現実を受け入れなければなら ない重要なポイントに到達する。
34. 計画の不確実性 - 2020年ふるさと納税返礼品 “おせち” 届かない問題 https://www.tokyo-np.co.jp/article/ibaraki/list/202001/CK2020010702000139.html
35. 計画の不確実性 • 2011年グルーポンおせち問題 https://gigazine.net/news/20110105_groupon_osechi/
36. 計画の不確実性 • 大抵の計画は不確定要素を含んでおり、その通りになる ことはほとんどない。 • 計画づくりをするのに十分な情報がまだなく、理解も足 りていなかったとしたら、状況が進む中でわかったこと をもとに計画を変えていくべきはずだろう。 書籍「正しいものを正しくつくる」より
37. 計画の不確実性 https://agilemanifesto.org/iso/ja/manifesto.html
38. 所感 • とは言っても、計画は事業部門が絡む話であり、計画な をなくすことは難しい。 • 「計画」は「予測」と認識した上で、プロジェクト終盤 にかけて予測が収束していくことを管理するのが大事。
39. マルチタスクの話
40. 開発チームに JOINして半年後
41. コアメンバーの異動 マネジメント 開発メンバー
42. マネージャと若手メンバーJOIN マネジメント 開発メンバー
43. 総勢10名体制
44. コアメンバーにタスクが集中
45. 進むマルチタスク化 案件A 案件B 管理職からの依頼 案件B 若手のフォロー 若手向けタスク創出 管理職の質問対応 管理職の質問対応 案件C 管理職から圧力 案件A 案件C アラート通知対応
46. マルチタスクについて • 人間はマルチタスクをこなせない。 • シングルタスクの切り替えをしているに過ぎない。 エヤル・オフィル （スタンフォード大学 神経学者）
47. マルチタスクについて • マルチタスクは生産性が低い。 • それぞれのタスクに集中できていないので、結局やりと げるまでに時間がかかる。 • 注意力散漫になっているためにエラー が増えること。 書籍「スタンフォード式最高のリーダー シップ」より
48. 開発プロセス見直し プロジェクト発足
49. 反復開発導入
50. 反復開発について • プロジェクトを「1週間のタイムボックス」に分割し、計 画、実行、振り返りを繰り返し行う開発。
51. 反復開発について 1週間タイムボックス 水 木 金 土 日 月 火 開発メンバーと作戦会議 （1.5h） ふりかえり（1.5h) 朝会（15分） 次週のタスク準備（1.5h) 開発時間 マネージャーと作戦会議 （1h）
52. 反復開発による効果 • 毎週、計画・振り返りを実施するので、プロジェクトが 進むにつれて、計画の不確実性が低減することができた。
53. カンバン導入
54. カンバンについて • カンバンの原則 • 見える化 • WIPの制限 • 流れの管理
55. カンバンの基本 • 「始めるのをやめて、終わらせることを始める」 書籍「カンバン仕事術」より
56. 実際のカンバン
57. カンバンのイメージ TODO NEXT DOING CHECK DONE 1週間分のタスクを TODOへ アバターを準備する
58. カンバンのイメージ TODO NEXT DOING CHECK DONE 今日実施予定のタスクを NEXTへ
59. カンバンのイメージ TODO NEXT DOING CHECK DONE 着手するタスクは アバターをつけて DOINGへ
60. カンバンのイメージ TODO NEXT DOING CHECK DONE レビューが必要なタス クはCHECKへ移動 完了したら DONEへ移動
61. カンバンのイメージ TODO NEXT DOING CHECK DONE レビュー待ちタスクは 優先して終わらせる
62. カンバンのイメージ TODO NEXT DOING CHECK DONE 完了
63. カンバンのイメージ TODO NEXT DOING CHECK DONE 終わらないタスクは 全員で作戦会議
64. カンバンのイメージ TODO NEXT DOING CHECK DONE 分解して全員で対応
65. TODO NEXT DOING CHECK DONE カンバン作成 完了
66. スウォーミングについて • 問題の周りに人が群がり（スウォーム）、すばやく解決 して、通常の流れに戻ること。
67. カンバン効果 • スウォーミングの積極的導入により、ナレッジ移転がや りやすくなり・属人化タスクを削減できた。 • 「始めるのをやめて、終わらせることを始める」ことで、 スイッチングコストを削減し、開発チームの生産力を アップすることができた。
68. 開発プロセス見直しによる効果
69. 開発プロセス見直しによる効果
70. 開発プロセス見直し前 • 「ver5.3」開発プロジェクト • リリース日：2019/3 予定 • リリース日：2019/4 予定 • リリース日：2020/5 予定 リスケ リスケ
71. 開発プロセス見直し後 • 「ver6.0」開発プロジェクト • リリース日：2019/11/10 • 「ver6.1」開発プロジェクト • リリース日：2020/01/28 • 「ver6.2」開発プロジェクト • リリース日：2020/03/末
72. 開発チームの関心事の変化 • 開発プロセス変更前 • リソース効率を上げる。 • タスクを創出し続けて、開発メンバーの空きをつくらない。 • 開発プロセス変更後 • フロー効率を上げる。 • いかにタスクを分割し共同作業をすすめていくかを計画する。
73. 開発チームのスタイルの変化 • フロー効率をあげるためには • 作業の流れを止めないように、ボトルネックを無くす。 • ボトルネックを無くすために、属人化タスクを無くす。 • 属人化タスクを無くすために、積極的に共同作業をする。 • 共同作業しやすいように、タスク分割・完了基準を明確化する。 • 共同作業により、学習しながら作業する開発スタイルに切り替わり つつある。
74. まとめ
75. まとめ • 無秩序な開発チームを「５S」活動で正常化。 • 「計画の不確実性」を「反復開発」で低減。 • スイッチングコストを「カンバン」で削減。
76. カンバンのオススメポイント • 開発が進むほど、計画の精度が上がる。 • スイッチングコストが削減できる。 • スウォーミング（共同作業）により開発チーム力がアッ プする。 • 導入コストが低い。
77. 「始めることをやめて、終わら せることを始める」ことで
78. 開発チーム力アップが アップしたという話でした。
79. ご静聴ありがとう ございました