仕様レベルの手戻りの振り返り
最近手掛けた機能で大きな手戻りを起こしてしまったので次回以降の開発に活かせるように言語化しておく。
手戻りの原因は2つ
- 課題の深堀りが足りていなかった
- 既存システムのデータ構造に対する理解が足りていなかった
課題の深堀りが足りていなかった
A機能を追加して欲しいという要望を満たすために、既存システムのデータ構造を壊さない範囲で「最小工数で実装できる方法」を選択した。 しかし、その方法ではA機能は追加できているが、業務上の課題が解決し切れていない片手落ちの対応になってしまっていた。 片手落ちの対応では結局ユーザに価値を届けられないので、仕切り直しになった。
既存システムのデータ構造に対する理解が足りていなかった
上記の「最小工数でできる方法」を選択したのは既存データ構造に対する理解が不十分なだったことも影響していた。 コードとテーブルを見てある程度理解はしていたけど、空で語れるレベルの理解ではなかった。 ちゃんと理解していれば、既存データ構造に適した拡張を加える判断ができたはずで、「最小工数でできる方法」は選択していなかったと思われる。
弊社開発フロー
before
after
対策
以下をドキュメントとして作成して、関係者に共有する
- 起票されたIssueに対して「Why?」「So what?」という問いを繰り返し、課題を深ぼる
- 業務とデータの関係を理解するために、既存システムのデータ構造を「図」にする
上記とキックオフMTGを踏まえた上で、ユーザーストーリーを作成する
- ロールごとに書く(管理者、営業、開発など)
- ストーリーを独立してリリース可能な順番に並び替える
- リリースを細かくするため
- スケジュールが把握しやすくなる
- 進捗が見えやすくなるので、メンタルに優しい
- リリースを細かくするため
- ユーザストーリー作成がスムーズにできない場合は、課題の深堀り・既存システム理解が不足している可能性が高い
メモ
開発フローが5段階あるうちの各フェーズでどうしたらより効率良く仕事を進められるかも言語化しておきたいな〜〜
