TRACERY Lab.(トレラボ)

TRACERY開発チームが、要件定義を中心として、システム開発で役立つ考え方や手法を紹介します。

内製開発と外部委託における見積りの相違点〜プロジェクト成功への鍵、開発見積りの重要論点 その1

TRACERYプロダクトマネージャーの haru です。

2025年2月18日(火)に開催された勉強会『BPStudy#210〜見積りと計画について学ぼう』の第3部では、開発の見積りをテーマにしたパネルディスカッションが行われました。その時の様子をお伝えします(伝わりやすくする目的で、話の流れを一部再構成しています。))。

プロジェクト成功への鍵、開発見積りの重要論点

  • その1: 内製開発と外部委託における見積りの相違点(本記事)
  • その2: 「高すぎる」と言わせない見積りの技術(説明責任、スコープ、タイミング、インプット)(近日公開予定)
  • その3: 見積りのトレードオフへの向き合い方(近日公開予定)
  • その4: 過去の経験を見積りに活かす方法(近日公開予定)
  • その5: 新規開発と既存システム改修の見積もり戦略の違い(近日公開予定)
  • その6: 『見積りソン』に参加して得たもの(近日公開予定)

参加者の自己紹介

haru:パネラーの皆さん、まずは自己紹介をお願いします。

高崎:株式会社アクティアでCOOの高崎と申します。弊社はJavaによるサーバーサイド開発を強みとし、設計にこだわりながら日々開発を進めています。

お客様と一緒にモノを作って行くスタンス姿勢を大切にしており、要件定義から見積もりの妥当性確認まで一貫して取り組んでいます。

また、開発メンバーに見積もりを依頼し、見積り精度を検証する役割を担うこともあります。本日は、これらの経験からお話しできればと考えています。

濱井:NTTコムウェアでPMOをやっております、濱井です。

PMO*3は「正しく作ることを支援する役割」と捉えられがちですが、真の課題は上流工程に潜んでいると考えます。

そのため私は要件定義を中心とする上流工程に興味をもっていまして、IIBA*4日本支部で理事を務めて8年目になります。IIBAでは要件定義のベストプラクティスを普及させ、社内でも導入を推進してきました。

本日は要件定義と見積もりの最適化について、皆さまと議論できることを楽しみにしてます。

神崎:普段は要件定義の支援をしております。

要件定義や上流工程に強い関心があるため、自ら策定した手法「RDRA」を用いて、関連ツールや情報サイトの開発しています。

見積もりについては20年以上前にファンクションポイント法*5を色々調べたので、昨年の「見積りソン」には懐かしさを覚えつつ参加しました。

藤貫:ファンクションポイント法を活用した見積もりの支援や審査に、約30年携わってまいりました。

その経験から、プロジェクト失敗の主因は要件定義の不備にあると痛感しています。

要件定義の精度は見積もりだけでなく、設計・実装・テストまで連鎖的に影響します。

本日はそのあたりを含め、さまざまなお話ができればと考えております。

haru:藤貫さんは、見積りに関する書籍も出版されてますよね。

藤貫:『プロジェクトの「測る化」』という書籍を出版しております。プロジェクトにおける Q(品質)・C(コスト)・D(納期)・S(スコープ)の測定方法の重要性を解説しています。

haru:参加者の皆さん、よろしければご一読ください。

haru:私はモデレーターを務めます、ビープラウド代表の佐藤治夫と申します。

2006年の創業以来、案件獲得のために見積もり業務を一貫して担当し、会社が提出するすべての見積もりに責任をもっています。

見積もりの精度とお客様の納得感を最優先に、日々注意を払っています。

内製と外部委託で異なる見積もりのポイント

haru:事前に参加者の方からいただいた質問から始めます。

ユーザー企業が社内で内製する場合と外部に委託する場合で、見積もりのポイントや注目すべき違いがあれば知りたい」ということです。

濱井:私の場合、SIerとしてお客様に見積もりを提出することもあれば、パートナーさんに見積もりをお願いすることもあります。

内製と外部委託では、マネジメント予備やリスク対応に対する考え方が異なるのではないかと思いました。

神崎:内製であれば、お金よりも工数の話がメインになるのではないでしょうか。

haru:内製のほうが、問題発生時にも柔軟に対応できる可能性が高いですね。
もちろん会社の文化にも左右されますが、内製体制であれば迅速な判断や調整がしやすい傾向があります。

一方、外部委託の場合は、契約や手続きの制約があるため、問題が表面化しやすく、対応が難航するケースが多いと思われます。

高崎:弊社では、外部からの受託開発と自社サービスの内製の両方を手がけています。

弊社の場合ですが、内製のほうが、算出された見積工数に対してシビアな傾向があると感じています。

同じエンジニア同士であることも影響していると思いますが、「なぜそんなに工数がかかるのか」と問う場面もあれば、逆に「その工数では対応できないのでは?」と指摘する場面もあります。

藤貫:私もSIerとして濱井さんと同様の立場にあります。

内製する場合には、見積もりだけでなく、体制や配置される人員のスキル・リソース状況も含めて総合的に検討する必要があると考えています。

特に見積り時には、計画とリスクを併せて見極めながら進めることが重要です。

外部委託契約においては、文化やプロセスの違いに加え、同じ契約文書でも発注側と受注側とで解釈が異なるケースがあるため、事前の認識合わせと細やかな確認が欠かせません。

haru:以前、某企業と外資系企業との間で、既存システムのリプレース開発案件に関する訴訟のニュースが報じられました。

そのニュースのコメント欄では、既存の開発会社である国内メーカー系企業が、追加や変更に対して「良きに計らって」対応していたのに対し、リプレース後のシステム開発を担当する外資系企業は、そのたびに追加見積もりを提示したため、問題に発展したのではないか、という意見が見られ、なるほどなと思いました。あくまで推測のコメントにすぎませんが。

濱井:発注側と受注側でどちらに非があるかは一概には言えませんよね。

次回は、「見積りの説明責任、タイミング、スコープマネジメント、インプットの粒度や精度」をテーマに、話を進めます。

この記事を書いた人
haru

佐藤治夫。株式会社ビープラウド代表取締役社長。TRACERYのプロダクトマネージャー。エンジニアとして活動を始めて以来、モデリングを中心としたソフトウェアエンジニアリングを実践している。Xアカウント: https://x.com/haru860

*1:モデルベースのビジネスとシステムの可視化手法。To-Be用途では要件定義に使え、As-Is用途では、既存システムの可視化に使用できる。RDRA公式サイト

*2:紹介資料:見積りと提案の力を競う見積りソン

*3:Project Management Officeの略。プロジェクトの標準化や支援、成功確率の向上を目的とした専門組織。

*4:International Institute of Business Analysisの略。ビジネスアナリシスの国際的な非営利団体。ビジネスアナリシスの専門家育成や、ビジネスアナリシスの方法論(BABOK)の普及などを目指している。

*5:ソフトウェア開発の規模を計測し、工数見積もりを行うための手法。ユーザーが利用する機能に着目し、その機能数や複雑さなどを数値化して「ファンクションポイント (FP)」として算出し、開発規模を評価する