システム開発を「人月」ではなく「機能・成果物単位」で外注するには
- 3 日前
- 読了時間: 11分
バックエンド開発を外部へ依頼したいものの、「SEを2名、3か月」のような要員単位ではなく、API連携や決済機能など、まとまった機能として任せたい。そんな発注は可能なのでしょうか。
結論から言えば、見積の内部計算では人日・人月を使いながら、発注や検収は機能・成果物単位にすることができます。 人月をなくすことではなく、「何に対して金額を支払い、何が完成すれば完了なのか」を明確にすることが重要です。
はじめに：人月で「計算すること」と、人月で「発注すること」は別
システム開発では、必要な工数を人日や人月で計算することがあります。
たとえば、
設計に10人日、実装に30人日、試験に15人日必要。
という積算です。
開発会社がこうした計算を行うこと自体に問題はありません。工数は、必要な体制や期間、原価を考えるための重要な情報です。
一方、顧客への見積まで、
SE 1.5人月PG 2.0人月
だけになっていると、発注側からは、
何が完成するのか
どこまでが金額に含まれるのか
何をもって完了とするのか
予算を下げたい場合に何を削ればよいのか
が見えにくくなります。
ここで分けて考えたいのが、工数を計算する単位と、仕事を発注する単位です。
結論：工数は価格算定根拠であり、精算単位ではない
成果物単位での外注を考えるときに、最初に分けておきたいのはここです。
工数は価格算定根拠であり、精算単位ではない。
たとえば外部API連携の開発について、開発会社の内部では、
設計に何日かかるか
実装に何日かかるか
試験に何日かかるか
どの程度の不確実性があるか
を積算します。
しかし、顧客が発注する対象は、
一定期間のエンジニアの稼働時間
ではなく、
合意した外部API連携機能の設計・実装・試験
とすることができます。
そして検収するのも、
想定した工数どおりに働いたか
ではなく、
合意した機能・成果物が完成したか
です。
つまり、
積算＝人日・人月
発注＝機能・成果物
検収＝成果物の完成確認
と役割を分けます。
この違いを明確にすると、要員を補充する取引ではなく、一定のバックエンド領域をまとまった範囲で任せる取引として整理しやすくなります。
人月発注と成果物発注では、同じ工数でも見えるものが変わる
ある外部API連携の見積を考えてみます。
人月中心で表すと、たとえば次のようになります。
項目 | 見積例 |
SE | 1.0人月 |
PG | 0.5人月 |
合計 | 1.5人月 |
この情報から分かるのは、主に想定された作業量です。
一方、成果物中心にすると、次のように整理できます。
見積項目 | 対象内容 | 完了条件の例 |
API仕様確認・設計 | 認証、IF、データマッピング | 設計内容の合意 |
API連携実装 | APIクライアント、業務ロジック、データ変換 | 実装・単体試験完了 |
エラー・再実行処理 | タイムアウト、再試行、ログ | 異常系の確認完了 |
試験 | 正常系・異常系の結合確認 | 試験結果を納品 |
リリース支援 | 手順作成、本番反映、納品物整理 | リリース・納品完了 |
必要な工数そのものが変わるわけではありません。
違うのは、発注側が「何に対して費用を支払うのか」を判断できることです。
「SEが何か月必要か」ではなく、
設計
実装
異常系対応
試験
リリース
のどこまでを外部へ任せるのかを話せるようになります。
成果物としてどこまで切り出せるかについては、「バックエンド開発を外注するとき、どこまでを成果物として切り出せるのか」で詳しく解説しています。
また、上の例のようなAPI連携を外注するときの技術的な確認項目は、「API連携開発を外注するときに確認すべきポイント」で解説しています。
価格を調整するときは、「単価」より先に「範囲」を動かす
成果物単位で見積を作る大きなメリットの一つが、価格と担当範囲を対応させやすいことです。
たとえば見積額が予算を超えていたとします。
人月中心の見積では、
人月単価を10％下げられませんか。
という価格交渉になりやすくなります。
一方、成果物中心の見積であれば、
本番リリースは自社で対応するので、リリース支援を外せますか。
エラー時の手動再実行画面は初回リリースから外し、次のフェーズにできますか。
まずは対象APIを1種類に絞って発注できますか。
といった調整が考えられます。
つまり、
同じ範囲を安くするのではなく、今回任せる範囲を小さくして価格を下げる
という考え方です。
価格が合わない場合には、単純な値引きを最初の選択肢とせず、
対象機能を減らす
工程の一部を発注側で担当する
調査だけを先に行う
PoCとして小さく始める
後続フェーズへ分ける
といった方法があります。
この方法なら、発注側は予算内で優先順位を付けやすく、受注側も「どこまで責任を持つ価格なのか」を維持できます。
人月表記が必要でも、発注の中心を成果物にすることはできる
SIerや大手企業との取引では、購買ルールや指定見積書によって、
想定人月
人月単価
想定工数
の記載を求められる場合があります。
その場合、人月表記そのものを避ける必要はありません。
たとえば、外部へ提示する情報を次のように整理できます。
見積項目・成果物 | 想定工数 | 金額 |
設計・設計資料 | 0.25人月 | ○万円 |
実装・対象機能 | 0.75人月 | ○万円 |
試験・リリース | 0.5人月 | ○万円 |
このとき重要なのは、
0.75人月分働くこと
を納品対象にしないことです。
見積条件では、たとえば次のように整理できます。
記載の想定工数は見積価格算定のための参考値です。本見積は記載された作業範囲・成果物に対する請負価格であり、実績工数による増減精算は行いません。
つまり、想定より実績工数が多かった・少なかったという理由だけで、請負価格を増減させるわけではありません。
一方で、仕様や前提条件、対象範囲そのものが変わった場合は別です。その場合には影響を確認し、必要に応じて追加見積や範囲変更を行います。
プレイリーソリューションズでも、通常の成果物中心の見積様式に加えて、顧客の購買ルールなどで人日・人月の記載が必要な場合に備え、成果物と想定工数を併記する見積様式を用意しています。
人月を表示するかどうかが本質なのではありません。
その人月が「精算する対象」なのか、「成果物の価格を計算するための参考値」なのかを分けることが重要です。
成果物単位の発注でよくある失敗
成果物単位で発注するときも、見積書の表記だけを変えればよいわけではありません。
見積書だけ「一式」に変えて、対象外を決めない
たとえば、
API連携一式
と見積書に書いたとしても、
フロントエンド改修を誰が行うのか
外部サービスとの契約手続を誰が行うのか
本番環境への反映を誰が行うのか
が決まっていなければ、発注範囲は曖昧なままです。
「一式」という名称そのものが成果物単位にしてくれるわけではありません。
何を含み、何を含まないのかまで決める必要があります。
バックエンド領域の具体的な切り出し方については、「バックエンド開発を外注するとき、どこまでを成果物として切り出せるのか」も参考になります。
提案書・見積書・検収条件で粒度がずれる
たとえば、
提案書
決済機能を開発します。
見積書
SE 2.0人月。
検収条件
別途協議。
となっていると、結局、
何を完成させれば、この発注が完了なのか
が分かりません。
成果物単位で発注するなら、
決済機能↓その設計・実装・試験↓合意した試験条件を満たせば検収
というように、提案・見積・検収の粒度をそろえる必要があります。
見積書だけ成果物中心にしても、前後の資料が人月・作業時間中心のままでは、取引全体としては曖昧さが残ります。
着手後に前提が変わったときの扱いを決めていない
成果物単位の固定価格では、見積時の前提も重要です。
たとえば、
外部APIの仕様が変更された
対象機能が追加された
発注側で行う予定だった作業も依頼することになった
といった場合です。
こうした変更まで、当初の固定価格へ無制限に含めるわけにはいきません。
あらかじめ、
仕様・前提条件・対象範囲が変わった場合は、影響を確認して別途協議する
というルールを決めておくことが重要です。
要件が完全に固まっていない段階から請負へ移る考え方については、「要件が完全に固まっていなくても、請負開発で相談できるのか」で詳しく解説しています。
実案件では「発注側が開発チームを管理しなくてよい」形も成立する
プレイリーソリューションズが担当した証券会社向けの案件では、
テキストの株価情報を音声にして、インターネットラジオとして配信したい。
という段階から相談が始まりました。
当初は、作るものの具体的な形や、必要となる技術も完全には決まっていませんでした。
そこで、
要件定義
基本設計
詳細設計
実装
インフラの選定・構築
本番リリース
までを一貫して担当しました。
この案件では、発注側が、
開発者を何名集め、誰に何を割り振り、技術的な進捗をどう管理するか
という体制を別途組む必要はありませんでした。
必要だったのは、
実現したいサービスについて合意し、その実現を一定の範囲として任せること
です。これは、「エンジニアを何人確保するか」を中心とした発注とは異なる考え方です。
もちろん、案件の規模や発注側の体制によって適した進め方は変わります。
ただ、バックエンド領域を外部へ任せる際には、必ずしも発注側が個々の開発要員を管理する必要はなく、機能や成果物の完成に責任を持つ開発会社へまとまった範囲を任せる方法もあります。
成果物単位の請負に向かない段階もある
成果物単位での外注には、前提があります。
それは、何を完成させるのかをある程度定義できることです。
たとえば、
現行システムを調べないと改修箇所が分からない
実現できるか技術検証が必要
顧客要望がまだ大きく変わる可能性がある
開発内容よりも継続的な技術支援を求めている
といった段階では、最初から開発一式を固定価格の成果物として発注しにくい場合があります。
特に既存システムでは、現在の仕様や影響範囲を確認する調査そのものが必要になることがあります。「既存システムの改修を外注するときに失敗しないためのポイント」でも、改修前の現状把握の重要性を解説しています。
その場合は、
まず調査・要件整理を行う↓その結果から開発範囲を決める↓定義できた機能を成果物単位で発注する
という進め方ができます。
実際に、要件定義と基本設計だけを担当し、実装は発注側で行った案件もあります。
この場合には、実装コードではなく設計文書そのものが成果物となり、その納品・確認を一つの完了単位として扱うことができます。
つまり、成果物単位の発注は、
「何があっても最初から固定価格にする」ことではありません。
成果物を定義できる段階になったところから、まとまった範囲として切り出す考え方です。
プレイリーソリューションズでは、内部積算と顧客への提示を分けています
バックエンド開発に特化したシステム開発会社 プレイリーソリューションズ合同会社では、SIer・Web開発会社などからバックエンド領域をご依頼いただく際、機能・成果物単位での請負を基本として
います。
社内では、
必要工数
担当
原価
予備工数
スケジュール
を人日・人月も使いながら積算します。
一方、顧客への提案・見積では、
何を担当するのか
何を納品するのか
どこまで責任を持つのか
何をもって完了とするのか
を整理して、成果物・工程ごとに価格を提示します。
Java / AWSを中心としたバックエンド開発、API連携、決済連携、既存Webシステム改修などを対象としています。
そのため、要員そのものではなく、
外部API連携一式
決済機能
既存Webシステムの特定機能群
といった単位で対象範囲を整理します。
顧客指定の見積様式で人月表記が必要な場合には、成果物と想定工数を対応させる見積様式も用意しています。
まとめ：人月をなくすのではなく、役割を変える
システム開発を成果物単位で外注するために、人日・人月を使わないようにする必要はありません。
人月は、必要な工数や価格を考えるための有効な尺度です。
ただし、
工数は価格算定根拠であり、精算単位ではない。
と整理することで、
何人を何か月確保するか
ではなく、
何をどこまで完成させてもらうか
を中心とした発注に変えることができます。
成果物中心の見積にすると、価格交渉でも単価だけを下げるのではなく、対象機能や工程を調整するという選択肢が生まれます。
また、購買ルール上、人月表記が必要な場合でも、成果物と想定工数を併記することで両立できます。
顧客案件を受注しているSIer・Web開発会社の方で、「要員を追加するのではなく、バックエンド機能をまとまった範囲で任せたい」「人月表記は必要だが、成果物単位で外注したい」という場合は、プレイリーソリューションズへご相談ください。
案件の状況を確認し、機能・成果物として切り出せる範囲と見積の組み立て方から対応します。
