bonotakeの日記

元・ソフトウェア工学系研究者、今・AI系エンジニア

MSのエルゴノミックマウスを強力にオススメする話

はじめに書きますが、この記事は思い切りダイレクトマーケティングかもしれません。
別に僕はMSの回し者ではないし当然利害関係もないですけど、本日はMicrosoft Sculpt Ergonomic Mouseを強力にプッシュしたい。

週末の深夜テンションで何か急に書きたくなった。許してほしい。

こいつを買った経緯(自分語り)

※ ここから、こいつを使い始めるいきさつを長々と語るので、面倒なら次のセクションまで飛んで下さい。

まぁ僕はもともと、キーボードに関しては熱烈なMS信者でして、確か一度肘が腱鞘炎になりかけたときに会社の上司に無理言って↓このエルゴノミックキーボードを買ってもらって、それ以来仕事ではずっとこれを愛用してました。

マイナーチェンジしてて型番がちょい新しくなってますが、僕が入手したのはもっと古いやつです。ただほぼ同じ形のはず。
1台は使い潰して、買い直してまでこれ使ってましたね。

一方、自宅のデスクトップ環境はワイヤレスキーボードのほうが都合よかったので、Microsoft Wireless Comfort Keyboard 1.0a ってやつを使ってたんですよ。もう廃番っぽいやつで現在は新品どこにも売ってなさそうですが、こんなやつ。

f:id:bonotake:20190217043026j:plain
Microsoft Wireless Comfort Keyboard & Mouse 1.0a

といってもプライベートでのメインマシンはずっとサブノートPCだったので、これはそんなにヘビーに使ってなかったんですよね。

ところが、会社辞めてフリーになって、自宅でがっつり作業する機会が増えたんです。
当時は(今も)メインのノートPCとしてMacBook Proの2017年モデルを使ってて、大変お気に入りなんですがキーボードだけはクソで、やっぱちゃんとしたキーボードを使って作業したいと。

で、↑のワイヤレスキーボード&マウス使ってデスクトップで仕事のコーディングとかし始めたんですが、1日で右手首が腱鞘炎になりました。
最初何が起こったのかわからなかったんですけども、よくよく考えたらこれはマウスのせいだと。
長らくMacBookトラックパッドで作業しててマウスはほとんど使ってなかったところ、久々にちゃんとマウス使ったら小指を上げる方向にひねるような持ち方に手首が耐えられなかったみたいです。

ということで、キーボードごと新しいマウスを買いました。

そしたら腱鞘炎が一瞬で治まった。嘘松じゃなくほんとに。

こいつの何がそんなにいいのか(使用感などを語る)

割と最近のエルゴノミックマウスに共通してるっぽいですが、手首を変にひねらないのですごい楽。
外観これなんですが、 f:id:bonotake:20190217052657p:plain こういうふうに握る。 f:id:bonotake:20190217035332j:plain 角度を変えるとこうなる。 f:id:bonotake:20190217035359j:plain 手首が自然に傾いてるのがわかりますかね。この傾きと握り具合がすごく心地いいんですよ。
結構重めで、ボールを上から鷲掴みにする感じで握ります。

なお、僕は普通のマウス操作をしてるときはこうではなく、こんな感じ。 f:id:bonotake:20190217035342j:plain f:id:bonotake:20190217035353j:plain この握り方が、僕の手のサイズだとちょうどいいですね。本当に野球ボールか何かをただ握ってるだけの感覚。

ただ、上の方の正規の?握り方にも実は意味があって、この親指がちょうど当たるところにブラウザの戻るボタンがあって、これが地味に超便利なんですよ。 f:id:bonotake:20190217052657p:plain ↑これの水色のWindowsボタンではなく、その脇にもう一個横向きにボタンがあるんです。
f:id:bonotake:20190217053036p:plain ブラウザバックするときにいちいち画面の左上にマウスカーソル持っていく必要なくて、リンククリックしてざっとスクロールして前の画面に戻る、ってのをほとんど手を動かすことなく指先だけで動作が完了するんです。
Webブラウザでググったりしてるときにこれがくっそ楽。
なお、僕は普段の開発はUbuntuでやってますが、この機能はUbuntuでも動きます*1

ということで(まとめ)

これ本気でいいマウスで、一度使うと普通のマウス使えなくなります。
普段の作業で手首疲れるとか痛いとか思ってる人は試してみるといいかもよ。

*1:水色のWindowsボタンの方はそのままではUbuntu18.04では機能しないです。Xevで見てると認識はしてるようだし、設定ちゃんとすれば動きそうですがそこまでは試しておらず。

就職したよ & ディープラーニングコンパイラについてお話したよ

新年あけました(←笑いどころ)
ええと、前回書いたのが10月初旬で、それから4ヶ月も開いたのか……
以降の僕の簡単な動静:

って感じでドタバタしていてブログもSNSも全然手に付きませんでした。

そんなところで先般 fpgax #11 + TFUG ハード部 なる勉強会があり、こちらで『DNNコンパイラの歩みと最近の動向 〜TVMを中心に〜』というタイトルでお話してきました。

fpgax.connpass.com

内容的には、最近出てきた "Deep learning コンパイラ" ってどんなものなのか、ざっくりと僕なりに概要をまとめたものです。
こちらで資料も見れます。

www.slideshare.net

あと当日の映像。僕の登場は 2:09:50 あたりから。


fpgax #11 + TFUG ハード部:DNN専用ハードについて語る会

以上、生存報告でした。

日経xTECH記事『デジタル活用を阻む「PoC貧乏」〜』について

日経xTECHに、次のような記事が載っています*1

tech.nikkeibp.co.jp

この記事、冒頭から

PoC(ポック)貧乏──。講演者の1人が使った言葉が聴衆の笑いを誘った。あるAI(人工知能)関連イベントでの出来事だ。

という一文で始まっています。

で、読み進めていただくとわかるんですが……この「AI関連イベント」、明らかに、私が関わっている 日本ソフトウェア科学会 機械学習工学研究会(MLSE)が5月に開催した、研究会発足記念のキックオフシンポジウムのことで、「講演者の1人」は、アクセンチュアUSAの工藤卓哉さんです。
下記アーカイブ動画の16:44あたりからご覧になれば、記事になっている話がそのまま講演で語られていることがわかります。その辺りで出てくる「丸山先生」は、MLSE運営委員の一人である丸山宏さん(現:Preferred Networks フェロー)です。


基調講演1「ソフトウェア工学における問題提起と機械学習の新たなあり方」工藤卓哉【機械学習工学研究会 キックオフシンポジウム2018】

それで、この「AI関連イベント」がMLSEキックオフシンポジウムであることを前提として書くのですが、当記事には何点か誤りがあると思いますので、このエントリーで指摘しておきたいと思います。
その指摘とは以下です。

  1. PoC貧乏 という言葉の意味が違います
  2. そもそも、PoC という言葉の意味が違います
  3. MLSEのイベントは「AI関連イベント」ではありません

この3点の詳細を、以降で順を追って説明します。

PoC貧乏 という言葉の意味が違います

記事では、工藤さんの講演内容の紹介を、以下のように締めくくっています。

PoCをいくら実施しても、その先が続かない。ベンダーに対価を支払って支援を仰ぐのであれば、リターンを得るどころかお金が出ていくばかり。これがPoC貧乏の実態だ。

これは工藤さんの指す「PoC貧乏」とは意味合いが全く異なります。工藤さんや我々がいう「PoC貧乏」とは発注者側でなく、受注するベンダーが損をする現象のことです。

機械学習プロジェクトにおいて、PoCでは成果が約束できないので、成果報酬でなく、準委任契約に基づく時間報酬で、小規模に行うことが多いです。
これはベンダーにとってあまり利益を生むものではなく、ベンダーはその後の本番システムの構築まで進めて初めて大きな利益を得るのですが、PoC段階で終わってしまうと期待した利益が得られません。この現象を「PoC貧乏」と呼んでいます。

そもそも、PoC という言葉の意味が違います

記事では、PoCについて次のように解説されています。

PoCはProof of Concept(概念検証)の略で、通常は「ピーオーシー」と呼ぶ。新しい技術やアイデアを活用して期待する効果が得られるか、どんな課題があるかなどを確認する作業を指す。

この説明自体は大枠では正しいと思いますが、記事タイトルにもありますように、記事では「デジタル活用」、いわゆる社内のデジタルトランスフォーメーション(DX)におけるPoCの話と、MLSEで扱っている機械学習プロジェクトでのPoCとを混同して用いられているようです。
DXにおけるPoCは、例えばベイカレント・コンサルティング社のサイトなどが参考になるかと思います。社内全体に展開する前に、まずは小規模な試行で効果を確認する行為をPoCと呼びます。

一方、機械学習プロジェクトにおけるPoCは少し特殊な意味合いがあります。機械学習プロジェクトにおけるPoCは、機械学習モデルの訓練(学習)を試みるフェーズのことです。
機械学習プロジェクトの難しいところは、モデルが目的のシステム構築に見合う精度・性能に達するか、達するまでいつまでかかるか最初に見積もれないことです。ですので、ひとまずPoCとして、訓練データを揃えられるだけ揃えて、機械学習エンジニアがモデルの訓練を試みます。
一度の訓練で目標精度に達することは少なく、機械学習エンジニアが様々な改良を加えながら訓練を何度も繰り返します。こうした作業が、機械学習プロジェクトにおけるPoCです。
PoCを経て十分な精度・性能が得られるとわかったモデルを使い*2、初めて実際のシステム構築に着手します。システム構築に踏み切る前に機械学習モジュールだけを先に仮組みするのが、機械学習プロジェクトでのPoCです。全社展開する前に一部の部署でトライアルする、というDXでのPoCとは、意味合いが全く異なります。

MLSEのイベントは「AI関連イベント」ではありません

最後に、これは個人的に不快感を覚えた点ですが、そもそもMLSEでは「AI」を扱っていません
これについてはMLSEサイトのQ&Aにありますので、少し長いですがそのまま引用します。

Q. 人工知能、AIという言葉を使わないのはなぜですか? この研究会では現在よく世間で問われている「AIをいかに業務で使いこなすか?」という問いに対し、対象を機械学習に限定しているだけのように見えます。

現在、機械学習人工知能(AI, Artificial Intelligence)と抱き合わせで議論されることが多いです。

これまで「AI」という用語は、その時代時代で別個の技術を指していました。初期のAI研究では論理プログラムや探索アルゴリズム、1980年代の第2次AIブームではルールベースのエキスパートシステムなどが「AI」と称されました。現在の第3次AIブームで、これに相当するのがディープラーニングを含めた統計的機械学習です。

しかし、これまでのAIと機械学習が典型的に違うのは、これまでのAIが演繹的アプローチ(汎用的なルールを人間が与え、そのルールに従って推論する手法)であるのに対し、機械学習帰納的アプローチ(個別のデータを人間が与えて、機械に汎用的なルールを獲得させる手法)である点です。従来のAIが演繹的であるという点では普通のプログラミング、一般的なソフトウェア開発と特段に変わるところはないのですが、機械学習は全く違う方法でプログラミングをするものだといえます。

ですので工学的視点から見ると、今までのシステム開発手法はそのまま適用できないことがあり、新たな工学としての体系化を行う必要があるのです。これが、MLSEでは「人工知能」「AI」でなく「機械学習」にこだわる理由です。

またAIの宿命として、技術が成熟すると、その技術は世間ではAIとは呼ばれなくなります。機械学習も遠くない将来、AIとは呼ばれなくなると予想されます。しかし,その場合でも機械学習自体は重要なシステム開発技術の一つとして残るでしょう。

AIであるか如何に関わらず、機械学習のための工学研究はこれから地道に取り組んでいく必要があります。ですのでMLSEでは、人工知能ではなく、統計的機械学習を中心に扱います。

「MLSEではAIを扱わない」ことは、キックオフシンポジウムでも何度か述べられていたことです。にも関わらず、MLSEの主催イベントであることを伏せた上で、敢えて「AI関連イベント」と呼称する行為には、遺憾というほかありません。

*1:このアイキャッチ画像に写っている方は記事後半で取材されている平鍋健児さんで、記者とは別人です。念のため。

*2:モデルの再訓練を行う場合も往々にしてありますが、この場合も、使用アルゴリズムや、深層学習の場合はネットワーク、またハイパーパラメータの類はPoCで最終的に用いたものから変更しません。

Leaving LeapMind

Note: This is an English translation of this post.

I guess someone knows and others don't, but anyway, I will leave LeapMind in the middle of next month.

It was the beginning of the last Oct when I joined the company. Since then, I have spent around one year, but it was quite a fulfilling year. I had a thrilling and supreme experience as an engineer, through the challenge in the cutting-edge area of deep learning compiler development, which is what only a few people can enjoy in the world.
There is a full of appreciation for all members of LeapMind. I would like to thank to all of them.

And then, I will be a freelance engineer from around Oct 20th.
But I won't be a permanent freelancer. I'm planning to spend several months to do various things including job hunting, and eventually, hopefully, I would transfer to another company.
Actually, there are many things I have wanted to do so much but failed due to lack of time. I may do some of them during the freelance period.

I want to add a note about MLSE (the special interest group of Machine Learning Systems Engineering). I will keep active as a steering member. We also spent around one year from when we started the activity as a voluntary group, and have gained huge supports from many people, much more than expected, through the year. This is worthwhile, I believe. That makes me more enthusiastic to boost the movement until "the machine learning systems engineering" becomes a true academic discipline.

So anyway, my title and affiliation will change, but I will come through and hit it up. Thanks!

LeapMindを退職します

感づいている人もいない人もいるでしょうが、来月の中旬あたりでLeapMindを退職します。

去年の10月頭からお世話になったので、ちょうど丸々1年といったところですが、大変充実した1年を過ごさせてもらいました。 ディープラーニングコンパイラ開発という、世界でもなかなか得ることのできない貴重な経験を通じて、常に世界の最先端で勝負し続けるという、スリリングで、エンジニアとしては最高な体験をさせてもらえました。
LMの皆さんには感謝しかありません。本当にありがとうございました。

10/20付近から、フリーランスエンジニアとなります。
といっても今後一生フリーで食っていくつもりはなく、色々なことをしながら数ヶ月かけてゆっくり転職活動をし、最終的にはどこかの会社にお世話になるのでは、と思います。
LMにいて、この世界で凄くやりたかったけど、時間を作れずになかなかできなかったこともいっぱいあります。この間にやってみようかな、などと思っています。

なお、機械学習工学研究会(MLSE)の活動については今までどおり継続します。こちらも有志が集まっての活動開始からちょうど1年くらいなのですが、僕らの当初の想像を遥かに上回る形で皆さんの支持を得ることができ、すごく手応えを感じています。 機械学習工学が本当の学問分野となるまで盛り上げていこうと思います。

そんなところで、まぁ肩書?所属?は変わりますが、ガンバって生きていこうと思います。

p.s. 俗に言う内幕暴露な「退職ブログ」を期待された方、すみません。Twitterにちょろっと挨拶を書くだけのつもりが長くなりそうだったので、ブログに書いただけでした。

Facebookのバグ自動修正ツール "SapFix" とは何ぞや?

前回の記事↓で国内ソフトウェア工学事情を勢いに任せて書いたら思いのほか炎じょ……バズってしまい、しかも身内のソフトウェア工学の先生方に火をつけまくってしまいまして、いやはや。関係者の皆様すみませんでした*1
フォローの記事も書こうと思ってたんですが、少々タイミングを逸してしまった感。でも少し誤解を与えたところもあるんで、また時間ができれば書こうかと思います。 bonotake.hatenablog.com

しかし、それから一週間くらい経ちまして、今度はソフトウェア工学に関わる人間としてはなかなか嬉しいニュースが。
それで、つい以下のようなツイートをしたところ、これも軽く話題になってるようで、今もまだ通知が止まらない感じです。

バグの自動修正(automatic repair)はここ数年ソフトウェア工学の国際会議ではかなり盛り上がってる研究トピックです。
これをFacebookがツール化した、というので、やはりこの分野の人間としては大変気になるところ。話題としてもキャッチーですしね。
しかも、この開発リーダーを務めたMark HarmanのFacebookへの投稿を読むと、

I am really delighted and also very proud that we are, today, announcing the first industrial-strength scaled-up automated program repair, now in continuous integration and deployment at Facebook.

とあって、社内の開発フローにさっそく組み込まれた模様。
ちなみにこの Mark Harman、ソフトウェア工学の世界ではプログラム解析の大御所として著名な研究者で、UCL(ロンドン大学)の教授でありながら、最近はFacebookの Engineering Manager (エンジニアの統括マネージャー?)を務めています。

research.fb.com

こういったあたり、海外のソフトウェア工学分野は産学が上手く結びついてるんだなぁ、というのを感じさせますねぇ。

で、そのMark Harmanが陣頭指揮を取って開発した自動バグ修正ツール "SapFix" なんですが、Facebookのブログに簡単な解説記事があります。
code.fb.com

ということで、この記事では残り、このブログ記事を元に、SapFix がどんなツールなのかを簡単に解説していきます。
ちなみにざっと読んだところ、実はそんなに凄いことはしていません。

Androidアプリを対象に、まず自動テストツール "Sapienz"を使って自動テストをかけます。なおこのSapienzも、search-based testing という、最近研究が盛んな技術を元にMark Harmanの研究室で開発された自動テストツールなんですが詳細は省略。ご興味ある方は(+論文読める方は)以下の論文をば。

で、このテストでクラッシュが観測されるとSapFixが稼働するわけですが、その内容とは

  1. 過去の修正から人手で作った修正パッチのテンプレートを、そのまま持ってくるか、あるいはそれがハマらなければミューテーションを使ってテンプレートを変形してパッチを作成。
  2. 上で出来上がったパッチを元に、さらに複数のパッチを生成。
  3. 生成したパッチがコンパイルを通るようなら、さらに開発者が人手で書いたテストとSapienzで生成したテストを流して、このパッチでもうクラッシュが起こらないか+別のクラッシュが発生しないかチェック。
  4. チェックを通ったパッチは人間がレビューして、良さそうならそのパッチを適用。

なお1. で使われてるミューテーションっていうのは、文法に従ってプログラムを適当に('+' を '-' にしたり、変数名を入れ替えたり)書き換える……というもので、元々はわざとバグを埋め込んでテストがそれを見つけられるかを診る、テストを評価するために生まれた技術なんですが、早い話、要はデタラメに書き換えてるだけです。

いかがでしょう。ぶっちゃけ全然凄いことしてません*2。むしろ「えっ、これでホントにバグ直るの??」ってレベルです。

ただ、個人的には結構感心しました。まぁこれが実用上使いものになるかどうかはこれからの評価を待たないといけなさそうですが、これで本当に使えるんならすごいなと。
automatic repair には例えばプログラムの意味まで踏み込んで理解し、バグの内容をちゃんと解析した上で然るべき修正パッチを生成する、なんて手法も研究されてます。で、第一線の研究者が開発に携わってるんで、そういうアプローチも知らない訳はないと思うんです。
でもそういうの敢えて使わずに、簡単な解析だけど軽くて実用のソースコードのサイズに耐えうる技術を使ってるんじゃないですかね、これ。 そういう、研究者の独りよがりでない「現場で使えればいいじゃん」っていう割り切りが凄いなと。

あとはこう言ったら言葉が悪いですが、こんな簡単な解析+自動修正を「数撃ちゃ当たる」的にやっても効果が出ちゃうほど、現場ではしょうもないバグが頻発してるってことなんだと思います。
これも勝手な推測なんですけど、FacebookみたいなDevOpsベースの企業では超短期開発でひたすらアップデートをかけ続けてるはずで、開発+リリース前テストに手間隙かけるよりは、実装はなるたけ簡素に済ませて、CI使って物量でバグを短期間に潰す、ってスタイルを採ってるのかな、と想像します。それならこの手法でも十分効果あるんではないかと。

ということで、最新鋭の技術とかを駆使してるわけでもなければ、理論的に凄い技術も使ってない、でも自らの開発現場に見合った、実用上もっとも効果がある技術を採用しているってことなのかな、と思った次第。
それでも実際の開発フローに組み込めるまで持っていくあたり、相当な作り込みをしてるんじゃないかな、とは想像しますが。これで本当に効果あったらすごいですね。

先のブログ記事によると、もうちょい手を入れた後でこのSapFix(と、テストツールSapienz)はオープンソースにする予定だそうで、ぜひ、中身を覗いてみたいです。

p.s. ……と、この記事をちょうど今書き終わろうかってところで、当の Mark Harman からFBで友達申請が来ましたw びっくりしたー。ツイート見られちゃいましたかね。

追記) 一晩明けてちょい読み返して思ったんですが……全体的にものすごく簡単な技術で構成してるのは事実だと思うんですが、絶対どこか一工夫は入れてると思います。特に怪しいのはパッチを複数作成するところ。脚注には元々書いてますけど。
ここは多分論文書いてどこかに投稿中なんで、まだ明かせないんだと思います。もしその論文が入手できたら補足記事を書きます。

*1:悪びれずに書くと、それなりの問題提起はできたんじゃないかと思ってます。ただあまり本質的でない、余計なところでご迷惑をかけた方面がいくつかあったようで、その点は大変申し訳なかったのでした。

*2:ただ、2. の手順でどう複数のパッチを生成してるか、元のブログには書いてません。おそらくここらへんがこのツールのミソで、詳しくは論文になるまでわからないかも。

最近のソフトウェア工学に思うこと

なんかこのブログに記事書くの、ほんと久々だなと思うんですが。
最近ずっと思ってたことがあったので、つい勢いで書きなぐってしまいました。若干炎上商法かもしれませんが、まぁたまには?いいや。
長文ですがお付き合いください。特に、ソフトウェア工学の研究している皆さん。


昨日、とあるソフトウェア工学のシンポジウムにて、機械学習モデルをWebサービスにデプロイするためのハンズオン、という企画がありました。
僕が運営委員やってるMLSEとの共同企画で、僕は発案者の1人ですが、当日は1人の参加者として中に混じっていました。

4人グループに分かれての作業だったんですけども、僕以外の3人は、いずれもソフトウェア工学の研究をしている修士の学生さんでした。

で、ハンズオンも後半になって「Dockerの使い方」の演習になったのですが、その3人ともDockerに触ったことがなさそうな雰囲気でした。いちいち確認したわけではないので勘違いだったら申し訳ないのですが、少なくとも僕の隣に座った学生さんはインストールで四苦八苦していました。

ただ正味な話、いまソフトウェア開発やっててDockerを全然使わないって、想像しづらいなぁ、とか思います。

いや、いうて僕も前職では業務では使ったことはなかったですし、所詮は単なるツールなんで、使い方を知らなければ覚えればいいだけで、それ自体は問題でも何でもないんです。

ただ、Dockerを知らない・わからないとなると、まず今流行のKubernetesなんて知らないだろうし、何するものかも理解できないですよね。 というかそもそも、「コンテナ」って概念もわからないと思うんです。

そういや(少なくとも日本語の)ソフトウェア工学の論文で「コンテナ」なんて単語、見たことないんですよね。
それどころか、「運用」「デプロイ」といった単語すら、みかけることは稀です。
そもそも運用やデプロイを主題として扱った論文なんて、国内のソフトウェア工学の論文ではたぶん1本もないです。僕の知る限り。

一方、それこそKubernetesの勉強会が都内で開催されたら、結構な数のエンジニアが集まるはずです。「これが俺の考えたさいきょうのデプロイ環境だ」的な話をする発表者もたくさん現れるのではないですかね。

何が言いたいかというと、今の(少なくとも日本の)ソフトウェア工学って、今のソフトウェア開発現場と相当乖離しているように思うんです。最近のソフトウェア開発現場で採用されてる開発形態・開発プロセスを全く想定していないし、だから実務家が持ってる課題意識を、今のソフトウェア工学の研究者は全く把握できてないし、把握しようともしてない感がすごくあります。

ぶっちゃけますが、特に今年になって、ソフトウェア工学関連の学会やイベントの参加者数、論文投稿数が激減してます。特に企業勢の参加が相当減ってるイメージです。

そんでもって、今参加している学会で発表されてる論文、ざっと眺めましたが、申し訳ないけどレベル低いなーと思います。基本的に小粒な研究ばかりだし、発展すれば実務でそのうち役に立ちそう、と思わせる論文がほとんどありません。アカデミックな観点から、新しい領域にチャレンジするようなheavyweightな論文もありません。どこを目指して研究しているのか、さっぱりわからない論文も多々あります。

まぁ、国内学会というか日本語論文のレベルが下がっているのはソフトウェア工学分野に限らなくて、最近はみんな、研究で良い成果が出たらすぐ国際会議にチャレンジする傾向にあるので、それもむべなるかな、というところもあるのですが。
ただソフトウェア工学の場合、日本人がトップカンファレンスで論文採択されることも非常に稀なんですよね。ICSEに日本人の論文が採択されることって、数年に1本あるかないかとか、そんなレベルです。 まぁ要するに、国内のレベルが低いんです。

そういうのもあって、学会への参加者が顕著に減ってるように思います。一方、IT勉強会はどこも大盛況です。
アカデミアの人はもしかすると「エンジニアの参加する勉強会と研究者の集う学会では扱う内容の質が違う」と思ってる人も多いかもしれませんが。
実際のところ、トップカンファレンスで発表された論文の輪講会をやる勉強会とかたくさんありますし、そうじゃなくても、「〇〇で発表された論文を参考に、自分達でこういう工夫をしてみました」なんて発表もしょっちゅう聞きます。ガチガチに最新の論文サーベイして、それに基づいてる発表なんかもあって、結構学術的にもレベル高いですよ。
そもそも、そういう場で発表する人、最近はPhD持ってる人も多いですしね。

要するに今のソフトウェア工学の研究会って、日本のそこかしこで開催されてるIT勉強会に客食われてるんじゃないかと思います。実際、企業人だとそっちの方が面白いしためになるし、と言う気がします。

研究者の全てが開発現場での流行を追う必要はないとも思いますが、誰も追わないってのもソフトウェア工学という学問の特性上まずいと思いますし、追わないなら追わないなりに、基礎研究としてレベルの高いものを見せてほしいんですが、そういうのも(国内では)ありません。

これは僕だけが抱いている「危機感」ではなくて、同じような話を複数のソフトウェア工学に携わる企業人から聞いてます。昨日も、終了後にある人と話してて、「このまま行くと、日本のソフトウェア工学の研究会って数年以内に消滅するんじゃないか」という話をしていました。

なので、国内にいるソフトウェア工学の研究者の皆さん、ぜひ、一度ゼロベースで、色々考えてみてほしいんです。 あなたは誰の方を向いて研究してますか?

追記で注) 既にいくつか頂いているブコメの中に、ちょっとズレてるなと思うものもあったので、一応書いておきます。
僕は1年前までソフトウェア工学の研究者で、情報処理学会ソフトウェア工学研究会 の運営委員も数年務めていました。 今は転職して本業ではなくなりましたが、副業として研究は続けていますし、国内学会のプログラム委員も複数務めています。
要するに、これは外野がギャースカ言ってる話ではなく、内部告発です。

もいっこ追記えーと、国内のソフトウェア工学研究者を表面上disってるように書いてはいますけど、僕の気持ちはそういうdisにあるのではなく、現実問題として、国内のソフトウェア工学研究が寂れつつある(客観的に数字で確認できる)ことへの危機感です。

注:bonotakeは、amazon.co.jpを宣伝しリンクすることによってサイトが紹介料を獲得できる手段を提供することを目的に設定されたアフィリエイト宣伝プログラムである、 Amazonアソシエイト・プログラムの参加者です。