Wada Takutoの紹介
始まりました。ツナギメエフエム の第112回です。ツナギメエフエム
は、IT勉強会コミュニティ繋がり の方々をゲストに迎えて雑談する
ポッドキャストです。まずは、Xの ハッシュタグについてお知らせ
です。ハッシュタグはカタカナで ツナギメエフエムです。投稿を待ち
ています。今回のゲストはtsunagimefmさんです。 それではまずは自己紹介
をお願いします。
tsunagimefm はい。よろしくお願いします。tsunagimefm
さんと呼ばれますが、Wada Takutoと 言います。インターネット上では
twadaさんと呼ばれています。twadaさん と呼ばれるようになってもう20年
ぐらいになるんですけど、コンサルタント とか技術顧問とか、住宅開発とか、
オープンソースソフトウェアの開発 とか、講演とか、いろいろやって
いますというところです。よろしくお願いします。
tsunagimefm はい。よろしくお願いします。ついに
この日が来てしまいまして、tiaさん めちゃくちゃお忙しいと思いますし、
まさか出演してもらえると思って なかったので、ダメ元でお願いを
したら出演オッケーということで 正直とても緊張しかつ困惑をして
います。tiaさんといったらエンジニア にとってはもちろん有名な方ですし、
私の場合はTexter FMとか深堀 FMとかその辺のPodcastを聞かせてもらって
て、tiaさんの声を今映像をつなぎ ずつリアルタイムに聞きながら
収録してるので、さらに緊張が増 している感じです。今日はtiaさんの
普段の講演とかの話もそうなんです けど、講演とかで話されてない
ところについてもお話できれば なと思ってるんで、よろしくお願いします。
公演とPodcastの関連
tsunagimefm はい。よろしくお願いします。
tiaさん 忙しそうですよね。とにかく。
tsunagimefm 忙しいですね。
tiaさん 良かったんですかっていう のが正直なところなんですけど。
tsunagimefm 良かったっていうのは。
tiaさん 出てもらって。
tsunagimefm いや、出られて嬉しいな っていうところがあって、直接Podcast
出ていただけませんかっていう オファーいただいて、もちろん出ます
よって形で喋れることになった のでとても嬉しいです。今、夜収録
してるんですけど、夜であればいろいろ 喋れるというところもあります
んで。
tiaさん なるほど。
tsunagimefm ぜひぜひいろいろ喋れれば と思います。
tiaさん 今年開催されたTechラーメン で久しぶりにお会いさせてもらって、
そのときPodcastの出演にお願いを 直接させてもらったんですよね。
そのときにいいですよって言って いただいたんで、すごい嬉しくて
ですね。アイスブレイクじゃない ですけど、ちょっとびっくりしたん
ですけど、フェイスブックでですね、 tiaさんは最近誕生日の投稿されて
いて、実は同い年だったっていう のが分かってですね。
tsunagimefm そうですね。
tiaさん ちょっとびっくりしちゃいました。
tsunagimefm なかなか自分の年齢ってもう 僕だから40代後半なんですけど、40
代後半になると自分の年齢ってもう なんかほぼ関心がないというか
覚えてないもんで。今年何歳になる かってあんまりあんまりはっきり
と意識してなかったりするんですよ ねっていうので、ずばり一切間違えて
ました。
tiaさん びっくりしました。
tsunagimefm 結構でも同世代のエンジニア 多いはずなので、そんなに珍しい
ことでもないかなと思います。
tiaさん 近いのかなと思ってたんですけど、
まさか同じと思ってなかったんで。 最初にちょこっと話させてもらったん
ですけど、TextFMとか深堀FMを聞かせて もらってるんですけど、TextFM更新
が止まってるじゃないですか。あれ なんかどういった理由なのかな
と思って、っていうのが僕すごく好き で聞かせてもらってたんですけど、
その辺りお話できるところがあれば。
tiaさん ありがとうございます。よく 僕もいろんなPodcastに出演させて
頂いていて、よく出るPodcastとして 深堀FMとかTextFMっていうのがあった
んですよね。今お話しにあったTextFM っていうのはほぼメインのスピーカー
でずっと喋ってきたんですけど、 これが最近更新がないと。なんで
更新がないかっていうと、もともと PIXTERという会社がありまして、写真
とか動画とかを扱う会社なんです けども、そのPIXTERのCTOの後藤さん
っていう方が一種採用広報のために、 ユース広報とか採用広報のため
に立ち上げて行っていたっていう のがTextFMというPodcastでして、僕
がもともとPIXTERの技術顧問として ずっとお取引あったので、CTOの後藤
さんは弟子みたいな存在だった ので、早く2人で喋る。後藤さんが
ホストで、私がゲストで喋るみたいな 感じのPodcastやってたんですけど、
これが後藤さんがPIXTERを退職された ため、なんて言えばいいんですかね
TextFMっていう形での継続はないん ですよね。ので、どっちかっていう
とまた別の機会で、別の機会に また後藤さんとPodcastを撮れたら
と思ってますので、TextFMというパッケージ での更新は今後は多分ないと思います
基調講演の重要性
という形です。
なるほど。ちょっと回線のトラブル があったので、途中からになるんですけ
れど、TextFMがなぜ更新が今止ま っているかというお話をいただき
ました。そうですね。次の話題に行こう と思うんですけど、最初にティアワ
さんにお会いしたのが、PHP Conference 福岡2017だったと思うんですよね。
もともとそのPHP Conference 福岡って 公募だったと思うんですよ。ゲスト
みたいな形ではなくて、一般公募 みたいにして来ていただいたんですけ
ど、ああやって公募で申し込むのも されるんですねと思ってですね。
なるほど。そうですね。ドキドキっていう のは失礼な話で、そうですね。公演
最近の公演って割と依頼をいただ いて、招待公演とか基調公演みたいな
形でしゃべらせていただくことが 多いんですけど、それだけじゃなくて
やっぱり公募、CAFEとかで申し込ん でしゃべるっていうのもやるように
していて。PHP Conference 福岡2017 もやはり公募で登壇したかなって
形。これ自体は前年のPHP Conference 2016かなで、しゃべっていた内容
をブラッシュアップしてもう1回 しゃべりたいというような思いが
ありまして、PHP Conferenceでもう1 回しゃべろうというので、福岡で
しゃべらせていただいたっていう 背景があります。
なるほど。公募をいただいて選出 するときって、基本登壇者の方の
名前を伏せて点数みたいなのをつけて どうするこうするみたいなのを決めるんです
よ。タイトルがやはり目立つというか 内容なので、これは誰のかなんとなく
分かるなみたいな状態だったんですよ ね。なので、ティヨダさんが来たぞ
みたいな感じになるんですよ。
そうですよね。伏せてもある程度 僕そういう選ぶ側になったことって
ないんですけど、分かっちゃうもの ですよね、ある程度。
そうですね。なので、すごいみんな びっくりした記憶があって、そっか
公募で来るのかと思って、すごい 嬉しかったんですけど、それがすごい
印象的でした。
そうですね。公募で何回かしゃべら せてもらったりとか、時々公募
しても落ちたりとかもあるんです けど、それも割と本望というか、
他の依頼をいただいてしゃべる場合 って、当たり前だけど絶対うかる
っていうか、絶対しゃべれるじゃない ですか。その代わりどちらかという
と、求められていることとか、期待 されていることをしゃべるという
形の構図になるんですよ。もちろん プロとしてしゃべるので、期待以上
の成果を出すぞという形でしゃべ るんですけど、フリーテーマでしゃべ
れる依頼っていうのはほぼないん ですね。こういうことについて
しゃべってくださいとか、このテーマ でしゃべってくださいという依頼
があるので、そのテーマでしゃべる という形になる。それに対して公募
による登壇って、どちらかという と自分主導でしゃべりたいことを
書いて応募するみたいな形になる ので、その2つってちょっと性質
が違うんですよね。なので、ずっと 求められた講演ばっかりしている
と、それはそれで、例えば新作 みたいのはしゃべれないし、自分
がしゃべりたいこともしゃべりにくい 表現難しいですね。打率の低い
っていえばいいんですかね。自分が しゃべりたいんだけど、聞いてる
人に刺さるかどうかわからない ものっていうのをしゃべる機会とか
練習する機会っていうのが減って っちゃうんですよね。なので、公募
で申し込むときは、どちらかという としゃべりたいことをしゃべる
とか、求められていることだけではなくて 自分がしゃべりたいことをしゃべる
というような色合いが強いです。 個人としてはそこでバランスを
取っているところもあって、やっぱり 求められていることをずっとやって
いると、自分が全然そうではない 全然違うベクトルの何か新しい
ことをしゃべりたいとか、変なこと っていうのは奇抜なことをしゃべり
たいとか、そういったときにそういう のをできる場ではないので、公募
に申し込んでいくというような 感じなので、チパー会議もそうだ
し、PHPカンファレンス福岡もそうだ し、テクラメンカンファレンスも
基調講演を依頼いただいて、基調 講演はだから求められることを
しゃべるみたいな感じですけど、 それだけじゃなくてライトニング
トークスに申し込んで、ライトニング トークスではしゃべりたいことを
5分でしゃべりまくって終わりみたいな 感じの二面性を出しましたって
感じですね。
そうですよね、テクラメンのとき はLTをされてて、ティアワザさん
LTするんだと思って、基調講演だけ じゃないんだなと思ってびっくり
したんですよね、あのときは。
あれはみんなすごいワクワクしながら 聞いてましたね。
ありがとうございます。
今テクラメンの話が出ましたけど、 あの基調講演はすごい良かったですね。
基調講演そうですね。
最近予習じゃないですけど、ティアワさん 来ていただく前にティアワさんの
登壇の、YouTube結構上がってるので、 いろいろ見させてもらったんですけど、
レッドマインジャパンVol.2っていう イベントがあって、そのときに話されて
いた内容にちょっと近いなって ちょっと思ってて。
そういうことですね。
それをブラッシュアップしてしゃべった 形になりました。
ですよね。
この内容だったなと思って、テクラメン の内容って動画も上がってないし
スライドも上がってないので、確か どんな内容だったっけっていうのを
思い出せたのがすごい良かったな と思ってですね。
こういうことを話されてたなと思って。
あのときのお話聞いた後にみんな すごい良かったって言ってて、
僕は聞いた後にすごい何というか やる気が出たんですよ。
みんな口々に朝日川来て良かったね っていうことを言ってましたね。
そうですね。
地方で開催されるカンファレンスで、しかも 地元の技術者の方々が中心になって
立ち上げた新しいカンファレンスで 一発目の基調講演を依頼いただく
っていうのはものすごく燃える シチュエーションで。
はい。
なので、いつも喋ってることではなくて、 違うことを喋ろう。
もちろんレッドマインジャパンで一回 喋ってるので完全新作ではないんですけど、
レッドマインジャパンの講演ってそんなに 広く知られてるわけではないので、
あれをブラッシュアップして、ほぼその内容を 初見の人たちに向けて新しいことを喋ろう。
新しいカンファレンスなので、 新しい内容を持ってって喋ろうと思って、
結構前日まで寝たりして、
カンファレンスの重要性
普段喋ってないこと、喋らないことを 講演しようというような形で
喋ったという構図がありますね。
なのでやっぱりテクラ面の皆さん、 すごい熱いカンファレンス。
地元でやるぞと、例えば札幌の函館だけじゃなくて 朝日川でやるぞというような強い意思というか、
みたいな感じたので、 これは特別なカンファレンスだなと思って、
なので基調講演でいつもは喋らないことを喋るし、 ライトニングトークスに申し込むし、
パネルディスカッションでも喋ったので、 結果3回登壇したことになったんですけど。
そうでしたね。パネルディスカッションもありましたね。
いやー、パネルディスカッションも なかなか面白かったですね。
そうですね。
お悩み相談でしたけど。
そうそう。いいカンファレンスでした。
そうですね。本当あれはすごい良かったんで、 もしまた来年あるんだったら行きたいなと思いましたね。
そうですよね。
いやー、本当1回目の開催でDivaさんの内容が聞けたんで、 めっちゃ良かったですね。
ありがとうございます。
カンファレンスのお話が聞けたんですけど、
キャリアパスの考察
最初にですね、 経歴的なお話を聞こうかなと思ってたんですけど、
最近別のところでお話をされたということで、
聞いたFMっていうのがありまして、 そちらのほうでお話をされたということなんで、
ちょっと経歴的なところはスキップして。
そうですね。いわゆるエンジニアと会ったきっかけとか、 最初の頃にやってたこととか、
その辺りはある程度他のところで喋ったというのもあるので、 そちらをお聞きいただければと思います。
これは私のお悩み相談みたいなところもあるんですけど、
キャリアパスみたいなところの話をちょっと聞きたいなと思うんですけど、
なんとかこの年まで生き残っては来てるんですが、
特にキャリアってそこまでしっかりしたビジョンみたいなものを持たずに、
今までなんとなく来てるんですよ。
来てるんですけど、このままでいいのかなみたいなのは、 結構誰しも不安を持ってるんじゃないかなと思ってるんですけど、
飯窪さんはキャリアパスとかってどういうふうに考えてこれまで来られたんでしょうか。
それ言うと僕も全然偉そうなこと言えなくてですね。
キャリアパスなので、僕たちも同い年っていう話がさっき出たじゃないですか。
だからキャリアパスもなんもない世代なんですよ。
そうですね。
なんて言うんですかね。ちょうど僕の話で言うと、大学に入った頃にインターネットというものが始まったぐらいの世代なんですよね。
なので、例えばウェブシステムのソフトウェアエンジニアなんて人はいなかったんですよね、それより前には。
割と手探りでいろんなことをやるとかいう形で進んできた世代。
よく何々世代っていうと、僕たちは76世代ってやつなんですよね。
76世代ってそれより年上になるとウェブエンジニアがあんまりいないという世代になるので、
簡単に言うと、ロールモデルってやつがいなかったんですよ。
ああいうエンジニアになりたいみたいな人がウェブの世界には、そもそもウェブの世界ってやつがなかったからいなかったので。
だからお手本がないとビジョンとかもないんですよね。
あまりお手本とかビジョンとかそういったものを得られずに進んで、暗中模索で進んできたっていうところがあって。
キャリアってだから、よくキャリアに関する質問もいただきますし、
例えばソフトウェアエンジニアのキャリアに関するテーマのカンファレンスで登壇してくださいみたいな依頼をいただいたりとかもあるんですけど、
なんていうか、率直に言うと私のキャリアなんて全く参考にならないだろうと思えないんですよね。
運ですとかそういう話にもなりかねないし。
ただ完全に運のみかっていうとそうでもなくて、やっぱりその運とか自流みたいなものと、
それが回ってきた時にそいつをつかんで離さないとかつかんでついていくみたいな、
技術力とか馬力みたいなものというのをともに兼ね備えていくと、ある程度キャリア的にはうまくいくみたいな側面がきっと一般論ですけどあるんだろうなと思ってて。
だから運のみでもダメだし、なんていうか実力のみでも運がなければダメだしみたいなところが残酷だけどあるんだろうなとは思うんですよね。
なので僕の場合は自分が好きでやっていたプログラミングとか、コードとしてテストを書きながら開発するという手法、
テスト駆動開発として知られている手法ですけど、
そのあたりどっちかっていうとキャリア的な狙いがあって得たスキルではなくて単に好きだからやってるんですけど、
好きだからやっているものがたまたまどっちかっていうと、この業界においてまあまあ必要な技術であるという風な流れになってきて、
近年さらにそれが加速してるんですけど、なので好きでやってるものが世の中に求められているものだったので、
今の自分のキャリアにつながっているという身も蓋もない話です。
だからキャリア、狙いとして妖怪を良くしようとか、あるいは競争力のあるスキルを手に入れようとか、そういう話ではないんですよね。
そうではなくて、好きでコードとテストコードを書いてたらそれが業界にだんだん見向きもされながら、最初は見向きもされてなかったんですけど、
業界に必要とされるようになってきたり、知られるようになってきたりしたっていう、全部は後から来たっていうだけの、私個人に関してはだけの話です。
さらにそこに関わって、これは後から自分で自覚した話なんですけど、私自身は技術についてとか技術の背後にある考え方とか哲学とかそういったことに対して、
喋って人に説明するっていうのが、人よりは得意、上手いということだったんだろうっていうのが後々になってわかったんですね、自分にとって。
だからこれは自分にとっては、なんて言ったらいいんだろう。自分にとってはそこまで特別なものとか特殊なものだとは思っていないんですけど、それが世の中に必要とされたり、他の人に高く評価されたいっていうのが、キャリアにとってはとても大事な気づきとか瞬間になると思うんです。
自分では大したことやってないと思っているものが他の人に感謝されたり評価されたり、そういうのって実は自分が競争力を持っているということを認識する大事な瞬間なんですよね。
私にとってはなので、プログラミングとかテスト駆動開発は単に趣味でやってたものが、なんか業界で大事そうな感じになってきたっていうだけの話なんですけど、人前で喋るとか、考えを人に説明するとか、あるいは小きめの企業の偉い人たちに説明するとか、
そのあたりの、自分ではそこまで、なんというか、すごく頑張っているというほどでもない。難しいな。いや、最終的には仕事なんで頑張ってるんですけど。力んでるわけじゃないんですよね。
話し手1のことですね。
話し手2のことですね。
話し手1のことですね。
話し手2のことで。
講演活動とその意義
いつかというと、2005、6年ぐらいなので、今でいうと結構昔なんですけど、それは僕のキャリアが単に長いからってだけの話で、
何年目かというと、キャリアとしては何年目だ?5年目ぐらいかな。5年目ぐらいのときに、講演を初めてやったら受けがよかった。
それまであんまり講演ってしたことなくて、ブログに書いたりとかはしてたんですけど、喋ったら結構受けがよい。
で、次の月に、月1で何か読書会みたいにやってたんですけど、読書会で穴が開いちゃったっていうのは、次の本決まるまでにちょっと空きがあるので、せっかく集まってるからみんなでつなごうっていうときに講演をしたんですけど、その講演が受けがよくって。
で、翌月もやって、それを受けをよくってみたいな感じで、自分では普通の、それまでのわかった技術的なことを喋ってたんだけど、とても評価が高いなというのが原体験になって、そこからいろんなところで喋るようになった。
で、喋ると、成功すると、やっぱり次の舞台がやってくるんですよね。ここで喋ってほしい、自分どこでも喋ってほしいとか、このカンファレンスで喋ってほしいみたいな感じのものがやってくるので、いろんな舞台で喋っていくうちにだんだん両言語で鍛えられていくというような感じです。
それが最初に登壇するきっかけみたいなところだったってことですね。
うんうん。なので登壇するきっかけは、読書会とかいい勉強会とか月1位ぐらいでやってたんですけど、次の読む本が決まらないっていうので終わっちゃうのはもったいないなと思って、つなぎの講演しようと思って、講演したら受けがよかったっていうのがきっかけです。
今はいろんな講演の依頼とかが来てると思うんですけど、年間どれぐらい講演とか登壇とかされてるんですか。
講演とか登壇ですよね。数える年も数えてない年もあるんですけど、パブリックなものと、そうじゃなくていわゆる技術顧問先とかで喋るみたいな、カウントに入れると大体年間50講演ぐらいです。
おー、50。すごい。やっぱお忙しいですね。
忙しいは忙しいですね。その代わりなんですけど、50講演なんですけど、僕は講演者の中でも多分かなり再演が多い講演者なんですよ。
なので50講演、50個全然違う講演してるっていうんじゃなくて、レパートリー的には年間50回喋るとしても、5、6種類ぐらいの講演を50回やるみたいな、そんなタイプです。
僕はそれはなんていうか、悪いことだと思ってなくて、なんていうか、講演者の中には毎回新しい内容喋りたいっていうタイプの講演者もいるんですけど、私は何回でも同じこと喋るよというタイプで、
なんでかっていうと、私の話を聞いてくださる方は大体初めて聞くんですよね、その内容。なんていうか、熱心な方の中には何回かこの話前も聞いたなということを思われる方、リピーターの方みたいな方もいらっしゃるはいらっしゃるんですけど、
大部分は私が喋るところを初めて聞くし、初めての内容に触れるというところなので、同じ内容を何回も喋るというのは全然悪いことではないんですよね。
初めてその内容を初めて聞く人にとっては初めての講演ですし、喋る側としては当たり前ですけど、同じ講演を繰り返せば繰り返すほど喋りがうまくなるんですよね。
タイムコントロールもうまくなります。アドリブンを聞くようになって、しかも同じ講演をずっと続けるかというと、毎回若干若干ずつですけど、改訂を入れるんですよ。改善を入れるので、ここ刺さってなかったなっていうところを改善したりとか、
走るとこ走ったりとか、膨らませるとこ膨らませたいみたいな感じで、毎回微調整を繰り返しながら一つの講演っていうのを何回も喋りながら練り上げていくので、結果当たり前ですけどうまくなるんですよ、喋りが。
喋りがうまくなると、依頼してくださった方の期待に応えられるというような構図になっているんですよね。依頼してくださった方が、私が喋って、喋ることによって何かを届けたいっていう徴収がいるんですね。
この人たちにこういうことを伝えてほしいという依頼が来るので、そこに一番効果的に考えが伝わるような喋りをしようと。なので、練習を繰り返せば、本番を繰り返せばそれだけうまくなるので、依頼してくださった方の希望に応えられる打率も上がるというような構図になっています。
話し手2「悪ビレず何回でも同じことを喋ります。例えば、質とスピードという講演が、僕の中だと一番再演以来の多い講演なんですけど、もう何回だろう、この間45回ぐらい喋ってるはずです。
なので、そうすると、大体社内で喋ってくださいという依頼が多いんですけど、社内で喋ってくださいっていうことはつまり、自社のサービス開発において、質と品質とスピードっていうのはトレードフだと思っていて、今はスピードが大事だから品質を落としてスピード上げようみたいなセリフがまかり通ってるみたいなところに対して、
僕が何を喋りに行くかというような形になるので、なるべく全社員を集めて、スラックとかで実況をガンガン回して、同じ瞬間を共有する。
で、自社社員が、仲間たちがこの講演を見て何を思ってるかというのを、感情を垂れ流しながら実況してもらうんですね、スラックで。そのスラックでどんどん流れていく実況とか感想とか質問とかそういったものが、講演の実は本番になるんです。
社内講演とスライド作成の工夫
私の講演をリアルタイムで見ている同僚たちが、また部下とか上司とかそういった人たちがリアルタイムの同じ講演に対して何を考えているかどう感じているかというのを目撃してもらうというような体験自体がその社内講演においてすごく大事な瞬間であるというような形で喋ってるというようなのが最近の仕事、社内講演の仕事ですね。
なんか再演をされているっていう話はすごい感じることがあって。
そうですね。
一発勝負だとそれはできないので、ある程度感が働くような、だから、初演の講演でそれはできないんですよ、絶対に。なので、それは再演だからこそできる芸当だなっていうところはありますね。
ちなみにその再演とかの場合、まあ再演にも限らないですけど、練習ってどれぐらいされてるんですか?
再演に関しては、再演の練習っていうのはあまりいらないんですよね。なぜかというと再演を繰り返してるからですね。
なので、新しく、再演のたびに例えば新しい調査のデータが出たらその新しい調査のデータに入れ替えたりとか、最新の内容に入れ替えたりとかはしているんですけども、
やっぱ再演っていうことになると、ある程度何分で何を喋るとか、どこに何を挟むみたいなことはある程度見えてるので、
毎回練習しなくとも大体大丈夫という領域にはなってるんですけど、初演の場合は不安なので練習しまくるみたいな感じですね。
岩田さんのスライドですごい気になることがあって、結構スライドの中にですね、いろんな書籍から引用を持ってくるところがあるじゃないですか。
あれすごい特徴的だなと思うんですけど、ああいうのってスライド作るときに事前に全部頭に入ってるものなんですか?
あの本にこういうこと書いてあったから、これを載せるかみたいなのってすっと出てきてるんですか?それともスライド作るたびに調べて持ってきてるのか、そのあたりがどうなってるんだろうと思って。
なるほど。このあたりはどっちかなっていうか、その中間というかネタ帳みたいな感じですね。つまり、いろんな個人としても技術書を読むし、いろいろな技術古文の技術古文業の一環として社内読書会みたいなものをいろんな会社でやってるんですね。
いろんな本を選んで読んでっていうときに、やっぱりいいフレーズだなとか、ここはいいなみたいなクオートしたいところがいろいろ出てきます。これいつか講演で使おうみたいなやつをネタ帳みたいなところにストックしておくみたいな感じですね。
なるほど、そうなんですね。
講演が決まってから調べに行くっていうよりは、どっちかというと日々読んでる本の中で、これはいつか引用しようとか、これはいつか引用するかもみたいなところを抜き出してあって、あるいは覚えていて、それをリロードしに行く、確認しに行くみたいな感じですね。
本読みとしては、これはたぶん得意不得意の話だと思うんですけど、私個人の話で言うと、私は読んだ本に関してはどこに何が書いてあったかを覚えているたちなんですよね。
なので、誰が書いたどの本のどのあたりにどういうことを書いてあったかっていうのをある程度、読んだ本に関してはある程度覚えているので、なのでここでこの人こんなこと言っちゃったよなみたいな感じで本めくりに行くと、そうそうこれをクオートしようとしてるんだったみたいなのがあったりするっていうのはあります。
いやもうすごい気になっててあれ、なんか引用がいつも多いというかそういう印象だったので、あれ常に頭に入ってるのかなどうなのかなと思ってですね。気になってたんですよ。
印象に残る講演体験
なので、細部は覚えてないんですけど、例えばボブおじさんがクリーンアーキテクチャーのこのページあたりでこんなこと喋ってたよなみたいな印象を覚えてるっていうのがあって、これいつか引用しようみたいな、このセリフはすごいなとか、いろいろそういうのがいくつかありまして。
そういうのは、なので、強く本に結びついて覚えているので、それをめくりに行くっていう感じで、僕、紙の本がいいか電子書籍がいいか議論みたいなのってあるじゃないですか。
僕の講演の動画をご覧いただいた方は、僕の背後に本棚があるみたいな画像を見たことある方いらっしゃるかもしれないんですけど、あれ僕だいたいオンライン講演って書斎でやってて、書斎壁一面が本棚になってるんですけど、割と紙の本を重視するタイプで。
なんでかっていうと、人間の記憶ってやつは場所にひも付くことが多いと言われてるらしいんですね。
たぶんこれを聞いてる皆さんも、経験があるんじゃないかと思うんですけど、いつどこで何をやったか。記憶と場所というやつがひも付いているという経験をされた方って結構多いんじゃないかなと思うんですね。
書斎に関しては、それが紙の本のページに相当するというような感覚を持ってて。なので、どの本のどのあたりにどういうことが書いてあったっていうので、紙の本の座標っていうかページというか、どの本のどのあたりっていう物理的な記憶として残ってるって言えばいいんですかね。
なんとなくわかる気がします。
ありますか。
最初の本に書いてあったよなみたいなのはある気がしますね。
ありますよね。ので、そういったところはやっぱり無視できないなと思ってて。なので、特に仕事としてコンサルティングとか顧問業みたいなこともやってたりとかもあるんですけど、
わりと短い時間で参考文献の中から引用できるとか、参考文献、その内容だったらこの本のここにこういうこと書いてあるよみたいなのを答えるのが必要になる場面って意外とあるんですね。
そういったときに、どの本のどこにどういうこと書いてあったかなっていうのをある程度パパッと覚えていて出せるというのは、これもやっぱり競争力なんですよね。差別化要因に。
なので、紙の本を結構重視している。ざっと概覧できるっていうのもあるし、例えば本棚のどこにある本。こういう背拍子だった。その背拍子の本のここにこういうこと書いてあったみたいな形の記憶と結びつけてインデクシングしてるみたいな感覚なので、
やっぱりそういったインデクシングが必要になると思うんですよね。
何か書き込んだり。割と僕は本を汚すんですけど、何か書き込んだり黄色い線引いたりとか。ちなみに線引きながら読むとかは科学的な根拠があるかっていうとそうでもないと言われてるんですけど、でもやってみるとページをザーッとめくって黄色いマーカーでマーキングされてるとか赤いペンで何か書き込まれてると、やっぱりそこから目に留まるし記憶がバーッと出てくるというところがあるので。
記憶を瞬時にロードする装置として、紙の本、紙の本というより本棚っていう装置って言いますから、本棚と紙の本っていうのがそういう役割を伴って一緒に仕事してるというような感じです。
リモートワークをするようになって、本棚のある部屋で仕事できるようになったっていうのは大きいですね。
岩田さんの先ほど本棚の位置の話をされてましたけど、それは登壇中に感じることがあって、オンライン登壇の動画とかを見ると、この書籍のって言って後ろの本棚からバッと取り出すんですよ。何の迷いもなく。
あのシーンを見てると、あ、覚えてんだなっていうのがすごいわかりますね。
そうですね、そうですね。なので本棚のどこにどの本があるか、その本のどのあたりに何が書いてあったかっていうのは、つんどくじゃないやつに関しては、読んだ本に関しては覚えてます。
つんどくももちろんいっぱいあって、つんどくに関してはもうなんか期待値を覚えてます。
この本にはこういうことが書いてあるんだろうなとか、こういうことが知りたくなったらきっとこの本をまためくるに違いないというふうに、期待値を覚えて本棚に沿っとしまうみたいな、そんな感じですね。
なるほど。ちょっと登壇にまつわる話をいろいろ聞いてるんですけど、これぜひ聞きたいのがあってですね。
過去これまでのいろんな登壇あると思うんですけど、マイベスト登壇とマイワースト登壇というか、これはちょっと反省があるなみたいなのをちょっと聞きたいんですが、このあたりでどうでしょう?
ベストはなかなか決めづらいけど、そうです。
マイベスト講演はDev Summitで喋ったシストスピードになるんですね。
シストスピードって何回か喋ってるんですけど、Dev Developers Summitで喋った、あれは何年だったろう?
コロナの直前かな?2020年かな?そのあたりで喋ったのがベストといえばベストなんですけど、私自身はどっちかっていうと常にベスト講演になるように喋ろうと思って喋ってるので、
例えば今年の初頭に喋った実力レガシーコード改善という講演があるんですけど、これはオンライン講演なんですけど、あれも自分の中では今年のベスト講演だと思ってますし、
そうかと思えば今年の中盤に開発生産性カンファレンスとかDevelop by Experience Dayというカンファレンスでテストに関する、自動テストに関する講演をしたんですけど、これも自信を持って良い講演だったというふうに言えるので、
あんまりどれがベストというのを決められないんですよね、実は。結構どれも自分の中では良いと思ってるという感じです。
ありがとうございます。そんな中で常にベストの講演になるようにされてるとは思うんですけど、過去にこんなことがあったなみたいなのは何かあったりしますか?
そうですね。いくつかあります。反省がある登壇とか。例えば、体調を整えられなかった講演とかはやっぱり反省があって、内容はすごく自信があるけど、喉の具合はだいぶ厳しかったな。
体調万全な状態でいけなかった講演なので、内容的にはすごい自信を持ってるんですけど、登壇者のコンディション的には申し訳ないというような感じでしたね。
なるほど。その動画拝見しました。辛そうでした。
そうなんですよ。ギリギリのところで喋ってるみたいな講演になっちゃってて、内容は結構自信ある内容だったんですけど、喉は辛そうでしたね。
というのが、ワースト、ワーストカテッドだから、そんなに内容は自信あるんですけど、コンディションが良くなかったですね。
他に何か覚えてるのありますか?
そうですね。覚えてる登壇とか緊張してた。緊張っていう意味だと、実は僕はかなり緊張するタッチなので、再演だろうが、なんだろうが、本番前は緊張するんですね。ガチガチに。
そうなんですね。
ガチガチに緊張するんですけど、壇上に立つとアドレナリンが出て喋っちゃうみたいな感じなので、直前はかなり追い詰められていて、壇上に立つとなぜか生き生きとしてしまうみたいな感じです。
印象に残ってる講演としては、国際カンファレンス、セレニウムっていうテストのツールと言えばいいんですかね。
サイブラリーでありツールでありっていう感じなんですけど、セレニウムのカンファレンスっていうのは国際カンファレンスなんですけど、それの基調講演をさせていただいたことがあって、
これが英語で資料を作りますし、僕は日本語で喋っていいんですけど、同時通訳の方がいらっしゃって、同時通訳で参加されるお客様も半分以上外国の方かな、みたいなぐらいのところなので、
国際カンファレンスで喋るっていうのは珍しい、僕の中だと珍しい経験で、やっぱ同時通訳の人がつく講演っていうのは独特の緊張がありましたね。
事前に何を喋るかっていうのはかなり通訳の方と綿密に意思疎通を取らなきゃいけなくて、なので壇上でアドリブを聞かせて脱線しまくるわけにはいかないですし、
講演資料もスクリプトみたいな、つまり私が日本語で何を喋る予定かというのを結構な量書いて渡さなきゃいけないみたいなところがあって、やっぱりそれは特殊な経験で面白かったですね。
コンサルティング業務の詳細
面白いですね、東壇の話いろいろ聞けて。
そうですね、ちょっと話題を変えましてですね、東壇とか講演もお仕事とされてると思うんですけど、そもそもコンサルティングっていうところがメインのお仕事だと思うんですね。
最近のお仕事はどんなことをされているのかっていうのがちょっと興味がありまして、1週間どういったスケジュール感でどんなお仕事をされているのかなっていうのが聞きたくてですね。
そうですよね、あまりそういうことを外でしゃべるってことはないので。
なので私はメインとしてはコンサルティング業が最近は多いです。
なのでコンサルタントとしては技術顧問業ってやつをやってて、あとは住宅開発を時々やって、オープンソフトウェアの開発をやったり、翻訳とか簡訳とかをやったりみたいな感じになるので、
1週間の仕事の割合としては、技術顧問業というのを定期的には3社やってまして、各社特定の曜日と紐づけてます。
つまり何曜日はこの会社の技術顧問業をやる、何曜日はこの会社の技術顧問業をやるみたいな形で。
なので3社やってるので、3つ曜日が埋まってるという感じになります。
週5日働くとすると、そのうちの3日間は技術顧問業特定のこの週は私がいますというような形でやってるんですね。
そうすると残り曜日は2つという話になりますね。
で、その2つで定期的ではない不定期の仕事とか単発のいわゆる研修とか社内講演とかコミュニティの講演とか、そういったことをその空いている曜日、2つの曜日に入れていく。
つまり週5日働くと過度率100パーでパツパツになって死んでしまうので、なるべく空けるようにしたいんですけど、依頼が結構いただいてしまうので、そうするとその空いた曜日に入れていくみたいな感じになって、結果的にパツパツになってるみたいなところですね。
聞いてるだけでやっぱりお忙しそうだなっていうのはすごい感じますね。
あとは、空いた時間に書籍、技術書の翻訳とか簡訳とかに結構関わってまして、その技術書の翻訳簡訳とか、あとは他の本のレビュアーとして依頼をいただくことがそれなりにあるのでレビューをしたりとか、そういった技術書に関わる仕事ですとか、
あとはオープンソフトウェアの開発っていうのは、自分も一人の開発者として毎日コミットする、毎日開発するっていうのをずっとやってるので、それは空いた時間とか、あるいは早朝とか夜とかにやっていたりしますし、
あと、住宅開発っていうのを年間何案件かやってまして、だいたい数的には2つとか3つとかその程度なんですけど、住宅開発を行うというのをやってまして、
なぜかというと技術顧問業だけだとコードを書かなく、正確にはコードは書いてるんですけど、ソロプログラミングはしないんですよね。技術顧問業ってペアプログラミングとかモープログラミングを行うのも仕事なので、コードは書くんですけど、一人ではコードは書かないんですね。
そうすると、やっぱりコードを書く量減ってしまいますし、それだけじゃなくて、自分で設計判断して、自分で実装して、良い面も悪い面も自分で解理値を受けるみたいな、そういう経験っていうのが顧問だけやってると減っちゃいがちなんですよね。
そうすると、だんだん結果的には技術力が落ちていって、コンサルタントとしての技術顧問としての説得力というか、そういったものがなくなってってしまうので、腕を維持するためにも、住宅開発というのを半ば維持みたいなものなんですけど、ずっと続けてるんですね。
今年も続けてますので、特定の時期に、空いた曜日とか早朝とか夜とかに、お客様のシステムを作る。
自分で設計して、自分で開発して、自分でデプロイして運用してっていうのをやるっていうのをずっとやってまして。
老眼とプログラミング
ちょうど先月9月が、住宅開発と技術顧問業とOSS開発が重なる時期だったんですけど、だいぶパツパツになってやってたんですけど楽しかったですね。やっぱり自分で考えて、自分で設計して、自分でコードを書くのは楽しいですね。
いいですね。D1さんもやってんだなっていうのを感じられて、嬉しくなってしまいました。
9月はしんどかったなと思って、後でGitHubでコミットとかプルリクとか数えたら、9月で295コミット、37プルリクエスト、24イーシュー足してるので、結構やったなっていう感じの1ヶ月でしたね。
お仕事についてなんですけど、私と同い年ということもあるので、これは聞きたいなと思ってるのが、何歳まで現役エンジニアとして働けると思いますかっていうのが聞きたいんですけど、どうでしょうね。
何歳まで働けると思うかっていう問いと、働きたいかっていう問いがあると思うんですよね。
その意味だと、何歳まで現役エンジニアとして働きたいかで言うと、死ぬまで働きたいんですよ。
なんでかっていうと、仕事だと思ってないからですかね。つまり趣味だからですね。ソフトウェアエンジニアであることが趣味なので、死ぬまでやりたいですという話ですね。
ただ働けると思うかっていう問いになると、もっとリアルになってきて、働きたいけど働けないっていうときがやってくるのかな、やってくるんだろうなとか、そのあたりのちらつく年になってきましたというところはあり。
なので、本人はやる気満々なんだけど、頭がついてこないとか、腕がついてこないとか、目がついてこないとか、そういうのがあるんだろうなっていうのはあります。
最近で言うとやっぱり目が、どうしても僕らの世代は老眼というやつが始まるので、めちゃくちゃ強敵なんですよね。
本当に見えなくなるので、見えないと集中力が続かないんですよね。
なので、例えば20代の頃のプログラミングとかって、一晩中でもいくらでもできたし、手伝ってもできたし、何でもできたって感じなんですけど、
40後半のプログラミングは、思考力は限界を迎えないんですけど、その前に目が限界を迎えるみたいな感じになっちゃって、
前だったらもっとガンガンいけたんだけどなーみたいな感じで、目がもう完全にダメになっちゃったからちょっと一回休みとか、寝て回復させようとか、そんな感じになってきちゃってましたよね。
分かりますね。便利なつもりでサブモニターをつけてたら、そのサブモニターの図が見えないみたいなことがあって、すごいショックで。
距離が変わるとピントが合わせにくい。ピントを合わせるのに時間がかかったりとか、あるいは合わせようと思ってもピントが合わない。悔しいみたいなところがあったりして。
結構だから、昔はプログラマー35歳定年節とかあったりして、35歳までにプログラマーを辞めろとか、やってられなくなるぞみたいなこと言われたりしたけど、全然そんなことなくて、普通に生涯現役でプログラマーの人もいるし、ロールモデルも増えてきたし。
だから、若い頃、僕らの世代の上にはロールモデルがあんまりいなかったって話、序盤でしたと思うんですけど。
逆に今の若い方々にとっては、もっと20年上のロールモデルとかって、まさに我々の世代だろうしみたいな感じなので、いるんですよね。
僕らとして次の世代に向けてどういう姿を見せていくかとか、そういった話にもなってくるんですけど、
僕らの上の世代でも現役エンジニアの方々っていうのもいらっしゃって、そういった方々の背中を見ながら、どうやって現役エンジニアを続けていくかみたいなところも考えていくという側面もあるなと思って。
この業界に入ったばっかりの頃には、年上のロールモデルって全然いなかったなって話したんですけど、今やいるんですよね。
業界すごく広がりが出まして、僕より10上の世代の方とか20上の世代の方とかでソフトエンジニアとして仕事されてる方っていうのもいるので、そうするとそういう方々の背中を見れるようになったし、
昔若い頃にそういった先輩方にもっと会っていろいろ話できたら、いろいろ面白かったろうなみたいなところも思ったりはするんですけど、その分だから僕らが若い世代と喋ればいいわけだしっていうのはありますね。
続けていきたいですね。
これ続けていきたいんですよね。
なんでかっていうと、プログラミングが好きで仕方がないので、これを奪われるのはなかなかに苦痛なんですよ。
だから自分の体の限界によってそれが奪われてしまうっていうのはやっぱりなかなかつらいので。
だからやっぱりメガネって嫌いだなって、僕はちょっと裸眼で生きてきたんですけど、やっぱり老眼鏡というやつを作りまして、やっぱり助かる、すごい助かるんですよね。
2038年問題の影響
限界が、なんていうかゲージの減りが鈍くなるんですよね。
なるほど。
すごく嬉しいっていうところがある。
そうすると、つまり自分の体の延伸として、本を読める時間とかコードを書ける時間が長くなる。
ゲージの減りが鈍くなるので嬉しいっていう感じなので、やっぱりそうするとまだまだできるなっていう感じが出てきます。
この収録の中盤に紙の本を大事にしてますって話をしたんですけど、紙の本のどこに何が書いてるかっていうのを覚えていて引き出せるっていうのが競争力となってるって話をしたんですけど、目が悪くなってくると紙の本が辛くなるんですよね。
そうですね。
これも手ごわくって自分の競争力の厳選だったデバイスにアクセスしにくくなってくるこの辛さみたいな感じになって、電子書のほうが読みやすいと思う瞬間もあるので、
そうしたら電子書と紙の本と合わせて読んでいくとか、結果その仕事に使う大事な本だったらどっちも買っちゃいいんだよみたいな感じで。
どっちも買っちゃうんですよね。電子書でも紙の本でも読めるみたいな感じにしていくみたいな感じで、しのいだりしてます。
僕仕事を始めた時って2000年だったんですよ。2000年4月入社なんですけど、2000年っていうと2000年問題があった年なんですね。
でも2000年問題って当然1月1日に起きる問題なので、僕は経験してないんですよ。経験してないというか回避をしたみたいな感じではあるんですけど、4月入社なんで。
でも2000年問題ではなく2036年問題とか2038年問題みたいなことが控えていて、もしかしたらこれを対応するかもしれないなって今ちょっと思っていて、これぐらいはまだまだ現役としてやっておきたいなと思って。
これは影響大きいので、ほとんどのエンジニアが2038年問題には戦うことになると思います。
もうだいぶ未来の話だと思ってたら、もう近づいてきているし、しかもこれ2000年問題って2000年1月1日に発動する問題なんですけど、
2038年問題って2038年に起こる問題じゃないんですよね。2038年以降扱うプログラムが影響を受けるので、2038年より前にも影響出始めてて。
例えば10年後の何かを扱わなきゃいけないシステムがあるとしたら、もうすぐ影響出だすんですよね、大きく。
だから猶予って実は全然ないんですよ。2038年に対応すればいいやという話では全然ないので、もちろん一番大きい影響があるのは2038年だと思うんですけど、
基本未来時刻とか未来日を扱うのであれば影響はもう出るので、実はそんなに猶予はないですと言える感じですね。
聞かれてますね、これが。
変域で多分対処することになると思います。
いろいろ話できたんですが、ちょっと最後にいくつか質問をしたくてですね。すごい仕事のリアルな話になっちゃうんですが。
いいですか。コードレビューがありますと。コードレビューを依頼されることとかあると思うんですけど、
この経験上、自分の経験上、このコードから何となく嫌な感じはするんですけど、うまく言語化できなくて上手に指摘とかサポートすることができないことがあったりするんですね。
そういったコードレビューの際に、そういったコードの怪しい箇所に対して言語化するスキルってどうやったら向上するんだろうなというのがまず一つ質問です。
言語化をするスキルですよね。
言語化のスキルなので結構難しいですよと話にあるんですけど、コードレビューって何のためにやっているのかなというと、
コードを書いた本人が気づいていない問題に気づいて、結果的にそのコードがより良くなっていくために第三者として関与するっていうのがコードレビューの大事な役割で。
なのでコードを書いた本人っていいコードだと思って書くんですけど、
コードレビュー自体は何のためにやるかというと、これはコードの保守性を上げるために行うっていうのが大きいと思ってます。
他にもセキュリティとかパフォーマンスとかいろいろな側面があるんですけど、
コードって動くだけではダメで、機能を満たす、望まれる機能を満たしている、動いているっていうのは、
例えば自動テストを書いて、自動テストの結果がパスしているということをレビュアとして確認することで動くコードであるということは確認できるんですけど、
僕らは動く良いコード、動く綺麗なコードというのを構成に残していかなければならないので、
動くだけではダメで、綺麗でなければならない。
綺麗ってやつもすごく難しいことがあって、このコードは綺麗じゃないねって言ってもそれは伝わらないですよね。
綺麗とは何かみたいな話になるので、もっと第三者的な言葉にしなきゃいけない。
綺麗という主観的な言葉を使うのではなくて、もう少し客観的な指標、我々が綺麗なコードと呼んでいるのは何なのか、
あるいは嫌な感じがするコード、嫌な感じって何だっていうのをもう少し分解して伝わる言葉にしていかなきゃいけない。
分解して伝わる言葉にするっていうのは、その場で言葉を発明する必要はなくて、
それこそだからやっぱり技術書とかを読むと、それを表現するための言葉とか、コードの品質に関する品質特性とかいろいろあったりするので、
綺麗じゃないとか綺麗とかって何のことっていうと、保守性という考え方とひも付けられそうだ。
保守性とテスト手法
保守性って何だっていうと、保守性というものは解析性、理解用意性ってやつですね。
解析性とか、あるいはテスト用意性、試験性ってやつですね、テスト用意性。
要するに、あとはもう一つは変更用意性ですね。
この良いコードというやつは、分かりやすくて変更しやすくてテストしやすいというのを満たしていてほしいんだよね。
その分かりやすいというのを表現するときに、我々よく綺麗という言葉を使いがちなんだけど、
分かりやすいっていうのは何だと思うっていうのを議論してやっていくわけですよね。
そうすると、その自明なコードが嬉しい。何をしているか、読み手に伝わる名前だと嬉しい。
名前から受けるイメージと関数の中身でやっていることが一致していると嬉しいですね、みたいな話になってくるんですよね。
そういった語彙を獲得していくために、いろいろチームで読書会みたいなのをやろう、
リーラブルコードという本を読んでみたりとか、クリームブックという本を読んでみたりとか、
プログラミング作法という本を読んでみたりみたいな形でチームの共通語彙というのを作っていくと、
ここってこの本のこういうところでこういう変数名のほうがいいって言ってたよね。
だからこういう変数名ではどうだろうみたいな感じでレビューアーとしてレビューしていくとか、そういった感じになります。
なので、自分の言葉だけでなくて、その第三者の言葉として伝わるような語彙を選ぶ。
すでに誰かが、例えば書籍とかの中で表現している語彙を使うとか、そういったこともあったりします。
なので、なんとなく嫌な感じというやつを、なんとなく嫌な感じって何かなっていうのを自分の中で分解する。
で、保守性が低そうに感じる。その保守性とは何か。理解容易性が低そうに感じる。理解容易性が低そうに感じるのはなんでだろうかって、
名前とやってることが一致していない感じがするとか。引数が多すぎて頭の中に収まらない感じがするとか、
ネストが深すぎて頭の中に収まらない感じがする。そういったところネストが深すぎて頭の中に収まらない感じがするっていうのは、
これは循環的複雑度として数値化できるので 数値化というものは数値化していく
そうするとサイクロマティックコンプレキシティ 循環的複雑度が
いや この処理はせめて10に収めたい いや せめて7に収めたいみたいな
そんな感じの議論もできるようになったりとか
いうと もう少し第三者的な客観的な指標で 保守性について議論していけるだろうというような感じになりますね
なるほど 分かりました ありがとうございます
ちょっとこの辺り もうちょっと言語化をうまくできるように
やっていきたいなと思ったので 質問させてもらいました
それとですね もう一個めちゃめちゃ具体的な内容で 本当に申し訳ないんですけど
これも質問で テストの話なんですけど
コード内にですね 外部のAPIを使って 呼んでいるところがありますと
そのAPIの利用マニュアルみたいなのには こういうふうに使いますよっていうのが書いてあるんですね
書いてあるんですけど いざ使ってみると ちょっと意図した動きとは違った動きをしたんですよ
っていうのが パラメータがあって フィールドとイコールズっていうパラメータと
あと そのフィールドのバリューを渡す形のAPIになってて
明らかに一見 返ってきそうなんですけど 実は完全一致じゃなくて
ライク検索になっているっていうAPIがありまして ちょっと意図通りではないなと思ったんですよ
でも これは外部のAPIなので 通信が発生するAPIですと
こういった外部のAPIって テストが書きづらいものだなと思ってるんですけど
こういうのをMockしたところで あまり意味がないテストだなと思うんですけど
こういう場合って 実際どういうふうにテスト書いたほうがいいんだろうなと思って 質問です
そうですよね 外部API呼び出しのところで 思ったんと違う動きをする外部APIがあるみたいな話で
これMockとかStubに変えたいけど MockとかStubが自分の妄想になってしまい
そうすると自分で妄想した外部APIのMockは 思ったとおりに動くんだけど
本物は全然そういう動きはしないみたいな感じになって
そうなんですよ
すごくよくあるシチュエーションです
これテストって実際に外部APIに対して行わないと 本当のテストにはならないんですよね
これって 童談の言葉で言うと ラージュなテストになると思うんですよね
それってちょっと準備が大変というか それを毎度やるのかっていうのが難しいところがあって
そうなんですよ なのでここで設計っていうのが大事になってきて
外部APIとやりとりするところって テストをしようとすると
ラージサイズにならざるを得ないんですよね
だしラージテスト つまりラージってのはテストサイズという概念なんですけど
スモールサイズのテストは1プロセスに収まるテスト
ミディアムサイズのテストは1マシンに収まるテスト
マシンに収まらないテストのことをラージテストって言うんですけど
絶対ラージテストになるんですよ
だけど本物がマシンに収まらないネットワークの先にあるので
忠実性の高い本物らしさの高いテストをしようとすると絶対ラージになる
そうするとそのラージサイズの外部APIに引っ張られて
テスト全体がラージサイズになってテストになっちゃう
ラージテストになっちゃう これが非常につらいんですけど
外部APIのテスト課題
これって設計でレイヤリングすればいいって話になるんですよ
外部APIとやり取りするところとその外部APIとやり取りした結果を翻訳して
自分たちの中の例えばデータ構造とかに翻訳するところというのを分ければよいっていう話になるんですよね
例えばデータベースに関しては我々はそれを普通にやってるんですよ
リポジトリパターンってやつですよね
同じことでデータベースがプロセス内外のやり取りだとするならば
外部APIとのやり取りもプロセス外とのやり取りなんですよ
だから外部APIとやり取りするリポジトリパターンみたいな
よくゲートウェイパターンって言われるんですけど
外部APIとやり取りするゲートウェイのインターフェースを作ります
例えばPHPとかJavaでいうと本当にインターフェースを作ります
そのインターフェースのインプリメンテーションとして
実際に外部APIとやり取りするゲートウェイがいます
そのインターフェースを責任分解点として
インターフェースの実装は本物実装とMock実装に分ければいいって話なんですよね
自分たちのコアのロジックたちは
その外部インターフェースとやり取りするゲートウェイに対して
依存をすればよいのであって
実装に対して直接依存しなければ
テストサイズとしては下げられるんですよ
下げられるところがテストはMockにできるので
スモールサイズに変えられますね
という形で責任分解点をまず設ける
それによってテストの大部分はスモールテストのサイズに持っていく
ラージサイズのユニットテストをかかざるを得ない
実際の本物の外部APIとやり取りすることによって
自分の考えている動きと本物の動きが一致するかどうかのテストっていうのは
少数ですけど動かし続けます
これはラージサイズのユニットテストになると
今後のイベント情報
そこで学んだことを内側に生かしていくために
内側に関してはインターフェースの実装として
自分の妄想ではない
自分が学んだ内容によるMockの振る舞いっていうのを提供していけばいいという話
これがまず基本的な考え方
その上でレコードアンドリプレイ型のライブラリとかを併用するのがよくて
外部APIとHTTPとかHTTPSでやり取りする場合に
通信の内容を保存しておいて再利用すればいいって話になるんですよね
というのが基本的なレコードアンドリプレイ型のライブラリの考え方で
外部APIと最初にしゃべるときは
本当に外部APIとつないでリクエストレスポンス
本物のレスポンスが返ってきます
そのレスポンスを保存しておいて
例えばJSONファイルとかに保存しておいて
2回目以降は本物につなぎにいくフリをして
そのレコードした保存したレスポンスを返すみたいな
タイプの動きをするテストのサポートライブラリっていうのは
探してみると実は結構あるんですよ
なのでそれを使って実際の通信の内容と
かなり近い内容のインテグレーションテストも書けるようになってきます
定期的にそのゴールデンイメージ
スナップショットテストみたいなもんですね
外部APIと通信して保存した内容
外部APIも予告なしに仕様が変わることとかが
しょっちゅうありますので
保存した内容っていうのをずっと取っておくっていうよりは
定期的に洗い替えしていくというような形で
動きが乖離していくっていうのを防ぐというような
運用をすることが多いです
なるほど 変わることがあるからですね 仕様が
そうですね
なるほど
ありがとうございます
すごい細かい仕事の内容を聞いてしまいました
気づけば時間が結構経っていました
めちゃくちゃ楽しかったですね
こういった初めてのポッドキャストの場で
しゃべるのも結構ドキドキするんですけど
普通にリラックスしてしゃべれたので楽しかったです
それは本当によかったです ありがとうございます
最後にちょっとイベントがあるっぽいので
その話をちょっとしようかなと思うんですけど
11月6日か 11月6日に
Ask Me Anything 寺田さんに何でも聞いてみようという
イベントがありますと
あります
これがオンラインですね オンラインで参加できるので
ぜひぜひお願いします
Ask Me Anything AMAってやつをやってみたかったので
やろうという企画です
Ask Me Anythingって何でも聞いていいよっていう
海外では時々ある形式なんですけど
あんまり日本でAsk Me Anythingやってるのって
場面としては少ないのでやってみようっていうので
何でもTワードだけど何か質問あるっていう感じの
イベントです
なるほど そういうことですね
面白そうですね これはぜひ参加したいですね
ぜひお願いします
他何かイベントとかありましたっけ
そうですね ポツポツ登壇しますので
例えば今度
コードAIに関する
コードAI本とよく呼ばれてるんですけど
これだな コード×AI ソフトウェア開発者のための
生成AI実践入門という本があるんですけど
その本の著者のハットリさんとレビュアー
私もその本のレビュアーなんですけど
レビュアーのメンバーで
いろいろイベントをやるというのがあるので
ぜひそちらもご興味のある方は
見ていただければというふうに思っています
日にちは何日だったかな 11月7日ですね
ぜひよろしくお願いします
これはリンクをメモに貼っておきます
ありがとうございます
ちょっと時間が押してしまって申し訳ないですけど
この辺りで第112回は締めさせてもらおうと思います
最後にもう一度Xのハッシュタグについてお知らせです
ハッシュタグはカタカナでつなぎめFMです
投稿待ちています
ということで今回のつなぎめFMは
岩田さんをお迎えしてお話しさせてもらいました
どうもありがとうございました
ありがとうございました
