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

by kyoshimoto

Slide 1

Slide 1 text

始めるのをやめて終わらせることを始める開発チームの話 RAKUS Meetup Osaka #5 株式会社ラクス吉元和仁

Slide 2

Slide 2 text

自己紹介 • 所属・氏名 • 株式会社ラクス第二開発部 • 吉元和仁（よしもとかずひと） • 仕事 • メール配信サービス「配配メール」の開発担当

Slide 3

Slide 3 text

話すこと • 開発チームが抱える問題を原理原則から紐解き、「始めるのをやめて、終わらせることを始める」ことで、開発チーム力アップに取り組んでいます。 • 開発チームの改善の取り組み、「カンバン」によるシステム開発の不確実性との向き合い方など、システム開発の原理原則をおりまぜてご紹介します。

Slide 4

Slide 4 text

Agenda 1. 無秩序な開発チームと割れ窓理論 2. 計画の不確実性の話 3. マルチタスクの話 4. 開発プロジェクトを見直した話 5. まとめ

Slide 5

Slide 5 text

無秩序な開発チームと割れ窓理論

Slide 6

Slide 6 text

1年半前

Slide 7

Slide 7 text

開発チームの構成マネジメント開発メンバー I joined

Slide 8

Slide 8 text

開発チームの課題

Slide 9

Slide 9 text

ルールやチェックリストが形骸化

Slide 10

Slide 10 text

ずさんなドキュメント管理

Slide 11

Slide 11 text

無秩序なウォータフォール要件定義概要設計詳細設計実装受入結合試験

Slide 12

Slide 12 text

割れ窓理論

Slide 13

Slide 13 text

割れ窓理論とは建物の窓ガラスが割れたまま放置されていると、管理人がいないと思われ凶悪な犯罪が増えるという理論。ジョージ・ケリング（米国の心理学者）

Slide 14

Slide 14 text

開発チーム正常化プロジェクト発足

Slide 15

Slide 15 text

５S活動 5S 整理整頓清掃清潔躾

Slide 16

Slide 16 text

改善内容 • ドキュメント・ルールを徹底的に整備・整頓。 • 開発工程の定義書を作成して、スコープや完了基準を明文化。

Slide 17

Slide 17 text

活動の成果 • チェックシート整理できた。 • ドキュメントがすぐに見つけれるようになった。 • 開発プロセスが正常化できた。（ウォーターフォール型の開発ができるようになった）

Slide 18

Slide 18 text

特にしつけが重要 5S 整理整頓清掃清潔躾

Slide 19

Slide 19 text

チェックシートを印刷して毎日回覧

Slide 20

Slide 20 text

計画の不確実性の話

Slide 21

Slide 21 text

5S活動後に見えてきた開発チームの課題 21

Slide 22

Slide 22 text

リリーススケジュール延期が慢性化 22

Slide 23

Slide 23 text

永遠の進捗90% 23

Slide 24

Slide 24 text

ホフスタッタの法則 • いつでも予測以上の時間がかかるものである。 • ホフスタッタの法則を計算に入れても。ダグラス・ホフスタッタ（認知科学者・人工知能学者）

Slide 25

Slide 25 text

90対90の法則コードの最初の90%が開発時間の 90%を占め、残りの10%がさらに90%を占める。トム・カーギル（ベル研究所）

Slide 26

Slide 26 text

計画どおり進めることは難しいんです

Slide 27

Slide 27 text

なぜ計画が難しいのか？

Slide 28

Slide 28 text

計画の不確実性 • コードと深く向き合っている人でしかわからないことが多い。

Slide 29

Slide 29 text

計画の不確実性 • 楽観主義などの要因により、コストを低く見積もる傾向がある。書籍「人月の神話」より

Slide 30

Slide 30 text

悲観的に見積もるべきか？

Slide 31

Slide 31 text

計画の不確実性 • 仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する。「パーキンソンの法則」よりシリル・ノースコート・パーキンソン（英国の歴史学者・政治学者）

Slide 32

Slide 32 text

計画の不確実性 • 見積りは、あくまで予測です。 • 予測を「ノルマ」にした途端、それを達成するための過負荷な労働が生まれ、クオリティが下がってしまいます。 • あるいは、スケジュールの予測精度はどんどん下がってしまいます。書籍「エンジニア組織論への招待」より

Slide 33

Slide 33 text

計画の不確実性 • 「ノルマ」にした結果 • 計画を守るための周りのプレッシャーに負け、予定通りと報告してしまう。 • その後、ある段階で、現実を受け入れなければならない重要なポイントに到達する。

Slide 34

Slide 34 text

計画の不確実性 - 2020年ふるさと納税返礼品 “おせち” 届かない問題 https://www.tokyo-np.co.jp/article/ibaraki/list/202001/CK2020010702000139.html

Slide 35

Slide 35 text

計画の不確実性 • 2011年グルーポンおせち問題 https://gigazine.net/news/20110105_groupon_osechi/

Slide 36

Slide 36 text

計画の不確実性 • 大抵の計画は不確定要素を含んでおり、その通りになることはほとんどない。 • 計画づくりをするのに十分な情報がまだなく、理解も足りていなかったとしたら、状況が進む中でわかったことをもとに計画を変えていくべきはずだろう。書籍「正しいものを正しくつくる」より

Slide 37

Slide 37 text

計画の不確実性 https://agilemanifesto.org/iso/ja/manifesto.html

Slide 38

Slide 38 text

所感 • とは言っても、計画は事業部門が絡む話であり、計画なをなくすことは難しい。 • 「計画」は「予測」と認識した上で、プロジェクト終盤にかけて予測が収束していくことを管理するのが大事。

Slide 39

Slide 39 text

マルチタスクの話

Slide 40

Slide 40 text

開発チームに JOINして半年後

Slide 41

Slide 41 text

コアメンバーの異動マネジメント開発メンバー

Slide 42

Slide 42 text

マネージャと若手メンバーJOIN マネジメント開発メンバー

Slide 43

Slide 43 text

総勢10名体制

Slide 44

Slide 44 text

コアメンバーにタスクが集中

Slide 45

Slide 45 text

進むマルチタスク化案件A 案件B 管理職からの依頼案件B 若手のフォロー若手向けタスク創出管理職の質問対応管理職の質問対応案件C 管理職から圧力案件A 案件C アラート通知対応

Slide 46

Slide 46 text

マルチタスクについて • 人間はマルチタスクをこなせない。 • シングルタスクの切り替えをしているに過ぎない。エヤル・オフィル（スタンフォード大学神経学者）

Slide 47

Slide 47 text

マルチタスクについて • マルチタスクは生産性が低い。 • それぞれのタスクに集中できていないので、結局やりとげるまでに時間がかかる。 • 注意力散漫になっているためにエラーが増えること。書籍「スタンフォード式最高のリーダーシップ」より

Slide 48

Slide 48 text

開発プロセス見直しプロジェクト発足

Slide 49

Slide 49 text

反復開発導入

Slide 50

Slide 50 text

反復開発について • プロジェクトを「1週間のタイムボックス」に分割し、計画、実行、振り返りを繰り返し行う開発。

Slide 51

Slide 51 text

反復開発について 1週間タイムボックス水木金土日月火開発メンバーと作戦会議（1.5h）ふりかえり（1.5h) 朝会（15分）次週のタスク準備（1.5h) 開発時間マネージャーと作戦会議（1h）

Slide 52

Slide 52 text

反復開発による効果 • 毎週、計画・振り返りを実施するので、プロジェクトが進むにつれて、計画の不確実性が低減することができた。

Slide 53

Slide 53 text

カンバン導入

Slide 54

Slide 54 text

カンバンについて • カンバンの原則 • 見える化 • WIPの制限 • 流れの管理

Slide 55

Slide 55 text

カンバンの基本 • 「始めるのをやめて、終わらせることを始める」書籍「カンバン仕事術」より

Slide 56

Slide 56 text

実際のカンバン

Slide 57

Slide 57 text

カンバンのイメージ TODO NEXT DOING CHECK DONE 1週間分のタスクを TODOへアバターを準備する

Slide 58

Slide 58 text

カンバンのイメージ TODO NEXT DOING CHECK DONE 今日実施予定のタスクを NEXTへ

Slide 59

Slide 59 text

カンバンのイメージ TODO NEXT DOING CHECK DONE 着手するタスクはアバターをつけて DOINGへ

Slide 60

Slide 60 text

カンバンのイメージ TODO NEXT DOING CHECK DONE レビューが必要なタスクはCHECKへ移動完了したら DONEへ移動

Slide 61

Slide 61 text

カンバンのイメージ TODO NEXT DOING CHECK DONE レビュー待ちタスクは優先して終わらせる

Slide 62

Slide 62 text

カンバンのイメージ TODO NEXT DOING CHECK DONE 完了

Slide 63

Slide 63 text

カンバンのイメージ TODO NEXT DOING CHECK DONE 終わらないタスクは全員で作戦会議

Slide 64

Slide 64 text

カンバンのイメージ TODO NEXT DOING CHECK DONE 分解して全員で対応

Slide 65

Slide 65 text

TODO NEXT DOING CHECK DONE カンバン作成完了

Slide 66

Slide 66 text

スウォーミングについて • 問題の周りに人が群がり（スウォーム）、すばやく解決して、通常の流れに戻ること。

Slide 67

Slide 67 text

カンバン効果 • スウォーミングの積極的導入により、ナレッジ移転がやりやすくなり・属人化タスクを削減できた。 • 「始めるのをやめて、終わらせることを始める」ことで、スイッチングコストを削減し、開発チームの生産力をアップすることができた。

Slide 68

Slide 68 text

開発プロセス見直しによる効果

Slide 69

Slide 69 text

開発プロセス見直しによる効果

Slide 70

Slide 70 text

開発プロセス見直し前 • 「ver5.3」開発プロジェクト • リリース日：2019/3 予定 • リリース日：2019/4 予定 • リリース日：2020/5 予定リスケリスケ

Slide 71

Slide 71 text

開発プロセス見直し後 • 「ver6.0」開発プロジェクト • リリース日：2019/11/10 • 「ver6.1」開発プロジェクト • リリース日：2020/01/28 • 「ver6.2」開発プロジェクト • リリース日：2020/03/末

Slide 72

Slide 72 text

開発チームの関心事の変化 • 開発プロセス変更前 • リソース効率を上げる。 • タスクを創出し続けて、開発メンバーの空きをつくらない。 • 開発プロセス変更後 • フロー効率を上げる。 • いかにタスクを分割し共同作業をすすめていくかを計画する。

Slide 73

Slide 73 text

開発チームのスタイルの変化 • フロー効率をあげるためには • 作業の流れを止めないように、ボトルネックを無くす。 • ボトルネックを無くすために、属人化タスクを無くす。 • 属人化タスクを無くすために、積極的に共同作業をする。 • 共同作業しやすいように、タスク分割・完了基準を明確化する。 • 共同作業により、学習しながら作業する開発スタイルに切り替わりつつある。

Slide 74

Slide 74 text

まとめ

Slide 75

Slide 75 text

まとめ • 無秩序な開発チームを「５S」活動で正常化。 • 「計画の不確実性」を「反復開発」で低減。 • スイッチングコストを「カンバン」で削減。

Slide 76

Slide 76 text

カンバンのオススメポイント • 開発が進むほど、計画の精度が上がる。 • スイッチングコストが削減できる。 • スウォーミング（共同作業）により開発チーム力がアップする。 • 導入コストが低い。