はじめに
初めまして、たまに実家に帰っては犬を吸っているganmoと申します。 新規プロダクト開発チームでリーダーをやっています。 私のチームでは長期の企画フェーズを経て、昨年12月に大規模な組織変更を実施し、新しい開発体制が本格始動しました。まずはPoC（Proof of Concept）フェーズとして、技術的な実現可能性の検証や、ワイヤーフレームをベースにしたプロトタイプアプリケーションの開発に着手しました。
組織変更前からスクラムを採用していましたが、新体制ではスクラムの運用がうまく機能せず、個人的にモヤモヤを抱えていました。
- 「スクラムがうまくいかない」
- 「形骸化している」
そんな悩みを私たちと同じように抱えているチームは少なくないと思います。
そこで今回は、あえてスクラムから一度離れ、ゲーミフィケーションの要素を取り入れた独自の開発スタイルを試してみた経験をお話しします。
当時の課題感
プロセスの課題
- 形だけのスクラムイベント
- 個人作業が中心で協働が少ない
- アウトプットのスピード感が不足
コミュニケーションの課題
- 外国籍メンバーとの言語の壁
- チーム間の情報共有が不十分
これらの課題に対して、チームで何か新しいアプローチを試してみる必要性を感じていました。
そんな中、定期的に開催している「Viewing Party」（チームでの技術動画視聴会）で、あるプロトタイピングの動画を見たことがきっかけとなりました。その動画から受けた刺激が、チーム全体の「もっと積極的にPoCを進めていこう」という機運につながりました。
ギルドスタイルの導入
というわけで、ゲーミフィケーション的な要素をヒントにギルドスタイルというオレオレ開発スタイルを提案してやってみました。 概要は下記のようなイメージです。
コンセプト：ハンターズギルド
狩猟の世界観をモチーフにした開発スタイルを導入
- ギルド（開発チーム）
- ギルドマスター（プロダクトオーナー的役割、村人（ペルソナ）の困りごとをクエスト化して掲示板に掲げておく。ganmoが担当）
- クエストボード（タスクボード）
- クエスト（タスク）
- パーティ（日々のワーキンググループ）
具体的な仕組み
クエストシステム
- クエストボード（Miroボード）での視覚的なタスク管理
- スター制度（難易度を★の数で示す）
- 毎日異なるメンバーで2つのパーティに分ける制度
- クエスト達成時に「クエストの付箋に剣を刺す」という演出
- これはめちゃくちゃスベりました
クエストボードのイメージ
パーティ編成のイメージ
Miroの図を使ってパーティ編成を毎日確認。LancerやArcherはパーティの名前です。それっぽい世界観で命名しました。
日々のルーチン
- ギルド集会（1時間/日）
- クエストリザルトの発表（動くプロダクトのデモ）
- ショートレトロスペクティブ
- ギルドマスターから今日のゴール（重要クエスト）の発表
狙っていた効果
ゲーミフィケーションの理論をかじって下記のような効果を期待していました。
- 毎日重要なクエストを各チームに1つ与えることで期待できる効果
- その日の目標の明確化
- モブワークの促進
- クエストの★の数によって、達成した成果の評価を可視化
- チームを毎日変えるルールにすることで期待できる効果
- 1日という時間制限を意識させる
- 1日で完了または引き継ぎ可能な状態になるようにタスクサイズを調整する
- 多様なメンバー間の交流促進
実際に得られた効果
コミュニケーションの改善
- モブワークによる活発な対話
- 英語での積極的なコミュニケーション
プロセスの改善
- WIP（Work In Progress: 仕掛かり中のタスク）の削減
- デモを通じて毎日視覚的に成果を共有
- ナレッジ共有の促進
特に言語の壁は日本人メンバーにとって、心理的な障壁になっていたのですが、今回のチャレンジによって思ったより英語で頑張れるという自信がついたように見えました。
直面した課題と改善プロセス
とはいえ、ゲーミフィケーションを取り入れることはいいことばかりではなく、実際には様々な課題にぶつかりました。以下に主な課題と改善策を紹介します。
課題1: 毎日チームを変えるのはさすがに厳しい
課題：
毎日チーム編成を変更することで、引き継ぎコストが増大。特に技術調査や環境構築が必要なクエストで効率が悪い点が目立ちました。
改善：
- チーム数の固定を廃止し、より柔軟なチーム編成を組めるように変更
- クエストの性質に応じて柔軟にチーム編成を変更
- 小規模クエストは個人作業、大規模クエストはモブワークなど、状況に応じた編成を採用
課題2: 短期成果へのプレッシャー
課題：
日次での成果創出が求められ、特に技術検証フェーズでメンバーの心理的負担が増大。改善の余地を考える時間も不足していました。
改善：
- ゴール設定を1日単位から1週間単位に変更
- チーム編成の件と合わせて、チームの自律的な計画立案を促進
課題3: タスク定義の曖昧さ
課題：
消化スピードが上がった結果、要件が不明確なクエストが増加し、チームに混乱が生じました。
改善：
- クエストの完了条件を明文化して必ず記載
- クエスト内容の全体共有時間を設定
課題4: コンセプトが某ゲーム過ぎる
課題：
某ゲームをモチーフにした概念が強すぎ、ゲームを知らないメンバーにとって理解の障壁となっていました。
改善：
- ゲーム的表現を標準的なスクラム用語に置き換え
- ギルド → チーム
- クエスト → タスク
- クエストタイム → スプリント
気づいたらスクラムに
気がついたら、私たちの開発スタイルは自然とスクラムの形に近づいていました：
- 1週間の期間設定 = スプリント？
- 期間開始時のゴール設定 = スプリントゴール？
- 日々の役割分担と進捗確認 = デイリースクラム？
- クエストの詳細化 = バックログリファインメント？
- クエストリザルトの発表 = スプリントレビュー？
- 次期間への改善点の議論 = スプリントレトロスペクティブ？
まとめ
私たちは、ゲーミフィケーションという「遠回り」を経て、以下のような気づきを得ました：
- チーム文化の重要性
- ゲーミフィケーション的な要素がチームに新しい刺激を与えた
- 形式よりもチームの自主性を重視することで改善が進んだ
- スクラムの本質
- 結果的に行き着いた先がスクラムだった
- オレオレ開発スタイルの課題の多くは、スクラムの中で既に解決策が用意されていた
スクラムの形に囚われて困っている方は、いったん全部忘れて自分たちなりのやり方を試してみることをお勧めします。 その過程で、スクラムの本質的な価値を再発見できるかもしれません。
以上です！！
