こんにちは。
請求管理ロボシステムPMの田本(@tamotamo97)です。
弊社テックブログ3本目はスクラム開発の導入についてです。
現在スクラム開発導入真っ最中なのでそれまでに至った経緯、スクラム開発とは、導入の流れ、今後について書いていきたいと思います。
スクラムってなに?って人からスクラムやったことない、やってみたい、チームに導入したいという人まで少しでも参考になれば幸いです。
という感じで書き始めたのですが、ボリューミーになってしまったので
1章でスクラム開発を導入するに至った経緯と課題の整理
2章で具体的なスクラム開発の方法
の2本立てで書きたいと思います。本記事は1章。
経緯
請求管理ロボは2014年8月にローンチし、ちょうど5年を迎えました。
当時からの開発手法を振り返ってみると
- 完全外部発注でウォーターフォール
- 準外部発注でアジャイル的
- 内製でなんちゃってスクラム
と変遷してきました。
私はPMに上番して1年になりますが、上番してすぐにスクラム開発をやってみたい!ということで
当時の開発フローとスクラム開発をがっちゃんこにした「なんちゃってスクラム開発」のフローに変更しました。
1年経ってある程度課題が顕在化してきたのと、
チームメンバーの伊代田さん(@hiy0ki)からの課題発信もあり、
ディスカッションしながら導入に向けて動いているといった感じです。
2019年10月から本格スタートの予定です。
なんちゃってスクラムとは・・?
ちゃんとスクラムを勉強して振り返ってみると本当にスクラム開発全然してないな・・・ということがわかったので現行の開発フローを「なんちゃってスクラム」と呼んでいます。
今までの弊社の開発フローはVモデルに沿ったアジャイル開発を採用して開発を行っていました。
- 要求ヒアリング、要求分析・整理
- 要件定義→レビュー
- 基本設計→レビュー
- 詳細設計
- コーディング→レビュー
- 機能テスト仕様書作成→レビュー
- 機能テスト
- リリーステスト仕様書作成→レビュー
- パフォーマンステスト
- リリース計画書作成
- リリース
機能の内容によって他の工程が入ったりしますが、
基本的には上記のフローを1ヶ月でサイクルしていました。
なんちゃってスクラムにして大きく変えたことは上記からプラスで
- スプリントを1週間と決めて小さい単位で毎週リリースをした
- デイリースクラム、スプリントレビューは取り入れた
の2点でした。
当時はリリース単位を小さく、回数を多くして問題に素早く柔軟に対応できるようにを目的として導入しました。
なんちゃってスクラムでの課題と目的の確認
スクラム開発を導入するにあたって現状の課題の整理をしてみました。
開発プロセスが変わることは大きなことですし、導入初期はどうしても開発スピードが下がります。
ちゃんと準備しないと正しい検証ができずに結局なんだったっけ?となります。
現状の課題
まずはスクラム開発をなんとなくやっているというところで以下のような課題がありました。
- 一般的なスクラム開発ではないので一般と差分が大きく新規メンバーのオンボーディングに時間がかかる
- ストーリーポイント、スプリントプランニングをしていないので見積が個人プレー
- チームが前より良くなっているのか、悪くなっているのかがわからない
- 他部署などへの説明、連携が取りにくい
- チームとしての見積ナレッジがたまらない
- ロールをきちんと分けていないのでボトルネックになる人がでてくる
- 例えばPOとSMを兼任することによって、ナレッジの片寄り、一部業務の集中、待ちによる意思決定の遅さが発生する
- スプリントの振り返りをしていないので、チーム力が向上しない
- トップダウンで担当者をアサインするので自立型チームにならない、管理コストがかかる
目的
何のためにスクラム開発を導入するのかを整理することが大切だと思います。
どの開発手法を選択するにも根幹としては
- チームの開発スピードのさらなる向上
- チームのプロダクト品質のさらなる向上
この2つを達成していきたいというベースがあって、
その上で上記現状の課題解決が見込まれそうなのでやってみようとなりました。
(おまけ)目的ついでにどういうチームであるべきかも少し話しました
雑に箇条書きです。
どういうチームであるべきか
- 請求管理ロボで売上を上げるシステムを作る
- 安全なアプリケーションを作る
- 請求業務の最適解を提供するアプリケーションを作る
- 業務的に専門的な知識が必要でチームにそのナレッジがある
- 役割ごとの専門家(要件定義、実装など)が集まる(分業できる)チーム
- (いままでは色々できるひとを求めていた(チームが小さかったからそのほうが効率良かった))
- 今(これからは)質を上げるステップ
- 開発速度が速いこと
- アプリ自体の動作速度が速いこと
- 速いことはいいことだ
- 実験的なもの(マイクロサービス試すとか)もできるようにしたい
- チームとして成長できる
スクラム開発について
課題と目的が整理できたところでスクラム開発について勉強していきました。
具体的な勉強方法としては
- 本3冊読む
- ネットで細かいところを調べる
-
イベントに参加して詳しい人に話を聞く
第1回 Scrum Beginners Night! (2019/08/20 19:30〜)
こちらのイベントに参加しました。
めっちゃ丁寧で一気に色々わかりますし、Scrum Masters Nightの子イベント的に運営しているみたいなので、初学者の方はBeginnersNightに参加してからMasters Nightに参加するとより良いと思います。
講師の方がとってもいい人だった。わかりやすかった。
をしました。
スクラム開発とは
スクラム開発って何?とかスクラム開発の流れやルールを説明しようと思いましたが、
それだけでかなり長くなりそうなので、次回の記事にまとめようと思います。
(まとめたらこちらにリンク貼ります)
まとめました。
導入の仕方・流れ
- 上記のようなことを整理してまずは2,3人でディスカッション
- 固まってきたらシステムチームのみんなに伝える ←☆うちはイマココ
- ステークホルダーに伝える(事業部全体)
- やってみてどうだったか評価する(☆これ重要)
まとめ
今回はスクラム開発の導入についての説明のみとなってしまいましたが、
次回の記事でスクラム開発の詳細と
その次は弊社が運用してみてどうだったかを続編として書いていこうと思います。
今日はこのへんで。
もう少し詳しく聞きたい、一緒に開発してみたい!という方がいらっしゃいましたらいつでも手ぶらで遊びにきてください!
P.S.先週FintechAward2019で3位を受賞しました!うれしみ!