電子情報技術産業協会(JEITA)ソフトウェアエンジニアリング技術専門委員会は、ソフトウェア開発技術の調査・研究活動を行っています。その活動の一環として毎年12月に、JEITA会員に閉じないオープンなイベント「ソフトウェアエンジニアリング技術ワークショップ」を参加費無料で開催しています。
今期は、去る12月23日（水）に「プログラミング言語の進化と未来」をテーマに、このイベントとしては初めてオンライン開催しました。少し時間が経ってしまいましたが、一昨年のブロックチェーン・昨年のクラウドネイティブに引き続いて、企画サイドの立場からその内容を報告します。
#公式サイト
https://home.jeita.or.jp/cgi-bin/page/detail.cgi?n=1321
#開催趣旨
プログラミング言語は70年の歴史の中で「構造化」「オブジェクト指向」という２つの革命を経て、今日では、初学者がオブジェクト指向言語から入門し、構造化に至っては当然過ぎて意識もされないようになりました。Javaの出現によるオブジェクト指向の定着からの20年間は、さらなる進化に向けて様々なアイデアが試されて、次の技術革命への模索が進んでいる段階と言えます。本ワークショップでは、こうしたプログラミング言語の進化を振り返り、また新しい言語の機能や実践例を専門のエンジニアの方々に紹介いただき、今後のプログラミング言語の方向性を議論しました。
#プログラム内容
プログラムは、基調講演、技術講演3件、総合討議（拡張Ｑ＆Ａ）から構成しました。
この記事では、まず事前収録で実施した4件の御講演の概要を紹介してから、最後にリアルタイムに実施した総合討議の内容について主に紹介します。
##基調講演 プログラミング言語：四半世紀を振り返る
京都大学大学院情報学研究科 五十嵐 淳 教授
五十嵐先生は、プログラミング言語理論、特にオブジェクト指向言語に関する研究における日本の第一人者で、日本ソフトウェア科学会の2019年度基礎研究賞を受賞されています。
講演タイトルの「四半世紀」は、1995年前後にJava、JavaScript、PHP、Rubyなどインターネット・ブラウザを意識した言語が次々に生まれたことから、それ以降のプログラミング言語の変遷を見て行こうという意味です。この時代の代表的な言語であるJavaは、関数型言語の影響を受けて、2004年にジェネリクスを導入、2014年にはラムダ式（および略記法と簡単な型推論）を導入、という形でほぼ10年ごとに進化しています。今後は、やはり関数型言語で実績が出ている機能が採用されていくのではないかとして、「パターンマッチング構文の導入」と「型の表現力向上（GADT：Generalized Algebraic Data Types）によるコンパイル時チェックの充実」を具体例として挙げています。最後は、「よい機能は使われるようになる」「プログラムの正しさは大事」という２点でまとめられていました。
##技術講演1 Rust with Fearless Concurrency
Idein株式会社 κeen 氏
κeenさん（最初の文字は英字の「ｋ」ではなく、ギリシャ文字のカッパ）の御本名は私も知存じ上げませんが、Rustドキュメント日本語化プロジェクトのメンバーの一人であり、『実践Rust入門[言語仕様から開発手法まで]』の著者として、Rustの普及に活躍されています。
講演タイトルの「Fearless Concurrency」は、『The Rust Programming Language』（通称the book）の第16章（日本語版では「恐れるな！並行性」）から取ったものです。この章の冒頭にその由来が述べられているので引用しておきます：
Rustチームは、… 所有権と型システムは、 メモリ安全性と並行性問題を管理する役に立つ一連の強力な道具であることを発見しました。 所有権と型チェックを活用することで、多くの並行性エラーは、実行時エラーではなくコンパイル時エラーになります。 … 結果として、 プロダクトになった後でなく、作業中にコードを修正できます。 Rustのこの方向性を__恐れるな！並行性__とニックネーム付けしました。
講演の内容は、κeenさん自身が資料を公開されていますので、詳しくはそちらを参照してください。Rustでバグの心配なく並行処理が書ける理由として、(1)「借用」によってデータの競合が起きない、(2)「所有権」によってデータの管理者がわかりやすい、(3)Mutexやチャネル等のミスを防ぐAPI設計、(4)Rayon、async/await等の便利ライブラリの存在、の４点を挙げていました。
##技術講演2 Go言語とテスト駆動開発の経験
株式会社メルペイ ソフトウェアエンジニア 柴田 芳樹 氏
柴田さんは、『Effective Java』、『プログラミング言語Go』をはじめとする多数の書籍の著者・訳者として、JavaやGo言語の普及に活躍されています。今回の御講演では、『プログラミング言語Go』の訳者あとがきに記載がある、「ある組み込みシステムの制御ソフトウェアをGoを使った完全なテスト駆動開発で行うプロジェクトを２年間にわたり率いて、Goでの組み込みシステムの開発が可能なことを実証」された経験談を披露いただきました。
当該プロジェクトは、柴田さんとしては４度目のデジタル複合機コントローラソフトウェアの開発だったのですが、それまで使っていたC++で悩んでいたメモリリーク・メモリ破壊の問題を回避できることを期待してGo言語を採用しました。実際にGoを使って役に立った機能として、競合検出器（Race Detector：実行中に発生したデータ競合を検出）、デッドロック検出（全ゴルーチン停止時にスタックトレースを出力）、チャネルとゴルーチン（複数種類のイベントを持つ場合のプログラミングが容易）の３点を挙げています。また、ゴルーチンを利用する上での重要な点として、(1)メモリモデルを正しく理解している人による設計/コードレビュー、(2)自動テストによるテスト、(3)さまざまな環境による長時間ランニングテスト、(4)ハング/テスト失敗したら「ログを入れて再現」ではなくその場で徹底的に調査、を挙げていました。
##技術講演3 プログラミング言語の潮流とRubyの進化
一般財団法人Rubyアソシエーション 理事長 まつもと ゆきひろ 氏
まつもとさんは、言わずと知れたRubyの生みの親で、このワークショップ開催の翌々日にRuby 3.0.0のリリースを控えて、Rubyがどんな言語を目指しているのかをお話いただきました。
まず、プログラミング言語の潮流を、1960年代の黎明期から「構造化」「オブジェクト指向」「GUI」「Web」「スケーラビリティ」といったキーワードで捉え、直近の動向としてはGo、Rust、Swift等の静的型言語の台頭がある中で、プログラミングにおける型に対する考え方に変化が見られる、と述べます。静的型と動的型の考え方の違いは根深いものがあり、静的型では「型はプログラムの一部である」、動的型では単なる「データの構造」、とみなします。それぞれのメリット・デメリットに対する折衷案として、静的型言語では「型推論」による型記述量の削減や「Liskovの置換原則」による動的性の導入、動的型言語では「Gradual Typing」による型情報の追加や「抽象解釈」による静的解析等が試みられています。
2020年の動向としては、静的型言語に対する(1)関数型の導入（Scala、Rust）、(2)例外処理を型に任せる（Option、Maybe）、(3)VMよりもNativeな実行、が挙げられます。そして、2020年代後半の予想として「より簡潔な表現」を目指す方向があり、そうなると静的型のメリットを型宣言なしでどう実現するのかが課題になります。
Rubyは「今の使いやすさ」を維持したまま「抽象解釈を使った網羅的な型チェック」と「ツール支援による高い生産性」の提供、そして「高い実行性能」の実現を目指します。
##総合討議（拡張Q&A）
（司会）ソフトウェアエンジニアリング技術専門委員会 幹事
ジャパンシステム株式会社 チーフテクノロジーアドバイザー 吉田裕之
例年このワークショップでは、最後に講演者と聴講した皆さんによるディスカッションの時間を取るのが恒例になっています。今年は初のオンライン開催のための不手際もありましたが、「設計との関係」「言語機能」「教育」の３つの観点から７つの議題について、予定時間を30分ほどオーバーするくらい熱い議論ができました。
（以下、発言者の敬称は省略させていただきます）
###・ソフトウェアの設計と言語
####最近の言語に「interface」が無いのはなぜ？
吉田（委員会幹事）：
80年代のオブジェクト指向は結局「差分プログラミング」を頑張ることだった。それが、90年代にオブジェクト指向設計が生まれ、Gang Of Fourの「デザインパターン」が出てきた時に、「我々がやりたかったのは差分プログラミングじゃなくて、こういうことだったんだよね」と気づいた。
そして，Javaに（C++には無かった）interfaceが入ってきて、「良い設計とは良いinterfaceを決めること」だ、という大きな変換点があり、C#、PHP、UMLにもinterfaceが採用された。
ところが、それ以降の言語ではinterfaceが明示的な言語要素としては入らなくなってしまった。それはなぜでしょうか？
五十嵐：
Javaのinterfaceもdefault method等で実装を持てるようになり、型（どういうmethodを持てるかというsignatureの集合）としての役割が少し小さくなっている。
Java等の今までのOO言語がなぜ使いにくくなったかというと、クラスにinterfaceの結合を書くと後からそれに手を付けにくい、ということがあった。ライブラリでも、渡したいobjectがinterfaceが違うから渡せない、interfaceが同じなのに名前が違うから渡せない、つまり結合のタイミングにあまり柔軟性が無いので使いづらいところがある。
κeen：
講演でも継承はあまりよくないと話した。クラス継承は、差分プログラミングに個人的に苦しめられた経験からも、なくなるだろう。
しかし、プログラミングの道具としてinterfaceは残るだろう、例えば、配列をsortする時には比較可能でなければならないので。
一方、ソフトウェア全体の設計としては、このComponentはこのinterfaceを持つ等は、最近の流行りだと言語の中ではなくて外側でやってしまう。programを分けてしまってprogramどうしのやりとりとしてinterfaceを例えばhttpのAPIとかで定義することが多い。
そういう意味ではinterfaceの設計はそんなに（言語の機能としては）重要でなくなってきているのかも。
柴田：
私自身振り返ってみると、Java登場の前はC++で開発していて、その頃は「オブジェクト指向と言えば継承だ」みたいな時代。その後、Javaが登場し勉強し始めたが、最初理解できなかったのが実はinterfaceだった、「これは何のためにあるのだろう」と1ヶ月くらい悩んだ。
ただ、そこを理解してしまうと、interfaceありきは非常に重要な設計道具で、2000年以降（講演で話したTake2以降）の開発では、interfaceという概念をそのまま設計に導入した。例えば「全部pure virtualで書く」としてC++でもinterfaceを実現でき、interfaceを使った開発をC++で長いことやってきた。そういう意味で設計の、あるいは開発の道具としては非常に重要なものだと思う。
一方で、GoのinterfaceはJavaと違ってimplementsを明示的に書く必要がない。「このオブジェクト（or構造体）を渡したい」と思った時に、それに必要な最低限のinterfaceを後付けで定義することができて便利。Javaから移ってきた人はやたらinterfaceを作りたがるが、Goでは２つ以上の具象型が実装しない限りinterfaceを定義するな、と言われている。
ちょっと世界が違うが、それでも設計の道具としてinterfaceは生きている。
まつもと：
動的型付け言語にはDuck Typingという概念があり、暗黙的なinterfaceに相当し、何に対してどんなふるまいをするかはそのオブジェクトが決める。
言語処理に組み込むと、Goのように後付けで定義できるinterfaceになるし、Swiftにもprotocolがあり、けして「あまり使われない概念」ではない。
ただ、柴田さんの話のように、誤用、使い過ぎたり使わな過ぎたりしやすい概念ではあることは確か。
####言語はソフトウェアの本質的困難をどう解決しているか？
大槻（株式会社一（いち））：
Brooks Jr.の「人月の神話」で言われているようにソフトウェアには「本質的困難」があり、それを解決する仕組みが求められている。例えば、自分の変更が他の人になるべく影響を及ぼさないように作るために「情報隠蔽」や「カプセル化」という概念が生まれ、「モジュール」とか「クラス」、「関数」が（言語機能として）生まれた。
変更が避けられないこともソフトウェアの本質的困難の一つで、変更容易性（changeability）を得るために「interface」が必要になった。
これまで、プログラミング言語がソフトウェアの本質的困難をどの程度解決してきたのでしょうか。また、webシステム等の新領域で新たに生まれた本質的困難は何でしょうか。
まつもと：
複雑さとの戦いはプログラミング言語の宿命で、言語によって色々なアプローチがある。
抽象的な定義によって処理をブラックボックス化するアプローチは、主に静的型付けのオブジェクト指向言語。
一方、最近の話題は関数型言語で、状態の管理は人間には辛いので、状態を持たないようにするアプローチ。
どちらが勝つのか、ハイブリットが残るのか、現時点ではまだ分からない。
言語仕様をより簡潔にシンプルにするというGoのようなアプローチもある。
柴田：
Brooksの本質的困難は今でもほとんど変わっていない。Web系もスケーラビリティ、可用性等、色々な問題を抱えていて、それらに対する色々な技術もまだ安定しているわけではなく、問題を解決しながら進化している状況。
モジュール設計で他人に影響を与えないように、は今でも変わらない。きちんと情報隠蔽も含めて分離することは、今でも変わってない、気をつけなければいけないことがらだと思う。
ただ、昔はコンパイラが遅くて継続的インテグレーションもできない状況で、他人に影響を与えないことは非常に大きな要素だったが、今ではコンピューターが早くなったおかげでいつでもビルドでき、githubなど手分けして作業するためのツールが揃ってきているので、それほど大変ではなくなった。
κeen：
92年生まれの私がプログラムを書く時に、他人と変更がかぶらないようにしようと気をつけることはほぼなく。たぶんCIやgit等のソースコード管理ツールのおかげであまり気にしないでよくなったのではないか。
ライブラリを出す時にはinterfaceが変わらないように気をつけるところはあるが、バージョンがあるので、変更があったとしても「バージョンが変わったからしかたないよね」と納得が行く。
アプローチが変わってきていると思う。
五十嵐：
本質的困難はなくなっていない。しかし、ツールの進化もそうだし、言語もモジュールの機能など少しずつ進化していて、複雑性困難さに立ち向かうための道具が色々な方面から増えてきているので、少しずつ与しやすくなっているのだろう。その分、武器のチョイスが難しくなっている面もあるかも。
プログラミング言語の立場から面白いと思っているのは、Scalaという言語。Scalaは、scalableを目指して付けられた名前で、それは性能の意味のscalableではなくて、小規模な部品から大規模なモジュールまで同じ抽象化が使えるという意味で面白い。クラス、モジュールなどレベルが違うと違う機構があると大変で、なるべく同じ武器で立ち向かいたいというアプローチ。
###・プログラミング言語の機能
####exceptionと大域的脱出について
吉田：
五十嵐先生が講演で述べられたように、Javaは「exceptionを型システムに融合する」という素晴らしいアイデアを採用した。
κeenさんはgoto文を見たことが無いと思いますが、80年代の「Goto statements considered harmful」という話からgoto文をできるだけ書かないようになり、C++にcatch/throwが採用されて「これでもうgoto文は書かなくてよくなった」と思ったもの。
一方で今は、まつもとさんが述べられたように「例外は型に任す」という考え方が出てきて、exceptionを提供しない言語も増えてきている。
しかし、「大域的な脱出」が必要な時があり（ex.イテレータの途中で失敗した時に最後まで処理しないでやめたい）、それに昔はgoto文が必要だった。
exceptionが無い言語では大域的な脱出についてどう考えているのでしょうか？
五十嵐：
例外を型に任せる話とJava流の例外は、同じものの違う見え方だと思う。
スタックを巻き戻すとかの実装の話は別として、Javaのようにどんな例外をこのメソッドが吐くのかを書くのは、ある意味で型に任せていると言える。例えば、脱出可能なイテレータのようなものを型レベルで表現は可能。
κeen：
Rustには例外が無いが、個人的には例外はそんなに便利じゃないと思う。try/catchを使わないと扱えないのが便利じゃなく、関数型言語のようにResult型で扱う方が便利。
イテレータを途中で止める関数も書けばできてしまうので、それほど重要な話では無い。むしろ、関数が途中で止まってしまうことの方が、例外が起きたときにどうするのかを考えながら書くのが、状態が爆発して難しいのではないか。
柴田：
大域的な脱出というと、遠い昔にはC言語のsetjmpとlongjmp関数を使ってスタックを戻すのにけっこう感激したもの。
Javaは例外ありきの言語で、それを最大限活用して、例外を含めてきちんとAPIを設計することが求められる言語。
一方で、Goは（例外に近いものはあるが）エラーがあると戻り値で返すのが基本で、戻り値を複数返せるのでその最後がエラーを表すのが典型的。呼び出しを遡るためにはreturnを繰り返すのだが、そのスタイルが悪いかというと、２年半のプログラミングの中であまりそれで困ることは無い。
言語設計者がいらないと思ったものは、無くてもできる言語になっていると思う。
まつもと：
一番シンプルなエラー処理は、C言語のように戻り値の中にエラーをエンコードしてそれをチェックする方式だが、チェックを忘れる危険性がある。
一番オートマチックなのは、JavaあるいはRubyのように、例外が発生して実行が中断する方式だが、関数を途中で抜けるので後始末が必要。チェックを忘れない方がいいけど、いきなり抜けられるとびっくりする、というジレンマがある。
そこで今は、Goでは複数の戻り値にエンコードすることで「ちゃんと書かないと値も取り出せない」、RustやSwiftでは型にエンコードして「正常かどうかチェックしないと値を取り出せない」ようにして、プログラマのうっかりが無いように強制する方向。
個人的にはチェックすること自体が鬱陶しいので例外の方が嬉しいが、いかに（後始末の）うっかりを無くすかは、それぞれの言語に対する課題。Rubyでは、ensure（Lispのunwind-protect）を使ったり、また例えばファイルをopenする時にブロックを使うとブロックの終わりに自動的にcloseする、といった方法で後処理を抽象化・隠蔽化している。
####Rustの所有権は「クールな機能」か
吉田：
五十嵐先生が「クールな機能」というお話をされましたが、本日うかがった講演の中では、Rustの所有権（ownership）はまさにクールな機能と思う。皆さんのご感想をうかがえればと。
五十嵐：
クールな機能だと思う。講演の最後の方で命令型言語の検証器に言及したが、所有権はaliasの問題を解決するものであり、検証器でも同じように所有権を推論する必要がある。
ポインタを使う言語ではこれから流行るのではないか、期待している。
κeen：
システムプログラミング言語などポインタを扱う言語では、必ず無いとやっていけないと思うくらい便利な機能。
一方、アプリケーションを書くような、ポインタをそれほど使わない言語ではただ単に面倒くさいだけで、掛けるコストに対して得られるものがそれほど多くない気がする。メモリ制御する場合はいいが、普段、メモリを気にしないでアプリケーションを書いている人なら別に要らない。
柴田：
C++での経験では、オブジェクトの解放をどこでやるのが正しいのか、コードを読んでわかるようなネーミングルールで所有権を表現していた。例えばgetで始まるメソッドが返す値は呼び出し側でdeleteしてはいけない、createで始まるメソッドでは呼び出し側が責任を持ってdeleteする。そういう運用ルールでしかカバーできず、それでも結局、間違って解放される、ダングリングポインタなど色々な問題があるので、さらにメモリ管理の機能が必要だった。
それが言語仕様として提供されるのは非常に面白い。
まつもと：
アイデアとして凄くクールであることは完全に同意するが、普段プログラムを書いている時によく怒られる、自分では普通に書いているつもりなのに怒られる。私はコンパイラに怒られるのが一番嫌いで、精神衛生上良くないのでなんとかならないかと思うところはある。
色々な事情をおいておくと、GoのようにGCしてくれた方が、と思うところの方が多い。
####関数型言語の大衆化について
大谷：
この5年ほど、学生や色々な人と話をしていて感じるのは、関数型言語の大衆化。以前は、関数型言語は理論的で一般的なプログラマには難しい側面があるだろうと思っていたが、JavaScriptはfirst-classの関数型言語なのに今や一般のWebプログラマに広く使われていて、これは驚くべきこと。普通のプログラマが抵抗なく関数オブジェクトの機能を使いこなして、関数オブジェクトを代入したりやっている。
大衆的なプログラマが当たり前のように関数型プログラミングをしているのは、もしかすると我々研究者が気づかないうちに大衆側からボトムアップに新しいプログラミングパラダイムが提案されて来たのではないか。皆さんはどう思われますか？
まつもと：
たしかにJavaScriptにはfirst-classの関数オブジェクトがあることが非常に重要で、それを使って関数型プログラミングを行っているプログラマがたくさんいることは非常に興味深い。
ErlangやElixirなど関数型プログラミングのパラダイムでwebアプリケーションが作られるなど、HaskellやOcamlを使う人たちとは違うキャンプの人たちにアピールするようになってきたという事実は間違いなくある。また、Elmという関数型言語は、関数型プログラミングとWebアーキテクチャを組み合わせたElmフレームワークを提供している。
一般大衆に関数型プログラミングが伸びてきたという観測は当を得ている。
一方、これから先、そういうものがボトムアップに出てくるかどうかは、現時点ではなんとも言えない。関数型言語も70年代からあるものがやっと追いついた、アカデミアから出たものがぐるりと何周かして大衆に届いたものと言える。
柴田：
First-classとしての関数オブジェクトはGo言語にもあるので、それに慣れてしまうと、あまりJavaとかには戻りたくないなと思うのが正直なところ。
κeen：
私はどちらかというと関数型言語寄りで、同僚もHaskellとかElmを使って普段仕事をしている。便利なものは皆んな使うのではないか。JavaScriptで関数をfirst-classに使わないで書こうとすると死ぬほど面倒くさいので、これを使ったら便利だと気づいたら皆んな使うのではないか。
大衆側から新しいプログラミングパラダイムが出てくるか、と言われると、割と出てきているのではないかと思う。例えば、Elmは「Elmアーキテクチャ」というMVCとはちょっと違うモデルを提供しているし、また、JavaScriptでは「reactiveプログラミング」で値が変更されたらイベントが発火していくなど、それなりにある。
それがアカデミアまで登っていくかというと、ちょっと距離がある気がする。
五十嵐：
プログラミング言語の研究者としては「やっと受け入れられたな」が本音。抵抗なく使いこなすようになってきているのは、first-classで当たり前に扱える言語からプログラミングを始めた人からではないか。
関数型言語が難しいと言われているのは、first-classの関数が難しいというよりは、recursionが難しいのではないか。first-classの概念は高校の数学でも「∑」などがあって、数列の和は「数列」というfirst-classの関数を扱っているようなものなので、そこには実はあまり抵抗はないのではないか。
言語は人間の思考を支配する部分もあるので、それをガラッと変えるのは世代が変わらないと難しいと痛感している。
####ドキュメンテーションコメントは必要か
佐野（日本電気）：
ソースコードをレビューする時に、プログラムの量とコメントの量の比率がある一定の範囲内にないと悪い習慣、とよく言われる。pre-conditionやinvariantを書くようなことを通じてプログラムを検証することもやられている。
そういうプラクティスについてどうお考えでしょうか？
五十嵐：
書きたくないのは本音だが、pre-conditionやpost-conditionはモジュールのinterface仕様の一部でもあるので、分割開発ではある程度しょうがない。
invariantは実装内部の話なのでできれば無くしたいので、研究レベルではinvariantの推論などの研究はたくさんあって期待される。
κeen：
私が書いているコードにはほとんどコメントがないが、なぜかというと、型に色々とエンコードしてあって、型を見ればだいたい分かるので、そんなに必要がない。
それとは別に、docコメントを言語システムとして持つべきだと思う。関数の前に書いてあるdocコメントをreflectionで取り出して色々できるようにする。pre-conditionやpost-conditionもシステムとして取り出して自動検証に使えるようになっているのが重要ではないか。
柴田：
基本的に公開するAPIを書く部分では、JavaならJavadocの形式できちんと書くのが当然。
Javadocのように言語が書き方のシステムを提供していると、ちゃんと書っく方向に行くのだが… 例えば、メルペイではmicro service間の通信はgRPCであり、.protoファイルに定義するのだが、.protoファイルはそもそもgRPC用の定義を書くもので、JavadocのようなAPI仕様を記述する場所ではない。しかし、だから書かなくていいというものではなく、なんらかの工夫をしてきちんと仕様を書くべきだ。
まつもと：
本音を言えばコメントもテストも書きたくないが、残念ながら人類はまだテストしない正しいプログラムを書くという技術を発明していないので、しかたがないのでテストも書くしコメントも書く。ただし、コード中のコメントについては、「一定の割合で書く」等のルールを課すべきではないのではないか。
私自身が自分に課しているルールは、一週間後の自分が騙されるようなコードにはコメントを書く。コメントは本当は邪魔なもので、コードを読んでひと目でわかる、明確なコードであればコメントはいらないはず。
APIについては、pre-condition等を含めて、あった方がいいとは思うが、未来のプログラミング環境ではコードから自動抽出してpre-condition等を提示して欲しい。
###・プログラミング言語の教育
####小学生にプログラミングをどう教えるのか
位野木（工学院大学）：
小学校では今年度からプログラミングが必修になっていて、例えば算数では多角形をscratchで書いてみる等の形で取り組まれてる。
専門家ではない教員達が、色々なレベルの子供達に、目的も様々（楽しさを教える、将来の日本を担う人材を育てる、等）な中で、どのように教えて行けばいいのか、どういう環境を用意すればよいのか、についてお考え・コツを教えて下さい。
まつもと：
私もこの教育指導要領ができた時に政府のIT戦略本部の人材育成分科会で、小学校からプログラミングを教えたからと言っても将来の職業プログラマの育成にはならないと思う、とコメントしたら皆さんが凍りついた。
できあがった学習指導要領を見ると、「プログラミング的思考」を既存の科目を通じて教える、プログラミング体験をする、になっていて、それでいいと思う。そうでないとプログラミングに触れない人達がいて、その中にも一定数適性を見いだされる人がいる、そういう人達にリーチするのが最大の目的。その後は、部活とするなり、自分でやるなり、趣味でやるなりして、伸ばしていけばいい。
成績を付けるようになって、テスト問題を解くようになっては絶対駄目だと思うので、そうならないように今後も声を高く上げていきたい。
柴田：
ものづくりという意味で、楽しんでもらえればいいのではないか。
子どもでなくても、ソフトウェアエンジニアは、一般にものを作っているので、それを楽しめるようになってもらうことが重要。
κeen：
小学校で教えることになると、先生の質もバラバラになって、難しいだろう。
個人的にプログラミングを学んでいた時に重要だと思ったのは、動かしてどうなるのかを自分の目で確認することだったので、教材も自分で試して動かせるものになっていれば、生徒も分かりやすいし、先生も生徒が自分で学んでくれるのでやりやすくなのではないか。
五十嵐：
必ずしも専門家ではない教員だが、児童から出る質問に真摯になんでも答えられるくらいのレベルに達していないと教えられないと思うので、そこをちゃんとやってもらわないと非常に不安しかしない。私でも（専門家でも）小学生に教えろ言われても無理な話で、まだまだ準備が足りないのではないか。
###・まとめ
####現時点で最大の関心事は？
二木（委員会委員長）：
プログラミング言語の研究をしたり、プログラムを開発したり、言語を開発したりしている立場から、現在の一番の関心事、プログラムあるいはプログラミング言語に期待する、に焦点を合わせて何が一番の関心なのかをうかがいたい。
例えば、信頼性なのか、並列性を出すことなのか、あるいは例えばインターネットやe-コマース等のdomain specificなアプリケーションに向けてなのか、色々とあるが、現在あるいは2020年代の一番の焦点とはなんでしょうか。
五十嵐：
一つはDSL（Domain Specific Language）で、DSLを簡単に作る技術が第一。ノーコード、ローコードというキーワードが注目を集めるのもその理由で、そういうものが簡単にエキスパートの人が作れる環境がこれから大事。
それと、プログラム検証と仕様からのプログラム合成が学術レベルでは今盛り上がっているので、実際のプログラミング言語にどんどん広がっていくと期待している。
κeen：
第一には、プログラマが書きたいビジネスロジックに集中できる環境が大事。ポール・グレアムが「プログラムは、プログラムを記述するためのDSLと、そのDSLを使ったプログラムからなる」と言っているので、プログラムを書くためのDSLを簡単に作れる言語が大事。
それとは別に、プログラムの検証には凄い興味があり、例えば、依存型があるIdrisという言語とか、正しさをプログラム自体で証明できる言語は、今後20年後くらいには普及するのではないか。
（κeenさんはその後の考察をブログに公開されています。）
柴田：
マルチコアあるいはマルチスレッドを最大限活用しようとすると、メモリモデルをよく理解して、プログラミングした時にそれがどういう影響を与えるかを理解して、さらにもの凄い量のテストを回さないといけない。それをなんとか言語で解決して欲しい。
かつ、今後出てくる高スペックなPCを最大限活用できるようなプログラミング言語が登場してくれると嬉しい。
Goもたしかにいいのだけれど、やっぱりメモリモデルはちゃんと理解していないとならないので、それがこの10年で解決すると嬉しい。
まつもと：
どういう記述をするとより簡潔に、より正確に、人間の意図をコンピュータに伝えられるかに一番興味がある。
技術的な観点からは、パフォーマンスをいかに改善するか、そのためにはマルチコアを活用しなければならないし、メモリモデル上の問題もあるだろう。
もう一つは、今後のプログラミングはエディタでポチポチとプログラムを書いて終わりではなく、例えばIDEとかインタラクションが中心になっていく。インタラクションによってプログラミング体験を向上させることが、言語そのものの改良と同じくらいに興味がある。
最後に、御講演いただいた方々、議論に参加していただいた方々、聴講していただいた方々に感謝いたします。