1. Yokohama North AM
  2. ep 156 @blue_goheimochi プレ..
2025-08-15 38:44

ep 156 @blue_goheimochi プレゼンツ!設計ナイト2025大解説!

Chapters

0:16 ポッドキャストの始まり

3:40 エアコンとプロジェクトマネジメント

6:24 設計ナイトの思い出

9:51 ワントラックの魅力

13:59 誰のための設計

19:13 ecspressoの設計思想

27:17 ADRの利活用

30:15 AIエージェント開発の設計

37:04 終わりの挨拶

サマリー

このエピソードでは、Yokohama North AMが特別ゲストの青郷英文さんを迎え、設計ナイト2025について詳しく解説しています。参加者の体験やイベントの構成に関する討論を通じて、技術コミュニティにとって重要な話題に焦点を当てています。AIを活用した設計方法やイベントに関する提案が取り上げられ、CQRS ESのカンファレンスやエスプレッソに関連する設計思想についても深く掘り下げられています。また、マルチファラダイムデザインおよびADRの利活用の観点からの考察が行われ、AIエージェントの開発についても触れられています。このエピソードは、設計ナイト2025の内容に焦点を当て、システム化やプロダクト開発における成功の要因について議論が交わされています。特に、ワークフローの整備や実際のテストマーケットの重要性が強調されています。

ゲストの紹介と近況
こんばんは、Yokohama North AM第156回です。Yokohama North AMは、ウェブ系エンジニアがテック系のキーワードをネタにして雑談をするボットキャストです。
ホスト役は、自称PHPRのハンハン1978です。本日の相手はいつもの金城さんと、なんと、青郷英文さんです。よろしくお願いします。
よろしくお願いします。よろしくお願いします。
ではあの、まずはゲスト紹介ですかね。金城さんはもう早くゲストとは言えない感じなんで、じゃあ郷英文さんの紹介をしますと、青郷英文さんですかね。
他に、なんて紹介すればいいんだ。オイラジオのメインパーソナリティの一人。何をフィーチャーしてご紹介すればいいのか、最初に準備しておけばよかったって今公開してます。
大丈夫です。それで。
それで大丈夫ですか。
はい。よろしくお願いします。
本日はオイラジオのメインパーソナリティとして。
コラボ会みたいな言い方。
コラボ会ですね。片側だけのコラボ。片側だけのコラボじゃない。こんなものはないかもしれない。
であの、郷英文さんにゲスト久しぶりで開拓していただいてありがとうございました。最近はいかがお過ごしですか。
最近はそうですね、わりと忙しくしてはいるなっていう感じがあって。
素晴らしい。
ちょっとマネジメントっぽいことをかじり始めてるので、やること変わりつつあるみたいなところで。
ラーニングゾーンとパニックゾーンの近くなったり引いてきたりみたいなのをやってて、たまに辛いなとか思ったり、楽になったなと思ったりっていうのを繰り返してるのが最近です。
じゃあ、今青春してるってことですね。
青春してるかもしれないです。へこんだり、ろこんだりしてます。
へこむといいですよね。やってるときは辛いんですけど。
そうですね。でも成長ってこうやってしてきたかみたいな気にはなってるんで、とりあえずやるかみたいな気にはなってます。
わかるな。じゃあそんな大変な辛い時とかってどうやって気を紛らわしたりしてるんですか。
最近やってたのはやっぱちょっとGPTにメンタルケアしてもらうってやってましたね。
すごい励ましてくれるんで。
なおい。
すごい励ましてくれるんですよ。励ましてくれるというか肯定してくれる感がすごいあります。
あれでもなんか最近寄り添わなくなったとか、話題の。
過度に寄り添ってた、もうやめたみたいなの僕もなんか見た気がしますね。
まあでもギャルクチョーはちょっと前にやめてくれたんで、それはすごい気に入ってますね。
めっちゃ何々とかって言ってくんでやめてくれたんで。
その人の見たことないんで。
僕も見たことないっすね。なんだろう。なんか言ったんですか。
うちのGPTちゃんめっちゃ何々言ってたんで。分かるとかって。分かるじゃねえこの野郎と思って。
なるほどなるほど。気になるキンジョウさんはエアコンは大丈夫ですか。
エアコンは最近涼しくなったんで勝ったなって思ってます。
これはあれですかね。PM視点で考えると青岡英文さんどのようにお考えですか。
PM視点。なんだそれ。
エアコンが壊れたまま気温が下がってきたからもう大丈夫ですっていう答えがメンバーから来ました。
あーなるほど。組織が壊れててもリリースまでいければプロジェクトマネジメントできるいいんじゃないですか。
良かったんでしたっけ。
プロジェクトはぶっ壊れない方がいいですね。ワインバーグの方にも同じこと書いてありましたね。壊れない方がいいみたいな。
本当にそう思います。トムデマロコも言ってましたね。リスクは取りたいが体を壊したくなさそうなことがいろいろ書いてあった気がする。
本当にここから気温が上がんないのとかは聞いた方が良さそう。
昨日の天気を見なさいってプロジェクトマネジメントでよく言いますけど、明日の天気も気にしないとダメなんですね。
今日割と本当に心配してるんですよ。9月とか油断するとめっちゃ暑いじゃないですか。
今週末がもうすでにまた暑いらしいですね。困っちゃいましたね。
今年の秋とか冬とかの換算期にはちゃんとエアコンの修理が行われない場合は俺もう送りつけますよ。
家ですか?マンションを?
そうマンションを送りつけます。
本たくさん置こう。
いやもう本当気になって気になって眠れないんで。
僕一人の時そこまでこの話を掘り下げないから、今日は仲間がいるからいけるぞみたいな雰囲気。
そうそうそうそう。このまま押し切っていきたいです。ここはパワープレイで。
ここまでいけるか試してほしいかもな。
やめてください。いけなかった時は終わりなんですけど。
まあそれはそう。生き残れば勝ちみたいなゲームなんで。
おかしいな。技術の話してる時はもうちょっとバランスの良い意見が出てくるはずなのに。
なぜエアコンの話になるとパワープレイするの?
確かに。不思議ですね。確証バイアス、生存バイアス、正常性バイアスですね。生きてるしなみたいな。
あの洪水のニュースの時に胸まであの水に浸かって大丈夫だよって言ってるおじさんの映像が流れた時に
すごいこれ正常性バイアスだと思って見てたんですけど。
いやー良くないですね。良くない話題ですね。
はい、いや、はい。そうなんです。
設計ナイト2025の体験
なんで、じゃあ今回はここで一旦区切って、今日のメイントピック、大メイントピックに入りたいと思うんですが。
今回なぜゴヘイモシさんを急にゲストに、半ば強引に呼んだかというとですね。
去る何月だったの?設計内と。
2月の25日ですね。
で、近所さんはテックラーメンで、私はちょっとプライベートの用事があって、どうしても参加できないっていうことで、
泣く泣くキャンセルしたんですが、なんとゴヘイモシさんは行っていたという話なんで、ぜひ今日は設計内との自慢話を我々にしていただこうということで、
いろいろ聞いていきたいんですが、どうでしたか?
めっちゃ良かったですね。
やっぱり、どうしても良さそうだなって思いましたよ。何がどう転んだって良さそうだなって。
平日の夜だったんですっけ?
そうです、金曜日の夜でした。
そうですよね。
良くなかったことを先に一つ挙げとくとすると、ちょっと自分の家から遠いんで、すぐ帰らなきゃいけなかったみたいなのがあるぐらい。
終わった後にすぐ帰る。
それは一泊すればよかったみたいな話。
確かにすごい鋭いな、そういう解決策を取れるな。
どこでやってたの?あ、そっか、吉祥寺でやってたのか。
そうですね。
そうですよね。気持ちはでも分かるな。あ、そっか、武蔵野公会堂だったんだ。
もう目に浮かんじゃいました。
この会場でこう話聞くの良いなって。去年の大吉祥寺PMが初めてだったんですけど、僕は武蔵野公会堂行くの。
2回目だったと思うんですけど、やっぱ聞きやすいという。良い会場なんだよなってすごい思います。
会場良いですよね、あそこ。
壇上の人の話を聞くことに全振りしてる設備ですからね、あそこ。すごいですよね。
階段上だし。
Mテーブル見てるんですけど、なんかめちゃくちゃな密度ですね。これを平日の夜にやるのかっていうぐらいの。
終わりの時間もなかなか深くてやっぱびっくりするぐらい、なんかこう深い時間に終わった感じがしてます。
21時40分クロージングか。あ、まあ吉祥寺だったら別に飲み屋さんとかあるのか。
それは確かにありそう。平日の夜に仕事終わってこの分量の話聞くっていうのはなかなかだなと思います。
ね。
楽しいんですよ、めちゃめちゃ。
脳みそがパンクしちゃいそうですね。
ワントラックだもんね、武蔵野公会堂ね。
そうですね。
やっぱなんかマルチトラックの勉強会が増えたじゃないですか、勉強会というかカンファレンスが。
ここに来て改めてやっぱワントラックってめっちゃいいなって思いますね。
すごい集中できて。
みんなが同じ話を聞いていて。
そうそうそうそうそう。
空間も内容も共有できて、感想を選しやすいしみたいなのはありそう思います。
そしたら感想をじゃあタイムテーブルに沿って要約を聞かせていただきたいんですけど。
すごい、ワントラックだから全部聞いてたよなって言って。
そうそうそうそう。
だから15分であたかも僕と金城さんが行ってきたかのような状態にしていただくことが今日のゴーヘムスターのゴール。
僕のポットキャストなの。
全部で1、2、3、4、5、トークとLTが3本あったんですけど。
LTは外部公開しないような内容のLTだったんで、たぶん資料とかの公開ないんじゃないか。
ちょっと調べたんですけど。見つけられなかった。
LTに関しては何もなかったっていうふうにネタ上に書かれているのは何もなかったということにしないということですね。
僕も記憶飛んでます。
はい、いいと思います。記憶は飛ばしていかないとやっぱり安心してそういう話ができなくなっちゃうから苦労するんじゃないですか。
なるほどなるほど。
じゃあメイントークについてガンガン聞いていきたいんですけど、どうですか米久保さん。誰のための設計。
これめちゃめちゃ良かったですね。
元ネタが誰のためのデザインっていう本らしいんですけど。
はいはいはいはい、ありますね。
発見可能性っていうキーワードに僕は惹かれて知らなかったなと思ったのと。
アフォーダンスっていうのが1つ要素に入ってるんですけど、それを含めた5つのアフォーダンス、シグニファイア、制約、対応付け、フィードバックの5つから発見可能性ってなるんだよみたいな話。
アフォーダンスはなんとなく大学の授業でやったみたいな記憶があって、すごい言葉的にも覚えてたんですけど、それ以外の5つの原理が強調して、そういう発見可能性って生まれるんだなみたいなのが割としっくり入ってきた気がするので、すごい良かったなと思って。
ソフトウェアそのものもそういう発見可能性を込めたソフトウェアにするみたいなのがやっぱ大事だよなって思ったのがすごい良かったなと思ってます。
なるほど、良さそう。どう考えてもこの本を買って僕は読んでるはずなんですけど、何も覚えてないっていう問題点があらわになってます。
これ買うんだったらあれですね、第2番かな、新しい本を買ったほうが良くて、アフォーダンスの定義が変わってるんで、増改定版のほうが良いです。
そうなんですね、詳しいじゃないですか。もしかしてアフォーダンスのプロですか。
これはあれですね、つんどくを消化するポッドキャストで読んだ本なんで。
なるほどなるほど。
強制されてたんですね。
そうです。
僕もそのタイミングでアフォーダンスってなんだっけなって調べた時に心理学におけるアフォーダンスとデザインにおけるアフォーダンスの違いっていうことが書いてある記事が出てきて、
第1版が出た後にノーマンさんが、著者の方がアフォーダンスの定義間違ってたって言ったみたいなことが書いてあるんですけど、
多分第2版にそういうのが反映されてるのかなって感じな気はしてます。
だから昔のやつシグニファイアって言葉が出てこなかったとかじゃないかな、確か。
アフォーダンスをシグニファイアって言い換えるようにしたみたいな感じだからそういうことなのかもしれないな。
そうですねそうですね。
しまった、反省してしまった。何も覚えてないGPUに対して反省してしまったけど、
発見可能にしてあげること、要は、これって結局APIOSDとかと一緒なのか複雑度を下げるとか、
一貫性を意識するとか、使いやすくしてあげるみたいなところに通じるのかな。
Gitなんちゃらなんちゃらっていうメソッドでセットするんじゃないみたいなそういう。
あー俺それ、そのコードを会社で見つけたときにコメント残しておきました。
Gitなんとかで実はセットしてますってコメント上に書いておきました。
そういうことか、レビューコメントかと思ったら、なるほど。
もともと存在してたコードで、もう書いた人ももちろんいないっていう。
いいですね、発見可能性が。
発見可能性を上げておきました。
気をつけろ、このGitはセットしているみたいなこと書いたはず。
全読の雑誌も聞こう。聞いてないなって思いました。
すごい。
長いんでね。
で、じゃあ誰のための設計はかなりもう、ほぼ聞いたと同様の感じになったんで、次に行きましょう。
よしよし。
これならこなせそうだって思いました。
AI時代のイベント設計
で、次が竹澤さんですね。
竹澤さんの話って、なぜAI時代にイベントを中心に考えるのかっていうお話だったんですけど、
だいたい3年後ぐらいに理解できるってバイアスが僕にあって、竹澤さんの話って。
なるほど。
っていうのがあるんですけど、でも今回はこう、割とこう、近づいてきたのか、ちょっとよくわかんないですけど、理解できた部分もあるかもって思ってるんですけど。
なるほど。
なんか従来はこう、イベントっていう考え方が抜けるような設計がはびこっていたみたいな、多分話を最初にされていて、ほとんどが現在の状況しかわからないみたいな感じなので、
AIを使うっていう文脈でこう、なぜが説明できないっていう話をされていて、それはすごいなるほどなっていうふうに思って、
だからイベントを中心に設定考えるというのではっていう提言っぽいことを言ってるのかなと思っています。
で、やっぱり事実が残ってる方が、AIが判断するに足る情報が多いっていうのはすごい納得感があるので、
今の時代だからこそ残す、経緯とか、なぜみたいなのを理解してもらわないといいアウトプット出してもらえないよなみたいなのがある気がする。
だからこそCQRS ESをやりましょうっていうことを言ってたんですけど、これは完全に宣伝っぽくて、福岡で来年やるCQRS ES カンファレンスがあるっていうのが最後についてたので。
エスプレッソ設計思想の探求
これだけでカンファレンスできるんだ。すごいな。
これはあれ今年、去年のいつだったかな。たぶん第一回をやってるんです。やってるカンファレンスだと思う。
PHP カンファレンスの前日だったみたいな時にやってたんで、それの第二回っぽいのがたぶん福岡でやるみたいな話だったんですけど、
とはいえイベントとして事実がどういう流れで発生したかっていうのが分かることにより、AIリーダブルになるというか、AIが解釈しやすい形になるのかなっていう印象を今のところは受けてます。
AIを絡めることで説得しようとしてくるような、なんとなくの流れを感じます。
互換を頑張って埋めてくれるのかなとか思うんだけどな、AIが。
そうなんですかね。イベントサーチングとかって結局儲かったサービスでデータのリファクタリング、データ別のリファクタリングみたいな考えが出てきたときに、
これへんが訴状に上がるんですけど、やはり辛いから無理だみたいなところにたぶん落ち着きがちだと思ってて、
たぶん初期の時点で内部にこれを意識して設計する人がいないと、ここに繋がるような形にできないんじゃないかなっていう気はしない。
だからこそ啓蒙してるのかもしれない。
確かに。
データ量の問題とかも出そうだしな。ちょっと僕もなんか業務で試せずなくて、あんまり経験値が溜まってないんですよね。
手元でちょっと試すぐらいはやってるんですけど。
よくわかってないところがあります。よっぽどイベント量が多い方が生きるような気もしないでもないですし。
ここに出てきて、データのサイジングとかそこらへんってどういうふうに考えたらいいのかとか、
それこそイベントが山のようにできるようなシステムってあると思うんで、
そうすると何兆とかになったときにそもそも捌けんのみたいな話とか。
自分がアーキテクトって考えると、無理でしたと後では言えないから。
そうすると打算的にデータベースを選択するみたいな話は普通にありそうだ。
なるほど。ふんわり理解しました。
残る時間も少なくなってきたので、ガンガン行きましょう。
これが藤原さんですね。
この話はめちゃめちゃよくて、エスプレッソの設計思想に至る道っていうタイトルではあったんですけど、
エスプレッソの話、ECSのデプロイツールって言えばいいのかの話だったんですけど、
経験から滲み出た設計感みたいなのがすごい感じて、すごいなって思いました。
めっちゃ語彙がないんですけど。
いいんです。語彙がないほど良かったということが分かったということで。
ハンドブック、エスプレッソハンドブックっていうやつに藤原さんが書かれてるんですけど、設計思想は書いてあるんですけど実は後出しですっていう話がされていて、
その元にあったのが、プロジェクトをやった時にMSPさんとの分業による責任分解店を作った時に、
藤原さんたちは、ECSを好きにしたい、それ以外は任せたいみたいなところの最初の分解店の作り方があって、
それがあったんで、そのエスプレッソがまずできたみたいな。
そういう最初にこうしたいみたいなところが、そもそも設計のモットーになっていたというか、それが設計だったみたいな感じで後から気づくみたいなイメージなのかなって思うんですけど、
そういうのが勘ではないと思うんですけど、こう出てきて使われるものになってるみたいなのはすごい。
どこで切るかを決めることが大事っていう風なお話だったんですけど、そういう切る勘どころみたいなのが鋭いというか、すごいなっていうのがあるなっていうふうに思っています。
この時々に応じた適切な見極めが必要って話はしていて、今のエスプレッソが剥く組織、剥かない組織がありますよねって話とか、
どっかのタイミングで多分使わなくなるのかとか、別のやり方になるのかっていうところは、
どこで切るかの見直すタイミングとかが現れてくるのかなっていう風に一旦受け止めているってところがあります。
このエスプレッソが剥く組織、剥かない組織っていうスライドがあるんですけど、
剥いているのところを見て、まさに今うちの会社でもエスプレッソのことをみんなで考えていて、すごくうちには剥いてるねとかって思ってて、
これやるとアプリのデプロイとインフラの変更が分離して扱えるっていうのがまさにモトストライクではまるんで、
これするとアプリのチームがECSを本当にかなり自由にできるし、
アプリケーションのコンテナとかの差し替えとかも自分たちである程度自由にできるが、
インフラインフラで土管を整えるみたいな役割にちゃんと分業してできるんで、すごくいいなと思ってて。
いや、いいですね。最後の言葉がいいですねでいいのかな。まあいいか。
いいのではないでしょうか。
いいですね。結局現場で課題を解決するために生まれたっていうものが他にも適応できてて、みんなにも刺さるっていうのはそれはそうなのかもしれない。素晴らしい話。
ADRの利活用とAIエージェント
では次です。マルチファラダイムデザインという単語が出てきたんでこれは末波さんですね。
そうです。さすが。可変性を制する設計構造と振る舞いから考える概念モデリングとその実装っていうお話でした。
で、そうなんですよ。マルチファラダイムデザインの話だったんで。若干読書を挫折してるんでうってなってみながら聞いてたんですけど。
ちょっとこの辺からボリュームが多くて、ちょっと疲れてきてたんだなみたいな感じで今考えてもなってるんですけど。
とはいえ発表の中でスライドの中にコメントはなかったんですけど、外部から振る舞いを変える要素がないみたいなところが印象だったなってすごい思っていて。
そういうところを見つけて留めておくみたいな一つ大事なところだったりとか、可変性っていうのをなるべく少なくするみたいなのを設計するにあたってまず考えていいところだなっていうのと、
そうじゃない部分をどこに押し込めるのかみたいなのってついにあるのかなっていうのをぼんやり考えているみたいなところが今のところあるんですが、
ちょっとあんまり消化できてない感がこれはあります。
スキンさんはマルチパラダイブデザインはどうですか。
私ですか。
はい。
1,2回ぐらい読んでるんですけど、たぶんあと10回ぐらい読んだほうがいいんだろうなって定期的に思う本の一冊です。
そうですね。僕も同じような気持ちですね。日本語で1回読んで、分かんないのはこれは訳されたからじゃないかと思って一応原文でも読んでみて、
分からないのは訳されたからではなかったってことに。で、もう1回日本語で読んで、最終的にあれだなって言って、
俺たちが言ってるハウってやつはソリューションドメインってことだなみたいな。
ここは一応重要な要素だけど、ここに越しすぎることなくビジネスとかを考えたほうがいいよみたいなかなりふわっとした理解で、
僕の中でのマルチパラダイムデザインは完結ということになってます。
だから、ソリューションドメインで物事を考えないほうがいいよみたいなところは僕はマルチパラダイムデザインから学んだかなと思ってます。
データベースがこうだからとか、うちのシステムがこうだからって言って、仕様に対して変更を要請しようとするタイミングがたまにあるんだけど、
誰とは言わずいろんな方々から。エンジニアはそれしがちなんですけど、そうじゃねえだろうと思って。
達成したいほうは課題を解決することであって、今のシステムがどうなってるからこうしかできないっていうのは最初で考えちゃダメだよねみたいなところはマルチパラダイムデザインから学んだのかなというふうに勝手に思っている。
だからきっとそれに近い話なんだろうという思い込みです。
確かにボリュームがいつも多いんですよねすごいね。
あーでもバインディングタイムの種類とか書いてあるからマルチパラダイムデザインによく出てくる話とかに似てるな。
一個がすごいですね。誰がいつバインドするのか考えようって書いてある。
そうっすね。
なるほどね。でもなんとなく薄らわかりました。なのでほぼ聞いたと同じになりました。
ここまででもうあれですね。
どうぞどうぞ。
ジェネレーティブプログラミングも読まないといけないですね。
ジェネレーティブプログラミングって嫌に分厚いやつじゃなかったでしたっけ。
そうなんだ。
下手したら家に刺さってる可能性が。
家で見かけたことがある。怖いから近づくのやめようと思って近づいてない。
776ページって書いてある。怖いですね。
よくないですね。仮に1ページ1秒でめくったとしても700秒だから10分かかるってことですね。大変です。
確かに。
僕は小学校で算数学んだんで計算できちゃうんですよ。
ごめんな。
じゃあ次に行きましょう。ここは僕もADRにはいろいろ意見があるんで理解できそうなタイトルだなと思ってました。
ADR運用におけるデータ利活用の考え方。どうでした?
ADRとこれDIKWっていうのかちょっとわからないですけど。
これ何て読むんだろう。
データインフォーメーションアレッジリズダムの頭文字っぽいんですけど。
このDIKWっていう概念でデータを知識にするための段階を表すフレームワークっていう感じなのかな。
ちょっとそういうふうに捉えてるんですけど。知識ピラミッドっていう風にも言うらしいという感じなんですけど。
ADRを書いただけにしないようにしようっていうのが多分主題なのかなっていうふうに思っていて。
変える知識にしていくには工夫が必要だよねっていうところだろうなと思ってるんですけど。
それにDIKWっていうフレームワークをはめるとこうだよねっていうのが説明させてくれていたみたいな発表になっているかなと思っています。
なかなかでもあんまり利活用的なところって意識してないな。ADRの。
っていうふうに思ったので、知識として有効活用できるようにしていく方向を考えたときに、どうやっていくのがいいだろうかっていうのはちょっとなんかまだぼんやりしてるなっていうのが自分の中であります。
なるほど。でもなんかすごいちょっとドキドキする話ですね。うちもなんかADRいっぱい増えてきたんで。
それをさらに利用して頭が良い感じを醸し出せるのだとしたらいいかもしれないなと。
醸し出すための考え方なのかなと。データで終わらせないためにっていう話なのかな。
どうしたらいいんだ。
DIKWピラミッド。ペーパーバッグ11600円っていう本が出てきました。ここで勢いで買うと痛い目が見えるからやめようかな。
高い本ばっか出てくるイベントですね。すごいですね。
やばいですね。DIKW。2021年エディション。ペーパーバッグ。これ何ページなの。316ページで1万円なんで。1ページあたり。そういう考えは良くない。
じゃあ安いか。
ショータイトルしか書いてないページとか絶対あるんでね。
この間勢いでとある本を買ったんですけど、マジで全部僕自身みたいなひどい本で1万円以上したんで、金返せって思って。
レビュー見たらひどい本だって書いてあったんで、先にレビューを読むべきだったと思います。
ちょっと話がずれましたけど、ADRをさらに利活用しようという話ですね。
これすごいですね。スライド見ましたけどちょっとドキドキするような提案で面白いなと思いました。
しないに越したことはないだろうなとはやっぱ思うんで。
そうですね。
晒せないようにするにはみたいな。
確かに。
ものに近いのかなっていう風には。
晒せたくない。
そうですね。
そしてなんとLTはなかったことになったんで、次が最後。
NAUIやつですね。AIエージェント開発を支える設計ということで。
そうですね。これが、なんていうサービスだったっけな。
営業支援ツールみたいなのを開発されてる会社さんのお話だったんですけど、
これはなんかそのAIエージェントっていうところに惹かれるんですけど、どっちかっていうと僕は正しくシステム化しているみたいなところに惹かれたところがあって、
人間がどう頑張っても無理な部分だけシステムとして実装するみたいなところから始めてってる、徐々に変えてってるみたいなアプローチから始まってるのがすごい素晴らしいなっていう風に思いながら聞いてます。
プロダクト開発の成功要因
最初はシステム化できない部分は自分たちで手動オペレーションしてたとか、泥臭い部分から始まってたりとか、ポックだから作り込まないようにしましたとかそういうところがあったりとかっていうのが、
なんかいいプロダクト作りしてそうだなっていう印象をすごい受けて、意識ってすごかったんだろうなっていうふうに思ったのと、
あとは本人がドメインエキスパートだったっていうのはやっぱ強いのかなっていうふうに思っていて、
いって成功しているワークフローをシステムに起こすみたいなところだったところも一つ、成功した要因に含まれそうな気がしてるんですけど、
そういう状態までワークフローを整えてたみたいなところがやっぱそもそも強かったのかなっていうふうに思っているところがあります。
で、ステップオフごとに、どこかのタイミングで人間がパンクしたので、
システム化しましたみたいな。人間がパンクしたっていうか、人間が処理することができないぐらいになったみたいなことがあったんで、
あそこにボトルネックが移動したってことなのかなっていうふうに思ったんですけど、そういうところを直したって書いてあって、
そこの回はスプレッドシートが複雑化しただけで事なきを得たって書いてあったんで、
これはそれでちょっと趣があるなみたいな話を聞きながら聞いたんですけど、
でも成長の過程としては、すごい正しいステップを踏んでそうみたいな感じの印象を受けて、すごい良かったなって感じがします。
素晴らしい。これいい話じゃないですか。だからAIエージェントっていうタイトルに騙されたためで、開発を支えた設計とは何かみたいな、
そういうもうちょっと抽象的な話と捉えたほうがいいってことですね。
そういう捉え方で聞いてたかなって僕は思ってます。
すごい素晴らしい。ポック作り込みってもうまじでダメなシステムナンバーワンみたいな話になりますよね。
これいらなくないですかとかっていうところにすごい固執する人がいるプロジェクトとか開発ってだいたいダメになるなっていう気がします。
身に覚えしかないので。難しいですね。
テストマーケットとか結局ガンガンして現実を知るっていうのが大事だから、
個人のこだわりみたいなのがそのテストマーケットで試せる範囲だったらともかく、そうじゃないんだったら一旦やめとこうよっていう意思決定がガンガンできるときっといいんですよね。
そうですね。どんだけ作らないかみたいなの、割と大事だなって思うときありますね。
思いますね。作ってるときに机上で考えてると絶対必要だって思うやつが、
試してみるとマジで誰からも求められてなかったってときすごいあるじゃないですか。
ああいうのいいですよね。ああいう経験すると。
自分が一番当てにならないというか、そんな感覚にもなるというか。
それでそうやって作ったものって、すごい範囲の少ない人は使ってるみたいな感じになって、気軽に削除できないとかそうなるんで。
わかるわかる。すげえわかる。今なんか過去のいろいろが口出しになって、それにダメージが。
でもたまには指しに行かなきゃいけないというか、リスクをとってそういうのを作って当てなきゃいけないみたいなのがある気がするんで。
バランス感覚が難しいよなと思います。
難しいですよね。ここ上手な人っていますよね、でも。
設計ナイトの感想
分かります。
いつも結構当たるみたいな人がいらっしゃって。どんな機能作らせても。そういうバランス感覚が優れてるんだろうなと思いながら見てます。
なんかでもさっきの藤原さんのエスプレッソの話もちょっと近いというか、自分たちが使いたいもの以上のことをやらないぞみたいなのが結局めちゃくちゃ深く刺さってる的な世界観でちょっと似た香りがしますね。
結局、使われるとか自分が積極的に使いたい気持ちになるっていう需要をまず満たさなきゃいけないっていうところがありますもんね。
すごい大切ですね。
藤原さんのやつは一回なんか同じような思想でやったけどしか返したみたいなのが書いてあった。
違うか。
違った。
似たような形でやったことがあったがそれがうまくいかなかったのでECS上を全部スキンしたいでした。
あのでも、経験があるとどこに責任分解点を引けばいいっていうのがわかるからっていう意味で、その失敗はきっとこの成功のためにあったんだって話なんですよね。
そうです。そういうのがありそうな気がします。
そうです。ものすごいわかる。わかりみしかない。だから結局やるっていうのが大事なんだ。だけの話なんですけど。
本当にそうです。やってダメだったらこう変えるっていう。
変える。固執しすぎないみたいな。
いや、すごい設計ナイトに行った気になってきました、今。武蔵野航海道の匂いがしてきました。
よかった。よかったです。
どうですか?金城さんはどうですか?
いやー、完全にお得な時間でしたね、今。
いやー、よかったですよね。設計ナイトよかったって、俺一緒に行ってきた気持ちになってきました。
終電早くて早く帰りましたねっていう偽の記憶が今、体の中に。
確かに。ちょっと仕事早めに切り上げた気がしてきた。
うん、気がしてきましたね。僕もしてきました。
5時くらいからそわそわして、6時くらいに終わらせて。
来年もあるといいですね、つってね。七条寺駅でじゃあお疲れ様でした、つって別れてくる感じが今湧き上がってきたんで。
すごいなー、なんか一個一個がキーノートみたいな。
ね。
七条寺の発表ばっかですね。
いやー、本当に。
素晴らしい。
見応えしかないみたいな感じでしたね、本当に。
うん。しかもワントラックだから、なんか逃げらんないですもんね、次の発表がすごい。
いやー、もうでもね、ホントね、ワントラックにして逃げさせないほうがいいと思いますよ。
ちょっと難しいと逃げたくなっちゃうから、きっとみんな。
ここしかないんだってね、状態にしてバインドしたほうがいいですよ、ガッて噛んだほうが。
バインドをさっき覚えた言葉ですか。
そうですね、バインド、でもバインド単体で使うとなんか、ネームサーバーとかそっちゲーの話がなんとなく。
ゲームだと敵を拘束する何かだったりしますね。
最近ちょっとゲームでやりすぎて脳がおかしくなってるんで。
なんでここまでいい話がすごい続いたんで、ここまでちょっとさらっと一回終わらせておきましょうということで、一旦仕切りますね。
で、今週も放送を聞いただきありがとうございます。番組のフィードバックや要望は、ハッシュタグ横浜のせいもつけてエクスポストしてください。
本日の相手は金城さんと青郷平持さんでした。ありがとうございました。
ありがとうございました。
ありがとうございました。
38:44

コメント

スクロール