00:00
こんにちはフリーアジェンダですエピソード208の今回はエクセルについて話をしています
以前エピソード205でプログラミングの本質というテーマでお話ししたんですけれどもその回の続きになっています
もし聞いてない方がいればそちらも合わせて聞いていただけると嬉しいですそれではどうぞ
はいどうもフリーアジェンダです
はいどうもフリーアジェンダです
(音声)
すみませんちょっと犯罪者の人が紛れ込んじゃったと思うんですけど
(音声)
ちょっと怖いなこの人
(音声)
やばいやばいやばいもう戻っていただいて大丈夫です
おはようございます皆さん
はいおはようございますちょっと犯罪者のエイチさんが紛れ込んじゃったけど
はい今回はその犯罪者のエイチさんとエクセルについて話そうと思います
はい犯罪者のエイチさんと話すな
そもそもエクセルって何なんですかね
いやいやちょっと待ってこの話のちょっと流れを伝えておきたいと思って
お珍しい
プログラミングの本質って何ですかって話をしたんですよ
うん
でプログラミングとはまとめて処理することだみたいな
あのーとかなんだ処理を記述することだっていうのが僕らの
なんだ回答だったんですけど
その発展であの物語の終盤で出てきた
エクセルはじゃあその観点から言うとプラグプログラミング言語に当てはまるんじゃないかっていう
僕の仮説をまあ話そうねって言ってそのまましっかり
前回の収録では忘れてたっていうのがスタートになります
うんうんうん
なんでまあ
なるほどね
はいそのエクセルはプログラミング言語に当てはまるのかってことを
まあ今回あのフリーエジェンダで話せればなっていうそんな感じ
すごい良いトピックだなって僕は思いますね
ね良いトピックだよね
良いトピックだしなんかヤモティがそんな良いトピック思いつくなんて
おーいおーい
雪が降るのかなって思うけどそんなことよりさヤモティさん
うんはい
エクセルってなんでエクセルっていう名前なのか知ってるかい
え?わかんない
え?知らないのかい
エクスエクス
セルはセルでしょ
ほう
エクスってなんだ
エグザミネーション
あーすげー
せめにエグザミネーションって何ですか
なんだっけそんな言葉なかったっけ
なんかあるかもしんないエグザミネーション
だからテスト的な意味かな
エグザミネーションはですね僕の記憶だと検査とか
試験とか
そうですね
確かに
いや説2個あるんですよね実は
あ説なんだ
ある2個あってすごいんですでも1個はヤモトさんが言う通り
エクセレントなセルなんじゃないかと
03:01
エクセル
セルっていうのはあのマス目のことですねエクセルのはい
もう1個単純にエクセルってのは優れてるっていう意味
なんでエクセル自体が
なんかすでにあった他の小計算ソフトよりも優れてるみたいな
単純なエクセル
どっちからなんじゃないかって言われてる
いうのを今ググって知りました
おー今か
あでもそうか
なんか僕の中でさあれエクセルっていうなんていうの
世の中一般的な通念の概念だと思ってたけどそうじゃないんだね
あれってマイクロソフトがつけた名前だったんだね
マイクロソフトエクセルですね
いや確かにそうだよなぁ
いやそういう意味だとすごくない
すごいですね
めっちゃすごいですけどね
まあマック製品だとあれはアレソートのものをナンバーズって呼ばれていて
それも結構すごい名前だなと思いますけど
使ってる人少ないから
確かにナンバーズってすごい使いづらい印象しかないな
どうするもしヤモッティがさアップルに入ってさプロダクトマネージャーとしてさ
オファーもらいましたみたいな
やったみたいなあのアプリでみたいな
でなんかプッションはどこだろうつって
いやナンバーズですって
ナンバーズ部門排除クラブどうする
愕然とするな
どうやってやっていくよ
3ヶ月くらいかけてそのこのプロダクトを閉じるべき10の理由みたいなのをまとめるかもしれない
このプロダクトを閉じるべき10の理由
皆さんお楽しみいただけたでしょうか
レアテーブルとかを買ってきてすげ替えるみたいな
なるほどなるほど
確かに
こっちの方が安そうだな
閉じるよ
これもし聞いているリスナーの方でナンバーズ担当されている方がいたら大変失礼なことを申し上げました
全部僕のせいみたいな
それでちょっとエクセルはプログラミングかっていう議題はすごい面白いと思うんだけど
僕はちゃんとそれについて今話せる感じがしないんで
一旦ヤモンティさんに話してもらいながら
僕なりの考えをまとめていきます
じゃあ
これ興味深いですねヤモンティさんについて語る
多分ねみんなはあんま知らないと思うけど
僕も100%知らないけどヤモンティはエクセルがすごい達者ですよ
割と使えるよ
うん達者な感じしますね
ちょっと話してる感じだと
僕多分エクセルよりもGoogleシートの方が得意なんですけど
ああまあそうですね
Googleシートは特殊な関数とか
あとGoogleアップスクリプトの繋ぎ込みとかが使えるんで
その辺がすごい便利
Googleアップスクリプトなくても
06:01
Googleシートだけの持ってる独自の関数っていうのは
すごいユニークで使いやすいものが多くて
それでこういろんな例えば配列の計算とかしやすいとかあるんで
結構エクセルよりも自分はGoogleシートの方が好きなんで
ですけど広い意味では表計算ソフトとして
二大巨頭じゃないですか
なんでそれを想定して考えると
プログラミング言語だって認識してる人は
ほとんどいないと思いますまず前提として
だけどこの前話したまとめて処理をまとめるとか
まとめて処理するとか
あとその処理をちゃんと記述するみたいな文脈で言うと
紛れもなくこの定義に当てはまると思ってるですよね
っていうのは何だろう
例えばその関数の組み合わせで結構その
自在にモデルを組むことができるとか
人間が例えば手で計算していったら
答えにたどり着くまでに10億年かかるようなものを
ある種その関数だったり
関数ってライブラリだと思うんですよね
言語の中で言うとその関数の組み合わせを使って
すごい高度で複雑な計算を一瞬で終わらせるものに
消化することができるとか
そのあたりを含めるとすごい有能な
プログラミング言語の一つだと思います他方で限界もあって
人間が論理管理できる限界というかを超えれない
みたいなところはあるなって思って
スプレッドシート上で機械学習レベルの
その計算はできないみたいな
あくまでその人間管理できる関数の組み合わせでしかないので
だからそれをなかなか超えづらいし
処理の限界もあって
何万行いくと落ちるみたいなのも発生するので
そういうところの限界は明確にあるんですけど
表計算上でやることに対してはほとんど困らない
性能を備えているなというふうに思ってますね
加えてもう一個すげー有能だなと思うのが
さっき言ってたエアテーブルとか
あとノーションのテーブルとかも頑張ったら表計算できるんですけど
すごく可視化みたいなbiツールとしての性能みたいな
あんまり良いものを持ってなくて
ExcelとかSplitSheetって
プログラミング的な処理をまとめるだけじゃなくて
可視化の部分でも有能な性能を持っているので
結構オールインワンツールだなっていうのはもう一個すごいなって
言語であると同時にbiツールでもあるみたいな
そういう特徴ある感じがしてます
うんうん
なるほど
じゃあそれで
(笑)
ありがとうございました
議論なんなかった?
いやもう本当にその通りだなっていう気はしますね
GoogleSheetは本当にいろんなことができますからね
09:01
ね
最近今期Excelほとんど触ってないからな
どれくらい派生してるんだろう
ベースは変わんないんじゃないかな
なんか僕がExcel一番触ったのってExcel2003とか2007だったんですけど
今っていくつなの?
いや多分その2000とかっていう
365
そうそうそうそう
うん
そうだよね
2003 2007
2003 2007
2003とか2007ってアップデートされてたってことだよね今思うと
うんうん
なんかそれを知らない
(笑)
気がする
アップデートされたのかな
自分の記憶だとでも2007とかで普通にインデックスとかマッチとか使ってた記憶があるんで
インデックスとかマッチとか使ったんですか
うん確か
すごたんですね
あれインデックスとかマッチってGoogleシート専用だっけ
もうちょっと記憶が曖昧だな
いやExcelにもありますしね
ありましたっけ
全然ありよりのありですね
そうっすね
使ってた記憶があるんですよね
はい
ごめんねちょっと今僕歯切れが悪いのは
はい
なんだろう
あの作ったExcelを見たっていう
自分が作ったExcelを見た
はいいきなあれですねはい
あのこれ聞いてくれてる方に説明すると光さんのモデルもすごいモデルっていうかExcelも結構素晴らしいっすよ
本当っすか
うん
まあそうでしょうね
(笑)
なんかBIツールのように扱ってくれますからね
モデルであると同時にBIであるみたいな
はいはいはい
まあそうですねちょっとじゃあ僕の考えを話すと
はい
いいっすか
はいどうぞ
そうですねプログラミングの特徴っていうのは確かにまとめることみたいな話をしたんだけど
なんかすごい
まず話したいことはそのExcelをプログラミング的により扱うと
プログラミング的な思考を持って扱うとすごく良いことが多いっていう意味で
結構やっぱりエンジニアとかが普段持ってる流儀とかで学ぶものがすごいあるなとは思って
でプログラミングってまとめることって本質はあるんだけど
すっごい簡単に言うとなんかAっていうインプットを入れると
そのAっていうインプットに対して中でこちょこちょこちょって計算をして
Bっていうふうな答えを返すみたいなものっていう
まあすごい簡単な定義というか挙動だよね
12:01
まあそれがすごいちっちゃい計算だと単なる関数だし
それはすごく複雑なことができるやつとかクラスみたいな感じで
それめっちゃまとめるとAPIみたいな感じになるんだとは思うんですけど
まあExcelもそんなもんなんですね
でもそのインプットを入れるとアウトプットが出てくるっていうのがあると
でインプットを入れるとプロセスがあってアウトプットが出てくるっていう話なんですけど
多分エンジニアの流儀としてそのインプットとプロセスをめっちゃ分離して
処理とか管理しておくっていう習性がすごい強いと思うんですね
だから300っていうものを入れたときに
300×3みたいな感じの計算がしたら900って返ってくるみたいな関数がすごい簡単にあったとしたときに
エンジニアは300×3=900っていう風に書きたくなくて
A×3っていう関数を作って
Aは300であるっていうことを別のところに書いておくみたいな感じの仕方するんですね
っていうのはそのAがいくつになったとしても計算ができるようにしておきたい
一番最初はヤモトっていう社長がいてエンジニアに
プロダクト作るぞみたいな300×3を計算できるプロダクト作るぞみたいな感じで
ヤモトさんそれっていつも300なんですか?みたいな
300×3が計算できる人の便利だろみたいな感じで作るんですけど
エンジニアはヤモトさん多分アイツアホだから後から300じゃなかったらやっぱり280にしたいわとか
絶対いいですよとか後々いろんな人に使われるためには300×3だけだとあまりユースケースが少ないから
ありとあらゆるものに対して3倍できるっていう風なプロダクトの方が抑劣って
A×3っていうプロダクトに実装するんですよ勝手に
Aは好きに選ぶようにするみたいな
すげー簡単な話なんですけどこれは結構重要で
Excelもどっちにするかによって人格分かれてるんですよね
セルの中に300×3って計算しちゃう人か一旦別のセルを参照して
A1のセル×3っていう風なインプットにしておいて
A1は後から変わるはずみたいな感じのことを考える
これ結構極めてプログラミング的な考えだなと思って
僕は結構全部そうやってやることをすごく不服してますね
これまぁ一定度伝わんないと思うんですけど
例えば事業予測みたいなのがあるとしようと
5年後の売上を知りたいみたいな時に
年々伸び率1.2倍かなみたいな頭の悪い計算があるじゃないですか
あるね
基本的に今年は来年去年の1.2倍来年は今年の1.2倍
再来年は来年の1.2倍みたいな感じにセルに記述していく
15:00
とすると後から大和に俺らマジティックさから
年々2倍成長目指すと言われたら5つのセル全部買いに行きゃいけない
とか大和に2倍の成長になったら売上いくつになるか
今一瞬で見せるよってそこで1個1個2倍
1.2に直せたら大和おいおっせーよみたいな
言われてまぁクビになるわけじゃないですか
いろんな人がクビになっていたと思うんですけど
やめろ風評被害
あるセルに1.2入れたやつを参照しておいて
言われた瞬間にそこに2に変えるとかすると
もう一瞬で2にバッと変わるみたいな感じ
あとなんかそれを抽象化するとか結構重要で
2倍とかって入れるのもいいんだけど
例えば落間シナリオ標準シナリオ
飛観シナリオみたいな名前つけて落間を選ぶと2が入って
標準を選ぶと1.2が入って飛観を選ぶと0.9が入って
みたいな感じにすることもエクセルで結構可能なんですよ
これよりリーダブルですよね
なんかそのセル参照しているセルの部分を
落間飛観標準みたいなやつをフルダウンみたいな感じで
選べるようにするとよりツールっぽくなるというか
みたいな感じに結構プログラミングの考え方を導入していくと
よりキャキーンってなる感じがあるんですよね
例えば今はプログラミングだと普通インプットって
1つの数字じゃなくて配列みたいなものとかも使えると思うんですけど
エクセルもチューズ関数とかマニアックなやつ使えば
インプットを配列ベースでコントロールすることができるんで
今言ったやつも1.5倍毎年成長じゃなくて
5つの変数が1.2倍1.2倍で1.5倍1.5倍2倍みたいな
切り上がりシナリオみたいなやつを作って
インプットをそれにチューズ関数とかで変えるとかそういうのもできるんで
意外と配列をインプットにできるみたいな考え方もあると考えると
極めてエンジニアが普段やってる思考に学ぶものが多いなと私は思います
いやもうその通りバリアンツとコンストを分けて仕分けるとか
あと今ヒカルさんが言ってたのは感濃度分析みたいな形で
そのボラティリティというか必ずブレが発生するものをちゃんと表現して
そのシナリオごとに見ることができるとか
その辺ができるってもうこれ相当手計算でやったら何時間かかるみたいな話だと思うんで
かなりの処理をまとめきってると思うんですよね
そういう意味ではプログラミング言語とは最終的には言えない気もするんだけど
プログラミングを表現するGUIであるっていうのは言えるんじゃないかなみたいな
うんうんうん
18:01
でも本当に今言ったバリアントとコンストを結構分けるみたいな話
コンストっていうのは一定値でバリアントは後から自分たちで変えられるみたいな感じのもので
僕は結構Excelとかは極めてくると文字の色とかもバリアントとコンストとかで色が分かれてるんだよね
やるよね
管理するシートも何なら分けておくみたいなとこもあるらしい
だからシートAにバリアントとコンストみたいなのがまとまってて
でそれを変えると最終的に売り上げはいくらみたいなだけがあるシートがあって
その実際の計算は別のシートで行われているみたいな話
これって極めてプログラミング的じゃん
なんかその処理の部分だけをカプセル化しているというか
プログラミングとかの考え方の一つって最終的には使う人
APIを使う人に関しては中で何の処理が行われているかっていうのは基本的に興味がないだろうし
触らせたくもないっていう風な考え方があると
一時期にExcelを実装する人も例えば経営者とか別にExcelで何が行われているか興味がなくて
結局売り上げいくらやねみたいな感じの脳筋ゴリラ
オープンハウスとかにいるような人でも
結局インプットこうしたらアウトプットこうなるよねってことだけが興味がある人がいるために
Excelっていうのはプログラミングのように処理を隠蔽して作るべきなので
そういう発想は本当にエンジニアに学ぶべきだと思う
Excelがプログラミング的かっていうよりはエンジニアに学ぶべきことが多いっていうのが正確な表現かなと思ってます
確かに僕なんでExcelに足りないことをあえて言おうと思うと
いいねー
まずはRead Meが全然ないんですよ
誰が作ったこの困難なモデルもRead Meがなくて
要はそれに対する事業環境が変化したとかってなった時に何をいじればいいのかっていうのが
大抵作った人に依存するっていう
その問題結構あって
なんか一社目にいたマルベニとかって事業係数って各課が持ってて
課から部に吸い上げて部から部門に吸い上げて部門から吸い上げて最後会社にするんですよね
それが何だろうホールディングス的な本社もあれば
子会社300社分もあってそれを吸い上げて本社は最後作るわけじゃないですか
やった時に各その最後のアウトプットはみんな同じフォーマットで出しなさいってなるんですけど
各課とか各子会社とかが作ってる中身って全然違って
移動になった時にやべぇマジで何もわからんってなるんですよね
っていうのでRead Me全然なくって新しいその別の課のAPIを触る時に全く触れないみたいなことが
21:03
すごい起きやすいってのが一個と
変更履歴が追えないっていう
追えるんだけど追えないみたいな
というのはそのサブンってのをログとして管理する仕組みが中に要はギットみたいな仕組みが入ってないんで
今回この関数のどこいじりましたかみたいなのとその影響範囲はどこだったかみたいなのって
本当に論理的には全てのセルの中身を開けて見ていかない限り気づけないみたいな状態になっているっていう
なんかこの2つはその今のプログラミングが発展してきたその中で培われたツルハシ的な概念を持ち込むともっと良くなるだろうなって思った
確かに
なんかさそのそうそうそうそれも含めて言うとテストは効いてないよね
テストもねそうだね
Excelってさめっちゃ間違い多いじゃん実際
うんうんうん
なんか数字おかしくないみたいな参照するセル1行ずれてましたみたいなめっちゃある
あるあるある
とか参照するセルを相対参照にしてなくて絶対参照にしてずれてなんかDT引っ張ってる
同じセルだけ参照してましたみたいな
ずっと2015年参照しとるやんみたいなね
そうそうそうずっと2015年やんみたいな
なんかその間違いに気づくのもすごい難しいんだけど
むずいむずい
でもなんかデータ分析一般に言えるけどテストってそれ難しいんだよね
あー
インプットに対して数字が出てきた時にその数字が間違ってるかどうかって
系統的に言えそうなものを言いづらくて
裸の時にこんなに成長してる感じなのに売上こんだけしか伸びんのみたいな話とか
なんか売上いくらとか出たけど割合してみると
なんかでもユーザー1人当たりの売上が30万なんだけど
なんか俺らのプロダクトシャーペンなんだけどみたいな
1人シャーペン30万個も買うかみたいな
なんかそういう結構ヒューリスティックな判断を入れないと
その演算が合ってるかどうかがわからないみたいな
結構あるけど
でもなんかなんだろうなそことかは結構課題ですね
確かになんかあのいわゆるソフトウェアのテストってV字モデルってのがあって
テストで言うとユニットテストっていう単体テスト
なんか1つの小さいAPIとか
あとはインテグレーションテストって言って
例えば関数でこのでかい変数AとB
このAとBも別のAPIから来てるみたいな時に
それがちゃんと繋がっていいアウトプットが出るかっていう
インテグレーションテストがあって
最後総合テストってこのモデルがちゃんと動いてるかみたいな
このレイヤーがあるとすると
エクセル作るのうまい人ってユニットテストとかがちゃんとしやすいようには作ってるなと思って
なんかこの1つ1つの関数とか変数を計算する時にも
いろんな計算をしてたりすると思うんですけど
24:01
それがどこで行われてて確認がせめてしやすいみたい
状態になってると思うんですけど
基本的にその確認しなきゃいけないボリュームが異常な量になっていくんで
確かにヒカルさんが言う通りこのテストできないみたいな問題は結構でかい
問題として残ってますね
そうですね
だからプログラミングとかだったら
割とリーダブルになされるはずのものっていうのは
GUIにめっちゃ依拠してるっていうところがやっぱり1つ問題かなと思って
さっきの2015年から2022年を計算するみたいな時に
それは配列処理したら結構リーダブルに欠けるとは思うんだけど
GUI上で横にビーッて引っ張るとか
あとどこを参照するとかっていうのも
なんかその普通にGUI上で選ぶじゃん
そうすると間違いに気づきづらいだと思うんだよね
プログラミングだったら普通の一個一個の変数とか参照する変数っていうのを
少なくとも結構ヒューマンリーダブルな命名をすると思うんで
その場合ってなんかこの関数からこの変数を参照するのはおかしいみたいなのが言えると思うんだけど
なんかそれが一行ずれるみたいなGUIだと気づきづらい
だから和菓子クラスっていうものが生クリーム変数を参照するわけがないみたいなことが
プログラミングちょっとわかるんだと思うんですけどざっくり言っちゃうと
でもなんかそのExcelだと1行目は生クリームで2行目はあんこで
和菓子の計算数の生クリームを参照したっていうおかしなことが
1行ずれたっていう見た目の正解が起きるから気づきづらいんだよね
確かに確かに
和菓子に生クリーム入れる人には本当に今失礼なことを言いましたが
生クリーム大福とかあるけどね
クリーム大福とか和菓子じゃないし
確かに今ねカシアの子孫からするとあんなものを認めてはいけんみたいな
ファック
これYouTubeに載らないかも
PですねPです
そんな感じですかね
思いのほか盛り上がりました
ありがとうございます
では今回はExcelについて話しました
和菓子万歳バイバイ
はい皆さんいかがだったでしょうか
そういえば余談なんですけども
ヤモティがメルカリにいたとき
私がまずどうやってヤモティを認識したかっていう話になるんですけど
ヤモティですね当時ガスについてめちゃくちゃ詳しい
マニュアル私でも理解できるようなマニュアルを書いていて
そのマニュアルをもとに私ガスを設定したんですよね
それの感謝を伝えたくて確かDMをしたような記憶があります
当時からも結構そういうガスとかExcelとかスプレッドシールとか
27:01
使ってたんだなっていうのを聞いててすぐ思い出しました
はいでは今日も聞きいただきありがとうございます
次は木曜日更新ですのでまたそれまでお待ちください
ではバイバイ
