四十三庵

蔀の雑記帳

Excelのピポットが使えるようになった瞬間に、世界に光が満ちて、病気が治って、会社の業績が三倍になった

タイトルの通りなんですけど、Excelのピポット機能ってすげー便利だなと思ったのでその紹介記事です。

ピポットを使うことになるケース

仕事してて、こんなデータがあったとするじゃないですか。
f:id:st43:20170731221630j:plain
このデータから、「商品名ごとの個数が欲しいけど、30分で出せるか?」(場合によっては何時〜何時まで)みたいなこと言われたら、あなたはどうしますか?
この例だと全部映ってないですが、実際は1000レコードくらい行がある。

たとえばだけど、商品名があらかじめ10個しかないとわかっていれば、countIf()とかでいいかもしれない。
10個の商品名を並べて、隣のセルに=countIf("A1",商品テーブル)とかいれて、千行ペロってコピーすればいいと思う。
ただ今回の場合、そもそも商品名の一覧なんてわかんなくて、そこから作成しないといけない、という前提。

マクロを書くのも一つの手だ。
けど実際のところ、VBA書いたりメンテしたりすんのはけっこう時間がかかる。
上手いこと再利用できればいいが、実際はその時々の特殊な状況で動けばいいやで組むから、
あのときは使えたけど、今回は微妙に違うみたいな場合が多い。

これまでの僕は、集計処理のためにマクロを書いていた。
最初は満足感があったが、だんだんほとんど再利用できていないことに気づいた。
そんなときに「発見」したのがピポットだった。

ピポットで1000件のデータを集計してみよう

実際にやっているところを見てみよう。
f:id:st43:20170731223725j:plain
まず、1000件のテーブルを選択して、ピポットテーブルを挿入する。

そうすると初見だとちょっと戸惑う感じのウィンドウが表示される。
とりあえず「列ラベル」と、「値」を商品名にしてみると……
f:id:st43:20170731223841j:plain
見事にやりたかった集計が完了した!

クロス集計とかもできる

これだけでも僕的にはけっこう使いみちあるなと思ったが、このようにクロス集計もできる。
f:id:st43:20170731224148j:plain
「EEEという商品が大阪ですごい売れてるなあ」というのが一目瞭然である。

ラベルの要素はいくらでも増やすことができるので、
「商品名」×「購入店」&「購入時間」というピポットテーブルもつくれる。
f:id:st43:20170731224421j:plain

フィルター機能とピポットでたいていの集計はできる

ピポットはすごいが、ピポットのすごさを享受するためには、
データがそれなりに整形されていないといけない。
その作業がけっこうしんどい。
でもまあフィルター機能使って、要らないレコードをうまいこと消していけば、いけると思う。

AIが人間の仕事を奪うと言われているが、「AIが分析しやすいように一次データを整形する作業」は絶対に残ると思った。今日。

あとがき

最初10万レコードでやろうとしたらExcel for Macが死んだので、
1万レコードでやりなおしてもやっぱり死んだので、1000でやりました。
うーん……
(了)

90年生まれの僕が自分を金持ちになったなと思った瞬間

iTunesで新作の音楽をダウンロードして聴いたり、Kindleでマンガ買いまくったりしてると、自分が金持ちになったなと感じる。
大した話ではないんだけど、これって結構デフレ世代っぽい感覚なのかなーと思ったので、一筆書いてみる。

働く前

高校生とか大学生だったとき、どういう風に音楽やマンガと付き合ってたか。
著作権的には完全アウトだけども、ネットにあげられてる音源とか、漫画とかをダウンロードするという手があった。
WinnyとかTorrentとか、ファイル共有ソフトを使うと更によかった。
けれど僕は金がないなりに節度は持っていたので、TSUTAYAとかブックオフによく行っていた。
したがって、流行の最先端からはいつも遅れることになった。
もともとトレンドを追うことにそんなに興味がなかったので問題はなかったけれど、
好きなミュージシャンの新譜が出てるのに、レンタルになるまで待たなければいけないのはそれなりに悲しいことではあった。
けれどTSUTAYAのレンタルは、CD五枚で1000円とかだったので、一枚あたり200円で借りられた。
アルバムを新品で買うと3000円なので、結構な金額差だ。
高校生当時、いくらこづかいをもらっていたかは忘れてしまったが、まあとにかく、3000円は大きな出費だった。

片道二、三十分かかるTSUTAYAまで自転車を漕ぎ、青い袋(今はなくなった)にCDを五枚つっこんで帰り、
パソコンのiTunesで曲をインポートした。
インポートはCDの傷つき具合にもよったが、十分ぐらいの作業だった。
この作業にはリッピングというカッコいい名前がある、と知ったのも最近のことだ。
インポートが完了したら、iPodをつないで、iTunesと同期する。
あとは一週間以内にまたTSUTAYAまで自転車を漕いで、返しに行く。

何もない休みは、ブックオフで二、三時間立ち読みしたこともあった。
社会人になってから同じことをしようとしたが、十分ともたなかった。
別に立っているのが辛いとかではなくて、単純にそこまでの情熱を持ってマンガと向き合えなくなった。
マンガはCDに比べると安かったので、気に入った作品だけ新刊を買っていた。
好きなマンガはたくさんあったので、全部買うわけにはいかなかった。

あと本読むときは図書館で借りてた。

優しくない価格設定

インターネット上ではよく「クリエイターには適切な対価が払われるべき!」という言説を唱えて、周りから同意・賞賛されるという美しい光景がある。
けど学生時代は何をどうしたって定価のCDは買えなかった。
もっとバイトしろよとか、本当に好きなミュージシャンなら親に泣きついてでも買うべきだとか言われてしまうかもしれないが、とにかく昔の僕はそういうやり方をしていた。

働き始めてから思ったが、色んなモノの価格はだいたい正社員の給料をベースに決められているように感じる。
そりゃそーだろ、と言われるかもしれないが、これは僕にとって一つの発見だった。
CDの値段とか、野球場の飲食物の値段とか、観光地のメシとか、学生時代はただただ高いなと思っていたが、
働き始めると「まあ高いけど、場所が場所なのでこんなもんか」と思うようになった。

iTunesの曲は、一曲250円する。
アメリカだと1ドルらしいので、普通に高い。
高いけれど、実際買ってみると便利である。
TSUTAYAに行くために自転車を漕ぐ必要もないし、レンタル中ということもないし、リッピングする必要もない。
部屋の場所もとらない。

マーケティングしてる人間からすると、金を出せない人間は、最初から相手にしてないのだろう。
まあ確かに、アルバム一枚200円で聴いてる人間に対してマーケティングしても、利益にはならない気がする。
(了)

プログラミングを勉強する前に知って欲しいアプリが動く仕組み

大学時代の友達から「プログラミング教えて!」みたいなことを言われたので、
内心やれやれと思いながら、会話をした。
「何をつくりたいの?」
「やっぱスマホアプリとかかなあ」
「ほーん」
「最初は無料でもいいけど、人気出てきたら有料化とかして、こづかい稼ぎしたいかな」
「ほーん」
「コストはなるべくかけたくないけど、ヒットは狙いたいな。SNS機能つけたりしたい」
「ほーん。コストかかるとしたらサーバー借りたりかな」
「え? なんで?」
「え?」 
「アプリつくるのにサーバー要るの?」
「なるほど」
確かにサーバーはなくてもなんとかなる。
なくてもなんとかなるが、彼のイメージしてるような、
ソーシャルにユーザー同士が交流するみたいなアプリを作りたいのであれば、サーバーは必
要となる。

そんなやりとりをきっかけに、
「なんかよくわからんけど、プログラミング覚えて、なんかサービスつくりたいという気持ちがあるよ、けど知識はあんまないよ」という人向けに、
アプリが動くざっくりした仕組みについて書いてみようと思った次第です。

記事の対象とレベル感

・プログラミング初心者を想定。
・わかりやすさ重視
・なるべく具体的に
・けどたとえ話でごまかしたりはあんまりしない
・インフラチックな話になるかも
・スマホアプリを例にして書いているが、基本的にはWEBシステムの設計の説明
・ミドルウェアの話は割愛

なんでサーバーが要るの?

たとえば電卓アプリみたいな単純なアプリだったら、サーバーは要らない。
Facebookとかメルカリとかみたいなアプリを作りたいのであれば、サーバーは必要となる。
何が違うのかというと、スマホ上で処理を完結できるか否かの違いだ。

電卓アプリはスマホ上で入力したデータを、アプリが計算して、結果を表示すれば良い。
それで完結する。
Facebookで友達を探すには、探したい友達の名前を検索窓に入力して、
Facebookのデータセンターにあるデータベースに友達を探しにいって、その結果を表示することになる。
別にFacebookのアプリが、ひたすら自分一人で文章を書いたり、写真を投稿したりして、自分一人が見る仕組みなら、
サーバーがなくてもいけるが、よほどの異常者しかそんなアプリは使わないだろう。

どこぞのIT企業がちゃんと作ったアプリであれば、だいたいは裏でサーバーが動いている。
ユーザーはあまり意識しないので、確かに僕の大学の友人のように、
スマホアプリであればサーバーが要らないと思うのも無理はないのかもしれない。

アプリが動く仕組み(ざっくり)

「プログラミング勉強したい!」と言ったときに、
イメージするのは普段自分が使っているスマホのアプリとか、インターネットのブラウザで動いてるWEBサービスとかだろう。
普通にユーザーとして使う分には、裏側がどうなってるかなんて意識する必要はない。
僕も働き始めるまでは、魔法みたいなもんだと思っていた。
ただ実際は魔法ではないので、裏側には泥臭い世界がある。

その泥臭い世界を、ざっくりとあらわすとこんな感じ。
f:id:st43:20170611170713j:plain
ユーザーは、インターネットブラウザかアプリから、何らかの操作をする。
たとえばGoogle検索をかける場合を考える。
検索した文字列データが、インプットとしてサーバーに送られる。
なんか上手いこと処理される。
ユーザーに対して、検索結果を返す。
それを受け取った、PCなりスマホなりは、結果を表示する。

基本はインプット/アウトプット*1の関係で、アプリの処理は進む。
ユーザーから見ると、自分の端末とサーバーの役割分担はよくわからない。
とりあえずなんか入力したらなんか返ってきた、という風にしか見えない。
ただ開発者になるのであれば、裏の役割分担は把握しておきたい。

アプリが動く仕組み(もう少し詳しく)

「なんか上手いこと処理される」と書いたところを、もう少し詳しく説明したい。
f:id:st43:20170611170720j:plain
これが一般的なWEBシステムの構成の全体図だ。
(スマホアプリもサーバー通信しているのであれば同じ)

ユーザーが直接操作したり、閲覧したりする端末で動く側を、「クライアントサイド」と呼ぶ。
「プログラミングするぞ!」というときにイメージするのは、このクライアントサイドのプログラムだろう。
実際のところ、多くのクライアントサイドのアプリは、ネットワークを通じて、サーバーで処理をさせている。
サーバー上の世界は、クライアントサイドに対して、サーバーサイドと呼ばれる。
サーバーサイドでもプログラムはガリガリ動いている。

クライアントから入ってきたリクエストは、まずWEBサーバーで受け付けられる。
WEBサーバーがやっているのは、HTMLリソースの管理やら、コネクションの管理やらだ。
スマホアプリだとWEBサーバーとは呼ばず、HTTPサーバーとかロードバランサと呼んだり、あんまり存在を意識しないっぽい。
画面を表示するだけでよければ、WEBサーバーが結果を返して終わりだが、
もっと高度な処理をするのであれば、APサーバーにデータを引き渡す。
APサーバーは、サーバーサイドのアプリが動く場所だ。
たとえばGoogle検索をかけたときに、実際に検索処理するプログラムなんかが稼働しているサーバーだ。
一般的な構成であれば、APサーバー上にはデータを置かず、DBサーバーに置く。
アプリは必要になったら、DBサーバーへアクセスに行く。

こんな風に、サーバーサイドでは三つの役割分担が行われて、
互いに必要なときにインプット/アウトプットをやりとりしている。

ハードウェア構成

f:id:st43:20170611170717j:plain
先程の図では、わかりやすさのために、物理的に三つのサーバーがあるような図にした。
しかし実際は、一台の中に三つの役割分担があってもいいし、大規模システムであるなら何十台とサーバーを構えてしまってもいい。
こちらの図は、一つのサーバー上に、WEBサーバー/APサーバー/DBサーバーを構えた図だ。
小さなシステムであれば、一台のサーバーに全部置いてしまっていいだろう。
物理的なサーバーを分割するのは、サーバーのハードウェア障害への備えという意味合いが大きい。
一台のサーバーに全部を置くと、その一台が壊れたときに、全サービス停止となるが、
WEBサーバー×2、APサーバー×2、DBサーバー×2みたいな構成だと、
一台サーバーが飛んでも、サービスは継続できる。

プログラミングするためにはそこまでやらないといけないの?

「プログラミングが!!!!!!!!したい!!!!!!!」みたいなキラキラした気持ちをもった人も、
勉強していくにつれて、高度なことをやるにはサーバーサイドで処理させる必要があると気づき。
しかもそれは非常にとっつきづらいし、サーバー用意するにしても金がかかるということで、
知識的にも金銭的にもハードルが高かった。

けど最近はクラウドがあり、AWSがある。
AWSは重量課金だし、あんまりサーバーサイドの深い知識がなくても、
「こんな構成にしたい!!!」という気持ちがあれば、Amazonのサービスを組み合わせることで、必要なインフラ部分が構築できる。

www.slideshare.net

まとめ

・ユーザーから見えている魔法の世界は無数のサーバーのレスポンスでできている
・アプリに高度な処理させたければサーバーが必要
・サーバーサイドはとっつきづらいが、AWSみたいなサービスを使うとよい

補足:サーバーレスアーキテクチャ

今のところ、「スマホアプリ」と言ったときに想像するようなアプリは、基本的には裏でサーバーを構えている。
しかし、クライアントサイドの性能も上がっているので、
サーバーなくてもいけるんじゃないか?という発想もある。
それがサーバーレスアーキテクチャと呼ばれる設計思想。
サーバーレスアーキテクチャという技術分野についての簡単な調査 - Qiita
↑たとえばここを参照。
昔のCGIの見直しみたいな話で、この設計であればAPサーバーが不要となるので、メンテすべきサーバーそのものがなくなる。
けれどレスポンス速度は、普通にサーバーサイドでやるよりも遅いので、そこが解消できるのか。
(了)

*1:リクエスト/レスポンスと書くほうがそれっぽいけど