• ノウハウ
  • |Remogu(リモグ)" />

    【Salesforce】設定で足りる範囲とコードが要る範囲|境目の見極めと見積りの考え方

    監修・編集責任者:牛尾 昭昌(株式会社LASSIC 執行役員)

    「設定とコードの境目」を示す図です。決めごとの多さ、標準から外れる度合い。設定で足りる/コードが必要になるを並べています。強調しているのはコードが必要になるです。ここから先はコードと添えています。

    📘 この記事でわかること

    • 「設定で足りる範囲」と「コードが必要になる範囲」の境目が、決めごとの有無で先に動くこと
    • 決めごとが無い現場が普通であることと、そこに外から入って手を動かす立場が求められること
    • 要望が入力・承認から経営指標へと段階的に広がっていくことと、その都度境目を引き直す考え方

    Salesforceの案件に加わるとき、最初の説明はいつも「設定でできます」から始まります。ところが作業を進めるうちに、「ここはコードが必要です」という一言に切り替わる場面にたいてい出会います。境目をどこで引くかは、機能の難しさよりも現場の決めごとの状態に左右されます。この記事では、境目の位置を決める要因と、外から入って手を動かす立場でその境目をどう扱うかを整理します。

    リモートワーク案件特化のエージェント|Remogu(株式会社LASSIC運営) 業務システム・SaaSの導入経験が活きる案件を探す リモート案件を見る

    1. 「設定でできます」はどこで止まるのか

    導入からしばらくは、設定の話だけで進みます

    Salesforceに限らず、外部のサービスや製品は一部での利用を含めて6割強の企業がすでに活用しています1。案件に入って最初に耳にするのも、たいてい「ここは設定で足ります」という言葉です。項目の並びを変える、承認の経路を組み替える、画面の表示を調整する——最初の数週間はこうした作業が中心になります。

    設定の作業には、フォームの並びを整えたり、通知の条件を調整したりといった、目に見える変更も含まれます。こうした変更は完成の手触りが分かりやすく、案件の進み具合を示しやすい面もあります。

    この段階では、外から入って手を動かす立場でも迷う場面は少なく、渡された仕様のとおりに設定を積み上げていけば作業は形になっていきます。案件の見積りも、この延長線上でそのまま立てられがちです。設定だけで進む前提が、しばらくの間は正しく見えます。

    ところが、この見立てがそのまま最後まで続くとは限りません。どこかで「ここはコードが必要です」という言葉に切り替わる瞬間が来ます。その瞬間がいつ来るかを事前に言葉にできているかどうかで、以降の進め方が変わってきます。

    止まる瞬間は「決めごと」に触れたとき

    止まる瞬間には共通点があります。外部サービスの利用について、方針を整備している企業は全体の約半数にとどまります2。つまり、設定を進める先に「誰がどこまで決めてよいか」という取り決めが無い現場のほうが、実際には普通だということです。

    決めごとが無いまま設定を重ねると、途中で「この先は誰の判断で進めればよいのか」という問いに突き当たります。この問いに答えられないと、設定の作業は一時停止し、コードで作り込むかどうかの相談へと切り替わっていきます。

    境目は機能の複雑さそのものよりも、決めごとの有無によって先に姿を現します。次の章では、決めごとが無い現場が実際にどういう状態にあるのかを見ていきます。

    図1:設定で足りる範囲とコードが必要になる範囲の境目
    設定で足りる範囲とコードが必要になる範囲の境目を示す図 境目 設定で足りる範囲 入力フォームの並び替え 承認ルートの変更 コードが必要な範囲 外部データの突き合わせ 独自の計算ロジック 境目は案件ごとに動きます

    図の作成:Remogu編集部。設定とコードの境目の考え方を整理したもので、統計データではありません

    2. 決めごとが無い現場という前提

    方針が無いまま、外部サービスだけが増えていく

    前章で触れたとおり、外部サービスの利用に関する方針を整備している企業は約半数にとどまります2。裏を返せば、残り半数の現場では、利用の判断が個々の担当者や部署に委ねられたまま進んでいるということです。

    この状態で案件に加わると、最初に確認する相手が定まっていないという感覚を持つことがあります。設定の変更ひとつでも、誰の承認を得ればよいのかが現場によって大きくばらつきます。

    決めごとが無い背景には、もうひとつの事情が重なります。意思決定を担う責任者を置いていない企業は約半数に上ります9。方針が無いことと、方針を作る担当者が不在であることは、同じ現場で同時に起きやすい組み合わせです。

    決めごとの相手も、実は定まっていない

    こうした現場では、境目の判断を仰ぐ相手を探すところから作業が始まります。情報システムの担当者に聞いても、事業部門に聞いても、最終的な判断者にたどり着かないまま時間だけが過ぎることがあります。

    下の表は、方針が整備されている現場とそうでない現場で、設定変更の進み方がどう変わるかを整理したものです。決めごとの有無は、作業の速さよりも、誰に確認すればよいかという入口の違いに表れます。

    確認する場面方針が整備されている現場方針が整備されていない現場
    設定変更の判断決めごとに沿って進みますその場の判断に委ねられがちです
    外部サービスの追加申請と承認の流れがあります担当者の裁量で進みやすくなります
    境目を確認する相手方針を管理する部署に確認します意思決定を担う責任者が定まらないことがあります9

    方針の有無を早い段階で見極めておくと、境目に差し掛かったときに慌てずに済みます。次の章では、この決めごとが無い現場に外から入るときの前提について見ていきます。

    3. 中の人が触る前提で入る

    内製化は進んでいても、担い手はまだ揃っていない

    開発の内製化は、一部実施中を含めて約半数の企業が進めています5。案件に加わる前提も変わってきていて、外から入る人がすべてを作り切るのではなく、導入したあとは中の人が触りながら育てていく形が広がっています。

    この前提に立つと、設定やコードをどこまで作り込むかという判断にも、もうひとつの軸が加わります。作りやすさだけでなく、あとから中の人が手を入れられるかどうかも見ておく必要があります。

    このため、案件に加わる前から、自分がどこまでを作り切り、どこから中の人に引き継ぐのかを言葉にしておくと、後々の認識のずれを防ぎやすくなります。

    課題は人材の確保と、新しい技術への対応

    内製化を進める企業が挙げる課題としては、人材の確保と新しい技術への対応を挙げる企業が多く見られます6。中の人が触る前提はあっても、実際に触れる人がまだ揃っていない現場のほうが多いということです。

    この状況は、外から入って手を動かす立場にとって役割を明確にします。作って終わりにするのではなく、後から中の人が引き継げる形で残すことが、案件の価値のひとつになります。

    設定を選ぶかコードを書くかを決めるときも、この引き継ぎのしやすさが判断材料に加わります。複雑な組み方を選ぶ前に、中の人がどこまで触れそうかを確かめておくと、境目の説明がしやすくなります。次の章では、この「中の人が触る」前提の上で、実際にどのような手法が広がっているのかを見ていきます。

    4. 設定で作る手法の広がりと、期待の先行

    ノーコード・ローコードは、すでに一定の広がりを見せている

    ノーコードやローコードといった手法は、一部利用を含めると全体の約4割の企業に取り入れられています7。Salesforceの設定を中心とした進め方も、この広がりの延長線上にあります。

    約4割という水準は、まだ広がっている途中の段階を示しています。取り入れている現場がある一方で、これから検討する現場もまだ多く残っているということです。

    同時に、マイクロサービスやノーコード・ローコードといった領域への関心そのものは高い状態にあります8。実際に取り入れているかどうかにかかわらず、期待だけが先に育ちやすい領域だといえます。

    関心の高さが、期待を先に進ませる

    期待が先に育つと、「この手法を使えば、複雑な要望にも設定だけで応えられるのではないか」という見立てが生まれやすくなります。実際に手を動かす立場からすると、この見立てと現場の実情の間にずれが生じやすい場面です。

    下の表は、実際に取り入れられている使い方と、期待が先に立ちやすい使い方を並べたものです。入力や承認まわりは設定の範囲に収まりやすい一方、他システムとの連携や独自の計算になるほど、期待と実情の距離が開いていきます。

    場面実際に取り入れられている使い方期待が先に立ちやすい使い方
    入力・承認まわり設定でそのまま対応できますこの範囲では期待と実情がほぼ一致します
    他システムとの連携標準的な範囲までは対応できます任せられる範囲が広いと見立てられがちです
    独自の計算・集計単純な集計にとどまりやすい範囲です込み入った計算まで賄えると期待されがちです

    期待の先行を悪いことと捉える必要はありません。関心の高さは、案件の入口が広がっているという合図でもあります。次の章では、この期待と実情の距離が、どのような軸で測れるのかを見ていきます。

    5. 境目は標準から外れる度合いで決まる

    作る側は標準を意識し、利用する側はまだ意識が育っていない

    APIの活用や、標準的なデータの形式を取り入れる意識は、作る側を中心に高いことが分かっています11。外部のサービスとつなぐことを前提に設計する習慣が、作る側にはすでに根づいています。

    一方で、モジュール性やデータモデルを意識した設計に取り組む企業は、特に利用する側を中心にまだ少ない状態です12。標準を意識する側と、まだそこまで手が回っていない側が、同じ案件の中で向き合う構図になります。

    この2つの見え方の差が、境目の位置を動かします。標準に沿って設計されている範囲ほど設定で足りやすく、標準から外れた独自の作り込みが多い範囲ほど、コードでの調整が必要になります。

    境目は、2つの軸の掛け合わせで動く

    境目を見極めるときは、機能そのものの難しさよりも、この「標準からどれだけ外れているか」と「決めごとがどれだけ整っているか」の2つの軸を確かめると、判断がぶれにくくなります。

    軸を持っておくメリットは、判断の速さだけではありません。相手に境目を説明するときも、感覚的な言い方より、この2つの軸に沿って伝えるほうが納得を得やすくなります。

    下の図は、この2つの軸の組み合わせで、境目がどちらに寄るかを整理したものです。標準に近く決めごとも整っている領域は設定の範囲に収まりやすく、標準から外れ決めごとも少ない領域ほど、コードでの調整が増えやすくなります。

    図2:標準から外れる度合いと決めごとの多さで位置が決まる様子
    標準から外れる度合いと決めごとの多さで境目の位置が決まる図 標準から外れる度合い 決めごとの多さ コード調整が 増えやすい 設定の範囲に 収まりやすい

    図の作成:Remogu編集部。境目の位置を決める2つの軸を整理したもので、統計データではありません

    この軸を持っておくと、案件に加わった初期の段階で、境目がどちら寄りかをおおまかに見立てられます。次の章では、この境目が案件の途中でどう動いていくのかを見ていきます。

    6. あとから来る要望——見たいものが増える

    最初の要望は、入力と承認まわりに集まる

    案件が動き出した直後は、入力フォームの並びや承認の経路を整えるといった、設定の範囲に収まる要望が中心になります。ここまでは前提どおりに進むことが多い場面です。

    ところが業務が回り始めると、次に来るのは他のシステムとつないでデータを行き来させたいという要望です。この段階から、標準的な形式でつながるかどうかが問われ始めます。

    要望が増えていく順番を知っておくと、最初の見積りの時点で「ここから先は改めて相談します」という一文を添えやすくなります。この一言があるかどうかで、後半の交渉のしやすさが変わってきます。

    さらに進むと、経営の指標をまとめて見たいという要望が出てきます。ビッグデータの活用や経営ダッシュボードの導入には、利用する側の企業も積極的に取り組む傾向があります13。使い始めて終わりではなく、そこから見たいものが増えていく流れは、利用する側にも共通しています。

    後半になるほど、境目は引き直される

    見たいものが増えるたびに、境目は引き直されます。最初に決めた「ここまでは設定で」という線が、後半の要望では当てはまらなくなる場面が出てきます。

    下の表は、要望が届く順番と、そのたびに境目がどう動くかを段階ごとに整理したものです。要望の中身が変わるタイミングを先に知っておくと、後半になって慌てて線を引き直す事態を避けやすくなります。

    段階届く要望の内容境目の動き方
    初期入力フォームや承認ルートの調整設定の範囲に収まりやすい段階です
    中期他システムとのデータ連携標準的な形式かどうかが問われ始めます
    後期経営指標をまとめて見たいという要望13設定の範囲を超えやすい段階です
    図4:要望が増えていく順番と、境目の引き直し
    要望が段階的に広がっていく順番を示す図 入力と承認の整備 最初に来る要望 業務データの連携 次に来る要望 指標を見る要望 最後に来る要望 要望が増えるほど境目は右へ動きます

    図の作成:Remogu編集部。要望が段階的に広がっていく順番を整理したもので、統計データではありません

    次の章では、この後半に集まりやすい不安と、契約まわりの負担について見ていきます。

    7. 品質と運用の不安、そして契約の負担

    優先されるのは、速さより品質

    利用する側の企業は、システムの品質を最も優先する事項として捉えています4。設定で早く形にすることよりも、あとから壊れない作りであることのほうが評価されやすいということです。

    この優先順位を知っておくと、境目の判断がぶれにくくなります。速く進めるために設定で無理に押し込むより、品質を保てる範囲を見極めて、必要ならコードでの調整を選ぶほうが、結果として評価されやすくなります。

    不安が集まるのは、入れたあとの運用

    外部のサービスにおいても、メンテナンスや運用に対する不安を抱える企業は多く見られます3。導入して終わりではなく、そこから先の運用こそが不安の集まる局面だということです。

    下の図は、検討・導入の段階から運用に入るまでの流れの中で、不安がどの局面に集まりやすいかを整理したものです。運用に入ってからの段階は、設定を整えたあとでも気を抜けない局面として意識しておく必要があります。

    図3:入れた後に不安が集まる場所
    不安が集まりやすい局面を示す図 検討・導入 取り決めを話す時期 導入直後 様子を見る時期 運用に入ってから 不安が集まる場面 品質を優先する目線が働きます

    図の作成:Remogu編集部。不安が集まりやすい局面を整理したもので、統計データではありません

    契約の手間も、境目と同じくらい重い

    契約についても、負担は境目とは別のところに潜んでいます。取引ごとに手間や工数がかかる点を課題として挙げる企業は多く見られます10。案件が変わるたびに条件を一から確認し直す負担は、実務の速さに直結します。

    セキュリティ面では、作る側の約7割が何らかのガイドラインを整備しています14。ただし、そのガイドラインは依頼元によって内容が異なるため、案件ごとに確認し直す前提は変わりません。品質・運用・契約のいずれも、境目の話と同じく「決めごとを先に言葉にできているか」に行き着きます。

    設定とコードの境目は、誰が最初に言葉にすればよいですか

    決めごとを最初に持ち出すのは、外から入って手を動かす立場からで構いません。方針を整備している企業は約半数にとどまるため2、待っていても言葉になって出てくるとは限りません。気づいた時点で、境目の見立てを先に共有しておくと、後半の要望にも対応しやすくなります。

    内製化が進んでいる現場では、外から入る役割は減っていきますか

    内製化を進める企業は約半数に上りますが5、課題として人材の確保と新しい技術への対応を挙げる企業が多く6、担い手が揃うまでには時間がかかります。中の人が触れる形で残すことができれば、外から入る役割はむしろ求められ続けます。

    境目を意識せずに案件に入ると、どこで困ることが多いですか

    特に不安が集まりやすいのは、運用に入ってからの局面です。外部のサービスにおいてもメンテナンスや運用への不安を抱える企業は多く3、設定を整えた直後より、しばらく経ってからの問い合わせのほうが増えやすくなります。境目をあらかじめ言葉にしておくと、この局面での負担が軽くなります。

    境目をどこで引くかは、案件を重ねるほど見立ての精度が上がっていきます。まずは自分の経験に近いSalesforce関連の案件を確認し、実際にどのような要望が寄せられているかを知るところから始めてみましょう。Remoguは、案件の90%以上がフルリモート可能なリモートワーク案件に特化したエンジニアマッチングサービスです。登録すれば、こうした境目を扱う案件の条件を具体的に確かめられます。

    リモートワーク案件をお探しの方へ

    Remoguは、株式会社LASSICが運営するITエンジニア・デザイナー専門のリモートワーク案件紹介サービスです。フルリモート・ハイブリッドの案件から、スキルに合うものを探せます。

    設定とコードの境目を先に言葉にできる人は、SaaSの案件で信頼されます。業務システムの導入や改修に手ごたえがあるなら、案件の条件から確かめてみてください。

    リモート案件を見る30秒で無料登録

    会員登録無料 / 案件閲覧・相談は無料

    ※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

    出典・参考情報

    *1 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」前提の広さ(2025年4月)
    *2 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」方針の有無(2025年4月)
    *3 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」不安の所在(2025年4月)
    *4 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」評価の軸(2025年4月)
    *5 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」誰が手を動かすか(2025年4月)
    *6 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」入る余地(2025年4月)
    *7 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」設定で作る手法(2025年4月)
    *8 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」関心の高さ(2025年4月)
    *9 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」決める人(2025年4月)
    *10 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」契約の負担(2025年4月)
    *11 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」つなぎ目(2025年4月)
    *12 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」設計の下地(2025年4月)
    *13 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」次に来る要望(2025年4月)
    *14 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」整備の差(2025年4月)