-
-
ken
はい、リスナーのみなさん、こんにちは。London Tech TalkのKen Wagatsumaです。
本日はですね、Book Club第3弾でTidy First?の本を読んでいました。
今までパート1、パート2、パート3の振り返りを、それぞれゲストの方を呼んで話してきたんですけれども、
本日はTidy First?の総振り返り編ということで、Tomohisaさんをお呼びして振り返っていこうと思っています。
Tomohisaさん、ようこそ。今日はよろしくお願いします。
Tomohisa Takaoka
はい、London Tech Talkのみなさま、お久しぶりです。高岡です。今日はよろしくお願いします。
ken
はい、よろしくお願いします。実はTomohisaさんとこの収録の場で話すの、僕めちゃくちゃ久しぶりということで、
前回の個人的に楽しみにしてた石板会は、確か熱を出したかな、僕が。出れなかったんですよね。
Tomohisa Takaoka
はい、ちょっと久々。
いや、お久しぶりです。結構、僕の時は浅井さんが頑張ってくださったり、
かずさんがやったり、けっこうけんさんとやることが少なかったので、けっこう嬉しいですね、話せると。
ken
僕もです。今回はTidy Firstを餌にして、Tomohisaさんを呼んで、僕が話すという、そういう裏目的があるんですけど、
London Tech Talkを昔から聞いてくださっている方には、Tomohisaさんお馴染みだと思うんですけど、
簡単に最近から聞いてくれたリスナーの方に自己紹介をお願いしてもいいですか。
Tomohisa Takaoka
はい、高岡トモヒサと言います。日本住んでいるのはアメリカのカリフォルニア州に住んでいるんですけれども、
仕事は日本の会社とアメリカの会社、Jtech Japanという会社とJtech Creationという会社で働いているソフトウェアエンジニア。
会社ではCTOという職でやらせてもらっています。
特にアーキテクチャーとかそういうものが好きで、最近はイベントソーシングというフレームワークを作るというのが大きな業務の一環となっています。
そういうのがきっかけで、DDIAの本の話をするときにBookClubに参加させていただいたのをきっかけに、London Tech Talkのコミュニティに参加しています。
ken
ありがとうございます。BookClubもね、もう初回からお世話になっているんですけど、ちょっとその最近の仕事の絡みでトモヒサさんのほうなんかちょっとグッドニュースというか、
があるみたいということなんで、せっかくなのでちょっとそれを発表してもらおうかなと思うんですけど、お願いしてもいいですか。
Tomohisa Takaoka
はい。えっと、11月1日でしょうかね。マイクロソフトのMost Valuable Professional、略してMVPというんですけれども、世界中でも3000人ぐらい。
日本語話す人では200人ぐらいなんですけれども、そういうマイクロソフトテクノロジーでコミュニティに貢献している人が受ける賞というのを初めて受けることができました。
ken
すごい。おめでとうございます。
ありがとうございます。
日本人の中だけでも200人。世界でも3000人。
Tomohisa Takaoka
でもマイクロソフトってテクノロジーが非常に多くて、クラウドだったりオフィスプロダクトだったりAzureだったり、いろいろある中で、僕が受賞したのはデベロッパーテクノロジーという開発技術に関することで、
特にウェブデベロップメントとかドットネットという言語周りのところで受賞したということで、そのカテゴリーに絞ると100人前後という感じになりますね、日本人で。
ken
すごい。おめでとうございます、改めて。
ありがとうございます。
ニュースはディスコードの方でもちょっと投げてくれたときに、もう本当になんか嬉しかったというか、僕何もしないですけど、なんかそのMVPに呼ばれて、なんかそのMVPサミットみたいなのに招待されてるみたいな。
Tomohisa Takaoka
そうですね、MVPの得点っていうのがいろいろあるんですけれども、MVPサミットっていうのがその得点の一つで、シアトルかな、マイクロソフトの本社があるあたりで、
MVPの人だけが集まれるイベントみたいなのがあって、多分出れない人もオンラインで見れると思うんですけれども、その中では結構マイクロソフトの社員の人もまだ知らないような、現在の開発しているプロダクトの情報とかそういうのが出て、
NDAなので言えないみたいなんですけど、ただ新しい発表が出る準備みたいなのをできるようにということで、そういう情報が公開されているみたいなことで、新しい情報にキャッチアップするっていう点では結構面白いかなと思っています。
ken
素晴らしいですね。だからそのマイクロソフトのエコシステムとか開発とかに貢献している人たちに呼んで、ネットワーキングづくりとかプロダクトへのフィードバックをもらったりとか、お互いにとってコミュニティの場ということなんでしょうね。
なんかその賞をもらうまでのこのプロセスというか、そこも詳しく聞いてみたいんですけど、これは基本的に石板の開発に対してもらったということであってますか、それとももうちょっと総合的なコミュニティ貢献みたいな感じになるんですか。
Tomohisa Takaoka
そうですね。それでいうと半分半分なところがあって、マイクロソフトMVPっていうのはどちらかというと何というかスキルを証明するものだけではなくて、コミュニティに貢献している人に対して与えられる賞なんですね。
なのでなんかそのプログラミングコンテストで1位になったみたいなそういうタイプのものではなくて、知っている、どれだけ知っているかというよりも知っていることをみんなが知れることができるようにどれぐらい共有しているかということなんですね。
そういう点でいろいろ申し込みにこういうことやりました、ああいうことやりましたってやるんですけれども、その中にはもちろんロンドンテックトークでCシャープのことについて話しましたとか、
ken
嬉しい。
Tomohisa Takaoka
そのブッククラブに参加してその技術について一緒に話すことを行いましたみたいな、そういう活動みたいなものも書いているので、ほとんどロンドンテックトークのおかげで受賞できたといっても過言ではないということになるのかなと思います。
ken
そのアプライにはどれぐらいのドキュメントみたいなものがあるんですか、例えば2、3ページぐらいのPDFを書くみたいなイメージであってますか。
Tomohisa Takaoka
いや結構書きましたね。
そうなんだ。
コミュニティに貢献するためにどんなことをしているとか、自分の技術力があることがどうしたらわかるとか、だいたい1つ1000文字ぐらいのテキストボックスがあるのが7、8個あったみたいな感じなので。
結構ありますね。
3、4ページぐらい書いたかもしれない。それプラスこういう活動しました、ああいう活動しましたみたいな。なので、あと大きなものとしてはオープンソース活動っていうのは他の人が行動を見れるっていうことがあるので、そういう意味では石板の開発は大きな一員ではあるんですけれども、
そういう登壇活動とオープンソースが半々ぐらいかなと思ってますね。
ken
なるほどなるほど。このMVPはプロフェッショナルズということなので、個人に受賞されたということになってますよね。
Tomohisa Takaoka
そうなんです。だから会社の宣伝にはこういう個人が取りましたっていう感じでするので、完全にその受賞自体は個人に対してっていう感じですね。
会社でプレスリリース的なの出してくれるような。
ken
出すかもしれないですね。
Tomohisa Takaoka
いやめっちゃすごいですね。これ出されたのは初年1回目とかなんですか?何回か。
初めてですね。やっぱりコミュニティ活動をしていかなきゃいけなくて、石板の開発をしてリリースするということで、せっかくだからちゃんと宣伝していかないといけないなと思って、
コミュニティ活動を増やしたのがちょうど1年半とか1年半ぐらい前とかで、ロンドンテックトークのブックグラブに出始めた頃ぐらいから、ソーシャルのXとかやっていたんですけれども、結構iOSコミュニティとかがだいぶ昔で、その後キーボード作成コミュニティとか、そういう趣味のことが多かったんですけれども、
ちょっとがっつりエンタープライズ開発とかアーキテクチャーとか、そういうののコミュニティに入ってきたのがだいたいこの1年半とか2年ぐらいかなと思いますね。
ken
なるほど、そうだったんですね。これは、もちろん例えばともひささんの石板とか、あとはマイクロソフトエコシステムに対する貢献があって、例えばショーがついてくるだと思うんですけど、例えばリスナーの中で、すでにオープンソースをかじってますとかであったり、マイクロソフトエコシステムで仕事してますみたいな人が、これをちょっと考えてもいいかなっていう人がいると思うんですけど、
なんかそのアドバイスじゃないですけど、アップライの時にこういうこと気をつけたほうがいいよであったり、普段のコミュニティ活動も、もちろんこのショーを撮るということが目的で動くことにはならないと思うんですけど、どういうことを普段考えてモチベーションとか考え方とかでやってきたのかっていうのをアドバイスという形でもし言語化できるなら伺ってみたいなと思います。
Tomohisa Takaoka
そうですね、結構これを目標にすると大変かもしれないですね。なぜかというとコミュニティ活動って結構その体力いるんですよね。例えば登壇をすると思って30分の話しようと思ったら、もちろん30分1時間でできるわけじゃなくて、まず自分がそのネタを持っていないといけないし、
ネタを持っていたとしてもその登壇の準備って結構数時間、1日2日丸々かかっちゃうので、自分のタイトルのためにもらえたらいいなとは思ってたんですけれども、どっちかというとコミュニティ活動を楽しんでいたらついてきたみたいなのが理想的かなとは思いますね。
ken
なるほど。トモヒサさんにとってコミュニティ活動って楽しかった部分って例えばどういうところになりますか。新しい人の出会いとか、例えばフィードバックをもらった瞬間とか。トモヒサさんの場合は何だったのかなっていうのがちょっと気になりますね。
Tomohisa Takaoka
そうですね、いろいろありますけれども、まず1つはそのフィードバック的なことが嬉しいっていうのがあって、やっぱり例えばオープンソースでいいものを作っていたとしても、誰もダウンロードしたりとか使ったりしてなかったらやっぱりなんか虚しさが出てくると思うんですけれども、
その発表したときにこれ面白そうとか、使ってみたいとか、興味深いとか、そういうのフィードバックがいただけると結構嬉しいなというのがありますね。
ken
なんかこう思い出に残っている、記憶に残っている予想外のフィードバックとかってあったりしますか。
こんな使い方してるんだとか、こういう観点があったのかみたいな。
Tomohisa Takaoka
そうですね、結構最近それがやっとなんか出てきたっていうところがあって、石板もなんかこのリリースしたのが去年の12月だったので、最初は結構スロースタートで、もう本当に自分たちだけが使っているみたいな感じだったんですけれども、
9月だったかな、日本の結構大きなイベントでの吉祥寺FMっていうイベントがありまして、吉祥寺PMか、そのイベントでオンラインで登壇させていただいたんですけれども、
その時にイベントソーシングの話って知ってる人が多いものの、結構やっぱり普通の開発手法と違うので、ちょっとイベントソーシングの認知っていうのをやってみようと思ってやったのが、アンケートを作ったんですね。
ken
イベントソーシングを使ってアンケートシステムを作ったってことですか。
Tomohisa Takaoka
じゃなくて、Googleフォームでイベントソーシングに関する認識調査っていうのをイベントの前に、そのイベントに発表するネタとして、こういうイベントソーシング使ったことありますかとか、イベントソーシング使ったシステムは成功しましたかとか、
あと、イベントソーシングと聞いて思い浮かぶことは何ですか、使ったことがある人とない人向けの質問とかを準備して、それをですね、まず自分のソーシャルで出すんですけれども、最初は8件ぐらい集まったんですね。
で、8件ぐらい。でも、イベントソーシングを使ったことがありますかっていう質問の答えが100%だったんですよ。
ken
なるほど。
Tomohisa Takaoka
つまり、僕のイベントソーシングの発信を見て、お互いにイベントソーシングの情報共有をしてる人たちが答えてくれたみたいな。
ken
似たようなクラスターに、イベントソーシング詳しい人が。
Tomohisa Takaoka
それで、アンケートとしてはあんまり全然意味がないものだったんですけれども、もうちょっと意見が欲しいなということで、Xの中でイベントソーシングって呟いてる人に、みんなDMを送る作戦っていうのをしたんですよ。
Tomohisa Takaoka
なかなかあんまりなんかみんながやってる方法ではないかもしれないです。
ken
ちょっとやってみたいな。結構登壇もすごい勢力的にねされていたなというのを見ていて観測して、
なんかその登壇に対する友人さん流というかなんかこうアドバイスがあってぜひ聞いてみたいなと思って。
僕結構英語の登壇も何回かされてたかな。
Tomohisa Takaoka
英語は、
ken
YouTubeで1回か。
Tomohisa Takaoka
YouTubeで1回登壇して、また今月1個あるんですけれども、英語もやり始めているっていう感じですね。
ken
なるほどなるほど。なんか普段どういうスタンスで準備されているのかとか、
そうですね。スライド作りに自分流があるのかとか、
もしなければ普段どういうプロセスで、例えば準備しているのかとかってちょっと詳しく聞いてみたいですね。
Tomohisa Takaoka
そうですね。結構やっぱり人前で話すって大変じゃないですか。
ken
大変ですね。
Tomohisa Takaoka
そうですよね。
だから、僕はどっちかというと何を話したいかみたいな筋、
だからプレゼンの紙で準備するってよりも、
同僚も同じようにやっていて、その同僚から川谷さんね、石板の時にも出てきましたけど、
プレゼンをパワーポイントで準備するのじゃなくて、
まず過剰書きで意見をよく整理してから、それからやったほうがいいみたいなことを彼がいつも言っていて、
そういうのを実践して、だからポイントをまず自分の中で整理して、
書いていることは実際に読まなくてもいいというか、自然に話すみたいなのを意識していて、
なのでそういう意味ではプレゼンに書いていること、
パワーポイントに書いていることをなぞるというよりも、
パワーポイントはサポートにして、あとはできるだけ自然に話せるようにするっていうのは結構意識してますね。
ken
なるほど。なんか自然に話すっていいですね。なんか僕もちょっとこうグッとなりましたけど、
要するにファンシーなスライドとかすごい美しいビューティフルなものを作って見せるというところではなくて、
それがあくまで自分が最初に伝えたいストーリーを過剰書きにして、そこがはっきりしてからスライド作るみたいな流れってことですね。
Tomohisa Takaoka
そうなんですよね。だからそういう意味では英語でも色々人に話すことはありますけれども、
例えば英語の文法とか正しい英語とかを気にし始めたら全く話せないですね。
僕も子供がいるっていう、子供が今15歳と12歳なんですけれども、
12歳の子でも英語のレベルで言うと僕よりもすごく高い。
2人ともネイティブなので、だから僕が変な発音したら笑われますし、
これ間違えてるよって言われますし、文法に関してもその言い方は違うよとか色々言われるので、
英語力というところで勝負しようと思ったらもう全然ダメなんですけれども、
それでも話すのは慣れているので伝わればいいかなっていう、
間違えてるとわかっていても伝わればいいかなという感じで話すときは、
あんまりその細かなことを意識しすぎないようには気をつけてますね。
ken
なるほど、なるほど、いやそれめっちゃわかりますね。
まだパブリッシュされてないんですけど、ついこの前初めて英語のポッドキャスト収録にチャレンジしてみたんですけど、
Tomohisa Takaoka
すごい。
ken
もう文法気にしてたら全然話が止まっちゃうので、
はい、で、ちょっと頑張ってみたんですけど、
自分でレコーディング聞いてみたら自分の英語の癖というのがすごいもうわかってて、聞いてて恥ずかしくなるんですけど、
でもその通りだなと思いましたね、やっぱ文法気にせず。
やっぱり話すコンテンツがまずあって、それをちゃんとストーリーとして自分がこう伝えるんだみたいな箇条書きとかナレティブで、
言語化してたらやっぱ伝わるプレゼンになるのかなと、あの聞いた話だったね。
Tomohisa Takaoka
そうですね、けんさんね、英語上手だし、話慣れてるからあれだと思いますけど、
でもそれでもね、やっぱりネイティブの人たちと比べたら全然違うので、
そこの土俵に逆に持っていかないようにするっていうのが大事なのかなっていう気がします。
ken
いやもうすごいわかりますね。
なんかその、ちょっとコミュニティの話がすごい盛りがあったので、
Tidy First本番に行く前、メインに行く前にもう一つぜひ聞いてみたいのが、
今後のコミュニティに対するどういったイメージで何をしていきたいか、
どれぐらいコミットしていきたい、こういうことをしていきたいとかってあるのかなと思っていて、
今の延長で元石板とか自分たちが作られているものを、
例えば引き続き登壇を続けたりして、拡大していこうとしているのか、
また何か新しいやり方とか、人巻き込みとかいろんなものを試そうとしているのか、
一旦そのコミュニティ活動を止めて開発に専念するとか、
何かその今後の展望みたいなのを聞いてもいいですか。
Tomohisa Takaoka
はい。そういう意味では、このMicrosoft MVPっていうのが年更新なんですね。
だから2024年という、2024年から2025年っていうのを受賞したんですけれども、
毎年7月に来年も受賞しました、しませんでしたみたいな発表がされていて、
そのコミュニティ活動の継続によって、続くか続かないかっていうのがあるんですけれども、
そういう意味では今のペースぐらいだったら仕事しながらでもできるので、
できるだけそのコミュニティ活動っていうのは続けていこうと思ってますね。
そういう意味では、石板の話をちょっとできればと思うんですけれども、
石板がどっちかというと今のところまだですね、
中小規模システム向けのプログラムなんですね。
だから分散システムに将来的に対応するための取り組みっていうのはすでにあるんですけれども、
分散システムまでを簡単に作れるところまでは行ってなくて、
今の目標としては分散システムを簡単に作るためのサポート機能みたいな、
基本までないところを開発していくっていうのが今の目標なんですけれども、
そういう意味で自分たちの、私たちの会社でのやってるシステムだと、
もう今の石板でカバーできちゃうんですね。
私たち中小企業向けのエンタープラザから数百人、数千人ぐらいまでかな。
一部コンスーマー向けで数万人ぐらいまではありますけれども、
数十万人、数百万人みたいなシステムは今のところ作ってないので、
石板だともう数万人ぐらいまでは多分今のものでも耐えられるという状況なんですけれども、
でも使っていただくためにはもうちょっと大きなものにも対応できるような機能を追加していきたいなと思っていて、
そういうところを勉強しながら、そしていろんなDDNAの本とか特にそういう目的で読み始めたんですけれども、
そういうのを形にしていくという点で、まだまだやることたくさんあるので、
東壇もそういうことで学んだことを共有していくみたいな、そういう形で続けていこうかなと思っています。
ken
なるほど。中小企業向けには今すごい機能しているものをもうちょっと大きい規模にスケールさせていくっていう話がすごい興味あるんですけど、
その機能、何が足りてないんでしょうか。その機能が足りていないのか、
それとも数万規模で使われたときに、例えば負荷テストをしてみたときに洗い出されるようなパフォーマンスのデクレーションとか、
例えばアウトメモリ的なものを洗い出せてないみたいな、ストレステスト的な話なのか、
例えば何か想定しているような求められる機能が実際にあって、そこがまだ実装できていないみたいな話なんですか。
Tomohisa Takaoka
どっちかというと公社の方で、一番大きなマイルストーンみたいなものが、
マテリアライズドビューを簡単に作成するフレームワークなんですね。
要は分散システム、ケンさんとかはね、分散システムの会社で使っている会社で働いておられるので詳しいと思いますけれども、
書き込みのデータベースと読み込みのデータベースをどうやってつないでいくかみたいなところが肝になっていて、
小さいイベントソーシングシステムだと、インメモリでできるぐらいなんですね。
なので今必要なデータっていうのはインメモリにイベントをたくさん読み込んで構成しておけば、
それを返せば済んでしまうので、特に結構大きなAzureなりAWSなりの32ギガとかのインスタンスを使えば、
ほとんど今必要なデータというのはオンメモリに入れられるので、
ken
さつたばで殴るパターンですね。
Tomohisa Takaoka
でもそれは数百万人数千万人が使うともう全然一数台で足りなくなるので、
そういう意味でSQLに自動で書き出すっていう機能が必要になっていて、
読み込み用のデータを作るところは石板の機能で今でもできるんですけれども、
コンピューター上のデータとして取っているものを自動的にPoSGLなりMySQLなりに書き込んでいって、
変わったもの変わったものが読み出されるデータを作るためのフレームワークみたいな。
でも規模としては結構その石板をもう一個作るみたいな、
なんていうかすごいシンプルなものは簡単に作れて、
たぶん作れば数週間でできるようなものなんですけれども、
こうだったらああだろう、ああだったらこうだろうみたいな、
ken
そういうことを考えているとなんか結構作り、
Tomohisa Takaoka
今なんか設計色々考えているっていう感じですね。
ken
何なら石板とは相対するような別の大きなオープンソースでソフトウェアができてもいいぐらいマテリアライズドビューをしっかり作るってなったらね。
簡単に作れるようになるとおっしゃっていたので、
だからユーザーがすごい簡単なんだろう、
シンプルなコンフィグレーションとかAPIで、
例えばここに書き出してPoSGLにこういうふうに書き出してってやったら、
あとは石板がいい感じに作ってくれるところまでを目指しているっていうことですよね。
今もう自前で作ろうと思えば彼らは作れるけど、
それをもちろんさせたくないのでってことですよね。
Tomohisa Takaoka
そうですね。今でもCosmos DB、DynamoDBに書き込んだものをCGCで取って、
それをファンクションなりラムダで自分で頑張って、
エラーケースまで含めて自分で書いて、
マテリアライズドビューを作るっていうのはもちろん簡単にできるし、
大きな会社であれば多分そこからスタートするのでいいと思うんですけれども、
ただ石板の売りの一番大きな売りは、
イベントソーシングの細かな原理は分かっていないけれども、
イベントソーシングの原理をこの集約、
このグループのデータに対してこのイベントを出すみたいなのを、
結構簡単に定義することによってシステムが作れるようになっていて、
慣れればRDBで普通にシステム作るよりも、
イベントソーシングがいいから石板を使うのではなくて、
石板使ったら楽にシステム作れるからもうRDBでもいいんだけれども、
石板使ったほうがいいみたいな部分によっては結構そういう状態になりつつあっていて、
社内ではそういうふうに今使っているんですけれども、
それをそういう感じでマテリアライズドビューも使えるようにしたらいいなと思ってるんですけれども、
データの順番が結構大事で、
順番が変なものにできたときに古いキャッシュを引っ張り出してくるとか、
もう一回リプレイし直してデータを再構成するとか、
その辺はやっぱり自動でやるような構成にしてあげたいなと思っているという感じですね。
ken
そうですよね。
分散システムだとディレイドログというか遅延して遅れてくるものとか普通にあったりするし、
クライアントがどういうものかによりますけど、
例えばIoTデバイスであったりとか、
iOSモバイル、Androidクライアントとかあったら結構遅延して、
クライアント側でキューイングして後でバッファして送ってきてとかあったりするんで、
その対応もそうだし、
いやーなんか面白そうですね。
そうですね。なんかイベントソーシングを石板で楽になるみたいな世界線がもうでき始めてたら、
それこそ石板アザサービスとか作ってね、
それをSaaS上でパースになるのかな、
で表現できたりとか、そんな世界が来たらかっこいいですよね。
どうぞどうぞ。
Tomohisa Takaoka
どうぞどうぞ。
ken
なんかその抽象化の方向性として、
僕はKafkaが詳しいからだけど、
KafkaのKafka Connect的な抽象化の方向に近いのかなと思っていて、
知らないリスナーの方に簡単にさまると、
Kafkaもログを入れるプロデューサー側とログを吐き出すコンシューマー側、
自分たちでローのAPI叩いてかけるんですけど、
大体ほとんどの人が例えばイラスティックサーチに吐き出したいであったり、
FluentDから収集したいみたいなユースケースはほとんど8割ぐらい一緒なので、
そこも抽象化したKafka Connectっていうのを作って、
コンフィグレーションを書いてプロセスを動かすだけで、
自分たちで実際の行動をほぼ書かなくても、
例えばFluentDからKafkaのソースで入れて、
ピタゴラスイッチみたいな感じでイラスティックサーチに吐き出すみたいなところはほぼ書かずにできちゃうっていう、
Kafka Connectっていう抽象化のレイヤーがあるんですけど、
なんかそういう方向に似てるのかなと思っていて、
メイクセンスかなと僕は話聞いていました。
Tomohisa Takaoka
そうなんですね。なので、Kafkaは使う必要があったら使いたいなと思いつつ、
私たちの作ってるシステムの規模的にはそこまでやらなくても大丈夫なので、
今まであんま使ってないんですけれども、
多分そのKafka Connectが内部的にどんなことやってるかとかを見ていくと、
すごい今僕らが作ろうとしているものも解決の糸口みたいなのが見えてくるのかなと思うので、
勉強してみたいなと思いました。
ken
ぜひぜひ。Kafka Connect結構面白くて、
例えばKafka AからKafka Bに全てのログをコピーするみたいなのって、
例えば障害対応時のフェイルオーバーとか、
あとリージョンを移すみたいなオペレーションって結構やる作業だったりするんですけど、
それもKafka Connectを使ったミラーメーカーみたいなので、
彼ら自身の中で作った抽象化をうまく使って、
彼ら自身が作りやすいツールを作って、
そのミラーメーカーもこのトピックのログだけコピーするとか、
Tomohisa Takaoka
そういうのを作ってたりするんで、
ken
抽象化がうまくできると結構幅が広がるというか。
Tomohisa Takaoka
そうですかね。
ken
でもやっぱオープンソースなので抽象化って結構難しくて、
1回バージョン1でこういうコンフィグレーションにしますとか出しちゃうと、
なかなか買いづらかったりするし、
ブレイキングチェンジでV2に出すか出さないかとかって結構考えたりするんで、
そこは本当にチャレンジされてるなというのを聞いてて思いますね。
Tomohisa Takaoka
そうですよね。
グッドニュースとしてはまだほとんど社内以外は使ってないので、
社内の人にはこれ結構変わったけど、
書き換え手伝うからあげてみたいな感じでやってるんですけれども、
使う人が多くなったら大変だろうなと思いながら、
それもあって今のうちに大きい変更するなら、
使う人少ないうちにやっとこうみたいな、そんな感じで。
結構最近も河合さんと大きな変更の話をして、
今までの石板は何だったんだろうかと思うような、
新しい変更を入れようか入れまいかみたいな話もしてたりします。
ken
楽しそうですね。
いいですね。熱い話だ、いつも。
石板とかコミュニティ周りで、これは言っておきたい、言いたいことありますか?
Tomohisa Takaoka
そうですね。結構登壇みたいなのが、
今月、来月でも結構あって、
ロックがしている今日に初めてですね、
いつもは自分で登壇したい人はどうですか?みたいな感じで、
自分で申し込みするんですね、登壇の。
でも初めてこういうところで、こういうイベントするんですけど、
登壇していただけませんか?って言っていただいたイベントがあって。
声がかかった、すごい。
それがちょうど今日で、ちょっと録画はないかもしれないですけれども、
そういうイベントがあったり、あと、
これが出る日にもよりますけれども、
11月結構後半から登壇ラッシュになってまして、
英語の登壇が11月19日にあったり、
あと、ファインリーっていう、
イベントをいろいろやっている会社の、
アーキテクチャーカンファレンスっていうのがあるんですけれども、
これはスポンサートークになるので、
初めてですね、そういう石板のプロモーションも兼ねて、
スポンサーのブースを作って、
僕の登壇もするっていう日本に行ってするんですけれども、
それに出るっていうのと、
あともう一個、
CQRS ESカンファレンスっていうのが、
初めてですね、イベントソーシングですね。
ken
イベントソーシング。
Tomohisa Takaoka
はいはい。
CQRSとイベントソーシングに特化したイベントっていうのを、
日本のイベントソーシングについて発信している、
インフルエンサーの方たちが作ってくださって、
そこでもお話ができるということになったので、
11月、12月、いろいろ話があるプラス、
その2つは、ファインリとCQRS ESは、
日本に行って話すんですね。
すごい。
なので、日本の方、もしよかったら参加していただけると、
嬉しいなと思います。
ken
11月後半ですか。
じゃあちょっとそれまでにアダプティを置きます。
Tomohisa Takaoka
そうですね。26日がファインリで、
12月がCQRSカンファレンスになってます。
ken
なるほど、いや暑いですね。東断ラッシュですね。
Tomohisa Takaoka
ラッシュなんですね。
ちょうどだから今回は谷間でよかったです。
ken
いやー、ちょっとポッドキャストでたくさん宣伝のお手伝いさせてください。
Tomohisa Takaoka
ありがとうございます。
ken
はい、ありがとうございます。
なんかもう、すごいお腹いっぱいぐらい話しちゃったんですけど。
一応、どっちがメインかわからないですけど、
タイディーファーストの総振り返り編ということで、
今回はざっくり振り返るということなので、
友人さんの意見を聞くのがメインで来ています。
すごいアンチパターンのクエスチョンになってしまうんですけど、
タイディーファースト読んでどうでした?っていう質問はまず始めたいと思っていて、
パート1、2、3も簡単に振り返ると、
パート1は結構Tips的なものが多くて、
ケント・ベックがよく使うかな、いろんなテクニックに紹介されていて、
で、パート2からちょっとより理論的なものに入ってきて、
いつタイディするのかっていうことに関して彼なりの考え方とかを紹介されていて、
で、パート3では割と哲学じゃないですけど、
金融工学のオプション理論とかの話も組み合わせながら、
タイディっていうのはソフトエンジニアの開発においてどういう意味なのかっていうところを書いてましたね。
全体で7、80ページぐらいの短い本ではあったんですけども、
結構読んだ人にとってここが面白かった、
パート1ですごい勉強になったという人もいましたし、
パート3がもうちょっとよくわからなかったとか、
オプション理論の話、勉強になったという人もいたんですけど、
トモエサさんの場合はどういうところに興味があったりとか、
全体読んでどんな感想を持たれたかっていうのをぜひ教えてもらってもいいですか。
Tomohisa Takaoka
はい。
Tomohisa Takaoka
これはやっぱりみんなが考えると非常に価値があるものなんじゃないかなと思うので、
オプション理論とか僕も詳しいわけじゃないですけれども、
少しやったことがいつそれが効果が出るのかとか、
そういう考え方と、
コードのリファクタリングっていうのを一緒に混ぜて考えることができたっていうのが、
一番面白かったかなと思いました。
ken
なるほどね。本当そうですよね。
友人さんも会社でCTOという立場なので、
結構方針の全体のを決めたりとか、
タイリングに関しては全社こういうふうにやっていこうみたいな、
メッセージを発信できる側にいらっしゃるからこそ、
多分見えてくることもあると思うんですけど、
実際これを読んで何か変わった、
もしくは何かアクションしてみたことってあったりしましたか?
メッセージングの仕方が変わってみたりとか、
自分の中でこの考え方が変わったからちょっと方針を変えてみたりとか。
Tomohisa Takaoka
そうですね、実際会社でこの本を読んで興味深かったので、
このタイリング、リファクタリングで、
あといろんな会社でそういうリファクタリングの日を設けているっていう話も聞くことができたので、
ぜひ時間とってやってくださいねっていうのは実際会社でもアナウンスをして、
そういうふうに、この日は絶対しなきゃいけないっていうところまでは、
もちろん今はまだやってないんですけれども、
でもそういう意識は会社に伝えることができたので、
結構そういうふうにやっているチームも出てきているという意味で、
すごい良かったなと思いますね。
ken
めちゃくちゃいいですね。
そのひささんがちょっと関連してるんですけど、書いてくれた感想の後半でですね、
タイリングが開発者の快適性を取ることによって、
離職率が減ったり、チームが協力する空気が生まれ全体の意識が上がるなど、
優先するものは選んでいけると感じましたという話があって、
これパート3の時にもチームの雰囲気とか、
ちゃんとリファクタリングメンテナンスされているソフトウェアやって、
就職の引き付けですね。
だから会社側の観点になった時にメリットがあるよねっていう話をちょっとしたんですけども、
これに関してもちょっとともひささんの考えとか意見があれば聞いてみたいなと思っていて、
結構ふわっとしてると思うんですよね。
なんか開発者が快適だな、このソフトウェア書いてて。
なんか快適だな、ちゃんとリファクタリングされてるなって、
定量化しづらいところの感覚ではあると思うんですけど、
それに対して例えばその開発者が快適だなという感じるような雰囲気づくりって、
何かされてたりするのかなと思って、
結構ブッククラブで出た意見としては、
なんか会社が例えば年に何回とかのペースでスパデイとかハックデイみたいな、
決まった時間をとってリファクタリングするであったり、
ファンリストみたいなのはこの本でも紹介されてるやり方ですけど、
みんなリファクタリングしたいことリスト常に見えるようにやっといて、
時間があった人がやるみたいな、
それをモチベーション、マネジメントするみたいな、
いろいろあったりすると思うんですけど、
リファクタリングがされている環境システムとして作るというか、
開発者が快適だなって感じるような環境づくりという観点で言うと、
どういったアイディアとか考えて、
過去に実践した成功例、失敗例でもいいんですけど、
何か考えてありますか。
Tomohisa Takaoka
そうですね、プログラマーが会話とか、
いろんなチームの一緒にミーティングに参加したりするんですけれども、
プログラマーがプログラミングを楽しんでるなって思うチームっていうのは結構あって、
そういうチームっていうのはやっぱり技術的な話をチーム内で共有できていて、
例えばこういう本に関しての感想を言い合ったりして、
そういう風にやってみたいみたいな、そういうのがチームメンバーから出ている、
そういうチームは結構活気づいてるし、
いろいろどんどん新しいことを取り入れたりしているので、
そういう意味で、僕は自分がこういうのを楽しかったとか、やってみてよかったとか、
こういうリファクタリングしたら綺麗にできましたみたいなのは、
できるだけ会社内で発表するように、スラックとかに書いておくようにしておいて、
やりやすいとはなかなか言っても、
特にプログラミングの細かなテクニックみたいなのは、
言ってもやれって言われたらやりたいものではなくて、
自分もやってみたいなと思った人がやったらすごく効率がいいのかなと思っているので、
プレッシャーはかけないもののパスを見せるっていうんでしょうかね。
こういう風になものを取り入れたらよかったんじゃないとか、
タイリーファーストも読んで面白かったから読んでみるといいんじゃないみたいな、
そういう感じで自分の社内コミュニティ活動じゃないですけれども、
そういう意味で小さい会社なので、
大きな方針を決めるというよりも、先頭に立って走るみたいな、
Tomohisa Takaoka
それを見て、なんかすごいいいなと思って、
その文化を作るっていう意味では、
非常にいい成果の一つじゃないかなと思いましたね。
ken
なるほど。
そのチーム外の人を呼ぶという観点、めちゃくちゃ面白いですね。
それは、モブプロをする側が、
あの人がいい、この人だったらなんかもたらしてくれそうみたいな感じで、
ある程度狙って呼んでるんですか?
割とランダムで呼ぶ感じなのか、わかります?
Tomohisa Takaoka
そうですね、今は2つの大きなチームがあって、
そのチーム内で、こっちの人があっちに行ったり、
あっちの人がこっちに行ったりみたいな、
そういう感じで、一つのチームがよくできていることを、
いろんなチームに広めていくみたいな、
そういう感じで今、アサインしてやっている感じですね。
ken
なるほど、これ面白いですね。
僕のチームでもSREですけど、
なんかモブプロじゃないですけど、
モブデバッキングみたいな、
モブインシデントハンドリングみたいなのをやっていて、
結構難しいインシデントとかが出てきたときに、
3、4人で集まってワーワーするんですけど、
ちょっと真似してみようかなと思いました。
なんかそのドメインエキスパート呼んで、
一人呼んで、モブデバッキングしてみたりとか。
面白いですね、結構。
すごく面白いと思います。
新しいフレッシュな観点が入るという意味で。
いいですね。
じゃあタイリーファーストにの話戻るんですけど、
一方でこの本読んで物足りなかった点であったり、
なんか読んでもいまいち分からなかった点とか、
あとはこの本では話されてないけど、
あの本とかこういうキーワードとか大事なこともあるよねであったり、
例えばこの本読んだ後で次に何を読んだらいいか、
何を勉強したらいいか分からない人であったり、
なんかこれを、この本を申しんしすぎてる人であったり、
そういう人になんかこの本の限界点じゃないですけど、
何かその逆の観点から言えることがあれば
ぜひちょっと聞いてみないかと思っていて。
なんか結構短い本でもあったので、
結構ブッククラブの中でも、
ここちょっとケントペックの言ってること分からなかったよねとか、
英語がよく分からなかったよねみたいな結構意見もあったりしたんですけど、
富士山さんの観点から見て、
何かその、何でしょうね、
この本の限界点みたいな何か感じる場面はありましたか。
Tomohisa Takaoka
そういう意味で言うと、
なんか一人で作業することに関して結構まとめてくださっていて、
ken
なるほど。
Tomohisa Takaoka
チームでの複数のプルリクをどうマージしていくかとか、
チーム内でのコンフリクトを減らしていくとか、
そういうところに関しては何かあんまり扱われていないので、
確か単純な一人の作業だったら結構まとめられているんですけれども、
そういう意味では何かチーム開発についてまとめている本とか、
チームの開発を効率的にする方法みたいな、
そういうところに進んでいくステッピングストーンじゃないですけれども、
踏み台みたいな感じとして、
まずこのTidy Firstの本っていうのは良かったのかなと思ってますね。
ken
なるほど。
確かに今思い返すとブッククラブでも、
じゃあどうするのみたいな意見が結構出てきたと思うので、
チーム開発の観点は確かに足りてなかったような気もしますね。
ありがとうございます。
ちょっとね、もともとイメージしていた収録時間がそろそろ来そうなので、
Tidy First、ざっくりそんなところかな。
トメシタさんの方で最後、コメントしておきたいことがあったら、
ぜひ聞いてみようかなと思うんですけど、
3回目のね、出れなかったですもんね。
はい、そうなんですよね。
Tomohisa Takaoka
なんかケンさんに聞いてみたいこととしては、
オーガナイジングの方法っていうのは今回いろいろ調整したと思うんですけれども、
なんかそのチームとして結構上手くまとまったし、
なんか人もたくさん集まり始めていて、今回全部で十何人でしたっけ。
ken
14人?
14人くらい。
あそこら辺いないかな、12、3かな。
Tomohisa Takaoka
そうですね、12、3ですね。
しかも2チームに分けてやったみたいな、
その辺なんか振り返ってどう考え終わっておられるのかなっていうのを、
ちょっと聞いてみたいなと思ってます。
ken
ありがとうございます。
そうですね、今回はやっぱり1回目、2回目で
アサヒさんがいろいろエクスプローアしてくれたものがあったので、
それのいいところはそっくり真似して、
改善できそうなところは改善してうまくできたんじゃないかなと思います。
で、良かったのがタイムゾーン2つに分けたことは、
もうすごいメリットがいっぱいあって、
まず結構前回って3タイムゾーンに分かれてたので、