ITエンジニアの過半が使いたくない、不人気ランキング不動の1位は「あの開発言語」

https://xtech.nikkei.com/atcl/nxt/cpbook/18/00062/00003/?i_cid=nbpnxt_ranking

アンケートでは、今後スキルを磨きたい言語を複数回答で選んでもらった。その結果、スキルを磨きたい言語の第1位は「Python」だった。回答者711人中435人がスキルアップを望んでおり、6割以上のエンジニアに選ばれている。

今後スキルを磨きたい言語

今後スキルを磨きたい言語[画像のクリックで拡大表示]

 『最近のAIシステムやデータ分析システムの構築にPythonは欠かせないプログラミング言語である。これらシステムを構築するためのライブラリーやフレームワークの多くがPythonプログラムで利用できるからだ。6割以上のエンジニアがスキルを磨きたいと言語に選んだのは納得できる。

 第2位は「JavaScript」(201人)だった。Web技術を用いたシステム開発にJavaScriptは欠かせない。利用している言語で第1位だったこともあり、スキルアップしたいエンジニアも多いのだろう。第3位は「C#」(160人)、第4位は「Java」(126人)が入った。基幹系システムで多く使われているC#やJavaもスキルアップしたいエンジニアが多い。

 注目したいのは第5位の「Go」(110人)と同率で第5位の「TypeScript」だ。Goは米グーグル(Google)が開発したプログラミング言語だ。高速処理が売りのプログラミング言語で、主にサーバー側で稼働させて高速な処理を実現したい際などに利用する。

TypeScriptは米マイクロソフト(Microsoft)が開発したプログラミング言語だ。コンパイルによってJavaScriptコードに変換できる。しかも型やクラス機構などが備わっており、JavaScriptよりも安全なコードを記述できるのが売りだ。グーグルが中心となって開発したWebアプリケーションフレームワークである「Angular」ベースの開発に利用できる。

 GoとTypeScriptは登場したのが2010年前後と比較的新しいプログラミング言語である。これらの言語のスキルを磨きたいというエンジニアが多いことから、今後JavaやC#といった定番言語以外の新言語がシステム開発に利用される機会が増えると推測できる。

利用したくない言語の第1位は不動

 PythonのようにITエンジニアの多くがスキルを磨きたいと思っている言語がある一方、利用したくないという不人気な言語もある。アンケートでは今後利用したくない言語を複数回答で選んでもらった。いわば、プログラミング言語の不人気ランキングである。

今後利用したくない言語

今後利用したくない言語[画像のクリックで拡大表示]

 アンケートの結果、第1位は「COBOL」(363人)だった。過半のエンジニアが今後利用したくない言語に選んだ。過去2回の調査でも「今後、スキルを磨かなくてもよいと思う言語」の第1位にCOBOLが選ばれている。もはや不人気ランキング不動の1位である。

 COBOLは多くの基幹系システムで稼働し続けているとはいえ、COBOLを利用する新規案件は少ない。事実、COBOLをメインに利用していると回答したエンジニアの86.4%は、主な業務を「運用・保守」または「エンハンス」と回答している。

 利用したくない言語の第2位は「FORTRAN」(272人)、第3位は「Visual Basic(VB.NET以外)」(228人)である。1~3位にランクインした言語はどれも新規の開発案件が少ない言語だった。また歴史が古く機能拡張がない点も共通している。こうした言語はITエンジニアに敬遠されているという結果になった。』

COBOL
https://ja.wikipedia.org/wiki/COBOL

『コードの実例
実例1 (Hello world)
000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. HELLO.
000300 PROCEDURE DIVISION.
000400 DISPLAY ‘HELLO, WORLD!’.
000500 STOP RUN.

出力 HELLO, WORLD!
この例では DISPLAY命令を使って文字列をコンソールまたは標準出力に出力している。

COBOLはレコードレイアウトの決まったファイルの処理に使われることが多い。その場合はふつう、ファイル節(FILE SECTION)にレコードとそれを構成するデータ群の定義を書く。そして、実行部(PROCEDURE DIVISION)のREAD文、WRITE文などでそのレコードを読み書きする。

実例2 (Hello world)
作業領域節(WORKING-STORAGE SECTION)にデータを定義した例。

000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. HELLO.
000300 DATA DIVISION.
000400 WORKING-STORAGE SECTION.
000500 01 HELLO1 PIC X(15).
000600 01 HELLO2.
000700 03 FILLER PIC X(06) VALUE ‘HELLO,’.
000800 03 FILLER PIC X(01) VALUE SPACE.
000900 03 FILLER PIC X(06) VALUE ‘WORLD!’.
001000 03 FILLER PIC X(01) VALUE SPACE.
001100 03 FILLER PIC 9(01) VALUE 2.
001200 PROCEDURE DIVISION.
001300 MOVE ‘HELLO, WORLD! 1’ TO HELLO1.
001400 DISPLAY HELLO1.
001500 DISPLAY HELLO2.
001600 STOP RUN.

出力 HELLO, WORLD! 1
HELLO, WORLD! 2


実例3 (Fizz Buzz)
000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. FIZZBUZZ.
000300 DATA DIVISION.
000400 WORKING-STORAGE SECTION.
000500 01 I PIC 9(3).
000600 PROCEDURE DIVISION.
000700 PERFORM VARYING I FROM 1 BY 1 UNTIL I > 100
000800 EVALUATE FUNCTION MOD(I 3) = ZERO
000900 ALSO FUNCTION MOD(I 5) = ZERO
001000 WHEN TRUE ALSO TRUE
001100 DISPLAY ‘FIZZBUZZ’
001200 WHEN TRUE ALSO FALSE
001300 DISPLAY ‘FIZZ’
001400 WHEN FALSE ALSO TRUE
001500 DISPLAY ‘BUZZ’
001600 WHEN OTHER
001700 DISPLAY I(3 – FUNCTION INTEGER(FUNCTION LOG10(I)):)
001800 END-EVALUATE
001900 END-PERFORM.
002000 STOP RUN.

出力

1
2
FIZZ
4
BUZZ
FIZZ
7
8
FIZZ
BUZZ
11
 (中略)
FIZZBUZZ
91
92
FIZZ
94
BUZZ
FIZZ
97
98
FIZZ
BUZZ』

「自称プログラマー」の哀れな末路、仕組みを考えないコーダーはエンジニアにあらず

https://xtech.nikkei.com/atcl/nxt/column/18/00148/082800134/

※「プログラマーと、コーダーは違う。」…。

 この業界ではたらく人は、よく見ておいた方がいい…。

『(木村 岳史 日経クロステック/日経コンピュータ)

たまに哀れな「自称プログラマー」に関する話を聞くときがある。例えば「あのさぁ、何をつくってほしいか、きちんと仕様にしてくれないと、システムなんかつくれないじゃん!」とか「何をつくるかを決めるのはビジネスサイドのあんたたちの仕事だろ。俺の仕事じゃないぜ」と言い放って、事業部門の人を怒らせたり涙目にさせたりする愚か者たちだ。

 一見とても正しい発言のように思える。というか大概の場合、発言としては正論であったりする。同業者なら「よくぞ言ってくれた!」と喝采する人もいるはずだ。何せ最近は、要件定義が全くできず、「何をつくってほしいのか」まで開発サイドに丸投げしてくるビジネスサイドのアホが多数いる。そんな連中を一言で撃退できる自称プログラマーは称賛すら集めるだろう。

 だが、この自称プログラマーが本心からそう思っているなら、やはり愚か者である。まず本質でないほうの理由から説明する。「何をつくるかを決めるのはビジネスサイドの仕事だろ!」と言い放ったが最後、「逆も真なり」となる。システム開発プロジェクトでビジネスサイドからの協力は一切得られなくなるし、力関係次第では無理難題を押しつけられる。「それはむちゃです」と言っても「知らねぇよ、それを何とかするのがITの専門家の仕事だろ!」といった具合だ。

 で、本質的なほうの理由だが、そもそもソフトウエアって何だっけ?という話だ。私が思うに、ソフトウエアとは「プログラミング言語で記述された(実装された)何らかの仕組み」である。つまりソフトウエアの本質は、それに実装されている何らかの仕組みにあるわけだ。業務アプリなら、もちろんビジネスの仕組みだ。その仕組みを考えてプログラミング言語を道具として使って実装していくのがプログラマーの仕事である。

 なぜ冒頭の愚か者たちを「自称プログラマー」と書いたか、もうお分かりであろう。ここまでで「仕組みを考えるのは当たり前でしょ」と不審に思った人は、パッケージソフトウエアやクラウドサービスの開発に携わるプログラマーなのだろう。一方、人月商売ビジネスにはそのあたりがよく分かっていない自称プログラマーが大勢いる。人月商売ビジネスでよく使われる言葉で言えば、彼ら/彼女らはプログラマーではなく「コーダー」。つまりエンジニアではなく作業員である。

 デジタル革命が進展するなかにおいては自称プログラマー、つまりコーダーという作業員はいつ職を失っても不思議ではない。デジタル革命と大げさに言わなくても、これまでも35~40歳あたりからコーダーは徐々に仕事が厳しくなってきていた。自称プログラマーに染みついているのは分業の発想だ。人月商売の多重下請け構造の発想と言い換えてもよい。そうした分業体制がそろそろ成り立たなくなりつつあると気付くべきなのだ。

プログラマーは「料理を創るシェフ」
 そう言えば以前、米Microsoft(マイクロソフト)でWindows 95のチーフアーキテクトなどを務めた中島聡氏と対談したことがある。その際、中島氏はソフトウエアを料理に例えていた。そうするとプログラマーはシェフである。シェフの仕事の本質は料理を「創る」ことであり、単に食材を切ったり煮たりすることではない。プログラマーも何らかの仕組みを「創る」のが仕事の本質であり、それは言われた通りコードを書くことではない。

 中島氏は多重下請け構造の人月商売のIT業界を次のように批判していた。「僕から見ると、ITゼネコンの方は料理をつくったことがない『なんちゃってシェフ』がレシピだけ書いている。下請けの人たちは、下りてきたレシピ通りつくるだけ。そこでは、おいしい、おいしくないは関係ない」。ITゼネコンとはSIerのことだが、このITゼネコンが支配する人月商売のIT業界には、料理を創るシェフに相当する本物のプログラマーが存在しないわけだ。

関連記事:ここがヘンだよ! 日本のIT業界
 ちなみにWindowsのようなOSやパッケージソフトウエア、あるいはクラウドサービスの世界では、何らかの仕組み(コンピューターを動かす基本的な仕組みや業務処理の仕組み、あるいはサービスの仕組み)を専門的に考えるプログラマーをアーキテクトと呼ぶ。だからプログラムを書いたことのないアーキテクトはあり得ない。程度の差はあるが、仕組みを考えてソフトウエアの形にしてきたプログラマーの中から、優れたアーキテクトが生まれてくるわけだ。

 一方、人月商売のIT業界のほうはどうかと言うと、アーキテクトに相当するのがSE(システムエンジニア)である。先ほどの中島氏の言い方に従えば、料理をつくったことがない「なんちゃってシェフ」たちだ。もっとも、最近ではSIerもプログラミング経験のないSEはさすがに使えないと深く反省し、プログラムを書く経験を積ませるようになった。ただ、仕組みを考え、それをプログラミングで形にしていくプログラマーの仕事を通じて、優れたSEが育っているのか言えば、全くそうではないから困ったものだ。

 そもそもSEは、アーキテクトと違って何らかの仕組みをゼロから「創造」する必要はない。要件を明確にしたうえで、必要となる機能をどう実装するかを検討するのが仕事だ。一応、仕組みを考えているとは言えるが、既存の業務をシステム化することが大半だから、考える仕組みとはまさに「機能をどう実装するか」のみである。実に単純な仕事だ。「システム導入を機に業務のやり方(仕組み)を変えましょう」と提案するなら創造的な仕事になるが、「それはお客さまやコンサルタントの仕事」として避けてしまう。

 しかも最近、その単純な仕事がさらに単純になっている。大規模な案件であっても、ERP(統合基幹業務システム)など出来合いのパッケージソフトウエアなどをシステムのベースに使うケースが増えてきたから、必要となる機能をどう実装するかを検討する機会は大幅に省略される。後はフィット&ギャップ分析などで、客が要望する(本当は必要でないかもしれない)機能をどうつくるかだけを検討する。これはもう、仕組みを考えるという創造性とは無縁の世界だ。

 SEですらそのレベルだから、SIerをはじめとする人月商売のITベンダーでは、仕組みを考えてプログラミングで形にしていくプログラマーが育たない。どんなにプログラムを書いても、仕様に基づいてコーディングしているだけだ。つまりコーダーばかりである。余計なことを言えば、人月商売のIT業界では、そんなコーダーにも「SE」との肩書を与えるから、もう訳が分からない状況になっている。

基幹系刷新では誰も「仕組み」を考えない
 もう一度書くが、ソフトウエアの本質は、それに実装されている何らかの仕組みにある。プログラマーであろうが、アーキテクトであろうが、「本物の」SEであろうが、その仕組みを考えて実装するのが仕事である。そして、ここまでがエンジニアである。単に言われた通り、仕様通りにプログラムを書いているなら、エンジニアではなくコーダーと言う名の作業員である。先ほどは料理の世界と比べたが、機械や土木などの世界のエンジニアもきっと同じであろう。

 そんなわけで人月商売のIT業界にいるのは、ソフトウエアの本質である仕組みをろくすっぽ考えない、なんちゃってSEや自称プログラマーばかりである。しかも話をさらに悲惨にするのは、システム開発を依頼する側、つまりユーザーであるビジネスサイドの連中も、新たにどんな仕組みをつくるのか、あるいは既存の仕組みをどう変えるのかを丸っきり考えていないことだ。

 例えば基幹業務システムの刷新ならば、新旧のシステムに実装するのは業務プロセスなどビジネスの仕組みである。本来なら刷新を機に、このビジネスの仕組みをどう変えるのかについて、ビジネスサイドの人やSE、プログラマーが真剣に考えて議論すべきなのだ。だが、誰も考えようとしない。特にITベンダーのなんちゃってSEや自称プログラマーは「それはお客さまがやること」との固い「信念」があるから、全く考えようとしない。かくして、何度刷新しても「現行通り」のシステムがつくられ続ける。

 人月商売のITベンダーからすれば客のシステムなのだから、客が「現行通り」と言えばその通りにつくればよい(ただしプロジェクトは大概悲惨な結果になる)。ただし、そんな仕事ばかり続けていると、つまり仕組みを考えないコーダー仕事などを続けていると、エンジニアならぬ作業者には成長がない。というか35歳あたりから劣化が始まる。最新技術を習得するのは加齢とともに大変になるし、コーディングスピードも若手に勝てなくなる可能性が高まるからだ。

 そんなわけで、仕組みを考えて実装できる本物のプログラマーにならないと、中高年になったときに大変だぞ……と極言暴論らしくあおりたいところだが、現実はもっと複雑だ。「現行通り」のシステムがずっと生き残り続けているので、そのシステムのお守りをしていれば稼ぎは少なくても食いっぱぐれることはない。特にCOBOLプログラムが生き残っていると、とても安心だ。今どき若手が「参入」してくることはほとんどないから、コーダー稼業でも食っていけた。

 めでたしめでたし……とは、もちろんいかない。時代は大きく変わり始めている。そう、ビジネスや社会のデジタル化、いわゆるデジタル革命の進展だ。巨大プラットフォーマーが主導するクラウドの急速な普及により、既存のビジネスや社会を変え得る新たなサービス(仕組み)を低コストでつくれるようになった。だからこそ、少人数で起業したITベンチャーが続々と登場し、既存の産業や企業に取って代わるデジタルディスラプター(デジタルによる破壊者)を目指し、しのぎを削っているのだ。

 仕組みを考えてそれを実装できる本物のプログラマー、そしてアーキテクトにとっては、最高にハッピーな時代が始まっているわけだ。特に日本では圧倒的に人材が足りず、引く手あまただ。これからは20代の若手であっても、年収1000万円程度の「低賃金」しか出せないような企業で働く必要はない。転職、副業は自由自在。何なら優秀な仲間とともに起業に踏み切ってもよい。作業員ではなくエンジニアである限り、素晴らしい未来が約束されている。

デジタルの時代に座して死を待つことはない
 では、作業員にすぎない自称プログラマー、なんちゃってSEはどうか。これはもうお察しの通りである。人月商売のIT業界に在職する作業員はこれから先、どんどん用済みになっていく。この極言暴論で何度も指摘しているように、途方もない工数をかけてシステムをつくり上げる大規模プロジェクトはこの先、数を急速に減らしていくはずだからだ。

 大規模プロジェクトの花形だった基幹系システム刷新でも、ERPやクラウドサービスの機能を可能な限りそのまま使うことが当たり前になる。ERPベンダーなどに高額のライセンス料を支払うのに、どうでもよい自社独自の業務のやり方をシステムに組み込むために、さらにSIerにばか高い人月料金を支払うのは愚かだ――。そんな当たり前の認識が日本企業にもようやく広まりつつある。

 大規模プロジェクトの需要が大きいから、人月商売のIT業界では多重下請けという分業体制が発達した。元締のSIerは、少しだけ仕組みを考えるSEと現場監督のプロジェクトマネジャーを出し、2次請け以下の多くの下請けITベンダーが大勢のコーダーを送り込む。こうしたプロジェクトを幾つもこなすことで、人月商売のIT業界は潤ってきたわけだかが、そんな前時代的な労働集約型の商売はまもなく成り立たなくなる。

 くだらない基幹系システム刷新でお金をドブに捨てるようなまねをやめたユーザー企業は当然、浮いたIT予算を顧客接点のデジタル化といったビジネスのデジタル化に使うようになる。その際に必要となる人材はもちろん、仕組みを考えてそれを実装できるプログラマー(できればアーキテクト)である。そんなわけなので人月商売のIT業界にいる作業員たちは、コーダーなどに甘んじていれば先はないが、プログラマーというエンジニアを目指せば前途洋々たる未来が開ける。

 最後に、ここまでずっと曖昧に表現してきた「仕組みを考える」について、少し詳しく書いておこう。既に理解している読者も多いかと思うが、プログラマーやアーキテクトが考える仕組みとは、ビジネスの仕組み(ビジネスモデルや業務プロセスなど)とシステムの仕組み(アーキテクチャー、ビジネスモデルなどをどう機能として実装するか、など)の両方である。

 そうした仕組みを一体で考えるには、マーケティングや法制度などのビジネスサイドの知識と、クラウドやAI(人工知能)などの最新技術に対する知識が必要になる。「スーパーマンじゃないんだから、そんなの不可能だ」と思う読者が大勢いるだろうが、まさにその通りだ。だからこそ、様々な分野の専門家であるエンジニアや、ITに詳しいビジネスサイドの人たちが集まる必要がある。ただし、専門領域ごとに仕組みを考えるといった「分業」をしては駄目だ。一緒に仕組み全体を検討しなければならない。

 さて、人月商売のIT業界で自称プログラマーやなんちゃってSEの仕事に甘んじている皆さん、いかがだろうか。人月商売に先がないことを見切ったSIerは、下請けITベンダーを切り捨てながら、そちらの世界に人材をシフトさせるのは間違いない。切り捨てられる側にいる人たちも、座して死を待つことはあるまい。本物のプログラマーの仕事は未来があるだけでなく、やりがいがあって楽しいぞ。』

機械語序論 第1回 計算機の仕組みと機械語

 ※C言語や脆弱性の話しから、久々で「機械語(マシン語)」のことを思い出した…。

 ※ それで、ネットで調べていたら、けっこう良い資料に当たった…。

 ※ 例によって、全くの個人的な興味と関心に基づくものだ…。

 ※ 自分の学習のために貼っておく…。多分、大学の1年生向けの講義用のスライドとして作成されたもの(2008年版か…)だと思う…。

※ 多分、この人が作成したものだと思う…。「msato」とあるからな…。違っていたら、ゴメンなさい…。

「デニス・リッチー」、「真に」世界を変えた男…。

バッファオーバーラン(※または、バッファーオーバーフロー)
https://ja.wikipedia.org/wiki/%E3%83%90%E3%83%83%E3%83%95%E3%82%A1%E3%82%AA%E3%83%BC%E3%83%90%E3%83%BC%E3%83%A9%E3%83%B3#:~:text=%E3%83%90%E3%83%83%E3%83%95%E3%82%A1%E3%82%AA%E3%83%BC%E3%83%90%E3%83%BC%E3%83%A9%E3%83%B3%EF%BC%88%E8%8B%B1%3A%20buffer,%E3%83%87%E3%83%BC%E3%82%BF%E3%81%8C%E3%83%90%E3%83%83%E3%83%95%E3%82%A1%E5%A2%83%E7%95%8C%E3%81%8B%E3%82%89

※ こういう「脆弱性」の話し、C言語がらみの話しを聞くと、「デニス・リッチー」のことを思い出す…。

デニス・リッチー
https://ja.wikipedia.org/wiki/%E3%83%87%E3%83%8B%E3%82%B9%E3%83%BB%E3%83%AA%E3%83%83%E3%83%81%E3%83%BC

※ アセンブラとか、C言語(上記ケン・トンプソンが開発した「B言語」に次ぐ言語ということで、「C言語」と命名された)とか、こういうヒッピーみたいなゴツイ親父たちによって開発されたんだ…。

『経歴
「C言語」および「UNIX」も参照
ハーバード大学で物理学と応用数学の学位を得た後、1967年、ベル研究所の計算機科学研究センターに勤務を始める。その後1968年ハーバード大学でパトリック・C・フィッシャー(英語版)の指導により、計算機科学の博士号を取得した。博士論文のテーマは “Program Structure and Computational Complexity”(プログラム構造と計算複雑性)であった[7]。

1969年ごろ、リッチーはケン・トンプソンと共に、ベル研究所で放置の状態にあったPDP-7上で独自のオペレーティングシステムを作り始める。これが後にUNIXと呼ばれるOSの原型となった。UNIXは1969年に原型が出来上がり、1971年に PDP-11/20 に移植された。このUNIX上で動作するアプリケーションを作るために、トンプソンによってB言語が開発され、リッチーがこれにデータ型と新しい文法等を追加しC言語が出来上がった。当初はアプリケーションを作成するために作られたC言語であったが、 1973年に、それまでアセンブリ言語で書かれていたUNIXをC言語で書き換えることに応用され、実際に移植は成功した。この頃のUNIXは文書マシンとして使われており、主にベル研究所の特許事務に用いられていた。

当初はPDP-11のアーキテクチャーに依存する側面が大きかったUNIXとC言語であったが、徐々にPDP-11への依存性を減少させていき、1978年にDEC製以外のコンピュータへのUNIXの移植に成功した。 C言語の開発は、リッチーのUNIXへの最大の貢献のうちの一つである[8]。

1983年、UNIX開発の功績により、ケン・トンプソンと共にチューリング賞を受賞している。21世紀初頭現在でさえ、C言語は組み込みシステムからスーパーコンピュータまであらゆるタイプのプラットフォーム上で用いられており、彼の業績は非常に大きい。

晩年は、引き続きベル研究所にて、1995年に発表されたオープンソース版の分散システム用オペレーティングシステムであるPlan 9や、1996年に公表された分散システム用オペレーティングシステムの Inferno とその言語 Limbo の開発に携わった。』
『死と後世への影響
2011年10月12日、1人住まいのニュージャージー州バークレーハイツの自宅で亡くなっているのが発見された[1][2]。70歳没。死去の第一報は、以前の同僚であり現在はGoogleに勤務するロブ・パイクによってGoogle+上で発表された[3][4]。彼は長い闘病(前立腺癌と心血管疾患)の末に、亡くなったという[15][2][3][16][17]。その死はスティーブ・ジョブズの訃報の約1週間後だったが、ジョブズほど大きく報道されることはなかった[18][19]。コンピュータの歴史家 Paul E. Ceruzzi はリッチーの死について「リッチーはレーダーの下にいた。彼は有名人というわけでは全くないが、…あなたが顕微鏡でコンピュータの中を見ることができたなら、彼の仕事をあらゆる箇所で見つけるだろう」と述べている[20]。

リッチーの死後間もなく行われたインタビューで長年の同僚だったブライアン・カーニハンは、リッチーはC言語がこれほど重要なものになるとは全く思っていなかったと述べている[21]。カーニハンは、CとUNIXがiPhoneなどの後世の重要プロジェクトでいかに大きな役割を果たしたかを述べている[22][23]。

他にもリッチーの後世への影響について、様々なことが言われている[24][25][26][27]。

Fedora 16 というLinuxディストリビューションはリッチーの死後1カ月ほどでリリースされており、リッチーへの献辞が添えられていた[28]。2012年1月12日にリリースされた FreeBSD 9.0 にもリッチーへの献辞が添えられている[29]。』

 ※ 「スティーブ・ジョブス…。世界を変えた男…。」という言い方が、よくされるが、本当に「世界を変えた」のは、デニス・リッチー(や、その仲間たち)だった…、とオレは思っている…。

C/C++が首位陥落、Web開発に欠かせない言語がトップに

https://xtech.nikkei.com/atcl/nxt/column/18/01373/072700001/?i_cid=nbpnxt_ranking

『システム開発を円滑に進めるには、開発対象のシステムに合ったプログラミング言語を選ぶ必要がある。プログラミング言語によって向いているシステム、または向いていないシステムがあるからだ。ITエンジニアには開発対象に応じて利用言語を増やしたり、場合によっては切り替えたりすることが求められる。

 ITエンジニアが開発するシステムは様々だ。最近では、従来の基幹系システムだけでなく、Webサービスやスマホアプリ、AI(人工知能)システムなどもある。では、ITエンジニアはどんなプログラミング言語を使っているのか。また開発対象のシステムごとに利用されている言語は何か――。

 これらを確かめるため、日経クロステックでは「プログラミング言語利用実態調査 2020 夏」をWebサイト上で実施した。調査期間は2020年6月23日~7月3日。711人の会員から回答を得た。その結果を見ていこう。

C/C++が首位陥落
 アンケートでは普段使っているプログラミング言語を3つまで挙げてもらった。その結果、利用言語の第1位は「JavaScript」で、回答者711人中217人が使っていた。3割以上のエンジニアがJavaScriptを使っていることになる。JavaScriptはWebシステムやWebアプリのクライアント側(Webフロントエンド)開発に多用されるプログラミング言語だ。

利用しているプログラミング言語
「あなたが現在使っているプログラミング言語は何ですか」という設問に対する回答の内訳。1人当たり最大3つ選択してもらった
[画像のクリックで拡大表示]
 日経クロステックでは2018年と2019年に同様の調査をしている。過去2回の調査では、利用言語の第1位は「C/C++」だった。今回、C/C++は第4位(182人)に後退した。このことからITエンジニアが開発するシステムにWeb技術の採用が進んでいることが分かる。

関連記事:プログラミング言語の人気ランキング、独自調査で解明
関連記事:プログラミング言語人気ランキング2020、2位に「大躍進」したあの言語

 利用言語の第2位は「Python」(207人)だった。PythonはAIシステムやデータ分析システムに利用されている。Python向けの機械学習や計算処理などのライブラリーやフレームワークが豊富にあるためだ。最近こうしたシステム開発に携わるITエンジニアは増えており、第2位に入る結果となった。

 利用言語の第3位は「Java」(186人)、4位は182人が利用していると回答した「C#」と「C/C++」だった。JavaやC#は基幹系システムや業務システムの開発に利用する定番言語である。

メインに使っている言語はJavaがトップ
 先ほどの回答は利用しているプログラミング言語を複数(3つまで)聞いた結果だ。では、メインとして使っている言語は何だろう。アンケートでは最も使っている言語を1つだけ挙げてもらった。

その結果、第1位は「Java」(16.0%)、第2位は「C#」(14.6%)だった。先ほど利用している言語では第1位だった「JavaScript」は第7位に後退している。現在のシステム開発には何かしらのWeb技術を用いるため一部JavaScriptを利用するが、主にプログラミングするのは定番のJavaやC#であることが分かる。

 第3位は「C/C++」(13.8%)だった。C/C++は組み込み系ソフトの開発に利用することが多い。組み込み系ソフトを開発するエンジニアの7割以上がメイン言語として使っていた。第4位は「Python」(12.9%)である。Pythonを用いたシステム開発は増えているものの、メインの言語として利用しているエンジニアはJavaやC#と比べて少ない結果となった。

 第5位は「VBA」(7.7%)だった。VBAは主にExcel上でマクロのプログラムを記述する際などに使う。Excelで行う計算処理を自動化して事務作業を効率化する用途でよく利用されている。ただし後述するアンケートの結果を見ると、事務作業以外でも利用する機会が増えているようだ。

開発用途別の利用言語
 続いて、開発するシステムごとの利用言語について見ていこう。アンケートの結果では基幹系システムを開発しているITエンジニアが最も多く242人だった。基幹系システムを開発するエンジニアが使っている言語の第1位は「C#」だった。その割合は22.7%である。第2位は「Java」で21.9%。両者を合計すると全体の4割強になる。登場時期が古い「COBOL」も9.1%のエンジニアが利用している。

開発対象システムごとにメインで利用する言語
[画像のクリックで拡大表示]

 組み込み系ソフトを開発しているエンジニアの73.8%は「C/C++」を利用していると回答した。過去2回の調査では組み込み系ソフトの開発にC/C++を利用しているエンジニアが多く、全体の順位を押し上げる傾向だった。今回の調査ではJavaやC#を利用して基幹系システムを開発するエンジニアの割合が増えたため、組み込み系ソフトで多用されているC/C++の順位を上回ったと思われる。

 意外だったのはWebフロント系システムを開発しているエンジニアの24.7%がJavaをメインに利用していることだ。Webフロント系システムの開発ではバックエンドとなるシステムとの連携が必要になる。バックエンドとなるシステムはJavaやC#といった言語で開発していることが多い。そのためWebフロント系システムを開発していると回答したエンジニアの多くがJavaをメインに利用していると推測できる。』

ベテランも4割強がプログラミング能力不足を実感

ベテランも4割強がプログラミング能力不足を実感、PythonとVBAで顕著
https://xtech.nikkei.com/atcl/nxt/column/18/01373/072800002/

※ どこまで行っても、「他人様が作ったもの」を利用する…、ということからは逃れられない…。その「他人様」がどういうことを考えて作ったのか…、ということがよく理解されない限り、「なんで、こうなっているんだ?」という疑問は、解消されない…。

※ ましてや、「英語圏」では無い日本人プログラマーでは、最初から「ハンディ」を背負って(しょって)いるわけだ…。

誰でもソフト開発「ノーコード」…。

誰でもソフト開発「ノーコード」 米IT大手が熱視線
https://www.nikkei.com/article/DGXMZO60479010Y0A610C2TJ1000/

※ 正確には、「コーディングなしに」だ…。

※ ちょっと昔(むかし)には、VBとかで「オブジェクト」を操作して、プログラムを作成するものが流行った(Delphiなんかも、この系統…)。

※ 最近は、もはや「オブジェクト(orコントロール)」の操作すら必要で無くなり、「行みたいなもの(まあ、オブジェクトの一種だと思うが…)」を、「ドラッグ&ドロップ」したり、挿入・削除したりするだけで、ちゃんと「動作する」プログラム(アプリ)が、作れてしまう…。そういう世の中に、なった…。

※ 特に、今般の「コロナ禍」においては、医療関係従事者や病院関係者、ソーシャル・ワーカーみたいな相談員…と言った、いわゆる「プログラマー」では無い人達が、必要に迫られて、早急に、何らかの「対策ソフト・アプリ」を作成する…、ということが加速した…。

※ 台湾では、IT担当大臣自らが、「どこでマスクや医療関係用品が購入できるのか、在庫はどれくらいあるのか」が分かる…、というアプリを開発したそうだ…。それにひきかえ、我が日本国においては、どうだった…。「ハンコ」を押しに、出社しなければならない…、という体たらくだった…。そして、「ハンコ押しロボ」が、開発された…。どうも、方向性が違っている気がするが…。

『【シリコンバレー=佐藤浩実】プログラミング言語の知識がなくてもソフトウエアを開発できる「ノーコード/ローコード」と呼ぶ技術への関心が高まってきた。米マイクロソフトの開発基盤の利用者は半年で7割増え、米グーグルや独シーメンスは関連企業の買収に動く。エンジニア不足の処方箋として期待され、新型コロナウイルス対策に生かす例も増えている。』
『■350万人が利用
マイクロソフトが5月下旬に開いた年次開発者会議。サティア・ナデラ最高経営責任者(CEO)は「350万人が『パワー』を使って日常的にアプリを開発している」と誇った。』
『パワーはソースコードを書けなくても「パワーポイント」や「エクセル」を扱うような感覚でソフトを作成できるサービスだ。IT(情報技術)エンジニアが集う「GitHub(ギットハブ)」の利用者が5千万人いるのに比べれば少ないが、この半年でユーザーは1.7倍に増えた。

マイクロソフトは3年ほど前から「ノーコード/ローコード」の開発基盤の整備を始めた。「大々的に公開したのは2019年から」と、担当するコーポレート・バイス・プレジデントのチャールズ・ラマナ氏は語る。5月に関連技術を持つ英企業を買収するなど、ここに来て投資の積み増しも鮮明だ。』
『■グーグルなど買収ラッシュ
グーグルは1月、プログラミングなしのアプリ作成を支援する米アップシートを傘下に収めた。シーメンスも米社を買収。米新興のアンコルクが3月までに日本円で約140億円を調達するなどM&A(合併・買収)や大型の資金調達が相次ぐ。

世の中にある多くのソフトは今も、プログラミング言語を学んだエンジニアがコードを書いて作っている。「傍流」の開発手法にIT大手が力を入れ始めたのは、世界の企業が進めるデジタルトランスフォーメーション(DX)の一助になるからだ。』
『■ITエンジニア不足に対応
金融や製造業、小売業まで、ITでビジネスモデルや業務を見直す動きは盛んだ。一方で熟練のエンジニアは不足し、日本だけでも30年までにIT人材が80万人不足するとの予測もある。ギャップを埋めるため、専門知識がなくても短期間でソフトを作れるサービスへの関心が高まっている。

新型コロナも転機になる。医療現場などで急にデジタル対応が必要になる場面が増えたためだ。

米ワシントン州の病院は病床の空きや人員配置といった情報を医療関係者が共有できるアプリを「パワー」で制作した。開発を担当したケビン・ブルックスさんは「急速な変化を把握して患者に対応することができた」と話す。米ニューヨーク市はアンコルクのサービスを利用し、感染者らが健康状態を登録するシステムを3日で構築した。』
『■クラウド連携で普及期に
「ノーコード/ローコード」をうたうサービスの歴史は長く、01年設立の米アウトシステムズや05年設立の米メンディックスが先駆けだ。当初は、作ったソフトの拡張性や外部データとの連携に制約があり、ソフト開発の主流にはならなかった。

米ガートナーのジェイソン・ワンVPアナリストは近年脚光を浴びるようになった背景について、「クラウドや(様々なデータをつなぐ)APIといった技術と組み合わせて使えるようになったから」と話す。マイクロソフトやグーグルが触手を伸ばす背景には、開発者の裾野を広げ自社のクラウドの利用を促す狙いもある。

ガートナーは24年までに、企業で使う業務アプリの65%が「ノーコード/ローコード」の開発手法を用いて作られるとみている。技術者不足が利用に拍車をかける。

一方、日本の大企業はシステムをゼロから作りこむことを良しとし、簡易な開発手法の採用に難色を示す向きもある。変化の速度が早まるなか、柔軟にツールを使いこなす意識改革が必要だ。』

96%が屈辱の「初級以下」判定、AtCoderのプログラミング実力判定試験の深層

https://tech.nikkeibp.co.jp/atcl/nxt/column/18/00001/03494/?P=1

『一般受験者ではエントリーが半数以上を占めているのだ。初級は約3割で、中級はたったの4%。未認定も1割以上いる。一方で上級やエキスパートは1人もいない。つまり、「一般受験者では初級以下96%」という衝撃的な結果になった。』

※ ここで出てきてる「一般受験者」とは、全くの「素人さん」では無いだろう…。そういう方面に興味と関心があって、ある程度プログラミングの経験も積んで来て、「腕試し」したくなったんで、参加した人達だ…。それで、「箔」を付けて、あわよくば、「在宅で」プログラミングの受注を受けたり、「副業」にしたりしようとする思惑がある人達…、と見た方がいい…。つまり、「在宅プログラマー予備軍」とでも言うべき人達…、と見た方がいい…。

『プログラミングの実力を測るのは難しい。対象者が書いたプログラムを人の目でチェックするには、時間も手間もかかり、評価者に高いプログラミングの能力が求められるからだ。かと言って一般的な試験問題では、プログラミングの知識を測ることはできても、プログラムを書く力を測るのは困難だ。
 この問題に真正面から挑戦しているのが、様々なプログラミングコンテストを運営しているAtCoderである。受験者にプログラムを書かせて実力を自動判定する新型の検定試験「アルゴリズム実技検定」を始めた。』
『この検定は、1からプログラムを作成する能力を問うものだ。同社によると「知識型ではない」「受験者が得意なプログラミング言語を選べる」「アルゴリズムの実力を測る」といった特徴を持つという。オンラインで参加する形式なので、自宅など好きな場所で受験できる。』と言うことだからな…。

そうでなければ、わざわざ自腹を切って、おそらくそんなに安くは無い「検定料」を払って、貴重な時間を割いて、「検定」に参加したりはすまい…。

そういう人達にして、こういう状況だぞ…。

政府は、「小学生から、プログラミング教育を行う!」とか、力んでいるが、どういうことになるのかな…。

マシン語の話し

 ※ Javaの話しとか、サイバー攻撃の話しの記事を読むとき、ある程度は理解しといたほうがいいと思われるのは、「マシン語」とか、「コンピューターが、動作する仕組み」とかの話しだ。                          『2段階方式で脱Java、JACICがオラクルと特別契約』
https://tech.nikkeibp.co.jp/atcl/nxt/column/18/00001/01412/?P=1

  それで、以下の投稿は、今年の3月に作ったものなんだが、まあ今でも役に立つところはある、と思われるので、紹介しとく。                  http://www.sankei.com/world/news/180316/wor1803160018-n1.html 
         
 『韓国の仲介で、米朝首脳会談が行われるような流れになってる感じだが、その裏で北朝鮮は活発に韓国にサイバー攻撃を行っていた訳だ。韓国の出方を探って、交渉を自国に有利に運ぼうという作戦だろう。
 その手口なんかをちょっと詳しく解説してるのが、以下の記事だ。このサイトは、ウイルス・マルウエアやダーク・ウェブ(ウイルスやマルウエアを有料で販売したりしてる、危ないサイト)、それらの作者への匿名でのインタビュー記事なんかが載ってるんで、結構参考になる。
(『北朝鮮のサイバー攻撃グループ「APT37」が活発化』
 https://the01.jp/p0006529/ )

それで、これらの記事に出てくるちょっと専門的な用語について、説明しておく。                                     
※ https://tech.nikkeibp.co.jp/it/article/lecture/20070820/279875/  画像は、ここからお借りした。

「コンパイル」:本来は、「翻訳する」とか「置き換える」、ってな意味だ。
 コンピューターは、結局CPU(Central Processing Unit 中央演算装置)で電子の0(電子がない)と1(電子がある)の情報(電子があると、電流が多く流れる。電子がないと、電流が少なく流れる。電子の有る無しを、電流の流れに置き換えて(交流の山と谷を、1と0と判定して)操作してるだけのもんで、8bitとか16bitとか32bitとか64bitとかいうのは、一度に処理できる「0と1の個数」を指している。
 8bitだと、一度に00101100みたいな8個の0と1の羅列を処理できるっていう話しで、16bitだとこれが16個という話しになる(bitというのは、1組の0と1という単位。デジタルの2値って、このこと)。32bitは32個、64bitは64個の0と1の羅列…という話し(32個の箱や64個の箱の中に、それぞれ0または1が入ってる、というイメージ)。
 だから、コンピューター(CPU)は、そもそもがこういう0と1の羅列しか取り扱えない。8bitのマシンは、00101100とか00101000とかしか取り扱えない。こういう、CPUで処理させようとする0と1の羅列を、「マシン語」という。
 コンピューター(CPU)の処理は、大体が指定されたデータの場所(アドレスという)のデータに対して、一定の処理をする(「命令」)という形になる(※ こういう0と1の羅列を、「データの場所」と「命令」に分けて取扱う(データの場所と命令を、混在させて取扱う)という仕組みを思いついた人が、フォン・ノイマンって人だ。まあ、天才の一人だな。イギリス国籍のユダヤ系の人だ。それで、このタイプのコンピューターを「ノイマン型」と言う)
 大体において、8bitの場合は上位4bitが「データの場所」を指して、下位4bitが「命令」を指していたり、レジスタ(CPU内部のデータを一時置いておく場所。まあ、高速メモリってな感じのもんだ)を2本使って、8bitの「データの場所」+8bitの「データの場所」計16bitのデータの場所という風に扱う場合もあるようだ。
 こんな風に、同じ0と1の羅列でも、それがどんな意味か、どういう「データの場所」の指定なのか、どういう「命令」なのかは、そのCPUで違う(CPUの設計・製造メーカーが、それぞれの設計・製造思想に基づいて設定してる)わけだよ。
 それで、このマシン語は、0と1の羅列で「00101100」とか「00101000」みたいなもんだから、これでプログラムを作るのは大変だ。まあ、初期の頃はシコシコやったらしいし、これでプログラムを作れる名人みたいな人もいたらしい(今でも、ソニーのプレステは、どっちかというとこのマシン語寄りでプログラムを作ってるという話しだ。そっちの方が、真似されにくいんで、わざとそういう風にしてるという話しも聞いた。だから、今でもXboxでは作り出すことが難しいタイプのゲームを作ることができて、競争力を保持してるという話しを聞いたことがあるぞ)。
 しかし、プログラミングの生産性は上がらないし、当然ミスも多くなる(0と1の1個でもミスったら、アウトだ)。いくら何でも酷くね、って話しになった。
 それで、登場したのが「プログラミング言語」だ。もう少し人間にも分かりやすい言語で書いて、それを「マシン語」に置き換えたらいいんじゃね、っていう発想だ(この、マシン語への翻訳・置き換えをコンパイルと言い、コンパイルするソフトを、コンパイラと言う)。
 最初に登場したのは、「アセンブリ言語」だ。
 例えば、「mov A B」(AをBに、移動する(move)する)、「comp A B」(AとBを比較(compare)する)、「add A B」(AにBを加える(add)する)みたいな感じで記述した。
 使われた記述が、「mov」「comp」「add」のような英単語を省略したようなもんなんで(英語圏の人にとっては)理解しやすいもんだったが、「A B」の部分が、前述した「レジスタ」に限定されていた(各CPUの内部に一般のプログラマーが自由に使える、高速メモリってな感じのものー(「汎用レジスタ」と言う)が設置されているんだが、CPU毎にバラバラ(前述のように、各CPUメーカーが、それぞれ勝手に設計・製造してた。今でも、そう)なんで、CPUが異なるマシンに向けて移植が大変だった)。また、命令がCPUのできる処理とほぼ1対1対応だったんで、あまり複雑な処理を記述するのに向かなかった。アセンブリ言語をマシン語に変換するソフトを、アセンブラ(コンパイラと対をなしてる感じだな)というらしいのだが、オレは使ったことはない。大体、アセンブリ言語も本で読んだことがあるだけだ。
 それで、1973年(たかだか、45年前の話しだ)に開発されたのが「C言語」だ。
「#include
int main(void)
{
printf(“Hello, world!\n”);
return 0;
}」
ってな感じのもんだ。
 ざっと意味を説明しようとしたんだが、長くなったし、あまり興味もなかろうと思うんで、省略する。
 上記の記述のプログラムをコンパイルして実行すると、使っているマシンのディスプレイに「Hello World!」って表示される。
 上記の記述をコンパイラでコンパイルすると、マシン語に変換されて、各CPUで実行することができる、ってわけだ。』