C/C++エンジニアのフリーランス案件の選び方｜契約前に確かめたいこと

C/C++エンジニアのフリーランス案件を選ぶときは、報酬や稼働日数に加えて、用途と担う層、規格の版とビルドの環境、既存コードの状態、新規と保守の割合、性能や品質への責任の書き方、作業の場所と端末、契約期間と節目の区切りの7点を契約前に確かめておくことが大切です。C/C++の案件は、同じ言語でもこの7点の違いで、毎日の負担と負う責任が大きく変わります。

特に見落としやすいのは、コードの状態と、求められる結果が釣り合っているかです。試験の仕組みがなく、書いた人もいないコードで、短い期間に大きな性能の改善を求められる案件では、どれだけ働いても約束どおりに進めにくくなります。この記事では、C/C++案件に固有の確認点を整理します。契約書全般の確認点は業務委託契約書のチェックポイントで解説しています。

C/C++の案件選びで差が出る理由

C/C++は用途が広い言語です。業務系の基幹処理、金融系の高速処理、ミドルウェア、ライブラリ、Windowsの業務アプリなど、同じ「C++開発」の募集でも、使う道具も、試験の厳しさも、働く場所も違います。案件票は「C/C++での開発」「既存システムの改修」のように短く書かれやすく、参画してから想定との違いに気づくことが少なくありません。

よくあるずれは次のようなものです。

• 新しい機能の開発と聞いていたが、実際は古いコードの不具合の調査が中心だった
• 使っている規格の版やコンパイラーがかなり古く、得意な書き方が使えなかった
• ビルドの環境が整っておらず、最初の数週間を環境づくりに使った
• リモートと聞いていたが、試験の環境が社内にしかなく、出社が増えた

こうしたずれは、面談と条件の確認の段階で、聞き方を工夫すれば多くを防げます。仕事の種類ごとの働き方はC/C++エンジニアの仕事内容で整理しています。

契約前に確かめたい7つの点

1. 用途と、担う層

最初に確かめたいのは、何に使われるコードの、どの層を担うかです。アプリケーションの処理なのか、ミドルウェアやOSに近い部分なのか、ほかの言語から呼ばれる部品なのかで、求められる知識が変わります。CとC++のどちらが中心かもあわせて確かめておきましょう。

面談では、「参画後の最初の1か月で、最も期待されている成果は何か」を聞くと、役割の実態が見えやすくなります。

2. 規格の版、コンパイラー、ビルドの仕組み

C/C++に特有の確認点です。

• 使っている規格の版と、新しい版へ上げる予定があるか
• コンパイラーの種類と版、対象のOS
• ビルドの仕組みと、外部のライブラリの扱い
• ビルドに時間がかかる場合、どの環境で行うか

C++の国際規格はC++23が最新の版として公開されています（2026年10月時点、isocpp.orgの案内による）が、現場では古い版のまま動いているコードも少なくありません。古い版の案件を避ける必要はありませんが、自分の経験の範囲と合っているかを知ったうえで受けることが大切です。

3. 既存コードの状態

案件票に書かれていない「コードの今の状態」を確かめます。

• コードの量と、書いた人が社内に残っているか
• 自動の試験がどこまであるか
• 設計の資料や、過去の変更の記録が残っているか
• 直近で大きな障害や、担当の交代があったか

状態のよくないコードの案件を避ける必要はありません。古いコードを整えた経験は評価にもつながります。ただ、状態を知ったうえで受けることが大切です。試験がないコードなら、試験を整える作業が業務の範囲に入るかを合わせて確かめておきます。

4. 新規の開発と保守の割合

新しく書く部分と、既存のコードを直す部分、不具合の調査に使う時間の割合を確かめます。どれが良い悪いではありませんが、自分が積みたい経験と合っていないと、参画してから不満が出やすくなります。障害の対応の体制に自分が入るか、入る場合は夜間や休日の連絡があるかも、ここで確かめておきましょう。

5. 性能や品質への責任の書き方

フリーランスのC/C++エンジニアは、多くの場合、準委任契約で参画します。準委任では、成果そのものではなく、業務を専門家として通常求められる注意を払って行うことが約束の中身になります。

確かめたいのは、契約書や発注の書面の書き方が、この考え方と合っているかです。

• 「処理時間を◯◯以内にする」のように、性能の到達を約束する書き方になっていないか
• 不具合そのものに対する損害賠償の定めがないか
• 成果物の納品が求められる場合、その範囲は何か（ソースコード、試験の結果、調査の報告など）

請負の形で受ける場合は、完成に対する責任を負うことになります。役割と契約の形が合っているかを確かめましょう。契約の形の違いは準委任契約と請負契約の違いで解説しています。準委任の契約なのに、発注元の社員から細かな作業の指示や勤務時間の管理を受ける働き方は、偽装請負の問題につながるおそれがあります。詳しくは偽装請負の記事をご覧ください。

6. 作業の場所、端末、ソースコードの扱い

金融系や業務系の案件では、ソースコードを社外に出さない決まりがあることが多く、作業の場所と端末の条件が細かく決まります。

• 出社の頻度と、リモートで作業できる範囲
• 端末は貸与か、自分の端末を使うか
• 外部のライブラリやOSSを使うときの決まり

外部のライブラリやOSSを使う場合は、そのライセンスの扱いを誰が確かめるかも決めておくと安心です。考え方はOSSライセンスの記事で解説しています。リモートの条件の見方はC/C++のリモート案件の記事をご覧ください。

7. 契約期間と節目の区切り

契約の期間と、リリースや製品の版の区切りが合っているかを確かめます。大きなリリースの直前に契約の更新時期が来ると、更新されなかった場合に最も大事な局面を見届けられません。稼働の幅を超えたときの扱いと、稼働が少ない月の扱いも、ここで確かめておきます。精算の仕組みは精算幅の記事をご覧ください。

フリーランス法では、6か月以上継続して業務を委託している場合に、契約を解除したり更新しなかったりするときは、原則として30日前までに予告することが求められています（2026年10月時点、公正取引委員会の案内による）。詳しくは契約解除・不更新の予告の記事で解説しています。

確かめた内容を書面と照らし合わせる

面談や事前の確認で聞いた内容は、契約の前に書面と照らし合わせます。フリーランス法では、発注する事業者は業務を委託したら直ちに、業務の内容、報酬の額、支払期日などを、書面またはメールなどで明示することとされています。報酬の支払期日は、給付を受け取った日から60日以内のできるだけ短い期間で定めることとされています（2026年10月時点、公正取引委員会の案内による）。明示される事項はフリーランス法で明示される取引条件をご覧ください。

C/C++の案件では、特に次の点が書面に反映されているかを確かめます。

1. 業務の内容に、担う範囲（開発、改修、調査、レビューなど）が書かれているか
2. 性能の到達や不具合のない状態を約束する書き方になっていないか
3. 成果物の範囲と、納品の形
4. 稼働の幅と、超えたときの精算方法
5. 契約期間と更新の時期

面談で聞いておくとよい質問はC/C++エンジニアの面談でよく聞かれる質問と答え方の逆質問の項目でも紹介しています。一般的な逆質問の考え方は面談で聞いておくべき逆質問をご覧ください。

よくある質問

古い規格の版やコンパイラーを使う案件は避けたほうがよいですか？

避ける必要はありません。古い環境のコードを安全に直した経験は、C/C++の案件では評価されやすい経験です。ただし、自分の経験の範囲と合っているか、新しい版へ上げる計画があるかを確かめてから受けることをおすすめします。

面談でコードの状態や試験の有無を聞くのは失礼ですか？

立ち上がりの見通しを立てるための確認として聞けば、失礼にはあたりません。「参画後の最初の数週間で何を把握すればよいかを知りたい」という目的を添えると、相手も答えやすくなります。答えられない場合は無理に聞き出さず、ほかの確認点で判断しましょう。

報酬の高い案件と、コードの状態がよい案件で迷ったらどうしますか？

一概には言えませんが、コードの状態がよくない案件では、調査や環境づくりに時間を取られ、稼働が増えて時間あたりの報酬が下がることがあります。報酬の額だけでなく、立ち上がりの見込みと稼働の見通しを合わせて比べるとよいでしょう。報酬の決まり方はC/C++エンジニアの報酬の記事で解説しています。