yumulog

北海道の大学教員／情報科学研究者の日記

技術書典7で情報処理学会として出展し学会誌とTシャツを頒布しました #技術書典

f:id:yumu19:20190922234108j:plain

技術書典7で情報処理学会としてブースを出展し学会誌とTシャツを頒布しました。

技術書典に出展することになった経緯

そもそもの大前提として、私は、昨年度から、情報処理学会誌『情報処理』の編集委員を務めています。学会誌というのは、学会員宛に毎月届き、破きにくいビニールに入ってる冊子です。↓こういうやつです。ジャーナルが掲載される論文誌ではありません。

情報処理 2019年10月号

情報処理 2019年10月号

編集委員になって約1年半経ったのですが、いままでの活動を通じてわかったのは、学会誌はかなり労力をかけてつくっていて、実際に面白い記事も多いということです。しかし、会員が実際に目を通す機会はおそらくそんなに多くないでしょうし(僕も編集委員になるまでは毎号熱心に読んでるわけではありませんでした)、そもそも会員全員が読んだとしても、情報処理学会員にしか届かないわけです。

特にそう強く思ったきっかけが、今年5月の特集で、私も編集に携わった「フレッシュマンに向けたプログラミングのススメ」でした。これは

平鍋 健児さん、油井 誠 @myui さん、柿本 正憲さん、榊 剛史 @tksakakiさん、渋川 よしき @shibu_jp さん、松本 亮介 @matsumotory さん、増井 雄一郎　　@masuidrive さん、及川 卓也 @takoratta さん、原田 隆宏さん、田中 章愛 @akichika さん

という執筆陣からも想像つくであろう通り、ソフトウェアエンジニアにとって非常に面白い記事が揃ってました。このような面白い記事がたくさんある学会誌を世間に広めないともったいないと思い、学会の中だけではなく世間一般にもっと読んでもらうための施策として、技術書典に出展することを発案しました。ちなみにこのフレッシュマン特集は、今回の頒布ラインナップのひとつにもなっています。

私は学会誌を技術書典を頒布することしか考えてなかったのですが、グッズの頒布を太田智美 @tb_bot さんが発案し、山本ユウカ @ymmox さんのデザインであの「この分野は素人なのですが」Tシャツが出来上がりました。書籍の手配や配送など出展に関する多くの作業は情報処理学会の会誌編集担当の事務局が担当していただき、出展の準備は他にも有志の編集委員も協力してくれました。

稲見 @drinami 編集長も「情報処理学会の薄い本」ということをたまに言っているのですが、学会誌は同人誌を作ることに近い面があると思います。編集委員は大学や企業に勤める人たちが集まった有志で結成され(学術界の委員というのは大体そういう形になってます)、商業的な売上よりも、いかに面白い内容を作り上げるか考えてます(そもそも学会誌は売上より会員数を伸ばすことがKPIですし)。

出展してみて

Tシャツのおかげで強いインパクトを残すことができたかなと思います。Tシャツのツイートが、技術書典関連で最もRT/いいねされたツイートだったと思います(ざっくり調べた限り)。

学会誌も、(正確な数はまだきちんと整理していないのですが概算を見る限り)1サークルとして見れば売れたほうなのではないかと思います。ただ、個人的に想定してたよりは売上少なかったなというのが正直なところです(完全に個人の見解です)。すぐに思い当たる改善点はいろいろあって、例えば、見本誌は置いておいたのですが、その隣にひと目で内容がわかるようなPOPやビラがあると手にとってもらいやすかったかなと。特にフレッシュマン特集の方は、表紙が硬くみえるのでｗ 学会誌は膨大なバックナンバーがあることが武器なので、過去記事から特選集をつくったりするなど、学会誌ならではの技術書典の出展の仕方があるのではないかという気もしました。

ちなみに

技術書典7の感想

技術書典は、一昨年の技術書典2でおうちハック同人誌を頒布したのですが、その時には現地にはいけなかったので、今回が初めて参加する技術書典でした。初参加の感想は、めちゃくちゃ面白かったです。コンテンツがありふれて書籍が売れなくなってきたこの時代に、有志で書籍書いて、それを売って、飛ぶように売れるの、(良い意味で)意味がわからんw 毎月開催してたら売れないと思うので、まあ一種のお祭りなんでしょうが。コミケの同人誌文化を活用して出版のハードルが下がったことでこういうお祭りが可能になったのかなと。

本を見て回るのは純粋にすごく面白くて、いろいろ買いました。

おわりに

情報処理学会の話とは別に、個人的にも、自分で文章を書いて表紙作って印刷所に発注して頒布するというのをやりたいなあと思いました。いつかやるぞ。

それから、個人的に思い描いていることとして、今後の技術書典にいろんな学会の会誌がずらりと並ぶようになると面白いなと思っています。きっと他の学会誌でも似たような想いを抱いているのではないかと思うので。人工知能学会、VR学会、電子情報通信学会、ヒューマンインタフェース学会、芸術科学会等々の会誌担当の皆さん、どうですか？

builderscon tokyo 2019で「20年後のソフトウェアテストの話をしよう」を発表しました #builderscon

presentation

f:id:yumu19:20190830193121j:plain ↑は懇親会で出たカクテルで、スポンサーにちなんだ名前が付けられています。

builderscon tokyo 2019で「20年後のソフトウェアテストの話をしよう」を発表しました！buildersconは『「知らなかった、を聞く」をテーマとした技術を愛する全てのギーク達のお祭り』で、いわゆる(学術会議ではない)テックカンファレンスです。ずっと行ってみたいと思ってたのですが、いままで機会がなく、今回初参加です。

発表資料

Togetter

概要ページ

講演動画

記事

発表

普段研究としてやっているBLEエミュレータの話を、研究者ではなくエンジニアに聞いてほしいと思い、buildersconに応募しました。「テストベッド」というテストに関する部署にいるので、テストに関する現場の課題を知りたいと日々思っているのですが、自分ではふだんバリバリ開発しているわけではない(コードは書きますが研究用のプロトタイプなのでデプロイや運用まで考えないことが多い)ので、現場を知るエンジニアに話を聞いてもらって直接意見交換するのが最も効率良いと思ったからです。（そもそもソフトウェア工学系の学会にも全然顔を出して無いのですが、、、それはまた別の話） もう一つ別の理由として、研究成果を学術会議以外で発表すること自体に興味がありました。JOSSでも話したとおり、アカデミアの学会・論文の仕組みが今の時代に合っていないのではないかという問題意識は強く持っており、エンジニアが集まるテックカンファレンスの形式はアカデミアの課題を打開する方策を示す可能性があるのではないかと思ってます。

それで、発表内容ですが、BLEエミュレータの話だけしてもあんまり面白くないだろうと思ったので、BLEエミュレータを提案の一つとして、先行研究事例も交えながら未来のソフトウェアテストをテーマとして話すことにしました。ただ、「未来」とざっくり書いてしまうと、1年後なのか5年後なのか100年後なのかはっきりしなくて議論が不毛になりがちので、聴講者全員と共通認識を持つために20年としました。

話した内容はざっくり

です。それぞれかなりのボリュームがあるので、発表時間は50分もあったのですがかなり詰め込んでギリギリでした。紹介事例も当日の朝に少し削りました。本当はもっとゆとりを持って話したかったのですが、結構駆け足で話したし、直前の機材準備もギリギリだったので終始落ち着きがなかったし、あと単に50分話して喋り疲れたのもあって、思ったより上手く話せなかったかなあという感想。AパートからBパートへのつなぎとして、「コンテキストアウェア」という概念を持ち出したのですが、上手く伝わったかな・・・。

タイトルには「ソフトウェアテスト」とついているものの、話そうとしている内容にソフトウェアテストの現状の話がほとんど含まれていないので、期待されていた内容と違うんじゃないかなーというのはすごく気になりました。プロポーザルにも「ソフトウェアテストの体系的/理論的な話はしません」と予防線を張ってミスマッチを防いだつもりですが、「思っていたのと違った」と感じた方がいたら申し訳ないです。そして、事例紹介の数がかなり多かったので、もしかしたらあまり興味を惹かないかなあというところも心配でした。ただ、「知らなかった、を聞く」というbuildersconの全体テーマにはきっとすごく合っていたんじゃないかなと思います(自画自賛)。というか、この全体テーマがあったからこそ、自身を持って話せました。

@t_wada さんが来ていたのを終了後にTwitterをみて知って驚きました。ご来場ありがとうございます！！（発表の前に知ってたらプレッシャーになったので、気づかなくてよかったかもw）

会場が満員になると満員大入タオルをもらえる制度があり、せっかくなのでこれは欲しいなあと思って事前の告知を少し頑張りました。結果、立ち見が出て会場に入れない方が出るほどの満員でした。来ていただいた皆様、本当にありがとうございました。

その他の発表

パラレルセッションなので当然全部は聞けないのですが、とても楽しめました。

コンパイラをつくってみよう

@DQNEOさんの、50分の発表時間の間にGoでコンパイラを書く発表。エラーを聴衆からの指摘で修正するということが4回ほどあり、一体感があってすごくよかった。こういう発表は、あとでYouTubeを見るだけでは一体感や臨場感が伝わらないので、現地でみる意味がすごくある。

あと、自分は最近コードあまり書いていないのだけど、書いているのを見ているだけでコード欲が少し満たされたように感じた。ゲーム実況動画をみてゲームした気分になるのと似てる気がする。見てるだけで面白いので、ライブコーディングというYouTuberジャンルがあってもよさそう。

スーパーカミオカンデの開発と運用

面白かった。一番大きな会場である丹羽ホールが満員で、すごく盛り上がっていたので、ゲストスピーカーながら例外で「盛り上がったで賞」を受賞したのも納得。

この話で科学に興味を持った方は、研究機関が年一回程度開催している一般公開*1や、科学館等でやっている講演会などに足を運んでみると良いかなと思います。大体無料です。

ところで、この招待講演の人選、プロポーザルの書き方案内中の推奨とされるトピックの例に

これまでまだ広い範囲にはあまり知られていない分野の問題や現状（例：デジタルセキュリティ、未来技術、ロケット技術）

と、いつもロケット技術が書かれているのですが、これがネタじゃなくて本当に受け入れられるよということを示したかったのかなあと思いました。

おわりに

こういうカンファレンスにはすごく久しぶりに来たのですが、Twitterなどを見ていてもポジティブな反応ばかりで、とてもよいなあと改めて感じました。そして、スポンサーランチ、コーヒー、スピーカーディナー、前夜祭、懇親会、アフターパーティなどなど、参加者とスポンサーへのホスピタリティが本当に素晴らしいなあと思いました。運営スタッフの皆様、本当にありがとうございました！

*1:NICTは毎年6月にやっています

新・なぜソフトウェア開発論文を書くのは難しい(と感じる)のか

f:id:yumu19:20190816232013j:plain

現在の研究テーマ的にシステム・ソフトウェア開発論文を読んだり書いたりする機会が多い。指南文献などもいろいろ読み、以前よりは書くポイントがだいぶわかってきたつもりだが、それでもやっぱりあまり得意ではない。むしろ書くポイントが分かってきたからこそ、その難しさを実感するようになったのかもしれない。なお、ソフトウェア開発論文の執筆の難しさについて書かれた、『なぜソフトウェア論文を書くのは難しい(と感じる)のか』という非常に有名な文章がある。執筆の難しさについて客観的かつとても網羅的に書かれているので、未読の方は、こちらを先に読むと良いだろう。

システム・ソフトウェア開発論文では、導入部で「なぜいままでだれもやっていないのか」「どのような難しさがあったのか」を説明することが重要だと実感している。論文としてまとめる際に、開発する難しさ、そしてその難しさを乗り越えるアイデアがあたかも初めからあったように書かないといけない。システム・ソフトウェア開発以外の分野の論文でも最初から課題があるとしてシンプルなストーリーに構成し直すことはよくあることなのだが、例えば、自然科学の論文では「なぜいままで誰もやっていなかったのか」を説明することはあまりないだろう。システム・ソフトウェア開発論文では、そこに客観的な説得力を持たせて書かないと読者(要は査読者)を納得させられない。しかし、これが難しい。

先日見た以下の記事で

私は、モノづくりというのは「課題がある！　→解決策を苦労して探した！　→完成！」というシンプルな生い立ちを持つことがむしろ不自然、あるいはとても窮屈、ひいてはもったいないことなのではないかと疑っています。

という記述があったのだが、これがまさにシステム・ソフトウェア開発論文の導入部を書く難しさを表していると思う。開発過程を振り返り構成を整理すればシンプルなストーリーに仕上がるという単純な話ではない。頑張って文章を書けば、複数の理由を上手くまとめることはできるであろう。しかし、論文である以上、導入と結論の一貫性が大事であり、開発したシステム・ソフトウェアは目的に沿って評価される必要があり、複数の理由が絡まった軸で評価することは極めて大変になる。

システム・ソフトウェア開発研究に着手する際に「ここが難しいからいままで誰もやっていないだろう、しかしこのアイデアがあればできるぜ！」と考えて始めることは稀*1で、本当のきっかけというのは「面白そうだから」「できそうだから」「まだ誰もやってないから」等という、登山家が「そこに山があるから」と言うのに近いものがある。業務や組織の都合で開発し始めることも多いだろう。しかし、そこで開き直って正直に書いても、読者は納得させられない。

また、「どのような難しさがあったのか」を書くのも難しく、「難しい手段を使わずに簡単に解決できるならそれに越したことはないのでは🤔」と思ってしまう。ただ、これはシステム・ソフトウェア論文の執筆スキルを上げることで解決できるのではないかと思っている。客観的に難しさを示すパターンがいくつかあって（「分散並列処理の制御の困難さ」「特定のボトルネックの指摘」等）、そのレパートリーを増やしていくことで、いろんな切り口から難しさを客観的に説明できるようになる。

このように、システム・ソフトウェア開発を書くのはすごく難しい(と感じる)。特に、自分はハッカータイプではなく、コードは何かの目的を実現するための手段でしかないと考えているタイプの情報系研究者なので、この形式で論文を量産していくのは難しそうな気がしている。考えるより先にコードを書くようなハッカータイプの研究者なら、こういう形式で知見を残して論文を量産できるのかもしれない。

参考

*1:人によっては結構あるのかな？

専門を絞りきれない研究者が歩む「ポリバレント研究者」という道

f:id:yumu19:20190523001008j:plain

（写真は、先週の博士論文一次提出時の様子です）

というエントリを先日読んだ。ネットワーク分野、NICT、社会人博士という共通点が多々あることもさることながら、「研究者を標榜しながらスペシャリストを諦めゼネラリストとして生きるという選択肢は、矛盾・葛藤を孕む」というのが、まさに普段自分が抱えてる葛藤で、あなたは私か！？と思うほど大変共感しながら読んだ。

私のキャリア詳細は記述せずポートフォリオを貼るにとどめるが、地球惑星科学を専攻した後に情報科学の分野に移り、情報科学の中でもネットワーク、Human-Computer Interaction、ユビキタスコンピューティングと取り留めなく分野を選んできた。また、研究活動の場も大学、国研、大企業、ベンチャー企業と転々としてきた。

また、周囲の情報系研究者やエンジニアを見渡すと、中学生・高校生からバリバリプログラミングやってましたという人ばかり目につく。そうなると大学の授業で初めてプログラミングに触れ、仕事でエンジニアやっていたので一応プログラム書けます程度の自分の専門性の浅さを思い知らされたりもした。なので、先述のような葛藤を抱えていて、こういう専門が複数ある研究者のことをどう表現すれば良いのだろう、どういう強みがあるのだろうとよく考えていた。ジェネラリスト型研究者、と呼ぶこともできるであろうが、ジェネラリストという言葉はすでに意味が定着している上に「ジェネラリスト」と「研究者」という反対の性質をもつものを結びつけることで矛盾する感じがして、別の呼称がほしかった。ところが、以前ある概念を思いついてからなんとなく整理がついた。それが、タイトルにもある「ポリバレント研究者」だ。ポリバレントというのは、サッカーにおいて1人で複数のポジションをこなせることを意味する。イビチャ・オシム氏がサッカー日本代表監督に就任した頃に流行った用語だ。ちなみにポリバレント(polyvalent)という英単語は、「多価」という意味の化学用語である。サッカー用語としては、世界共通で使われているわけではなく、日本独自のものである。

日本人サッカー選手の精鋭を集められる代表チームであれば、サイドバックの専門家など各ポジションを極めた選手で構成した方が良いと考えるかもしれない。しかし、特に近年はサッカー戦術の発展が著しく、試合の中で一つのポジションの役割が流動的に変化する。そのため、ポジションを越えたチーム戦術の理解と、戦術に合わせた役割の変更に対応することが重要なのであろう。あとは単純に、代表チームでチームの人数枠が限られている*1ので、ケガ人や不調の選手が出るとチーム構成がままならなくなるので、複数ポジションをカバーできる選手が重宝されるというのもあるが。

この、ポリバレントという概念を研究者と結びつけることを思いついてからは、ポリバレントなサッカー選手に強みがあるように、複数の分野にまたがる研究者にも同じような強みがあるんじゃないか、と思っている。例えば、他分野の知見が必要になったとき、その分野に飛び込んでコミュニケーションをとることは、（ステレオタイプな偏見を大いに含むが）ずっとひとつの専門で続けてきた研究者の方が苦手なように見える。自分が知らない分野への敬意は大事だが、自分から飛び込まないとなかなか話が進まない。もっとひどい場合では、外から見て「あの分野はダメだ」とdisってる。一方、ポリバレントな研究者だと分野を越えることに全く躊躇いが無い。越境することができる研究者って意外と少ないので貴重なんじゃないだろうか。

研究分野のポリバレントの他にも、基礎研究から実用技術化、社会実装まで、研究のフェーズによって研究者の役割が変わってくる。こういったフェーズごとにいろんな役割をこなすという意味でポリバレントもあるかもしれない。こうなってくると、ただの器用貧乏という風にも見られるのだが、器用貧乏にならないためには分野や役割によらずにどこでも発揮できる「自分の軸」が必要なのかも。

先のエントリのスライドにあった図を見てなるほどと思ったのだけど、この「菊地の狙い目」と書いてあるスペシャリストとジェネラリストが重なるところがポリバレント研究者なのかもしれない。

追記

好奇心が未来をつくる ソニーCSL研究員が妄想する人類のこれから

好奇心が未来をつくる ソニーCSL研究員が妄想する人類のこれから

にて、副所長の暦本さんのインタビュー(最初の章)で

周囲の研究者とはまったく違う知識を持っていて、それを問題解決に結びつけられれば、より困難な問題の解決が可能

　

一人の研究者のキャパシティで考え続けるより、まったく違う分野の知識が入って組み合わせが起こることのほうが重要

また、所長の北野さんのインタビュー(最後の章)で

新しい研究は、一つの分野に特化するケースが多いものですが、一人の研究者が複数の分野をよくわかっているときに、新しいものが生まれる確率が高い。

　

自分の中に複数の分野の体験と知見を深く持ち、その中で越境するのが最もインパクトがある。あくまでも、自ら越境していくことで未来が拓けていくのだと思います。

とあり、ポリバレントの強みがとてもわかりやすく書かれている。実際、CSLの現メンバーに複数分野を渡ってきた人はとても多く、本書の全20名のインタビューではそのキャリアの変遷の背景や理由が深く書かれているのでとても面白い。

*1:W杯なら23人