ホーム
0フォロー
1フォロワー
なぜ“デジタル人材不足”を解消できない? 調査に見るDX推進の「現状と打開策」とは
根元 亮治ルートアシスト
「DX人材」という前に(そもそも論ですが)「自らのビジネスにおけるDX」を考える必要があると思います。
そしてそのためには、「デジタルの技術を道具・武器にする」ことで、今のビジネスをもっと良くできる「可能性がある」ことに「気がつく」ことができなければ、何も始められず(第一歩も踏み出せず)、従って必要とする人材も考えられないと思います。
あくまで「現状のビジネスモデル、スキーム」の中で、問題を見つけて、その改善策を考え、その解決のために「知っている範囲の中から」デジタル技術を探して、さらにそこに必要な人材を探す、ということであれば、改めて「DX」という言葉を使う必要もないだろうと思います。(デジタル技術による改善を否定する訳ではありません)
手段ではなく目的が大事だ、と言われますが、その考え方にはワナがあると覆います。
「デジタル技術」が持つ「(潜在)能力」を、理解しておいた上で、それをビジネスに組み込めば、何か新しいものが生まれるのではないか、ということを考えることは、「デジタル技術」に「引きずられる形で」方向を決めることとは違うと思います(例えは悪いかもしれませんが、航空機が戦争を変えたように)。
そのためには「DX人材を引っ張ってくる」という発想から離れて、自らのビジネスを理解している人に、デジタル技術の基本を学んでもらい、その上で、デジタル技術の活用例を、(自らのビジネスの範囲にこだわらずに、それを越えた事業分野も含めて)研究・調査し、そこから「アイデア出し」していく、ということが、遠回りしているようで、近道ではないかと思います。
そこで学ぶ技術というものは、必ずしも「最先端の」高度技術である必要はないと思います。いわゆる「DX成功事例」と呼ばれるものに、それほど突拍子もない技術は使われていないと思います。
そしてその「学び」というものは、ビジネスの遂行と切り離す必要はなく、例えば、先に挙げた「デジタル技術による改善活動」と並行する形で進めていくことが現実的だと思います(改善だけで満足してしまわないことが大切)。
もちろん、そのためには記事にあるとおり、その活動をバックアップする体制が必要だと思います。
未経験からITエンジニア「転職する前」に知っておきたい3つのこと
根元 亮治ルートアシスト
私が未経験者への研修を行っていたときには、「プログラムで何かを作る」に加えて、以下のような点を重要視していました。私自身の経験では、これらは実務に必要なスキルだと思うのですが、「未経験者研修」の文脈ではあまり取り上げられていないように感じます。私が知らないだけで、すでに「カリキュラム」としての常識になっているのかもしれません。
●必要なデータの整理と構造化(DB設計以前の)●最小機能・処理の見極め(足固め)からの積上げ●異常系処理(予防・検出と再実行可能な復旧)●改修(コードリーディングなど)●要求分析(仕様の読み込み)とヒアリング●仕様説明とレビュー●作業項目や工数・日程の見積りと報告、など
なぜ「今」プログラミングを学ばないと後悔するのか
根元 亮治ルートアシスト
「ビジネスのためにITを活用する」という意味では、ビジネス上の価値を生み出すのは「情報」(ビジネス上で意味のある「データ」)そのものであって、ITシステムはそれを扱うための道具(保存、入出力、処理)であると考えています。
そして、この「データ」の構造や、システムの性能・安定性などの条件によっては、ノーコードも(Web系などの)システムも、棲み分けが可能なものだと思います。
「データ構造が単純」(一枚のテーブルか単純なリレーション)であって、性能などの非機能要件がそれほど厳しくなければ、ノーコード(あるいはローコード)でも十分な場合があります。
これらは提供メーカーにロックインされるために、陳腐化やサービス終了のリスクがありますが、業務用のツールの作成には、制作前の「設計」(どんなデータを扱うか、どう入出力させるか)が重要で、それさえ残せば(制作自体は単純作業になるので)乗り換えも可能だと思います。
主要ベンダーのクラウド上で動作しているものならば、ある程度の安定性は期待できるでしょう。
一方で「データ構造が複雑」なものは、データの構造(どのようなデータを、どのように持つか)と、そのフロー・加工(データをどのように入出力し、加工するか)が複雑になりますから、対応できるシステムを設計・構築する必要があります。
データの構造の設計については、ビジネスと直結するために是非とも社内で抑えておきたい部分でもありますが、その一方でフロー・加工の設計は「UI/UX」「性能・安定性」などの面で高い技術力を持ったエンジニアが必要になります。
米国では企業で内製化することが多いのですが、日本ではほとんどが外注です。
今後は、いきなりすべて内製化とはいかないと思いますが、データ構造が単純なものはノーコードで内製化し、複雑なものは、主にデータの構造の設計を企業側で持ち、
データのフロー・加工の設計は、システム構造の基本知識のある企業側技術者と、高い技術力を持つ外部の技術者との協業・アジャイルで開発を進めていく形になるのではないでしょうか
(データの構造を企業側で抑えることで、データサイエンス・AIへの活用もあると思います)。
親密企業の参入を指示 平井卓也デジタル相に官製談合防止法違反の疑い
根元 亮治ルートアシスト
平井大臣の発言に「新しいシステムを実験的に入れてくれてもいい」というのは「実証実験」を想定した発言と思います。
実験を「高速に」繰り返しながらゴールを目指す「アジャイル」の手法を取り入れると仰っていましたから。特にAI技術では当然のことなので。
しかしながら、それにも「入札」が必要で、そこに「官製談合防止法違反の疑い」が生じる余地があって、もしそれが「アジャイル」に支障を生じる可能性があるのであれば、早急な対応が必要だと思います。
イーロン・マスクは、実験ロケットが爆発しても「データが取れたから成功」と言っていましたが、JAXAがやったら長官の首が飛ぶ、とも言われます。ITに限らず、各分野での早急な技術力立ち上げのためにも、手を打っておく必要があるでしょう。
中国ロケット残骸がインド洋落下 モルディブ近く、被害は不明
「わきまえる障害者になりたくない」JR東の対応に声上げた、車いすの伊是名夏子さん
根元 亮治ルートアシスト
障がい者の方にとっても、「自由に~へ行くことができる」が「目的」で、鉄道はその「手段」であって、「手段」には得意不得意があると思います。
鉄道や航空機は遠距離に強く、自動車はもっと小回りに強い。
なので「無人駅の階段で電動車椅子を駅員が手で運ぶ」という手段の議論から、もっと広く「出発地から目的地に線が繋がっていること」を目的にして、
広く交通機関全体で、得意不得意を補う形で、連携できる体制を考えていくべきではないでしょうか。
これは一私企業では無理だと思いますので、行政レベルで設置した調整機関の元に広く交通機関が集まる仕組みが必要と思います。
加えて言えば、現在、その線自体が繋がっていないところが多々あるだろうと思っています。
今回のように、曲がりなりにも一つ線が繋がっているところに、もう一つ鉄道の線を繋げることより、そちらを繋ぐ方が、まず優先されるべき課題だと思います。
マイナンバーカード保険証利用 本格運用先送りへ トラブルで
根元 亮治ルートアシスト
「データの整合性の確保」はシステムの根幹ですから、これが運用前に「偶然ではなく」しかるべきチェック体制の下で検出されたならば、これは健全な姿だと思います。失敗「そのもの」を問題視された結果として隠蔽に走る例も多々見てきましたから。
リスケによって生じたマイナス面も、うまく糧にして活用して頂きたいです。
なお、保険者番号のデータが「●」で入力されていた件、これは完全な邪推ですが、
わざわざ「●」を手入力した、というよりはOCRでの読み損ないをそのまま機械的に登録してしまったのではないかと思ってしまいます。
昨今のデジタル化の流れで、「紙」のデジタル化ツールが繁盛しているように見受けられますが、ツールの限界を見極めた上での正しい活用ができていなかったとすれば(邪推の上塗りですが)、サポートが必要かもしれません。
「ツールの限界の啓蒙」は、公平で冷静に対応しないと営業妨害にもなりかねませんから、難しいと思いますが。
【石川善樹】いくら便利なツールを増やしても、あなたの仕事が減らない理由
根元 亮治ルートアシスト
『「人」と「仕事」の、どちらが先に「定義」されるべきか』という問題提起だと読みました。
「組織が仕事を定義し、そこにリソースを割り当てる」という流れの中で、
「リソースとして人を割り当てる」という部分を更に見直して、
「デジタルツールを活用する」「もっと活用できるように仕事の内容を組み換える」と進めば、
デジタル化は進んでいくものと思います。
『先に「人」や「セクション」があって、そこにミッションを与えて、
それに対して、現場主導で、個々の責任範囲を重複させながらミッションを遂行する』
という考え方を持っている組織は、考え方を根本的に見直す必要があるのではないでしょうか。
また、「仕事を定義する人=マネジメント層」と「仕事を割り当てられる人」という立場が明確化されることも含めて、
これは痛みを伴うものになるかもしれません。
ひょっとしたら、日本の企業のデジタル化の遅れも、そこに起因するのかもしれません。
NORMAL
投稿したコメント