日大の学部訪問で広がる将来の選択肢
【AI時代】「プログラマー」と聞いて、何をイメージしますか?
「AIがコードを書いてくれるから、プログラマーはこれから不要になる」
そんな意見を見かけます。
でも、ここで少し気になることがあります。
そもそも皆さんがイメージしている「プログラマー」って、どんな仕事でしょう?
Webサイトや業務アプリのコードを書く人?
それとも、車・ロボット・工場設備などの組み込みシステムを、センサー、マイコン、通信、モーター、制御まで含めて動かす技術者?
同じ「プログラミング」でも、必要な知識も仕事の中身もかなり違います。
AIによって「コードを書く作業」が減ることと、「プログラマー・ソフトウェア技術者の需要が減ること」は、本当に同じなのでしょうか。
文系・理系で、この「プログラマー」という職業のイメージに違いはありませんか?
実際、経産省のモビリティDX戦略では、2030年にモビリティ分野でソフトウェア人材が5.14万人不足、そのうちソフトウェアエンジニアが2.71万人不足すると推計されています。
つまり、
「AIがコードを書く」
↓
「プログラマーが不要になる」
↓
「理系人材の需要も減る」
と単純に考えてよいのでしょうか?
AIによって減る可能性があるのは、まず「コードを書くことそのもの」の仕事。
一方で、AI・ロボット・自動車・工場設備など、ソフトウェアを現実の機械に組み込んで動かす仕事は、単純な「コードを書く仕事」とは別物です。
では、「プログラマー」と聞いたとき、文系と理系では、そもそも見えている世界が違うのでは?
AI時代に減るのは「プログラマー」なのか。
それとも、
「コードを書くことだけを仕事にしている人」なのか。
このあたりを、文系と理系から見える世界の違いとして、考えてみたいと思います。
サイボウズの「kintone」は、まさに「コードを書かなくても業務アプリを作れる」方向の代表例ですよね。
これを見て、
「AI+ノーコード」
→「プログラマー不要」
→「理系人材も不要」
となるのでしょうか。
「中国のヒューマノイドが走った!」
→「日本はフィジカルAIで勝ち目なし」
そして今度は、
「kintoneでコードを書かなくていい!」
→「プログラマーはいらない!」
→「理系もいらない!」
いやぁ、ずいぶん便利な世界観です(笑)
目に見えたものをそのまま技術の全体像だと思えば、確かに話は簡単です。
走ったロボットを見て「技術力」を判断し、コードを書かないアプリを見て「技術者不要」を判断する。
これでAI時代の産業構造まで語れるのだから、ある意味すごい。
「見えた!」=「理解した!」ではないんですけどね●笑
そして面白いのは、サイボウズ自身も「ノーコードだからエンジニア不要」とは言っていないことです。
kintoneは、JavaScriptによるカスタマイズやAPI連携にも対応していて、ノーコードで対応できる領域と、コードやIT知識が必要になる領域を分けています。
つまり、kintoneが示しているのは、
① 「コードを書く作業」は減らせる
ということ。
顧客管理、日報、問い合わせ管理、ワークフロー、プロジェクト管理など、以前ならプログラマーに依頼していた業務アプリを、現場側がノーコードで作れる。
これは確かに、「プログラミングそのものの需要を減らす技術」の一例です。
でも、
② 「ソフトウェア技術者そのものが不要になる」
とは全く別の話。
kintoneのようなノーコード基盤そのものを作る人、JavaScriptで高度なカスタマイズをする人、APIや外部システムとの連携を設計する人、大規模システムとの統合やセキュリティを考える人は、当然必要になります。
要するに、
「コードを書く量が減る」ことと、「ソフトウェアを設計・開発できる人が不要になる」ことを混同してはいけない。
むしろAIやノーコードが普及するほど、単純な「コードを書く作業」と、何を作るのかを決め、システムを設計し、現実の業務や機械につなげる仕事を分けて考える必要があると感じます。
「プログラマー」と聞いたとき、文系と理系では、そもそも見えている世界が違いますよね〜
「プログラマー」と聞いて、
「パソコンに向かってコードを書く人」
をイメージするのか。
それとも、
「数学や物理、情報、機械などの知識を使って、現実の問題をコンピュータでどう解決するかを考える人」
までイメージするのか。
この違いは大きいと思います。
理系から見ると、プログラミングはあくまで問題を解くための一つの道具です。
例えば、イメージしやすいのが「組み込みシステム」です。
自動運転を例にすると、
▲ センサーから速度や周囲の状況を取得する
↓
▲ コンピュータがデータを処理する
↓
▲ 「減速する」「停止する」などを判断する
↓
▲ 制御プログラムがモーターやブレーキなどを動かす
↓
実際の車が動く
という流れになります。
この▲の部分には、それぞれプログラムが組み込まれています。
つまり、プログラムは単に「画面に何かを表示する」ためにあるのではありません。
センサーから情報を受け取り、計算・認識・判断し、その結果を使って現実の自動車を動かす。
これも、プログラミングの一つの姿です。
もちろん、AIがこうしたコードを書くことも、これから増えていくかもしれませんが、
「では、何を計算させるのか?」
「どんなデータを使うのか?」
「どんなアルゴリズムが必要なのか?」
「その判断は本当に正しいのか?」
「異常が起きたらどうするのか?」
「システム全体として安全に成立しているのか?」
という問題は残ります。
つまり、
「AIがコードを書く」
↓
「プログラマー不要」
↓
「理系人材も不要」
とは、なかなかならない。
むしろAIによって「コードを書く」という作業が自動化されれば、その前後にある問題設定・数理モデル・設計・検証・システム化といった部分の重要性が相対的に高まると思います。
「プログラマー」という言葉から、画面に表示されるコードだけを見るのか。
それとも、そのコードによって何を計算し、何を設計し、何を実現しようとしているのかまで見るのか。
エデュを見ていると、同じ「プログラマー」という言葉でも、文系と理系では、そもそも見えている世界が違うのではないかと感じます。
>自動運転を例にすると、
▲ センサーから速度や周囲の状況を取得する
↓
▲ コンピュータがデータを処理する
↓
▲ 「減速する」「停止する」などを判断する
↓
▲ 制御プログラムがモーターやブレーキなどを動かす
↓
実際に車が動く
という流れになります。
この▲の部分には、それぞれプログラムが組み込まれています。
つまり、プログラムは単に「画面に何かを表示する」ためにあるのではありません。
「コンピュータ言語の通訳」というのは、ずいぶん狭いプログラマー像ですね。
自動運転やロボット、工場設備の組み込みソフトまで「通訳」と呼ぶのでしょうか?
高校物理が、未履修みたいですね。
例えば自動運転なら、現実の車を動かすために、力学・電磁気学・熱力学・流体力学、さらに制御工学や数学、AIなどの知識を、プログラムにつなげていく必要があります。
つまり、単に「言語を翻訳する人」ではなく、
物理世界 → 数理モデル → アルゴリズム → プログラム → 現実の機械
をつなぐ仕事もある。
やはり、「プログラマー」と聞いたとき、文系と理系では、そもそも見えている世界が違うのかもしれませんね〜
補足すると、自動運転でプログラムを書くというのは、単に「停止してください」とコンピュータに翻訳することではありません。
例えば制動距離なら、単純化すると
d = v² /(2μg)
と表せます。
速度 v、タイヤと路面の摩擦係数 μ、重力加速度 g が関係します。
つまり、雨や雪で摩擦係数 μ が小さくなれば、同じ速度でも制動距離は長くなる。
こうした現実世界の物理現象を理解し、数式やモデルに落とし込み、センサーから得たデータを使って計算し、それを制御プログラムとして実装する。
これも「プログラミング」です。
「プログラマー=コンピュータ言語の通訳」とだけ捉えると、こういう組み込み・制御の世界は、ほとんど見えなくなってしまうんですよね。






























