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

Scrum Fest Sapporo 2020

Transcript

1. アジャイルに向かう組織に聴いてほしい アジャイルへの第一歩 NECネクサソリューションズ 今井 貴明 Scrum Fest Sapporo 2020
2. 本日の内容 • アジャイルが浸透していない社内でアジャイル（スクラム）やろうと してうまくいかなかったのでふりかえりをしました。 • その結果見えてきた“最初にやったらよさそうなこと”をお話しします。 2 @t_k_redman
3. こんなものを作りました • 始めてスクラムをやってみて大ゴケした後の振り返りから誕生。 • 前例がほぼ無い組織では何から始めたらよかったのか。 ↑こんなかんじの目次 3 @t_k_redman
4. こんな人には役立つかも • WF開発メインの組織にアジャイルを取り入れたい。 • アジャイルをやりたいけど何から始めていいかわからない。 • アジャイルを実践しているけどうまく進まない。効果を実感できない。 4 @t_k_redman
5. TK 自己紹介 TK（Imai Takaaki/@t_k_redman） • https://takaremo.com • NECネクサソリューションズ所属 • 千葉県在住 / 27歳 • アジャイルの推進やスクラムマスターなど • AWSやらAngularを嗜む程度 • 先日、第2子爆誕 5 @t_k_redman
6. 始めてのスクラムでやったこと ★お題は社内部門の業務アプリケーション刷新 ① スクラムの勉強会を開催 • スクラムガイドを読み合わせながら進め方やルールを確認。 • 使用するプラクティスの説明。 ② プロジェクトのルールや体制を決定 • スプリント期間、ツール、アーキテクチャなどを決める。 • ステークホルダを含めて役割を確認。 ③ 開発スタート そのときの失敗談：https://www.slideshare.net/ssuser21f6db/ss-238917492 6 @t_k_redman
7. 起こったこと① • それぞれの「アジャイルってこういうもんでしょ」 7 @t_k_redman そうは言っても スケジュールは 引かないと 全部終わらな いと困るよ！ 繰り返しながら 作るんでしょ？ スケジュール引 いても変わっ ちゃうんで… 優先順位を決め ながらですね… いやまあそうなん ですけど…
8. 起こったこと② • 依頼部門は発注側、私たちは受注側 8 @t_k_redman 開発はあなたたちの役目でしょ！バリア 発注側 なんとか要望をくみ取らなきゃ！スクラム 受注側
9. ウォーターフォール VS アジャイル
10. ウォーターフォール VS アジャイル
11. 軸足をどこに置くかという話 • 二項対立ダメ、絶対。 「あなたたちのWFはもう古いよ！」ではない。 「これからは全部アジャイルに一新しないと！」でもない。 「アジャイルならそんなのだめでしょ！」とも限らない。 • 一方で、ウォーターフォールに軸足がおかれているという事実 「開発＝WF」みたいなバイアスがかかっている。 WF開発を基準としてアジャイルに派生していこうという感覚。 11 @t_k_redman
12. アジャイルを深く理解しようとする前に 認知できている部分から紐解く
13. ①アジャイルを知る
14. アジャイルは「状態」 • アジャイルは開発手法を表すものではない。 開 発 方 法 論 WF開発 XP スクラム アジャイル 具体的な方法論を表す 言葉ではない。 アジャイルに向いている 「スクラム＝アジャイル」 と誤解されることが多い。 14 @t_k_redman
15. 起源を知る http://agilemanifesto.org/iso/ja/manifesto.html 15 @t_k_redman
16. 原則を知る http://agilemanifesto.org/iso/ja/principles.html 16 @t_k_redman
17. スタートラインに立つ • 多分説明してもまだよくわからないだろうけど、まずはこういうもの があることは知ってもらう。 • フレームワークとかではないよ！ということで、後の話が食い違いそ うな誤解を払拭しておきたい。 17 @t_k_redman
18. 誤解を解く • アジャイルにどんなイメージをもっている？ 18 @t_k_redman 品質気にせずに 爆速でガンガン作って 高生産性を叩き出す手法 SILVER BULLET
19. 誤解を解く • アジャイルにどんなイメージをもっている？ 19 @t_k_redman 品質気にせずに 爆速でガンガン作って 高生産性を叩き出す手法 SILVER BULLET Outcomeの効率はいいかもね。 全部一気にはできないけど 小出しなら速いよ。 フィードバックから改善する前提 なのは良いけどバグは潰してね。
20. どうやら思っていたものとは違いそうだ • 「想像してたものと違う」ことは分かってもらえた。 • 次は開発というものに対する思い込みを解いていきたい。 • 比較的ギャップが大きそうな部分にフォーカスしてみる。 20 @t_k_redman
21. 長期的な計画が立てにくい • 検証を繰り返し流動的に進めるので、長期計画が立てにくい。 21 @t_k_redman 計画 Sprint1 Sprint2 Sprint3 Sprint4 要件 A 要件 B 要件 C 要件 D 計画 Sprint1 Sprint2 Sprint3 Sprint4 要件 A 要件 B 要件 C 要件 D Done 追加 優先順位変更 取消 当初の計画： １週間後：
22. 計画と目的と進捗の指標 • なぜ計画を立ててそれを基準に進捗をトレースするのか。 計画を守ることが目的になっていないか。 当初の計画通りだとなぜ順調だと言えるのか。（逆も然り。） 目的を考えたときに何を指標にすると良さそうか。 22 @t_k_redman
23. 目的を誰と共有するか • プロジェクトの目的を改めて確認したとき、どの範囲で共有すべきか。 23 @t_k_redman プロダ クト 目的 計画 実現 顧客 開発者 要件 価値？ プロダ クト 目的 目的 顧客 開発者開発者
24. ②適用判断をする
25. 万事いける気がしてしまう • 「得体の知れない弾丸」から「チョット分かった弾丸」に昇格。 • 万能感を感じるかもしれないので、向き不向きや必要なことを確認し ていく。 25 @t_k_redman
26. 顧客との共創体制をつくれそうか • 顧客と同じ方向を向ける状態じゃないと厳しい。 • 契約云々もあるけど、最低限歩み寄れそうかはポイントになる。 26 @t_k_redman プロダ クト 目的 顧客 開発者 契 約 目的 プロダ クト 顧客 開発者 開発者
27. 向き不向きを考える • 「要件定義は終わってます」みたいなタイミングから納期までの開発 をアジャイルで、とかは意味ない。 • なんでアジャイルなのかは考えたほうがいい。 27 @t_k_redman
28. なんでアジャイルなのかを考えてみる • 選択肢の一つであることは認識してもらう。 レッツトライの精神は歓迎！ • ワークショップなんかで考える機会を設けるなど。 Why agile?(https://www.agilejapan.org/2018/session/d1_Why-Agile.pdf) 28 @t_k_redman
29. ③体制を整える
30. 周囲のアジャイル理解に対応する • WF開発とのギャップが大きく、開発チームやプロジェクト外の人に 理解されにくかったりする。 • 単純に「こういうものです」という説明はするとして、必要に応じて 抵抗を和らげる策を講じる。 30 @t_k_redman 管理体制 大丈夫なの？ 状況を資料に まとめて！ もっと細かく 進捗報告を プロジェクトルームに招き、朝会の様子 やかんばんボードを見てもらう。 メトリクスを可視化しておく。 スプリント内のイベントに参加してもらう。
31. 目的の認識を合わせる • 明文化されていたとしても、個々の受け取り方に微妙に違いがあった りする。 • 開発チームだけでなく、必要に応じてステークホルダも含めて目的、 ゴール、ビジョンの共通認識を持てるようにする。 31 @t_k_redman https://agilewarrior.wordpress.com/2010/11/06/the-agile-inception-deck/
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. 何がどれだけ必要なのか
33. ロールの違い • これまで属人化していた役割が、必ずしも特定の人に割り振られるわ けではない。 • 既存のロールに無理やり別のロールをはめ込むようなことが無いよう に注意する。 33 @t_k_redman
34. ④ルールを決める
35. チームのルールを決める • スプリントの期間、ツールやプラクティスの活用、などなど。 • プラクティスをトライ＆エラーで試していくのもいいけど、トライの 成功率を高める努力はできる。 ⇒なぜそれが必要なのか、狙いは何か。 • いろんなプラクティスを知ってみる。 35 @t_k_redman 有名どころ • 朝会（デイリースクラム） • かんばん • プロダクトバックログ • スプリントバックログ • KPT • インセプションデッキ • スプリント（イテレーション） • ユーザストーリー • ストーリーポイント • etc. 参考：アジャイル型開発におけるプラクティス活用 リファレンスガイド https://www.ipa.go.jp/sec/reports/20130319.html
36. ルールは改善していく • 「狙い」をもって決めたルールはふりかえりで活きてくる。 • 一度決めたものに固執しなくていい。契機を待たなくたって、今有効 な改善は今やったっていい。 • プラクティスだってアレンジしていいし、自分たちで生み出したって いい。 36 @t_k_redman
37. まとめ
38. 得体の知れないものを独自解釈しないようにする • いきなりいろいろ決めるよりかは、頭をゆっくり切り替えたい。 ⇒軸足の置き場所を確認する • 特に、「よくわからないもの」を「チョットワカル」ようにしておき たい。 38 @t_k_redman
39. 社内向けスライドの着地点 • マインドセットしっかり！という結論でまとめてある。 39 @t_k_redman このあたり。 「アジャイルへの第一歩はこれだ！」 みたいな文脈になってる。
40. アカンぜ。 40 @t_k_redman いきなり 「マインドセット変えましょう！」 はアカンぜ。 ※許可もらった。
41. 1年経って再考してみた「第一歩目」 • アジャイルのマインドセット≒アジャイルを理解する ⇒マインドセットというものでもなく、思い込みを無くすに尽きる。 • 「思ってるよりもこれまでとギャップがあるよ」をどう伝えられるか。 • 「意識」とか「思想」とか崇高なものでもない。 変化した後の姿を イメージしてもらえるかどうかの問題！！ イメージできた上で、それを採用するかどうかはその人次第。次のステップ。 41 @t_k_redman
42. ご清聴ありがとうございました。