【技術編】アイカツ!シリーズのCD売上から見えてくるもの

先週書いたアイカツ！のCD売上分析で使用したpytonコードをメモとして記載しておく。 分析自体については以下を参照ください。
snofra.hatenablog.com

今回のデータ分析について

今回はデータ量も大したことなかったので手動でデータをcsvに加工して作業をしていた。
JINの投稿データは収集に1時間かかってマジクソと思ったんだけど、クローラ作るほど何度もJINは利用しないので頑張った。

データの加工はpandasで簡単にやりつつ、描画はbokehにしてpandasのdataframeをそのまま取り込むことにした。

実装量はかなり少ない。変に自前でサマリする処理加えるよりも楽だったというのが正直なところ。

実装

ロード部

import pandas as pd
import numpy as np
import math
# bokeh系のライブラリ
from bokeh.plotting import figure, output_file, show
from bokeh.io import output_notebook
from bokeh.models import ColumnDataSource,  Range1d, LinearAxis
output_notebook()

# csvファイルのロード
# アイカツ！のCD売上
df_aikatsu_cd = pd.read_csv('C:/xxxx/cd_sales.csv', parse_dates=[2], engine='python', encoding="utf-8")
# googleTrends
df_trend = pd.read_csv('C:/xxxx/multiTimeline.csv', parse_dates=[0], engine='python', encoding="utf-8")
# JINのアイカツでヒットした投稿数
df_jin = pd.read_csv('C:/xxxx/jin.csv', parse_dates=[0], engine='python', encoding="utf-8")

sales_day_all = df_aikatsu_cd.fillna('0')

加工部

# 発売月単位でサマリする
df = pd.DataFrame({'発売月' : sales_day_all["発売日"].dt.strftime('%Y-%m'),
                   '初動枚数' : sales_day_all.fillna('0')["初動枚数"].str.replace(',','').astype('int'),
                   '累計枚数' : sales_day_all.fillna('0')["累計枚数"].str.replace(',','').astype('int'),
                   '売上高' : (sales_day_all.fillna('0')["セールス(円)"].str.replace(',','').astype('int') /10000).round(0) # 売上高(万円)単位で出すため除算
                  })

df_groupby = df.groupby("発売月",as_index=False).sum()

# 発売年単位でサマリする
df_groupby_year = pd.DataFrame({'発売年' : sales_day_all["発売日"].dt.strftime('%Y'),
                                '初動枚数' : sales_day_all.fillna('0')["初動枚数"].str.replace(',','').astype('int'),
                                '累計枚数' : sales_day_all.fillna('0')["累計枚数"].str.replace(',','').astype('int'),
                                '売上高' : (sales_day_all.fillna('0')["セールス(円)"].str.replace(',','').astype('int')/100000000).round(4) # 売上高(億円)単位で出すため除算 
                               })

df_groupby_year = df_groupby_year.groupby("発売年",as_index=False).sum()

# googleTrendsを月単位でサマリ
df_trend_month = pd.DataFrame({'月' : df_trend["週"].dt.strftime('%Y-%m'),
                               'トレンド数' : df_trend.fillna('0')["トレンド数"].astype('int')
                             })

df_groupby_trend = df_trend_month.groupby("月",as_index=False).sum()

# googleTrendsを年単位でサマリ
df_trend_year = pd.DataFrame({'年' : df_trend["週"].dt.strftime('%Y'),
                   　         'トレンド数' : df_trend.fillna('0')["トレンド数"].astype('int')
                             })

df_groupby_trend_year = df_trend_year.groupby("年",as_index=False).sum()


# JINのアイカツでヒットした投稿数のサマリ
df_jin = pd.DataFrame({'投稿月' : df_jin["投稿日"].dt.strftime('%Y-%m'),
                       'count' : df_jin.fillna('0')["count"].astype('int')
                      })

df_groupby_jin = df_jin.groupby("投稿月",as_index=False).sum()

年単位、月単位のサマリはDataframeでやるのが一番簡単かなということで、Pandasのdataframeのgroupbyとsum()で一気に集計している。

bokehの表示上の都合で、売上高の桁調整をここでやる。 0が多すぎるとうまく表示されない。

pandasのdataframeの一部カラムだけ表示したいなーと思って調べたので、今回は特に使うことないがメモだけしておく。

# pandasのdataframeの一部のカラムだけ表示する
print(df.loc[:,['発売月','初動枚数','累計枚数']])

こんな感じで表示される。

曲線近似の算出

# 曲線近似の算出
# 累計枚数
regression = np.polyfit(df_groupby.index, df_groupby['累計枚数'], 1)

print(df_groupby.index*regression[0] + regression[1])

# 売上高
regression_sales_amount = np.polyfit(df_groupby.index, df_groupby['売上高'], 1)

print(df_groupby.index*regression_sales_amount[0] + regression_sales_amount[1])

曲線近似の算出はnumpyとscipyがあるようだけど、今回はnumpyで実装。
ailaby.com
qiita.com

正直、曲線にする必要は全然なかった。
グラフのプロットはprint文のとおり、CD売上月とCDの累計売上数or売上高で1次関数で算出している。

グラフのplot

時系列データを使ったCD売上推移

# CD売上推移のグラフplot
df_groupby["発売月"] = pd.to_datetime(df_groupby["発売月"])

# CD売上のplot
p = figure(plot_width=800, plot_height=400, x_axis_type="datetime", title="CD売上推移")
p.line(df_groupby["発売月"], df_groupby['累計枚数'], line_width=3.5, color="red", alpha=0.5)
p.circle(df_groupby["発売月"], df_groupby['累計枚数'], fill_color="white", line_color="red", size=10)

# 曲線近似のplot
p.extra_y_ranges = {"graph2": Range1d(start=0, end=11200)}
p.line(df_groupby["発売月"], df_groupby.index*regression[0] + regression[1], line_width=1,color="blue", alpha=0.5, y_range_name="graph2")

show(p)

グラフのX軸と、y軸の説明、グラフの凡例は多少加工しているが以下のような感じで出力される。

かなりシンプルに実装できる。 Dataframeをそのままグラフにplotできるbokehだからこそのシンプルさだと思う。

苦戦したのはX軸をうまく読んでくれないというのがあった。
というのも時系列データにする場合、型をちゃんと日付型にする必要があったんだけど、daraframeでは文字列型だったから。
日付型にto_datetimeしてから再度入れなおすという対応をした。

盛り上がっていた時期を調べるグラフ

df_groupby_trend["月"] = pd.to_datetime(df_groupby_trend["月"])
p = figure(plot_width=800, plot_height=400, x_axis_type="datetime", title="盛り上がっていた時期は？")

# CD売上のplot
p.line(df_groupby["発売月"], df_groupby['累計枚数'], line_width=3.5, color="red", alpha=0.5)
p.circle(df_groupby["発売月"], df_groupby['累計枚数'], fill_color="white", line_color="red", size=10)

# googletrendsのplot
p.extra_y_ranges = {"graph2": Range1d(start=1, end=500)}
p.line(df_groupby_trend["月"], df_groupby_trend['トレンド数'], line_width=3.5, color="green", alpha=0.5, y_range_name="graph2")

show(p)

これもグラフのX軸と、y軸の説明、グラフの凡例は多少加工しているが以下のような感じで出力される。

JINとの比較グラフ

df_groupby_jin["投稿月"] = pd.to_datetime(df_groupby_jin["投稿月"])
p = figure(plot_width=800, plot_height=400, x_axis_type="datetime", title="GoogleTrendsの検索数vsJINの記事数")

# googletrendsのplot
df_groupby_trend["月"] = pd.to_datetime(df_groupby_trend["月"])
p.line(df_groupby_trend["月"], df_groupby_trend['トレンド数'], line_width=3.5, color="green", alpha=0.5)

# JINの投稿数のplot
p.extra_y_ranges = {"graph2": Range1d(start=0, end=20)}
p.line(df_groupby_jin["投稿月"], df_groupby_jin['count'], line_width=3.5, color="blue", alpha=0.5, y_range_name="graph2")
p.add_layout(LinearAxis(y_range_name="graph2"), 'right')

show(p)

基本は前のものと同じなんだけど、このグラフはグラフの右側にメモリを表示するようにした。メモリがあったほうが分かりやすいかなという判断。
p.add_layout(LinearAxis(y_range_name="graph2"), 'right')


折れ線グラフを棒グラフにしたパターンも試してみているので、メモしておく

df_groupby_trend["月"] = pd.to_datetime(df_groupby_trend["月"])
df_groupby_jin["投稿月"] = pd.to_datetime(df_groupby_jin["投稿月"])
p = figure(plot_width=800, plot_height=400, x_axis_type="datetime", title="GoogleTrendsの検索数vsJINの記事数")

# googletrendsのplot
p.line(df_groupby_trend["月"], df_groupby_trend['トレンド数'], line_width=3.5, color="green", alpha=0.5)

# JINの投稿数のplot
p.extra_y_ranges = {"graph2": Range1d(start=0, end=20)}
p.vbar(x=df_groupby_jin["投稿月"], width=1, bottom=0,
       top=df_groupby_jin['count'], color="blue", y_range_name="graph2")

show(p)

その場合はこのようにplotされる。

相関係数の算出

# 相関係数の算出
correlation = np.corrcoef(df_groupby_trend_year["トレンド数"].values.tolist(), df_groupby_year["累計枚数"].values.tolist())
print(correlation[0,1])

相関係数を出すために各dataframeをarrayにしている。 月単位も年単位も同じやろってことで年単位にしてる。

numpy.corrcoef — NumPy v1.14 Manual


相関係数0.75はまあまあ相関しているのかなーっと。

売上高の算出

p = figure(plot_width=800, plot_height=400, x_axis_type="datetime", title="CD売上高推移")

# 売上高のplot
p.line(df_groupby["発売月"], df_groupby['売上高'], line_width=3.5, color="red", alpha=0.5)
p.circle(df_groupby["発売月"], df_groupby['売上高'], fill_color="white", line_color="red", size=10)

# 曲線近似のplot
p.extra_y_ranges = {"graph2": Range1d(start=1000, end=2000)}
p.line(df_groupby["発売月"], df_groupby.index*regression_sales_amount[0] + regression_sales_amount[1], line_width=1,color="graph2", alpha=0.5, y_range_name="foo")

show(p)

グラフの実装は前と同じなので、言うことは特にない。

売上高の算出

# 年別売上高
#売上高でソートしてdataframeのindex振り直し
df_groupby_year_tmp = df_groupby_year.sort_values('売上高').reset_index(drop=True)

# 売上高のplot
p = figure(plot_width=400, plot_height=500, title="年別売上高")

p.hbar(y=df_groupby_year_tmp.index, height=0.5, left=0,
       right=df_groupby_year_tmp['売上高'], color="firebrick")

show(p)

plotするときにソートができそうになかったので、事前にソートを実施。
その時にdataframeのindexを振りなおさないと、結局plotしたときにソートが意味なくなってしまうので、dataframeのindexを振りなおして、y軸にindexを設定している。

ただこれをやるとy軸のメモリの凡例が0～６になるという問題があって、俺は結局グラフの加工でカバーすることにした。
うまい方法ないのかなー。

実装

簡単なplotなのでそんなに実装に時間はかかっていないけど、加工するのめんどい。
けど、加工したほうが見やすいっていうのをここのブログ見て理解した。

speakerdeck.com

shinyorke.hatenablog.com

今まではplotしてはいできたって、実装視点でしか見てなかったんだけど、実際はあれじゃわかりにくかったよなーと。
グラフ中に分かりやすく書いてあげるってのが必要だと思ってた。
気づかせてくれてありがとうございますっていう気持ち。

技術書典４で買った本

技術書典4が4月22日に開催された。もう1か月以上前なのか。
俺は北海道在住なのでなかなか行けないけど、今は以下のようなサイトで電子版として読めるんだからいい時代になった。

booth.pm

技術書典4で買った本をメモしておく。

• 脆弱性ってなんだろう? 〜CVSSを知ろう〜
• ソフトウェアエンジニアの情報収集について
• WOWHoneypotの遊びかた

脆弱性ってなんだろう? 〜CVSSを知ろう〜

共通脆弱性評価システム（CVSS）の評価方法について漫画で紹介している本。CVSS V2ベース。
CVSSの評価方法いまいちわかっていなかったので、読んでよかった。

脆弱性を家の錠前に例えているので初心者の俺が読むにはちょうど良かった。

ソフトウェアエンジニアの情報収集について

エンジニアのいわゆるググりかたを教えてくれている本。

技術系の情報収集方法や、質問の仕方みたいなのも書いているので、ググり方よくわからないと1度でも思ったら目を通しておくのもいいかも。

質問の仕方については以下サイトがベース。かなり勉強になるので以下サイトを読んでおいて損なし。
技術系メーリングリストで質問するときのパターン・ランゲージ

WOWHoneypotの遊びかた

セキュリティの勉強のひとつとしてHoneypotを導入してみようと思って買った。

この資料がベースになっている。
speakerdeck.com

上記のほかに実際に導入する手順も入っているので、いざ入れようとなっても詰まらないんじゃないかなーと思う。

まだまだ読みたい本

まだ買っていないけど、読んでおきたい本もある。

技術書典でかなり有名なこれは買ったほうがいいかなと思ってる。DNS本。
booth.pm

あとはvvvv本。VJやってみたいなーって思っているので。
booth.pm

5月読んだ本

読んだ本の内容を忘れないようにメモしておく。
5月から今更kindleを使い始めて読書がはかどるようになってきた。
ただやっぱりデータより実物買ったほうが買った感あっていいよなー。

あと、簡単な感想はツイッターに書いたりしているのでそこから思い出すんだけど、まとめて書くとかなり時間がかかる。
次から1冊単位で書こう。

売る力 / 鈴木敏文

売る力 心をつかむ仕事術 (文春新書 939)

うちの会社のマーケティングチームから鈴木敏文氏の本は読んだほうが良いとの話を聞いて読んでみた。

セブン&アイ・ホールディングスを創り上げた人間の仕事術として、商品のどこをこだわったのかを軸に記載さてている本。

この本の主軸は変わらない視点に対して、いかに新しい要素を加えていくかという点。

ざっくり概要を書く。

新しいものをつくためには

新しいものを作るためには予定調和を壊す必要があるが、それは奇をてらったものでは一時的に話題になっても定着しない。

定着させるためには、変わらない視点に対しひとつアクセントを加えることで発生する、おやみたいなレベルの壊し方が重要。

一時的な爆発力よりも、客に期待を継続させ続けるということが必要。

この本では上質さと手軽さをx,y軸として置いたときにどこに誰も参入していない空白地帯を見つけるかというのが書かれている。

その軸のいずれかが、変わらない視点であってその軸を変えないことが肝要である。

二匹目のどじょうを狙うと大体うまくいかないので、それよりは現代の消費者が最も関心を持つだろう2つの座標軸の空白地帯を見つけること。

ビジネスの成功

ビジネスには運の要素がある程度あるが、運は自分がいかに呼び寄せるような一歩踏み込んだ挑戦や努力をしたかである。

自分がうまくいっていないと思う場合、運よりも自身が何かに縛られていたり、安易に妥協していて幸運と出会いにくい働きかたなのではないか。

畑違いでも観点は同じ

自分とは全然畑違いだが、自分が言われることや意識しようとしている観点が同じだなと思うことがあった。

特に変わらない視点に対して何を組み合わせていくかという点は、自分がどの分野で生きていくかを決めるときに役立つんじゃないかと思う。

自分の視点がない状態でプロジェクトにいた場合に、提案されるものに対してこうだという理由も出しにくいし、逆に言われたことに対する突込みも出てこない。

そういう点でいかに自分の変わらない観点を持つかっていうのは大切だし死ぬ程言われていることなので。

非社交的社交性 大人になるということ / 中島義道

非社交的社交性 大人になるということ (講談社現代新書)

中島義道を薦められたので、読んでみた。

全２部構成で1章が自身の半生を顧みるもの、2章が自身の主催する哲学塾にいる不思議な人たちについて書いたもの。エッセイみたいな本。

カントを研究している人なので、カントの哲学について書かれている。

自殺

その中で完全義務と不完全義務について書かれていて、自殺は楽になりたいという気持ちからくるのであれば、それは理性よりも快楽を求めるため完全義務に反するというのはなるほどなと思った。
qlocozy.com

他人を恐れる

他人を恐れる人は決まって他人による自分の評価を恐れる人、他人によく思われたいという気持ちが強い人である。
どうせと呟いて自暴自棄にならないためには、自分を評価する２つのいずれかの存在が必要。

1. 自分のやっていることが認められること
2. 自分を心から愛する人、評価する人、理解する人が存在すること

これはよくツイッターで言われるような承認欲求を満たすにはに該当する内容で、俺も承認欲求を満たされたいので、俺のやってることを誰か認めて理解してちやほやしてくださいｗ

最速の仕事術はプログラマーが知っている / 清水亮

最速の仕事術はプログラマーが知っている

有名プログラマ清水亮のライフハック本。
以下の５章で構成されている。

1. 迅速で無駄のない仕事術
2. 情報の整理術
3. 致命的なミスを行わないための段取り方法
4. チームの成果を最大化する
5. 視野を広げてビジネスを設計する

内容としては筆者の経験を元にしながらtipsを各章５～１０程度紹介する構成となっている。

迅速に作業を行えるための辞書登録しようやword使うな、情報収集に検索方法を工夫しろとか、情報整理にevernote使ったほうがいいというレベルのもの。

この本を読む人はきっと一般の人というよりはSEに寄っている、あるいは趣味でプログラム触っているひとみたいな感じなのだろうか。

おそらく一般の人が読むと読みにくい箇所もあるかもしれない。
ループの話をしたりプログラミング用語も多少出てくるので、なじみなければ読みにくいかもしれない。

SEの人が読むと2015年の本でもあるので、今更感のある話もあったりすると思う。ネットのライフハック系の記事で見知った内容もあるかもしれない。

読んでいて微妙だなって思ったのは、各章で人称にばらつきがあるという点。私だったり筆者だったり。そこは合わせてほしい。

こうすれば必ず人は動く / デール・カーネギー

こうすれば必ず人は動く（文庫）

『人を動かす』のほうが有名だと思うが、デール・カーネギーのラジオ講座の書籍版。
『人を動かす』と同じかどうかは未読なので分からないけど、基本はおなじなのではと。

全23章に対し人を動かすためにはどのようにすべきか解説しつつ、ラジオドラマ形式のセリフページで再現する構成。

今も書店で平積みで置いていることの多いカーネギー本なので、いろいろ興味深く読めた。

ザクッとかく。

誤りを犯した場合

自分を守るためにも、まず間違いを犯したら、速やかに十分にそれを認める。

他人に間違いを伝える場合

他人が自分に協力したいと思わせるように、その人自身の間違いに気づかせる。

他人の前で叱責して辱められるとやり返そうとするだけ。
自分が扱ってもらいたいように他人を扱う。

その人自身の過ちを気づかせるのであれば、その人の感情を傷つけないようにそのその人の面目が保たれるように思いやりを持って行う必要がある。

自分自身に対しての気持ちの持ちよう

「自分のことを自分がどう思っているのか」が重要。

自分に勇気がなければ、今すぐに勇気を持つ。

胸を張って自分は強い人間であることを体を使って表現する。そうすることで次第に勇気が自分のものになる。

また自分で自分を蔑まない。それを相手の前で言わない。自分で自分を蔑むことで相手も自分を蔑むようになる。

自分のことを考えるのをやめる。
勇気が持てない理由の一つに他人が自分のことをどう思っているのかに対して恐怖心を持っているから。恐怖心は克服できる。

他人は自分のことなんて考えていない。
自分を見ているという感じはただの錯覚。

他人も自分と同様に自分のことしか考えていないし、自分と同じように他人が自分をどう思っているのか気にしている。

相手を味方につける

相手の興味について興味を示す。

自分のことではなく、相手のことについて話をすることで相手は何時間でもしてくれるし、そういう自分を気遣ってくれる相手に対して味方になる。

自分のことを忘れて無私の気持ちで興味・関心を抱くことで友人を作ろうと思わなくても友人ができる。

人から興味を持ってもらいたいと思うなら、人に対して興味を持つこと。

自分のことを考えることをやめ、自分がいかに素晴らしいのか語って大したものだと思われるようにしないことが重要。

自分が成功するためには

成功するためには自分に与えられた仕事を遂行するための脳力を決して疑わないこと。

実際にトライしてみると自分が思っている以上のことができる。

自分の年齢に誇りをもつ。
隠したり偽ったりせずに、歳を取ることによって培われる判断力、信頼性、経験があるということを確信する。

時間の使い方

自分が時間をどのように使っているのか、それを把握することが大切。

1日の計画を立てることによって、焦りと優柔不断という成功を妨げる要素を排除できる。
また、自分なりの目標を立てる。毎日、ある一定のことを成し遂げようと心に決める。

目標を立てることで、締め切りが発生してそれに間に合わせなければならないというときに最も大きな成果が上げられる。

情報セキュリティハンドブック

情報セキュリティハンドブック

内閣府が無料に配布しているので読んでみた。
kindleで無料配布しているのと、内閣セキュリティセンター（NISC）でも無料配布している。

www.nisc.go.jp

全部で5章に分かれていてそれぞれ以下のとおり。

プロローグ　サイバー攻撃ってなに？
第１章　基本のセキュリティ ～ステップバイステップでセキュリティを固めよう～
第２章　セキュリティを理解して、ネットを安全に使う
第３章　スマホ・パソコンのより進んだ使い方やトラブルの対処の仕方
第４章　被害に遭わないために、知らない間に加害者にならないために
第５章　自分を守る、家族を守る、災害に備える
エピローグ　来たるべき新世界

読んでほしい対象はセキュリティに対して知見のない人。
全編通してイラスト付きで説明しているので、とっつきやすいと思う。

本当にセキュリティのことを知らない人、一般の人は第2章から読むことをお勧めしたい。

第1章は、セキュリティを勉強したい人、基本情報試験の勉強している人は、最初の第一歩として読むのにはすごい適していると思うが、一般の人には難度が高い気がする。
途中でイラストがなくなるページも数ページ続くので、読むのがきついと思う。

セキュリティリスクの話をする本ということもあるからか、2章以降、基本的に物事を悲観的に見てることが多いので、ちょっとそこは気になった。

日経ネットワークの「インターネットができるまで」メモその2

日経ネットワーク2018年5月号の「インターネットができるまで」がよくまとまっており学びがあったので、学んだところをメモする。続き。

snofra.hatenablog.com

TCP/IP：データを小包に分けて送る

ここではTCPからTCP/IPへの変遷について記載されている。
TCP/IPについてはある程度の知識は持っているが、TCP時代の話は知らなかったので勉強になった。

TCPとTCP/IP

1974年当初トランスポート層とネットワーク層は分割しておらず１つだった。それがTCP。
1978年にトランスポート層(TCP)とネットワーク層(IP)が分割することになった。

その間4年なので結構短い。

なぜ分割されるようになったのか

TCPのプロトコルTCPかUDPかを判断することになるのだが、送信元と送信先間のみで必要なプロトコル。

送信元と送信先間に存在するルータはこのプロトコルは不要というか、むしろ経路だけ確認すればいいルータにTCPなのかUDPなんて負荷がかかってしまうだけなので分断。

フラグメント処理

ルータはパケットのMTU(Maximum Transmission Unit)に合わせてパケットを分割（フラグメント処理）を行いつつ、送信先へ。
一度分割されたらマージされることはなく、送信元でパケットを結合してデータを取り出すことになる。

IPアドレス：みんなが自分だけの住所を持つ

IPアドレスについての歴史と、IPv4が枯渇しているということが記載されている。

IPアドレスの振り分け

IPは自分で好き勝手に割り当てられるものではなく、一元管理される。IANA(Internet Assigned Numbers Authority)（アイアナ）で管理していた。

だが、運用費用の一部を米国政府の研究費用に使われていたことが非難されて、1998年にICANN(Internet Corporation for Assigned Names and Numbers)（アイキャン）が設立。
IANAが担っていた役割は2000年にICAANに引き継がれた。

引継ぎまでに17年かかっているの意外に時間かかってるなあと。

クラスによる割り当てについて

クラスによる割り当てとCIDR(Classless Inter-Domain Routing)による割り当てがある。

CIDRってどんなのだったっけとかたまに超初心者感出しちゃうんだけど英語でみるとそのまま書いてるのね。
クラスによる割り当てとクラスじゃない割り当てってこと。略語の理解大事。

なぜCIDRが使われるのか

そもそもクラスはIPアドレスの分類のことを言う。
クラスによる割り当ては基本クラスA～C*1*2まである。

• クラスAがネットワーク部8ビット。0.0.0.0～0.255.255.255
• クラスBがネットワーク部16ビット。128.0.0.0～128.0.255.255
• クラスCがネットワーク部24ビット。192.0.0.0～192.0.0.255

じゃあなんでわざわざクラスじゃない割り当てであるところのCIDRを使い始めたかというと、

アドレスクラスを用いたIPアドレス割り当てには問題が生じた。ほとんどのネットワーク（たとえばインターネットサービスプロバイダ）ではクラスAでは大きすぎ、クラスCでは小さすぎたため割り当ての要求がクラスBに集中したのである。クラスBの割り当てを受けたネットワークの中には65,534台のホスト（インターネットサービスプロバイダであれば接続ユーザー数）を同時にすべて接続することがまれであるネットワークも存在し、IPアドレスが無駄に消費されることになった。

IPアドレス - Wikipedia

クラスAだと割り当てられるIPアドレスの数って1677万721で、クラスBが6万5536、クラスCが256の固定値で絶妙に使いにくかったから。

小さいネットワークを作ろうと思ったときにクラスAだと多すぎて、そんなにIPアドレス使わないのに維持管理に余計な工数かかるので、まあ松竹梅の竹選んどこ的な感じでクラスBが使われることが多かった。

とはいえクラスAもBも無駄多いので、動的にネットワーク変えられないの？って思って誕生したのがCIDR。

IPv4の枯渇

上で書いたIPアドレスのことをIPv4って呼ぶが、その番号誰が割り当ててくれるのってICANNであり、日本だとAPNIC(Asia Pacific Network Information Centre)という地域インターネットレジストリ(RIR：Rogional Internet Registry)が割り当ててくれる。

日本はJPNICという国別インターネットレジストリ(NIR：National Internet Registry)に所属しているが、JAPANICはIPアドレスの在庫を持っていないので、APNICに払い出してもらうことになる。

そのIPv4はもう枯渇していて、2011年4月にIPアドレス在庫が枯渇している状態。
これからの話じゃなくてすでにないという。

IPv4アドレスの在庫枯渇に関して - JPNIC

とりあえずは企業から返却されたIPアドレスを使っているが、IoT時代でとにかくインターネットにつないどけば、機械学習とかで分析できるやろな感じなので余計に枯渇するよねって話。

たまに見る光回線なのにインターネットクソ遅い問題みたいなのは、IPv4の上限ギリギリでみんな使ってるから混んでいるという話もあったりする。

IPv6にすることで早くなるみたいなのって結局誰もIPv6使ってないからという話で、今は早いかもしれない。
www.itmedia.co.jp

IPv4やべえって話。

*1:実際はDとEもあるが、Dはマルチキャスト用。Eは未使用

*2:第8回 アドレス・クラスとさまざまなIPアドレス (1/3)：基礎から学ぶWindowsネットワーク - ＠IT

日経ネットワークの「インターネットができるまで」メモその１

日経ネットワーク2018年5月号の「インターネットができるまで」がよくまとまっており学びがあったので、学んだところをメモする。

構成としては以下となっている。

1. プロローグ：たった４拠点から始まった
2. TCP/IP：データを小包に分けて送る
3. IPアドレス：みんなが自分だけの住所を持つ
4. ルーティング：事故が起こったら道順を変える
5. DNS：通信相手を名前で指定する
6. Web：世界中で情報を共有する

１についてはインターネットの歴史、2～6についてはOSI参照モデルのネットワーク層とトランスポート層とアプリケーション層について書かれている。

プロローグ：たった４拠点から始まった

ここではインターネットの起源であるAPRANET*1についてと、回線交換とパケット交換の違いについて、現在のインターネットについて書かれている。

読んだ感想

回線交換とパケット交換の違いについてはイラストが分かりやすかった。

回線交換方式はひとつの端末が通信を独占してしまって、使ってないときもその通信回線が独占されっぱなしでもったいない。
だからデータをパケットという小さい範囲で区切って送れば無駄な時間なくなっていいんじゃないかみたいな考え方。
そうすることで異なる端末からパラレルで送信できるし、あて先が同じパケットを別経路で送ったっていい。冗長化も生まれてきた。

今までパケット交換方式のことは知っていたけど、回線交換方式を知っておくことで歴史の流れから特徴がうまくつかめた気がした。

輻輳について

輻輳というワードいつも忘れがちなのでしっかりメモしておく。

輻輳とは、さまざまな物が1カ所に集中することで、通信分野では、電話回線やインターネット回線にアクセスが集中することをいう。輻輳が起きると回線がつながりにくくなったり、集中した通信システムがダウンするといった現象が起きる。システムのダウンを避けるために、輻輳が起きそうになった場合には通信を制限する輻輳制御という措置が取られる

輻輳 | 用語集 | KDDI株式会社

俺たちがときどき感じてるネットつながんねえな感じが輻輳状態ということ。しっかり覚えておく。

でもって、輻輳に関連して、フロー制御と輻輳制御がある。ともにトランスポート層。

フロー制御

データをパケットという塊で相手に送るが、送信側がパケットを投げまくるけど受信側がさばききれないという場合もある。
さばききれないと取りこぼしてしまうのでTCPの場合、後でもう1度再送してもらわないといけない。

イメージ的には工場のラインで、流れてくるものがすごい多かった場合そりゃさばけるわけない。だけど、さばかなきゃいけないので漏らしたものはあとでまた流しなおしてもらわなければいけない。

それって正直無駄。
なので、受信側が送信側に受信可能なデータサイズを送るようになっている。これがウィンドウサイズ。
このウィンドウサイズによって送る量をコントロールするっていうのがフロー制御。

輻輳制御

輻輳制御っていうのが、通信開始したときにじゃあパケット送るかって大量のデータを送り付けてもネットワークが混んでいる可能性がある。

2車線道路で道路が混雑しているときに2車線すべて使う車が来たとしたら、クソ迷惑。
それやめましょうねってTCPだとスロースタートというアルゴリズムで通信量は少なくしている。

また、何らかの原因でネットワークが混雑している可能性があるので、その時にも通信量を少し抑えましょうねっていうのが輻輳制御。

詳細は『マスタリングTCP/IP 入門編』を参照のこと

マスタリングTCP/IP 入門編 第5版

インターネットの歴史がいまいちわからなかったので整理

登場用語

まず用語。
ISPはInternet Service Providerの略。ドコモとかauとかのこと。
ISPはその規模によってTier1とTier2で分けられていた。日本のTier1はNTTコミュニケーションズのみ*2
Tier1とTier2の間はIX(Internet eXchange Point)がいる。ISP通しの中継をやっているもので、各プロバイダ間、プロバイダ(Tier2)とNTT(Tier1)の中継を行っている。*3

インターネットの歴史について

以前10年位前まではTire1とTire2で明確に階層構造となっており、Tire2同士の接続は無償で相互接続を行える（ピアリング）。Tire2からTire1に対しては了以金を支払って接続（トランジット）していた。

最近はこの階層後続が崩れ始めている状態。

原因は米グーグルや米Akamai、米Facebookなど大手のトラフィックを持つハイパージャイアントと呼ばれる企業がCDN(Contents Delivery Network)をやり始めたから。

CDNというのは、たくさんの人がインターネットを使うようになってアクセスも増えてくる。そうしたときに当然サーバにアクセスが集中するんだけど、輻輳制御とかいちいちやっていたのでは遅くてしょうがない。
なので、CDNとしてサーバを分散させたほうがアクセスが集中しないでいいよねっていう考え方。*4*5

ハイパージャイアントが何を変えたかというと、Tier2はわざわざ金払ってTier1にトランジットしなくても、グーグルとかAkamaiとかCDNに直接ピアリングでよくなったということ。

この点でいいところはピアリング、つまり金払わなくていいということ。ハイパージャイアントの収入はコンテンツホルダだったり広告費だったり。
逆にハイパージャイアントのネットワークが落ちた場合、ウェブサイトに接続できないという大規模障害は発生する可能性がある。

[参考]
https://www.janog.gr.jp/meeting/janog33/doc/janog33-traffic-kamei-1.pdf
大規模な接続障害、Googleが謝罪 「ネットワークの誤設定」原因 - ITmedia NEWS
大規模ネット障害になっても不思議じゃない？「BGP」の仕組みとリスク | 日経 xTECH（クロステック）

ながくなったので、次で「TCP/IP：データを小包に分けて送る」以降の学びをメモしていく。

*1:Advanced Research Projects Agency NETwork

*2:ティア1 - Wikipedia

*3:http://wa3.i-3-i.info/word11497.html

*4:コンテンツデリバリネットワーク - Wikipedia

*5:https://blog.redbox.ne.jp/what-is-cdn.html

engineer meeting podcast vol.112の曽山さんの話がかなり良かった

聞いてて久々にすごい放送聞いたなって思ったので取り急ぎ書いておく。

engineer meeting podcastは株式会社サイバーエージェントに所属している方が技術論やリーダー論を話しているラジオ番組。

vol.112は株式会社サイバーエージェントの取締役 人事統括、株式会社CyＣＡＳＴの代表取締役社長の曽山哲人さんがゲスト。

この人の話が本当によかったので、自分の琴線に触れたところを簡単にまとめつつ、感想を書いておく。
エンジニアとかコンサルの人、それ以外の人もかなり面白い話をしているので聞いてみたほうがいい。

soundcloud.com

人を効率よく回せるのは6人程度がちょうどよい。

5、6人の小さい単位で成果が出るメソッドを確立するということにこだわったほうがいい。
50人とか大きい範囲は無理だと認めたうえで、小さい軸で機能させていく。人数が増えた場合は小さく割っていく。

人が見られる数で自分の目で面倒みられる限界値も6人とかそういうレベルなんだと思う。

6人超えると業務上、互いにかかわらない人も出始めてきて、ひとつの集団としてやっていくのはなかなかむつかしいのかなと。

進捗確認の朝会や夕会やるにしても6人以上の参加者がいると情報共有の内容よりも時間をロスしているなってことが多い。

単なる作業進捗は小さい単位でなるたつ手法かなと思っていて、多いと単純に自分の番が回ってくるのも遅いし、何も言わなくてもいいかなという当事者意識も薄れていくので。
ファシリテートするほうも人数が多いということは、なめていく量も多いのでそれだけだらだらやってるのと変わりない。

少人数で互いを補い合うような体制作りを目指したほうが、自分がいないとだめだと思って当事者意識もって取り組めるのかなと。

それがこの回で話されている

育てるために心がけることは、小さい集団で自分でやっているという経験を早く持ってもらう。リーダー経験をしないとそれが身につかない。

というのにつながってくるのかなと。

大人数の場合はリーダー経験積みたくてもある程度レベル分けされているので、上の人が自然とその立ち位置につくことがおおく、
若手のチャンスはなかなか降りてこない。

よいエンジニアは意味づけの力をもつエンジニア

自分の仕事にどんな意味があって、これが広がるとどうプラスになるのか自分なりに考えてる人は活躍する。

これも当事者意識につながってくるんだと思うんだけど、自分の割り当てられた作業をいかに楽しくやるかって、今やっている作業っていったん何だろうと想像して答え合わせしていくことなんだと思う。

答え合わせは直接的に聞くものだったり、自分の中の別のプロジェクト経験と紐づけて新しいものを組み合わせたりとか。

フィードバックとか評価の心がけ

人と人は立場関係なくずれていくもの。
ずれていくことを前提に途中で月１回面談する等で互いに経験チェックをする。
そしてずれを補正しあうことで心理的安全性を高めることができる。互いに心理的安全性を担保したほうが組織がまとまる。
実施する頻度や時間は成果を出すために必要な時間。それは上司と部下で合意が取れる頻度にして、相手に確認したほうが良い。
伸びる組織はアンド思考。AとZを共に生かす。どうやったらアンドになるかを考えて、落とせるのが伸びる組織。

これはほんとそうで、人と人は基本認識が合わないものだと俺も思っている。

だからこそフィードバックするときはきちんと、互いのずれなく話すべきだし俺は話すの苦手なので絵を使ったりして話すように心がけてる。
やっぱ絵描いたほうが変に空中戦するよりも分かりやすいと思っている。

学生の人にアドバイスするなら

とりあえずなんでもいいからリスクをとる
研究やるなら話題なりそうものをやる。そのうち自分でサービスやりたいならこの１年でサービスだす。
リスクをとったらとった分だけ、自分にしかわからない学びがある。
リスクとはその人がいつもやっていることと違うことをやることで感じる「ひやひや」。

これはもう心が痛い話で、俺はあまりリスクとっていかない人間なんだけど、それだと知識も地位もアドバンテージとりにくいってのはすごく感じてる。

ただやっぱ勇気がいるっていうのもそのとおりで、伸びていくのってその勇気の最初の一歩をいかに踏み出せるかって感じだと思う。

ダメならダメでしょうがないという感覚だったり、誰かが助けてくれるだろみたいな楽観視がある程度は必要なのかもなあと。

選択肢を広げる（キャリアオプション）

今は変化が激しいのでキャリアパスやキャリアデザインができる時代ではなくなってきている。
キャリアの選択肢を複数持ちながら、その中で今自分に来ているオファーや部署移動の案内などから自分にはまるものを選んでいく。

またキャリアはアップデートし続けることで成長するが、掛け算でアップデートしていくことが一番伸びる。
自分の武器×新しい分野×新しい分野……と掛け算していくことで、常に強みが残っている。掛け算にすることで他社に真似できないキャリアになる。

もしオファーが想定外のものの場合乗ったほうがよい。会社やチーム、上司の期待に応えるだけでも関係性はよくなる。
わざわざ自分を選んでいるので、このオファーで伸びる要素があると思われている。
そのため、想定外のオファーは乗るだけで他者の官舎や期待が掛け算で乗ってくる。これだけで価値がある。

自分のキャリアオプションを持ちながら想定外の依頼は乗っかってみるのがおススメ。

自分はこれ強みかなって思うことって結構あったりするんだけど、それ単体だと意外に大したことなく終わっていくことが多い気がする。

それってその強みの枠の一歩外を出てないから、結果普通なんだよなあと。
その不変である強み、視点に対して、別の視点を置いていくことで自分にとって新しいコラボレーションになるのかな。
その層の蓄積をし続けることでほかの人と圧倒的に違う感じが出てくるのかなあと。

自分と「アイカツ！」というコンテンツについて改めて感じたこと

そういう星のもとに生まれているのか、年に１回は酒の場でハラスメントに遭って揉めるのだが、謎の気づきがあったのでメモする。

TL;DR

自分が自分の想像以上に「アイカツ！」というコンテンツが好きで大事にしているものであったかを自分が初めて理解できた。

顛末

今回はアイカツ！を１回も見てない上司のおっさんから、ごみだとクズだの言われたっていう、一見したら別に何ともない話だったりする。

そのおっさんは俺のバックボーンをあまり理解できていないというのもあって、何も考えてないだろうしネタみたいな話だと思ったんだろう。

俺のバックボーンを知るチームメンバーから見たら、

• チームに入ってきた直接的要因が「アイカツ！」というコンテンツであった
• それがどれだけ好きなのか

ということは知っていただろうから、（内心ごみだとは思っているが）特段何も触れなかったんだろうと思う。

言われたときに、俺の好きなコンテンツを否定するとは何事だ！みたいな気持ちではなく、純粋に悲しいという感覚のみ介在している感覚だった。

俺は「アイカツ！」というコンテンツをもっと理解したいなという経緯から、分析等のアナリティクス世界に入ってきたということもあり技術的側面、
「アイカツ！」シリーズのアニメから自分の精神的なものを支えているという認識はあった。

それが自分の中でどの程度の比重を占めているのかなんて考えたこともなかった。
自分が悲しみに暮れてしまうほど、自分の中で重要なものになっているなんて思ってもいなかったので、それに一番驚いた。

正直

アルハラしてくる会社に在籍し続けるってのは、善良な人に対してもこいつらも俺を人格攻撃してくるんかと思ってしまうし正直きつい。*1
取り敢えず２年連続ヒットしたので、会社の飲み会はもう行かない。

信用値も底値だし、とっとと辞めようとは思っている。

北海道の企業転職きつめだけど探し始めるところにきたかなと。
とりあえずアニメ好きなおっさんを許容してくれる会社な。

*1:多様性を考えてますとか言ってる会社でアニメ好きなのはディスってOKの傾向なんなん？