アジャイルに向かう組織に聴いてほしいアジャイルへの第一歩

Scrum Fest Sapporo 2020

Transcript

1. アジャイルに向かう組織に聴いてほしい
   アジャイルへの第一歩
   NECネクサソリューションズ
   今井 貴明
   Scrum Fest Sapporo 2020
   

   View Slide

2. 本日の内容
   • アジャイルが浸透していない社内でアジャイル（スクラム）やろうと
   してうまくいかなかったのでふりかえりをしました。
   • その結果見えてきた“最初にやったらよさそうなこと”をお話しします。
   2
   @t_k_redman
   

   View Slide

3. こんなものを作りました
   • 始めてスクラムをやってみて大ゴケした後の振り返りから誕生。
   • 前例がほぼ無い組織では何から始めたらよかったのか。
   ↑こんなかんじの目次
   3
   @t_k_redman
   

   View Slide

4. こんな人には役立つかも
   • WF開発メインの組織にアジャイルを取り入れたい。
   • アジャイルをやりたいけど何から始めていいかわからない。
   • アジャイルを実践しているけどうまく進まない。効果を実感できない。
   4
   @t_k_redman
   

   View Slide

5. TK
   自己紹介
   TK（Imai Takaaki/@t_k_redman）
   • https://takaremo.com
   • NECネクサソリューションズ所属
   • 千葉県在住 / 27歳
   • アジャイルの推進やスクラムマスターなど
   • AWSやらAngularを嗜む程度
   • 先日、第2子爆誕
   5
   @t_k_redman
   

   View Slide

6. 始めてのスクラムでやったこと
   ★お題は社内部門の業務アプリケーション刷新
   ① スクラムの勉強会を開催
   • スクラムガイドを読み合わせながら進め方やルールを確認。
   • 使用するプラクティスの説明。
   ② プロジェクトのルールや体制を決定
   • スプリント期間、ツール、アーキテクチャなどを決める。
   • ステークホルダを含めて役割を確認。
   ③ 開発スタート
   そのときの失敗談：https://www.slideshare.net/ssuser21f6db/ss-238917492
   6
   @t_k_redman
   

   View Slide

7. 起こったこと①
   • それぞれの「アジャイルってこういうもんでしょ」
   7
   @t_k_redman
   そうは言っても
   スケジュールは
   引かないと
   全部終わらな
   いと困るよ！
   繰り返しながら
   作るんでしょ？
   スケジュール引
   いても変わっ
   ちゃうんで…
   優先順位を決め
   ながらですね…
   いやまあそうなん
   ですけど…
   

   View Slide

8. 起こったこと②
   • 依頼部門は発注側、私たちは受注側
   8
   @t_k_redman
   開発はあなたたちの役目でしょ！バリア
   発注側
   なんとか要望をくみ取らなきゃ！スクラム
   受注側
   

   View Slide

9. ウォーターフォール VS アジャイル
   

   View Slide

10. ウォーターフォール VS アジャイル
    

    View Slide

11. 軸足をどこに置くかという話
    • 二項対立ダメ、絶対。
    「あなたたちのWFはもう古いよ！」ではない。
    「これからは全部アジャイルに一新しないと！」でもない。
    「アジャイルならそんなのだめでしょ！」とも限らない。
    • 一方で、ウォーターフォールに軸足がおかれているという事実
    「開発＝WF」みたいなバイアスがかかっている。
    WF開発を基準としてアジャイルに派生していこうという感覚。
    11
    @t_k_redman
    

    View Slide

12. アジャイルを深く理解しようとする前に
    認知できている部分から紐解く
    

    View Slide

13. ①アジャイルを知る
    

    View Slide

14. アジャイルは「状態」
    • アジャイルは開発手法を表すものではない。
    開
    発
    方
    法
    論
    WF開発 XP スクラム アジャイル
    具体的な方法論を表す
    言葉ではない。
    アジャイルに向いている
    「スクラム＝アジャイル」
    と誤解されることが多い。
    14
    @t_k_redman
    

    View Slide

15. 起源を知る
    http://agilemanifesto.org/iso/ja/manifesto.html
    15
    @t_k_redman
    

    View Slide

16. 原則を知る
    http://agilemanifesto.org/iso/ja/principles.html 16
    @t_k_redman
    

    View Slide

17. スタートラインに立つ
    • 多分説明してもまだよくわからないだろうけど、まずはこういうもの
    があることは知ってもらう。
    • フレームワークとかではないよ！ということで、後の話が食い違いそ
    うな誤解を払拭しておきたい。
    17
    @t_k_redman
    

    View Slide

18. 誤解を解く
    • アジャイルにどんなイメージをもっている？
    18
    @t_k_redman
    品質気にせずに
    爆速でガンガン作って
    高生産性を叩き出す手法
    SILVER BULLET
    

    View Slide

19. 誤解を解く
    • アジャイルにどんなイメージをもっている？
    19
    @t_k_redman
    品質気にせずに
    爆速でガンガン作って
    高生産性を叩き出す手法
    SILVER BULLET
    Outcomeの効率はいいかもね。
    全部一気にはできないけど
    小出しなら速いよ。
    フィードバックから改善する前提
    なのは良いけどバグは潰してね。
    

    View Slide

20. どうやら思っていたものとは違いそうだ
    • 「想像してたものと違う」ことは分かってもらえた。
    • 次は開発というものに対する思い込みを解いていきたい。
    • 比較的ギャップが大きそうな部分にフォーカスしてみる。
    20
    @t_k_redman
    

    View Slide

21. 長期的な計画が立てにくい
    • 検証を繰り返し流動的に進めるので、長期計画が立てにくい。
    21
    @t_k_redman
    計画 Sprint1 Sprint2 Sprint3 Sprint4
    要件
    A
    要件
    B
    要件
    C
    要件
    D
    計画 Sprint1 Sprint2 Sprint3 Sprint4
    要件
    A
    要件
    B
    要件
    C
    要件
    D
    Done
    追加
    優先順位変更
    取消
    当初の計画：
    １週間後：
    

    View Slide

22. 計画と目的と進捗の指標
    • なぜ計画を立ててそれを基準に進捗をトレースするのか。
    計画を守ることが目的になっていないか。
    当初の計画通りだとなぜ順調だと言えるのか。（逆も然り。）
    目的を考えたときに何を指標にすると良さそうか。
    22
    @t_k_redman
    

    View Slide

23. 目的を誰と共有するか
    • プロジェクトの目的を改めて確認したとき、どの範囲で共有すべきか。
    23
    @t_k_redman
    プロダ
    クト
    目的
    計画
    実現
    顧客
    開発者
    要件
    価値？
    プロダ
    クト
    目的
    目的
    顧客 開発者開発者
    

    View Slide

24. ②適用判断をする
    

    View Slide

25. 万事いける気がしてしまう
    • 「得体の知れない弾丸」から「チョット分かった弾丸」に昇格。
    • 万能感を感じるかもしれないので、向き不向きや必要なことを確認し
    ていく。
    25
    @t_k_redman
    

    View Slide

26. 顧客との共創体制をつくれそうか
    • 顧客と同じ方向を向ける状態じゃないと厳しい。
    • 契約云々もあるけど、最低限歩み寄れそうかはポイントになる。
    26
    @t_k_redman
    プロダ
    クト
    目的
    顧客 開発者
    契
    約
    目的
    プロダ
    クト
    顧客
    開発者
    開発者
    

    View Slide

27. 向き不向きを考える
    • 「要件定義は終わってます」みたいなタイミングから納期までの開発
    をアジャイルで、とかは意味ない。
    • なんでアジャイルなのかは考えたほうがいい。
    27
    @t_k_redman
    

    View Slide

28. なんでアジャイルなのかを考えてみる
    • 選択肢の一つであることは認識してもらう。
    レッツトライの精神は歓迎！
    • ワークショップなんかで考える機会を設けるなど。
    Why agile?(https://www.agilejapan.org/2018/session/d1_Why-Agile.pdf)
    28
    @t_k_redman
    

    View Slide

29. ③体制を整える
    

    View Slide

30. 周囲のアジャイル理解に対応する
    • WF開発とのギャップが大きく、開発チームやプロジェクト外の人に
    理解されにくかったりする。
    • 単純に「こういうものです」という説明はするとして、必要に応じて
    抵抗を和らげる策を講じる。
    30
    @t_k_redman
    管理体制
    大丈夫なの？
    状況を資料に
    まとめて！
    もっと細かく
    進捗報告を
    プロジェクトルームに招き、朝会の様子
    やかんばんボードを見てもらう。
    メトリクスを可視化しておく。
    スプリント内のイベントに参加してもらう。
    

    View Slide

31. 目的の認識を合わせる
    • 明文化されていたとしても、個々の受け取り方に微妙に違いがあった
    りする。
    • 開発チームだけでなく、必要に応じてステークホルダも含めて目的、
    ゴール、ビジョンの共通認識を持てるようにする。
    31
    @t_k_redman
    https://agilewarrior.wordpress.com/2010/11/06/the-agile-inception-deck/
    

    View Slide

32. インセプションデッキ
    • もちろん全部できたほうがいいけど、1と2を回答できるとよい。
    • 開発中に何度か実施して見失わないようにするのもよい。
    • フランクにアイスブレイクっぽくやってみても面白い。
    32
    @t_k_redman
    https://github.com/agile-samurai-ja/support/tree/master/blank-inception-deck
    1. われわれはなぜここにいるか
    2. エレベーターピッチを作る
    3. パッケージデザインを作る
    4. やらないことリストをつくる
    5. 「ご近所さん」を探せ
    6. 解決案を描く
    7. 夜も眠れなくなるような問題はなんだろう？
    8. 期間を見極める
    9. 何をあきらめるかをはっきりさせる
    10. 何がどれだけ必要なのか
    

    View Slide

33. ロールの違い
    • これまで属人化していた役割が、必ずしも特定の人に割り振られるわ
    けではない。
    • 既存のロールに無理やり別のロールをはめ込むようなことが無いよう
    に注意する。
    33
    @t_k_redman
    

    View Slide

34. ④ルールを決める
    

    View Slide

35. チームのルールを決める
    • スプリントの期間、ツールやプラクティスの活用、などなど。
    • プラクティスをトライ＆エラーで試していくのもいいけど、トライの
    成功率を高める努力はできる。
    ⇒なぜそれが必要なのか、狙いは何か。
    • いろんなプラクティスを知ってみる。
    35
    @t_k_redman
    有名どころ
    • 朝会（デイリースクラム）
    • かんばん
    • プロダクトバックログ
    • スプリントバックログ
    • KPT
    • インセプションデッキ
    • スプリント（イテレーション）
    • ユーザストーリー
    • ストーリーポイント
    • etc.
    参考：アジャイル型開発におけるプラクティス活用 リファレンスガイド
    https://www.ipa.go.jp/sec/reports/20130319.html
    

    View Slide

36. ルールは改善していく
    • 「狙い」をもって決めたルールはふりかえりで活きてくる。
    • 一度決めたものに固執しなくていい。契機を待たなくたって、今有効
    な改善は今やったっていい。
    • プラクティスだってアレンジしていいし、自分たちで生み出したって
    いい。
    36
    @t_k_redman
    

    View Slide

37. まとめ
    

    View Slide

38. 得体の知れないものを独自解釈しないようにする
    • いきなりいろいろ決めるよりかは、頭をゆっくり切り替えたい。
    ⇒軸足の置き場所を確認する
    • 特に、「よくわからないもの」を「チョットワカル」ようにしておき
    たい。
    38
    @t_k_redman
    

    View Slide

39. 社内向けスライドの着地点
    • マインドセットしっかり！という結論でまとめてある。
    39
    @t_k_redman
    このあたり。
    「アジャイルへの第一歩はこれだ！」
    みたいな文脈になってる。
    

    View Slide

40. アカンぜ。
    40
    @t_k_redman
    いきなり
    「マインドセット変えましょう！」
    はアカンぜ。
    ※許可もらった。
    

    View Slide

41. 1年経って再考してみた「第一歩目」
    • アジャイルのマインドセット≒アジャイルを理解する
    ⇒マインドセットというものでもなく、思い込みを無くすに尽きる。
    • 「思ってるよりもこれまでとギャップがあるよ」をどう伝えられるか。
    • 「意識」とか「思想」とか崇高なものでもない。
    変化した後の姿を
    イメージしてもらえるかどうかの問題！！
    イメージできた上で、それを採用するかどうかはその人次第。次のステップ。
    41
    @t_k_redman
    

    View Slide

42. ご清聴ありがとうございました。
    

    View Slide