エアコンクリーニングの交渉
こんにちは、ninjinkunです。
最近、家賃の値上げが通告されて、その後、周囲の家賃も上がっているのを知っているので、おそらく応じざるを得ないだろうと思っていたのですが、
それにちょっとだけごねまして、結果として、エアコンのクリーニングを無料でやってもらうというのを勝ち取りました。
私、こういう小さい交渉みたいなのが結構好きなんですけど、
ネゴシエーションというほうでもないですけど、
もともとエアコンがついているんですけど、備え付けのものと、自分たちでつけたものが一つずつあって、
備え付けのほうが2007年製で結構古くて、
しかもフィルターの掃除はしているけど、内部のクリーニングはやってこなかったので、
少し酸っぱい臭いが出るみたいな、クリーニングしてないエアコンだったらそうなると思いますけど、
そういう感じになっていて、ここらでお金を払ってクリーニングしなくちゃなと思ったんですけど、
今、我々6年間住んでいますので、おそらく6年間クリーニングされていないと。
クリーニングも昨今1万円以上するんじゃないかなと思うので、どうしようかなと思ったところに値上げの話があったので、
ついでにエアコンのダクトを補強している補強材みたいなのが少し劣化して剥がれてきたりしたので、
これを抱き合わせで言えば何かやってくれるんじゃないかなと思って、
とりあえず値上げに関して契約更新と家賃値上げに関してお問い合わせを送って、
可能であれば、応じるのは矢塚ではないが、可能であればエアコンの交換、もしくはクリーニングをやってくれないかということを、
ついでにここも剥離もありますみたいなのをやったら、
じゃあクリーニングいいですよっていうのは返ってきて、何でも言ってみるものだなという感じですね。
これはどうも他にもGoogleと例えば家賃の値上げに際して更新料を少し下げてもらうとかいろいろテクニックがあるらしいんですけど、
そういうのをやってもいいっちゃいいんですけど、おそらくエアコンのクリーニングとか結構飲みやすい方ですよね。
何でかというと元々管理会社が持っているアセットの方に投資するという方向だから、
我々からもらうお金が少なくなるというよりは多分投資する方がやりやすいですよね。
ですし多分彼らの経費で落とせるしということも考えて、
交換またはクリーニングといったら、交換は出てこなかったんですけど、
本当は交換してもらえば電気代も下がるしもっといいと思うんですけど、今回はクリーニングになりました。
でも家賃値上げは嬉しくないけど、クリーニングが無料になったのはちょっと歩きが嬉しいという話です。
AI技術の進展
それで、最近また自分のAIと自分の仕事のプログラミングの足をしたいんですけど、
自分の高人気仲間のじゅんぼくさんが今週出ていた気まぐれFMの中で、
彼のAIを使ったコーディングとか仕事の仕方がこれだけ変わっていますという話をしていて、
まさに同じことが自分にも起こっていて、
ちょっとずつAIで例えばリストのアプリのコードは結構書いてますとかそういう話をしたんですけど、
ここ数ヶ月でそこは結構だいぶまたガラガラ変わってて、
やってることは基本的にAIに指示を出してコードを書いてもらって、
それを自分で最後は評価してコードベースに統合していくってことはそれは一緒なんですけども、
それの精度みたいなのがだいぶ上がっていて、
特にここ2ヶ月ぐらいで海外を設計しているのがクロードコードっていう、
アンソロピックという、ここももともとOpenAIから分かれた会社ですけど、
LLMのモデルを開発している会社ですね。
ここが出してきたクロードコードってやつが今爆発的に流行っていて、
クロードコード自体はCLI、コマンドラインで黒い画面ですよね、
動くツールなんですけど、
特徴として結構思うのがまずコードの検索、読み込みの精度が高いんですよね。
なのでコードベースをすごい高速なリップグリップっていう、
検索ツールで検索して何でもバババッと取り込んでいくと。
さらにお願いしたことを最後まで粘り強くやってくれる確率が高いっていうのを結構みんな言ってて、
これは私も何とか感じてはいることなんですけど、
オンラインで見たある発言によれば、
他のツールの検索ツールとしては、
オンラインで見たある発言によれば、
他のツール、今まで私もカーソルとか、
キットアポコパイロット、エージェントモードとかそういうツールを使ってきてたんですけど、
それは基本的にLLMのモデルは他社のやつを買ってきてるんで、
そのLLMを使うには別の会社にお金を払ってるんですね、
オープンAIとかアンソロピックとかに。
そうなると、できるだけ使う使用量を減らすってモチベーションが湧くんで、
どこかで探索を断ち切ったりとか、タスクを諦めたりとか、
あるいはちょっと一回ポーズを挟んでくるみたいな、
キットアポコパイロットなんかそういう仕組みが入ってて、
ボタンを押さえて先に進めなかったりするんですけど、
このクロードコードはLLMの開発元自体が作ってますんで、
どうも彼らが多少赤字を掘っても、
ガンガンモデルを使わせる方向に振ってるんじゃないかというのを見て、
なるほどなと思いましたね。
なんで、LLMを使いまくれば使いまくるほど、
というかタスクが終わらなかったら最後まで、
終わるまで回し続けるっていうのが一番何ですかね、
それが一番タスクを完成まで持っていくには必要なことなんですけど、
それを他のプレイヤーは途中でやめるけど、
クロードコードはやめずに、
これがダメなら次の手段っていうのをどんどんやっていくっていうことをするから、
お願いしたことが最後まで終わるっていうのを見て、
なるほどなと思いましたね。
コーディングスタイルの変化
なるほどなと思いましたね。
私も完全に乗り換えてしまって、
クロードコードを使ってますね。
どうも世間ではこれを、
クロードコードのサイトにもあるんですけど、
何並列でも同時に動かすというのが流行っているらしくて、
特にGitWorks3っていう、
我々がファイル管理に使っているGitっていうツールの、
今作業しているブランチっていう、
ディレクトリというか作業スペースを、
いくつも別のディレクトリに展開できるっていう機能があって、
それでいろんなところ、
そのディレクトリに今作業しているコードを分割しておいていって、
その中でそれぞれのクロードを立ち上げて、
それぞれ作業させると、
本当に何並列も同時に作業ができるようになるというので、
なかなか派手しいワークスタイルになってきたなという。
人によっては同じ作業を別々のクロードにやらせて、
それでうまくいった方を取るみたいなことをしている人もいらしく、
なるほどっていうね。
なんで、例文にお願いすると、
同じことを命令しても、
場合によってうまくいったり、
うまくいかなかったりするんで、
そういう確率的な振る舞いをするんだったら、
同時に走らせてみればええやんという発想ですよね。
なかなかそれも凄まじいなという。
それを支えるのも、
クロードコードのプランが、
こういうコーディングエージェント、
ある程度使い放題というか、
ここまでは定額で、
これ以上は重量課金みたいなところが多いんですけど、
クロードコードは、
定額プランを結構推していて、
クロードプロっていう20ドルのプランと、
クロードマックスっていう100ドルと200ドルのプランがあって、
私はプロでやってるんで、
あんまりたくさんは使えないんですけど、
マックスとか、
マックスの100ドルとか200ドルにすると、
もっとこれが大量に使えるようになるんで、
どんどん何並列も動かしても、
大丈夫という感じになるっぽいです。
あと、この使い放題っていうのも、
どういう感じかっていうと、
一応そのレートリミットっていう、
使う上限が決まってて、
5時間のウィンドウになってて、
5時間内で、
その指定のトークンスっていう、
基本的にLLMとやり取りする、
言葉の、
LLM的なカウントの数がトークンなんですけど、
これが指定に達すると、
1回止まりますと。
ただ、5時間経つと、
またその枠が開放されるので使えますっていう、
感じですね。
なので、
大量に作業すると、
一時的には止まることはあるけど、
また時間経つと、
使い放題になるっていう、
そういうモデルになってて、
これが、
アンソロピック社が赤字を掘らずにできてるのかは、
結構謎、多分、
結構赤字掘ってるんじゃないかと思うんですけど、
そういう感じで、
エンジニアでも今喜んでこのモデルを
ジャブジャブ使う開発スタイルに、
適合しようとしてるっていう、
そういう時代になってますね。
これがまさに、
この前、
AIコーディングミートアップっていう、
イベントに行ってみたんですけど、
これは、直前までは、
Grindルーコードっていう、
エディターの中で動く、
LLMを使ってコードを書く、
それの活用事例について話しますって言ったんですけど、
直前でこのクロードコードのトリックが加わって、
参加してみたら、
このイベントの発表時は、
Grindとかルーコードを使ったんですけど、
ここを2回作りまして、
全員クロードコードを何しかしないっていう回になって、
まさにこの業界の移り変わりの速さを感じましたね。
その回の中でも、
皆さんクロードコードをバリバリ使って開発をしていて、
面白かったのは、
結構、
こういうエージェントを使って、
こういうイベントを作って、
こういうイベントを作って、
こういうイベントを作って、
こういうイベントを作って、
こういうエージェントを使ってコーディングしている人たちが、
大量にいるチームでは、
コードを書くこと自体は、
すごい速くなるんだけど、
その後にエンジニアのフローの中では、
コードレビューっていうフローがあって、
書いたコードを同僚に見てもらって、
それをオマージュするっていう作業があるんですけど、
そのコードレビューの方がボトルネックになりつつあるということを聞いて、
なるほどなと思いましたね。
なので、コード自体はAIが大量に書いてくれるけど、
コード自体はAIが大量に書いてくれるけど、
それを見る人間が不足しているっていう、
そこでAIにレビューさせられないかという発想も出てくるんですけど、
まだそこまでは、
コードレビューの重要性
最初のフィルタリングみたいな、
簡単な指摘を消してくるとか、
そういうのはみんな使ってるっぽいし、
私も使ってるんですけど、
本当にこれが例えば事情的にクリティカルなことにならないかとか、
そういうことは人間が担保しないといけないんで、
コードレビューっていくつかいく割あるんですけど、
コードは、
これがいいコードかとか、
将来的にメンテできるかっていう、
そういうコードの品質の担保っていう観点と、
あとは監査的な観点が入っていることがあって、
これは会社の内部統制とか、
そういう組み方というか、
あれにもよるんですけど、
コードレビューをしたことで、
これは人が確認しました。
なので、
そのまま事業的に誰か確認したっていう、
そういうフローを入れなくちゃいけないっていうのが、
どうも私も全然詳しくないんですけど、
そういう内部統制とかも考え方があるらしくて、
そのコードレビューにその役割を負わせてるって会社は、
結構あるっぽいんですよね。
人が基本的には、
これはビジネス的にクリティカルなことになりませんっていうことを、
同時に保証してるっていう側面があるんですけど、
なんで人間がいなくちゃいけないと言えばいけないと。
というので、
引き続きこのコードレビューがボトルネックになっていくっていうのは、
結構続いていくトレンドなんじゃないかなと思うんで、
なかなかアンキコミ深いですね。
そういう話をしているパネルディスカッションがその後であって、
その中で、
T和田さんっていう、
海外では有名な方が、
発言されていて、
そういう時に、
大事になるのは、
振る舞いの変更と構造の変更を、
ちゃんと分けてレビューに出しましょうと。
なので、
振る舞いの変更っていうのは、
さっき言ったビジネス的に影響があったり、
ユーザー体験に影響が出る、
実際のアプリケーションの動きを変える変更のことで、
構造の変更っていうのは、
リファクタリングと呼ばれる、
本当にコードの内部だけをきれいにしたりすること。
それは、
色んなことに対応できるために必要だったり、
推し性を上げたりするために必要なんですけど、
この構造の変更は機械的にレビューしてもよかろうというので、
こういうのはどんどんAIでレビューできるけど、
振る舞いの変更だけは人間が担保しないといけないんで、
ただ、これを同時に出すと、
どうなるかというと、
これを同時に出すと、
どっちも人間が見なくちゃいけないから、
それは非効率ですねということで、
実際に同僚にレビューをお願いする際に、
これは振る舞いの変更です。
けど、構造の変更はほとんど含んでいませんとか、
これは純粋にリファクタリングに特化してますとか、
いうことをちゃんと明示的に書くことによって、
これはAIがレビューできる、
人間がレビューしないといけないってことが分けられるんじゃないかってことを言ってて、
なるほどなというふうに思いましたね。
AIコーディングの進展
という感じで、
コーディングにAIがどんどん入ってくることは、
本当に今年の一大大きなトレンドで、
自分の仕事の仕方ももうガラッと変わっちゃいましたけど、
引き続きこれにキャッチアップしないと、
将来的にも仕事がないだろうし、
でもその先に我々の仕事が果たしてどれで残るかは謎ですが、
でも自分はAIがコードを書いてくれること自体は慣れちゃって、
全然嫌とかそういうのもなくて、
プログラミング自体は楽しかったんですけど、
どっちかっていうと、
どんどんもっと仕様を決めるとかデザインを決めるとか、
そういう方向に集中できるんで、
自分はもともとそっちもやってたから、
プロダクトマネージャーと呼ばれる職能をやったこともあるし、
デザイナーも兼任してたりするし、
むしろそっちに集中できるようになったんで、
コードを書くのが全部自分でやる必要は、
全然その必要性を感じないなっていうので、
AIが作ってきたその機能を自分が使ってみて、
こんなに良くなったわいって喜ぶのは一緒なんで、
自分はあんまここもう抵抗ないなって感じですね。
その分どんどんいろんな変更をアグレッシブに入れたりもできるんで、
だんだん順応してるし、
今ここでAI使えませんって言われたら、
うわってなると思いますね。
それこそ、
漢字だんだん書けなくなってるみたいな感じと同じかもしれないし、
ゼロからコードを書いた経験っていうのがどれだけ生きるのかっていうのは、
また一つわからないところで、
新しく業界に会社に入ってくる人たちが、
AI前提で彼らもコードを書くと思うんですけど、
それたちがガリガリ手動でコードを書いた経験がない人たちが、
どういう風に成長するのかっていうのは、
今後まだわからないと思うんですけど、
手動でコードを書いた経験がない人たちが、
どういう風に成長するのかっていうのは、
今後まだわからないところですよね。
そこでもしかして、
手書きの経験がないとダメだってなるのか、
いやいやもうAIで余裕でしょってなるのか、
自分としては多分手書き、
手動でコードを書いた経験自体は多分言うほど大事じゃなくて、
どっちかというともっと基礎的なコンピューターサイエンスの知識とか、
あとは実際にそれを本番にデプロイして何が起こったかとか、
実際にユーザーのアクセスが集中したらどんな風に落ちるかとか、
そういう方向の運用とか、
人間としてだとどういう風に対応して責任を取っていくのかみたいなことの方が、
大事になりそうだから、
そっちさえ学べれば、
むしろコーディングをAIに任せながら勉強していく方が効率は良いと思いますので、
若い人の成長ってむしろどんどん速くなるんじゃないかなって思うんですよね。
新しい仕事のスタイル
というわけで、また結構長々喋っちゃいましたけど、
最近のAIコーディング、
エージェンティックコーディングって呼んだりね、
AIコーディングって呼んだり、
バイブコーディングって呼んだり、
いろんな流派があるんですけど、
自分はエージェンティックコーディング派かな。
なんでもいいですよね。
という感じで、
でも最近は本業でも結構AIでコードを書き始めてて、
結構そこで変わったのが、
ちょっとまた話しなくなっちゃうけど、
ドキュメントをすごい書くようになったんですよね。
AIは最初の指示をうまく作って、
そこでこれとこれとこれをやって、
この順番でやるとできますよっていうのを指定してあげると、
非常にうまく動くんですけど、
その指示書になるところを最初にAIと一緒に作って、
そこは結構人間として壁打ちしながら作るんですけど、
それを書き出してもらって、
その通りに動いてもらうっていう。
だから今までは自分でいきなりコードを書きながら考えてたことが、
AIにまず壁打ちしてもらいながらドキュメントを作りながら、
事前に考えるっていう風に変わってて、
これはとてもいいなって思いますね。
自分は結構、
深く考えずに作り始めてしまって、
後からめちゃめちゃ脳機というか、
開発時期が伸びてて大変になったっていうことを引き起こしたこともあるんで、
事前にどんどん相談できるようになって、
ドキュメントを作っていくことで、
事前に何が起こるかをすごく深く考えて準備することができるんで、
これはとてもいい仕事のスタイルの変化かなと思いますね。
というわけで、
最近のAIの使い方でした。
ありがとうございました。
