自動化：自作するか、ソフトを買うか、コンサルを雇うか？Make-vs-Buyの意思決定

ほとんどの中堅企業における自動化プロジェクトは、技術で失敗するのではありません。判断があまりに早く、間違った数値に基づいて下されるために失敗します：自前で作るか、既製ソフトを買うか、コンサルタントを頼むか？

どの道にも適切な場面があります。しかし「Make or Buy」の問いに誠実に答えられるのは、次の二つが確定している場合だけです：どのプロセスを扱うのかが分かっていること、そしてそのプロセスがどれだけユーロでコストがかかっているかが分かっていること。これがFLOWREFYメソッドのOフェーズの役割です。本稿はその背後にある意思決定ロジックを示します。ツール対ツールの比較ではなく、作る・買う・外注するが実際に分かれる閾値を示します。

順序を守ってから決定する

FLOWREFYメソッドは、プロセスごとに四つのステップを回すループです：FLOWは（F 候補を見つけ、L をユーロで定量化し、O で負荷時のボトルネックを見つけ、W で介入の費用と効果を計算する）、REFY は細かくします（R 不要を削ぎ落とし、E 責任を明確にし、F 正確に一つの技術的レバーを作り、Y 同じ計算で再測定する）。

Make-vs-Buyは純粋にOフェーズの問いです。そしてOフェーズには鉄の原則があります：まず整理し、それからソフトウェアを買うこと。順序を逆にすると、混乱を自動化するだけです。より速く、より高コストで。

自明に聞こえますが、実際はそうではありません。中堅企業の典型的な流れはこうです：誰かが展示会でツールを見て、営業が良くて予算があり、六週間後には、以前は誰もきちんと定義していなかったプロセスを実装したソフトウェアが稼働しています。結果は、表面は光っているが高コストの停止状態です。

ですから何かを買うか作る前に、二つの前提が満たされている必要があります：

1. ボトルネックが確定していること。正確に一つのプロセス、五つではない。これは「サイクルごとに一つのボトルネック」という原則です。
2. ボトルネックがユーロで定量化されていること。現状の年間コストを知っていること。さもなければ投資を正当化できません。これが原則です：もしユーロで言えないなら、触るな。

両方が未確定なら、Make-vs-Buyの議論は早すぎます。その場合はFおよびLフェーズに戻るべきです。ボトルネックの定量化方法はFLOWプロセスコストアナライザーをご覧ください。

三つの道を正直に並べる

計算の前に、三つの選択肢が実際に何を意味するかを冷静に定義します。販売時の説明ではなく、現実の意味です。

自前で作る（Make）

No-Code/Low-Codeプラットフォーム、自前のスクリプト、社内開発者など、自社リソースで自動化を構築します。ロジックは完全に自社の所有となり、いつでも調整できます。その代償は：保守、アップデート、知見を負うこと、つまり人に依存するリスクです。作った人が辞めると理解が失われがちです。

既製ソフトを買う（Buy）

プロセスを大部分カバーする標準ソリューションを導入して利用します。導入は速く、ベンダーが保守・開発を続け、サポートもあります。その代償は：自社がソフトに合わせる必要があることです。例外処理では限界に当たることがあり、ライセンスはユーザー数やボリュームに応じて増え、ときに厄介です。

コンサルタントに依頼する

コンサルタントは第四の道ではなく、他二つを加速する存在で、通常は一時的です。内部にボトルネックを正確に定量化する知見がない場合や、移行が一度きりで複雑な場合に有効です。危険なのは、最終的に誰も社内で保守できないブラックボックスが残ることです。その場合、ボリュームの問題を依存の問題に置き換えただけになります。

本当に決め手になる三つの数値

勘やベンダーの魅力を忘れてください。Make-vs-Buyの決定は、三つの計測可能な指標にかかっています。

1. 標準化度合い

プロセスはどれほど一般的か？

• 高く標準化されている（給与計算、ニュースレター配信、チケッティング、定型の請求承認など）：何千もの企業がまったく同じ問題を持っています。ここには成熟した安価なソフトがあります。買うべきです。自前で作るのは車輪の再発明です。
• 部分的に特殊（標準コアだが三つの独特な例外ルールがある）：標準ツールをベースに、小さなブリッジを自前で作る混合形態。
• 高度に個別化されているか競争優位に直結している（そのプロセスが市場での差別化要素そのもの）：標準ソフトは外部のロジックに押し込む結果になります。ここでは自前開発が明確に有利なことがあります。

経験則：標準的なものは買い、あなたをユニークにするものは作るか作らせて引き取る。

2. ボリューム

プロセスはどれくらいの頻度で回るか？

ボリュームは固定費が正当化されるかを決めます。自前開発は初期費用が高く、限界費用は低い。買うライセンスは初期費用が低いが、継続費用はユーザーや取引量に応じて上がります。

• 低頻度・稀なボリューム：自前はほとんど割に合いません。初期投資が回収されないため、買うか放置する方が現実的です。
• 高頻度で安定したボリューム：自前の方が有利です。固定費用が多数の実行で分散され、継続ライセンス費用は年を追うごとに負担になります。

3. 3年TCO（総所有コスト）

ここで多くが失敗します：ライセンス同士を比べて、本当のコストを見落とすのです。Total Cost of Ownership は三年間で発生するすべてです。

買う場合に計上するもの：

• ライセンスとセットアップ費用
• 想定ボリュームを掛けた36か月分の継続費
• データ移行と設定
• 社員のトレーニング
• 社内での運用管理コスト（誰かがツールを保守する必要があります）

作る場合に計上するもの：

• 一度限りの開発時間（時間×社内時間単価、正直に見積もる）
• 年間保守（目安：開発費の年15〜25パーセント）
• ホスティングとインフラ
• 人的リスク（作った人が辞めた場合のコスト）

この二つの合計だけが比較可能です。保守や研修を入れると、判断が大きく変わることがよくあります。どちらの方向にも傾きます。

そして時に、両方とも不適切であることもあります。例として、サンプル分析 AN-2026-03（構成上の例で顧客データではありません）では、ワークフロー自動化の提案として18.000ユーロの見積りが出ていました。プロセスは契約前に再計算されました：

[
  { "label": "導入コスト（Buy）", "value": "18.000", "unit": "€", "tone": "critical" },
  { "label": "作業時間の削減額", "value": "4.000", "unit": "€/Jahr" },
  { "label": "償却期間", "value": "> 4", "unit": "Jahre", "tone": "critical" },
  { "label": "処理時間", "value": "-7", "unit": "%", "note": "12,8 → 11,9 Tage" }
]

このケースでは三つ目の答え、つまりどちらでもないが正解でした。ボトルネックはサプライヤー側にあり、社内の買う・作るいずれの解でも届かない場所にありました。

四つの質問で決定ロジックを回す

ボトルネックとユーロ値が確定していれば、次の四つの質問を順に処理してください。

質問1：標準的なプロセスか？ はいで高く標準化されている → 強い傾向として買う。質問3へ進む。 いいえで高度に個別化されている → 質問2へ進む。

質問2：社内に作り、三年の間保守する能力はあるか？ はい → 自前で作るは現実的な選択肢です。質問3へ進む。 いいえ → 標準ツールをプロセスに合わせるか、一次的な構築と社内知見移転のためにコンサルタントを雇う。引き継ぎのないブラックボックスは絶対に受け入れないこと。

質問3：3年TCOを直接比較するとどうか？ 両者の合計を計算してください。差が概ね20％未満なら、ほとんどの場合は買う方が勝ちます。リスクが小さく、立ち上げが速いためです。

質問4：担当者が辞めたらどうなるか？ 解決策が一人に依存するなら、自前の選択にはリスクプレミアムを上乗せしてください。あるいはコンサルタントに契約上で十分な文書化と引き渡しを求めてください。

図解的な計算例

ロジックを実感してもらうために、架空の例を一つ示します。実在の顧客事例ではありません。

従業員60人の機械製造会社が、Fフェーズで見積り作成を最も高コストのボトルネックと特定しました。Lフェーズで費用を見積もると、三名が主に手作業で見積りを作成しており、年間約40.000ユーロの拘束労働コストがありました。

Oフェーズではまず整理を行いました：テンプレートを統一し、価格ロジックを文書化しました。その後でMake-vs-Buyの問いです：

• 買う（CPQの標準ソフト、つまり自動見積り構成ツール）：年間ライセンス約9.000ユーロ、加えてセットアップと研修。3年TCO概算35.000ユーロ。問題点：特有の価格ロジックには70％しか合致しない。
• 作る（社内No-Codeコンフィギュレータ）：一度きりの費用約18.000ユーロ、年保守約4.000ユーロ。3年TCO概算30.000ユーロ。利点：価格ロジックに100％合致。リスク：知見が一人に依存する。

合計は近接しています。決め手は価格ロジックの高い個別性で、標準ツールに不利に働きました。結論：作るが、文書化された引き継ぎを伴わせて人的リスクを緩和する。どちらが勝つかは完全にあなたの数値次第です。まさにそのための計算機が用意されています。

正確に一つのレバーを操作し、再測定する

どのような決定をしても、サイクルごとに正確に一つのレバーだけを動かしてください。並行してツールを買い、別のプロセスを変更し、さらにスクリプトを書くのはやめてください。三つ同時に変えて改善が出ても、どの施策が効果を出したか分かりませんし、無駄金を燃やすだけです。

Wフェーズ（Wire & Watch）では、Lフェーズで算出した同じユーロ値を再度計測します。これにより主張ではなく、実際の前後比較が得られます。これがFLOWREFYメソッドが一般的な「何かを自動化した」話と異なる点です。

Make-vs-Buyの方向性が定まったら、No-Codeプラットフォームの具体的選定に深く入りたい場合は概観記事Beste No-Code-Toolsが役立ちます。また、購入や構築の前にそのステップが自動化可能かを確認したい場合は記事Prozesse automatisieren: Beispieleに実践的な着手点があります。

決定前の簡潔チェックリスト

• ボトルネックが確定している：正確に一つ、五つではない
• 現状コストが年間ユーロで定量化されている
• プロセスは先に整理されており、混乱を自動化していない
• 標準化度合いを正直に評価している
• ボリュームが分かっている（プロセスはどれくらいの頻度で走るか）
• 両方の選択肢について3年TCOを算出している（保守と研修を含む）
• 人的リスクを評価し、必要なら上乗せや引き継ぎで対策している
• コンサルタントを使う場合は文書化と引き渡しを契約で担保している

これらのチェックがすべて揃って初めて、あなたの決定は単なる勘以上のものになります。

次の一歩：無償のFLOW診断

Make-vs-Buyの問いは、そこに置く数値の精度次第です。ボトルネックが既に分かっているなら、判断は計算問題になります：標準化度合い、ボリューム、3年TCOを比較するだけです。現在そのプロセスがどれだけコストを生んでいるかは、Prozesskosten-Rechnerが算出します。これが両方の選択肢に対して比較する基準の数値です。

まだどのプロセスが最も高コストか、あるいはそのコストがいくらか分からないなら、一段階前から始めてください。無償のFLOW診断が、まず最も高コストのボトルネックを見つけ出し、購入や構築の前にユーロで表現します。まず測り、次に磨くのです。