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

by Kazuki Higashiguchi

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

© 2012-2020 BASE, Inc. 4 The Failure of Agile “あれから14年が経ち、私たちは行き先を見失っています。 ”アジャイル”という言葉はスローガン化してしまいました。本来の意味をなさなくなっただけならまだいいですが、最悪に考えれば排外的な存在になってしまったとすら言えます。 2～3のソフトウェア開発のプラクティスを、不十分に生半可に試みるといった”軟弱なアジャイル”を行う人が数多く存在します。本来の目的を忘れて努力を重ねるといった、口先だけのアジャイルの狂信者がたくさんいるのです。 ” https://postd.cc/the-failure-of-agile/ アジャイルの破綻―原因、そして新たな提案（”The Failure of Agile” の翻訳）

Slide 5

Slide 5 text

© 2012-2020 BASE, Inc. 5 具体的なプラクティスへの固執 “初心者がこれに対応する唯一の方法は、コンテキストのない簡単なルールに従うことです。例えば、「これが起こったら、あれをする」といったようなルールです。ご丁寧なことに、アジャイル開発手法には初心者用にいくつかの具体的なプラクティスが提供されているため、初めてアジャイルを取り入れるチームは、これら全てもしくは一部に固執してしまい、凝り固まったやり方になってしまいます。彼らは、アジャイルの原則やアジャイル宣言の概要を尊重することなく、鉄則となっているプラクティスを入手するだけで、それ以上何もしないのです。 ” https://postd.cc/the-failure-of-agile/ アジャイルの破綻―原因、そして新たな提案（”The Failure of Agile” の翻訳）

Slide 6

Slide 6 text

© 2012-2020 BASE, Inc. 6 成功する「アジャイル開発の始め方」ってなんだろう ● チーム開発について考える際に、「アジャイル開発」のエッセンスを取り入れることは、思いつきがちだろう ● しかし、単に手法を取り入れるだけでは不十分なことは、The Failure of Agile でも示されている ● 様々な現場で実践されている分、Failureな体験をしてきた開発者も少なからずいるだろう ● そんな今、アジャイル開発を始めるために役に立つのは、正誤あるにしろ、現場で取り組まれた思考プロセスの事例ではないか

Slide 7

Slide 7 text

© 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

Slide 8

Slide 8 text

Slide 9

Slide 9 text

© 2012-2020 BASE, Inc. 9 ● 資金調達サービス「YELL BANK」など金融サービス（機能）を開発・運用 ● 新規サービスの開発から、稼働中サービスのグロース施策・問い合わせ対応など ● 機能横断的（backend/infra/frontend ...etc） ※ 適宜他チームと協同しながら ※ サービス実現のためのカバー範囲を広げていく方向へ About us: “少人数チーム”の特徴 BASE BANK Dev Team お急ぎ振込お急ぎ振込 ...etc ...etc PdM Developer EM Biz

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© 2012-2020 BASE, Inc. 11 アジャイルの適用は現状と向き合うところから https://www.oreilly.co.jp/books/9784873119090/ Matt LeMay　著、吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士　訳、及川卓也　まえがきみんなでアジャイル ―― 変化に対応できる顧客中心組織のつくりかた “成功するアジャイルの適用は、常に厳しく正直に現状を見ることから始まる。何がうまくいっていて、何がうまくいっていないのか。アジャイルを今の仕事のやり方をちょっと変えるだけのことと思っているなら、アジャイルから得られるメリットもちょっとだけになるだろう。” （2章自分たちの北極星を見つける）

Slide 12

Slide 12 text

© 2012-2020 BASE, Inc. 12 現状と向き合う - できていないこと期間・規模が大きいPJ中盤で中だるみ PdMが開発Directionまでやっているが、そろそろ厳しい（特定ロールの負荷） PJメンバー間の仕様や状況の認識ブレ良くも悪くも、個人の馬力でリリーススケジュールを実現している ...etc 現状の課題感を議論・言語化する ... ... WFH (Work From Home) でのコミュニケーション不足

Slide 13

Slide 13 text

Slide 14

Slide 14 text

© 2012-2020 BASE, Inc. 14 自分たちにとっての北極星を言語化する 1. メンバー: 個々人の達成感（成果を出せている・成長している感覚） 2. チーム全体: 関係各所との「約束」を守る（関係各所に宣言し、PJの現在地点を適宜振り返り、その状況を適切に共有する）自分たちの大事にしたい目標を議論・言語化するテンション上げた開発がしたいですよね、途中の中だるみとかを回避しつつ。うーん、ちゃんとリリースできて、エンジニアとして成長している実感が得られることを「生き生き」した開発だと思っていて、...

Slide 15

Slide 15 text

Slide 16

Slide 16 text

© 2012-2020 BASE, Inc. 16 アジャイルソフトウェア開発宣言 “アジャイルチームの基本的な仕事の進め方 1. 一つのチームとして働く 2. 短いイテレーションで作業する 3. イテレーションごとに成果を上げる 4. ビジネス上の優先度を重視する 5. 検査と適応” https://book.mynavi.jp/ec/products/detail/id=22141 Mike Cohn 著安井力、角谷信太郎訳 / アジャイルな見積りと計画づくり価値あるソフトウェアを育てる概念と技法

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

© 2012-2020 BASE, Inc. 22 北極星から優先度を考える Step1: 優先度から必要であろう方針を立てる ● 個々人の納得感と達成感のあるマイルストーン ● 重要マイルストーンに対するブレークダウンと見積もりの継続的評価 1. メンバー: 個々人の達成感（成果を出せている・成長している感覚） 2. チーム全体: 関係各所との「約束」を守る（関係各所に宣言し、PJの現在地点を適宜振り返り、その状況を適切に共有する）自分たちの北極星に近づくために必要なことは？ Step2: 具体的なアクションを決定 ● PJごとに、中間地点を定め、それをブレークダウンし、見積もる ● 短いイテレーションで作業するリズムへ ● チームとしての進行状況を、可視化する ● 振り返りによる継続評価

Slide 23

Slide 23 text

© 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 計画

Slide 24

Slide 24 text

© 2012-2020 BASE, Inc. 24 GitHub Projectを用いたカンバン管理 ● カンバンには、GitHub Project を利用 ● 課題解決スコープをあくまで「開発」に絞った（ビジネス的なIssueについては対象外へ） ○ 「今より少しでもマシになるならやってみよう」精神 ○ そのため、Developerの使い勝手などを重視 ● ストーリーポイントの可視化は、 banyan/github-story-points というブラウザ拡張を利用 ○ https://github.com/banyan/github-story-points

Slide 25

Slide 25 text

Slide 26

Slide 26 text

© 2012-2020 BASE, Inc. 26 WFH 下のレトロスペクティブ ● レトロスペクティブ（振り返り）を、オンラインで行うために Miro を利用 ● レトロスペクティブ内で行っていること ○ 振り返りワーク (ex. KPT、Mad Glad Sad) ○ 前回以前のレトロスペクティブで出た ActionItemの影響はどうだったか ※ Miro による Mad Glad Sadの様子

Slide 27

Slide 27 text

Slide 28

Slide 28 text

© 2012-2020 BASE, Inc. 28 開発プロジェクトにおける不確実性 Alexander Laufer の不確実性理論 ● 目標の不確実性 (end uncertainty) ○ 何を開発するのか、スコープ・プロダクトの性質 ● 方法の不確実性 (means uncertainty) ○ どうやって開発するのか、技術・スキル・連携方法 https://book.mynavi.jp/ec/products/detail/id=22141 Mike Cohn 著安井力、角谷信太郎訳 / アジャイルな見積りと計画づくり価値あるソフトウェアを育てる概念と技法 / 第3部価値のための計画づくり

Slide 29

Slide 29 text

Slide 30

Slide 30 text

© 2012-2020 BASE, Inc. 30 リリース計画を再考し、スプリントレビューを実施 ● スプリントごとのプロダクトに対するフィードバックを持って、さらに、方法の不確実性・目標の不確実性、を低減したい ● プロダクトに対するフィードバックを得るには、ホリゾンタルスライスではなく、バーティカルスライスによる、プロダクトタスクの切り分けが必要 ○ 捉える単位を作業ではなくユーザー視点の機能へ ● それを前提にした、リリース計画（リリースまでの段取り）を再考

Slide 31

Slide 31 text

© 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 計画スプリントレビュー

Slide 32

Slide 32 text

Slide 33

Slide 33 text

© 2012-2020 BASE, Inc. 33 組織重力の3つの法則 https://www.oreilly.co.jp/books/9784873119090/ Matt LeMay　著、吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士　訳、及川卓也　まえがきみんなでアジャイル ―― 変化に対応できる顧客中心組織のつくりかた 1. 組織の個人は、日々の責任ややる気を伴わない場合、顧客対応を避ける。 2. 組織の個人は、自分のチームやサイロの居心地のよさのなかでいちばん簡単に完了できる仕事を優先する。 3. 進行中のプロジェクトは、プロジェクトを承認した最上位者の決定がない限り続く。

Slide 34

Slide 34 text

© 2012-2020 BASE, Inc. 34 顧客対応（プロダクトサポート） ● スプリント中に発生した、問い合わせ対応やバグフィックスは、事前に計画できるものではない ● しかし、サービス運営会社のDeveloperとしてはとても重要な活動。「チームの速度の阻害要因」と捉えてしまわないようにしないといけない ● それ以外にも、採用活動や外部登壇なども、重要な外部要因スプリント計画時に、傾向をもとに、可処分な想定消化ポイントから、事前に引いておく（予測のズレは、振り返り、対策する）

Slide 35

Slide 35 text

Slide 36

Slide 36 text

© 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 自分たちが目指す目標と関連付けて”なぜ”やっているのか、を言語化する

Slide 37

Slide 37 text

© 2012-2020 BASE, Inc. 37 心理的な過負荷の検知 ● スプリント疲れ・一定期間来続けるリズム・イテレーションで成果を上げていくことへのプレッシャーが過負荷になってしまう ● 「2x6+1のリズム」など一般的な知見があるが、そもそもこの課題にどう気づくか ● 個人差があるようなものはチーム課題として顕在化しにくい潜在的課題チームの ”感情” に目を向ける BASE Developers’ Blog チーム開発の潜在的課題が見つかる振り返りワーク「Mad Glad Sad(喜、怒、哀)」 https://devblog.thebase.in/entry/2020/07/08/162359

Slide 38

Slide 38 text

Slide 39

Slide 39 text

© 2012-2020 BASE, Inc. 39 振り返り：課題に対して少しでも良くなっているか期間・規模が大きいPJ中盤で中だるみ PdMが開発Directionまでやっているが、そろそろ厳しい（特定ロールの負荷） PJメンバー間の仕様や状況の認識ブレ良くも悪くも、個人の馬力でリリーススケジュールを実現しているチームとしての協働をPJ早期から行えているペアプロなどによるそれぞれの知識の同期スプリント計画の合意とコミット・スプリントレビューにより緊張感の維持スプリント計画の過程での知識の同期スプリントレビューによる早期の認識ブレの修正ロールと個人が疎結合になり、個人がボトルネックになりにくくなった

Slide 40

Slide 40 text

© 2012-2020 BASE, Inc. 40 どうアジャイル開発に取り組んできたか ● 現状と向きあい、目指す方向を定め、それとアジャイル宣言・原則は同じ方向を向いていることを確認した ● 優先度に合わせた漸進的なプラクティスの適用を実施した ● 取り組んでいく中で、振り返りにより検査し、課題に対して対策を講じ、適応を試み続けている ● 当資料にdumpした思考プロセスが、次の誰かの一歩目に繋がれば幸いです

Slide 41

Slide 41 text

© 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

Slide 42

Slide 42 text

© 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

Slide 43

Slide 43 text

© 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