見出し画像
Photo by rumaru

はじめてのすくらむ

JuKoA

こちらの記事はディップ株式会社Advent Calendar 10日目の記事です

はじめに

今回、dipにPMとして転職し、PMをしながら別プロダクトでスクラムマスターとしてスクラムを始めた話しとして、実際に導入までどのようなことをしたか、結果今どうなったかをまとめました。

自己紹介

DX事業本部でインタビュー受けたので、こちらで紹介。

スクラムを始めた理由

スクラムを始める理由、タイミングはチームそれぞれかと思います。
今回は、下記の内容が強かったこともありスクラムを採用しました。

  1. 価値探求が必要なプロダクト性質
    事業部要求が強く、顧客への価値が見出しにくいプロダクトだったため、事業部要求を元に、小さく繰り返し、顧客への価値を探求する形で進めようと決めました。

  2. 不確実な技術要素
    今回利用する技術として、チーム内で知見のない技術が必要でした。
    そもそもやりたいことにマッチしているのか、使う上での課題等、小さく回し、確認しながら進める形を検討しました。

  3. 社内開発
    プロダクト性質上、他のプロダクトが採用しているOEMは取れないこともあったため、社内開発で進めることになります。
    社内で開発しているからこそAgileに進めたいと決めました。

始める前に

今回の注意点としては、MVPとして、作るものが決まっている点です。
なぜMVPの範囲を決めたか？というと、初期プロダクトとしてのゴールが無いと、ゴールまでの道筋が描けなかったためです。

元スクエニCTOの橋本さん資料の138ページにあるように、進めた結果、そもそも間違っていたは避ける必要がありました。

そのため、今回は、MVPとして、最低限機能を決め、それに必要なタスクを洗い出し、WFで進めてもいいんじゃないか？という中、MVP対応後の進め方をスクラムで進められるように、できる変更から始めました。

Sprint1～3

チームメンバーからしたら初めてのスクラムでしたが、細かいルールを作らない状態でスタート。
ただし、何も無いと話しが進まないので、ベースに必要な下記は用意しています。

  • カンバン（ClickUp）

  • チケット管理するステータス

  • スプリント移行手順

  • デイリースクラムの流れと時間

  • スプリントプランニングの流れと時間

  • スプリントレビューの流れと時間

  • 念のための予備の時間

チームの状況と成長

各スプリントでの消化タスク件数は下記のとおりです。
Sprint1: 消化件数 7件
Sprint2: 消化件数 17件
Sprint3: 消化件数 18件

開始時、不慣れなこともあり、チケットをどう扱ったらいいのか、カンバンをどう活用したらいいのか、各イベントで何を話したらいいのか、メンバー的にもわからないことだらけだったかと思います。

そんな中、勇気を出して提案してくれるメンバーがいたため、いくつかのカイゼンが行われました。
・レビューに向けて用意するもの定義
・各ステータスのフローやチケットを動かすルール
・タスク洗い出し
・困ったことリストの作成

カイゼンの中で特徴的だったのが、困ったことリストです。
わからない事、どうしたらいいかわからない事、なにか引っかかる事を自由にチケット化してよいカンバンが作成されました。

個人的な振り返り

状況から、スプリントレトロスペクティブをあえて導入しませんでしたが、予備の時間が、実質レトロスペクティブの時間になっていたと思います。
ただし、定義が曖昧だったため、レトロスペクティブとして定義したほうが良い振り返りができると感じました。

ルール自体は少なく開始してよかったと思います。
タスク消化量からしても、最初の動き出しは淀みがちですが、チームメンバーが決めることで、モチベーションへの影響や自己管理化に繋がると改めて感じました。

Sprint4～8

安定期（と呼ぶのでしょうか？そもそも安定とは？）。
Sprint3までの経験値を元に、各イベントをこなすことができるようになった状態です。
あるべきは、レトロスペクティブ等で課題を出し合ったり、スクラムマスターから問いを投入すべきでしたが、タスク消化することをメインで進めたかったため、今回は実施せずで進めました。

ただし、ゴールの見える化は必要だと感じたので、アジャイルな見積もり方法を元に、残タスクの消化可能なスケジュールを提示し始めました。

チーム状況と成長

タスク消化メインであったこともあり、各自得意な分野のタスクを分けて実施している状態でした。
しかし、技術検証している点もあったため、デイリースクラム後、課題詳細を話す技術ミーティングが設けられていたため、検証だけでなく、相互理解が進んでいました。

しかし、ゴールがどこなのか、今の進め方が本当に正しかったのか？疑問に思うメンバーも出始め、スプリントレトロスペクティブの時間を作る形にしました。

個人的な振り返り

チケット性質からスプリントレトロスペクティブを省いたことが仇となりました。
たまたま、開発メンバー内の1on1を通し、メンバーが勇気を出して疑問を出してくれたから問題を発見できましたが、出てこなければ、MVPが終わるまでもやもやと進んでいたかと思います。

ポジティブに考えると、チームメンバーから疑問が出てきたのは、チームとして良い点だと思います。

Sprint9

スプリントレトロスペクティブを導入。
スクラムイベントがすべて実施される形。

チーム状況と成長

初回のスプリントレトロスペクティブでは、「Good/Bad/もやもや」を出しました。
実施した結果、開発メンバーはアジャイルにもっと進めたいと考えていた点が共有され、全員、手が行き届いていない機能ついて考え、必要なタスクが生まれました。

個人的な振り返り

レトロスペクティブを通して、チームメンバーはもっとアジャイルに進めたかった旨を聞くことができたのは良かったです。

レトロスペクティブには、ClickUpのホワイトボード機能を使いました。
まだ機能としては不足している点があるため、文字が小さい、重いなど使うための課題はあったので、様子を見ながら利用ツールを検討する必要があると感じました。

全体を通した所感

ルールの作成を最小限に抑えた点は全体的に良かったと感じています。
ルールが無いから困る事は多いですが、この「困る事」をチームで共有し、チームで解決できたのがポイントです。

レトロスペクティブの導入は遅かったかもしれません。
でも、気づいたときにすぐに行動することがベストだと思うので、カイゼンまでのスピード、また、それに適応できるメンバーは素晴らしいと思います。

今後について

今はまだ、「Do Agile」の段階。
チームメンバーの理解度などから「Be Agile」の段階に進めると確信しています。
各イベントを通し、「透明性」「検査」「適応」を軸にサポートしていこうと思います。


この記事が気に入ったらサポートをしてみませんか？