R&D プロジェクトでスクラムでのアジャイル開発を 1年間やってみて感じた良かった事・難しかった事

NTT Tech Conference 2022
R&D プロジェクトでスクラムでのアジャイル開発を 1 年間やってみて良かった点と悪かった点
Track1 15:15〜

https://ntt-developers.github.io/ntt-tech-conference/2022/

Transcript

1. © NTT Communications Corporation All Rights Reserved. R&D プロジェクトでスクラムでのアジャイル開発を 1年間 やってみて感じた良かった事・難しかった事 2022.03.23 NTTコミュニケーションズ株式会社 イノベーションセンター 岩田 紘成 1
2. © NTT Communications Corporation All Rights Reserved. 自己紹介 岩田 紘成（@shirobrak） • 2018年入社（4年目） • NTT レゾナント株式会社（~ 2021.03） • メディアサービスの開発業務 • オンラインワークスペースサービスの開発業務 • NTT コミュニケーションズ株式会社（2021.04 ~） • ネットワーク技術の検証業務 • ベンチャー開発支援業務 2
3. © NTT Communications Corporation All Rights Reserved. 今日話したいこと R&D プロジェクトで スクラムマスターとして 1年間 スクラム でのアジャイル開発に携わってきたので、 • なぜ スクラム を導入しようと思ったか • どのように スクラム を回しているか • やってみて良かった事 • やってみて難しかった事と現在どう向き合っているか といったこの1年の取り組みで得たノウハウを共有します 3
4. © NTT Communications Corporation All Rights Reserved. プロジェクトの概要と スクラム導入のきっかけ 4
5. © NTT Communications Corporation All Rights Reserved. プロジェクトの概要 プロジェクト名 • Arcadia • 「エンジニアの楽園を作ろう」という思想から • 各々がやりたいことをやるプロジェクトにする 検証目的（プロダクトゴール） • マルチベンダかつマルチ AS からなる SR-MPLS 網を利用した VPN サービス 実現のための技術検証と VPN サービスの提供 • 上記の網を運用するシステムの考案・開発 5 成果紹介 MPLS JAPAN 2021 マルチASかつマルチベンダにおけるSR-MPLS TEの実現（田島 照久） https://mpls.jp/2021/presentations/20211101_MPLSJAPAN_NTTCOM_tajima_pub.pdf
6. © NTT Communications Corporation All Rights Reserved. メンバー構成（5人チーム） • プロダクトオーナー：1人（開発チーム 兼任） • スクラムマスター：1人、私（開発チーム 兼任） • 開発チーム：5人 進め方 • 機器設置など物理作業を行う以外は 基本的にはリモートワーク メンバー構成と進め方 6
7. © NTT Communications Corporation All Rights Reserved. なぜ スクラム をはじめたか？ きっかけ • プロジェクトが本格始動するに際し、 どう進めていくかを決める必要があった • R&D でのスクラム開発のノウハウが自チームで 少なかったのでやってみようということに スクラムへの期待 • スクラムのフレームワークに則り進めることで、 • 様々な背景を持つチームメンバの持つ得意をうまく展開して、 チームとして成長したい • 定期的にアウトプットする機会を仕組みを作りたい 7
8. © NTT Communications Corporation All Rights Reserved. どうスクラムを回しているか？ 8
9. © NTT Communications Corporation All Rights Reserved. スクラムのサイクル スプリントの期間 • 原則 1週間（水曜〜火曜） イベント • プランニング • 朝会 / 終わりの会 • リファインメント • スプリントレビュー • 振り返り イベントの進め方 • 各イベントのファシリテーターは スプリントの初めにランダムに決める 9
10. © NTT Communications Corporation All Rights Reserved. プランニング イベントの概要 • スプリントゴール設定と ゴール達成のための計画を立てる （スプリントバックログを作成する） • 時間：Max 1時間30分で実施 ゴールを設定したら右画像のように 1日以内で実施できる粒度のサブタスクに分割し、 1スプリントで全て終えられるような計画を立てる 10 👇 スプリントバックログ例（一部） スプリントゴール 「L2VPN での CE接続ができる事を確かめる」
11. © NTT Communications Corporation All Rights Reserved. プランニング 進める上での工夫 プロジェクト掛け持ちのメンバが多いので使える時間を予め確認して、 タスクの見積もり時間の合計が、 全員で使える時間を超えないように注意して計画する 11 全員でスプリントで使える時間＞タスクの合計見積もり時間
12. © NTT Communications Corporation All Rights Reserved. 朝会 / 終わりの会 イベントの概要 • スプリントのゴールを達成するために、 各々がやったこと・やることを共有する • 時間：Max 20分で実施 進める上での工夫 • フレックス勤務や別プロジェクト対応等、 稼働時間がバラバラな時も多いため、 情報共有の場の意味も含めて 「終わりの会」 も実施している 12 👆 朝会 共有順 Slack Bot 朝は眠かったりで進め方忘れがちなので、 Slack Bot に教えてもらうようにした
13. © NTT Communications Corporation All Rights Reserved. リファインメント イベントの概要 • 次回以降のスプリントで実施するであろうタスクの認識を合わせて、 全員がだれでもそのタスクを実施できる状態にしておく • タスクの完了の定義など • 時間：Max 1時間 で実施 進める上での工夫 • 当初はこのイベントを実施せずにプランニングの最初に 軽く認識合わせだけして、スプリント実施していたが、 認識あってない事が多々あったので実施するようにした 13
14. © NTT Communications Corporation All Rights Reserved. スプリントレビュー イベントの概要 • スプリントでの成果物をデモして フィードバックをもらう • 時間：Max 1時間 で実施 進める上での工夫 • 参加者全員エンジニアなので、 動く所だけじゃなくどういう設計したか とか含め説明するようにした方が盛り上がる のでそうしてます 14 👆 スプリントレビューでの デモ の様子
15. © NTT Communications Corporation All Rights Reserved. 振り返り イベントの概要 • スプリントを振り返って、 より良い開発を行って行くために チームとしてどうしたら良いか？ について話し合う • 時間：Max 1時間 で実施 進める上での工夫 • KPT や YWT をベースに実施 15 👆 振り返りボード
16. © NTT Communications Corporation All Rights Reserved. その他の取り組み スプリント内の時間のログを残す • 使える時間内でプランニングしたにも関わらず、 タスクが全て完了しないことが多発した際に導入 • タスクに実際どれくらいかかったか？やどういう所に詰まったか？ などログをとるようにした 16
17. © NTT Communications Corporation All Rights Reserved. その他の取り組み スプリント内の時間のログを残す 💡 メリット • どのタスクはこれくらい時間がかかったが見える化されて、 次スプリントのプランニング時に、以前のログを確認することで、 見積もり精度が向上した • 入力がエンジニアの負担になるかなと危惧していたが、 1分程度で入力できるので習慣化した（自動化できたら嬉しい） 💡 デメリット • 管理シートがリッチになってきて、 スプリントバックログと2重管理っぽくなってくる 17
18. © NTT Communications Corporation All Rights Reserved. その他の取り組み スプリントに名前をつける 以前見学に行った社内のチームで実践していて 面白いなと思い真似てみた 💡 メリット • なんか楽しい気がする • スプリントレビューとかの話のネタになる • 数字のナンバリングより スプリントの区切れが意識しやすくなる 18 👆 直近のスプリント名一覧 好きな人なら何の名前か分かるかも
19. © NTT Communications Corporation All Rights Reserved. その他の取り組み オンラインワークスペースの活用 • 初めて行うタスクなど難しそうなタスクは チームメンバーで集まってモブプロ的に進めるようにしている • 稼働時間がバラバラなので、 作業する時はなるべく分かるように入って作業している 19 👆 Discord を活用したモブ作業の様子
20. © NTT Communications Corporation All Rights Reserved. 取り組んでみて、良かったこと 20
21. © NTT Communications Corporation All Rights Reserved. チーム内でのスキル展開の仕組みとして使えた • プランニングやリファインメントといったイベントを活用し、 全員の認識を合わせる機会を多く作ることで、 他の人の知識や考えに触れ それぞれの得意な事をうまく展開できる仕組みができた • 初めて実施するタスクやトラシュータスクなど、 難しいタスクはモブプロ的に、チーム全体で解決していく事で、 得意な人の作業の仕方や考え方などに触れる事ができ、 各々のスキルアップにも繋がった 21
22. © NTT Communications Corporation All Rights Reserved. 定期的なアウトプットの機会を作れる • スプリントレビューを活用する事で、 アウトプットする場を仕組み的に作る事ができ、 新入社員やチームメンバ全員にアウトプットする場を作れる • 自分のやったことの振り返りの観点でも、 スプリントレビューでのデモやそのフィードバックを通して 理解を深めることができるなと感じた 22
23. © NTT Communications Corporation All Rights Reserved. 難しかった事と、解決への取り組み 23
24. © NTT Communications Corporation All Rights Reserved. スクラムチーム外に依存する問題が発生しやすい（1） 発生した問題 • 最新の機器・OSを利用した検証を行うため、 問題が発生した際に情報が少なく解決に時間がかかったり、 最終的にメーカーへ問い合わせる事が頻繁にあり、計画通りに行かない • トラシュー中 / 問い合わせ中のタスクが 何スプリントにも跨ってしまう • 実際は何もやってないタスクなのに、 そのスプリントのスプリントバックログには のってしまうため、計測も狂う 24 👇 4スプリントくらい居座った Multi-AS L2VPN の検証業務
25. © NTT Communications Corporation All Rights Reserved. スクラムチーム外に依存する問題が発生しやすい（1） どう対応しているか？ - 時間の使い方の工夫 - 時間を必要ならかけるしかないので せめて深追いしすぎないような仕組みを整えた • それまでトラシュー中のタスクは終わるまでひたすら粘っていたが、 見積もり時間を超えた時点で、 「どこ（or いつ）まで試してダメだったら問い合わせる」 というような認識合わせを行って時間を無駄に消費しないようにした 25
26. © NTT Communications Corporation All Rights Reserved. スクラムチーム外に依存する問題が発生しやすい（1） どう対応しているか？ - タスクの扱い方の工夫 - タスクからチームでコントロールできない状態を排除した • 問い合わせる時点で、 • 「問い合わせる」 • 「回答後の対応」 を別タスクとして切り出して 検証タスクとしては DONE にする => 本当に着手するタスクだけを スプリントで扱えるようになった 26 👇 現在のプロダクトバックログ Multi-AS L2VPN まだいる...
27. © NTT Communications Corporation All Rights Reserved. スクラムチーム外に依存する問題が発生しやすい（2） 発生した問題 • 検証に利用する機材やソフトウェア の納期の影響でブロックされるタスクが発生する • 発注して手元に届くまで最低でも数ヶ月はかかる 27
28. © NTT Communications Corporation All Rights Reserved. スクラムチーム外に依存する問題が発生しやすい（2） どう対応しているか？ • ブロッキングされやすい「検証タスク」と 自分たちでコントロールしやすい「開発タスク」 を混ぜたプロダクトバックログを作成する これにより現時点では 「このスプリント何もできることない...」 という状態にはなってない 28 ネットワーク技術の検証タスク ネットワーク技術の検証タスク ネットワーク運用システム開発タスク （ソフトウェア開発） 👇 プロダクトバックログ 優先順位 高 優先順位 低
29. © NTT Communications Corporation All Rights Reserved. 不確実性をどこまで減らしてから着手すべきか？ 検証タスクは何をもって「誰でも着手可能」とみなすかが難しい • 誰でも着手できるレベルまで落とし込むなら 実際に設定する config を確認してから着手したい • これなら属人性が少なく確実だが、検証するのと同じくらい時間がかかる • 今は検証に使う技術の概要と何を検証したいか？ の認識があったら着手可能にしている • 設定する config はスプリントが始まってから調べるので、 ドキュメントが見つからないなど、検証が長引くリスクがある 29
30. © NTT Communications Corporation All Rights Reserved. まとめ 30
31. © NTT Communications Corporation All Rights Reserved. まとめ R&D プロジェクトでスクラムを導入してみて... • 良かった点 • チームメンバ間のスキル共有が進んだ • 定期的に成果をアウトプットしフィードバックを得られる仕組みが得られた • 難しかった点 • 本 R&D プロジェクトだとチーム外に依存する問題が発生しやすい • チームで扱える事だけを計画に組み込めるように工夫する必要がある • 検証タスクはどこまで不確実性を排除してから望むべきか？ • → 今後の課題 31 Special Thanks: 本スクラムの取り組みは、Arcadia チームメンバ （市原 英也、竹中 幹、田島 照久、三島 航、宮地 瑠香）によって行いました。