2026 年 9 月 1 日更新: 全面的に書き直しました。外注が高くつく構造に IPA・公正取引委員会・JUAS の一次データを付け、看板の「1 年 vs 1 ヶ月」を検算する章を新設。生成 AI の章は旧版の「AI を使えば Python 経験 1 年程度でも実用的なコードを書ける」という断定を撤回し、METR と DORA の実証データに基づく記述へ改めました。
1. 結論 — 内製が効くのは「止まっても困らない・小さい・仕様が社内にある」もの
「外注か内製か」という立て方では結論が出ません。決めるべきは どの業務を内製に回すか であって、会社の方針としてどちらに寄せるかではないからです。内製が外注より速く安くなるのは、次の 3 条件が揃ったときだけです。
- 止まっても人が困らない。設備が止まる、人が危ない、法令記録が欠ける——このいずれかに触れる機能は、内製の対象から外します。集計が半日遅れる程度で済むものだけが候補です
- 作る範囲が小さい。4 章で見るとおり、外注案件の工数の中央値は 1 人月換算で 40 人月を超えます。同じものを 1 ヶ月では作れません。範囲を絞ったから 1 ヶ月で済む、という順序です
- 仕様を決める人が社内にいる。外注が長引く最大の原因は、実装ではなく仕様が決まらないことです。決める人が社内にいて、画面を見ながらその場で直せるなら、工程の大半が消えます
逆に、この 3 条件のどれかが欠けていれば、内製は外注より遅く・高くつきます。仕様が固まっていない案件を内製で始めれば、社内で仕様書のラリーをするだけです。
本記事は特定の SIer や外注ビジネスを否定するものではありません。基幹システム、複数拠点をまたぐ基盤、24 時間の運用保守が要る領域は、外部パートナーと組むほうが合理的です。扱うのは、その線を自分の現場で引き直す方法です。
2. ケーススタディ — 架空企業 A 社（数値はすべてダミー）
2.1 状況設定
従業員 200 名規模の中小製造業で、産業機器の組立・検査を行うメーカー。検査工程の設備は PLC で動いており、稼働ログを Excel で手集計しています。月末の集計に毎回 20 時間。これを自動取得して画面に出し、月次レポートまで自動生成したい、というのが要件です。
2.2 2 つのルートの見積もり（ダミー）
外注ルート: SIer 3 社の提案は、A 社が 12 ヶ月・1,800 万円・月額保守 30 万円、B 社が 9 ヶ月・1,500 万円、C 社がフル機能版で 14 ヶ月・2,200 万円。3 社とも要件定義から受け入れまでのウォーターフォール工程で、ヒアリングだけで 2〜3 ヶ月を見込みます。
内製ルート: 担当は生産技術エンジニア 1 名（Python 経験 1 年程度）と外部メンター（スポット契約の技術顧問などを想定）。使うのは Python と pymodbus・pandas・Streamlit・SQLite で、いずれも無償で使えます。期間は試作 2 週間と 1 ラインでの限定運用 2 週間の計 1 ヶ月、費用は人件費 1 ヶ月分とメンター費 30 万円・PC 20 万円で合計 100〜150 万円程度。項目ごとの比較は 9.3 の表にまとめました。
2.3 なぜ 1 ヶ月で終わるのか — 成立条件は 5 つ
1 ヶ月で終わるのは、外注案件と同じものを速く作れるからではありません。作る範囲が違うからで、A 社の内製案が 1 ヶ月に収まるのは次の 5 つが同時に成立しているときだけです。
- 対象を 1 ラインに絞っている。全工場に広げると、通信仕様の違いと例外処理で工数が跳ね上がります
- 設備には書き込まない。読み出しだけなら検証範囲が小さくて済みます。書き込みを入れた瞬間、安全確認と品質保証部門の承認が別工程として乗ります
- 仕様を決める人が作る人と同じ。集計項目を決めるのも、画面を見て「この列は要らない」と言うのも同じ人です。要件定義書も承認のラリーも発生しません
- 止まっても生産は続く。設備は動き続けるので、完成度 100% を待たずに現場へ出せます。契約で品質を保証する外注では、この省略ができません
- 既存の運用を置き換えない。Excel の手集計と並走させ、移行の判断を後回しにする分、初期の要件が小さくなります
裏を返すと、全社展開が前提、設備への書き込みがある、仕様を決める人が別部署にいる、のどれか 1 つでも当てはまれば 1 ヶ月では終わらず、見積もりは月単位で膨らみます。「内製なら 1/10」という一般法則はありません。あるのは「範囲を 1/10 以下に絞れる業務が現場にはかなりある」という事実です。
3. なぜ外注は高く長くなるのか — 6 つの構造
外注の見積もりが高いのは、悪意でも怠慢でもなく、日本のソフトウェア開発が置かれた構造から出てきた数字です。ここを理解すると、値切る以外の打ち手が見えます。
3.1 作れる人が、そもそもベンダー側にいる
IPA が国勢調査と米国労働統計局のデータを突き合わせた集計では、日本の情報処理・通信従事者のうち 73.6% が IT 企業に所属し、IT 企業以外（ユーザー企業）は 26.4% です（2020 年・総数 1,253,930 人）。米国は逆で、IT 企業 35.1% に対し IT 企業以外が 64.9%（2021 年・総数 4,981,090 人）。日本の比率は 2015 年からほとんど動いていません。
日本のユーザー企業は、ソフトウェアを作る能力を自社に置かない前提で組織を作ってきました。社内に人がいないので外に頼み、外に頼むから経験が残らず、次も外に頼みます。外注が高いのは価格交渉の問題ではなく、この循環の結果です。
3.2 発注した工数の 6 割は、さらに外へ出る
IPA「ソフトウェア開発分析データ集2022」で外部委託の比率を回答した 562 件では、外部委託の工数比率の中央値が 63.4%（P25 は 41.5%、P75 は 79.4%）と報告されています（表1-3-2.1）。金額比率でも回答 54 件の中央値が 40.0%（表1-3-2.2）。発注した工数の 6 割強は、さらに外へ流れています。
この構造は公正取引委員会が調べています。2022 年 6 月、資本金 3 億円以下のソフトウェア業 2 万 1000 社への調査を公表し、多重下請構造型のサプライチェーン上を、買いたたき・減額・支払遅延・不当なやり直しといった違反行為が連鎖していると指摘しました。買いたたきの経験があるという回答は 15.7%、不必要な「中抜き」事業者の存在を感じたことがあるは全体の 25.9%、最終下請では 33.5% です。
ただし、これは「元請が中抜きしている」という告発ではありません。層が増えれば各層で契約・進捗管理・品質保証の実務が発生し、手間には対価が要ります。問題は発注側からその総量が見えないまま総額に乗ることです。なお SIer の人月単価に公的な相場統計は見つからず、本記事では単価を断定しません。
3.3 現場の暗黙知を伝えるところから始まる
外部の開発者は、PLC の構成・ライン編成・品質基準・承認フローを一から学ぶところから始めます。それだけで数週間から数ヶ月かかり、その間は発注側のキーパーソンの時間も同じだけ奪われます。やっかいなのは文書化されていない情報で、「この設備は冬になると値が少しずれる」といった条件は聞かれなければ誰も言わず、受け入れテストで要件漏れとして出てきます。暗黙知を持っている人が作れば、この伝達そのものが発生しません。
3.4 プロジェクトの 97.2% がウォーターフォール
同じデータ集2022 では、開発ライフサイクルモデルの内訳がウォーターフォール型 97.2%（1,339 件）、反復型 2.1%、その他 0.7% と報告されています（図1-3-1）。要件定義書・基本設計書・詳細設計書と承認のラリーを積み上げる進め方は、契約で品質と納期を保証する以上は意味がありますが、「画面の並び順を変えたい」程度の変更も書類の改訂を伴い、反映に数日から数週間かかります。
作る人と決める人が同じなら、画面を見ながらその場で直せます。安くなるのは人件費ではなく、合意形成の工程が消えるからです。
3.5 リスクの分の価格と、上がり続けるベンダー価格
受注側は「動かなかった」「想定と違った」に契約上の責任を負い、その余裕を見積もりに乗せます。内製で同じ金額にならないのは、責任を自社が引き受けているからで、リスクが消えたわけではありません。
加えて価格そのものが上がっています。JUAS（日本情報システム・ユーザー協会）の「企業IT動向調査2026」は、東証上場企業とそれに準じる 4,500 社に依頼し 957 社が回答したもので、2025 年 9〜10 月の実施です。この調査では、2025 年度に IT 予算が増加すると答えた企業が 52.6%、その理由の第 2 位が 「円安・人件費高騰・ベンダー提供価格の値上げ等の影響」で 46.6% でした（1 位は既存システムの刷新・更新・増強で 66.3%）。「外注は高い」ではなく「外注はさらに高くなっている」が 2026 年時点の実情です。
3.6 引き継げない形で作られる
外注で作られたシステムが、そのベンダー独自のフレームワークや命名規則で実装されることがあります。別のベンダーに引き継げず、社内でも直せず、保守費用が発生し続ける状態です。
これは個社の不満ではなく、政府が対策を明文化している構造問題です。デジタル庁の情報システム調達改革検討会は 2023 年 3 月の報告書で、「ベンダー独自仕様の組み込みや知的財産権に係る制限によっても、ベンダーロックインが生じている」と述べ、コストの高止まりを課題に挙げて疎結合化やオープンな技術の促進を施策に掲げました。経営層への説明では、「担当者が使いにくいと言っている」ではなく「国が調達改革の論点として扱っている」と言えることの重みが効きます。
内製にも同じ問題は起きます。作った本人しか読めないコードは、社内版のロックインです。対策は 11 章にまとめました。
4. 「1 年 vs 1 ヶ月」は妥当なのか — 公的ベンチマークで検算する
2 章のダミー数値が現実の分布のどこに位置するかを公開データで確かめます。使うのは IPA「ソフトウェア開発分析データ集2022」（2022 年 9 月 26 日公開）。5,546 件のうち直近 6 年分の 1,479 件が分析対象で、対象業種の内訳では製造業が 202 件・13.7% を占めます。
4.1 「外注 12 ヶ月」は業界の分布の中にある
同データ集の表1-3-3「プロジェクト全体の月数」は、N=1,396 に対して中央値 10.1 ヶ月、P25 が 6.0 ヶ月、P75 が 15.0 ヶ月、最小 0.3 ヶ月、最大 52.7 ヶ月。1 年以内に収まるプロジェクトはおよそ 6 割と報告されています（図1-3-3）。2 章の「外注 12 ヶ月」は、中央値と P75 のあいだにあるごく普通の値でした。相見積もりで「1 年」と言われたなら、吹っかけられているのではなく相場です。
4.2 「内製 1 ヶ月」は中央値の 40 分の 1 以下の話
工数を見ると、話の性質が変わります。表1-3-4「プロジェクト全体の工数（人時換算）」の中央値は 7,395 人時（P25 が 3,105 人時、P75 が 20,446 人時）。1 人月を 160 時間で換算すると中央値は約 46 人月、P25 でも約 19 人月です。対して 2 章の内製案は 1 人が 1 ヶ月、約 160 人時。差は 10 倍ではなく 40 倍以上あります。規模で見ても同じで、同データ集の SLOC 規模（コメント行と空行を除いたコード行数）の中央値は 31.8KSLOC。1 ラインの稼働ログを集めて画面に出すツールは、ふつう数百行から数千行に収まります。
これは内製が 40 倍速いという意味ではなく、作っているものが違うという意味です。したがって正直な言い方はこうなります。「外注 1 年が内製 1 ヶ月になる」のではなく、「外注で 1 年かかる規模の要件から、1 ヶ月で作れる範囲だけを切り出せることが多い」。切り出せるかどうかが判断の本体で、切り出せない要件は内製しても 1 ヶ月では終わりません。
金額の物差しも、この工数から作れます。約 46 人月に自社の人月単価を掛ければ、目の前の見積もりが分布のどのあたりかを言えます（公的な単価統計が無いため、本記事は単価を示しません）。「高いか安いか」ではなく「何人月分の見積もりか」で話すほうが先に進みます。
稟議でも同じです。「1/10 になります」ではなく「1 ライン・読み出しのみ・既存運用は残す、という範囲に限定した見積もりです」と書けば、範囲の議論に持ち込めます。
4.3 このデータを使うときの限界
IPA 自身が、このデータ集の読み方に注意を書いています。引用する側として同じ場所に並べます。データ提供企業は無作為抽出ではありません。IPA は「定量的管理されたプロジェクトの統計情報と見るのが妥当」であり、生産性・信頼性の統計は「世間相場観よりも良い値を示している可能性がある」としています。中央値 10.1 ヶ月は、管理が行き届いた側の数字かもしれません。母数も項目ごとに違い（工期 N=1,396・工数 N=1,444・外部委託比率 N=562）、製造業は全体の 202 件・13.7% で、引いた中央値は全業種を合わせた値です。
そして 2022 年版が最後です。IPA は事業終了に伴い今後の発行予定はないと公式ページに記載しています。外注の妥当性を公的データで検証しようとしても、参照できる最新の数字が 2022 年で止まっている。だからこそ自社で実測を取る価値があります。1 件でも内製の実績を作れば、次の判断は他人の中央値ではなく自社の数字で行えます。
5. 内製・外注・購入の判断基準 — 5 つの問いで振り分ける
判定は次の 5 つの問いでほぼ決まります。上から順に見て、止まったところが答えです。
各問いの意図です。
- 止まったとき困るのは、人か設備か。人の安全と設備の停止に関わる機能は候補から外します（Python に任せない 4 つの領域）
- 求める応答は、秒より速いか。ミリ秒単位なら PLC の仕事、秒から分で足りるなら Python の範囲です
- 同じことをする製品が売られているか。売られているなら先に見積もりを取ります。取らずに内製を選ぶと、後で必ず「なぜ買わなかったのか」と聞かれます
- 仕様を決める人が社内にいるか。ここが内製の本体です。決める人がいない案件は、外注しても内製しても同じところで止まります
- 2 人目が触れる形にできるか。バージョン管理に置き、手順を書き、動かし方を別の人が再現できることが条件です
業務に当てはめると次のように分かれます。判定は当サイトの見解で、現場の規模・保守体制・既存設備によって変わります。右列の理由を自分の現場に置き換えてください。
| 業務 | 判定 | そう判断する理由 |
|---|---|---|
| 稼働ログを集めて画面に出す／書式の違う CSV を統合して品質グラフにする | 内製 | 読み出しだけで済み、数秒遅れても生産は続く。計算式も人が検算できる |
| しきい値超過を通知する | 内製（停止は制御層に任せる） | 通知が数十秒遅れても人が対応できる設計にする |
| 設備を止めるインターロック／検定・法令記録の根拠データ | 内製しない | 前者は安全層・制御層の責務。後者は技術ではなく社内規程と法令の問題で、品質保証部門の判断 |
| 生産計画・在庫・原価の管理／数十人が同時に使う入力画面 | 買う / 既存システム | 業務ルールが多く、権限管理・同時アクセス・バックアップの作り込みも要る |
| 複数拠点をつなぐ基盤・ネットワーク | 外注（運用は協業） | 止まると全社が止まる。インフラは外に任せ、業務ロジックは社内に置く |
技術課題ごとの実装ルートは 製造業で Python にできること・できないことにあります。本記事は手前の「誰が・いくらで・どう承認を取るか」を担当します。
6. 生成 AI は何を変え、何を変えないのか
旧版は「AI を使えば Python 経験 1 年程度でも実用的なコードを書ける」と根拠なく断定していました。この断定は撤回します。2025 年以降の実証データは、もっと複雑なことを示しています。
6.1 熟練者が慣れたコードで使うと、遅くなった
研究機関 METR は 2025 年 7 月、経験豊富なオープンソース開発者 16 名・246 件の課題によるランダム化比較試験を公開しました。対象者は平均 5 年関わっている自分のリポジトリで作業し、ツールは主に Cursor Pro と Claude 3.5 / 3.7 Sonnet。結果は、AI を使ってよい条件のほうが課題の完了に 19% 長くかかったというものでした。しかも開発者は事前に 24% 速くなると予想し、実験後も 20% 速くなったと認識していました。実測と主観が逆を向いています。
ここを切り取って「AI は効かない」と読むのは誤りです。著者自身が、この結果は「AI が多くの開発者を速くしていないことの証拠ではない」「近い将来の AI が同じ設定で速くしないという証拠でもない」「ソフトウェア開発以外に一般化できるものでもない」と明記しています。
条件を見ると、製造業の内製化はむしろ逆側にいます。METR の対象は熟練者が 5 年見てきた大規模なコードベースで、AI に文脈を説明する手間が自分で書く速さを上回る状況でした。現場の内製は不慣れな人が新規に小さいものを作る状況です。ただしこれは海外の実証で、日本の製造業に当てはまる根拠にも、当てはまらない根拠にもなりません。確実に言えるのは 1 つ。速くなったという自分の感覚は、当てにならない。
6.2 速度は上がるが、安定性は下がる
Google の DORA チームが 2025 年 9 月に公開した「State of AI-assisted Software Development」は、世界中の技術者およそ 5,000 名への調査に基づくレポートです。職場で AI を使っていると答えたのは 90%、生産性が上がったと感じているのは 80% 超。一方で AI の生成コードをほとんど、またはまったく信頼していないのが 30%。AI の活用はスループットとは正の相関に転じたものの、デリバリーの安定性とは依然として負の相関にあると報告されています。
中心的な主張は、AI は増幅器だというものです。自動テストとバージョン管理が整っているチームは伸び、密結合で遅い工程を抱えているチームは既存の問題が拡大して表に出る。内製化の文脈に読み替えれば、AI を入れれば内製できるようになる、という順序ではありません。作ったものを検証する仕組みを先に用意した現場だけが、AI で速くなります。
6.3 日本の導入状況は「3 社に 1 社」
前掲の JUAS「企業IT動向調査2026」（回答 957 社）では、コード系の生成 AI を「導入・試験導入」と答えた企業が 32.6%（区分表記は JUAS の公表文に従う）。前年度比で 10 ポイント以上の伸びですが、水準はまだ 3 社に 1 社です（言語系は導入済み 33.9%、試験導入・準備中を含め 53.4%）。稟議では「もう半数以上が言語系を試している」とも「コード系はまだ 3 社に 1 社」とも書けます。どちらの読み方をしたかを明示するほうが信用されます。
6.4 変わったこと、変わらないこと
変わったのは、最初の 1 本を書き始めるまでの時間、エラーを調べる時間、他人のコードを読む時間。変わらないのは、動作確認とエッジケースの検証、設備につないだときの挙動を実機で確かめる工程、なぜその設計にしたかを人が書き残す作業、現場に受け入れてもらうまでの時間です。
稟議に書くときの原則は 1 つ。「AI で ◯% 速くなる」と書かない。METR が示したのは、その ◯% を自己申告で出すと逆符号になりうるということでした。書くなら、社内で 1 件だけ実測してからです。
ツール選定・社内情報の扱い・法人契約・情報漏洩対策は本記事の範囲外です。生成 AI を製造業の内製開発で使う実戦ガイドでまとめます。
7. 内製化のデメリットと組織的な壁
不利な側をまとめて出します。経営層が最初に聞くのはこちらです。提案書も同じ順序で書きます。
| デメリット・壁 | 中身 | 打ち手 |
|---|---|---|
| 担当者への依存と保守責任 | 作った本人しか直せないと異動・退職で止まる。外注なら「動かないので見てほしい」で済む部分も、内製は自分たちで直す | 止まっても影響の小さい業務から始める。バージョン管理・手順書・引き継ぎパッケージ（11 章）と ログ設計を最初から入れる |
| 採用で補えない | 3 章のとおり、書ける人の 73.6% は IT 企業側にいる。ユーザー企業が中途で確保するのは容易ではない | 採用前提の計画を立てない。今いる人が学ぶ前提で組む（学習ロードマップ） |
| 評価と責任が担い手に不利 | 人事評価が「IT を作ること」を項目に持たないうえ、外注の失敗は先方の責任、内製の失敗は担当者の責任になりやすい | 削減時間を工数として部門実績に載せる（回収期間）。撤退基準を着手前に明文化し、撤退を成果として扱うと合意しておく |
| 学習期間の工数と、社内の慣性 | 担当者が学ぶ時間と現業を抜ける時間が実費として発生する。加えて「IT 部門でない人間が作ってよいのか」という不安が残る | 機会費用を比較表に載せる（9.3）。情報システム部門と品質保証部門には着手前に相談を通す |
2 行目は当サイトの主張にとって不利な事実なので、はっきり書きます。「内製なら人材の心配が要らない」は成り立ちません。日本のユーザー企業は、そもそも書ける人を採りにくい側にいます。内製化の計画は、採用ではなく今いる人が学べる範囲から組んでください。ここを飛ばした計画は、人が採れないという理由で止まります。
逆に、外注の「担当者が辞めても大丈夫」も無条件ではありません。担当営業の異動、保守契約の終了、ベンダー自身の事業撤退。外注にも同じ形の依存があります。どちらのリスクなら手当てできるかを選ぶ話です。
8. 内製化の失敗パターン 5 つと回避策
7 章が「始める前の壁」なら、こちらは「始めた後の事故」です。
8.1 動くものはできたが、現場が使わない
いちばん多い失敗です。技術的には成功していて、誰も開かないダッシュボードが残ります。原因はたいてい、作る人が「あったら便利だろう」と考えたものを作っている点です。回避策は着手前に 「これができたら、誰の何分がなくなるか」を 1 行で書くこと。書けなければ作らず、書けたらその人に先に見せて、使うと言ってもらいます。
8.2 属人化 — 作った人が異動して止まる
内製化で最も警戒されるのが属人化です。運用に載った後で担当者が変わり、誰も触れなくなるパターンで、放置されたツールは、止まるより間違った値を出し続けるほうが厄介です。回避策は 3 つ。着手時点で 2 人目を決めておく（書ける必要はなく、動かし方と止め方を知っている人で十分）、コードをバージョン管理に置く、止め方を先に書いておく。動かし方だけの手順書は、担当者がいなくなった瞬間に役に立ちません。
8.3 手作りが増えすぎて、全体を把握できなくなる
小さな成功が続くとツールが増え、どれが現役か分からなくなります。社内版のロックインです。回避策は台帳を 1 枚だけ作ること。ツール名・目的・置き場所・実行している PC・担当者・止めたときの影響、この 6 列で足ります。年に 1 度見直し、使われていないものを止めます。
8.4 「読み出しだけ」のつもりが、設備に影響した
技術的にいちばん怖い失敗です。読み出しは設備の動作を変えないので安全に見えますが、通信の負荷はかかります。
- PLC には同時接続数の上限があり、ポーリングを増やすと既存の収集装置がつながらなくなることがあります。稼働中の PLC へのアクセスはスキャンタイムに影響し得ます
- RS-485 のように 1 本の線を複数の機器で共有している場合、PC を足すこと自体が既存の通信に影響します（pyserial の記事）
回避策は運用側で決まります。つなぐ前に、その線に何がぶら下がっているかを保全担当と確認する。通信テストは計画停止日か保全日に行う。生産設備 LAN と事務 LAN の分離を確認する。この 3 つを着手条件にしてください。分離されているなら、それを崩す提案はしないでください。収集用 PC を設備側に置いて出力ファイルだけを渡す、日次のエクスポートを事務側で処理するなど、分離を保つ形に寄せます。構成変更は情報システム部門とセキュリティ担当の領分です。通信の設計は TCP/IP 通信と pymodbus の記事で扱っています。
8.5 情報システム部門の承認が取れず、現場 PC に置けない
自分の PC では動いたのに、現場の PC に持っていけないパターンです。Python がインストールできない、実行ファイルがセキュリティ製品にブロックされる、社内プロキシで通信が通らない。回避策は配布の壁を最初のフェーズで確認しておくこと。試作が終わってから相談すると作り直しになります。手当ては PyInstaller・CP932 と UTF-8・Windows サービス化の各記事にまとめています。
9. 稟議を通す提案書の作り方
技術的に正しくても、資料が通らなければ何も始まりません。そのまま雛形として使える形にしてあります。
9.1 提案書の章立てテンプレート
A4 で 3〜4 枚、6 項目が目安です。
- 現状の課題と、そこに払っている時間・費用（「月末集計に 20 時間」のように数字にする）
- 対象範囲の限定。どのラインの、どのデータを、どこまで（2.3 の 5 条件）
- 3 案の比較と、費用・回収期間（9.2・9.4）
- リスクと対策。7 章の表に自社の打ち手を書き足す
- 撤退基準。いつ・何をもって止めるか（10 章のゲート）
- スケジュールと次の判断日。承認は「やる/やらない」ではなく「次の判断日まで進める」で取る
9.2 3 案を並べる（現状維持・最小投資・推奨）
1 案だけ出すと、決裁者は「やる/やらない」の二択に追い込まれ、判断しない選択（差し戻し）が最も安全になります。3 案にして比較の会話に変えます。肝は現状維持にも金額を付けること。何もしなければゼロ円だと思われている間は、投資の話になりません。
- 案 A（現状維持）: 手集計を続ける。年間の工数を人件費に換算し、転記ミスや報告の遅れも列挙する
- 案 B（最小投資）: 試作だけ実施する。数十万円規模。判断材料を得るための支出と位置づける
- 案 C（推奨）: 試作から限定運用まで。金額・期間・撤退条件を明示する
9.3 比較表は不利な項目から書く
外注案と内製案を並べる表では、内製に不利な行を上に置きます。決裁者は必ずそこを聞くので、先回りして書いた資料のほうが信用されます。以下は 2 章の A 社ケース（ダミー数値）の例です。
| 比較項目 | 外注（SIer A 案） | 内製 |
|---|---|---|
| 学習コスト・機会費用・品質保証の責任 | ほぼ無し。契約でベンダーが負う（ただしロックインはある・3.6） | 学習期間の工数（目安 4〜6 ヶ月）と現業カバーが必要。品質保証も社内が負う（7 章） |
| 初期費用と期間 | 1,800 万円・12 ヶ月 | 100〜150 万円・1 ヶ月（1 ライン・読み出しのみに限定した場合） |
| 保守・機能追加・仕様変更 | 月額 30 万円。追加は都度見積もりで、反映に数日〜数週間（書類改訂を伴う） | 担当者の工数内とメンター顧問料。反映は即日〜数日 |
上の金額は記事用のダミーです。必ず自社の見積もりに置き換えてください。相場感が要るなら、4 章の分布（工期の中央値 10.1 ヶ月・工数の中央値 7,395 人時）を出典付きで引きます。
9.4 回収期間の出し方
決裁者が知りたいのは いつ元が取れるか だけです。年間の削減額 ＝ 削減できる時間（時／年）× 社内の時間単価（円／時）、回収期間（ヶ月）＝ 初期費用 ÷（年間の削減額 ÷ 12）。A 社のダミー数値なら、月 20 時間の集計がなくなって年間 240 時間、時間単価を仮に 4,000 円とすると年間 96 万円の削減、初期費用 120 万円で回収期間は 15 ヶ月です。ただしこの 120 万円に、担当者が学ぶ時間は入っていません。9.3 の目安 4〜6 ヶ月は現業を抜ける実費で、月 20 時間を 5 ヶ月・同じ単価なら 40 万円、初期費用 160 万円・回収期間 20 ヶ月です。学習分は初回だけで 2 件目以降は乗らない、と併せて書いてください。
ここで 「1 年で回収できます」と言わないのが要点です。切り上げても、決裁者が電卓を叩けば分かります。次の 2 点を先に添えるほうが通ります。
- 前提を明示する。時間単価は社内標準があれば使い、無ければ仮定だと書く。「20 時間」が実測か担当者の申告かも書く
- 金額にならない効果は分ける。報告が早くなる、転記ミスが減る、社内に経験が残る。回収期間に混ぜず、定性効果として別欄に置く
なお、AI の活用を前提に工数を短く見積もるのは避けてください。DORA の ROI 資料でも AI 導入初期の生産性低下をどう管理するかが論点になっています。導入直後は一時的に遅くなりうると先に書くほうが、後の説明が楽になります。
9.5 想定質問 7 とその答え方
会議で実際に出る質問です。
| 質問 | 答え方 |
|---|---|
| 本当に 1 ヶ月でできるのか | 1 ライン・読み出しのみ・既存運用は残す、に限定した見積もりだと明示する。範囲が広がれば期間も伸びると先に言う |
| 担当者が辞めたらどうする | 2 人目を着手時に指名済みであること、バージョン管理と手順書を成果物に含めることを示す（11 章） |
| 品質は誰が保証するのか | 止まっても生産に影響しない範囲に限定していること、品質保証部門の確認が要る工程は対象外であることを書く |
| 設備を壊さないか | 読み出し専用・通信テストは計画停止日・保全担当と事前確認の 3 つを着手条件として書く（8.4） |
| 市販品で足りるのではないか | 先に見積もりを取った事実と金額を示す。取っていないなら、取ってから提案する |
| 失敗したらどうする | 各フェーズ末の撤退基準と、そこまでに使う金額の上限を示す（10 章） |
| AI で作ったコードは信用できるのか | 生成物は必ず人が検証すること、AI で何 % 速くなるとは見積もっていないことを示す（6 章） |
社内に前例があるなら必ず使ってください。「Excel マクロで月次集計を自動化したときと同じ発想で、今度は設備のデータを扱います」という連続性のある説明は、新しいことを始める提案より抵抗が小さくなります。
10. 段階的ロードマップ — 4 フェーズと撤退判断ゲート
一気に広げず順に積みます。各フェーズの終わりに撤退するかどうかを判断するゲートを置くのが、この設計の本体です。ゲートが無いロードマップは、止められないロードマップです。
10.1 各フェーズで何を作るか
フェーズ 1 は設備に触らない領域から選びます。日報の集計、複数 Excel ファイルの統合、提出書類の自動生成（pywin32 の記事）。ここで派手に失敗すると後続が進まないので、地味でも確実に動くものにしてください。
フェーズ 2 は設備と PC をつなぐ段階で、PLC と Python で通信する方法や pyserial の記事が入口です。着手条件は 8.4 の 3 つ。ネットワークとセキュリティの担当部門（専任部門がなければ情報システム担当者と設備管理責任者）との事前調整も、ここで必ず通します。
フェーズ 3 は複数のデータをまとめて画面にする段階です。SQLite での蓄積、品質管理グラフ、監視アプリが該当し、24 時間動かすなら ログ設計と 常駐化を入れます。
フェーズ 4 は基幹との連携バッチや分析基盤。失敗の影響範囲が広いので、設計・テスト・運用の手順を組織のルールとして整えてから進みます。5 章の表で「買う」「外注」に振り分けた領域を、無理に内製へ引き戻さないでください。
10.2 撤退基準は、着手前に数字で書く
「うまくいかなければ止める」では止まりません。着手前に次の形で書きます。
- 期限: 「◯月◯日のゲートで判断する」と日付で書く
- 条件: 「1 ヶ月後に、対象部署の 3 人中 2 人が週 1 回以上使っていること」のように数えられる形で
- 上限: 「このフェーズの費用は ◯ 万円まで。超えたら止めて再提案する」
- 止めたときの扱い: 撤退は失敗ではなく判断だと承認の時点で合意する。決めないと、担当者は止められません
11. 終わらせ方 — 引き継ぎパッケージと撤退手順
内製化は始め方ばかりが語られますが、組織にとって重いのは終わらせ方です。ここを設計できているかが、7 章のデメリットのほとんどを打ち消します。属人化への対策もこの章にまとめました。
11.1 引き継ぎパッケージの中身
「引き継ぎ資料を作る」では実行されません。次の 5 点が揃っていれば、書いた本人がいなくても運用は続きます。
- 何のために作ったか、止めると誰が困るか。誰の何分がなくなるツールなのかを 1 行で書き、困る人の連絡先を添える。ここが空欄なら、そのツールは止めてよいということです
- 動かし方と止め方。止め方を必ず書きます。止められないツールは、異常時に誰も触れなくなります
- 置き場所とつないでいる先。コード・実行 PC・出力先・設定ファイルと、どの設備やデータベースに読み出しのみでつないでいるか
- なぜその設計にしたか。現場の都合と、見送った案の理由。AI は「何をしているか」は説明できますが、「なぜそうしたか」は残さないと復元できません
- 止まったときの見分け方。ログの見方とよくある止まり方。ログ設計を最初から入れておくと、この項目は自動的に埋まります
バージョン管理は前提です。変更履歴と経緯が残っていれば、4 番目の多くはコミットメッセージで代替できます。運用は Git とブランチ戦略の記事で扱います。
11.2 撤退の手順
止めると決めた後の順序です。放置と撤退は違います。
- 止める日を決めて周知する。ほかに使っている人がいる可能性があります
- 元の運用に戻せるか確認する。2.3 で手集計を残すと書いたのは、この保険のためです
- データを保全する。集めたデータは止めた後も価値があります。保存先と保存期間を決めてから止めます
- 接続を外す。設備側の接続設定、収集用アカウント、開けたポート。作ったときに触ったものを戻します
- 台帳から消す。8.3 の台帳から削除し、止めた日と理由を残します
この手順を最初のフェーズから決めておけば、撤退のコストが読めます。読めるから、決裁者は着手を承認できます。畳み方が書いてある提案のほうが通ります。
12. おわりに
外注が高く長くなるのは構造の結果です。日本ではソフトウェアを書ける人の 73.6%（2020 年）が IT 企業側におり、外部委託の工数比率は 562 件の中央値で 6 割強、開発ライフサイクルの 97.2% は書類の承認を積み上げるウォーターフォール（3 章の出典による）。値切って解決する話ではありません。
一方で「内製なら 1/10」という一般法則もありません。外注案件の工数の中央値は 1 人月換算で 40 人月を超え、1 ヶ月で終わるのは作る範囲を切り出せたときだけです。切り出せるかを見極めるのが 5 章の 5 つの問い、切り出せた後に要るのが 9 章の提案書と 11 章の畳み方。業務ごとに線を引き直し、内製に回した分だけ社内に経験が残る。この積み上げのほうが、どちらかに寄せるより現実的です。
本記事は一般論であり、特定の企業・案件への助言ではありません。金額・期間・体制の妥当性は、自社の状況・既存設備・社内規程・契約条件によって変わります。実際の投資判断は、社内の関係部門と必要に応じて外部の専門家に確認したうえで行ってください。また、設備・ネットワークへの接続や設定変更は、自社の安全基準・社内規程と保全部門・情報システム部門の承認に従い、自己責任で実施してください（着手条件は 8.4）。24 時間稼働の設備では、事前の保全承認が前提です。