※ラグビー人気がすごい今日この頃ですが、ラグビーの話ではなくソフトウェア開発手法の話なので悪しからず。
はじめに
LITALICOでQAエンジニアしている@haizi18です。
この記事は「LITALICO Engineers Advent Calendar 2019」の23日目の記事です。
前職でQAエンジニアでジョインした際に、「プロダクトチームがうまく回っていないからと何とかしてほしい」ということで、QAエンジニア経験しかない人がプロダクトに関わっている全員が幸せになれるような状況をつくるために、スクラムマスターとして試行錯誤しながらスクラム開発を取り入れた１年間を振り返ります。
この記事では、スクラム開発をどのように導入していったのかを解決していったのかを、時系列でつらつら書いています。
公開できる範囲で作成物なども添付していきます。
書いていたら記載量がおおくなったしまったので、２〜３記事に分けます。
今回の記事
準備編：チームにジョイン〜Sprint0まで
次回以降
- 実践編：Sprint1〜
- 横展開編：他チームへの展開
これからスクラム開発を取れ入れる人、取り入れたけど悩んでいる人の参考・安心材料になれば幸いです。
略語
- SCM（スクラムマスター）
- PO（プロダクトオーナー）
- MVP（Minimum Viable Product）
前提条件
私のスペック
-
QAエンジニア
- 歴は、５年ぐらい その前はテストエンジニア５年ぐらい。
- 主にリリース・品質基準策定、テスト計画〜テストケース実施、開発やテストのプロセス設計・改善などを経験してきてます。
- QA組織のマネジメント経験あり。
- PM（プロジェクトマネージャー）経験なし。
- コーティングはほぼできない、RubyとJava Scriptを少しかじった程度。
-
今まで関わったプロダクト
- 組み込み系ソフトウェア開発でウォータフォール開発：6年
- toB向けSaaS系サービスでアジャイルぽい開発：4年
プロダクトチームの取り巻く環境
組織
５０名ぐらいtoB向けSaaSサービスを開発提供しているプロダクトが主体のベンチャー。
グループは、職能ごとに分かれており、ビジネス、総務/人事、開発の３つ。
プロダクトが３つあり、プロダクトチームも３つ存在する。
ジョインしたプロダクトチームの構成・状況
-
メンバー10名
-
PO1名、デザイナ1名、開発エンジニア4名、テストエンジニア3名、QAエンジニア兼SCM1名（私）
-
リリース対応に追われ、開発エンジニア、テストエンジニア、QAエンジニアが疲労している状態で勤怠に影響し始めている。
プロダクトの状況
-
ファーストリリースして４ヶ月ぐらい。
-
MVPで作っていたため、ファーストリリースは最小限の機能のみでありながら、将来性を買われてかなりの法人ユーザーが契約している・興味を示している状況。
-
リリースは２週間に１度行なっている。
最初にやったこと
正確にチームの実態を知るために１ヶ月間QAエンジニアとして品質保証活動をしながら、以下のことを行いました。
-
プロダクトチームの全員のメンバーと1on1やランチを行き、現状について根掘り葉掘り聞きまわった。
-
そこで拾った不平不満、もどかしさ、腑に落ちない感、ストレス要因などを、課題感に置き換える。
-
次のリリースに何を出すかの検討〜リリースまでのプロセス・コミュニケーションパス・イベント等をdraw.ioを使って全て可視化できるようにした。
-
まとめた情報をリリース後に半日スケジュールを抑えて、プロダクトチーム全メンバーを伝えて全員の認識を合わせた。
伝えたことは「プロセス・コミュニケーションパスを可視化したもの」「うまく行っているところ」「課題感」の三つ。
その場で出てきたものも含めて全員でその３つをブラッシュアップをしました。
1ヶ月たって見えてきたこと
要約
-
アジャイル開発の思想を取り入れて反復的なプロセスで開発をしているが、何かうまくいっていない感を全員がもっている。ただ、何がうまくいっていないのか分からない。
-
振り返り（KPT）は行い少しづつ改善はしていっているが、新しい課題・困り度とがでてきて一向に開発スピードが上がらない。
-
リリース直前から今に至る半年間、作業量が多く長時間作業をしているため、チーム全員の疲労感がたまりモチベーションにも影響が出始めている。
※全部ではないですが、詳細な内容は参考程度に下記に記載。
コミュニケーション
-
会議体,朝会などは職能グループ単位で実施しているため、３プロダクト分の情報が毎朝飛び交っており、属しているプロダクトチームの状況・状態が見えづらくなっている。関係性が薄い情報が７割ぐらい占めている。
-
技術的なこと以外の困りごとを誰に相談すればいいのかわからず、毎回迷いて放置してしまうことがある。
結果的に Bugにつながったり、進捗の阻害要因になっている。
例：
・仕様の変更をしたが誰にどのタイミングで共有したらいいのか ・仕様検討でAさんともめて、コミュニケーション取りづらい -
POがビジネスグループのメンバーということもあり、基本クライアント対応で外に出ている。そのためPOとのコミュニケーションが取りづらく、要求・要件などの確認などにタイムロスが発生している。
-
開発エンジニア，QA,テストエンジニア，デザイナー間の要件・仕様の共有方法が口頭・会議体・ドキュメント・チャット等で散乱していて定まっておらず、認識ずれが発生し手戻りが起きる。
次リリースの開発案件
-
POから五月雨式に次リリース分の要求が開発エンジニアのリードにふってくる。
その都度見積もりを行い、リリースできるかどうか調整しているため、リリースまでの作業量の調整が難しく、作業時間を増やすことで対応している。 -
QA、テストエンジニア、デザイナーには、開発エンジニアのリードから決定した分の要求について説明がある。
そのため開発エンジニア以外の作業量を考慮した計画が立てづらい。立てることができない。 -
PO通さずビジネスグループ側から、直接開発エンジニアに次リリースの要求や本番環境のデータエクスポートなどのタスクがふってくる。
ビジネスグループリーダーからふってくると断れないメンバーがおり、結果作業量が増える -
ビジネス側に次リリースの開発案件は共有しているが、いまいち伝わっていないため、開発エンジニアに個々に確認しにくるケースが多発している。
先の見通し
- PO以外のメンバーは、1ヶ月の開発案件はなんとなく見えているが、3ヶ月先・半年先など今後のプロダクトが歩む方向性がよくわらず、達成感を得ることが難しくモチベーションに影響してるかもしれない 。
どうやって解決しようとしたか
スクラム開発なら解決できるのではないかとスクラム開発経験があるメンバーからの助言を得たのですが、導入方法はだれもわからず、体系的に全体を把握することにしました。
読んだ本・参考にした資料
読んでみて
ブラッシュアップして見えた課題をある程度解決できそうなイメージが湧いたのと、今度チームがぶつかる数多の障害物を取り除くためのフレームワークだということが理解できた。
-
スクラムの概要を１分で理解できるイラスト
一枚に集約されているため、全体像をインプットした上で本を読んだので、理解がしやすかった。 -
SCRUM BOOT CAMP THE BOOK
挿絵もあり、知識がなくてもアジャイル開発、スクラム開発について全体的に理解ができる、特にスクラム開発の各イベントも漫画化されていてイメージしやすくよい書籍でした。スクラム開発の全体像を０ベースで理解するにはおすすめ。ただ「バックログリファイメント」については記載がなかったと思うので、スクラムガイドや他で補う必要はあります。 -
スクラム現場ガイド
実際スクラム開発を導入した詰まったときに、聞ける人が周りにいない場合に辞書がわりに使うのに便利です。事前にさっ目をとおして、どんな内容が書いてあるかを把握しておくだけで十分だと思います。
実際、スクラム開発を導入して何度もお世話になっていてバイブル化しています。
感謝。
Scrum inc認定研修会に参加
上記の本を読み知識は入れましたが、チームに導入する前に
「味方・相談相手がほしい」「もう少しスクラム開発を熟知しておきたい」と思い、POを誘ってScrum inc認定研修会に参加しました。
費用
私は「Licensed Scrum Master」POには「Licensed Scrum Product Owner」に参加がしたかったのですが、各研修がみっちり２日間あり、費用は20万円。
ちゃんとした決裁ルートがなかったので、CEO・CFOに直談判。（ベンチャーならでは？）
洗い出し課題感を共有した上で、解決策としてスラクム開発の各イベントを紐づけてた表を書いて、さくっと説明して承認をいただき無事参加することができました。
認定研修会の内容
すでにまとめてくださっている記事がありましたので、研修の内容を知りたい方は、そちらを読んでみてください。
認定研修会の感想
スクラムガイドをより噛み砕いた資料が配られ、各スクラムイベントをチーム単位でのワークショップ形式で行うので、事前にSCRUM BOOT CAMP THE BOOK で得た知識を経験に変えらる貴重な機会でした。
「なぜ、そのスクラムイベントが必要なのか？」を体験することでき、本や一人で考えてもたどり着くのに時間がかかるであろう、経験則上からくる質問・悩みなども参加者から上がっており、導入イメージをつよく持つことができた有意義な２日間でした。
受けたからこそわかった事ですが、スクラム開発は「軽量」で「理解は容易」だけど実際ワークショップを行ってみると「習得は困難」だというのは身にしみて分かりました。
事前に知識をインプットしてその状態だったので、プロダクトチームに導入する際は、知識レベルを合わせる必要があることを痛感。
研修会後にSprint０を行う
プロダクトチーム全員の知識・目線を合わせるために、Sprint0（２週間）と称して次リリースの開発をしながら、スクラム開発でスプリントを回すために以下のことを行いました。
やったこと
-
スクラム開発を導入するメリットの共有
- 所要時間：１時間ぐらい
- プロダクトチーム全員＋ビジネスグループリーダーに、スクラム開発を導入するメリットを課題と紐付けて説明。
なぜスクラム開発を導入しようとしているのかを腹落ちするつもりまで話をする意気込みでしたが、すんなり理解を得られた。
-
スクラム開発の役割・ルール・イベント目的を最低限理解する
- 所要時間：合計５時間ぐらい
- プロダクトチーム１０名全員＋ビジネスグループリーダー
- 定時後に１時間ほどSCRUM BOOT CAMP THE BOOK のもくもく会を開催し、５日で読破。
-
インセプションデッキの作成
- 所要時間：２－３時間ぐらい
- プロダクトチーム全員
- プロダクトの全体像(目的、背景、優先順位、方向性等)を端的に認識を合わせるために、インセプションデッキを作成。
フェシリテートする人が慣れると１時間ぐらいでできるらしい - フォーマットはこちらを使用させていただきました。[ネスケラボ：インセプションデッキ]
-
Sprintの期間を決める。
- 所要時間：５分ぐらい
- プロダクトチーム全員
- 1Sprint＝ 2週間にしました。
以前からこの感覚だったので、特に違和感ないだろうという結論。
-
本番リリースのサイクルを決める。
- 所要時間：３０分ぐらい
- プロダクトチーム全員
- 月1回・ 2Sprint分まとめて本番リリース。
- 考慮したこと
- 1Sprint単位のリリースだとリグレッションテストが月２回発生してしまい、メンバーに無用な負荷がかかる。
- PO＋ビジネスグループリーダー＋ボードメンバーに意見を仰ぎ
リリースサイクルが1Sprint分・2Sprint分でも業界の特性上、クライアントに提供できる価値に差がでづらいと判断を得たのは大きかった。 - 緊急性が高い障害対応は都度都度対応。
-
スクラムイベントを開催する日時・参加者・運用を決める。
- 所要時間：3時間ぐらい
- プロダクトチーム全員
-
半年先までのプロダクトバックログを作成
- 所要時間：4ー５時間ぐらい
- POとSCMで実施
- 流れ
- POの頭にあるリリースしたい要望・要求を、ストーリーで付箋に書く
「○○として、✗✗したい、なぜなら△△だからだ」のような形 - POとSCMでデスカッションしながら優先度が高い順に並べていく
- 基本的には、迷った時にSCMが問いかけをしてPO自身の考えを引き出していく形のファシリテーションをした
- POから作成した叩き台を、ボードメンバー＋ビジネスグループリーダーに説明し意見をもらい、POの判断で優先順位を最適化する
- POの頭にあるリリースしたい要望・要求を、ストーリーで付箋に書く
準備編を振り返ってみて
やってよかったこと
-
信頼関係が気づけていないタイミングで何か変えようとするときは、大概反対勢力に対抗させることが多いので
課題の洗い出しを事前に時間かけて出来たことは、事実ベースで話をすることができ非常に有益だった。 -
プロダクトチーム以外のキーパーソーンを抑えると組織間のコミュニケーションがスムーズにいくと研修時に一緒だった方に教えていただいたので実践したみましたが、効果てきめんでした。
ビジネスグループリーダーを要所要所で巻き込んだ結果、開発の内情を理解してもらえたのと、半年先のリリース予定アイテム（最新情報）が明確に見えるようになったこともあり、ビジネスグループからの無理難題な依頼が減り、PO通してくるようになったのは大きかった。 -
スクラムガイド、書籍、セミナーの情報はあくまでフレームワークなので、思想や型はそのままでチームにフィットする運用・手順を事前に決めておかないと、無駄な障害にぶつかって導入が困難になってしまう恐れがありそうだったため、Sprint０を設けてスクラム開発を行うための準備時間を作ったのは正解でした。
今思う改善点
-
Scrum inc研修会で行ったスクラムイベントのワークショップをSprint0で行っておけば、事前にSprint1以降でぶつかる障害にきづけたかもしれなかった件が数個あった。
-
Sprint0で、スクラムイベントなどを決める際に特にたたき台など使用せず、その場で議論しながら作り上げたため、余計な時間がかかってしまった感がいなめない。
最後に
最後までお読みいただきありがとうございました。
もう少しわかりやすく図と追加したかったのですが、諸事情で時間がなかったため後日少しづつ更新していきます。
実践編：Sprint1〜は年明けに投稿予定です！
ご指摘・質問はお気軽に！！