固定スコープ開発の受入条件をどう書くか

「動くダッシュボード」だけでは、完成の解釈が分かれます。書面の受入条件には、入力、期待する動作、確認担当者が納品を受け入れるために使う証拠を記載します。

スコープ、対象外、納品条件とともに着手前に合意してください。完成を確かめる共通の基準になりますが、事業成果を保証したり、すべての開発リスクをなくしたりするものではありません。

一つの条件に五つの要素を入れる

「連携が安定している」を、具体的な場面に置き換えます。以下は条件の書き方の提案例であり、顧客案件で得られた結果ではありません。

申請者権限を持つパイロット利用者が有効な申請を送信すると、担当者と状態を持つ記録が作成されます。承認権限を持つ担当者は申請を承認し、記録された判断を確認できます。申請者はAPI経由でも自分では承認できません。

証拠は、テスト環境での合意した操作手順と権限テストです。必須項目が空の場合と保存に失敗した場合は、別の条件で確認します。対象の役割と画面を明記し、一つの条件がいつの間にか製品全体の仕様へ広がらないようにします。

承認済みのテスト注文について、連携先が合意した項目を一度だけ受け取ります。同じイベントを再送しても注文は増えません。連携先が利用できない場合は失敗を記録し、合意した復旧手順で重複なく転送を完了できます。

イベントを使うシステムでは、この確認が必要になります。Stripeも、Webhookの同じイベントが複数回届く場合があると説明しています。Webhookのガイドを読む。

テストする停止状態、復旧手順、証拠を決めてください。一回の復旧テストに成功しただけで、今後のあらゆる障害に対応できるとは判断しません。

文書の種類、項目、正解データ、採点方法を合意します。代表的な評価データを確保し、システムの調整には使わず残します。各実行について、出力、誤り、欠落項目、担当者による修正を記録し、結果を判断できるようにします。

正解率の目標を設けるなら、分母、一部だけ正しい出力の扱い、許容できない誤りを決めます。結果のばらつきが判断に影響する場合は、反復実行も合意します。モデル自身が示す確信度は、正しさのテストではありません。

人による確認の経路も調べます。不完全な入力や対象外の入力が、合意した確認工程へ渡ることを確かめてください。承認が必要な操作は、その承認を受け取る前に実行してはいけません。

PoCでは、動かせる実験と、その方法が業務に適さないことを示す評価を納品する場合もあります。実験の実施、測定した閾値の達成、または両方のどれを約束する案件かを事前に決め、閾値に届かなかった場合の扱いも合意します。

実業務で使うパイロットでは、必要な権限、デプロイ、監視、復旧、サポートを明示的にスコープへ含めます。必要に応じて、リポジトリへのアクセス、起動手順、引き継ぎの確認も加えます。説得力のあるデモだけでは、これらを満たした証拠になりません。

進捗デモでも受入条件を使います。合格、不合格、未解決の依存事項を記録してください。別のシステム、言語、業務が必要になったら、成果物、価格、日程への影響を書き、その作業を始める前に変更へ合意します。

最初の案は共同で作ります。エンジニアは技術的に確認できる条件にし、業務責任者は意図した仕事を確かめる内容になっているかを確認します。

相談には1ページの依頼書を持参してください。業務自体が未定なら、最初の開発の選び方から始められます。

固定スコープのパッケージを見ると、案件ごとに成果物と受入条件を合意するための出発点を選べます。