最近、学校でのプログラミング授業の必須化など、将来に向けてIT技術者を増やそう！という国を挙げての施策や、地方自治体・企業などが増えている。

そんな中、今現在でIT技術者が不足しているという報道。しかし、そこには違和感も感じる訳ですよ。IT技術者を増やしたいなら何をしないといけないのか？を話してみる。

報道にある「IT人材不足」報道

Yahoo!ニュースを見ていたら出てきたこの情報

Yahoo!ニュース

 

1574 Shares

167 Users

53 Pockets

正社員不足、企業の45％に＝IT関連で深刻―帝国データ調査（時事通信） - Yahoo!ニ...

https://headlines.yahoo.co.jp/hl?a=20170824-00000074-jij-bus_all

帝国データバンクは24日、人手不足に関する企業の動向調査結果を発表した。「正社員が - Yahoo!ニュース(時事通信)

内容を一部抜粋すると

「正社員が不足している」と回答した企業は、2016年7月の調査に比べ7．5ポイント増の45．4％となり、06年5月の調査開始以来の最高を更新した。人材難はIT関連業種などで深刻化しており、企業活動を制約する可能性もある。

確かに、ダイコクの働いている会社でも人手不足は大きく感じている。ただ、「人手不足だから正社員をいっぱい入れよう！」とはならない。「協力会社に人材を依頼しよう！」が今の主流。仕事がなくなった場合に調整しやすいからだ。

協力会社側は自社で人材用意するか協力会社の協力会社に依頼をする。その協力会社も人手不足で・・・という連鎖が起きているのが今のIT人材不足の構図。

だから元記事の「正社員が不足している」という報道はちょっと違和感を覚える。そもそも、大元は正社員を取ろうとしていないのではないか？

正社員が不足する理由

では、協力会社側で正社員が不足する理由は・・・給料が安いからに他ならない。なんで給料が安いか？請け負う仕事の単価が安いから。

IT業界って人月単価で仕事の値段を決める事が多い。バイトやパートと同じで時給いくらの考え方。例えばプログラム開発に100時間かかるから１時間3,000円で30万円になります的な。

この時、100時間が適正な時間でそのまま契約できればいいけど、値引きを要求される事がある。10時間分を値引きすると、100時間でする作業を90時間でしなければ正規の利益が出ない。

そうすると、10時間を短縮できる「スキル」を持っている人が作業しないといけない訳です。仕事が早くできる人ほど、安く仕事をする不思議な世界。同じ仕事量なのに残業をする人の方が褒められるのと似てますね。

するとそれが「常態化」する。そうなると正社員を取る時に「スキル」を持っている人必須になる。素人が門戸を叩こうと思っても叩く前に追い出されてしまう訳です。

スキル持ってる人からみると安すぎて仕事する気になれない。

本来、会社は新卒等を「育てて」いくのですが、今のこの業界は人手が足りてないので「即戦力」となる人しか採用しない。だから募集に対してますます応募できる人が狭まっていくのです。

負のスパイラル。

先の人月単価でしか収入が得られないと言うのも１つの原因ですね。お金を稼げないスキル不足の人を抱えていても赤字になってしまうばかりだから採用しにくい。

仮に素人がやるから通常100時間のところ、150時間で作業しまっせ！で通る優しい世界だったら人不足は解消する。やってみたい人はたくさんいる。

IT業界って技術は日進月歩だけど人の考え方は昔のまま

IT業界ってなんでか知らないけど、プログラマよりSE、SEよりプロマネの方が偉いと言う風潮がある。そして単価も高くなっていく。しかしながらそれはただの「役割」であって上位に存在するものではない。

しかし、そんな風潮があるからプログラマは若い世代で固められ、マネージャーは年寄り世代で固められる。

年齢が上がってプログラミングが覚えられなくなるいわゆる「プログラマ35歳限界説」も実はこう言うところから生まれたのかもしれない。年齢上がるごとにプログラミングに触れる機会が大幅に減るから新しいプログラムを覚えられなくなる。

実際に新しく実装された機能に触れてみないから機能を理解できずに設計書には古いやり方しか反映されない。それが繰り返される。

基本、新しい物好きは若い人材に多い。だったら設計段階から新しいことを知っている新しいもの好きの人材にも参画してもらうべきだ。

不足する原因に向き合わない限り、今の構図は変わらない

業界内から見ていて「人が少ない理由」は今まで話してきたことのように感じています。これ、重症的な考え方だと思うんですよね。

コスト計算も今時の作り方を反映できてない。昔ながらの「手続き型プログラミング」で１ステップあたりで計算できていた時代なら通用していたのは分かる。しかし、オブジェクト指向プログラミングや、GitHubを活用したプログラミングなど今時のコーディング方法には対応できてない。無理矢理のこじつけで対処している。

人が足りない！って叫んでいるのは実際にには「教えなくても自立して出来る人がいない！」って叫んでいるんです。なり手が少ないんじゃない。経験者がいないんだ！と。

本当に人手が欲しいなら、１−2年後を見据えて人を採用すべきだと思うし、プロジェクトも時間単価じゃなくて、重要度やオリジナル度などでコスト評価するべき（それが時間単価に反映されるならそれでも良いと思う）

小学校からプログラミングに触れる時代になろうとしている。この教育を受けるこの子らが就職する１０数年後までに業界も変わっておかないと、ダサい業界になりかねない。ITドカタなんて揶揄される時代を塗り替えておこう！

小学生からはじめるわくわくプログラミング

阿部 和広 日経BP社 2013-07-25 売り上げランキング : 1397 Amazon Kindle 楽天ブックス 7net by ヨメレバ

プログラムはなぜ動くのか　第２版　知っておきたいプログラムの基礎知識

矢沢久雄 日経ソフトウエア 2007-04 売り上げランキング : 25223 Amazon Kindle 楽天ブックス 7net by ヨメレバ

ガジェット・・・というよりプログラミング教育用アイテムの紹介。

子供のプログラミング能力向上に１役買う製品

スクラッチ2.0

スクラッチ2.0とは子供向けビジュアルプログラミング言語でウェブブラウザー上でプログラミングが出来るツールです。

無料で利用でき、子供を中心に世界中の人たちが利用しています。

サイトをザックリ見たところ、海外の人が多い。日本人の参加者は少ないです。

ビジュアルプログラミング言語というのは特定の機能を持った図形を組み合わせて動きを制御出来る言語です。

ワークフローとも呼ばれますね。

Webサイト

nekoboard2

今回、発売されたnekoboard2はそんなスクラッチ2.0に対して命令が出来るセンサーボードです。

以下、HPより引用

nekoboard2には明るさセンサー、音センサー、ボタン、スライダーセンサーの4つのセンサーを搭載しています。加えて、他の抵抗センサーを取り付 けられるピンソケットを4つ搭載しています。Micro USBケーブルでパソコンに接続することで、各種センサーの値をプログラムの動作に反映させることができます。

端的に言うと、nekoboard2に付いているセンサー類によってスクラッチ2.0に命令を送り動作を変更するためのアイテム。

このアイテム単体はセンサー機能しか無いので何もできません。スクラッチ2.0で活用できるプログラムを書いてこそのアイテムです。

まとめ

プログラミングをするときに一番わかりやすいのは「事象が発生したら動きが変わる制御をする」という事。「目に見えるもの」だからね。

プログラミングは論理的に考え、想定してコーディングする事が多い。

今回のアイテムがあれば理解しやすい。また、値段も１つ2,500円と始めやすい値段である事も魅力的。

スクラッチ2.0の存在は初めて知った訳ですが、無料で始めれるので子供の教育に活用できると良いですね。

mag.switch-science.com

 

243 Shares

1 User

16 Pockets

スクラッチ2.0で使えるセンサーボード「nekoboard2」を4月27日に発売します。

http://mag.switch-science.com/2016/04/21/nekoboard2/

ゲームで遊ぶな、ゲームを作ろう!スクラッチ2.0アイデアブック―ゼロから学ぶスクラッチプログラミング

石原 正雄 カットシステム 2014-04 売り上げランキング : 5491 Amazon Kindle 楽天ブックス 7net by ヨメレバ

※一個前のバージョンです。

nekoboard

posted with カエレバ

スイッチサイエンス

Amazonで購入

Yahooショッピングで購入

7netで購入

手続き型とは

簡単に言うと、書いたプログラムを上から下に読んでいけば理解できるし、何してるのか？が全て見える書き方である。ある処理の塊をサブルーチンとして関数化するけどどこで何やってるかは一目瞭然。

オブジェクト指向型とは

処理をオブジェクトとしてまとめておき、必要なときにそのオブジェクトを生成し必要なパラメータを与えたり、メソッドを呼び出したりして使うもの。基本的にオブジェクトは処理の最小単位に分かれている。

手続き型しか知らない人が陥る事

手続き型しか知らない人がオブジェクト型のプログラムを解析しようとする時に実施して、よく分からなくなって挫折するのが「スタートからゴールまで 順番に処理を追う」という方法を試す事にある気がする。先にも書いたように、処理は最小単位に別れているので、処理を追っていくと別のメソッドを追って、 メソッドを追って・・・とするうちに何をしているのか分からなくなる。図に表してみようとする（フローチャートを描く）とグチャグチャになりやすい。そも そも、オブジェクトを生成するという概念が無いと、より分からなくなる。

似て非なる言葉

オブジェクトの生成というのは手続き型で言えば「サブ関数に移動する」と勘違いしやすい。というか、最初のうちは同じ事だと思っていた。

やらかしやすい事

Javaって手続き型でもオブジェクト指向型でもプログラムは書ける。どちらかを使うのではなく、どっちも書ける。だからオブジェクト指向型で構築されたプログラムを手続き型しか知らない人が追加でサブ関数的に処理を描く事も可能になる。 違いが分かってくると何でもないけど、最初は分からずに書いていたので保守性の悪いプログラムにしてしまっていた。

新しく手続き型しか知らない人がプロジェクトに来たらどう教えるか？

で、タイトルにつながるのだがプロジェクトに手続き型しか使った事がない人がやって来る模様。本人もオブジェクト指向で作った事はないと言っている のでどうしたもんか？と。自分が理解出来たのはある日突然の閃きのように「！！分かったっ！！」ってなったから。ずっと同じ事をやっているとある日突然理 解する・・・ってやつです。 でも、プロジェクトは閃いてくれるのを待ってはくれない。そして、期間限定のミッションなので新しい人はこのプロジェクトが終わったら去っていく人。立つ鳥跡を濁さずじゃないけど、プロジェクトを引っかき回すような事はして欲しくないし・・・難しいものです。