00:03
はい、みなさんこんにちは。TRY-CATCH FM第29回を始めていきます。 お願いします。 お願いします。
MIYACHIさん、最近運動してる? あのですねー
前にポッドキャストで話したけど、引っ越したじゃない? そうね。
それでちょっと家賃がね、だいぶ安くなったから
あのー、彼女同棲してるんだけど、2人でちょっとジムに入会しまして
anytime fitnessに入会して、4月の頭から週2でジムに行ってる最中で。
一緒に行ってるの?それは? そうそうそう。
平日1回と休日1回、週末1回って感じかな。 なるほどね。
会社のジムに行けてた頃は良かったんだけどさ。 うちも駅からちょっと歩いたら、anytimeはあるんだけど、なんか
通い続けれる気がしたり、どっかでなんかもう行ったなってなりそうな気がするんだよね。 やっぱあれはね、家からの近さですよ。
ついでがあるか近いか、あとあのトレーナーをパーソナルにつけて、あの人の時間取っちゃってるから、さすがに行かないってわけにいかないなって予約取ったから行くとかね。
そういうのがないと、なんか行かなくなりそうな気がするんだよね。 あー、そのトレーナーもね、結構高いからね。
そうね、行ったら楽しいんだよね。 そうそうそう、後悔しないんだけど、ジム行ったら、やっぱ腰を上げるのがね、
しんどいよな。 なんか風呂入るときと同じ感じね、なんかめんどくせーなってなっちゃう。
行ったら楽しいんだけど。 そうなんだよな。 だから今の家から徒歩3分くらいで行ける距離にあるから、
いいっすね、それはいいわ。 だからまあ今んところはまあ続いてるかな。
なるほどね。 ランニングマシン
をまあ20分くらい
やってるのと、まあ普通にウェイトトレーニングをやってるって感じかな。
なるほどー。 どうですか?
そう、そういうのをやろうと思って。 いやでも多分手軽にできないと続かねえなと思ってウィフィットトレーナーを買って。
で、なんか続いてるのか続いてないのか微妙なぐらいの頻度でやりつつ、結局趣味のサイクリングとか散歩とかの方をやってる。
サイクリングどれくらい乗るの?距離として。 距離の方は最近短いから1回あたり10、20キロくらいだけど。
03:06
多分それこそこのゴールデンウィーク中のどっか、 あれ人に会わなくて済むから、午前中にでも
なんだろう、僕は荒川の近くに、荒川の割と海に近い方のところに住んでるんですが、 赤羽、赤羽、東京の人はわかるかもしれない。赤羽の近くにね、あの水門があるんですけど。
ここがすごく景色が良くて、ベンチがあって昼寝ができるので。 春と秋はたまにそこで昼寝をしているので、そこに行くと片道20キロぐらい走れるんだよね。
ゆうがの週末だな。 だから割とそういうことをするかな。なんか走ってどっか行ってちょっと物を食べたりとか、
なんかのんびり過ごしたり景色を見たりするのが割と運動としてはいいかなって感じ。 なんか自転車とかだとなんか風景も見れるからいいよね。
そう、飽きづらいし、きつくないからさ。 ランニングマシンとかウェイトトレーニングって言うて、ずっと続けられないというか、
あ、疲れたって体が動かなくなるんだけど、 自転車はなかなかそれが起こない。
終わった後は、確かになんかこう、 全知全能患者が出てくる。
やっぱりやってる間辛いね。 そうねー。
30分1時間、2時間とか続けたいってなるっていうものとしては、自転車は有りだと思う。 油産運動的な意味で。
自転車ってさ、俺もちょっと前買おうとしたんだけどさ、 どれくらいで買えるのかな、そういうちょっと遠出というか10キロとか20キロとか。
あとは、買うチャリって。
なんかこれ、何だろう、大手のスーパーとかイオンバイクとかが出してる。 名前出しちゃっていいのかな。
2万くらいで売ってるようなクロスバイクは、 劣化した後、劣化が早いというか、その後整備して長く乗るっていう感じではないので、
何年か乗りたいんだったら5万くらいかな、出してクロスバイクを買うぐらいが、コスパが一番いいんじゃないかなと。 なるほどねー。
ロードバイクとかまで乗らない、普通のクロスバイクでいいやっていうんだったら、それ買えば、近所のスーパーに買い物に行くとかさ、
だったら、袋下げると、ハンドル下げて走るとか、リュックに荷物入れるとかで、普段使いの買い物とかに持ち帰るから。
電車代も払わなくてよくなるし。
東京駅間狭いから、一駅二駅とか普通の人でも無油で走れちゃうから。
06:02
何より感染リスクが低下するっていうのがやっぱ魅力的だと思う。
でかいね、本当にでかい。
やっぱりね、季節を感じれますよ、自転車は本当に。
春だったら桜とかがさ、自然に目に入るし、秋だったら金木犀の香りが来て、あ、ここにあったんだってなるし。
なるほどね。
一番のおすすめは夏の夕暮れですね。
暑かったのが、ちょっといい風が吹き始めた頃、あれはあれのために生きてるでもいいと思うぐらい本当に良い季節なので、皆さんこれからの季節は自転車です。
やってみようかな。
じゃあちょっと本題入りますか。
今日の本題が。
本題が、いいコードについてっていう記事が、いいコードとは何かっていう記事が上がってて、ちょっとツイッターとかで話題になったので読んだらなかなか良かったっていう話です。
なかなか良かったって言うと上からっぽいな、でも良かったと思います。
これはちょっとツイッターでタイムライン流れてたから、ちょっとサクッと最初の3分の1か半分くらいまで見たときに、下あたりを読もうと思って、まだちゃんと見れてなかったから。
ぜひね、コスワに教えてもらいたい、どんな感じだったか。
まずその記事、どんな人が書いたかって話で、サイバーZ、サイバーGっていう、サイバーエージェントの関連子会社でスマホ特化の広告代理店かなんかをやってる会社があって、そこのCTO室のメンバーだそうです。
2019年新卒入者って書いてあったんで、今3年目とかなのかな。
僕らより年も若くて、ただ未踏っていう、全然未踏の未踏って書くIPAっていう公的な国の組織がやってる、ITに関するすごい優秀な人材を発掘していろいろ支援しようみたいなプロジェクトがあるんだけど、
そこのスーパークリエイターやってた人みたいな感じなので、学生の頃からバリバリやってた人ですね。
っていう人が、2021年度のエンジニア新卒研修でそういう講義をしましたっていうスライドだそうです。
で、割とめちゃめちゃキャリアがある人とかわかんないけど、なんか行動の良さとかについてちょっと迷っちゃう。
コードレビューする時の話に、こうした方がいいと思うよって言うけど、その根拠をちょっとうまく言えないとか、そういう人とかは結構読むといいんじゃないかなと思います。
で、どういうことが書いてあるかっていうんだけど、まずスピードと品質。早く作りたかったら品質を落とせば早くできるのとか、
09:03
品質上げたかったら時間かければ品質上がるのかみたいな話と、よくある技術的不細っていうやつ。
技術がなくてできなかったこととか、後からわかってできるようになったけど、まだやってないこととかっていうような技術的不細の種類とかについて解説していって。
あとはもうちょっと具体的な、こういうコードがあった時に、そもそもコーディング7段階ぐらいに分けて、
こういうものまでまとまってます、こういうものまでまとまってますっていう、まとまりのレベル間でレベル分けをして、
それがどういう理由でそれだけ良いのか、どういう状態は避けるべきなのか、避けるとしたらどんなふうに変えるべきなのかっていうようなことが結構具体的に書いてあります。
これか、この、
業種だと結構。
理論的とかいろいろあるね、はいはいはい。
最後の方はそのなんだっけ、クリーンアーキテクチャーとかの話かな、その辺は結構何を大事にしたいかとか思想の話もあるので、
こう大事にするかは人によるけど、まあその何だろう、かっこたるものがない人とかは特に、あのこういう考え方もあるあるし、それは割と良いものかもしれないということで、
知っておくと何かを決める時の基準になるかもしれないので、まあそれはそれで読んでおいたらいいかなって感じなので、
全体で言うとそんな感じのことが書いてあります。
最初の、品質とスピードはトレードオフである?みたいな疑問その1みたいなのあるけど、
これ結構やっぱさ、特にSIRとかだとさ、
この、なんていうの、
このテーマって結構あるじゃん。
なんかQCDだっけ、QCD、クオリティーコストってなんだ、デリバリー?ノーデリバリーか。
コストと品質と、まあノーチをいかに守るかみたいな、この3つの軸でさ、会話されたりするじゃない。
でまあそのノーチを守るためには、品質をちょっと下げてとか、
コストを上げてとか、
まあそこはちょっとトレードオフみたいになってるみたいな話をしがちじゃない。
でそこの話だよね、まさに。
これでいうところの品質っていうのが、品質この話の中でも2つに分かれてて、
お客さんから見えるビジネス的なところでの品質、こういうことができて欲しいとか、
こうなんだったら、ここを押したときこうなって欲しいとかね。
そのレベルは担保されてないとさ、そもそもできたって言えないじゃんっていうことで、
12:02
そこは保証された前提で、じゃあそのシステム的に良い、後、後押しされる良い行動になってるかとか、
まあ保守性が高いかとかさ、拡張性があるかとか、そういうところの良さっていうところが、
品質を今回の品質として捉えて、それが機能上はうまく動くんだけど、
中身ちょっとやばくて今後直すのきついよねっていう意味で品質が低いっていう風にすればスピードって上がるっていう話。
結論から言うとそこではそうではないよねっていう、必ずしもそうではないよねって話がされてて。
この内部的な保守性とかの品質を後から綺麗にしようみたいな話で、
で、その後っていうのは来ませんみたいなね。
来ません。しかも短期的にがって早くなるって僕らは感じて思ってるたりするんだけど、
本当に早くなるの。早くなるのってどのぐらいの間なら品質を落としても早いのっていう話で、それがめちゃめちゃ短いんではないかっていう主張なんだよね。
1週間とかでもう読みづらくなったり、雑に作った行動のせいでちょっとここと共有しようとした時になんかうまくできなかったりとか、
そういうことが起きて、結果かなり近い未来でスピードが落ちちゃうから、品質下げたら結局スピード上がんないんじゃねっていう主張が流れてますと。
なので、じゃあ時間をかけたら上がるのかって言われると、それってゆっくり作ったらいいかっていうよりは知識とか経験がいるから、ちゃんと教育の方に力を入れるよねっていう話が流れてました。
なるほどね。
じゃあその具体的な内容として、そういう悪い部分、品質が悪い部分ってどういうふうに発生するのっていうところで技術的不採の話が出てくるんだよね。
技術的不採、品質が下がってる状態とここではイコールにされてたね。
3種類ありますっていうふうに。3種類?6種類かな。不採が発生する知識の種類。IT的な技術の話とか、例えば金融系のシステムっていうのだったら、金融系の値に関する知識が足りてなくて、良くない行動になってるとか。
ドメイン知識の部分と、まず2パターンに分かれた上で、発生する経緯によってまた3パターン。
こうやって書いたらいいな、分かってる。分かってるんだけど時間ないんだとか、分かってるんだけど予算足りないんだとかで、ごめんってある程度の品質で妥協したっていうのが意図的な部分。
15:09
人的な不採と変化による不採っていうので、新しい言語が出ました。新しいライブラリが出ました。何なら法改正で金利が変わりました。
もうあるかもしれない。これは改修案件だけど。そういう何か変化したりとか、使ってた技術が古くなったとかね。フロントエンドとかめっちゃあると思うんだけど。
そういうので変化による不採っていうのがあって、もう1個学びによる不採っていう、自分が成長したことによって過去の自分の行動がクソなのみたいなね。
ざっくり言うと。そういうので、当時知らなかったものを学んだおかげで出てくるポジティブな技術的不採もあるけど、それもポジティブなものを含めて置いとくとどんどん悪化しますと。
どんどん古くなるし、そこが古いせいで法改正が変えられないとか、理想とのギャップが激しくなっていくんだよね。
っていう意味で技術的不採は直していこうねっていうのは、それが品質に直結するよっていうようなことが言ってるかなって感じですね。
まあそうだなぁ。理想論を言うとまあそうだね。でもやっぱさ、こういうとすごい老害みたいだけど、
その時その時でさ、ベストな実装をしたとしてさ、ある日突然黒船のように新しい技術が入ってくるじゃん。
でもさ、一方で市場で製品を提供している我々は、
常に競合の脅威に晒されてて、 1ヶ月とか3ヶ月とか開発を止めて、その新しい
フレームワークとか、 ツールとかに移行っていうこともできると思うんだけど、
やっぱプレイヤーに、プレイヤーとか他の競合、他者に遅れを取ってしまうよね。
まあね。それが長期で見たら勝てるよって話なのかな。
そうだね。まあそこまで深い話まで踏み込んでなかったけど、これは記事じゃなくて僕の思っていることとしては、
例えばその、何だろう、
何がいいんだろうな。クラウドとかはちょっと変えたほうがいいかなと。
何かしらツールを使ってたとします。 ツールとかフレームワークを使ってきてました。
で、新たなちょっとイケてるフレームワークが出てきました。 これにすぐ全部変えろっていう意味ではなくて、
今使ってるこれのものの中でもっといい使い方できるよねとか、 これのライブラリの使い方間違ってましたとか、
そういうところを直す、はできるだけ早く直したら、 それを持っておくことも、何だろう、今度直すっていうのを持っておくこともないし、
18:07
新しく学んだ、今学んだことを常に当てていくだけで、まあその変更箇所が明確じゃないですか。
何かずっと溜め込んでるとどこを直したらいいかわかんなくなるっていう意味で、 割とちょいちょい当ててったほうがいい。
ハブサイは編載してったほうがいいよっていうような感じだとは思います。 もうちょっと全体の公開というか、ここをクラウドに移行しますみたいなレベルのやつ。
それはもっと大規模な話だから、計画的にやろうねっていうことだとはもうさっきから書いてないけど、そこはまあそういうことだと思う。
そうだねー。 でもまあ、この経緯全体としてはね、本当にそうだなっていう印象を受けた。
今別通、本業じゃないところで、よそでなんか参加させてもらってる。 開発とかだとテストコードとかで、テストのアサーションのライブラリとかをさ、
新たにちょっと拡張して導入したから、書き方が結構ガラッと変わって、一行こういうふうに書けば、 アサーション、あらゆるパターンでできるようにしましたみたいな。
独自のオブジェクトとかも中身まで見てやってくれますみたいなとかを、 導入されたらもう、一気に全部はやらないんだけど、
そこの回収担当がどっかを回収するたびに、そこのテストは全部付け替えていくもんね。 そうすると、やっぱりどこにずっと残ってる新しく書いたものだけ新しいみたいなことが減っていくから、
どんどん新しい、最近編集したコードが一番見やすいみたいな状態になっていくんですよね。 そういうことにちょっとコストを避けると。
レビューのときにもうここ新しいようなテストの仕方にしてるから、 それ合わせてくれるみたいなの言われたりするし。
そういう余裕がある、余裕があるっていうか、それを当然とするっていうのは大事なことかもしれないですね。
しかも後から来た人さ、
ちょっとこの時足りなかったんだよねとかさ、ここ間違ってたよみたいなやつがいっぱいあると、マジ分からんじゃん。 そうそうそうそう、後から来る人っていう意味では、この記事の中にもさ、
割れ間取り論とかっていう話してると思うけど、採用にも影響したりするよね、やっぱ。
21:02
実際があるとさ、技術的な発信ができないっていうか、
むしろちょっと外すべきことだから、例えばJQueryとかまだ使ってますみたいなさ、プロジェクトとかだとさ、 技術ブログも書けないじゃん、今どきJQueryかよみたいな話になるから。
フロットウェイト早すぎんだよ潮流が。 まあでもそういうところはあるよね、やっぱね。
なんか例えばさ、採用面接で候補者来たとしてもさ、 そのプロジェクトではどういう言語を使ってるんですか?とか言われて、
JavaとJQueryでやってますみたいなと言ったら、 本当にマイナスだよね、今だと。
新しいものへのキャッチアップっていう意味でも確かにそういうのやった方がいいし、 人が入った後、戦力っていうか、そのプロジェクトでちゃんと動ける状態になるまでの、
スピードに明らかに関わると思うんだよね。 あと引き継ぎのめんどくささ。
だからやっぱりそういうコストとしても減らした方がいいと思いますよ、トータル。
なんかね、結構やっぱり技術的負債を返済するために、 ちょっと会社によってはROI出したりするだろうけど、
なんか、 その時に
どうなんだろうね、いかに今の状態が続くことで損失が出てるのかっていうところって、 案外考えられてないところなのかなと思ったりもした。
そこって非技術者は本当にわかんないだろうから、
でも実際、多分あらゆる現実のものでも同じことが起きると思う。技術的負債って、 建築業でも何でもね。
そういうので、ちょっと直感的な例も含めつつ、 実際こういうふうになりますっていう説明を経営者に対して、経営人に対してできるっていうのが多分、
技術側のマネジメントする人の、 いいマネジメント、いいマネージャーだとは思うんだけど、
みんながそれすんの大変だよなっていう感じ。 だからそういうのがやっぱなんだろうな、VPOEとか
そういうのかな。 そういうビジネスと
技術サイドの間に立つ人ってやっぱ大事だなぁと思う。
俺もめちゃめちゃテッキーなタイプのエンジニアじゃないから、 そういうところで価値を発揮しないといけないのかなと思ったりもする、俺は。
人それぞれやりたいこととか強みが違うから、 それが向いてると思ったら、皆さんそういうところのポジションはとても重要があるけど、
やりたがる人が割と少ないので、 やってみたい人はバリバリやってみたらいいと思う。
24:03
社内調整係とも言えるからね、そういうのってちっちゃく。
最新の技術について行きまくりたいっていうわけではないけど、 技術には触れてたいくらいの人はありかもしれないですよ。
その不細の返し方の一例というかね。
そういうところで、いいコード、不細のないコードっていうのはコード単位、ツールとかじゃなくてコード単位ではどんな風に書いたらいいんだろうね、みたいなところで、
さっきした良いコードとはっていうレベル感というかね、 モジュールの結合度とかを元から見て、
一番良いのがこういう状態、一番悪いのがこういう状態なんだけど、 全部を一番良い状態にして書くっていうのは不可能なので、
できるだけこの悪い状態というか、 あまり一緒にいて欲しくないテップがまとまっているメソッドの何々モジュールをサイズを小さくして、
そいつらをサイズが小さい悪いやつをサイズが大きいやつで呼ぼうねみたいな、 そんな書き方についてのことが書いてあります。
これはちょっとこの場でパッとしゃべるのは難しいので、
実際読んでもいいかもしれない。
読んでほしいですね。ノートのところに良いコードとはって、 良いコードとは何かってググったら出てくると思うので、
これ出てくると思う。
皆さん読んでください。
その中で結構いろいろと結合の仕方の話とか、 実際の直し方みたいなものとかについても触れられているので、
皆さんぜひ読んでみてほしいですね。
そうだね。
この間、上司とのワンオワンでも言われたけど、
新規プロダクトとかで、またゼロから良いコードを書くっていうのはそれほど難しいことじゃなくて、
既にある市場に投入されているプロダクトのコードを、
いかに良くしていくか、いかにメンテしていくかっていう方が、
価値のある働きになったよ、みたいなことを言われて、
俺もその時ちょうどUI UX改善みたいなことをやってて、
レガシーなコードに触れてたから、そういう言葉をもらったんだけど、
それは確かにそうだなと思って。
技術的な面と予算とかスケジュール的な面を踏まえて、
どういう順番でどういう優先順位で、どこから直していくかみたいな、
計画が立てれるスキルは本当に重要があると思いますよ。
そういうのって往々にして努力されるんだよね。
そうなんだよね。
やるのが大事なんだと思う。
審議事情とか華やかで楽しいと思うけど。
27:03
マジでその驚くさいところはマジで価値があるけど、
自動化してほしいなって思う。
レガシーな技術とか結構人間のあれこれがあるから、
なかなか自動化って難しいよね。
そうですね。
今日はこんな感じで終わりましょうか。
はい。
では、ありがとうございました。
ありがとうございました。またね。
