00:01
どうも、FREE AGENDAでーす。
話しましょう。
今日のテーマは何でしょう?
今回のテーマは、コードを曲げないにもかけることとか、そういうことによって良かったことは何かというのを、
たぶん2人とも強いエンジニアとかそういうわけではないけど、一応かけるものがあるよね、プログラムとして。
ヤモトさんは何がかけるんですか?
僕は、なんかちょっと恥ずかしいですけど、Google Apps Scriptみたいな、Java Scriptでできた、Googleの提供しているツールを結構自由につなげて動かすみたいなスクリプトと、
あとはSQLとか、あとレール図をちょっと書いたりとか、
iOSだと、Swiftを共同創業者の本を見ながら書いて、自分で動くものを作るとか、そういうレベルは軽くやったかな。
Google Apps Scriptは便利ですよね。
Apps Scriptは便利ですね。マクロみたいなものです、Excelの。
いかがさんは?
僕はSQLはきれいじゃないけどめちゃくちゃかけますね。
そうだね。それは僕もそうかも。結構かけるかも。
僕はPythonが好きですね。データ分析系だったりとか、昔はRっていう統計専門の言語を使ったけど、Pythonを結構書くようになって、それはすごい良かったなと思います。
でも勉強したのは本当に年いってからでしょ。
年いってから、そうですね。Pythonを始めてからというのは30とかじゃないですか。それまではHello Worldしてない?
僕もGoogle Apps Scriptを初めて書いたのは28,9とか。
あ、そうなんだ。
だしSQLを初めて書いたのはメルカリ入ったからなんで。
あ、そうなんだ。
30差し掛かるかぐらいです。
今でも書いたりします?
今も全然書きます。
あ、そうなんだ。
何か必要なとか、自分が気になったことを調べるときに書いたりします。
確かにGoogle Apps Scriptは便利ですよね。
そうですね。
コード書けば良かったコードみたいなの何かありますか?
どっちからいく?
どっちからというのは?
じゃあ僕からいこうか。
どうぞ。
コード書けて良かったことは、何だろうな。
その動くもの、要はプロダクト、ソフトウェアとしての動くものって基本的にどういう設計であるのかっていうのが生々しく分かる。
例えばデータベースが必要で、データベース自体も使いやすいものと使いにくい状態ってあるので、それってどうなってたらいいのとか、
例えばそれをインターフェースに表示するときに間で処理が必要じゃないですか。
じゃあどこまでデータベースとかAPIの中で処理を終わらせた状態で送るのが良いのかとか、逆にクライアントサイドでここは処理した方が良いのかみたいな不確実性をどっちに持たせるか、演算をどっちに持たせるかによっても結構メリ出目があるじゃないですか。
そういう設計に理解ができるようになったんで、エンジニアが何に困ってるとか、リファクター何でしたいのかとかの話はすごい鮮明に分かる。
03:08
意識ってミスんないっていうのが1個一番重要な僕にとってはメリットとしてあったこと。
なるほどな、これはなるほどですね。
前提僕も実際描いて何かが作れるって話よりも設計とか思想みたいなのが分かるって話をしようと思って。
ヤモトにまず振って、ヤモトが実際ガス使ってこういう普通に作れたから便利だったよねみたいな話をしたところに、それもあるけどよりオーバーキーでいうと設計がって話をしようと思ったら同じだったっていう。
似てるね、ぬいともですよ。
まあそうだね、確かに処理の速さとかが分かったとか、どういう処理が重いのかとかって結構理解できたのは良くて、
多分エンジニアとかに何か頼むときに、それすげえ難しいって言われるときに、なんで難しいのか結構自分なら納得感ないと、なんで?みたいになる時もあるけど、
なんとなくこの処理は厳しいだろうなとか、ちょっと冗長だろうなみたいなのがあったりすると、少し話しやすくなるっていうのはありますね。
あと技術的なジャッジは僕はもう基本的にCTOに全部預けてるんだけど、
まあ石川さんも。
そう、預けてるんだけど、彼が僕とコミュニケーションするコストが下がってると思う。
それは間違いなく取ってる。
あと僕はやっぱ思うのはオブジェクト思考。
きちんと分かってんのかってエンジニアの人に詰められたら、すいませんとは言うんですけど、曲がりないにも設計人みたいなのは理解しているつもりで、やっぱあれをすごい学んだことが良かったなと思って、
結構今とかってデータ分析とかも、Pythonとかも使わずにGoogleシートでやるのが結構早かったりはするんですよね。
でもやっぱりその時に変数を切り分ける。
事業キャプターを作る時にどういう変数で継続率を何パーにするのかとかってあるじゃないですか。
でもなんかこれって明確にそういった変数みたいなのをハードコーディングしてシートを作ってしまう人と、
変数と切り分けて、なるべくそんな状態にしてオブジェクト思考っぽく、これにはこういう役割を持たせるシート、これにはこういう役割を持たせるっていう風に切り分けて考える。
モンストを結構切り分けるみたいなところだったりとか、複数のオブジェクトみたいなのをバラバラに設計して最終的に繋ぐみたいな感じの思想があると、
すごいシートとか何でも綺麗に作れると思うんですよね。
バリアントとコンセプトを分けるみたいな。
そうそう。完全にそう。モデル部分とパラメータを分けるみたいな感じの思想は全然違うなと思ってて。
自分でも仕事とかで事業モデル作ったりするんですけど、管理とか財務系の人ってそういうのやるけど、そういうのうまくないと思ってるんでしょうね。
全部ベタ書きしちゃって、どこをどういじるかとかっていう、後からの使い勝手みたいなやつとかなくて、
06:05
結構気持ち悪かったりするんですけど、それは明確に自分がオブジェクト思考の言語を書いたことがあるからだなと。
確かに。
思っているんですよね。
確かに。
例えば世の中で今起きているプロダクトとかを設計する時のトレンドとして一個マイクロサービスみたいな、
メルカリとかテックブログとかですごい盛んに発信されてて、なぜそれがいいかとか言ってると思うんですけど、
基本的に99%ぐらいの人ってそれ理解できないと思って、理解できないとかしていない。
なぜならそういうふうにものを作ってきた経験がないというか。
でもソフトウェアってオブジェクト思考の一部じゃないですか、多分マイクロサービスみたいな、一個一個を層にしていく。
それぞれの開発速度とか密度を上げられるようにすることで全体の速度が上がるみたいな。
なんかそういう思想を理解できただけで、例えば組織を設計する時にも、
全く同じ話をしようよ今。
じゃあそれがうまくできるようにするにはどう設計すべきかとか、そこから逆算で入れるんですよね。
本当にそう。
人集める時とかも。
プロジェクトのタスク感とかも、いかにそのAさんとBさんの仕事を素にして、
Aさんが出したアウトプットがBさんのインプットになるっていうところの依存関係とか、
そこは結構ソニーが設計しておくみたいな感じの、各タスクをオブジェクトと捉えてみたいな感じにして、
かつオブジェクトなので、どういうものを入れればどういうインスタンスになるかみたいな考え方とかは。
聞いてる人はこの話に興味があるからだんだん自信になっちゃう。
あとSQLとかかけることで良かったのは、一時情報を自分で得られる量が増えるじゃないですか。
それとかめちゃくちゃいいなと思ってて。
例えばデータを自分で綺麗なマスターテーブル作って、それを集計して、
率がどうだとかっていうのを見れる人と見れない人って、
もはや意思決定できるかどうかに100倍の差ぐらいが生まれると思ってるんで、
その意味だとそれは本当にできて良かったなって思いますね。
それは本当にそうかもね。
だから1個前のポッドキャストでヤマトが睡眠をウェアラブで測ってるって話だったけど、
あれを結構自分で測って毎日勝手に見れるか、毎回毎回専門医とかに問い合わせないと分かんないかっていう状態だと、
こうしたらおっきゅうだしスピードも遅いし、自分が欲しいものとかを体力で取れるかも分からないしみたいな感じで。
フィードバックが遅くなるよね。自分に対する。
それはそうかもね。
だから自然と自分を変えていけるんですよね。良い情報に触れられるかどうかで。
そこが一番重要だったかなっていうのは思います。
まあそれはそうだね。
09:00
ひたくったときにテストアップル、メジャーアップルというか、やって良かったかどうかってデータ的に分かれる。
ちょっとひたくらんだっけとかも考えながらやれるとは思うんだよね。
いろんな人とお茶してたりとかクライアントワークで付き合いしたりする中でも、そういうことをやってる人ってほとんどいないんですよね。
スタートアップとかに言うと、メルカリみたいな良い会社を一回見てると結構それはできるようになるものとか、それがスタンダードになってて非常に良いなと思うんだけど、
やっぱまだまだ少数派だったなっていうのは。
今最近入社した人とかの話を聞いても、そういう人っていないんだっていうのを結構判明したりしてびっくりしたりします。
確かにデータ取ってこられる人がすごく少なくて困っている会社さんは多いですね。
あとどういうプログラミングというかエンジニアリング的な素養を学ぶと人生豊かになるんだろうな。
なんですかね。
でもどんどんそういうのはなくても大丈夫なようにGoogleさんが頑張ってくれてるとは思うんですけど。
いわゆるノーコードの。
ノーコードもそうですし、SQということはビッグクエリとか、昔は自動で更新しようと思ったらエアフローとか頑張って組んでみたいのが、
でもそこに明らかにニーズがあるんだったらGoogleがどっちかっていうとGUIでポチポチできるようにしていくはしていくし、
コードとして価値が残る部分と、割と反英語的にエンジニアにも使える部分と分かれていく気がするんだけど。
あれ系やってて思うのは結局下がってるの、今までデータ見なかった人がデータ見るようになるとか、
自律的に何かをさばいていくようなハードルが下がっているのではなくて、
のではない。
これまでもデータ分析してた人とかのコストが下がってるだけだと思ってる。
それは本当にそう思います。
ハードルは誰も超えてこないっていうのが、僕の観測の中での結論かな。
ああいうツールが改良されていってる先にあるのって。
それは一部そうかもしれない。
一部っていうのは、ビッグクエリの例とかで言うと、僕クエリ書くのすごい好きなんですけど、環境構築するのとかってダルダルなんですよね。
マイスQLを自分のクライアントなりサーバーにインストールして、
そこからいろいろと自分なりの環境を構築していくとかってダルいんですけど、
ビッグクエリって普通にURL打ち込んだら使えるみたいな状況なんで、
ここは結構下がってるって思うんですよね。
確かに確かに。
パイソンとかも結構環境を作るの、ダルいんじゃないんですよ。
自動で全部入れてくれるやつとかもあったりはするんですけど、
リラックスに傾向がある人とかだと、そこでまず引っかかるっていうのは結構あると思うんですけど、
でもGoogleってパイソンみたいなURL一個。
12:00
今パイソンってGoogleが出してるツールで、
Google、スプレッドシートみたいな感じで言われてたら、すでにパイソンが打てるみたいな状況のツールとかなんですよね。
Googleコラボレイトリっていう。
知らなかった。
普通はいちいちパイソン入れて、パイソンを書くための、
名前忘れちゃった。
EDIとか入れなきゃいけないわけじゃないですか。
PMとかして。
そういうのがほとんどなくてもいいっていう、
ベースを用意するっていう部分に関しては楽になっていると。
確かに確かに。
そこでつまづいてる人が結構多いのも事実かなと。
事実ではあると思う。
僕もそこ全然強くないんで。
僕もそうですね。
かけりゃいいんで。
確かに。
毎回パソコン買った後に社内の人捕まえて、
頼む環境設定してみて。
それだけやってくれたら後やるからみたいな感じにしてます。
Googleに限るとそこもどんどん楽になっているんだと思うんですけども。
そうですね。
すごい楽だなって思います。
でもそこはあんまりついていけてないから。
分かる。
どっかを使えばいいんじゃよとか言われても、
すまんみたいな。
本当にすいませんっていう。
そうですね。
最低限かけるといいことあるかもしれないですね。
そうですね。
特にソフトウェアとかアルゴリズムを司るような、
コアになってくるような事業をやる上では、
どんな触手でもあったほうがいいものかなって思います。
はい。
曲がりなりに行動をかけるといいことがあるという話でした。
はい。
ありがとうございます。
気に入ってくれた人はチャンネル登録お願いします。
お願いします。
フリオジャニでした。
またねー。
バイバイ。
