「自分たちで作る」は幸せか？

どーもbarusuです。メリークリスマス。
2025アドベントカレンダー25日目の記事です。

え、1日遅いって？
…時差ですよ、時差！

Cloudnative IRS Advent Calendar 2025 – Adventar

今日の記事はコラム的な内容です。
今年ずっと考えてきたテーマについて、考えたことをまとめました。

---

1. 疑問提起

iPaaSを導入すれば業務が効率化される。

ノーコードツールを使えば、エンジニアでなくても自動化ができる。

RPAを入れれば、定型作業から解放される。

本当でしょうか。

より正確に言えば、それは「誰にとって」本当なのでしょうか。

iPaaSとは誰の為にあるのだろうか。

ここで言うiPaaSとは、製品そのものというよりも「業務効率を上げるために内製化という選択肢を執る際に使われるソリューション全般」を指しています。
RPAでもノーコード・ローコードツールでも、本質は同じです。
※主語の定義が難しかった…ミスリードを誘発したらごめんなさい。

私はこの問いをずっと抱えていました。

自分たちで作ることは、果たして幸せなのか？

逆に、外部ベンダーに任せれば幸せになれるのか？

Do It Yourselfの精神は、現代でも必要なのか？

内製の功罪とは何か？

これらの問いに向き合いながら、考えたことを整理してみます。

2. 「改善」で得られるもの

組織が活動する上で、さまざまな「手続き」や「タスク」が存在します。
目的を達成するための一連の行動があり、その流れをスムーズにしたり、省略・統廃合することで効率化・省力化・自動化を図ります。
これらは一般的に「改善」と呼ばれますよね。

改善によって期待される効果は多岐にわたります。

分類	効果
ミスの防止	発生率減少、発見率増加
スケーリング	同コストで対応件数N倍、リードタイム短縮
コストダウン	労力・人員削減、要求スキル低下
新たな付加価値	従来できなかったことが可能に
可視性・透明性	属人化解消、ブラックボックス排除
アジリティ	変化への対応速度向上
リスク分散	特定ベンダー/人物への依存脱却
ガバナンス	監査対応、内部統制強化
知識・能力の蓄積	ナレッジ形成、人材育成

ここまで挙げたものは、すべて改善の「結果」として得られるものです。
しかし、見落とされがちな側面があります。それは、改善を「実行する過程」で得られるものです。

ここが「内製か外注か」という議論の核心に触れる部分だと思っています。

3. 「結果」と「過程」の分離

ここで一つの補助線を引いてみます。

「改善によって得られる効果」と「改善を実行する過程で得られる効果」は別物ではないでしょうか。

前者はResult（結果）です。
ミス防止、スケーリング、コストダウン、新たな付加価値。これらは改善が完了した後に得られます。

後者はProcess（過程）です。
自分たちで作ることで業務を深く理解する。組織に知見が残る。次の改善ができる人材が育つ。これらは改善を実行する過程で得られます。

山登りに例えてみます。

🥾 自分で山を登る場合（内製）

• 頂上に着ける（時間はかかる、失敗リスクもある）
• 登る過程で得られるもの：
  • 筋力、判断力
  • 地形の知識
  • 次の山への自信
• → 次の山も自力で登れる可能性が高まる

🚁 ヘリで頂上に行く場合（外注）

• 頂上に着ける（早い、確実）
• 登る過程で得られるもの：
  • なし
• → 次の山に登りたければ、また金を払う必要があり、登れないリスクもある

こう並べると内製最高じゃん！内製しか勝たん！に見えますが、当然そう単純ではありません。

4. 反論と検証

「Processで得られるものが本質」という考えには、いくつかの反論が想定されます。
順番に考えてみます。

「すべての山を自分で登る必要があるのか？」

答えはNoです。
すべての山を自分で登る必要はありません。本業に関係ない山まで自力で登る意味があるのか？という問いは正当だと思います。

しかし、考えてみると…
「この山は登るべきか否か」という判断は、登る前に気づくもの、登っている途中に気づくもの、登頂してから気づくもの、下山して振り返って初めて気づくもの、様々です。
いつ気づくかという違いしかありません。

そして現実的に難しいのは「これは我々が登るべき山なのか？」という問いへの答えが、合っているかどうかは誰にもわからないということです。

ただし共通しているのは、一度でも山に登ったことがあり、何が自分たちにとって必要で何が不要なのかを考えた者でなければ、要不要に気づくことも考えることもできないという点です。

結果論と一般論を重ねれば、もっともらしい「やるべきではない」理由付けは作り上げられます。
しかし、自分たちのビジネス、組織の存在意義、MISSIONは自分たちで考え決めるものであって、外部から与えられるものではありませんよね。

つまり、すべての山を登る必要はないけれど、取捨選択と判断をする能力が必要であり、それを得られるのはある程度のProcessの経験値なのだと思います。

「登山技術の習得自体がコストである」

その通りです。
学習コスト、失敗コスト、時間コスト。それを払う余裕がない組織はどうするのでしょうか。

無い袖は振れません。
登山技術の習得のためにそれらを払う余裕がなく、他に優先すべき事柄があるのであれば、その組織においては「今は」何もしないのがベターということになります。

ただ、1日に5分でも時間が取れるのであれば、自分の業務を振り返ってみるといいと思います。
その5分で改善案を思いつくのであれば、あとは少しずつその5分を使って工夫をしてみる。
それだけでも最初の一歩になります。

「次の山が来ない場合もある」

一度作って終わり、変化しない業務ならProcessの価値は回収できないのではないか。
こういう反論もあるかもしれません。

この仮定が正しいのであれば、たしかにProcessの価値は微々たるものです。
しかし現実的にこの仮定通りにはならないと思います。
私たちの業務は複雑で、複数のプロセスが存在し、入り組んでいますよね。
一つの業務で得た経験は、他の業務でも活きます。そうなればProcessの価値は回収できるのではないでしょうか。

「ヘリで登っても、どの山に登るべきかを判断する力は別で鍛えられるのでは？」

戦略眼と実行力は別の筋肉ではないか、という問いです。
自分で考えておいて手前味噌ですが、これは良い反論だと思います。

しかし、どの山に登るべきかを選ぶ際、必ずしもヘリで登れるとは限りません。
自分たちで登る際のコストや難易度と、ヘリで山頂を目指す難易度、そもそも実現が可能かの見込みを立てる能力などを比較・勘案した上で立てるのが戦略です。

ヘリを使うしか選択肢がないのであれば、それは戦略とは言えないのではないでしょうか。

選択肢を持った上でヘリを選ぶのは戦略であり、選択肢なくヘリを選ぶのは依存だと思います。

5. よくあるパターン

ここまでの議論から、いくつかの典型的なパターンが見えてきます。

パターン	状態	評価
1. 選択肢を持った上での外注	評価・検証できる能力あり	✅ 戦略
2. 選択肢のない外注	評価・検証できない	❌ 依存
3. 作りっぱなしの内製	メンテ・廃棄できない	❌ 負債化
4. 持続可能な内製	ライフサイクル回せる	✅ 健全

それぞれ詳しく見てみます。

パターン1：選択肢を持った上での外注

自分たちで設計でき、プロセスが想像でき、期待結果を評価できる。
その上で、スピードやコストを勘案して外注を選ぶ。これは戦略的な判断だと思います。
外注先が出した結果や、取り組んでいるプロセスを評価・検証できる能力があるからこそ、外注という選択肢が機能します。

パターン2：選択肢のない外注

自分たちでは何もできない。だから外注する。結果の評価も検証もできない。
外注先が「できました」と言えば「できたんだ」と思うしかない。これは依存です。
外注先に問題があっても気づけません。気づいたときには手遅れになっていることも多いのではないでしょうか。

パターン3：作りっぱなしの内製

作りたい。でもメンテは嫌だ。このマインドで作られたものは、やがて負債になります。
作った人が異動や退職をすれば、誰も触れないブラックボックスが残ります。

実は、作ることより捨てることの方が難しいのです。
「これはもう要らない」と判断し、廃棄する決断ができる人がいなければ、内製物は増え続け、やがて誰も全体像を把握できなくなります。
これは内製の失敗パターンだと思います。

パターン4：持続可能な内製

作る人、メンテする人、対象業務に関わる人、意思決定者。これらの役割が分担されている。
特定個人に依存しない形で運用の体制が作れている。これが健全な内製の形だと考えています。

6. 筆者の考え

ここまでの議論を踏まえて、私の考えを述べます。

「選択肢を持てること」自体が価値であり、その選択肢を持つためにはProcessの経験が必要である。

内製のProcessで得られる「選択肢を持つ力」こそが本質的価値だと思っています。

では、iPaaSは誰のためのものでしょうか。

私の考えは、前を向く人のためのものです。

もっと良くしたいと思っている人。自分で作ることに向き合える体力がある人。そういう人のためのものだと思います。

「体力」とは何か

ここで言う「体力」とは、作る・メンテする・改善する・廃棄する、という一連のライフサイクルを、特定個人に依存せず回せる状態を指しています。

状態	評価
「作りたい、メンテも引き受ける」という個人がいる	✅ 体力あり（個人）
作る人、メンテする人、判断する人が分業できている	✅ 体力あり（組織）
「作りたい、でもメンテは嫌」というマインド	❌ 体力なし（作らない方がいい）
特定の一人に全部依存している	❌ 体力なし（その人が抜けたら終わる）

チーム組成の観点

持続可能な内製には、以下の4つの役割が必要です。最低でも3人はいると良いと思います。

1. 作る人 ― 実際に手を動かして構築する
2. メンテする人 ― 運用、保守、改善を担う
3. 対象業務に関わる人 ― 要件を出し、結果を評価する
4. 意思決定者 ― Go/No Go、優先順位、廃棄を判断する

兼務を含めても、視点が3つ以上ないとチェック機能が働きません。「作る人」と「使う人」と「決める人」が同一人物だと、独りよがりになりやすいからです。

うまくいかないパターン

• 作る人＝メンテする人となり、個人のモチベーションに左右される
• 意思決定者が意見を出さず、お気持ち表明と答え合わせしかしない「なぞなぞ出題者」になっている
• 誰も廃棄の判断をしない（または、できない）

最初の一歩

最初は自分一人で「作る側」「メンテする側」「業務に関わる人」「意思決定者」のすべてを兼務することになるかもしれません。
これがしんどいのであれば、まずは自分が取り扱う課題を手元のものに限定し、徹底的に小さくする。
それによって得た効果を元に、チーム組成を試みる。
3人以上が関連する業務課題に取り組めたら、ある程度の体力がついた状態と言えると思います。

厳しい話

そして、ここからが厳しい話になります。

体力がない組織は、iPaaSを買っても意味がありません。

もっと言えば、体力がない組織にとっては不幸な結果を生みます。

これはベンダー側にも、買う側にも言えることです。

体力がないなら買わない方がいい。
まずはPoCや無料体験から。

体力がないところに売らない方がいい。
まずは「なんでやりたいんですか？」とお話を伺うところから。

我々のようにiPaaS製品を取り扱っている側が「売るな」と言うのは奇妙に聞こえるかもしれません。
これが私の本音ですし、ささやかながら普段から言ってることでもあります。
誰にでも必要とされるものではない、という認識ですね。

7. 結論

Take Away

動かないことが最大の損失です。

「この山は登るべきか、わからない」状態が問題なのであって、やってみて「登るべきでなかった」と判断できたのであれば、当初の問題からは確実に前進しています。

ただし、ここで一つ重要な区別があります。

「iPaaS製品を契約する」ことと「内製化に向けた小さな実践をする」ことは、まったく別の話です。

体力がない状態でいきなりiPaaS製品を契約しても、使いこなせずに終わる可能性が高い。
それは「ジムに入会しただけで筋肉がつくと思っている」のと同じです。

まずは手元で筋トレをしてください。
基礎体力を作る。それが先です。

現場の方へ：小さく始めるためのヒント

最初の一歩は何でもいいと思っています。
何でもいいから、デッドロック状態をすみやかに脱することが大事です。

動けない理由、わかります。

• 失敗の責任を取りたくない
• 何から始めればいいかわからない
• 今の業務で手一杯
• 上が理解してくれない
• 外注の方が安全に見える

それでも、小さく始めることはできます。

小さく始める具体例：

• ブラウザのブックマークレットを作ってみる
• CLIで動かせるバッチファイルを作ってみる
• 普段の操作を簡略化できるショートカットを覚える
• 自分のPCのローカル上で完結し、誰にも迷惑をかけない範囲で始める

何から始めればいいかわからないなら：

• 自分または周囲の業務で、一番手間がかかっているものは何か？
  • → それはどうなったら楽になるか？
• 一番憂鬱な業務は何か？
  • → それをやらなくて済むにはどうしたらよいか？

マネージャー・経営層の方へ：許可と環境づくり

上の理解が得られないから動けない、という声は現場からよく聞きます。

もしあなたがマネージャーや経営層であれば、現場に「小さなトライ」を許可してください。
失敗しても責任を問わない範囲を明確にしてあげてください。
「小さなトライ」を褒め、感謝し、歓迎する空気を作ってください。

個人のPCで完結する工夫、業務時間の5分を使った改善の試み、これらを「勝手なことをするな」と潰してしまうと、組織は体力をつける機会を失います。

また、外注の方が安全に見えるかもしれませんが、最近では外部委託の失敗で発注者側の責任を問う判例も出てきています。
外注に任せれば安全、ということはありません。自社のリスクは自社でコントロールすべき問題です。

選択肢を持った上で外注を選ぶのは戦略ですが、選択肢なく外注するのは依存です。
依存状態にある組織は、外注先に何かあったときに詰みます。

新しい問い

最後に、いくつかの問いを残しておきます。

• あなたの組織には「体力」がありますか？
  • 作る・メンテする・改善する・廃棄する、というライフサイクルを回せる状態にありますか？
• あなたは選択肢を持っていますか？
  • 内製も外注も選べる状態ですか？それとも、外注しか選択肢がない状態ですか？
    • もし後者なら、それは戦略ではなく依存かもしれません。依存から抜け出すために、最初の一歩を踏み出せますか？

そして、あなたが「前を向く人」なら、iPaaSはあなたのためにあります。

8. Summary

• iPaaS（≒内製化支援ツール）は、「前を向く人」「体力がある人」のためのもの
• 改善には「Result（結果）」と「Process（過程）」があり、Processで得られるものが次の選択肢の幅を広げる
• 選択肢を持った上で外注を選ぶのは戦略、選択肢なく外注するのは依存
• 「体力」とは、作る・メンテする・改善する・廃棄するというライフサイクルを特定個人に依存せず回せる状態
• 体力がない組織はiPaaSを買っても不幸になる。いきなり契約するな、まずは手元で筋トレしよう
• 現場は小さく始める。マネージャーはそれを許可し歓迎する。それが体力をつける道筋

---

最後の蛇足的コメント

売る側の人間が「売るな」と言うのは矛盾に見えるかもしれません。
しかし、体力のない組織に売りつけても、Too Matchな製品では誰も幸せにならない。
それは経験上、痛いほどわかっています。だからこそ、この記事を書きました。

マジで困ってるんです！助けて！って方には伴走支援できます！とアピールしておきます。
お問い合わせお待ちしております！

自動化への理想と、業務現場の現実とのギャップに苦しんでいる人へ、この想いが届きますように！

ではでは。