はじめまして、ピクスタ開発部の星 id:watasihasitujidesu です。
idがwatasihasitujidesuですけど、執事ではありません。エンジニアです。

今日は、タイトルの通り、スクラムを開発チームに導入した話をします。

導入した経緯

これまでのピクスタの開発部では、アジャイル開発でもなく、ウォーターフォールでもなく、各エンジニアにほとんどの権限を委譲したカウボーイコーディングスタイルでした。

要件定義・設計・実装・テスト・運用が個人に委ねられる事が多く、組織が大きくなるにつれて以下のような問題が発生してきました。*1

進む属人化
- トラックナンバー１(!)
  - ○○さんしか知らない仕様
  - ○○さんしか知らない実装
誰も知らない仕様
守られないスケジュール

これら開発部の抱える問題を少しでも解消すべく、アジャイル開発手法であるスクラムを導入しました。

導入失敗

なぜ失敗したのか

スクラムガイド*2をサクっと読んだ後に、えいやで導入してみましたが、1ヶ月もしないうちに開発チームのモチベーションが低くなり、失敗に終わりました。

スクラムは軽量であり理解は容易ですが、習得は困難です。*3

まさにスクラムガイドに記載されている言葉通りで、心に沁みました。導入失敗した理由は下記の通りです。

スクラムの概要すらメンバーが理解していない
スクラム導入者の経験、知識が浅すぎた
- この場合はどうですか？という問いに対して
  - わかりません／＾o＾＼
ツール(JIRA)を銀の弾丸だと思ってしまった。
- ツールの学習コストが高すぎる。
開発チーム全員を1チームにしてしまった。
現状、行うべきタスク(プロダクトバックログ)が600件(!)も存在した
- 全てプランニングすることは不可能
- 全て付箋に書くことなんてエンジニアのすることじゃない！！！
  - 開発チームのモチベーション低下

成功に導くために

導入は失敗に終わりましたが、めげません。

スクラムは経験主義を基本としていますので、失敗を経験した直後に、振り返り(レトロスペクティブ)を行い、再始動に向けて問題点を洗い出し、対策を考えました。

現状、開発部が抱える問題を明確にして共有
スクラムの概要、役割、各イベントの説明
- それを踏まえて、開発部の問題をどのように解決していくかを明確にして共有
導入者自身(スクラムマスター == 星)の知識向上(ベストプラクティス & よくある質問を記憶)
ツールを廃止。まずは全て手作りで行う。
- 付箋作成はスクラムマスターが全て担う。
開発チームを2つに分けてそれぞれ別のスクラムチームにする。
行うべきタスク整理し、作業可能と思える件数まで取捨選択。

また、上記の対策の他に、スクラムマスターの行動の優先度を

チーム >>>>> 越えられない壁 >>>>> 自分*4

とする気概を持って取り組まなければ、導入は難しいと感じました。

導入初期の状態

スクラムは軽量であり理解は容易ですが、習得は困難です。

この言葉の通り、まだまだチームにスクラムが浸透していない状態でした。チームに少しでもスクラムの理解を深めてもらうために、辛抱強く、繰り返し説明をしなければならないのですが、それが強要になってしまわないか*5など、深く考えながら行動する必要がありました。

色々な本や、サイト、SlideShareなどで数多の手法参考にしましたが、結局たどり着いたのは

開発チームと会社の風土に適した開発フローを考えて考えて考えぬくこと
メンバーが気持ち良く開発できるやり方と環境を整えること

この2点を大切にしながら、スクラムの各イベントや手法をカスタムしていく方法を採用しました。

現在の状態

現在、再導入から３ヶ月経ちました。 PIXTAにマッチしたスタイルにカスタマイズしたことで、メンバーのモチベーション維持に成功。順調にメンバー全体にスクラムを浸透させていくことができました。だけでなく、今や新メンバーに対して、プランニングの方法や意味を教えられるほどに成長しました。当初の導入失敗時を思うと、感慨深いです。

また、プランニング時の規模の見積もりは、プランニングポーカーにより算出していますが、過去に対応したことのあるチケットを考慮してサクサク進めているので、経験値の恩恵を受けていると感じます。

f:id:texta:20151008174512j:plain