【Tableau】Kobe Bryant Shot Dataを分析してみる

こんにちわ@Yoshimiです。

Tableauの可視化スキルが趣味のバスケットボールでもできたらもっと楽しくなるだろうなと思い、バスケットボールのデータの分析をしていきます。

今回、kaggleのKobe Bryant Shot Dataを使わせていただきます。

Contents

データを理解する

可視化をする前にデータの理解をしましょう。
Kobe Bryant Shot DataはNBAのスーパースターKobe Bryantが20年間のキャリアで試した全てのフィールドゴールのデータになります。
データのフィールド名は以下のようにまとまっています。

column columnの意味
action_type ショットのアクションタイプ
combined_shot_type 複合的なシュートタイプ
game_event_id ゲームイベントID
game_id ゲームID
lat 緯度(latitudeのことだと思う)
loc_x loc_x
loc_y loc_y
lon 経度(longitudeのことだと思う)
minutes_remaining 残り分
period ピリオド
playoffs プレーオフ
season シーズン
seconds_remaining 残り秒数
shot_distance ショット距離
shot_made_flag 成功or失敗
shot_type ショットタイプ(区分)
shot_zone_area ショットゾーンエリア
shot_zone_basic ショットゾーン_ベーシック
shot_zone_range ショットゾーン_距離
team_id チームID
team_name チーム名
game_date ゲーム日付
matchup マッチアップ
opponent 対戦相手
shot_id ショットID

shot_id で一意のレコードになっています。

game_idは行われた試合のid、試合が行われた日付もgame_dateとしてあるようです。

action_typeはそのショットがどのようなショットタイプだったかのようで、「Driving Layup Shot」など、ドライブからして例アップしたと思われます。同じようなフィールドで、combined_shot_typeがありますが、データを見ると最終的なショットの分類だと考えられます。

lat、loc_x、loc_y、lonでは、位置情報もあります。

Tableauでも確認してみます。

Kobe Bryant Shot Dataを分析してみる

可視化の前に、今一度Tableauでデータを確認します。
「Shot Made Flag」をディメンションにして、行シェルフに持っていきます。

Nullがあることがわかります。
このデータは、kaggleからのデータを持ってきたわけですが、予測モデルを作成するためのデータセットですので、あえてNullとなっています。ですので、このNULLを除外して可視化を進めていきます。

時系列で分析してみる

レギュラーシーズンは10月から翌年4月となっていますので、大枠の「Season」でみていき、その後、気になるところがあれば細かくみていこうと思います。

「Season」を列シェルフ、「Shot_id」を「個別のカウント」とし、行シェルフに入れます。
2013-14のシーズンでショット数が極端に少ないことが確認できます。原因はグリズリーズ戦で相手選手との接触プレーで右膝を負傷のようです。

「Shot Made Flag」をカラーに入れます。
行セルフの「Shot_id」を右クリックで押下します。簡易表計算>合計に対する割合を選択し、次を使用して計算>セルと続けて選択していきます。ラベルをつけて割合を表示させてみます。

引退2シーズン前まで40%以上を超えるシュートの成功率です。

どんなショットが多いのか確認してみます。
デビューから年月が経つにつれてジャンプショットの割合が多くなってきます。

ショットのタイプによる分析

ショットが打たれた位置情報の可視化

工夫して可視化してみる

最後に

Python勉強したいのであればこれ一択


AIの技術、データ分析を身につけるにはPythonが取り組みやすいです。専門コースもあるので、まずは、気軽に問い合わせしてみてください!
技術者も多くなってきていますが、世界と戦うにはまだまだ人材不足です。高い年収を狙うなら今がチャンス!


フリーランスエンジニアが登録して欲しいエージェント


長くお世話になっているengineer-route。
単価、稼働日数、稼働時間相談も親身にのってくれます。しっかりしたサポート・コミュニケーションを交わすことで「はいってみた違った」というエンジニアあるあるを極力回避できると思います。私は当たりしかないです。