【Devトークスペシャル アフターレポート】ちょまどさんとDevトークで話した！

こんにちは！Qiita Jobs Plus 編集部です。

Qiita Jobs では、エンジニア同士で気軽に相談や情報交換などができる場として「Dev トーク」をご用意しています。 https://jobs.qiita.com/dev_talks/about

そして、その Dev トークをもっとみなさんに知ってもらい、より気軽にご利用いただくきっかけとして、著名な方と Dev トークで話せる「Dev トークスペシャル」という特別企画を実施しています。

今回の記事では、Dev トークスペシャル第 3 弾として、IT 企業でエンジニアとして働きながら、漫画家など多方面でも活躍されているちょまどさんの回について、Dev トーク実施当日の模様をご紹介します。

今回レポートするのは、下記の 2 つのトークテーマ回です。 ・「推し技術について語ってください」 ・「インターネット老人会」

※個人が特定できる情報やクローズドな内容の箇所は大きく省き、ダイジェストとして構成しています。もっと内容の濃い充実した時間になっているのですが、ぜひ雰囲気だけでも伝われば幸いです。

ちょまど

大手外資系 IT 企業で DevRel 業をしているエンジニア。エンジニアカルチャーが好き。英文科卒業後、新卒入社した日系企業を（プログラミングやりた過ぎて）3か月で辞めて、スタートアップにエンジニアとして転職し、そこで C# に出会う。C#/Visual Studio が好きすぎて それらの生みの親の会社に転職し、現在に至る。Twitterではフォロワー 9 万人を超えるツイ廃。松屋が好き。

トークテーマ「推しについて語ってください」

応募者の中から選ばれたお 2 人にそれぞれの推し技術もご紹介いただき、3 人で Dev トークを行いました。

「Kotlin が好きすぎる方」と「ストリーム処理を推す方」が参加

ちょまど：

お忙しい中、参加くださってありがとうございます。うれしいです！　（後ろを振り返って）うちの Google Home（Google Nest Hub）の音が入ってきてしまっているので音を止めますね。ちょっと、ごめんなさい。（離席）

参加者Ｓ：

（参加者Ｋ氏の部屋にデジタル機器がたくさん映っているのを見て）部屋がすごいですね。

参加者Ｋ：

いつもこんな感じです。はい。

ちょまど：

（戻ってきて着席）Google Home の画面に「Google Home がうるさすぎる」って検索結果が表示されていて……。

一同：

（笑）

ちょまど：

では、自己紹介をお願いします。

参加者Ｋ：

自社開発プロダクトを作っている会社で Android アプリ開発エンジニアとして仕事をしています。たまに Web を書いています。技術スタックは Kotlin です。現在は、Kotlin で Android アプリを開発するのがメインになっています。今回、応募したのも Kotlin が大好きで「推し」なので、その話ができればと思ったからです。よろしくお願いします。

ちょまど：

応募の際のメッセージに「Kotlin が好きすぎて夜も眠れません」と書いてあって、これは面白い人だ！　と思いました。

一同：

（笑）

参加者Ｓ：

ソフトウェアエンジニアをしています。リサーチ＆エンジニアリングとして、たまに論文を書いています。専門分野は主にデータベースです。データベースと密接に関わるストリーム処理も専門の一部で、今日はストリーム処理のお話をさせていただきたいと思っています。今日はプログラミング言語の話はしませんが、言語では Rust が大好きです。いずれ、Rust の話もできたら良いなと思っています。

ちょまど：

私の個人的な勝手な印象だと Rust と Elixir は“信者”が多いイメージがあるんですよ。

一同：

（笑）

参加者Ｓ：

Rust もそうですけど、R あたりも濃いかもしれないです。Rust は、どんどんコモディティ化していくだろうなと思っています。

ちょまど：

そのあたり、メモリ管理の話とか詳しい話を聞きたい気もしますが、それは今度ということになりそうですね。

「だんだん、Kotlin じゃないと書けない体に」

ちょまど：

では、まず「推し」の Kotlin について語っていただけますか？　私、前職でモバイルアプリを開発していましたが、当時、まだ Kotlin はなかった気がします。

参加者Ｋ：

Kotlin 1.0 は、2016 年 2 月にリリースされました。

ちょまど：

2 月まで Android アプリの開発はしていましたが、3 月に転職したので、タイミングとして Kotlin は見たことがない感じですね。

参加者Ｋ：

なるほど、大丈夫です。その時代に Kotlin 触っている人ってちょっと“変態”なんで。

一同：

（爆笑）

ちょまど：

ちなみに、その頃、触っていましたか？

参加者Ｋ：

僕が今の会社に入ったのは 2016 年です。そこで出会った Android エンジニアの人がすごく濃くて。もう使ってたんですよ、Kotlin をプロダクションで使っていました。

ちょまど：

えっ！（驚）　もう、その時期にプロダクトに使っていたのですか？

参加者Ｋ：

はい。僕は、学生時代は Java で Android アプリを作っていたので、「なんなのだ、この言語は!?」みたいになって「Java で良いじゃん」と思ってブツクサ言いながら書いていたんですけど、だんだん、Kotlin じゃないと書けない体になっていきました。

参加者Ｓ：

（笑）

ちょまど：

だんだん、“沼って”いったわけですね。（笑）

参加者Ｋ：

そうです。さきほど、クロスプラットフォームの話が出てきたので話をすると、今、とても“熱い”のが、Kotlin で書いてクロスプラットフォームで iOS のアプリもデスクトップのアプリも Web のアプリも全て作れるマルチプラットフォームという機能です。

ちょまど：

それはサードパーティか有志がやっているのですか？

参加者Ｋ：

公式です。開発元のジェットブレインズが「推し」ている機能です。Kotlin はもともと JVM の言語なので、JVM でコンパイルして実行します。Kotlin のコードをネイティブコードにコンパイルしたり、JavaScript にコンパイルしたりできる機能をジェットブレインズが作っています。「どんなプラットフォームでも Kotlin 一発で書けるようにしようぜ！」というのが、Kotlin のマルチプラットフォームです。

ちょまど：

すごい。iOS のアプリをビルドできるって Xcode を介してですよね。

参加者Ｋ：

そうです。オブジェクティブ C のコードになるのかなと。それで、C、Swift から読みこめるコードの形にしています。Kotlin のマルチプラットフォームは、UI の共通化はそんなに頑張らない方向性で、ドメインロジック、特定の言語にあまり関わらないロジックの部分から共通化していく方向性です。1 回のコードで書いてデプロイできるようにすることにフォーカスしているのが上手いと思います。急速に広まっている感じです。

ちょまど：

良いですね。わかります、私は、かなり C#“信者”で、全て C#で書きたくなるので、Kotlin で全て書きたくなる気持ち。

参加者Ｓ：

プラットフォーム固有の UI 周りとかは Kotlin 以外の言語で書く必要も出てくる感じなんですか？

参加者Ｋ：

そうです。

Kotlin に引きこまれていった理由は？

参加者Ｓ：

Kotlin の言語機能で、何が好きですか？　他の言語と比べて気に入っているのはどんなところなのでしょうか？

参加者Ｋ：

言語機能で好きなのは、「Class Delegation（クラス委譲機能）」です。

参加者Ｓ：

ほうほうほうほう。

ちょまど：

それは何ですか？　かっこいい名前。

参加者Ｋ：

継承をいい感じで実行できる機能です。Kotlin は基本的にはインターフェースの多重継承はできますが、他は多重継承ができません。しかし、Class Delegation を使うとインターフェースの実装を引数だとかで渡したインスタンスに代わりにやってもらうことができます。

参加者Ｓ：

Ruby にも似たような機能がありますね。

参加者Ｋ：

そうです、mixin 機能は、まさに似たような感じです。それを使うと多重継承のような実装ができるので、インターフェースをすごい抽象クラスっぽく使えて、クラスを分けられて見やすくできるので好きですね。

ちょまど：

私自身は、多重継承はあまりしたくない派なんですけど、プロダクト開発にあたって、それはめちゃくちゃ便利なのですね。

参加者Ｋ：

僕は「便利だな」というよりも「好きだな」と思っていまして、バシバシ使っています。

ちょまど：

良いと思う。昔、アプリ開発をしたときに、多重継承でカオスになってしまいました。そのとき、多重継承を使いこなせる人、クラス設計が上手い人はセンスが良いと感じたのを思い出しました。

参加者Ｋ：

僕も Class Delegation でいい感じになるまで、たくさんのゴミを作ってきました……。

一同：

（笑）

ちょまど：

もともと Java で Android アプリを書いていて、入社した会社の先輩の影響で Kotlin に引きこまれ、その後、“信者”になった理由や Java との比較をぜひ聞きたいです。

参加者Ｋ：

Java が嫌いということはないです。型安全で書けますし。ただ、やはり、インターフェースの実装だとか継承だとかのところで冗長の書き方をしなければならないことが多いです。Kotlin は、インターフェースの名前、中括弧、ファンクションを何か書いて 1 行で済ませられるんですよ。

参加者Ｓ：

（大きく頷く）

ちょまど：

すごいスマートですね。

参加者Ｋ：

型安全を維持しつつ、実用的に短く、細かく、綺麗に簡潔に書けることがもうめちゃめちゃ好きですね。そこを触ってもう 5 ～ 6 年ぐらい経っているけど未だにちゃんと貫き通しているので、そのわかりやすさが良いですね。

参加者Ｓ：

型安全というと型を使ったプログラミング、ジェネリクス（Generics／総称型）とか含めて良い感じなのですか？

参加者Ｋ：

そもそもジェネリクスを使いこなすのが大変っていうのはあるのですが、そんなに困ったことはないかな。逆に Web のフロントやって TypeScript とか触ったりすることがあるのですが、そこは Kotlin というか、Java の型システムが僕は好きという感じです。

ちょまど：

ありがとうございます。

2015 年頃からストリーム処理は劇的に進化した

ちょまど：

つづいて、ストリーム処理「推し」のお話をお願いします。

参加者Ｓ：

ストリーム処理とは何かっていう話からはじめて、何でそれが「推し」なのかみたいな話をしたいと思います。ちょまどさんはバックエンドのデータ処理とか、あるいはバックエンドアプリとかでデータベースを触ることってありますか？

参加者Ｋ：

あります。

ちょまど：

ブラックボックス化された API だけ触っているような感じで、あまりその辺の理解はしていないです。

参加者Ｓ：

では、データベースから話していくことにします。

ここに数に限りがあるデータがあります。この左側のカラフルな点をデータとすると、これがディスクかどこかに格納されていて、扱うデータの数は決まっている状況です。中央の矢印、ここでは MapReduce（マップリデュース）と書いてありますが、要は何かの処理をして図の右側のようにデータを綺麗にします。こういうのはデータベースとか Hadoop（ハドゥープ）とか Google MapReduce 等がやる典型的な処理です。決まった対象のデータを何かドカンとするのが、有限な個数のデータに対してする処理であって、データベースとか、そういう分散システムが得意としていることです。

これは、データの数が定まりきっていなくて、もしかしたら、100 年先にもデータが流れてくるかもしれない世界において、どうデータ処理をするかという話がはじめっていることを示しています。時系列に沿ってデータが流れていく図です。左側の方は時刻が遅くて未来に来るデータで、やってきたデータを 12 時頃に「黄色い網」でフィルタリング処理するみたいなイメージの図です。

フィルタリングだったら、別にデータが何個これから来ようと来たデータ、来たデータ 1 個ずつフィルタリングしてやれば処理できます。これは無限のデータ列に対してやるストリーム処理の中でとても簡単な方法で何も考えずにできるものです。

ただ、これを考えると、計算によっては実は難しいことを要求されます。例えば、やってきた赤いデータを数字として、10 分間ごとに赤の平均値を計算していきたいとします。10 分に 1 回、赤の平均値が出てくるような計算をすることが実ユースケースでもあり、これは例えば Web 広告のクリックレートなどを 10 分ごとに速報値を出すといったケースを考えたとき、ストリーム＝無限のデータ列に対して、何か一定時間を区切って計算するっていうことをやらないといけないわけですね。

ちょまど：

なるほど。

参加者Ｓ：

その場合、こういったストリーム処理に味付けをする必要があります。こういった、10 分に 1 回みたいなことをやる道具としてウインドウ（Windowing）といったものがあります。いろいろな物がありますが、Fixed Windowing が一番簡単で、例えば 1 番が 12 時 00 分から 12 時 10 分まで、2 番が 12 時 10 分から 12 時 20 分までみたいな感じで時間の幅を区切って、その幅のウインドウの中で集まったデータをバウンディットデータとして計算すると、データベース時代のバッチ処理の考え方をウインドウによってまた取り戻すことができて、いろいろできる……というのがストリーム処理のはじまりでした。

ストリーム処理が使われ始めたのが、2010 年から 2014 年あたりとかになるともう日本の会社もリアルタイムの分析をするために使い始めていました。ただ、2014 年までのストリーム処理は理論的にはわりと無茶をしていたんですよ。

ちょまど：

どうしてですか？

参加者Ｓ：

さきほど、10 分に 1 回、データを集めると話しましたが、遅れてやってきたデータをどうするのか、といった話があって。

参加者Ｋ：

あ！　なるほど。

参加者Ｓ：

例えば、ソーシャルゲームのデータですね。当時、地下鉄のモバイル網はまだ穴がありましたから、ふつうに 5 分間通信ができなくて、5 分後になって、5 分前のデータがやっとストリーム処理系に入ってくるってことがザラにあったわけですよ。あの時代は「もう遅れたからしょうがない」で無視するか、あとは後ろのウインドウに処理を任せていました。出てくる計算値は近似値でしかなく、言い方は悪いですが、ある意味、嘘のデータだったわけです。

ちょまど、参加者Ｋ：

（頷く）

参加者Ｓ：

それを克服したのが、2015 年、2016 年あたりに、データ自体にタイムスタンプを持たせて、計算はストリーム処理系にやってきた時刻ではなく、データの持っているタイムスタンプをベースに計算をする動きが出てきました。

例えば、データが持っているタイムスタンプが 13 時なのに、何かの都合で遅れて 14 時に到着したときに、古いデータを捨てるか、捨てずに遅れたデータとしてちゃんと計算に加味してやるかとかは、ストリーム処理をするユーザーに決めさせよう、それを決めさせるための API みたいなのを用意しようという流れがどんどん出ていたのが 2015 年から 2019 年ぐらいまでの話です。

ちょまど：

ここまでの私の理解では、今まではストリーム処理として、リアルタイムに来たデータをなんとかやりくりしていたのが、ブレイクスルーとしてタイムスタンプを持たせて、それを見て上手く修理をするという流れになりましたってことですか？

参加者Ｓ：

正解です。データの方のタイムスタンプを見つつ、遅れてきたデータをどう扱うかっていうことを決めるために、実はまだ話してなかったいろんな工夫がなされています。今、開いた本が、元 Google の Akidau さんが書いた『Streaming Systems』と言う本です。

データベースはかなり多くの教科書や実践的な入門書がありますが、ストリーム処理は教科書的なもので良い本がない中、これは結構ちゃんとしている本なんですよ。だから何かストリーム処理系の研究者と対等に話す際にも、これ 1 冊を読んでおけば何かある程度話ができるようになるっていうある種お得な状況です。Kotlin1.0 の時代に似ているかもしれません。

これまでで、組み込みのデータベースはもう成熟していますが、これから組み込みのストリーム処理系が来ると思っています。そういう時代になると、本当にどんどん流れて発生してくるストリームのセンサーデータを処理しないと良いアプリが開発できないっていう時代になって、それには新しい処理系が必要になる筈です。それで開発用のライブラリを作っています。予言するけど、これは流行りますよ（笑）

参加者Ｋ：

ラズパイ（Raspberry Pi）上で推論までやり、結果を出すみたいなデモを Google がやっていますが、そこのデータ分析に使われる可能性がありますね。

参加者Ｓ：

推論結果がどんどん流れてきますから、その結果を使って何か行動に移すのはまさにストリーム処理なわけです。

参加者Ｋ：

たしかにアツいと思いました。

ちょまど：

良いですね。私、エンドユーザーが使うアプリを作る人もすごいなと思うのですが、開発用ライブラリを作る人って熱いなと思います。センスがいい人が作ったライブラリって私たちも使っていて気持ちいいですよね。

参加者Ｓ：

ディベロッパーとしては同感です。ディベロッパーの気持ちはわかります。ただ、コンシュマーの気持ちがわかりません。

ちょまど、参加者Ｋ：

（笑）

ちょまど：

あっという間に、残り時間が 1 分を切りました。今日はありがとう。すごく楽しかったです。

参加者Ｋ：

こちらこそ。

参加者Ｓ：

楽しかったです。

トークテーマ「インターネット老人会」

応募者の中から選ばれた 3 人が参加し、懐かしい技術、ゲームなどについて 4 人で Dev トークを行いました。

パソコンのデータをカセットテープで読みこんでいた時代

ちょまど：

今日は貴重な時間をいただいてありがとうございます。はじめに、自己紹介をしていただけたらうれしいです。

参加者Ａ：

データ活用、AI、クラウドに興味を持っています。現在は、AWS の学習コミュニティに参加して、和気あいあいと楽しくやっています。今日は「インターネット老人会」ということなので昔の話をすると、私が中学生の頃はネットワークがなく、NEC の「PC-6001mk2」を使っていました。データをカセットテープで読みこんでいました。

ちょまど：

カセットテープで？　うわぁ。

参加者Ａ：

ゲームをするのに、ゲームをする時間よりテープを「ピーガー（データ音の真似）」と読みこんでいる時間の方が長いくらいでしたね。

参加者Ｐ：

懐かしい、それ。

ちょまど：

私、聞いたことないです。

参加者Ａ：

大学院生のときは『Netscape Navigator』が全盛時代でした。

ちょまど：

私も『Netscape Navigator』は使っていましたよ。その頃だと思いますが、Windows95 を買い求める人々の行列を写真で見たことあります。

参加者Ｐ：

私はエンジニアをやっています。使っている言語は主に C#と JavaScript です。趣味では Python、あと最近 Unity の C#に手を出しました。VRChat のせいです。

ちょまど：

今、Unity の C#と.net 最新版の C#は違いがありますね。

参加者Ｐ：

昔の話をすると、初めての Windows が「3.1」です。そこからいろいろやって Linux に手を出しました。Windows のマシンに Linux をインストールしては、全消しして Windows に戻すのをよくやっていました。

ちょまど：

Windows の上に VM を立てるのではなくて、全て消すのですね。

参加者Ｐ：

当時、VM なかったので全消しでしたね。大学から大学院時代は「2 ちゃんねる」全盛期で、そこから Flash にハマって、ニコニコ動画に流れ、オンラインゲームでという感じです。よろしくお願いします。

ファミコンの名作 RPG の容量は「40KB」。制約があった方が良い？

参加者Ｆ：

私は今、SIer で働いています。Qiita には今までいろいろ投稿してきました。老人会的な話をすると、私は『ファミコン』がすごく好きでした。そして、当時のファミコンの容量はすごくて「ドラゴンクエスト」の容量は 40KB でした。最近のログファイルより絶対軽いと思います。

参加者Ａ：

40KB か、すごいな。

ちょまど：

ヤバ……。

参加者Ｆ：

そんな中でみんなモノを作っていたんだというところに想いを馳せています。

ちょまど：

私が思っていた“インターネット老人”は、ジオシティーズで Web サイトを作ったり、「キリ番」文化を楽しんだりするイメージでした。私がはじめてパソコンをゲットしたのが 2010 年なんですよ、大学入学祝いで。それで Web サイトを作り始めたのがきっかけでもう一気にのめり込んでしまいました。

最近は「あの頃は良かった」みたいな“懐古厨”がヤバくて……。すごく限られたリソースの中でいかにイノベーションを起こすか、みたいな。私はイラストサイトを作っていたのですが、回線が細かったので、どうやったら 5 秒以内にイラストなど全てのコンテンツを表示させることができるかを考えるのが楽しくて、つい懐かしんでしまったりしますね。今はそんなことを考えなくてもいいじゃないですか。

参加者Ａ：

制約があった方が面白いですね、意外と。

ちょまど：

さっきのファミコンの容量の話とかめっちゃ好きですね。

参加者Ｆ：

私も制約は大事だなと思っています。人類は制約がある方が新しい発見ができると思っています。

参加者Ａ：

8bit で、ものすごい音楽を作ったじゃないですか、ドラクエとか。あれ、かっこいいですよね。絵もドット絵であれだけのクオリティを出せたのはすごいですね。

パソコンやインターネット文化にハマったきっかけは

参加者Ｐ：

インターネット老人会は、ゼロ年代が一つの鍵なのかなと思いました。あの頃、私は「2 ちゃんねる」文化に浸かっていました。

ちょまど：

私、「2 ちゃんねる」は見ていませんでしたが、アスキーアートはすごく好きでした。「モナー」とか「ギコ猫」とか。Flash ムービーの「千葉滋賀佐賀」はよく見ていました。

参加者Ｐ：

2010 年頃になると、もう「ニコ動（ニコニコ動画）」になっていましたね。

ちょまど：

「ニコ動」は懐かしいです。

参加者Ｐ：

ネットミームにはいろいろ影響を受けてきた気がしています。

ちょまど：

みなさんが、パソコンやインターネット文化にハマったきっかけは何でしたか？　私は先ほども話しましたが、2010 年にパソコンを買ってもらったことでした。

参加者Ｆ：

私がコンピュータに関連する学科に進んだきっかけはやはりファミコンでした。将来、進路を何に決めようとなったときに「ファミコンを作る人になりたい」と思って理系になって、そのまま進んだ流れでやっています。

ちょまど：

作る側に行きたいというのがエンジニアだなって思いました。

参加者Ａ：

私は光栄（現・コーエーテクモゲームス）のゲーム『三國志』ですね。

参加者Ｐ：

わかる！

参加者Ａ：

でしょ（笑顔）『三國志』や『信長の野望』がなかったら、今がないので、全ての運命のはじまりでした。

参加者Ｆ：

私もゲームですね。その後、パソコンをやっているうちにインターネットにハマっていった感じですね。当時は、インターネット回線は「テレホーダイ」の時間帯しか自由に使えなかったので、制約は多かったですが。

ちょまど：

今や、我々は Wi-Fi の飛んでいないところは、水槽から水を抜かれた魚のような状態になるじゃないですか。昔は大変だったのだなと思いました。あと 1 分になってしまいました。みなさん、忙しい中、貴重な時間をありがとうございました。今後もよろしくお願いします。

おわりに

Dev トークはエンジニア同士で気軽に相談や情報交換などができる場です。

特徴 ・これまで出会わなかった人とも出会い、気軽につながるきっかけになる ・同期的なコミュニケーションで 知識共有や課題解決が可能 ・エンジニアにとって興味関心の高いテーマが多い

Qiita Jobs では様々なトークテーマで募集されているので、気になるテーマを見つけ、ぜひ気軽に参加してみてはいかがでしょうか？