一生ヘタレプログラマそれでもコードを書き続ける: 準委任契約と受託開発の同時並行は地獄だった。経験者が本気でやめておけという理由

受託開発と準委任契約を同時に抱えたことがある。今思い返すと、あの時期は本当にしんどかった。「どちらも回せる」と判断した自分の見通しが甘すぎた。今回はその経験を正直に書く。これから同じことを考えている人には、少しでも参考になれば。

準委任契約と受託開発、何が違うのか

まず整理しておくと、準委任契約と受託開発（請負契約）は契約形態が根本的に違う。

受託開発は「成果物を納品する」契約だ。期日までに動くものを完成させる責任がある。仕様が変わればスコープ管理が必要で、納品まで責任が続く。

準委任契約は「業務に従事する時間を提供する」契約だ。成果物への責任ではなく、一定時間クライアントの指示のもとで働くことへの対価が発生する。いわゆる時間売りで、SES（システムエンジニアリングサービス）がこれに当たることが多い。

この2つを同時に抱えると何が起きるか。端的に言うと「マインドセットの切り替えコストが想像以上に高い」という問題が発生する。

受託開発と準委任を同時に回していた時期の自分が直面した問題を、そのまま書く。

受託開発は、自分でスケジュールを組んで納期に向けて進める。裁量がある分、自己管理が全てだ。一方の準委任は、クライアントのスケジュールや指示に従って動く。この2つが同時に動いていると、「今日は受託の進捗を詰めるべきか、準委任先の要件ミーティングを優先すべきか」という判断が毎日発生する。

準委任先の割り込み対応が入るたびに、受託のコンテキストが飛ぶ。コードの続きを書こうとすると「あ、さっきの話はどこまで進んだっけ」から始まる。これが積み重なると、受託の進捗が目に見えて遅れる。

準委任契約は基本的に時間のコミットメントだ。週何時間、月何時間という枠で動く。でも受託開発は時間じゃなくて成果物へのコミットメントで、「完成するまで終わらない」という性質がある。

準委任先から「来週この機能のレビューに参加してほしい」と言われると断りにくい。しかし受託の納期が迫っていれば、そちらを優先したい。このせめぎ合いが毎週起きる。どちらも大事なクライアントだから余計に消耗する。

午前中は受託のコードを書いて、午後は準委任先のオンラインミーティングに出て、夕方また受託に戻る。文字にすると普通っぽく見えるが、実際は全然普通じゃない。

受託の仕事はその案件の技術スタック・仕様・コンテキストに深く入り込んで初めて効率が出る。準委任先もそれぞれの技術環境・チーム文化・プロジェクトの背景がある。複数の「別世界」を一日の中で行き来するのは、頭の中のメモリ切り替えコストが想像以上にかかる。

これを実感したのは、あるバグを受託案件で調査していた夕方に準委任先のスラックが大量に流れてきた時だった。対応しながら、元のバグ調査に戻った時には完全にコンテキストが飛んでいた。30分かけて元の状態に戻るまで、実質何も進んでいない。

同時並行の最大のリスクは「どちらも中途半端になる」ことだ。

受託は成果物の品質が直接クライアントの信頼に影響する。納品物に品質問題があれば、それは自分の責任として残る。準委任は時間売りとはいえ、出したアウトプットの質はそのまま評価に繋がる。

どちらも「とりあえずこれで」という水準になってくる。自分が許容できるラインより下の品質で出してしまったことが何度かあって、その時の後悔はかなり引きずった。

ただ、全ての同時並行が絶対ダメかというと、そうとも言い切れない。現実には複数の仕事を掛け持ちしている人は多い。

許容されやすいケース:

危険なケース:

自分がはまったのは危険なケースの3つ全部に当てはまっていた。それでも「どうにかなる」と思って引き受けたのが失敗だった。

準委任と受託の同時並行は、余裕があるように見える時期でも相当慎重に判断すべきだと思ってる。どちらかが開発の佳境に差し掛かっている時は、もう一方を断るか調整交渉するのが正直なところ。

「せっかく来た仕事を断るのはもったいない」という感覚はわかる。自分もそれで何度も判断を誤った。でも無理して両方引き受けた結果として品質と信頼を失う方が、長期的にはるかに損だ。

断ること、調整すること、スコープを絞ること。これも受託開発のスキルのうちだと、18年かけて腹に落ちた。