受託開発とは顧客の要望に従ってソフトウェアやアプリケーションの開発を請け負い、その全て又は一部の完成を条件に報酬を得る開発手段のことです。対象となるものとしては企業の基幹システムのようなオーダーメイド系からパッケージ製品の改修まで幅広く存在します。受託開発と対になる言葉で自社開発という言葉があります。
主な契約形態としては請負契約となっており成果物の納品義務が発生すると共に瑕疵担保責任があります。大規模なシステム開発になる場合、システムインテグレーター（SIer）が一次請けとなって受託開発業務を請け負うことが基本です。また必要に応じて二次請け、三次請けと業務の一部を切り離して再委託が行われるケースも度々見受けられます。

システムインテグレーター（SIer）について解説された記事はこちら＞＞

受託開発の契約形態は請負契約が基本

IT業界における受託開発では基本的な契約形態として請負契約が適応されることが一般的です。請負契約の内容を見ても分かる通り成果物が問われる受託開発の性質上適した契約内容といえるでしょう。例に顧客は基幹システムやECサイトの開発など目的とする要件の元、各ベンダーに発注をします。
そこで準委任契約のような成果物の問われない契約を交わしてしまっては実際に納入物が存在しなかった時に困ってしまいますよね。このことから受託者側は請負契約の性質や内容をしっかりと理解した上で契約及び業務の遂行を実施するようにする必要がありまます。

『請負契約の特徴』

・成果物を完成させる義務有り
・瑕疵担保責任有り
・指揮命令権は受託者に有り

請負契約の特徴や注意点について解説された記事はこちら＞＞

受託開発の見積もり時に抑えておくべきポイント

受託開発において大きな失敗を生んでしまいかねないのがこの見積もりです。「想定していたより工数が掛かってしまった」なんていうことを度々耳にします。それもそのはず受託開発の性質上、顧客ごとにオーダーメイドの依頼を承ることがほとんどのためにまったく同じ事例に出くわす場面はごくごく稀なのです。
それではどのようにして見積もりにおいて想定外のようなリスクを回避していけば良いのでしょうか。最低限以下に記載のポイントは抑えることで想定外を最小限に抑えて実工数と差異の少ない正しい見積もりを行えるようにしましょう。

『見積もり時に抑えておくべきポイント』

・見積もりの範囲を明確に設定する
・想定される作業項目を最小限まで落とし込んで工数を測る
・作業工数を自社の新人エンジニアで想定する
・納期スケジュールに余裕をもたせる

見積もりの範囲を明確に設定する

具体的な作業範囲を明確にしましょう。作業範囲の線引きが曖昧のまま進行してしまうと顧客と受託者の間でその作業は発注の範囲内に相当するのか否かが不明となってしまいます。このような事態は実際に多くの場面で発生しているようでお互いにとっても納得感は薄れてしまい作業の途中で不信感を生むキッカケとなってしまいます。
どこからどこまでの範囲をどのようにして開発を進めていくのかを見積作成時に明確に設定するようにしましょう。また万が一不明な点が出てきた際にもどのようにして解決に導くのかをお互いの合意の上でルールを決めておくようにしましょう。

想定される作業項目を最小限まで落とし込む

作業範囲が明確になった後に、作業工数を算出するため一つ一つの作業項目に目を向けます。作業項目単位での工数を正しく見積もるために各作業項目を最小限まで落とし込むことが必要とされます。
この時、どんぶり勘定で見積もってしまうと想定以上に工数負担が生じてしまう恐れがあります。作業項目単位での工数を正しく見積もる際には実作業者に極力近い立場の技術者同席の上で協議することが大切です。とはいっても実際に作業をしてみなければ分からない部分も多々あるかと思います。
そのような機会を減らして行くためにも受託実績をしっかりと記録し、親しい発注内容を正しく見積もりが出来るようにノウハウを蓄積しておくことが大切です。

作業工数を自社の新人エンジニアで想定する

見積もり作成の際に大きな失敗として陥りやすいのが自社のどのエンジニアを想定して作業工数を見積もっているのかという部分です。仮に自社にエース核となる一般的な方の約2倍作業効率の良いエンジニアを作業者として想定し見積もりを算出していたとしましょう。
もしもこの方が何らかの理由で長期休暇ないし退職となった場合、プロジェクトの進行に大きな影響が出ることはもちろん作業工数も当初予定していた2倍、3倍も掛かってしまう恐れがあります。
こうした事態を回避するために予め作業工数を自社の新人エンジニアを基準に設定しておけば対応者の代えも行いやすいだけでなく当初の見積もりと大きな変更なく作業進行が出来ることでしょう。

納期スケジュールに余裕をもたせる

受託開発において最もあってはならないのが納期遅延です。顧客は予定された納期に合わせて様々な業務スケジュールを立てております。場合によっては顧客に多大な損失を与えてしまいかねません。このような事態を避けるために必ず納期スケジュールに余裕をもたせましょう。
顧客の目的や要望を第一に考えながらも現実的かつリスクを最小限に抑えた正しいスケジュールを提示する必要があります。間違っても受注したいがために非現実的な納期スケジュールを承諾してしまってはなりません。顧客にとっても受託者にとっても不幸せな結果となる可能性の種は摘むようにしましょう。

受託開発の流れ

受託開発の仕事の流れについて見ていきましょう。

仕事の依頼を貰う

受託開発は顧客から開発という仕事の依頼を受けて成立する業務です。そのため仕事の依頼を獲得しなければなりません。いわゆる営業活動の実施が必要となるわけですが、営業活動には様々な手法があります。
自ら顧客を獲得しにいくアウトバウンドと呼ばれる手法から、顧客側から来てもらうインバウンドと呼ばれる手法まで。自社の状況に適した営業活動を選択の上、仕事の依頼を貰うことを実現しましょう。

『営業手法』

▼アウトバウンド営業
・テレフォンアポイントにし新規見込み顧客を獲得する
・ダイレクトメッセージにし新規見込み顧客を獲得する

▼インバウンド営業
・自社のホームページへ問い合わせを貰う
・展示会に出店し見込み顧客を獲得する
・セミナーへ集客をしみ込み顧客を獲得する

▼ルート営業
・取引や付き合いのある企業から仕事を貰う

顧客と打合せをする

見事営業活動にて見込み顧客を獲得することが出来れば顧客との打合せへと進みます。システム開発を発注するニーズがある顧客は必ずその目的や課題を抱えております。この目的や課題をヒアリングし正しく汲み取って企画の計画書に落としていくことも受注者の仕事です。これをシステム企画と呼びます。新規システムの開発や既存システムの改修など問題点を調査・分析し、それに基づき、システムの企画を行います。

システム企画について解説された記事はこちら＞＞

見積書の作成

顧客との打合せによってシステム開発の概要が定まった後に、システム企画を元に見積書の作成を行います。簡単に言うとそのシステム開発を行うにあたってどれくらいの工数と費用が発生するのかを明確にするものです。ここではシステム開発に携わるエンジニアの稼働工数を一ヶ月に見立てて一人月として算出することが一般的とされております。仮に10人が10ヶ月稼働した場合、100人月という見積もりになります。また見積もりの際に主な費用の対象となる項目は設計費、開発費、QA費、仕様書作成費が挙げられます。

『見積書の主な費用対象』

・設計費
・開発費
・QA費（品質保証検査費）
・仕様書作成費

設計・開発・テスト

顧客より見積書の確認が取れて正式に受注となれば受託開発スタートとなります。この開発においては大規模なものであればウォーターフォールモデル、小規模なものであればアジャイル開発と呼ばれる開発手法を採用することが一般的です。
ウォーターフォールモデルの場合にはその名の通り各開発プロセスの役割を明確にし上流工程から下流工程にかけて水が滝のように流れることをイメージして作業が進められます。一方アジャイル開発は短い単位での開発要件を切り取って作業を進めることでリスクを最小限に抑えるという特徴があります。

ウォーターフォールモデルとアジャイル開発について解説された記事はこちら＞＞

納入前確認

設計からテストまで開発における一連の流れが完了すれば残すは納入前確認となります。ここでは一般的に受け入れテストと呼ばれる顧客によるシステムチェックが行われます。具体的には開発者によって作成されたシステムが要件通りに仕上がっているか顧客が判断をするためのテストです。

受け入れテストについて解説された記事はこちら＞＞

納品

納入前確認となる受け入れテストが完了すれば晴れて納品となります。ここまでが基本的な受託開発に関する一連の流れです。

受託開発のメリット

受託開発のメリットについて見ていきましょう。

開発実績を積み上げられる

受託開発では様々な企業からの依頼を受けることで多種多様な開発実績を積み上げられるこというメリットがあります。実績を積み上げていくことで特定の技術についてのノウハウを自社の財産として活用できることや、専門分野に強い受注活動も期待できます。

予算計画を立てやすい

受注開発では業務の遂行（納品）と引き換えに対価の支払いを受けるため予算計画を立てやすいというメリットがあります。一方、自社開発においては目的のサービスの開発が完了した時点では売上の発生が起こるものではありません。そのサービスが軌道に乗り、顧客を継続的に獲得した末に売上が発生します。このように売上の発生地点が明確で採算がしっかり取れるというのも受託開発が人気の理由の一つです。

リピーターの獲得がしやすい

受託開発ではリピーターを獲得しやすいというメリットがあります。ソフトウェアやアプリケーションの開発を外注する企業のほとんどがそのニーズは一度や二度のモノではありません。よって一度依頼を受けた内容を顧客が満足行く形で遂行できれば、リピーターとして今後も継続な発注が期待できるます。実際に受託会社の多くがルート営業という取引や付き合いのある企業から仕事を貰うことで業績を上げております。

受託開発のデメリット

受託開発のデメリットについて見ていきましょう。

納期に関する問題

受託開発において最もあってはならないのが納期遅延と上記「受託開発の見積もり時に抑えておくべきポイント」でも説明をさせて頂きましたが、いくら注意を払っていても問題が絶えないのが納期についてです。様々な問題が考えられますがここでは顧客都合による内容に触れていきたいと思います。顧客都合においてよく見受けられるのが仕様変更または業務計画による納期の問題です。
受発注の立ち位置の性質上、パワーバランスが発注者側に強くなりがちですが顧客都合による何らかの変更が発生する場合には必ず納期に関する相談をおざなりにせず必要に応じて現実的なスケジューリングを打診するようにしましょう。

予算に関する問題

こちらも上述の納期の関する問題同様にパワーバランスが発注者側にあるということから予算についても低めに設定されがちであるという問題があります。
これについてはパワーバランス以外にも影響していることがあり世の中の様々な受託会社が受注活動の際に獲得のために他社よりも安く見積もりを出すことで市場全体の価格設定を下げているということが挙げられます。
これについての対応策は見積もり提出時に価格勝負で戦うのではなく、なぜこの予算が必要なのかということを理路整然と顧客に伝えて理解を得て解決する必要があります。基本的に顧客の最大の目的は要望通りに品質高く長く利用できるシステムを完成させることが目的なので無理に価格を下げて品質を下げてしまうリスクを発生させないためにも提案力を身につける必要があります。

まとめ

受託開発を理解するために特徴や仕事の流れ、メリット・デメリットなどを簡単に解説させて頂きました。受託開発を一言で表すと『顧客の要望に従ってシステム開発を請け負い、その全て又は一部の完成を条件に報酬を得る開発手段のこと』です。受託開発の契約形態は請負契約が主であり、見積もり時には失敗を防ぐために多数の注意事項が挙げられます。受託開発についてこの記事で記載されている最低限の内容は理解しておくようにしましょう。