12. ケーススタディ・特殊ケース
これまでの1〜9章は「業務が正しく流れているときの標準フロー」を説明してきた。しかし実際の現場では、標準フローだけでは説明できない挙動——一見バグに見えるがそうではないもの、逆に本物のバグ、メニューにすら出てこない業務、二段階に分かれた手動運用——に日常的に出会う。本ページは、そうした「新人が現場で最初にぶつかって驚くこと」を1か所にまとめた、いわば"戦訓集"である。第1部は代表的なケーススタディを物語形式で、第2部は業務別の特殊ケースを早見表で、第3部は9本の業務ブリーフに残るすべての未解明事項を、現場ヒアリングにそのまま使える質問リストとしてまとめる。
1. 代表ケーススタディ
① RSBS23 支払総括書の小計 / ② 隠しメニューMENUR1 / ③ itks16r ラベル取り違え / ④ SSBS01/SSBS02 二段階出荷
⑤ Excel見積とAS400単価の橋渡し / ⑥ 設計№が先・品番登録が後 / ⑦ 外製受入と経理入力の二重入力 / ⑧ 受注まとめ入力の属人化
2. 業務別の特殊ケース早見表
見積 / 受注 / 技術情報 / 生産 / 試作・工機 / 外製 / 出荷 / 経理
3. 未解明事項の総覧 — 現場ヒアリング質問リスト
- 標準フローでは説明できない「新人が現場で驚くこと」を代表8ケース+業務別早見表にまとめる。
- 未解明事項は約130件→44項目に統合され、唯一の台帳(SSOT)はhearing.htmlに一本化された。
- RSBS23小計問題やMENUR1隠しメニュー発見など、「正しさより一貫性」を学ぶ好例が並ぶ。
1. 代表ケーススタディ
ここで紹介する8件は、単なる「変わった仕様」の紹介ではない。板倉製作所のレガシーシステムを理解し、正しく移行・運用していくうえで、新人が繰り返し立ち返るべき教訓を含んでいる。
① RSBS23 支払総括書の小計 — 正しさより一貫性 AS/400
背景: 支払総括書（現物印字版、RSBS23/ITSW32R）は、外注・材料・工具・設備・その他の5種別ごとに小計行を印字する帳票である。
何が起きるか: 小計を積算する変数G1KGxxはプログラム起動時に一度だけゼロクリアされ、種別が切り替わるたびにリセットされることがない。その結果、印字される「小計」は実際にはその種別だけの合計ではなく、それまでの全種別の累計になる。最後の種別グループの「小計」は最終行の「合計」と完全に一致してしまう。
なぜそうなっているか: 移行担当者は当初これを「休眠中のレガシーバグ」と判断し、数学的に正しい独立小計を計算する実装で移行版を作った。しかし本番のSHDPデータを実際にクエリしたところ、FY2025-2026のどの支払期間にも必ず5種類すべての種別が存在しており、「小計＝累計」は毎回・必ず発現していたことが判明した。つまり経理担当者が長年見てきた紙の帳票は、全部この状態で印字されていたことになる。3つの選択肢（①レガシー通りの累計 ②数学的に正しい独立小計 ③両方併記）を提示したところ、rmondo氏は①を選択した。理由は、経理担当が新しいWeb版プレビューを過去の紙の記録と突き合わせるとき、同じ数字が出ることの方が数学的な正しさより重要だから。
新實さんへのヒアリングで、支払総括書（RSBS23）そのものの現在の位置づけが判明した。種別ごとに小計を分ける仕様にしたのは前経営者の要望によるものだったが、現在この帳票はAS/400側の計算結果をチェックするための内部照合リストとしてのみ使われており、種別区分・その小計は特に不要——必要なのは合計のみ、と新實さんは明言した。D25で選んだ「レガシー通りの累計小計」という決定自体は誤りではなく、経理担当者が紙の記録と同じ数字で照合できることを優先した判断として引き続き正しい。ただし、この決定に付随していた「種別が今後6つ目以上に増えたら小計方式の再検討が必要」という将来リスクは、そもそも小計の精度がほとんど問題にならない（照合対象は合計のみ）という新事実により、実質的に解消された。 (出典: 新實さん、2026-07-22ヒアリングシート回答、hearing.html F3、docs/feedback/hearing/2026-07-22-niimi-hearing-sheet-F.md参照)
出典: brief-9 §8 ケーススタディ / finance.html §8 / docs/decisions.md D25
③ itks16r ラベル・ルックアップ取り違えバグ 移植版フロントエンド
背景: MENUJ1の新規・設変構成入力（ITKS16R）の移植版フロントエンド（itks16r.html）で見つかった実害のあるバグ。
何が起きるか: 2つの入力欄の画面表示ラベルと🔍検索ポップアップの紐付けが入れ替わっていた。id="inp-cdth"（送信キーwscdth、本来は担当班コード）が「指示形態コード」とラベル表示され、指示形態用のポップアップが出るよう誤配線。id="inp-ktsj"（送信キーwsktsj、本来は指示形態コード）は「構成済標準工数」という実在しない架空の項目名でラベル表示され、ポップアップなし。実際の担当者が画面の指示どおり「指示形態コード」欄に指示形態の値を入力すると、実際にはwscdth（担当班コード用のバリデーション）に送られてしまい、ほぼ確実にバリデーションエラーで構成登録全体がブロックされた。
なぜそうなっているか: バックエンド側の検証ロジック自体は最初から正しく、フロントエンドの表示だけが壊れていた（session 27, D19で発見・修正）。
data-lookup属性ではなく、id・送信キー名・数値レンジ（桁数）をDDS仕様と突き合わせるのが正しい調査手順。同種の取り違えは他画面にも潜んでいる可能性があり、機械的な横断チェックが今後の課題として挙がっている。
出典: brief-4 §8.3 / engineering.html §8.3 / docs/decisions.md D19 / feedback-swapped-label-lookup-diagnostic
④ 出荷入力と在庫展開の二段階手動運用（SSBS01→SSBS02） AS/400
背景: MENUS1（出荷管理サブシステム）オプション1「出荷入力」（SSBS01/ITND50R）は、生産完了した受注に対して「実際に出荷した」という事実を記録する画面。
何が起きるか: ITND50Rは在庫演算を一切行わない（JHMPは読み取り専用、BHMPは開かれない）。伝票№の自動採番も行わない。在庫を実際に減らすのは別プログラムSSBS02（出荷データ在庫展開、ITND01R）で、こちらは「出荷が確定した受注」を一括スキャンし、完成品在庫（JHMP）と部品在庫（BHMP）をまとめて減算するバッチ処理である。両者はメニュー上の別オプションであり、SSBS01が自動的にSSBS02を呼ぶ仕組みはない。
なぜそうなっているか: 出荷の「事実の記録」と「在庫数への反映」を意図的に別プログラムへ分離する設計になっている（明文化された理由はないが、伝票処理と在庫バッチを分離する当時のオフコン運用パターンと推測される）。
SSBS02をいつ・どのくらいの頻度で回すかは、新實さんへのヒアリングで判明した: 「SSBS01を実行した後に、SSBS01実行者がSSBS02を実行することになっています。基本的に1人が１日１回実行します。」——つまり日次バッチとして自動起動されているのではなく、SSBS01を実行した本人が続けて手動でSSBS02を実行するという、担当者ベースの運用ルールで1日1回回されている。回し忘れが実際に起きるかどうかについては直接の言及はなかった。 (出典: 新實さん、2026-07-22回答、docs/feedback/analysis/2026-07-22-niimi-remaining-A-questions-reply.md参照、hearing.html A10)
出典: brief-8 §4-5 / shipping.html §4 / §5
⑤ Excel見積とAS/400単価の手動橋渡し（JHMP/PRMPの二重構造） Excel/VBA 解決済み
背景: 見積書はExcel（見積書発行フォルダのVBAブック）で作成され、正式な単価は最終的にAS/400のSSBS04/SSBS05（ITUR01R/ITUR04R）で製品単価マスタPRMPへ登録される。
何が起きるか: 見積書（Excel）で決定した単価を誰がどうやってAS/400へ転記しているか、自動連携が見当たらない——手入力だとすれば対応表もない。さらに受注品番マスタJHMP自体にも決定単価・見積単価・号試単価・変更単価１〜５というほぼ同じ意味のフィールド群が存在し、PRMP（日付別複数行）との関係が未解明だった。片方が正でもう片方はコピー／表示専用なのか、独立して更新される別の値なのか、ソースだけでは確認できなかった。
JUDP＞PRMP＞（旧世代の名残である）JHMPという構造。 (出典: 新實さん、2026-07-22ヒアリングシート回答、hearing.html B1、docs/feedback/hearing/2026-07-22-niimi-hearing-sheet-B.md参照)
なぜそうなっているか: 見積（Excel）と単価登録（AS/400）が別の業務・別のツールとして発展してきた結果、業務側で人手による橋渡しが常態化していた。JHMP/PRMPの二重構造は、単価改定回数の増加に固定フィールド数のJHMPが対応できなくなり、日付別複数行を持てるPRMPへ移行した結果であることが確定した（推測ではなく新實さんの証言による）。
出典: brief-2 §7-1, 未解明事項1・6 / estimate.html §JHMP / hearing.html B1
⑥ 設計№が先・品番登録が後（#CHKSN） AS/400
背景: 素朴には「①品番登録→②構成→③設計№」の順だと思いがちだが、実際のロジックは逆である。
何が起きるか: KSBS01（ITKS01R 受注品番データ登録）の#CHKSNサブルーチンは、入力された品番がSNMP（設計№マスタ）にもJHMP（受注品番マスタ）にも一件も存在しない場合、メッセージ14「設計№が登録されていない品番は処理できません。」で入力そのものをブロックする。つまりまったくの新規品番は、先に設計№を確保してからでないと受注品番登録すら通らない。
なぜそうなっているか: 図面（設計№）が品番の存在証明として扱われているためと推測される。ただし実務上はITKS16R（MENUJ1、受注入力の新規・設変構成入力）が、得意先入力→品番→構成→単品品番→確認、という流れの最後にJHMP・KSMP・BHMP・SNMPへ一括で書き込むため、新規品番の立ち上げは通常この1画面で完結し、新人が個別に順序を意識する場面は少ない。
出典: brief-4 §1 / engineering.html
⑦ 外製受入と経理SHDP入力の二重入力・突合なし 推測を含む
背景: GSBS06（支払明細書印刷、ITSI13R）は、その月に受入登録済みのSFDP明細行を集めて支払明細書（SFDPP3）を作る——これは「外注先ごとの支払うべき金額の元データ」である。
何が起きるか: 経理担当者は別途、経理管理サブシステム（MENUR1）のRSBS01（支払金額データ入力、ITSW10R）で、支払費用データ（SHDP）を仕入先・発生月ごとに手入力する。「GSBS06が作った支払明細書の金額」と「SHDPに経理が入力する請求金額」は別々に管理されており、GSBS側のSFDP金額をSHDPへ自動転記する仕組みは確認できなかった。経理担当者は外注先からの請求書、または支払明細書の金額を見ながらSHDPへ手入力していると考えられる。
なぜそうなっているか: GSBS06（外製受入サブシステムMENUG1配下）とMENUR1（経理管理サブシステム）は別のサブシステムとして独立に発展しており、両者を自動連携させる仕組みが最初から設計されていない（または失われた）。
出典: brief-7 §7-3 / brief-9 §5.4 / outsourcing.html §7 / finance.html §5
⑧ 受注まとめ入力 — 依頼者退職で「使われているかどうか」が分からなくなったツール 属人化の実例
背景: 受注まとめ入力.xlsx（各PCのC:\ITA_PGM配下）は、トヨタ紡織向けに特化して作られたツールである。客先からデータで受け取った注文を、AS/400のグリーン画面へ一件ずつ手入力する代わりにコピー＆ペーストで取り込み、メニュー番号53〜57の5ステップパイプラインで一括してAS/400へ転送する（詳細: daily-rhythm.html A13）。
何が起きるか: このツールには「ログインすると入力内容が消える」という一見バグに見える挙動があり、担当者は入力途中の内容をデスクトップへ一旦退避し、ログイン後に手でC:\ITA_PGMへ戻す、という運用でこれに対処してきた。ヒアリングで判明したのは、これはツール自体のバグではなく、IS_Startup.bat（全PC共通の環境変数・設定配布のためにログイン時に走る全社共通スクリプトで、このツールとは無関係の目的で存在する）が毎回C:\ITA_PGMを配布時の既定状態へ書き戻していたことが原因だった——つまり「デスクトップ退避」という手作業の民間伝承は、本来の原因が別にあることを知らないまま何年も生き続けてきた回避策である。さらにこのツールは失敗時に「社内のコンピュータ管理者に連絡してください」という汎用エラーダイアログを出すが、新實さんによれば実際の連絡経路は「実際には発生していませんが、手段としてはそのままにして新實を呼びに行く、ことになります」——電話・メール・チケットのような記録の残る経路ではなく口頭・対面のみの想定であり、かつこれまで一度も実際に発生したことがないため、この経路自体が検証されたこともない。そして新實さんはヒアリングの最後に、聞かれてもいないのに次を自ら申告した——「たぶんですが、受注まとめ入力は使われていないのではなかと思われます。作成依頼をした社員が現在在籍しておらず、その方法が他の社員へ伝わっていないと思われます。」
なぜそうなっているか: このツールは特定の得意先（トヨタ紡織）向けの、特定の依頼者の要望から生まれた個別対応ツールであり、汎用マニュアルではなく現場担当者自筆のSOP（受注まとめ入力の手順と注意点.xlsx）だけがその使い方を伝えていた。エラー時の連絡経路が口頭・対面のみのまま残ったのは、実際に発生した実例が一度もなく、整備する必要に迫られたことがなかったため。そして依頼した社員本人の退職により、「なぜこのツールが存在するのか」「今も本当に必要か」を知る人がいなくなった——ファイルとSOPは今もPC上に存在し、パイプライン自体は技術的には動く状態のまま残っているが、それを使うべきかどうかの業務知識だけが失われている。
出典: 新實さん、2026-07-21/22ヒアリングシート回答A11、hearing.html A11 / daily-rhythm.html A13 / docs/feedback/analysis/2026-07-22-niimi-remaining-A-questions-reply.md
2. 業務別の特殊ケース早見表
第1部で扱った8件以外にも、各業務ブリーフには数多くの「特殊ケース」が記録されている。ここでは業務別に一覧化する。第1部と重複する項目は一行だけの相互参照にとどめている。
見積
| ケース | どうする | 出典プログラム | 詳細 |
|---|---|---|---|
受注票（社内向け作業指示スリップ）に印字される単価は「決定単価」ではなく「見積単価」（JHMTAN/JHMKAT） | 現状のまま維持・移植（ソースコメントで明言されたレガシー仕様） | ITJM75R AS/400 | estimate.html §7 |
| 型費（カタヒ）は単価と別建てで一貫管理。ただし「機械・治具・設備」費の内訳対応は未確認 | PRMPのK行で個別登録可能。内訳詳細は現場確認待ち | PRMP AS/400 | estimate.html §7 |
無償支給材費（PRHYSK）・自給品費（PRHYJK）の運用ルール（ゼロ計上か評価額か）が不明 | 運用ルールは未解明、現場ヒアリング待ち | PRMP AS/400 | estimate.html §7 |
| JHMP/PRMPの単価二重構造 | → 代表ケーススタディ⑤を参照 | — | ①⑤ |
受注
| ケース | どうする | 出典プログラム | 詳細 |
|---|---|---|---|
| 事前完成処理（JSBS07）は在庫チェックが無く、画面警告のみのオペレーター判断に依存 | 「純粋にオペレーターの判断に委ねる」レガシー仕様のまま維持 | ITJM31R AS/400 | order.html §7 |
| トヨタ紡織管理表（JSBS13）は他得意先とは別フォーマットの得意先固有帳票 | 大口得意先向け個別帳票として個別維持 | ITJM40R AS/400 | order.html §7 |
| 最終受注納期問合せ（JSBS23）は表示欄が6桁しかなく、世紀部分「20」が無条件に切り捨てられ2桁年表示になる | バグとして修正せず、レガシー仕様として維持 | ITJM27R AS/400 | order.html §7 |
| 受注票再発行（JSBS14）は存在チェックのみで、キャンセル済・完了済の受注でも無条件に再発行可能 | 意図的なレガシー挙動として維持 | ITJM74R AS/400 | order.html §7 |
| 中止品番の受注残確認（ITJM35R）はメニューに現れない自動裏方処理で、中止区分を'D'/'Z'に書き分ける | JSBS16C/20Cの編集終了時に自動実行、操作不要 | ITJM35R AS/400 | order.html §7 |
| 受注まとめ入力（トヨタ紡織向けバルク受注取込）の利用実態に属人化の懸念 | → 代表ケーススタディ⑧を参照 | — | ①⑧ |
技術情報
| ケース | どうする | 出典プログラム | 詳細 |
|---|---|---|---|
| KSBS13保管図面データ処理は2024年1月付けの社内文書で作業停止が明記されている | 移植不要（retired — ACS移行済; not ported） | ITRD01R 使用停止 | engineering.html §8.1 |
| KSBS11（試作品製造計画表作成）がなぜ生産管理系ではなくMENUK1にあるのか、配置理由が不明 | 構成データの読み出し・加工が機能の重心のため、と推測（配置理由の公式説明なし） | ITKS32R 推測 | engineering.html §8.2 |
| itks16r ラベル・ルックアップ取り違えバグ | → 代表ケーススタディ③を参照 | — | ①③ |
生産
| ケース | どうする | 出典プログラム | 詳細 |
|---|---|---|---|
| 出来高訂正には在庫のマイナス化を防ぐガードが無く、部品品番がBHMPに無い場合は在庫更新だけ静かにスキップされる | レガシー仕様のまま維持（新人は静かな失敗に注意） | WSBS12 AS/400 | production.html §9 |
| 号口作業指示書強制発行（WSBS36）はソースが失われており、WSBS35を土台に復元方針が立てられている | ITSJ85Rを土台に「未発行状態フィルタを外した強制発行」として再構築 | WSBS35/WSBS36 AS/400 | production.html §9 |
| S/A品（サブアセンブリ品）は専用の完成入力群を持つが、ITGO03Rには重複登録防止ガードが無く二重計上のリスクがある | 既知の脆弱点を認識した上でレガシー仕様のまま維持 | ITGO03R〜06R AS/400 | production.html §9 |
| Dekidaka Excelジョブは出来高報告書の体裁整形を担うと推定されるが内部ロジックは未解析 | AS/400側がステージングしたデータをExcel VBAで整形（詳細未確認） | — Excel/VBA | production.html §9 |
試作・工機
| ケース | どうする | 出典プログラム | 詳細 |
|---|---|---|---|
試作→号口への明示的な「昇格」処理が見当たらない。試作(JHKUGO=1)と号口(JHKUGO=9)は並行した受注体系 | 同一品番に対し号口の受注を新たに起票する運用と推測 | JHMP.JHKUGO 推測 | proto-tooling.html §9.1 |
| 金型の廃棄は「通常保管の金型」と「自動倉庫内の金型」で別プログラムに分かれ、廃棄候補の洗い出しも別途ある | ZSBS14（通常）/ZSBS23（自動倉庫）を使い分け、ZSBS19でチェック→人手判断→実処理の2段構え | ITMD01R/ITMD08R/ITMD05R AS/400 | proto-tooling.html §9.2 |
| 試作品在庫を直接上書きできる強力な画面（ITTS34R）は、必ずZLGPへ変更履歴を残す設計になっている | 4名限定パスワード制限と組み合わせた監査証跡として運用 | ITTS34R AS/400 | proto-tooling.html §9.3 |
外製
| ケース | どうする | 出典プログラム | 詳細 |
|---|---|---|---|
| 分納受入（複数回に分けての納品）が正しく扱えない。2回目の受入入力が1回目の納入数・金額を上書きしてしまう（合算されない） | 分納の実運用有無を現場確認中。現状は上書きされたまま | GSBS04/ITSI04R AS/400 | outsourcing.html §9-1 |
| 単価は改定マスタではなく、発注のたび都度入力する運用。継続的な単価契約マスタはMENUG1範囲内には見当たらない | 都度入力運用を維持（別サブシステムに単価マスタがある可能性は否定できず） | GSBS01 AS/400 | outsourcing.html §9-2 |
| 支給材（無償／有償）はMENUG1（外製管理）の範囲外。得意先(アイシン)向け支給品は別サブシステム(MENUA1/A2)が管理 | 板倉製作所→外注先への支給材管理の所在は未確認（紙・Excelの可能性） | — 推測 | outsourcing.html §9-3 |
| 検収（品質合否判定）の独立ステップ・フィールドがGSBS04には見当たらない | 「受入＝検収」の一体運用と推測、現場確認要 | GSBS04 AS/400 | outsourcing.html §9-4 |
| 支払明細書とSHDP経理入力の二重入力 | → 代表ケーススタディ⑦を参照 | — | ①⑦ |
出荷
| ケース | どうする | 出典プログラム | 詳細 |
|---|---|---|---|
| 指示書の再発行は目的別に4種類（JSBS14/24/25/26）に分かれる。うちITKM18R（まとめ指示の再発行）には最初の1行しかチェックせず後続行の発行済みを見逃す既知の潜在バグがある | 原典通りに移植し、ログ出力のみ追加する方針（DEVIATIONS #69） | ITKM18R AS/400 | shipping.html §7 |
| 分納出荷は打切区分（JUKUED）＝0のまま、同じ受注に複数回の出荷入力ができる | 組付側の分納再引当はBJDPQ4という専用作業キューで管理 | ITSS03R AS/400 | shipping.html §7 |
| 直送（得意先を経由しない出荷）に相当する明示的なフラグ・分岐が見当たらない | 未解明。現場確認要 | — 未解明 | shipping.html §7 |
| 月次締め（累積処理）が完了すると、出荷入力の修正・削除は一切できなくなる。SSBS02実行後の在庫は自動的に戻らない | 締め後の訂正は社外/経理との別ルート調整が必要と推測 | ITND50R AS/400 | shipping.html §7 |
| SSBS01/SSBS02の二段階手動運用 | → 代表ケーススタディ④を参照 | — | ①④ |
経理
| ケース | どうする | 出典プログラム | 詳細 |
|---|---|---|---|
| 関連会社間の相殺（ネッティング）処理に相当する機能・テーブルが調査範囲内に見当たらない | 範囲外、または別サブシステム/手作業の可能性。未解明 | — 未解明 | finance.html §9.1 |
手形金額（SHDP.SHKGTG）は記録されるが、期日・決済状況を追跡する専用テーブルが無い | 銀行側システムか手作業台帳で管理している可能性（未解明） | SHDP AS/400 | finance.html §9.2 |
| 消費税率はITSW99Rが日付に応じて自動判定（0%〜10%の5段階）。インボイス制度対応も2025年1月に改修済み | 継続的に制度対応の改修を受けている | ITSW99R AS/400 | finance.html §9.3 |
| 得意先コード60/61・90/91はコードにハードコードされたペアリングで、片方を指定すると同時に請求対象へ含まれる | 関連会社の一括請求慣行と推測。対象企業名・理由は未確認 | ITS000R/ITS002R 推測 | finance.html §9.4 |
| 支払種別は5グループ（外注/材料/工具/設備/その他）。NMMPコードグループ13で名称管理される | SHDPは非仕入系コストを横断する一元台帳として運用 | SHDP AS/400 | finance.html §9.5 |
| RSBS23支払総括書の小計問題 | → 代表ケーススタディ①を参照 | — | ① |
3. 未解明事項の総覧 — ヒアリングシートに統合
以前このページの第3部には、9本の業務ブリーフに残る未解明事項を80件の表として並べていた。これらの質問は 14. ヒアリングシート に 根本原因ごとに統合・最小化（約130件 → 44項目）し、ベテラン社員の記憶を呼び覚ます形式（【手がかり】＝実際の画面名・数字・止まった日付 → 【質問】 → 【回答欄】 → 【解けると】）に作り直した。以後、板倉製作所の「未解明事項」の唯一の台帳（SSOT）は hearing.html であり、この早見表の第1部・第2部はそのまま「現場で驚くこと」の戦訓集として残す。
| 記号 | 対象（誰に聞くか） | 項目数 | 主なテーマ |
|---|---|---|---|
| A | 新實さん（システム全般・運用・メール・経理システム） | 11 | 隠しメニュー・EDI・自動メール・経理システムのバグ／移行スコープ |
| B | 営業・受注・見積担当 | 8 | 見積単価の橋渡し・JHMP/PRMP二重構造・試作受注の入口・伝票№・分納 |
| C | 生産管理・製造現場・技術情報 | 10 | 在庫引当／在庫展開・かんばん運用・支給材・止まった業務データ・構成登録 |
| D | 工機課・金型・試作担当 | 6 | 握りつぶしバグ・金型の資産／償却・不明コード値・ロット№ |
| E | 外注・仕入担当 | 4 | 受入〜検収〜支払・分納受入・表面処理コード・使用停止フラグ |
| F | 経理担当 | 4 | 入金消込・相殺・手形・得意先ペアリング・請求書ロジック |
| G | 総務・全社 | 5 | 権限モデル（個人か共有か）・アカウント実名・端末台帳・外製管理の要否 |
| 合計 | 48 | → 14. ヒアリングシートで詳細を見る | |