SAPの入門書：「スリーランドスケープ」を5分で理解する
note見てくださりありがとうございます。この文章を紹介している私はこんな人です。
・文系修士卒
・インフラエンジニア出身
・コンサルファーム出身
・ITコンサルタント（現職）
・30代
・港区在住
・年収1400万円程度
・26歳から社会人（1浪1留）
このnoteでは、SAP導入プロジェクトに必須の知識、「スリーランドスケープ」について解説します。
「スリーランドスケープ」はSAPの基本的なシステム構成を指し、上流工程から下流工程に至るまですべてのメンバーが把握しておくべき知識です。
スリーランドスケープとは
「スリーランドスケープ」は、SAP社が推奨しているSAPのシステム構成を指します。「開発機」「検証機」「本番機」の3環境から構成されるため、「スリーランドスケープ」と呼ばれています。
この項目では、それぞれの環境の役割紹介と、スリーランドスケープを使ったSAPシステム導入の進め方、スリーランドスケープのメリットを説明していきます。
開発機
「開発機」は、カスタマイズや、アドオンプログラムの開発、単体テストの実施を行う開発環境で、現場では「DEV(Development environment)」と呼んだりもします。
利用者はSAPシステム開発を担うABAPエンジニアやSAPコンサルタントです。プロジェクトによりけりかもしれませんが、SAPコンサルが要件定義中に実機でさくっと動作確認をしたい場合等は開発機を使うケースが多いです。
なお、実業務のユーザーが開発機を使うことはありません。
開発機での作業が終わり、プログラム単体での動作等の確認が済んだら、作った資源（プログラムやカスタマイズデータ）を検証機に移します。
このように資源を別の環境に移すことを「移送」と呼びます（移送に関しては後ほど詳しく説明します）。
開発機では最低限開発ができればよいので、サーバースペックもそれなりのものが選ばれます。
検証機
検証機はその名の通り動作検証を行う検証環境で、結合テスト、総合テストが実施されます。「テスト機」、「品質保証サーバー」「QAS（ Quality Assurance Server）」とも呼ばれています。
テスト結果に問題がなければそのまま本番機へ移送されますが、もし問題があった場合は、いったん開発機に戻って修正・移送し、再び検証機でテストのステップを踏むことになります。
検証機でそのまま修正してしまうと、開発機と検証機の資源に差が出てしまい、バージョン管理が煩雑になるためです。
また、検証機にはテスト用に本番稼働時相当のマスタ、業務データが投入されるので、実際にシステムを使うユーザー向けのトレーニングもこの環境で行われます。それに伴い、サーバーのスペックやストレージ容量は本番機相当のものになります。
本番機
本番機は実際の業務で使用する本番環境で、「本番サーバー」「PRD（Production environment）」とも呼ばれます。
ここを使うのはユーザーだけで、基本的に開発者がデータを変更することはありません。もし誤ってカスタマイズやデータを書き換えてしまうと、実業務に影響が出てしまうためです。
SAPコンサルの業務では、どうしても実際の業務データを確認したい場合にのみ、参照権限でログインすることはありますが、「なるべく触らないようにする」が原則です。
もし、本番機で不具合が発覚した場合も、いったん検証機で調査を行い、開発機での修正、検証機でのテストを経て本番機に移行するステップを踏みます。
スリーランドスケープのメリット
ここまでご紹介してきたように、スリーランドスケープでは、基本的に開発→検証機→本番機へと一方通行で開発を進めることになります。そのメリットは下記4点が挙げられます。
メリット：
・開発とテストを同時並行できる
・本番機にバグがあるプログラムを反映することを防ぐ
・開発や検証による、実業務への影響を最小限に抑えられる
・ユーザーテスト可能な環境も確保できる
それぞれについて、詳しく説明していきます。
開発とテストを同時並行できる
まず、開発機と検証機が2つに分かれているため、プログラムの開発・テストを同時並行で行うことができます。
もしも開発機と検証機が一つであれば、プログラムAを作成しテストを行っている間、プログラムBの作成には着手できません。しかし、開発機と検証機が分かれていれば、プログラムAのテスト中にプログラムBの開発を行うことが可能です。
特に開発規模が大きくなる大企業では、少しでも開発期間を短くするためにこうしたメリットの影響力は大きいでしょう。
本番機にバグがあるプログラムを反映することを防ぐ
次に、スリーランドスケープでは、開発したプログラムをいったん検証機でテストしてから本番機に移送するため、本番機にそのままバグを渡してしまう可能性を抑えることが可能です。
さらに、開発機から検証機への移送そのものが、異なる環境間で正しくデータを移送できるかのテストを兼ねているため、本番機への移送がうまくできないという事態の発生リスクも低くできます。
開発や検証による、実業務への影響を最小限に抑えられる
もし本番稼働中に不具合が発生した際に、開発・検証・本番稼働を一つのサーバーで行っていた場合は実業務をストップして不具合の検証・修正作業をしなければなりません。
しかし、スリーランドスケープではそれぞれの環境が分かれているので、実業務を止めることは防ぎつつ検証作業ができます。また、検証の際に誤って実データに影響をもたらすこともありません。
ユーザーテスト可能な環境も確保できる
SAP導入プロジェクトは、①以前導入したSAPのバージョンをアップデートするもの、②完全に新規でSAPを導入するもののざっくり2つに分けられます。
①の場合、ユーザーもSAP操作に慣れている場合が多いですが、②の場合はユーザーが実業務でSAPを利用するのに慣れてもらうためのトレーニング環境を用意する必要があります。
本番機をユーザートレーニング環境とした場合、誤ってトレーニング中に重要なマスタやデータを消してしまうリスクがあるかもしれません。しかし、検証機があれば、リスクを減らしつつ本番機相当の環境でのトレーニングが可能です。
こうしてメリットを並べていくと、スリーランドスケープは常に稼働することが求められるERPシステムの品質を担保しつつ、開発・テスト業務を行いやすいように考え出されたシステム構成であることが分かります。
「移送」とは
「移送」とは、異なる環境に資源（カスタマイズや開発オブジェクト）を移すことを指します。プロジェクトによりますが、カスタマイズやプログラミングは開発チームが、移送はインフラチームが行う、というように担当者が分かれている場合が多いです。
移送手順①：移送依頼番号の取得
移送を行う単位は、「移送依頼番号」単位となります。イメージとしては、1移送依頼番号が1つの箱で、その中にカスタマイズや開発したプログラムを入れて、他の環境へと受け渡していくような形です。
プログラムの修正やカスタマイズの変更を行うと、自動的に「移送依頼番号取得画面」がポップアップします。この画面で移送の内容等をテキストで入力すると移送依頼ができあがります。
移送手順②：移送依頼リリース
作業が完了したら、移送依頼のリリースを行います。リリースは移送内容の確定を意味するため、もしある資源をリリースした後に、同じ資源を追加で変更する場合は新しく移送依頼を取得する必要があります。
移送手順③：移送依頼のエクスポート・インポート
移送依頼がリリースされると、移送内容がファイル（データファイル・コントロールファイル）にまとめられ、自動的に元環境からエクスポートされます。そのファイルを、移送先の環境にインポートすることで移送完了となります。
まとめ
このnoteでは、以下の点について説明しました。
・SAPのシステム構成は開発機・検証機・本番機からなる「スリーランドスケープ」が推奨されている
・「スリーランドスケープ」ではそれぞれの環境の用途がかっちり決められており、それを守ることで開発・テスト管理や、バグ修正による実業務への影響が抑えられている
・「移送」は異なる環境に資源（カスタマイズや開発オブジェクト）を移すこと
SAP案件に携わるには、個々のモジュールや機能の理解以外にも、全体のシステム構成や移送の概念の理解が必要です。用語がややとっつき辛いところもありますが、概要の把握にお役立ていただければ幸いです！
今回は以上です。
最後までお読みいただきありがとうございました。
もしnoteがよければスキ！をいただけるとありがたいです！