プログラミング、つまずいたから つまずかせない 教育を変革 EdTechの旗手(4)

https://www.nikkei.com/article/DGXZQOFK246OV0U1A220C2000000/

※ こういう統計が、出てるんだな…。

※ オレは、レベル1とレベル2の間くらいか…。

※ レベル3で、やっとスクリプト使ったり、Linux系でサーバ立てたりとかか…。情シス受かったりとかか…。

※ 政府が、やたら「プログラミング教育」を言っているから、小学校教員も、情シス必須…、ということになるだろうな…。

※ 現行、小学校教員は、女子の「文学部」「教育学部」出身者が多いだろう…。

※ 源氏物語、枕草子大好き乙女に、ゴリゴリ「プログラミング」「コンピューティング」を、強制するのか…。

※ ヤレヤレな話しだ…。

『わかりにくいところを熟知

「プログラミングで僕もつまずいたから、あきらめずに学習できるシステムが必要だと思った」。Progate(プロゲート、東京・渋谷)社長の加藤将倫(28)は、柔らかなビーズクッションに座りながら語る。東京大学の学生時代、プログラムを学ぶ「ゲート」(入り口)を創りたいと志して起業した。遊び心あふれるオフィスには卓球台やゲーム機器も置いてあり、柔軟な発想で学習ソフトを開発している…

この記事は会員限定です。登録すると続きをお読みいただけます。

残り4529文字

すべての記事が読み放題
有料会員が初回1カ月無料

有料会員に登録する
https://www.nikkei.com/r123/?ak=https%3A%2F%2Fwww.nikkei.com%2Farticle%2FDGXZQOGM010QT001022021000000&n_cid=DSPRM1AR07

無料会員に登録する
https://www.nikkei.com/r123/?ak=https%3A%2F%2Fwww.nikkei.com%2Farticle%2FDGXZQOGM010QT001022021000000&n_cid=DSPRM1AR07#free

ログインする
https://www.nikkei.com/login

遊び心あふれるオフィスには卓球台やゲーム機器も置いてあり、柔軟な発想で学習ソフトを開発している。

加藤は「初心者がつまずくハードルをとにかく下げた」と笑顔を見せる。同社のオンライン教材は現在、国内外で200万人超が利用している。2020年から小学校でプログラミング教育が必修となり、親も「子供に聞かれたときのために」と学び始めた。学び直しをする社会人の需要もあり、この教材をきっかけにアイドルからエンジニアに転職した人もいる。新型コロナウイルスの影響で巣ごもりの時間が増えた影響もあり、会員数の伸び率は従来の2倍になった。

ふつうプログラムのコードはパソコンで書いていくが、「スマートフォンのほうが親しみやすい人もいる」。ブラウザだけでなく、アプリでも学べるようにした。Python(パイソン)やJavaScript(ジャバスクリプト)などのプログラミング言語ごとに細かくレベル分けしてある。レベルアップすると、いやし系キャラの「にんじゃわんこ」が祝福してくれる。

例えばウェブサイト制作につかう言語、HTMLを学ぶとする。サイト内の文字の大きさや関連ページへのリンクなど、コードを書き込むときは機能ごとに「開始タグ」と「終了タグ」を指定していく。リンクを貼るときは次のような具合だ。

Progate

まず開始タグとしてと打ち、参照を表すhrefという属性とリンク先のURLをここに盛り込む。さらに画面上でクリックしてもらう文言(ここではProgate)を指定し、終了タグのと書く。このとき、どこでスペースを空けるかや、ダブルクオーテーション(”)をつける場所などもイラストで丁寧に図示してある。
Progateのアプリは、初心者でもプログラミングを独学しやすいよう丁寧に設計している

「何のために学んでいるか、実感を得やすくした」というのもポイントだ。たとえば演習問題で、検索エンジンのGoogleにリンクを貼るためのコードを書く。このシステム上のプレビューで「Googleへ」と青文字で表示される。これをクリックすると、本当にそのサイトへ飛ぶようになっていて、身につけた技術が役立つんだと達成感がある。コードを書くときに分からなくなっても、別のいやし系キャラ「ひつじ仙人」がヒントを出してくれる。学習者の心が折れないような仕掛けが満載だ。

大学の授業にモヤモヤ感

加藤がコンピューターと向き合うようになったのは、母親の影響が大きい。父親の仕事の都合で、小学校から中学校のほとんどをオーストラリアで過ごした。そこで母が現地の大学で学び直すことを決め、専攻したのはコンピューターサイエンス。家でもパソコンで課題をこなし、簡単なゲームをつくると息子にも遊ばせた。加藤は「こんなのつくれちゃうんだ?」と、わくわくしたという。

ところが帰国して自分が大学生になると「挫折の連続だった」。東大工学部の電子情報工学科で、コンピューターの原理やプログラミングについて学んでいた。周りの学生を見渡すと、アルゴリズム(コンピューター上の計算手法)やソフトウエアのつくり方について、小中学生のころから学習してきた猛者も少なくない。「僕は文系脳」という加藤。「彼らはなぜすぐに講義内容を理解できるんだ」と焦りながら、なんとか食らいついている状況だった。

「実社会にどう役立つか」という成果が見えにくい授業も多かった。加藤はフェイスブックの創業者、マーク・ザッカーバーグの半生を描いた映画「ソーシャル・ネットワーク」をみて、彼が学生時代にSNSを開発した姿に刺激を受けた。だが、大学の授業は「どうしたらフェイスブックみたいなサービスにつながるのか?」という加藤のモヤモヤ感を置き去りにして進んでいった。

日本のIT(情報技術)エンジニアは約109万人。世界4位ながら米国など上位3カ国との差は大きい。経済や社会の急速なデジタル化でIT人材の需要は高まり、日本は今後10年で約45万人の不足に陥るという経済産業省の予測もある。実社会は即戦力を渇望しているのに、大学の授業は対応できていないのではないかと加藤は疑問を抱いた。

そんなとき、のちにProgateの共同創業者となる同級生、村井謙太がプログラミングを学ぶための学生サークルを立ち上げた。村井は東大工学部の社会基盤学科で学んでおり、コンピューターサイエンスが専門ではなかった。サークルはあえてプログラミング技術が「バリバリな人」(加藤)ではなく、今は苦戦しているけれど飛躍したいと思う人が集まった。加藤も加わり、同じ悩みを持つ仲間たちと前進できることを喜んだ。

ただ、テキストを見ながら実験的にプログラムを組むだけでは、やはり実社会で役立つという手応えは感じられない。そこで「実際に仕事を受注してみればいい」とサークルのメンバーらで企業に営業をかけた。あるITベンチャー企業から受注したのはフリーランスの営業員らに営業活動をアウトソーシングするためのシステム開発。顧客企業との受発注や営業人材を管理するための画面が求められた。

勢い込んだ加藤の前に壁が立ち塞がった。この案件を仕上げるには、ウェブ制作に合うHTMLやPHPといったプログラミング言語を使う必要があると気づいた。加藤がもともと授業で習っていたのはロボット制御やアプリ開発にも利用するC言語やJavaなど別の言語だった。

せっかく受注した仕事。なんとしても完成させたい――。加藤は外部のエンジニアから即席の技術指導を受けつつ、寝る間も惜しんでシステムをつくり上げた。眠い目をこすりつつ、納入時には安堵の思いと達成感に包まれた。身につけた技術が社会とつながる実感も得られた。

プロゲートの加藤将倫CEO(東京都渋谷区)

渡米きっかけ、起業決心

自信をつけた大学3年の終わりごろ、起業へと踏み出すきっかけが訪れた。サークル活動を通じて知り合った起業家が、米国で開かれるテクノロジーと音楽・映画の祭典「サウス・バイ・サウスウエスト(SXSW)」に参加するという。「英語がしゃべれるなら、君も行ってみる?」と誘われ、すぐさま渡米の準備をした。

米国ではその起業家にIT関係者を紹介してもらうなかで、フェイスブックの創業初期のメンバーにも出会えた。案内してくれた自宅の豪邸ぶりに「度肝を抜かれた」。話を聞くと、創業時の社員の多くはすでに同社を離れ、ストックオプションで巨万の富を得ていた。大金持ちになったことに満足せず、新事業に挑戦する人もいる。加藤は「テクノロジーを駆使するこんな格好いい人たちがいるんだ」と起業家たちの生き方に衝撃を受けた。

その豪邸に集まっていた起業家から「ところで君はどんなプロダクトをつくっているの?」と質問されたのが忘れられない。日本の起業家の1人だと思われていたのだ。加藤は言葉に詰まった。どうにかプログラミングで仕事を受注できるようになったが、オリジナリティーのあるシステムで勝負しているわけではない。「あの時の自分が悔しくて、自分も世の中に役立つものを生み出したいと思った」。

大学4年になるとき、進路選択で悩んだ。どこかの研究室に入って、さらに大学院も目指すべきか。それとも……。脳裏に焼き付いて離れないのは米国の情景だった。「やりたいのは、いま起業することだ」と決心。プログラミングサークルの村井と共に、14年7月にProgateを立ち上げた。高校時代の友人らも誘い入れ、シェアハウスを借りて「一緒に飯を食いながらプログラミング教材をつくり込んでいった」。

試作品の段階から出資を決めたのは、ベンチャーキャピタルのイーストベンチャーズだ。同社マネージングパートナーの松山太河は「出会ったときから、加藤くんは社会を変えたいというエネルギーを持っていた」と語る。当初、利益が出なかった時期をイーストベンチャーズは資金面で支えた。成長したProgateが20年に合計4億円を資金調達したときも第三者割当増資に応じた。
高校の授業でも活用

先進的な理数系教育に取り組む「スーパーサイエンスハイスクール」の一つ、東京都立立川高校はProgateの教材を採用している。1年生の川崎哲平は素早いブラインドタッチで、Pythonのコードを打ち込んでいった。身につけた技術でいずれ、書籍を丸ごと翻訳するソフトを作りたいと目を輝かせる。同級生の柳沢大志はC#(シーシャープ)というプログラミング言語で、神経衰弱のゲームを一からつくり上げた。
都立立川高校では、ゲームのプログラミングを楽しむ生徒もいる

学校に使ってもらうなかで予期しない反応も返ってきた。立川高校の教諭、佐藤義弘は手取り足取り教えるProgateの教材に「とても丁寧に作ってある」と感心する。それと同時に「生徒を一段と成長させるには失敗から学ばせることも重要だ」と挫折の機会を与える必要も説く。加藤も「初心者を脱した人が、さらに自立できる教材にすることが次のステップだ」と考えている。教材の改善に終わりはないのかもしれない。

日本人のITスキルを向上させたいという思いは強い。小学校、中学校と豪州の現地校に通い、日本の存在感が低下していくのを肌で感じた。小学生のころは、日本のMDプレーヤーのような製品が「クールだ」ともてはやされた。ところが「次第にハードウエアじゃなくてソフトウエア、アイデア勝負の世界に変わり、日本が話題になることが減った」。

経産省はIT人材を7つのレベルに区分し、主要国の状況を分析している。「高度な知識・技能」に相当するレベル4以上の人材は、米国だと7割、インドで6割、中国は5割だった。日本は4割弱にとどまるという。若い頃からITに慣れ親しむとともに、世界で競争すべく厳しさに接することも必要かもしれない。
目指すはグローバル展開

加藤は世界にも目を向ける。18年、進出先に選んだのはアフリカだった。1990年代の内戦による打撃からの復興を遂げてきたルワンダと、かつてクーデターが頻発していたウガンダ。ともに経済の伸びしろが大きいと踏んだ。

だが「まだ成長初期のベンチャー企業が挑戦するには、やや時期尚早だった」。オンラインの課金ビジネスで採算をとるには、まだ難しい市場だと判断して撤退した。「もっと会社が成長したら戻りたい」と再挑戦の決意を胸に秘める。

同年にはインドでも市場開拓を始めた。IT企業が集まる南部のベンガルールに拠点を置き、学生を中心に20万人超までユーザーが増えてきた。小中学校から熱心にIT教育に取り組む親も多いなか、中途半端な理解のまま進学して困る人もいる。大学生を中心に、学び直すニーズがあるという。

さらに20年にはインドネシアに現地法人を設立し、インドネシア語のプログラミング教材を展開している。人口2億7000万人の同国はスマホの普及でデジタルサービス市場が急拡大し、スタートアップ企業も次々と登場してきたことで「エンジニアが不足している」。インドネシアの会員も10万人が目前という。

加藤は「日本の底力を発揮し、グローバルに価値を届けられる企業になりたい」と力を込めて語る。日本の「失われた30年」の間に米国のGAFA、中国のアリババ集団や騰訊控股(テンセント)などの海外企業が飛躍を遂げた。豪州で「日本が埋没していく」と感じた加藤は世界に勝負を挑み続ける。

=敬称略、つづく
連載記事一覧はこちら

アプリ自作、私もできた 子育てママや学生などが公開

https://www.nikkei.com/article/DGXZQOGG16BMO0W0A211C2000000/

『プログラムの知識がなくてもスマートフォンなどのソフトウエアを開発できる技術「ノーコード」を使い、アプリやサービスを作る例が増えている。子育てママは飲食店の紹介、学生は大学の情報を提供するアプリを作った。コロナ禍に促された格好で、誰でもサービスを自作できる時代が訪れている。

「飲食店も近所のママも困っていて助けたかった」。西脇智子さんはノーコードを使い、東京都稲城市の持ち帰りができる飲食店などを紹介…

この記事は会員限定です。登録すると続きをお読みいただけます。

残り1607文字

すべての記事が読み放題
有料会員が初回1カ月無料

有料会員に登録する
https://www.nikkei.com/r123/?ak=https%3A%2F%2Fwww.nikkei.com%2Farticle%2FDGXZQOGM010QT001022021000000&n_cid=DSPRM1AR07

無料会員に登録する
https://www.nikkei.com/r123/?ak=https%3A%2F%2Fwww.nikkei.com%2Farticle%2FDGXZQOGM010QT001022021000000&n_cid=DSPRM1AR07#free

ログインする
https://www.nikkei.com/login

西脇智子さんはノーコードを使い、東京都稲城市の持ち帰りができる飲食店などを紹介するアプリ「いなぎお弁当マップ」を自作した。2月、地域の課題解決をテーマにした音声交流サイト(SNS)「クラブハウス」の集いで取り組みを話すと注目を集めた。その後も話を聞きたいという依頼が届く。1月の緊急事態宣言の後には「何度も使っていると声をかけられた」と言う。

2020年2月、新型コロナウイルスの感染が広がり、飲食店の客は激減した。学校が休校し、主婦の食事を作る負担が増したころ、西脇さんは知人からノーコードを使いアプリを自作できるソフト「グライド」があると聞いた。アプリ開発の経験はないが、考えるよりも先に試すと半日で原型ができたという。3日後には公開した。

人口約9万人の稲城市で最大で月1万人が利用した。西脇さんは「もっと良いものはいくらでも作れるが、求められるものをいち早く出すことだけを考えた」と強調する。

ノーコードとはその名の通り、コンピューターへの命令文であるコードを書かずに、あらかじめ用意されたプログラムのパーツやツールを組み合わせるだけでアプリなどを自作できる技術だ。対応するソフトが公開されており無料のものもある。

専門知識がなくても使える手軽さが売りだ。初心者がプログラミングスクールに通って、アプリを開発できるようになるまでに半年かかるといわれる。ノーコードを使えば難しい場合で1~2カ月、簡単な場合は数日で作れるようになるという。

コロナ禍の不便や不自由を補おうとノーコードの利用は広がった。企業がサービスを開発するのを待っていては時間がかかるし、利用者の細かい要望にまで目が届かない。当事者がすぐ開発できることが重要だった。

明治大の学生、菅沢孝平さんはコロナ禍で大学に行けず、情報を得られない新入生などに、サークルや授業、ゼミなどの情報を紹介するアプリを20年10月までに公開した。

プログラミングは「学んだが挫折した」経験があり、苦手意識があった。それでもグライドならば使えそうに感じて取り組むと、1週間でアプリができた。菅沢さんは「開発にかかる時間が短いので利用者を増やすのに時間を割けた」と話す。

仕事に役立つ例もある。兵庫県加古川市の職員、多田功さんは特別定額給付金を申請する独自システムを開発し、20年5月に同市が採用した。政府の専用サイトと異なりマイナンバーカードが不要で、事務処理が楽になった。同市では政府専用サイトの3倍以上使われた。多田さんは申請業務を担っており「当事者が開発すれば使いやすいものを生み出しやすい」と言う。

ノーコードのオンラインサロン「NoCodeCamp」を運営する森岡修一さんは「今後はノーコードのようにコンピューターが人に合わせるようになる」と指摘する。優れたアプリを開発するには、プログラム技術よりも課題を解決する発想力が必要になるという。

開発ソフト、内外に300種、数年後には主流の手法に
ノーコードを使い、アプリなどを開発できるソフトウエアは、米バブルといった海外のスタートアップが2015年ごろから先行して提供を始めた。20年には米グーグルが専門業者の米アップシートを買収。米アマゾン・ウェブ・サービス(AWS)が業務アプリを開発できるサービスの提供を始めるなど大手が参入した。ウェブサービス開発の基盤ソフトになろうとしている。

日本でも、スマホアプリを簡単に開発できるソフトを提供するヤプリが20年12月に上場するなど注目を集める。ノーコードを利用した開発ソフトは、国内外合わせて300以上あるという。企業が自社のエンジニアのプログラミング技術などを生かして改良できる仕様のものもあり、利用は広がっている。
調査会社の米ガートナーによると、24年までに世界のアプリ開発の65%がノーコードなどの手法になると予測する。デロイトトーマツミック経済研究所の予測では、ノーコードなどの国内の市場規模は23年度に4560億円になる見通しだ。(大越優樹)

漏れのある抽象化の法則

※ クロステックの「抽象化の破れ」の話し(「抽象化のやぶれ」というノーコード/ローコード開発の落とし穴 https://xtech.nikkei.com/atcl/nxt/column/18/00138/010800705/ )を検索してたら、当たった…。

※ 「抽象化の破れ」も、「漏れのある抽象化」も、たぶん同じことを言っているんだろうと、思う…。

※ 非常に参考になったんで、貼っておく…。

『1. 漏れのある抽象化の 法則について

  1. 自己紹介● 名前 – 橘田 隼一● TwitterID – hayabusa333● 興味があること – カーネルとか言語開発とか● 現在のお仕事 – テストプログラマー● 信仰 – Joel教
  2. 漏れのある抽象化の法則
  3. 漏れのある抽象化の法則 ● Joel Spolsky提唱 ● Fog Creek Software 創 業者 ● 人気ブログ Joel on Software
  4. 抽象化一度に注目すべき概念を減らすことおよびその仕組み
  5. TCP/IPIP● 信頼性のない通信方式TCP● 信頼性のある通信方式
  6. TCPはIPの上に実装されている
  7. 信頼性のない通信方式で信頼性のある通信を行う
  8. TCPはIPを使って通信を行っているが詳しいことを 知らなくても通信できる
  9. TCPはIPを使って通信を行っているが詳しいことを 知らなくても通信できる
  10. TCPはIPを抽象化している
  11. しかしLANケーブルが切れていれば繋がらない回線が重ければ、TCPは信頼性を確保できない
  12. 抽象化には漏れがある
  13. これが漏れのある抽象化の法則
  14. 漏れのある抽象化の法則自明でない抽象化はすべて、程度の差こそあれ、漏れがある
  15. 抽象化は失敗する。あるときは小さく、あるときは 大きく、漏れがあるのだ。 物事は悪くなるものだ。この漏れは、抽象化が行われているあらゆる場所で起こる。
  16. Joel の出した例
  17. 大きな二次元配列の要素を順番にたどるという単純な事でも、水平方向か垂直方向かで、「芝目」に依存してパフォーマンス特性が劇的に異なるこ とがある
  18. C言語で記載for(i = 0; i < 30000; i++){ for(j = 0; j < 30000; j++){ array[i][j] = 0; }}for(i = 0; i < 30000; i++){ for(j = 0; j < 30000; j++){ array[j][i] = 1; }}
  19. デモ
  20. この性能差はプログラム言語に よって出たものではなくOSやCPUによって現れたものである
  21. C言語は簡単である。ただしOSの特殊な振る舞い に目をつむれば
  22. OSは簡単である。 OS ただしCPUの特殊な振る舞いに目をつむれば
  23. あなたが日常使うことの90%は 1週間で学習できるが、残りの10%を知るためには2、3年かか るかもしれない
  24. 先ほどの例の理由を知るためには、C言語だけではなく OSの特性、メモリ管理、仮想化、CPUの挙動についても知らない といけない
  25. 漏れのある抽象化の法則にうまく対処する唯一の方法は、その抽象化がどのように機能し、それが何を抽象化している のかを学ぶことだ。
  26. そういうわけで、抽象化は私たちが作業する時間を節約してくれるが、私たちが学ぶ時間までは節約してくれないのだ。
  27. ネットワーク・サーバはプログラム言語で実装されている
  28. プログラムはOSやCPUの上で動いている
  29. 抽象化されている先を 知らなければ 問題は解決できない
  30. 問題を解決できるエンジニアになるためには全てを勉強する必要がある
  31. 我々が目指すエンジニア像は 漏れのある抽象化の法則の漏れを解決できるエンジニアで あるべきである
  32. ぜひ、漏れのある抽象化に だまされないで 漏れを解決できる人に なってほしい
  33. 参考書籍
  34. ご清聴ありがとう ございました』  
  35. ※ こっちも、非常に参考になったんで、貼っておく…。  子どもは何にも知らないの
     https://blog.practical-scheme.net/shiro/20070912-machine-language

『shi3zの日記 – マシン語を知らない子ども達
マシン語読みの言語知らず
アルゴリズムを知らない子ども達
コンパイラの中身を知らない子ども達
オシロスコープを知らない子供たち
元のshi3zさんのエントリが断定調で、一般論と具体論が混ざってることもあって 異論反論パロディが続出したようで。つい黙ってられなくて あちこちにコメントしてしまったけど まとめとく。

解釈が割れた点は:

元の論の対象となる「プログラムが書ける人」は一般の職業プログラマや趣味プログラマまで 含むのか、それとも抽象化の破れにいつも直面してそれを何とかしてしまえるような 一部のタフな人材を指してるのか。
元の論の「マシン語を理解する」は80386アーキテクチャ特有のバッドノウハウまで 理解してばりばりアセンブラを書き下せることを指すのか、それともストアドプログラム アーキテクチャ、MMU、特権命令、割り込み、コンテキストスイッチなどの現代の 代表的なマシンアーキテクチャを理解するということを差し、80386を持ち出したのは 単なる代表例にすぎないのか。
あたりかな。私は両方とも後者と取ったけど、別に解釈すれば異論が出るのがわかる。

ただ、どういう解釈をしても次のような意見が出てくることには首をひねる。

「抽象化はレイヤの積み重ねで、論理回路の下にも半導体があり、電磁気学や 量子力学を知る必要があり、と続いてゆくから程度問題にすぎない。結局「自分は 論理回路から知っているよ」という優越感ゲームにすぎないのでは」

そう思う人にはDaniel HillisのThe Pattern on the Stone (翻訳: 思考する機械 コンピュータ) を勧めとく。翻訳は読んだことが無いが、原書の内容はとても平易なので、 内容だけなら中学生でも理解できるだろう。

第1章は論理回路。第2章で論理演算と状態機械。第3章でプログラミング言語。 第4章でチューリングマシン。第5章でアルゴリズム。以降、暗号や並列計算、 機械学習などを扱う。これを読んだからってプログラムがかけるようにはならないし 紹介された個々の概念を理解したことにはならないけれど、少なくとも現代のコンピュータが どういう概念の積み重ねで出来ているかという構造がわかるようになっている。

で、第1章の論理回路なんだけど、Danny Hillisはここで「スイッチとランプ」 「棒とばね」「パイプと弁」などで論理回路を作って見せる。つまりデバイスが 何であろうと、1と0が表現できてそれを伝達する仕組みさえあれば、残りの全ては その上に構築できるということだ。もちろん物理的に実現可能な規模で現代の CPUを作ろうとしたら半導体以外では非常に困難だろうけれど、今後全く新種の デバイスが出現して物理層がごっそり置き換わったとしても、上の層に 変化はない (ちなみに量子コンピューティングになったらどうなるの、という話は ちゃんと同書の中にも出てくる)。

私は高周波回路も量子力学も苦手だったし、数百MHzのバスクロックに乗るパルスの 波形や数GHzのチップクロックの中を走る電子の雲がどうなってるかなんて 考えたくも無いんだけれど、それらがデジタル回路の抽象化の壁を越えてくる確率と 「高級言語」で書かれたプログラムのSEGVに出会う確率にはあまりに大きな差がある。 抽象化力を指標とすれば、論理回路は非常に強力で成功した抽象化であり、 一方現代の高級言語の多くはまだその域に達していないとも言える。

このような抽象化の壁の厚さの違いに自覚的であることにより、次のようなメリットがある。

学ぶものごとに優先順位をつけられる。たくさんの層があっても、 壁が分厚くなっているいくつかの層を重点的に学べば安定した足場が得られる。
良い抽象化と悪い抽象化の区別がつけられる。自分で抽象化を設計する時に、 自覚的に壁の厚さを選択できる。
抽象化力の違いを無視して相対化してしまう危険は上のメリットの裏返しだ。

あまりにたくさんの層があって全部は学べないから、とりあえず目の前の層を学んどいて、 漏れが出てきたらすぐ下の層、というふうに広げてゆくしかない、と思う。 でも時間に限りがあるから安定した足場までなかなか到達せず、いつも不安を抱えている
自分の設計した抽象化が良いのか悪いのか、判断基準が良くわからない。 また、与えられた問題に必要とされる抽象化の程度を判断できない。
なんだかんだで、ネタにマジレスな野暮だけど、せっかく書いたから貼っておく。

Tags: Programming, Assembly, Hardware』

リーナス・トーバルズ

https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%BC%E3%83%8A%E3%82%B9%E3%83%BB%E3%83%88%E3%83%BC%E3%83%90%E3%83%AB%E3%82%BA

 ※ 懐かしい「名前」だ…。

 ※ VBとかで、サンプルプログラムをなぞって、喜んでいたり、何とか「動く」プログラムを作っては、喜んでいたりした昔(むかし)を、思い出すよ…。

 ※ その頃、ペッカ・ヒマネン(Pekka Himanen)の「The HACKER Ethic」(河出書房新社から翻訳本が、出ている。「リナックスの革命(ハッカー倫理とネット社会の精神)」というタイトルだ…。)という本を、買った…。

 ※ まあ、買っただけで満足して、読んじゃいないが…。もっとも、その頃は忙しくて、到底、読んでるような時間は、無かった…。

 『リーナス・ベネディクト・トーバルズ(Linus Benedict Torvalds、1969年12月28日 – 、Sv-Linus Torvalds.ogg [ˈliːnɵs ˈtuːrvalds][ヘルプ/ファイル])はフィンランド、ヘルシンキ出身のアメリカ合衆国のプログラマ。Linuxカーネルを開発し、1991年に一般に公開した。その後も、公式のLinuxカーネルの最終的な調整役(もしくは「優しい終身の独裁者」)を務める。

アンドリュー・タネンバウムが開発したカーネルとオペレーティングシステム (OS) であるMINIXに刺激を受け、自宅のパーソナルコンピュータ上で動作可能なUNIX OSの必要性を感じ、自分の趣味の時間と自宅の設備でLinuxカーネルの初期の開発を行った。』

トランスメタ
https://ja.wikipedia.org/wiki/%E3%83%88%E3%83%A9%E3%83%B3%E3%82%B9%E3%83%A1%E3%82%BF

※ 確か、トーバルズを高給で、取締役に招いたはずだ…。

『トランスメタ (Transmeta Corporation) は、かつて存在したアメリカのベンチャー企業。当初は低消費電力を特徴とするVLIW型のコードモーフィングマイクロプロセッサを開発していたが、その後は低消費電力集積回路の知的財産権のライセンス提供を主な事業とした。1995年、デビット・ディツェル[1]、Bob Cmelik、Colin Hunter、Ed Kelly、Doug Laird、Malcolm Wing、Greg Zyner によって設立された。2009年1月、トランスメタは米国の未上場のビデオプロセッサメーカーであるNovaforaに買収され、2009年8月に完全に営業を停止した。

トランスメタはふたつのx86互換CPUアーキテクチャ、CrusoeとEfficeonを生み出している。これらは低消費電力と発熱特性の良さを武器として、ノートパソコン、ブレードサーバ、タブレットPC、高静粛性のデスクトップパソコンなどに使われたことがある。』

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

『Crusoe
名称は『漂流記』の主人公ロビンソン・クルーソーに由来する。設計・発売元のトランスメタについてはそちらの記事を参照のこと。同社はいわゆるファブレスであり、製造は社外への委託であった。

最大の特徴はx86命令をCrusoeのハードウェアではデコードせず、「コードモーフィングソフトウェア (CMS4.1)」がx86命令をCrusoeのネイティブのVLIW命令に動的に変換する点である。この点で、発表当初は同時期に開発されたインテルのItaniumとVLIW(Itaniumでは発展形のEPICアーキテクチャ)の実装方法について比較されることがあった。また、CPU負荷に応じて動的にCPUのクロック周波数を高低するLongRun技術を採用し、同CPUの消費電力の低減に貢献している。

第1世代Crusoe
2000年に発売された「TM5400/5600」ではPCのノースブリッジチップを統合している。ただしAGPには対応していない。主に組み込み向け用途を狙ったCPUであるが、発表当初は、まだ他社製CPUに低消費電力向けのものがなかったため、ソニー、NEC、富士通、東芝、カシオなど特に日本市場向けの各社のモバイル向けノートパソコンなどに広く採用された。しかし、初回のアプリケーション起動時にはコードモーフィング処理を行うため、(2回目の起動からは多少速くなるというアナウンスだったものの)パフォーマンスは同クロック周波数の他社製CPUとベンチマークなどで比較すると60%程度で、明らかに見劣りするものだった。またノートパソコン全体の消費電力を左右するのはCPUだけではなかった。発売当初、各CPUのCMSはフラッシュメモリに書き込まれていてバージョンアップ時に変更が可能とされていたが、修正版は一般にはリリースされていない。

第2世代Crusoe
2002年にはCMS4.2にバージョンを上げ、クロック周波数を向上して、パフォーマンスを改善した「TM5800」を発売した。これらはノートパソコン以外に、タブレットPCやブレードサーバへの採用も期待された。もっとも、2003年にインテルが対抗して低消費電力のCPU (Pentium M) を出荷したことや、製造先をIBMからTSMCに変更したものの度重なる製造遅延などでクロックスピードを上げることができず、CPUパフォーマンスを上げることができなかったことなどから、各社のノートパソコンでの採用数は徐々に減少することになる。

Crusoeを採用した主なパソコン
NEC – LaVieMX、LavieZ 駆動時間を延ばすために取り外し型バッテリのほかにLCD(反射型または半透過型)の裏にも取り外し不可のバッテリを実装していた。
富士通 – FMV-BIBLO LOOX
ソニー – VAIO PCG-C1VJシリーズ、PCG-GT3、PCG-U1等
カシオ – CASSIOPEIA FIVA(MPC-205/206/206VL/216XL/225/701)
シャープ – Mebiusノート PC-SX1-H1 PC-MM1シリーズ
東芝 – Libretto L1、L2、L3、L5
日立製作所 – FLORA 220TX、210W NL3 (企業向け)210W NL3はシャープのPC-MM1シリーズとほぼ同一の設計だが、BIOSや、パーツの実装などが一部異なる。
OQO – アメリカで超小型PCを開発、発売
このほか、IBMもCrusoeを搭載したノートパソコン(ThinkPad)を試作、展示したことがあったが、目標とした連続駆動時間を実現できず、開発は中止された[1]。』

 ※ まあ、処理が遅くて、「使いものに、ならなかった。」という記事も、見た…。

 ※ まだこの頃は、「処理の速さ」と「電力消費」は、トレードオフだった…。

 ※ そういうことの「経験」が、Armの「ビッグ・リトルアーキテクチャ」なんかへと、繋がって行くんだろう…。

 ※ それと、半導体の微細加工技術の進展が、1個のダイに、異なる種類のCPUを詰め込むことを可能とすることになったりも、したんだろう…。

能力主義の負の側面、チームの士気を下げる「優秀だがいやなやつ」

能力主義の負の側面、チームの士気を下げる「優秀だがいやなやつ」
クライブ・トンプソン テクノロジーライター
https://xtech.nikkei.com/atcl/nxt/column/18/01472/111800003/

 ※ こういう話しは、よくよく噛みしめておいた方がいい…。

 ※ 人は、決して、一人で何でもできるわけじゃないんだ…。

『「社会を作り変えたいなら、コードを書くのが一番だ」――。ソフトウエアが世の中を大きく変えている今、それを作り上げるコーダーの存在感は高まる一方だ。優秀なコーダーをひき付けられるかが、企業の競争優位性を大きく左右するまでになっている。本特集では5回にわたって、そんなコーダーたちの実像に迫る。

 プログラミングは意志の力のみが物を言う才能の世界で、桁違いの能力差が存在するとコーダーは考えがちだが、そうなるのは、ある意味、当たり前である。

 なにせ、毎日、実感することばかりなのだ。コンピューターに怒ってもしかたないし、どやしつけたらテストの結果がまっとうになるなんてこともない。プログラマーのメレディス・L・パターソンが2014年に書いたエッセイから一節を紹介しよう。

 「ルートシェル相手に口論しても意味がない。相手によってコードが対応を変えることなどありえない。コードが自分の価値を決めるのであって、逆はありえないのだ」

 ふつうの人はできる振りをしたり言い逃れをしたり、言いくるめようとしたりするが、プログラマーは走るコードに敬意を払う。それ以上でもそれ以下でもない。フェイスブックを上場したとき、マーク・ザッカーバーグが書いたオープンレターの一節を紹介しよう。

 「ハッカーというのは、新しいアイデアがうまくいきそうかとかどう作るのが一番いいかとかを何日も議論するより、とりあえず作ってみて、どのあたりがうまくいくのかを確かめてみる人種です。だから、フェイスブックでは『論よりコード』とよく言うのです……また、とてもオープンで能力主義というのも、ハッカーの文化です。一番大事なのはアイデアやその実現であり、それを推進しているのがだれであるとか、その人が部下をたくさん抱えているとかは関係ないと考えるのです」

 プログラミングには、もうひとついい点があるとコーダーは言う。独学で、高学歴の人間と肩を並べられる工学分野はこれだけだ、と。ミドルスクール時代に独学でプログラミングを学び、大学院で情報科学の博士号を得たあと、会社をいくつも創業したコーダー、ジョアンナ・ブルーワーもそう考えるひとりだ。

 「科学・技術・工学・数学、いわゆるSTEMの世界で、博士号を持っているような人が完全に自学自習の人と肩を並べる分野は、コンピューターサイエンスしかないでしょう。すばらしい特徴です」

 一方、能力主義の根底には自画自賛の側面も否定できないと言うコーダーも少なくない。

 新入社員のころや高校などでは人付き合いのうまさで序列が決まりがちだが、そんな時代に、引っ込み思案で決まりの悪い思いばかりをしてきたら、プログラミングは客観的な世界であるとの考えに惹かれるのも無理はないだろう。

 たとえば、ハイ・パフォーマンス・コンピューティングの博士号を持ち、スタンフォード大学で教壇に立っているシンシア・リーは、1990年代から2000年代、コーダーとしてスタートアップで働いていたが、周囲には、若いころ、仲間はずれにされているとかわかってもらえないとか思っていた人がたくさんいて、みな、ここは、そういう口先人間がちやほやされるとは限らない世界だと大喜びしていたという。

「我々がいた技術世界では、切れ者っぽい印象の人やスーツ姿の人には疑いの目が向けられがちでした。いわば敵側ですからね。1980年代の青春映画を観ればわかりますが、当時の高校で人気だったタイプです。対して、我々は、オタクの楽園を作っていたのですから」』

『クオーラとピンタレストで怒濤の成果を挙げたことで知られるトレイシー・チョウも、同じように考えているという。ピンタレストの共同創業者、ベン・シルバーマンが究極のロックスターだと語ったプログラマーである。

 「ソフトウエアの成功者は、ほかの分野で成功してきた人とタイプが違うと思います。また、ここでは、自分の力で成功したと思えないと、成功した実感が得られないのではないでしょうか」

 プログラミングというものは、門外漢にとってはまずまちがいなくわかりづらいし、同じ仕事をしている人にとってもわかりやすいとは限らない。だから、適当なことを言っても通りやすいのだとトレイシーは言う。

 「コードはほとんどの人にとってわかりにくかったり隠れたところで動いていたりするのも一因でしょう。表に出ていても、たいがい、なにがどうなっているのかわかりませんし。ですから、『能力次第の世界、わかる人にはわかる世界なんだよ』と言っておけばなんとなくそんなものかと思ってもらえたりするのです」

 だれでも中を見たりいじったりできるようにコードをオンラインで公開するオープンソースソフトウエアの世界は、特に能力主義の色彩が濃いとされている。自分の貢献を成果として受け入れてもらえるよう競うことになるからだ(お金はもらわないことが多い)。

 実例として、オープンソース関連で一番有名な成功物語となったオペレーティングシステム、GNU/Linux(たいていは、単に「Linux」と呼ばれる)について見てみよう。コンピューターを動かす基本のオペレーティングシステムである点はウィンドウズやMacOSと同じだが、無償で使えること、2500万行ほどもあるコードをだれでも自由にダウンロードして中を見られることなどは大きく違う。

 Linuxの起源は1991年。フィンランドの大学生リーナス・トーバルズが、あくまで趣味として、オペレーティングシステムのカーネルを自作してみようと思ったのだ。オンラインで公開したとき本人も書いているように、大がかりなプロの作品にするつもりなどなかった。だから、シンプルなカーネルができたとき、ほかのハッカーが見られるようにソースコードを公開した。

 そして、雪だるま式の拡張が始まった。世界各地のプログラマーから機能追加の提案コードやバグの修正提案などが届くようになったのだ。よさげな提案は採用。こうして、何百人、何千人もの貢献により、Linuxは、機能がどんどん強化されていった。

 スタイルの異なるコーダーがよってたかっていじってもコードがぐちゃぐちゃにならないようにするため、トーバルズは、「ギット」なるものを開発する(いま、幅広いコーダーに活用されているソフトウエアだ)。ギットを使うと、だれかの貢献を組み込むことも簡単にできるし、その結果、動作がおかしくなったりしたら、元に戻すことも簡単にできる。

 一部ファンが主張していることなのだが、いまのオープンソースは、メリットの市場競争といった感じになっている。多くのコーダーがよいと認め、これなら我々のプロジェクトに組み込んでもいいんじゃないかとなるのはだれのアイデアなのか、それを競っているわけだ。オープンソースとはメリットの純度を高める蒸留だと言ってもいいだろう。

 Linuxにおいて、トーバルズは、役に立つしよくできていると思った貢献のみをLinuxのコードベースに取り込む「善意の独裁者」の役割を果たしている。貢献の敷居はきわめて低い。

 Linuxのソースコードをダウンロードし、そこに手を加えて(ギットを使って変更すれば、木構造で改変場所がわかる)、こういう改変をしてみたんだけどどうだろうとコア・コントリビューターに送るだけでいい。優れた改変だと判断されれば採用され、世界中で使われるようになるわけだ。実際にはもう少しややこしかったりするが、基本的にはそんな感じである。』

『2016年、ポートランドにトーバルズを訪ねたとき、次のように言われた。

 「手元に自分の木があって、好きなようにできるわけです。クレイジーなことを試し、それがうまくいって、かつ、それが実はクレイジーでもなんでもないんだとわかれば、見てくれよとその木を公開すればいいのです。それがすごくいいものだったら、いろんな人が採用してくれます」

 私が会いに行ったころのトーバルズは、もう、自分でコードを書くことがほとんどない状態になっていた。ケーブルやいろいろな道具(スキューバダイビングが趣味で、ダイビング用のソフトウエアも作っている)が転がる自宅の小さなオフィスに座り、毎日、送られてくるコードのチェックをする、いわば、大賢者としてソフトウエアを判断するのが仕事になっていたのだ。

 ちなみに、彼のところまで到達するには、まず、メンテナーと呼ばれる人々による審査を通らなければならない。メンテナーとは中核となる貢献者のことで、自発的にLinuxのコードをたくさん書いたり他人のコードを評価したりして、やる気があるとトーバルズや他のメンテナーに認められた人々だ。ここに入れれば、かなりの実力者ということになる。

 Linuxはコンピューティング分野で広く使われており、インテル、レッドハット、サムスンなどのテック企業には、Linuxへの貢献を業務の一環とする社員やそれが専門の社員までいるようになっている。だから、Linux貢献者の中核と認められるのは、履歴書の売りにもなるほどのことだ。

 有名オープンソースプロジェクトに対する貢献はキャリアアップにつながることが多い。だから、たくさんのコーダーが貢献しようとする。週末の趣味として作ったプロジェクトをオープンソースとしてギットハブなどのサイトに公開するコーダーが多いのも同じ理由だ。自分の仕事を見てもらえるのもうれしいし、自分用に作ったツールをほかの人が使ってくれるのもうれしい。

 さらに、ほかの人々のコードを見て、どう作っているのかを知るのは勉強になる。生態系の一員としてそういう義務があると感じるコーダーも少なくない。自分のコードをオープンソースとして公開したり、ほかの人々のプロジェクトに貢献したりという形で、受けた恩を返しているというのだ。

 取材したコーダーは、全員が、仕事でオープンソースのコードを大量に活用していると言っても過言ではないし、高額の仕事にオープンソースのコードが使われているのも当たり前のことと言える。

 つまりオープンソースとは、いかに心を揺さぶるかのアダム・スミス的競争とカール・マルクスが喜びそうな共産主義的気風とが混然一体となってモチベーションを生み出しているわけだ。そして、それを支えているのが、コードはうそをつかない、つまり、コードが優れていれば、仲間にはわかるし、そういうコードは受け入れられるという理想である。

 「口からでまかせには、みな、眉をひそめるものなのです」とトーバルズは言う。』

『たしかによさげである。だが、スーパーヒーロー級の人材を中心とした世界は、実際のところ、ぐちゃぐちゃになりがちだし、生産性も思ったほど上がらなかったりする。ソフトウエアアーキテクト、ジョナサン・ソローザノ=ハミルトンの体験談を紹介しよう。

 話の主人公は、彼と同じ会社で働いていた自称ロックスタープログラマーである。ソローザノ=ハミルトンのブログでは、リックという名で呼ばれている。リックは「困ったら彼に聞け。そうすれば、ホワイトボードに解決策をさっと書いてくれる」と社内でうわさされるほど優秀で、ヘッドアーキテクトとしてプロジェクトの設計に携わりつつ、エースプログラマーとしてコードを書きまくっていた。彼のおかげで苦境を脱したことも数え切れないくらいあった。

 そんなことをくり返した結果、彼は、自分なしにはなにごともうまくいかない、自分のスキルがすべてを左右すると思うようになったらしい。自分はコーディングのスーパースターである、10倍優秀な人材で凡人とは格が違う、と。そして、あれもこれも背負いこんでいく。

 だが、リックが頑張っても、プロジェクトは遅れていく。ある程度以上大きなプロジェクトは、いかに優秀でもひとりでどうにかできるはずがないのだ。丸1年遅れた時点で、もう2年はかかるほどの遅れだ。リックはヒーローになろうと必死に働いた。上司も、彼の好きにさせていたようだ。当時の状況をソローザノ=ハミルトンは次のように書いている。

「リックはコードを書きまくっていました。毎日12時間、休みなく仕事をしていたのです。この状況を打開できるのはリックしかいないと、みんな、思っていました。息をひそめ、ずたぼろのプロジェクトをなんとかまとめる魔法のような解決策をリックが思いついてくれるのをじっと待っていたのです」

 だが、リックは、過労でいらつき、内にこもるようになっていく。

 このあたりで、事態を打開できないかとソローザノ=ハミルトンに声がかかった。まずはリックに会って話を聞いたが、「あんたなんかに、オレの作ったものが理解できるはずがない。オレはアルバート・アインシュタインで、あんたらみんなはサルで、泥をこねるしか能がないんだから」と取り付く島もない。

 コードを確認すると、これが、スタイルが独特な上、コメントなどがなく、本人以外に手を入れられそうにないものだった。だから、関係者全員が一緒に作る形で一から製品を作り直すことにした。リックはそれも拒絶。休まず仕事を続けるし、ほかの人が書き換えたところを元に戻したり、周りをさげすむようなことを言ったりした。事態は悪化の一途である。

 結局、彼は首にするしかなかった。すると事態は好転した。残った社員が協力し、シンプルな製品を開発。最終的には、サイズも複雑さも20%以上削減することができた。つまり、発注元にとって読みやすいし理解しやすく、また、保守もしやすくなったということだ。スーパーヒーローなんていらなかったわけだ。しかも、開発期間はわずかに6カ月強である。

「リックほどのプログラマーはいませんでした。なんでも自分で作ろうとする鬼才はいなかったのです。その結果、生産性はかつてないほど高くなりました」

 ソローザノ=ハミルトンは、こう結んでいる。

 これは、能力主義の悪い面がもろに出た例だと言える。優秀だがいやなやつ、つまり、自分はかけがえのない人材だと思い込んだプログラマーが生まれてしまうことがあるのだ。そういう人が威張りちらすと、ほかの優秀な人が逃げてしまうし、残念なことに、いまいち使い物にならない製品ができてしまったりする。すべてがその人の頭の中にしまわれているからだ。

 そもそも、社内を混乱させる性格では、たとえ優秀であってもどうにもならないというのが正直なところだろう。』

『優秀だがクズとしか言いようのない人と仕事をして大変だった話は、ほかにもたくさんのコーダーが語ってくれた。

 Yコンビネーターに採用されたとある企業が雇ったロシアのコーダーもそういう人物だった。いい仕事をするのだが、どんな具合だとあいさつされるたび、「こんなところは大嫌いだ」と返すのだ。理由は「ほかの連中の仕事がひどすぎるから」だそうだ。とにかくお山の大将でねと上司はため息交じりだった。

 アプリの作成によく活用されるコードライブラリー、リアクトに詳しいツイッターのプログラマー、ボニー・アイゼンマンは、ロックスターコーダーという神話があるから話がおかしくなるのだと言う。

 優秀だがいやなやつが必ず役に立つとも限らない。たしかに、難問を解決してくれて短期的に助かるかもしれないが、全体の士気にやっかいな後遺症が残る。いやなやつの相手はしたくないと、ほかの優秀な人材が逃げてしまうのだ。IBMのベテランコーダー、グラディ・ブーチも、すごく優秀なのに周囲と協力できず、日の目を見る製品が作れないプログラマーを何人も見てきたそうだ。

 リックのような人材が本当に10倍優秀で、10倍のソフトウエアを書けるのだとしても、つまり、ふつうの10倍のスピードで書けるのだとしても、そこから生まれるのは「技術的負債」であることが多い。急ぎすぎてあちらもこちらもめちゃくちゃになったものしか生まれないのだ。

 手の早いコーダーは、たいてい、手っ取り早いやり方ばかりを採用するし、そのコードはつぎはぎだらけで、その後、だれかがじっくりこつこつクリーンアップしてやらなければならない。ディベロッパーの友人、マックス・ホイットニーの言葉を紹介しよう。

 「10倍優秀なエンジニアというのは、実は、生産性が10倍の人ではないのです。本当のところ、そう言われる人は、同僚の仕事を10倍に増やしているんです。これ、実は、ネットで読んだ話なんですけどね。ともかく、氷山の水面から出ている部分みたいなものなんです。光り輝いてきれいなんですが、その裏には技術的負債が山のように積み上がっているわけです」

 アンドリーセンも語っていたが、コーダーがスタートアップを立ち上げたがるのは、そうすればどんどん前に進めるからだ。だがその場合も、ある程度のユーザーを捕まえられるくらいには機能するがコードベースはぐちゃぐちゃで、根気よくクリーンアップして混乱を収めてくれるプログラマーが必要になったりする。

 トレイシー・チョウは、ピンタレストで、バックエンドの大幅な改修を担当した。そのためにコードベースの検証を進めていたとき、検索が必ず2回行われるという変な動作に気づいた。なにかがおかしい。

 調べてみると、検索を実行するコードがなぜか2回、コピーペーストされていた。ピンタレストの立ち上げ期に、だれかが拙速な仕事をしたわけだ。その1行を削除するだけで、検索の効率は倍増した。このように、10倍優秀というのは、コードを書くことより、むしろ、他人の失敗を修正することに発揮される能力だったりする。』

頭の良さで人をぶん殴っていた、ある同僚の話
https://blog.tinect.jp/?p=68019

 ※ こっちも、同根の話しだ…。

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で実行することができる、ってわけだ。』