社内開発にスクラムを導入した話
この記事はcommewアドベントカレンダー25日目の記事です。
自己紹介
SEとして新卒入社後、以下プロジェクト経験を経て、去年の6月にベンチャー企業に転職し、ECプラットフォームSaaS開発（Ruby, Ruby on Rails）を主に行っています。10月からEMとして開発メンバーのマネジメントや採用などもやってます。
1. 自動車の組み込み開発（C言語）
2. 自社開発でゲーム開発するSES会社に転職後、銀行の業務システム開発（C言語）
3. Android TVの組み込み開発（C++）
4. Androidアプリの開発（Java）
5. 別のSES会社に転職後、容器管理システムの開発（PHP）
6. スタートアップ企業に転職後、EC自動出荷システムSaaS開発(PHP, Symfony)
7. 転職の合間の副業で、ホテルのチェックインシステム開発(PHP, Laravel)
もう少し詳細が知りたい方は、今の会社に転職する際に書いた以下の記事が参考になりますのでよかったらこちらも合わせて見ていただけると。。。
社内開発にスクラム導入した話
スクラム導入前の開発の課題
スプリント期間がリリース単位
うちは、月1ペースでリリースをかけているのですが、スプリント期間も自然とそのリリースに合わせて組まれるため、1ヶ月という長期間での開発となってしまいます。そのため、スプリントのゴールがリリースになってしまっている。
バックログやスプリントが機能していない
要件が固まっていない段階でスプリントに紐づいてしまっているため、実質機能していない。
チームの生産性が把握できていない
リソースが常に不足しており、見積もりも正確にできておらず、タスクも過多という悪循環でスプリントが回り続けてしまっている。メンバーの残業時間も多い。生産性が可視化できていないため、計画通りにタスクをこなすことが困難な状態が続いてしまっている。
開発とQAの距離が遠い
うちは、開発とQAで部署が別れており、役割を分けて動いているからかどうしてもお互いの距離が遠く感じてしまう。一緒に仕事しているのにその人と仕事以外のコミュニケーションがなかったりなど・・・
スクラム導入へ・・・
前述している課題は、全部スクラムを導入するとこで解決するのでは？と思い、リーダー陣を集めてスクラム導入について提案して、まずは自分が抱えている大型の開発プロジェクトで試験的に導入してみることに。。。
8月からスクラムを導入して、約1ヶ月回してみて、色々、課題感を見つけて解決するという繰り返しをしていくにつれてメンバー個々の意識も変わってきたので、経営陣含む上位陣に提案してみた。同じような課題感を上位陣も感じていたので、自分のスクラム導入の提案はすんなり通り、全社的に導入の方向に。。。
もちろん引き続き各チームへのスクラム導入の牽引は引き続き自分の方で責任持って進めていったが、ここからはトントン拍子にことが進み、12月現在では、スクラムベースで開発が進むのが当たり前になってきた。
導入に至るまでに、ネガティブな意見もちらほらあったが、どうするかをその場その場で考え、全責任を持ち、意思決定をしてここまで持って来れたので大変だったが、やりがいはあった。
以前、イベントのLTで登壇する機会があったのでその際もスクラム導入について触れたので以下埋め込みとして残しておきます。。。
今後について
導入したことによるポジティブな意見が多い中、まだ課題もたくさんあるため、その課題を開発のメンバーや他部署のリーダー陣やメンバーと一緒に考え、よりいい形にしていければと思っている。