PBLでスクラムやる気まんまんだった僕が結局スクラムをやらなかった理由

PBLでスクラムやる気まんまんだった 僕が結局スクラムをやらなかった理由 Agile PBL祭り 2024@東京

目次 1. 発表者のバックグラウンド 2. PBL開始から半年までのあらすじ 3. やったこと・やらなくて正解だったこと 4. 結果生まれたもの 5. まとめ

発表者のバックグラウンド

発表者の PBL遍歴 ● 学部1年 ○ 高度ICT演習, ETロボコン ● 学部2年 ○ 高度ICT演習, ETロボコン ● 学部3年 ○ 高度ICT演習, ETロボコン, プロジェクト学習 高度ICT演習とETロボコンを並行して3年間続けている ⇒ この経験が発表者のチーム開発観の基礎になっている (特に1年次)

それぞれの PBLで学んだこと 高度ICT演習 → アジャイル開発のプラクティス, 特にスクラム ETロボコン → チーム開発のアンチパターン 両方 → 失敗する チーム開発の例

高度ICT演習 前半の活動 ⇒ スクラムの勉強会 と 開発プロダクトの企画 1コマ目 → スクラムの勉強会 2コマ目 → 開発プロダクトの企画 といった形で毎週の活動を行っていた 結果、「スクラムってなんかいい感じなんだな」という 曖昧な認識ではあったものの、これはこれでよかった

高度ICT演習 後半の活動 ⇒ ガッツリ 開発 1日のスケジュールを決めて、スプリントを回した (3時間/週)が、 うまくいかなかった 原因は色々ある ● ペアプログラミングのやり方が間違っていた ● 1回/週 なので、「あれ、何やってたんだっけ」が発生 ● そもそも 3時間/週 だと当然の如く足りない

ETロボコン ロボコンという名前がつきながらも、ロボットは全チーム同じ仕様で ソフトウェアのみを競う という珍しいロボコン 実際の競技だけではなく、UMLという形式で記載した設計書も提出する義務 がある 高校生時代から参加しており、大学でも継続

ETロボコン 1年目の失敗 「大学生だし自分で自律的に動いてくれるでしょ」と思い込んで、 メンバーを集めるだけ集めておいて放置してしまった あるチームでは仲違いが起こり、 メンバーの1人がストレスに起因する一時的に片耳難聴になってしまった 結果は勿論奮わず

これらの失敗を経験した後 ... 「チーム開発」を知るため SCRUM BOOT CAMP THE BOOKを読了した チームが結果を出すためにはチームの主体的な態度ももちろんだが、 リーダー (SM)がチームに、チーム自身の生産性や開発対象に対する 興味を持ってもらうよう工夫する ことが重要と認識した

PBL開始から半年までのあらすじ

おおまかなスケジュール (学内成果発表会ポスターより)

プロジェクト最初期 先生やOBが、2回ほどアイスブレイクを実施 その後、全体での飲み会もあり、ほぼ打ち解けた とりあえず1年間を通してやるであろうことをリストアップ 初期の進め方は先生に言われるがまま、 週の活動は持ち回り制(= ファシリテーター制)となった

プロジェクト前半の問題点 : 当事者意識の皆無 持ち回り制にした結果、 ● 誰も「いつまでに」「何を」「どれくらい(のクオリティで)」 必要かわかっていなかった ● 全員が「とりあえず今週を乗り切ろう」というマインド 結果、学内の中間発表の際に大混乱が生じた

後から確認したら 3年前の先輩も同じ問題を 抱えてた

学内の中間発表後に ふりかえり KPTによるふりかえりを実施 ふりかえり対象は 「これまでのチームについて」 ここでやっと初めてチームで自らを ふりかえった チームビルディングが活き、 気兼ねなく自分たちの問題点を 共有できた

やったこと・やらなくて正解だったこと

やったこと 1: インセプションデッキの 作成 プロダクトの方向性を確認するためにイ ンセプションデッキを作成 この通りにはいかなかったが、 「皆でプロダクトについて話す」 ということは非常に重要だった (これがメンテできてれば完璧だった)

やったこと 2: 時間外になるべく開発しない 単なるサボりではなく、必要なことだった 互いに見えるところでしか作業しなかったので、 互いに何をしているのか把握できた

やったこと 3: POっぽい振舞い 発表者 = プロダクトの発案者 自分の中でこのプロダクトの価値や最終形のビジョンを固めて、 常にメンバーに話したり、レビューの指針にした

プロダクトオーナーは、スクラムチームから ⾒み出されるプロダクトの価値を 最⾒化することの結果に責任を持つ 。組織・スクラムチーム・個⾒によって、 その⾒法はさまざまである。 プロダクトオーナーは、効果的なプロダクトバックログ管理にも責任を持つ。た とえば、 ● プロダクトゴールを策定し、明 ⾒的に伝える。 ● プロダクトバックログアイテムを作成し、明確に伝える。 ● プロダクトバックログアイテムを並び替える。 ● プロダクトバックログに透明性があり、⾒える化され、理解されるようにす る。 (スクラムガイド2020より引用)

やらなくて正解だったこと : スクラム 理由としては主に次の通り ● 我々の熱意に対してオーバーヘッドが大きかった ● 「メンバー全員、同じ時間に必ず」というのが確約できなかった ● 全員が初めて触る技術なので、見積りがほぼ不可能 ● (そういったものに頼らなくてもモノを作れる自信があった) 直感的に、このチームには何かのルールを与えるよりも 信頼して待つことが重要なのではないかと考えた

まとめ

まとめ ● 今までのPBL経験は失敗ばかりだったが、失敗なりに様々な経験を得ら れた ● PBL開始から半年で蓄積していた問題が中間発表で爆発。 その結果、自分たちを見つめ直す良い機会となった ● アジャイル開発のプラクティスは取り入れつつ、自分たちの 特徴を捉えて「やること」「やらないこと」を分別できた