【2025年6月2週目振り返り】改善チケットの消化方法、夏祭り、MCP
やったこと
- 所属プロダクトが先週リリースしたので、1週間ハックウィーク的なものを設けて改善活動をしていた
- 僕は Storybook を使ったテスト環境を整えたくて、まずそれができるようにプロダクトのコンポーネント設計の考え直しと、ある程度その設計にそってリファクタを進めたりした
- 見事にそのリファクタでバグを出したりしたんだけど、それを踏んだユーザーはいなかったのでギリギリ助かった
- テストを整備するためのリファクタでバグを出すの、厳しい…
- プロダクトの改善活動、こういう落ち着いている期間にがっつりやるだけじゃなくて日々の開発の中で少しずつ進めるための仕組みづくりをしていきたいな
- 娘のダンス教室に見学に行った
- 2ヶ月ほど前から娘がダンス教室に通い始めた
- 保育園で一緒だった子のママがプロのダンサーで教室もやっており、その人の教室に入った
- 僕は主にスイミングの面倒を見ており、妻が主にダンスの面倒を見るという役割分担が出来上がっていたので、ダンスの様子は妻が撮った動画で見ていたくらいで生で見たことはなかったんだけど、今回初めて見れた
- 一生懸命振りを覚えて踊っている姿はキラキラしていてとても良かった
- と同時に、たまに先生の話を全く聞いておらず鏡に写る自分に夢中になっていたりすることもあって、課題も見つけられた
- 2ヶ月ほど前から娘がダンス教室に通い始めた
- 最寄り駅で小さめなお祭りをやっていて娘の友だちと一緒に参加した
- 駅前のバスロータリーを封鎖して、キッチンカーが15台くらい？並んで食べ物やおもちゃを売っている感じのイベント
- 地下アイドルっぽい人たちのライブもあったりしてなかなか楽しかった
- 娘たちはアイドルに手を振られてめちゃくちゃ興奮しており、ピュアさがとても良かった
- フロントエンドカンファレンス北海道2025のプロポーザルを出した
- Storybook v9 × Next.js App Router時代のコンポーネント設計〜RSC依存を抑えテストを活用する実践パターン〜
- 頑張ってひねり出したけどレベルが高い内容とは言えないので、あまり期待せずに待機しておきます
- MCP の活用、初めてできた
- プロダクトのコンポーネント設計を改善するにあたって、親のチケットとそれに紐づく対象ファイルの変更の子チケットというのを JIRA で作りたかったんだけど、子チケットの数がめっちゃ多くなってしまうので JIRA MCP を使ってエージェントに依頼したら良い感じに作ってくれた
- エピックとかその他メタ情報の制御がうまくいかなくてちょっと手作業を入っちゃったんだけど、MCP をしっかり活用できていなかった中でやっと意味がある活用ができて良かった
振り返り
- プロダクトの機能開発と改善
- 改善活動、スクラム開発をしているとなかなか継続的にやっていくのが難しい
- 基本的には新規機能開発やユーザー要望への対応、バグ修正が最優先タスクになる
- エンジニアが切るような改善チケットは優先度が上がらず貯まる一方になっていく
- そういうのを解決するために、スプリントの中の20%は改善活動に充てるだとか、毎日何時以降は me-time と呼ばれる時間としてスプリントタスク以外のことをやる時間にするだとか、そういう決め事をするんだけど、結局ビジネス側と握ったスケジュールがパツってくるとそういうのをかなぐり捨てて機能開発にフルコミットになって、決めたことが廃れていったりする
- そんなわけでなかなか改善チケットの消化を仕組み化するのが難しい
- 現状は個人のモチベーションによってちょこちょこ消化されているなって感じ
- ありそうな対策として
- その改善チケットのプロダクト価値をエンジニアが語れるようになって PO がスプリントに入れる判断ができるようになる
- エンジニアのスキルとして、ビジネス的価値で語れるようになる必要がある
- スプリントに必ず改善チケットを1,2個入れる運用をルール化する
- 優先度決めを PO に任せずにエンジニア含めてみんなで決める文化を作る
- スケジュールで忙しくなってきたときにこのルールが消え去らないように対策を考える必要はありそう
- あとはこの改善チケットの消化を可視化して、改善実績を定期で共有する仕組みを作ったりするのは良さそう
- 改善チケットレビュー文化を作る
- 改善チケットをみんなで見て、棚卸しをしたり優先度を決めたりできると良さそう
- そんな時間を毎週30分くらい作ってもいいかも
- 技術負債を見える化する
- 技術負債ダッシュボード的なものを作ったりする
- lint の warning、E2E の成功率、ビルド時間、テスト実行時間、テストのカバレッジなどなど、このあたりの数値を可視化して、これが悪化してきたときにビジネス的な影響を語れると良いかもしれない
- レトロで改善消化率を見る
- 改善チケットの消化率を KPI として持つのも良いかもしれない
- その改善チケットのプロダクト価値をエンジニアが語れるようになって PO がスプリントに入れる判断ができるようになる
- 結局のところ
- 同期的な時間が増えてしまうという問題はある
- ゆるいスクラムをやって非同期コミュニケーションを重視していたりするとなかなかどんなやり方も定着させるのは難しいかもしれない
- 個人のモチベーションに頼らず仕組み化する必要があるんだけど、これが僕には難しい
- 僕の熱意によって頑張ればいっかというフェーズはそろそろ辞めて、チームを巻き込んで仕組み化する活動をしていくことがステップアップに繋がりそう
- 結局長くエンジニアをやっているとこういうプロダクトマネジメントを学んで行く必要がありそう
- 同期的な時間が増えてしまうという問題はある
- 改善活動、スクラム開発をしているとなかなか継続的にやっていくのが難しい
- 久々に1ヶ月の収支がプラスになった
- 5月分の収支をまとめた
- ここ数ヶ月、税金とか車検とか病院とか小学校準備とかなんやかんやでずっと収支がマイナスの日々を送っておりついに貯金が尽きたんだけど、久々に収支がプラスになって貯金ライフを復活させることができたのでこの調子でやっていきたい
来週やること
- 長々と読み続けている重い本2冊を読み終える