社内に優秀な人材がいるのに、なぜDXを外注してしまうのか？

「DXはITツールの導入ではなく、デジタルによる事業や組織の変革である。だからこそ外注せず、内製化によって自社内でDX人材を育てるべきだ。」

こうしたスローガンを掲げるITコンサルティング会社に対して、実際には「内製化を外注する」という話を耳にすることが少なくありません。

おそらく、一定規模以上でIT部門を持つ組織であれば、DXという言葉が登場する以前から「内製化の重要性」は語られてきました。多くの人が、理屈としては理解していたはずです。

それにもかかわらず、日本のITシステム内製化率は、諸外国と比べて依然として低い水準にとどまっています。 インターネット上では、その理由として「DX人材の不足」「学習機会の不足」「ビジョンの不在」「予算不足」などが挙げられます。

しかし、市民開発という“内製化の現場”に携わってきた立場から見ると、問題はヒト・モノ・カネ以前に、組織の構造そのものにあるのではないかと感じています。

安定運用人材≠DX人材

現行業務を深く理解し、トラブルやクレームが少なく、確実に業務を遂行し、高い品質のサービスを提供できる人。

一般に、こうした人材は「優秀な人材」と評価されます。ここでは仮に安定型人材と呼びます。

一方で、DXに求められる人材はどうでしょうか。

• これまでの前例を一度リセットし、業務を再設計する
• 不安定な状態でも、まずはやってみて仮説検証する
• 失敗を前提に、スピードを優先する

こうした行動特性を持つ人材を、ここでは挑戦型人材と呼びます。

並べてみると分かる通り、両者はほぼ真逆です。同じ人でも、評価のものさしや活躍する環境が違えば、評価は180度変わります。

ただし、どちらも「優秀」であることに変わりはありません。評価は、あくまで組織側の定義次第です。

もちろん、業務内容によっては一度の失敗が大きなリスクになる場合もあり、「挑戦すれば評価される」と単純に言えるわけではありません。だからこそ各社が「自社にとっての優秀さ」を定義する必要があります。

ただ一般論として、安定型人材のほうが継続的に利益を生みやすく、組織内の摩擦も少ないため、評価は高くなりがちです。

では、その安定型人材にDXプロジェクトを任せるとどうなるでしょうか。

DXに求められるのは、あえて不安定さを受け入れ、破壊的で、スピード重視の行動です。未知の領域に足を踏み入れたとき、「知識やノウハウの不足」を強く感じ、「プロにガイドしてもらおう」という判断に至る。

これが、DXが外注へと向かう自然な流れです。

「うちには挑戦型人材がいないから外注するしかない」と思われるかもしれません。しかし、市民開発研修の現場を見る限り、挑戦型人材は驚くほど多く存在します。正確には、もともとその素養はあるが、発揮されていないのです。

安定型か挑戦型かは、人事制度とは無関係の、個人の資質に近いものです。

どれだけ安定型人材だけを採用してきた会社でも、一定数の挑戦型は必ず存在します。多くの場合、本人も無自覚のまま、安定型として振る舞っています。

重要なのは、そうした挑戦型人材を発掘・評価する人事評価以外の仕組みがあるかどうかです。

市民開発をうまく実践している企業では、表彰制度や社内コミュニティの運営などを通じて、挑戦型の行動を可視化し、評価しています。

「責任の所在」が曖昧になる

業務のデジタル化は、個人や一部署だけで完結するものではありません。複数の部署や役職、さらには顧客や取引先との関係が必ず絡みます。

DXは本質的に挑戦的な取り組みであり、不安定さと失敗を前提に、スピードを重視して進める必要があります。 では、失敗した場合はどうなるでしょうか。

多くの組織では、「仮説検証として価値があった」と評価されることは稀です。現実には、原因分析と再発防止策の説明が求められ、最終的には担当部署や管理職の評価・人事に影響が出ます。この構造のままでは、DX推進部長は何人いても足りません。

そこで選ばれるのが外注です。

仮説検証を外注できれば、失敗は外注先の責任にできます。DX推進部長の責任は「外注先選定の失敗」に局所化され、致命傷になりにくくなります。

内製化していれば、たとえ左遷されなくても、部下の異動やチーム解体が起こり得ます。組織構造上、誰かが責任を負わされるからです。この状況で「内製化を選べ」というのは、あまりにも非論理的です。

外注先の失敗は、失敗にあらずなのです。

市民開発がうまく機能している組織では、役割と責任を事前に細かく分解し、複数人で少しずつ負う構造を作っています。一人にすべての責任が集中し、キャリアが壊れることを防ぐためです。

DXを「プロジェクト」と呼ぶ

業務を「プロジェクト」と呼んだ瞬間、外注されやすくなります。プロジェクトとは、一定期間内に明確な成果物があり、投資対効果を事前に説明できるものです。

ITシステム開発は長らくこの文化で進められてきました。

その延長で、DXもプロジェクトとして扱われがちですが、DXは本来「事業や組織の変革」であり、短期間で明確な成果物が出るものではありません。

それでも「プロジェクト」として始めると、稟議書には期間・成果物・予算が並びます。条件が揃えば、「得意な誰かに任せたほうがいい」という判断になるのは自然です。

ここで強調したいのは、誰かを非難したいわけではありません。

「プロジェクト」と名付けた瞬間に、無意識のうちに外注へ流れる構造があることに、目を向けてほしいのです。

上手に市民開発を行なっている組織は、各施策を段階に分けて計画しています。小さい規模でうまくいけば少し大きくしてやってみる、というように施策自体はうまくいく限り続いてく仕組みです。

業務のデジタル化は個人活動である

「DXは業務時間外にやるもの」という風土が、いまだに残っている組織は少なくありません。

あなたの業務が楽になるのだから、あなたの個人の時間でやってくださいね、という暗黙の雰囲気です。

その象徴的な事例として、日本中で発生しているのが「Excelマクロ、誰が作ったかわからない問題」です。

ここ5年使い続けてきたExcelマクロの作成者がすでに退職しており、引き継ぎも行われていない。これは致命的な問題です。

多くの場合、作成者は自分の個人活動としてExcelマクロを作ります。

それが便利だからと周囲が使い始め、いつのまにか業務になくてはならない存在になります。そして、ある日突然動かなくなり、業務が円滑に進まなくなります。

業務に組み込まれてしまうと、善意で作った本人も「自分が保守します」とは言えなくなります。

業務ツールになった瞬間に責任が発生し、異動して別の業務に就いても、そのツールの保守責任だけが残り、いびつな指揮命令系統が生まれます。

このような組織では、そもそも草の根のデジタル化改善活動が評価されにくく、徐々に改善しようという意欲そのものが薄れていきます。

一方で、市民開発をうまく実践できている組織には、草の根のデジタル化改善活動を評価する仕組みがあります。

人事制度として取り込むのに時間がかかる場合でも、活動内容を社内で共有したり、経営層に報告したりするなど、正式な「業務」として扱う工夫があります。

こうした問題は、組織構造上、責任の所在が曖昧であることから発生します。

市民開発をうまく実践できている企業では、役割分担とそれぞれの責任を事前に明らかにし、細分化された責任を複数人で少しずつ負う構造を作っています。

その結果、ひとりがすべての失敗を背負い、左遷されてしまう、といった事態を回避できています。

内製する覚悟がない

これは、経営の権限を持つ方々に向けた話です。

根性論のように聞こえるかもしれませんが、経営者が内製する覚悟を持つだけで、内製化が進むケースは少なくありません。

「この業務は、失敗してもいい」

この言葉を発することができるのは、最終的なビジネス責任を負う経営者だけです。

この前提が崩れた瞬間、DXは必ず外注に向かいます。それほど重要なポイントです。

逆に、「失敗していいからやってみてほしい。責任は持つ」と社長が明確に発信すると、現場の社員が驚くほど前向きにDXを進め始める事例は数多くあります。

コストをかけず、即効性があり、最も費用対効果の高い施策と言ってもいいでしょう。

もちろん、この覚悟は発信だけで完結するものではありません。

DXを内製化し、継続的に推進するためには、組織基盤の整備が不可欠です。

教育予算、人事評価の見直し、一時的な生産性低下を受け入れる姿勢など、取り組むべきことは多くあります。

長期的に見れば、これらの施策は間違いなく重要です。

しかし短期的な視点では、どれだけ教育予算を投じても、評価制度を整えても、覚悟が伴わなければほとんど意味を持ちません。

まず必要なのは、経営者自身が内製化する覚悟を言葉として発信することです。

私たちは、DXの外注から内製への転換を、市民開発という考え方をベースにした「ふえん式」という形で事業として提供しています。

次稿では、ふえん式がどのように組織構造を変え、市民開発を支援し、現場DXを推進していくのかを、具体的に解説していきます。

次回は2月2日の掲載予定です。