われわれはなぜアジャイルに向かうのか
- 1. Toshihiro Ichitani All Rights Reserved. われわれはなぜ アジャイルに向かうのか Ichitani Toshihiro 市⾕聡啓 開発をアジャイルにしていくために 読むべき最初の⼿引き
- 2. Toshihiro Ichitani All Rights Reserved. http://about.me/papanda0806 Ichitani Toshihiro 市⾕聡啓 ソフトウェア開発16年 SIer→サービス→受託→起業 仮説検証とアジャイル開発 ギルドワークス株式会社 代表 株式会社 エナジャイル 代表 ⼀般社団法⼈ 越境アジャイルアライアンス代表理事 DevLOVE コミュニティ ファウンダ 0 → 1
- 3. Copyright (c) 2017 Guild Works Inc. 皆さんは、アジャイル開発という⾔葉に 様々な場⾯で既に遭遇しているかと思います。 どんな⾯持ちでしょう？
- 4. Copyright (c) 2017 Guild Works Inc. 皆さんは、アジャイル開発という⾔葉に 様々な場⾯で既に遭遇しているかと思います。 どんな⾯持ちでしょう？ 「取り組んでいるが上⼿くやれているか分からない」 「アジャイル開発？今更(笑」
- 5. Copyright (c) 2017 Guild Works Inc. 皆さんは、アジャイル開発という⾔葉に 様々な場⾯で既に遭遇しているかと思います。 どんな⾯持ちでしょう？ 「取り組んでいるが上⼿くやれているか分からない」 「アジャイル開発？今更(笑」 アジャイルに向き合うのに今更も へったくれもありません！
- 6. Copyright (c) 2017 Guild Works Inc. なぜなら、アジャイルとは度合いだから。 “アジャイル開発”という実体があるわけではない。 (歴史的な成り⽴ちからして)
- 7. Copyright (c) 2017 Guild Works Inc. なぜなら、アジャイルとは度合いだから。 “アジャイル開発”という実体があるわけではない。 (歴史的な成り⽴ちからして) 実体としては「XP」「スクラム」「リーン開発」 などがよく挙がる。 そして、 「そのチームにとっての開発のあり⽅、やり⽅」も ”アジャイルな開発”と⾔える。
- 8. Copyright (c) 2017 Guild Works Inc. 度合いって何のこと？ 少しずつ反復的に開発を進めることで 必要とする⼈から必要なフィードバックを得て 調整し続けられる開発 →“アジャイルさ” = 「変化に適応できる度合い」 ⼀⾔でアジャイルな開発を表現すると (共通的な特徴は) http://gihyo.jp/dev/serial/01/agile 「アジャイル開発者の習慣」
- 9. Copyright (c) 2017 Guild Works Inc. 皆さんは、アジャイル開発という⾔葉に 様々な場⾯で既に遭遇しているかと思います。 どんな⾯持ちでしょう？ 「取り組んでいるが上⼿くやれているか分からない」 「アジャイル開発？今更w」 アジャイルに向き合うのに今更も へったくれもありません！ この時間では、アジャイルな開発とは何か あらためて問い、どのように向き合っていくか をテーマに致します。
- 10. Copyright (c) 2017 Guild Works Inc. 本⽇のテーマ なぜ、アジャイルに向かうのか。 背景 よくある問題 乗り越える
- 11. Copyright (c) 2017 Guild Works Inc. 関係者それぞれの期待が異なり、 出来たモノと違っていたと分かった。
- 12. Copyright (c) 2017 Guild Works Inc. 関係者それぞれの期待が異なり、 出来たモノと違っていたと分かった。 システムテストに⾄るまで、完成品が 確認できなかった。結果、最後の調整が膨⼤に。
- 13. Copyright (c) 2017 Guild Works Inc. 関係者それぞれの期待が異なり、 出来たモノと違っていたと分かった。 システムテストに⾄るまで、完成品が 確認できなかった。結果、最後の調整が膨⼤に。 でも、考えていること、期待していることを ドキュメントですべて表現できない。
- 14. Copyright (c) 2017 Guild Works Inc. 関係者それぞれの期待が異なり、 出来たモノと違っていたと分かった。 システムテストに⾄るまで、完成品が 確認できなかった。結果、最後の調整が膨⼤に。 でも、考えていること、期待していることを ドキュメントですべて表現できない。 最後のテストで、技術的な問題噴出。
- 15. Copyright (c) 2017 Guild Works Inc. 関係者それぞれの期待が異なり、 出来たモノと違っていたと分かった。 システムテストに⾄るまで、完成品が 確認できなかった。結果、最後の調整が膨⼤に。 でも、考えていること、期待していることを ドキュメントですべて表現できない。 最後のテストで、技術的な問題噴出。 構想してから、市場に投⼊するまでの 期間が⻑すぎる。
- 16. Copyright (c) 2017 Guild Works Inc. 関係者それぞれの期待が異なり、 出来たモノと違っていたと分かった。 システムテストに⾄るまで、完成品が 確認できなかった。結果、最後の調整が膨⼤に。 でも、考えていること、期待していることを ドキュメントですべて表現できない。 最後のテストで、技術的な問題噴出。 構想してから、市場に投⼊するまでの 期間が⻑すぎる。 アジャイルに向かう意義が⼗分にある
- 17. Copyright (c) 2017 Guild Works Inc. アジャイルな開発のプロセス的な特徴 少しずつ反復的に開発を進めることで 必要とする⼈から必要なフィードバックを得て 調整し続けられる開発
- 18. Copyright (c) 2017 Guild Works Inc. リリーステスト実装設計 フェーズゲート開発 アジャイルな開発 要件定義 開発された ボリューム
- 19. Copyright (c) 2017 Guild Works Inc. アジャイルな開発のプロセス的な特徴 少しずつ反復的に開発を進めることで 必要とする⼈から必要なフィードバックを得て 調整し続けられる開発 「インクリメンタル」(少しずつ) 「イテレーティブ」(繰り返し) つまり「早く(少しだけ)形にできる」やり⽅
- 20. Copyright (c) 2017 Guild Works Inc. 早く(少しだけ)形にできることの意義 フィードバックに基づく調整で、⽬的に適した ソフトウェアに仕⽴てられる 形にすることで早めに関係者の認識を揃えられる つくるものやチームについての問題早く気付ける チームの学習効果が⾼い 早く始められる 結合のリスクを早めに倒せる Time to market が短い サンクコストが⼩さくできる 開発チームのリズムを整えられる ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨
- 21. Copyright (c) 2017 Guild Works Inc. 形にすることで早めに関係者の認識を揃えられる そもそも、関係者(ビジネス側、ビジネスとチーム間、 チーム内で)つくるものの解釈が異なっている。 最初から、完成型が構想できない。 誰かが正解を持っているわけではない。 ドキュメントですべてを書き尽くせない。 それはコードになる。 「形にするためのコミュニケーションの過程」や 「形にしたものの動き」から共通理解を育める
- 22. Copyright (c) 2017 Guild Works Inc. アジャイル開発は、ドキュメント つくらない？
- 23. Copyright (c) 2017 Guild Works Inc. アジャイル開発は、ドキュメント つくらない？ 開発するために必要なことは減らない！ アジャイルな開発にすることで、急に開発に必要 だった⼿順がなくなるわけではない。 コード以外の記述が全く不要なわけではない。 ただし、「理解や伝達のための成果物」は 最低限にしておくこと。
- 24. Copyright (c) 2017 Guild Works Inc. つくるものやチームについての問題早く気付ける 開発を⼀巡させるのが早いため、プロダクトやチームの 問題に早く気付ける。 コードが書けない = バックログの完成の条件を詳細にする。 バックログが消化できない = チームに必要なタレントを巻き込む。 認識の齟齬が多い = コミュニケーションの内容、頻度の調整。 要件の実現⽅法が分からない = 技術的な実現可能性の検証。 改修時のデグレが多い = ⾃動回帰テストの充実。
- 25. Copyright (c) 2017 Guild Works Inc. チームの学習効果が⾼い 「常に最初から同じメンバーで継続的に活動」が前提 異なる担当者に伝達 伝達伝達
- 26. Copyright (c) 2017 Guild Works Inc. 早く始められる 全ての要件を決めきる必要がない = 部分を後回しに出来る 結合のリスクを早めに倒すこと 常に結合。 Time to marketが短い 早いスプリントからリリースできる = 早く収益化できる。 サンクコストが⼩さくできる 早いスプリントから評価が出来るため、途中でやめられる。 開発チームのリズムを整えられる チームの実状に計画をあわせられる。
- 27. Copyright (c) 2017 Guild Works Inc. アジャイル開発は、計画しない？ 確かに、綿密な細か〜い、スケジュール表を 最近は⾒かけなくなりましたね！ だけど、 細かいスケジュールをつくらない ≠ 計画しない というわけでは決してない。
- 28. Copyright (c) 2017 Guild Works Inc. むしろ、頻繁に計画づくりを⾏う。 アジャイルな開発では、イテレーションと呼ばれる 単位で、時間を区切り開発を進める。 各イテレーションで何をするのかは 「イテレーション計画ミーティング」 という場で、イテレーション毎に毎回⾏う。
- 29. Copyright (c) 2017 Guild Works Inc. むしろ、頻繁に計画づくりを⾏う。 アジャイルな開発では、イテレーションと呼ばれる 単位で、時間を区切り開発を進める。 各イテレーションで何をするのかは 「イテレーション計画ミーティング」 という場で、イテレーション毎に毎回⾏う。 毎回。イテレーションを1週間で回しているなら 毎週、計画づくりをするってこと！ なぜやるかって？頻繁に計画づくりしたほうが、 現実から乖離した計画を追わなくて済むよね。
- 30. Copyright (c) 2017 Guild Works Inc. アジャイル開発は、⾒積もりしない？
- 31. Copyright (c) 2017 Guild Works Inc. アジャイル開発は、⾒積もりしない？ ⾒積もりは、2つのプランニングで必要になるよ。 ①「リリースプランニング」 ②「イテレーション(スプリント)プランニング」
- 32. Copyright (c) 2017 Guild Works Inc. アジャイル開発は、⾒積もりしない？ ⾒積もりは、2つのプランニングで必要になるよ。 ①「リリースプランニング」 ②「イテレーション(スプリント)プランニング」 やることに対して⾒積もりをしないと、全体として 何イテレーション必要なのかが分からない(①)し ⽬の前のイテレーションでチームとしてどこまで できそうなのか⾒⽴てることができない(②)
- 33. Copyright (c) 2017 Guild Works Inc. ⾒積もりは相対的に⾏う A.コップの⽔の量がどのくらいあるか？ B.右のコップの⽔の量は左に⽐べてどのくらいか？
- 34. Copyright (c) 2017 Guild Works Inc. アジャイル開発は、フェーズゲート開発 よりも早く済むし、お安く済むんでしょ？
- 35. Copyright (c) 2017 Guild Works Inc. アジャイル開発は、フェーズゲート開発 よりも早く済むし、お安く済むんでしょ？ ムダが減らせる分は、早くたどり着けるかもしれ ないし、コストも抑えられるかもしれない。 …ただし、イテレーション開発とは、そもそも 試⾏錯誤をするために時間を区切っているわけ だから、つくる⽅向性の調整が今までより細かく できるようになるということは、期間もコストも ⼤きくなる可能性があるということ。
- 36. Copyright (c) 2017 Guild Works Inc.
- 37. Copyright (c) 2017 Guild Works Inc. ☓ △ △ ⃝
- 38. Copyright (c) 2017 Guild Works Inc. 本⽇のテーマ なぜ、アジャイルに向かうのか。 背景 よくある問題 乗り越える
- 39. Copyright (c) 2017 Guild Works Inc. 少しずつ形にするにあたっての問題 忙しい。 常に開発をしている、常に確認をするということは 常に開発チームと共にあるということ (a)
- 40. Copyright (c) 2017 Guild Works Inc. 少しずつ形にするにあたっての問題 ある程度の腕が求められる。(b) 各タスクにある程度 ⻑い時間をかける 最初から⼀通りのスキルが必要。 最初は圧倒される可能性がある。 早めに失敗できるので、何が ボトルネックになるか気付き易い。 (最初は進捗が上がりにくい)
- 41. Copyright (c) 2017 Guild Works Inc. 少しずつ形にするにあたっての問題 チームを越えて対象を分割すると、同期が難しい(c) チームを分割した場合、 フェーズではなくて、 タイムボックスで同期を 取るため、取れ⾼が容易に ずれる。 作っているモノを同期しなけ ればならないときに、揃える 難しさがある。
- 42. Copyright (c) 2017 Guild Works Inc. 少しずつ形にするにあたっての問題 QCDに特徴的な課題がある(d) 「品質の維持」のためのコストが必要 →少しずつ作るので、作る度に既存機能に改修の影響が発⽣する タイムボックス分割分のオーバーヘッドがある 「品質とコスト」を⼀定とすると、「スコープ」と「納期」で 調整する必要がある = ローンチタイミングが守られるか
- 43. Copyright (c) 2017 Guild Works Inc. 少しずつ形にするにあたっての問題 そもそも考え⽅が関係者であっていない(e) 「いままでと違うやり⽅」について、 上層部、現場メンバーそれぞれに対して考え⽅が合わない。
- 44. Copyright (c) 2017 Guild Works Inc. 本⽇のテーマ なぜ、アジャイルに向かうのか。 背景 よくある問題 乗り越える
- 45. Copyright (c) 2017 Guild Works Inc. 「忙しい問題」の乗り越え⽅ (i) ⻑期的には、プロダクトオーナーを育てる。 ふるまいを⾝に付け、時間を取れること。 (ii) 短期的には、代理のプロダクトオーナーを⽴てる。 ※ バックログの⼊れ替えである程度対処は可能だが 本質的には「プロダクトオーナーの判断」以上には 全体のスピードは早まらない。
- 46. Copyright (c) 2017 Guild Works Inc. 「ある程度腕が求められる」乗り越え⽅ (i) ⼤⽬に⾒る。 (ii) チームの状態にあわせて段階的な移⾏が必要。 ・プラクティスを少しずつ取り⼊れる ・第1段階 開発上の問題を取り除く (ふりかえり、タスクボード、スタンドアップミーティング) ・第2段階 開発だけ反復 ・第3段階 プロダクトオーナーを巻き込んだ開発
- 47. Copyright (c) 2017 Guild Works Inc. 「同期問題」の乗り越え⽅ (i) チーム内の同期 → 計画ミーティング、デイリー、デモ、 (ii) チーム外との同期 → 階層化=「デイリーカクテルパーティ」 第3章：デイリーカクテルパーティーに参加しよう
- 48. Copyright (c) 2017 Guild Works Inc. 「QCD問題」の乗り越え⽅ (i) 品質の維持へのコスト → ⾃動回帰テスト (ii) タイムボックスオーバーヘッド問題 → 反復の必要性を問う (iii) ローンチタイミングが守られるか → 常にシミュレーションが必要(着地予想)。 納期とスコープのトレードオフを判断し続ける。
- 49. Copyright (c) 2017 Guild Works Inc. 「考え⽅あわない問題」の乗り越え⽅ アジャイルな開発に取り組み始める際に準備が必要 → インセプションデッキ ・なぜ必要なのか ・どうやってやるのか ・この現場での課題とは何か
- 50. Copyright (c) 2017 Guild Works Inc. インセプションデッキは 何のために必要？
- 51. Copyright (c) 2017 Guild Works Inc. インセプションデッキは 何のために必要？ プロジェクトを始めるにあたって、 前提と制約、背景と現状などについて 関係者の間で認識を共通にすることで ⽅針や判断基準を揃える。 その結果、チームが状況に応じた適切な判断を 下せるようになることを期待する。
- 52. Copyright (c) 2017 Guild Works Inc. 導⼊にあたっての作戦 ① 段階的にやる (プラクティス導⼊) ② コミットメント(特に納期)の調整が効きやすい領域から ③ 経験豊かな⼈を混ぜ込む
- 53. Copyright (c) 2017 Guild Works Inc. 自分の現場で何から始めたら良いのか
- 54. Copyright (c) 2016 Guild Works Inc. 型としてのアジャイル開発との⽐較を⾏う(1/3) 54 型としてのアジャイル開発 あなたのチーム ⻘字は今後やると良さそうなこと ※ここでの型はスクラムガイド及び アジャイルサムライ、リーン開発の 現場を前提 チーム ・1チーム、両⼿未満 ・プログラマ、デザイナ、プロジェクトマ ネージャ、アナリスト、テスター等 ・開発チーム、PO、スクラムマスター ・必要に応じた役割と定義と期待 ⽅向付け ・プロジェクトの⽅向付けやチームビルド を⾏う ・フレームは、インセプションデッキ 要求 ・管理⼿段は、プロダクトバックログ ・形式は、ユーザーストーリー形式(INVEST) ・完成の定義がある ・バックログを練る、伝える機会がある →バックログリファインメント リリース計画 ・プロダクトバックログを元に、リリース 時期を⾒定める ・チームのベロシティ(仮定でおく) ・バックログの⾒積もり(相対⾒積) →プランニングポーカー Sample
- 55. Copyright (c) 2017 Guild Works Inc. この先にあるのは？ 「少しずつ形にできるようになる」 つまり「体のコントロール」と同じ。
- 56. Copyright (c) 2017 Guild Works Inc. この先にあるのは？ 「少しずつ形にできるようになる」 つまり「体のコントロール」と同じ。 「体のコントロール」 = 頭で考えたことを即座に伝えて、 体の部分を思うようにすぐに動かせる
- 57. Copyright (c) 2017 Guild Works Inc. この先にあるのは？ 「少しずつ形にできるようになる」 つまり「体のコントロール」と同じ。 「体のコントロール」 = 頭で考えたことを即座に伝えて、 体の部分を思うようにすぐに動かせる 「体のコントロール」のようにソフトウェアをつくる = 必要なことを即座に伝えあい、 すぐに試せる、形にできる。
- 58. Copyright (c) 2017 Guild Works Inc. 最後に、再び。 “アジャイル開発”という実体があるわけではない。 実体としては「XP」「スクラム」などがあり、 先⼈の肩越しに、⾃分たちの開発を変化に適応 できるようになることが「アジャイルである」こと。 ⾃分たちの意思と、その実現のための開発が 限りなく⼀致していくこと！
- 59. Copyright (c) 2017 Guild Works Inc. https://guildworks.jp/ 「正しいものを正しくつくる」ギルドワークス https://enagile.jp/ 「越境をエナジャイズする」エナジャイル https://www.tagile.org/ 「SoE、SoRで越境する戦略と戦術を得る」越境アジャイルアライアンス 「開発現場のためのコミュニティ」DevLOVE https://devlove.doorkeeper.jp/