【PyCon JP 2018】「野球エンジニア」が説く、エンジニアリングにおける“選球眼”の大切さ

Pythonistaの選球眼

中川伸一氏（以下、中川）：では、野球の話を始めます。今年は「Pythonistaの選球眼」というタイトルで、野球と技術のオールインワンの話をしたいと思います。すみません、今さらながら遅れましたが、PyCon JP 2018もとい、PyConスタジアムへようこそ（笑）。

今年も野球の時間がやってまいりました。ということで、1個だけ真面目な話を挟ませてください。去年までは趣味でやってたことなんですが、今年から野球が仕事になっちゃったので、けっこう重要な連絡事項です。

とくに1行目。プロアマ問わず、今日のセッションに関しては、日本の野球に関するご質問とご意見には、残念ながら一切お答えすることができません。それだけは、約束として思ってください。これ、けっこう笑いごとではないんです。僕の首が飛んじゃうので。

ただ、今日の話はメジャーリーグの話で、メジャーリーグの話については、よほど際どい質問でない限りはお答えします。あと、その他諸々はだいたいさっき言ったとおりなので、ご自由にお過ごしください。

突然の野球クイズ！

（会場拍手）

問題！　「今シーズン、2018年のメジャーリーグ、現時点のホームラン王と言えば？」わかる方！　いない。

会場：ジャンカルロ・スタントン！

中川：ブー！　答え、クリス・デービスさんです。ハイ、このリアクションも含めて、想定どおりでした。

（会場笑）

僕はアスレチックスというチームが好きなんですが、そこで今、アメリカンリーグとナショナルリーグを合わせてのホームランキングになっている、平たく言うと右投右打の4番DHが専門の走塁と守備が駄目な、ちょっと小さい大砲です。でも、当然知らないですよね。スタントンは確かにすぐ出てくるかもしれないですけど。ということで、このクリス・デービスさんがどんな選手かを、さっそくですがデモでお見せしたいと思います。

ホームランを打つ秘訣

これはそのまま今日見せるデモなんですが、大雑把に言うと、これが打球速度と飛距離です。

打球速度がだいたいマックスで180キロメートル以上、平均で140キロメートルぐらいです。スライドに戻ります。今日は投球や打球のデータをもとに、いろいろやるためのプラットフォームみたいなものを作ってきました。

見方その1。わかりますか？　これはホームベースで、1塁・2塁・3塁と起点にすると、このへんがたぶん内野です。

これはホームランと2塁打以上の長打だけをプロットしてるんですが、これを見ると、まんべんなく広角に打っているのと、あとはフライとライナーが半分以上のなかなかいい選手だということがわかります。

一方で、もう1つの見方。

打球速度と飛距離、速度×角度で見てみます。メジャーリーガーの場合、最近は打球速度が180キロメートルとかマックスで出るやつはホームランが出やすい、みたいな話をこれからするんですが、一番注目してほしいのは、みなさんから見て右手側のグラフです。

ホームラン多発ゾーンがあります。これは、実は科学的に証明されています。すごい速度といい感じの角度で、だいたい飛距離は伸びます。

（会場笑）

いや、でも実際そうなんです。このへんは「バレル・ゾーン」と片仮名でググってもらえると、『Baseballe Geeks』というメディアがございますので、その記事をご覧いただければと思います。

「速いフライを打て」というのがホームランを打つための秘訣でして、もうちょっとさっきのプロットをわかりやすくしてみます。

このオレンジ色がバレル・ゾーンなんですが、さっきのデービスさん。ごめんなさい、先ほどのグラフとカラーマップが変わってるので、ホームランが緑色なんですが、緑色がだいたいオレンジのところにかかっています。届かないところがツーベースみたいなことがわかります。

ということで、「ホームラン王のひみつ」。

打球速度をなるべく伸ばしましょう。だいたい160キロメートル以上。いい感じの角度に飛ばしましょう。ここには書いてないですが、だいたい22度から50度の間ぐらい。逆に上がりすぎると今度はフライになってしまうので、いい感じというのはそういう意味です。

あとは総じて、フライを打つ努力をするとそうなって、たぶん野球好きの人だったら聞いたことがあると思うんですが、「フライボール革命」という言葉、聞いたことありませんか？　「フライボール・レボリューション」とか。その秘密はこれです。

エンジニアにとっての“選球眼”

フライを打つためのボールの見極めと技術が大事ということで、ボールの見極め、つまり選球眼という技術は大事です。フライを打つ技術とセットで長打はたくさん生まれます。というのが、野球選手の場合。

僕らエンジニア・Pythonista、ここにいらっしゃるみなさんにも、実は選球眼は存在します。その選球眼を、これからあと残り25分ぐらいでお話ししたいと思います。

すいません、自己紹介を忘れてました。野球のエンジニアです。

PyConのおかげで、本当にプロのエンジニアになってしまいました。そういう人です。所属はネクストベースという野球のベンチャーで、今は1人エンジニア兼アナリストとか、いろいろやっています。

簡単に自社の紹介をさせてもらうと、ネクストベースは、「Innovations For All Athletes」、すべてのアスリートに技術革新をというテーマをもとに、こちらのスクリーンショットで出ているのが「BACS」という弊社のプロダクトなんですけど。

この「トラックマン」。先ほどの打球や、ここには出していませんが、投球のデータを3D表示したり、どういった傾向にあるかを変化量で表示したりすることによって、選手やチームのサポート・コーチングをするためのシステムを、各球団に入れています。

あとはプロアマ問わず、野球チームや選手の動作解析であるとか、球団運営などのコンサルティングやサポート、コーチングをしています。その他は、メディア事業もやっています。あと、これは重要な役なんですけど、エンジニアは僕1人しかいないので、同じくスポーツを科学で変えたい人を募集しています。

メディアです。

「Baseball Geeks」というメディアをやっています。みなさん、ブクマしてください（笑）。先ほどの「バレル・ゾーン」とか、あとは最近だと、甲子園の秋田県代表の吉田投手の分析もやらせてもらったりしたんですが、どうデータを見ることによって新しい野球が見えるかという、「Baseball Geeks」というメディアをやっています。こちらもぜひご覧いただければと思っています。

あとは、Python関係では、私はもともと前職でRettyという飲食系のWeb系のアプリサービスの会社に務めていたんですが、その時代から、Pythonのもくもく会をやっています。

こちらについては、だいたいざっくり毎月1度ぐらいやっています。

今月はなんと今週末の土曜日にやるので、PyConでこのセッションも含めて、いろいろなすてきなセッションがたくさんあると思うんですが、そこで学んで「続きをやりたいな」とか、そういった方がいましたら、なんとPyCon JP枠なるものがあるので、今からならまだ間に合います。土曜日空いている方はぜひどうぞ。

Python×野球の歴史

いきなりですが、PyCon JPと野球の歴史。なんとこのセッションで5回目・5年目です。

ざっと見渡すと、大雑把に言うと最初はDjangoのWebアプリケーションをやって、次にデータ分析系のことをずっとやって、なんと今年は2014年から2017年を全部を包括する内容になっています。

何をしてきたかと言うと、新たな野球分析基盤を作りました。「Morton」という名前です。

これに関しては、PyCon JP 2014から2017でいろいろ作ったり分析してきたノウハウを使って、データ収集から分析・可視化を新しく作り直しました。

初代の「No Ball」、野球という名前を付けたDjangoアプリケーションから、去年作った「Bradford」というデータを収集して可視化するダッシュボードを作ったんですが、それらをまとめて新たに、メジャーの公式のパブリックになっているトラッキングデータを用いて作り直しました。

ちなみに、名前の由来は、『ビッグデータ・ベースボール』という本がございます。その『ビッグデータ・ベースボール』で甦った選手が2人いて、そのうちの1人がチャーリー・モートンという、当時ピッツバーグ・パイレーツ、現在はヒューストン・アストロズにいる、なかなか球の速い先発ピッチャーがいるんですが、その先発ピッチャーの名前から拝借しています。

では、なぜ彼がデータ分析で甦ったかというのは、『ビッグデータ・ベースボール』という本を読んでいただいた方が早いと思います。

本日お話しするもの、全体像はこちらです。

これを全部作ってきました。使ったものはこれです。

30分で説明しきれません。大雑把に言うと、Pythonはlatestのバージョンを使って、今日の主役はどちらかと言うと、DjangoとNuxt.js、Vue.jsです。あとは、それらのアプリケーションを動かすために、Luigiとかpandasとかでいい感じにやりました。以上です。

とは言え、何も話さないのもアレなんで、3つのテーマでそれぞれどういった技術を使ってどういったことを実現したかをお話ししたいと思います。

Django REST FrameworkとNuxt.jsでSPA

まずは、Django REST FrameworkとNuxt.jsというお話をしたいと思います。

もともと、Pythonとデータ分析と言えば、けっこうイメージが強いんです。確かに、過去3年間ずっとPydata、Jupyter NotebookとかPandasmとかMatplotlibとか、唯一やっていないのは機械学習ぐらいで、そういったものを使ってやってたんですが、実は初代はDjangoのアプリケーションでした。

PyCon JP 2015のときに、これはダイジェストなんですが、実はさっきと似た画面を作っていたんです。これもDjangoで作っていまして、今はプロの野球のエンジニアとしていろいろやっているんですが、当時はどうやったらファンタジーベースボールというソーシャルゲームに勝てるかを、そもそものゲームをハックするために分析をしていました。

そんな中で、ゲームをハックしていた時代から4年経って、再びなぜDjangoに戻ってきたかと言うと、このWeb界隈の4年間の進化って相当すごいと思うんです。4年前とか、Single Page Applicationは確かにあったと思うんですが、今ほど一般的ではなかったですし、そういったところがあります。

あとは、先ほどちょっと紹介したNuxtベースの「BACS」については、表がVue.jsでできていまして、幸いにも仕事でVue.jsを触る機会ができたので、何かしらやりたいなと。あとは、「BACS」であるとか、今みたいなお見せしたUIとかを新しく商品として作るときに、技術選定の可能性として、ReactとかAngularとか、Djangoとか、Single Page Applicationっていろいろあると思います。Webに関して言うとDjangoとかFlaskとか、もちろんRuby on Railsとか、いろいろあるとは思うんですけど、その中で手を動かして試したかったです。

あとは何やかんやで、今年のCFPはDjangoが多かったりとか、DjangoCongress、Djangoのカンファレンスデイが日本でもあったりしたので、その波に乗っとけみたいなチャラい理由もいちおう含んでいます。

2014年からどう変化したかと言うと、当時はPythonのlatestバージョンが3.4で、今は3.7です。

Djangoは1.7から、現在は今日時点で2.1。ロングタイムサポートは1.11なのかな？　忘れちゃいましたけど、もっと行ってるかもしれない。

あとは、Bootstrapベースで先ほどのやつは作ってたんですけど、それがSingle Page Applicationになったりですとか、グラフライブラリについても、Chart.jsなど表現力が高いものが、もちろんD3などは4年前からありましたが、そういったものも含まれています。

あとは、何よりも大きいのは、野球の先ほどの投球や打球のトラッキングデータが、僕だけではなくて一般のみなさんとかも、サイトを知っていると手に入るんです。そういったものを使って何かをやるのが、少なくともアメリカは出てきたのはけっこう大きいところです。

Nuxt.jsとDjango REST Framework

そんな中で、今回はメイントピックとして、Nuxt.jsとDjango REST Frameworkの話を軽くしたいと思います。まずNuxt.js。まずはSingle Page Applicationにした理由なんですが、そもそも解析・分析ツールとしてどう見せたり、キビキビ動くようにしたらいいか、ヌルヌル動くようにしたらいいかは最優先課題だと思っています。

逆にSEOはまったくがんばらなくていいので、そういったユーザー体験を考えるときには、やはりSingle Page Applicationかなと。そこに関しては、選択肢として1択でした。あとは、仕事でVue.jsなどをやりつつ、お試しでReactでアプリを作ったり、以前、別の会社でAngularも使っていたりしていたので、いろいろお試しをした結果、Nuxt.jsがけっこうイケてそうだなということでNuxt.jsにしました。

Nuxt.jsは、簡単に言うと、これはPythonのカンファレンスなので本当に簡単な説明なんですが、Vue.jsをベースにしたフルスタックなSingle Page Applicationのフレームワークです。Vue.js版Ruby on Railsみたいな言い方をする人もたまにいますが、そんな感じです。基本的にはルールに従ってゴニョゴニョ書いたら、だいたい何かしら動きます。

このポイントとしては、肝心のUIやグラフを連携させたりといったことはNuxt UIでだいたいできちゃった。かろうじて今日のPyConは間に合ったというのが、正直なところです。とは言え、デザインのテンプレパターンはやっぱり欲しいと思っていまして、なんと世の中、優しい企業や優しい人がいまして、Nuxt UIというなかなか優秀なテンプレがありました。

例えばシステムの管理画面やブログの投稿画面みたいものをまとめているパッケージとしてCore UIがありまして、Core UIはさまざまな実装があります。AngularやVue.jsなど。そんな中でNuxt.js版があって、それが「Nuxt UI」という名前です。これを、ライセンス的にも問題なかったのでForkして、それから拡張して作りました。といったところで、フロントエンドはできました。

Django REST Frameworkを採用してよかったこと

次は、バックエンドです。Django REST Framework。

UI周りはNuxt.jsに任せちゃって、Djangoに関してはjsonでやりとりすればいいでしょうということで、Djangoは完全にRESTful APIと、あとここには書いてないんですが、データベースをマネージするためのDjango Adminで、管理画面だけの役割にしました。

これが4年前からの大きな進化で、4年前は単なるWebアプリケーションだったので、見せる部分とデータの部分で分かれていなかったんですが、完全にデータの部分と見せる部分がRESTで疎結合になったので、けっこうきれいなアーキテクチャになりました。

そういうものを作りたかったので、Django REST Frameworkにしました。セイバーメトリクスの指標値計算もしているんですが、これに関しては、REST Frameworkが何者かというのは、今日はたぶん芝田さんがお話ししているのかな。

たぶん芝田さんのお話や他の方の資料を見ていただくといいとは思いますが、Serializerという戻り値をいい感じにするクラスがあります。

その中で、データベースを設置した行単位で計算ができます。これはちょっと細かすぎるので、後でスライドを公開するときに、雰囲気コードを眺めてほしいんですけれども。

すみません。読めないですよね、これ。

（会場笑）

じゃあ飛ばしますね。後で読んでください。

REST Frameworkにして良かったのは、行レベルの指標計算をSerializerMethodFieldという機能があって、その中で項目ごとにhookをして、そこで実行したいClassやMethodを実行できる良さがあります。そんな中で、これは去年のPyCon JPでも話ましたが、「sabr」というセイバーメトリクス用の科学計算パッケージを自分で作って、それを使っていい感じにやりました。

SQL上でわざわざアベレージを取らなくてもできるようになった。そういったところで大きいのは、これはどちらかと言うと、REST Frameworkのアーキテクチャがイケているんですけれども、DBのクエリセットとSerializer（戻り値）の編集部分という、ある意味、役割と責任がきれいに分かれていて、非常に見通しのいいことになりました。

ちなみに、今日はコードは公開できないので、見通しのいいコードを見せることができないのは残念なんですけれども、まねしてやりゃわかります。

（会場笑）

とは言え、まあまあつらかったです。

Luigiを用いたパイプライン

といったところで、2014年からはいい感じに進化したねというのが、4年間の振り返りになります。ここまでが、昨日Twitterでつぶやいたときに、聞きたい話4つのうちのベスト1のDjangoの話だったんですが、一番聞きたくない話のLuigiの話をここからいきます。

（会場笑）

本当はLuigiは、僕はむしろこっちが専門なので、こっちの話がしたいんですけれども（笑）。さくっといきます。Luigiの話です。

もちろんWebアプリケーションはデータがないと動きません。データは試合が毎日ある限りは、毎日更新されます。

ではそのデータをちゃんとWebサイトからCSVを取ってきて、データベースに流し込む人が必要ですよねといったところでLuigiはがんばってくれています。

大ざっぱに言うと、Luigiとpandasでバッチを作っています。

pandasでCSVをごそっと読み込んで、ごにょごにょと処理をしてCSVに吐き出します。CSVをデータベースに保存します、みたいなことをやっています。これに関しては、私がRettyにいたときに、似たようなバックエンドをLuigiとpandasで作っていました。こちらにちゃんとした解説と絵があるので、そちらをご覧いただいた方が早いかなと思います。

Luigiすごくいいところは、バックエンドで進行状況を画面で見たいとか、そういうことがあると思うんですが、そういったものが標準な機能でこれだけで手に入ります。

特定のポートに穴を開けて、ブラウザでポチポチ叩いてあげると、こんな進行画面が見れるのは、非常に便利です。

PyDataでプロトタイピング

次がPyData。Jupyterとかpandasとか、Bokehの話。

いきなりWebアプリケーションを作るとけっこうつらいので、いろいろなデータを見ながら、実験的にいろいろやりたいですといったところで、Jupyterみたいな道具はけっこう便利です。

ここの連携は何かと言うと、こちらです。

生のCSVデータや、たまにデータベースのデータから引いてきて、何かしらの「この機能どうしようかな」「どうやってアルゴリズム組もうかな、実装しようかな」「何のグラフ使おうかな」と試行錯誤するときに、いきなりJavaScriptとDjangoを書き始めるとつらいので、Jupyterでやりました。

ここで言うPyDataとは、大ざっぱに言うと、Pythonを用いたデータ処理、営みすべてです。営みっていい言葉ですよね。どうでもいいですけれども。

（会場笑）

機械学習などの前処理がよくある。よくやっているやつで、方法としては何でもありっちゃ何でもありなんですけれども。別にJupyter使わなくてもいいですし。だいたいJupyterとpandasを使っちゃった方が、非常に楽だとは思います。

プロトタイピングはなぜしたかと言うと、先ほどもお話ししたとおり、Webアプリやバックエンドを作る前に、部分部分のモジュールやパーツを作るわけじゃないですか。その作ったやつを数珠つなぎに動かすとかデバッグするみたいなところで、PyCharmみたいなIDEでやってもいいんですけれども。

もうちょっと複雑なやつは、先にこいつJupyter上でやっちゃった方が楽ということで、Jupyterを使いました。試し書きやデバッグするのに、ブラウザで動くのはやりやすいですね。あと、個人的にはソフトウェアって、設計をして作って動かして、「ちょっと合わねえな」とか「バグがあるな」と、作っては壊してのトライアンドエラーの繰り返しだと思っています。そういったところでもJupyterは使いやすいです。

それをやることによって、対象の面倒くさいデータ。ちなみに、今日のデータに関しては1シーズン分なので、約70万球。だいたいメジャーリーグは1シーズンを終えると、60万球から70万球くらいになるんですが、70万球×5年分とか使っていたりするので、それを使っていきなり正解の実装はたぶん難しいと思うので、Jupyterなどでやっていました。

活躍したツールと工夫

今回活躍したものは、大ざっぱに言うと、BokehとpandasとJupyterです。

Bokehでいろんなグラフを書いたり、pandasで処理を考えたり、これらを使うプラットフォームとしてJupyterを使っていました。

その他のこだわりポイントは、この1枚にまとめています。

セイバーメトリクスデータ、先ほどデモでは見せていないんですが、懐かしのアダム・ダン率とかもこの中に含まれています（笑）。そういったところは、もともと2014年に使っていた自分のツールを使ってうまくやりました。スキーマは変わっていましたが、なんとかなりました。

あとはDocker。先ほどお見せしたWeb画面は、全部PC上のDockerで動いています。これに関しては、やはりクラウドサービスにお引越しするときに、手離れしやすいようにということでやっています。あとは2人目、3人目のエンジニアが入ってきたときに、「はい、これ開発環境だから、これを使って開発してね」と、スタートの時間を短くする意味合いも含んでいます。

個人的には、開発は最近だとCloud9的なやつとか、EC2上で自分でやって、そこ上で開発する人も多いとは思うんですが、個人的にはローカルPCでやっちゃうのが好きなので、PyCharmでずっとやっています。仕事だと、たまにEC2にSSHで入ってということもあるんですが、基本的には自分のPCの中でやっています。

果たしてスライダーは本当につらいのか？

これでいったん技術の話は終わりです。ところでみなさん、先ほどから僕があるキーワードばかり言っていることに、お気付きでしょうか？　何かと言うと、「つらかった」とか「つらかった(´・ω・｀)」とか「つらみを味わう」とか、いろいろつらいことがあるじゃないですか。野球って、けっこうつらいイベントが。だいたい25から334個くらい。

（会場笑）

ちなみに野球好きの方は今日この会場にどれくらいいらっしゃいますか？

（会場挙手）

半分くらい。少なくとも、25回くらいはつらいことありますよね。多くても334回くらいだと思うんですよ。

（会場笑）

なんか伝わりましたかね。ここで、今日のためにちょっとした緊急検証をやってまいりました。

緊急検証、「果たしてスライダーは本当につらいのか？」。

（会場笑）

ちなみに言うと、日本のプロ野球やアマチュアの話については質問禁止なので、言葉は発しないでくださいよ。

（会場笑）

僕はあくまでも、「スライダーはつらい」という話しかしていません。某掲示板で有名な「外スラはつらい」は本当かということで、今日の基盤を使って軽くデータを見てきました。なお対象は、今日はメジャーの話でしたのでメジャーリーガーです。ちなみにマジな話をすると、仕事では決してこんな適当なことはしません（笑）。

（会場笑）

ちなみにこのアイデアは昨夜、徹夜明けくらいに思いついて、慌てて作りました。

スライダーが得意・苦手な選手

ということで、さっそくメジャーリーグ版、つらいランキングとつらくないランキングを出してみました。

（会場笑）

「つらい」の意味は、スライダーで三振を取られた回数が多い選手。「つらくない」は、逆にスライダーをヒットにしている選手のランキングです。先ほどちょっと名前が出た、ジャンカルロ・スタントン。彼は圧倒的につらいことがわかりました。

（会場笑）

ちなみに、これには特徴があります。今日この先あとスライドはそれほど多くないので、ここで時間使います。つらい上位5人は、ホームランを30本以上打っています。つらくない方は、比較的リーディングヒッター、いわゆるアベレージヒッターが多いです。アルトゥーベは去年の首位打者です。後はどちらかと言うと、つらい成分はとくに理由はないんですが、左打者より右打者がなんとなくつらい気はします。あ、意外と反応なかったな。

（会場笑）

ということで、今日は軽くジャンカルロ・スタントンのつらさについて。本当にジャンカルロ・スタントンはつらいスライダーでくるくるしているのか、ちゃんと見てみました。デモを出すには画面が小さいので、いきなり結論出します。

このレーダーチャートがポイントです。このレーダーチャート、ここはスライダーなんです。スライダーで、こっちはフォーシーム。圧倒的に、アウトも三振も全部スタントンというバッターは、スライダーでくるくるいっています。

（会場笑）

くるくるいっているか、ごろごろいっている感じはしました。

（会場笑）

基本的には超優秀な選手で、右打者で去年はナ・リーグのホームラン王かな？ ちなみに打球のプロットは、右打者の場合やっぱりどうしても引っ張るので、こっちに寄っちゃうんですけが、だいたいまんべんなく打っていたりとか。あとはデータは出していないんですが、打球速度もかなりいい選手なので、すばらしいなというところです。

「選択と決断」の中で「選択と集中」ができること

ということで、結びましょう。いろいろ話しましたが、真面目な話をすると野球と技術の選球眼は毎日頻繁に発生する「選択と決断」の繰り返しの中で、「選択と集中」がしっかりできること。これは技術者としても、野球好きとしても思っています。

選択と決断。エンジニアは選択と決断が常にある。「Djangoで作ろうか、Flaskで作ろうか」とか、「言語は何にしよう」とか、「JavaScriptはどのフレームワークを使おうか」って、みんなテーマは違えど、似たような選択と決断の瞬間はあると思います。野球選手に関しても、常に来るボールに対して「振るか、振らないか」とか、そういうことがあったりすると思います。つらいスライダーは見逃してもいいかなって気はするんですけれども（笑）。

（会場笑）

そういった選択と決断の繰り返しです。では、正しく選択するためにはどうすればいいか。何はともあれ技術力を磨きましょう。エンジニアリングのこと、技術のことを正しく知る・練習する。野球もたぶん一緒でしょう。僕はプレイする方まったくだめなので、見る方は好きなんですけれども。あとは、日々の練習と鍛錬は怠らないようにしましょう。

個人の学習や読書、あとはみなさん勉強会やイベントとか、そういったことに行くのが好きだとは思うんですが、そういったところも活用していきましょう。プロスポーツに関しても、選手はもちろんチームで練習することもあれば、個人練ということもあると思うので、そこも大切だと思います。

あとは、これも重要なポイントなんですが、決断を恐れないこと。個人的にはイシューから始めるのを重要視していて、そもそも作るモノとか分析するコトを、仮説やテーマこみでちゃんと言語化しましょう。それによって何ができるかと言うと、物事を決断するためのルールができます。自分に作れます。

「迷ったら○○」。私の場合は完全に「迷ったらPython」というルールがあります（笑）。もしかすると野球選手に関しては、スライダーでくるくるしていない人は、迷ったらスライダーは見送っているかもしれません。それも立派な決断です。といったところで、決断ルールをちゃんと作って、決断ルールの外にあるものは絶対やらない。スライダーは見送るみたいなことを書いていますが、とくにスライダーだけじゃないんですけれども（笑）。

（会場笑）

そういうのあります。あとは、それをやるためには、ちゃんと集中しましょう。選択・決断を正しく回すためには、集中することは非常に重要なポイントだと思っています。なにより集中する理由としては、リソースを集中すること。時間やお金です。逆に発散することは、例えば流行りものに飛びついていろいろやるとか、毎日・毎週のように勉強会やイベントに行くとか。

そういったことを繰り返していると、目的あるうちはいいんですが、それを何のためにやっているのか。本来学びたいものがあったはずなのに、本質的ではないところにいって、結局のところ、分散して何も生まれないことがあったりすると思うので、集中は大事だと思います。

個人的な集中のコツとしては、習慣作りかなと思っています。よくやっているのは、勉強会は週に1度までとか、SNSはもくもくしている間は断ちましょうとか。そういったルールはちゃんと決めています。

野球×Python、ゲームセット

といったところで、先ほどまでこの言葉を二言発していなかったんですけれども、今回で僕の野球とPythonの発表は一応終わりです。一応。それも結局のところ、「野球やるぞ！」と選択・決断・集中したおかげで、本当にプロの野球エンジニアになれました。

これからはそのリソースを、Pythonやエンジニア界隈だけではなく、例えばインターネットのTV放送局や、地上波でもいいんですが、そういったところでデータドリブンで解説したりして、スポーツや野球など、そういった世界をより良くしていけたらいいなと思います。それがそもそも本職にけっこうつながったりしてくる、と言うか、そもそもそういう仕事なので（笑）。やっていけたらなと思っています。

といったところで、Pythonから生まれた野球のエンジニアリングは、もっと広い世界で羽ばたくということと、これぞまさに「ひろがるPython」ではなかろうかと。何うまいこと言っているんだという話ですけれども。

（会場笑）

とは言え、寂しいと思うことはなかれといったところで、来年以降も、たぶんPyCon JPは野球以外のCFPを出すのと、別に野球とPythonって、僕がやらないといけないというルールどこにもないので。

逆にみなさん、来年はチャンスです。だって私、CFP出さないんですもん。ということで、後に続いてスポーツで何かやりたいとか、野球が好きだという人は、ぜひ。幸いにもあと1年くらい時間はあるので、1年くらいがんばれば何かできると思います。とは言え、僕って野球好きなんで、あ、タイムアップですね。手のひらはくるくると回ると思います。

（会場笑）

来年しれっとCFP出していたら、ごめんなさい。

（会場笑）

ということで、今までご声援ありがとうございました。私のトークはお開きになります。ありがとうございました！

（会場拍手）