astamuse Lab

astamuse Labとは、アスタミューゼのエンジニアとデザイナーのブログです。アスタミューゼの事業・サービスを支えている知識と舞台裏の今を発信しています。

データ分析ことはじめ 〜はじめてのデータ分析やってみたよ〜

f:id:astamuse:20201217033839j:plain

ご挨拶

どうもお久しぶりです、gucciです。
気づけばもう12月も半ば…今年は本当に色々なことがあった年でしたね。

新型コロナによってこれまでの日常が一変し、当たり前だったものが当たり前でなくなるという本当に大変な年だったと思います。

私の好きなプロ野球ももちろん多大な影響を受けて、シーズンの開始が遅れ、無観客試合や手拍子での応援など、これまでとは異なるシーズンでしたが、何はともあれ無事にシーズンが終わることができたのは本当に素晴らしいことだと思います。

データエンジニアとしてやってきて

さて、そんな中で私はデータエンジニアになり2年が経ちました。
(入社して1年弱アプリエンジニア〜その後データエンジニアにジョブチェンジ)

弊社はとにかく様々なデータを集めています。
技術情報と他のデータを組み合わせたり、新しい分析手法を用いたり、独自の切り口で分類を行なったりすることで、弊社にしかできないソリューションを提供しております。

非常に優秀なデータアナリストがおりますので、分析するためのデータを我々データエンジニアが整備していくといった塩梅でございます。

これまでデータを色々な形で料理できるようにあれこれ設計・整備して参りましたが、おやおや、データを実際に使う側にも少し興味が湧いてきました。

そこで今回は、
データ分析ことはじめ 〜はじめてのデータ分析やってみたよ〜
というお題でお送りしたいと思います。

ちなみに、本当に初歩の初歩のことしかしないので、今回の内容はどちらかといえば非エンジニア向けのライトな内容です。
「データで分析っていってもまったく想像がつかない!」
「プログラミングでデータを使うと何ができるの?」
「野球が好き!」
という方におすすめです。

そうだ、野球のデータを使ってみよう

さて、データの分析をやってみようかなと思ったものの何を題材にして良いのかさっぱりわかりません。
悩み抜いた末に、日頃からこっそり集めていたプロ野球のデータを活用してみることにしました。
それでは簡単クッキング!!

使うもの

  • プロ野球のデータ: csvファイル
  • 実行環境: JupyterLab
  • データごにょごにょ: Pandas
  • 可視化ライブラリ: Plotly Express

プロ野球のデータ

いつもお世話になっているサイトがこちらの 「プロ野球データFREAK」さんです!!
こちらのサイトから「打者成績」「選手一覧」のデータを拝借させていただきました。
いつもありがとうございます。

実行環境

今回 python で分析を行なっていきます。
JupyterLab は Jupyter Notebook の進化版で、ブラウザ上で動作するプログラムの対話型実行環境です。
簡単に実行結果が確認でき、またグラフなどの描画も画面上でできるのでデータ分析には欠かせないツールと言えそうです。

データごにょごにょ

データ分析といえば Pandas (実はあまり使ったことがなかった)。
Dataframe という「表」でデータを扱うことができますので、とりあえずこいつでやっていきましょう。

可視化ライブラリ

今回はいわゆる有名な Matplotlib でなく Plotly Express というのを使っていきます。

plotly.com

弊社自慢の若手超優秀機械学習エンジニアのNくんが以前紹介されていたので、使ってみたくて選びました。
元々は Plotly というオープンソースのデータ分析・グラフ可視化ツールがあって、それのラッパーライブラリが Plotly Express だそうです。
より簡単にインタラクティブな描画ができるという優れモノです。
3Dやアニメーションも使えるみたいなのでなんだかとっても良さげ。
ただ、JupyterLab で描画すると最初は真っ白で何も表示されなくてビビります。
ちゃんとチュートリアルを読まないとですね。

plotly.com

給料泥棒を探せ

それでは、さっそくやっていきましょう。

  • 2020年の年俸
  • 2020年の成績

これらを組み合わせて可視化することで、給料泥棒お金を貰っている割にあまり結果を出せていないのは誰か、というのを調べちゃいましょう。
今回は打者の指標としてはOPSを用います。

OPS(オプス、オーピーエス)は On-base plus slugging の略であり、野球において打者を評価する指標の1つ。出塁率と長打率とを足し合わせた値である。

いっぱい塁に出たり長打を打てる人が打者として優れているよね、って指標です。
1を超えたら本当にすごい。

ここからは簡単にコードのご紹介!!(いい感じにパスとか汲んでくださいませ)

必要なライブラリの読み込み

import plotly.express as px
import glob
import pandas as pd
import re

CSVデータ読み込み

# 2020年の打者成績一覧を読み込み
df_all_batter_stat_2020 = pd.read_csv('{適切なパス}/Baseball/Batting/2020_stats.csv', sep = ',')

# 2020年の各球団の選手一覧を読み込み
# 「2020_{チーム名}.csv」で格納してある
dir_path = '{適切なパス}/Baseball/Player/'
all_files = glob.glob(dir_path + "2020*.csv")

# 一つ一つのデータを読み込んで dataframe に追加していく(その際チーム名も追加)
df_all_player = pd.DataFrame()
for filename in all_files:
    df = pd.read_csv(filename, sep=',')
    team_name = re.sub('\d+_', '', filename.split('/')[-1].replace('.csv', ''))
    df['チーム'] = team_name
    df_all_player = pd.concat([df_all_player, df]).reset_index(drop=True)

打者成績一覧と選手一覧とがっちゃんこ

df_all_batter_data_merged = \
    pd.merge(df_all_batter_stat_2020, df_all_player, how='inner', on=['選手名', 'チーム'])

'年俸(推定)' の文字列を'年俸(万円)'の数値に変換
OPSを算出して dataframe に追加

df_all_batter_data_merged['年俸(万円)'] = \
    df_all_batter_data_merged['年俸(推定)'].str.replace(',', '').str.replace('万円', '').astype(int)
df_all_batter_data_merged['OPS'] = \
    df_all_batter_data_merged['長打率'] + df_all_batter_data_merged['出塁率']

全選手表示すると大変なことになるので、
『規定打席を超えた人(372打席)または年俸が1億円より多い人』を抽出

df_all_batter_data_merged_over_10000 = \
    df_all_batter_data_merged[(df_all_batter_data_merged['年俸(万円)'] > 10000) | (df_all_batter_data_merged['打席数'] > 372)]

いざ、散布図を表示

fig = px.scatter(
    df_all_batter_data_merged_over_10000,
    x='OPS',
    y='年俸(万円)',
    text='選手名',
    color='チーム',
    size_max=30,
    height=500,
    width=800,
    size='本塁打',
    color_discrete_map={
        '巨人': '#F97709',
        '阪神': '#ffff00',
        '広島': '#FF0000',
        '中日': '#00008b',
        'DeNA': '#00bfff',
        'ヤクルト': '#7cfc00',
        'ソフトバンク': '#f9ca00',
        'オリックス': '#b08f32',
        '日本ハム': '#02518c',
        'ロッテ': '#221815',
        '西武': '#102961',
        '楽天': '#85010f'
    }
)

fig.show()

その結果がこちら↓↓

いかがでしょう!!
この描画されたグラフ、マウスホバーで情報がでたりドラッグでズームインとかできちゃうんです!!
すごいお便利。
ちなみに、円の大きさが本塁打の数を表しています。
本当はもっと大きく出したかったのですが、サイトのページサイズの関係でこの形になりました…。
こちらの画像の方が見やすいかもしれません。

f:id:astamuse:20201217023224p:plain
2020年俸/2020打者OPS

この散布図を見るだけで、

  • 図右上:期待通りゾーン
    • 柳田えぐい(一番年俸をもらっていて一番OPSが高い。すばらしい。)
  • 図左上:年俸の割にOPSが高くないゾーン
    • バレンティンがちょっと…年俸の割に…残念…
  • 図右下:年俸の割によくやっているゾーン
    • 村上くんは年俸の割にものすごいOPS

といったことが簡単にわかってしまいました。データを可視化するってのはすごいことですね。
これまでの貢献やOPS以外での活躍というのももちろんありますので一概には言えませんが、一つの見方としては面白いですね。
もうすっかり分析した気分になれちゃいます。

きちんとお給料もらってる?

さぁ乗ってきたところで、今度は活躍に応じてきちんと年俸が支払われているのかチェックしてみましょう。
前述の検証では、2020年の年俸と2020年の成績を使いましたが、
本来年俸というのは結果に対して「よう頑張った!!次も期待してるで!!」の側面が強い(成果)と思いますので、ためしに1年ずらして計算してみましょう。

  • 2015〜2019年の成績の平均
  • 2016〜2020年の年俸の平均

これらを使ってみます!! 基本的にはほぼ同じコードですので、新しいとこだけ書いておきます!!

集約して平均をだす

grouped_batter_detail = df_all_batter.groupby(['選手名', 'チーム'], as_index=False)
grouped_batter_detail_avg = grouped_batter_detail.mean()

新しいのはこの子ぐらいでした。
5年に増やしたことによりさらに選手がごちゃくつので、
『平均400打席を超えた人または平均年俸が2億円より多い人』に条件を変更して・・・抽出!!

その結果がこちら↓↓

いかがでしょう!!
いちおおっきいのも貼っておきます!!

f:id:astamuse:20201217025510p:plain
5年平均での図

この散布図からは、

  • 図右下の広島の丸選手が、図右上の巨人に移籍してしまうのも仕方がないかも…
  • 近似曲線をイメージすると、やはり全体的にソフトバンクと巨人はそれよりも上にいそうな気がする…
  • 気のせいかもしれませんが、中日は少し給料が低めなイメージが…

といったようなことがパッと思いつきますね!!
(個人の考えなので、ご気分を害された方がいらっしゃいましたら申し訳ございません。)

まとめ

いかがだったでしょうか。
大した分析はできていませんが、データを元にパッと可視化するだけで新たな気付きや発見があるというのが体験できたかと思います!!
今回はほんの一部の可視化〜分析でしたが、機械学習とかも絡めて予測できたらさらに幅が広がりそうですね!!

最後に、アスタミューゼではアプリエンジニア、デザイナー、プロダクトマネージャー、データエンジニア、機械学習エンジニアなどなど絶賛大募集中です!!
どしどしご応募ください!!お待ちしております!!

最後までお読みいただき、ありがとうございました!!

ニューラル機械翻訳モデルを自作してみる

f:id:astamuse:20201208203648p:plain

こんにちは、師走ですね。業務に関連した技術トピックをということで、今回は翻訳について書こうと思います。

機械翻訳について

弊社アスタミューゼは知の「流通・活用・民主化」を掲げており、世界各国の特許やグラントその他のデータを収集・分析・提供しています。これらの文書は当然各国語で記述されているため、統一した分析処理のためには機械翻訳や多言語処理が必要不可欠です。

ニューラル機械翻訳

2020年を振り返って翻訳関連の話題といえばDeepLを思い浮かべる方が多いのではないでしょうか。2018年頃から欧州を中心にGoogle Translateと比べた品質の優位性が話題になり、3月に日本語対応が発表されたことで国内での認知度が一気に向上しました。試しにつかってみたという方も多いはずです。

www.deepl.com

このDeepLに代表されるように、ここ数年の機械翻訳の発展は、自然言語処理のなかでもニューラル機械翻訳(Neural Machine Translation, 以下NMT)という分野の研究成果が寄与しているようです。従来の統計的機械翻訳と比べた性能向上やNMT固有の誤りとその対処法などが、国際会議でもさかんに報告されています。

この記事では、ニューラル機械翻訳(NMT)システムがその内側でどんな処理をしているかを理解することを目的に、実際に簡単な翻訳モデルを手元で作成してみて、その品質を評価するところまでをご紹介します。

続きを読む

現場コーチング受けてみた話

f:id:astamuse:20201125123021j:plain

こんにちは、アプリケーションエンジニアの @yukung です。突然暑くなったり寒くなったり、気温の変化が大きい今日このごろ、体調いかがでしょうか。コロナの勢いも再び出てきてしまっており少し不安な状況になりつつある中、再度気を引き締め直してしっかり体調に気をつけていきたいですね。

スクラム始めてみてその後どうなった?

さて、今回は以前ご紹介した、弊社の ICP 開発チームにおける開発の様子のその後について触れてみたいと思います。

以前このブログで、ICP 開発チームでは開発の進め方としてスクラムを導入して開発を行っていることをご紹介しました。その時の経緯や具体的なやり方の様子などは、以下の記事もぜひご覧ください。

lab.astamuse.co.jp

また、本記事の趣旨とは少しずれますが、今年の大きな変化として多くの企業がリモート・在宅での業務にシフトしていく中で、我々 ICP 開発チームもスクラムを継続しつつ、自ずとリモート主体の業務スタイルに移行しています。その時の変化の様子については、以下の記事で紹介されていますのでこちらもどうぞご覧ください。

lab.astamuse.co.jp

スクラムを始めてみて浮き彫りになった課題

上記の記事で触れた通り、スクラムを始めてしばらくは、私自身がスクラムマスター兼開発者兼各種スクラムセレモニーの MC を兼任する形で進めていました。見様見真似で始めたこともあり、はじめの頃はチーム全体が何が正解かも分からず、まずは私が言っていることを正として、進めていたと感じています。

そうすると、容易に想像できることではありますが、だんだんと私自身がボトルネックになりはじめている感触を持つようになりました。どんな点でそう感じていたかについて、細かいものまで挙げると切りがないですが例えば以下のようなものです。

  • スプリントプランニングの進め方について
  • ストーリーポイント見積もりの基準について
  • デイリースクラムのファシリテーション
  • プロダクトバックログリファインメントの議論のファシリテーション
  • 振り返りのファシリテーション
  • etc...

当然といえば当然ですが、知らないものに取り組んでいるのでそうならざるを得ないのはある程度仕方のない面があります。

一方で、この状況は決して芳しいものではなく、チームの成果を最大化するにはこの状況自体を改善する必要性がありました。PM の Gyopi が機を見たタイミングで違和感や改善提案などを出してくれてそれ自体に大分助けられていたのですが、私自身も認定スクラムマスターの資格を持っている訳ではなく、私自身でも自信を持って進められているわけではありませんでした。

そんな折、私が以前在籍していた職場で現場コーチとして関わってくれていたギルドワークスの中村さん

guildworks.jp

からお声がけいただいて、中村さんのご厚意によりアドバイスをいただける機会を得ることができました。

GuildWorks

コーチングの内容(一部)

漠然とした課題感は持っていたものの、自分たちでも何が課題なのかをはっきり認識できていない中で、中村さんには現状を率直にぶつけてお話を聞いていただきました。以下はその時のミーティングの様子で話していたメモの一部です。(字が汚くてすいませんw)

f:id:astamuse:20201125120251j:plain

(この時からは結構時間が経っており、今となってはという話も含まれていて個人的には懐かしい感情が沸いてきます…)

また、中村さんにはチームの振り返りのある会にご同席いただいて、様子を観察していただきました。一部ですが抜粋してみます。あくまでも私たちのチームの状況なので、全て参考になるわけではないと思いますが、なんとなく雰囲気が伝わればと思います。

f:id:astamuse:20201125120331p:plain

中村さんとのオンライン雑談会

また、この後ある程度時間が経ってからも、オンラインでの雑談会で相談に乗っていただいたりもしました。その時にいただいたメモなどを一部抜粋してご紹介します。

こちらも私たちが直面した状況に対する議論のメモなので、これを読んでそのまま何か答えとなるようなものではありませんし、特定の課題に限っていないので取り留めもないのですが、少しでも参考になればと思い載せてみます。(中村さん)とカッコ書きにしているところは、中村さんからいただいたアドバイスの一部です。

オンライン雑談会のメモ

  • ストーリーポイントの確からしさに対する不安
    • 怖い?
      • (中村さん)正確さを求められる強迫観念をチームが持っている?
    • 数字は取っているけど、それを見てカイゼンする姿勢になりづらい
    • ポイントについて話しているのにいつの間にか工数見積になっている。
      • (中村さん) 議論する前にまず最初につけてみると良い かも?
      • (中村さん)1,2,3,5,8,13 で 2 つ以上離れていると、話し合うと良さそう なアラート。
    • (中村さん) 規模見積と工数見積の違い について
  • チームの人数の大きさについて。多いと感じているが実際どうなのかが不安
    • 最適な人数ってどれくらい?分けたほうがいい?
      • (中村さん)どうして分けないの?
      • 実際に回るかどうか不安
        • (中村さん) 試しに PO と SM (私自身) が、一緒に1週間くらい旅行に行ってしまって、その間みんなに回してもらえばいいのでは?
      • (中村さん) 小さく分けてうまくいかなければ、元に戻せばいい んじゃないかな?
      • (中村さん)PO が一人で回らないかもという場合、POを増やすという選択肢もある。例としてエンジニアから企画の人に手伝ってもらってPOをできていた例がある。
    • チームをわけることで、ドメイン or 技術スキルに偏りが出るかもという不安
      • (中村さん) 「みんながいい感じに守備範囲広くできる状態」をそもそも目指すのか?目指すとしたらそこにはどのように到達する のか?
      • (中村さん) ”チーム”としてユーザーに届けるためのスキルを持っているか が大事。
    • (中村さん) スモールチームでやったほうが、学びの増幅が起きやすい 印象がある
    • チーム分ける時、コードベースでも分けてる?
      • (中村さん)とある現場の例では、別れているチームも1つあるけど、2チームは同じところを触っている
      • (中村さん)同じところを触りそうなときにはスプリントの手前でやることをずらして被りづらいようにしている
  • リファインメントっていつしたらよい?今は週一回時間を取ってやっているが、議論が発散しがちでうまくできていないと感じる

現場コーチから持ち帰って実践したこと、変化があったこと

上記のような取り組みをさせていただいたことで得られたこととしては、まずは 私自身の良い振り返りの機会になった 、ということが大きかったと思っています。

自分自身でも自信を持てていたところ、逆にあまり自信を持てておらず不安だったところ、全く観点がなかったところなど、率直にぶつけさせていただいたことで気付かされることが多くありました。それによって私自身の振る舞いが少しずつ変わっていったように感じています。

また、上記でいただいたようなアドバイスを元に起こったチームの変化という意味で 1 つ挙げると、 私が行っていたような多くの議論のファシリテーションなどを、今ではチームメンバー全員で交代しながら実施することができるように なりました。

それによって、プロダクトバックログリファインメントとの向き合い方が以前より変わり、 しっかりリファインメントできたものに関してはやることがはっきりしてチームメンバーが理解できている状態でスプリントプランニングに臨めるようになった ため、議論がスムーズになりました。

スプリントプランニングやプロダクトバックログリファインメントなどについて、関わっているメンバー一人一人が、 誰かがやってくれるものという認識ではなくチームメンバーが自分のタスクとして認識する ことで、どういう事に気を配らないといけないのか、また議論の着地点をどこにするのか、という意識が少しずつチームメンバーに芽生えてきたのではないかと感じることが多くなってきました。結果的にリモート中心となってもミーティングの練度が高まっていったように感じています。

まとめ

スクラムを始めてしばらくして浮き彫りになってきた課題について、幸運にもギルドワークスの中村さんにアドバイスいただける機会をいただけたことで、チーム開発におけるカイゼンを一歩前に踏み出すことができたと感じています。

お声がけいただいたギルドワークスの中村さん、この場を借りて御礼申し上げます。ありがとうございました!

我々 ICP 開発チームはまだまだ完成された開発チームではありませんが、スクラムを用いて自分たちの開発するものについてチームで議論しながら進められるような開発ができています。こうした開発にご興味がある方は下記バナーの採用サイトからご応募いただければと思います。

Copyright © astamuse company, ltd. all rights reserved.