Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
「始めるのをやめて、終わらせることを始める」ことを始めた開発チームの話 / Rakus Mee...
Search
kyoshimoto
February 05, 2020
Technology
17
9k
「始めるのをやめて、終わらせることを始める」ことを始めた開発チームの話 / Rakus Meetup Osaka 2020-02-05
Rakus Meetup Osaka #5 の発表資料です。
https://rakus.connpass.com/event/182082/
kyoshimoto
February 05, 2020
Tweet
Share
More Decks by kyoshimoto
See All by kyoshimoto
視座とアジャイル / shiza_and_agile
kyoshimoto
0
400
リリース後21年目になる レガシーサービスにLaravelを導入した話 / PHPTechCafe-2022-01-26
kyoshimoto
0
410
13年続くレガシーサービスを安全にリリースし続けるためのテスト戦略 / rakus-meetup-osaka-vol8-2020-08-05
kyoshimoto
4
1.9k
Chatdealerの高速開発を支えるLaravel
kyoshimoto
0
2.1k
Other Decks in Technology
See All in Technology
Apple/Google/Amazonの決済システムの違いを踏まえた定期購読課金システムの構築 / abema-billing-system
cyberagentdevelopers
PRO
1
210
【技術書典17】OpenFOAM(自宅で極める流体解析)2次元円柱まわりの流れ
kamakiri1225
0
210
カメラを用いた店内計測におけるオプトインの仕組みの実現 / ai-optin-camera
cyberagentdevelopers
PRO
1
120
Automated Promptingを目指すその前に / Before we can aim for Automated Prompting
rkaga
0
110
VPC間の接続方法を整理してみた #自治体クラウド勉強会
non97
1
810
ExaDB-D dbaascli で出来ること
oracle4engineer
PRO
0
3.6k
バクラクにおける可観測性向上の取り組み
yuu26
3
410
WINTICKETアプリで実現した高可用性と高速リリースを支えるエコシステム / winticket-eco-system
cyberagentdevelopers
PRO
1
190
分布で見る効果検証入門 / ai-distributional-effect
cyberagentdevelopers
PRO
4
690
AWS re:Inventを徹底的に楽しむためのTips / Tips for thoroughly enjoying AWS re:Invent
yuj1osm
1
550
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
5
49k
わたしとトラックポイント / TrackPoint tips
masahirokawahara
1
240
Featured
See All Featured
Ruby is Unlike a Banana
tanoku
96
11k
It's Worth the Effort
3n
183
27k
The Language of Interfaces
destraynor
154
24k
Making the Leap to Tech Lead
cromwellryan
132
8.9k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5k
How to Think Like a Performance Engineer
csswizardry
19
1.1k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
328
21k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
A Tale of Four Properties
chriscoyier
156
23k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.1k
RailsConf 2023
tenderlove
29
880
Art, The Web, and Tiny UX
lynnandtonic
296
20k
Transcript
始めるのをやめて 終わらせることを始める 開発チームの話 RAKUS Meetup Osaka #5 株式会社ラクス 吉元和仁
自己紹介 • 所属・氏名 • 株式会社ラクス 第二開発部 • 吉元和仁(よしもとかずひと) • 仕事
• メール配信サービス「配配メール」の開発担当
話すこと • 開発チームが抱える問題を原理原則から紐解き、「始め るのをやめて、終わらせることを始める」ことで、開発 チーム力アップに取り組んでいます。 • 開発チームの改善の取り組み、「カンバン」によるシス テム開発の不確実性との向き合い方など、システム開発 の原理原則をおりまぜてご紹介します。
Agenda 1. 無秩序な開発チームと割れ窓理論 2. 計画の不確実性の話 3. マルチタスクの話 4. 開発プロジェクトを見直した話 5.
まとめ
無秩序な開発チームと 割れ窓理論
1年半前
開発チームの構成 マネジメント 開発メンバー I joined
開発チームの課題
ルールやチェックリストが 形骸化
ずさんなドキュメント管理
無秩序なウォータフォール 要 件 定 義 概 要 設 計 詳
細 設 計 実 装 受 入 結 合 試 験
割れ窓理論
割れ窓理論とは 建物の窓ガラスが 割れたまま放置されていると、 管理人がいないと思われ 凶悪な犯罪が増えるという理論。 ジョージ・ケリング (米国の心理学者)
開発チーム 正常化プロジェクト発足
5S活動 5S 整理 整頓 清掃 清潔 躾
改善内容 • ドキュメント・ルールを徹底的に整備・整頓。 • 開発工程の定義書を作成して、スコープや完了基準を明 文化。
活動の成果 • チェックシート整理できた。 • ドキュメントがすぐに見つけれるようになった。 • 開発プロセスが正常化できた。 (ウォーターフォール型の開発ができるようになった)
特にしつけが重要 5S 整理 整頓 清掃 清潔 躾
チェックシートを 印刷して毎日回覧
計画の不確実性の話
5S活動後に見えてきた 開発チームの課題 21
リリーススケジュール 延期が慢性化 22
永遠の進捗90% 23
ホフスタッタの法則 • いつでも予測以上の時間がかかるものである。 • ホフスタッタの法則を計算に入れても。 ダグラス・ホフスタッタ (認知科学者・人工知能学者)
90対90の法則 コードの最初の90%が開発時間の 90%を占め、残りの10%がさら に90%を占める。 トム・カーギル (ベル研究所)
計画どおり進めることは 難しいんです
なぜ計画が難しいのか?
計画の不確実性 • コードと深く向き合っている人でしかわからないことが 多い。
計画の不確実性 • 楽観主義などの要因により、コストを低く見積もる傾向 がある。 書籍「人月の神話」より
悲観的に見積もるべきか?
計画の不確実性 • 仕事の量は、完成のために与えられた時間をすべて満た すまで膨張する。 「パーキンソンの法則」より シリル・ノースコート・パーキンソン (英国の歴史学者・政治学者)
計画の不確実性 • 見積りは、あくまで予測です。 • 予測を「ノルマ」にした途端、それを達成するための過 負荷な労働が生まれ、クオリティが下がってしまいます。 • あるいは、スケジュールの予測精度はどんどん下がって しまいます。 書籍「エンジニア組織論への招待」より
計画の不確実性 • 「ノルマ」にした結果 • 計画を守るための周りのプレッシャーに負け、予定 通りと報告してしまう。 • その後、ある段階で、現実を受け入れなければなら ない重要なポイントに到達する。
計画の不確実性 - 2020年ふるさと納税返礼品 “おせち” 届かない問題 https://www.tokyo-np.co.jp/article/ibaraki/list/202001/CK2020010702000139.html
計画の不確実性 • 2011年グルーポンおせち問題 https://gigazine.net/news/20110105_groupon_osechi/
計画の不確実性 • 大抵の計画は不確定要素を含んでおり、その通りになる ことはほとんどない。 • 計画づくりをするのに十分な情報がまだなく、理解も足 りていなかったとしたら、状況が進む中でわかったこと をもとに計画を変えていくべきはずだろう。 書籍「正しいものを正しくつくる」より
計画の不確実性 https://agilemanifesto.org/iso/ja/manifesto.html
所感 • とは言っても、計画は事業部門が絡む話であり、計画な をなくすことは難しい。 • 「計画」は「予測」と認識した上で、プロジェクト終盤 にかけて予測が収束していくことを管理するのが大事。
マルチタスクの話
開発チームに JOINして半年後
コアメンバーの異動 マネジメント 開発メンバー
マネージャと若手メンバーJOIN マネジメント 開発メンバー
総勢10名体制
コアメンバーにタスクが集中
進むマルチタスク化 案件A 案件B 管理職からの依頼 案件B 若手のフォロー 若手向けタスク創出 管理職の質問対応 管理職の質問対応 案件C
管理職から圧力 案件A 案件C アラート通知対応
マルチタスクについて • 人間はマルチタスクをこなせない。 • シングルタスクの切り替えをしているに過ぎない。 エヤル・オフィル (スタンフォード大学 神経学者)
マルチタスクについて • マルチタスクは生産性が低い。 • それぞれのタスクに集中できていないので、結局やりと げるまでに時間がかかる。 • 注意力散漫になっているためにエラー が増えること。 書籍「スタンフォード式最高のリーダー
シップ」より
開発プロセス見直し プロジェクト発足
反復開発導入
反復開発について • プロジェクトを「1週間のタイムボックス」に分割し、計 画、実行、振り返りを繰り返し行う開発。
反復開発について 1週間タイムボックス 水 木 金 土 日 月 火 開発メンバーと作戦会議
(1.5h) ふりかえり(1.5h) 朝会(15分) 次週のタスク準備(1.5h) 開発時間 マネージャーと作戦会議 (1h)
反復開発による効果 • 毎週、計画・振り返りを実施するので、プロジェクトが 進むにつれて、計画の不確実性が低減することができた。
カンバン導入
カンバンについて • カンバンの原則 • 見える化 • WIPの制限 • 流れの管理
カンバンの基本 • 「始めるのをやめて、終わらせることを始める」 書籍「カンバン仕事術」より
実際のカンバン
カンバンのイメージ TODO NEXT DOING CHECK DONE 1週間分のタスクを TODOへ アバターを準備する
カンバンのイメージ TODO NEXT DOING CHECK DONE 今日実施予定のタスクを NEXTへ
カンバンのイメージ TODO NEXT DOING CHECK DONE 着手するタスクは アバターをつけて DOINGへ
カンバンのイメージ TODO NEXT DOING CHECK DONE レビューが必要なタス クはCHECKへ移動 完了したら DONEへ移動
カンバンのイメージ TODO NEXT DOING CHECK DONE レビュー待ちタスクは 優先して終わらせる
カンバンのイメージ TODO NEXT DOING CHECK DONE 完了
カンバンのイメージ TODO NEXT DOING CHECK DONE 終わらないタスクは 全員で作戦会議
カンバンのイメージ TODO NEXT DOING CHECK DONE 分解して全員で対応
TODO NEXT DOING CHECK DONE カンバン作成 完了
スウォーミングについて • 問題の周りに人が群がり(スウォーム)、すばやく解決 して、通常の流れに戻ること。
カンバン効果 • スウォーミングの積極的導入により、ナレッジ移転がや りやすくなり・属人化タスクを削減できた。 • 「始めるのをやめて、終わらせることを始める」ことで、 スイッチングコストを削減し、開発チームの生産力を アップすることができた。
開発プロセス見直しによる効果
開発プロセス見直しによる効果
開発プロセス見直し前 • 「ver5.3」開発プロジェクト • リリース日:2019/3 予定 • リリース日:2019/4 予定 •
リリース日:2020/5 予定 リスケ リスケ
開発プロセス見直し後 • 「ver6.0」開発プロジェクト • リリース日:2019/11/10 • 「ver6.1」開発プロジェクト • リリース日:2020/01/28 •
「ver6.2」開発プロジェクト • リリース日:2020/03/末
開発チームの関心事の変化 • 開発プロセス変更前 • リソース効率を上げる。 • タスクを創出し続けて、開発メンバーの空きをつくらない。 • 開発プロセス変更後 •
フロー効率を上げる。 • いかにタスクを分割し共同作業をすすめていくかを計画する。
開発チームのスタイルの変化 • フロー効率をあげるためには • 作業の流れを止めないように、ボトルネックを無くす。 • ボトルネックを無くすために、属人化タスクを無くす。 • 属人化タスクを無くすために、積極的に共同作業をする。 •
共同作業しやすいように、タスク分割・完了基準を明確化する。 • 共同作業により、学習しながら作業する開発スタイルに切り替わり つつある。
まとめ
まとめ • 無秩序な開発チームを「5S」活動で正常化。 • 「計画の不確実性」を「反復開発」で低減。 • スイッチングコストを「カンバン」で削減。
カンバンのオススメポイント • 開発が進むほど、計画の精度が上がる。 • スイッチングコストが削減できる。 • スウォーミング(共同作業)により開発チーム力がアッ プする。 • 導入コストが低い。
「始めることをやめて、終わら せることを始める」ことで
開発チーム力アップが アップしたという話でした。
ご静聴ありがとう ございました