YOKOTA Takehiko

北欧神話好き ／ 株式会社ディー・エヌ・エーに所属

[Takuto Wada @t_wada]

一時的な資料なので、生成した HTML をリポジトリに保存する必要はありません。保存は Markdown が良いでしょう。人間の認知負荷を下げるために、ビューとして HTML を活用するということです。

[YOKOTA Takehiko @i_am_skirnir]

これ、やってみよう。

[mizutani @m_mizutani]

AI出力をmarkdownじゃなくHTMLにしたほうが良い説、最初は自分も「いやいや構造化された文書ならたいして変わらんでしょ」と思ってたけど、実際試したら確かにHTMLの方が表現力高いし、現状ボトルネックの一つである人間の認知負荷を下げられるならということで、最近設計は全部artifactにULさせている

[YOKOTA Takehiko @i_am_skirnir]

仕事PC、いつも大量にブラウザタブやブラウザウィンドウが開いていて、ブラウザで作業中に割り込みが入った後に元のタブに戻れずとても非効率だったんだけど、copliotに課題感を伝えたらあっという間に神アプリを作ってくれて業務効率が爆上がりした。いいね、こういうのだよ、うん。

[YOKOTA Takehiko @i_am_skirnir]

google ai proプランに加入したら、もらえるはずのAIクレジットがもらえなくて、サポートに連絡したら契約内容が変わって付与しなくなったと言われた。んで、公式サイトにはその時点でAIポイントがもらえると書いてあったので一次情報くれと言ったら一ヶ月経ってもくれないの、不誠実すぎないか？

[ところてん @tokoroten]

大企業では成果物がなかなか測れないので、案件の進捗の代替指標として、使った経費の額を指標にすることがあるんだ

「俺は１０億円の案件をマネージした男だぞ」ってさ

そういう環境だと「経費を使うと評価が上がる」というバグが生まれるので、筋悪なものに経費を溶かすアホが生まれて、それが評価されて、アホが出世するという現象が生まれるんだ

ところであそこにトークン消費量を自慢しているプログラマーがいますね

[Takuo Kihira @tkihira]

三年前の私へ。とても楽しいです。

[Yusuke Endo @ysk_en]

こんにちは。

デザイナーとして、大企業からスタートアップまで、かなり使われているプロダクトをデザインしていると自負しているのですが、多くの皆さんがAIでVibe Codingしただけで、使われるプロダクトを生み出せると思っていることに疲れたので、この投稿を書いてみます。

この投稿を読んですぐに取り入れられるくらい長く書くつもりです。長い文章が嫌いなら、とりあえずブックマークだけして後で読んでください。

1. 新しいプロダクトを考える時は、自分の好きなツールで考えるようにしてください。

AIは便利ですが、文章だけで考える必要はないです。考えが進むなら紙でも石でもレゴブロックでも良いです。

2. これから何のゲームをプレイしようとしているのかを理解してください。

どうすれば勝ちなのか、達成したいことを明確にします。プロダクトのデザインはアートではなくサイエンスです。

最高のユーザー体験は、勝つための体験設計の一部です。あらゆるものすべてに意思が必要です。デジタル領域のプロダクトはもはやeSportsです。

3. プロダクトの価値で課題を解決する場合、誰よりもその課題に乾きを持ってください。

解決していない現状に笑けるくらい怒ってください。できない場合、本当の問題に気づくのに多くの時間がかかり、大抵の場合は先に飽きがきます。

課題の実感がない人がデザインするプロダクトほど的外れで退屈なものはありません。自分がユーザーだとこの上ないですが、「この人の問題を解決したい」と思える実在の人の近くにいてください。会って話して存在する根源的な課題を認識してください。

4. 機能ではなく、もたらす結果から考えてください。

「あったら良いな」と思う機能は必要ないです。「必要な気がする」機能も必要ないです。わからないことばかりなのに、自分でゲームを複雑にする必要はないです。削って削って削り切ってなお削りすぎたと後で困るくらい削ってください。その上で命をかけたいと思えるコア体験に集中してください。

5. 退屈な解き方をしないでください。

ただでさえAIでクソみたいなツールが増えまくっているので、あなたが作るプロダクトくらいは面白くあってください。つまらないものに人生の時間を使わせないでください。

6. プロダクトを使う道のりを完全にコントールしてください。

あなたのプロダクトを認知してから、プロダクトの入り口にたどり着き、期待値を持って動き始め、最初の最高の体験をし、お金を払ってでも使い続けたいと思う、一連の流れを何度も何度も通しで確認してください。

すべての画面、パーツに意思と責任を持ってください。パーソナライズやカスタマイズといった言葉で濁して無駄に選択肢を増やさないでください。使う人が迷う要素を徹底的に排除し導きます。

素晴らしいプロダクトデザインは空気のようです。気づかないうちに流れていきます。普段使っているプロダクトがなぜそうなっているのか、なぜ使いやすいのか、なぜ使いにくいのかを観察して説明できるようにしてください。

7. 発明すべきか、ベストプラクティスに従うべきかで悩むと思いますが、UIにおいては一番使われているプロダクトを真似してください。

プロダクトは人に使われるための道具です。使われる感触もわからず、UIの作法もわからず、何も知らないのに「俺が考える最強のプロダクト」を作る？？ただ「時間を無駄にしたい」と言ってるだけです。守破離が近道です。

すべてを模倣するのではなく、中途半端に見た目だけ真似するのではなく、設計意図を理解した上で、ありがたく先人の試行錯誤の結果を拝借してください。

8. 最初からドーパミンに依存する安易な手段に逃げないでください。

焦らせて判断を鈍らせたり、論点をずらすような短期的なハックを前提にすると価値を見誤ります。ハックしなければならいほど価値のないものを作ってるんですか？ゲームに大勝利するためにも体験価値の証明を優先してください。

9. プロダクトの設計に迷った時は、リリース投稿やリリース動画を考えてみてください。

あなたがわからないものはユーザーも理解できないです。リリース時の様子が想像できないのならコア体験がまだ存在していません。作ってる自分やチームですら使うのにつまずくものはプロダクトになってないです。すべてを捨てて最初からやり直しても良いです。

10. プロダクトのスタンスやポジションを持ってください。

似たようなものがたくさんある気がしますが、あなたのプロダクトを使う言い訳がほしいです。単に便利なだけでなく、会う人々に勧めたくて仕方がなくなるような強い思想です。

スタンスやポジションはすべてのデザインの意思決定に現れます。見た目やテキストのトーン、情報設計の運び、他にはない使いやすさにです。

そのために、考えのすべてをAIに任せないでください。自分の意思を持ってください。

11. 期限を必ず切ってください。頑張っても間に合うかわからない期日を設定してください。

失敗する前提で早く動いてください。振り返るタイミングがないまま続けると失敗を認識できないからです。失敗を認識できないと改善できません。

手作りでじっくり時間をかけると愛着が湧いて失敗だと認識したくなくなります。大成功に近づくためにさっさと作ってさっさと失敗してください。

12. 素早く失敗したら、成功できるサイズやステップまで小さく小さく刻んで問題を探ってください。

失敗したということは、理解できていないことや認知していない領域が存在しています。中途半端な成功には注意してください。緩やかな死です。自信を持って成功している状態を認識し続けてください。

13. 最初から分業で物事を始めないでください。

分業はチームで最適化を行うための手段です。最適化すべきものすらない状態で、意味のないタスクを生み出して無駄な仕事をしないでください。そして、最初から自動化しないでください。バカな要件を自動化してもゴミが生まれるだけです。

13. ユーザーが使っている様子を生で見てください。

できる限り自然な状態で、説明なしに使っている様子をただただ観察してください。妄想だけでは想像もしなかったハードルが驚くほど見つかります。

14. 楽しく生きてください。つまんないやつが作るプロダクトはたいてい面白くないです。

15. 使ってもらえるプロダクトを作れるようになったら、対価をもらえるように価値の付け替えをデザインしてください。

認知と利用を一体にしたプロダクトのデザインをしたり、ユーザーのモチベーションを課金に転換したり、自己増殖的に価値が作られる仕組みを組み込んだり。この先も楽しいゲームが待っています。

16. なんだか導入の思想ばかり書いてしまったので、より具体的なプロダクトのデザインについては、数日後にパート2をあげます。フォローといいねを押してください。ありがとうございます。

[YOKOTA Takehiko @i_am_skirnir]

Mavenの読み方、意見割れがちなので大事。

[irof @irof]

読み方書いてる親切さ

[YOKOTA Takehiko @i_am_skirnir]

AIエージェントを使うとアイデアをすぐ実装できるので、TODOがすぐなくなるし次々とアイデアが湧いてくる。そして外出中でもアイデアが湧いてくるので、すぐ実現したくなる。そういうことか！

[YOKOTA Takehiko @i_am_skirnir]

スマホでバイブコーディングという記事を見て、なんでスマホでやるんだろ、家でPCでやればいいじゃんって思っていたけど、最近自宅でAIエージェント使ったコーディングを始めたら理由が分かった。

[YOKOTA Takehiko @i_am_skirnir]

「知能」って書いてる点から考えると、反応時間が一番短い「最速」が一番知能が高そうに見えるが、多分そうじゃないよね？

[篠原 修司 @digimaga]

なんかChatGPT 5.5のモデル選択が変わった

[Ryutaro YOSHIBA @ryuzee]

https://t.co/tDJQUe6tA1

[iwashi / Yoshimasa Iwase @iwashi86]

Linux の開発メーリスが管理不能になっているという話(by Linus)だった。

・原因は、研究者の多くがAIツールを使ってバグを発見し、同じような報告を大量に送りつけていること
・多くの人が同じAIツールを使っている
・だから、まったく同じバグの報告が何重にも重複して届く事態が起きている

・開発者らは、届いた報告を適切な担当者に転送するだけの作業に多くの時間を奪われている
・すでに1週間前や1ヶ月前に修正されたバグに対して、わざわざ過去の公開議論のリンクを添えて「修正済みである」と返信する不毛な作業も発生している

・Linusは、このようなやり取りをすべて生産性のない時間の無駄であり、無意味な混乱であると批判している

・AIが発見したバグはその性質上秘密にすべきではない
・非公開のメーリングリストでこれらを扱うと、報告者同士でお互いの報告内容が見えないため、さらに重複が悪化するという問題がある

・LinusはAIツール自体を否定しているわけではない
・実際に役立つのであれば素晴らしいツールであると認めている

・しかし、現状の使い方は開発者に不必要な苦痛を与え、中身のない見せかけだけの仕事を生み出しているに過ぎないと指摘している
・AIツールを利用するなら、単に報告するだけでなく、より生産的で開発環境を良くする形で使う方が良いという主張

・公式のドキュメントにはLinusほど過激な表現は書かれていない
・だが伝えたい本質は同じ

・AIで見つけたバグは、すでに他の誰かも見つけている可能性が非常に高いという事実を認識した方が良い
・本当に開発に貢献したいのであれば、ドキュメントを読み、自分自身で修正パッチまで作成して、AIの成果に付加価値を与えること
・内容を大して理解もせずに、ただ報告書だけを送りつけて去っていくような無責任な人間にはならないでほしいとLinus氏は強く呼びかけている

https://t.co/7ZK8MRcxT1

[Takuto Wada @t_wada]

210字のプロンプトから4545字に水増しした「記事っぽいもの（AI Slop）」を生成できてしまう。（todesking が書いたからそうかなーと思いながら読んでいたけど）批評性が高い。 / ちょっとしたアイデアをAIで長文記事にして公開するのをやめろ https://t.co/Ge1RJOLVpy

[mattn @mattn_jp]

Vim 終了代行、始めます

Vim を終了出来なくなってしまった事ありますか？終了方法が分からず無駄な時間を費やしてしまっていませんか？
弊社にお任せ頂ければ、弊社の優秀なスタッフが遠隔で対応。

事前に行うヒアリング内容に応じ、:q, :q!, :qall!, :wq!, :wqall! などの使い分けを優しくアドバイスいたします。
万が一、それでも終了できなかった場合でもご安心下さい。プロによる kill コマンドの実行のサポートをさせて頂きます。

【料金プラン】
基本プラン(:wqall! まで) XXX 円
安心プラン(kill コマンド実行) XXX 円

今すぐお電話を！

[kawasima@99卒 @kawasima]

AIが出力したコードを理解することなく使うことの是非でフォーカスされがちな『認知負債』についてまとめました。(Hacker Newsで今さら盛り上がっていたので)
https://t.co/uEOTrCvFO8

[iwashi / Yoshimasa Iwase @iwashi86]

DHH が出ているepから部分的にメモ。メモの順番は前後している。

・かつては、AIを使うことは「AIのプロジェクトマネージャー」になるようなものであり、自ら手を動かす現場から遠ざかってしまうため、自分には合わないと考えていた
・だが、実際に複数のAIエージェントを同時に走らせてみると、マネージャーになるどころか、巨大な「パワードスーツ」に乗り込んだような感覚になった
・具体的には、自分の腕が2本から一気に12本に増えたような感じ
・同時に7つの画面を見ながら、5つのキーボードを操作しているような状態
・コードの一文字一文字を自分でタイピングしていなくても、「自分が直接手を動かして作っている」という手触り感は全く失われていない

・37signalsでは、新プロダクトを立ち上げる際は1〜2人程度の極めて少人数のチームで始め、プロダクトの形が見えてから人数を増やす手法をとっている
・同社では、デザイナーは単に見た目を作るだけでない
・プロダクトの仕様を考え、HTMLやCSSの実装まで担う重要な役割を果たしている

・優れたソフトウェアやプロダクトには、外面の見た目だけでなく、内面のコードや構造にも美しさが必要
・DHHは、半年前のインタビュー時点では、AIのコーディング支援ツールに対して非常に懐疑的だった
・というのも、一文字ずつ推測してくるオートコンプリート型のAIは、思考の邪魔になるため不快に感じていたから

・しかし、自律的にツールやターミナルを操作できるエージェント型AIが登場したことで、AIに対する評価が180度変わった
・特にOpusモデルが高い精度のコードを出力したことが、彼の考えを改める決定的な転機となった

・現在は新しい開発プロジェクトを始める際、必ずAIエージェントに最初のドラフトを作成させている
・AIが書いたコードであっても、人間の開発者が書いたものと同様に、高い美しさと品質基準を求めている

・また、AIエージェントにツールの手助けなしで自社プロダクトのサインアップを指示したところ、自律的にブラウザを操作して完了できたことに衝撃を受けた
・AIの進化によりアイデアを試すコストが劇的に下がっている
・以前なら割に合わないと諦めていた細かいパフォーマンス改善などにも挑戦できるようになった

・現在、AIの恩恵を最も受けているのは、AIの出力を正確に評価し、プロダクション環境に耐えうるか判断できるシニアエンジニア
・逆に、シニアの指示通りにコードを書くだけのジュニアエンジニアの役割は、AIに代替されつつあるため立場が危うくなっている
・シニアエンジニアの生産性がAIによって数倍から十倍になることで、彼らが生み出す価値はさらに高まっている

・今後、ただ実装だけを行うプログラマーの需要は減る
・プログラマーの黄金期のピークは過ぎた可能性がある
・将来的には、何を構築すべきかを決定し、AIを適切に指揮できるプロダクトマネジメントやデザインの能力がより重要になる

・採用において優秀な人材を公募で見つけることは難しい
・長引く選考プロセスを経ても最終的な定着率はそれほど高くないのが現実

・AIによって生産性が上がり仕事が楽しくなっても、睡眠や健康を犠牲にしてまで過労状態に陥るべきではない
・DHH自身は毎日8時間の睡眠を確保することを最優先とし、健康的な生活を大切にしている

・彼が経済的に成功しても働き続ける理由は、純粋にコンピュータで遊んだりシステムを作ったりすることが大好きだから
・人間は目的や使命感を持たずにただ余暇を過ごしているだけでは、本当の幸せや充実感を得ることはできないという価値観がある

https://t.co/aYDctPe56E

[Ryutaro YOSHIBA @ryuzee]

変革をするって言い出した幹部の方へ。チームの稼働を十分に確保しろ。自分も時間を毎週ちゃんと確保してそれを最優先にしろ。他の予定でチームに影響を及ぼすな。会議では末席に座れ。前に出て仕切るな。聞かれたことだけ答えろ。そして本当に大事なときだけ1つ質問しろ。責任は取れ。よろしくね！

[Takuto Wada @t_wada]

Claude Code がセッション終了時に memory や user_profile を保存するようになったが、現在の Claude セッションが将来の Claude セッションに「こいつは面倒くさい奴だぞ」と申し送りを行っているところが見えてしまうというかなんというか

[Ado @ado1024imokenp]

みんなAdoさんとどんな関係ですかって聞いてくれるんだけど、ごめんなさい……Adoさんって、どなたでしょうか……？自分が知らないだけだと思うのですが……質問にお答えできなくてごめんなさいっ……！