1. 手戻り・考慮漏れの原因
プロジェクトを進める中で、手戻りや考慮漏れが発生する原因はいくつかありますが、主に以下の2点が挙げられます。
-
要件に対する認識の齟齬
クライアントや関係者と要件の解釈が異なる場合、実装が進むにつれ誤解が発生し、手戻りが必要になることがあります。 -
既存仕様に対する認識の齟齬
現行のシステムや既存の機能に対する影響を見落としてしまうことがあります。この結果、意図しないバグや挙動が発生し、手戻りが必要になることがあります。
2. 実装前に行うこと
2.1. 要件に対する認識の齟齬を防ぐ
実装内容の整理/PR(MR)のスコープ決め
実装前にまず行うべきは、タスクのスコープを明確にすることです。作業のボリュームを小さくしておくことで、手戻りが発生した場合の影響を最小限に抑えることができます。スコープを小さく分割することは、レビュアーの負担を軽減し、レビュー時間の短縮や品質の向上にもつながります。特に、画面レイアウトの変更が大きい場合や、デザインイメージが提供されていない場合は、簡単な資料を作成し、依頼者に事前確認を取ることが有効です。
例: 定期購読プランのアップグレードと割引コード適用
ここでは、定期購読プランのアップグレード機能と割引コード適用機能を例に、スコープの分割を紹介します。
-
スコープ1: プランアップグレード機能の実装
- ユーザがアカウント設定画面で「プランアップグレード」オプションを選択
- アップグレード対象のプラン一覧を表示し、ユーザが選択したプランのアップグレードAPIを呼び出す
- APIレスポンスを元に、アップグレードの成功を確認し、以下の処理を行う
- ユーザアカウント情報の更新
- 新しい請求サイクルと料金情報を画面に反映
- アップグレード完了の確認メール送信
- アップグレード失敗時には、エラーメッセージを表示
-
スコープ2: 割引コード適用機能の実装
- プランアップグレード画面に割引コード入力フィールドを表示し、条件に応じてフォームを表示
- 割引適用APIを呼び出し、コードの有効性を確認し、適用
- 割引後の請求金額をユーザに提示し、確認メールを送信
-
スコープ3: アップグレードおよび割引適用後のメール送信機能の実装
- アップグレードや割引が適用された際、自動的に確認メールを送信
- メールには、次回請求額や適用済み割引額を記載
内容が複雑である場合は、この段階で簡易的なレビューを受けることも選択肢の一つです。
2.2. 既存仕様に対する認識の齟齬を防ぐ
既存の機能に変更が影響する可能性があるかどうかを確認するため、既存仕様をしっかりと把握しておくことが重要です。既存のドキュメントがあれば、それを参照し、必要に応じて以下のような情報を整理します。
- 各画面ごとの操作、状態遷移、影響するデータ、影響する画面などを詳細に確認する
- ドキュメントが存在しない場合や古い場合は、以下のような情報を記載した資料を事前に作成します
資料の例
| 画面 | 操作 | 状態遷移 | 影響するデータ | 影響する画面 | 詳細 |
|---|---|---|---|---|---|
| サブスクリプション管理画面 | 「プランアップグレード」ボタンを押下 | "subscriptionPlan: basic → premium" | サブスクリプションデータ、ユーザーデータ、請求データ | アカウント設定画面 | ユーザが「プランアップグレード」ボタンを押下すると、プランが変更され、ユーザーデータと請求サイクルが更新され、確認メールが送信される。 |
| 割引コード適用画面 | 割引コードを入力し、「適用」ボタンを押下 | "discountStatus: not_applied → applied" | サブスクリプションデータ、ユーザーデータ、請求データ | サブスクリプション管理画面、アカウント設定画面 | 割引コード適用後、割引が反映され、サブスクリプションの請求金額が変更され、ユーザーデータが更新され、確認メールが送信される。 |
| アカウント設定画面 | 「プランキャンセル」ボタンを押下 | "subscriptionPlan: Premium → Cancelled" | サブスクリプションデータ、ユーザーデータ、請求データ、履歴データ | サブスクリプション管理画面、請求履歴画面 | プランキャンセル後、サブスクリプションデータが更新され、ユーザーデータおよび請求履歴に反映され、確認メールが送信される。 |
| $\hspace{8em}$ | $\hspace{8em}$ | $\hspace{14em}$ | $\hspace{8em}$ | $\hspace{8em}$ | $\hspace{8em}$ |
3. PR/MR作成時に行うこと
3.1. セルフレビュー
実装後には必ずセルフレビューを行い、以下の点を確認します。
- 仕様・要求を満たしているか: 要件通りの機能を実装しているか確認する。
- 潜在的な問題がないか: 見落としがないか、潜在的な問題やバグのリスクがないか確認する。
- コード品質: コードが簡潔でメンテナンスしやすいか、またリファクタリングが必要かどうか確認する。
3.2. チェック項目
PRやMRの作成時には、以下のようなチェックリストをテンプレートに追加し、それに基づいて作成・レビューを行います。
- 画面の変更あり: 画面レイアウトや表示内容が意図通りに変更されているか・解像度や端末のサイズによる違い
- DBスキーマ変更あり: 新しいフィールドやテーブル追加、既存スキーマの変更が正しく行われているか
- CI変更あり: CI/CDパイプラインでテストが通るか
- 変更内容の影響範囲について確認済み: 既存機能への影響・ドキュメントを更新しているか
まとめ
手戻りや考慮漏れを防ぐには、要件の認識統一や既存仕様の確認が重要です。スコープを小さく区切り、PRやMRの作成時に確認すべき項目を共有することで、リスクを減らしスムーズな開発が進められます。しかし、手戻りや考慮漏れを完全に無くすのは難しく、携わるシステムに対する経験が不可欠です。振り返りを行い、経験を積みながら少しずつ改善していくことが大切です。