DEVELOPER’s BLOG

技術ブログ

準委任契約に込めた私たちの想い〜お客様と一緒に考える柔軟な開発のかたち~

2025.05.12 深川 愛子
コラム
準委任契約に込めた私たちの想い〜お客様と一緒に考える柔軟な開発のかたち~

はじめに

小さな仕様変更のつもりが、大きな追加費用の話に発展してしまった。思い描いていたイメージと違う画面ができあがってきた。そんなすれ違いに、もどかしさを感じたことはありませんか? 私たちも、「もっと柔軟に、一緒に考えられる開発のかたち」を模索してきました。
本記事では、変化に寄り添う開発パートナーでありたいという私たちの想いと、準委任契約に込めた想いをご紹介します。


一緒に考えるパートナーであるためには?

請負契約の現場でよく交わされる言葉

例1)機能追加の要望が出たとき
発注側(お客様):「そういえば、検索結果にフィルターを追加できますよね?あれ、たしか最初の打ち合わせで話してたと思うんですが...」
開発側:「申し訳ありません。それはスコープ外ですね。要件定義書には含まれておりません。」
発注側:「えっ?最初から話してたと思うんですけど...。なんで反映されてないんですか?」
開発側:「正式な仕様としては合意されておらず、実装対象になっていないため、対応には追加費用が発生します。」

例2)軽微な修正のつもりで依頼したとき
発注側:「あと、ここの文言を少し変更して、ボタンの色も変えてもらえますか?デザインにちょっとこだわりたくて。」
開発側:「それは大幅な仕様変更です。デザインガイドラインからの逸脱になりますので、影響範囲を精査し、別途お見積りとなります。」
発注側:「えっ?ボタンの色を変えるだけですよ?そんなに大ごとですか?」
開発側:「スタイルガイドや他画面との整合性にも関わるため、慎重な対応が必要になります。」

例3)思っていたものと違う画面が出てきたとき
発注側:「あれ?この画面、ここのフローはもっと簡単になるはずじゃなかったでしたっけ?」
開発側:「そんな話、聞いてません、、、いただいた仕様に基づいて、その通りに作っています。」
発注側:「えぇ...たしかに言葉にはしてなかったかもしれないけど、流れ的に当然そうなると思ってました。」
開発側:「明文化されていない内容は基本的に対象外となります。」

システム開発の現場で、こんなやりとりに疲れた経験はありませんか?
こうした"すれ違い"とも言える冷たいコミュニケーションをせずに、開発することはできないのか?
そんな想いが私たちにはありました。


請負契約がもたらす"壁"

システム開発は、進めるうちに新たな課題や気づきが次々に生まれるものです。
しかし請負契約のもとでは、要件・納期・金額を最初に確定させるため、途中で仕様を変えるたびに、調整や費用の再検討が必要になります。

「最初に決めた通りに作る」ことと、「本当に必要なものを届ける」こと。
この間に生まれるズレに、私たちは違和感を抱くようになりました。
もっと自然な変化に柔軟に応え、最適なシステムをお客様と一緒に育てていきたい。
そんな想いが、大きくなっていきました。


お客様とチームでいたいから、準委任契約という選択を

システム開発を進める上で、「まずは請負契約で進めたい」というご要望をいただくことは少なくありません。ゴールや成果物を明確に決めてからスタートするスタイルは、安心感があり、プロジェクトの管理もしやすいと感じられるからだと思います。私たちも、請負契約ならではの安心感やメリットを十分に理解しています。

ただ、近年のシステム開発は、市場環境の変化が速くなり、ビジネスニーズやユーザー要求も常に変化しているため、プロジェクト開始後に要件やニーズが変わるケースがますます増えてきました。
最初に決めた仕様を守ること自体が目的になってしまい、「本当に今、必要なもの」とずれてしまう──そんなジレンマが起きる場面も、現場で見てきました。

そうした背景から、私たちが選んだのが 「準委任契約」 でした。

この契約形態では、あらかじめ決まった成果物に縛られることなく、必要な作業・工程そのものに対して対価が発生します。 つまり、変化に柔軟に対応できます。 請負契約のように、最初にすべてを決めてから始めるのではなく、都度、話し合いながら進めていくスタイルが特徴です。

とはいえ、ゴールへの責任感が揺らぐわけではありません。 私たちは、仕様変更や要件追加があった場合でも、プロジェクトの目的やお客様の本来のゴールを常に意識しながら対応を進めます。 単に作業をこなすのではなく、お客様と同じ目線で課題を解決することを目指して伴走します。

また、準委任契約では柔軟な対応が可能な一方で、プロジェクトの方向性がぶれないよう、定期的なチェックポイントや中間ゴールの設定を必ず行っています。
これにより、お客様と認識を合わせながら一歩ずつ進めることができ、進行中でも「今、正しい方向に向かっているか」を常に確認しながら開発を進められます。

準委任契約を導入することで、現場は大きく変わりました。 例えば、あるプロジェクトでは、当初要件が曖昧だったにもかかわらず、「まずは一緒に考えていきましょう」とスタートできました。
結果として、お客様自身も気づいていなかった課題やニーズを掘り起こすことができ、本当に必要とされるシステムにたどり着くことができました。 「仕様に含まれていないから...」ではなく、「まず相談する」ことができるようになり、 信頼を積み重ねながら、「共にゴールを創っていく」感覚が生まれました。

最近では、当初は「絶対に請負契約でないと進められない」というお声をいただいた企業様からも、最終的には「準委任契約でお願いします」と言われることが増えてきました。

悩む


準委任契約が生む、柔軟な開発と信頼の関係

準委任契約には、私たちが大切にする価値観と相性の良いポイントがたくさんあります。

柔軟に変化に対応できる

準委任契約の最大の強みは、「途中での変更」に柔軟に対応できることです。 要件の追加や修正も、都度話し合いながら、スピード感を持って反映できます。 「まず作ってみて、使ってみて、調整していく」という現代的な開発スタイルと相性が良く、お客様の"ひらめき"を最大限活かすことができます。


一緒にプロジェクトを育てる

請負契約だと、どうしても「発注者 vs 受注者」という関係になりがちです。 でも準委任契約では、同じチームの一員として、共通のゴールに向かって並走している感覚が生まれます。
実際に、あるお客様からは「仕様にないけど、相談したらすぐ一緒に考えてくれて先回りした提案ももらえた」という声もいただきました。


進捗が「見える化」されることで、同じ目線で前に進める

請負契約でも、進捗管理表や中間報告などを通じて、プロジェクトの状況を把握することは可能です。ただ、その多くは「成果物の完成に向けた節目ごとの報告」であり、日々の作業の流れや現場で起きている細かな変化までは伝わりづらいこともあります。

一方、準委任契約では、稼働状況や進捗を日報や定例ミーティングなどを通じてリアルタイムで共有する文化が根付きやすく、「どこに時間がかかっているか」「何に悩んでいるか」といった細かな情報まで、お互いが同じ目線で把握できる関係性が築かれます。

また、契約構造の違いも、プロジェクトへの関わり方に影響します。 請負契約では「成果物に対する対価」という性質上、ある程度お任せするスタンスになりやすい傾向があります。

準委任契約では「稼働時間に対する対価」であるため、お客様も「何に時間が使われているのか」「この進め方でよいか」など、日々の状況に対して自然と目を向けるようになります。 その結果、もしスケジュールが遅れそうな場合でも、「なぜそうなっているのか」「何を優先すべきか」といったことを事実に基づいてフラットに議論できるようになり、対立ではなく建設的な対話につながります。 進捗の"見える化"は、単なる報告のための手段ではなく、お互いの理解を深め、信頼関係を育てるプロセスそのものだと考えています。


信頼関係が深まる

何かを"お願い"するたびに費用の話になってしまうと、どうしても心理的な距離ができます。
でも準委任契約なら、「まず相談してみよう」と思っていただける関係を築くことができます。
お互いがフラットに意見を出し合えることで、自然と信頼関係が深まる。
それは、プロジェクト成功の大きな鍵になります。

エンジニアにとっても、作ることだけがゴールではなく、"お客様の課題を解決する"という本質的な価値に集中できるようになりました。

プロジェクト管理


本当に寄り添える開発パートナーでありたい

私たちが準委任契約に込めているのは、「契約形態を変えること」そのものではありません。 大切なのは、"お客様の力になりたい"という想いを、どうやって実現するか。 そのためのひとつの手段として、私たちは準委任契約を選んでいます。

お客様のビジネスや現場に深く入り込み、ともに課題を見つけ、解決し、改善を重ねていく──。 そんな関係性こそが、私たちの理想です。 変化の多い時代だからこそ、契約にも柔軟性と信頼が求められると、私たちは感じています。

とはいえ、準委任契約がすべての案件に適しているわけではありません。

  • 短期間・低コストで成果物を納品することが明確な案件
  • スコープが完全に決まっていて、変更が発生しないことが前提の案件

こうしたケースでは、請負契約のほうが適していることもあります。 大事なのは、プロジェクトの性質に応じて、最適な契約形態を選ぶこと。 私たちは準委任契約を"万能の正解"とは捉えていません。 お客様にとっての最善策をご提案しております。

同じ方向を向き、変化を楽しみながら一緒にものづくりをしていく──
そんな出会いが生まれることを、心から願っています。

もし今、

  • もっと柔軟に動いてくれる開発パートナーがほしい
  • 仕様が固まっていなくても相談に乗ってほしい

そんな思いをお持ちでしたら、ぜひ一度お話ししてみませんか?契約形態は、あくまで関係づくりの"土台"です。 お客様とともに、信頼でつながるチームをつくっていけることを、私たちは何より大切にしています。



X(旧Twitter)・Facebookで定期的に情報発信しています!

関連記事

クラウド運用のその先へ、 AWS・Azure・Google Cloudを超えるSRE統合戦略

はじめに:マルチクラウドの「分断」がもたらす課題 背景:なぜマルチクラウドは難しいのか 解決策:SREによる統合戦略とは 技術戦略:統合運用を支える実装ポイント まとめ 1.はじめに:マルチクラウドの「分断」がもたらす課題 近年、企業のクラウド活用は高度化し、AWS・Azure・Google Cloudといった複数のクラウドサービスを同時に利用する「マルチクラウド戦略」が一般化しています。「いっそ1つのクラウドに統一した方が効率的では

記事詳細
クラウド運用のその先へ、 AWS・Azure・Google Cloudを超えるSRE統合戦略
SRE コラム
SREの費用は高いのか?──コストの見える化と

はじめに SREにかかる費用の内訳 なぜ「高い」と感じるのか? "投資対効果"の視点で見るSRE コストを最小化しながら始めるには? まとめ:SREは「高い」ではなく「将来を守る投資」 1.はじめに SRE(Site Reliability Engineering)を導入したい──そう考える企業が増える一方で、「費用が高すぎるのでは?」と導入に躊躇する声も聞かれます。しかし、SREにかかるコストは単なる"費用"ではなく、"将来的な

記事詳細
SREの費用は高いのか?──コストの見える化と"投資対効果"の考え方
SRE コラム
SRE実践の盲点: 多くのチームが見落とす5つのポイント

SRE導入後のよくある課題と本記事の目的 盲点①:ポストモーテムの形骸化 盲点②:モニタリングのカバレッジ不足 盲点③:自動復旧の未整備 盲点④:改善サイクルの不在 盲点⑤:カオスエンジニアリングの未導入 まとめ 1.SRE導入後のよくある課題と本記事の目的 Site Reliability Engineering(SRE)の導入は、サービスの可用性や信頼性を高めるための有効な手段として多くの企業に取り入れられています。しかし

記事詳細
SRE実践の盲点: 多くのチームが見落とす5つのポイント
SRE コラム
 人材不足に立ち向かうSREの力:次世代の運用体制をどう築くか

はじめに:運用現場の"人材不足"が引き起こすリスクとは? なぜSREが"人手に依存しない運用"を可能にするのか? 自動化・可観測性がもたらす省力化と再現性 従来の限界を超えた次世代の運用支援〜生成AI×SREの事例〜 今すぐ始めるためのSRE導入チェックリスト まとめ:人が足りない今こそ、SREという選択を 1.はじめに:運用現場の"人材不足"が引き起こすリスクとは? クラウド化やマイクロサービスの導入が進む中、IT運用の現場では

記事詳細
人材不足に立ち向かうSREの力:次世代の運用体制をどう築くか
SRE コラム

お問い合わせはこちらから