要件カバレッジ
要件定義書（ドラフト）の機能要件38件・非機能要件・確認事項36件が、このデモのどの画面で確認できるかの対応表。要件の行を押すと、要件の内容・デモでの確認方法・開く画面が出る。
機能要件
38件
必須14・推奨18・廃止候補6
画面で確認できる
30件
操作して振る舞いを確認できる
一部のみ再現
2件
要点のみ。残りは説明・見本
移行しない（廃止候補）
6件
確認事項 優先度「高」8件
中野様への確認事項（要件定義書6章）。全36件（高8・中18・低10）。デモの各画面には、回答で仕様が決まる箇所に「確認 #n」の目印を付けている。
優先度
分類
| # | 優先度 | 確認事項 |
|---|---|---|
| 1 | 高 | 各会・祭事の「現会員／現職」の判定基準は何か（入金実績／退会フラグ／退任日／期間）。会ごとに定義が食い違っている。 ① 現行運用の実態 |
| 2 | 高 | FileMakerとAccessの双方に実装がある業務（崇敬会・総代会・大祓・年賀状等）の、現在の正本はどちらか。今後どちらに一本化するか。 ① 現行運用の実態 |
| 3 | 高 | 各種帳票（振込用紙・宛名ラベル・胡床短冊・領収証・封筒等）の実物用紙の型番・入手先・使用プリンタ機種。 ① 現行運用の実態 |
| 4 | 高 | 各Access DBの利用実態（同時に使う人数・PC台数）と、最新ファイルの置き場所（NAS共有パスが3〜4系統混在）。 ① 現行運用の実態 |
| 5 | 高 | 未受領のAccess/FileMaker関連ファイル（大祓・提灯祭り・流鏑馬管理・祈祷フォーム・記念事業等）は現存するか。提供可能か。 ① 現行運用の実態 |
| 15 | 高 | 出欠・玉串・初穂料・参拝実績など「当日運用」項目を新システムでデジタル管理したいか（現状は空欄のまま運用）。 ② 新システムの機能要否 |
| 16 | 高 | 各会の会員資格実体（多度講講員6,633人・神馬会会員名簿1,001人等、ハブ未登録が多数）を統合後の顧客へ正式に統合する方針でよいか。 ② 新システムの機能要否 |
| 36 | 高 | メニューフォーム.mdbの起動先のうち、未受領のDB（祈祷フォーム・祈祷管理法人・記念事業）は現存し今も入力しているか。FMの祈祷明細とどちらが正か。 ① 現行運用の実態 |
| 6 | 中 | 削除ボタンの平文パスワード（3桁数字）は現在も同じ値を使っているか。 ① 現行運用の実態 |
| 7 | 中 | 各会の会費・講金・初穂料等の単価・改定履歴は現在も同じか。 ① 現行運用の実態 |
| 8 | 中 | 祭事の開催日・年間スケジュールは毎年同じ日程か、変動するか。 ① 現行運用の実態 |
| 9 | 中 | 多度講の当年の参拝日程（Excel「本年参拝日.xls」）の最新版・過去数年分の提供（最優先）。 ① 現行運用の実態 |
| 10 | 中 | 各会の役職・世話方の交代が最新まで反映されているか（神馬会は役員の最新退任日が2021-11-08で止まっている可能性）。 ① 現行運用の実態 |
| 11 | 中 | FMレコードの書き出し可否と受け渡し方法（個人情報の扱い方式）。 ① 現行運用の実態 |
| 12 | 中 | 総代会・自治会長の就任年月日は実際の就任日か、名簿更新（入力）日か。年度の切り替わり実務。 ① 現行運用の実態 |
| 17 | 中 | 崇敬会の家族会員（444件）を別人物として登録するか、世帯主の付帯情報として持つか。 ② 新システムの機能要否 |
| 18 | 中 | 祈年祭・新嘗祭・多度祭Aの案内先（約215人が共通）を1つの「大祭案内先グループ」として統合管理してよいか。 ② 新システムの機能要否 |
| 19 | 中 | 10年継続表彰・誕生日・創立記念の挨拶・研修旅行・お守り送付履歴等を今後も続けるか、記録を残す必要があるか。 ② 新システムの機能要否 |
| 20 | 中 | 総代会旅行・崇敬会研修旅行の参加者名簿管理は今後も必要か。 ② 新システムの機能要否 |
| 24 | 中 | 各DBの残骸・旧系統テーブル（H21・祈年祭2・aaaa・講員管理〔IDとばし〕・来賓TBLあああ・一般会員等）は移行対象外として廃棄してよいか。 ③ データの取捨選択 |
| 25 | 中 | 節分祭の旧系統（祈祷名簿マスター372件・節分祭tbl603件、2011年で更新停止）は履歴として残すか廃棄するか。 ③ データの取捨選択 |
| 26 | 中 | 孤立レコード（崇敬者マスターに存在しない参照。各DB0〜14.2%）は人物を特定して復元するか、廃棄するか。 ③ データの取捨選択 |
| 29 | 中 | 起動経路のない帳票群（多度講管理4本・ふいご管理2本・神馬会1本・多度祭管理1本等）は不要と判断してよいか。 ③ データの取捨選択 |
| 30 | 中 | 退会・退講者を含む個人情報の保存期間（多度講の退講者3,199人等）。 ③ データの取捨選択 |
| 31 | 中 | 旧称→現称の統一（区長→自治会長、命会/人命界→神馬会など）を新システムの表記としてよいか。 ④ 命名・組織変更 |
| 32 | 中 | 神馬会の地区33区分とFMの町内地区22区分の対応（対応表）、地区の新設・統合の予定（小山台等）。 ④ 命名・組織変更 |
| 13 | 低 | 郵便番号・住所・電話の表記統一の方針。 ① 現行運用の実態 |
| 14 | 低 | 社報・崇敬会・総代会など複数会の配布物の重複調整の実務フロー。 ① 現行運用の実態 |
| 21 | 低 | 社報の町内戸数管理（全戸数列）・地区戸数集計を今後も使うか。 ② 新システムの機能要否 |
| 22 | 低 | 年賀状業務は現在も実施しているか。崇敬者マスター/FMのフラグへの一本化でよいか（実質は最優先。宛名の印刷手段が資料から不明）。 ② 新システムの機能要否 |
| 23 | 低 | 節分祭の「崇敬者検索」フォーム（ハブと同名だが接続なし）や旧系統名簿の扱い。 ② 新システムの機能要否 |
| 27 | 低 | 年賀状.mdb・メニューフォーム.mdb全体の廃棄可否（年賀状.mdbは現役。メニューは現行ボタン18が稼働中）。 ③ データの取捨選択 |
| 28 | 低 | 遺族会の「来賓TBL」と「来賓TBLあああ」のどちらが現行データか。 ③ データの取捨選択 |
| 33 | 低 | 総代会の「御厨」フラグの意味・範囲。 ④ 命名・組織変更 |
| 34 | 低 | 崇敬者マスターの「柱石献納者」（166件）等、意味が不明なフラグの確認。 ④ 命名・組織変更 |
| 35 | 低 | 「多度祭Ｂ重複」（ふいご管理）等、意味が不明な列の扱い。 ④ 命名・組織変更 |