ブッククラブの終了
ken
はい、じゃあ、アサイさん、今日もよろしくお願いします。
Yosuke Asai
お願いします。
ken
はい、ということで、今日はですね、ついにDDIAブッククラブ、終わりましたね。
Yosuke Asai
はい、つい先ほど終わったんですけど、なんか日記がすごかったですよ、最後の、一番最後の読み終わった後の。
ken
すごかったね。
はい。
なんか、みんなやりきった感が出てたよね。
Yosuke Asai
うんうんうん、ほんとに文化祭終わったみたいな感じの雰囲気でしたけど。
ken
いやー、ということで今日はね、テッペイさんも終わったままね、ちょっと呼んで、ゲストに呼んで、3人で12回目の振り返りをしていきたいなと思ってます。
テッペイさん、今日はよろしくお願いします。
Teppei Iwaoka
よろしくお願いします。
ken
お願いします。
はい、もうね、テッペイさん何回も出てくれてるんでね、もう今日は自己紹介なしでいこうかなと、思っています。
はい。
ということで、じゃあ早速ね、導入していきたいんだけど、DDIAのね、ブッククラブをいつからやってましたっけ?もう3ヶ月ぐらいになるかな。
Yosuke Asai
8月から多分やってると思うんですよね。
ken
うんうん。
Yosuke Asai
で、2週間に1回なので、12章をきて、だから、あ、24週間か。だから、約半年ですね。
うわー。
ken
はい。
やりきりましたね。
参加者の感想
Yosuke Asai
やりきりました。
ken
で、そうですね、じゃあ最初にテッペイさんの率直なやりきっての感想を聞いてみたいですね。どうですか。
Teppei Iwaoka
そうですね、あの、今バックエンドエンジニアとして働いているんですけど、そのバックエンドエンジニアとしては少し恥ずかしいぐらい、データベースについて何も知らないような状況からスタートして、
このDDI本を読み始めたっていうところなんですけど、本当に毎回毎回知らないことが出てきて、でもそれはすごくバックエンドエンジニアにとって重要なことで、
それを一つずつ拾っていけたっていうすごいいい機会だったなと思ってます。
で、特にこう、知識を身につけることは一人でもできるんですけど、結構内容もすごく重たかったので、重要なことをすごく深くまで掘り下げて説明してくれる本なので、やっぱり読むのも結構大変で、
そこを乗り越えつつ最後まで来れたのは本当に周りの方々のおかげでここまで来れたなっていう気がしています。本当に大きなものを得られたなと思ってます。
ken
いやー、そうですよね。で、確かこれ一番最初にブッククラブ参加したいって言ってくれたアサヒさんと僕以外の人がテッペイさんじゃなかったっけ?
Teppei Iwaoka
そうかもしれないですね。
Yosuke Asai
そうだと思います。
ken
そう、だからファーストペンギンなんですよ、テッペイさんしかいないから。
Yosuke Asai
そうですね、それで確か他にも参加してくれる人がいますって言ったら、なんかトモシさんとかも来てくれたっていう名のやった気がするんですけど、違うかな。
ken
そうそう、だから別にこう、よいしょしたいわけじゃないけど、ファーストペンギンがいてくれたおかげで、なんかこうペンギンの群れになったようなところがある。
それで12回目最後だからテッペイさん呼んでんのかなと勝手に思いました。
Yosuke Asai
そういうことですね、たぶん。
アサヒさんさすがですね、やっぱり。
Teppei Iwaoka
すごい照りかけ通りです。
ken
じゃあどうどう、アサヒさん的にもブッククラブをファシーしたのは初めてだったんですか?
Yosuke Asai
そうですね、初めてです。
いやー、なんか本当に最初の、そうですね、第5章くらいから人を集めてやったと思うんですけど、テッペイさんも来てみたいな。
やっぱり最初本当に緊張してどうやってやっていくんだろうみたいな、やんなきゃよかったなと思いながら準備したんですけど、
でもやってみてやっぱり徐々に慣れていって、皆さん本当に温かいですし、かつ知識もすごくて、
あの特にしゅうへいさんとか友人さんとかケンさんも3人すごい知識が、経験と知識が豊富で、そこからいろいろ実践として学べることも多かったですし、
テッペイさんと僕、じゅんぺいさんは比較的データベースの経験は少ないんですけど、
そういった中でも質問とかもしやすくて、いろいろ話を聞けてっていうので、本当にいい空間だったなというふうに思います。
ken
そうですよね、みんなのエッチ強みっていうのが光ってたかなと思ってて、
例えば今日もReduxとかフロントエンド周りの話になったでしょ、
そこら辺たぶんじゅんぺいさんってフロントエンドエンジニアのかな、
はい、そうです。
いろいろそこら辺からみんなフィードバックもしてくれたりとか、
で、一人一人こう、例えばGCP寄りの人とか、Azure寄りの人とか、AWS寄りの人が違うので、
そこら辺でもいろんなデータベースを触ることもでき、議論することもできて、
そういうかんじで本当に自分の知識が他方面から打たれてどんどん強くなっていくみたいな感じがして、
やっぱブッククラブで議論する形式だからこそ、一人で読むとはまた違う知識の鍛え方ができたかなと、
僕もすごいよかったなと思ってます。
Yosuke Asai
本当に他方面の人がいるのはすごいよかったですね。
ken
そうですね。
じゃあせっかくだから、どうぞどうぞ。
Teppei Iwaoka
さっきの話しやすいとか質問しやすい雰囲気っていうのもすごく感じていて、
最初結構お互いのことを全然知らずに、お互いの名前を読んで何かを質問したりとかもなかったと思うんですけど、
最後らへん結構何々さんとかって言いながら、これってどうなんですかみたいなことが結構活発に行われていて、
本当最後とか全然臆することなくいろんなことが聞ける状態になっていて、
本当にいい雰囲気メンバーだったなっていうのは改めて思いますね。
ken
本当に思いますね。
最後のほうとかね、他の人が挙げたディスカッショントピックというか、
意見に対して質問もね、ほぼ毎回出たような感じだったし、
やっぱりバーを下げずに最後までやりきったっていうのは、
参加してくれた僕含め全員にとってやりきった感に繋がったと思うんですよ。
なんかこうイージーなやり方に途中で落とすことができたと思うんですよね。
何ですかね、事前に読まずに参加してもいいよっていう風にアナウンスしたりとか、
でも必ず最後までバーを下げずにレイズバーして、
みんな事前に読んで書くっていう風にしてたじゃないですか。
そこ絶対線を割らずに。
だからこそなんかやりきった感っていうのかな、熱狂っていうのかな。
まあアサヒさんいわく文化祭終わった後みたいな。
Teppei Iwaoka
本当にそうですね。
Yosuke Asai
なんだかんだ読むのに相当時間かけたんで、僕も。
読むのが遅いっていうのもあるんですけど、
本当に直前の土曜日を全部潰して読むみたいなそういう感じだったんで、
それだけ得られるものも多いですし、皆さんも結構時間かけていただいたと思うので。
てっぺさんはどんな感じですかね、結構読みの時間かかりました?
Teppei Iwaoka
そうですね、多分これ結構多い方だと思うんですけど、
多分6時間とか毎週、毎、この2週間に1回ですけど毎回使ってたと思うんですよ、少なくとも。
で、英語で読んで日本語で読んでみたいなことをすることもあったので、その時とかもっとかかってると思いますし、
結構実は重たかったなっていう感じですね、ぶっちゃけやると。
だけどやっぱりさっき言ってくださった通り、皆さんがバーを下げずにしっかりやってこられるので、
そこに置いてかれないようにっていうので、なんとかくらいつけたなっていうのは本当感じますね。
ken
すごいよね、その熱量だよね。
やっぱそれに値する本でもあったよね。
Teppei Iwaoka
そうですね。
Yosuke Asai
これは本のチョイスが本当に素晴らしかったなと思います。
なんかけんさんが最初にいろいろ紹介していただいた通りだと思うんですけど、
この本を読み通すことで、なんだろうな、
データベースだけじゃなくて、本当にアプリケーションのシステム構築全般の話がかなり詳しくなるというか、
本当にさらえると思っていて、
その分いろんなシステムを抽象的に見れることができるようになったなというふうに個人的には思っているので、
Yosuke Asai
結構事前に知識も必要というか、
それに開発の経験とかないと厳しいところもあると思うんですけれども、
読み通してだいぶ理解が上がったなというのは思います。
ken
そうですよね。
てっぺさんも以前の収録、DDIの収録で言ってくれたかもしれないけど、
このデータベースというトピックに対するメンタルモデルができるということで、
いろんなキーワードが入ってきたから、自分の中で地図ができたと思うんですよね。
例えば、コレクトネスの話をしているときにはこういうキーワードや技術があったなとか、
スケーラビリティの話にはパーティションとかいろいろあったな、
気にするべきことはあったなと思うんで、
これ絶対バックエンドエンジニアとして今後やっていくために、
エッチになると思いますよね、たぶんね、強みというか。
そうですね。
Teppei Iwaoka
実際、今、何かしらが襲い物があったときに、
同僚の方から、それを解決するためにパーティショニングとかを使えばいいんじゃないか、
みたいな話が出てきたりとかもしてて、
多分前の自分だったらパーティショニングっていうのがあるんだぐらいで終わってたんですけど、
パーティショニング使えば確かに早くなるかもみたいなところまで考えられるようになって、
実際自分がそれに向き合うってなったら、
ちゃんと調べて進めていけそうだなっていうぐらいにはなっていて、
そもそもスタートに立とうとすらしてなかったところから、
一旦スタート地点には立ててるような状態になれたかなと思ってて、
この違い結構大きいかなと思ってますね。
ken
大きいですね、その違いはね。
めちゃくちゃいい。
Yosuke Asai
なんかバックグラウンドができてちょっと安心感があるような感じですかね。
なんていうか。
ken
そうですね。
ぜひその次あれだね、その話が出た時に、
いやパーティションっていうのはね、こういうデメリットもあってね、
今この技術で使うのはこういうのもあってねっていう風にちょっとやっていける感じすぐなりそうですね。
この継続とかもね。
Teppei Iwaoka
そうですね。
2週目が必要かもしれないですね、また。
ken
それ僕3週目読まなきゃいけない。
Teppei Iwaoka
そうですね。
ken
そんなね、重たいね、なかなか読みごたえのある本だったんですけど、
まあ12回目の振り返りショーということで、
ラムダアーキテクチャーについて
ken
12回目の内容も簡単にね、振り返っていきたいなと思うんですけど、
今回は結構マーティン先生の思いが入ったというか、
まあ今までいろんな技術をこう紹介してきたと思うんですよね。
パーティションのショーであったりだとか、
あとは何だろうね、いろんなこうその技術を踏まえた上で、
今後のそのデータベースはどういう風に進化していくかとか、
あとはそのデータベースシステムを作るっていう技術的に作るだけではなくて、
どういったことを気にしなくて、気にして作っていかなきゃいけない、
どういけないのかっていう、
なんか割とこうエモいようなトピックが多かったかなと思いますね。
テクニカルなキーワードで言うと、
例えばラムダアーキテクチャーの話とかが出てたので、
これ結構議論になったので、
一旦簡単にラムダアーキテクチャーについて振り返っておきましょうかね。
で、ラムダアーキテクチャーっていうのは気になっている人も多かったんですけど、
そのデータベースのパイプラインを作るときに、
2つのレイヤーを積み重ねて作るものですね。
1つはスピードレイヤーと呼ばれるもので、
もう1つはバッチレイヤーと呼ばれるものですね。
なんか具体例で考えましょうか。
例えば、いろんなIoTデバイスからログが入ってきて、
そのログの状態をニアリアルタイムでダッシュボードで見せたいみたいなときに、
例えば昨日までのデータ、
例えば1年以上分ある大量のデータがあるじゃないですか。
ラムダアーキテクチャとデータ処理
ken
それはバッチレイヤーでバッチで処理するんですよね。
例えば1時間に1回とか1日に1回みたいな感じで。
大量のデータがあるからリアルタイムでさばけないので、
バッチでまるっと計算しておくと。
だけど要件的にリアルタイムのデータも欲しいということで、
過去1時間分まではバッチで処理するんだけど、
過去1時間分から今までのデータはスピードレイヤーでリアルタイムで計算すると。
そのバッチレイヤーの結果とスピードレイヤーの結果を足し合わせることで、
リアルタイムのより精度の高いデータを出すみたいなのがラムダアーキテクチャでしたね。
お二人は現場で経験とかあったりしますか?
Teppei Iwaoka
全く現場での経験はないですね。初めて知りました。
Yosuke Asai
僕もないんですけど、正直な感想としては、
実装というかメンテナンスが大変そうだなというふうには思って、
本にも書いてありましたけど、
同じロジックを2つ維持なきゃいけないことがあるのと、
あと、よくわからなかったのがラムダアーじゃなくて、
ストリーミングでデータを送って、
多分足りないところをバッチで補うというか、
失敗したやつを補うっていう感じなのかな、これは。
ken
多分どっちもできるんですけど、
よくある形は2つを合わせるって感じ。
だから、今この時点までのデータが欲しいときに、
90%ぐらいはバッチで取って、
残りの最後の10%ぐらいリアルタイムのデータはスピードレイヤーで取って、
足し合わせるって感じですね。
Yosuke Asai
じゃあもう取らないデータみたいのを決めてるんですか?
ストリーミングで取らないデータはこの辺でみたいな。
ken
そうそう、ストリーミングで取るのは過去1時間から今まで。
過去1時間分、レスザン1ナワーのデータで、
1時間以上のデータはバッチで取る。
それを合わせる、足すって感じ。
Yosuke Asai
でも、ストリーミングを継続的に実行していれば、
全部流せるってことにならないんですかね。
ken
ストリーミングを。
Yosuke Asai
過去1時間っていうのがずっと続くわけじゃないですか。
だから1時間以上前のやつも1時間前に取られてるってことにはならないんですか。
ken
例えば1年以上前のデータが欲しいってなったときに、
ずっと1年間ストリーミングパイプラインが動き続けてないと取れないんですよね。
Yosuke Asai
そういうことか。集計のタイミングで過去1時間以上前のやつとかっていうことですね。
ken
例えばデータ量にもよるけど、
途中でストリーミングパイプライン1年間分のデータずっと貯められないから、
1週間以上のデータはチェックポイントというかスナップショットみたいな感じで、
ストリーミングから吐き出して、3分更新ようにバッチで計算するように吐き出してみたいな感じで分けて、
ストリーミングで処理するのは本当に最近入ってくるデータだけみたいな感じにすると、
コストも全然違うからさ、バッチ処理とスピードレベルの。
Yosuke Asai
なるほど。本読んだだけでは分かってなかったんですけど、これにも理解しました。
ken
おっしゃる通りメンテナンスコストはめちゃくちゃ大変ですよね。
だって2つのレイヤーやんなきゃいけないからさ。
Yosuke Asai
はい。けんさんは実際にこれを実装というか経験されてるんですね。
ken
保守をしたことが1回と作ったことが1回あって、
僕がCookpadの広告に入った時の先人がすでにラムダアーキテクチャで広告ログのリアルタイムを作ってて、
別の機会にそれを参考にして、もうちょっとちっちゃいバージョンのラムダアーキテクチャを作ったみたいなことがあるんですけど、
やっぱり保守が大変でしたね。
これディスカッションの中でてっぺいさんも挙げてくれたけど、
やっぱりラムダアーキテクチャ自体はちょっと古い概念になるので、
その後ポストラムダアーキテクチャみたいなアーキテクチャパターンがいくつか出てて、
例えばカップアーキテクチャとか、あとこれアパッチフーディっていうのかな。
Teppei Iwaoka
フーディみたいですね。
ken
でもラムダアーキテクチャに代わるアーキテクチャパターンが提案されてるという感じですよね。
これについてはどうですか、てっぺいさん。軽く触れられそうですか。
アパッチフーディについてですか。
Teppei Iwaoka
読んだ記事の感想でもいいけど。
ログベースのシステムと整合性
Teppei Iwaoka
そうですね。ちょっと触れられなさそうです。すみません。
ken
分かった分かった。そんな感じです、ラムダアーキテクチャは。
他に12章の内容として触れておきたい。
お二人はありますか。じゃあまずてっぺいさんから。
Teppei Iwaoka
今回の12章で特にログベースのシステムが再度押されていたなっていうところが、
印象として強かったです。
やっぱりログベースだと整合性も保ちやすいし、対障害性も高いしっていうところで、
いいシステムなんですけど、
一つログベースだと保証しきれないのが適時性。
整合性の中にも適時性と一貫性ですかね。
一貫性には適時性と整合性というのが2つがあるというのが紹介された上で、
整合性はログベースのシステムすごく保ちやすいんですけど、
適時性というところが特別な処理を加えない限りなかなか守れないというところが言われていて、
その点はちょっと弱みというか問題になりそうだなと思いつつも、
この一時的な違反が発生したら謝罪して後から修復するというような緩い制約でも問題ないケースがほとんどなんじゃないかなというふうな言われ方もしていて、
そういうふうに考えると、
整合性を保ちつつパフォーマンスとか対障害性を持てるこのログベースのデータフローシステムというのはすごい優秀なのかなというところをすごく感じましたね。
ただちょっとこの謝罪で何とかなるのかどうかっていうのは結構国によってもなんか雰囲気違ったりするのかなと思ってて、
ここはちょっと日本だとまたもう少し厳しく考えたほうがいいとかっていうのはあるのかもしれないなと思いつつっていうところですね。
ken
そうですよね、いやここ面白いトピックだなと思って、
まず適時性って出てたけど、これ英語版だった、何て言ってたっけ、タイムリネスかな。
Teppei Iwaoka
タイムリネスだったと思いますね。
ken
一貫性とかコンシスタンシーとかコレクトネスだと思うんですけど、
多分ここの章の一番のテイクアウェイとしてはバックエンドエンジニアのてっぺいさんとしても、
作るときに何を気にしなきゃいけないかってことが見えたってことですよね、
適時性とか整合性みたいなのがあって、
この謝罪、一時的な違反が生じたときに謝罪した後から修復するような緩い制約でも問題ないアプリケーションって具体的に何だろうねっていうのをちょっと考えてみたいんですけど、
ここら辺どうですかアサヒさん、なんか読んでて感じるところあった?あんまり気にならなかった?
Yosuke Asai
いや気になりましたね。
Reduxのコンセプトの重要性
Yosuke Asai
この適時性がいらないシステム結構あるんじゃないかって僕は思って、
やっぱりっていうのはほぼ使ってる、例えばSNSとかそういう決済が伴わないシステムっていうのはほとんどいらないんじゃないかなみたいな個人的には思っていて、
決済するが必要なものだけなんかここで購入しましたとか、
この値段で買いましたみたいなものが必要だったり送金が必要だったりっていうものに関しては必要な可能性があるかなというふうに思っていて、
なんでこの、たぶんこのさっき言った適時性と整合性の整合性は必ず必須だよっていうベースラインは保っておいて、
適時性は必要かどうかっていうのを判断した方がいいっていう、なんか自分の中に軸ができてよかったなと思ったんですけど、
ken
そうね、めっちゃいいっすね。
いやなんかそれめちゃくちゃいい観点だなと思ってて、なんでかっていうとたぶんこのシステムを作ってエンジニアじゃない人とかと設計詰めたりとか、
そのなんだろうね、当てたりするときに絶対初手としては、なんかこう全部やってくれた方がいいじゃないですか、
整合性って何みたいな感じ、タイムレスもやってよみたいな感じになると思うんですよね。
そこでそのプッシュバックができると思うんですよ。
いや、このシステムに本当に適時性必要ですか、それをするためにはこういった例えば追加の保守コストがかかりますよとか、
こういったデメリットがありますよみたいな、そういったところも彼らの目線で語れるようになると思うんですよね。
なんかこれただなんかめんどくさそうなんですけどって言ってもさ、いや作ってよってなる。
そこのなんだろうね、他のビジネス側とかエンジニア以外の人と議論していくためのこのつまみのいじり具合っていうのも、
理解しながらネゴシエーションできたりするじゃない。
Yosuke Asai
はい。
ken
そこら辺はすごい良い観点だなと思って。
Yosuke Asai
交渉の材料にも使えるようなとこなんですかね。
ken
ね。
うん。
この謝罪してっていうのは具体的には何なんですかね、なんか多分アナロジーだと思うんだけどね、
本当にアイムソーリーっていう訳じゃないと思うんだけど。
Teppei Iwaoka
自分の理解が正しければ、飛行機の予約とかホテルの予約とかの例が出てたと思いますね。
で、まあ席は数限られているので、その席に対して容量を超えてしまうような予約を適時性がないが故に発生してしまうこともあって、
その場合にはより良いシートに移ってもらうとか、もう少し分かんないですけど、ホテルとかだとそのタイプの部屋はないけど、
もう一つグレードの高い部屋になるので移ってもらうとか、そういうことによって解消するみたいなことが書かれていたのかなと思いますね。
ken
なるほどなるほど。だから結局そのユーザーエクスペリエンスも込みで、トータルとしてのサービスシステムってどうあるべきなんだっけっていうのを語るときには、
やっぱデータパイプラインだけで全部保証できないから、例えばUXチームとかと一緒に考えていく必要があるのねっていうマインドシフトが起きるところですね。
確かにそうですね。
確かに面白いな。
浅井さんの方は12章他のところで気になっていたキーワードとかトピックとかありますか?触れておきたいところ。
Yosuke Asai
そうですね、今回結構システム全体的な話になってきて、フロントエンドとかモバイルとかのところまで話が広がっていって、
モバイルが出たことでネットワーク遅延とかが起きやすくなるというか、モバイルを使っていると結構インターネットのあるところに行ったりすることがあるので、
それに伴って起きる問題とかの話が出てきたのが面白いです。
そのモバイルが出る前と出た後全然違う状況にあるんだなっていうのも個人的に面白かったですね。
あとはReduxとかそういうフロントエンド関連のテクノロジーも出てきて、このダイアグラムとか見て全然分からなかったのが今回分かって僕は嬉しかったなっていうのは個人的にはありました。
ken
いいですよね。浅井さんも何か挙げてくれてたけど、リアクトのイベントのフレームワークでReduxっていうのがあって、
4年前に読んだけれども、今回Reduxがどういうものか分かったみたいな書いてくれてて、
これすごい個人的にはピンときたんですけど、これどういうことかというとReduxって別にこのほう全然出てこないじゃないですか。
フロントの話一切出てこないじゃないですか。でもここで学んだメンタルモデルとかコンセプトを別のところで活かしたってことなんですよね。
仕組みとしては。こうやって本当にコンセプトを理解しないと他のところでできないじゃん。
こういうのは確かドメインディペンデンシー問題みたいなの言うんだけど、
ドメインが変わったときに他のドメインの知識を活かせるかどうかって結構重要なスキルだと思うんですよ。
例えばバックエンドだけじゃなくてフロントエンドのところでもこのコンセプトあったねみたいな。
そういうのが結構イノベーションとか真の理解につながったりするんで、
データベースとニューロン
ken
そういった議論もできたっていうのは本当にブッククラブの強みだったかなと。
これ多分浅井さんがReduxの話を挙げてくれなかった僕も多分その観点はなかったと思うので、
本当に集合地を寄せ集めて議論できたっていうのは本当に良かったなと思いますね。
Yosuke Asai
確かに。やっぱり他のところに適応できる。
このデータベースの話って脳の仕組みとかにも適応できるのかなと思ったりして、
自分の脳がどう動いているのかみたいなちょっと似てるところはある気がして、
多分全然違うと思うんですけど、
本当にそういう自分がどう考えるかみたいなとか、
どういう情報を押した選択するかみたいなところにも適応できそうだなみたいなちょっと思いましたね。
ken
なるほど。それめっちゃ面白いんじゃない?
ニューロンが分散システムみたいな感じでニューロン同士。
なんかニューロンってあるよね。
Yosuke Asai
ありますね。ニューロンとかシナプスがどうとかいろいろあると思うんですけど。
ken
シナプスで繋がってて電気信号渡すんだよね。
Yosuke Asai
そうですね。確かそうです。
ken
電気信号ってさ、多分エラーが発生するはずだから、
どこかでそのコレクトネスを担保する仕組みってあると思うんだよね。
うん。
で、シナプスって遠ければ遠いほど電気信号時間かかるじゃん。例えば。
Yosuke Asai
はい。
ken
だけどそのショートカットするための機構があって、
何か熱い薬缶を触ったときにピッてこう手がなじむのは、
確かその、そこ電気信号がショートカットされたからだと思うんですよ。
Yosuke Asai
はいはい。積水反射みたいな。
ken
そう。で、シナプス同士がその電気信号を走らせれば走らせるほど、
そこの軸って太くなってくるんですよね。
だから例えばそれってその野球でキャッチボールの練習をしてると、
どんどんどんどん投げるのが上手くなるみたいな感じで。
Yosuke Asai
はい。
ken
それってその2つのシステムがなんだろうね、
こうAPIでやり取りすればするほどそこの知見が溜まってて、
モニタリングに利用できるみたいな、そういう感じなのかな。
Yosuke Asai
ああ確かに。
わかんないけどアナロジー深いけど。
いやでも確かにその、キャッシュとかと近いかもしれません。
やり方をどんどん覚えてすぐに出せるようになるみたいなのとか、
近い気もしましたね。
そうかそういうのにつながってくると思うと、
そこまで僕は考えてなかったですけど面白いですね。
ken
どうですかてっぺいさんこれ。
Teppei Iwaoka
いや自分もなんかそのキャッシュとか、
クラウドフロントとかのイメージがすごくあきましたね。
よく使われるのがすぐ返されるようになってるじゃないですか。
確かに。
ken
そうか。
うん。
確かに。
面白そう。
これ誰か気になる人いるんじゃない?
データの正しさと倫理観
ken
うん。
Yosuke Asai
いや。
ken
面白そうですね。
ねえ。
やってみたいな。
やりたいですね。
うん。
そうそうで、この12章のトピックでもう一つぜひ触れておきたいトピックがあってですね、
これが真にデータを使える組織とかとか、
正しいことを行うについてっていう、
もうちょっと哲学的なエモい話になっていくと思うんですけど、
倫理観とかもかかってくるよね。
Yosuke Asai
本当にこの本の最後で話がガラッと変わるというか、
データの正しさという話とか、
倫理観の話とかなって。
ken
そうですよね。
これ、てっぺいさんもいいディスカッショントピックを挙げてくれたんですけど、
これ僕のまず印象から言うと、
これブッククラブの中でも言ったんですけど、
僕は今までSREとして結構技術的な観点ばっかり興味があったんですよね。
結構スケーラビリティを上げるとかリライアビリティを上げるみたいなところ、
楽しいしかっこいいし技術的チャレンジもたくさんありますよね。
99.5% 99.99%にするためにどんなアーキテクチャーが必要かとか、
リクエストパーミニッツを一桁上げるために何が必要かみたいな。
サイトリライアビリティエンジニアのスケーラビリティとかリライアビリティというところはそこでやってきたんだけど、
じゃあそこで作ったデータパイプラインとかデータの倫理観とか、
あとそこで本当に真にデータを使える組織にするためには、
ちゃんとそのデータの中身とかを保守していかなきゃいけないし、
どんなデータがあるかっていうデータカタログとかも保守できるようにならなきゃいけないし、
組織ってどんどん変わっていくので、
変わっていく組織に合わせてデータパイプラインがレジリエントな形でなきゃいけないよね。
例えばマイクロサービスの文脈だとConwayの法則とかがあって、
その組織の形とサービスの形は似てくるみたいなのもあるんだけど、
データパイプラインにも言えるかなと思っていて、
そこら辺まで今後個人的には考えていくべき話かなと思ったんですけど、
ここら辺の正しいことを行うっていう観点について、
お二人のほうで気づきとか感じたことってありますか?
じゃあ今回はアサヒさんからいこうか。
はい。
Yosuke Asai
そうですね。
僕がちょっと思ったのは、
ken
難しいよね、この問いね。すごい社会学的な問いだよね。
Yosuke Asai
そうですね。ここに書いてある熊健吾さんをちょっと思い出したんですよね。
アラスカ鳥よりは哲学的な部分というかところで。
ken
まずどんな人だっけ?
Yosuke Asai
熊健吾さんというのは建築家なんですけども、
僕一回熊健吾さんの建築展に行ったことがあって、
そこで結構すごいなと思って、
そこでちょっと本も読んでみたんですけど、
熊健吾さんは結構木とかを使って、穴とか使って独特な建築をする方なんですけど、
その人の本を読んで、
こういうすごい世界で認められる建築をするというか、
ためにはすごいバックグラウンドとして、
哲学とか宗教とか政治とかすごい理解があるっていうのがわかって、
そういう理解があるからこそ結構人が親しみやすいというか、
建築を作るみたいなところをすごい読んでて思ったんですけど、
今回そのマーティ先生がこういうふうに一番最後に新しいことを行うというか、
なんか差別とかをなくすための、
が起きないようにするデータの作り方みたいなところを話になってきて、
やっぱりそういういい設計をする人っていうのは、
そういうところに理解が深いんだかなっていうふうに個人的には思って、
思いましたという話ですね。
ken
なるほど、そこで熊健吾さんを挙げてくれたというわけでね、
つまりそのマーティ先生がこういったそのエモいトピックに、
興味関心というか思いがあるっていうところと、
その一流の建築家の熊健吾さんがちょっと重なってみえたと。
Yosuke Asai
そうですね、まさにその通りです。
ken
いやーかっこいいな、そういうソフトエンジニアになりたいな。
Yosuke Asai
いやー本当に。
ken
なんかね、ただ早いだけのソフトウェア作って終わりですってよりさ、
このソフトウェアを作ったにはこういう思いがあって、
社会をこう良くしたくてとかさ、
こういう差別をなくしたくてみたいなさ、
言うたらかっこいいよね。
っていうか、なんか一生を通して、
自分の時間を費やす価値があるよね。
Yosuke Asai
本当にそうだと思いますね。
ken
なるほどね。
てっぺいさんはどうですか?
Teppei Iwaoka
ここについて思ったこととか。
改めてデータを取り扱うものとしての責任の重さっていうのを感じましたね。
自分が直接何か悪いことをするっていう機会は今までなかったんですけど、
そういうふうにも使うことができるっていうことを、
改めてこの章を通して認識しましたね。
一つ思いついたのが、
資本主義、デジタルとデジタル社会がもたらす光と影っていうの、
ドキュメンタリー番組みたいなのがNetflixから出てたんですけど、
それはGAFAとかのいいねボタンとかを作った人とかが、
それが及ぼすような影響とかに対して敬意をならすみたいな、
そういう危険さを説明してくれるようなものなんですけど、
その中で使われているデータが政治的なターゲット広告に使用されたりとか、
そういう重要な社会的なことにも影響を与えるっていうところを思い出して、
この本にも書いてましたけど、
自分たちがどういう世界を生きたいかっていうのが大事なんだよみたいなところが、
12章でも書かれてたかなと思うんですけど、
本当にそこにまで影響してくるような、
今住んでる社会をどう生きたいのかみたいなところにまで広がってくるような、
すごい大きなテーマだし、
そこを扱うものとしての自覚を持たないといけないなっていうところを感じましたね。
このトピックめちゃくちゃ深いですね。
ken
そのいいねボタンの話もあって、
僕このネットフリックスの監視資本主義っていうのは見てないから、
触れられたかわかんないんだけど、
SNSとかで出てくるそのいいねボタンとかも、
ABテストとかでどんどん改善していくじゃないですか。
これ記事とか本をちょっと読んだんだけど、
それこそさっきもちょっと話でたけど、
シナプスとか脳神経の仕組みがどんどんわかってきたと。
そうするとそのドーパミンっていうホルモンがあって、
そのドーパミンに対する理解ができてきたんですね。
それをハックすると、
どれだけ人間が使ってくれるアプリになるか、
だからアプリのリテンションを高めるために、
どんな機能があるかっていうのを、
そういった観点からめちゃくちゃ優秀な方に、
そういった観点からめちゃくちゃ優秀なソフトエンジニアが、
例えばコードかけるだけじゃなくて、
脳神経科学とかも論文とかも読めちゃうような人が、
それを組み合わせて、
例えばアプリの通知はこういうのをすると、
何回もアプリを開いてしまうとか、
こういういいねボタンを押すと、
他人からのいいねが欲しくて何回も何回もFacebookを訪れちゃうとか、
そこをハックしていくんですよね。
でもその先に何があったかというと、
ちょっと多くは語らないけどさ、
じゃあSNSっていうのは、
いいものだけじゃないじゃない?
もたらしたものって。
そういったとこにぶち当たったときにだよ、
倫理観って発動するかどうかって、
結構重要なポイントだと思うんですよ。
自分が価値がある、成果があるようなものを実装して、
わかんないけどRUSAがもらって、
昇進して、
家買えるっていう方に行くのか、
それとも倫理観を発動して、
本当に自分が作っているものって社会にとって良いものなのかっていうのを
考えるかどうかって結構大事な問題だと思うんですよね。
うん。
なんかこう、結構センシティブなトピックだから、
一言言うだけにとどめるけど、
結構さ、科学者とかとも似てくると思うのよ。
科学者が作る科学的なトピックって、
科学者が作る科学的な技術ってさ、
人殺しされするじゃない?普通に。
でも純粋に好奇心で作っている人もいるじゃん。歴史上。
うん。
そこを難しいなと思って。
難しい。
Yosuke Asai
深い話です。
ken
やっぱり、
Teppei Iwaoka
あ、どうぞ。
ごめんなさい。その話を聞いていて、
一つ思いついたのが、
最近、Xって課金、
課金というか、
多くのアテンションを獲得した人に対して、
お金が支払われる仕組みになったじゃないですか。
ネットコミュニティの盛り上がり
Teppei Iwaoka
で、その後からすごく感じるのが、
すごく攻撃的というか、
人を不安にさせたりするような
投稿ってすごい増えたなと思ってて、
で、個人はそれによってお金が得られるから
そういうことをするっていう心理だと思うんですけど、
そのX社としては、
どういう人に対してお金を払うとよいのかみたいなところで、
どういうツイートが流れるのかっていうところも
作っていけるわけで、
そういうところにもやっぱり現れてくるなっていうのが
ken
すごい感じましたね。
めちゃくちゃわかるね。
Yosuke Asai
朝井さんも何か言いかけたね。
いや、そうですね。
企業の中で働いていると、
そういう今言ったような課金体系とか、
あのところで、
売上重視というところに傾いてしまうっていうところは
あるのかなと思ってて、
そういうところでやっぱり人に悪影響を与えてしまうような
実装を実際にしてしまうみたいなところは
出てきているような気はしていて、
なんでケンさんがおっしゃったような
倫理観を持って仕事をするっていう人が少しでもいれば、
それをちょっと食い止めて、
本当の真のユーザーフレンドみたいなところに
持ってきるのかなみたいな気はしたので、
本当にいいポイントだなと思いました。
ken
いや、本当にその通りだよね。
技術ブログによるマーケティング
ken
いや、僕こういう話すっごい好きでさ、
これ一晩明かせるんだけどさ、
このままやっちゃうみたいな。
仕事とかもいろいろあるからね。
そう、でもてっぺいさんがそのXの話を挙げてくれて、
それすごいいいなと思ったので、
ちょっとそこを深掘ってみたいんだけど、
課金するって言ったよね。
僕らソフトウェアエンジニアからしたらさ、
これXに課金たとえばしますって、
僕はしてないけど現時点ではしますってなったときに、
そんなに、なんだろうね、
払える額だと思う。
確か今数百円ぐらいだっけ?
わかんないけどさ、
でもさ、世の中にはそれ払えない人もいるんだよね。
その額さえも。
それってさ、
差別社会のその格差構造になってしまうんだよね。
課金というハードルを挟むことによって、
それができる人とできない人で、
まず先手がされるよね。
で、かつ払える人の中でも、
そういったアグレッシブな行為をできる人とできない人で、
さらにどんどん分化していってしまう。
かつデジタルの社会だから、
そういったアグレッシブなコメントを使って、
どんどん簡単にコピーできるから、
簡単にリツイートできちゃうから、
どんどん広がっていってしまって、
そういったコンテンツを消費するものと、
生産するものの、
そのコンテンツを消費するものと、
そういったコンテンツを消費するものと、
生産するものの、
もう超えられない壁というのができてしまうんですよね。
そこを作りたいですかという話なんですよね。
結局。
深い話ですね。
そうそうそうそう。
もちろんこれ一応語弊のないことを言うと、
僕も過去にSNSを作っている会社に実際受けていたし、
入ろうと思っていたことがあって、
中でそれを抑えるために頑張っている人っていっぱいいると思うんですよ。
SNSがダメとかそういう話をしているわけではもちろんなくて、
誰かが現時点でもそういった問題、
同じ問題意識を抱えてやってくれている人っていっぱいいるんですけど、
一方でそういった人たちの努力より、
そうじゃない方向の機能実装の方が、
加速度的に増えていってしまうよねっていうのが問題だと思うんですよね。
Yosuke Asai
なるほど。
ken
これまたてっぺいさんがディスカッショントピックの最後で挙げてくれたのが、
めちゃくちゃいいと思っていて、
これちょっと読んでいいですか、そのまま。
Teppei Iwaoka
はい、もちろん。
ken
ディスカッショントピックがブッククラブに参加していないリスナーの方に言うと、
事前にみんな一人一人書いてくれているんですよね。
リンクを挙げてこんなのがあったよとか、
こんなのここ分からなかったですみたいな。
てっぺいさんが最後に挙げてくれたのが、
読むとデータの破損が多かれ少なかれ避けられないことだと理解した上で、
破損したデータによって個人の差別につながるようなことがあってはならないなと改めて感じましたと書いてあって、
この個人の差別につながるかどうかっていうのをさ、
普通データパイプライン実装してて考えるかっていう話。
考えたことありますか。
Yosuke Asai
ないですね。
Teppei Iwaoka
そこまで想像及ばないですよね、なかなか。
ken
だからこそ考えていく必要があると思うんですよって思った。
本当にこのてっぺいさんのディスカッショントピックで
目覚めたの、やばって思った。
ディスカッション、ブックラブでも触れたけれども、
例えば機械学習の画像、なんだっけ、画像カテゴライズのアルゴリズムがあったときに、
例えばさ、ゴリラの画像と特定の人種の人を間違って分析してしまうみたいなシステムができてしまったりするじゃない。
そういった機械学習のシステムとか今後どんどん増えていくと思うんだけど、
本当にインジェストしていくデータの品質とか正しさとか倫理観っていうのを、
ちゃんとこう作る側も意識しなきゃいけないよねと思って。
例えばこれもう一つ具体例が出たのが、これ2人も後で聞いてみたいから、
ちょっとぜひ僕がいつもみたいに話してる間に考えてほしいんだけど、
例えば個人のクレジットスコアってあるじゃない。
例えばこの人にどれぐらいお金貸せますかとか、
インシュレンスどれぐらいの金額にしますかみたいな、
クレジットスコア、その人のクレジットスコアを算出するときに、
どこまでその人のデータを取るかっていう話があるんだよね。
その人のパーソナリティとか、すっごいプライベートなデータを取ろうと思えば取れるじゃん。
それをクレジットスコアに反映するっていう発想はさ、
すごい単純だと思うけどありだと思うんだよね。
その人のどれぐらいプライベートな会話で他人に嘘ついてるのかとか、
どれぐらいちょっとした盗みをしてるのかとかそういったもの、
プライベートなデータとかそういったものでもどんどんやっていくと、
ちょっとしたミスがその人がもうクレジットスコアが一気に下がってしまって、
もう取り返しのつかないようなポジションに落とされてしまうかもしれない。
そのプラットフォーム上。
例えば本当は善意のある人間なのに、
ちょっとした行為が間違ってプラットフォーム上で、
クレジットスコアを大きく下げるようなアルゴリズムで増幅されてしまった場合、
その人のプラットフォーム上でのスコアって一気に下がると。
でもさ、人ってそんな簡単じゃないじゃん。
いい人悪い人って分別できないというか、
その人の善性と悪性っていうのはさ、もっとすごいグレーなものじゃないですか。
すごい家族に対して悪いというか、すごい横暴な人なんだけど、
道端ではすごいおばあちゃん助けてるみたいなそういう人もいるし、またその逆もあるから、
なんかそこを言ったクレジットスコアみたいなシステムとか作ってるとかってとも、
こういった個人的な差別とか倫理観というのをすごい発動せざるを得ないようなところなのかなと思ったんですよね。
確かに。
Yosuke Asai
この人の良い悪いみたいな、良い悪いっていうのはあれですけど、
一面じゃない、そのコンピューターとかでアルゴリズムで判定すると、
ある一部分で聞いとって判定してしまうみたいなこともなりかねないと思うんで、
確かに今おっしゃったような話は気をつけないと、
自分自身としても本当に怖いですし、なんか今後コンピューターで、
データの品質と倫理観
Yosuke Asai
アルゴリズムに判断されてしまう、
どういうのかわかんないっていうのはちょっと怖いですね。
そうですね。
なんかそうですね、本の中でもあったんですけど、
Teppei Iwaoka
ある国から来ている人だったらあまりお金を持ってないだろうとか、
こういう人種の人だったらおそらく来ていないだろうとか、
そういうカテゴリーで結構判断されてしまいがちで、
その人自身が本当にそうかっていうと、
多分そうじゃないことも多々あるっていうことを考えると、
そういうアルゴリズムによる判別ってすごい危険だなっていうのを思いつつも、
じゃあどうやったらこう、
一、こう、開発者として、
そこに携わっていたとして、
どうやったらこう判断されてしまうかっていうのを思いつつも、
一、こう、開発者として、
そこに携わっていたとして、
どうやったらそこを改善していけるんだろうっていうのは、
ちょっとすごく答えのないところだなっていうのも同時に思いますね。
ken
いや本当にそれめちゃくちゃいい観点でさ、
だってさ、それをやっぱ防げる位置にあるのは僕らソフトウェアエンジニアだと思うんですよ。
だってそれって最初のデータモデルを作るときに考えなきゃいけないことなんですよね。
例えばですけど、
今の国の話は面白かったから、
今の国の話は面白かったから、
それって典型的なステレオタイプとかラベルを埋め込んでるじゃないですか。
なんかその、
でも、その国と、
例えばじゃあクレジットスコアがひも付かないよっていう風にボトムアップで、
やっぱ主張していかないといけないと思うんですよね。
そこでああそうなんだ、言われたからじゃあ実装しようみたいな、
実装したらもう後の末ですよね。
あとはなんかよくあるのは、
ジェンダーとかもそうですよね。
なんか言われたからじゃあ男性と女性のフィールドをブーリアンフラグで持とう。
ブーリアンじゃないじゃないですか。
そこの型をさ、
ジェンダーのデータベースに入れるジェンダーという絡むのフィールドの型を決めるのはソフトエンジニアですよね。
それ言われたからブーリアンにするのか、
いやこれこういう観点があるからストリングとか別の方がいいんじゃないで、
提案できるかどうかと思うんですよ。
なんかジェンダー以外にもそういったところっていっぱいあると思っていて、
そこに普段実装してる側がどれだけ気づけるかっていうのは、
そういった答えのないのを発信し続けていきたいよね。
そうですね。
Teppei Iwaoka
優しい世界を作っていければ開発者になりたいですね。
ken
いいこと言うじゃん。
優しい世界を作るエンジニア。
そうですね。
改めて感じましたね。
これね、答えのない問いをやっぱり信頼できる人たちと議論しつくすってのも、
ブッククラブとかこういうポッドキャストのいいところだと思ってますね。
確かに。
Yosuke Asai
なかなかできないですね、こういう話は。
そうだね。
ken
今のトピックは結構まとまりがなかったからこれぐらいにして、
ポッドキャストできないように綺麗にまとまるような話に持っていきたいんだけど、
最後はね、次はね、
そもそもじゃあブッククラブが終わってDDIA本読み終わったので、
DDIA本、一通りこう振り返ってみたいんだけど、
これすっごい簡単な、今解いたのとはすごい比較して簡単な解いたけど、
DDIA本を読んだ一番勉強になった点と印象に残った点をちょっと一人ずつ挙げていきたいかなと思っているんですよね。
逆に難しいかな。
ということで、じゃあ誰から行こうか。
挙手制で行く。
ログベースのメッセージブローカーとCache
ken
じゃあ僕行きますね。
はい、じゃあさんさんどうぞ。
Yosuke Asai
僕2つあるんですけど、1つはイベントソーシングとログベースのメッセージブローカーのところが、
前章のところですね、やっぱ印象に残って、
これを知ったことで世界が開くというか、
こういうデータベースに保管するというかだけじゃなくて、
ログを元にしてデータを発生させていくみたいな話が僕はすごいメリットが多いんだろうなと思っていて、
今の一般的なアプリケーションとは作りが違うというか、
変えていく必要があるので、そういう発想を持ってどんどん設計に関わっていきたいなというふうに思ったのと、
あともう一つは、
Cacheの重要性というかCache自体に様々な形式があるというところが面白くて、
例えばセカンダリインデックスというのもCacheだし、
データベースからデータウェアハウスとかにデータを送って、
それを読み取りやすくするというか、
分析に使いやすくするというのもCacheだしみたいな、
そういうCache、全てが読み取りに際して効率がいいようにするためのCacheみたいな考え方をすると、
結構分かりやすいというような気がしたのが良かったなと思いました。
ken
なるほどね、Cacheですね。
確かに中間データとかデータを計算した形をどうやって持つかみたいなのは、
いろんな持ち方があるからね。
バケットに入れたりとかマテリアライズビューにしたりとか、
CacheはCacheでもスナップショットみたいに計算してディスクに置いておくのか、
それこそCacheストアみたいな感じでメモリに置いておくのか、
メモリに置いておくのもメモキャッシュドみたいなCacheストアに置くのか、
それこそアプリケーションのコードの中で、
例えばRubyのハッシュのキーとバリューみたいな感じでキャッシュド持つのかみたいな、
いろいろあるから、本当にその、
どう実装していくのかなっていうのは考えるときに一つこう、
考える材料をいろいろ教えてくれたっていうのは確かに僕もそうだなと思いましたね。
Yosuke Asai
今思ったんですけど、Cacheだとお金になっちゃいますね。
Cacheって言わないと何か分からないですね。
ken
Cache。
Yosuke Asai
なるほど。
どっちなんだろうって。
ありがとうございます。
イントネーションが。
いや僕が、僕もそれ一回前に言われたんですけど、
Cacheだとお金だよってなんか上司に言われて。
ken
どっち?
Yosuke Asai
発音分かんない、どっちが正しい。
日本語、英語だから元々関係ないからあんまり。
ken
いや、ちょっとね、また間違ってたよって。
僕よく言われるんですよ、日本語の何かおかしいってイントネーションが。
Yosuke Asai
いや僕も言われたんで、どっちが正しいか分かんないです。
ken
ありがとう教えてくれて。
Yosuke Asai
いやいやいや、僕がおかしいと思ったんです。
ken
香港に留学してたんだけど、
英語だと、あれ?香港?香港?あれ?どっちがどっち?
なんか日本語で話すときも、そう、日本が香港だよね。
香港ですね。
僕は日本語で話すときは、香港って言っちゃうんだよね。
すっごい分かんないんで。
Yosuke Asai
Cacheさん、ロンドンの言い方も一時期ロンドンって言ってましたね。
ken
本当ですか?
独特で面白いなと思って。
そういうのをね、改善したくて日本語でポッドキャスやってるっていうところもあるんで。
改善する必要は別にないと思いますけどね。
そうかな、でもさ、やっぱ、うわって思っちゃう人がいるから、
やっぱり日本語で発信するときはちゃんと日本語として発信したいんだよね。
なるほど。
聞いてる人がいるから。
Yosuke Asai
面白いですね。
帰国シージョンみたいでいいですね。
Teppei Iwaoka
そうですね。
ken
リスナーの方々にはちょっと温かく見守っていただきたいなと思いますが。
Yosuke Asai
いや、全く違和感ないですよ、普段は本当に。
ken
どうですか?てっぺいさん、いく?
Teppei Iwaoka
そうですね。
トランザクションの重要性と限界
Teppei Iwaoka
洋介さんがおっしゃったログベースのっていうところは、
自分も結構勉強になったというか、
これ結構優秀かなって思ったようなシステム構成で、
今後そういうところにより注力というか、
興味を持って見ていきたいなっていう気持ちになりましたっていうのがあるのと、
あと、具体的、実際の生活の中ですごく勉強になったなっていうところでいくと、
一番はトランザクションの章かなと思っていて、
普段の業務でトランザクションを使うんですけど、
トランザクションをとりあえず使っておけば、
なんかうまいこといくんだろうぐらいの、
本当恥ずかしい話なんですけど、
理解しかなかったんですけど、
トランザクションを貼ったとしても、
それにはいろんなレベルがあって、
それで防げるもの、防げないものがあるっていうところを理解したりとか、
トランザクションをすべてに貼ればいいっていうものではなくて、
それによって遅くなったりとか、
そういうデメリットもあるんだよみたいなところを学べたのは、
一番現場で使える知識としてすごく勉強になったなっていうところは、
思いますね。
確かにね、トランザクション難しいもんね。
ken
そうですね。
Yosuke Asai
なんか一つの技術ですべてをカバーすることができないみたいな話も多分あって、
まさにそれもちょっと近いのかなと思ったんですけど、
その場面に応じて正しい技術を選んでいく、
ストレージでも正しいストレージを選んでいくみたいなことが繋がってくるのかなと思って、
すごい大事だなと思いました、聞いて。
本当にその通りトランザクションもそうだったし、キャッシュもそうだったし、
ken
僕が唯一一つ挙げるとするなら、
これリリア絵本、確か2013年かな、がされたのが出版、14かな、そこら辺だ。
日本語版が多分2015だと思うんだけど、
なんか全然本質的なものはまだまだ必要だなと思いました。
ちょっと読む前、実は不安だったんですよ。
古いかなと思って。
もっと新しいものが出てくると、
逆に時間を得ているからこそ、
残るものっていうのはそれだけ価値があるんだなって思いましたね、
データベースの業界でも。
表面的な技術はどんどん変わっていくんだけど、
例えば今回も読みながら皆さんが、
今のクラウドシステムだったらこういうデータベースがあるよって結構リンクを上げてくれて、
確かにそこは入ってないんだけど、
でもその本質っていうのは全然変わってくると思うんだけど、
なんか新しい研究が出てきても、
それって今までの研究を改善するものだから、
なんかDDIエボーに語られているような、
じゃあトランザクションが、
分散アルゴリズムはっていうのは、
なんかまだまだ引き続き考えていかなきゃいけないなっていうのが一番印象に残りましたね、私は。
うん、確かに。
まだこれから解決しがいがある問題がたくさんあるというか、
いろいろ考えていかなきゃいけないなっていうのが一番印象に残りましたね、私は。
うん、確かに。
Yosuke Asai
まだこれから解決しがいがある問題がたくさんあるというか、
いろいろ考えていかなきゃいけないなっていうのが一番印象に残りましたね、私は。
Teppei Iwaoka
なので、なんか第何版か分かんないですけど、
ちょっと最新のやつも出してほしいですよね、
その基本的なところは多分残りつつ、
そのもう少し最新化されているところは最新化された、
次の版が出るとすごい面白いなと思いますね。
ken
ねえ、いやこれ多分浅井さんもこれ挙げてくれたけど、
DDIエボーで改善、反論できるところがあるとすればっていうのは、
これだよね、なんかマーティー先生にフィードバックできることがあればいいかなと思って考えてくれたトピックだよね。
Yosuke Asai
そうですね、もしなんかこの先生に対して、
こんだけミスボケ読んだので、こういうところもっとこうしたらいいのではとか、
こういうところ今後どうなってくるのだろうかみたいな質問とかできたらいいなと思ったんですけど。
ken
これさ、やろうよ。
Yosuke Asai
ぜひ。やりますか。
ken
なんかさ、せめてメール出そう。
メールとか載ってるでしょ。
Yosuke Asai
確かに載ってると思います。
ken
反論とかなかったら感謝だけでもいいから、ちょっとみんなの連命で出そうよ。
おかげさまでこのブッククラブやって。
Teppei Iwaoka
そうですね。感謝はすごいですね。
ken
できれば改善面とかね。
Yosuke Asai
民族会のCと英訳して送りたいですね。
こんだけやったよっていう。
サマライズしてもらって。
ken
意味わかんない。
それはやろう。ぜひ。
あと一つ思った。
たぶんマーティン先生も第2版書いてるみたいにどっかツイッターで言ってたような、
これは僕が夢で希望で見ただけかもしれないけど、
もしなくても。
Yosuke Asai
ないつきすぎ。
ken
そこの差分をさ、この参加してくれた人で考えて、
いや、例えば僕はアパチカフカの最新のここ書いてないよとか、
例えばテペさんはバックエンドエンジニアから見た、
なんかこの反論とか回線があって、
それを技術書店とかでみんなで勝手に書いて、
ブログ連盟でもいいし、ちょっとした本でもいいし、
書いて、僕らの成果物として出しても面白いかもね。
Yosuke Asai
確かに。やりましょう、それは。
ken
マーティン先生がやってくれないのであれば僕らでやりましょう。
Yosuke Asai
面白いですね、それ。いいですね。
Teppei Iwaoka
結構、この分野は今後期待の持てる分野だと思いますみたいなとこ、
何度も出てきたと思ってるんで、結構ヒントはたくさんあると思いますね。
取り組むトピックとしては。
Yosuke Asai
しゅうへいさんも、何だっけ、2023年の今において、
特にこの最後の章でどういうところが変わってきているかとか、
結構変わってきているところが多いんじゃないかっていう、
多分問題だと思ってたので、そういうところも聞いてみたいですね。
ken
聞いてみたいな、これはやろう。
いいですね。
せっかくDDIMを読み切ったことだし、
これはここの3人を各々が次に読みたい本というか、
アサヒさんどういう気持ちで書いてくれたか聞いてみたいんだけど、
僕としてはじゃあ各々がこれを読んで次何をするか。
本でもいいし、ネクスト、アクションアイテムとして何をするかというのも込みで聞いてみたいですね。
次の展望と提案
ken
これはもう例えばアサヒさんの中では次にこれを読みたい本みたいなの決まってる?
Yosuke Asai
僕は卒業臨読会のトレードオフの本が気になっていて、
それを選んだ理由としてはやっぱりデータベースのことを一通り学んで、
次もう少しシステム全体というかアプリケーション領域も含めたシステム全体というか違う領域ちょっと行ってみたいなと思ったので、
それをさらにデータベースの知識を活かしつつ他のこともやってみたいなと思っているので、
そういうところを読んでいきたいなと思いつつも、
このデータベースで読んだ知識自体は本当に今の仕事にすごい活きてくるので、
どんどん自分の理解とかを活かして提案したりとか改善点を見つけたいみたいなところをやっていきたいなとは思ってますね。
ken
いいですね。あえてこうデータベースから抜け出すみたいなところは僕も全く同じようなのがあって、
データは抜け出さないんだけど、スケーラビリティとかリリアビリティ考えるの好きだからついついそこに行っちゃうんだけど、
あえて僕もコンフォートゾーン抜けて、もうちょっとこの倫理観とか、
それを組織でデータをスケー、何だろうね、エンタープライズデータを運用していくのはどういうことなのかっていうのを、
そこら辺に書かれたオライリーの本がいくつかあるみたいだから、
ちょっとそっちコンフォートゾーン抜けて、ハードな問題に向き合っていきたいなと僕は思ってますね。
Yosuke Asai
一番注目している本はどれですか、ちなみに。
ken
これ本読むときは結構目次だけじゃなくて、中とかフィードバックとかをレビュー見て決めるので、現時点ではないんですけど、
タイトルだけで見ると、データガバナンスとディフィニティブガイドとか、
あとはデータクオリティファンダメンタルあたりかな。
ちょっと面白そう。
もうちょっと詳しく精査してから決めるけど、タイトルだけで見るとここら辺が面白いかなと思ってますね。
Yosuke Asai
まさにこの最終章の内容が結構つながってきそうな感じのタイトルですかね。
ken
どうなんだろうね。でもさ、もしかしたらそんなに詳しく書かれてないと思うから、
いや意外とちゃんとした哲学書を読んだほうがいいってなるかもしれないよね。倫理家。
マイケル・サンドルの正義についてとかもう一回読み直したほうがいいかもしれなかったりする。
分かんない。
てっぺさんどうですか。何かありますか。
Teppei Iwaoka
そうですね。データベースの本を読んだので、データベースをもっと詳しく読んでいきたいっていうのは一歩でありつつ、
なので詳細データベースでしたっけ、小説っていうのも紹介ですかね。ありがとうございます。
っていうのもありつつ、なんかこのDDA本を通してすごくこういい本って改めていいなっていうのを感じて、
これDDA本ってやっぱり世の中的にもすごく高評価を得ていて、読んでみたらやっぱり良かったっていう経験があるので、
世の中的に良いと言われているものを他の分野でもちょっと見てみたいなっていうのはちょっと思ってて、
気になってるのはクリーン系があるじゃないですか、クリーンコードとかクリーンアーキテクチャーとか、
特にクリーンアーキテクチャーとかってすごい気になるトピックでもあるし評価もすごく高かったので、
そんな感じでそういうのを読んで、こういい本から各分野のエッセンスをもらいつつ、
自分の知っている領域を広げていきたいなっていうのが現状ですね。
ken
クリーンアーキテクチャー僕も読みたいなと思って、なんか事前に投票したんだよね。
僕はクリーンアーキテクチャーに投票した。クリーンコードは読んだんだよ。
もっとアーキテクチャーよりも読みたいなと思って、もしテッペーブッククラブサブで僕が参加しますので。
本当ですか。
Yosuke Asai
いや本当にやって欲しいです。並行したブッククラブとか。
Teppei Iwaoka
やりたいですね。やりましょうか。
ken
でもアサヒさんがやってくれたテンプレ、ブッククラブのテンプレが広がってるじゃない。
例えば友人さんも会社で入れてくれるみたいなのがあるから、
もしリスナーの方にブッククラブやりたいんだけどやり方は分からない的なところで迷っている人がいたら、
ぜひアサヒさんに連絡してもらって。
Yosuke Asai
そうですね。お釣りは高いですけど、やります。
ken
コンサル寮。ブッククラブ。コンサル寮。
Teppei Iwaoka
定着すると噂ですからね。
ken
定着するね。
Teppei Iwaoka
反復による定着をなんか仕組みとして取り入れていくとなってるんで。
ken
そうですね。反復による。
そうなんですよ。いいツッコミを入れてくれましたけど。
まずしゅうへいさんが言ってくれたのかな。
同じ本を4回タッチポイントがあると。
ブッククラブに出る前に1回読むと。
で、ブッククラブで当日に読むと。
そこで分からないことが結構出てきたので、
そのブッククラブ終わった後に、もう1回読むと。
その後で数週間おいて、ブッククラブのチャプターごとにディスカッションされた
ポッドキャストがロンドンテックトークというところからパブリッシュされると。
忘れたころにパブリッシュされるんで、
それを聞くことで記憶に定着するみたいなことを言ってくれていてですね。
ステルスマーケティングですけど。
Teppei Iwaoka
いやでも本当にいい反復だと思いますね。
自然な形で反復ができているので、めちゃくちゃありがたいです。
Yosuke Asai
なんとかんでもおいしいスルメイカみたいな感じですよね。
ken
そうですね。
おっと、それうますぎるでしょ。
じゃあもう最後にせっかくスルメイカだったDDIA輪読会全体の内容じゃなくて、
輪読会としてのまとめをしていきたいな。
これじゃあ最後にアサヒさんにまとめてもらうとして、
輪読会のパワフルな参加者
ken
僕、てっぺいさん、アサヒさんな感じでいこうかなと思うんですけど、
ブッククラブ、これ収録で言ってたよね。
2回目なんですよね、僕がDDIA本を読むのは。
で、DDIA本のブッククラブをするのは、
これね、さっき2回目って言うと実は3回目なんですよ。
クックパッドの時に2回してるんですよ。
クックパッドジャパンで1回混ぜてもらって、
DDIA本に行為をして、で2回目はクックパッドグローバルであったので、
それは僕ファシリーじゃなくて他の人が立ち上げたのに参加させてもらったんですね。
というか3回目なんですよ、実は。
今話しながら思い出したんだけど、
でもやっぱりメンバーによって全然違う。
同じ本読んでて同じテンプレでも中身が全然違う。
で、今回は結構僕が2回目に経験したテンプレと似てたんですけど、
やっぱりこのみんなの熱量がすっごかったよね。
その事前にDDIA本の感想を事前にみんなでGoogle Docsに書くんだけど、
その量、ボリューム、あと内容の濃さ、半端ない。
これはね、半端ないですよ。
これ売れ売れますよ、本当に。
リンクもあるしトピックのカバレッジもすごいし。
だからブッククラブの感想としては、
同じ本で同じ形式でもやっぱり参加しているメンバーの熱量とか、
あと多様性によって違う。
で、多様性も良かったなと思って。
フロントに強い人もいれば、アズールに強い人もいれば、
アバチカフカに強い人もいれば、バックエンドもエンジニアもいればということで、
そこも良かったかなと思っていて。
本当にそのブッククラブを運営してくれたアサヒさんもそうだし、
ファーストペンキーになってくれたテッペイさんにも、
おかげでこの濃いブッククラブできたというのは、
僕にとっても結構良い思い出になったんで、本当に良かった。
これをやっぱ再現性高く、他のメンバーとか他の人とか他の本でも
できるようになると、人生楽しいなと思った。
いやー良いですね。
Yosuke Asai
めちゃくちゃ良いですね。重いことないですね、これ。
ken
僕もだから本当にこれを受けて、技術本のブッククラブは2人が今後リードしてくれると思うんだけど、
社会学系の本とか哲学系の本とか興味ある人呼んで、
そっちの頑張っていこうかなと個人的に思いましたね。
Yosuke Asai
確かに幅を広げていくのもありですね。
ken
どうですか、じゃあテッペイさん。
Teppei Iwaoka
そうですね、ちょっとめちゃめちゃ被っちゃってあれなんですけど、
やっぱり内容が良いのはもちろんで、それによって得られたこともめちゃくちゃあるんですけど、
やっぱりこのメンバーですね、このフォーマットも含めこの回っていうのが
素晴らしかったなと本当に思ってますね。
やっぱりケンさんもおっしゃってましたけど、熱量がすごくて、
他の方がやられていることに刺激を受けてもっと頑張ろうっていう気持ちにもなりますし、
他の方との交流の中でこういうことされているんだみたいなところで
関心の幅が広がっていったりとか、
技術自体に対する興味っていうところもどんどん深まっていったような気がしていて、
なんかこう温かくて熱量があって、お互いを高め、お互いに慣れてるかちょっと自信はないですけど、
すごくみんなで高め合っていくような素晴らしい、この回、フォーマット含め人たちっていうのが本当に最高でしたね。
完全に同意、完全に同意。
ken
本当に楽しかったよね、議論がね。
楽しかったです。
続けていきたいですね。
ディスカッションと学びの機会
Teppei Iwaoka
そうだよね、続けていきたいね。
ken
じゃあ最後にこの輪読会をね、主体性を持って最後までやりきってくれた、じゃあアサヒさんのまとめで締めましょうか。
ありがとうございます。いやもう本当にお二人が言ってくれたことに完全に同意で、あんまり言うことないんですけど、
Yosuke Asai
私個人としては、この本の内容についてはかなり知識が浅めで、
その中で参加して、ある意味、私が一番得をしたというか、かなと思っていて、
この本の世界も浅い中で実際にモデレーターとしてやって、収録もやってっていうところを全部やってみて、
本当にしっかり準備をした気がないんで、その分学びも多かったですし、
その主役さんが言ったような何度も何度も繰り返して、
読んだりとかすることもあったので、なんかすごい一番身についたような気がしていて、
だからぜひこの経験自体は、なんかいろんな人にもやってほしいというか、
だったというのは個人的には思っていて、はい、なんでこの輪読会自体を継続したこともすごい良かったですし、
今後も継続していきたいですし、まああの、
やっぱりこの本の中に入ってくれた人たちに、
輪読会の継続と多様性
Yosuke Asai
継続したこともすごい良かったですし、今後も継続していきたいですし、
どんどん輪読会やってみたいっていう人にチャレンジするような場を提供できたらいいなというのも思っていて、
なんでこのロンドンテックトークで複数の輪読会を並行して走らせるとか、
好きな輪読会に参加するみたいなようなことができたらもっと面白いなというふうに思っています。
ken
超かっこいいまとめ。なんかこう、
ポッドキャストという化けの皮をかぶったブッククラブみたいな感じですね。
Yosuke Asai
インターフェースしかないみたいな。
ken
そうそうそうそう。いや本当に、たかがブッククラブされどブッククラブですよね。
なんかみんな集まってスケジュール調整して本読むだけの場って多分誰でも作れると思うんですよ。
でも、それを中身の濃いものにするってやっぱりファシリテーターの思いと準備と熱量だったんで、
本当にいいブッククラブを運営するっていうのはスキルだし、経験だし、
そこで一緒に参加してくれたメンバーとはこう、なんか声優感が出るよね、仲間。
飲み切ったね、みたいな感じがあるから。
いや本当に、これは本当に良かったし、再現性高くできるようになるともっと楽しくなっていくと思うんで。
多分今回のエピソードが公開される頃にはもうアサヒさん主体の別の次のブッククラブをやってると思うんですけど、
リスナーの方でも参加したいなということがあったら、Googleフォームからでもいいし、
XのDMでもリツイートでも、どの手段でもいいのでぜひ連絡ください。
今回のDBIA版も途中から参加してくれた人もいるもんね。
Yosuke Asai
はい、そうですね。まさにいつでも参加していたら大丈夫なんで、ぜひお気軽に参加してほしいです。
ken
はい、ということで、じゃあ本当にお疲れ様でした。やり切ったね。
Teppei Iwaoka
お疲れ様でした。
ken
じゃあ今日の収録もこれぐらいにしたいと思いまして、ペサも今日は参加してくれてありがとうございます。
Teppei Iwaoka
ありがとうございました。
Yosuke Asai
ありがとうございました。
ken
お疲れ様。
