10月の振り返り
こんにちは、エンジニアの三田です。
こんにちは、エンジニアの博崎です。
ゆるテクは、三田と博崎が、緩く技術の話をするポッドキャストです。よろしくお願いします。
よろしくお願いします。
はい、というわけで、久々の収録なんですかね、たぶん。
だったかな。覚えてないですね。
うん、なんかそんな気がする。
はい。
今日はですね、今日収録日結構10月の終わりのほうなんですけれども、
うん。
終わりのほうなので、せっかくだから今日は10月中に、
例えば読んでみた記事で面白いものあったかどうかとか、
なんかこの1ヶ月でこれ系触ってみて面白かったよとかがあったら、
うん。
共有して雑談してみようかなって思ってます。
いいですね、10月振り返り。
はい、10月振り返り。振り返りって言うとちょっと行儀惜しいかもしれないですが。
はい。
はい。
というところで、なんか博多家さんどうですか。
そうですね、何の準備もしてなかったんですが、
10月なんかちょっと世間的には障害とか、
ああ。
我々の業界で言うとね、障害とか。
そうですね。
はい、あと某有名企業とかのランサム被害とかがあったなっていう。
はい。
そうですね。
そういうのが思い出されますかね、はい。
確かに、障害で影響を受けた会社さんもいっぱいいるだろうし、
ランサムウェアを受けてまだ物流が滞っているケースもあるかもしれないしで、
いろいろありましたよね、10月は。
スペックドリブンディベロップメントの紹介
そう、まだ多分解決してないから、今この瞬間も頑張って復旧をされてる方がいらっしゃるでしょう。
はい。
はい、というわけで今日はそこのテーマをお話しに行きたいなと思いつつも、
多分僕らそんなに深く語れるものもないので、
はい。
もうちょっと身近なものでなんか喋れるといいなってちょっと思っていて。
うん。
で、僕からちょっと一個雑に投入するんですけど、
ほうほう。
すごく構成も考えてないから、ほんとこのツール触ってみて面白かったっすっていうレベルの共有なんですけど。
ほう、ツール。
はい、もうここ数年ずっとね、もうみんなAI使って開発しててっていうのは割と当たり前になっていると思っていて。
うん。
で、その中で最近出てきた、最近でもないのかな、割とよく聞くのがスペックドリブンディベロップメント。
うん、SDDはよく見ますね、最近は。
そうそうそう。
うん。
まあ、使用駆動開発みたいな心があるかなと思っていて。
で、その文脈で一個オープンソースのツールで面白いものを紹介してもらったので、この場を借りてまた劇の紹介をしようかなと思ってるんですけど。
ほうほうほう、はい、面白そう。
えっと、スペックワークフローMCPっていう。
スペックワークフローMCP。
はい、オープンソースがあって。
スペックワークフローMCP、はい。
僕も最近、ほんとここ一週間ぐらいで触り始めたんですけど、結構肌感良かったなって思ったので、ちょっとこの場で紹介して、なんかこれを聞いた人はちょっと試しに触ってみるかとかなったらいいなって思ったりしてますと。
ほうほうほう、はいはい。
これを紹介するにあたって、軽く普段、ちなみに自分はこういうふうにAI使って開発してますを紹介させてもらうと、いろんなとこで言われてるように、わりと雑に命令してもさってな方向の実装が出てきちゃうとかってあるじゃないですか。
うん、はいはい。
あったりするし、命令して一気にAIの柄を使ってアウトプットしたものを人間がレビューするのも結構辛みがあったりするしで、そのまま命令するのは僕は結構使ってて辛いんですよ。
はいはいはい。
なので、わりと普段やってることとしては、AIに命令を出す前に、何でもいいんですけど、僕の場合だとGitHub Issue使ってるんですけど、Issueにめちゃめちゃスペック、仕様を詳しく書いてます。
で、その仕様を詳しく書いたものを、クロードコードなり、デビンなり、自分たちが使ってるAIエージェントに読ませて、読ませた上で、実装計画書っていうのを作ってもらってます。いつも。
うんうん。
チェックリスト形式で作ってもらって、まず僕がそれを見て、この感じで実装するんだったらいいんじゃんみたいな。
うんうんうん。
なので、作る前に一旦計画のタイミング、プランのタイミングで人がレビューしてますと。
はいはい。
で、かつ、じゃあこれのプランでいいから作ってねっていう時も、結構これは僕の裸感だけど、ここまでだったら一気に出てきてもレビューできるなっていう線引きをして。
うん。
これはタスク1からタスク4ぐらいまでをまずやってほしいですみたいな。
うん。
のをずっと普段の開発でやっていて、それをやるメリットって早い段階でレビューして方向修正できるっていうのもそうだし、
うん。
あの、一周にスペックが残るので、極論僕じゃない誰かが命令してもある程度同じ結果になるというか。
うんうん。
そういう意味で再現性とか後で、何だろうな、何でこうなってんのを知るために残してるような意図があったりしますと。
はい。
で、ずっとこれをまあ自分で頑張ってたんですけど、これが多分商用になったのがおそらくAWSのキロ。
ですね、はい。
うん。だと思ってて、そこのフローが割とテンプレート化されてスタンダードになってきているんだろうなと思っています。
うん。
で、ただキロの場合だと、やっぱこうね、お金、無料プランの範囲で使うのは難しいし、確かなんか発表直後って抽選じゃないですけど、使えるようになるまでタイムラグがあった気がしてて。
ウェイトリストありましたね、あれ。
あ、そうそうそうそう。ウェイトリストとかもあったんで、まあ割と多分個人が自由にどんどん使っていくには、なかなかこうハードル高い面もあるかなって思ってて。
うんうん。
で、今回紹介しているこのスペックワークフローMCPっていうのは、要はそのキロのオープンソースみたいなやつです。
うんうん。はい、前提が分かりました。
はい。で、まあこれ何してくれんのっていうところでいくと、要は自分のコードリポジトリにコードの実装ルール。
うん。
で、スペックワークフローの、ワークフローMCPの文脈で言うと何だっけ、ステアリング文章、ステアリングファイルっていうのを書くんですけどね。
おお、そう、それをちゃんと分かってないけど、はいはい。
このプロダクトがどういうプロダクトであるか。
うん。
で、このリポジトリがどういう構造であるか。ファイル構造とかデザインの思想であったりとか。
はいはい。
で、あとは技術的な仕様、選択してる言語であったりとか、トレーシング何使ってるとか、そういう技術スタックかな。
はいはいはい。
の3つに分けたマークダウンまでちゃんと書かなきゃいけないんですよ。
あ、それはこっちが書くんですね。
こっちが書く。
うん。
そこの内容自体を一旦AIにリポジトリ分析させて、こういう文脈書いてっていうのが全然できるんで、最初のプロトタイプはそれで書いて、自動的に作ってくれたりもするんで、それでまず書かなきゃいけないですと。
うんうん。
で、それを書いた上で、あとはシンプルにマクロードのMCPと接続させて、こういうことやりたいですってやってくと、実装計画、要件定義から作って、実装計画作ってタスクリスト作って、作り始めてくれるみたいな機能で。
なるほど。はいはい。
で、なんか個人的にちょっと嬉しかったなって思ってるのが、このスペックアクロMCP、実はGUIがありましてですね。
そうなんですか?
そうなんです。
Webですか?
Web、ローカルで起動して操作するダッシュボード機能がついておりまして。
それはローカルで動いてなんかポートナンバーとかでみたいなそういうやつ?
今、僕らが見てるページに貼ったんですけど、なんかこういう感じで看板ボードだったりするんですよ。
多分、思ってる以上に看板ですよね。
そうですね。これ、昨日もこんな感じでしたね。
多分めっちゃインスパイアされてると思う。
されてますね、これきっと。なるほどね。
結構便利だなって思ったのが、ここで作られてるボードとかに対して利用者がレビューしてくるんですよ。
レビュー?
このタスクのここはもっとこうしてほしいみたいなレビューコメントを入れられて、実は。
コメント入れられるんだ。
そのコメントを入れると、じゃあそうしますねっていうふうに、元の仕様の方も合わせて修正してくれるみたいな。
なるほど。
なので、よくある最初に命令を出して作ったプロトタイプを、自分の後はプロンプティングで頑張っていい感じの形にしてくっていうところ。
頑張っていい感じのところにするっていうのを、ちゃんと仕様にもリバースしてくれるというか。
変更される大元というか、元自体はどこにあるんですか?
UIの中のストレージで持ってるのか、リポジトリに書かなきゃいけない?
リポジトリに書かなきゃいけない。
リポジトリに自動的にそういうファイルができます。
できるんですね。
なので究極的に言うと、そこの仕様ファイルをギト管理しとけるんで、今までどういう命令したんだっけとか、
この仕様って何だったっけを全部追えるようになる。
なるほど。
ただ逆に仕様ファイルがすごく増えていくんで、リポジトリ太っていく問題はあるんで、
それはどういうインドでアーカイブした方がいいんだっけとかは、各チームの選択によるところではあると思います。
なるほど。はいはい。
っていうふうにレビューができるっていうのが結構僕的には便利だったっていうところと、
あとはレビューができるってことで気づいた人もいるかもなんですけど、
承認ができるんですよね、最終的にGUI上で。
出てきた内容に対して承認ボタンを押すと、承認されたねって言って、
次のステップに進んでくれるみたいなっていう感じなんで、
結構今までずっと自分が手元で努力作やってたところをスマートに体系化してくれたし、
グラフィカルに表現して今どういう状況なのかパッと見で分かるようにしてくれたっていうところで、
触ってて楽しかったんで、ぜひ紹介しておきたいなって思いました。
いいですね。
オブザーバビリティーカンファレンスの話題
そうなんですよ。
CLIでこれでいきますみたいにチェックリストを作らせてっていうようなことってみんなやってたと思うんですけど、
GUIでできると、それこそエンジニア以外の人もとっつきやすいのかな、やりやすいでしょうしね。
というのはちょっと楽しかったので、紹介でした。
なるほど、試してみよう。
あとは、何かあるとすれば、先日、オブザーバビリティーカンファレンスありましたよね。
ありましたね、月曜かな。
月曜日、何か見ました?
えっとですね、自分は現地参加とかしてないですね。
配信のアーカイブみたいなのがあるのかなとか、資料とかって誰かまとめてくれてるのかなみたいなのをちょっと探してみたんですけど、
まだなんか、今我々がこの収録してる段階ではアーカイブは多分まだ出てなくて、アーカイブが出たら見ようかなぐらいの気持ちでしたね。
なるほどですね。
僕も今回は現地参加じゃなくてオンライン参加させてもらってたんですけど、実はもう午前中にちょっと調子悪くなって遺産しちゃったんで、
もし博多家さんがいろいろ見てたらちょっと話聞いてみたいなって思ったぐらいで話を作りました。
いやー、自分は月曜日はね、子供が体調を崩しててんやまやだったんだよ。
じゃあちょっと資料まとめが出るのを待つか、ちょっと自力でいろいろ資料をちょっと集めてきて自分たち読んでみるぐらいですかね。
そうですね。なんかあればいいけど。
オブザーバビリティの理解
午前中見たやつとかどれですか?それの話してみますか?
はい。どんな話せるかなって感じなんですけど。
僕午前中見たのがLINE Yahoo株式会社の方が発表されてた、
オブザーバビリティが育む開発者のシステム理解と好奇心っていう表を言っていましたね。
その途中からなんかちょっとうーってなって。
大変だ。
なっちゃったんですけど。
この資料は多分最初キーノットがあってすぐの発表だったのかな?
そうです。
とかで資料が上がってたんで、タイトルも興味引かれたんで読んでみましたね。
いいですね。
良かったですね。
ですよね。なんかこう、チームで開発しててたまに思うのは、
モニタリングとかはみんなしっかりするんだけれども、
それをもう一歩オブザーバビリティにしていくというか、
っていうところはやっぱり割と関心ごとの違いからなのか、
この資料で言うとメンタルモデルでしたっけ?
そうですね。
メンタルモデルの違いからなかなか進むのって難しいよなってずっと感じてたんですけども、
そこに対してどういうふうに取り組んでたかとかっていうのが発表されてましたよね。
そうですね。結構良くて、前半の方は問題点みたいなのを前提の共有だったと思ってて、
最近ではあんまり聞かなくなったけど、
開発者の人がダッシュボードを見てくれない問題みたいなのってのはあると思ってて。
でもこの方のいるチームは、開発者の人も運用までやるし、
この方がエンベデスバックから開発の方もやるみたいな感じだから、
それぞれオーバーラップしてるけどもそういう問題がやっぱり起きちゃうみたいなのがあって、
そういうふうになるんだなっていうのは前半読んでて思いましたね。
エンベデスとしてても、そこのギャップがあるって結構やっぱ面白いですよね。
そうですね。あと何だったかな。
環境を整えるみたいな対策をされたっていうのは確か書いてありますね。
すごいなと思ったんですけど、その後、具体的には付加試験を簡単にしたり、
それ自体は難しいけどできるかなということだと思ってるんですけど、
その後ちゃんと使ってもらう工夫みたいなのがちゃんとされてて、
チューニングコンテストみたいな。
その活動をされてましたね。
これすごいなと思って。
これはすごいですよ、マジで。
実際に使う場を作らないと、やっぱりなかなか使ってもらえないから、
こういうの大事なんだよなと思って見てましたね。
チューニングコンテストの後の終了とかにもあったんですけど、
ノリでスラックにパンの絵とか出してチューニングしてみないとかっていう動きめちゃめちゃいいなって思ってて、
成果も分かりやすいし、やった人としても達成感感じるだろうなって思いますよね。
そんなに多分ここで挑戦してみないのノリって言ってるぐらいだから、
そんな激ムズなやつでも多分ないんでしょうしね。
あとこれスラックのスクショがスライドに貼ってあるんですけど、
これいいなと思ってて、
開発の人が実際オグラバビリティツールをこういうふうに使って、
こういう思考でここに問題があるって思うんだなって思考のトレースができてるのがすごいいいなと思いますね。
確かに。それすごい大事ですよね。
その後自分でできるようにもなりますからね、真似して。
チューニングコンテストの実施
この辺どうなんですかね。
例えばある程度見方が分かる人とかだと、
そのグラフ見て、多分こういうことが読み取れるから、
ここどう改善していけばいいんだろうとか打ち手見えたりするじゃないですか。
今って僕曲の読み方よく分かんなくても、
その画面自体をAIに尋ねてみるっていうのも1個手段として可能だと思ってて、
そこまでを自分でやらせた方がいいのか、
ある程度解釈した上で伝えてあげた方がいいのかって、
結構それはあれなんですかね、オブゾバビリティの習熟度というか、
スキル間によってバランスとったほうがいいんですかね。
なんじゃないですかね、やったことがないんで、ただのエアアップのしゃべりですけど、
最初はやっぱりこういうふうにやるってちゃんと教えてあげて、
慣れてきたら普通に自分で完結できるようにするが王道な気がしますけどね。
それがさらに慣れてきたら、
大体みんなそこに対しての共通認識を持てるようになってるから、
エンジニアリングでちょっと自動化してみるとかが面白かったりするんですかね。
そうですね、自然にじゃあこれこれでいいじゃんになって自動化に結びつくんですかね。
うん、になりそうですよね。
そうですね、最後なんかちょっとそしてまたいいこと書いてあって、
正常とは何かみたいなのがちゃんと書いてあって、これ好きだなと思って読みましたね。
これね、はいはい。
グレイスフルディグラデーションか。
ユーザーにとって体験が損なわれなければそれは正常であるっていう風にするっていう感じだと思うんですけど、
単純にエラー率とかだけをSLOにしてもって感じですね。
これ僕すごい良いと思う盤面、難しいところあるなってちょっと思ってて、
ユーザーにとって体験を損なわないようにするっていう風になった時に、
極論では損ないすぎると損なっている状態が正常になりかねないなって思っちゃう。
これはこんなもんだからですか。
そうそう、この画面3秒ぐらいいつもかかるからね、みたいな。
はいはいはい。
そこに対してどう挑戦していくかというか、自分たちで決定しながら数字を決めていくかって結構大変だなって思っちゃいますね。
そうですね、その辺ちゃんと自分が運用したことないんでわかんないですけど、クリティカルユーザージャーニーってあるじゃないですか。
はい。
あれへんの話になるのかなと思っていて、ユーザーがこの画面を通ってこういうことができてっていうようなのをちゃんと合意して定めておくと、
正常と何かが認識が合っていれば大丈夫なんじゃないかなという。
そうか、CUJ上のこの一連のジャーニーの中で、ここの例えば速度感はここを担保しましょうねとか、可用性は支出しましょうねみたいなのを定義すれば、あまりこう無法地帯にはならないか。
単にただここを通ってこれができることだけじゃなくて、もっと深く、それがこうできるとはどういうことかみたいなので、ちゃんと何ミリセック以内にリスポンスが返っているとか、ここの文脈で言うとキャッシュが古くないとか、そういうところまでちゃんと決めてあげると大丈夫なのかなっていう推測。
ユーザー体験の重要性
確かにね、この正常とは何かっていうのを話し合うのがまず大事なんだろうな。
ここまでの、だから気づいてきた関係性あってのこの話ですよね。
確かにね。
それでいくと本当に当たり前かもしれないんですけれども、よくSREとかのユーザーって開発者であるっていう文脈もあったりすると思うんですけど、やっぱりちゃんとシステムを使う最終的なユーザーに対しての理解もちゃんと高くないと、教科書の数字だけ当てはめてもハマらないよねっていうのは間違いないですよね。
間違いないですよね、それね。まともな数字とか設定できないよなって思いますよね。
急に390とかって言われてもみたいなね。
全然文脈によってはそれじゃ足りないってこともあるだろうし、APIとかの種類によってはそれ別にやりすぎとかっていうこともあるだろうしね。
最初のほうのセッションだけ見れて資料共有できたっていうところなんですけど、他の資料とかも出てきたらとか、実際出てきてる人もいると思うんですけれども、見つかったら読んでみてこれ面白かったねとかまた収録なのか雑談なのかでできるといいなとは思ってます。
そのタイミングによって収録するかもしれないしないかもしれない。
そうですね。ちょうどなんかキリもいいので、今回は何だこれは。
10月のいろいろ。
10月の出来事について話しました。感想などは、はしゆるテクをつけて投稿するかMixi2のコミュニティまでお願いします。
今日はありがとうございました。
ありがとうございました。
