Agile and Business
- 2. Seeing is understanding. ⾃⼰紹介 • ㈱永和システムマネジメント – 福井市（本社）、神⽥東京（⽀社）、沖縄（事務所） – 「⾦融」、「医療」、「組込みシステム」開発 – 「Ruby と Agile」を使ったシステム開発 • 株式会社チェンジビジョン – 福井市（開発部）、神⽥東京（本社） – astah* (旧：JUDE) の開発 • 平鍋健児 – UML+マインドマップエディタ astah*の開発 – 要求開発アライアンス、理事 – 翻訳、XP関連書籍、『リーン開発の本質』 『IMPACT MAPPING』等多数。 – 著書『アジャイル開発とスクラム』、『要求開発』 『ソフトウェア開発に役⽴つマインドマップ』 4
- 3. Seeing is understanding.5 『アジャイル開発とスクラム』 • 顧客・技術・経営の３者をつなぐ ために、アジャイルと⽇本経営の 接合点を探る • 海兵隊の組織とアジャイル • 知識創造プロセスとアジャイル • 実践知リーダーとアジャイル • 富⼠通・楽天・リクルートの事例 • Jeff Sutherlandインタビュー 平鍋健児＋野中郁次郎著
- 5. なぜ、アジャイルか? 7
- 6. Seeing is understanding.8 市場 ビジネス IT 市場分析 発注 納品リリース 半年から３年 ミッション・リスク分割型ビジネスと ウォーターフォール型開発（従来型）
- 7. Seeing is understanding.9 従来型の問題＝要求の劣化 システムの機能の利用度 全く使われない 45%ほとんど使われな い 19% たまに使う 16% いつも使う 7% よく使う 13% • Standish group study report in 2000 chaos report
- 10. Seeing is understanding.Photograph © Tom Poppendieck Mary Poppendieck mary@poppendieck.com www.poppendieck.comCopyri ght©2 016 1 2
- 15. 2002-11 英国NHS（国営医 療サービス事業）は £10bn（1000億円） 電子カ ルテに投資、失敗! 対応：Francis Maude 議員 がエストニアを訪問し、彼ら のプロセスを真似た。 ガバナンスの原則 デリバリを遅らせな い。 必要な時に正しい階 層で決断する。 正しい人でやる 自分で見に行く 価値を付加するもの だけやる 信頼しチェックする 4-8 weeks 6-8 weeks A few months, then iterate From: hUps://www.gov.uk/transformacon 7/ 2014 17 Copyright©2016 Poppendieck.LLC
- 17. アジャイル開発とは何か? 19
- 18. Seeing is understanding.20 プロセスとしてのアジャイル • 短いサイクルで、分析、設計、実装、テストを並列に⾏う • タイムボックス型、進化型開発 分析 設計 実装 テスト 時間 時間 要求(スコープ) 要求(スコープ)Waterfall Agile Beck 2000Royce 1970 最後に動くものができる 動くものが徐々に できあがり、成長する
- 19. Seeing is understanding.21 分割の仕⽅ • 顧客に分かる機能で切る。 • 層で切らない。 • ビジネスの価値が分かる。 • やりがい、コミュニケーション "These days we do not program software module by module; we program software feature by feature.“ —Mary Poppendieck by Akiyah
- 21. Seeing is understanding. スクラムの3本柱 • 透明性 – プロジェクトが順調か、判断できる情報を標 準化し、関係者全員で正しく共通理解をもつ。 • 検査 – 成果物や進んでいる⽅向がゴールに向かって いるから絶えず確認する。 • 適応 – 何か不備があった場合、ゴールの逸脱を最⼩ 限に抑えるために早期に調整する。 23
- 25. Seeing is understanding.27 アジャイルソフトウェア開発宣言 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツール よりも 個人と対話を、 包括的なドキュメント よりも 動くソフトウェアを、 契約交渉 よりも 顧客との協調を、 計画に従うこと よりも 変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas © 2001, 上記の著者たち この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。 重要 超重要!
- 27. Seeing is understanding.29 アジャイルの プラクティス（例 XP） • 計画ゲーム • ⼩規模リリース • メタファー • シンプルデザイン • テスティング • リファクタリング • ペアプログラミング • 共同所有権 • 継続的インテグレーション • 週40時間 • オンサイト顧客 • コーディング標準
- 32. Copyright©2016 Poppendieck.LLC 見える化/透明性 l 「最新の正の情報」が、「一箇所に」、「大 きく」書かれていて、それを、「両チームのメン バー」、「審判」、「観客」が見ている。 「次の 行動」を誘発する。 全ステークホルダーが、行動を起こせるような、確かな、分かりやすい情報源 POINT
- 33. Copyright©2016 Poppendieck.LLC プロジェクトの成功は、 Moving Target 要求 R(t) システム S(t) チーム(t)R(t) S(t) Δ t 不明確かつ不 安定な要求。 いくらよい計画を立てても、見えていなければ、プロジェクトは成功できない。POINT Δ 基盤技術 T(t) T(t)
- 35. Copyright©2016 Poppendieck.LLC タスクかんばん l 作業の見える化 – ToDo(未実施) Doing(実施中) Done(完了) で管理。 – 各自の作業を指示しなく ても、毎朝自発的に 作業開始。 – フォーマットは徐々に カイゼン。 タスクかんばんの例 ※バーンダウンチャーなどと共に、とにかく、壁に貼る。「情報発信器」とも呼ばれる。 作業の見える化は、「タスクかんばん」で行なう。 POINT (協⼒：チェンジビジョンastah* チー ム）
- 41. “Kanban, Successful Evolutionary Change for Your Technology Business” http://www.agilemanagement.net Copyright©2016 Poppendieck.LLC
- 47. Copyright©2016 Poppendieck.LLC 朝会 l 作業の明確化 – 自発的なサインアップ – 昨日やったこと、 今日やること、 問題点、の３点のみ。 – かんばんの前 で、行なう。 – 朝の仕事はじめが 重要！ – スタンドアップで１５分． – 定時刻、定位置、短時間 朝会の例(協力：チェンジビジョンastah* チーム） 毎朝、「かんばん」の前で全員で短い会議を行ない、リズムをとる。 POINT PF実践編：朝会ガイド http://www.ObjectClub.jp/community/pf/
- 48. Copyright©2016 Poppendieck.LLC ふりかえり(1) l カイゼンの気づき – Keep(良い点) Problem(悪い点) Try(次回挑戦) を出す。 – 全員で意見を出し、 暗黙知の共同化と 形式知化を行なう。「名前付け」 – 「課題－解決リスト」、とは違う。 – とにかく、カジュアルな雰囲気で 全員発言することで、チームの 安全性を確保する。 – 「問題vs私たち」の構図になるように。 ふりかえりシートの例 カイゼンの「気づき」を「ふりかえり」で得る。 POINT 実践編：ふりかえりガイド http://www.ObjectClub.jp/community/pf/
- 49. Copyright©2016 Poppendieck.LLC ふりかえり(2) l Keep/Problem/Try（KPT） – Keepは定着する。 – ProblemはTryを 生み出す。 – Tryは、Keepか Problemに移動する。 – 定着したものには、 「名前づけ」を。 ふりかえりがカイゼンを導く Keep Problem Try 新しい問題！ 新しいアイディア！ 解決法 やってみて うまく行った うまく行かない 定着 イテレーション毎に「ふりかえり」を繰り返すことでプロセスが改善される。 POINT
- 52. Information-technology Promotion Agency, Japan Software Engineering Center Copyright© 2012 Information-technology Promotion Agency, Japan. All rights reserved. Software Engineering Center 非ウォーターフォール型開発の 普及要因と適用領域の拡大に関する調査 ～非ウォーターフォール型開発の普及要因の調査～ 調査概要報告書 https://www.ipa.go.jp/sec/softwareengineering/reports/20120328.html より抜粋して紹介
- 55. 2012年3⽉調べ 74
- 56. 2016年5⽉調べ 75
- 57. スクラム認定状況(2013-16) • PO の数がグンと伸びている。（⽶・英） – ビジネス側に確実に訴求している。 • ⽇本はようやくデンマークに追いつく。 – （デンマークの⼈⼝は⽇本の 4.3 % だって!） • ベトナムで盛り上がっているように思った が、まだまだ。 • 「有効」認定者数なので、減る場合もある。 76
- 58. 77 ユーザ企業 システム部⾨ ユーザ企業 システム 部⾨ SIer ⽶国の構造 ⽇本の構造 横にスケールするAgile 縦にスケールするAgile Agileのスケール⽅向 中堅ソフトハウス 契約を挟み多段の下請け構造の中で、どうしたらゴールを共有できるだろう？ Copyright©2016 Poppendieck.LLC
- 68. Copyright©2016 Poppendieck.LLC One more thing …