AS400 / IBM iの保守では、業務担当者への聞き方で調査速度が変わります。「何がエラーですか」だけでは、在庫照会、請求締め、出荷確定、EDIのどこで困っているか分かりません。
この記事では、現場でよく出るメニュー名や運用に合わせて、最初に聞くべき質問を整理します。
在庫照会で聞くこと
- どの商品、どの倉庫、どのロットの在庫か
- 画面上の数量と、実在庫のどちらが正しいと思うか
- 直前に出荷、返品、棚卸、在庫調整があったか
- 引当済み、出荷予定、移動中の数量を含めて見ているか
請求締めで聞くこと
- どの締め日、どの得意先、どの請求単位か
- 締め前か締め後か
- 再締めしてよいか、請求書やPDFは出力済みか
- 売上、返品、赤伝、消費税のどこが合わないか
出荷確定・EDIで聞くこと
- 出荷確定済みか、未確定か
- EDI送信済みか、相手先で受信済みか
- 物が届かない可能性があるか
- 再送すると二重送信にならないか
- テストデータやダミーデータが混ざっていないか
噛み合わなくなるのは、その会社独自の考え方が出てきた時
業務部門と話がかみ合わない場面には、はっきりした型があります。システム開発側は、各社共通の一般的なルールを前提に会話しています。受注があって、出荷して、売上が立って、締めて請求する。この標準の流れを頭に置いて話を進めます。
ところが業務部門は、自分の会社のやり方で話します。そしてその会社独自の考え方が出てきた時に、会話が噛み合わなくなります。開発側は「一般的にはこうですよね」と確認したつもりでいて、業務側は「はい」と答えている。でも業務側が思い浮かべているのは自社のルールなので、実は合意できていません。
怖いのは、噛み合っていないことにその場では誰も気づかないことです。開発側は一般ルールで作り、業務側は自社ルールで検収します。ズレが表に出るのはテストか本番稼働後で、その時には手戻りが大きくなっています。
ルールだけでなく、用語そのものが違うこともある
分かりやすい実例があります。一般的には「粗利」と書きますが、「当社では荒利です」という会社がありました。読みも意味も同じです。それでもその会社では、その表記が正です。
些細に見えますが、システムでは表に出ます。画面のラベル、帳票の見出し、項目名、仕様書。どこかで一般的な表記のまま作ると、そこだけ差し戻しになります。そして直す時には、すでに複数の画面と帳票に散っています。
用語が違うということは、その裏に自社の考え方があるサインでもあります。呼び方が違う項目が出てきたら、計算の仕方や扱いも一般的なものと違わないかを、そこで一度確認しておくと安全です。
自社ルールが出やすいところ
販売管理で会社ごとの差が出やすいのは、だいたい決まった領域です。ここを一般論のまま通過させないでください。
| 領域 | 会社ごとに違うところ |
|---|---|
| 売上計上のタイミング | 出荷した時点か、相手が受け取った時点か |
| 締めのルール | 月末締めか、20日締めか。取引先ごとに違うことも多い |
| 単価の決まり方 | 得意先別、数量別、期間限定など、優先順位の付け方 |
| 在庫の引当 | 受注時に引き当てるか、出荷指示時か。予約在庫の扱い |
| 返品・赤伝 | 在庫を戻すか戻さないか、売上取消か値引きか |
| 消費税の端数 | 切り捨て・四捨五入、明細単位か伝票単位か |
聞き方をひとつ変えるだけで防げる
対策は難しくありません。一般論で確認しないことです。「一般的にはこうですよね」と聞くと、業務側は自社のやり方を一般的だと思っているので「はい」と返ってきます。これでは差が出ません。
- ×「売上は出荷時点で立ちますよね」
- ○「売上はどの時点で立てていますか。出荷時ですか、相手の受領時ですか」
- ×「締めは月末ですよね」
- ○「締めは取引先ごとに違いますか。違う場合はどこで管理していますか」
違いがある前提で、選択肢を出して聞く。この形にすると、自社ルールが自然に出てきます。相手を疑っているわけではなく、会社ごとに違って当たり前だという前提を先に共有するということです。
外部のベンダーを見る時も、この確認をしてくるかどうかが判断材料になります。AS400保守会社・開発会社の選び方にも書いたとおり、一般論だけで話を進める相手は、後で必ず食い違います。
聞き方のコツ
業務担当者は、AS400のジョブ名やファイル名ではなく、在庫照会、請求締め、出荷確定といった業務名で話すことが多いです。保守担当者は、その業務名をジョブ、画面、ファイル、外部連携へ翻訳して調査します。
ヒアリングの基本形は、AS400業務ヒアリングシートにもまとめています。
まとめ
AS400保守で独自性が出るのは、コマンド説明よりも、業務担当者から必要な情報を引き出す力です。在庫照会、請求締め、出荷確定、EDIの質問を型にしておくと、調査と設計が速くなります。
質問を調査条件へ変換する想定例
たとえば「出荷したのに請求へ出ない」という相談では、現象だけを聞いても対象を絞れません。業務担当者の言葉を、検索に使えるキーと締め条件へ変換します。
| 確認点 | 確認内容 | 判断 |
|---|---|---|
| 対象 | 受注番号、出荷番号、得意先、処理日を聞く | 同じ得意先の全件か1伝票だけかを分ける |
| 時点 | 出荷確定時刻と請求締めの基準時刻を聞く | 締め前データか締め後データかを分ける |
| 例外 | 返品、赤伝、保留、手修正の有無を聞く | 通常フローと例外フローを混ぜずに追う |
聞き取り結果は「確認できた事実」「担当者の推測」「依頼したい対応」に分けて記録します。推測を事実として引き継がないことが、調査のやり直しを減らします。聞き取り時刻と回答者の役割も記録します。
比較対象には、同じ得意先・同じ締め日の正常伝票を1件用意します。対象伝票との差を、入力時刻、状態コード、実行ジョブ、連携結果の順に並べると、担当者の記憶に頼らず分岐点を探せます。回答が得られなかった項目は空欄にせず「未確認」とし、確認担当と期限を付けて調査票へ残します。聞き取り後は、業務担当者と調査担当者が対象キーと時点を読み合わせ、別の伝票を調べていないことを確認します。
関連するAS400確認ルート
業務担当者へのヒアリングでは、在庫照会、請求締め、出荷確定のような実際の画面・締め・例外処理を聞くことが重要です。設計前に業務の言葉をそろえると、保守もAI活用も進めやすくなります。
業務担当者への聞き方を変える
AS400の調査では、業務担当者へ「何が困っていますか」と聞くだけでは情報が足りません。どの画面で、どの入力条件で、いつから、誰の作業で、どの帳票やデータに影響したのかを分けて確認します。
- 再現する画面名、メニュー名、処理名を確認する
- 正常だった最後の日時と、異常に気づいた日時を分ける
- 締め処理、出荷、請求、在庫など影響業務を聞く
- 手作業で回避した内容があれば必ず残す
現場で役に立つのは、技術用語よりも業務の流れです。担当者の言葉を処理、データ、帳票、ジョブに置き換えて整理すると、RPGやCLの調査に入りやすくなります。