みなさんこんにちは！
UUUMシステムユニットの sawa__it です。
10ヶ月の子どもが全然離乳食を食べてくれません。どうしたらいいですか？（ガチ）
自己紹介
UUUMには2020年の12月に入社しました。
最初は社内の数値管理システムを担当し、現在ではクリエイター管理システムの担当をしております！
役割はPMです。
PMといってもコンテキストが定まっておらず実態はプロダクトマネジャーとプロジェクトマネジャーとエンジニアリングマネジャーが混ざったようなことをしております。
前職では順番待ちシステムの会社で主に某大手回転寿司チェーン向けにオウンドアプリやアプリ内のスマホオーダー、順番待ちタッチパネル＆配席管理システムの開発及びPMをやっておりました。
2019年にScrumAllienceの「認定スクラムマスター」を取得しており、各種イベントや勉強会にも参加しているので見かけたら声をかけてくれると嬉しいです！
振り返り
上記の通り、役割がいろいろ混ざったようなことをしているためどの立場で何をやってきたかというのは曖昧になりますが参考になれば幸いです。
前提
チームの状態として自分が入る前はこんな感じでした
- チームは５人（PM含む）
- なんちゃってアジャイル
- タスクはアサイン形式
- 要件が降りてくるだけで自社開発なのに受託開発っぽいという意見があった
- エンジニアとユーザの関わりが少ない
Scrumの導入
「Scrumは銀の弾丸ではない」とはよくいうもののソフトウェア開発をする部署や人においてアジャイルソフトウェア開発宣言やアジャイル宣言の背後にある原則は大事な考え方だと思っており
弊社の経営理念である「セカイにコドモゴコロを」や経営戦略である「もっとアソビナカマを」にもマッチした考え方だと捉えています。
チームにはジュニアエンジニアもいたため今後のキャリアにも備えてフレームワークに則った開発経験がある方がよいと思い、2021年の６月からScrumを導入しました。
導入後にチームとして得て欲しいと期待する点は以下です。
- フレームワークに則った開発経験
- 開発の自分ごと化するマインドセット
- ドメイン知識の吸収
体制について
アンチパターンから入るのも申し訳ないのですが
チームとしてScrumを経験したメンバーが他にいなかったため現在においても自分がプロダクトオーナーとスクラムマスターを兼務しております。
正直、導入してから半年以上たった今ではチームも成熟し振り返りでチーム自らカイゼンできていると思っているので不都合を感じないのですが、チームのカイゼンにフルコミットできるわけではないのでやはり兼務はしない方が良いです。
特にScrumの導入とチーム異動によってプロダクトを担当したタイミングが近かったこともあり、導入や変更は少しずつと思いつつも「よくわからない奴が急にプロダクトの決定権を持ち開発体制にまで口を出してきた」というような印象を与えたと思います。見え方伝え方にバイアスがかかってしまったのかなと感じているので、やむを得ず似たような状況になってしまう場合には注意が必要です。
スプリントは１週間
最初は「納期に追われるみたいで辛い」「２週間にしたい」という意見もありました。
その都度「１週間の計画が立てられないチームが２週間の計画を立てられるわけがない」と説明し今ではリズムも定着し週ごとに事業の優先度に対応した開発ができていると思います。
これはスクラムマスター研修での江端 一将さんの受け売りでもあります。
スプリントの開始と終了
最初は月曜始まり金曜終わりのスプリントでしたが、祝日でイベントがずれて調整コストが高かったり、月金で休みをとりにくくなってしまったのでおすすめしません。
次に水曜始まり水曜終わりに変更しなるべくオフラインで行うように変更しました。
オフラインはコミュニケーションの観点ではよかったのですが、コロナに阻まれて結局オンラインで１日中MTGとなりました。
水曜日が近づくとプレッシャーがしんどくなってきたという声や、シンプルに座り続けるのがしんどいという理由で曜日を分ける判断をしました。
現在では木曜始まりの水曜終わりのスプリントで回しています。
水曜日に関連プロダクト含めた意思決定の場があるので翌日に計画を反映できるのでちょうどよくやれていると思います。
リファインメント
リファインメントはスプリントプランニングの前に時間をとって行っておりましたが、デイリーでも新しく作った要望に対して説明をするようにしていきました。これによってプランニングの場で改めて説明する必要がなくなりました。
プランニング
プランニングではストーリーポイントを使っていません。
導入時に徐々にScrumに切り替えていこうとする中でストーリーポイントを使った見積もりへの変更を後回しにしてしまったため未だに時間で行っております。
フィボナッチ数を使った時間見積もりって何それ美味しいの
釈明をさせていただくと時間で行っているもののフィボナッチ数で進めているため単位が違うだけで相対的ではあるし、ベロシティの観測にも影響はありません。
そのため、感覚的には長く時間がかかってしまっており結果としてプランニングが時間通りに終わらないことがしばしばあります。
一方で、タスクの見積もりが８以上になると取りかかった際に「朝のデイリーから夕方までに終わらないということになるので分割した方がいいよね、4以下になるようにしよう」という気づきも得られたのでそこはよかったと思います。
タスクはサインアップ方式で行っているため興味のあるタスクについて自ら選択することができます。
旧来のトップダウンのマネジメントには見られない「自分たちで見積もって自分たちでタスクを決定し自分たちで進める」形式はある種逃げ場がないようですが、これまで以上にチームに責任感が生まれたように思えます。
エンジニアとユーザに直接会話してもらう
Scrumではチームが「自己組織化（作業を成し遂げるための 最善の策を、チーム外からの指示ではなく、自分たちで選択する。）」することを目指します。
実はそんな高尚なことを目指しているわけではなく
「大枠はプロダクトマネージャが考えるけど、詳細は手戻りがなるべく発生しないように自分たちでフィードバック受けた方が身になるよね。」であったり「やらされている感」の払拭がメインでそうしていたのですが
実際に行ってもらうと直接話をしてもらうことで以下のような意見が出ました。
- 要件を落としてもらうだけではわからない課題感や温度感、背景が伝わった
- ドメイン知識が深まることで既存のコードの意図やおかしい点が分かる
社内とはいえユーザ側と直接会話することでこちらも責任感を高める要因になったのではないかと思います。
ところでスクラムガイドの2020年版に「自己組織化」という言葉が出てこないのはなんでなんでしょうかね。
デイリーは朝と夕方の２回
異動した当初は毎日夕方にデイリーを実施してました。
12月頃からメンバー追加で時間の制限があることから朝に移動しました。
チームの課題としてレビュー待ちの状態のタスクが残ってスプリントバックログを完了できないことが多かったため、バーンダウンチャートをデイリー毎に確認するようにしました。
それはそれで効果があったのですが、朝とったアプローチが上手くいったのか確認するのが24時間後になってしまうため、夕方にも行うようにしました。
また、チームではスプリントに影響を及ぼすような過小見積もりと技術的リスク、不具合、差し込み、体調不良などのリスクを「あばれる君」と称して報告します。「あばれる君」が発動されると、チームは手を止めてリスクを共有し計画を組みなおします。課題が大きければその時点で諦めるタスクを決定します。
Among us の緊急会議みたいな感じですね
「Slackで報告すればいいのでは」という意見もありますが、強制的にコミュニケーションポイントを作ることで報告の流れで課題を報告しやすかったり、アプローチを見直すことができたのでよかったと思います。
スプリントレビュー
スプリントレビューについては特筆するようなこともないのですが、コミュニケーションが増えたことで終わらないものが事前に分かっていることが多いため短い時間で済んでいるように思います。
振り返りはKPT
最初はポジティブに進められそうなYWTを採用しホワイトボードツールで行いました。しかし振り返り慣れをしておらず、課題であれば出しやすいということでKPTをテキストで行うように変更しました。
KPTに切り替えてからもやはり最初は主に自分を主語にした表面的な振り返りばかりでチームに対しての意見は出てきませんでした。
が、「なぜ上手くいかなかったのか」「どうすれば次うまく行くのか」などを半年以上繰り返すことによって徐々にメンバーからもチームに対しての意見が出せるようになってきました。
最後に
このような感じでチームにScrumを導入した流れを振り返ってみましたがいかがでしたでしょうか。参考になるところがあれば幸いです。
最初は一人で頑張っている感じがしましたが、だんだん理解を得られて周りにも評価される実感が得られるのでチームのみならず部署全体に広まれば良いと思ってます。
ではでは！
