SAP Basisエンジニアの参画初月にやること｜現場で信頼される進め方

SAP Basisエンジニアの参画初月は、環境の構成と承認の流れをつかみ、本番に触れる前に手順と連絡経路を確かめ、月末に「運用の見立て」と「改善の案」を出すところまでを目標にします。最初の1か月で成果として求められるのは、大きな作業を終えることより、このBasisに本番を任せて大丈夫だと発注側が判断できる材料を示すことです。

参画前の契約・環境の準備は参画が決まってから開始日までにやること、職種を問わない最初の1週間の進め方は参画初日から最初の1週間でやることで解説しています。この記事では、Basisならではの初月の動き方に絞ります。

初月のゴールを3つに分ける

この3つを、1週目、2週目、3〜4週目の順に重心を移しながら進めます。

1週目：環境と決まりを読む

Basisとして最初に読む資料

Basisは、本番に触れる前に読んでおくべき資料が多い職種です。次の順で目を通すと、全体像をつかみやすくなります。

1. システムの構成図と環境の一覧：開発・検証・本番の構成、製品の版、データベース、OS、基盤、冗長化の有無
2. 作業の申請・承認・記録の決まり：誰の承認で本番に触れてよいか、記録をどこに残すか、特権IDの申請の流れ
3. 監視の項目とアラートの設定：何を見ていて、何を見ていないか
4. バックアップと復旧の手順：取得の頻度、保管の場所、復旧の訓練をいつしたか
5. 直近の変更の履歴と障害の記録：最近何を変え、何が起きたか。古い課題が放置されていないか
6. 移送のルールと予定表：反映の順番の決まり、並行して動くプロジェクトの有無
7. 事業者や保守会社との責任の分担：どこまでが相手の責任か（見られる範囲で）

読みながら、「決まりではこうなっているが、実態は違いそう」という点を書き留めておきます。この段階では結論を出さず、仮説としてためておきます。

関係者と短く話す

資料だけでは分からないのが、人の見方です。発注側の基盤の責任者、社員の基盤担当や窓口、業務側の代表、事業者や保守会社の窓口と、それぞれ短い時間で話す機会をもらいます。聞くことは次の3つに絞ると、相手の負担になりません。

• このシステムで一番心配していること（性能、障害、古い構成など）
• 止められる時間の決まり方と、避けてほしい時期
• Basisに期待すること

同じ質問を全員にすると、関係者ごとの見方の違いがはっきりします。業務側が心配している遅さと、基盤側が気にしている構成の古さが食い違うこともあり、その違いが運用の課題の手がかりになります。

本番に触れる前に確かめること

1週目は、本番環境に対して自分で変更を加えないのが基本です。参照の権限で監視とログを見ながら、変更の権限が付く前に、承認の流れと記録の残し方、障害時に誰へどの手段で何分以内に連絡するかを窓口と確かめておきます。

2週目：手順と連絡経路を自分のものにする

定型作業を現場の手順で一度通す

2週目には、移送の反映、ジョブの確認、定期的な点検といった定型作業を、現場の手順書どおりに一度自分で通します。いきなり形を変えず、まずは前のやり方を踏襲し、手順書に抜けている確認項目や、記録の残し方のあいまいな点だけを書き留めます。

報告の形を責任者と合わせる

発注側の基盤の責任者に、作業の前後の報告をどこに、どの粒度で出すかを確かめ、初回の報告を出します。Basisの報告は、作業の記録より「判断が要ること」と「見えてきた危うさ」を先に書くと読まれやすくなります。リモート中心の案件での報告の工夫はSAP Basisエンジニアのリモートの記事でも触れています。

承認の流れと連絡経路を一枚にまとめる

誰の承認で本番に触れてよいか、特権IDの申請はどこに出すか、障害時に誰へ連絡するか、停止枠は誰が業務側と決めるかを一枚にまとめ、窓口と確かめます。ここがあいまいなままだと、2か月目以降に判断待ちが積み上がるか、承認を飛ばして信頼を失うかのどちらかが起きます。

3〜4週目：運用の見立てを出し、改善の案に合意を取る

運用の見立てをまとめる

1〜2週目で集めた情報をもとに、運用の見立てをまとめます。中身は次のとおりです。

• 環境の一覧と、自分の担当と他の担当（事業者、保守会社、権限の担当など）の境目
• 監視・手順書・バックアップで見つけた抜けや古い点
• 性能や容量で、このまま進んだ場合に起きそうなこと
• 近い将来の更新や移行に向けて、先に片づけたい前提条件

改善の案は選択肢で出す

改善が必要な場合、一つの案だけを出すと、「前の担当のやり方を否定された」と受け取られやすくなります。たとえば監視の項目を足す場合でも、「すぐ足せるもの」「停止を伴うもの」「事業者との調整が要るもの」のように分け、それぞれの影響と手間を示したうえで、責任者に選んでもらう形にします。Basisとして推す案があれば、その理由を添えます。

次の1〜2か月の作業計画を引く

合意した内容をもとに、次の1〜2か月の作業計画（定期作業、改善の作業、控えている更新の準備）を引き、関係者に共有します。ここまでできれば、初月の役割は十分に果たせています。

案件の型によって初月の重心は変わる

同じBasisの案件でも、型によって初月に力を入れる場所が違います。

運用・保守の案件

日々の監視と定型作業が中心の案件では、現場の手順を正確に回せることを先に示します。改善の提案は、手順を一通り回して現場の事情が分かってからにします。障害が起きたときの切り分けの順序と連絡経路を、参画の初期に確かめておくことが欠かせません。

移行・バージョンアップの案件

リハーサルや本番が控えている案件では、環境の把握と並行して、移行の方式、リハーサルの計画、停止枠の決まり方、切り戻しの判断をする人を早めに確かめます。途中から参画する場合は、前任者が作った手順書と見積もりの根拠を読み、根拠が分からない部分を一覧にして窓口に確かめることが初月の中心になります。移行プロジェクト全体の初月の動きはS/4HANA移行の参画初月にやることで解説しています。

新規構築の案件

まだ環境がない段階で入る場合は、現状を把握するより、サイジングの前提、冗長化の要件、基盤ベンダーとの責任の分担を関係者と言葉で合わせることが初月の中心になります。月末には、構成の骨子と、決めきれていない論点の一覧を出せることを目指します。

事業者が運用を担う契約の案件

運用の一部をSAPやクラウド事業者が担う契約では、契約の範囲を読み、どこまでが事業者の責任で、どこからが自社の責任かを確かめることから始めます。事業者への依頼の出し方と、障害時に事業者へ渡す情報のそろえ方をつかむことが、初月の大きな仕事です。

初月に避けたい動き

範囲外の依頼が増えてきたときの扱いは作業範囲が広がったときの記事、Basisがつまずきやすい場面はSAP Basisエンジニアのフリーランスがつまずきやすい点と対策で整理しています。

1か月の終わりに振り返ること

1か月が過ぎたら、次の点を自分で振り返ります。

• 環境の一覧と、自分の担当の境目を責任者と共有できているか
• 承認の流れと障害時の連絡経路が、関係者と共有できているか
• 本番に触れた作業に、すべて申請と記録が残っているか
• 運用の見立てと改善の案を、責任者に伝えられたか
• 契約で決めた業務の範囲と、実際に担っている仕事がずれていないか
• 夜間・休日の作業を含め、稼働時間の記録が残っているか

ずれている点があれば、2か月目の早い段階で窓口と話しておきます。

よくある質問

前任のBasisからの引き継ぎがほとんどありません。何から始めればよいですか？

システムの構成図、変更の履歴、障害の記録から読み始め、環境の一覧と、分かっていないことの一覧を自分で作るのが近道です。そのうえで、発注側の基盤の責任者と事業者の窓口に、今一番心配していることを聞いてください。引き継ぎの資料がない状態そのものも、運用の見立ての一部として報告に含めておくとよいでしょう。引き継ぎの進め方は契約終了時の引き継ぎの記事も参考になります。

参画初月に本番の障害が起きたら、どうすればよいですか？

まず、確かめた連絡経路に沿って関係者へ知らせ、どの層の疑いが強いかを早めに共有します。自分で解決しきろうとせず、事業者や保守会社の担当の部分は早く相手に渡します。対応の経緯と判断は記録に残し、落ち着いてから見立てと再発防止の案をまとめると、初月の評価にもつながります。

1か月たっても環境の全体像がつかめません。どうすればよいですか？

システムの台数が多い案件や、事業者と責任が分かれている案件では、1か月で全体をつかみきれないこともあります。その場合は、分かっていることと分かっていないことを分けて報告し、残りをいつまでに確かめるかの予定を示してください。分からない点を隠したまま見立てを出すより、範囲を区切って示すほうが信頼されます。