受託開発は、直請けが前提 メリットとデメリットのまとめ

受託開発とは、顧客から仕事を受注し、システムやソフトウェアを開発することを指します。

他社向けのシステムを請け負って開発することを受託開発というんですね。

受託した仕事の一部を、下請けとなる別の事業者に再委託することもあります。全部を再委託する「丸投げ」も存在します。

会社のブランド力で仕事が受注できる場合など、自社では営業だけおこなって、実際の開発は受託開発に依頼するケースもあります。

【関連記事】
▶受託開発って？受託開発営業の仕事の進め方を徹底解説！

政府による DX 推進もあり、時代は従来の受託開発やウォーターフォール形式から、自社開発やアジャイル方式での開発に変わりつつあります。従来の受託開発にもメリットがある中、この先のIT業界の動向などについて解説します。

受託開発の特徴

受託開発のメリットは、実績を積みやすいこと

• 実績を積みやすい
• 仕事を選ばなければ、案件は豊富にあるため、エンジニアがある程度まで経験を積みやすいと言えます。
• 開発が完了し、検収が済めば、必ずある程度の開発費用が入ってくる。

システム開発による収益で会社を運営していくなら、比較的仕事が得やすい形態と言えるでしょう。ただし、実績がないうちは、利益率の低い仕事をやらざるを得ないケースもあります。

開発したシステムが利益を生み出すかどうかはではなく、仕様に沿った成果物を納品したかどうかが重要なポイントになります。

受託開発のデメリットは、不利な条件の案件も多い点

• 短納期の場合がある
• アジャイル方式など、頻繁に仕様が変わる前提で開発を進めると、開発費用が回収できないケースがある。
• 2次受け3次受けだと、下請けという扱いになり、費用を値切られることがある
• 開発したシステムが大きな利益を生み出しても、リターンは少ない
• 会社としてやりたいことがやりにくくなる
• 最新技術など、チャレンジしたい技術を使った案件があるとは限らない

特に実績のないうちは、不利な条件で契約を結ばざるを得ないケースも多いです。

また、深層学習やVRなどの最新技術にチャレンジしたいのに、顧客からは枯れた技術での業務アプリ開発のみを求められるケースも少なくありません。

WebサーバやDNSなどの、ウェブインフラ、MySQLやOracleなどのデータベース、ログ収集やシステム稼働状況の蓄積など技術としては確立していて枯れた技術となっていますが、まだまだ多くの需要があり、しかも低価格での提供を求められています。

【関連記事】
▶受託開発ソフトウェア業とは？業界の課題と動向を解説！

旧来の開発方式は、ニーズに合わなくなっている

仕様変更をしない前提のウォーターフォール方式は、受託開発のニーズに合わなくなってきています。かといって、スピード優先のアジャイル方式は受託側にとってリスクも大きいです。

ウォーターフォール方式は、時代遅れになりつつある

昔ながらの開発手法で、いったん仕様を決めたら納品まで基本的に仕様変更を認めません。要件定義から、設計、プログラム製造まで「前工程に間違いがない」前提で、システムを開発していきます。

ウォーターフォールは「滝」を意味し、上流から下流に一方通行で流れる様子を指しています。もともと、製造業や建築業など、設計したらその通りに実物を作るのが当然な分野で重宝されていました。

受託開発は、基本的にウォーターフォール方式での開発をおこなうのが無難と言えますが、ユーザのニーズに合わせてスピード感のある柔軟な仕様変更が求められるウェブサービスなどの案件ではウォーターフォール型開発は顧客のニーズに合わなくなってきています。

アジャイル方式は、仕様変更に柔軟対応できるが管理がしにくい

ウェブ系サービスなど、ユーザの反応次第で仕様が変わるケースで採用される開発手法。最小限の機能単位など小規模な納品を繰り返して、仕様変更での手戻りを最小にします。具体的には、設計、開発、テスト、デプロイ、レビュー、再設計というサイクルを回し続けます。しかし、うまくルールを決めないと発注者の仕様変更に振り回されて、成果物ゼロというケースもありえます。

顧客にとっては、仕様変更前提の柔軟な開発手法ですが、小規模な開発が同時並行するため受託会社にとっては全体の進捗状況やスケジュールの把握が困難で、赤字化するリスクが高い手法と言えるでしょう。

小規模開発を繰り返すため、ドキュメント類はソースから自動生成したり、ビルドや単体テストを自動化するなど仕組み上の工夫が必要になります。

DX推進により、企業はシステムを外注する受託開発から、自社でエンジニアを雇い柔軟に開発するスタイルへ変容しつつあります。特にスタートアップ企業ではその姿が顕著に現れています。

もし、スタートアップへの転職を目指すなら「ポテパンキャンプ」がおすすめです。最短5か月で未経験からプログラマー・エンジニアになれるプログラミングスクールで、多くのスタートアップ企業への紹介実績があります。

優良企業への転職に強いスクールはこちら

受託開発と自社開発、どちらがよい？

受託開発と対照的なのが、自社のサービスを開発する自社開発。

受託より自社開発が良いというわけではなく、それぞれメリット、デメリットがあります。

自社開発のメリットは、ヒットしたときの利益の大きさ

自社おこなうサービス用のシステムを開発することを、自社開発と言います。

• 密なコミュニケーションを取りやすい
• 大きな利益を生み出すサービスを作り出せば利益は大きい
• 納期は受託開発よりも緩い

社内同士なので、打ち合わせの調整が比較的しやすいです。会議を設定して不必要に多くのスタッフを拘束しなくて済むケースもあります。

また、大きな利益を生み出すサービスを作り出せば利益は大きいのもポイント。

自社開発した仕組みで得た利益は、経費を除いて自社のものとなるため利益率は高いです。ただ、狙ってヒットを生み出すのは、なかなか難しいところです。

締め切りについては、絶対的な納期がないので、調整可能なケースも多いです。

サービスの内容にもよりますが、受託開発よりは開発納期の締め切りがゆるいことが多いです。納期よりも、品質を優先させるケースもあります。

自社開発のデメリットは、狙ってヒットが出せない点

• 開発スタッフの維持が難しい
• サービスをヒットさせられるとは限らない
• 社内の部署内であつれきが発生することもある

自社サービス開発のためには一定数のエンジニアを雇用し続ける必要があります。しかし、開発費用の中で最も多くかかる人件費を支払い続けるのは非常に困難です。多数の開発スタッフを維持する人件費が莫大になるため、自社の少数精鋭スタッフ＋流動的に増減できる外部スタッフの体制になりがち。

また、スタートアップ企業の9割は失敗すると言われています。市場のニーズをつかんでサービス化することは、とてもむずかしいことなんですね。

そして、順調に開発が進んだけど、サービスが普及せず広告費や開発費などが全く回収できないケースがあります。受託開発の場合でも赤字になることはありますが、まったく収入が入ってこないということはありません。

利益の配分をめぐって、社内での部署間でのあつれきなどが発生することもあります。契約でつながっている他社とは違って、社内調整に時間がかかるケースもあります。

開発中でも仕様が変わり続けるため、従来のウォーターフォール型の開発手法だとフォローしきれないのもデメリットと言えるでしょう。

優良企業への転職に強いスクールはこちら

一般的な受託開発の流れ

一般的な受託開発の流れを見て行きましょう。以下の流れは、旧来のウォーターフォール型で、スピード感が求められるウェブ系サービスなどの開発には合わないケースもあります。

ヒアリング 課題と解決方法を洗い出す

顧客の抱える課題を聞いて具体化します。顧客側は、IT技術をどのように使えば、どういう形で課題が解決できるかイメージできないため、ヒアリング後に、費用の概算と提案をおこないます。

システム化して解決できる課題を洗い出す作業です。発注者と合意が取れたら、契約書を取り交わします。

要件定義 システムの仕様を決める

システム化するにあたって、仕様を決めるフェーズです。

要件定義を具体的におこなっておかないと、設計やプログラム製造で手戻りが発生し、開発効率が落ちます。

システム導入後にできることと、できないことを明確にする作業です。

設計 使用に基づいたシステム実装方法を決める

要件定義にしたがって、システムの具体的な設計をおこなっていきます。データ設計、システム設計、運用設計などをおこないます。システム設計には、方針の策定を中心とした基本設計と、システムの具体的な実装を中心とした詳細設計があります。

プログラム製造・単体テスト 設計に基づいてコーディングする

設計書を中心に、プログラム製造（コーディング）をおこない、実行可能形式にビルド、機能の単体テストをおこないます。

CIツールなどの、自動ビルド、自動単体テストなどの仕組みを導入することで人的ミスによる手戻りをある程度予防できます。

結合テスト、システムテスト 仕様通りに動作するか試験する

単体テスト済みのモジュールの連携テスト、複数のモジュールを実行して想定した結果が出るかどうかを試すシステムテストなどをおこないます。

想定した結果が出力されない場合は、プログラムのデバッグ、設計の見直し、要件定義の見直しなど前の工程にさかのぼって原因を究明することになります。

設計や要件定義にあいまいな箇所があると、手戻りが多くなり工数がかさみます。

運用テスト 人の動きも含めてシステムのテストをおこなう

システムで自動化する部分と、人が対応する部分を連携させるテスト。本番運用を想定してシステムの動作確認をおこないます。

異常事態を意図的に発生させ、設計した運用フローでリカバリが可能かどうかなどを試験します。

例えば、データバックアップをサーバのデータが破損した前提でリカバリし、システムが正常に復旧するかなどを試験します。

リリース システムをユーザに開放し、利用してもらう

システムをユーザに開放し、利用してもらいます。

システムの利用方法の説明や、トラブル時のサポートをおこなうヘルプデスク担当を決めることもあります。本番稼働初日は、システム停止の影響範囲にもよりますが受託会社の立会が求められることが多いです。

成果物一式の納品と、ユーザ検収（仕様どおりの成果物が納品されたかを確認する）をおこないます。

保守・運用 システムに問題が起こらないよう監視・点検

システム安定稼働後に、問題なくシステムが動作し続けるよう稼働状況の確認や診断、点検などを定期的におこないます。

アラートを出力したハードウェアなどの予防交換をおこなうケースもあります。システム運用を請け負う場合は、運用監視と異常時のアラートや連絡、リカバリなどをおこないます。

本番環境で発生した不具合を検証したり、追加機能の開発をおこなうために、テスト環境や開発環境を用意する必要があります。

優良企業への転職に強いスクールはこちら

受託開発の契約は、法律で定められていて罰則もあり

受託開発の場合、「請負契約」という形態で、受注者と契約を結びます。

請負契約の特徴は次の通りです。

• 成果物を完成の義務がある
• 瑕疵担保責任がある
• 発注者には指揮命令権がない
• 検収後に一括で報酬を支払う

成果物完成の義務 成果物は契約書内で定義する

まず、成果物は何かを契約書内で定義する必要があります。一般的には、プログラムソースコード、実行モジュール一式、ドキュメント類などです。

請負契約では、成果物の納品が必須となります。

瑕疵担保責任 2020年から契約不適合責任に名称変更

納品後、一定期間内に仕様に合わないシステム上の不具合などが見つかった場合、受託側は対応する義務があります。

不具合には、処理速度の遅さなども含まれます。業務効率化のために導入したのだから、処理が遅すぎて使い物にならないのは不具合と言えます。

見積もり時に、瑕疵担保対応分の工数を加算しておくケースもあります。

契約書上では、修補などの項目で詳細を定めておきます。民法では瑕疵担保対応期間は、引き渡しから1年としていますが契約書によって短縮することが可能です。

なお、瑕疵担保責任は、2020年4月1日から「契約不適合責任」と名称が変更になります。

発注者には指揮命令権がない 違反には罰則あり

請負契約の場合、発注者がSEやプログラマに命令をすることは禁止されています。具体的には「業務の遂行方法」「労働時間」「残業や休日出勤の指示」「服務上の規律」などが該当します。

請負契約は民法632条などで規定されていて、請負人が請け負った仕事を完成させるまでは発注者は報酬を支払わなくても問題ありませんが、請負人に対して指示や命令を出すことができないんですね。

これに違反すると、偽装請負という扱いになり、懲役や罰金の罰則がかせられます。罰則の対象は、違反行為を直接行った当人、管理職、会社の代表者など広い範囲に及びます。

検収後の一括支払い 機能毎のフェーズ分割が無難

納品後、ユーザから「仕様通りの成果物を受領した」と、検収書を受け取って初めて、システム開発費用を請求できます。

なお、開発規模が大きく、開発が長期間に渡るような場合は、プロジェクトを複数のフェーズに分けて、フェーズ１，フェーズ２、フェーズ３でそれぞれ検収をおこなうというケースもあります。

また、検収を分割して中間金を支払うよう契約で定めることは可能ですが、注意が必要です。例えば、３回の検収に分けた場合、２回めの検収まで完了したがシステムが完成しなかった場合、すでに受け取った中間金を返還する義務があります。

検収を分割の場合は、仕様で定められた機能単位でフェーズ分けするのが無難と言えるでしょう。

受託開発とSESの違い

SESは、System Engineering Serviceの略で技術者の労働を提供する企業を指します。

受託開発でも、自社開発でもない第三の選択肢と言えるでしょう。

派遣とは違って扱いは正社員なので、待機中でも一定の給与は保証されます。

ただし、二次請け、三次受け、もしくはそれ以上の下請け仕事であることが多く、利益率は非常に低いです。多重下請け構造の下層に位置することが多いため、給与も低い水準のことが多いです。

さらに、最近では一次請けの大手企業が、自社の開発要員の再配置をおこなって、なるべく自社で仕事を完結させて、SESに仕事をまわさないようにする動きが出てきています。そのほうが、自社の利益率が改善するからですね。

受託開発でも、二次請け以下だと待遇はSESと変わりません。直請け案件を多く請け負っていることが重要になります。

優良企業への転職に強いスクールはこちら

まとめ

DXの推進もあり、自社開発（社内SEによる開発）に切り替える企業が増えていますが、まだまだ受託開発によるシステム開発が続きそうです。まずは自分に合った働き方と何なのか？を考えて進む道を検討しましょう。