Salesforceの案件|事業者側と受託側の責任分界の引き方

📘 この記事でわかること
- クラウドサービスの責任が事業者と利用者で分担される考え方と、参画前に確かめておきたい確認事項の全体像
- 権限やアカウントをどこまで引き受けるかの線引きと、共有IDを渡されたときに使える断り方の材料
- 手元に残すものと利用終了時の条件を入口で確かめる進め方と、見えにくい委託の階層・保存先を知る視点
Salesforceの案件で任されるのは、画面や項目を組み立てる作業だけではありません。権限をどこまで渡すか、障害が起きたときにどちらが対応するか、契約が終わったあとにデータをどう扱うかという境界は、曖昧なまま渡される場合があります。境界の位置を知らずに進めると、抱え込む範囲がじわじわ広がっていきます。この記事では、クラウドサービスの安全利用に関する公的な手引きをもとに、事業者側と自分側の責任をどこで分け、参画前に何を確かめておくとよいかを整理します。
▶ あわせて読みたい
1. SaaSの案件で詰まるのは、作り込みより責任の線
事業者が担う範囲と、自分が担う範囲のあいだにある空白
SaaS上の開発案件で手が止まるのは、複雑な画面を組み立てるときよりも、責任の置き場所が見えなくなったときです。独立行政法人情報処理推進機構が公開した中小企業向けの手引きは、クラウドサービスのセキュリティについて、サービス事業者と利用者が役割・責任を分担し、対策を実施することで維持・向上すると整理しています1。事業者が担う範囲と、利用者が担う範囲は、最初から分かれているという前提が置かれているということです。
参画したばかりの案件では、この分担を意識する余裕が生まれにくいものです。画面の動きや項目の調整に集中しているうちに、権限の設計やデータの扱いといった、本来は利用者側全体で担う役割まで、なんとなく引き受けてしまう場面が出てきます。事業者側の対策で守られている部分と、利用者側で埋める部分の境目を先に知っておくと、抱え込む範囲を自分で選べるようになります。
画面の見た目を整える経験よりも、その画面がどの権限で誰に開かれるかを決める経験のほうが、分担の線に近い場所にあります。設定を触る手前で、事業者側の対策と利用者側の確認事項の線がどこにあるかを確かめておくと、後から範囲を広げられることも、逆に抱え込みすぎることも防ぎやすくなります。
「事業者がやってくれる」に頼りすぎると起きること
クラウドサービスの評判や実績を信頼して、細部の確認を省いてしまうことがあります。ですが手引きが示す通り、維持・向上の責任は事業者と利用者の双方が担うものであり、利用者側が対策を怠れば、事業者側がどれほど堅牢な基盤を用意していても、抜け落ちる部分が残ります1。SaaS上の案件に参画する際は、この分担の前提を最初に共有しておくことが、後々の行き違いを防ぐ土台になります。
逆に、事業者側が担う範囲まで自分の役割だと思い込んでしまうケースもあります。基盤の稼働維持や大規模な障害対応など、事業者側の対策で担保されている部分まで背負い込むと、本来集中する開発や設定の作業に手が回らなくなります。分担の線を知ることは、責任を減らすためではなく、担う範囲を正しく定めるための土台です。
下の図は、その境目をひとつの線として整理したものです。事業者側が担う範囲と、利用者側の確認事項を分けて眺めると、外から参画する立場が担いやすい範囲と、社内に残る範囲が見えてきます。この先の章では、利用者側の確認事項のうち、社内の担当者でなければ埋められない項目から順に見ていきます。
図の作成:Remogu編集部。手引きが示す分担の考え方を整理したもので、統計データではありません
2. 社内の管理担当は、外から入る人では代われない
特性を理解した管理担当者という確認事項
手引きのチェック項目には、クラウドサービスの特性を理解した管理担当者を社内に確保しているかという確認が含まれています2。これは、日々の運用を外部の担当に委ねてよいという意味ではなく、社内のどこかに、そのサービスの特性を理解して判断できる人を置いておく必要があるという確認事項です。
外から参画する立場がこの役割そのものを引き受けてしまうと、契約が終わった瞬間に、判断できる人が社内からいなくなってしまいます。設定の変更履歴や、なぜその権限構成にしたのかという経緯は、案件が終わったあとも社内に残る必要がある情報です。自分が担うのは、その判断を助ける実務であって、判断そのものの代わりではありません。
「代わりを務める」と「支える」の線引き
何でも巻き取れると見られるよりも、どこまで引き受け、どこから社内の担当に戻すかを言葉にできることのほうが、参画後の関係が長く続きます。設定作業だけの人だと見られる心配は、引き受ける範囲を自分から示すことで薄まっていきます。
参画前の打診の場面で、社内に管理担当が置かれているか、置かれていない場合はどの範囲まで自分が担うことになるのかを確認しておくと、契約終了後に何が社内に残るのかが最初から見えます。下の表は、外から参画する立場が引き受けやすい範囲と、社内に残す範囲を分けたものです。
| 項目 | 外から参画する立場が引き受けやすい範囲 | 社内に残す範囲 |
|---|---|---|
| 個別の設定・調整 | 要件に沿った変更の実装 | 変更の可否を最終判断する |
| 権限の設計 | 設計案を提示する | 誰にどの権限を与えるか決める |
| 他システムとの連携 | 連携方法を実装する | 連携の可否を判断する |
| 特性を理解した管理体制 | 運用を支える実務を担う | 継続して判断できる担当者を置く2 |
権限の設計や認証の仕組みも、この線引きの延長にあります。次の章では、誰にどのような権限を与えるかという確認事項を見ていきます。
引き受ける範囲を確かめながら、自分に合うSalesforce案件を見る →
3. 権限とアカウントは、作り込みと同じ重みで置かれている
誰に、どのような権限を与えるかという確認事項
利用者側の範囲を決める確認事項では、誰に、どのような権限を与えるかを検討することが挙げられています3。画面の作り込みと同じ重みで、権限の設計が確認事項に置かれているということです。外部から参画する立場に管理者権限がまとめて渡されている場合、それは案件の信頼の証ではなく、権限設計そのものが十分に詰められていない状態を示しているとも読めます。
権限は、必要な範囲だけを渡し、必要がなくなれば戻すという前提で設計されるものです。参画の打診を受けた段階で、どのような権限が渡される予定なのか、その権限が案件の内容に見合っているのかを確認しておくと、後から権限を渡されすぎているという不安を抱えずに済みます。
権限を渡されすぎて不安になる場面もあります。手引きが誰にどのような権限を与えるかを確認事項として挙げているのは3、渡す側にも渡される側にも、権限の範囲を決める責任があるという前提があるからです。広すぎる権限を渡されたと感じたら、その範囲が案件の内容に見合っているかを、クライアントと協議する材料にできます。
共有アカウントを渡されたときの断り方
利用者の認証を厳格に行う確認事項では、ID・パスワードを共有しないこと、そのほかの認証機能も利用することが挙げられています4。共有アカウントで作業してほしいという打診を受けた場合、この確認事項を材料にして、個別のアカウントを用意してもらえるかをクライアントと協議する余地があります。
共有アカウントで素早く着手できることよりも、自分の名前が残るアカウントで、いつ何を変更したかが追える状態のほうが、あとになって障害の原因を切り分ける場面で自分を守る材料になります。
下の図は、権限を渡す範囲をひとつながりの帯として示したものです。次の章では、この権限の話とあわせて、手元に残しておくものと、参画前に確かめておきたい出口の条件を見ていきます。
出典:中小企業のためのクラウドサービス安全利用の手引き(独立行政法人情報処理推進機構、2026年6月)をもとに作成
4. 手元に残すものと、出口の条件を先に確かめる
サービスが止まったときに、自分の手元に何を残すか
バックアップに責任を持つ確認事項では、サービスの停止やデータの消失・改ざんに備えて、重要情報を手元に確保し、必要なときに使えるようにしているかが問われています5。SaaS上で作業していても、事業者側の基盤にすべてを預けきるのではなく、自分の作業に関わる重要な情報は、手元でも確認できる状態にしておく必要があるということです。
参画中にこの確認を怠ると、障害が起きたときに、何が失われたのかを自分で説明できない状況に陥ります。逆に、日々の作業の中で重要情報を手元に確保する習慣があれば、障害が起きた場面でも、どこまでが自分の作業範囲で、どこからが事業者側の対策の範囲かを、落ち着いて切り分けられます。
利用終了時の条件は、参画する前に聞いておく
利用終了時のデータを確保する確認事項では、全データの返却や、残留データの完全消去などの条件を確認することが挙げられています6。この確認は、契約が終わったあとの話に見えて、実際には参画する前に聞いておきたい内容です。
契約が終わったあとに条件を聞くよりも、参画する入口で出口の条件を聞いておくほうが、途中の判断が軽くなります。データの返却範囲や消去の条件をあらかじめ知っていれば、稼働中にこれは残していいのかと迷う場面が減ります。
下の表は、参画前に確かめておきたい7つの確認をまとめたものです。あわせて図3で、入口と出口のつながりを見ていきます。
| 確認事項 | 内容 |
|---|---|
| 管理担当の有無 | 特性を理解した管理担当者を社内に確保しているか2 |
| 権限の設計 | 誰に、どのような権限を与えるか3 |
| 認証の方法 | ID・パスワードを共有しないこと4 |
| 手元への確保 | 重要情報を手元に確保して必要なときに使えるようにしているか5 |
| 利用終了時の条件 | 全データの返却や残留データの完全消去などの条件6 |
| 再委託先の管理監督 | 再委託している場合の管理監督責任7 |
| 保存場所の把握 | どの国や地域に設置されたサーバーに保存されているか8 |
図の作成:Remogu編集部。手引きが示す確認事項の順序を整理したもので、統計データではありません
出口の条件を確認してから、Salesforceの案件条件を見る →
5. 見えにくい階層と、置き場所を確かめる
設備の保守などを再委託している場合の管理監督
適用法令や契約条件を確認する確認事項では、設備の保守等を再委託している場合の、再委託先の管理監督責任を確認することが挙げられています7。SaaS上の案件は、事業者・利用者という二層だけでなく、事業者がさらに保守などを外部に委ねている場合があり、その階層は外からは見えにくいものです。
障害が起きたときにどこまでが誰の責任かを整理するには、この階層があることを前提に置いておく必要があります。自分が直接やり取りするのは事業者側の窓口だとしても、その先に再委託先が関わっている可能性を踏まえて、確認事項を投げかける相手を選ぶ視点が役に立ちます。
データがどこに置かれているかを、設定を触る前に知る
データ保存先の地理的所在地を確認する確認事項では、データがどの国や地域に設置されたサーバーに保存されているかを確認したかが問われています8。設定を変更する前に、扱っているデータがどこに置かれているのかという前提を知っておくと、変更の影響範囲を見誤りにくくなります。
設定画面の中だけを見ているよりも、その設定の先にある階層と保存場所まで視野に入れているほうが、Salesforceでの経験を語るときの厚みが変わります。同じ設定作業でも、階層を意識して進めてきた経験は、次の案件でも生きる材料になります。
次の案件の打診を受けたとき、これまでの経験について尋ねられる場面があります。触れてきた設定や実装の内容だけでなく、事業者側の対策や再委託先の階層、データの置き場所まで意識してきたかどうかは、面談の中の会話で自然に伝わっていきます。層を意識した経験は、次に参画する案件でもそのまま材料になります。
下の表は、Salesforceでの経験を4つの層に分けて書き出したものです。図4もあわせて確認してみましょう。
| 層 | 内容 | 経験の書き出し方 |
|---|---|---|
| 自分が触れる設定・実装の層 | 画面・項目・連携の実装 | 実装した内容とその意図を書く |
| サービス基盤の運用の層 | 事業者側が担う稼働の維持 | ここは自分の実績にしない |
| 再委託先が関わる層 | 保守等の管理監督7 | 契約範囲に含まれるか確認した経験を書く |
| データの保管場所の層 | サーバーの設置国・地域8 | 確認した経験を書く(国名は書かない) |
図の作成:Remogu編集部。手引きが示す確認事項を層として整理したもので、統計データではありません
階層を整理できていると、次の参画先を選ぶときにも、自分がどこまで踏み込める案件かを見極めやすくなります。
6. まとめ
SaaS上のSalesforce案件で消耗するのは、作り込みが難しいときよりも、責任の線が引かれていないときです。独立行政法人情報処理推進機構の手引きは、クラウドサービスのセキュリティを事業者と利用者の役割・責任の分担として整理し1、管理担当者の確保、権限の設計、認証の方法、手元への確保、利用終了時の条件、再委託先の管理監督、保存場所の把握という確認事項を並べています。外から参画する立場が担う役割は、この一覧のどこを引き受け、どこを社内に残すかを、自分の言葉で線引きすることです。
責任の線を自分で説明できるようになると、設定作業だけの人と見られる心配は薄れていきます。Remoguで扱う案件の90%以上がフルリモート可能です9。場所に縛られず、Salesforceでの経験を活かせる案件を探すなら、まず登録して、自分の経験に合う条件を確かめてみましょう。
7. よくある質問
設定作業だけの人と見られないためにどうするか
設定を変更した理由や、どの権限構成を選んだ根拠を言葉にして残しておくと、単なる作業の実行者ではなく、判断に関わった立場として伝わりやすくなります。手引きが示す確認事項1のうち、自分がどこを担い、どこを社内に戻したかを説明できることも、同じように役立ちます。
社内に管理担当がいない現場ではどうするか
手引きは、特性を理解した管理担当者を社内に確保しているかを確認事項として挙げています2。担当者が置かれていない場合、自分がその代わりを引き受けるのではなく、担当者を置く必要があることをクライアントと共有し、自分が担う範囲を明確にしておくことが出発点になります。
障害が起きたときの責任はどこにあるのか
手引きは、事業者と利用者が役割・責任を分担するという考え方と、確認事項の一覧を示していますが1、個別の障害でどちらの責任になるかは契約の内容によって変わります。この記事では法的な判断には踏み込まず、参画前に確認事項を確かめておくことで、行き違いの起きにくい状態を作る視点を紹介しています。
中小企業向けの手引きは大きな組織の案件でも参考になるのか
手引きは中小企業を主な対象に作られていますが、事業者と利用者の役割・責任を分担するという考え方1や、管理担当・権限・認証・保存場所などの確認事項は、組織の規模にかかわらず共通して押さえておきたい視点です。大きな組織の案件でも、確認事項のリストとして参考にできます。
リモートワーク案件をお探しの方へ
Remoguは、株式会社LASSICが運営するITエンジニア・デザイナー専門のリモートワーク案件紹介サービスです。フルリモート・ハイブリッドの案件から、スキルに合うものを探せます。
SaaS上の案件で消耗するのは、作り込みが難しいときよりも責任の線が引かれていないときです。まずはSaaS上の開発のリモート案件が、いまどんな条件で並んでいるかを見てみてください。
会員登録無料 / 案件閲覧・相談は無料
※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。
出典・参考情報
*1 独立行政法人情報処理推進機構「中小企業のためのクラウドサービス安全利用の手引き」利用者がやるべきことを知っておきましょう(2026年6月)
*2 独立行政法人情報処理推進機構「中小企業のためのクラウドサービス安全利用の手引き」7. 管理担当者を決める(2026年6月)
*3 独立行政法人情報処理推進機構「中小企業のためのクラウドサービス安全利用の手引き」8. 利用者の範囲を決める(2026年6月)
*4 独立行政法人情報処理推進機構「中小企業のためのクラウドサービス安全利用の手引き」9. 利用者の認証を厳格に行う(2026年6月)
*5 独立行政法人情報処理推進機構「中小企業のためのクラウドサービス安全利用の手引き」10. バックアップに責任を持つ(2026年6月)
*6 独立行政法人情報処理推進機構「中小企業のためのクラウドサービス安全利用の手引き」13. 利用終了時のデータを確保する(2026年6月)
*7 独立行政法人情報処理推進機構「中小企業のためのクラウドサービス安全利用の手引き」14. 適用法令や契約条件を確認する(2026年6月)
*8 独立行政法人情報処理推進機構「中小企業のためのクラウドサービス安全利用の手引き」15. データ保存先の地理的所在地を確認する(2026年6月)
*9 Remoguサイト公開情報(フルリモート可能案件の割合)