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