非プログラマーがDXをするのが難しい具体的な理由3選

こんにちは、はじめまして。ゴリラです。
私はプログラマー歴10年超の経験を持ち、これまで社外CTOとして多数のDXプロジェクトに携わってきました。

Twitterアカウントはこちら👇
https://twitter.com/dxsoudan

さて、以前から私は「DXは専門知識があるエンジニアと二人三脚でやるべき」とお伝えしてきました。
ズバリ一言で言えば、「素人じゃできないよ」ということです。
この主張については、賛否両論あると思います。
そこで、私の主張をさらに肉付けするために、今日は具体的に「非プログラマーがDXをするのが難しい具体的な理由3選」というテーマで書いてみようと思います。

理由その1. データの一元管理体制に移行する技術の有無

DXとはなにか？でお伝えしたように、DXとは経営から現場まで一気通貫で同じデータが流れるように生まれ変わらせることです。
ということは、必然と部門間のデータ連携を果たさねばなりません。
ほぼすべての企業は「部門」という縦割りで経営しているので、営業部なら営業のデータ、広報部なら広報のデータと、それぞれ独立・分断したマスターデータを持っているわけですが、DXをはじめる場合は、それらを一元管理できるような形で繋ぎ込む or 作り直すという選択を迫られます。

では、ここで質問です。
あなたはハレーションが起こらないように、できるだけ現場のストレスを最小限に抑えながらデータを一元管理できる体制に移行させることができますか？
「現場の非難なんかクソくらえ。パワープレイで移行できるんじゃ。」というカルチャーの会社であれば、そんなに神経質にならなくても大丈夫だと思います。
しかし、そうではない大多数の会社にとっては、かなり腰の重い作業になると思います。
このデータ統合によって、生産性の低下を免れることができることができるのはごく少数です。

優秀なDX人材であれば、この問題をエレガントに解決することができます。
現場の人に「Beforeのデータ管理手法よりもAfterの手法の方がいいじゃん！」と、逆にモチベーションを高めさせ、すぐに生産性を向上させることができる能力を持っています。

理由その2. 内製化・外注化の判断基準の有無

プログラミングに対してまったく理解がない会社は、デジタルの課題に直面したとき、システムのことはすべて外注するという選択肢しか採用することができません。
ぶっちゃけ、そんな会社はITベンダーからすれば「ネギを背負ったカモ」です。
対等な会話をすることができないので、ベンダー側に都合のいい条件になったり、ほぼ言い値のような金額で飲まざるをえない場面がよくあります。

それに対抗できるカードがあるとしたら、やはり内製化です。
内製化をすることで、自分たちの要望に適ったコードを書くことができる利点があるのはもちろんですが、社内の事情を汲み取る時間を大幅に削減することができることや、正確な投資対効果の見積りをすることができることが一番の利点です。

私のこれまでの経験で言えば、内製化していないDXプロジェクトが成功した例を見たことがありません。
外注した会社の話を聞くと、「要件定義に時間をとられ、莫大な費用を払ったにも関わらず、部分的な効率化しか果たせなかった」という例が多発しています。
これは本当にあるあるな話なので、読んでいて頷ける方も多いのではないかと思います。

余談ですが、このIT丸投げ外注文化はアメリカでは滅多にありません。
アメリカにももちろん外注エンジニアはいますが、日本とは違い、競争力の源泉となる価値を生む基幹システムとそうでない些末なシステムを明確に切り分けて考えていて、後者に外注エンジニアを採用する考えが一般的です。
さらに、アメリカであれば同じ英語圏のインドが外注先候補一番手として挙がってきます。
社内の基幹システムはアメリカ在住で経営層に近いエンジニア、それ以外のシステムはインド在住のエンジニアに仕事を振っているのが多くの会社で共通しています。

理由その3. デジタルの恩恵を実感した経験の差

これが一番根本的な理由だと思います。
「デジタルの力って必要だよね」という主張は、大なり小なり全員が賛同してくれると思います。
しかし、その必要性の実感度には大きな差があります。
当たり前ですが、プログラマーであればあるほど、デジタルに救われた経験が多いので、この必要性を身に沁みて分かっているのです。

ちなみに、私にとっては、2013年に「GitHubにpushしたら、Jenkinsがテストコードを実行してくれて、問題なければ本番にデプロイされる」という経験をしたことが、一番の目からウロコの経験でした。
この感覚が、僕にとってはベルトコンベアにモノを流したら自動でモノが完成していくような、デジタル化による業務効率化の象徴となる出来事でした。

このような直接的な体験がない人にとっては、DXの本当の価値や可能性を理解するのが難しいかもしれません。
デジタル技術がもたらす変革の大きさや、それによって得られる競争優位性を具体的に理解できていないのです。
そのため、非プログラマーがDXを推進する際には、以下のような課題に直面することがあります。

• 投資対効果の見積りが難しい

• 技術の選定や導入順序の最適化ができない

• 従業員の抵抗を予測し、適切に対処できない

デジタルの恩恵を実感した経験を持つDX人材は、これらの課題に対して、より適切に対処することができます。
技術の可能性と限界を理解し、現実的なゴールを設定し、そこに至るまでの道筋を明確に描くことができるのです。

さいごに

最後までお読みいただきありがとうございました。

一応断っておくと、この記事を書いた意図として、「プログラマーの俺ってすげえだろ？」とドヤりたいわけではありません。
「ネギを背負ったカモ」なのに、それに気づかずにIT予算を無駄遣いしている会社が日本に多すぎて、「このままで大丈夫か？」となったので書いています。

次回もまた、具体的なDXなどについて共有していきます。

さて、さいごに宣伝させてください。
読者の中には、
「ゴリラの言っていることが全然わからんのだが・・・？」
「そんなDX人材身近にいないんだけど・・・？」
という方もいるかもしれません。

そんな方に、ゴリラが無料で相談に乗りたいと思います。
これからDXをはじめようとしている方、
DXをはじめたけど行き詰まっている方、
DXがそもそも何か分からない方、
どんな方でも歓迎です。

Xで気軽にDMいただければと思います。
この記事が何かあなたのお役に立てると嬉しいです。
それでは。