yumulog

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

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人

平成と令和とインターネットと情報科学

f:id:yumu19:20190502145700p:plain

令和が終わる頃、令和がどんな時代だったと振り返られるだろう。想像してみると、VR、自動運転車、人口減、都市集中あたりが挙げられるかな。ただ、その時代がどういうものだったかは、次の年号に移るときに振り返るのもそうだけど、200年くらい経ったときにどう語り継がれているかが本質だと思う。

平成は間違いなくインターネット勃興の時代と言われるだろう。PCという端末を通じて情報にアクセスできるようになり、 スマートフォンという端末を通じてそれがいつでもどこでも持ち出せるようになった。まだ平成が終わったばかりだからだろうけど、とてもわかりやすく進化したと感じる。

「端末を通じたインターネット」を実装をしたのが平成だとすると、「社会に溶け込んだインターネット」が始まるのが令和なのではないか。現在、インターネットは情報端末を通じてアクセスするのがメインだが、これはまだインターネット社会のプロトタイプに過ぎない。物理世界にあるデバイスの情報や、そのデバイスが取得する情報を取り込んだり、その情報を社会システムの前提として組み込んだり、処理した結果を物理世界にフィードバックすることでインターネットのポテンシャルが発揮される。

こんなことは、IoTの文脈でも散々言われてきた。ただ最近は、IoTってスピーカーが喋ったり玄関の鍵をスマホで開けられたりするというところでイメージが落ち着いてきてしまっているようにも思える。IoTってそれだけじゃなくて、もっと壮大な何かなんですよ（語彙力）

こういうコンセプトを実現して社会に溶け込ませるにはかなり総合的に学際的に知見を積み重ねていく必要があって、こういう研究をする分野をなんて呼べば良いんだろう。と考えて出てきたのは「情報科学」だ。日本語の「情報科学」は、英語の "Computer Science" の訳に相当する。いままで、Computer Scienceを情報科学と訳したことにとても不満を持っていたのだけど、こう考えると情報科学というのはとてもいいワードだなと感じる*1。Computer(計算機)でもComputing(計算)でもなくて情報が主体になる。

最近、この先何をしたいのか考えることが多いんだけど、残りの人生でバリバリ活動できる期間は概ね令和と一致すると思われるので、この先の自分のことを考えるのと令和がどういう時代になるか考えることはいろいろと共通する。ということで令和もやっていこうと思うんですけどね。

*1:いいワードだからといって紛らわしいことには変わりないが