DXが進まないのはIT人材不足だけが原因ではない
アンドゲート田村です。
株式会社アンドゲートという会社の代表をやっています。
この記事では、DXが進まないのはIT人材不足だけが原因ではなく、構造上の欠陥があるというお話を書きます。
もしよろしければ「スキ」をお願いします。喜びます！
進まないDX
昨日「DXがうまくいっていない」という記事を見かけました。
要約すると…
IT投資をSIerへ丸投げしているからITの実動部隊がいない
日本はCIO(最高情報責任者)が設置されていないし、いても使えない
多重下請けでIT人材が低賃金になっている
その解決策として
人事制度改革をするべき
具体的には、職種別の賃金体系やDX人材のための会社を設立する
といったものです。
上記は「切り取り」ですので、正しくは原文をご覧ください。
目の前のDXは進んでいる
手前味噌で恐縮ですが、アンドゲートが関わるお仕事はDXが実現しています。
プロジェクト発足時には誰も思い描いていなかった「新しいコンセプト」「新しいビジネスモデル」「新しいワークフロー」「システム要件」がプロジェクトの成果物として生まれます。その後はリリーススケジュールに合わせて必要十分な機能を実装していきます。
聞こえはカッコ良いですが、実際は一つ一つ決めるべきことを決めていくしかなく、地道で泥臭いワークをひたすら繰り返します。
繰り返していくうちに元々あった「想い」が形になっていき、最終的には一つのストーリーとなって具現化します。
もちろん、プロジェクトの最中に
求めていたのは「DX」ではなく「デジタル化」だった
と気が付くこともありますので、DXが正義ではありません。
多重下請け構造でDXは無理
そのような活動を行っていてヒシヒシ感じるのは「答えは顧客の中にしかない」ということです。
そのためには経営や現場が「自分でやる意思」を持っているかが重要となります。
IT業界に蔓延する課題として「多重下請け構造」がありますが、私は全否定はしていません。
業務向けなど要件が決まっているシステムではIT土方方式の方が効率が良いこともあります。(私はやりたいと思いませんが)
多重下請け構造の問題点は下記です。
1. 「丸投げ」することにより「発注元がやるべきこと」がわからない
2. 指揮系統が多段となり小回りが効かなくなる
3. 発注元は支払った金額分の価値を享受できず、現場は能力以上の貢献が求められて疲弊する
多重下請け構造の諸悪の根源は「役割を特定していないこと」
役割を特定しないことで「この仕事は誰の責任でしたっけ?」などのコミュニケーション増加や
発注元は「金額払っているのに動いてくれない」
現場は「この金額でその仕事は…」といった「期待値」のブレが生じます。
「役割の特定」「疎結合な繋がり」にすることで問題点が解決します。
1. 「発注元がやるべきこと」がわかる
2. 指揮系統がシンプルになり機動力が向上する
3. 役割のない「中抜き」がなくなり費用の削減ができる
特に「DX」をお題としたプロジェクトはスピードが命ですので、無駄なコミュニケーションの削減や指揮系統の整理は効果絶大です。
「IT人材不足」の原因は何なのか
「慢性的なIT人材不足」と謳われて久しいですが、その「IT人材」とはエンジニアのことを指しているのか、マネージャーのことを指しているのかさえ曖昧です。
エンジニアはスキルを獲得し続けなければならない宿命を負っています。
なぜならITの専門性は常に細分化・深化が進んでおり、スキルの寿命は短い特徴があります。
現に、私がエンジニア人生で培ったITスキルの半分は既に淘汰されています。
「エンジニアはエンジニアリングに集中するべき」ではありますが、仕事では「マネジメント」が必要です。
マネジメントの領域はエンジニアリングの領域の先にあるものではなく、全く別のスキルセットが必要です。
そして「マネジメント」の専門性を持つ人材は「エンジニアリング」の専門性を持つ人材よりも更に希少です。
そのため組織のリーダーが「マネジメント」の専門性を持たずしてプロジェクトのマネジメントを行っており、プロジェクトが鈍化する原因の一つとなっています。
「IT人材が足りないのであればIT人材を育てて増やせばいいではないか」
そう思われるかも知れませんが、これはマリー・アントワネット状態です。
驚くほど現場が見えていません。
エンジニアの育成は前述の通り、細分化・深化するスキルを追わねばならず現場で活躍するレベルになるためには相当の訓練が必要です。
スクールで学習するエンジニアもいますが「Javaで簡単なシステム」が作れる程度では現場では足手まといです。
また、エンジニアの数を増やせば良いかと言うと、そうではありません。
2人のプロジェクトに対して2人追加した場合、開発力は2倍になりますが
4人に対して2人追加した場合は1.5倍
10人に対して2人追加した場合は1.2倍です。
プロジェクトの規模が大きくなればなるほど、開発力の増強にはコストがかかるようになります。
この現象を私は「スケールアウトのジレンマ」と呼んでいます。
IT人材不足を「量」で補うのではなく「質」を変える
「質」を変えるとは「無駄なものは作らない・作らせない」です。
エンジニア不足に対してエンジニアを足すのではなく、有限であるエンジニアリングリソースを効率的に利用するアプローチに切り替えます。
要件定義の時点で、必要以上に要求のレベルが上がっていたらハードルを下げる
要件の数が増えてきたら、ロードマップを作り直してリリースタイミングを再考する
要件が曖昧だったら要件を詰めてからエンジニアに依頼する
どれも当たり前のことですが、エンジニアは要件を詰めるスキルを持ち合わせていないため、大抵の場合は「言われた通り」に作ります。
企画側の暴走を防ぎ、プロジェクト活動の効果を最大化させるのは「マネジメント」の役割です。
新規事業は逆算で生み出せない
新しいことへのチャレンジは「答え」がありません。
「答え」がないため、ゴールからの逆算ができずバックキャスティングのアプローチが使えません。
これは訓練されたビジネスマンであればあるほど「怖い」と感じます。
市場の動向にプロダクトを追従するためには常に変化する必要があります。
「走りながら考える」必要がありますが、一度決めたことを覆してはいけない文化に身を置いていると、どうしてもスピードが鈍化します。
未知の領域に対しては「方法論」を使うしかない
逆算できない新規事業作りに対しては「知識」ではなく「方法」からアプローチする他ありません。
フォアキャスティングのアプローチでしか新規事業は生まれません。
これはとても覚悟が必要なことです。
上司から「いつになったら収益化するんだ」と詰められるような組織から良い新規事業は生まれません。
新規事業は「成功するまで続ける」類のものです。
とはいえ、スケジュールや予算の都合がありますので、観測可能なKPIに落とし込んで進めていきます。
この「方法」のアプローチを、アンドゲートでは「方法論」と呼んでおり
新規事業やDXといったワードを使う案件では必要不可欠な考え方です。
仕事の「進め方」を変えるダンドルクラウド
IT業界に蔓延している課題は、構造を変えれば解決に向かうであろう、というお話でした。
「多重下請け構造」は「役割を決める」
「慢性的なIT人材不足」は「構造を組み替える」
「新規事業作りのノウハウ不足」は「方法論」
最後に清々しくアンドゲートの新プロダクト「ダンドルクラウド」の宣伝をいれておきます。
現在鋭意開発中です。
「PMって特定の人しかできないよね」
から
「PMって誰でもできるよね」
に変換したので、次は
「PMって人じゃなくてもできるよね」
に挑戦しています。
少しでも気になる方、お気軽にお問い合わせください！
dandlecloud@andgate.co.jp
最後まで読んだ方！是非「スキ」をお願いします。喜びます！