本文へ移動
実装と知見

内製か、外注か。費用・依存・主導権から考えるシステムづくり

#内製と外注#システム開発#業務改善

誰が担い、何を引き継ぐか。

企業サイトと問い合わせ受付を題材に、仕事・情報・利用条件のつながりを動かします。

図の全体を見比べるには、PCブラウザでの閲覧をおすすめします。

独立した架空例です。各方法の一例を比べる図で、最適な方法を判定する診断ではありません。

つくり方を選ぶ
同じつくり方で、引継ぎの準備を変える

チェックは、必要な利用許諾・権限と共有資料が用意された場合の仮定です。所有権の譲渡や、移行の成功を表しません。

外注の役割分担例通常の運用

決める

自社掲載内容と受付のルール比較・要件整理は外部の支援も使える

つくる

外部パートナー合意した範囲を実装する自社が操作と受入条件を確かめる

使い続ける

外部パートナー合意した範囲を保守する問い合わせへの対応は、どの方法でも自社

情報

共有前の仮定外部の担当だけが知る情報業務ルール・数字の定義・判断理由・運用手順
仕事・情報を渡す次の担当へ渡す前に確認が必要
資料共有:共有前の仮定利用条件:未確認の仮定

この方法が合う条件と負担

対象と完了時の確認条件を整理でき、必要な専門性を外部から得たい場合。

想定外の変更、追加費用、保守と契約終了時の扱いを確かめます。範囲を決める支援も外部へ相談できます。

説明・調整の負担
開発の専門性を使えます。依頼先を探し、業務・受入条件を説明し、変更の範囲と費用を調整する仕事は残ります。
関係への依存
業務や実装への理解が深まるほど、その担当へ頼む利点と、別の相手へ説明し直す負担が生まれます。
変更・移行の条件
引継ぎ先が判断理由をたどれるか、必要なデータ・コード・環境を使えるかが未確認です。
次に確かめること
  • 業務ルール、数字の定義、判断理由、更新・復旧の手順を誰が共有するか。
  • データの取出し、コードの利用・変更、環境の管理、他社保守、終了後の利用・移行を認められるか。
  • 次の担当が動作を再現できるか。引継ぎの作業範囲・費用・時期を誰と合意するか。

共有と利用条件を確かめても、移行費用・互換性・実際の運用能力は別の確認事項です。

図の三つの仕事すべてを、説明の負担・関係への依存・利用条件から見ます。詳しい考え方は、続く本文で説明します。

システムづくりの選択は、開発料金と社内担当者の給与だけでは決まりません。 依頼内容を説明する仕事、変更を調整する仕事、使い続けるための知識と権限も含めて考えます。

すべてを内製する必要はありません。範囲を決めた外注、標準機能を使う既存サービス、継続的な共同開発にも、それぞれに合う条件があります。「何を自社で判断するか」「どこに外部の力を使うか」「何を自社に残すか」を、仕事ごとに分けると比較しやすくなります。

上の図は、説明用に独立して作った「企業サイトと問い合わせ受付」の例です。つくり方を選び、資料の共有と利用条件を変え、担当の引継ぎを試せます。実際の顧客や契約を再現したものではありません。

この記事では、企業・契約に関する三つの研究を手がかりにします。研究の考え方と、ITの依頼に置き換えた実務上の問いを分けて説明します。研究者名と一次資料は末尾の参考資料にまとめています。

料金のほかに、説明と調整の仕事を見る

外部へ頼むには、相手を探し、仕事を説明し、条件を交渉し、実施した内容を確認する負担があります。一方、社内で行う場合も、管理や調整の負担がなくなるわけではありません。外部との取引と組織内の調整、それぞれの費用を比べることが、企業の範囲を考える出発点になります。参考資料1

ITの依頼では、見積金額に加えて、次の仕事を並べてみます。

比較する仕事 内製で確かめること 外部の力を使う場合に確かめること
担当を確保する 採用・育成・欠員への備え 依頼先の探索、対応範囲と継続性
業務を実装へつなぐ 部門間の説明、仕様の整理、レビュー 業務と例外の説明、要件と受入条件の合意
変更を進める 他の仕事との優先順位、社内承認 変更範囲、追加費用、時期の調整
使い続ける 保守・障害対応・引継ぎの担当 保守範囲、利用料、変更・終了時の条件

既存サービスを使う場合も、機能の比較、自社の設定、仕事を合わせる手間があります。標準機能で足りるなら、個別開発を減らせる合理性があります。使う人の時間と、維持する仕事を同じ範囲で比べます。

改善計画での実務への応用

当社は、業務を伺った担当者が、要件の整理から設計・実装、導入後の見直しまで担います。帳票と仕事の流れから業務ルールや例外を整理し、画面・データ・確認条件へつなげる進め方です。

担当が変わるたびに説明し直す負担や、業務と実装の認識のずれを減らすことを目指します。ただし、同じ担当者がすべてを記憶しているだけでは、当社への依存が増えます。合意した要件、数字の定義、設計を選んだ理由、運用手順を共有することも、支援範囲として相談します。

詳しく理解する価値と、相手を替える負担を見る

ある相手との仕事のために行った投資は、別の相手や用途へ移すと価値が下がることがあります。たとえば、その相手との運用を学ぶ時間が該当します。ここで見るのは、単に「独自性が高い」「競争上の強みがある」ことではありません。別の関係へ移したとき、どれだけ使い直せるかという性質です。

こうした投資と、予期しない変化への対応を合わせて考えると、一度の価格交渉だけでは決まらない、継続的な関係の設計が必要になります。社内での管理、外部との契約、その中間にある継続的な協働を比較する視点です。参考資料2

ITの仕事では、変更の調整方法まで決める

顧客固有の業務ルールや例外を理解し、運用に慣れた担当者には価値があります。その理解を得るには時間がかかるため、担当を替える際にも学び直しが必要になります。これは、社内の担当者にも外部の支援会社にも起こります。

将来の不確実さは、仕様変更の回数だけでは表せません。法令や利用するサービスの条件、取引先との受け渡し、担当体制が変わることもあります。変更の内容や影響が、着手時には分からない場合があります。

継続的に一緒につくる場合は、次の調整方法を確認します。

  • 今の契約で対応する変更と、追加の合意が必要な変更をどう分けるか。
  • 優先順位、追加費用、実施時期を誰と決めるか。
  • 業務ルール、数字の定義、判断理由をどこへ残し、誰が更新するか。
  • 担当者や会社が変わるとき、何を渡し、どの動作まで確かめるか。

専用の理解が必要だからといって、必ず内製がよいとは限りません。知識の共有、変更の合意、引継ぎを組み込んだ外部との関係も選択肢です。月額契約を結ぶだけで依存が解消するわけではなく、自社が確認や判断に参加する時間も見込みます。

契約に書き切れない変更を、誰が決められるかを見る

将来の出来事をすべて契約に書き切ることは困難です。書かれていない状況で、対象となる資産をどう使うか、誰が決められるかが問題になります。所有は、その決定を行える立場と関係します。その配分が交渉力を変え、着手前に学習や改善へ投資する動機にも影響する、という考え方です。

一方に決定する力を集めると、その側が投資しやすくなる反面、もう一方の改善への動機が弱くなる場合があります。すべてを一方に帰属させれば常に最適、という結論にはなりません。参考資料3・4

所有、使う権利、ログインできることを分ける

ITの実務では、顧客が要望の優先順位を決めることだけで、変更や移行を進められるとは限りません。データ、コード、環境を、契約終了後もどの範囲で扱えるかを確認します。

分けて確認する項目 具体的な問い
所有権・権利の帰属 データやコードの権利は、何について誰に帰属するか
利用許諾 利用、変更、複製、他社による保守、終了後の利用をどこまで認められるか
アクセス権限 データを書き出せるか。コード、設定、配信・実行環境を誰が管理できるか
実際の運用能力 次の担当が、手順と環境を使って動作を再現し、障害へ対応できるか
移行・終了時の作業 取出し形式、引継ぎ範囲、作業費用、時期、利用停止と削除の扱いは何か

これらは別々の確認項目です。コードの権利があっても、必要な設定や手順がなければ動かせません。管理者としてログインできても、他社による変更や保守が契約上認められるとは限りません。データの書き出しができても、移行先が同じ機能を持つとは限りません。

上の図で「利用・変更・移行の条件を確認する」にチェックすると、必要な許諾と権限がそろう場合を仮定します。所有権がすべて自社へ移ることや、移行の成功を示す操作ではありません。

この表はITの依頼での確認事項です。経済理論から個別契約の法的結論を導くものではありません。契約と、利用する製品・外部サービスの条件を、対象ごとに確認します。当社との契約についても同じです。

四つの方法を、仕事ごとに組み合わせる

選ぶ単位は、システム全体を一括して内製か外注かに分けることだけではありません。「掲載内容を判断する」「画面をつくる」「問い合わせに対応する」「基盤を保守する」のように仕事を分け、それぞれの方法を比較できます。

方法 合いやすい条件 残る負担・確かめる条件
内製 業務理解と開発・運用の担当を確保し、継続して育てられる 担当者の時間、採用・育成、レビュー、欠員と属人化への備え
範囲を決めた外注 対象と確認条件を整理でき、必要な専門性を外部から得たい 説明・受入、想定外の変更、保守、引継ぎ・終了時の合意
既存サービス 標準機能と利用条件が業務に合う 設定と日々の運用、機能の制約、利用料、データの取出しと移行
継続的な共同開発 利用しながら見直す必要があり、自社も確認と判断に参加できる 参加時間、変更範囲と費用、知識共有、当社を含む相手への依存

架空の企業サイトなら、掲載内容と問い合わせ対応は自社、標準のフォームは既存サービス、個別の連携は外部開発、と分ける案もあります。業務が安定している部分と、試しながら見直す部分で進め方を変えても構いません。

一度決めて終わりにせず、担当体制、必要な変更、使うサービスの条件が変わった時点で見直します。原価管理なら計算ルールと確認担当、AIによる社内検索なら参照資料の権限と更新担当など、判断する対象に応じて問いを具体化します。

事業の判断は、御社に。仕組みづくりは、一緒に。

改善計画は、中小企業診断士として経営・業務を整理する視点と、エンジニアとして設計・実装する両面から支援します。今の帳票と仕事の流れを確認し、選択肢、必要な情報、費用と役割を一緒に整理します。事業上の判断をしていただく前の、判断材料をつくる仕事から相談できます。

現場を理解し、小さくつくり、実際の利用を確かめて見直す。使い続けることと、次の担い手へ渡すことを、どちらも設計時の確認事項に含めます。当社が継続して担う部分と、自社や他の相手が担う部分も相談して決めます。

業務ルール、数字の定義、判断理由、運用と引継ぎの共有範囲、コードの利用条件、環境の管理、契約終了時の作業は、対象ごとに合意する項目です。無制限の支援、全権利の譲渡、将来の移行を保証する約束は、この説明には含めません。

依頼できる支援と進め方は、IT化・DX支援の役割分担で説明しています。自社の業務で、役割分担を整理するという段階からご相談いただけます。参考予算と条件は料金ページをご覧ください。

関連する設計の考え方

参考資料

本文の三つの視点は、次の一次資料を参照しています。ITでの問いと操作図は、当社による実務への応用です。各研究そのものの診断器や実証結果ではありません。資料は新しいタブで開きます。

  1. Ronald H. Coase, The Institutional Structure of Production(1991年講演)(新しいタブで開きます)。市場での取引費用と、組織内で調整する費用から企業の範囲を考える説明を参照。
  2. Oliver E. Williamson, Transaction Cost Economics: The Natural Progression(2009年講演・PDF)(新しいタブで開きます)。資産特殊性、予期しない変化への適応、取引を支える関係の設計を参照(本文pp.463–465、PDF pp.9–11)。
  3. Oliver Hart, Incomplete Contracts and Control(2016年講演・PDF)(新しいタブで開きます)。不完備契約、所有に伴う残余コントロール権、交渉力と事前の投資への影響を参照(本文pp.373–375、PDF pp.3–5)。
  4. The Royal Swedish Academy of Sciences, Contract Theory: Scientific Background(2016年・PDF)(新しいタブで開きます)。契約理論の背景と、所有・投資の関係の説明を参照(本文pp.20–23、PDF pp.22–25)。