**********************************************************************
セッション：特別企画
テーマ：ぼくの/わたしの欲しい組込みプログラミング言語
講師： 間瀬　順一 氏(株式会社アイシン)
　　　 山崎　進 氏(北九州市立大学)
　　　 後藤　孝一 氏(株式会社ヴィッツ)
　　　 細合　晋太郎 氏(株式会社チェンジビジョン)
　　　 及川　達裕 氏(四国職業能力開発大学校)
　　　 浜名　将輝 氏(株式会社ゆめみ)
日時：2021/09/02 13:20～14:40
参加人数：64名（終了時）
**********************************************************************

＜はじめに＞
・組込みソフト開発では主にC言語が使われる．
・組込みソフト開発で言語に求められる要素，開発言語を変えるための起点について議論する．

＜現状把握＞
・約2/3のプロジェクトがCが主力言語である．
・次がC++, アセンブラが補助的に使われている．
・開発プロジェクトの種別
93%が派生，7%が新規 → 多くの開発プロジェクトはベースがある．
・リアルタイム性
多くのもの(81%)がミリ秒オーダーとなっている．
・規制度合い
半分が規制あり，もう半分はなし．

つまり，流用元がCのためそのままCで書くことが多くなっている．
また，組込み開発の成果は「モノ」として販売される側面があり，計算力をむやみに増やすことが難しい．
リアルタイム制約も厳しく，小回りが効くCを使うことは合理性がある．
法規制や機能安全規格などへの対応も蓄積された知識があるため，品質が保証される．

一方で，Cには欠点もある．そこで，組込みソフト用の新しい言語が提案されつつもある(例：mruby, Elixir, Rust，Zenなど)．

＜SWEST23参加者が興味のある言語＞
上にある言語程，興味のある人数が多い．
・python
・Rust
・C++
・Elixir
・C
・Ruby
・Go
・Nim
1票の言語はその他で14名．色々な言語に興味を持っている参加者がいて，SWESTらしい結果になっている．

＜色々な立場から言語について言及＞
・細合氏：アプリ開発者としての立場
・及川氏：教育機関の者としての立場
・浜名氏：学生or若手技術者としての立場
・後藤氏：開発マネージャとしての立場
・山崎氏：言語を提案する者としての立場

＜細合氏のお話＞
実務と言語がどのように関わっているのかの話である．
・astah開発
Javaで作ってきたので言語は変えにくい．

・受託開発・コンサルティング
その時の状況目的に応じて言語を変えることが可能である．

・目的と制約
今やろうとしていることが解決できる言語を選ぶ(ハードウェアやお客様の環境で動く言語)．
以上を満たさないものを除外して，トレードオフ等を考えて決定する．

・手札を増やす
選択肢を増やさなければ，お客様にも提案できない．
日常的に新しい言語を知る．
RSSでの情報取得が有効である．
何が流行っているのか/メインになっているのかを抑えておく(言語の世界はあっという間に変わっていく)．
作り方の方法論や自動化の手段など，言語以外の周りの知識も増やしておく．

・選択権
選べる状況の方が少ない(明日からCを使おうなどいえない)．
開発周りを支える部分を探す．
現場を知っている人でなければ言語は変えられない．

〇SWESTに来るような熱い人が開発現場を変えていけるのでは？

＜及川氏のお話＞
教育サイドからのポジショントークである
・再就職を支援する立場で「組込み教育」を実施している．
初学者を対象(20～30歳前後)
期間：6ヵ月間
学ぶこと：電子回路，C言語，マイコンプログラミング，RTOS, ラズパイ，ネットワーク，PHP
実績：組込み・業務系のプログラマ，IT系の非開発者を輩出した．

・職業訓練における欲しい言語
実業務で使っている言語が欲しい(最も大事)．
→ 再就職が直近のゴールである．ある程度何かを知っている方が現場のニーズに答えられる．
興味を持った生徒が自分でガンガン学びやすい言語が欲しい(次点で大事)．
→ 自分で興味を持って学べるようになることがスキルアップのために大事
コンテンツや情報が豊富である．
環境構築が容易である．
オブジェクト指向など最近の言語の要素が詰まっている．
UI作ったり，見た目で動かすことができ，生徒の興味を惹くことができる．

・教材開発者の視点
Cだと最近のものを活かしづらい(たとえば，ラズパイには python)．
ビジュアルプログラミング言語もPythonやJava scriptに変換される．

以上より，実務を考えるとCだが，生徒の学びやすさはpythonである．しかし，pythonでは求人に弱い欠点がある．
6ヵ月ではどちらも覚えさせるような教育は難しい．

＜浜田氏のお話＞
学生目線でのポジショントークである(浜田氏は社会人二年目)．
・初心者が思う各言語の印象
アセンブリ
コンピュータの基礎教養としては学ぶ価値がある．
初心者は割込みハンドラの開発しない，敷居高い．
C
標準ライブラリが弱く書いていて楽しくない．
コンピュータの基礎を学ぶのは価値がある．
C++
色々便利なライブラリがあるが，pythonやRubyに比べると書きにくい．
Rust
初心者向けではない．
Go
組込み以外の多用途で楽しそう(Web開発やGUIアプリ開発もできる)．

　つまり，C/アセンブリは難しく楽しくない．pythonとかGoとかの方が楽しい．

・学生の気にすること
就活での印象
面接での需要 → 新卒にとっては何でもよい．
どのように書いたかのプロセスが大事となる．
コーディング試験とかもあるので，そのような場合はpythonとかの書きやすい言語の方が良い．

・理想
やろうと思えばC並みの低レイヤーを書ける．
過去資産を流用できる．
軽量性を活かしたモダンな言語設計である．
ライブラリが豊富である．
組込み以外にも使える．

・今できること
何でも良いから自分の好きな言語を1つ見つける(普段自動化したいことを実現するための言語や研究で使う言語)．
就職したら大抵の製品は C で書かれるため，Cやアセンブリもかじっておくと良い．
C を書くための補助ツールを別言語で書けると便利なこともある．

＜後藤氏のお話＞
開発マネージャとしてのポジショントークである
・後藤氏の略歴
C++, C, pythonの3つに触れてきた．
ガラケー開発をC++，車載系をC，AI・人工知能の研究をPythonで書いてきたという経歴を持つ．
最近プログラミングに触れる機会は，たまにコードレビューするくらいとなっている．

・多種多様な言語対応が必要
仕事内容で扱う言語が変わる．
車載だとしても
ECU : C
シミュレーション：MATLAB/Simulink
補助するためのVBA
ナビ：C++, Java
最近はAI使うためにPython
車以外
Kotlin, Swift, PHP, Ruby, Java, JavaScript, Rust...

つまり，幅広い領域の知識が必要である．
マネジメントをする立場としては，多種多様な言語に対応できる人，言語よりかは組込み以外の領域にも幅広く対応できる人が求める人材である．
様々なものがつながり仕事の幅が広がっているため，組込みの技術も必要だが，それ以外の領域の知識も必要となる．

・今後必要とされるスキル 2030
プログラミングは66位
→ 今後，必要とされるスキルとしてプログラミングの順位は低い．
言語が溢れている中で，その中でも今後必要とされるプログラミング言語が考えられるべきである．
　加えて，プログラマ地位向上のために何をしていくべきかを考えていくべきである．

＜山崎氏のお話＞
プログラミング言語処理系サイドからのポジショントークである．
・とある方の主張
C言語は自分の足を撃ち抜く言語だから嫌いな人がいる．
一方で，自分の足を撃ち抜ける言語だから好きな人もいる．

・上記に対してC言語の理想像
C言語は，自分の足を撃ちぬこうと思えば撃ちぬけるが，このままだと
自分の足を撃ちぬくことになることを警告してくれるC言語である．

・上記の理想は無理がある
プログラミング言語では，機能を自由に組み合わせてプログラミングできてしまう．
そのような任意のプログラムについて，「自分の足を撃ち抜くような」不具合が存在するかどうか，存在するとしたら
どこに存在するかを計算によって判定することは不可能となる．
例) 停止性問題：任意のプログラムが無限ループしないことを判定するようなプログラムは計算可能ではない．
プログラミングに関して適切な制約を与えることで，不具合の入りにくいプログラミングができるようにしている．
例：gotoを極力排除することで，スパゲッティプログラムにならないようにしている．

・現代的な言語の制約
Rustの場合
型理論を背景にして制約を与える．
変数の値のコピーに制約を与える．
Elixirの場合
メモリを直接共有しないプロセスとメッセージバッファリングのモデルに基づく制約を与える．
アクタモデルに沿って計算が進行するように制約を与えて設計する．
変数を上書き更新できないイミュータブル性を持たせる制約を与える．

・議論するにあたって
単に機能としてどのようなものが欲しいかを議論するだけだと，「全部入り」になる(実現不可能)．
「引き算」の思考が求められる(どのような不具合を含むプログラムを排除したいのか？)．

＜パネラのお話終了後の全体アンケート＞
Q1　皆さんのポジションは？
・管理者：2%
・開発者：37%
・教育　：53%
・その他：8%

Q2 ソフトウェア開発で困ることは？
選択肢
・開発で使う言語や環境に習熟できていない(第一位)
・ソフトウェアを短期間で開発しなければならない(第二位)
・開発するソフトウェアの複雑度が高い(第三位)
・開発するソフトウェアの量が多い
・開発するソフトウェアの仕様や制約が頻繁に変更される
・開発で使うライブラリやツールに不具合が多い(少なめ)
・開発したソフトウェアの品質が悪い(少なめ)

＜ブレークアウトでの議論＞
「ソフトウェア開発で一番困っていること」を部屋ごとにチャット経由で発表する．
・発生している頻度
・解決の困難さ
・困っていることによる負のインパクト
以上3点を議論する．

＜各ルームの意見(チャットに書かれていてものを記録)＞
ルーム 1
「開発する時間が取れていない」

ルーム 3
4つの困っていること
　・大規模化したときに見通しが悪くなる
　・学生にとっては習熟に困っている
　・外部ライブラリの不具合で困っている，OSSなら直せるけど，バイナリのみ提供だとどうしようもない
　・バージョンの不一致，バージョンアップをいつすべきかで悩んでいる
番外編
　・就職先で求められる言語と，授業や卒業研究等で使ってきた言語が一致しないことは，意外と気にしなくて良い」

ルーム 4
「言語、ツールなどいろいろなものが複雑になりすぎている」

ルーム5
「そもそも開発者が技術向上に対してモチベーションが低い」
「自発的に技術力の向上をしていく意識のある人がすくない」

ルーム 7
「非ソフトウェアエンジニアがソフトウェアのカンコツ・文化を理解して開発に参画する為には？」

ルーム 8
「オンライン中心になってきているのもありコミュニケーションがとりずらい」

ルーム 9
「今まで何も困ったことが無いことが、不安。」

ルーム 10
「（使いこなすために）新しいものを覚えるコスト」が大きいこと」

ルーム 11
「情報の吸収、自分の中に取り込むことが難しいこと」

ルーム 12
「設計漏れに寄る手戻り工数がツライ！」
「手戻りしやすい言語があればいい言語？」

ルーム 13
「新しいことをやるのに、言語や技術の選択肢が広く難しい。各々の学習コストが高くてつらい」

＜各ルームの意見を受けてのディスカッション＞
・新しい言語の習熟について議論する．
（後藤氏）
環境：組込み開発環境は新しいことに移行できない問題がある．
　　 　お客様の所定の物があるが，今まで使ってきた者の方が使い勝手良い．
　　　 現場の人は乗り越えた方が良いことは分かっているが，腰が重い．

（細合氏）
二週間に一回，2時間ほど好き勝手にやる勉強会が行われる．
そこでは，会社に役に立つ・自分がやりたいことをやって，周りと共有する．
勉強会の時間で発見された技術が社内で定着することがある．
時間を作らないと忙しい忙しいとなってしまうので，まずは時間を取って，皆で学んでいこうという意欲が大事だ．

・後藤氏の発言から新しい言語の導入が保守的な場合があることが分かる．
　山崎氏は比較的新しい言語に取り組んでいる．新しい言語の普及に心掛けていることについて議論する．
（山崎氏）
コミュニティの中で，初心者にフレンドリーな感じにする．知らない人に対して冷たい態度は取らない．
何かに興味がある人を巻き込んで勉強会を開催する(参加者が少なくても良いからまずはやってみる)．
→ 面白そうなテーマであれば，ギャラリーとかも入れられるようにして，コミュニティを盛り上げていく．
時には，海外のコミュニティにみんなで飛び込んでみて，挑戦的に技術磨きを行う．
総じて，コミュニティが成り立っていることが重要なことである．

・教えることで工夫していることを教育観点から意見をいただく．
（及川氏）
最新をあえていれることはしない．
ビジュアルプログラミングを取り入れる．
回路の知識を付けたうえで，Arduinoを動かすという感覚を身に付けてC言語へ導入する流れを取っている．

・新しいことは覚えることが多い．このことに関して議論する．
　若い人は覚えることが多いと思うがどのように思うか？
（浜名氏）
業務外でもいろいろ勉強は必要である．
一方で，業務外でやっているインセンティブが少ないのも現状である．
それが評価される仕組みがあればモチベーションにつながるのでは？

（山崎氏）
子育て世代的には…
自分のための時間はほとんど取れない．
会社の中によっては，時間外での自己研鑽を義務化している企業もある(子育て世代には辛い)．
自由時間は家庭に使いたいため，合間時間を効率的に使って自己研鑽しなければならない．
長い時間使って技術を習得して評価されることは敬遠されるべき．子育て世代のような時間を取れない人もいることを考慮しなければならない．

・学びのばらつきに対する考えは？
（後藤氏）
強制するということは，会社の時間を使うことになり，上層部に説明しないとならない．
評価を作れれば良いが，難しい．
だが，自分で学べる人は，結局上が評価してくれる(ことが多い)．
見てる人は見てるので，自己研鑽によってスキルが向上したのであれば，インセンティブは勝手に上がっていく．

・学習コストを乗り越えて何かできるようになっているのが良い状態．実務の話で，Javaからastahを切り替えることは？
（細合氏）
JavaからKotlinに切り替えて，やっている．
こっそり勉強して，それの凄さを披露すると，その技術が定着する場合もある(実例を見せないと周りは分かってくれないことが多い)．

（細合氏の意見に対するコメント）
勇気をもって誰かが書き換えることが大事かもしれない．
ただし，1人で全部切り替えることは厳しい．小さなモデルケースを示して，その後全体設計や運用プロセスにて検討する流れになるだろう．
組込みもいろいろなため，適したプログラミング言語も様々であろう．

■ まとめ
開発の社会自体が新しいことをやっていこうという気持ちになることがまずは大切になる．
アセンブラからCに変わったように，Cに取って代わるものが出てきてもおかしくはない．
人材育成で困る，プロセスで困るなど様々な状況で困りごとがあるため，各状況を考えて，議論を進める必要がある．