テストの信頼度と胆力プレー #hey_spaces_yoyak CTO 藤村と STORES 予約テックリード編

10月6日（水）にCTOの藤村 @ffu_ と STORES 予約エンジニアの伊藤がTwitter Spacesでプログラミングについておしゃべりしたので、その様子を一部お届けします。

名前を読めば、バイブス的にはわかるみたいな感じがいいですよね

藤村 : ヘイでCTOをやっている藤村です。エンジニアとしては、Ruby on Railsのバックエンドが一番長くて、その次はフロントエンドが長くて、半々ぐらいでやってきました。あとはインフラとか、CSSとかもいろいろやってたりしました。伊藤さんも自己紹介をお願いします。

伊藤 : はい。自分は今年で働き始めて6年目ぐらいで、新卒のときに名古屋にある受託開発の会社に入りました。しばらくして東京に行って、東京でも何社かで受託やスタートアップで開発をして、2020年の1月にクービック株式会社に入社しました。Ruby on RailsやReactを書いていたら、急にヘイにグループ化されると聞いて。ああ、そうなんですかみたいな。で、今年の1月からヘイの社員になって、今に至ります。

藤村 : 伊藤さんは、バックエンドとフロントエンドのどっちが得意なんですか？

伊藤 : バックエンドのほうが人並みにはできるんじゃないですかね。ウェブ開発で押さえるべきところとかは、一応かかわっていて。ReactもSPAっぽいのは一通り作れるけど、そんなトレンドをめちゃくちゃ追ってるわけではなくて。そういうReduxとかは一応書けるけど、ほかの状態管理のやつとか。

藤村 : MobX？

伊藤 : そうそう。とか、Recoil的なとかは、実務で使ったりした上での勘所とかはなくて。もう普通に書くしかできない。

藤村 : じゃあバックエンドで、自分のこだわりポイントはどこら辺なんですか？

伊藤 : 個人的に思うのは、明示的に書くことですかね。それはRubyでの受託や、副業で仕事受けていたりしている中で、Railsのプロジェクトを何個かさわってきて、やっぱり人と仕事をするときは何が起こるかわからないと難しいことが多いわけじゃないですか。上から下に読めたほうがいいなみたいな。

藤村 : それは本当そうですね。

伊藤 : 上から下に読めば、読んで何が起こるかわかれば。

藤村 : 名前読めば、バイブス的にはわかるみたいな感じがいいですよね。

伊藤 : 上からまじでちゃんとなめていって、がんがん置き換えていくみたいなのは、ちょっと冗長でも愚直に書いてあるほうがいいと思っていて。だから個人的には、めちゃくちゃRailsっぽいことをしたいというよりは、何がどこで起こるかわかる中で、地味に書いていきたい気持ちですね。

藤村 : あれでしょ？DHHが何とかover brevityっていう記事書いたの知ってます？

藤村 : DHHの名前は簡潔さよりも明示的さだよね、って記事です。これ、やばいね。ヘイのTwitter Spacesでヘイドットコムの作者がいるっていう。

伊藤 : そうなんですよね（笑）。
僕はどっちかというと、ヘイドットコムには結構、気持ちがあって。

藤村 : まじで？

伊藤 : ちょうどヘイのグループになるか否かぐらいの時期に、このBasecampが作ってるHEYっていうメールサービスが出て、「これは！」と思って。これがあるから、Action Mailboxとか、そういうやつが入ってきたのかみたいな、種明かしみたいな。

藤村 : Action Textとかもこれですよね。

伊藤 : そうそう（笑）。Action Textでも、Basecampとかで使ってるのが本体でも。ヘイでも使われてますね。ヘイドットコムでも使われてる。ヘイドットジェーピーではなく。

並々なる思いっていうのは、自分もすぐ飛びついて、1年間、約日本円で1万円分ぐらいの契約をすぐして@hey.comっていう名前をメールアドレスに使ってたんですよ。

藤村 : 悲しいね。

伊藤 : そしたら、ヘイ株式会社にジョインするっていう。

藤村 : （笑）

伊藤 : @hey.jpっていうアドレスを手に入れて。

藤村 : 終わった。終わってしまった（笑）それで話を戻すと。

伊藤 : そうそう、Clarity。

藤村 : 簡潔より、読めるほうがいいってDHHが言ってて、これの例とか結構すごくて、めちゃくちゃメソッド名長いんだよね。8単語を使ってる。

伊藤 :

藤村 :いや、こういうことですよね。僕、これ賛成なんだよね。

伊藤 : 僕もこれぐらい長いメソッド名つけたりします。このメソッドは何かやばいときに、やばい理由で仕方なく呼んでるんやでみたいな、そういう名前にしたりしてます。

藤村 : いや、重要っすよ。こういう名前にしといたら、あとから違うことできないもんね。でも、enableとかだったらだめじゃん。

伊藤 : そうっすね（笑）。

藤村 : そうそう。ここは重要だよな。

伊藤 : いや、でも確かに、こんだけこういう明示さ求める割に、僕、concern みたいのが結構苦手で。

藤村 : わかる（笑）。

伊藤 : アタッチャブルって何？みたいな。

藤村 : でも、何とかブルってよく許せるなって感じだよね。その名前いいの？みたいな。仕方ないっちゃ仕方ないし、俺もつけたことあるけど、よく言葉にうるさいDHHがあれを許したなって思いました。

テストスイートがそろっていれば、胆力プレーで乗り切れる気はする

伊藤 : 今日話そうかなって思ってたことがひとつあって、ここ数カ月ぐらい、胆力的に解決することが多かったなと思っていて。理論上、全部grepして全部正しく書き換えれば、すべてうまくいくでしょうっていうところに帰結してるなと。

藤村 : わかる。あれじゃない？目つぶってダッシュすれば終わるって感じだよね。

伊藤 : そうそう（笑）。

藤村 : 1000件は手作業でいけるっしょみたいな。

伊藤 : そうそう、1000件は。

藤村 : いや、1000件は無理かもな（笑）。自分で言っといて何だけど。

伊藤 : 個人的には、一生懸命grepして書き換えるプレーは結構やっていて、静的型つけ合ったらもっと楽だろうけど、実際そうもいかない場所もあるんじゃないかなと。

藤村 : そうですね。あとRubyだしね。

伊藤 : Rubyだし、それで型ついてたとしても、結局それっぽいところを追ってかないといけなかったりとか。

藤村 : 型つきの言語で大規模なリファクタリングとか、大規模な何かの書き換えするときって、Haskellとかでやったけど、要は型検査で落ちるところが、ざーって100個とか出てくるから、それを目つぶって直してくみたいな感じ。

伊藤 : たしかに。あれも結構TypeScriptとかでもありますけど、目つぶってダッシュ感はありますよね。でも、あれって、めっちゃ壊れた、やっぱやめとこってなることも多いかなと思ってて。そこを走りきれる人って、なかなかいないなぁと思ってます。

藤村 : そういう1日フルに時間空けて全力でやれば終わるみたいなやつとか。それが2日でも。

伊藤 : 1日はちょっとしんどいですね（笑）。

藤村 : まじか。俺、やっちゃうけどな。

伊藤 : 半日だったら走りきれるなって。私はちょっと胆力不足で。

何でこれ思ったかというと、Vue 2から、Vue 3に上げるときに「APIが変わってるから、上げられないでしょ」みたいなネットの意見に対して、「いや、それはもうやるしかないし、ReactだってHooksに書き換えるとき大変だったやん」みたいなことを@ushiro_nokoが言及していて。だから、そこは結局やるしかないポイントってあるから、やろうよみたいな話で。

藤村 : それはある。だがしかし思うのは、胆力プレーができるのはテストスイートが揃ってるときだなっていう気もしてるんだよな。

伊藤 : そうですね。

藤村 : テストスイートが揃っていれば、胆力プレーで乗り切れる気はする。

伊藤 : 間違いない。

藤村 : 最近思うんですけど、テストコードへの信頼度っていうのが、概念としてある気がしてて。

伊藤 : ああ、あります。ありますね。

藤村 : 俺らのチームのこのリポジトリは、こういうテストスイートがあって、こいつらがパスすると、このぐらいの品質が保証できている、みたいな感覚値ってあるじゃないですか。

伊藤 : あります。

藤村 : それが高いところ、低いとこがあって、高いと胆力でやりきるみたいな感じでいけるけど。

伊藤 : そうです。この変更の部分はカバーされてる、たぶん大丈夫やみたいな気持ちだからやれるっていうところはありますね。

藤村 : そうなんですよね。

伊藤 : すごいわかります。単純にカバレッジでも、一応カバーされてるけど、本当のカバレッジじゃないみたいな。

藤村 : カバレッジより信頼度って気持ちみたいな。

伊藤 : 信頼、そうですよね。ありますよね。

藤村 : STORES 予約は信頼度、何点ぐらい？自然言語で表現すると。

伊藤 : 信頼度か。通ってる量は多いですね。エッジケースが漏れていたり、まだカバーしきれてない危険な変更をできてしまうところはあるかなって感じですね。だから、単純な置き換えだったら、思いっきりクラッシュするとかは検知できますが、何かここで変な値が紛れ込んで保存、インサートされてしまいますみたいなのは、すり抜けられますかね。

藤村 : 巧妙な間違い方はできるって感じだ。

伊藤 : そうですね。今のチームは、ちょっとこのテストケースあかんとこ多いから、ちょっと直そうぜとか、知らない間にみんな直してますね。

藤村 : いいっすね。

胆力でも気合いでもなくて、割と理知的なプレーということに気付く

藤村 : 胆力について記事を書いてくださいよ。

伊藤 : いや、でも、何かそれ…

藤村 : 根性論に聞こえるかもしれないって？

伊藤 : そう、根性論っぽくて、あんまり公には言わない話なんですよね。

藤村 : まあね。

伊藤 : 僕、めちゃくちゃタイポ見つけるのうまいんですよ。タイポ見つけるの早いっていうか、文字を見つけるのが早いんですよね。だから、grepを大量にして、置換をばーっと見ていって、これっぽい、これっぽいみたいな、を消していく作業が得意。

藤村 : 伊藤さん、Markdown書いてて、改行入れる、入れないみたいなのあるじゃん？要はh1とか、h2のあとで改行入れるか、入れないかみたいな。

伊藤 : ああ、はいはい。

藤村 : ああいうの気になるほう？

伊藤 : 気になりますね。

藤村 : そうだよね。そういう人の発言だなって思った。俺もちなみに超気になるんだけど。

伊藤 : 今だと、Markdownに自動でエディタがprettierかけてきたりして調整されたりするけど、いや、ここもう一行空けたいなみたいな。

藤村 : わかる、わかる。

伊藤 : 収まりのいい行とかあったりしますね。

藤村 : わかる。それで何だっけ、タイポを見つけるの早いと。

伊藤 : そうそう（笑）。それは生まれつきで、あんまり読んでないけど、画像として入ってきて、ここ違っとるやんみたいなのが読んでないけどわかる。ここの文字の収まりがおかしいっていうところが、見つかったりするっていうのに依存してるやつですね。

藤村 : でも、3時間手作業すれば終わるやつってたまにあるよね。

伊藤 : ありますね。

藤村 : 3時間かけて全部直せば終わるやつとかいうのって結構あって、そういう仕事をいつやるか、やらないかみたいなのはあるよな。

伊藤 : ありますね。今日もちょっとやっちゃいましたね、1時間ぐらいやって（笑）。

藤村 : やっちゃった？わかる。

伊藤 : やっちゃいましたね。普通にdiffが3000行ぐらいなるけど、まあって、やってしまったな。

藤村 : わかるわかる。コマンド、ワンライナーでできたらいいけど、そうもいかないやつも多いみたいな。

伊藤 : そう、そうもいかなかったっていう（笑）。いつもできるわけじゃないから、今日、朝コーヒー飲んでて、そういえばって思って手を動かし始めたら、まあ、できたからやりましたみたいな。いや、でも難しいんですよね。

藤村 : あれ、俺、世の中で今、軽視されてるような気がするんだよな。

伊藤 : 何でそこに思うところがあるかなんですけど、昔Goのプロジェクトを書いていて、Goってerrorsってあるじゃないですか。errorインターフェース。基本的にエラーでそのまま返したりすると、スタックトレースがつかないんですよね。それをerrors.Wrapとかしてラップするみたいなのが割とよくあるやつなんすけど。

プロダクションコードで動いて出してるときに、何かでクラッシュしてるんだけど、スタックトレースついてないから、そもそもプロダクションでデバッグができないみたいな。このエラーはどこからきたの？みたいなことになっていて、あたふた、あたふたみたいな感じでして。

その当時のコードベースメンテナンスしてるオーナーと話して、errors.Wrapしないとねという話にはなったけど、なかなかその人は、まだerrors.Wrapにするか、標準的にラップする方法のfmt.Errorfのどっちにするか迷ってるみたいなので、なかなか着手されなくて、ずっとスタックトレースがわからないみたいな状態で。

でも、それを一気にやってくれたら、いや、やるべきだったし、逆にその方がすぐに対応しないのだったら、自分やるべきだったし、もんにょりもんにょりみたいな。その胆力での置き換えをやらないんだったら、Goをやってる意味も、もはやないのではみたいなのを思った記憶があります。

藤村 : 胆力でもいけるし、正規表現でコード書き換える、ワンライナー作ってやるってのもありですよね。

伊藤 : そうですね。でも、それをやるのも一種の胆力というか、手の速さみたいなのがありそう。

藤村 : 昔、別の会社のプロジェクトで、FactoryBotってあるじゃないですか。あれをfactory.rbっていうのに全部書くやり方もあるんですよ。

伊藤 : へえ。でも、どのファイルでもいいんですよね、あれ。

藤村 : そうそう。自動生成でfactories.rbかな、にどんどん書き足されていくモデルを追加するというのもあるんですよ。その流れでfactories.rbですごい量のファクトリーが書いてあるからこれはちょっともう読めない、どうしようって時に、すげえ頑張って正規表現を書いてファイルを分割したことがあって。あれもいわゆる胆力プレーですね。

伊藤 : そうですね、胆力プレーですね。ひとつでもかすが残ってると終わらない系の。もう移しきるなら移しきって初めてその価値が出る系はあるなって。

藤村 : 手作業と自動化のかけ算みたいな。かけ算違うな。たし算で、ここまでは自動化してるからワンライナーというか、ファイル書き換えでいけるけど。

伊藤 : そうそう。ワンライナーでファイルはある程度このスクリプトを吐き出しておき、だからちょっと細かいところは微調整しつつで全部実行するみたいなのは、よくやりますね。

藤村 : そうなんですよね。胆力だな。まじでこういうこと言うと嫌われそうなんですけど、何やかんや胆力とか、気合いみたいなのってあるよなって、よく思うんですね。

伊藤 : それをうまいこと、でも、いつでもそのやる気が出るわけじゃないから、何かうまいこと保ちつつやってく技みたいなのが、今、求められてるというか。求められているっていうのは変だけど、それだけで価値になりますよっていうのは、もっと言っていいのかなと思うけど。ちょっと俺、刺されるのやだしなぁみたいな（笑）。

藤村 : でも、あるよな。

伊藤 : 手が、ぱっと着手できるようにはなりたいんですよね。ある程度、足がかりは常に作っておいて。

藤村 : 何だろう、瞬発力なんですかね。でもさ、考えてみたら、胆力でいけることに気がつくのって、事前準備要るんですよね。

伊藤 : 事前準備、要りますよね。

藤村 : ここ胆力でいけるなって見えるまで考えてないと、胆力でいけるようにならないっていうのはある。

伊藤 : そうそう。だから日頃から見てて、この沼の様子を見に行って、この沼、何かやばそう…みたいな。やばそうだけど、ほかのコードを書いたり、そこのコードにちょっとだけ浸かってメンテしてるうちに、沼の深さがある程度わかってきて。

藤村 : あ、ここに水路作ると、沼から結構水が抜けるなぁってわかってくるみたいな。

伊藤 : そうそう（笑）。水抜けるなってわかったときに一気に走り切るみたいな。

藤村 : ちょっと水抜いてみよっかて、試すとかね。

伊藤 : ああ、ありますね。

藤村 : あるよね、何か。

伊藤 : 全然無理でしたねってときもある。でも、それがわかるだけでもいい。

藤村 : もう全然、胆力でも気合いでもなくて、割と理知的なプレーだったということに気がつくという。

伊藤 : そう。下準備が大事ですね。

藤村 : 大事ですね。

伊藤 : それこそ、総合的なプレーだから、さっきのテストのカバレッジではなくて、信頼度を上げておかないとそれはできないし。どこが信頼度ないのかなとか、コードにふれてないと結局わかんないですね、もうそのコードベースにふれてないと、どこに沼があってとかが。

藤村 : こいつ、いじると実はめっちゃテスト落ちるんだよねみたいな。

伊藤 : ああ、もう当然、頭に入ってますね（笑）。

藤村 : そうそう、そういうやつですよね。それがわかると、この角に用水路を作れば大丈夫みたいなのがわかるという。

伊藤 : そうそう。

藤村 : あるよな。

伊藤 : すごい抽象的な感じだけど。いや、でも何かテストの信頼度は数値化されるべきなんじゃないですか。カバレッジじゃなくて。

藤村 : そうね。簡単なアンケートでいけそうだよね。俺、思うのは、エンドツーエンドテスト、RailsでいうとFeature Specとかがエンドツーエンドテストに通っていれば、8割変なことが起きないみたいなのとか、そういうのあるよね。

伊藤 : そうですね。確かに。

藤村 : 正常系は大丈夫とか。

伊藤 : たしかに。

藤村 : 前の会社だと、100行では終わらないぐらいのFeature Specを書いてて、exampleを書いてて、正常に登録して、主要な機能をさわってて、動くことだけを確認するスペックとか書いてましたね。こいつが通っていれば、まず本当に壊滅的に壊れることはないとか。

伊藤 : わかります。

藤村 : そういうのがあると気が楽なんだよな。そういうので、モックしちゃいけないんだよな。

伊藤 : そうなんすよね。全部本当の機能をたたきましょう。

藤村 : そうそう。データベースをちゃんと通してやったほうがいい。

いろんなソフトウェアを書く仕事があります

藤村 : ヘイには、STORES というネットショップを開設できるサービスと、STORES レジというネットショップと在庫連携ができるPOSレジアプリ、STORES 決済というキャッシュレス決済のサービス、あと STORES 予約というオンライン予約システムをやっています。今日は STORES 予約の開発チームをリードしてくれてる、伊藤さんに来てもらって、ソフトウェア開発について熱く語るみたいになっちゃったんですけど、そういう話をしてました。

もし、ヘイってどんな感じなんだろうみたいに興味があったら、僕にDMで、気軽に連絡をいただけると、とてもうれしいです。もう冷やかし感覚でいいので、ぜひともお声かけお願いします。

伊藤 : お願いします。

藤村 : いろんなソフトウェアを書く仕事があります。

伊藤 : いろんなソフトウェア書きますね。

藤村 : 俺もいろんなソフトウェア書きたいな。いろんなソフトウェアを書いている人の仕事を、プルリクとかで眺めてるのが楽しい。

伊藤 : （笑）。