スライド 1

Size: px

Start display at page:

Download "スライド 1"

まれああくや
5 years ago
Views:

1 デジタルビジネスの潮流とアジャイル開発 ~ ビジネスとエンジニアの協働チームづくり ~ 1 株式会社チェンジビジョン株式会社永和システムマネジメント平鍋健児

自己紹介永和システムマネジメント福井市 ( 本社 ) 神田東京 ( 支社 ) 沖縄 (

2 自己紹介永和システムマネジメント福井市 ( 本社 ) 神田東京 ( 支社 ) 沖縄 ( 事務所 ) 金融医療組込みシステム開発 Ruby と Agile を使ったシステム開発株式会社チェンジビジョン福井市 ( 開発部 ) 神田東京 ( 本社 ) astah* ( 旧 :JUDE) の開発平鍋健児 UML+ マインドマップエディタ astah* の開発要求開発アライアンス理事翻訳 XP 関連書籍リーン開発の本質 IMPACT MAPPING 等多数著書アジャイル開発とスクラム要求開発ソフトウェア開発に役立つマインドマップ 2

3 アジャイル開発とスクラム顧客技術経営の 3 者をつなぐためにアジャイルと日本経営の接合点を探る海兵隊の組織とアジャイル知識創造プロセスとアジャイル実践知リーダーとアジャイル富士通楽天リクルートの事例 Jeff Sutherland インタビュー平鍋健児 + 野中郁次郎著 3

4 なぜアジャイルか?

5 ミッションリスク分割型ビジネスとウォーターフォール型開発 ( 従来型 ) 市場分析発注市場ビジネス IT リリース納品半年から 3 年 5

6 従来型の問題 = 要求の劣化システムの機能の利用度いつも使う 7% よく使う 13% たまに使う 16% ほとんど使われない 19% 全く使われない 45% Standish group study report in 2000 chaos report 6

7 ミッションリスク共有型ビジネスと Agile 型開発市場ビジネスと IT が一体になった OneTeam を作りミッションとリスクを共有するやってみて結果から戦略を作りながら進むビジネス市場 IT 7

8 Lean Startup IDEAS 素早く学習 LEARN AB テスト顧客インタビュー顧客開発なぜなぜ 5 回真因分析顧客アドバイザリボード仮説検証プロダクトオーナーの責任顧客タイプ分析機能横断チーム半自立チームスモークテスト DATA CODE BUILD 素早くコード単体テストユーザビリティテスト継続的結合漸進開発オープンソース利用クラウドクラスタ免疫システム JIT スケーラビリティリファクタリングデベロパーサンドボックス素早く測定 AB テスト明確なプロダクトオーナ継続的開発ユーザビリティテストリアルタイムモニタ顧客代表 MEASURE 漏斗分析コホート分析ネットプロモータスコア検索エンジンマーケティングリアルタイムアラート予測的モニタリング 8

9 DX( デジタルトランスフォーメーション ) の文脈で 9 9

10 顧客開発と製品開発どっちが先か? ニーズ ( 顧客 ) とシーズ ( 製品 ) 10

11 スタートアップ ( 新事業 ) どちらも先ではないその中間を成長させる MVP 小さな MVP が成長して顧客と製品を形成した 11

単体テストユーザビリティテスト継続的結合漸進開発オープンソース利用クラウドクラスタ免疫システム JIT スケーラビリティリファクタリングデベロパーサンドボックス

12 IDEAS Lean Startup 素早く学習 LEARN AB テスト顧客インタビュー顧客開発なぜなぜ5 回真因分析顧客アドバイザリボード仮説検証プロダクトオーナーの責任顧客タイプ分析機能横断チーム半自立チームスモークテスト DATA MVP CODE BUILD 素早くコード単体テストユーザビリティテスト継続的結合漸進開発オープンソース利用クラウドクラスタ免疫システム JIT スケーラビリティリファクタリングデベロパーサンドボックス素早く測定 AB テスト明確なプロダクトオーナ継続的開発ユーザビリティテストリアルタイムモニタ顧客代表 MEASURE 漏斗分析コホート分析ネットプロモータスコア検索エンジンマーケティングリアルタイムアラート予測的モニタリング 12

13 アジャイルは 3 周目に入った! クラウドの普及 IoT/SoE 時代の到来 3 rd Wave 到来組織変革の手法不確実さへの対応リリーススピード重視 2 nd Wave 2010 年当初企業戦略 1 st Wave 2000 年当初エンジニア主体テクノロジーに感度の高いソフトハウス大手 IT サービス企業 / スタートアップ先進的大手企業一般的大手企業 13 シリコンバレー型のやり方を既存大企業が取り入れ始めた

14 従来型発注側受託側下請ベンダー企画部門開発部門発注 ( 開発ベンダー ) 発注発注発注下請ベンダー下請ベンダー壮大な伝言ゲーム 14

15 アジャイル型開発企画部門参加参加組織横断一体チーム参加開発部門開発ベンダー 15

16 アジャイル型開発 (2) 営業部門 Analysis 部門 UX 部門マーケティング部門参加参加企画部門参加組織横断一体チーム参加参加品証部門開発部門開発ベンダー 16

17 アジャイル開発とは何か? スクラムとは何か?

18 プロセスとしての Agile 短いサイクルで分析設計実装テストを並列に行うタイムボックス型進化型開発 Waterfall Agile 要求 ( スコープ ) 要求 ( スコープ ) 時間分析設計実装テスト Royce 1970 時間 Beck 2000 最後に動くものができる動くものが徐々にできあがり成長する 18

19 分割の仕方顧客に分かる機能で切る層で切らないビジネスの価値が分かるやりがいコミュニケーション "These days we do not program software module by module; we program software feature by feature. Mary Poppendieck by Akiyah 19

20 20 スクラムの流れ

21 スクラムの 3 本柱透明性プロジェクトが順調か判断できる情報を標準化し関係者全員で正しく共通理解をもつ検査成果物や進んでいる方向がゴールに向かっているから絶えず確認する適応何か不備があった場合ゴールの逸脱を最小限に抑えるために早期に調整する 21

22 22 スクラムでの役割

23 23 スクラムのフレームワーク

24 アジャイルの価値原則実践価値 value まずはこれを共有すること原則 principle 考え方としての方針実践 practices 具体的に現場ごとに作る 24

25 アジャイルソフトウェア開発宣言私たちはソフトウェア開発の実践あるいは実践を手助けをする活動を通じてよりよい開発方法を見つけだそうとしているこの活動を通して私たちは以下の価値に至った重要超重要! プロセスやツールよりも個人と対話を包括的なドキュメントよりも動くソフトウェアを契約交渉よりも顧客との協調を計画に従うことよりも変化への対応を価値とするすなわち左記のことがらに価値があることを認めながらも私たちは右記のことがらにより価値をおく 25 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

27 アジャイルのプラクティス ( 例 XP) 計画ゲーム小規模リリースメタファーシンプルデザインテスティングリファクタリングペアプログラミング共同所有権継続的インテグレーション週 40 時間オンサイト顧客コーディング標準 27

29 アジャイルのレフトウィングソーシャルプラクティス協働でゴールに向かうチーム環境朝会タスクかんばんバーンダウンチャートふりかえりその他アジャイルのゴールビジネス価値顧客満足市場創造アジャイルのライトウィング技術プラクティス高速に石橋を叩いて渡る開発環境継続的インテグレーションテスト駆動開発リファクタリングペアプログラミングその他 29

30 アジャイル開発の現場

31 プロジェクトの見える化からはじめましょう

32 見える化 / 透明性最新の正の情報が一箇所に大きく書かれていてそれを両チームのメンバー審判観客が見ている次の行動を誘発する POINT 全ステークホルダーが行動を起こせるような確かな分かりやすい情報源 32

33 プロジェクトの成功は Moving Target 不明確かつ不安定な要求要求 Δ R(t) システム S(t) 基盤技術 T(t) t T(t) R(t) POINT Δ チーム(t) S(t) いくらよい計画を立てても見えていなければプロジェクトは成功できない

34 タスクかんばん作業の見える化 ToDo( 未実施 ) Doing( 実施中 ) Done( 完了 ) で管理各自の作業を指示しなくても毎朝自発的に作業開始フォーマットは徐々にカイゼンタスクかんばんの例 ( 協力 : チェンジビジョンastah* チーム ) POINT 34 バーンダウンチャーなどと共にとにかく壁に貼る情報発信器とも呼ばれる作業の見える化はタスクかんばんで行なう

35 助け合う

36 SOMC での朝会のヒトコマ 3 人のリーダが集まっての朝会移動式ホワイトボードである NUboard を使ってます ( 写真提供 : ソニーモバイルコミュニケーションズの冨田さん ) 36

37 37 日本からも海外へ発信

38 Kanban, Successful Evolutionary Change for Your Technology Business 38

39 Corey Ladas ttp://leansoftwareengineering.com/2007/10/27/kanban-bootstrap/ 39

40 40 ( 協力 : ヤマハモーターソリューション )

41 ポータブルかんばん ( 協力 :CCS 佐藤竜一さん ) POINT 41 かんばん -nano スーツにもベストフィット!

42 バーンダウンチャート進捗の見える化バーンダウン ( 下向き ) タスクかんばんと連動中間成果物では計測しないメールでエクセルシートを配布したりサーバに置いたから見てねはナシバーンダウンチャートの例 ( 協力 : 永和システムマネジメント : チーム角谷 ) POINT 42 全体進捗はバーンダウンチャートで見える化繰り返しのリズムづくり

43 スルーしない

44 朝会作業の明確化自発的なサインアップ昨日やったこと今日やること問題点の 3 点のみかんばんの前で行なう朝の仕事はじめが重要! スタンドアップで 15 分. 定時刻定位置短時間朝会の例 ( 協力 : チェンジビジョン astah* チーム ) PF 実践編 : 朝会ガイド POINT 毎朝かんばんの前で全員で短い会議を行ないリズムをとる p.44

45 ふりかえり (1) カイゼンの気づき Keep( 良い点 ) Problem( 悪い点 ) Try( 次回挑戦 ) を出す全員で意見を出し暗黙知の共同化と形式知化を行なう名前付け課題 - 解決リストとは違うとにかくカジュアルな雰囲気でふりかえりシートの例全員発言することでチームの実践編 : ふりかえりガイド安全性を確保する問題 vs 私たちの構図になるように POINT p.45 カイゼンの気づきをふりかえりで得る

46 ふりかえり (2) Keep/Problem/Try(KPT) Keep は定着する Problem は Try を生み出す Try は Keep か Problem に移動する定着したものには名前づけをやってみてうまく行った Keep うまく行かない定着 Problem Try 解決法新しい問題! 新しいアイディア! ふりかえりがカイゼンを導く POINT p.46 イテレーション毎にふりかえりを繰り返すことでプロセスが改善される

47 47

48 esm-conference ブログよりやわたメディカルさんの事例 48 現場ではこのように KPT を張り出し気づいた時に付箋をはり毎日お昼に話し合ってすぐアクションというサイクルで回していたとのこと 24 時間 /365 日とまらない現場はこのように手軽に導入しやすく当事者同士で話し合って解決策を見つける仕組み ( 問題 vs 私たち ) がフィットしたとのこと

49 佐賀県庁の事例 (1) ニコニコカレンダー 49 ( 協力 : 佐賀県庁東泰史さん )

50 タスクかんばん佐賀県庁の事例 (2) 危険ゾーン ( 協力 : 佐賀県庁東泰史さん ) 50

51 朝会佐賀県庁の事例 (3) 副知事 ( 協力 : 佐賀県庁東泰史さん ) 51 ぜひこの資料を見てください ( 有名資料 )

52 ヴァル研究所日本最大数 (100 以上 ) のかんばん実践例が観れます下は総務 (!) の例営業でも開発でも

53 5 つの原則見える化 (Management by Sight) 目に見えるようにして行動につなげるリズム (Rhythm) 人間活動として定期的なリズムを設計する名前づけ (Name and Conquer) 気づいた概念に名前をつけておく問題 vs. 私たち (Problem vs. us) 問題と人間を分離するカイゼン (Kaizen) 継続的に今の自分たちにできる小さいことから

54 見える化 / 透明性最新の正の情報が一箇所に大きく書かれていてそれを両チームのメンバー審判観客が見ている次の行動を誘発する POINT 全ステークホルダーが行動を起こせるような確かな分かりやすい情報源 54

55 リズムリズムをデザインする四半期月週日会議や成果物のタイミング日次のテスト日次の朝会 ( 毎朝 10:00) 週次の会議 ( 毎週金曜は ) 朝会ふりかえりのタイミングリズムがチームのハートビートリズムが行動の搬送波 POINT p.55 リズム ( チームの鼓動 ) をデザインしてチームを前進させよう

56 名前付け気づきをキャッチナレッジを, 定着他のチームに伝播例 : 今日のお仕事 (by 坂田さん ) ぬかどこ (by 倉貫さん ) にこにこカレンダー名前は大切 ( 写真協力 : 平塚市博物館 POINT p.56 名前をつけないと, 気づきが逃げて行っちゃう!

57 問題対私たち (Problem vs. Us) ともすると, 議論は You vs. Me You vs. Us になりがち. 問題と人とを分離 Problem vs. Us にもちこむホワイトボードを使う座り方を替えるペアプログラミング You vs. Me の構図問題 vs. Us の構図 You vs. Us の構図問題 vs. Us の構図 POINT p.57 不毛なゼロサムゲームから, 生産的な議論へ向かうカギ.

58 大きな改革でははじまらない小さなカイゼンから今の自分たちでできること来週からできることよくなっていくことを体感しようふりかえりが強力な武器 For the better tomorrow 明日はきっと今日よりもいい日に決まっているカイゼン POINT p.58 継続的に今の自分たちでできることからカイゼンをうまくいったら自分たちをホメよう

59 全体構成色つき UML 1 週間見える化リズム名前づけ問題対私たちカイゼン計画イテレーション開発ふりかえり半日一日の繰り返し半日タスク要求タスクタスク朝会かんばんバーンダウンタスクふりかえりペアボードあんどんマインドマップにこにこカレンダー SKMS p.59

60 astah* 開発チーム例 p.60

61 デジタルとアナログ

68 Scrum と野中郁次郎 ( 時間があれば )

70 最初のスクラムの本 Agile Software Development with Scrum (by Ken Schwaber, Mike Beedle) の最初の一行は次の引用で始まっている今日では新製品開発の動きが速く競争率の高い世界では速度と柔軟性がとても重要である企業は新製品開発に直線的な開発手法は古くこの方法では簡単に仕事を成し遂げることができないことを徐々に認識し始めている日本やアメリカの企業ではラグビーにおいてチーム内でボールがパスされながらフィールド上を一群となって移動するかのように全体論的な方法を用いている -- The New New Product Development Game

73 Agile and Lean Toyota Production System The New New Product Development Game Manufacturing Industry in Japan 2 Lean Software Development 1 Scrum Patterns XP Agile Lean Kanban 2013 Yasunobu Kawaguchi Lean Startup Startup Four steps to the epiphany

Innovation Sprint 2011 http://www.publickey1.

74 Innovation Sprint me Jeff Sutherland Ikujiro Nonaka

75 野中郁次郎 The New New Product Development Game(HBR) 1 Scrum リレーからラグビーへ The Knowledge Creating Company U.S. Marine 4 2 SECI モデル暗黙知と形式知のスパイラルな変換活動が知識創造過程である 3 フラクタル組織どの階層においても自己相似形 Managing Flow, The Wise Leadership(HBR) 実践知フロネシス形式知と暗黙知を繋ぐ実践知

76 SECI モデル Seeing is understanding.

77 知識創造は暗黙知と形式知の相互変換運動である暗黙知 (Tacit Knowledge) 形式知 (Explicit Knowledge) 言語文章で表現するのが難しい主観的身体的な経験知特定の文脈ごとの経験の反覆によって体化される思考スキル ( 思いメンタルモデル ) や行動スキル ( 熟練ノウハウ ) 言語文章で表現できる客観的理性的な言語知特定の文脈に依存しない一般的な概念や論理 ( 理論問題解決手法マニュアルデータベース ) 相互作用のスパイラルアップアナログ知 - デジタル知の動的綜合 Nonaka I.

78 暗黙知言語文章で表現するのが難しい主観的身体的な経験知特定の文脈ごとの経験の反覆によって体化される思考スキル ( 思いメンタルモデル ) や行動スキル ( 熟練ノウハウ ) 78

79 形式知言語文章で表現できる客観的理性的な言語知特定の文脈に依存しない一般的な概念や論理 ( 理論問題解決手法マニュアルデータベース ) 79

新たな関係 ( 連想仮説 ) を作り出す ( 井崎正敏 < 考える > とはどういうことか?

80 暗黙知と形式知 - 氷山のメタファー - 1. メタファーの本質とはある種類のことがらを別の種類のことがらの見地から理解し経験することである ( レイコフ G. & M. ジョンソンレトリックと人生 ) 2. 本来まったく異なる領域にあるものどうしを重ね合わせることでその領域にはなかったイメージを導入し新たな関係 ( 連想仮説 ) を作り出す ( 井崎正敏 < 考える > とはどういうことか? 洋泉社 2008) 例 : 暗黙知のイメージ氷山のメタファー形式知 ~~~~~~ 暗黙知水面下の領域には膨大な感覚イメージ的な経験知があるそれを共感し共有し変換して新しい知をつくりだす Nonaka I.

ナレッジは非常にスティッキー (sticky) である ( 移動しにくい ) ことが分かってきたニーズナレッジには暗黙知の部分が多く

81 Sticky Information 81 一般に製品開発に必要なナレッジは大きく 2 つに分けられる 1 つはシーズナレッジもう 1 つはニーズナレッジこれまでの手法ではニーズナレッジをメーカー主導で収集しようとしていた紙に書かれた情報としてメーカーに持ち帰ろうとしていたのであるしかしニーズナレッジは非常にスティッキー (sticky) である ( 移動しにくい ) ことが分かってきたニーズナレッジには暗黙知の部分が多く文書化した段階で多くの情報が抜け落ちるイノベーションに必要なのは形式知化できない情報であり紙に書かれたものではない -- Democratizing Innovation (by Eric Von Hippel)

82 組織的知識創造の行為 - SECI モデルどう知るか - 暗黙知暗黙知共同化 (S) 表出化 (E) 暗黙知暗黙知 Environment I Individual 内面化 ( I) O G I E 連結化 (C) E I I O G G Org. I I Group I G I 形式知形式知 E G 形式知形式知 Nonaka I. & H. Takeuchi

組織的知識創造の行為 - SECI モデルどう知るか - 身体五感を駆使直接経験を通じた暗黙知の獲得共有創出 ( 共感 ) 1. 組織内外の活動による現実直感 2. 感情移入気づき予知の獲得 3. 暗黙知の伝授移転形式知を行動を通じて具現化新たな暗黙知として理解学習 ( 実践 ) 9. 反省的実践を通じた形式知の体化 10.

83 組織的知識創造の行為 - SECI モデルどう知るか - 身体五感を駆使直接経験を通じた暗黙知の獲得共有創出 ( 共感 ) 1. 組織内外の活動による現実直感 2. 感情移入気づき予知の獲得 3. 暗黙知の伝授移転形式知を行動を通じて具現化新たな暗黙知として理解学習 ( 実践 ) 9. 反省的実践を通じた形式知の体化 10. 目標 - 成果の持続的追求自己超越暗黙知暗黙知暗黙知暗黙知共同化 (S) 表出化 (E) Environment E O I I I I Individual Group I I I 内面化 ( I) 連結化 (C) O E G G I GOrg. G E G 形式知形式知 Nonaka I. & H. Takeuchi 形式知形式知対話思索比喩による概念図像仮説の創造 ( 概念化 ) 4. 自己の暗黙知の言語化 5. 言語から概念仮説原型の創造形式知の組み合わせによる情報活用と知識の体系化 ( 分析 ) 6. 概念間の関係生成とモデル化 7. 形式知の伝達普及共有 8. 形式知の編集操作化 IT 化 I = 個人 G = 集団 O = 組織 E = 環境

84 Seeing is understanding. Design Thinking との関係

integrate the needs of people, the possibilities of technology,

85 Design Thinking 85 Design thinking is a human-centered approach to innovation that draws from the designer's toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success. Tim Brown, president and CEO

86 86 IDEO Method Cards

87 87 iphone アプリもあるよ

88 88

89 89

90 SECI モデルとアジャイルプラクティス Tacit Tacit Socialization Externalization Sprint Demo Story Writing Visit Users Coding Standard Pair Programming Daily Standup Sit Together Retrospectives Explicit Internalization Everything about Learning Combination Sprint Planning Explicit Explicit Explicit

91 T T 知識創造マシンとしてのスクラム創造された 2 つの知識 S E E 要求とユーザに関する知識ソフトウェアの作り方に関する知識 I C E E E 成長するソフトウェア製品成長するスクラムチーム

92 対象に棲み込む -Indwelling- あらゆる状況の手がかりを統合して対象に住み込みライダーの視点 ( 内側 ) から切開していく暗黙的な知り方提供 : 本田技研工業マシンを見ているといろんなことがわかりますあのカーブを切るにはああやればこうすればとそして次の製作過程へ自然に入っているんです

93 その場で概念 ( コンセプト ) を紡ぎ合う言葉と動作言語化によって初めて自己の考えが明確になる床の上の設計図提供 : 本田技研工業

Nonaka s Text Agile/Scrum (Software) The New New Product

CI-model Fractal Organization アメリカ海兵隊 (U.S.

Scrum Master Daily Scrum 2001 Agile Software Development with Scrum

94 Nonaka s Text Agile/Scrum (Software) The New New Product Development Game 1986 Scrum The Knowledge Creating Company (HBR) Org. Patterns(by Jim Coplien) (at PLoP) 1994/1 First Sprint of Scrum by Jeff Sutherland SECI-model Fractal Organization アメリカ海兵隊 (U.S. Marine) /2 Second Sprint of Scrum (with Cope s Ideas) Scrum Master Daily Scrum 2001 Agile Software Development with Scrum (by Ken Schwaber, Mike Beedle) 2001 The Agile Manifesto Phronetic Leadership Managing Flow 2008 Wise Leadership (HBR) Software in 30 days 2013 アジャイル開発とスクラム - 顧客技術経営をつなぐ協調的ソフトウェエア開発 Collaborative Software Development That Connects Customers, Engineers, and Management

95 副題顧客技術経営をつなぐとは? 95 出所 :Page, T. & J. Pimlott, eds., NAM(1988) P.10 95

98 98

自己紹介永和システムマネジメント福井市 ( 本社 ) 上野東京 ( 支社 ) Ruby と Agile を使ったシステム開発株式会社チェンジビジョン福井市 ( 開発部 ) 上野東京 ( 本社 ) astah* ( 旧 :JUDE) の開発平鍋健児 UML+ マインドマップエディタ asta

自己紹介永和システムマネジメント福井市 ( 本社 ) 上野東京 ( 支社 ) Ruby と Agile を使ったシステム開発株式会社チェンジビジョン福井市 ( 開発部 ) 上野東京 ( 本社 ) astah* ( 旧 :JUDE) の開発平鍋健児 UML+ マインドマップエディタ asta 初歩から学ぶアジャイル開発入門株式会社チェンジビジョン株式会社永和システムマネジメント平鍋健児自己紹介永和システムマネジメント福井市 ( 本社 ) 上野東京 ( 支社 ) Ruby と Agile を使ったシステム開発株式会社チェンジビジョン福井市 ( 開発部 ) 上野東京 ( 本社 ) astah* ( 旧 :JUDE) の開発平鍋健児 UML+ マインドマップエディタ astah*