SlideShare una empresa de Scribd logo
1 de 41
Descargar para leer sin conexión
カンバン vs スクラム
                                   実践ガイド
                            Future of Agile, Stockholm
                                  May 27, 2009


Henrik Kniberg - Crisp AB
Agile coach & Java guy
Cofounder / CTO of Goyada (mobile services)
30 developers
                                 09/9/2
Lead architect at Ace Interactive (gaming)
20 developers
                            Henrik Kniberg
Chief of development at Tain (gaming)
40 developers
Agile coach at various companies

henrik.kniberg@crisp.se
+46 70 4925284
                                                         1
最初に

このプレゼンテーションの目的:

カンバンとスクラムを比較することではっきりさせること。
... そして、あなたの環境でこれらのツールをどのように使えそう
か、わかるでしょう。




 Henrik Kniberg        22     2
組織を分ける

       スクラムを一言で表すと
 製品を分ける


                        大きなグループでは大きなモノの構築に長い時間を費やす。
                        小さなチームは小さいモノの構築に短い時間を費やす。
                        …でも全体を眺めるために定期的に統合します。


                                プロセスを最適化
ビジネスの価値を最適化

 $$$

                    時間を分割
                  1月                                                                                                                                                                                       4月

  $


                                     Not
                                             checked out                                            Done! :o)                              SP INT G A : B
                                                                                                                                             R     O L eta-ready rel ease!
                                 checked out
                                                                                                                                                                               Burndown
                                                                                                                         Write
                                                                                                    Deposit              failing
                                                                                                                          test
                                                                                                                        2d
                                                                                                                                   DAO
                                                                                                   Code       Inte gr
                                                                                                  cle anup                     DB
                                                                                                               test
                                                                                                             2d 0.5d         desig n
                                                                                                   1d                        2d
                                                                                                                                 1d


                                                                     GUI                        Write

                                 Migration                           sp ec
                                                                     2d
                                                                                                fa iling
                                                                                              2d te st
                                                                                               1d      3d
                                    tool                                         Tapes
                                                                                       t ry
                                                                                  sp ike
                                                      Impl.                      1d
                                                                                      2d
                                                    migration
                                                          8d



                                 Backoffice                           Write
                                                                      failin g
                                                                        test
                                   Login             I mpl
                                                     GUI
                                                                     2d
                                                                                                                                           Unpl anned items                               Next
                                      In tegr.           1d
                                        with
                                       JBoss
                                             2d

                                                         Write
                                                                                                                                               Fix memo
                                                                                                                                                  leak
                                                                                                                                                        ry
                                                                                                                                                             Sal es sup port
                                                                                                                                                                                       Withdraw
                                                                                                                                                                                      P test
                                                                                                                                                                                       erf
                                 Backoffice              fail ing
                                                          test
                                                                                                                                         WriteIRA
                                                                                                                                             (J
                                                                                                                                         failin g
                                                                                                                                           2d
                                                                                                                                          te st
                                                                                                                                                     125)                             Withdraw
                                                                3d                                                                                              3d        Write

                                 User adm
                                                                                                                                                                        whitepap er
                                          in                                                                                                                           4d
                                   GUI       Clarify
                                  desig n    req uire-   Impl
                                  (CSS)       ments      GUI
                                        1d          2d      6d




       Henrik Kniberg                                                                                                                                                                                33    3
カンバンを一言で表すと…
                     To do   Dev      Test    Release   Done!
                      5      3            2    3

   仕事の流れを見える化          H         F     D           C
                                                        A
                      I      G         E
   作業中(WIP:work in      J
                                                        B

                       K
   progress)を制限
   測定、そして流れの最適化                      FLOW




Henrik Kniberg                       44                     4
カンバンのルーツ(トヨタ)                      看板


            買い手                            納入業者




 消費         取り外し    受取              出荷         割当   製造




必要な時に必要なだけ生産という考え方(Just-
in-time)と、自律と人間味のある自動化(自働化)
がトヨタ生産方式の二つの柱です。
これらの仕組みを運営するためツールがカンバ
ンです。


                              トヨタ生産方式の父
                              大野耐一氏
  Henrik Kniberg                          55         5
ソフトウェア開発におけるカンバン




Henrik Kniberg     66   6
カンバンとスクラム、
どちらもプロセスの(仕事を流す)ためのツール
          物理的なツール   プロセスのツール
                    別名 ”組織のパターン”


                       プロダクトオーナー




                    ペアプロ
                            食事しながら
                            ミーティング




Henrik Kniberg        77           7
前もって決められているか vs 適応か

前もって決められている方向                                                                                                                                                                                   より適応する方向


                                            RUP                                                XP                        スクラム                             カンバン                               なんでもする
                                           (120+                                              (13)                        (9)                              (3)                                 (0)
  •
  •
  •
      Architecture Reviewer
      Business Designer
      Business-Model Reviewer
                                             )
                                             •
                                             •
                                             •
                                                 Business use case realization
                                                 Business use-case model
                                                 Business vision
                                                                                        •
                                                                                        •
                                                                                            Whole team
                                                                                            Coding standard
                                                                                                                     •
                                                                                                                     •
                                                                                                                         Scrum Master
                                                                                                                         Product Owner
                                                                                                                                                   •
                                                                                                                                                   •
                                                                                                                                                       Visualize the workflow
                                                                                                                                                       Limit WIP
  •   Business-Process Analyst               •   Change request                         •   TDD                      •   Team                      •   Measure and optimize lead time
  •   Capsule Designer                       •   Configuration audit findings           •   Collective ownership     •   Sprint planning meeting
  •   Change Control Manager                 •   Configuration management plan          •   Customer tests           •   Daily Scrum
  •   Code Reviewer                          •   Data model                             •   Pair programming         •   Sprint review
  •   Configuration Manager                  •   Deployment model                       •   Refactoring              •   Product backlogt
  •   Course Developer                       •   Deployment plan                        •   Planning game            •   Sprint backlog
  •   Database Designer                      •   Design guidelines                      •   Continuous integration   •   BUrndown chart
  •   Deployment Manager                     •   Design model                           •   Simple design
  •   Design Reviewer                        •   Development case                       •   Sustainable pace
  •   Designer                               •   Development-organization               •   Metaphor
  •   Graphic Artist                             assessment                             •   Small releases
  •   Implementer                            •   End-user support mateirla
  •   Integrator                             •   Glossary
  •   Process Engineer                       •   Implementation model
  •   Project Manager                        •   Installation artifacts
  •   Project Reviewer                       •   Integration build plan
  •   Requirements Reviewer                  •   Issues list
  •   Requirements Specifier                 •   Iteration assessment
  •   Software Architect                     •   Iteration plan
  •   Stakeholder                            •   Manual styleguide
  •   System Administrator                   •   Programming guidelines
  •   System Analyst                         •   Quality assurance plan
  •   Technical Writer                       •   Reference architecture
  •   Test Analyst                           •   Release notes
  •
  •
  •
      Test Designer
      Test Manager
      Tester
                                             •
                                             •
                                                 Requirements attributes
                                                 Requirements
                                                 management plan
                                                                                                                             武器や流派にこだわるな。
  •
  •
  •
      Tool Specialist
      User-Interface Designer
      Architectural analysis
                                             •
                                             •
                                             •
                                                 Review record
                                                 Risk list
                                                 Risk management plan
                                                                                                                             (引用:アジャイルソフトウェア開発
  •

  •
      Assess Viability of architectural
      proof-of-concept
      Capsule design
                                             •

                                             •
                                                 Software architecture
                                                 document
                                                 Software development
                                                                                                                             著アリスター・コーバーン)
  •   Class design                               plan
  •   Construct architectural proof-of-      •   Software requirements specification

  •
  •
      concept
      Database design
      Describe distribution
                                             •
                                             •
                                             •
                                                 Stakeholder requests
                                                 Status assessment
                                                 Supplementary business specification
                                                                                                                                      宮本武蔵
  •
  •
      Describe the run-time architecture
      Design test packages and classes
                                             •
                                             •
                                                 Supplementary specification
                                                 Target organization assessment                                                       1584-1645
  •   Develop design guidelines              •   Test automation architecture
  •   Develop programming guidelines         •   Test cases
  •   Identify design elements               •   Test environment configuration
  •   Identify design mechanisms             •   Test evaluation summary
  •   Incorporate design elements            •   Test guidelines
  •   Prioritize use cases                   •   Test ideas list
  •   Review the architecture                •   Test interface specification
  •   Review the design                      •   Test plan
  •   Structure the implementation model     •   Test suite
  •   Subsystem design                       •   Tool guidelines
  •   Use-case analysis                      •   Training materials
  •   Use-case design                        •   Use case model
  •   Analysis model                         •   Use case package
  •   Architectural proof-of-concept         •   Use-case modeling guidelines
  •   Bill of materials                      •   Use-case realization
  •   Business architecture document         •   Use-case storyboard
  •   Business case                          •   User-interface guidelines
  •   Business glossary                      •   User-interface prototype
  •   Business modeling guidelines           •   Vision



 Henrik Kniberg                                                                                                                                                                         88            8
  •   Business object model                  •   Work order
  •   Business rules                         •   Workload analysis model
  •   Business use case
スクラムの定義する役割




                 P   SM
                 O




Henrik Kniberg            99   9
スクラムが定義するイテレーション
スクラムチーム
                           week 1    week 2   week 3   week 4    week 5   week 6   week 7   week 8



カンバンチーム 1                           スプリント 1                     スプリント 2

                  計画 と合意                 デモ
                                                        ふりかえり
                                       (リリース?)



カンバンチーム 2                  week 1    week 2   week 3   week 4    week 5   week 6   week 7   week 8

        ふりかえり (4w)

          計画 周期 (2w)

         リリース周期 (1w)




カンバンチーム 3                  week 1    week 2   week 3   week 4    week 5   week 6   week 7   week 8

        ふりかえり (4w)

         計画 (必要時)

        リリース(必要時)




 Henrik Kniberg                                                                                  10
どちらも作業中(WIP)を制限するが、方法が異
なる
          スクラムボード                  カンバンボード


  To do   Ongoing Done :o)   To do   Ongoing Done :o)
                                        2
                     A                         A
                 B                      B
     C                         C
     D                         D

            FLOW                      FLOW




作業中を時間単位で制限                  作業中を状態で制限
(iteration)
                                     作業中:WIP(Work in
                                     Progress)
Henrik Kniberg                               1111       11
どちらも経験に基づいている


        速度                  リードタイム            品質              予測可能性
     (aka ベロシティ)        (akaサイクルタイム)        (障害の割合等)          (SLAの達成,等)




                                               カンバンは、より再構成しやすい


                                               すごい!たくさんの       うわぁ、もっと複雑に
  多くの小さなチーム                  2,3の大きなチーム         選択肢がある!         なってしまった!
  作業中制限(少)                   大きい作業中制限

ワークフローの状態(少)                 ワークフローの状態(大)

  イテレーション(短)                 イテレーション(大)

      計画回数(少)                計画回数(大)

         .... etc ...        .... etc ...


 Henrik Kniberg                                        1212                12
例: WIP制限による実験
Monday, Week 1                   Monday, Week 2              Monday, Week 3                Monday, Week 4
To do Ongoing      Done :o)       To do Ongoing   Done :o)   To do Ongoing                   To do Ongoing
                                                                              Done :o)                       Done :o)
          1                                8                          8                                  8
C        B           A                    C         A                   D      A                         D    A
                                                    B         H                 B                              B
D                                  E      D                         E                               E
E                                  F                          I     F          C                L             C
                                                                                                     F
F                                                                       G                                G
                                   G                                                            M
     ZZZZzzzzz                                                                                           H
     z                                                                                       N       I
              暇で暇でしょうがな                                            統合しているサーバ                         J
              い。WIP制限を8にし                                          で問題があってDとE                       K
                 てみよう。                                             が終わらなかったぞ。
                                                                   代わりにFとGをやら
                                                                      ないと。                うわぁ。WIP制限に
                                                                                          ひっかかった。すぐ
                                                                                          に作業を止めて統           WIP制限を4にし
  Monday, Week 5                                                                          合しているサーバを          てみよう。そして
                                                                                            直さないと!           次は早めに対処
    To do Ongoing     Done :o)
               4                                                                                                しよう。

    N         L          J
    O         M           K
    P




     Henrik Kniberg                                                                      1313                   13
Eが欲しくなったよ!


スクラムはイテレーション中変更を許可しませ
                 P
ん。               O                                     To Do のスロットが空く
                                                       のを待ってください。そ
                     次のスプリントまで待っ                       れかCかDと交換してく
                        てください                                ださい。

Scrum                              Kanban

  To do   Ongoing Done :o)         To do    Ongoing Done :o)
                                     2         2
     C           A                   C        A

    D            B                   D         B


            FLOW                             FLOW




Henrik Kniberg                                      1414                14
スクラムボードはどのイテレーション間でもリ
セットします。
 Scrum
 スプリントの最初の日      スプリント中   スプリントの最終日




 Kanban
 いつでも




Henrik Kniberg              1515      15
スクラムはなんでも屋チームで規定されます。

スクラム              カンバン – 例 1   カンバン – 例 2




                               専門家               専門家
                                        なんでも屋の
                     なんでも屋の                      チーム
    なんでも屋の                              チーム
    チーム              チーム




 Henrik Kniberg                      1616        16
スクラムのバックログ要素はスプリントに合わ
    ければなりません。
      スクラム




              Sprint 1     Sprint 2   Sprint 3   Sprint 4



      カンバン

                                          期間を跨ったタスク
WIPの制限 = 3               期間を跨ったタスク




    Henrik Kniberg                                          1717   17
スクラムでは、見積もりやベロシティは規定さ
れています。


                         V= 8                  V= 7                  V= 9

          1      2                   2                 1    1    2
                                                                            ベロシティは大体: 8 / sprint
           2         3           1         3    1       2        2    1     (継続的なペースですか?)

         Sprint 1               Sprint 2              Sprint 3




Henrik Kniberg                                                                    1818             18
どちらも同時に複数の製品に携わることがで
  きます。
スクラムの例 1                              カンバンの例1
                            製品毎のチーム   色で意味づいたタスク
 緑の製品               黄の製品
            緑チーム             黄チーム




スクラムの例2             スクラムの例 3          カンバンの例2
          製品をまたいだ   全ての製品   製品をまたいだ   レーンで意味づいたタスク
全ての製品
          チーム               チーム




  Henrik Kniberg                         1919        19
1.    短期的財務目標を犠牲にしてでも長期的な考えで経営判断する。
                         2.    淀みのない流れをつくって、問題を表面化させる


     どちらもリーン
                         3.    プルシステムを利用して、つくり過ぎのムダを防ぐ
                         4.    生産量を平準化する(ウサギではなく、亀のペースで仕事をする)


     でアジャイル
                         5.    問題を解決するためにラインを止め、品質を最初からつくり込むカルチャーを定着
                               させる。
                         6.    標準化作業が絶え間ない改善と従業員の自主活動の土台になる。
                         7.    すべての問題を顕在化させるために目で見る管理を使う
                         8.    技術を使うなら、実績があり、枯れた、人や工程に役立つ技術だけを利用する。
1.    プロセスやツールより         9.    仕事をよく理解し、思想を実行し、他人に教えるリーダーを育成する
      人と人同士の相互作用を重視する。   10.   会社の考え方に従う卓越したヒトとチームを育成する
2.    包括的なドキュメントより       11.   パートナーや部品メーカ等の社外ネットワークを尊重し、改善するのを助ける
      動作するソフトウェアを重視する。
                         12.   現地現物を徹底的に理解するように自分の目で確かめる(現地現物)
3.    契約上の交渉よりも
      顧客との協調を重視する        13.   意思決定はじっくりコンセンサスをつくりながら、あらゆる選択肢を十分検討する
                               が、実行は素早く行う(根回し)
4.    計画に従うことよりも
      変化に対応することを重視する。    14.   執拗な反省と絶え間ない改善により学習する組織になる




                                                   リーン
                                                    人
                                           ジャス     品質   ライン
                                            ト・     コスト
                                                    改善
                                           イン・           を
                                           タイム   リードタイム 止める
                                                  無駄を省
                                                      く
     Henrik Kniberg                              2020
                                              いつでも使える状態を保つ       20
小さな違い:
  スクラムにはプロダクトバックログがある
        スクラム:                 カンバン:
          プロダクトバックログは必ず存        プロダクトバックログは必ずしも存
          在する。                  在しない。
          プロダクトバックログの変更は        プロダクトバックログは着手可能
          次のスプリントに影響する。         であればすぐに変更できる
          (現在のスプリントではない)        あらゆる優先度を順付ける枠組
          プロダクトバックログはビジネ        みを使える。例えば:
          ス価値が大きいものから順に           どの項目からでも
          並べられる                   いつも一番上の項目から
                                  いつも一番古い項目から
                                  20%は保守項目から、
                                  80%は新機能から
... だけど多くのチームではこれらのアプローチを組み
                                  製品Aと製品Bを均等に
合わせてつかってるけどね
                                  緊急の項目を先に




  Henrik Kniberg                         2121      21
小さな違い:
スクラムには朝会がある




                 ... だけど多くのカンバンチームもそうしているね。




Henrik Kniberg                                2222   22
小さな違い:
   スクラムにはバーンダウンチャートがある。
                              Burndown                   カンバンといえば「これ」といった
             70                                          図はない。チームにとって必要で
             60                                          あればどんなものでも使う。
Estim work 50
     ated
   remaining 40
             30
             20
             10

          August 1 2 3 4 5 8 9 10 11 12 15 16 17 18 19
                               Date




   Henrik Kniberg                                                2323       23
例: スクラムボード vs カンバンボード
スクラム
  Product        Sprint backlog
  backlog
                    Committed Ongoing Done :o)
    E
    E
    F                                               A
    F
    G                               B
   HG I                             C
  J H
    L
      K                 D
  M



カンバン
                                            Dev
   Backlog          Selected                 3           In production :o)
                         2        Ongoing         Done

                        D            B              A        X
         F                                                       R
             G          E               C
     H                                                      Q
        I
    J L
    M   K




Henrik Kniberg                                                               2424   24
シナリオ1 –ある仕事の流れ


                                                      Dev
            Backlog                  Selected             3          In production :o)
                                         2
                                                Ongoing       Done
                     A
                             B
             G

                         C
             F
                             D
         H
                     I
        J        L               E
         M           K




Henrik Kniberg                                                            2525           25
シナリオ1 –ある仕事の流れ


                                                      Dev
            Backlog                  Selected             3          In production :o)
                                         2
                                                Ongoing       Done

                                        A
             G
                                         B
                         C
             F
                             D
         H
                     I
        J        L               E
         M           K




Henrik Kniberg                                                            2626           26
シナリオ1 –ある仕事の流れ


                                                      Dev
            Backlog                  Selected             3          In production :o)
                                         2
                                                Ongoing       Done

                                                  A
             G
                                         B
                         C
             F
                             D
         H
                     I
        J        L               E
         M           K




Henrik Kniberg                                                            2727           27
シナリオ1 –ある仕事の流れ


                                               Dev
            Backlog          Selected             3          In production :o)
                                 2
                                        Ongoing       Done

                                 C                     A
             G
                                D          B

             F

         H
                     I
        J        L       E
         M           K




Henrik Kniberg                                                    2828           28
シナリオ1 –ある仕事の流れ


                                                Dev
            Backlog          Selected             3          In production :o)
                                 2
                                        Ongoing       Done

                                            C                       A
             G
                                D                        B

             F

         H
                     I
        J        L       E
         M           K




Henrik Kniberg                                                    2929           29
シナリオ1 –ある仕事の流れ


                                          Dev
            Backlog      Selected             3          In production :o)
                             2
                                    Ongoing       Done

                             F        D           C             A
             G
                                                                B
                             E



         H
                     I
        J        L
         M           K




Henrik Kniberg                                                3030           30
シナリオ 2 – 問題があったときの展開


                                                      Dev
            Backlog                  Selected             3          In production :o)
                                         2
                                                Ongoing       Done
                     A
                             B
             G

                         C
             F
                             D
         H
                     I
        J        L               E
         M           K




Henrik Kniberg                                                            3131           31
シナリオ 2 – 問題があったときの展開


                                                      Dev
            Backlog                  Selected             3          In production :o)
                                            2
                                                Ongoing       Done

                                        A
             G
                                        B
                         C
             F
                             D
         H
                     I
        J        L               E
         M           K




Henrik Kniberg                                                            3232           32
シナリオ 2 – 問題があったときの展開


                                               Dev
            Backlog          Selected             3          In production :o)
                                 2
                                        Ongoing       Done

                                 C        A
             G
                                D          B

             F

         H
                     I
        J        L       E
         M           K




Henrik Kniberg                                                    3333           33
シナリオ 2 – 問題があったときの展開


                                               Dev
            Backlog          Selected             3          In production :o)
                                 2
                                        Ongoing       Done

                                           C            A
             G
                                D          B

             F

         H
                     I
        J        L       E
         M           K




Henrik Kniberg                                                    3434           34
シナリオ 2 – 問題があったときの展開


                                               Dev
            Backlog          Selected             3          In production :o)
                                 2
                                        Ongoing       Done

                                           C            A
             G
                                D
                                          !?            B

             F

         H
                     I
        J        L       E
         M           K




Henrik Kniberg                                                    3535           35
シナリオ 2 – 問題があったときの展開


                                           Dev
            Backlog      Selected             3          In production :o)
                             2
                                    Ongoing       Done


             G                        !?            A

                            D                       B

             F
                             E                      C
         H
                     I
        J        L
         M           K




Henrik Kniberg                                                3636           36
シナリオ 2 – 問題があったときの展開


                                          Dev
            Backlog      Selected             3          In production :o)
                             2
                                    Ongoing       Done

                                                    A
             G
                            D                       B

             F
                             E                      C
         H
                     I
        J        L
         M           K




Henrik Kniberg                                                3737           37
シナリオ 2 – 問題があったときの展開


                                          Dev
            Backlog      Selected             3          In production :o)
                             2
                                    Ongoing       Done

                                                                 A
             G
                            D                                    B

             F
                             E                      C
         H
                     I
        J        L
         M           K




Henrik Kniberg                                                3838           38
シナリオ 2 – 問題があったときの展開


                                           Dev
            Backlog      Selected             3          In production :o)
                             2
                                    Ongoing       Done

                                      D                          A
             G
                                                                 B
                                       E
             F
                                                    C
         H
                     I
        J        L
         M           K




Henrik Kniberg                                                3939           39
カンバン vs スクラム               www.crisp.se/henrik.kniberg/kanban-vs-scrum.pdf
概要
にているところ                  ちがうところ
                         スクラム                     カンバン
 どちらもリーンでアジャイルである     時間を区切ったイテレーション(タイム 時間を区切ったイテレーションは必須
 どちらもプルスケジュールを基にしている ボックス)が定義されている。       ではない
                      イテレーション内の仕事量を具体的にする コミットメントは必須ではない
 どちらもWIPの制限がある        ため、チームでコミットする。
 どちらも透明性に基づいて、改善をよりしや ベロシティを計画づくりとプロセス改善の リードタイムを計画づくりとプロセス改善
 すくしている               ための標準の測定基準として使う     のための標準測定基準として使う
 どちらもソフトウェアを早く、頻繁にリリース 職制を横断したチームが規定されてい 職制を横断するチームはオプション。専門
 可能にすることに注力する。         る                  家のチームが許される。
 どちらも自己組織的なチームに基づく     1スプリントに完了できる大きさにタス タスクの大きさに特に決まりがない。
                         クを分割する.
 どちらも作業を細かく分割することを求める バーンダウンチャートが定義されてい 図の種類について特に決まりがない。
 どちらもリリース計画を実証されたデータ(ベ る。
 ロシティ/リードタイム)を継続的に最適にしてWIPの制限が間接的 (スプリントごと) WIPの制限が直接的 (ワークフローの状
 いる                                         態ごと)
                         見積もりをする。           見積もりは必須ではない。
                         進行中のスプリントにタスクを追加でき 着手可能な時タスクを追加できる。
                         ない。
                         スプリントバックログは特定のチーム カンバンボードは複数のチーム、もしく
                         からのみ所有される。         は人々が共有できる。
                         3つの役割 (PO/SM/Team) 役割は特に規定されない
                         スプリントごとにスクラムボードはリ  カンバンボードにリセットするタイミング
                         セット                はない
                         優先順位付けされたプロダクトバックロ 優先順位付けは必須ではない
                         グが規定されている
 Henrik Kniberg                                     4040             40
一番大切なこと:
ふりかえりと共にはじめよう!
                 より自分たちにあったプロセ
                 スに進化させよう.
                 最初は間違えてもいいじゃ
                 ない
                 いいことは道具箱に追加し
                 よう。
                 試そう!




Henrik Kniberg        4141   41

Más contenido relacionado

La actualidad más candente

「ユーザーを理解するって言うほどカンタンじゃないよね」 UXデザイン・UXリサーチをもう一度ちゃんと理解しよう!
「ユーザーを理解するって言うほどカンタンじゃないよね」 UXデザイン・UXリサーチをもう一度ちゃんと理解しよう!「ユーザーを理解するって言うほどカンタンじゃないよね」 UXデザイン・UXリサーチをもう一度ちゃんと理解しよう!
「ユーザーを理解するって言うほどカンタンじゃないよね」 UXデザイン・UXリサーチをもう一度ちゃんと理解しよう!Yoshiki Hayama
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!mosa siru
 
「ウチの事業部の商品をWebサイト・アプリで目立たせて!」私だけじゃなかった! 社内政治と落としどころの見つけ方
「ウチの事業部の商品をWebサイト・アプリで目立たせて!」私だけじゃなかった! 社内政治と落としどころの見つけ方「ウチの事業部の商品をWebサイト・アプリで目立たせて!」私だけじゃなかった! 社内政治と落としどころの見つけ方
「ウチの事業部の商品をWebサイト・アプリで目立たせて!」私だけじゃなかった! 社内政治と落としどころの見つけ方Yoshiki Hayama
 
“UXデザイン”のキモ『ユーザーインタビュー』の具体的テクニックを詳解!| UXデザイン基礎セミナー 第2回
“UXデザイン”のキモ『ユーザーインタビュー』の具体的テクニックを詳解!| UXデザイン基礎セミナー 第2回“UXデザイン”のキモ『ユーザーインタビュー』の具体的テクニックを詳解!| UXデザイン基礎セミナー 第2回
“UXデザイン”のキモ『ユーザーインタビュー』の具体的テクニックを詳解!| UXデザイン基礎セミナー 第2回Yoshiki Hayama
 
DDDをScrumで廻す あるいは ScrumをDDDで廻す
DDDをScrumで廻す あるいは ScrumをDDDで廻す DDDをScrumで廻す あるいは ScrumをDDDで廻す
DDDをScrumで廻す あるいは ScrumをDDDで廻す Kiro Harada
 
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019Tokoroten Nakayama
 
「UXデザインとは」からはじめる「本流」のUXデザインはじめの一歩 | UXデザイン基礎セミナー 第1回
「UXデザインとは」からはじめる「本流」のUXデザインはじめの一歩 | UXデザイン基礎セミナー 第1回「UXデザインとは」からはじめる「本流」のUXデザインはじめの一歩 | UXデザイン基礎セミナー 第1回
「UXデザインとは」からはじめる「本流」のUXデザインはじめの一歩 | UXデザイン基礎セミナー 第1回Yoshiki Hayama
 
「顧客の声を聞かない」とはどういうことか
「顧客の声を聞かない」とはどういうことか「顧客の声を聞かない」とはどういうことか
「顧客の声を聞かない」とはどういうことかYoshiki Hayama
 
プロトタイピングとユーザビリティテストで「UXデザイン」を練りあげよう! | UXデザイン基礎セミナー 第4回
プロトタイピングとユーザビリティテストで「UXデザイン」を練りあげよう! | UXデザイン基礎セミナー 第4回プロトタイピングとユーザビリティテストで「UXデザイン」を練りあげよう! | UXデザイン基礎セミナー 第4回
プロトタイピングとユーザビリティテストで「UXデザイン」を練りあげよう! | UXデザイン基礎セミナー 第4回Yoshiki Hayama
 
アジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイドアジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイドHiroyuki Ito
 
メタプログラミングって何だろう
メタプログラミングって何だろうメタプログラミングって何だろう
メタプログラミングって何だろうKota Mizushima
 
技術選択とアーキテクトの役割
技術選択とアーキテクトの役割技術選択とアーキテクトの役割
技術選択とアーキテクトの役割Toru Yamaguchi
 
心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話Yusuke Hisatsu
 
良い?悪い?コードコメントの書き方
良い?悪い?コードコメントの書き方良い?悪い?コードコメントの書き方
良い?悪い?コードコメントの書き方Shigenori Sagawa
 
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第3部)
3週連続DDDその2  深いモデルの探求(ドメイン駆動設計 第3部)3週連続DDDその2  深いモデルの探求(ドメイン駆動設計 第3部)
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第3部)増田 亨
 
デキるプログラマだけが知っているコードレビュー7つの秘訣
デキるプログラマだけが知っているコードレビュー7つの秘訣デキるプログラマだけが知っているコードレビュー7つの秘訣
デキるプログラマだけが知っているコードレビュー7つの秘訣Masahiro Nishimi
 

La actualidad más candente (20)

「ユーザーを理解するって言うほどカンタンじゃないよね」 UXデザイン・UXリサーチをもう一度ちゃんと理解しよう!
「ユーザーを理解するって言うほどカンタンじゃないよね」 UXデザイン・UXリサーチをもう一度ちゃんと理解しよう!「ユーザーを理解するって言うほどカンタンじゃないよね」 UXデザイン・UXリサーチをもう一度ちゃんと理解しよう!
「ユーザーを理解するって言うほどカンタンじゃないよね」 UXデザイン・UXリサーチをもう一度ちゃんと理解しよう!
 
⼤企業で実現するイマドキの内製開発
⼤企業で実現するイマドキの内製開発⼤企業で実現するイマドキの内製開発
⼤企業で実現するイマドキの内製開発
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
 
「ウチの事業部の商品をWebサイト・アプリで目立たせて!」私だけじゃなかった! 社内政治と落としどころの見つけ方
「ウチの事業部の商品をWebサイト・アプリで目立たせて!」私だけじゃなかった! 社内政治と落としどころの見つけ方「ウチの事業部の商品をWebサイト・アプリで目立たせて!」私だけじゃなかった! 社内政治と落としどころの見つけ方
「ウチの事業部の商品をWebサイト・アプリで目立たせて!」私だけじゃなかった! 社内政治と落としどころの見つけ方
 
“UXデザイン”のキモ『ユーザーインタビュー』の具体的テクニックを詳解!| UXデザイン基礎セミナー 第2回
“UXデザイン”のキモ『ユーザーインタビュー』の具体的テクニックを詳解!| UXデザイン基礎セミナー 第2回“UXデザイン”のキモ『ユーザーインタビュー』の具体的テクニックを詳解!| UXデザイン基礎セミナー 第2回
“UXデザイン”のキモ『ユーザーインタビュー』の具体的テクニックを詳解!| UXデザイン基礎セミナー 第2回
 
WayOfNoTrouble.pptx
WayOfNoTrouble.pptxWayOfNoTrouble.pptx
WayOfNoTrouble.pptx
 
DDDをScrumで廻す あるいは ScrumをDDDで廻す
DDDをScrumで廻す あるいは ScrumをDDDで廻す DDDをScrumで廻す あるいは ScrumをDDDで廻す
DDDをScrumで廻す あるいは ScrumをDDDで廻す
 
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
 
「UXデザインとは」からはじめる「本流」のUXデザインはじめの一歩 | UXデザイン基礎セミナー 第1回
「UXデザインとは」からはじめる「本流」のUXデザインはじめの一歩 | UXデザイン基礎セミナー 第1回「UXデザインとは」からはじめる「本流」のUXデザインはじめの一歩 | UXデザイン基礎セミナー 第1回
「UXデザインとは」からはじめる「本流」のUXデザインはじめの一歩 | UXデザイン基礎セミナー 第1回
 
Slideshare Japanese
Slideshare JapaneseSlideshare Japanese
Slideshare Japanese
 
「顧客の声を聞かない」とはどういうことか
「顧客の声を聞かない」とはどういうことか「顧客の声を聞かない」とはどういうことか
「顧客の声を聞かない」とはどういうことか
 
プロトタイピングとユーザビリティテストで「UXデザイン」を練りあげよう! | UXデザイン基礎セミナー 第4回
プロトタイピングとユーザビリティテストで「UXデザイン」を練りあげよう! | UXデザイン基礎セミナー 第4回プロトタイピングとユーザビリティテストで「UXデザイン」を練りあげよう! | UXデザイン基礎セミナー 第4回
プロトタイピングとユーザビリティテストで「UXデザイン」を練りあげよう! | UXデザイン基礎セミナー 第4回
 
アジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイドアジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイド
 
メタプログラミングって何だろう
メタプログラミングって何だろうメタプログラミングって何だろう
メタプログラミングって何だろう
 
技術選択とアーキテクトの役割
技術選択とアーキテクトの役割技術選択とアーキテクトの役割
技術選択とアーキテクトの役割
 
心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話
 
良い?悪い?コードコメントの書き方
良い?悪い?コードコメントの書き方良い?悪い?コードコメントの書き方
良い?悪い?コードコメントの書き方
 
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第3部)
3週連続DDDその2  深いモデルの探求(ドメイン駆動設計 第3部)3週連続DDDその2  深いモデルの探求(ドメイン駆動設計 第3部)
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第3部)
 
Oss貢献超入門
Oss貢献超入門Oss貢献超入門
Oss貢献超入門
 
デキるプログラマだけが知っているコードレビュー7つの秘訣
デキるプログラマだけが知っているコードレビュー7つの秘訣デキるプログラマだけが知っているコードレビュー7つの秘訣
デキるプログラマだけが知っているコードレビュー7つの秘訣
 

Más de Hiroki Kondo

Coderetreat in KIT 導入資料
Coderetreat in KIT 導入資料Coderetreat in KIT 導入資料
Coderetreat in KIT 導入資料Hiroki Kondo
 
Coderetreat in KIT 資料/
Coderetreat in KIT 資料/Coderetreat in KIT 資料/
Coderetreat in KIT 資料/Hiroki Kondo
 
Coderetreat in KITスポンサー資料
Coderetreat in KITスポンサー資料Coderetreat in KITスポンサー資料
Coderetreat in KITスポンサー資料Hiroki Kondo
 
Eclipseデバッガを活用するための31のtips
Eclipseデバッガを活用するための31のtipsEclipseデバッガを活用するための31のtips
Eclipseデバッガを活用するための31のtipsHiroki Kondo
 
分散環境でのTrac
分散環境でのTrac分散環境でのTrac
分散環境でのTracHiroki Kondo
 
分散環境でのTrac
分散環境でのTrac分散環境でのTrac
分散環境でのTracHiroki Kondo
 
10分で出来る!?プラグインライブコーディング
10分で出来る!?プラグインライブコーディング10分で出来る!?プラグインライブコーディング
10分で出来る!?プラグインライブコーディングHiroki Kondo
 
JRubyでカードアプリを作ろう
JRubyでカードアプリを作ろうJRubyでカードアプリを作ろう
JRubyでカードアプリを作ろうHiroki Kondo
 
モジュール指向勉強会-コードリーディングを始める前に-
モジュール指向勉強会-コードリーディングを始める前に-モジュール指向勉強会-コードリーディングを始める前に-
モジュール指向勉強会-コードリーディングを始める前に-Hiroki Kondo
 
Javaにおけるモジュラリティ元年
Javaにおけるモジュラリティ元年Javaにおけるモジュラリティ元年
Javaにおけるモジュラリティ元年Hiroki Kondo
 
成長できるエンタープライズシステムを目指して-OSGiによるモジュール型アーキテクチャの実現-
成長できるエンタープライズシステムを目指して-OSGiによるモジュール型アーキテクチャの実現-成長できるエンタープライズシステムを目指して-OSGiによるモジュール型アーキテクチャの実現-
成長できるエンタープライズシステムを目指して-OSGiによるモジュール型アーキテクチャの実現-Hiroki Kondo
 
業務システムで使うSpring Dynamic Modules
業務システムで使うSpring Dynamic Modules業務システムで使うSpring Dynamic Modules
業務システムで使うSpring Dynamic ModulesHiroki Kondo
 
どこでもTrac Wiki
どこでもTrac WikiどこでもTrac Wiki
どこでもTrac WikiHiroki Kondo
 
どこでも Trac Wiki (Moba S Conflicted Copy 2009 07 14)
どこでも Trac Wiki (Moba S Conflicted Copy 2009 07 14)どこでも Trac Wiki (Moba S Conflicted Copy 2009 07 14)
どこでも Trac Wiki (Moba S Conflicted Copy 2009 07 14)Hiroki Kondo
 
HELP ME! 説明書
HELP ME! 説明書HELP ME! 説明書
HELP ME! 説明書Hiroki Kondo
 
Rodから聞いたことを全部話すぜ
Rodから聞いたことを全部話すぜRodから聞いたことを全部話すぜ
Rodから聞いたことを全部話すぜHiroki Kondo
 
斜め上行くリッチクライアントの考え方(仮)
斜め上行くリッチクライアントの考え方(仮)斜め上行くリッチクライアントの考え方(仮)
斜め上行くリッチクライアントの考え方(仮)Hiroki Kondo
 
斜め上行くリッチクライアントの考え方(仮)
斜め上行くリッチクライアントの考え方(仮)斜め上行くリッチクライアントの考え方(仮)
斜め上行くリッチクライアントの考え方(仮)Hiroki Kondo
 

Más de Hiroki Kondo (20)

Coderetreat in KIT 導入資料
Coderetreat in KIT 導入資料Coderetreat in KIT 導入資料
Coderetreat in KIT 導入資料
 
Coderetreat in KIT 資料/
Coderetreat in KIT 資料/Coderetreat in KIT 資料/
Coderetreat in KIT 資料/
 
Coderetreat in KITスポンサー資料
Coderetreat in KITスポンサー資料Coderetreat in KITスポンサー資料
Coderetreat in KITスポンサー資料
 
Eclipseデバッガを活用するための31のtips
Eclipseデバッガを活用するための31のtipsEclipseデバッガを活用するための31のtips
Eclipseデバッガを活用するための31のtips
 
分散環境でのTrac
分散環境でのTrac分散環境でのTrac
分散環境でのTrac
 
分散環境でのTrac
分散環境でのTrac分散環境でのTrac
分散環境でのTrac
 
10分で出来る!?プラグインライブコーディング
10分で出来る!?プラグインライブコーディング10分で出来る!?プラグインライブコーディング
10分で出来る!?プラグインライブコーディング
 
JRubyでカードアプリを作ろう
JRubyでカードアプリを作ろうJRubyでカードアプリを作ろう
JRubyでカードアプリを作ろう
 
モジュール指向勉強会-コードリーディングを始める前に-
モジュール指向勉強会-コードリーディングを始める前に-モジュール指向勉強会-コードリーディングを始める前に-
モジュール指向勉強会-コードリーディングを始める前に-
 
Javaにおけるモジュラリティ元年
Javaにおけるモジュラリティ元年Javaにおけるモジュラリティ元年
Javaにおけるモジュラリティ元年
 
成長できるエンタープライズシステムを目指して-OSGiによるモジュール型アーキテクチャの実現-
成長できるエンタープライズシステムを目指して-OSGiによるモジュール型アーキテクチャの実現-成長できるエンタープライズシステムを目指して-OSGiによるモジュール型アーキテクチャの実現-
成長できるエンタープライズシステムを目指して-OSGiによるモジュール型アーキテクチャの実現-
 
なぜ今OSGiか
なぜ今OSGiかなぜ今OSGiか
なぜ今OSGiか
 
業務システムで使うSpring Dynamic Modules
業務システムで使うSpring Dynamic Modules業務システムで使うSpring Dynamic Modules
業務システムで使うSpring Dynamic Modules
 
どこでもTrac Wiki
どこでもTrac WikiどこでもTrac Wiki
どこでもTrac Wiki
 
どこでも Trac Wiki (Moba S Conflicted Copy 2009 07 14)
どこでも Trac Wiki (Moba S Conflicted Copy 2009 07 14)どこでも Trac Wiki (Moba S Conflicted Copy 2009 07 14)
どこでも Trac Wiki (Moba S Conflicted Copy 2009 07 14)
 
HELP ME! 説明書
HELP ME! 説明書HELP ME! 説明書
HELP ME! 説明書
 
Help Me!
Help Me!Help Me!
Help Me!
 
Rodから聞いたことを全部話すぜ
Rodから聞いたことを全部話すぜRodから聞いたことを全部話すぜ
Rodから聞いたことを全部話すぜ
 
斜め上行くリッチクライアントの考え方(仮)
斜め上行くリッチクライアントの考え方(仮)斜め上行くリッチクライアントの考え方(仮)
斜め上行くリッチクライアントの考え方(仮)
 
斜め上行くリッチクライアントの考え方(仮)
斜め上行くリッチクライアントの考え方(仮)斜め上行くリッチクライアントの考え方(仮)
斜め上行くリッチクライアントの考え方(仮)
 

Último

2024 01 Virtual_Counselor
2024 01 Virtual_Counselor 2024 01 Virtual_Counselor
2024 01 Virtual_Counselor arts yokohama
 
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦Sadao Tokuyama
 
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfTaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfMatsushita Laboratory
 
20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdfAyachika Kitazaki
 
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見Shumpei Kishi
 
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-LoopへTetsuya Nihonmatsu
 
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法ssuser370dd7
 
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)ssuser539845
 
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~arts yokohama
 

Último (12)

What is the world where you can make your own semiconductors?
What is the world where you can make your own semiconductors?What is the world where you can make your own semiconductors?
What is the world where you can make your own semiconductors?
 
2024 03 CTEA
2024 03 CTEA2024 03 CTEA
2024 03 CTEA
 
2024 01 Virtual_Counselor
2024 01 Virtual_Counselor 2024 01 Virtual_Counselor
2024 01 Virtual_Counselor
 
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
 
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfTaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
 
20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf
 
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
 
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
 
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
 
2024 04 minnanoito
2024 04 minnanoito2024 04 minnanoito
2024 04 minnanoito
 
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
 
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
 

Kanban Vs Scrum日本語版

  • 1. カンバン vs スクラム 実践ガイド Future of Agile, Stockholm May 27, 2009 Henrik Kniberg - Crisp AB Agile coach & Java guy Cofounder / CTO of Goyada (mobile services) 30 developers 09/9/2 Lead architect at Ace Interactive (gaming) 20 developers Henrik Kniberg Chief of development at Tain (gaming) 40 developers Agile coach at various companies henrik.kniberg@crisp.se +46 70 4925284 1
  • 3. 組織を分ける スクラムを一言で表すと 製品を分ける 大きなグループでは大きなモノの構築に長い時間を費やす。 小さなチームは小さいモノの構築に短い時間を費やす。 …でも全体を眺めるために定期的に統合します。 プロセスを最適化 ビジネスの価値を最適化 $$$ 時間を分割 1月 4月 $ Not checked out Done! :o) SP INT G A : B R O L eta-ready rel ease! checked out Burndown Write Deposit failing test 2d DAO Code Inte gr cle anup DB test 2d 0.5d desig n 1d 2d 1d GUI Write Migration sp ec 2d fa iling 2d te st 1d 3d tool Tapes t ry sp ike Impl. 1d 2d migration 8d Backoffice Write failin g test Login I mpl GUI 2d Unpl anned items Next In tegr. 1d with JBoss 2d Write Fix memo leak ry Sal es sup port Withdraw P test erf Backoffice fail ing test WriteIRA (J failin g 2d te st 125) Withdraw 3d 3d Write User adm whitepap er in 4d GUI Clarify desig n req uire- Impl (CSS) ments GUI 1d 2d 6d Henrik Kniberg 33 3
  • 4. カンバンを一言で表すと… To do Dev Test Release Done! 5 3 2 3 仕事の流れを見える化 H F D C A I G E 作業中(WIP:work in J B K progress)を制限 測定、そして流れの最適化 FLOW Henrik Kniberg 44 4
  • 5. カンバンのルーツ(トヨタ) 看板 買い手 納入業者 消費 取り外し 受取 出荷 割当 製造 必要な時に必要なだけ生産という考え方(Just- in-time)と、自律と人間味のある自動化(自働化) がトヨタ生産方式の二つの柱です。 これらの仕組みを運営するためツールがカンバ ンです。 トヨタ生産方式の父 大野耐一氏 Henrik Kniberg 55 5
  • 7. カンバンとスクラム、 どちらもプロセスの(仕事を流す)ためのツール 物理的なツール プロセスのツール 別名 ”組織のパターン” プロダクトオーナー ペアプロ 食事しながら ミーティング Henrik Kniberg 77 7
  • 8. 前もって決められているか vs 適応か 前もって決められている方向 より適応する方向 RUP XP スクラム カンバン なんでもする (120+ (13) (9) (3) (0) • • • Architecture Reviewer Business Designer Business-Model Reviewer ) • • • Business use case realization Business use-case model Business vision • • Whole team Coding standard • • Scrum Master Product Owner • • Visualize the workflow Limit WIP • Business-Process Analyst • Change request • TDD • Team • Measure and optimize lead time • Capsule Designer • Configuration audit findings • Collective ownership • Sprint planning meeting • Change Control Manager • Configuration management plan • Customer tests • Daily Scrum • Code Reviewer • Data model • Pair programming • Sprint review • Configuration Manager • Deployment model • Refactoring • Product backlogt • Course Developer • Deployment plan • Planning game • Sprint backlog • Database Designer • Design guidelines • Continuous integration • BUrndown chart • Deployment Manager • Design model • Simple design • Design Reviewer • Development case • Sustainable pace • Designer • Development-organization • Metaphor • Graphic Artist assessment • Small releases • Implementer • End-user support mateirla • Integrator • Glossary • Process Engineer • Implementation model • Project Manager • Installation artifacts • Project Reviewer • Integration build plan • Requirements Reviewer • Issues list • Requirements Specifier • Iteration assessment • Software Architect • Iteration plan • Stakeholder • Manual styleguide • System Administrator • Programming guidelines • System Analyst • Quality assurance plan • Technical Writer • Reference architecture • Test Analyst • Release notes • • • Test Designer Test Manager Tester • • Requirements attributes Requirements management plan 武器や流派にこだわるな。 • • • Tool Specialist User-Interface Designer Architectural analysis • • • Review record Risk list Risk management plan (引用:アジャイルソフトウェア開発 • • Assess Viability of architectural proof-of-concept Capsule design • • Software architecture document Software development 著アリスター・コーバーン) • Class design plan • Construct architectural proof-of- • Software requirements specification • • concept Database design Describe distribution • • • Stakeholder requests Status assessment Supplementary business specification 宮本武蔵 • • Describe the run-time architecture Design test packages and classes • • Supplementary specification Target organization assessment 1584-1645 • Develop design guidelines • Test automation architecture • Develop programming guidelines • Test cases • Identify design elements • Test environment configuration • Identify design mechanisms • Test evaluation summary • Incorporate design elements • Test guidelines • Prioritize use cases • Test ideas list • Review the architecture • Test interface specification • Review the design • Test plan • Structure the implementation model • Test suite • Subsystem design • Tool guidelines • Use-case analysis • Training materials • Use-case design • Use case model • Analysis model • Use case package • Architectural proof-of-concept • Use-case modeling guidelines • Bill of materials • Use-case realization • Business architecture document • Use-case storyboard • Business case • User-interface guidelines • Business glossary • User-interface prototype • Business modeling guidelines • Vision Henrik Kniberg 88 8 • Business object model • Work order • Business rules • Workload analysis model • Business use case
  • 9. スクラムの定義する役割 P SM O Henrik Kniberg 99 9
  • 10. スクラムが定義するイテレーション スクラムチーム week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8 カンバンチーム 1 スプリント 1 スプリント 2 計画 と合意 デモ ふりかえり (リリース?) カンバンチーム 2 week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8 ふりかえり (4w) 計画 周期 (2w) リリース周期 (1w) カンバンチーム 3 week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8 ふりかえり (4w) 計画 (必要時) リリース(必要時) Henrik Kniberg 10
  • 11. どちらも作業中(WIP)を制限するが、方法が異 なる スクラムボード カンバンボード To do Ongoing Done :o) To do Ongoing Done :o) 2 A A B B C C D D FLOW FLOW 作業中を時間単位で制限 作業中を状態で制限 (iteration) 作業中:WIP(Work in Progress) Henrik Kniberg 1111 11
  • 12. どちらも経験に基づいている 速度 リードタイム 品質 予測可能性 (aka ベロシティ) (akaサイクルタイム) (障害の割合等) (SLAの達成,等) カンバンは、より再構成しやすい すごい!たくさんの うわぁ、もっと複雑に 多くの小さなチーム 2,3の大きなチーム 選択肢がある! なってしまった! 作業中制限(少) 大きい作業中制限 ワークフローの状態(少) ワークフローの状態(大) イテレーション(短) イテレーション(大) 計画回数(少) 計画回数(大) .... etc ... .... etc ... Henrik Kniberg 1212 12
  • 13. 例: WIP制限による実験 Monday, Week 1 Monday, Week 2 Monday, Week 3 Monday, Week 4 To do Ongoing Done :o) To do Ongoing Done :o) To do Ongoing To do Ongoing Done :o) Done :o) 1 8 8 8 C B A C A D A D A B H B B D E D E E E F I F C L C F F G G G M ZZZZzzzzz H z N I 暇で暇でしょうがな 統合しているサーバ J い。WIP制限を8にし で問題があってDとE K てみよう。 が終わらなかったぞ。 代わりにFとGをやら ないと。 うわぁ。WIP制限に ひっかかった。すぐ に作業を止めて統 WIP制限を4にし Monday, Week 5 合しているサーバを てみよう。そして 直さないと! 次は早めに対処 To do Ongoing Done :o) 4 しよう。 N L J O M K P Henrik Kniberg 1313 13
  • 14. Eが欲しくなったよ! スクラムはイテレーション中変更を許可しませ P ん。 O To Do のスロットが空く のを待ってください。そ 次のスプリントまで待っ れかCかDと交換してく てください ださい。 Scrum Kanban To do Ongoing Done :o) To do Ongoing Done :o) 2 2 C A C A D B D B FLOW FLOW Henrik Kniberg 1414 14
  • 15. スクラムボードはどのイテレーション間でもリ セットします。 Scrum スプリントの最初の日 スプリント中 スプリントの最終日 Kanban いつでも Henrik Kniberg 1515 15
  • 16. スクラムはなんでも屋チームで規定されます。 スクラム カンバン – 例 1 カンバン – 例 2 専門家 専門家 なんでも屋の なんでも屋の チーム なんでも屋の チーム チーム チーム Henrik Kniberg 1616 16
  • 17. スクラムのバックログ要素はスプリントに合わ ければなりません。 スクラム Sprint 1 Sprint 2 Sprint 3 Sprint 4 カンバン 期間を跨ったタスク WIPの制限 = 3 期間を跨ったタスク Henrik Kniberg 1717 17
  • 18. スクラムでは、見積もりやベロシティは規定さ れています。 V= 8 V= 7 V= 9 1 2 2 1 1 2 ベロシティは大体: 8 / sprint 2 3 1 3 1 2 2 1 (継続的なペースですか?) Sprint 1 Sprint 2 Sprint 3 Henrik Kniberg 1818 18
  • 19. どちらも同時に複数の製品に携わることがで きます。 スクラムの例 1 カンバンの例1 製品毎のチーム 色で意味づいたタスク 緑の製品 黄の製品 緑チーム 黄チーム スクラムの例2 スクラムの例 3 カンバンの例2 製品をまたいだ 全ての製品 製品をまたいだ レーンで意味づいたタスク 全ての製品 チーム チーム Henrik Kniberg 1919 19
  • 20. 1. 短期的財務目標を犠牲にしてでも長期的な考えで経営判断する。 2. 淀みのない流れをつくって、問題を表面化させる どちらもリーン 3. プルシステムを利用して、つくり過ぎのムダを防ぐ 4. 生産量を平準化する(ウサギではなく、亀のペースで仕事をする) でアジャイル 5. 問題を解決するためにラインを止め、品質を最初からつくり込むカルチャーを定着 させる。 6. 標準化作業が絶え間ない改善と従業員の自主活動の土台になる。 7. すべての問題を顕在化させるために目で見る管理を使う 8. 技術を使うなら、実績があり、枯れた、人や工程に役立つ技術だけを利用する。 1. プロセスやツールより 9. 仕事をよく理解し、思想を実行し、他人に教えるリーダーを育成する 人と人同士の相互作用を重視する。 10. 会社の考え方に従う卓越したヒトとチームを育成する 2. 包括的なドキュメントより 11. パートナーや部品メーカ等の社外ネットワークを尊重し、改善するのを助ける 動作するソフトウェアを重視する。 12. 現地現物を徹底的に理解するように自分の目で確かめる(現地現物) 3. 契約上の交渉よりも 顧客との協調を重視する 13. 意思決定はじっくりコンセンサスをつくりながら、あらゆる選択肢を十分検討する が、実行は素早く行う(根回し) 4. 計画に従うことよりも 変化に対応することを重視する。 14. 執拗な反省と絶え間ない改善により学習する組織になる リーン 人 ジャス 品質 ライン ト・ コスト 改善 イン・ を タイム リードタイム 止める 無駄を省 く Henrik Kniberg 2020 いつでも使える状態を保つ 20
  • 21. 小さな違い: スクラムにはプロダクトバックログがある スクラム: カンバン: プロダクトバックログは必ず存 プロダクトバックログは必ずしも存 在する。 在しない。 プロダクトバックログの変更は プロダクトバックログは着手可能 次のスプリントに影響する。 であればすぐに変更できる (現在のスプリントではない) あらゆる優先度を順付ける枠組 プロダクトバックログはビジネ みを使える。例えば: ス価値が大きいものから順に どの項目からでも 並べられる いつも一番上の項目から いつも一番古い項目から 20%は保守項目から、 80%は新機能から ... だけど多くのチームではこれらのアプローチを組み 製品Aと製品Bを均等に 合わせてつかってるけどね 緊急の項目を先に Henrik Kniberg 2121 21
  • 22. 小さな違い: スクラムには朝会がある ... だけど多くのカンバンチームもそうしているね。 Henrik Kniberg 2222 22
  • 23. 小さな違い: スクラムにはバーンダウンチャートがある。 Burndown カンバンといえば「これ」といった 70 図はない。チームにとって必要で 60 あればどんなものでも使う。 Estim work 50 ated remaining 40 30 20 10 August 1 2 3 4 5 8 9 10 11 12 15 16 17 18 19 Date Henrik Kniberg 2323 23
  • 24. 例: スクラムボード vs カンバンボード スクラム Product Sprint backlog backlog Committed Ongoing Done :o) E E F A F G B HG I C J H L K D M カンバン Dev Backlog Selected 3 In production :o) 2 Ongoing Done D B A X F R G E C H Q I J L M K Henrik Kniberg 2424 24
  • 25. シナリオ1 –ある仕事の流れ Dev Backlog Selected 3 In production :o) 2 Ongoing Done A B G C F D H I J L E M K Henrik Kniberg 2525 25
  • 26. シナリオ1 –ある仕事の流れ Dev Backlog Selected 3 In production :o) 2 Ongoing Done A G B C F D H I J L E M K Henrik Kniberg 2626 26
  • 27. シナリオ1 –ある仕事の流れ Dev Backlog Selected 3 In production :o) 2 Ongoing Done A G B C F D H I J L E M K Henrik Kniberg 2727 27
  • 28. シナリオ1 –ある仕事の流れ Dev Backlog Selected 3 In production :o) 2 Ongoing Done C A G D B F H I J L E M K Henrik Kniberg 2828 28
  • 29. シナリオ1 –ある仕事の流れ Dev Backlog Selected 3 In production :o) 2 Ongoing Done C A G D B F H I J L E M K Henrik Kniberg 2929 29
  • 30. シナリオ1 –ある仕事の流れ Dev Backlog Selected 3 In production :o) 2 Ongoing Done F D C A G B E H I J L M K Henrik Kniberg 3030 30
  • 31. シナリオ 2 – 問題があったときの展開 Dev Backlog Selected 3 In production :o) 2 Ongoing Done A B G C F D H I J L E M K Henrik Kniberg 3131 31
  • 32. シナリオ 2 – 問題があったときの展開 Dev Backlog Selected 3 In production :o) 2 Ongoing Done A G B C F D H I J L E M K Henrik Kniberg 3232 32
  • 33. シナリオ 2 – 問題があったときの展開 Dev Backlog Selected 3 In production :o) 2 Ongoing Done C A G D B F H I J L E M K Henrik Kniberg 3333 33
  • 34. シナリオ 2 – 問題があったときの展開 Dev Backlog Selected 3 In production :o) 2 Ongoing Done C A G D B F H I J L E M K Henrik Kniberg 3434 34
  • 35. シナリオ 2 – 問題があったときの展開 Dev Backlog Selected 3 In production :o) 2 Ongoing Done C A G D !? B F H I J L E M K Henrik Kniberg 3535 35
  • 36. シナリオ 2 – 問題があったときの展開 Dev Backlog Selected 3 In production :o) 2 Ongoing Done G !? A D B F E C H I J L M K Henrik Kniberg 3636 36
  • 37. シナリオ 2 – 問題があったときの展開 Dev Backlog Selected 3 In production :o) 2 Ongoing Done A G D B F E C H I J L M K Henrik Kniberg 3737 37
  • 38. シナリオ 2 – 問題があったときの展開 Dev Backlog Selected 3 In production :o) 2 Ongoing Done A G D B F E C H I J L M K Henrik Kniberg 3838 38
  • 39. シナリオ 2 – 問題があったときの展開 Dev Backlog Selected 3 In production :o) 2 Ongoing Done D A G B E F C H I J L M K Henrik Kniberg 3939 39
  • 40. カンバン vs スクラム www.crisp.se/henrik.kniberg/kanban-vs-scrum.pdf 概要 にているところ ちがうところ スクラム カンバン どちらもリーンでアジャイルである 時間を区切ったイテレーション(タイム 時間を区切ったイテレーションは必須 どちらもプルスケジュールを基にしている ボックス)が定義されている。 ではない イテレーション内の仕事量を具体的にする コミットメントは必須ではない どちらもWIPの制限がある ため、チームでコミットする。 どちらも透明性に基づいて、改善をよりしや ベロシティを計画づくりとプロセス改善の リードタイムを計画づくりとプロセス改善 すくしている ための標準の測定基準として使う のための標準測定基準として使う どちらもソフトウェアを早く、頻繁にリリース 職制を横断したチームが規定されてい 職制を横断するチームはオプション。専門 可能にすることに注力する。 る 家のチームが許される。 どちらも自己組織的なチームに基づく 1スプリントに完了できる大きさにタス タスクの大きさに特に決まりがない。 クを分割する. どちらも作業を細かく分割することを求める バーンダウンチャートが定義されてい 図の種類について特に決まりがない。 どちらもリリース計画を実証されたデータ(ベ る。 ロシティ/リードタイム)を継続的に最適にしてWIPの制限が間接的 (スプリントごと) WIPの制限が直接的 (ワークフローの状 いる 態ごと) 見積もりをする。 見積もりは必須ではない。 進行中のスプリントにタスクを追加でき 着手可能な時タスクを追加できる。 ない。 スプリントバックログは特定のチーム カンバンボードは複数のチーム、もしく からのみ所有される。 は人々が共有できる。 3つの役割 (PO/SM/Team) 役割は特に規定されない スプリントごとにスクラムボードはリ カンバンボードにリセットするタイミング セット はない 優先順位付けされたプロダクトバックロ 優先順位付けは必須ではない グが規定されている Henrik Kniberg 4040 40
  • 41. 一番大切なこと: ふりかえりと共にはじめよう! より自分たちにあったプロセ スに進化させよう. 最初は間違えてもいいじゃ ない いいことは道具箱に追加し よう。 試そう! Henrik Kniberg 4141 41