おもちゃソフトウェアを作る楽しさ

 (blog.jsbarretto.com)
53 ポイント 投稿者 GN⁺ 2025-06-25 | 3件のコメント | WhatsAppで共有
  • Toyソフトウェアの制作は、ソフトウェア開発の本質的な楽しさと創造性を取り戻す方法である
  • AIと産業化によってソフトウェア開発の純粋な喜びが失われつつある時代に、個人プロジェクトとしてシンプルなおもちゃプログラムを作ることは、実務で役立つ知識と深い理解を得るきっかけになる
  • おもちゃソフトウェアは80:20の法則に従い、最小限のコードで最大限の機能を実装し、過度な設計や完成度への執着を避けることが核心である
  • LLMなどのAIツールに依存せず、自分でぶつかりながら作る経験そのものが、学習と成長の本質的な喜びである

なぜおもちゃプログラムをもっと作るべきなのか

  • Richard Feynmanの名言「自分で作れないものは、理解していないということだ」→ 何かを自分で作る経験は深い理解につながる
  • これまでの「車輪の再発明をするな」という助言とは逆に、車輪を自分で作ってみる経験は、読書や理論学習よりも多くのことを教えてくれる
  • 近年、AIとソフトウェアの産業化が開発の楽しさと職人気質を脅かしている
  • おもちゃソフトウェアの制作は、再びコンピュータに夢中になれるシンプルな楽しさを取り戻させてくれる

おもちゃプログラムの原則: Keep it simple

  • おもちゃソフトウェアは80:20の原則に従う: 20%の労力で80%の機能を達成する
  • 目標は最終製品ではなく、シンプルさと主要な原理を自分で実装することにある
  • 過剰な構造設計（over-engineering）を避け、本当に必要なコードだけを書くやり方を重視する
  • すべてのコードパスをまだ実装していない状態のままにしておき、必要になるたびに実装を増やしていくようなアプローチを勧めている
  • 小さく見えるシステムでも、実際にやってみると意外と簡単に作れることを体験できる

おもちゃソフトウェアの副次的な利点

  • おもちゃプロジェクトで得た知識が、実務における問題追跡、バグ修正、ミスの予防に予想以上に役立つことが多い
  • 自分でぶつかりながら制約条件を体験することは、ソフトウェアの本質への洞察を与え、革新的な解決策の発見にもつながる
広告

例: さまざまなおもちゃソフトウェアプロジェクト一覧

過去15年間に自分で実装してきたおもちゃプロジェクトの種類を、難易度と予想所要時間つきで整理している。各プロジェクトには簡単な説明と追加の参考資料が含まれる

  • Regexエンジン（難易度 4/10、5日） : POSIXスタイルの正規表現を解釈し、一致する文字列を識別することで、正規表現の内部動作を深く理解できる
  • x86 OSカーネル（難易度 7/10、2か月） : CLIとシンプルなドライバ、メモリマネージャなどを含み、インメモリファイルシステム、ELF実行ファイル、GUI、プロセス分離などへの追加挑戦も可能
  • GameBoy/NESエミュレータ（難易度 6/10、3週間） : シンプルな命令セットとハードウェアへの理解、PPUやPSG、独特なカートリッジ形式の実装
  • GameBoy Advanceゲーム（難易度 3/10、2週間） : スプライトベースのシンプルなゲーム。GBA開発コミュニティは活発で、1人でも十分に把握できるシステム構造
  • 2D物理エンジン（難易度 5/10、1週間） : 基本的なニュートン力学とシンプルな衝突処理から始め、複雑な図形・慣性・解決アルゴリズム、ソフトボディや複合相互作用へ拡張可能
  • 動的インタプリタ（難易度 4/10、1〜2週間） : ツリーウォーキングインタプリタで、自分だけの言語を作ることが技術的・創造的な喜びを与える
  • C系コンパイラ（難易度 8/10、3か月） : 単純な型システムとターゲット環境から始め、各種最適化や多様なバックエンドを支えるアーキテクチャ設計へ発展できる
  • テキストエディタ（難易度 5/10、2〜4週間） : シンプルなファイル入出力から始め、UIツールキット（QT/GTKなど）も利用可能。コンソールベースを好む人にも向き、unicode、syntaxハイライト、マルチバッファ、LSPなどの追加機能も試せる
  • Asyncランタイム（難易度 6/10、1週間） : Rustなら impl Future タスク処理と並行性を実装し、I/Oウェイクアップも追加できる
  • Hash Map（難易度 4/10、3〜5日） : 内部動作の原理、クローズド／オープンアドレッシング、ロビンフッド規則を学び、性能と適切な使いどころを理解できる
  • Rasteriser / Texture Mapper（難易度 6/10、2週間） : 3Dグラフィックスパイプラインの構造を学び、ベクトル数学、Zバッファ、テクスチャマッピングやシェーディングアルゴリズムまで深められる
  • Signed Distance Fieldレンダリング（難易度 5/10、3日） : 数学的な空間表現とシンプルな可視化を通じて、シェーダとベクトル数学への理解を深められる
  • Voxelエンジン（難易度 5/10、2週間） : 3Dグラフィックスやゲーム開発経験があれば理解しやすく、テクスチャ、手続き生成、ネットワークなどにも挑戦可能
  • Threaded Virtual Machine（難易度 6/10、1週間） : 高速なインタプリタで、アーキテクチャごとのコード生成なしに最適化された処理系を実装でき、コンパイラに匹敵する性能を体験できる
  • GUIツールキット（難易度 6/10、2〜3週間） : 基本的なUIツール作成を経験した後、レイアウトエンジン、テキストシェーピング、アクセシビリティなどの発展機能を自分で実装できる
  • 軌道力学シミュレータ（難易度 6/10、1週間） : ニュートン重力モデルをシンプルに実装し、複数天体の相互作用、積分アルゴリズムや可視化への拡張、NASAデータの適用なども可能
  • Bitwise Challenge（難易度 3/10、2〜3日） : 64ビットの状態だけで再現されるゲームで、創造的な状態管理の訓練になる。詳しいルールはGitHubで確認可能
  • ECSフレームワーク（難易度 4/10、1〜2週間） : Entity-Component-System構造を自分で実装し、言語の型システム統合、高性能化、制約への最適化を試せる
  • CHIP-8エミュレータ（難易度 3/10、3〜6日） : 1970年代のシンプルな仮想マシンで、素早く実装でき、さまざまなファンゲームを観察・実行できる
  • チェスエンジン（難易度 5/10、2〜5日） : ルール実装から始めて徐々に発展させる。自作エンジンに負ける経験は、開発者として成長する一場面になる
  • POSIX Shell（難易度 4/10、3〜5日） : POSIXベースのシェルの原理と限界、実際のShell言語互換性の実装を通じた深い理解、そして数多くのトリックを体験できる

LLMなどのツール利用に関する助言

  • LLMなどの先端ツールも有用だが、本当の学びは自分で直接探究するときにより深まる
  • 既存のソリューションを見るよりも、未知の領域を探究し、自分なりの答えを見つける過程のほうが、より深い達成感を得られる
  • おもちゃプロジェクトをLLMなしで進めると、最初は慣れずに大変かもしれないが、時間が経つほど固有の技術的な喜びと高い達成感を感じられるようになる
  • 車で移動していては、走者としての「ランナーズハイ」は味わえない → 近道ではなく自分で体験することから深い喜びを得られる

関連記事

3件のコメント

 
tolluset 2025-06-30

LLMを使わずにやってみろというのには共感します。迅速な開発が必要でないなら、自分で一つひとつ理解しながら作っていくほうが、より楽しくてやりがいがある気がします。
 
nezz1204 2025-06-26

トイプロジェクトのことだったんですね。タイトルだけ見て、おもちゃに入るソフトウェアを作ることだと思っていましたね。笑
 
GN⁺ 2025-06-25
Hacker Newsの意見

  • LLMを検索エンジンのように使っている人がいるのか気になる。以前は Google で pros cons mysql mongodb のように検索して、公式ドキュメント、フォーラム、ブログ、Stack Overflow まで読み漁っていて時間がかかっていた。ただ、読みながら学ぶ時間そのものはいつでも歓迎だった。今は LLM にもう少し具体的に、たとえば「写真保存時の mysql vs mongodb の長所短所、参考リンクも添えて」といった感じでプロンプトを入れている。すばやく要点を把握できるし、リンクも付くので幻覚だけに頼らなくていいのがよい。たまに「postgres で写真メタデータを保存する data schema を作って。X は別テーブルに分けたい」など具体的な依頼もするが、これは自分がどんな成果物になるべきかを正確に分かっている時だけ使う。単にタイピングの時間が惜しい時や、型の正式名称（int と integer など）を一瞬忘れた時に使うだけ

    • LLMを技術質問エンジンとして使うと、一見もっともらしいが重要なところで間違った情報を出すことが多い。額面通りに信じて答えに従うと、無駄に数時間、あるいは数日を失うこともある。参考リンクを求めても、実際に情報がある場合と無関係な内容を出す場合が半々くらい。それでも一つ確実にうまいのは「tip-of-my-tongue」的な逆引き検索だ。つまり、概念を説明するとそれに対応する検索語を勧めてくれる役割には一貫性があり、満足している
    • そのうち企業がLLMに大金を払って、自社製品がより有利な比較として表示されるようにする気がする。LLMは結果が「有機的」に見えるよう、フレーミングや強調の仕方だけを変えられる。真実と根拠のある情報だけを見せつつ、「文脈上の強調」だけを操作できるからだ
    • 自分もまったく同じようにLLMを検索用として使っている。感覚としては、2010年代初頭の Google 検索が圧倒的に強かった頃に戻ったような感じだ。何でも見つけられた時代。もちろん、その時期は長く続かず、今の Google 検索は苦痛と挫折そのものだ。Google とマーケターが作った変化に不満は多いが、現在のLLMは一時的にオンライン情報を表面化させるのに非常に効率的だと感じる。参考リンクも大抵かなり正確。結局は昔と同じ変化の力が働くだろうし、また消えてしまう前の束の間の機会だと思う
    • 自分もLLMを検索エンジンのように使う人間の一人だ。まだAI IDEは使っていない。最近、ライブの技術面接で、自分が選んだLLMに Google 検索するように質問しながら答えようとしたところ、面接官にこういうふうにAIを使う応募者は初めて見たと言われた。ほとんどの開発者は、まだAI IDEより先に検索用途で使っていると思っていた。自分たちみたいな例は珍しいのだろうか？
    • 開発でもLLMを検索エンジンのように使っている。「/src/foo にある自分が clone した repo を分析して barFeature がどう実装されているか説明して。次に /src/baz プロジェクトを見て、foo のアプローチが baz に適用しにくい理由を説明して」といった使い方だ。何か新しいものをやらせるのではなく、既存プロジェクトを自分のアイデアに翻訳して活用している。本当に新しくて挑戦的な開発は、自分で直接コードを書いてこそ楽しい

  • キャリア的に見ても、いちばんよかったことの一つは、転職の合間に6か月休んで進めた個人プロジェクトだ。もともと始めたいプロジェクトは多かったが、制約がないとスコープがどんどん膨らみ、結局完成しないことが多かった。そこで各プロジェクトに1週間だけ投資すると決めた。1週間でできるところまでしか作らなかった。ゼロから始めて、新しい言語やフレームワーク、あるいは不慣れな分野で、1週間で実用的な何かを作れた経験は、とてつもなく自信につながった。自分がもともとプログラミングを好きだった理由も思い出せた。もし転職の合間に数か月ほど休みができるなら、シリコンバレー面接の準備をする代わりに、ただトイプロジェクトを作ってみると、自分がすでにどれだけ多くのことを知っていたかに驚くはず

    • AI生成ツールがあれば、こういう個人のトイプロジェクトを進める時にものすごく助かる。自分は主にバックエンドだがフロントもできなくはない。ただ CSS に時間がかかりすぎて、以前は個人プロジェクトを最後まで終えられないことが多かった。今はAIに「いい感じにして」と頼めば85%くらい完成した状態まで持っていってくれて、残りはバグ修正や細かな調整をするだけなので、素早く仕上げられる。昔は泥沼みたいだった開発が、今はこうしてずっと楽になったおかげで、個人プロジェクトをより頻繁に作るようになった
    • 最近は使っているライブラリへの不満がたまって、直接直す方向に移っている。不完全なオンボーディング文書、壊れた SDLC、深刻な性能問題などを見つけると、一日中修正作業をしてしまう。ほかの人が待っている共同プロジェクトと違って、個人のトイプロジェクトはサイドクエスト（雑事）に脱線しやすい。共同作業には誰かが待っているというプレッシャーがある
    • どうやって6か月も休んで次の仕事を見つけられたのか気になる。自分も6か月休みたいが、仕事が見つからずもっと長く休むことになるのではと不安だ
    • 子どもの頃は classic ASP + SQL でサーバーを立てて、HTML/CSS/JS を全部触りながら簡単にデプロイしていた。あの頃は FTP でファイルを上げるだけでよかった。今はもっとモダンな方法を試してみたいが、個人プロジェクトをやると毎回デプロイや開発プロセス（ライフサイクル）の悩みで迷子になることが多い。トイプロジェクトのホスティングやデプロイ方法をどう選んでいるのか知りたい
    • 自分もAIがボイラープレート部分やテスト自動化コードなどを生成してくれるおかげで、こうした個人プロジェクトの進み方が確実に速くなった

  • トイソフトウェア開発は、自転車や車、ボートの整備に似ている。楽しい。でも通勤用の自転車を直すのはストレスだ。トイソフトウェアを作るのは楽しいが、いつか自分が本当に使おうとすると、あらゆるバグを発見してしまい、直す時間はないというジレンマが生まれる

    • 自分で使うためのソフトウェアだけを開発するほうが好きだ。車も、より安く長く乗れることに満足感がある
    • 以前はメールサーバーを自前運用していたが、今はもうやっていない。これは自分でやりたい作業というより、この仕事は専門家に任せたくなったからだ
    • 最近、自分で請求書アプリケーションを作った。必要な機能を一つずつ追加していくのは楽しかった。既存の有料サービスで月額料金を払わないと使えないような機能まで全部入れたが、実際に請求書を送ろうとした瞬間、自作アプリで解決すべき問題（スタイル、住所入力など）が多すぎることに気づいた。結局、自転車に乗る楽しさと通勤用自転車の実用性との間でバランスを取る必要があると感じた。時間が経てば、楽しさと実用性が少しずつ近づいていくのかもしれないという気づきもあった
    • 自分も「完成したソフトウェア」にしたいものが多すぎるが、時間もエネルギーもない。退屈で反復的な作業も非常に多い。それでも「AIの成果物」を管理して選別するのもかなり仕事だ。まだ初期実験の段階なので、数か月後にもこの意見を保っているかは分からない
    • こういう理由で、個人ホームページを作るのが本当に楽しい。実際に自分の遊び場として使える

  • LLMに対して否定的な意見が多いのが意外だ。LLMは情報をスプーンで口まで運んでくれる。新しいプロジェクトを始める時、当然ながら最初からすべてを知っているわけではない。ベストを尽くして失敗し、その後で勉強し、なぜ駄目だったのかを理解し、新しい方法で調整することこそ本当の学びだ。何もかも知ったうえでただチュートリアルをなぞるだけでは、手法ごとの限界や本当の長所短所を体験できない。たとえば正規表現でパーサーを作ろうとして、再帰表現を扱えないことを自分で発見し、より複雑な構造や時間計算量の問題なども自分の手でつかんで学ぶべきだ。自分で最適化コンパイラを実装して、あらゆる最適化テクニックに打ちのめされることで、実際のコンパイラがなぜそう設計されているのか理解できる。自分でレイアウトエンジンを書けば、width という概念ひとつを適切に扱うことの苦労すら体験できる。試行錯誤を通じて学ぶこと以上によい経験はない。LLMが失敗を防いでくれるからといって、大事な学習機会まで逃してほしくない

    • 多くの人はLLMを使わないと取り残されると言うが、むしろLLMをあまり使わないことのほうが、長期的には大きな利点になる気がしている

  • 自分もコンピュータグラフィックスを学ぶために、何年も週末や夜を使って数えきれないほど奇妙なプロジェクトをやってきた。1円も稼げなかったが、そのおかげで夢の仕事を得られた。代表的な成果物へのリンク:

  • この記事が示した「プログラミングの楽しさ」という精神は本当に必要だと感じる。AIエージェントコーディングの時代にはなおさら貴重だ。ただ、著者が示したトイプロジェクトの想定所要時間は短すぎる気がする。自分は平均的な速さではないが、それでもあのリストの大半は、1日2〜3時間ずつ作業する前提なら数日で終わるプロジェクトではないと思う。始める前のリサーチだけでもかなり時間がかかる感覚だ。たとえば最近、自分の Pelican ブログを個人製の Odin static site generator に置き換えたが、1日2〜3時間しか使わなくても2週間かかった。あのリストのほかのプロジェクトより簡単な部類だったのに、そのくらいかかった

    • 君のプロジェクトは「トイ」プロジェクト以上のものだ。自分自身が本当の顧客になっていて、デプロイ後もきちんと動くことを期待している。その期待が、トイと本物のツールを分ける境界だ。1時間でワードプロセッサーを作ることだってできる。キー入力を一つずつ処理するだけで、狂ったように単純で、終了ボタンすらない版かもしれない。でもそれでも「トイ」ワードプロセッサーとしては十分だ
    • もし「X日」という所要時間を 24*X 時間として解釈するなら、このリストはもっともらしく見える
    • トイプロジェクトの利点の一つは締め切りがないことだ。だから十分にのんびり、ゆっくり進められる。自分も PEG ベースのチューリング完全言語をコロナ禍の頃からまだ磨き続けている
    • こうした時間短縮は、どこまで 3rd-party ライブラリを使い、何を自分で解いたのか、実際にどれだけ最も核心にだけ集中したのかによって大きく変わる。著者の GitHub（https://github.com/ssloy/…

  • 「LLMをこういうプロジェクトに使うな」という助言には自分も同意するが、あまり極端に受け取らないほうがよいという立場だ。AIの助けをどう受けるべきかという助言が、なぜ人に助けを求めるのとは違って感じられるのか、という点も興味深い。ブログの最後に「プログラミングが得意な友人がいるなら絶対に助けを求めるな」と書いてあったら変だろう。専門家の友人なら文脈を理解し、自分で解けるように助けてくれる。AIにも本当に「問題を解いてもらうのではなく、専門家の友人のように導いてほしい」と頼んでみた人は、ほとんどいないはずだ。もちろん今はまだできないか、不十分かもしれないが、1〜2年後にはこういうガイドのされ方がごく自然になっているかもしれない。だから「自分がどんな助け方を望んでいるかを明確に伝える」習慣をつけるとよい。LLMが必ず間違った正解しか返さない、という固定観念を持つ必要はない

    • AIはまだ専門家の開発者ではないと、はっきり感じている
    • LLMを専門家の友人のように使うのが、自分がいちばんよくやる使い方だ。信頼できるものにするには、プロンプトや質問そのものを偏らないように変えて尋ねる必要がある。最近は Claude や ChatGPT が、自分の考えに同調しすぎる傾向が強くなった気がする
    • （投稿者）実は自分は本気で「専門家の友人にさえ助けを求めるな」と勧めたい。どうしても行き詰まった時だけ、そのテーマに関する簡単な文献を読むくらいがよいという考えだ。本当にいろいろな方法を自分で試し、ぶつかりながら解いていく経験こそが、創造力や問題解決力を育てるうえで不可欠だと強く信じている。混乱している時間は絶対に必要だ。ただし、最終的には誰もが自分で決めるべきことだ
    • 実際、LLMには「先生」のように接して質問している。インターンのように答えてくれ、という聞き方はしない

  • Claude ベースの vibe coding のおかげで、本当に久しぶりに楽しいサイドプロジェクトを始められた。ツールとプロセスに慣れてから数週間で、家族向けのカレンダー／天気ダッシュボード、Bluesky の閲覧アプリ（既読の投稿を隠す）、ゲーム化した会社向け PM ダッシュボード、一定時間後に Reddit 投稿を隠す Chrome 拡張、保守されていない WordPress プラグインの代替アプリなど、いろいろなアプリを素早く作っている。初期には Claude に UI 改善など多くを任せていたが、今では90%の完成度で満足し、高度化よりも新しいアプリ機能に集中するコツをつかんだ

    • Claudeがバグを修正しておきながら、結果をすぐ見せてくれないことがあって困る。一つの修正で更新後の結果出力を6回も要求し直したことがある。同じような経験をした人はいるだろうか

  • このリストは本当に印象的だ。著者には簡単に感じられたプロジェクトのかなりの部分が、自分にはぐっと高難度に見えるだろう。でも実際、自分のトイプロジェクトをまた始めたくなる動機づけには確実になった。ただ、LLM学習についての結論はもう少し繊細だ。どう使うかでまったく違う。たとえば「この問題をそのまま実装して」と頼むのは学習に最悪だし、「ELFの構造を最上位の抽象度で、『なぜ』に焦点を当てて説明して」は逆に強力な学習促進剤になる。毎回自分でリサーチしなくなるのは欠点かもしれないが、本当に知的に考える姿勢があるなら、ソクラテス式の問答をいつでも受けられるのは、学習を大きく加速する

    • （投稿者）それこそが本文で言った「特定の種類の学習」だ。たとえば ELF バイナリ構造を学ぶなら、自分の推測だけでは分からない。歴史や意思決定の過程を知る必要があるので、仕様書や文書、LLMも含めた参考資料を使うべきだ。根本的には「自分で作ってみる constructive learning」が重要で、実際に自分でバイナリフォーマットを作ってぶつかりながら探る過程こそが、ELF など実在のフォーマットの理由や問題点、デザイン空間全体まで理解させてくれるポイントだ。こうした探究型の学習ではLLMの助けを借りないことを勧める。「ノートPC、テキストエディタ、コンパイラだけ渡して10年間放置したら、どこまで作れるだろう？ どこで具体的な情報を得ないと行き詰まるだろう？」

  • ここで紹介されているプロジェクトは本当にいいアイデアだが、自分にはどれ一つとして面白そうに思えない。こういう時、自分は本当にプログラミングが好きだったのだろうかと疑問になる

    • 自分とは正反対のようだ。リストの大半のプロジェクトが面白そうで、誰かが試してみたい、あるいは実際にやったことがありそうな題材だった。実は自分も最近までその問いをしていて、子どもが生まれて育休に入り、本当に楽しみのために「単純な」コーディングプロジェクトを始めた。依存関係を全部外して、すべて最初から自分で作ることにしたら、思ったよりずっと複雑になったが、そのぶん数時間のコーディング時間が待ち遠しくてたまらなくなった。急にコーディングがすごく楽しくなった。たぶん、本人は燃え尽き気味なのかもしれない