移行の企画段階で、必ず同じ会議が開かれる。現行のアドオンが四百本あり、全部を移送すると工期と費用が計画に収まらない。だから各部門に一覧を配り、要否を確認してもらう。返ってくる回答は、ほぼ全件が「要」である。 部門から見れば、要らないと答えて後で困るより、要ると答えておくほうが合理的だからである。会議は三巡し、落ちたのは十数本。この会議の設計が間違っている。 要否を聞く相手が違うのではなく、要否を人に聞くという順序が違う。 SAPの移行ガイドは、この順序について明確な立場をとっている。
スコープは、要不要の議論ではなく既定値の計算である
順序を入れ替えると、会議の議題が変わる。使用実績から既定スコープを機械が計算し、その結果に対して人が例外を申し立てる、という順序になる。
SAPはスコープの内外を、判定規則として書き下している。オブジェクトがスコープ内になるのは、明示的にオブジェクト単位でスコープに追加された場合、そのパッケージが明示的にスコープに追加された場合、スコープ内の少なくとも一つのリクエストエントリポイントから使用されている場合、スコープ内の他のオブジェクトから参照されている場合、またはそのオブジェクトタイプに使用データが存在しない場合である。スコープ外になるのは、明示的にオブジェクト単位でスコープから除外された場合、またはいずれのリクエストエントリポイントからも使用されていない場合の二つだけである。
この非対称性が効く。 落ちる条件は二つしかなく、そのうち一つは人の明示的な操作である。つまり 機械が自動で落とせるのは「どの入口からも呼ばれていない」ものだけであり、それ以外はすべて既定で残る。データベーステーブルやデータ要素のように使用データを取れないオブジェクトタイプは、使われていなくても残る。「機械的に切る」と言うとき、実際に機械が切っているのは呼び出し実績ゼロの入口だけである。 ここを誤解したまま「AIで棚卸しする」といった話に流れると、結局は人が全件を見る作業に戻る。
一年より短い使用実績は、使ってはいけない
移行の企画は、たいてい時間がない。使用実績の収集も「三か月分でとりあえず回そう」となりやすい。SAPはこの点に理由を書いている。
ガイドは、「Ideally, the usage data you add to your custom code migration project should cover at least one year of usage information, so that also usage data of quarter and year ending functionality is considered.」（プロジェクトに追加する使用データは、理想的には最低一年分の使用情報をカバーすべきである。四半期末および年度末の機能の使用データも考慮されるようにするためである）と述べる。四半期決算と年度決算でしか動かないプログラムを取りこぼさないため、というのが一年の根拠である。
経理と財務の領域では、この指摘の重みが他の領域と違う。アドオンの多くが、期末にしか動かない。 決算整理の一括仕訳、税務用の集計帳票、年一回の固定資産の実地棚卸リスト、償却資産申告の補助資料。三か月分の使用実績で切れば、これらは全部「未使用」に見える。そして削除トランスポートに載る。本番稼働の初回決算で、無いことに気づく。
裏返せば、使用実績の収集は移行の企画より先に始めなければならない。 SUSGでの集約をまだ有効にしていないなら、ガイドは 本番システムでトランザクションSUSGを起動し、Activateを選んで使用データの集約を有効化するよう 求めている。移行の意思決定が固まってから収集を始めると、一年分が溜まるまでスコープが切れない。「まだ移行を決めていないから」を理由に収集を止めている会社が、一年後に選択肢を失う。 これは投資でも要員でもなく、設定を一つ入れるかどうかの話である。
中央チェックシステムの選択が、捨てられるかどうかを決める
もう一つ、企画段階で見落とされる分岐がある。カスタムコード分析をどの環境で回すかで、できることが変わる。
SAPは三つの選択肢を挙げる。中央チェックシステムがSAP S/4HANA 1809以降であればCustom Code Migrationアプリを使え、SAP BTP ABAP environmentでも同アプリを使える。問題は二つ目の選択肢である。 中央チェックシステムをSAP NetWeaver Application Server for ABAP 7.52に置く場合について、ガイドは 「With this approach you can neither scope your custom code based on usage data nor filter the analysis results by scope or quick fix availability.」（このアプローチでは、使用データに基づくカスタムコードのスコーピングも、スコープやクイックフィックスの有無による分析結果の絞り込みも行えない）と明記している。
つまり、中央チェックシステムを既存のNetWeaver環境で済ませる判断をした時点で、使用実績で捨てるという方法そのものが選べなくなる。 これはインフラの都合として決められがちな論点で、経理側の会議に上がってこない。しかし結果として、移行スコープが四百本のまま固定される。 費用への跳ね返りはそのまま工数に出る。インフラの一行の判断が、移行費用の桁を変える。
なお、SAP Solution Manager経由で使用データを取り込む道もあるが、制約がある。ガイドは 「When loading usage data collected in SAP Solution Manager, the usage counter will not display usage numbers (0 usages). Usage counter data is not supported by the APIs of SAP Solution Manager.」（SAP Solution Managerで収集した使用データをロードする場合、使用回数カウンタは使用回数を表示しない（0 usages）。使用回数カウンタのデータはSAP Solution ManagerのAPIでサポートされていない）としている。使用の有無でスコープは切れるが、実行回数の多寡で優先順位をつけることはできなくなる。
ちなみに、SAPのガイドがカウンタとして示しているのは、リクエストエントリポイント配下のプロシージャごとの Number Usages（使用回数）である。利用者数はこの画面に出てこない。 「実行回数と利用者数で切る」という設計を置くなら、利用者数は別の経路で取る必要がある。ここを企画書に書いてから気づくと、判定基準の作り直しになる。
会議に上げるのは、二種類だけである
既定スコープが計算されれば、人が判断すべき対象は自動的に絞られる。SAPはガイドの中で、スコープを変更する必要が生じる場面を例示している。
第一の場面は、Business Suiteシステムで使用されているトランザクションを、S/4HANAでは業務プロセスを変えるためもう使わない場合である。この場合はリクエストエントリポイントでフィルタし、そのエントリポイントをスコープから外す。実績はあるが、業務ごとやめる。 これは使用実績では絶対に落ちない。落とせるのは、業務をどう変えるかを決めた人だけである。
第二の場面は、新しい機能が開発中で、まだ本番システムで使われていない場合である。ガイドは 「no usage data has been collected for this application and it has not been added to your scope automatically」（このアプリケーションについては使用データが収集されておらず、自動ではスコープに追加されていない）とし、開発物を含むパッケージをパッケージ単位でスコープに追加するよう説明する。実績はないが、これから使う。 これも機械では拾えない。
第三の場面は性質が違う。ガイドは、複雑なオブジェクトほど変更頻度も高い傾向があるとしたうえで、Custom Code Migrationアプリの複雑度分析でパッケージの Halstead Difficulty を表示し、再設計により単純化すべきかを判断できるとする。これは捨てるかどうかではなく、残すものを移送するか作り直すかの判断である。 スコープの議論と混ぜると会議が長くなる。分けて置く。
機械的に切ることの限界を、先に書いておく
この方法には、明示しておくべき穴が二つある。穴を伏せたまま導入すると、稼働直後に信用を失う。
第一に、静的解析は動的な呼び出しを拾わない。 SAPはATCについて 「ATC is not able to find all potential issues (for example, dynamic coding is not covered by static code checks).」（ATCはすべての潜在的な問題を検出できるわけではない。たとえば動的コーディングは静的コードチェックの対象外である）と注記している。既定スコープが「静的に参照されるオブジェクト」を含める設計になっている以上、プログラム名を変数で組み立てて呼ぶような実装は、参照関係として捕捉されない。 使用実績で拾えていれば残るが、期末にしか動かない動的呼び出しは、一年分の使用実績を取っていなければ二重に漏れる。
第二に、削除は取り消しの安い作業ではない。 削除はシステムコンバージョンの中で削除トランスポートとして流れる。移行後に「やはり必要だった」と分かったとき、戻すのは旧環境からのコードの復元と再テストになる。 旧環境をどこまで、いつまで保持するかという判断と一体で決める必要がある（SAP移行で旧システムの過去データをどうするか｜移行年数と旧環境の維持費）。
この二つを踏まえると、実務上の落としどころは明快になる。削除トランスポートの対象一覧は作るが、対象のうち期末・年度末にしか動かない可能性のある領域だけは、使用実績とは別に人が一度見る。 対象領域は限定できる。決算整理、税務、開示、固定資産、そして年一回の法定帳票である。四百本を全件レビューするのと、そのうち数十本を領域指定でレビューするのとでは、会議の回数が違う。
決めるのは三つ
第一に、使用実績の収集を、移行の意思決定より先に始める。 SAPは本番システムでABAP Call Monitor（SCMON）を使用し、トランザクションSUSGで最低一年の使用データを収集することを推奨し、プロジェクトに追加する使用データは理想的には最低一年分をカバーすべきであるとしている。理由として挙げられているのは、四半期末および年度末の機能の使用データも考慮されるようにするためである。経理領域のアドオンは期末にしか動かないものが多く、短期間の実績で切ると体系的に取りこぼす。 収集の有効化はSUSGでActivateを選ぶだけの作業であり、移行を決めていない段階でも止める理由がない。
第二に、中央チェックシステムの構成を、経理側の論点として扱う。 SAPは、中央チェックシステムをSAP NetWeaver Application Server for ABAP 7.52に置く構成では、使用データに基づくスコーピングも、スコープやクイックフィックスの有無による絞り込みもできないと明記している。この一点で、捨てるという選択肢の有無が決まる。 SAP Solution Manager経由で使用データを取り込む場合も、使用回数カウンタは0 usagesと表示されるため、実行回数による優先順位づけができない。インフラ費用の比較だけで構成を決めると、移送工数の側で桁違いに支払うことになる。
第三に、会議に上げる対象を、二つの型に限定する。 既定スコープは、使用済みオブジェクト、それらから静的に参照されるオブジェクト、使用データが存在しないオブジェクトタイプを含む形で自動計算される。スコープから外れるのは、明示的に除外したものと、いずれのリクエストエントリポイントからも使用されていないものだけである。したがって人が判断すべきなのは、実績はあるが業務ごとやめるもの（リクエストエントリポイント単位で除外する）と、実績はないがこれから使う開発中の機能（パッケージ単位で追加する）の二つに限られる。 そのうえで、静的コードチェックが動的コーディングを対象外としていること、削除がシステムコンバージョン中の削除トランスポートとして流れることを踏まえ、決算整理・税務・開示・固定資産・法定帳票の領域に該当する削除候補だけは人が一度確認する。残すものを移送するか作り直すかは、複雑度分析（Halstead Difficulty）を使う別の議論として分けて置く（SAPアドオン（追加開発）をどこまで作るか｜Fit-to-Standardの判断基準）。
