初めて受託開発をする時に絶対に気をつけるべきこと

受託開発経験がない会社やフリーランスが初めて受託開発をすることがあると思います。受託開発はハイリスク・ハイリターンです。

初めて受託開発をする時に、絶対に気をつけるべきことを紹介します。

絶対にするべきこと

ベテランエンジニアが参画すること

ベテランエンジニアが参画すること

受託開発では、ベテランエンジニアをプロジェクトマネージャーやプロジェクトリーダーに参画させましょう。

客先常駐(SES)では、未経験の新人を一人で参画させることがあります。しかし、これは配属先にベテランエンジニアが存在しているから可能となります。何かしら困っても、配属先のベテランエンジニアにアドバイスをもらうことが可能で、致命的なトラブルになることは少ないです。

しかし、受託開発では相談相手が自社のメンバーのみとなります。稀に、自社内で待機中のエンジニアに対して、受託案件をアサインする場合があります。そのエンジニアがベテランでない場合、相談する相手が存在せずに、品質の悪いシステムができあがったり、開発することができない場合があります。

そうなってはトラブルしかないので、必ずベテランエンジニアを参画させるか、相談できる環境にしてください。やる気と気合だけではシステムは開発することはできません。発注側に迷惑がかかるのと、信用・信頼の低下にもなるので、リスクがある場合は受託を避ける必要もあります。

開発以外の工数の計算もする

プロジェクト開始前と開始後も工数を計算する

客先常駐(SES)は準委任契約が一般的です。プロジェクトを参画後は、開発時間外も含め、全ての時間で売上が発生します。

  • 開発前の打ち合わせ
  • 勤務時間中の移動
  • 開発後の運用保守

などで請求が可能です。

しかし、受託開発は一括請負が一般的です。システムを納品して、検収後に売上請求することが可能となります。この請求するまでの期間は売上が発生しません。そのため、開発以外で必要な工数も正確に計算して、お見積書に入れる必要があります。

機能単位での工数を見積もった後、その他の工数を見積もりましょう。この工数は、エンジニア以外の工数も必要です。営業や経理の方など間接的に携わる人全員分必要です(計算は会社によります)。

プロジェクト完了後、

「想定より赤字だった」

となるリスクを減らすべきです。

工数見積もりを正確にしてはいけない

プロジェクト開始前と開始後も工数を計算する

機能の工数を見積もる時、正確にしてはいけません。係数(0.8や1.2など)を掛けて計算する必要があります。

例)
30人日 × 0.8 = 24人日
30人日 × 1.2 = 36人日

これは、担当するエンジニアのスキルレベルや顧客リスクなどさまざまな角度から計算をし、見積もりをします。新規顧客であれば係数を高くしたり、お得意様であれば係数を低くします。また、顧客によっては途中で要件が変更となる可能性があります。再見積もりできる場合はいいですが、顧客によってはごねられたりすることがあります。

想定する最大の工数を計算し、正直ベースで数字を見積もってはいけません。概算で出しましょう。

全工数での利益を計算する

利益を計算する

受託開発を始めると、企業や案件によっては、利益率に差が出ます。3%程度しかないものや、50%前後の利益率が出ている案件も存在しています。赤字もよくあります。

今までのお話でもありましたが、携わる人の人件費を考慮して計算します。会社によっては、給料がバレる可能性があるので、エンジニアは直接計算することはありませんが、ベンチャーのような会社で透明性のあるところでは計算することも可能です。

開発に必要な工数だけで、利益は計算することはできません。

  • 受注前の打ち合わせや課題管理表などのやりとり
  • 開発やデザイン
  • 調査
  • 営業
  • 間接的に携わるメンバー
  • ソフトウェアなどのライセンス費用

特に、受託開発ではライセンス費用などが発生します。客先常駐(SES)での案件を持ち帰りで、自社内で開発する時もあります。その時にVisual Studioなどを利用していた場合、ライセンス費用がかかります。高価なソフトウェアを受託で利用する場合は気をつける必要があります。ソフトウェアの費用を計算しておらず、受注後に大きな出費となった案件も存在しています。

発注元のIT知識レベルに注意

発注元のIT知識レベルに注意

IT知識レベルが低い会社の受託開発をする時は注意が必要です。なぜなら、なんでもかんでも問合せしてくるからです。

マニュアルを配布していても、ちょっとしたシステムの使い方を毎日電話で聞いてくる顧客も存在しています。保守契約を結んでいても、サポート内容によっては、保守契約の時間では不足してしまい、トラブルとなることも多々あります。

半永久的にサポートすることもあるため、最初に注意が必要です。

また、システム屋の常識が通用しないので、最初にしっかりと説明をしておく必要があります。

役割・担当範囲を明確にする

役割・担当範囲を明確にする

受託開発する時は、役割や担当範囲を明確にしましょう。

例えば、ホームページを制作する場合は

  • テキスト
  • デザイン
  • 素材
  • 写真
  • 問合せ方法(メールやLINEなど)

など、誰がどこを担当するか明確化しておきましょう。例えば、WordPressの構築だけと思っていたら、カメラマンではないのに写真撮影を依頼されたり、デザイナではないのに素材作成を依頼される場合もあります。必ず、できることとやることを明確化しておきましょう。

また、準委任契約と違い、受託開発はプロジェクトに遅延が発生しても、追加料金を取れることが少ないです。遅延は、開発だけでなく、顧客からの提供資料・開発側からの納品物の確認遅延によって発生する場合も多々あります。顧客を巻き込んで、プロジェクトを進めていく必要があります。

プロジェクトマネージャの力が重要です。

瑕疵担保責任(契約不適合責任)に注意する

受託開発は、瑕疵担保責任(契約不適合責任)が発生します(以降、責任で表現します)。この責任は、何かしら問題があった場合に、無償で対応する必要があります。そのリスクを考慮して受注しましょう。責任の期間は、180日や365日などとても長いです。極論、数人日程度でも発生する場合があるので、責任については理解しておく必要があります。

詳しくは、瑕疵担保責任や契約不適合責任で検索し、法律関係のサイトで学びましょう。

受託はリスクが大きいがノウハウをストックできる

受託はリスクが大きいがノウハウをストックできる

受託開発は、準委任契約と違いより大きな範囲での責任が発生します。しかし、ノウハウをストックすることが可能です。

  • 準委任契約と違い、時間に依存しないビジネスとなる
  • 自社のスキルの統一化
  • 採用したいエンジニアが明確に
  • ノウハウのストックがテンプレートとなる
  • パッケージとして販売できる場合がある

などのメリットが大きいです。

そのため、受託開発できる場合はぜひチャレンジしましょう。エンドユーザ(非IT企業の顧客)とのコネクションが増えるのもメリットとなります。エンジニアも自社開発に憧れることが多く、受託開発ができる会社の需要は高まっていくと想定しています。

読むべき本