SAP BTPエンジニアのフリーランスがつまずきやすい点と対策

フリーランスのSAP BTPエンジニアがつまずきやすいのは、請負で何をもって完成とするかがあいまいなこと、つなぐ先の担当者との段取り待ちで作業が止まること、標準で足りる部分まで作り込むこと、サービスの利用料や検証の環境の費用の扱いです。どれも、BTPの仕事が「SAPと他のシステムの間」に立ち、自分だけでは決められない部分を多く含むことから起きます。

対策の基本は、つまずきの種を契約と参画初期の取り決めで小さくしておき、現場では判断の理由と依頼を記録に残すことです。この記事では、契約・現場・技術・お金の順に、BTPならではの場面と対策を整理します。独立の手順はSAP BTPエンジニアがフリーランスになるにはで扱っているので、ここでは「実際に起きやすい場面」に絞ります。

契約でのつまずき

請負の「完成」の範囲があいまい

BTPの案件には、月単位の準委任のほか、アプリや連携フローの納品を約束する請負の形もあります。請負で「連携の構築」とだけ書かれていると、相手先のシステムの改修が遅れて結合テストができないときや、稼働後に相手先の仕様が変わったときに、どこまでが自分の責任かで揉めやすくなります。

対策：請負では、完成の基準（どのテストを、どの環境で通せば完成か）と、稼働後の不具合への対応の期間と範囲を、署名の前に確かめます。請負で負う責任の考え方は契約不適合責任の記事をご覧ください。

「BTPの開発」の範囲が広がっていく

契約書には拡張アプリの開発とだけ書かれ、現場ではアカウントの設定、権限のロールの設計、Cloud Connectorの設定、利用部門への説明まで期待されていた、という食い違いはよく起きます。BTPは設定と開発の境目があいまいなため、引き受けた範囲が少しずつ広がりやすい分野です。

対策：参画前に、自分が担う作業（開発、連携フロー、権限の設定など）と、担わない作業（Basisの担当が持つ接続の設定、つなぐ先のシステムの改修など）を言葉で確かめておきます。範囲の外の依頼が来たときの扱いは作業範囲が広がったときの契約の扱いで整理しています。

指揮命令の形が社員と変わらなくなる

発注側の社員の下に置かれ、作業の手順や勤務時間まで細かく指示される状態が続くと、準委任の契約と実態がずれてきます。考え方は偽装請負の記事で解説しています。

現場でのつまずき

つなぐ先の担当者との段取り待ちで止まる

連携の仕事は、S/4HANAの担当、相手先のSaaSの担当、ネットワークや基盤の担当がそろって初めてテストができます。自分の作業は終わっているのに、接続の許可やテストデータの用意を待つ時間が長くなり、遅れの理由を問われる立場になりがちです。

対策：参画の初期に、つなぐ先ごとの窓口、接続の申請の手順、テストの日程を一枚に書き出し、発注側の窓口と確かめます。依頼したことと回答の日付を記録に残しておくと、遅れの理由を説明しやすくなります。進め方はSAP BTPエンジニアの参画初月にやることで整理しています。

本番の権限とデータの扱いを確かめずに動く

本番の環境や業務データに触れる権限は、案件ごとに決まりが違います。検証のつもりで本番に近いデータを個人の端末に置いた、渡された権限の範囲を超えて設定を変えた、といった動きは、悪意がなくても信頼を大きく損ねます。

対策：権限の範囲、データを置いてよい場所、作業の承認の流れを、最初の週に確かめます。分からないときは、作業の前に聞くのが基本です。

業務部門の言葉が分からず、要件を取り違える

Web・クラウドから来たエンジニアに多いのが、受注、出荷、請求、仕訳といった業務の言葉が分からず、要件の意図を取り違えることです。画面や連携は動いても、業務で使えない形になってしまいます。

対策：要件の打ち合わせのあとに、自分の言葉で「何を、誰が、どのデータで」をまとめて返し、取り違えがないかを確かめます。

技術でのつまずき

標準で足りる部分まで作り込む

Fiori elementsの標準の型や、SAPが用意しているAPIで足りる部分を、自分で作り込んでしまうことがあります。作り込むほど、SAPの更新に合わせた保守の負担が増え、引き継いだ担当者が困ります。

対策：作り込む前に、標準で足りない理由を一言で説明できるかを確かめます。説明できない場合は、標準で済ませる案も並べて相談します。

エラー処理と運用を後回しにする

正常に流れる連携やアプリは作れても、相手先が止まったとき、データが壊れていたときにどう動くかを決めていないと、本番で問い合わせが増えます。

対策：設計の段階で、エラーの気づき方（監視と通知）、再処理の手順、問い合わせの窓口を決め、運用の担当に渡せる形で書いておきます。

古いサービス名や古い環境の前提で話す

BTPのサービスは、名前や束ね方、提供の環境が変わり続けています。古い名前や古い環境の前提のまま設計を話すと、現場との認識がずれることがあります。動向はSAP BTPエンジニアの将来性の記事にまとめています。

対策：参画先で使っている環境とサービスの名前を最初に確かめ、資料ではその名前に合わせます。

AIの開発支援をルールを確かめずに使う

AIによるコードの生成や設計の支援は便利ですが、取引先のソースコードや業務データを外部のサービスに入力してよいかは、契約と取引先のルール次第です。考え方は業務での生成AIの利用に関する契約条項をご覧ください。

お金でのつまずき

検証の環境や利用料の負担があいまい

BTPのサービスは、使った分だけ費用がかかるものがあります。個人の検証の環境で、課金の設定を確かめずにサービスを動かし続けてしまうことや、案件で使う環境の利用料をどちらが負担するかが決まっていないことがあります。

対策：案件で使う環境は、発注側が用意して費用も持つのか、自分で用意するのかを契約前に確かめます。個人の検証の環境では、課金の設定と利用の上限を自分で確かめておきます。

本番の切り替えの稼働が精算されない

本番の切り替えや障害の対応では、夜間や休日の作業が発生することがあります。月の稼働の上限を超えた分の扱いを決めていないと、働いた分が報酬に反映されないことがあります。考え方は精算幅の記事で解説しています。

移行や検証の区切りで契約が終わる

移行の案件は期限に向かって進み、検証の案件は方針の変更で止まることがあります。フリーランス法では、6か月以上続く業務委託を解除したり更新しなかったりする場合、発注側は少なくとも30日前までに予告することになっています（2026年10月時点、公正取引委員会の案内による）。契約期間の決め方は契約期間の記事をご覧ください。

対策：参画中から、案件の終わりの見通しを窓口に確かめ、次の案件の相談を早めに始めます。

よくある質問

相手先のシステムの遅れで、自分の作業が終わりません。どうすればよいですか？

待っている内容と依頼した日付を記録に残し、窓口に早めに共有してください。準委任の契約であれば、作業を約束どおりに行っていることを説明できます。請負の場合は、完成の時期に影響が出ることを早く伝え、時期の見直しを相談することが大切です。

標準の機能を使うべきか、作り込むべきか、発注側と意見が分かれました。

両方の案を、費用、保守の負担、SAPの更新への影響で並べて示すと判断してもらいやすくなります。最後に決めるのは発注側であることを踏まえ、自分の意見と理由を記録に残しておきましょう。

参画してから、聞いていた分野と違う作業が多いと気づきました。

まずは、どの作業が想定と違うかを具体的に書き出し、窓口や紹介を受けたエージェントに伝えてください。契約で決めた業務の範囲と照らし合わせ、範囲を見直すのか、追加の作業として扱うのかを相談することが出発点です。