Conference | Democratizing Data

機械学習工学研究会夏合宿2022でMLインフラ運用WGを終了しました

Fri, 15 Jul 2022 15:16:04 -0700

2019年から土橋さん (@masaru_dobashi) と共同幹事をしていた、機械学習工学研究会 (MLSE) の「本番適用のためのインフラと運用WG」を、6月30日～7月2日に開催したMLSE夏合宿で終了しました。

2022年MLSE夏合宿での議論

今回の夏合宿では、過去開催してきた討論会やカンファレンスで上がっていた、本番適用をするための課題をリストアップし、現在も課題となっている部分を中心に議論をしました。

議論に使ったMuralはGitHubにexportしてあります。

https://github.com/mlse-jssst/InfraOpWGProceedings/blob/master/20220702_SummerCamp/MLSE_InfraOPWG_SummerCamp_Output.pdf

黄色以外の色のものは当日追加したトピック、左下の赤で囲まれた部分はさらにそのまとめになります。

活動をまとめていて気づいてきたのは、多くのMLOpsツールを提供するベンチャーやクラウドベンダーによって、自動化をするためのOSSやマネージドサービスはそろってきているものの、組織やプロジェクトのフェーズごとに必要なものが違ってくるということでした。

フェーズによるML基盤の変遷としては、Karteの基盤の変遷の話を思い出しました。

少人数でのML基盤としてはCADDiのマネージドな環境を駆使した基盤も参考になると思います。

また、組織やチーム作り自体が大きな障壁になりうる話も頻繁に聞いており、これは研究者的なモデル開発をする人と運用をするdeveloperをチームとしてどう構成すればいいのか、どうやってナレッジや成果物を共有すればいいのか（研究開発部門が子会社など）、チーム作りの課題が浮き彫りになりました。

あとは、機械学習やデータを活用したプロダクトづくりの文化の醸成も、銀の弾丸がない中で各社試行錯誤していることがうかがえました。これは、プロジェクトのKPI設計をビジネスサイドに理解してもらう難しさや、作り切りでOKだった従来型のソフトウェア製品とは違った変化に対応し続ける必要がある機械学習システムの「運用」の理解を得る難しさが課題に挙げられました。

振り返ってみて

企業の事業部門に在籍しながら3年というスパンで学会仕事をするのは、なかなか大変だったなというのを改めて実感しました。COVID-19による社会情勢の変化、海外移住（夏合宿のような長時間イベントは時差的に厳しい）など個人の状況の変化、会社のチームの異動（上司が変わるたびに説得をする必要がある）と、長期的に継続する社外活動というのは思うようには進まないものだなという当たり前のことを感じました。

もう一回程度、事例共有カンファレンスがしたかったですが、最近ではMLOps勉強会でそういった話が日本語でも展開されているので、そちらにも期待です。

今後について

今後は、（我々も事前にすり合わせたわけではないのですが）ちょうど杉山さんをはじめとする皆さんがこの夏合宿から開始した、機械学習オペレーションWGに引き継がれていきます。今後の活動が楽しみです。

過去の活動の様子

機械学習工学研究会の「機械学習基盤本番適用と運用の事例・知見共有会」を開催しました

Tue, 10 Nov 2020 22:18:19 +0900

@masaru_dobashiさん共同で、機械学習工学研究会（MLSE）本番適用のためのインフラと運用WG主催の、「機械学習基盤本番適用と運用の事例・知見共有会」をオンライン開催しました。

イベントのconnpassは以下のリンクです。機械学習基盤本番適用と運用の事例・知見共有会

@wakame1367さんによるツイートのまとめはこちらです。機械学習基盤本番適用と運用の事例・知見共有会ツイートまとめ

YouTubeの動画

YouTube Liveの配信はアーカイブとして見ることができます。

当日の資料

感想

今回、僕は企画とCfP系のとりまとめ、当日は配信担当をさせていただきました。当日の司会進行は土橋さんにおまかせをしてしまったのですが、いつもながら質疑応答の仕切り力は素晴らしい限りだなと思いながら聞いていました。

今回のトピックは、機械学習チームが解散したという衝撃的な話からはじまり、NLPを中心とした機械学習基盤、リアルタイム予測基盤、モバイルやエッジ向けの機械学習など多岐にわたる発表が充実していました。個人的に特に思ったことは、一言に機械学習基盤といっても組織や規模、フェーズに応じたアーキテクチャが採用されているというように感じました。これはMobility Technologies大西さんの発表で、Kubeflow Pipelinesを選んだ理由に「ブラウザベースでパラメータを入力できること」ということがありました。

「テストごとにパラメータを入力する必要があったが、AirflowはそういうWeb UIがない。Kubeflow Pipelinesはそれができる」これは、ソフトウェアエンジニア以外の参加者がいるからですね #MLSE
— Aki Ariga (@chezou) November 6, 2020

当たり前ではありますが、システムの要件は組織の体制やビジネス要件に規定され、それが機械学習基盤でも変わらないということが改めて実感できました。

今後も、MLSE 本番適用のためのインフラと運用WGではこうした機械学習基盤のアーキテクチャやパターンを明確にするために、討論会などの活動を続けて行きたいと思います。

機械学習工学研究会（MLSE）の夏合宿 2020で本番適用のためのインフラと運用に関する討論会を開催しました

Sat, 11 Jul 2020 18:00:00 +0900

@masaru_dobashiさんとMLSEの夏合宿で、本番適用のためのインフラと運用WGの討論会を開催しました。 WGのモチベーションはMLSEのサイトをご確認ください。

MLSEの夏合宿自体の概要は、@ysk_motoさんがまとめてくださった記事がわかりやすいと思います。Discordを中心に130名を超える参加者がオンラインで様々な議論をするというスタイルでした。

機械学習工学研究会（MLSE）夏合宿　2020に参加しました

実は我々のWGの討論会自体は第一回はオフラインで開催しました。そちらのまとめはGitHubにあります。よければ御覧ください。

今回の討論会のまとめは、以下の2つのトピックについて議論をしました。

機械学習における監視・観測とアーキテクチャ例
責任分解とシステム

もう少ししたらGitHubのレポジトリにまとめを上げる予定ですが、その中から興味深かった話題を紹介したいと思います。

COVID-19の影響は予測モデルを更新し続けることである程度抑制できた

これは、PFNの丸山さんが話題に出してくれたのですが、deeplearning.aiのnewsであるThe Batchやこの記事でも言及されていた、「COVID-19によって人間の行動が変わってしまって予測に対する影響は出なかったのか？」という問いが投げかけられました。その中で、ある広告系の企業の参加者が、「入力データもモデルも毎日更新しているので、現状は対応できていると考えている。毎日モデルを更新するのが大切」という知見を共有してくれました。

もちろん、劇的に前提条件が変化をする問題ではなかなかそのままのロジックや特徴量が使えないということもありうるとは思いますが、モデルを継続的に学習しつづけることで、変化に追従するというのは長期間機械学習システムを運用していく上でなくてはならないのだと改めて思いました。

学習したモデルは、組織のありかたで渡し方はおろか渡せるものも変わる

予測モデルを誰が学習するのか、という話題のなかで、小さなチームでは学習も予測も一人でやるという状況が出たのに対して、日本の大企業では特に研究開発の会計的な事情で、研究所で学習したモデルや学習をするためのコードを渡せず仕様書のようなドキュメントで開発部門に渡すしかない、という話が出ました。言われてみればそういうケースもありうるのかと思いつつ、部門の切れ目でAPIを用意するという立て付けも取れるかもしれませんが、研究所で学習や予測APIを提供するといった体力があるところも限られてくるとは思うので、日本の会計や税務的に難しさが発生するのかと、ハッとした瞬間でした。

モデルのリネージは決めてとなるOSSがない

これは討論会で出た話では有りませんが、実験管理は徐々にOSSで出てきているが、モデルの作成に至るまでのリネージはOSSとしては決定版がないよね、という話が何度か出てきました。もうシャットダウンしてしまったDotscienceではこうしたリネージを可視化する機能を持っていましたが、まだOSSでは良いものは私の知る限りではないように思います。こうしたこともあり、サイバーエージェントではモデルのリネージを管理するためのツールを内製で開発しているそうです。OSSとしてカバーするのは難しいかもしれませんが、各社が自社のサービスの上でのソリューションを提供してくるかもしれません。

夏合宿全体を通じた感想

Discordを通じた議論や発表はとても体験としてよかったと思います。特に、人工知能学会のポスターで苦痛だったExcelで書かれPDFで出力されたパスワード付きZoomのリンクをクリックして移動するという地獄の体験をしたあとでは、Go Liveでどういう発表をしているのかもプレビューで覗けますし、軽量な音声だけで議論も進むので活発な議論ができていたのではないかと思います。

ただ、会社のポリシーでP2Pのプロトコルを使っているDiscordのアプリは使えず、会社のMBPでは非力だったためか画面共有の表示が安定してされなかったのは難しいところではありました。GPUマシンでは安定しているので、MBPでは少し厳しいですね。

我々の討論会ではZoomを使って議論をしたのですが、Muralと呼ばれるMiroのようなオンラインホワイトボードも使っていたので、複数のグループに分かれて付箋を貼っていくスタイルでも良かったかもしれません。

ただ、ご多分に漏れずDiscordの参加人数が10人を超えてくると、議論が一本にしかならない関係もあり並列して話をするのは難しい印象でした。

最後に

9月頃にWGとして、各社で携わった機械学習基盤の知見共有をするためのオンラインカンファレンスを実施予定です。もう少ししたら、公募を開始しようと思いますので、機械学習システムを構築している話や、構築しようとしたけどうまく行かないといった話をシングルトラックのセッションとして発表していただければと思います。

IBIS 2019の機械学習工学企画セッションに登壇しました

Thu, 05 Dec 2019 00:24:00 +0900

この記事は、機械学習工学アドベントカレンダー2019の5日目です。

こんにちは、chezouです。先日、PFNの比戸さんにお声がけいただきIBIS 2019という日本で最大の理論系機械学習のワークショップで、3日目の「機械学習工学」の企画セッションに「継続的改善をし続けるための機械学習基盤の課題」というタイトルで発表しました。理論系のワークショップというのは知っておりアウェイ感半端なく、数式もないという煽りも受けましたが、なんとか実務者の皆様に届いてくれたのではないかと思っています。

Challenges for Machine Learning Systems toward Continuous Improvement

Machine Learning in productionに対する9つの課題は、世の中にまだまだ整理されているものではなく難産だったので色々と議論ができればと思っています。9つの課題とdotscienceのLuke Marsden氏によるReproducible, Accountable, Collaborative, Continuousという4つのマニフェストの話を元に整理してみたのですが、どのような課題と抽象化を行っているのか、そしてそれがどういう嬉しさがあるのかへの理解の一助となればと思います。

Concept drift?

「学習時と予測時の分布の違いを検出するデータバリデーションが大事」という話をしました。で、この「学習時と予測時の分布の違い」というのを"Concept drift"という表現を使って説明をしたのですが、 shima__shima先生からもご指摘をいただき、どうも違うのではないかということで色々と調べたり議論をしていました。Concept driftは英語圏では雑にこのニュアンスを表現するのに使われており、特に産業界ではそれでいいかなという表現であるという認識です。ただ、もともとはストリームデータに対するdriftという定義があるようです。

人によっては"Covariate shift"(共変量シフト)や"Domain shift"という表現をするということから、Covariate Shiftがいいのかなと思っていましたが、“Delayed effect"という表現が時間的な変化に対する表現としてよいようです。ただ、個人的にはスライドでも書いたように光の変化は時間変化というよりは仮定する前提条件が覆された例だと思っているため、Delayed effectも少し狭いかなと思っていました。

なお、GoogleはTensorFlow Extendedの論文中で"training-serving skew"という表現を使っています。

以下、shima__shima先生の説明が参考になるかと思います。

共変量シフトは統計系の文脈ででてきて抽象的に分布が違うといった意味合いで最初に出てきました．
転移学習は機械学習分野で類似したデータという感じででてきました．2000年中頃はいろいろ呼び名がありましたが今では転移学習に落ち着いていると思います． https://t.co/4n1NXdWPAE
— しましま (@shima__shima) December 3, 2019

同じころ，コーパスの分野の違いというあたりから，Hal Daumé さんあたりがNLP分野でドメイン適応という言葉を使い始められました．
時間による変化で起きるならdelayed effect という言葉もあります．https://t.co/qVmBdO2fz3
— しましま (@shima__shima) December 3, 2019

機械学習工学セッションの他の発表

他の発表は、NIIの石川先生による機械学習工学とテストの話 (スライド)、STORIA法律事務所の柿沼先生の機械学習と知財の話(スライド)でした。

石川先生の機械学習を工学として捉え直したときの説明や、adversarial testなどテストの最近の状況は自分自身追いかけられていなかったのでとても良かったです。

柿沼先生はAI模擬裁判などでご存知の方も多いと思いますが、先生の知財の話は学習済みモデル含めたシステムの権利は受託したベンダーか発注者のどちらにあるのか、という話も面白く、実践的で知見に富んだ話でした。ぜひML関係者はスライドを読むと良いと思います。また、柿沼先生への比戸さんの質疑から派生した議論をメールでさせていただいたのですが、機会があったら公開したいと思っています。

機械学習工学研究会キックオフシンポジウムに登壇しました

Thu, 17 May 2018 14:03:57 +0900

タイトル通り日本ソフトウェア科学会の研究会、機械学習工学研究会キックオフシンポジウムに登壇しました。@bonotake さんから声をかけられた時はカジュアルに受けたのですが、蓋を開けてみれば大御所の方々ばかりで恐縮しながらの発表でした。

僕の発表内容としては、書籍「仕事ではじめる機械学習」の話からデプロイパターンの話と、機械学習特有の難しさはどこから来るのかという話をしました。

仕事ではじめる機械学習
_Amazonで有賀康顕, 中山心太, 西林孝の仕事ではじめる機械学習。アマゾンならポイント還元本が多数。有賀康顕, 中山心太, 西林…_amzn.to

時間が20分だというのに資料を一通り作った後に気づいて、かなり表層的にさらっとしか話をしませんでしたが、詳しい方からすると当たり前の話しかできませんでした。

話しきれなかったこと

お気づきの方は、参考文献等を見てわかるかと思いますが、機械学習特有の難しさという話は、主に以下の3つからピックアップしてきた話になります。

Hidden Technical Debt in Machine Learning Systems
_Eletronic Proceedings of Neural Information Processing Systems_papers.nips.cc

TFX: A TensorFlow-Based Production-Scale Machine Learning Platform - Google AI
_We present TensorFlow Extended (TFX), a TensorFlow-based general-purpose machine learning platform implemented at…_ai.google

My model has higher BLEU, can I ship it?
My model has higher BLEU, can I ship it?www.lucypark.kr

個人的には、どれも語り尽くされた感があるところはあったのですが、特にTFXの論文がプラットフォームの話だけではなく、典型的な機械学習の問題をどのようにシステムとして回避しているかという話が詰まっていて良かったので改めて補足したいと思います。。

例えば、「入力データのスキーマを作ってチェックする」という話が書いてあるのですが、ここでいうスキーマとは、カテゴリ値の種類を列挙したり、期待される統計値の幅を予め記述しておくというJSONSchema的なspecに近いものです。特に学習時のデータの分布と予測時の分布が極端に異なるということは往々にしてあるのですが、それをデータのスキーマでvalidationすることでアラートを上げてコントロールするというのは目からうろこでした。

また、予測結果を他部門の人が使うエピソードがあるのですが、その中で「締切に追われるエンジニアは、サクッと使えるものは使ってしまうものである」みたいなことが書いてあって、ですよねーと一人頷いていました。

3つ目のLucy Parkさんの発表資料は、Joel test for better Machine learning systemsというサブタイトルの通り、何をクリアすればいいかできていないとまずいかという11の質問項目を提案しています。

Do you keep your data versioned as well as your code?

Do you have an experiment database?

Do you have specified evaluation metrics?

Do the evaluation datasets match the needs of your users?

Can you reproduce your experiments in one step?

Do you have up-to-date documents?

Do you have the best computational resources money can buy?

Do you have tools to test model training?

Do you have tools to interpret your models?

Can you easily replace a component of your algorithm?

Does your team have a clear vision?

詳細はスライドを見ていただければと思うが、この中でデータのバージョン管理をしてる？という話が出ていたが、これはまだベストプラクティスがないよねという話がスライドでもされています。

少量データであれば、なんとでもなるのだが規模が大きくなってきて、かつ変更が入るようなデータをどう保持するのかというのは、自分でも気になって社内で議論したことがあるのですが、いわゆるDWHに入っているようなデータは、BiTemporal modeling (日本語だとこちらの記事がわかりやすい)という方法を使えば逐一スナップショットをとるのではなく、変更を管理できるという方法を教えてもらいました。

一方で、DVCのようにgit likeにデータのバージョンを管理する方法というのも提案されていて、バイナリのデータはこちらのほうが良さそうだと思っています。

機械学習の予測では、一度異常が起きた時の原因究明が難しく、問題の切り分けのためにソースコードを遡るだけでなく、学習データ自身やモデル自身を遡る必要があるためここの話は非常に実用上重要になってくると思います。

あとは、バージョン管理をするのと同時に、依存関係を記述するモデルのリネージが重要になってくるだろう話もしました。モデルのリネージの話はまだこれといったツールがあるわけではないのですが、予測結果を利用してさらに別のプロダクトを作るというケースがあるように、何がどの結果をつかっているのかというのを可視化できるツールというのが、今後機械学習に依存したプロダクトが増えるに連れて重要度を増すでしょう。

機械学習システムにどういう立場で関わるか？

パネルディスカッションなどを通じて感じていたのは、機械学習システムを作る人が誰でどう関わるのかというのが人によって大きく異なるというのを改めて感じました。

いわゆるコンサルやSIとして係る場合、発注者と受注者の関係が発生します。この場合、要件定義を先にして…のようにウォーターフォールで客が作りたがるという話が出ていましたし、ソフトウェア工学的にもそうした立場に立った意見が目立ったのかなと思います。

そこに関しては、発注者自身が受け入れ要件を理解して定義できないといけないよね、などという話も出ましたが、幸いにして日本語だと機械学習システムのプロジェクトの進め方関連の書籍が拙著以外にも出ているので、そういった立場の方々はぜひ一度読むとよいのではないでしょうか。

人工知能システムを外注する前に読む本~~ディープラーニングビジネスのすべて~~
_Amazonで坂本俊之の人工知能システムを外注する前に読む本~~ディープラーニングビジネスのすべて~~。アマゾンならポイント還元本が多数。坂本…_amzn.to

人工知能システムのプロジェクトがわかる本企画・開発から運用・保守まで (AI & TECHNOLOGY)
_Amazonで本橋洋介の人工知能システムのプロジェクトがわかる本企画・開発から運用・保守まで (AI & TECHNOLOGY)。アマゾンならポイント還元本が多数。本橋…_amzn.to

個人的には、データドリブンなプロダクトを作るという観点では、ドメイン知識を持っている人が一番強いと思っており、最初はがっつり機械学習のシステム構築を支援するけれど、段々と発注側の人を育てる方向にシフトをしていき、最終的には内製化できるのが理想的ではないかと考えています。

機械学習が詳しい人の強みとしては、「どういう問題の切り出し方をしたら、機械学習で解けるか」というところだと思っています。この問題定義は、なかなか場数を踏まないとできるようになるのは難しく、そこをお手伝いすることが僕自身も多いです。それ以外のどう手を動かすかといった知見を少しずつトランスファーしていくのが、継続的に改善を必要とする機械学習システムでは良い形なのではないかと思います。

思った以上にCI,CDの話が出てこなくて、「ん？」と思っていたのですが、改善をし続けるという話が自社内でやれるかどうかでスピード感も変わってくるのかなという観点を得ることができました。

最後になりますが、司会の丸山先生や登壇者の皆様、500人規模の大規模な運営をしていただいたスタッフの皆様ありがとうございます。交流会でも非常に濃密な議論が出来てとても楽しかったです。

PyConJP 2017に参加した

Sat, 09 Sep 2017 12:24:23 +0900

2年ぶりにPyConJPに参加しました。2日間参加してきたので、メモがてら書いていきます。

興味深かった話

pandasとdaskのコミッターのshinhrksさんの基調講演。pandasに対してどうコントリビュートしているかという話を中心に、OSS活動をしていこうと思わせる（1日目とは打って変わって）良い基調講演でした。

特に印象的だったのが、pandasの中ではAirspeed Velocityを使ってCIでベンチマークを取りコミット間の処理速度が低下していないかを検出しているという点です。Pythonのパッケージなので、他の言語では難しいかもしれないということです。ともすると速度のデグレは気づきにくいことも多いですが、OSSでそこまできっちり見ているのは素晴らしいと思いました。

なお、pandasやビジュアライズに入門するには昨日でたJupyter本が良いです。

PythonユーザのためのJupyter\[実践\]入門
_Amazonで池内孝啓, 片柳薫子, 岩尾エマはるか, @drillerのPythonユーザのためのJupyter\[実践\]入門。アマゾンならポイント還元本が多数。池内孝啓, 片柳薫子, 岩尾エマはるか,…_amzn.to

リクルートテクノロジーズのyuzutas0さんによる分析基盤とカルチャーを作っていく話。どの話も、あーあーあるあるという感じで会場も共感の嵐でした。結局、現場のユーザが使うためには、独りよがりな基盤を作っても使われなければ無いから、コミュニケーションを取っていって必要なものを作っていこう、という泥臭さしかない話でした。こうしてデータドリブンで仮説を作っていく話はとても良いと思います。

Cookpadのayemos_yさんの発表。自分が課題感感じているところかなと思ったら少し違った話でした。通常、ソースコードはgitなどでバージョン管理をするのに対して、モデルは比較的バージョン管理をしやすいけど、入力データのスナップショットをとることが難しいので、repeatabilityを確保するのは難しいよなと思っていたのですがその問題提起の話でした。

モバイルやセンサーからくるデータは遅延して到達したり、後で更新したりするみたいな時があったときや、データの欠損があったりしたときに、そのまましれっとモデルの更新をすると、データが原因なのかモデルがダメなのか何がダメなのかがぱっと切り分けられなくて、モデルの更新をしにくくなるという状況なのは辛いなという認識です。例えるならば、バージョン管理もテストもない状態でコード変更をして神に祈ってデプロイするイメージに近いです。（ゴールデンスタンダード使ったりなにか悪くなってることは検出できますが…）

解決方法はまだまだ発展途上だなというか、PySparkでETLしてS3上にHive形式のテーブル作ってそれをImpalaでもPrestoでも叩けばええやんという気持ちでいっぱいだったのですが、問題自体は重要な話であり、Googleなんかはどうにかしてクリアしているポイントのようなので、僕自身もなんとかしたいと思っている場所だったりします。良い解決方法考えていきたいところです。

もう一件、テキスト処理をPythonでやる話がありました。話の殆どは知ってる話だったのですが、spaCyが日本語対応したらしいよという話を聞いて、実はjanomeがTokenizerに使われているのをしりました。

なお、RからもspacyRというwrapperを使えるようでopenNLPとrJavaに疲弊している人は使うと良いようです。

感想

PyConはあまり知り合いも少なく、アウェイ感があるのですが、なんか地味に知り合いが増えてきたこともあり色々と話しをできてよかったなと思います。

実は一番印象に残ったのは、shimizukawaさんやtakuan_oshoさんなどインターネッツの中でしか見たことがない方とお会い出来たりお話できたことでした。また、色々とお話をしていると「ああ、aodagさんの文章を翻訳した人ですね」と言われて、地道な活動をしてきてよかったなと思います（虎の威を借る何とやらとも言う）

また、英語セッションで質問をしたら、何故か英語圏の人に囲まれて日本語のテキスト処理とコーパスが辛いんだけど、とか言う話を議論できたのは良かったです。

一方で発表は、今回初日のキーノートがただの会社の紹介に終止したマーケティングで終わったり、海外勢のデータ系がやってみた系が多かったりと結構辛かった一方で、日本人の発表者は非常に濃い良い発表が多く良かったなぁと思いました。特にcondaとwheelのfragmentationについてはなんとかならんかなと思って質問しましたが、お茶を濁されたのが悲しかったです。

ただ、自腹で1万円払って来年も行くかというとプログラム編成がデータ系が横に並んで厳しかったり、発表のクオリティの分散が激しかったりと悩ましいなぁというところです。自分はデータ系しかほぼ見てないのですが、2年前に参加したときはjanomeの話とか濃い話がありそう思わなかったのですが、RubyKaigiの方が講演のクオリティの平均が高い（ハズレを引きにくい）のかなと思いました。aodagさんのパッケージングの話とか（資料しか見てないけど）昔からの人の発表は安定感あったのですが…。

とはいえ、プログラム編成も投稿が山のようにきたりしている現状、SciPyあるいはScientific Programming, Data Analysis & MLみたいな言語を絞らないカンファレンスを日本でやって、それでガス抜きをしないとPyConには荷が重いだろうなぁと思います。イメージ的には、Polyconみたいな言語非依存なカンファレンスの科学計算版で、industrial trackとbeginner trackとresearch trackの3本立てでちょっと学会よりはゆるい感じの集まりかなぁ。

いずれにせよ、Pythonは今後もお世話になっていくので、PyCon JPの運営の皆さんに感謝しつつ燃え尽きないよう継続してって頂きたいなぁと思います。