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

SAP BTPエンジニアの参画初月は、環境と権限の構成、つなぐ先の担当者、既存の拡張や連携の作りをつかみ、小さな変更を一つ、現場の手順どおりに本番まで通すことを目標にすると進めやすくなります。そのうえで月末に、見つけた課題と次の1〜2か月の進め方を窓口と共有し、合意を取ります。

BTPの仕事は、SAPと他のシステムの間に立つため、自分の作業だけでは進まない部分が多くあります。初月に段取りの相手と手順をつかんでおくと、その後の遅れを防げます。この記事では、週ごとの進め方、案件の型による重心の違い、避けたい動き、月末の振り返りを整理します。参画前の準備や最初の1週間の一般的な動き方は参画が決まってから開始日までにやることと参画初日から最初の1週間でやることで扱っているので、ここではBTPならではの点に絞ります。

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

大きな設計の見直しは、初月に結論を出すものではありません。まず現場の手順で一度通し、そのうえで見えた課題を整理するほうが、提案の説得力が増します。

1週目：環境と権限、既存の作りを知る

最初に確かめること

• アカウントの構成：開発・検証・本番の環境の分け方と、それぞれで使っているサービス
• 自分の権限：どの環境で、何を変えてよいか。本番に触れる権限があるか
• データの扱い：業務データを置いてよい場所、個人の端末で扱ってよい範囲
• デプロイと承認の流れ：誰の承認で、どの手順で本番に出すか
• AIの開発支援の利用ルール：取引先のコードやデータを入力してよいか

権限やデータの扱いが分からないまま動くのは、BTPの案件で信頼を落としやすい動きの一つです。分からない点は、作業の前に聞くのが基本です。

既存の作りを読む

動いている拡張アプリ、連携フロー、ワークフローを一覧にし、それぞれが何と何をつなぎ、誰が使っているかをつかみます。設計書が古い、またはない場合は、実際の設定やソースコードから読み取った内容をメモに残します。このメモは、月末の振り返りの材料にもなります。

2週目：つなぐ先の担当者と段取りを組む

窓口の一覧を作る

S/4HANAの担当、相手先のSaaSや社内システムの担当、Basisや基盤の担当、業務部門の窓口を一覧にします。接続の申請、テストデータの用意、テストの日程の調整を、誰に、どの手段で頼めばよいかもあわせて書きます。

小さな変更に取りかかる

窓口から任された小さな改修や連携の修正に取りかかります。ここで大切なのは、変更の中身より、現場の決まりどおりにソース管理、レビュー、テスト、承認を通すことです。手順のどこで時間がかかるかが分かると、その後の見積もりが正確になります。

3〜4週目：成果を本番に通し、課題を整理する

小さな成果を本番まで通す

2週目に取りかかった変更を、現場の手順どおりに本番まで出します。本番に出したあとの確かめ方（監視の画面、ログ、エラーの通知）も、このときに一度見ておきます。

気づいた課題を整理する

既存の作りを読み、手順を一度通すと、課題が見えてきます。たとえば次のようなものです。

• 標準の機能で足りるのに作り込まれている部分
• エラー時の再処理の手順が決まっていない連携
• 古い名前のサービスや、終了の予定がある環境の上で動く仕組み
• 権限のロールが広すぎる、または整理されていない部分

課題は、すぐ直すべきもの、計画して直すもの、様子を見るものに分けて並べます。

次の1〜2か月の進め方を出す

課題の整理をもとに、次の1〜2か月で取り組むことと、その順番の案を窓口に示します。見直しの案は一つに絞らず、費用や保守の負担の違う選択肢として出すと、発注側が判断しやすくなります。

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

移行の案件

旧来の連携基盤や古い環境からの移行では、初月は現状の棚卸しが中心になります。動いている連携やアプリを一覧にし、使われていないものを見つけ、そのまま移すもの、作り直すもの、廃止するものに分ける材料を集めます。

拡張開発の案件

CAPやFioriで拡張を作る案件では、開発の作法と標準をつかむことが中心です。ソース管理のルール、テストの書き方、デプロイの手順を早く覚え、既存のコードの書き方に合わせます。

連携の案件

Integration Suiteで連携を作る案件では、つなぐ先との段取りが初月の重心です。接続の申請やテストの日程は時間がかかるため、早めに動き始めることが大切です。

AIの組み込み・検証の案件

AIの案件では、どのデータをAIに渡してよいか、結果を誰が確かめるかを初月のうちに窓口と確かめます。検証で終わるのか、本番の開発に進む見込みがあるのかも、このときに把握しておきます。

初月に避けたい動き

• 権限やデータの扱いを確かめずに作業する：悪意がなくても、信頼を大きく損ねます
• 既存の作りを早く否定する：作られた理由を聞く前に作り直しを提案すると、前任者や社員の反発を招きます
• 標準で足りる部分を作り込み始める：初月は現場の標準に合わせることを優先します
• 段取り待ちを黙って抱える：待っている内容と依頼した日付を記録し、早めに共有します
• 契約の範囲の外の作業を黙って引き受ける：範囲を超える依頼は、まず窓口と扱いを確かめます。考え方は作業範囲が広がったときの契約の扱いをご覧ください

参画中によくあるつまずきはSAP BTPエンジニアのフリーランスがつまずきやすい点と対策で整理しています。

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

月末には、次の点を自分で振り返り、窓口との会話の材料にします。

1. 環境・権限・手順のメモは、次に入る人が読んでも分かる形になっているか
2. つなぐ先の担当者に、自分から依頼を出せる関係ができているか
3. 小さな成果を本番まで通し、その記録を残せたか
4. 見つけた課題と次の進め方を、窓口と共有して合意を取れたか
5. 契約で決めた業務の範囲と、実際に頼まれている作業がずれていないか

5でずれが見えた場合は、早めに窓口や紹介を受けたエージェントに伝えることが大切です。リモート中心の現場での進め方はSAP BTPエンジニアのリモート案件の記事も参考になります。

よくある質問

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

まず、動いている拡張と連携を一覧にし、それぞれの設定やソースコードから何と何をつないでいるかを読み取ります。分からない点は、つなぐ先の担当者や業務部門に聞いて埋めていきます。読み取った内容をメモに残すと、次の引き継ぎにも使えます。引き継ぎの考え方は契約終了時の引き継ぎの進め方も参考になります。

初月から大きな設計の判断を求められたら、どうすればよいですか？

判断の材料がそろっていない場合は、何が分かれば決められるかと、それを集める期間を示して相談するのが現実的です。急ぎの場合は、暫定の案と、あとで見直す前提を明記して出すと、判断の理由が記録に残ります。

リモートの現場で、関係者との距離が縮まりません。

定例の場だけでなく、作業の途中で短い相談や進み具合の共有を文章で出すと、関わりが増えます。判断の理由や依頼の内容を文章で残しておくことは、リモートの現場で信頼を得る基本です。