0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

取適法の取り締まりトレンドから見る、システム保守とクライアントワーク #2

0
Last updated at Posted at 2026-08-03

(この記事は、取適法の取り締まりトレンドから見る、システム保守とクライアントワーク#1の続きです。)

価格は「話し合って決める」が原則になった

公正取引委員会が、ソフトウェア業を対象に行った実態調査(2022年, ソフトウェア業調査)によれば、

  • 一度決めた代金を、後から不当に下げる「減額」を経験した事業者が13.5%
  • 相場より著しく低い額を強いる「買いたたき」が15.7%
    と報告されています。

2026年1月に施行された取適法(中小受託取引適正化法)では、受注側と協議せずに一方的に代金を決めること自体が、禁止行為に加わりました。価格は「話し合って決める」が原則になった、ということです。

つまり、決めるときも、決めた後も、代金を一方的に動かすな、ということです。

エンジニア・デザイナーの日常における取適法的NG集 / #2 代金を一方的に変更する

前者の「決めるときに代金を一方的に決める」≒ 金額に合意しないまま着手してしまう話は、前回扱いました。なので、今回は、「決めた後」に代金が動いてしまうケースを見ていきます。

<発注側から動かすパターン>

発注担当者Aさん:先月の◯◯対応、請求いただいた◯円の件なんですが。
エンジニアBさん:はい。
発注担当者Aさん:前に似た対応をお願いしたとき、もう少し安かったですよね?
エンジニアBさん:あ……前回のとは、少し中身が違って。(そう言われると、弱いな)

——「前回はもっと安かった」。この一言は、効きます。担当が変われば工数も変わるのに、似て見えるぶん、説明が難しい。過去の実績が、こちらを縛る梃子になる。決めた後に、前例を持ち出して代金を押し下げるのは、制度が禁止している「減額」に近い動きです。

<受注側から動かすパターン>

エンジニアBさん:(着手前に50,000円で合意した作業。夜間帯リリースになった。)
エンジニアBさん:(割り増しください、って言えばいいんだけど……気まずいな。まあ、いいか。)
発注担当者Aさん:今回も助かりました!
エンジニアBさん:(何も言えず、)いえ、こちらこそ。

——誰にも値切られていません。決めた後に作業内容を変え、代金交渉を行わず、受注者自身が蓋をしたパターンです。

なぜ、削ってしまうのか

いずれのパターンも、私が実際に見たケースであり、それも1度や2度ではありません。

あるべき論を講ずるのであれば、作業内容(影響範囲調査含む)や条件(夜間対応は別料金など)を予め明示していれば、変更するときも「⚪︎⚪︎⚪︎なので増額or減額になります」と調整相談もしやすい、という事ではあるのですが、なかなかそういったあるべきの流れに行っていない理由をもう少し深く読み解いてみましょう。

IT業界の商習慣はややこしい

発注者と受注者の取引の土台となる商習慣や常識とも呼べる取引のお作法そのものが、"ケースバイケースで判断"が求められてしまうことが、背景にあるのではないかと考えています。例えば、1つの取引が成立させるには、次のような要因を考慮しています。

  1. 契約形態
    同じクライアントでも、請負と準委任(=成果に払うか、動いた時間に払うか)が混ざる。例えば、改修の一式は請負、日々の運用は準委任、と案件ごとに立て付けが変わるから、単価の意味を混同しがち。

  2. 営業行為か、SE稼働か
    定額の保守契約がある場合で迷いがちなケースです。どこまでが営業行為(営業行為として直接的に費用請求しない)で、どこからがSE稼働が発生する業務(有料提供)なのか。
    例えば、「費用見立てを出す」場合でも、営業行為と捉えられるケースと、システムや用件の調査が伴うケースがあり、この線が画一的に引けないのです。

  3. 起点が複雑
    これも保守フェーズで起こりがちな話ですが、誰かしらの意思(リクエスト)ではない作業が発生します。外部からのアタック、強制アップデート、監視アラートなど、"事象"を起点として業務が発生するというのも業界的な特徴です。
    品質規格のJIS X 0161は、保守を4つに分類しており、是正保守(障害・緊急の修正)、適応保守(OS更新やセキュリティパッチ、法令対応)、完全保守(改善)、予防保守(予兆への対応)。この内、前の二つ——是正と適応が、まさに"自発的でない起点で始まる業務"です。

金額の正当化が辛い

コミュニケーションの土台が揺れている
↓
値段を握れない(握るのが面倒)
↓
値段を握っていないから、値段交渉が難しい
↓
「ゼロから正当化」しなければならない

この「ゼロから正当化」が、しんどい。人間なので、どこかに逃げたくなります。

例えば、言い出さずに飲む。

夜間のリリースを頼まれて、通常と同じ単価のまま、自分の判断で引き受ける。範囲が広がっても「これくらいなら」と吸収する。もう一つは、あとで出す。あとで出した金額は、根拠の履歴がないぶん、相手の目には「急に高くなった」と映り、積み重なると、お金に対する信頼が揺らぐ。

直ぐ動ける人は、現場では"できる人"に見えてしまいます。値段交渉というステップを踏まない=怠慢ということではなく、システムを正常に保つ有能さと責任感が、周りまわってお金を削る方向に働いている、とも言えなくはありません。

システムオーナーも、発注した自覚が薄いだけで、決して踏み倒そうとしているわけじゃない。システムの運用の経験が浅いと、外部要因でSE対応が必要となるという理解がなければ予算を確保できておらず、エンジニアに支払う原資がないという板挟みの状態である可能性もあります。

じゃあ、どうする?

常識・慣習が揃ってくれば良いという話なので、回数を重ねていって、発注側と受注側の背景知識が積み上がっていけば、ゼロから正当化する必要はなくなり、楽になって行くものではあります。

今回は、初めのとっかかりとして、取引を成立するための判断ポイントを整理しました。目の前の作業の値段を考える時のチェックリストとして参考になれば幸いです。
システムや保守に偏った項目もありますので、関係ないと思うものは読み飛ばしてください。

  1. いくら、とはっきり言えるか?
    言えないなら、まだ値付けできないサイン。「調査だけ◯◯◯円」を先に切り出して、そこで正式に出す。

  2. 作業範囲は、どこまで入ってる?
    調査、仕様調整、テスト、本番化など、実は制作工程そのもの以外の工程もたくさんあります。どこまで含む金額なのかを切り分けておくと、後で「仕様の再調整対応」が発生した時も相談しやすくなります。

  3. 緊急度は、高いか?
    障害などで緊急で作業への対応に入る必要がある場合は、フェーズを分けてみましょう。緊急対応のほとんどは、最終的な着地金額がわかっていない状況で着手することになります。なので、一次対応までで"切り分けて"、フェーズの上限を置きます。

  4. どの契約に乗せる?
    稼働予算が割り当てられた契約があるなら、その契約の範囲に沿っていますか。例えば、仕様の問い合わせ程度の相談であれば、保守契約の中で無償で対応OKという判断もできる。ただし、"なぜ無償か"理由の言えない無償は、作らないように注意。

  5. 契約の枠に、収まる?(枠内/超過/枠外)
    稼働予算が割り当てられた契約があるとして、その枠内に収まっているか。超過していれば、追加請求の検討対象になります。

  6. 作業が発生した起点はどこ?
    セキュリティパッチの適用やOSアップデートなど、発注者からの希望ではないが、クライアントのサービスを維持する上で必要な作業である。情報収集と対応要否チェックまではサービス(あるいは保守契約内)、適用やテストは有料のような形で責任の分岐点を明確にした金額の算出ができているか。

  7. 夜間・休日・時間外か?
    Yesなら、割増を検討しましょう。ただし、「割り増しです」という一方的な通達は避けたいところです。追加費用を払っても夜間に対応を希望しているか、追加費用は出したくないから営業時間内での対応で良いかを発注者に確認しましょう。何を優先するか、金額のバランス感を擦り合わせる絶好の機会です。

  8. 請負か、準委任か?
    "完成物"を約束する仕事か、"動いてくれること"を約束する仕事か。適切な契約形態をとっているかチェックします。完成物を約束できないもの(調査・運用・障害対応)を請負で受けると、読めない工数の責任まで背負ってしまうことになります。新機能の実装、改修一式、特定画面の制作は、請負に向きます。監視、障害の一次対応・原因調査、技術相談などは、準委任向きと言えます。

  9. 過去の業務、他の業務と、揃っているか?
    似たような業務を過去に引き受けたことがあるなら、今回の金額・工数との差に注意です。業務や影響の範囲が異なるなど金額の根拠を明示しましょう。内容は異なるが同時進行している業務についても、発注者にとっては比較対象です。簡素に"見える"業務と複雑そうに"見える"業務が、それぞれ妥当な金額が設定されているか、横並びで比較されているということを意識しましょう。

各々のチェックポイントに対して、判断基準や取り扱い方針はあくまで事例ですので、ご参考までに。

どこへ向かうのか

現場の人が積み上げた判断が、前例や商習慣として受発注のルールに形を与えていきます。

金額を維持するか、再合意へ向けたコミュニケーションをとるか、判断しているのは、エンジニアや発注担当者などの「現場の人」です。残念ながら、契約書やルールを決めた会社の代表や営業でもないということです。

現場の一人一人が、リーズナブルに(理にかなった)金額を判断できるようになることが、健全な商取引に直結します。これが出来ないと、どんなルール、契約書であれれ、現場の一件の事例で、その有効性が疑われてしまうことになります。

私自身、「どこまでを別料金にすれば"ちょうどいい"のか」の答えを、毎度毎度考える日々です。だからこの連載を書いています。現場で値段を判断している人と一緒に、その物差しを育てていきたい。

あなたの現場で、「これは自分で削ってしまったな」という一件があれば、よければ聞かせてください。値段を判断する現場の物差しを、一緒に育てられる仲間を、探しています。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?