Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Agile and Business

1.800 visualizaciones

Publicado el

IIBA 12/12

Publicado en: Tecnología
  • Sé el primero en comentar

Agile and Business

  1. 1. Seeing is understanding. 「ビジネスサイクルと Agile開発サイクルの統合」 株式会社チェンジビジョン 永和システムマネジメント 平鍋健児 1
  2. 2. Seeing is understanding. ⾃⼰紹介 •  ㈱永和システムマネジメント –  福井市(本社)、神⽥東京(⽀社)、沖縄(事務所) –  「⾦融」、「医療」、「組込みシステム」開発 –  「Ruby と Agile」を使ったシステム開発 •  株式会社チェンジビジョン –  福井市(開発部)、神⽥東京(本社) –  astah* (旧:JUDE) の開発 •  平鍋健児 –  UML+マインドマップエディタ astah*の開発 –  要求開発アライアンス、理事 –  翻訳、XP関連書籍、『リーン開発の本質』 『IMPACT MAPPING』等多数。 –  著書『アジャイル開発とスクラム』、『要求開発』 『ソフトウェア開発に役⽴つマインドマップ』 4
  3. 3. Seeing is understanding.5 『アジャイル開発とスクラム』 • 顧客・技術・経営の3者をつなぐ ために、アジャイルと⽇本経営の 接合点を探る • 海兵隊の組織とアジャイル • 知識創造プロセスとアジャイル • 実践知リーダーとアジャイル • 富⼠通・楽天・リクルートの事例 • Jeff Sutherlandインタビュー 平鍋健児+野中郁次郎著
  4. 4. Seeing is understanding.6 アジェンダ • アジャイル開発⼊⾨ – なぜアジャイルか? – アジャイルとは何か? – アジャイルの事例 • アジャイルの実際 – アジャイルのチームづくり • ⽇本とアジャイル
  5. 5. なぜ、アジャイルか? 7
  6. 6. Seeing is understanding.8 市場 ビジネス IT 市場分析 発注 納品リリース 半年から3年 ミッション・リスク分割型ビジネスと ウォーターフォール型開発(従来型)
  7. 7. Seeing is understanding.9 従来型の問題=要求の劣化 システムの機能の利用度 全く使われない 45%ほとんど使われな い 19% たまに使う 16% いつも使う 7% よく使う 13% •  Standish group study report in 2000 chaos report
  8. 8. Seeing is understanding.10 市場 IT ミッション・リスク共有型ビジネスと Agile型開発 ビジネス 市場 ビジネスとITが⼀体になった 「OneTeam」を作り、ミッション とリスクを共有する。 やってみて、結果から戦略を 作りながら進む。
  9. 9. Seeing is understanding.11 IDEAS CODEDATA BUILDLEARN MEASURE 素早くコード 単体テスト ユーザビリティテスト 継続的結合 漸進開発 オープンソース利用 クラウド クラスタ免疫システム JITスケーラビリティ リファクタリング デベロパーサンドボックス 素早く測定 AB テスト 明確なプロダクトオーナ 継続的開発 ユーザビリティテスト リアルタイムモニタ 顧客代表 素早く学習 AB テスト 顧客インタビュー 顧客開発 なぜなぜ5回、真因分析 顧客アドバイザリボード 仮説検証 プロダクト・オーナーの責任 顧客タイプ分析 機能横断チーム 半自立チーム スモークテスト 漏斗分析 コホート分析 ネットプロモータスコア 検索エンジンマーケティング リアルタイムアラート 予測的モニタリング Lean Startup
  10. 10. Seeing is understanding.Photograph © Tom Poppendieck Mary Poppendieck mary@poppendieck.com www.poppendieck.comCopyri ght©2 016 1 2
  11. 11. IBMの Agile 原則 13  確実さより明快さがよ り重要  1つ1つの完全性を求 めるよりコースの都度 修正がより重要  自主的なチームの方 が「コントロールと構 造」よりうまくいく  集合知は個々の知性 を上回る  8-10人のフルスタック チームがすべての仕事 をする。(設計・構築・デ プロイ)  リーダシップの役割  強いチームを作る  明確な目的を作る  生産的な環境を作る  大きなことを成し遂げるのだと、 人々をインスパイアーする。  重要なこと(だけ)を計測する Jeff Smith, IBM CIO Copyright©2016 Poppendieck.LLC
  12. 12.  The “Industrial Internet” of Things  データを使って資産の生産性を上げる  重要スキル: サイエンス、セキュリティ  重要課題: スキルのある人を集めて難題を 解かせる 14 Copyright©2016 Poppendieck.LLC
  13. 13.  我々の競争力はデジタル生産性だ。  勝つためには、シンプルな組織が必要。  変化のために、よりリーンで速く、
 分散したビジネスモデルが必要。  複雑で中央集権型の官僚主義は、時代遅れだ。  GEは躊躇せずリスクをとるようにエンパワーされた ローカルなチームに、能力を集める。  もし20代でこの会社にはいるのなら、コーディング を学ぶ必要がある。職種が営業であっても経理で あって、運用であってもだ。プログラマーであるかな いかは別にして、コーディングを知っているべきだ。 15 Copyright©2016 Poppendieck.LLC
  14. 14. hUps://e-estonia.com/the-story/digital-society/ Popula/on: 1.3 Million Size: 45 227 km² Capital: Tallinn Language: Estonian Member of EU Currency: Euro GDP: 18.4 BEUR  99% の銀行取引はオンライン  95% の所得税申告はオンライン  31.4% の選挙投票はインターネット  95% の医薬は電子的に処方される  プログラミングの学習は7歳から 16 Copyright©2016 Poppendieck.LLC
  15. 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
  16. 16. 4-8 weeks 6-8 weeks A few months, then iterate Copyright©2016 Poppendieck.LLC 18
  17. 17. アジャイル開発とは何か? 19
  18. 18. Seeing is understanding.20 プロセスとしてのアジャイル •  短いサイクルで、分析、設計、実装、テストを並列に⾏う •  タイムボックス型、進化型開発 分析 設計 実装 テスト 時間 時間 要求(スコープ) 要求(スコープ)Waterfall Agile Beck 2000Royce 1970 最後に動くものができる 動くものが徐々に できあがり、成長する
  19. 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
  20. 20. Seeing is understanding.22 スクラムの流れ
  21. 21. Seeing is understanding. スクラムの3本柱 •  透明性 – プロジェクトが順調か、判断できる情報を標 準化し、関係者全員で正しく共通理解をもつ。 •  検査 – 成果物や進んでいる⽅向がゴールに向かって いるから絶えず確認する。 •  適応 – 何か不備があった場合、ゴールの逸脱を最⼩ 限に抑えるために早期に調整する。 23
  22. 22. Seeing is understanding.24 スクラムでの役割
  23. 23. Seeing is understanding.25 スクラムのフレームワーク
  24. 24. Seeing is understanding.26 アジャイルの 価値、原則、実践 価値 value 原則 principle 実践 practices まずはこれを共有すること 考え方としての方針 具体的に現場ごとに作る
  25. 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, 上記の著者たち この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。  重要 超重要!
  26. 26. Seeing is understanding.28 アジャイルの原則 • 顧客価値の優先 • 変化に対応 • 短期のリリース • 全員同席 • モチベーションと信頼 • 会話 • 動くソフトウェア • 持続可能なペース • 技術的卓越性 • シンプル • ⾃⼰組織的チーム • ふりかえりと改善
  27. 27. Seeing is understanding.29 アジャイルの プラクティス(例 XP) •  計画ゲーム •  ⼩規模リリース •  メタファー •  シンプルデザイン •  テスティング •  リファクタリング •  ペアプログラミング •  共同所有権 •  継続的インテグレーション •  週40時間 •  オンサイト顧客 •  コーディング標準
  28. 28. Copyright©2016 Poppendieck.LLC
  29. 29. Seeing is understanding.31 ⾼速に⽯橋を 叩いて渡る 「開発環境」 協働でゴールに 向かう 「チーム環境」 ビジネス価値、 顧客満⾜、市場創造 継続的インテグレーション テスト駆動開発 リファクタリング ペアプログラミング アジャイルモデリング … その他 朝会 タスクかんばん バーンダウンチャート ふりかえり … その他 アジャイルの レフトウィング アジャイルの ライトウィング アジャイルのゴール ソーシャルプラクティス 技術プラクティス
  30. 30. Seeing is understanding.32 アジャイル開発の実際 〜プロジェクトファシリテーション〜
  31. 31. Copyright©2016 Poppendieck.LLC プロジェクトの ⾒える化から はじめましょう
  32. 32. Copyright©2016 Poppendieck.LLC 見える化/透明性 l  「最新の正の情報」が、「一箇所に」、「大 きく」書かれていて、それを、「両チームのメン バー」、「審判」、「観客」が見ている。 「次の 行動」を誘発する。 全ステークホルダーが、行動を起こせるような、確かな、分かりやすい情報源 POINT
  33. 33. Copyright©2016 Poppendieck.LLC プロジェクトの成功は、
 Moving Target 要求  R(t) システム  S(t) チーム(t)R(t) S(t) Δ t 不明確かつ不 安定な要求。 いくらよい計画を立てても、見えていなければ、プロジェクトは成功できない。POINT Δ 基盤技術  T(t) T(t)
  34. 34. Copyright©2016 Poppendieck.LLC 実践
  35. 35. Copyright©2016 Poppendieck.LLC タスクかんばん l  作業の見える化 – ToDo(未実施)
 Doing(実施中)
 Done(完了)
 で管理。 – 各自の作業を指示しなく
 ても、毎朝自発的に
 作業開始。 – フォーマットは徐々に
 カイゼン。 タスクかんばんの例 ※バーンダウンチャーなどと共に、とにかく、壁に貼る。「情報発信器」とも呼ばれる。 作業の見える化は、「タスクかんばん」で行なう。 POINT (協⼒:チェンジビジョンastah* チー ム)
  36. 36. Copyright©2016 Poppendieck.LLC 助け合う
  37. 37. Copyright©2016 Poppendieck.LLC バーンダウンチャート l  進捗の見える化 – バーンダウン(下向き) – タスクかんばんと連動 – 中間成果物で
 は計測しない。 – メールでエクセルシート
 を配布したり、
 サーバに置いたから
 見てね、はナシ。 バーンダウンチャートの例 全体進捗は、「バーンダウンチャート」で見える化、繰り返しのリズムづくり POINT (協⼒:永和システムマネジメント:チー ム⾓⾕)
  38. 38. Copyright©2016 Poppendieck.LLC スルーしない
  39. 39. Copyright©2016 Poppendieck.LLC SOMCでの朝会のヒトコマ 3⼈のリーダが集まっての朝会。移動式ホワイトボードであるNUboardを使ってます。 (写真提供:ソニーモバイルコミュニケーションズの冨⽥さん)
  40. 40. Copyright©2016 Poppendieck.LLC 日本からも海外へ発信
  41. 41. “Kanban, Successful Evolutionary Change for Your Technology Business” http://www.agilemanagement.net Copyright©2016 Poppendieck.LLC
  42. 42. Copyright©2016 Poppendieck.LLC http://blog.crisp.se/henrikkniberg/
  43. 43. Copyright©2016 Poppendieck.LLC http://leansoftwareengineering.com/2007/10/27/kanban-bootstrap/ Corey Ladas
  44. 44. Copyright©2016 Poppendieck.LLC 現場で ⼯夫する
  45. 45. Copyright©2016 Poppendieck.LLC 「かんばん-nano」スーツにもベストフィット! POINT ポータブルかんばん (協力:CCS 佐藤竜一さん)
  46. 46. Copyright©2016 Poppendieck.LLC 日本からも海外へ発信
  47. 47. Copyright©2016 Poppendieck.LLC 朝会 l  作業の明確化 –  自発的なサインアップ –  昨日やったこと、
 今日やること、
 問題点、の3点のみ。 –  かんばんの前
 で、行なう。 –  朝の仕事はじめが
 重要! –  スタンドアップで15分. –  定時刻、定位置、短時間 朝会の例(協力:チェンジビジョンastah* チーム) 毎朝、「かんばん」の前で全員で短い会議を行ない、リズムをとる。 POINT PF実践編:朝会ガイド
 http://www.ObjectClub.jp/community/pf/
  48. 48. Copyright©2016 Poppendieck.LLC ふりかえり(1) l  カイゼンの気づき –  Keep(良い点)
 Problem(悪い点)
 Try(次回挑戦)
 を出す。 –  全員で意見を出し、
 暗黙知の共同化と
 形式知化を行なう。「名前付け」 –  「課題-解決リスト」、とは違う。 –  とにかく、カジュアルな雰囲気で
 全員発言することで、チームの
 安全性を確保する。 –  「問題vs私たち」の構図になるように。 ふりかえりシートの例 カイゼンの「気づき」を「ふりかえり」で得る。 POINT 実践編:ふりかえりガイド http://www.ObjectClub.jp/community/pf/
  49. 49. Copyright©2016 Poppendieck.LLC ふりかえり(2) l  Keep/Problem/Try(KPT) –  Keepは定着する。 –  ProblemはTryを
 生み出す。 –  Tryは、Keepか
 Problemに移動する。 –  定着したものには、
 「名前づけ」を。 ふりかえりがカイゼンを導く Keep Problem Try 新しい問題! 新しいアイディア! 解決法 やってみて うまく行った うまく行かない 定着 イテレーション毎に「ふりかえり」を繰り返すことでプロセスが改善される。 POINT
  50. 50. Copyright©2016 Poppendieck.LLC
  51. 51. esm-conferenceブログより Copyright©2016 Poppendieck.LLC やわたメディカルさんの事例 “現場では、このようにKPTを張り出し、気づ いた時に付箋をはり、毎⽇お昼に話し合って、 すぐアクション、というサイクルで回してい たとのこと。24時間/365⽇とまらない現場は、 このように⼿軽に導⼊しやすく、当事者同⼠ で話し合って解決策を⾒つける仕組み(問題 vs私たち)がフィットしたとのこと。”
  52. 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
 より抜粋して紹介
  53. 53. Seeing is understanding.http://sec.ipa.go.jp/reports/20120611.html72
  54. 54. Seeing is understanding.http://sec.ipa.go.jp/reports/20120611.html73
  55. 55. 2012年3⽉調べ 74
  56. 56. 2016年5⽉調べ 75
  57. 57. スクラム認定状況(2013-16) •  PO の数がグンと伸びている。(⽶・英) – ビジネス側に確実に訴求している。 •  ⽇本はようやくデンマークに追いつく。 – (デンマークの⼈⼝は⽇本の 4.3 % だって!) •  ベトナムで盛り上がっているように思った が、まだまだ。 •  「有効」認定者数なので、減る場合もある。 76
  58. 58. 77 ユーザ企業 システム部⾨ ユーザ企業 システム 部⾨ SIer ⽶国の構造 ⽇本の構造 横にスケールするAgile 縦にスケールするAgile Agileのスケール⽅向 中堅ソフトハウス 契約を挟み多段の下請け構造の中で、どうしたらゴールを共有できるだろう? Copyright©2016 Poppendieck.LLC
  59. 59. IT⼈材の 流動性 IT人材白書2014: hUp://www.ipa.go.jp/jinzai/jigyou/about.html Webビジネス企業での 中途採⽤が圧倒的に 増えている ⼈材流動!!! 考察: hUp://qiita.com/kenjihiranabe/items/05ac9g741edc1ee5276 Copyright©2016 Poppendieck.LLC 78
  60. 60. Seeing is understanding. デジタルとアナログ 79
  61. 61. Copyright©2016 Poppendieck.LLC astah* 開発チーム例
  62. 62. Copyright©2016 Poppendieck.LLC
  63. 63. Copyright©2016 Poppendieck.LLC
  64. 64. Copyright©2016 Poppendieck.LLC
  65. 65. Copyright©2016 Poppendieck.LLC
  66. 66. Copyright©2016 Poppendieck.LLC
  67. 67. Copyright©2016 Poppendieck.LLC
  68. 68. Copyright©2016 Poppendieck.LLC One more thing …
  69. 69. ご清聴ありがとうございました。Copyright©2016 Poppendieck.LLC
  70. 70. Copyright©2016 Poppendieck.LLC

×