少人数でのアジャイル開発への取り組み実例 （一歩目の踏みだし方） / a first step to agile movement

July Tech Festa #JTF2020 で発表した少人数でのアジャイル開発への取り組み実例についての資料です。
Google slide: https://docs.google.com/presentation/d/1qyufmgne7SCFA4wBs6Zz_6kAEy8btSp79ERR76nFJhY/edit?usp=sharing

Transcript

1. © 2012-2020 BASE, Inc. 1 少人数でのアジャイル開発への 取り組み実例 （一歩目の踏みだし方） 2020.07.25 July Tech Festa 2020 / Kazuki Higashiguchi (@hgsgtk) #JTF2020
2. © 2012-2020 BASE, Inc. 2 こんな方々に役に立ってほしい • 自身のチーム開発に漠然と課題感を持っている • アジャイルに興味があるが、一歩踏み出せていない • 過去、アジャイル開発を経験したが、“うまくいかなかった” • 比較的少人数の開発チームに所属している
3. © 2012-2020 BASE, Inc. 3 当発表は、チーム環境、に焦点を当てています https://blogs.itmedia.co.jp/hiranabe/2012/09/rightwing-and-leftwing-of-agile.html An Agile Way: アジャイルの「ライトウィング」と「レフトウィング」
4. © 2012-2020 BASE, Inc. 4 The Failure of Agile “あれから14年が経ち、私たちは行き先を見失っています。 ”アジャイル”という言葉はスローガン化し てしまいました。本来の意味をなさなくなっただけならまだいいですが、最悪に考えれば排外的な存在になってしまっ たとすら言えます。 2～3のソフトウェア開発のプラクティスを、不十分に生半可に試み るといった”軟弱なアジャイル”を行う人が数多く存在します。本来の目的を忘れて努力を重 ねるといった、口先だけのアジャイルの狂信者がたくさんいるのです。 ” https://postd.cc/the-failure-of-agile/ アジャイルの破綻―原因、そして新たな提案 （”The Failure of Agile” の翻訳）
5. © 2012-2020 BASE, Inc. 5 具体的なプラクティスへの固執 “初心者がこれに対応する唯一の方法は、コンテキストのない簡単なルールに従うことです。例えば、「これが起こったら、あれ をする」といったようなルールです。ご丁寧なことに、アジャイル開発手法には初心者用にいくつかの具体的なプラクティスが提 供されているため、 初めてアジャイルを取り入れるチームは、これら全てもしくは一部 に固執してしまい、凝り固まったやり方になってしまいます。 彼らは、アジャイルの原則やアジャイル宣言の概要を尊重することなく、鉄則となっているプラクティスを入手するだけで、それ 以上何もしないのです。 ” https://postd.cc/the-failure-of-agile/ アジャイルの破綻―原因、そして新たな提案 （”The Failure of Agile” の翻訳）
6. © 2012-2020 BASE, Inc. 6 成功する「アジャイル開発の始め方」ってなんだろう • チーム開発について考える際に、「アジャイル開発」のエッセンスを取り入れ ることは、思いつきがちだろう • しかし、単に手法を取り入れるだけでは不十分なことは、The Failure of Agile でも示されている • 様々な現場で実践されている分、Failureな体験をしてきた開発者も少なからず いるだろう • そんな今、アジャイル開発を始めるために役に立つのは、正誤あるにしろ、現 場で取り組まれた思考プロセス の事例ではないか
7. © 2012-2020 BASE, Inc. 7 • 東口　和暉 (Kazuki Higashiguchi) • GitHub / Twitter: @hgsgtk • BASE BANK, Inc. (BASE, Inc.) > Dev Division > Tech Lead • これまでの関心・外部発表 ◦ Unit Test(xUnit, TDD, xUTP) / Code design / Pattern language / Docker / CI / Server-side Architecture / Legacy Code / Agile ◦ https://speakerdeck.com/hgsgtk About me
8. © 2012-2020 BASE, Inc. 8 About us: 取り組み事例対象の”少人数”チーム データ戦略 Designers ※ 兼任 PdM Developer EM ※ 2020年6月4日時点 SRE ...etc Biz BASE BANK Dev Team frontend/backend
9. © 2012-2020 BASE, Inc. 9 • 資金調達サービス「YELL BANK」など金融サービス （機能）を開発・運用 • 新規サービスの開発から、稼働中サービスのグロー ス施策・問い合わせ対応 など • 機能横断的（backend/infra/frontend ...etc） ※ 適宜他チームと協同しながら ※ サービス実現のためのカバー範囲を広げていく方向へ About us: “少人数チーム”の特徴 BASE BANK Dev Team お急ぎ振込 お急ぎ振込 ...etc ...etc PdM Developer EM Biz
10. © 2012-2020 BASE, Inc. 10 取り組み前夜 Photo by Vincent Chin on Unsplash • 現状と向き合う • 自分たちの北極星を定める • アジャイル開発に取り組むか
11. © 2012-2020 BASE, Inc. 11 アジャイルの適用は現状と向き合うところから https://www.oreilly.co.jp/books/9784873119090/ Matt LeMay　著、吉羽 龍太郎、永瀬 美穂、原田 騎郎、有野 雅士　訳、及川 卓也　まえがき みんなでアジャイル ―― 変化に対応できる顧客中心組織のつくりかた “成功するアジャイルの適用は、常に厳しく正直に現状を見ることから 始まる。何がうまくいっていて、何がうまくいっていないのか。アジャイ ルを今の仕事のやり方をちょっと変えるだけのことと思っているなら、 アジャイルから得られるメリットもちょっとだけになるだろう。” （2章 自分たちの北極星を見つける）
12. © 2012-2020 BASE, Inc. 12 現状と向き合う - できていないこと 期間・規模が大きいPJ中盤で中だるみ PdMが開発Directionまでやっているが、 そろそろ厳しい（特定ロールの負荷） PJメンバー間の仕様や状況の認識ブレ 良くも悪くも、個人の馬力でリリーススケ ジュールを実現している ...etc 現状の課題感を議論・言語化する ... ... WFH (Work From Home) でのコミュニ ケーション不足
13. © 2012-2020 BASE, Inc. 13 自分たちの北極星を定める fukabori.fm 32. みんなでアジャイル w/ ryuzee https://podplayer.net/?id=104223290 “季節が移り変わっても北極星の位置が変わらないように、状 況が変わり時間が経っても変わらない、自分たちが大事にした い・目指したい目標。”
14. © 2012-2020 BASE, Inc. 14 自分たちにとっての北極星を言語化する 1. メンバー: 個々人の達成感 （成果を出せている・成長している感覚） 2. チーム全体: 関係各所との「約束」を守る （関係各所に宣言し、PJの現在地点を適宜振り返り、その状況を適切 に共有する） 自分たちの大事にしたい目標を議論・言語化する テンション上げた開発がしたいですよ ね、途中の中だるみとかを回避しつつ。 うーん、ちゃんとリリースできて、エンジニア として成長している実感が得られることを「生 き生き」した開発だと思っていて、...
15. © 2012-2020 BASE, Inc. 15 アジャイルソフトウェア開発宣言 “プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を” Manifesto for Agile Software Development / https://agilemanifesto.org/
16. © 2012-2020 BASE, Inc. 16 アジャイルソフトウェア開発宣言 “アジャイルチームの基本的な仕事の進め方 1. 一つのチームとして働く 2. 短いイテレーションで作業する 3. イテレーションごとに成果を上げる 4. ビジネス上の優先度を重視する 5. 検査と適応” https://book.mynavi.jp/ec/products/detail/id=22141 Mike Cohn 著 安井 力、角谷信太郎 訳 / アジャイルな見積りと計画づくり 価値あるソフト ウェアを育てる概念と技法
17. © 2012-2020 BASE, Inc. 17 アジャイル開発に取り組むか • 短いイテレーションで成果を上げていく仕事の進め方は、個々 人の達成感に大きく寄与する • 検査と適応による変化への対応は、関係各所との約束（コミュ ニケーション、見積もり）に対する信頼度に寄与する • 対話（コミュニケーション）を重視する方針は、WFHでのプロ ダクト開発にマッチしそう
18. © 2012-2020 BASE, Inc. 18 やらなかったこと • 「アジャイル開発をしましょう」とは言わなかった ◦ 人によって「アジャイル」の解釈が異なる。 “WHY” を共有する上では、その 言葉が足かせになる可能性を感じた ◦ アジャイル開発がやりたいわけではなくて、チーム課題を 解決したい • 「アジャイル開発の手法」に固執してしまわないように
19. © 2012-2020 BASE, Inc. 19 アジャイルに 取り組む 1. チーム自身の検査と適応 2. プロダクトに対する検査と適応
20. © 2012-2020 BASE, Inc. 20 自分たちの優先度に沿った漸進的なプラクティス導入 自分たちの優先度に沿って、「まずこれを始めよう」とピックアップして始めた 結果的に、次の順番になった 1. チーム自身の検査と適応 2. プロダクトに対する検査と適応 まず、チーム自身に対する、検査と適応のリズムが生まれることを優先
21. © 2012-2020 BASE, Inc. 21 Phase1. チーム自身の検査と適応
22. © 2012-2020 BASE, Inc. 22 北極星から優先度を考える Step1: 優先度から必要であろう方針 を立てる • 個々人の納得感と達成感のあるマイルストーン • 重要マイルストーンに対するブレークダウンと 見積もりの継続的評価 1. メンバー: 個々人の達成感 （成果を出せている・成長している感覚） 2. チーム全体: 関係各所との「約束」を守 る （関係各所に宣言し、PJの現在地点を適宜振り返り、その 状況を適切に共有する） 自分たちの北極星に近づくために必要なことは？ Step2: 具体的なアクションを決定 • PJごとに、中間地点を定め、それをブレークダウン し、見積もる • 短いイテレーションで作業するリズムへ • チームとしての進行状況を、可視化する • 振り返りによる継続評価
23. © 2012-2020 BASE, Inc. 23 Phase1 - チーム自身の検査と適応 の実装 Project A Project B Release Milestone Issue Sprint 顧客問い合わせ 対応 Bug Fix Other ビジネス優先度 の高い機能 将来のPJの 阻害要因の改善 レトロ スペク ティブ Out of Planning ※ エンドユーザーに 実際に届ける粒度 ※ このくらいの期間に 「ここまでいければ」 というまとまり Backlog Daily standing Story Point カンバン管理 Sprint 計画
24. © 2012-2020 BASE, Inc. 24 GitHub Projectを用いたカンバン管理 • カンバンには、GitHub Project を利用 • 課題解決スコープをあくまで「開発」に絞った（ビジネス的なIssueについては 対象外へ） ◦ 「今より少しでもマシになるならやってみよう」精神 ◦ そのため、Developerの使い勝手などを重視 • ストーリーポイントの可視化は、 banyan/github-story-points というブラウ ザ拡張を利用 ◦ https://github.com/banyan/github-story-points
25. © 2012-2020 BASE, Inc. 25 カンバンチラ見せ • banyan/github-story-points では、[1pt] とissue/pr/cardのタイトルに設定 することで、ストーリーポイントとして可視化する • 毎イテレーションごとにレーンを残して消化ポイントを記録、のちのベロシ ティ計測へ活かす
26. © 2012-2020 BASE, Inc. 26 WFH 下のレトロスペクティブ • レトロスペクティブ（振り返り）を、オンラインで行うために Miro を利用 • レトロスペクティブ内で行っていること ◦ 振り返りワーク (ex. KPT、Mad Glad Sad) ◦ 前回以前のレトロスペクティブで出た ActionItemの影響はどうだったか ※ Miro による Mad Glad Sadの様子
27. © 2012-2020 BASE, Inc. 27 Phase2. プロダクトに対する検査と適応
28. © 2012-2020 BASE, Inc. 28 開発プロジェクトにおける不確実性 Alexander Laufer の不確実性理論 • 目標の不確実性 (end uncertainty) ◦ 何を開発するのか、スコープ・プロダクトの性質 • 方法の不確実性 (means uncertainty) ◦ どうやって開発するのか、技術・スキル・連携方法 https://book.mynavi.jp/ec/products/detail/id=22141 Mike Cohn 著 安井 力、角谷信太郎 訳 / アジャイルな見積りと計画づくり 価値あるソフト ウェアを育てる概念と技法 / 第3部 価値のための計画づくり
29. © 2012-2020 BASE, Inc. 29 チーム→プロダクトの作り方へ • スプリント期間は、初回 2days、以降は1weekで回していった • 北極星に向かっていくためのリズムが定着してきた ◦ → チームの連携方法に対する慣れ、方法の不確実性が低減 • 目標の不確実性 の低減への着手の必要性から、プロダクト作り に対する検査と適応へ
30. © 2012-2020 BASE, Inc. 30 リリース計画を再考し、スプリントレビューを実施 • スプリントごとのプロダクトに対するフィードバックを持って、さらに、方法 の不確実性・目標の不確実性、を低減したい • プロダクトに対するフィードバックを得るには、ホリゾンタルスライスではな く、バーティカルスライスによる、プロダクトタスクの切り分けが必要 ◦ 捉える単位を作業ではなくユーザー視点の機能へ • それを前提にした、リリース計画（リリースまでの段取り）を再考
31. © 2012-2020 BASE, Inc. 31 Phase2 - プロダクトに対する検査と適応 の実装 Project A Project B Release User Story Sprint 顧客問い合わせ 対応 Bug Fix Other ビジネス優先度 の高い機能 将来のPJの 阻害要因の改善 レトロ スペク ティブ Out of Planning ※ エンドユーザーに 実際に届ける粒度 ※ バーティカルスライス によるユーザー視点の機能 Backlog Daily standing Story Point カンバン管理 Sprint 計画 スプリン ト レビュー
32. © 2012-2020 BASE, Inc. 32 Photo by Javier Esteban on Unsplash 課題と適応 • 顧客対応（プロダクトサポート） • プラクティスに対する認識差異 • 心理的な過負荷の検知
33. © 2012-2020 BASE, Inc. 33 組織重力の3つの法則 https://www.oreilly.co.jp/books/9784873119090/ Matt LeMay　著、吉羽 龍太郎、永瀬 美穂、原田 騎郎、有野 雅士　訳、及川 卓也　まえがき みんなでアジャイル ―― 変化に対応できる顧客中心組織のつくりかた 1. 組織の個人は、日々の責任ややる気を伴わない場合、顧客対応 を避ける。 2. 組織の個人は、自分のチームやサイロの居心地のよさのなかでいちばん簡単に 完了できる仕事を優先する。 3. 進行中のプロジェクトは、プロジェクトを承認した最上位者の決定がない限り 続く。
34. © 2012-2020 BASE, Inc. 34 顧客対応（プロダクトサポート） • スプリント中に発生した、問い合わせ対応やバグフィックスは、事前に計画で きるものではない • しかし、サービス運営会社のDeveloperとしてはとても重要な活動。「チーム の速度の阻害要因」と捉えてしまわないようにしないといけない • それ以外にも、採用活動や外部登壇なども、重要な外部要因 スプリント計画時に、傾向をもとに、可処分な想定消化ポイントから、事前に引 いておく（予測のズレは、振り返り、対策する）
35. © 2012-2020 BASE, Inc. 35 プラクティスに対する認識差異 • プラクティスについては一般的な ”アジャイルの用語” を用いていたが、それを 何故やっているのか、について認識の差異が生まれた • 採用や社内調整などで、新たに開発メンバーがJOINした際に顕在化 自分たちの “語彙” を育てていく
36. © 2012-2020 BASE, Inc. 36 自分たちの “語彙” を育てていく . ├── README.md ├── coding_rule.md └── lively_development ├── README.md ├── daily_standup.md ├── flow_by_iteration.md ├── god_document.md ├── kpt.md ├── mad_glad_sad.md ├── pair_programming.md ├── planning_poker.md ├── retrospective.md ├── sprint_planning.md ├── sprint_review.md └── template.md 自分たちが目指す目標と関連付けて”なぜ”やっているのか、を言語化する
37. © 2012-2020 BASE, Inc. 37 心理的な過負荷の検知 • スプリント疲れ・一定期間来続けるリズム・イテレーションで成果を上げてい くことへのプレッシャーが過負荷になってしまう • 「2x6+1のリズム」など一般的な知見があるが、そもそもこの課題にどう気づ くか • 個人差があるようなものはチーム課題として顕在化しにくい潜在的課題 チームの ”感情” に目を向ける BASE Developers’ Blog チーム開発の潜在的課題が見つかる振り返りワーク「Mad Glad Sad(喜、怒、哀)」 https://devblog.thebase.in/entry/2020/07/08/162359
38. © 2012-2020 BASE, Inc. 38 Photo by Bobby Burch on Unsplash まとめ
39. © 2012-2020 BASE, Inc. 39 振り返り： 課題に対して少しでも良くなっているか 期間・規模が大きいPJ中盤で中だるみ PdMが開発Directionまでやっているが、 そろそろ厳しい（特定ロールの負荷） PJメンバー間の仕様や状況の認識ブレ 良くも悪くも、個人の馬力でリリース スケジュールを実現している チームとしての協働をPJ早期から行えている ペアプロなどによるそれぞれの知識の同期 スプリント計画の合意とコミット・スプリントレ ビューにより緊張感の維持 スプリント計画の過程での知識の同期 スプリントレビューによる早期の認識ブレの修正 ロールと個人が疎結合になり、個人がボトルネックにな りにくくなった
40. © 2012-2020 BASE, Inc. 40 どうアジャイル開発に取り組んできたか • 現状と向きあい、目指す方向を定め、それとアジャイル宣言・原則は同じ方向 を向いていることを確認した • 優先度に合わせた漸進的なプラクティスの適用を実施した • 取り組んでいく中で、振り返りにより検査し、課題に対して対策を講じ、適応 を試み続けている • 当資料にdumpした思考プロセスが、次の誰かの一歩目に繋がれば幸いです
41. © 2012-2020 BASE, Inc. 41 参考文献 • みんなでアジャイル ―― 変化に対応できる顧客中心組織のつくりかた / Matt LeMay　著、吉羽 龍太郎、永瀬 美 穂、原田 騎郎、有野 雅士　訳、及川 卓也　まえがき ◦ https://www.oreilly.co.jp/books/9784873119090/ • More Effective Agile “ソフトウェアリーダー”になるための28の道標 / Steve McConnell (著), クイープ (翻訳), 長 沢 智治 (監修) ◦ https://www.amazon.co.jp/dp/B089KFKB5H • アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き / ＥｓｔｈｅｒＤｅｒｂｙ (著), ＤｉａｎａＬａｒｓｅｎ (著), 角征典 (翻訳) ◦ https://devblog.thebase.in/entry/2020/07/08/162359 • アジャイルな見積りと計画づくり 価値あるソフトウェアを育てる概念と技法 / Mike Cohn 著 安井 力、角谷信太郎 訳 ◦ https://book.mynavi.jp/ec/products/detail/id=22141
42. © 2012-2020 BASE, Inc. 42 参考文献 • 「組織の構成要素は人ではない! 」 渡邉　信光 ◦ https://b-p-i-a.com/?p=709 • アジャイルの破綻―原因、そして新たな提案 （”The Failure of Agile” の翻訳） ◦ https://postd.cc/the-failure-of-agile/ • Manifesto for Agile Software Development ◦ https://agilemanifesto.org/ • fukabori.fm 32. みんなでアジャイル w/ ryuzee ◦ https://podplayer.net/?id=104223290 • An Agile Way: アジャイルの「ライトウィング」と「レフトウィング」 ◦ https://blogs.itmedia.co.jp/hiranabe/2012/09/rightwing-and-leftwing-of-agile.html
43. © 2012-2020 BASE, Inc. 43 参考文献 • BASE Developers’ Blog チーム開発の潜在的課題が見つかる振り返りワーク「Mad Glad Sad(喜、怒、哀)」 by hgsgtk ◦ https://devblog.thebase.in/entry/2020/07/08/162359 • 小さなチームが始めたアジャイル開発 (2020.06.04 presented by hgsgtk) ◦ https://speakerdeck.com/hgsgtk/small-team-begun-agile-movement