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
410
リリース後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
組織成長を加速させるオンボーディングの取り組み
sudoakiy
2
210
RubyのWebアプリケーションを50倍速くする方法 / How to Make a Ruby Web Application 50 Times Faster
hogelog
3
950
SRE×AIOpsを始めよう!GuardDutyによるお手軽脅威検出
amixedcolor
0
180
iOSチームとAndroidチームでブランチ運用が違ったので整理してます
sansantech
PRO
0
150
マルチプロダクトな開発組織で 「開発生産性」に向き合うために試みたこと / Improving Multi-Product Dev Productivity
sugamasao
1
310
AWS Lambdaと歩んだ“サーバーレス”と今後 #lambda_10years
yoshidashingo
1
180
いざ、BSC討伐の旅
nikinusu
2
780
【Startup CTO of the Year 2024 / Audience Award】アセンド取締役CTO 丹羽健
niwatakeru
0
1.3k
インフラとバックエンドとフロントエンドをくまなく調べて遅いアプリを早くした件
tubone24
1
430
安心してください、日本語使えますよ―Ubuntu日本語Remix提供休止に寄せて― 2024-11-17
nobutomurata
1
1k
Terraform Stacks入門 #HashiTalks
msato
0
360
Shopifyアプリ開発における Shopifyの機能活用
sonatard
4
250
Featured
See All Featured
Mobile First: as difficult as doing things right
swwweet
222
8.9k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
27
840
A designer walks into a library…
pauljervisheath
204
24k
How GitHub (no longer) Works
holman
310
140k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Put a Button on it: Removing Barriers to Going Fast.
kastner
59
3.5k
Building Your Own Lightsaber
phodgson
103
6.1k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
48k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
28
8.2k
Writing Fast Ruby
sferik
627
61k
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」活動で正常化。 • 「計画の不確実性」を「反復開発」で低減。 • スイッチングコストを「カンバン」で削減。
カンバンのオススメポイント • 開発が進むほど、計画の精度が上がる。 • スイッチングコストが削減できる。 • スウォーミング(共同作業)により開発チーム力がアッ プする。 • 導入コストが低い。
「始めることをやめて、終わら せることを始める」ことで
開発チーム力アップが アップしたという話でした。
ご静聴ありがとう ございました