「どの水準まで書けば設計完了か」は、お尋ねするより当方からお示しした方が早いと思われますので、成果物の一覧としてご提案いたします。これをもって「設計完了」の判定基準としていただきたいです。
詳細設計の上限について
一般的なIT案件では、詳細設計に「モジュール／関数単位の擬似コード」まで含めます。本件ではこれを含めない形とさせてください。理由は次の2点です。
- 実装作業は業務範囲外としてお話ししております。
- 設計とレビューを同一の者が担うため、実装まで踏み込むとレビューが自己検証になります。
したがって詳細設計の上限は「どう書くか」ではなく「何が決まったか」とし、判定基準・閾値・失敗時の動作・データ形式は当方が決定します。それをコードでどう表現するかは実装側にお任せいたします。
成果物一覧（ご提案）
| # | 成果物 | 内容 |
|---|---|---|
| 基本設計 | ||
| 1 | インターフェース定義 | 入力（振り分け後フォルダの新着PDF、またはA-7④の通知）／出力（「C」付き調査済みPDFとサマリ、返却先）／外部（外部検索・内部DB）。本件では最も重い成果物になります。 |
| 2 | 処理フロー・状態遷移 （シーケンスを含む） | 正常／タイムアウト／部分失敗（3調査のうち1つが失敗した場合）／再試行／「C」を付与する時点。「誤実行ゼロ」の本体はここです。 |
| 3 | 保存スキーマ （調査結果・証跡） | ご提案資料の「蓄積」に対応します。A-4のご回答がそのままスキーマになります。テーブル定義書は不要と考えております。 |
| 4 | 非機能の整理と前提の明示 （1ページ） | 通過条件を検証可能な形に翻訳し、未定の項目を列挙します。非機能要求そのものを当方が定義することはいたしません（通過条件はご提案資料が示したものであり、判定方法はD-1のとおり未定です）。 |
| 詳細設計 ／ 上限は「決定事項の確定」 | ||
| 5 | 調査ロジック仕様 | 項目ごとの照会対象・クエリの構成・ヒット判定基準（B-3）・抽出項目・失敗時の動作。 |
| 6 | 判定・集約仕様 | 異常値ハイライトの基準、サマリの形式、「承認／否認の判断は行わない」境界。 |
| 7 | 受入照合仕様 | 突合する項目、「迷えば必ず不一致に倒す」規則。ペーパーレス案件に限ります。 |
| 8 | テスト観点表 ＋ 未決事項一覧 | 通過条件をどう測定するかの観点。テストの実施は範囲外とします。未決事項一覧は下記のとおり完了条件に含めます。 |
| 作成しないもの ／ 一般的な工程には含まれますが、本件では省きます | ||
| — | システムアーキテクチャ構成図 | ご提案資料の図を正とし、差分のみ記述します。同じ内容を2か所に置くと必ず食い違うためです（A-7がその実例です）。 |
| — | ERD／テーブル定義書 | 当方でDBを新設しないため。上記3で代替します。 |
| — | API詳細仕様書／シーケンス図（単独） | インターフェースが3つのみであり、上記1・2に含めた方が食い違いません。 |
この一覧の前提
稼働は月32時間（2か月で64時間）を上限としています。上記8件はこの範囲に収まる分量として組んでいます。上限を超える分量が必要になる場合は、成果物の範囲をあらためて相談させてください。
レビュー段階について — 成果物ではなく、着手前に決めておきたい前提
- レビューの入力物 — 何をお受けしてレビューするか（コードか、実行結果か、実測値か）。閉域環境およびWings専用端末に当方が接続できない場合、非機能の充足は当方では測定できませんので、実測値をご提供いただく前提になります。
- 回次 — 実装完了後の1回のみとすると事後承認になります。区切りを決めたいです。
- 指摘管理台帳 — 指摘とその回答・未解消を一覧で残します。設計とレビューを同一の者が担う構成では、これが唯一の補いになります。指摘が文書で残れば、自己検証であっても第三者が後から検証できます。
「設計完了」の定義について
「すべて決まっている状態」を完了と定義しますと、A-1〜A-7へのご回答が揃わないことが、そのまま当方の未達として計上されてしまいます。そのため完了の定義は「決まったもの ＋ 決まらなかったものの一覧（未決事項一覧）が揃っている状態」としていただきたいです。
ご確認いただきたい3点
① 上記の成果物一覧をもって「設計完了」としてよいか。
② パトリック様へは孫代表経由で提出し、パトリック様とは技術的な協議のみ直接行う（実装の細部の指示は行わない）という境界でよいか。また、パトリック様はこの分担をどうご理解されているか。
③ 設計書の承認者は誰か。またレビューの入力物・回次を、いつ、誰と決めるか。