内製化と外注で迷う背景と、判断がぶれる典型パターン

Web制作は「作って終わり」ではなく、公開後の更新・改善まで含めて成果が決まります。ところが、リニューアルや制作会社の切り替えを検討する局面では、社内の不満や焦りが先に立ち、内製化と外注のどちらが良いかを結論から探しがちです。その結果、費用・体制・リスク・成果の論点が混ざり、意思決定がぶれます。

経営者・事業責任者の立場で見たとき、迷いが生まれやすい背景は大きく3つあります。

1つ目は、社内の期待値が部門ごとに違うことです。営業は問い合わせ増、採用は応募増、情シスは安全な運用、といった具合に目的が分散します。情シスとは、社内の情報システム部門を指します。目的が分散したまま「サイトをきれいにする」「更新を早くする」など手段だけが先行すると、内製化・外注の判断軸が定まりません。

2つ目は、現場の困りごとが「構造の問題」か「実行の問題」か切り分けられていないことです。たとえば、更新が遅い原因が、外注先のレスポンスではなく社内承認フローにあるケースもあります。逆に、社内担当が1人に偏って属人化している場合は、内製化を進めても速度が上がらないことがあります。属人化とは、業務が特定の人に依存する状態を指します。

3つ目は、ベンダーとは制作や運用を請け負う外部企業を指しますが、そのベンダーの役割を「作業者」と見なすか「一緒に設計する相手」と見なすかで期待が変わる点です。前者の前提で発注すると、要件が固まらないまま見積比較に入り、提案が比較不能になりやすいです。後者の前提なら、要件定義とは目的と制約のもとで実現すべき範囲・品質・機能を文章化する工程を指しますが、その要件定義の支援も含めて依頼する設計になります。

判断がぶれる典型パターンを整理すると、次のようになります。

• 目的が曖昧なまま見積を取り、金額だけで判断して後から手戻りが増える
• 「更新が遅い＝外注が悪い」と短絡し、承認フローや素材準備の問題を放置する
• 内製化を掲げたが、採用・育成・評価が追いつかず、結局外注が増えて二重投資になる
• 外注を続けたが、仕様や運用が共有されず、軽微な改修でも時間と費用がかかる

ここで大切なのは、内製化か外注かの二択ではなく「どの業務を、どの品質とスピードで、誰が責任を持って回すか」を先に決めることです。以降の章では、そのための整理手順を、事業目的→費用→体制→リスク→成果の順で揃えていきます。

まず整理する：事業目的・サイトの役割・制約条件

最初にやるべきは、サイトで解決したい問題を言語化し、目的を具体化することです。デザインやUIの話はその後で十分に間に合います。UI/UXとは、UIは画面や操作部品など見た目と操作の設計、UXは利用体験全体の設計を指します。目的が具体化されていないと、UI/UXをどれだけ整えても「成果につながったか」が判断できません。

整理は次の4点に絞ると、経営判断に必要な材料が揃います。

1) 事業目的を数値に落とす

「売上を伸ばす」「問い合わせを増やす」だけだと、社内で優先順位が決まりません。たとえば、商談獲得を主目的にするなら、問い合わせ件数だけでなく、有効商談率や受注までのリードタイムも見る必要があります。リードタイムとは、作業開始から完了までの所要時間を指します。KPIとは、目標達成度を測るための重要指標を指します。KPIは1つではなく、上流（閲覧・回遊）から下流（問い合わせ・商談）までの因果が追える形にします。

2) サイトの役割を分解する

BtoBのサイトは「会社の信用」「サービス理解」「比較検討の後押し」「問い合わせの獲得」が同居しがちです。BtoBとは、企業間で取引が行われるビジネスを指します。役割が多いほど設計は複雑になり、内製化だけで回す難度が上がります。逆に、役割が明確で更新頻度が高い領域は、内製化の効果が出やすいです。

3) 制約条件を先に棚卸しする

制約は後から出るほどコストが膨らみます。代表例は、既存CMSの制約、セキュリティ要件、法務レビュー、複数部署の承認、既存の営業資料との整合、などです。CMSとは、専門知識がなくてもWebページを更新できる管理システムを指します。CMSを変えるか据え置くかで、制作だけでなく運用の難度も変わります。

4) 体制の前提を固定する

社内で誰が最終決裁し、誰が情報を集め、誰が原稿を用意し、誰が公開作業をするか。ここが曖昧だと、外注してもプロジェクトは止まります。PMとは、納期・予算・品質を管理しプロジェクトを推進する責任者を指します。社内PMがいない場合は、外部のPM支援を前提にしたほうが、結果としてTCOを抑えられることもあります。

この整理ができると、内製化と外注の比較は「好み」ではなく「目的達成に必要な仕組み」の比較になります。

費用の判断軸：制作費ではなくTCOで比較する

費用の比較で起きやすい落とし穴は、見積金額だけで判断し、公開後の運用・改善にかかるコストを見ないことです。TCOとは、初期費用だけでなく運用・保守・改修まで含めた総コストを指します。内製化でも外注でも、TCOで見ると見え方が変わります。

内製化の費用は「制作費」ではなく「体制維持費」に近い形になります。採用・育成・評価の仕組み、業務が回るまでの立ち上げ期間、属人化を防ぐドキュメント整備などが効いてきます。外注の費用は、初期制作に加えて、改修の都度見積や保守費、緊急対応の有無、移管時の追加費用が効いてきます。

費用項目	内製で発生しやすい要素	外注で発生しやすい要素	見落としやすい点
人件費	採用・育成・評価、繁忙期の残業	不要（ただし窓口工数は残る）	担当者が抜けた際の引き継ぎコスト
制作・改修費	工数は社内吸収、優先順位付けが重要	都度見積、要件が曖昧だと膨らみやすい	軽微改修が積み上がると年間費が読みにくい
ツール・環境費	開発環境、検証環境、解析ツールなど	保守費に含まれる場合と別の場合がある	権限管理や監査対応の追加コスト
品質・再現性	ルール化・レビュー設計が必要	標準化されている会社だと安定しやすい	ドキュメント不足は内製・外注どちらでも破綻要因

TCOで比較する際は、少なくとも「初期＋1年運用」の範囲で試算し、次に「2〜3年での組織定着」を別枠で見ます。内製化は立ち上げ期の投資が大きく、外注は運用の積み上がりが見えにくい傾向があります。経営判断としては、単年度の安さよりも、事業スピードと品質を維持できるかを含めた総額で比較するほうが、後からの失点が減ります。

体制の判断軸：役割分担と意思決定フローを先に決める

内製化と外注の議論が迷走する最大の原因は、「誰が何に責任を持つか」が曖昧なまま作業の話に入ることです。結論から言うと、社内に残すべきは“成果責任”で、外部に任せやすいのは“作業責任”です。成果責任は、目的・KPI・優先順位・最終承認に対して説明できる状態を指します。

役割分担はRACIで固定する

RACIとは、業務ごとに実行責任・最終責任・相談先・共有先を整理し、意思決定の迷子を防ぐ枠組みを指します。たとえばリニューアルでは、少なくとも次の4領域を分けて考えると整理が早いです。

• 目的と要件：事業目的、KPI、ターゲット、コンセプト、要件定義
• 体験と表現：情報設計、UI/UX、デザイン、コピー
• 実装と品質：CMS設定、実装、テスト、公開
• 運用と改善：更新フロー、アクセス解析、改善ロードマップ

このうち「目的と要件」は社内が主導しないと、外注でも良い提案は出ません。逆に「実装と品質」は再現性が重要なため、外部の専門チームに寄せたほうが安定しやすい領域です。みやあじよでも、表現や集客の前に目的とコンセプトを言語化することを重視しています。

内製化で最低限持つべき「3つの役」

「内製化＝制作ツールを触れる人を増やすこと」と捉えると失敗します。公開後に成果を出すには、制作スキル以前に“運用が回る役割”が必要です。ディレクションとは、関係者を調整し制作を前に進める実務を指します。

• 事業の責任者：目的・優先順位・投資判断を行う（最終責任）
• 編集の責任者：原稿・事例・更新テーマを集め、品質を担保する（コンテンツの責任）
• ディレクション役：外注管理も含めて進行・レビューを設計する（実行の責任）

この3つが揃うと、外注を使ってもスピードと品質が落ちにくくなります。逆に、誰か1人に背負わせると属人化し、内製でも外注でも詰まりが起きます。

意思決定フローを短くし、手戻りを減らす

同じ人数でも、決め方が遅いとコストは増えます。ここでのポイントは「会議を増やす」ではなく「決める人を減らす」ことです。

• 最終承認者は1人に固定し、承認条件（法務・ブランド・セキュリティ）を先に文章化する
• 週次で“決める会”を置き、判断待ちの状態を溜めない
• 変更要求は優先順位と一緒に管理し、やる・やらないを即決できる状態にする
• レビューの観点を固定する（目的に効くか／ユーザーが迷わないか／更新しやすいか）

また、内製化を進める場合ほど「作れる人」より「整理して伝えられる人」が重要になります。みやあじよが良いデザインに含める要素として挙げている「やりたいけど分からないことの言語化」は、内製・外注のどちらでも成果に直結する役割です。

リスクの判断軸：契約・権限・移管・セキュリティの見落としを潰す

内製化・外注のどちらを選んでも、リニューアルで痛手になりやすいのは「資産が手元にない」「責任範囲が曖昧」の2点です。リスクは“起きてから”だと高くつくため、事前に潰せるものから潰します。

ブラックボックス化を防ぐのは「資産」と「権限」の管理

移管とは、運用や管理の主体を別の組織へ移すことを指します。ベンダー変更を前提にするなら、最初から移管できる形で持つべき資産があります。代表的には次の通りです。

• ドメイン、DNS、サーバー、SSLなどの契約情報
• CMSやホスティングの管理アカウントと権限設計
• ソースコード一式、仕様書、デザインデータ、画像・文章の権利関係
• 解析や広告、タグ管理などの計測設定

DNSとは、ドメイン名とサーバーの所在地を紐づける仕組みを指します。
SSLとは、通信を暗号化して盗聴や改ざんを防ぐ仕組みを指します。

「どこに何があるか」が説明できない状態は、外注の問題というより社内統制の問題になりやすいです。内製化に振る場合でも、資産管理が弱いと担当者交代のたびにスピードが落ちます。

著作権・利用許諾は“後で揉める”代表例

著作権とは、文章や画像などの創作物を利用・改変する権利に関する法的な枠組みを指します。デザインデータや写真、フォントなどは、制作が終わってから「自由に使えない」ことが判明すると、作り直しになります。見積比較の段階で、納品物の範囲と利用条件は確認し、社内で保管できる形に揃えます。

契約と運用の境界線を文章で固定する

SLAとは、運用保守での対応時間や品質基準を数値で取り決める合意事項を指します。保守とは、システムを安定稼働させるための監視・更新・障害対応を指します。外注の契約では、制作範囲だけでなく保守範囲も曖昧になりやすいので、少なくとも次の観点は明文化します。

• 緊急対応の有無（夜間・休日）、初動の時間、復旧までの目安
• 軽微改修の扱い（定額に含む／都度見積）、月間の上限
• セキュリティ更新の責任分界（CMS本体、プラグイン、サーバー）
• 退任・解約時の引き継ぎ物と期限
• 障害時の連絡経路と、誰が社内説明を行うか

脆弱性とは、攻撃者に悪用され得る欠陥を指します。セキュリティ要件がある企業ほど「誰が、どの頻度で、何を更新するか」を曖昧にしないことが重要です。

効果の判断軸：KPI設計と改善サイクルを内製・外注のどちらで回すか

費用と体制とリスクを整えても、成果の測り方と改善の回し方が決まっていなければ、リニューアルは“きれいになっただけ”で終わります。経営判断として重要なのは、公開後に伸びる仕組みを持てるかどうかです。

KPIを「経営KPI」と「運用KPI」に分ける

KPIは一枚岩ではありません。たとえば経営側が見るべきは、商談や受注に近い指標です。一方で運用側は、改善で動かせる指標を持つ必要があります。コンバージョンとは、問い合わせ送信など成果につながる行動を指します。

• 経営KPI：有効問い合わせ、商談化率、受注単価、採用応募の質
• 運用KPI：主要ページの流入、回遊、離脱、コンバージョン率、フォーム完了率

この分解ができると、内製化すべき領域も見えます。運用KPIを日常的に見て改善を回すなら、社内に最低限の分析・意思決定の役割が必要です。外注に任せる場合でも、KPIの読み解きと優先順位付けは社内が持つほうが、投資対効果の説明がしやすくなります。

改善サイクルを「設計」してから作る

PDCAとは、計画・実行・評価・改善を繰り返すマネジメント手法を指します。改善が回る組織は、個人の頑張りではなく“型”を持っています。

• 月次でKPIレビューを行い、次月の改善テーマを3つまでに絞る
• 改修は小さく早く出し、学びを次に反映する
• A/Bテストとは、2パターンを比較して成果の高いほうを採用する検証を指します。大きな改修の前に検証で確度を上げる
• 集客方法（SEO、広告、SNS、展示会後の導線など）とサイト改善を同じ表で管理し、どこに投資するかを見える化する

SEOとは、検索エンジンで見つけてもらうためにサイトやコンテンツを最適化する取り組みを指します。
SNSとは、ソーシャルネットワークサービスを指します。

内製化は「更新の速さ」だけでなく「学習の速さ」を高められる点が強みです。一方で、改善の量が増えるほど品質管理も必要になります。次の章では、内製・外注・ハイブリッドの結論を出すためのチェックリストと、ベンダー選定・乗り換えの進め方を具体化します。

結論の出し方：内製／外注／ハイブリッドの判断基準チェックリスト

ハイブリッドとは、内製と外注を組み合わせて役割を分担する形を指します。結論は「どちらが上か」ではなく、サイト業務を“変化が多い領域”と“再現性が必要な領域”に分けて決めます。

• 変化が多い領域（更新・改善・企画）：社内主導ほどスピードと学習が上がる
• 再現性が必要な領域（実装・品質・保守）：専門チームほど安定しやすい

状況	内製が向く	外注が向く	ハイブリッドが向く
更新頻度が高い	編集・更新を内製化し改善を回す	窓口工数が増えやすい	更新は内製、土台改修は外注
品質・セキュリティ要件が厳しい	標準化できれば強い	体制が整った会社なら安定	要件・承認は内製、実装は外注
短納期で刷新が必要	立ち上げが間に合わない	経験値でスピードが出る	設計は内製、制作は外注
改善を継続して伸ばしたい	学習が溜まりやすい	都度見積が積み上がりやすい	分析・意思決定は内製、制作は外注併用

方向性が決まったら、目的・KPI・優先順位・最終承認は社内に残し、外部には“実行力と品質管理”を求めると破綻しにくくなります。

ベンダー選定・乗り換えの進め方：要件定義から運用設計まで

ベンダー選定の成否は、見積を取る前に「比べられる状態」を作れるかで決まります。RFPとは、要件と選定条件をまとめてベンダーへ提示する提案依頼書を指します。RFPで提案の粒度を揃えると、価格差の理由も説明しやすくなります。

進め方は次の流れで設計します。

1. 現状整理：目的・課題・制約・資産（アカウント、コード、解析）を棚卸し
2. 要件定義：対象範囲と、公開後の運用・改善の回し方まで決める
3. RFP作成：納品物、体制、スケジュール、評価基準を文章化
4. 提案評価：金額だけでなく、進め方・品質管理・移管設計を比較
5. 契約・運用設計：責任分界、保守範囲、解約・移管時の取り決めを明文化

確認観点	提出物・根拠	落とし穴	判断ポイント
要件の理解度	前提条件、除外範囲、想定リスク	「できます」だけ	前提が揃っているか
体制と進行	役割、レビュー回数、進行案	窓口不明で停滞	意思決定の設計があるか
品質と保守	テスト方針、保守範囲	公開後が別契約	責任分界が明確か
移管・引き継ぎ	納品物一覧、権限管理方針	解約時に資産不足	移管手順と期限が入るか

みやあじよの制作方針でも「目的→コンセプト→集客方法とUI/UX設計」の順で設計することを重視しています。要件定義でこの順序を守ると、比較軸が“見た目”から“目的達成”に戻ります。

相談に繋げる：現状整理のテンプレと支援できる範囲

内製化か外注かを最短で決めるには、現状をA4一枚に整理すると議論が前に進みます（箇条書きで十分です）。

• 目的（売上・問い合わせ・採用など）と優先順位
• ターゲットと、伝えるべき強み・根拠
• 現状課題（更新、制作体制、計測、運用）
• KPI（経営KPIと運用KPI）
• 制約（セキュリティ、法務、ブランド、承認フロー、CMS）
• 資産（ドメイン、サーバー、解析、CMS権限、データ所在）
• 体制（最終決裁者、編集責任者、ディレクション役）

当社の支援領域は、要件定義支援、Web制作・リニューアル、PM支援、運用設計です。「やりたいけど分からないことの言語化」を起点に、目的と制約を整理し、比較できるRFPの骨子づくりから伴走します。

まとめ

判断基準は、制作手段ではなく「責任の置き方」です。目的と制約を揃え、TCOで投資判断し、体制とリスクを先に固めた上で、学習が溜まる改善は社内に、再現性が要る実装・品質は外部も使う。この考え方で、内製・外注・ハイブリッドの最適解が出しやすくなります。