blog-jim-nielsen-com

ジム・ニールセンが『Poor Charlie’s Almanack』を聴きながら感じた、チャーリー・マンガーの実用的で飾らない知恵を紹介。マンガーは難しい問題を解くのではなく「シンプルな解決策がわかること」を重視し、投資や問題解決において「やらないこと」を素早く排除し、多角的に攻め、好機にのみ断固として行動するアプローチを提唱。間違いを恐れず認めて修正することの大切さも説く。

AppleのmacOSアイコンデザインは後方に進むほど優れたものに見えるという逆説的な観察から、Apple自身のアイコンルールと「スクアークル」形式の強制が、サードパーティ製アプリも含めたmacOSエコシステム全体のアイコンデザインを劣化させていると論じる。MicrosoftのOneNoteや、Capo、BBEdit、Fantasticalなどのサードパーティ製アプリの経年変化を例に挙げ、Appleの手本がもはや模範的ではなくなった現状を批判する。

チャットボット型インターフェースは「打つ、読む、また打つ」という反応的なサイクルを生み、熟考や内省を積極的に妨げている。日本の「間（Ma）」の概念が示すように、立ち止まることは「作業の欠如」ではなく、むしろ不可欠な作業そのものである。良質で健全なソフトウェアを構築するには、情報を「消化」するための時間と間（ま）がどうしても必要なのである。

アイコン一覧のサイズ変更をJavaScriptを使ったWeb Componentから、サイズごとに別ページを用意するHTML主体のアプローチに置き換えた事例。JSを削除したことでCSSビュートランジションが無料で手に入り、モバイルでも快適に動作。クライアント側の重複コードを排除し、メンテナンス負荷も軽減できた。

JavaScriptを使ったページ内インタラクションを避け、HTMLのナビゲーションとCSS view transitionsを活用するアプローチを紹介。ブログのメニューを「拡張」ではなく「別ページへの遷移」として実装し、リンクという基本機能に依存することで、あらゆるブラウザや環境で動作を保証。シンプルながら堅牢で高速な設計を実現している。

個人のコーディング速度が10倍になっても、ソフトウェア全体が10倍良くなるわけではない。これは陸上競技の4✕100mリレーと同じで、最も速い4人の選手を集めれば勝てるという単純な話ではない。バトンの受け渡し（チーム内の連携やインターフェース）の方が、個人の速度よりも重要である。企業においても、より速いプログラマーを集めてもより速い企業にはならず、人と人との関係性やインターフェースこそが重要だ。

AIによるコーディングの高速化が必ずしもソフトウェアの改善につながらないという議論を、オリンピックの4✕100mリレーに例えて考察。バトンパスの重要性が示すように、個人の速度向上だけではチームとしての成功は保証されず、人と人との関係性やインターフェースにも注力すべきだと説く。

著者はノートサイトに小さな更新を加えました。大きな変更はありませんが、個々のノートに独自のURLを割り当て、識別子の形式を変更し、古いURLから新しいURLへのリダイレクトを実装しました。また、投稿間をランダムに移動する「シャッフル」機能も追加しています。

プログラミングは、物事を反復的に構築する過程で思考を研ぎ澄ます活動である。AIによるコード生成はこのプロセスを飛ばすため、詳細な理解や思考の深化の機会を失うことになる。コード生成は強力なツールだが、それに伴うプロセスが目標達成に役立つかどうかを意識することが重要だ。

Jason Gorman氏は、ソフトウェア開発における「継続的」という言葉の重要性を論じている。従来の段階的な開発プロセス（設計、コーディング、テスト、統合、リリース）は、すべてが高速で変化する現代には適していない。代わりに、これらの段階は相互に連続したサイクルであり、フィードバックループを通じて小さなステップで進化していくことが重要だと指摘する。

1997年のClarisWorksのダイアログ「Now / Later / Never」は、ボタンの文言が周囲の文脈なしでは理解できないという「click here」ルールを破っているが、簡潔で優雅な表現でユーザーを魅了している。体系的な規則と局所的な文脈への配慮の間には常にトレードオフがあり、スケールを追求するソフトウェアでは規則が優先されがちだが、熟考された例外は規則以上の価値を生むことがある。

著者は、理想のRSSリーダーアプリをバイブコーディング（AI支援開発）で試みた。macOSアプリ、Webサイト、Electronアプリと様々な方法でプロトタイプを作成したが、既存のReederのような完成度には遠く、AIによる開発の限界と、アイデアを「良いもの」にするまでの道のりの長さを実感した。

LLMを使ったプロトタイピングは簡単で魅力的だが、すぐに飛びつく前に少し考えてスケッチを描くことで、本当に作りたいものかどうかを安価に確認できる。スケッチはトークンや計算コストをかけずにアイデアを検証する効率的な方法だ。

著者は個人サイトのビルドとデプロイをリモートサーバーからローカルマシンに移行した経験を語る。Netlifyでの分散ビルドの問題に悩まされ、すべてを自分のコンピューター上で完結させることで、トラブルシューティングの時間を削減し「自分のマシンで動けばそれでOK」というシンプルなワークフローを実現した。

AI支持者がLLMが期待通りに動かない時に「スキル問題だ」と言うのに対し、人間中心のUXデザイナーは「私たち作り手側のスキル問題だ」と考える。技術を固定点として捉えるテクノロジー中心アプローチと、人々の実際のあり方に合わせる人間中心アプローチの違いを考察する。

現代社会では速度が主要な美徳となっているが、知恵は経験によって自分自身が「解きほぐされる」ことを必要とする。速度を保つことで反省を避けられるが、重要なことは必要な時間をかけてこそ理解できるものであり、知恵は私たちを追いかけているのに、速すぎてその教えに気づけないのだ。

2000年代初頭、家族旅行で車がオーバーヒートした際、整備士は機械的な問題ではなく「コンピューター化された車」の診断には別のコンピューターが必要だと指摘。この経験から、LLMで生成されたコードベースの問題も、将来的にはLLMなしでは診断・修正できなくなるかもしれないと考察している。