00:10
今日も日本からゲストの方をお呼びしています。
Sanjo Satoshiさんです。よろしくお願いします。
よろしくお願いします。
ご本人から自己紹介もしてもらいたいと思うんですけども、簡単に僕の方から紹介すると、
僕がCookpad時代に日本のオフィスで働いていた時に、広告事業でソフトウェアエンジニアをしていたんですけれども、その時の同僚ですね。
今は別のとある面白そうなスタートアップに移って、ソフトウェアエンジニアをされているということなので、
今日はCookpadから転職に至るまでのキャリアの話と、あとは今の現在の会社について、どんな事業をされているのかとか、
その中での参考にしていただければと思います。
Sanjoさんの取り組みということを深掘りしていきたいなと思っています。
今日はよろしくお願いします。
よろしくお願いします。
ということで、改めて本人の方から簡単に自己紹介してもらってもいいですか。
Sanjoと申します。
今説明していただいたように、もともとCookpadで我が妻さんと同僚だったというところで、
もうちょっと昔の話からすると、
新卒で、
Cookpadに入社したんですけど、その時は研究開発部というところで、機械学習エンジニアとして働いていました。
その後、アプリケーションをやりたいなというところで、広告事業の方に移動したところ、
その時の上司、グループ長だった我妻さんと一緒に働かせていただいたというところで、
今年の6月ぐらいに転職して、
新しい会社で今お手伝い頑張っているというところです。
こんな感じです。よろしくお願いします。
だから広告事業に来る前は機械学習エンジニアだったんだよね。
多分入社する時もその枠で入ったんだっけ。
そうですね。もともと大学院のところで機械学習とか研究やってて、
その流れで研究開発部に海賊になったという形ですね。
なるほど。
なぜチームっていうのは、何人くらいのチームだったんですか?2人は。
当初、移動したタイミングでは、我妻さんがグループ長という形で、もう1人上に部長がいて、
チームメンバーとして4人ぐらいかな。
社員は4人かな。
確かに近いですね。
あとインターンが1人いて。
そうそうそう。
日々デビューし合ってたよね。
03:01
経験ガクガクの議論を。
すごいな。
実際に学びました。
アプリケーション側に移ってみて、実際にどうでしたか?大変なこととかありましたか?
仕事の進め方が全然違っていて、
研究開発の方だと、基本的にこういう技術があるからこういうことができますよっていう、
シリーズベースで物事を進めていって、こういうのできるんで何か使ってもらえませんかみたいな形で、
事業部の方に持ちかけていくみたいな動きをしてたんですけど、
トーク事業部の方に行くと、やりたいことがあって、それをかつチームで進めていくみたいなところで、
研究開発部の方は基本、少人数1人で頑張る。もしくはいてももう1人いるぐらいの形で、
小人数でやってたんですけど、
トーク事業部の方は複数人で基本動くっていうところで、
その働き方、動き方みたいなのは全然違いました。
だから研究開発室で機械学習エンジニアやってた頃は、どっちかというと、
リサーチエンジニア的な動きというか、
技術とかそれがあって、それをいかにビジネスに応用できるかっていうのを考えて、
売り込む必要がありましたよね。
だから多分、ステークホルダーマネジメント、
文脈でいうと、まず最初に技術とか、
売り込めそうなポイントを見つけた上で、
まず社内に売り込んでいくみたいな動き方が必要。
広告事業の時はもうすでに、
契約取ったクライアントさんとかがいて、
その人と一緒にやってるビジネスサイドとも、
ある程度数値目標があった上でやっていくみたいな感じだったから、
始まりから違ったようなところもあったよね。
そうですね。
うん。
ちなみにこの、
うん。
なぜ機械学習エンジニアだった時から、
プロダクトを作るっていう方に回りたかったかっていう、
当時の心境みたいなのも、
ぜひ改めて聞いてみたいんだけど。
そうですね。
当時は、それこそ機械学習使って、
こういうことできますよみたいなのを、
事業部の人に売り込んだりとか、
逆に困ってることありますかみたいなのを聞いて、
その事業部のところで課題を持ってるのを解決できないか、
みたいな動きをしてたんですけど、
あんまりうまくいかなくて、
いろいろ話す中で、
実際に事業部に入ってみないと、
本当に何が課題なのかとか、
今何が求められてるのかみたいなのが、
聞いてる範囲だと、
しっかりキャッチアップしきれないのかなと思って、
実際に僕、物が作るのが好きっていうのもあって、
06:01
その、
いろいろ、
利害が一致して、
ちょっとやってみたいっていう風に、
町長にお願いしたら、
移動させてもらえたっていう形ですね。
なるほどね。
もともと結構、
趣味で開発とか、
友人と何か作ったりしてたんだっけ、
あの当時から。
そうですね。
もともとなんかWebサービス作るみたいなのは好きで、
やってはいたんですけど。
ちなみに今まで、
自分とか友人と作ったWebサービスで、
思い出のサービスとかありますか。
そうですね。
最初、
売り上げが立ったみたいなのは嬉しかった。
小学ですけどね。
学校の、
チラバスってあるじゃないですか。
どういう授業をやってますよ、みたいな。
あの辺で、
学校のサイトがあまりにも見づらくて、
もうちょっと使いやすいやつ、
できないかなと思って、
作ってみたやつで、
検索とか、
学生評価大事なんで、
評価で絞り込みできたりとか、
そういうやつを作っていて、
その中で、
ちょっとオプションとして、
教科書とか、
の、
中古サイト向けに、
リンク貼って、
そこでアフィリエイトするっていうので、
ちょっと売り上げがね、嬉しいみたいな。
すごいね。
すごいね。
なんか、
典型的な、
なんか、
綺麗なニッチ戦略というか。
そうです。
完全に大学、
同じ大学の人しか使わないやつですね。
うん。
そういうのが刺さるんだよね。
なんか、ジェネラルに、
それっぽいかっこいいの使っても、
なんか、
PVは増えるけど、
コントリビューションっていうかね、
あの、
コンバージョンまでいかないみたいな、
ところがあるから。
なるほどね。
あれは最初に、
レイルズ触って、
うん。
作ったやつですね。
そうだね。
まあ、
Cookpad、
トータルで何年いた?
5、6年ぐらい?
そうですね。
5年、
うん。
ちょっとぐらいですかね。
そうだよね。
だから、
1回チーム移動してるから、
2つのチームを経験した、
という感じだよね。
そうです。
うん。
広告事業の方も、
僕が途中で、
あの、
グローバルの方に行くっていうのは、
前からも、
後で、
Cookpadの広告事業、
他のね、
あの、
メンバーと支えてくれたので、
そこら辺は、
大変、
感謝してます。
はい。
ありがとうございます。
なんか一番、
思い出の、
技術というか、
技術じゃないな、
プロジェクトとかありますか?
Cookpadの中で、
これが一番楽しかったな、
というか。
いやー、
思い出というか、
あの、
ちょっと悔しかった例で言うと、
そういうことは、
09:00
あの、
我が妻さんが、
広告事業部に、
やった時に、
やってた、
リアアーキテクチャーのやつ。
この広告配信サーバーを、
Railsで書いてるやつを、
Goで、
リアアーキテクトしよう、
っていう、
プロジェクトを、
やってたんですけど、
我が妻さんが、
5倍を作っていただいて、
おお、
大変そう。
で、
ちょっと、
あの、
海外に移動するっていう話で、
抜けちゃった後で、
よし、
やるかと思って、
あの、
引き続き、
僕が、
こう、
リアアーキテクト頑張って、
進めていこうと思ったので、
やったんですけど、
力足らずで、
結局、
完遂はできなかったので、
それはちょっと、
悔しいな、
というのが、
まだ残ってますね。
RailsからGo、
ですよね、
すごい、
それは大変そうですね。
やる。
けんさんがいないと、
大変っていう話ですね。
いや、
あれは、
僕が、
相手も、
全然大変だった。
リアアーキテクトは、
難しいんだよね。
やっぱり、
なんか、
単純に言語を変えます、
みたいな、
あの、
理由だけだと、
その、
ビジネス目標と、
絡めていく必要があって、
例えば、
一部の、
例えばね、
広告商品だけは、
あの、
Goでやる価値があるから、
やりましょう、
ってなっても、
既存の、
他に90%ぐらい、
Railsでうまく動いてる、
機能があるので、
それも、
わざわざ乗り換えるか、
っていうと、
また、
それは別の話になってくる。
補修、
メンテナンスコストとか、
移行コストも、
かなりかかってくるし、
そこまでしてやる必要が、
なるかっていうと、
その、
全部移行っていうより、
マイクロサービスにしたり、
とか、
なってきちゃうので、
うん。
その、
リアアーキテクトの、
その、
エグジットの、
クライテリア、
というか、
どこまでを、
リアアーキテクトとするか、
っていうのも、
結構その、
難しい、
ポイントかな、
と思っててね。
プロジェクトを進める、
みたいな、
なんか、
Railsのコートが、
ゼロになったから、
完成、
みたいなの、
実は本質的ではなくて、
なんか、
そこで動いてる、
ビジネス的に、
なんか、
できるのかな、
っていうのが、
個人的な、
学びでしたね、
僕としては。
うん。
うん。
うん。
まさしく、
その、
進めていく、
メリットが、
うん。
他の部分、
その、
わが妻さんが、
やってくださったことは、
ビジネス的に、
必要っていうところで、
進めていく、
モチベーションが、
結構あったんですけど、
うん。
他の部分が、
あんまり、
モチベーションが、
上がらず、
うん。
事業化して、
うん。
なんか、
そういうチャレンジを、
すごいさせてくれる、
土壌では、
あったよね。
そうですね。
確かに、
なかなか、
許可おりないところも、
ありそうですね、
そういうの、
やりたいと思っても。
うん。
うん。
広告事業とか、
その、
入稿サイドの、
ビジネス要件、
多いからさ、
例えば、
なんか、
今週から、
12:00
来週まで、
こういうテキストを、
何パーセントで、
配信します、
って言って、
画像を入れたり、
テキストを入れたり、
そういった、
サーバってさ、
Railsの方が、
むしろ、
開発しやすかったり、
するから、
うん。
全体の、
データフロードを、
どうするか、
っていうのも、
含めて。
いやー、
まあ、
でも、
いろいろ、
失敗を通して、
学ばせてもらった、
みたいなところは、
僕的にも、
あるかな。
そうです。
かなり、
ありがたい。
それが、
なんか、
最初のキャリアで、
できるのは、
すごい、
でかいですよね、
いろんな失敗が、
2023年、
6月に、
転職。
6月に、
退職して、
同じ月に、
新しい会社に、
入った、
って感じだったっけ?
退職自体は、
なんか、
有給証を含めて、
4月、
5月ぐらいに、
してて、
うん。
6月ぐらいから、
新しい仕事を、
やり始めた。
うんうんうん。
なるほどね。
じゃあ、
徐々に、
その、
今、
どんな会社で、
働いてるか、
っていうのを、
聞いていきたいんですけど、
まあ、
今、
収録とか、
考えずに、
今、
何してんの?
みたいなことで、
聞いたんだけど、
なんか、
全然、
経路が違ったよね。
まあ、
元々、
ソフトウェア、
作ってて、
まあ、
Web上の、
レシピ検索プラットフォーム、
みたいなの、
作ってたけど、
まあ、
今は、
もうね、
製造業界、
業界で、
ハードウェア、
と、
一緒に、
開発してる、
みたいなところなんで、
なんか、
日々、
学びじゃないかな、
と思うんだけど、
その、
どんな苦労してるか、
っていうのを、
ちょっと聞いてみたい。
ということで、
じゃあ、
簡単に、
今の会社について、
紹介してもらっても、
いいですか?
はい。
今の会社はですね、
マジンっていう、
会社で、
まあ、
あの、
工場向けの、
ソフトウェアを、
作っている、
会社ですね。
で、
えっと、
まあ、
2018年、
創業で、
まあ、
23年7月時点で、
まだ、
13人ぐらいの、
いわゆる、
スタートアップ、
の会社、
ですね。
で、
やってることは、
えっと、
工場向けの、
ソフトウェアっていうので、
具体的な、
話でいうと、
まあ、
あの、
製造業向けの、
こう、
加工の、
異常検知を、
するシステム、
みたいなのを、
提供してます。
で、
まあ、
業界も、
いろんな、
こう、
加工方法があって、
今、
いわゆる、
まあ、
例えば、
あの、
金属の棒から、
削っていって、
ネジ作るとか、
そういう、
切削加工って、
いわれてるやつと、
あと、
射出成形って、
いわれてる、
あの、
15:00
樹脂を溶かして、
金型に、
こう、
押し付けることで、
あの、
形作りしていく、
例えば、
あの、
ドラモデルの、
あの、
なんていうんですか、
あの、
パーツとか、
あれの、
あの、
いわゆる、
今、
この、
2つの、
加工方法、
向けに、
以上検知システム、
っていうのを、
提供してます。
なるほどね。
はい。
という、
解説です。
この、
あの、
ウェブサイトを見て、
すごい面白そうだなって、
思ったんですけど、
まず、
ちょっと聞きたいのが、
会社名のマジンティーノは、
何から来てるのか、
っていう、
あんまり、
変換できなかったんですけど、
これは、
なんか、
あの、
もう、
本当の、
由来かどうかは、
知らないんですけど、
社長が、
こう、
インパクトがあって、
覚えやすい名前、
なんでいいんでしょう、
みたいなやつで、
本当に、
それも分かんないですけど、
そういう、
確かに。
理由だし。
じゃあ、
あの、
マジンブームの、
マジンから来てるんですかね。
どうなんですか、
それが、
隠れた理由かもしれない。
ぐらい、
でも、
ちゃんと、
聞いたことないんで、
どうなんだろう、
めちゃくちゃ、
なんか、
あの、
かっこいいよね、
マジンとか。
覚えやすいです。
かっこいいです。
どこで働いてるんですか、
マジンですって、
言ってみたいもんだって。
お前の、
お前のインパクトが、
すごいですね。
ええ。
しかも、
切削加工とかさ、
射出成形、
多分、
僕ね、
三条さんと、
この前、
話す前まで、
このキーワード自体、
知らなかったんですけど、
僕も、
知らなかったです。
うーん、
確かに。
何も。
製造業向けの、
異常検知システムって、
何も。
異常検知システムって、
異常検知って、
SR的には、
結構、
好きなキーワードなんだけど。
うーん。
確かに。
異常っていうと、
まああれですね。
ここら辺、
詳しく。
うん。
あの、
簡単に言うと、
あの、
不良品を検知したい、
っていう話なんですよね。
で、
まあ、
何だろうな、
異常、
どう説明する?
異常とは、
じゃあ、
異常って、
どういう、
異常なネジって、
何?
異常なネジって、
何?
異常なネジって、
何?
そうですね。
えっと、
今、
提供するシステムにおいての異常、
っていう話で言うと、
まあ、
目的、
その、
使ってくださるお客さんの目的としては、
不良品っていうのを検知したい、
っていうところで、
まあ、
どうやって検知してるのか、
みたいな仕組みの話、
に、
寄っちゃうんですけど、
例えば、
切削加工で言うと、
この機械が、
えっと、
動く時に、
使ってる電流値、
みたいなのを、
センサーつけて、
モニタリングしておいて、
なんか、
こう、
違う電流の動きをしてるな、
みたいなのを、
検知してあげる、
みたいなシステムですね。
で、
まあ、
なんで電流を、
見てるのか、
みたいな話で言うと、
例えば、
その、
切削で、
こう、
18:00
金属削る時に、
こう、
刃物みたいなの、
付いてるんですけど、
それで、
削ってる中で、
その、
刃物が欠けちゃったりすると、
まあ、
上手く削れなくなって、
で、
まあ、
その、
上手く削れないんだけど、
その、
その、
加工機自体は、
削りに行こうとするので、
まあ、
普段と違う、
こう、
電流の動き、
みたいなのが、
出てきて、
まあ、
それを、
こう、
検知してあげることで、
非常なんじゃないか、
不良品なんじゃないか、
っていうのを、
こう、
工場の人に伝えてあげる、
っていうシステムですね。
すごいですね。
うん。
この話、
最初に聞いた時、
めちゃくちゃかっこいいな、
と思ったんですよね。
なんか、
匠の技術っぽくない?
なんかさ、
いや、
なんか、
匠の、
木こりとかがさ、
木を切ってさ、
あ、
なんか、
今日は木の音が違うな、
と思ったら、
なんか、
木に異常がありました、
みたいな、
なんか、
それを、
こう、
電流で把握する、
みたいな、
なんか、
そういう、
イメージを思いながら聞いてたら、
めちゃくちゃかっこいいな、
と思って。
確かに。
うん。
確かに。
匠ですね。
電流を測るっていうのが、
面白いですよ。
うん。
うん。
電流って、
どこの電流なんですか?
その、
えっと、
切削だと、
まあ、
モーターで、
こう、
なんか、
金属回したりしてるんですよね。
その、
モーターと、
まあ、
あとその、
えっと、
刃物の部分を、
こう、
くっつけて、
こう、
回しながら、
くっつけることで、
削っていく、
みたいな感じなんですけど、
あの、
機械の仕組み的には、
この刃物を、
この位置に持っていきます、
みたいな、
指令の仕方をしてて、
で、
その、
刃物が、
切れ味悪いとか、
そこに持っていくのに、
より力が必要になってくるんですよね。
それが、
その、
電流に、
現れてくる、
みたいな。
こういう。
へえ、
面白い。
これは、
確かに、
いいですね。
これ、
面白いですよね。
これ、
僕も聞いたとき、
面白いな、
と思って。
ハードウェアの世界の人からすると、
当たり前かもしれないけど、
まあ、
僕ら、
ソフトウェアの世界の人からすると、
エラーって、
なんか、
人為的なエラーの方が、
多いんだよね。
なんか、
その、
バッドコード入れちゃったりとか、
なんか、
デプロイミスったりとか、
で、
なんか、
こう、
メトリクスが跳ねたら、
ああ、
誰かが、
なんか、
また、
変なデプロイしたね、
みたいなのが、
多いんだけど、
まあ、
ハードウェアって、
普通のことやってても、
なんですね、
エラーの幅っていうか、
すごい、
大きいじゃない。
だから、
その、
異条件システムの価値というのが、
なんか、
こう、
ぶどまりみたいな話を、
見たことがあって、
この、
なんか、
100個作った時に、
何個、
失敗するか、
成功するかっていうのが、
ぶどまりみたいな、
それを高めると、
まあ、
21:00
コストが下がって、
利益が上がる、
みたいな話を、
聞いたことあるんですけど、
それを改善していく、
みたいな、
流れの、
目的、
っていうことで、
あったんですか?
そうです。
この、
特に、
切削とかだと、
えっと、
なんか、
何個中何個以上、
なんか、
こういう風な、
話、
ではなくて、
この、
刃物が、
欠けたり、
あの、
切り味悪くなってる、
とか、
なので、
あの、
一回欠けた後は、
多分、
ずっと不良になるんですよ。
それを、
まあ、
今は、
多分、
まあ、
工場によるかもしれないですけど、
基本、
人で見て、
これ、
不良だから、
何かあったのかな、
っていうので、
機械見て、
欠けてるから、
あの、
交換しようか、
みたいなのが、
結構、
でかくなるので、
そこを、
いち早く、
こう、
気づかせたい、
ということですね。
ものによっては、
その、
24時間、
動かしたい、
みたいな、
機械もあったりするんで、
こうなってくると、
余計こう、
気づくの遅れると、
大変なことになるので、
じゃあ、
監視の負担というか、
その、
作業員の負担も、
下げたりできて、
かつ、
稼働時間も、
広げられる、
みたいな、
メリットがあるんですね。
一応、
その、
その、
どんどん、
摩耗してるよ、
みたいなのを、
築けるような、
仕組みもあって、
まあ、
これぐらい、
摩耗してるので、
そろそろ、
交換したまま、
いいんじゃない、
みたいな、
こう、
パラートを上げる、
みたいな、
仕組みもついてたりするので、
この不良が出る前に、
交換できる、
とか、
その刃物の、
その、
最大限の、
こう、
寿命まで使える、
みたいな、
メリットとかも、
あるんですね。
うん。
だから、
まあ、
入れると、
なんだろうね、
コストも下がるし、
それに応じて、
利益率も上がるし、
みたいな、
まあ、
摩耗するタイミング、
というか、
壊れるタイミングも、
事前にある程度、
分かれば、
まあ、
なんだろうね、
まあ、
入れない手はないよね、
多分。
うん。
だから、
方向性としては、
その、
異常検知のね、
精度とか、
あとは、
対応している、
なんだろうね、
プロダクト?
を、
増やしていく、
という風になってくる、
のかな?
そうですね。
うん。
あの、
プロダクトで言うと、
えっと、
うちの、
会社の、
なんか、
賢いなと思った、
ポイントなんですけど、
その、
電流センサーを、
使ってるので、
後付けできるんですよね。
この、
機械の、
その、
電流、
流してる部分に、
後から、
こう、
センサー付けるだけで、
後付けでいいので、
特に、
その、
機械自体に、
加工が必要なくて、
センサー付けるだけで、
電流みたいなところが、
あるので、
後、
電流って、
その、
切削の機械、
こう、
どれに、
24:00
こう、
依存するとかいう、
ものでもないので、
基本、
切削の、
加工機だったら、
対応してるんですよね。
この、
ハードウェア自体は。
で、
後は、
じゃあ、
その、
加工の内容とか、
に合わせた、
こう、
精度のブレとかが、
出てくるので、
その辺を、
どれだけ、
包められるか、
みたいなことが、
このソフトウェアの、
世界に、
落とし込める、
みたいな、
ことですよね。
なるほど。
なんか、
なんすかね、
最近、
ちょっと僕も、
分散システムとかの、
勉強をしてて、
それとすごい、
近いのがあるな、
と思ったんですけど、
なんですかね、
実際に、
機械の、
機械を、
買いに行くんじゃなくて、
機械が、
壊れそうなところを、
検知して、
直すみたいなのが、
まあ、
分散システムだと、
より強いマシンじゃなくて、
安いマシンを、
いくつも使って、
みたいな、
多分、
似てると思うんですけど、
なんか、
そういうのと、
近い考え方なのかな、
と思って、
なんか、
面白いな、
と思いました。
なんか、
サイドカーの、
プロセスみたいなのを、
走らせて、
まあ、
そこで、
その、
アウトゴイングと、
インゴイングの、
ネットワークを見て、
なんか、
こう、
やばそうだったら、
サーキットブレイクして、
みたいな、
そんな感じ。
うん。
なんか、
そんな感じ。
すごいよね。
そういうのを、
真面目に、
こう、
アウトゴイングを、
置いたり、
とか、
して、
こう、
上下させてもらった時に、
すでにさ、
なんか、
設備投資の額で言うと、
大きいわけよ、
金額が。
工場に、
入れる、
なんか、
その、
ね、
大きな、
マシンとかって。
だから、
それを、
もう一回、
替えて、
中を、
ゴニョゴニョして、
入れないと、
この異常検知システム、
使えませんってなると、
電流のところにシュッと
アディションするだけで使えるっていうのが
やっぱその参入障壁も下げるし
使ってくれる人のことを真に考えているというか
賢いなと思って
そのままやるのいいですね
結構そもそもこの業界について僕も知らないんですけど
ここら辺のその
競合というか新しいメーカーの参入状況ってどうなんですか
結構多い?日本とかは
工作機械って言われている
実際に加工する機械自体は
結構古くからあるメーカーがほとんどで
あんまりそのメーカー自体は
新しく参入してないっていうのが現状みたいですね
それに対して異常検知システムみたいなところで言うと
例えば
画像診断みたいなのが結構ある印象ですね
27:02
実際に出てきたものを画像で機械学習とかかけて
異常かどうか判断する
そういうのは結構見るんですけど
僕のまだ業界ぺぺなので
ちょっと知識狭いんですけど
僕の知ってる限りだと
電流使ってみたいなのはあんまりない印象ですね
じゃあ営業とかに行っても
同じようなのを言っている会社はほぼないっていう
工場かもないって感じですかね
そうですね
あんまり最新技術みたいなところが
まだ取り入れられてないところが多くて
こういう新しい技術を使って
提供しているプロダクトみたいなのは
結構興味を持っていただいている現状ですね
実際その参入
導入するハードルも低くて
低いっていうので
とりあえず試してみるみたいな感じにはなってそうな印象を受けてますね
実際にもう試されてるお客さんとかいらっしゃるんですか
そうですね
何社か入れてもらってて動かしてるっていうのが現状ですね
ソフトウェアだけど全然ハードウェア
ソフトウェアも一つハードウェアもあるんで
全然プロセスが違いそうな感じが面白いそうですね
かっこいいよね
ちょっと聞いてみたいのが
機械学習の素養もある三條さんに
さっき画像認識でアルゴリズムの精度を高めようとしてる企業もあるって言ったけど
現状ってどれぐらいなもんなんですか?
ぶっちゃけ画像認識による
そこは正直そんなに詳しくはないんですけど
見せてもらった不良品とかを見てると
なんか人で見ても判断が悪くないんですけど
人で見ても判断が悪くないんですけど
人で見ても判断が悪くないんですけど
触ってみて初めてわかるみたいなレベルの不良だったりするので
それを画像で判断するのって相当難しいんじゃないかなとは個人的に思いましたね
インプットして画像だけじゃなくて
それこそ電流とか別のセンサーを使った新しいメトリクスとか
そういうのをもっと複合的に組み合わせて
全体として精度を高めていくっていう方が
メイクセンスなのかな
なのかなとは思いますね
少なくとも素人が見ても何の不良とは思わないレベルの不良なんで
それがね人間が見てもわからなかったけど
機械に見せるとそこで気づけなかった不良品までわかるみたいなレベルになれば
多分また一つ突破するんでしょうけど
そこはねまだまだという感じなのかな
30:00
難しそうな印象ですけど
その技術って全然
世界で戦っていけそうな技術じゃないですか
そうですね
実際の製造業は結構グローバルで共通の技術なんで
今実際のうちのプロダクトが
アジア系のところに話も近くても結構好印象な感じっていうのは聞いてますね
国ごとの特色の違いみたいなのってあるんですか?
日本は結構多品種で少なく生産するみたいなのが主流っぽいんですよね
ただ聞いた感じだと中国は少ない品種をとにかく大量に生産するみたいな感じの
経路が違うところがあるらしくて
うちのプロダクトだと結構大量生産みたいなところに向いてたりするので
中国も結構面白いねっていう話もあるんですけどね
確かに
種類が少ない方が検査しやすいですよね
品種変えると人が返すみたいなことが結構起こったりとか
全部自動でできるところもあるんですけど
あと分析がちょっと難しくなったりするので
商品種の大量生産みたいな方がうちのプロダクトには
コストメリットもありそうだよね大量生産の方がね
そうですね
なかなかイノベーティブなプロダクトだと思うんだけど
どういったエンジニアリング体制で支えてるんですか
何人ぐらいがいてどういったロールの人が裏側にいるのかなってすごい気になるんだけど
正社員が今13人とかなので少ないんですよね
その中でエンジニアが今正社員僕ともう一人の方2人が
ソフトウェアエンジニアが多いんですよね
あと業務委託で手伝ってくださってるソフトウェアエンジニアの方が2人いる
プラスで結構品質とかが求められるので
QAの専門の方が1人とあとデザイナーの方がいるという感じですね
それとは別にソフトウェアアプリケーション以外のところとして
実際に異常検知するアルゴリズムの部分を作ってくださっている方が正社員1人と
あと創業者が2人いるんですけど
その人たちもともとアルゴリズム系の研究者の方々で
その辺のお二人も手伝ってくださっていて
あと相手の学生アルバイトの方が普通にいるっていう
かっこいいなんか少数性って感じだね選ばれし
33:04
個人的にはもっと増やしてほしいですけどね
中からいる人しかないね忙しいからね
めちゃくちゃ大変なんですよね
大体2人でプロダクトを2つ持ってるんで
もう1人1個みたいな感じなんですよね
めちゃめちゃ忙しいですね
ちなみにどういう技術を利用されてるんですか
技術でいうとまずその加工機につけてるセンサーから
この情報を分析して処理してるエッジデバイス
産業用PCでIPCって言うんですけど
IPCにはPythonで異常検知とかごりごり解析してるところがあって
あとは設定とか実際に加工した履歴とかを
Web上で画面で見たいっていう用語があって
その辺をラストでAPI部分に書くと画面はリアクトとかで書いてる
あとそのエッジデバイスなので
加工性管理とかにはAnsible使って
IPCのキッティングとかをやってるっていう感じですね
これソフトウェアを更新したらリモートでデプロイできるんですか
一応遠隔で更新できるツールはあるんですけど
結構苦戦はしてますね
すごい
あまり効率よくないので
そうですね すごい大変です
あとちょっと特殊な例として
特殊な例というか
IPC以外の例として
一応クラウドで画面も提供してて
工場って結構大規模になってくると
加工機が数十台とかあったりするんですね
今IPC側で提供してる画面っていうのは
加工機一つにつき一つの画面しか見れないので
それぞれの機械をまとめてみたいよねっていう要望があって
そのIPCの情報をすべてクラウドに集約して
クラウド上で見れるみたいな機能も提供してたりしますね
そっちはAPIはPythonで書いてて
画面はリアクトで書いてる
GCPで動いてるみたいな感じですね
扱う技術の幅が本当に幅広くて
これを二人でやってると思うとすごい大変ですね
本当にインフェアにかなりついてますね
かなり近いところからバックエンドとフロントまで
36:00
あとクラウドもあってみたいな
これは実際かなり大変ですね
めちゃくちゃすごいですねこれ
めちゃくちゃ勉強になりそうな環境の気がしました
ちょっと聞いてみたいところとしては
電流を検知して異常検知のアルゴリズム自体は
サーバーサイドで走ってるんだよね
Pythonのプロセス GCPに走って
いや違います
Python自体はIPC上で動いてる
IPC上の方か
部分自分にプロセスを乗っけてるってことか
そうですね
なんでIPC上でやってるかっていうと
異常検知をできるだけ早くしたいんですよね
クラウドに1回データ送ってとかだと
そのネットワークのコストとか
あと
コスト安定するかとか
工場だと結構ネットワーク繋がりにくかったりしてて
そういう課題もあって
IPC上でより早く検知できるように
クラウドには持っていかずにやっている
IPC 産業用PCっていうのは
普通にPCぐらいのスペックがあるんだよね
メモリ制限とかそういったもの気にしなくていい?
ラズベリーパイぐらいのスペックは
ありません
だいたいラズベリーパイだと思うんですよ
それを産業用にちょっと
熱とか長期運用とかに変えられるような構成にしてるっていうのが
多分IPC上がりやすいと思う
なるほど
例えばクラウド側のサーバーとやり取りするプロトコルとかってのは
どうしてるんですか
普通にHTTPベースのAPI
REST APIとかなのか
なんか独自でちょっとショーメモリになるように改変した?
秘伝のプロトコル作ってたりとかするんですか?
今はもうそんな余裕はないので
普通にHTTPに乗せてやりたいと思います
逆にそれでもいいってことなんですね
そうですね
ネットワークのコストとか話されてましたけど
実際に送るときは
じゃあ1時間に1回でまとめて送るみたいな感じで
データを蓄積してからクラウド側に送るって感じになってるんですか?
定期的に発信して送ってるんですか?
はい
この異常検知システムの異常ってどうやって検知してるんですか?
モニタリングですね
今GCP使ってるってことなので
GCP上のクラウドモニタリングツールを使って
アラートさせたりとかしている?
クライアントさんから連絡来たら見るって感じ?
難しくてですね
ソフトウェアレイヤーの異常
39:02
要はエラーですね
プログラムのエラーに関しては
今Sentryとかで見れるんですけど
ハードウェアの異常に関しては
今はちゃんとモニタリングしきれてなくて
一応異常っぽいなってなったら
勝手に再起動するようになってるんですけど
それをうまく検知とかはできてないですね
結構あんまり詳しくない領域で
結構いろんな技術があるっぽくて
もうちょっと深掘りするとうまくできそうな気はするんですけど
まだ触り部分しか見れてないのが現状ですね
この辺SREからしたらすごい楽しそうな領域ですよね
わかんないですけど
なんかさハードウェアSREみたいなのあんのかな?
まあ普通にいるから
リライビートエンジニアリングだもんな
ヘルスチェックみたいなのができればいいんですかね?
なんかハードウェアの世界でのリライビートエンジニアリングっていうのは
多分もともといるだろうし
多分ウェブサイト側の方ができるんですよね?
ウェブサイト側のがSREって形でプラクティスが出てきたけど
そこをミックスさせるようなシステムっていうのがどんどん増えてきてて
そこのなんだってハイブリッドなシステムのリライビリティエンジニアリングに特化した人材っていうのは
実はこれから結構求められてくるんじゃないかなと思ってたりします
うん
確かに面白いな
ちなみに気になったんですけど
このPythonの検査の
処理の部分は
機械学習とかも取り入れたりするんですか?
それとも基本的には固定のロジックで検査していくんですか?
この辺は機械学習とは結構相性が悪いかなと思って
機械学習って検知できてできなかったりするのと
あと理由の説明が結構しづらいところがあるので
今は統計的な手法でこういう理由で異常として判断してますよみたいなのを
ちゃんとお客さんに説明できる形で提供してますね
そうですよね
パターンとかが
ある場合はその方が良さそうですよね
前までは異常とした方が急に出なくなりましたって言われて
結構そのお客さんもうちも困ると
この辺はちゃんとコントロールできる形でアドロイドしています
なるほど
勉強になるよね
この異常検知のスタイルとしては
擬音性と擬音性があるじゃない
フォロースポジティブとフォロースネガティブ
この場合はどっちの方が気にするべきなんだろう?
摩耗してるってセンサーが言ってて見に行ったけど
実は摩耗してなかったっていうのは
そんなにリスクじゃないから
どういう異常検知自体は
多分バイナリーで出てくる?
0が1みたいな感じで
いや今は数値
42:00
連続値で出してて異常度合いみたいな数値で
連続値で出してるっていうんで
そこの異常度合いをどうするかっていうのは
お客さんが今調整してるんで
これぐらいの異常度合いだと
無視していいですみたいな
っていうのはお客さんがコントロールして
一応その
さっきのどっちに倒すかみたいな話だと
擬音性を許容するっていう形ですね
異常じゃないものを異常として
検知してしまっても
それはいいでしょうか?
異常なものを無視する方が問題でしょうっていう形で
これ分かんないですけど
Webhookみたいなのも提供してるんですか?
例えばソフトウェアエンジニアの単純な発想としては
じゃあこれが異常検知の精度も高まってきて
これぐらいだったら確実に異常でしょう
っていうのが見えてきたら
それをWebhookで別のIPCとかが見に行って
自動でプロセスを止めるみたいな感じで
そこまでもういっている?
もしくは世界観として見ている?
世界観としては結構
それは製造業で結構標準的なやり方っぽくて
同じようにうちのシステムとしても
異常ですってなったときは
信号を出してデジタル信号を出して
機械にフィードバックすることで
加工を止めるだったりとか
アラート流すとかそういったことがあって
そういったことをその機械ができるように
信号は提供しているって感じですね
面白いねめちゃくちゃめちゃくちゃ
めちゃくちゃ楽しそうです聞いて
ハードウェア開発ならではの
楽しさと難しさって感じだよね
ハードウェア開発ならではのペインポイント
というか難しさ聞いてみたいんだけどさ
まずアップグレードの難しさって
さっきちょっとちらっと言ってましたけど
そこら辺ちょっと詳しく聞いてもいいですか
提供している各IPCをユーザーに
ばらまいてるわけですけど
それを全部アップデートするのかとか
ユーザーに委ねるのかとかまずいい選択肢があって
現状はまだユーザーに委ねてないので
そのうちの機械の中で
私が順次アップデートかけてる っていう状態なんですけど
数が多いのと 止めていいタイミング だったりとか
実際に加工してる途中に ソフトウェアアップデートするんで
ちょっと止まりますねとか そういうのをされると困るみたいな
45:03
話もあるので コミュニケーションとか取りながら
順次アップデートかけるっていう のは結構今大変だなと思って
最終的にはお客さんに委ねたい なとは思ってるんですけど
そこは結構大変ですね 例えばお客さんに委ねるってなったら
お客さんによって全く更新かけない お客さんだったりとか
常に最新保ってくれるお客さん っていうのもあるんですけど
画面のUI変わると嫌です みたいな人とかは更新しなかったり
とかすると思うんですけど そうなってくると今クラウドも
提供してるので クラウドとの互換性だったりとか
あとバグフィックスしてる人とか みたいな人とかは
アップデートしたいんだけど あんまり取り込んでくれないとか
そういう難しさとかもあったり しますね
クラウドのデータベースのメンテナンス と話が似てますよね
MySQLのバージョン上がったから こっちも上げてくださいって言
われるんだけど それをするとクライアントアップデート
したり 多分事故るからテスト書いてから
とか 本番換去してからみたいになると
今エンジニアリングリソース書けないんで
Likeしようかなみたいな 難しいよね
難しそうだな
お客さんもソフトウェアにそんな 慣れてない方もいそうなんで
その場合になおさらアップデート したくないみたいな人も
いたりすると思うので 大変そうですね それ
あとユーザーにアップデートを 委ねるみたいなことをしようと思っても
その機能を作ることにしたいな と思うので
結構難しいなと思ううまくいけばいいんですけど
例えばうまくいかなかったときに ロールバックどうするのとか
その辺 セキュリティ周りとか考え 出すと結構奥が深そうだなと思
って まだそこまでは着手しきれ ばないっていう状態です
技術的な難しさもそうだけど それ以上にプロダクトとしての
インターフェースをどこまで ユーザーに見せるかっていう意味
での難しさだよね これはね
シンプルユーザーがいじれる設定 のノブっていうのはシンプルに
しといて 稼働してるときにアップデート
かけて迷惑をかけるみたいなのを なるべくシステム側で直すという
か避けるっていうふうに システム側の実装に複雑性を持って
いくのか
システム側をシンプルにしてユーザー に任せるのかっていう
48:00
プロダクトの性格として大きな 別れ道だよね
結構かなり議論要素が多いなと思 って 議論中っていうところですね
実際にこの開発とかをするときに 工場の機械とかがないと開発し
にくいところもあるんじゃない かなと思うんですけども どういう
ふうに開発されてるのかっていう のはどういうふうに考えられるのか
っていうところもあるんじゃない かなと思うんですけどもどういう
はどういうふうに考えられるんですか 検知するソフトウェアとか
Sure
実際にこの電流値を使ってるシステム なのでこの電流値に依存してる
んですよなのでその実際のほうを データがないみたいなのが開発
環境では起こってしまうのでそこが 結構難しいポイントで
一応その 事前に
お客さんの部分に電流値をモニタリングするシステムみたいなのを入れてもらって
それを元に作ったデータで開発進めるみたいなことをやってたりもするんですけど
どうしてもシミュレーション環境と実際の環境だと違う部分が起こったりもして
例えばセンサーでうまくモニターできなかったり欠損してしまったとか
そういうのが起こるとアルゴリズムで異常として判断しちゃったみたいな話とか
結構難しかったりとか
あと実機で工場において長期運用するみたいなのが
開発環境ではあんまり
そこまでテストしきれないところがあって
実際において長期運用してみた中で出てきた問題とか
そのアルゴリズムがちょっとずつデータが溜まっていって遅くなっちゃったとか
そういう問題とかが結構起こったりしてて
難しいポイントだなとは思ってますね
クラウドサービスとかで開発するのと比べると
なんていうか
未知なことが多いから
その辺
予想できないことに対応するのが難しそうっていう感じですかね
ユーザーが何かアクションを起こしてっていうのだったら
自分たちで再現できるんですけど
実際に加工してる機械に依存したシステムになってくるんで
そこを再現するのが難しい
HKSとかが再現できないっていうか
お客さんの環境もかなり異なりそうですもんね
発生する環境としない環境があったりみたいなのとかで
51:02
そうですね 発生する環境としない環境があったりみたいなのとかで
出てきて
それを再現するのも難しいしっていうところがありそうです
だいたい障害で発生して
その問題を特定するときには
まず再現手法っていうのを
探っていくからね
OSSとかでも一周を提起するときには
まずこの再現方法を書いてくださいみたいなところが多いけどさ
再現できないとどうしたらいいか分かんないからね
確率的に
別で起きてるのか
別の未知の結果で起きてるのかみたいな
原因で起きてるのかみたいな
そうなんですよね
こないだ起こった障害として
アルゴリズムの部分が
プロセスがハングしてしまって
何も動いてないみたいな状態になってしまった障害があって
エラーを吐いてるわけでもなくて
ただフリーズして動いてないみたいな
タイムアウト的な感じ
セントリーとかで検知はできないけど
なんか裏側の処理が全然終わってないみたいな状態になって
これ色々結構調べたんですけど
多分ですけど
そのIPCの電源が何かしらの理由で切られた形跡があって
それが何かの悪さをしてハングしたんだろうなみたいなところまでしか分かんなくて
電源を切ってもう一回つけた後にハングしちゃってたってこと
そうなんですよ
なるほど
僕はそのAレイヤーの部分の知識が足りずに
ちゃんとゲイン作成できなかったんですけど
代言もできないのでかなり堂々したやつですね
アルゴリズムなのかプロセスなのかどのコンポーネントか分からないけど
何かがその電源障害に対してリリエントじゃなかったってことだよね
うん
でも通常はもう
問題ないですよね
通常のその電源落ちたパターンだと問題なくて
なぜかそのタイミングだけダメだった
それがなぜなのかがこうなってきた
そのタイミングは特定できてるんですか
ここで止めれば
ここで電源落とせば
それが分かってなくて再現できてないんですよね
そういうのってどうやって検知していくんだろうね
まあなんかありきたりだけど
カースエンジニアリングみたいな感じだけど
なんかそのいろんなタイミングで電源を落とすことをシミュレーションするシステムを
なんか別でずっと動かしておいて特定するみたいな感じとかかな
やるなら
うん
一応その開発のその時では
54:00
電源が落ちるぐらいは想定してたんですよね
なのでまあちゃんと電源落ちて復旧したらちゃんと動くようになるぐらい
確認はしてたんですけど
なんかある特定のタイミングだけってなると
難しくて
いやコンポーネントがね増えてくとね
複雑になってどこでどういった悪さをしてるかっていうのが全く見えなくなるからね
その辺はあれですね
SRU的な人材が足りてないってことで
手が回ってないですね
お
足りてないそうです
ねえ
ちゃんと
足りてないそうです
そうですよ
うん
さんじょうさんに声かかるかもしれない
ぜひ助けてください
なんかこの前あのDHHって知ってます?
あのRailsの
あの
こういったあのなんかプロ
えープロレーサーでもある
はいはい
あのうん
人が
いいオランダだったかなで
ヨーロッパの方であった確かRailsのカンファレンスに来て
なんかピーノートかなんか発表してて
そこですごい面白いこと言ってて
社内でもちょっと話題になったんですけど
僕そのシンプリシティとコンプレキシティの話で
そのシンプリシティを目指そうっていうのはみんな言うじゃないですか
シンプルな設計にしましょうみたいな
でもそのコンプレキシティっていうのも実は重要なんですよと
そのコンプレキシティちょっとなんていう言い方してたか正確に出てこないんだけど
確か言ってたのは
コンプレキシティ is a bridge
コンプレキシティ is a bridge
to
to
simplicity みたいな
その感じかな
複雑性のあるシステムっていうのは最終的にシンプルなシステムを達成するための手段なんですよみたいな
複雑なシステムが自然発生的にできてしまうのはしょうがない
でもそこでシンプルなシステムを目指していくこと
達成していくっていうことがソフトウェアエンジニアリング開発では必要なんだよみたいなことを言っていて
なんか最初からずっとシンプルなシステムを保つっていうのは不可能でどこかしら必ず複雑になってしまうじゃない
ビジネス要件とかお客さんが種類が増えてきたりとか
だけどそれをほっとくとどんどんどんどん複雑にこう
枝葉が分かれていくようになっちゃうから
どこかでグリップしてまたシンプルに戻す
例えば思い切ってアルゴリズムを減らしてみるとか
思い切ってプロセスを1個減らしてみるとか
そういったこう枝計りみたいな間引きみたいなのを定期的にしなきゃいけないんだよね
それが結構リライビリティにもつながってくるから
57:00
シンプルな設計を追い求めるシンプルな設計にするためにこう
ナタを切るみたいなのも個人的にはSREの仕事だったりするんじゃないかなとか
そういうのは最近の気づきではありますけどね
確かにいらないものを持ち続けているのもコストにつながると思うので
何度も見直して今あるものを見直して
いうものだけを持ち続けるみたいな感じですかね
でも大体そんな感じですよね
見直すのってめちゃめちゃ難しいですよね
時間を確保するのもね
延長をして複雑になっていくので
うん
第三者から見たらなんでこんな複雑なのって思うかもしれないけど
工事者からするとあるべくして出てきた可能性な気がしてて
ある時に第三者になんでこんな複雑なんですかって言われて気づくみたいなことは結構経験としてありですね
そのあるコンポーネントの4割はいるけど6はいらないみたいな状態だと減らすのが難しかったりとかしそうです
一部分だけ減らすみたいな
全然ちょっと話ずれちゃうけど
浅井さん中心に今ブッククラブやってて
DDIAっていうデータベースの本読んでたんだけど
そろそろ終わるから次の本しようかって言って
最近決まったんだけど
それこそまさにソフトウェアアーキテクチャーの話じゃなかったっけ
トレードオフとか設計と誤りみたいな
そうですねはい
設計と誤りの話ですね
全然読んでないんで内容わかんないですけど
タイトルめちゃめちゃ面白い
先人からもらうみたいな
うん
もしよかったらご参加してください
そうですよね
ぜひ参加したかったんですけど
あの時間はどれくらいですか
日本時間だとね
あそっか
そうですよね時間
あそっか
ちょっとあそこ以外にずらせないですよね
タイムゾーンを考えると
そうです
浅井さんと僕がヨーロッパにいて
日本からも何人かいて
アメリカ西海岸からも何人かいてみたいな
すごい全世界ブッククラブみたいな感じになってるから
そうですね
一応ついちゃったけど
そんなところかな
なんか話し足りなかったことある?
一個ちょっと聞きたかったのが
なんかラストを使ってるっていうところで
すいませんもう一回ラストを
なんかどういう風に使ってるか
個人的に気になったんで伺ってます
ラストはアルゴリズム
APIに立つって言うんですけどラストで
アルゴリズムとやり取りをするAPIだったりとか
あとそのユーザーに提供する画面用のAPIだったりとか
1:00:01
大きな影響をしてたりします
あとはその裏でいくたバッジジョブとかが動いてるんで
その辺とかもラストは使われてるっていう感じですね
なんかサーバーサイドをアルゴリズムで
結構コードを書くように使ってます
テイレイヤー向けとかではなく
普通にバックエンドとして使ってるんですか?
そうですねバックエンドとして使ってる感じ
まあでもテイレイヤーの部分もあったりもしますけど
それこそ電流センサーとやり取りするみたいなのが
ラストで書いてあるじゃないですか
やっぱりマシン自体が小さいから
それに合わせてラストを使うっていうところもあるんですかね
そうですね最初はそういう用途で動いてました
確かにありがとうございます
僕は大丈夫です
ラスト書いてるんですか?気になってる
ラスト書いてますよ
確かに
ラストも結構いいですよ
ラスト結構好きですけど
Railsも結構好きでしたけど
ラストはラストの良さが
コパイロットとかがいい感じに保管してくれるので
だいぶ書くのが楽になってます
結構ハードルが高いイメージがまだありますね
コパイロットがあればだいぶ学ぶのも楽というか
比較的入りやすいんですかね
それはどうでしょうね
学ぶハードルがそこそこ高いんじゃないかな
そうですよね
何度か練習してないと大変ですよねいきなり書くっていうのは
安城さん機械学習もあるし使ってるし
これのネタも別に話してみてるんだけど
コパイロットの話でこの間あったのが
語欄ってあるじゃない
語欄ってのは機械学習とかコパイロットですごい
学習しやすい言語なんだって
なんでかっていうと
すごいもうみんな同じような書き方するじゃん
言語仕様がそうなってるから
語法マットみたいなの入ってて
みんな同じような書き方するから
この問題に対する正解パターンみたいなのがわりと
割と見えやすい
コパイロットで
ゴーランっていうのはすごい
精度がいいんだって現状
そういう言語ってさ
学ぶ必要あるのかなって
思っちゃうんですよね
なるほど
おかしいかな
機械が
将来的に機械に取り替えられそうというか
機械が全部かけそうな言語
誰かしらがインプットしなきゃいけないと思う
そうはならないと思うんだけど
それだったら
僕はRubyから来てるから
だいぶバイアスかかってるかもしれないけど
自由度の高い言語で
パーソナリティが
ドクドク出るような
ソースコード書いた方が
1:03:01
楽しいんじゃないかなって思っちゃうんだよね
ラストとかは
静的片付けだしさ
どっちかというと
コパイロットしやすい
側なのかなと思ってて
そうです
僕のプログラムを書くモチベーションが
多分我が妻さんと違うので
多分意見が違うんですけど
僕からすると
なんかめんどくさい処理
全部コパイロットにやって欲しいので
パイロットがどんどん書いてくれれば
すごく嬉しくて
その設計とか
その辺は何か個性が出せるポイントなので
逆にそっちで
頑張って
こういう構成でやりたいんだけど
あとは頼むみたいな感じで
任せられた方が僕は嬉しいですね
ラストだからこういう関数書きたいんだって
コパイロットに教えたら
適当にやってくれるんで
途中ちょっと編集して
OKみたいな感じでやってほしい
アサヒさん的にはどう?
プログラミングを書くモチベーションみたいなのって
モチベーション
いや僕も書くのは楽しいですけど
なるべく多くのことが終わった方がいいんで
コーパイロットとか書いてくれた方が
嬉しいなっていうのはありますけど
そうっすね
あんまり意見ないですね
仕事はそんな感じかな
だから週末
日曜大工みたいな感じ
仕事はサンジョウさんみたいに
自動化できるのをどんどん自動化して
コパイロットって名前がいいよね
パイロットのコパイロットだからね
もう全部まかないといけないからね
そういうふうに言われちゃって
週末は社会に貢献できないような
自分だけがいいと思ってる
プログラミングを書いて
自己満足に浸るみたいな
そんな感じ
そうっすよね
趣味としてやるものとはまた違いますよね
そんな感じだけどね
全然話違いますけど
この前チャットJPTで生成したコードをPR出したら
それはちょっと読みにくいんじゃない?みたいな
やっぱりその機械が出してくるものと
実際に人が分かりやすいものと違う時があるんで
なんかそうですね
その辺は工夫していきたいなとか
ただやってもらうだけでも
自分で考えていくの楽しいなっていうのは
ちょっと思いました
プログラミングを文学だとするとさ
誰かに読んでもらうために書いてるわけだから
チャットJPTは編集者みたいな感じかなと思ってて
自分が書いた文章
自分が書いたコードをタイポ直してとかね
自分が書いたコードをタイポ直してとかね
自分が書いたコードをタイポ直してとかね
自分が書いたコードをタイポ直してとかね
タイポ直してとかもっといいネーミングないみたいなやると
編集者が編集してくれてちょっといい感じになる
それを他の人に見せる
文章を書いて
1:06:02
そこが逆
そこがどうなって
どっちが面白いかどうなっていくのかっていうのは
人によるのかな
例えばプロットラインを書いてもらって
こっちが編集して見せるのか
自分が書いたものを直してもらって
書くのかみたいな
その辺はそうですね
人の意見も全然違うところはあるんで
難しいですね
自分の方針とかに沿って作ってくれたら
一番いいのかなっていう気はしましたけど
あれですよ
パイロットは結構過去のコードを参照してくれてるんで
同じようなパターン
同じ書き方で
出してくれる
だから測定をしなくていい
測定して変えるみたいなのは特に必要ない
同じような書き方で出してくれる
同じような書類だったら同じような書き方で出してくれる
ラストだと結構型変換とかで
めんどくさい書き方を結構書かないといけないんですよ
ここをピッて出してくれるんで
重宝する
もう3分この話してもいいですか
はい
ダメだったらダメって言ってね
行きましょう
すごい話面白くてこの前ね
アンチフラジャイルって本読んだんですよ
ニコラス・サレブさんって人が書いた
これはブラックスワンって聞いたことありますか
経済学用語なんだけど
ブラックスワンっていう本があって
それはなんかその
予想してないイベントがあって
予想してないイベントがあって
それが起こったときに
ヒットとかシステムっていうのは
それにすごい脆弱であるっていうことで
2008年のさ
リーマンショックみたいなのが起こったじゃないですか
それの前に書かれた本で
それを予測してたんじゃないかみたいな
ちょっと流行った本なんですよね
僕らが大学生の頃
経済学部の学生が
こぞって読んでたみたいな本で
そのブラックスワンっていう
ベストセラーなのかどうか分かんないけど
それを書いた人の本で
で
そこのアンチフラジャイルが言ってたのは
システムには2つあると
フラジャイルなものと
アンチフラジャイルなもの
脆弱なものと脆弱に対して
耐性があるもの
強いもの脆弱から成長できるもの
みたいなのがあって
そこの例として出てたのが
猫と洗濯機
洗濯機ってのは
人工物ってのはフラジャイルなんですよ
なんでかっていうと
人工物ってのはフラジャイルなんですよ
決まった動作しかしない
で
壊れたら壊れたままなんですよね
1:09:01
壊れたら人間様が
治しちゃいけなきゃいけない
だけど猫とか
生き物とか人間っていうのは
怪我してもそこから治ることができるんですよ
で
それまで想像しなかった新しい
イベントが来たときに
そこから学ぶことができるんですよね
洗濯機はそれができない
だから例えば猫も
ちょっと傷をつけても
そこから回復することができるんですよ
人間も筋トレしたら
より筋肉が大きくなって
よりマッチョになるみたいな感じ
そのシステムで大事なのは
ランダムなイベントだって言うんですよ
予期してなかったイベント
例えば洗濯機ってのは
毎日同じことをするっていうことを
求められてるじゃないですか
ある日突然電源が落ちたりとか
水が止まったりとか
水が出過ぎたりとか
洗剤がより多くの
規定量以上に入れられるみたいな
ランダムなイベント
あとは洗濯と一緒に
石が入れられるみたいなのされると
ランダムなイベントに対して
弱いんですよ
フラジャイルなシステムという
だから弱い
壊れる
終わり
壊れて終わり
だけど
アンチフラジャイルな生き物とか人間は
ランダムなイベントが起こると
ちょっとそれで傷つけたり
ちょっとハングしたりするんだけど
そこから学んで
次同じようなイベントが来たときに
より学んでるから
そこから学習することができる
みたいなのがあるんですよ
なんでその話をしたかというと
さっきのチャットGPという話に戻ってくるんですけど
チャットGP
コパイロットとか
過去に学んだものに対して
常に同じ回答を当ててくるじゃないですか
それって
イノベーションないじゃないですか
過去のものだから
過去から進歩してくるじゃないですか
どうしない
ずっと
だからそこのコパイロットが学んだデータに対して
誰がどうこうランダムネスを入れて
どんどんどんどんその出してくる答えを
発展させていけるのかって
誰がどうしてくんだろうなっていうのを
最近結構悩んでいて
ここまででちょっとなんかアイデアアイデアというか
質問か
ごめんなさいまたモノローグしちゃったんだけど
いやー
めちゃくちゃ深い話ですねこれは
答えが
確かに
誰が入れるかとか
どういう思想で入れるかによって
結果が全然変わりそうですよね
なんか
全く同じ
アルゴリズムの問題に対して
いつも同じパーフェクトな回答を出してくる
っていうのは
実は良さそうなんだけど
でも中長期的に見るとそれって
価値を低減していかないかなっていうのが
問題意識の根底に
あるものなんだよね
うんうんうん
なるほど
1:12:00
はい
それはその側面はありそうですよね
うん
実際今のなんかチャットGPTとか
前なんですかね
LLMとかも改善されてると思うんですけど
それがどうやって改善されているのかっていうところと
繋がってくるんですかね
なんかどういう風に新しい知識を取り込んでみたいな
かもしれないけど
うん
ちょっと分かんないな
すいません
最後に答えのないものをぶっこんで
そろそろクロージングに行こうかなと思ってるんですよね
はい
すいませんね
はい
いやいやいや面白い
めちゃくちゃ面白いです
うん
考えなきゃと思いました
ゲストやリスナーと一緒に考えていく
ポッドキャストということで
はい
まあね
いや
最後ちょっとだいぶ雑誌しちゃったけど
なんか全然畑違いのスタートアップの話聞けるのは
すごい面白かったです
ちょっと浅井さんもどうですか
面白かったですね
感想のためみたいなの
ぜひ聞かせてください
いやあのうん
この全く違う分野で全然僕知らない内容が多かったんですけど
聞いてみると共通点とかも多くて
なんかそういう意味では
なんだろうな
挑戦してみたいなっていう思えるなんかすごいいい話を聞けてよかったなと思いました
なんかそうですね
もう
確かになんで転職したかみたいな
そういう理由とかも聞けなかったので
ぜひその次回また話を聞けたらなと思うんですけど
いろんな解釈を
確かに
あのねよくあるパターンとしては
まずは表層的なイベントを聞いて
2回目3回目でちょっとこう深掘りしていくっていう
そうですね
ぜひ聞かせてください
そんな感じかな
はいじゃあ今日は
株式会社マジンで働く
三条さとしさんをお呼びしました
今日はありがとうございました
ありがとうございます
ありがとうございました
