読者です 読者をやめる 読者になる 読者になる

てくすた

ピクスタ株式会社のエンジニア・デザイナーがつづるよもやまテクニカルブログです

ピクスタでスクラムを導入してみて一回挫折したけど、再起させた話

スクラム

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

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

目次

  • 導入した経緯
  • 導入失敗
    • なぜ失敗したか
    • 成功に導くために
  • 導入初期
  • 現在の状態
  • まとめ

導入した経緯

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

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

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

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

導入失敗

なぜ失敗したのか

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

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

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

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

成功に導くために

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

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

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

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

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

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

導入初期の状態

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

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

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

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

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

現在の状態

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

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

f:id:texta:20151008174512j:plain

まとめ

スクラム導入において、色々な情報や手法がありますが、結局のところはチームにどのように浸透させるかが肝です。 メンバーの中には悲観主義や懐疑主義の方が必ずいると思いますが、導入する人やスクラムマスターが明確に目的・行動指針・成功像を強く思い、伝えることが何よりも大切です。

また、スクラムマスターはチームを第一に考えることが重要だと、導入を経て感じたことです。

参考にした書籍

スクラム導入時に読んだ書籍を紹介します。

saitou.hatenablog.com saitou.hatenablog.com saitou.hatenablog.com saitou.hatenablog.com

みなさんのスクラム導入に少しでも寄与できたら幸いです。

ピクスタでは、サーバントリーダーとして活躍できるエンジニアも募集しています!!

連絡先

  • メールアドレス (ブログ担当):info@pixta.co.jp
  • 採用ページ (エンジニア): https://pixta.co.jp/recruit/wanted#webeng
  • 〒150-0002 東京都渋谷区渋谷3-11-11 IVYイーストビル9F(受付3F)

*1:想像は容易ですね

*2:http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-JA.pdf

*3:スクラムガイドより引用

*4:サーバントリーダーってやつですね

*5:スクラムスレーブにならないように