顧客と合意した作業範囲
締結済みの契約と変更依頼を比較し、承認済みの範囲と提案段階の作業を区別します。
顧客の要件と実装結果の照合
契約と顧客とのやり取りを、開発タスク、コードの変更、テストに結び付けます。合意した範囲、実装済みの内容、まだ判断が必要な依頼を区別して確認できます。
テスト対象の機能に含まれていない顧客の要望
NorthstarのSSOチケットは、ログインのテストに合格しています。一方、顧客のセキュリティ質問票には、退職後4時間以内にアカウントへのアクセス権を停止する要件もあります。チームは契約書と議事録で合意の有無を確認したうえで、実装がこの機能に対応しているか調べる必要があります。
契約とコードを照合するプロジェクト範囲の確認
架空のRelay Studioのワークスペースには、契約範囲、顧客とのやり取り、設計上の判断、コードの変更、テスト、リリース記録をまとめています。合意した作業と実装済みの機能を比較し、顧客とチームが追加で決めるべき事項を確認できます。
作業のもとになった判断
顧客の意見や議事録をチームが記録した判断に結び付け、決定の経緯を確認します。
設計と実装の計画
設計上の判断を、関連するシステムと機能の実装計画に結び付けます。
実際に実装された機能
合意した要件を、完了したタスク、コードの変更、テスト結果に照らし、実装の状況を確認します。
合意した要件・実装状況・未決定事項の確認
顧客の言葉に含まれる要件を整理する。
顧客はログインとアカウントへのアクセス権の停止を、どちらも「SSO」と呼んでいます。その表現を、契約で合意したSAMLログインの範囲と、後から出たアカウント管理の依頼に照らして確認します。同じ呼び方でも、追加の機能が既存の契約範囲に含まれるとは限りません。
合意済みの範囲と追加の依頼を明確に区別。
NorthstarのSSOチケットはテストに合格しています。顧客が求める退職者のアクセス権の停止は、なぜ未対応のままなのですか。
要件からリリースまでをたどる。
設計上の判断ADR-12から、AUTH-81、コードの変更PR-118、テストAT-11、リリースRC-8までたどると、ログイン機能の実装を確認できます。API一覧と、リリースに含まれないAUTH-94を併せて見ることで、アカウント管理の依頼が未対応である理由を把握できます。
実際にテストした機能に基づく実装状況。
RC-8のコードとテストは、Northstarのどの要件に対応していますか。対応していない要件は何ですか。
次の合意に必要な判断を整理する。
テスト済みのリリース、現行のアカウント管理手順、未署名の変更依頼CR-9を併せて検討します。追加の作業を約束する前に、合意が必要な機能の動作、受入確認の内容、担当者を具体化します。
顧客とチームの判断事項が明確なレビュー。
Northstarの実装レビューの草案を作成してください。テスト済みの範囲、未対応のアカウント管理の依頼、次に決めるべき事項を含めてください。
新メンバーの受入れ・顧客支援・提案書の準備
新しいメンバーへの引継ぎ
プロジェクトの概要、主要な判断、担当者、進行中のタスクをまとめ、新しいメンバーが業務を把握できるようにします。
顧客サポートの調査
顧客の問題を、関連する要件、実装資料、過去の解決記録に結び付けて調査します。
新しい顧客への提案準備
似た過去のプロジェクトを振り返り、うまくいったこと、想定より時間がかかったこと、次の提案に反映すべき事項を整理します。
EngramRAG
業務の引継ぎに使える判断・実装の履歴
EngramRAGは顧客の言葉を、具体的な機能、記録された判断、実装資料に結び付けます。新しい依頼と承認済みの変更が履歴に残るため、後のレビューでも何を、なぜ作ったかを確認できます。
顧客の言葉を機能に結び付ける。
顧客が使う表現を、対応する機能やシステムに結び付けます。
提案・承認・実装の状態を区別する。
提案段階のアイデア、承認済みの変更、実装が完了した機能を区別します。
判断の理由も残す。
判断の理由と合意内容を残し、今後のプロジェクトのレビューでも活用します。
