1. 趣味でOSSをやっている者だ
  2. 102: データエンジニアリング..
102: データエンジニアリングの技術の螺旋 (syou6162)
2026-10-01 1:10:52

102: データエンジニアリングの技術の螺旋 (syou6162)

spotify apple_podcasts
  • Even G2
  • LLM高騰とマルチモデルオーケストレーション
  • データエンジニアとしての活躍
  • Data Vault
  • 基本に立ち戻る
  • コードへの肌感の保ち方
  • RSSとmetabol

Even G2

LLM高騰とマルチモデルオーケストレーション

データエンジニアとしての活躍

Data Vault

基本に立ち戻る

  • コードへの肌感の保ち方
  • わからないことは教えてもらう・AIに教えてもらう
  • ドメインエキスパート

RSSとmetabol

感想

まだ感想はありません。最初の1件を書きましょう!

サマリー

ゲストはスマートグラス「Even G2」を紹介し、カメラを搭載せず、軽量なメガネとして翻訳・文字起こし・要約・表示ができる点や、SDKで自作アプリを作れる点を語る。対面の英会話や介護記録、移動中の予定確認に役立つ一方、常時録音への周囲の抵抗やサービス継続性には課題がある。LLMの利用費が高騰する中、Devin Fusionのように高性能モデルを主役にしつつ、実装やテストを軽量モデルへ委譲するマルチモデル構成が紹介され、モデル選択・ルーティングをめぐるDevin、Claude Code、GitHub Copilotなどの動向も話題になる。Devinは独自のコーディング向けモデルにも取り組み、各社が自前モデルを持つことの競争上・政治上の意味についても意見が交わされる。 10Xのデータエンジニアとして、Stailerを支える在庫・配送・店舗運営・分析のデータ基盤と、データマネジメント成熟度アセスメントの実践が説明される。DMBOKを参考に、会社の優先度や依存関係を踏まえて改善ロードマップを作り、メタデータ整備や分析向けテーブルを用意した結果、AIエージェントがデータを探しクエリを書く際にも基盤整備が役立っているという。Data Vaultではハブ、リンク、サテライトでエンティティ、関係、属性の履歴を管理し、複数ソースへの追従やAIによる実装のしやすさが利点として語られる。さらに、アジャイルデータモデリングや単体テストを学び直し、AIに主権を渡さずコードへの肌感覚を保つこと、専門家に教わりながら未知の領域を学ぶことの重要性が議論される。最後に、卓球の推し選手サイトをAIと作った経験と、RSSの新着をMarkdown化するOSS「metabol」を題材に、個人のドメイン知識で小さな道具を作り、枯れたテキストベースのインターフェースを活用する楽しさが語られる。

Even G2の機能と日常利用
はい、趣味でOSSをやっている者だ。引き続きショウさんをゲストにお話をしていこうと思います。
はい、ということで、前半デビンの話とか音声入力の話とかをしてたんですが、
音声入力つながりというか、まあ、みたいなのでちょっと違う話をしていこうと思うんですけど、なんか僕最近、今使ってるメガネがもう12年ぐらいかけてるメガネなんで、
ちょっと買い替えも含めて検討してて、それでなんかちょっとスマートグラスを買うみたいな手もあるなと思ったら、
ショウさんにちょっとこうお勧めいただいたみたいな、まあなんかそういうのがあります。なんかそれについてお話ししてもらっていいですか?
そうですね、なんかこれは買おうと思って買ったっていうよりかは、完全に散々のぶるいで、なんか欲しいと思って買ったみたいなところがあるんですけど、
スマートグラス、イーヴンG2っていうメガネを最近買ってっていうのがありまして、
スマートグラスはいろんな種類があると思うんですけど、イーヴンG2の割と特徴的なところとしては、
意図してカメラを搭載していないみたいなところがあります。
今なのにその写真とか、話した相手の顔とかは写せないっていう感じになっていて、
一方できることとしては、そのカメラの上に、めちゃくちゃリッチっていう感じはないんですけど、テキストだったり簡単なグラフだったり、
表の形式みたいなところとかが出せるみたいなところだったり、あとはカメラ自体に音声の入力のマイクがついているんで、
そこ経由でいろいろ音声の、例えば音声の会話の内容を翻訳してくれるとか、会話サポートっていう機能で音声の書き起こしをしてくれたりとか、
まとめをしてくれたりとかみたいな感じのところがあるっていうところですね。
あとはその公式でSDKとかも用意されているんで、気軽に自分用のアプリとかを作ったり、
ストアみたいなのがあるんで、そこで公開したりとかみたいなのができるっていう感じですね。
大雑把にはそんな感じのものです。
そうですね、カメラついてなくて、なんかちょっとショウさん、カメラにどうこうって言ってたけど、
グラスにそういういろんなものを表示したりとか、そういったものができるっていうことですよね。
カメラ機能はついてないっていうので、割と普通のメガネっぽくて、割と軽いっていう感じですよね。
そうですね、なんかこういう系のメガネって、ちょっとおもちゃっぽいところもあるかなと思っていて、
なんて言うんでしょうか、結構疲れてると、ずっと1日中つけてると疲れてくるとか、
電池が切れたら何も使い物にならないみたいなところがあると思うんですけど、
電池が切れたら何も使い物にならないは、これも同じっていうところがあるんですけど、
結構その電池自体は1日は余裕で持つみたいな感じだったり、
あとはその、全然重くないんですよね。重くないんで、1日、なんて言うんでしょう、
僕とかそもそも目悪い系の人からすると、メガネつけないとそもそも何も見えないから、
日常生活とか外怖くて歩けんわみたいな感じだと思うんですけど、そういう日常用途で全然使えるメガネだったりするので、
そういうおもちゃなスマートレンズではないみたいなところ、ちゃんとした生活で使えるみたいなところがすごい気に入っているって感じ。
ちょっと今つけている色はあれではないんですけど、そんな感じですね。
そうだよね。僕もなので、ちょっと調べて良さそうだったので、
そんなめちゃくちゃ高いってわけでもないから、普通に買いに行って、メガネ屋に買いに行って、
ちゃんとレンズとかも視力測ってもらって、買いました。
ただまだ生産待ちなので、まだいつ届くかわからないという状況なので、ちょっと話を聞きたいなと思っていたんですけど、
これって何で知って、どうして勾配まで至ったんですか?
他にも比較対象とかもあると思うんですけど。
そうですね、比較対象は多分0番目だとかが有名なところなのかなと思うんですけど、
あとは、壮大さんとかが使っているやつだったのかな。
ARグラスとかでパソコンで映しているやつを外部ディスプレイ的な感じでメガネに映すみたいなやつとかもあったかなと思うんですけど、
そういうところとかが比較対象になったかなっていう感じで、
一日中つけて普通のメガネとして使えるみたいなところが、自分としては優先の高いなみたいなところがあって、
そこを考えるとARのグラスというよりかはスマートグラスっぽいところに落ち着いて、
そこからカメラついてると話す人にも身構えられそうだなみたいなところがあったんで、
いい分時に落ち着いてみたいな感じですね。
確かTwitterに急激に流れてきて、欲しいなって気持ちになったって感じ。
誰経由だったかちょっと覚えてないですけど。
たしかにそういうのあった気がする。
たしかにそうか、XDRとかがそういうまさにそういうヘッドマウントディスプレイのメガネ版みたいなやつで結構ゴツい感じ。
だし常用する感じではないって感じだよね、あれはなんかね。
そうですね、あとそのメガネつけてどう入れるみたいな感じになるとまた途端にややこしくなってみたいな話があったんでって感じですね。
スマートグラスの活用とプライバシー
そう、なんか確かにもう僕も英語でのミーティングとかもあるから、
英語でのミーティング、オンラインだと逆にそのトランスクリプトとかが書けられていいんだけど、
普通に対面の英語だと結構困っちゃうなみたいなのがあったんで、
それがちょっと体験で使わせてもらったときにちゃんと目の前に緑の文字で文字起こしが出たりみたいなのがあったので、
これはすごいなってなりました。
どういう用途で使ってますか?
仕事で英会話すること僕はあんまりないんですけど、
先月デビンコンっていうのが東京であったときに、デビンの開発者の人がちょうど来ていて、
さっき話したようにデビンの結構ヘビーユーザーだったんで、なんかフィーチャーリクエストみたいなのしたいなと思ったんですけど、
僕は英語流情に話したり聞いたりみたいなのができたりしないんですけど、
そのEven D2で目の前に翻訳されたのが出ると言ってることはわかるし、
伝えたいことはボディランゲッジプラスあとは気合みたいな感じでどうにかなったんで、
そういうところで役に立ったりみたいなのがありますし、
あとはもうちょい身近っぽいところとかだと、
最近は結構親の介護みたいなところとかで経過とかをいろいろちゃんと残しておかないといけないみたいなところがあったりするんですけど、
そういうところを普通に会話しながら記録簡単に残すみたいなことができるようになったりとか、
また新幹線の移動とかみたいなところの自分用のスケジュールとかを常に目の前に出せたりとかみたいなところとかは便利だったり、
そういうやつのアプリとかを、本当にその仕様とかを伝えた上でエージェントにやってもらえば、
自分が欲しいアプリとかみたいなものが作れたりとか、それが常時メガネで動いてみたいなこととかは結構便利だなっていう感じで普段使ったりって感じですね。
そうか、SDKもあるから割ともうそれもエージェントに作ってもらいやすいっていうのがあるって感じ。
そうですね。なんか、リング、指輪のタイプで操作をできるやつもあったりするんです。
そこの入力だったりとか、あとは音声でどういう入力が来てるみたいなやつを渡してテキストに変換した上で、
例えばスラックのエージェントに流して会話するみたいなこともできたりするんで、
メガネのとこだけ見ながらエージェントとかと会話したりみたいなこともできたりするんで、
外から見ると何やってるかわからない人って感じですけど、そういうこともできるようになったりみたいな感じですね。
そうだよね。指輪も僕は合わせて買いました。
あれは結構やっぱあったほうがいいですね。
そうだよね。便利だなっていうのと、でもちょっとやっぱ未来というか、まだ多分ギョッとされる部分がある気はするというか、
普通に会話してるだけなのに録音されてるみたいな感じにはなっちゃうから、その辺の塩梅とか、それこそ海外行くときとか、
なんか結構そういう場所を選ぶ部分みたいなのがちょっとあるのかなっていうのは思ったりはしますね。
それはそうですね。そこのユースケースみたいなところはもちろんって感じですね。
とはいえね、こういったものが結構当たり前になってくれるほうが嬉しいというか、
みんながね、みんながつけてると、まあそういうもんかってなっていきますからね。
そうですね。カメラはちょっとだいぶ世の中のハードルがありそうな気がしますけど。
そうだね、カメラハードルがある。なんか最近はね、そうだね、録音、常時録音みたいなのはね、
まあそれも結構その際ものアイテムはあるけど、なんかペンダントのやつとか、そういうのは多少なんかそういうもの珍しく認識はされつつあるみたいな、そういう感じはあるよね。
まあでもまあ、とっさのトラブルとかそういった時も、なんか割とその辺の証拠保全みたいなのができそうなのも助かるかもしれないっていうのはありますかね。
そうですね。
いやーなるほど、ちょっと楽しみです。届いて。
8ヶ月くらいしたら届くと思いますよ。
それぐらいだって言われましたね。なのでもうちょっとかな。
だと期待しているので、はい、なんかまた届いたら質問させてもらうかもしれないです。
はい、なんか面白いアプリ作りましょう。
そうします、はい。
ちょっとね、ちゃんと買ったからにはこういうのってこう、事業継続性みたいなところが気になるんで。
ある意味こう使ったりとかしながらね、こう支えるみたいな部分もあるかなというふうには思ったりはしています。
一応買い切りなんでね、使わなくても会社的にはあれは買わない。
なんか、EVEN D2にAI機能ついてるんですけど、AI機能を使うのにそこのサブスクプランみたいなのに入る必要は別にないみたいな感じなんで。
それって、それこそ翻訳とかテキスト起こしみたいなのは、スマホとつないでスマホの方が処理してるみたいになってるわけですよね。
そうです。メガネ単独ではもちろん動くものではまらないです。
でもなんかその辺のやつがちゃんと継続的に動いてもらう必要はあるわけですよね。
刷修されちゃうと困るみたいな。
それはありますね。そういう意味では継続的にって大事ですね。
なるほどな。ありがとうございます。
LLM高騰とDevin Fusion
そうですね、なんかちょっと話を全然別の話に戻していくと、前半最後の話であったように結構最近LLM高いよねみたいな感じになってきてるので、
コンテキストのコントロールみたいなのが難しくなってきてるっていうところで、
なんかその辺の話を僕がいろいろしてたら、デビンフュージョンっていうのがあるっていうのを、
デビンにはデビンフュージョンがあるっていうのを結構教えてもらったんですよねっていうのがあって、
ショウさんに、へーって思って、このブログ記事を読んだんですけど、
これはなんかどういうものかっていうのを教えてもらっていいですか。
なんか基本的にその賢いフェーブルとかみたいなモデル使うと、賢いがお高いよねみたいなところかなと思っていて、
デビンフュージョンとかのアプローチとしては、ユーザーとやりとりするとか結構難しい問題考えられたりするみたいなところは、
フェーブルみたいな賢いモデルを使うんだけれども、
コード書いたりとか、ユニットテストとか、リンター直してとかみたいな、
どのモデルがやってもそんなに変わらん人みたいなところとかは、
サイドキックみたいなさっきのコンテキストを横にどかしたところで作業してみたいな話をしましたけど、
そういうところで作業してもらって、そいつをメインの頭がいいモデルのところに戻してみたいなのを組み合わせながら、
内部としてはユーザーはどっちを使ってるとかは意識しないでいいみたいな、
クロードコーラーとかだとユーザーがいろいろ切り替えてみたいなこととかやったりする場合もあると思うんですけど、
その辺を内部で吉田にやってくれるみたいな感じのところがDebian Fusionっていう感じで、
この書のと張ってるところのリンクのところだと、フェーブルとほぼほぼコンパラくらいの性能落ちないくらいなんだけど、
コストとしては、同じタスクやるのに10.5ドルくらいとかみたいなやつが1.3ドルくらいみたいな感じで、
かなり安くできるみたいな感じのところがDebian Fusionのやつっていう感じですね。
そうですよね。そういう、やっぱり最近そういうフロンティアモデルみたいなものをバカ使うわけにもいかないから、
そういううまく用途別で組み合わせていい感じにやってくれるソリューションみたいなのが結構出てきていて、
結構Debian Fusionは先駆けの一つみたいな感じなのかなっていう感じがしてますね。
クロードコードとかにはアドバイザーっていうのがあったりしますけれども、
それとの違いみたいなものとかも、なんかこの記事書いてたりしたんでしたっけ。
そこの中の細かいところまではちょっと追っかけてないって感じですけど、
仕組みとしては結構似たような感じのところはあるのかなって感じですが、
アドバイザーみたいなところは、例えばアンソロピックが出しているモデルの中のところでいいものを選んでっていう感じだと思うんですけど、
クロードコードそこの特定のプロバイダーに縛られないみたいなところがあったりすると思うんで、
オープンAIがアストラルみたいなモデルを出していきたいと思うんですけど、
ああいうモデル、新しいのが出てきたらそれに追従してみたいなところもあったりするんで、
特定のプロバイダーに縛られてっていうか、いろんなプロバイダーのいいところ取りをしつつみたいな感じで、
なんて言うんでしょう、なんとかの新しいモデルが出たみたいなところに一気に注せずに、
普段の開発を心穏やかに過ごせるみたいなところは、結構この忙しいご時世的にはいいところかなと思いながら使ってるって感じですね。
たぶんこのブログにも書いてて、クロードコードのアドバイザーとかだと、
これは逆にアドバイザーモデルみたいなのを選べて、それこそそういう普段はちょっとリーズナブルなモデルを使うけど、
ちょっと困ったときにアドバイザーみたいな、ちょっとこれなんとかしてみたいな、
そういうちょっと困ったときに上位のモデルを呼び出すみたいな、そういう作りっていうか設計になってて、
DevInfusionは逆で、メインのセッションでそういう割と強めのモデルを動かすんだけど、
実装に立ち入ったところとか、そういったところは軽量モデルに移情することで、
メインのセッションは実装の細かいところを意識しないでコンテキスト埋めずに済むし、みたいな、そういう話なのかなというふうに理解をしてます。
今、該当のところを読み直しました。
アドバイザーみたいな形でやるやり方だと、結構コンテキストキャッシュみたいなのが効かないので、
何度もアドバイザーとかを呼び出しちゃうと、逆にオーバーヘッドが大きいよねっていう問題があって、
DevInfusionみたいなやり方だと、逆に強めのモデルをちゃんとメインに据えるから、
そこのコンテキストが維持されつつも、細かい実装に立ち入ったこととかは、
サイドキックって呼ばれているプロセスに任せられるからいいですよね、みたいな感じですかね。
サイドキックに任せる方のコンテキストは、メインエージェントがギュッと圧縮して関係するところだけ渡せばいいので、
そういうコンテキストでめっちゃ食うみたいなことを避けやすいみたいなのもコストを下げられるようにとしてありそうですね。
AIモデル競争と独自モデル
そうですね。この辺のモデルオーケストレーターみたいなのは、最近各社が頑張ろうとしているところなのは感じますし、
GitHub Copilotとかも、オートモデルセレクションっていう機能があって、
これはHydraってやつと、もともとあるやつと、最近ちょっとエクスペリメンタル、リサーチ機能で出てきたHydra Fusionっていう、
これ明らかにDevin Fusionから名前を持ってきたでしょうっていうのがあるんですけど、
Hydraってやつはオートモデルセレクションで、最初のプロンプトみたいなものに合わせて最適なモデルを自動で選んでくれますよみたいなそういうもので、
これはマイクロソフトの方とか含めた論文がHydraっていうのがあって、
割と4次元ぐらいの超軽量なベクトルで判断してモデルをルーティングするみたいなそういう仕組みになってるっていう感じですと。
ただこれだと結構最初のプロンプト一発で割とモデルを選ぶ作りになってて、
そこがちょっと最初のモデル選定がうまくいかないとちょっと残念なことになるみたいなのがあるので、
そういう意味では多分複数のモデルをうまく組み合わせてやってくれるオーケストレーターみたいなものの方がいい部分もあるんじゃないかということで、
Hydra Fusionっていうのが出てきたんじゃないかなという感じがしてるという感じでございました。
あれでしたね、なんかその魚AIみたいなところがやってたところとかもそうだ気がしますし、
なんかカーソルとかでもオートみたいなところ入ってきたりとかがあるから、結構なんていうか、いろんなところがやりやすいアプローチなのかなと思ってて、
なんかDevinもそういうアプローチなのかなと思ってたんですけど、本当に最近これいつだ、9月11日だから、本当に最近だ1週間も経ってないや。
Devinがソフトウェアエンジニア1.7っていうやつを出してきてて、これはDevin Fusionみたいに複数のモデルを組み合わせてとかではなくて、
その既存の君経営さんみたいなモデルをポストトレーニングした形のどこかのモデルを、このDevinの会社のところでトレーニングをしたモデルで、
自分のところでモデルを出すみたいな感じのことをやってきてて、ここのフロンティア自体をDevinを追っかけないと思ってたんですけど、
そこも頑張ってきているし、そこのモデルにさっき言ったFusionをさらに掛け合わせることでお安くするみたいな、この小ノートに貼ってるリンクのところを見てもらうといいと思うんですけど、
タスクあたりのコストとスコアのところで、コストかかんなくてスコアがいい方がいいよねみたいなところがあると思うんですけど、
一番このグラフでいうと左上の方にいるといいみたいな状態をパレート最適って呼んだりするんですけど、そういうパレート最適なところにそこのモデルがソフトウェアエンジニア2.0っていうところが来てるぜみたいなところが最近出ていて、
そういう組み合わせのところも頑張ってるし、そういうフロンティア的なところの開拓みたいなところも頑張ってて、すごい勢いがあるなっていうのを感じておるんで、Devin不協人間になっておりますがおすすめですという感じですね。
そうですよね。今ちょっと話した話とダブっちゃうんだけど、つまり単独モデルで強力なやつも出してきて、しかもこれはKimiK3っていうもともと高性能なオープンメイトなモデルをポストトレーニングしたやつで、コーディング用途にポストトレーニングしたやつだから、コーディング用途にかなり強い強力であるっていう感じになってきてるっていう感じですよね。
そうですね。なんか今すごいDevinバグってて、なぜか10月末までだったかな。Devinさっき言ったクラウドエージェントとしても使うこともできるんですけど、ローカルで使えるDevin CLIっていうやつがあって、なぜか期間限定でそのモデルが使えるっていう異常なことになっていたりするんで、
あんまりみんな使いまくって使えなくなると悲しいんですけど、そういう感じでお手軽に使えるようになったりしてるんで、ぜひ試してもらえるといいのかなと思ったりしてます。1人からももらってないんで、そういう宣伝ではないです。
そうだよね。割とこういう高性能なモデルをさらにチューニングするみたいなのってあんまり他社やってなくて、それこそCursorのComposer 2.5とか、そういうのは割と軽量なモデルをコーディング用途にさらに特化させるみたいな、そういうのが多かった気がするから、これはちょっと気になるアプローチですよね。
そうですね。その辺のアプローチ気になる人的にも興味深いし、普段使う分にはその辺意識しなくても全然使いやすいみたいな感じではありますね。
最近だと、マイクロソフトとかGitHubも独自でモデルをそんな強く作ってたわけじゃないんだけど、マイクロソフトがMAIっていうそういうモデルシリーズを出してきていて、最近だとMAI Flash 1.1っていう、これはコーディング用途の軽量モデルっていう位置づけで割と安いやつなんだけど、
これはかなり強力な感じになってて、結構各社やっぱりちょっとそういうオープンウェイトモデルをチューニングしたり、MAIはなんか結構自社でさらから作ってるみたいなんだけど、割となんだかんだでやっぱりちょっとモデル自分たちでも作んないとねっていう感じになってきてるのは感じますね。
あれなんですかね、なんかリスク回避みたいなところもあるのかなと思ってて、なんかオープンAIのモデルが、いつだっけ、10月かそこらでなんかカーソルから使えなくなるみたいな、カーソルが色マスカのところを買収されてみたいな感じで、強豪のあれにあたるのかみたいなところ。そういうのがあるとちょっと自前でもモデル持ってないとちょっと危ない側面もありそうですしね。
そうだよね、しかもなんか割とそういう政治的な要素も最近絡んできて、きな臭い部分もあるから、なかなかその立ち回りが難しくなってるのは感じますよね。
でも逆にこういうコパイロットとかカーサーとかもそうだけどデビンももちろんそうで、割と中立的というか自分たちでモデル競争に加わってないから割と各社のモデルを組み合わせて使える良さみたいなのはありそうだから、そういったプレイヤーは残るだろうなっていう感じはするけどね。
まあそうですね、ちょっとこればかりはどうなるか、進化が早すぎるんで読みにくいって感じます。
そう、もう全然読めないよな、なんかちょっと本当に、それこそ2000年代の検索エンジンとかポータルサイトとかがすごくたくさん出てきてた頃と結構似てる感じがしてて、
AOLとかなんかもうあんまりもうなくなっちゃったけど、そういう当時有力だと思われたものが跡形もなくなっちゃうみたいなのがあるから、それと似たようなことが起きちゃうことはあるだろうなっていうのは思ってますね。
そうですね、1年後もわかんない、半年後は無理だな。
いや、わかんないね、本当にね。まあとにかくちゃんと、ある程度このままAIがいい感じに使える状況が定着してってほしいなっていう感じではありますけどね。
うん、そうですね。
10Xのデータエンジニアリング
はい、ということで、AIの話は多分これぐらいな感じがしてて、まあ多少この後も出てきそうだけど、そうですね、なんかショウさんが今の会社に入ってからとかの活動とか、まあその本部のデータエンジニアとしての活動についてちょっと聞いていこうかなというふうに思ってるんですけれども、
なんか取り上げてくださってる話の中で、話したい話とかってありますか。
一応、自分がいる10Xがどういう会社とか、プロダクトを提供しているかみたいな背景だけを簡単に説明させてもらいますと、
10Xって会社でStaylerっていうプロダクトを提供しています。ネットサービスを運用するときのプラットフォームを提供するみたいな会社になっていて、
例えばライフさんとか杉役局さんみたいなオフラインとかでスーパーだったりドラッグストアをやっている会社さんが、うちのStaylerを使うとそこのネットスーパーだったりとかネットドラッグストアができるみたいな、そういう感じのところになってます。
そこでどういうふうにデータが関わってくるかみたいなところで言うと、いろんなところで関わってきていて、オフラインで管理している在庫みたいなところからネットスーパーの在庫みたいなところのデータをどう作るかみたいな話だったりとか、お客さんに商品を届けるまでに実際の店舗で商品をピッキングして、お客さんに届けるようにピッキングとパッキングをしてみたいな感じの操作があったりするんですけども、
そういうオペレーションの最適化みたいなところをどうしていくかみたいなところとかでデータが必要だったりとか、どういうところ、いろんな地域にスーパーあると思うんですけど、どういう地域からネットスーパーを開けるのがいいのかみたいなところの戦略みたいなところだったりとか、普通にサイトの改善みたいなところで分析をしたりとか、そういう改善みたいなところのダッシュボードをパートナーさんに出したりとかみたいな感じのところがあるんで、
ネットスーパーを出す前のところから出した後だったり、実際のオペレーションの改善みたいなあらゆるところでそのデータが必要になったりするっていうところがあるんで、自分みたいなデータエンジニアがその辺の分かりやすいところにデータマートみたいなのを作ったりとか、データパイプラインとかを作ったりみたいなところを、いかに品質高く運用できるかみたいなところをやっておるっていう感じですね。
小ノートに貼ってるところは、そういうデータパイプラインとかに関係する品質のところだったり、そういうデータに関わるデータマネージメントをどうやっているかみたいな話をいくつかピックアップしてるみたいな感じです。
なんか結構入社されてからその辺の整備だったりとかを、かなり一手に取り組まれたみたいなイメージがあるんですけど、そういう感じであってますかね。
そうですね。もちろん自分一人でやったわけではないって感じですけど、入社した当時は結構スタートアップにありがちな結構カオスな状況だったりしたんで、権限管理みたいなところとかから、とにかくその月曜とかのいろいろな集計とかが必要な時期とかにいろいろなところから問い合わせが来て、なかなか日誌もサッチもいかないみたいなところだったりしたんで、
そういうところのどういうところから直すといいかみたいなところの分析をしたりとかして、そこのボトルネックになっているところを徐々に打ち手をやっていってみたいな感じですね。
で、その辺の変遷みたいなところは、小ノートのところに入っているアセスメントでひも解く10Xのデータマネジメントの奇跡みたいなところで書いていたりしていて、今のうちの会社だったりプロダクトでのデータの状況ってどうなんだっけみたいなところをアセスメント形式で一年単位とかでやってるんですけど、そこでそのボトルネックとかがどう変化していったかみたいなところが分かったりしてみたいな感じで、
前職とかでもやってたんですけど、何年もいる会社でやってみると結構面白いみたいな感じのところでしたね。
そうですね、この資料ちょっと拝見してて、そういうデータマネジメント成熟度アセスメントっていうのがあるんだなっていうのを知りましたっていう、なんかこれってどういう、割とこれだみたいなそういうやり方がある、提供されてるものなんですか?どういうものなんですか?
それで言うと、ディンボックっていう、ソンムさん向けとかで言うと、PMD、ピンボックみたいなやつのデータ版がありまして、そこにそのアセスメント的なやり方とかが書いてあったりして、それを結構フルでやるとなかなか大変だったりするので、
マジシャンのコスパに合う感じとかでギュッと圧縮しつつ、みたいな感じでやってるってところですね。
なるほど、なんかこれを結構継続的に、ここ3、4年ぐらい取られてるみたいな、そういう感じですけど、そうです、ピンボックがプロジェクトマネジメントのやつで、ディンボックっていうのがあるっていう感じなのか。
なるほど、じゃあ結構そういうちゃんとしたものが、そういうガイドラインがあるっていう感じなんだね。
そうですね、なんか結構会社のフェーズだったりとか大きさとかによって、どういううちでやっていくといいかみたいなのが結構変わったりみたいなところがあるんで、
うちはこうやったみたいなところで、いろんな会社さんの資料があると思うんですけど、それをどう実際に適用するかみたいなところは、結構工夫が必要みたいなところがあったりするんで、
そういったところを解きほぐすためのいいフレームワークみたいな感じかなというところですね。
11項目みたいなところがあったりして、全社的なレベル、全体的な成熟度みたいなところだったり、うちの会社でどういう項目のところが優先度が高いとか低いみたいなところとか、
あとはこの項目やるんだったらこの項目を先にやっとかないと進めにくいよねみたいなところとかを依存関係立てながら、
メインでやりたいのはここだけど、そのためにこっちを先にやっとこうみたいなところとかを取り込みながら、例えば次の下記とかにやるロードマップのところとかの組み立てに使ったりみたいな、そういう感じでやってるってことですね。
AI時代に生きるデータ基盤
なるほどね。なんか、その辺のここ数年の組織としての変遷がどうだったのかみたいな話と、あと、ピンボックのほうの話をすると、ピンボックとかって結構改訂されてて、
アジャイルとかがちゃんと取り入れられるようになってきてから、結構その7半とかですごい変わったみたいなのがあったりするんですけど、それこそこういうデータアセスメントみたいなものって、AIでめっちゃ変わる可能性あるんじゃないかなっていうふうに思ったんですけど、
その辺りって、それこそ組織側がどうアセスメント的に変わってるのかと、割とそういう考え方みたいなのも変わろうとしてるのかとか、その辺りってどういうふうなのかお話してもらえますか。
はい、それでいうといろんなところがあって、教科書的なところだと、こういうアセスメントやるときってチームでやりたいんで、日本語版があると便利みたいな感じなんですけど、新しい版とかが出てはいるものの、英語版から数年遅れで日本語版になるみたいな感じなんで、
になっていて、かつ改訂された版はAIとかが流行る前くらいに出たみたいなところがあるんで、そういう教科書的なところには結構AIっぽい話はまだ全然載ってないみたいな感じです。世の中的なところでいくと、もちろんAIとデータのところってすごいシナジーあったりするんで、
例えばオントロジーみたいなところをどう構築していくかとか、セマンティックレイヤーみたいなところでエージェントがどうデータをクエリ書くときとかに間違いにくくするかみたいな話とかは出てはきているなっていう感じのところはあるんですけど、この辺のフレームワークのところ、結構よくできてるなと思うのは、
最先端のハウは変わってきてるんだけど、さっき言った11項目みたいな観点のところに新しいハウみたいなところが結構当てはまるみたいなことが多いなと思ってて、ティーワラさんとかが技術は螺旋構造になってるみたいな話よくされると思うんですけど、
なんかいかにもそういう感じになってるなっていうところがあって、なんかこう螺旋渦巻いているところの、例えばそのオントロジーみたいなところとかはこの辺にあるんだけど、そもそもオントロジーってもう何十年も前から言われてる話なんで、そういう話のところにあったりとか、そのセマンティックレイヤーみたいなところとかもデンボックでいうところのこういうところだったりとか、こういうところを強化していくと自然と紐づいてくるみたいなところがあったりするなっていう気がしているんで、
これ変化が早い時代だからこそ、このデンボック自体も何年くらい前かな、多分20年以上前くらいからあるような話のところだったりするんですけど、基礎っぽいところは意外と由来でいないなみたいなところがあるんで、最先端のハウのところが変わりつつ、根っこのところはしっかり抑えておくことには引き続き価値があるかなみたいな感じで思ってるってところですかね。
なるほど、確かにそういうところはある感じがするし、あとデータとかで言うと、最後のほうにRSSのネタとか書いたけど、割とそういうセマンティックスを守らせるとか整形させるみたいなのがAIによってやらせやすくなってる部分とかもある気がしてて、そういう整備みたいなのをそういうフレームワークに沿ってやらせるみたいなのもやりやすくなってるのかなみたいなの最近ちょっと感じたりはしますね。
そうですね、うちの例とかでいくと、入所した直後とかは、ビズデブの人とかが、ティンクスの良い文化として社長とかもクエリをバンバン書いたりとかするし、ビズデブの人とかも自分でめちゃくちゃ難しいやつじゃなければ書くよねみたいな文化があって、それはすごい良いって感じなんですけど、
入った当初とかは結構似たようなテーブルとか似たようなカラムとかがあって、どういう時にどれを使えばいいみたいなのが結構わかんないみたいな話とかがあって、近くのデータエンジニアに教えてもらうとか、スラックに貼ってある過去のクエリをコピーして使って、でもこれじゃなかったみたいな感じで間違えるとかみたいなのはかなりあったんですけど、
その辺のどういうテーブルがどういう用途で想定して作られているとか、このカラムはこういう意味でとかみたいなそういうデータに対するメタデータみたいなところを付与するみたいなのを、僕入った何年目くらいかな、多分1.5か2年目くらいとかでガッとやって、
で、社内の8割くらいのところには何かしらそういう状況がわかるメタデータが付いてるみたいな感じのこととかをやったりしたんですけど、そこで人間がセルフサービスできるようなみたいなことをいろいろ工夫していってたんですけど、最近だとエージェントが探すみたいなこととかが結構当たり前になってきてるんですけど、
そういった状況でこのデータはどういうものかっていうのをカラム名とかだけに耐えらず、メタデータをちゃんとAIが読めるみたいなことを準備してたのは、今の時代めちゃくちゃ効いてるなみたいなことがあったりしてるんで、なんかそういうAIが来たからっていうよりかはアセスメントのところで必要そうなところとかをちゃんとやっていたらちゃんとAIのところにも効いてるなみたいな感じになっていて、
なんかその投資対効果的なところは出てきているのかなみたいな感じですね。なんか分析のところとかもその人間がこういうふうにしやすいみたいなそのディメーショナルモデリングっていうそのモデリングの手法とかがあったりするんですけど、そういうところを人間向けにちゃんと整備して、ビジネスの人から使いやすくみたいなところとかも整備をしていった結果、
クエリの書き方みたいなところも、AIが長大なクエリを書くのは簡単になってると思うんですけど、その確認を誰がするんだとかみたいな問題とかがもちろんあると思ってるんですけど、そういう長大なクエリ書かなくても分析をしやすいような分析に向いたテーブルとかを用意してあげておいたら、
AIもクエリを書きやすくなったりとか読みやすくなるみたいなところがあったりしてるんで、基礎とか基盤みたいなところとかをやっておくと、こういう時代に生きてくるんだなっていうのを痛感しているみたいな感じですね。
なるほどね、そうか。土台をちゃんと整備してたから立ち上がりもちゃんと早かったみたいな話か。それはいい話ですね。だし、ちゃんとそういう整備、ちゃんとやるの大事だよってのはあんま変わんないので、そういう整備を後追いでもいいから、AIにやらせてもいいかもしれないし、設計とかはちゃんと自分たちで考えようねみたいな話ですかね。
そうですね。
Data Vaultとデータモデリング
ちょっと軽く教えてもらっていいですか。
これはデータ界隈のところでもめっちゃみんな使ってるかっていうと、ディメンショナルモデリングほどは普及はしてはいないっていう感じのとこなんですけど、うちの会社みたいにいろんなデータソースとかを取り扱いつつ、アジャイルにデータのパイプラインとかデータのモデルとかを組んでいきたいみたいなときに使われる、そういうときに相性がいいモデリングの手法みたいな感じになってて。
簡単にかいつまんで説明すると、モデリングするときの要素として3つのパーツがあって、ハブっていうやつとリンクっていうやつとサテライトってやつがありまして、ハブっていうのはエンティティの定義を決めるみたいな感じのやつで、そいつのキーになるものは何かみたいなものとかを決めておいて、例えばハブユーザーみたいなやつとかがいるみたいな感じになってて、
ハブユーザーとかハブショップみたいなやつとかがいて、リンクっていうのはハブとハブのつながりを表す履歴を持ってるテーブルみたいな感じになってて、例えばあるユーザーがうちのスーパーみたいな例だと、
僕が京都の〜店舗のユーザーになりましたみたいなときにはそこのリンクが入るみたいな感じになって、引っ越して他の店舗を使うようになりましたって感じになったら別のリンクが入ってみたいな感じのハブとハブのつながりを表すみたいな感じになっていて、最後のサテライトっていうのがハブとかの属性、アトリビュートの履歴を管理するみたいな感じのものとかになっていますと。
例えばユーザーの住所がどこどこで引っ越して変わったとか、ネームとかあとはイメージがどう変わったとかみたいなアトリビュートを管理するみたいな感じのモデリングになっているっていう感じになっていて、ここまでが概要って感じになっていて、データボルトの何がいいのみたいな感じのところとかで言うと、
いろいろあるんですけど、例えばうちとかで言うといろんなパートナーさんからデータをもらってみたいなところがあるんですけど、いろんなデータが来たときとかにそこの追従だったりみたいなところが後からやりやすいみたいなところとかがあったり、あとは分析の方面とかでさっき言ったそのユーザー向けにはディメーショナルモデリングやってって感じ、
例えばそのファクトオーダーみたいな感じとかディムユーザーみたいなのを組み合わせてみたいな感じでやったりするんですけど、そこの前段のインターナルなところをデータボルトとかでモデリングすることが多くて、結構データボルトってさっき言ったハブとリンクとサテライトみたいな作り方が結構かっちりしてたりするんで、
エージェントとかにいろいろ任せたりするときに、なんて言うんでしょうね、結構そのデータウェアハウスの中の作り方って会社によってまちまちだったりするんですけど、お作法的なところがあるとエージェント自体もそこの知識があったりするんで、結構迷わず書いてくれるみたいなところもあったりして、
そういう意味でデータボルトって多分20年か30年くらい前からあるフレームワークって感じなんですけど、今の時代に結構向いているような感じのフレームワークかなっていうところで、うちのチームで何年くらいかな、僕入る前とかだから4,5年くらい運用してるみたいな感じのやつですね。
おだしょー なるほど。すごくさらっと見た感じ面白そうだなと思ってて、最近やっぱりよく業務アプリとかそういったものを作る上で、ちゃんとイベントを地区一事実を記録しましょうみたいなことは言われるんだけど、
じゃあそれをどういうふうな分類としてモデリングすればいいんだっけみたいなところって、僕としても曖昧だなって思っていて、そういう意味ではちゃんとそういうエンティティ的なハブがあって、
関係性の変化だったりとか、属性の繊維みたいなものをちゃんとその、なんていうか、細切れのモデル、イベントでは取りづらいやつをちゃんと関係づけるっていうか、まとめて管理するための考え方として確かに良さそうなのかなっていうのを、曖昧な理解ですけど思ったりはしました。
そうですね、なんかそのバックエンドのモデルとか、RDBの側で、そういう、なんていうんですか、履歴テーブル的なところとかをちゃんと管理してくれたりとかしてくれると、もちろんデータウェアハウス側でも管理しやすいっていうところがあると思うんですけど、そうなってないところとかでも、ちゃんと履歴管理だったりとか、そういうエンティティのリンクの付け替わりだったりとか、そういうところをちゃんと解きほぐして、
この形に持ってくるのとかはそのデータエンジニアとかだったりするんですけど、いい形になってるとやりやすいし、そうなってない形でもその型があると、どういう感じでやるっていうところがやりやすいっていうのは、こういうデータボールとかのモデリングのフレームワークを採用するご利益なのかなっていうのはありそう。
なるほどね。だからデータウェアハウス側でのモデリング手法で、ある意味そういう雑多なアプリケーションからのログみたいなものをちゃんとそういった形で整理して保存してあげるといいよみたいな感じっていうことですかね。
そうですね。
あと逆にそういったところを意識して、アプリケーション側の、それこそRDBのモデリングだったり、そういうログの出力みたいなのもやれるといいみたいなところがありそうだなって思ったんですけど、その辺もなんか取り組んだりされてるんですか。
その辺は僕がっていうよりかは、ソフトウェアエンジニア側のプロダクト作っている側のチームでやってくれているとか、結構意識してくれているところがあってありがたいなっていう感じになっていて、例えばステータスが遷移するみたいな状態のものなんだけど、
例えばビッグクエリとかにはデイリーでしかロードされないんで、途中の遷移がわからなくて、問い合わせがあった時にどう遷移したかわからないみたいなところとかをちゃんとイベントにしていきましょうとかみたいなところとかをやってくれているチームとかがあって、確かね、この秋のイベントソーシングの回とかでもそういう話をしてくれるみたいな、鈴木さんって方が話してくれるんですけれども、
そういったところは僕のデータ基盤チームの中だけっていうよりかは、もちろんソフトウェアのエンジニアがやってるバックエンドのチームとかと連携しながらみたいな感じのところでやってます。その辺の結構、こういうところで苦しんでるみたいなところとかをオフサイトとかに行って話したりとかして、改善とかになることもあったりするんで、すごい助かってるなっていう感じですね。
基本に立ち戻る開発とOSS
なるほど、いいですね。ありがとうございます。なんかデータウォルトそういう歴史あるなんか手法、フレームワークだと思うんですけど、なんか今学ぶとしたら、なんかどういったおすすめの書籍とかってないんですか。
そうですね、なんかいきなりデータウォルトから入るの結構なんかハードウェイって感じかなと思っていて、最近だとおすすめ、僕がおすすめ勝手にしてるって感じなんですけど、アジャイルデータモデリングっていう本が最近、本自体は昔からあったんですけど、日本語で翻訳されて、結構読んでみたらよかったんで、
僕もデータテックJPっていうコミュニティーの中で、どのくらいかな、半年くらいかけて輪読会やってっていう感じでやったりしたんですけど、この本はすごくよかったですね。なんかモデリングから入るっていうよりかは、このビームアスタリスクのアスターで、ビームアスターっていうシェアリングとかも兼ねたところの方法論みたいなところが定義されていて、
なんかその分析から入るっていうよりかは、普段の業務プロセスみたいなところをどうやっているかみたいなところを聞きつつ、そのデータのモデリングに必要な要素とかをどう取り出していくかとか、そういうところのシェアリングとかそういうところも含めた話からディメンシタのモデリングみたいな話にやっていくみたいな方法とかが結構例とかもたっぷり書いてあったりしたんで、自分は最近この辺をおすすめすることが多いですね。
ありがとうございます。さっきリンクを踏んだら、Kindle版を持ってて積んでたことに気づきました。なんかそうですね、持ってきてくれた話として、なんかそこに今の本の話も書いてますけど、基本に立ち戻るといったことを書いてくださってますけど、これはどういうお話ですか。
そうですね、さっきのリンボックの話もそうなんですけど、結構昔からある話が今の時代に結構生きてくるみたいなところもあるなっていう文脈もあるんですけど、うちのチーム、バックエンドが経験あるデータエンジニア、今4人チームでいるんですけど、バックエンドの経験があるエンジニアが僕とEMでいて、
分析系、アナリストのところから来たアナリティクスエンジニアの人が2人いてっていう感じになってて、EMの人は今A8とか他のチームの兼務をしてるみたいな関係があって、今僕とアナリティクスエンジニアの2人で結構メインの業務回してみたいなところが多いんですけど、
なんかそうすると結構そのソフトウェアエンジニアのバックグラウンドがない方とかだと、結構その、なんていうんですよ、パイソンとかのそのソフトウェアを書くみたいなところのコードとかをテストとかをどういうふうにテストしていくといいかとか、どういうふうにするとそのテストがしやすくなるかみたいなところの勘どころがない、
まあそのアナリストから来たらまあそれは当然という感じだと思うんですけども、とはいえその今まではそのエスケールとかを書いていることが多かったんで、データの取り込みだとかAIエジェントを使ってなんかやるみたいなそのアプリケーションのところとかは僕がやってみたいな感じだったんですけど、
最近だとそのエスケール自体はそのAIが書いてくれるみたいなところもあるんですけど、役割をちょっと拡大させていくとか、そういう必要もあるねっていうところがあるんだけど、まあそこの書き方がなかなかわからないとそのエージェントが書いてきたコードをそのまあよかろうみたいな感じで出してきてしまうみたいなこととかがあったりするなっていうのがあって、
今そのチームの中でここでちょっとリンクを貼っている単体テストの考え方使い方みたいな本とかのリンクをとかをやったりとかしたりしているっていう感じですね、なんかここもそのなんかこの辺がないと結局なんかそのエージェントの言いなりになったりみたいなこともあるし、なんか出してきたプルリクエストを誰かからコメントもらったけどそのコメントをエージェントに食わせてみたいな感じになっていると、なんか何やってるんやみたいな感じでだんだん虚無な感じになっていくんで、
仕事を楽しむっていう意味でもそのエージェントに主権を渡さずその自分の力をちゃんと蓄えていけるみたいなところとかを意識したいなとかと思ってちょっとチームでその基本に立ち戻るみたいな、ここちょっとどっちかっていうとそのアナリストから来た人とかみたいなと、そういうところでどうやっていくかみたいなところがある、でも若干そのチーム事情っぽいところがあるかと思うんですけど、
そういうなんか基本に立ち戻るみたいなところはデータモデリングみたいなところでもそうだしテストっぽいところとかでもちょっとそういう機会は増えているなという感じでちょっと書いていってたって感じです。
なるほどね、ありがとうございます。確かになんか文外観なところに来た時にちょっとよくわかんないけど周りがこれでよしって言ってるからじゃあそれでいいのかってなっちゃうのはあんまり良くなくてっていう、ちゃんとっていうのと、最近やっぱAIにいろんなことやらせてると自分が知らないこととかなんかこうどんどん進めてくれるからなんかよくわかんないけどそれでいいのか、いいのかなーって流されちゃうことも起こりそうだけど、
でもまあやっぱそうだよね、理解を手放さないみたいなことは結構大事だから、そういう意味ではこういうなんていうかある意味ベースの知識みたいなものがやっぱ改めて役に立つみたいなのはありそうかなっていうのは思いますね。
そしてあとはなんかその本読むのもいいんだけど、なんか本に書いてあるところが具体で僕らのリポジトリでは例えばどういうところなのかとか、なんかこうなってるんだけどこうなってた、本当はこうしたんだけどこうなってる理由は歴史的背景で実はこうなっていてみたいなところとかも一緒におさらいできるとか、なんかそういうところはモデリングのところもそうだしテストのところとかも結構いいなと思いながらやってますね。
たしかに業務に近い、業務に課題感があるところの話を、てかそういう話題の本読むと割と業務に絡めて理解も深まるし、業務理解も深まってお得みたいなところはあるよね。
そうなんです。まあそこと関係していつつ、なんか逆のことを言うんですけど、そう言いつつ、自分がコード書く量ってもう2年前くらいからするとかなり圧倒的に減りまくってるって感じだと思うんですけど、なんか書かないとコードベースの理解とかがやっぱりどうしても浅くなってしまうなみたいなこととか、
まあとはいえなんかここのところを手放すとそもそも自分は何やってる人なんだっけみたいなところもあるなみたいな感じの、なんかその自己矛盾を抱えながらやっているなみたいなところもあったりして、そもそも僕がそのマカレルチームにいた時から、結構EMとかそういったレイヤーの消灯されてることとかもあったりするかなと思って、
なんかこういう時代とかでその肌感覚みたいなところとかをそのどう保ち続けるかみたいなところってその、まあ昔からあったかもしれないけど、なんか昔からあったかもしれないけど新しい課題みたいなところでもあるのかなっていう気がしてて、なんかその辺存分さんどういうふうになんていうか向き合ったりとかされてるのかなみたいなちょっと僕は聞いてみたかったって感じですね。
これは難しいですよね。なんかちょっと似たような話結構いろんなところでしちゃってるからまた話すみたいになっちゃうかもしれないけど、まあただなんかそう、その今言ってくれたようにあんまりそのマカレルやってた時とある意味変わんないなって思ってる部分はあって、なんかマカレルなんてもうなんかみんなそれぞれの専門性が突き抜けてるスターエンジニア軍団だったから、
なんかもう僕も別にそれぞれがやってることなんて理解できないわけですよ、完全にはって思ってて、もうそこで、でも別にその、なんかこっちがやりたいこととか、なんかこういうことを伝えるなり、逆にその向こう側もこういったのあったほうがいいですよねってやってくるみたいなのもあったから、なんか割ともうそういう状態になれちゃったみたいなのが結構あるっていうのと、
逆にやっぱそういった時に、そのわかんないところはなんとなく教えてもらうみたいなことを、逆にそういう人が教えてもらうみたいなことをやるように心がけてたから、いや心がけてはないけど、そうだね、だからそれこそ機械学習の話をしょうさんに聞いたりとかそういうのしてたから、
まあそれとあんまり変わんないかなっていう感じはしてるし、そういう意味では、なんかそういう作ってきた、そのサブンとかコーディングエージェントが作ってきたものに対して、まああんまり確認せずに取り込むことも自分のOSSとかだったらあるんだけど、でもなんか気になったところは、なんかちゃんと聞いてみて、なんか理解を深めるみたいなことはやってるみたいなのがあるかな、
ちゃんとそういう、なんていうか、自分がこう、刺激というか刺激してるというか、そういう知り合いを与えてる人たちから教えてもらうみたいなことを結構やると、逆に知らないこととかも高速にキャッチアップできてお得みたいなふうに思ってる部分はあるかなとは思いますね。
たしかにですね。キャッチアップする部分でそういうのを活かして、逆に浅くなりがちなところを深めていいみたいな。
まあとはいえ、なんかそういう綺麗な話もしつつ、確かになんかこんなふうにこうノールックマージ的なのでやってていいのかみたいに思っちゃう部分はあるっちゃありますけどね。
うん。ここはなかなか難しいですなぁ。
まあでも、そうだね、そういう意味で、普段使ってない言語とかをなんか書いてもらったりすると、割とそういう、教わったりする、教えてもらえるとか、なんかこの言語ではこういう考え方なんだな、みたいなのはあったりはするなとは一時期思ってたんですけど、
やっぱなんか僕はGo慣れてるし、GoをAIにやらせるとすごい快適だなっていうふうに、まあ多分それは僕が慣れてるからもあるんだけど、っていうのはちょっと思っちゃって、Goを使いがちみたいなのはありますね。
Goはやっぱコンパイルっていうかビルドとかテストが早いから、割とバグって直すみたいなのをAIがすごい高速にやってくれる感じがあるんだよなって思ってます。
それはわかりますね。自分もそのスラックとかで動かすAIエージェントを昔Pythonで書いてたけど、毎日だなと思ってGoで書き直したらだいぶ快適になったんで、もちろんPythonでもできると思うんですけど、快適度に上がった気がするな。
ラストとかもいいんだけど、やっぱビルドに時間がかかるから、割とエージェントがドツボにはまった時に復帰してくるのにちょっと時間がかかるなっていうのは感じますね。
Goもおすすめ。
でもなんか、たくさん作るとか、自分が作りたいものをたくさん作ってみて、そういう経験学習みたいなものがしやすくなってきてる時代だと思うし、
逆にそういうふうに、ドメイン知識を持って早く学習して、出して検証して作り直すみたいなのを早められるのが今一番強みになるから、ソフトウェアエンジニアって自分の作りたいものを作って改善するみたいなサイクルって自分自身がドメインエキスパートだからやりやすい立場にあると思っていて、
だからそこは多い、自分だけのツールを作るのもいいんだけど、割とうかつにやっぱり出してしまって、それで誰も使わなかったら別に自分だけが使えばいいだけだから、別に出していけばいいんじゃないの?っていうのは僕最近は思ってることではありますけどね、っていう。
自分も最近、ショーノートの上の方に書いてたんですけど、趣味で卓球が好きで、最近も金沢まで卓球の試合の応援に行ったりとかしてたんですけど、なんかそういう卓球の推しの選手をひたすら応援するサイトみたいなのを作ったりしたんですけど、それ自体は別によくって、
卓球の試合だったりとか、例えばシングルスの試合もあるし、ダブルスの試合もあるし、プロリーグみたいなのもあるし、日本代表選手みたいな、一つの大会だけみたいなところとかもあったりするんで、そういうところとかをどうモデリングするのかみたいなのをひたすら週末、エージェントさんと話していて、
そこの卓球に関するところは自分もドミネエキスパートっぽいくらいの歴をやってるんで、なんかそういうところのモデリングをエージェントと話してるのはめちゃくちゃ楽しかったですね。
いやーそういうのね、楽しそうだよね。なんかそう卓球結構ね、ずっと長くやってたし追いかけてますよね。そういうやっぱ、なんか好きなものがあるのは強いなって思いますね。
そうですね。なんか考えるところも楽しいし、出てきたアウトプットも見るのも楽しいし、みたいな感じで、なんか一石二鳥みたいな感じでした。
なんか僕あんまりいろんなこと好きだけど、そういうところで自分用のソフトウェアを作るみたいなのをあんまりやってないんだよな。まあ普通に自分の普段の仕事とかその周辺のものを便利にするOSSはたくさん作ってるけどみたいな感じではありますね。
ボーリングとか、後ろにある自転車とか、結構スポーツ関係のやつあると思うんですけど、なんかそういうところの、わかんないですけど、入力とかそういう分析みたいなのってあんまりそこまではって感じなんですか。やれることはみたいな感じ。
なんかそう、そこまで情熱を維持できてるわけではないんですよねっていう、たまになんか見たりして楽しいけどみたいな感じなので、なんかそんなに深くショウさんの卓球みたいなのがあるわけじゃないなっていうのは思いますね。
僕もやってるのはだいぶやってなくて、なんか久しぶりに観戦したら楽しくなってきたんで、めちゃくちゃ再練してみたいな感じなんで、なんとも見えないところではありますけど。
一時期、それこそ永山さんとかやってるけど、ストラバとかそういったものをもっといい感じにみたいなのを最近やってる人はいるなって思うし、それは一時期ちょっと興味あったけど、ちょっとあんまりやらなくなってしまったみたいなのがありますね。
metabolとRSSの情報整理
最後にちょっともうだいぶ話してるけど、僕の新作の話をしていくと、最近メタボルっていうOSSを作りまして、これはどういうものかというと、最近いろんな人がAIにRSSリーダーを作らせてるみたいなのがあると思うんですけど、
僕もそういうリーダーじゃないけど、RSSの新着をまとめてマークダウンにしてくれるみたいな、そういうものを作ったっていう感じです。
いいですね、なんかこの辺みんなそれぞれのやり方で最近のシュットできるようになったところもあるから、それぞれのやり方でいろいろ個性出しながらやってるところが見てて面白いなという感じですね。
同僚もSREの人なんですけど、フロント含めてRSSリーダー作ったりしていて、おもろいなと思いながら見てます。
はい、ババロットさんですよね。これも気になってたんですよ。でもそうそう、家にMac miniがちょっと余ってるんで、余ってるんでというか、そこで動かしてもいいかもなとは思ったりはしたんですけど。
でもババロットさんには、あれババロットさんZプラグ作った方じゃなかったっけ、だと思うんですけど、まだ使ってるんでお世話になってるっていう感じです。
なるほど、そっちを逆に僕は知らなかった説がある。
でも確かにRSSリーダーとか、やっぱり結構状態をSQLiteに持たせるとか、どっかでクローラリングさせるみたいなのをさせるみたいなのが、僕としては面倒くさいなみたいなのがあったから、もうそういう機構はスケジューラーとかは持たせずに、
RSSから新着記事を切り出すツールを作り、URLからマークダウンに変換するツールを作り、それを組み合わせてこういう感じにしたみたいな、割とそういうコンポジション的な作りになっているので、ある意味これはこれで僕っぽいツールになったなっていうのは思ってます。
なるほど、僕はその辺なんかめんどくさいなと思ったんで、スラックでRSSフィールド登録できるじゃないですか、あそこで何のやつが更新されてとかみたいなところのトリガーはお任せにして、新しいのが出てきたら、そこはクロールさせるんですけど、
記録かどうかはスラックのアイコンをつけて、そのアイコンがついてないやつをクロールさせてみたいな感じで、なんかその辺をサボりつつ要約させたりとか、そういうノーエージェントにやらせてみたいな感じでやったりしてて、アプローチがみんな違って面白いみたいな感じで。
そうだよね、そう、記録管理とかやりだすとね、そう大変なんだよなーっていうのはあるので、もう今のところとりあえずバーって取ってきて、サマリーを作って気になったやつをつまみ食いする感じかなっていうのと、あとなんかまあローカルのマークダウンに評価スコアみたいなのを持たせて、それによってある意味好みをキュレーションしてくれるようにゆくゆくはできるといいなーとか思ったりはしています。
これ結構沼ですよね、なんかその検索できるようにしたいみたいなやつとか、そのフェイバリットみたいなやつつけるようにしておすすめとか、その無限に沼要素があるから、いかにそこの沼になりすぎないようにするかみたいな。
そう、そうなんだよね。まあそう、でもまあ割と人間が把握できるテキスト量なんて大した量じゃないから、割とテキスト、ファイルシステムテキストベースでいけるんじゃないの?ぐらいの感じで僕は今考えてるっていう感じです。
なんかめっちゃ大手さん扱いされそうですけど、昔のライブドアリーナーみたいなあのインターフェースはなんか今考えても、情報量を捌くっていう意味ですごく優れたインターフェースだったんだなっていうのをなんか自分で作ろうとすると、なんかあのインターフェースに寄ってくるなみたいな感じになって、あれが優れていたんだなっていうのを痛感させられたりしてますね。
そう、あれは早くてよかったよね。そう、今さ、結構その、まあ、デビンの音声入力とかでやらせたらいいのかもしれないけど、なんか割とその、こう、一件一件AIがなんかこう質問してそれに答えて捌いていくみたいなことはできるんだけど、結構それ、時間かかるなっていう感じがしていて。
なんか具体的には、なんか僕、毎朝その仕事に着手するときに、自分のそのタスクをそのマークダウンで管理してるから、その、今確認したほうがいいやつとか、保留にしてたやつを掘り起こしとか、そういうのをなんか全部AIにあの条件で取れるようにしてるんで、じゃあこれはなんというか、着手しますか、明日まで先延ばしにしますかみたいなのを聞いてもらえるようにしてるんだけど、結構一つ一つのターンラウンドが結構長いなっていう感じがしちゃっていて、
まあそれでも困ってないんだけど、でも確かにその、そう、あのRSSリーダーみたいなやつだともうなんか一瞬で、こうキードボードショートカットで、なんか読んだりスキップしたりできるから、やっぱああいうのは体験としては良かったですよね。
うん。おんこちしん、おんこちしんかわかんないけど、枯れているインターフェースみたいなの良さがありますね。
まあそうですね、まあやっぱ情報収集みんな改めて見直してる感じはすごく感じる、今日この頃ですね、やっぱちょっと溺れちゃいそうになるんでねっていう。
はい、よし、なんかだいぶ長く話したけど、ちゃんと一応話し切れた気がする。なんか話したいこととか宣伝したいこととかないですか。
そうですね、まああの、デビンとGOは良いぞという感じの精錬ができたので良かったんじゃないでしょうかと思っております。
はい、わかりました。まあはい、だいぶいろいろ、はい、お話ができて面白かったです。
はい、ということで、趣味でOSSをやっているものだ、前回今回と翔さんをゲストにいろいろお話をしました。ありがとうございました。
ありがとうございました。
趣味でOSSをやっているものだは、感想やお便りをお待ちしています。
ハッシュタグOSS4ファンでツイッターやブルースカイに投稿していただくか、お便りフォームhttps://oss4.fun/.voiceからお寄せください。
RSS、Listen、Spotifyなどでの購読もよろしくお願いします。
番組を応援されたい方は、コードックでのチップも受け付けていますので、番組ホームページからの支援をぜひご検討ください。
次回もお楽しみに。
01:10:52

コメント

スクロール