Scrappy - 友だちや自分のための小さなアプリを作る
(pontus.granstrom.me)- Scrappy は、非専門家でも手軽に自分で小さなアプリを作れるよう支援する ホームメイドソフトウェア制作ツール
- 大規模な商用アプリやエンタープライズアプリとは異なり、個人的で創造的な小規模の課題を自由に解決できる
- キャンバスベースのUI と簡単なコード編集、リアルタイムの共同作業・共有機能を提供し、非プログラマーでも活用できる
- すべてのアプリ（Scrapp） は基本的にマルチプレイヤー環境で、アカウント作成なしですぐに利用・共同作業が可能
- AIコード生成 や既存ツールとは異なり、Scrappy は ユーザー自身の操作と所有権 を重視する
紹介と背景
- ほとんどのソフトウェアは、大衆市場向けの販売用か大規模なカスタムアプリが中心
- しかし実際には、個々人のニーズを満たす小規模で個人向けのアプリは非常に少ない
- Scrappy は、誰でも友人や家族のために シンプルで創造的なアプリ を自分で作れるよう支援する研究プロトタイプ
- Scrappy の目標は、プログラミングの専門性がなくても、より多くの人が創造的でパーソナライズされたソフトウェアを作れるというビジョン を具体的に示すこと
Scrappy とは何か
- Scrappy で作られたアプリは Scrapp と呼ばれる
- 代表的な例:
- 小学生向けの算数練習アプリ: 難易度調整が可能
- 地域イベント参加者カウンター: 複数の入口で来場者の出入りを管理
- 会議コスト計算時計: 会議のコストをリアルタイムで算出
- 週間家事管理: メンバーごとに柔軟に予定を管理可能
Scrappy でアプリを作る体験
- Scrappy では、Figma、Miro、Google Slides に似た無限キャンバス 上にボタンやテキストフィールドなどのオブジェクトを配置する
- Inspector パネルでプロパティを直接編集でき、ボタンなどには JavaScript コード も接続できる
- アプリ制作は、ドラッグ＆ドロップ、プロパティ編集、コード挿入を段階的に繰り返しながら完成させる
主な特徴:
- 基本動作の構成: フィールドやボタンを置いて即座に動作をつなげられる
- リアクティブな数式: 特定の条件に反応するリアルタイムのプロパティ変更を実装
- マルチプレイヤー同期: 状態は常にリアルタイムで保存・同期される
- ライブ編集: 実行と編集を分けず、常にリアルタイムで修正できる
- 選択的共有: アプリの特定部分だけを個別に共有・接続できる
- 可視的なデータ操作: スプレッドシートのようにデータを見ながらデバッグ・修正できる
Scrappy を開発した理由
- Scrappy は ユーザー主導のプログラミング を実現するもので、“small computing”、“casual programming”、“home-cooked software” といったトレンドに関連している
- 既存のビジュアルプログラミング（ブロック型、ノード＆ワイヤー型）とは異なる道を選び、直感的な操作とスクリプティング を組み合わせている
- HyperCard、Visual Basic、同時的なオンラインメディアなどから着想を得ており、生産性キャンバスツール とリアルタイム共同編集（Google Docs、Figma など）の体験を重視している。
- Scrappy は 大規模な商用アプリや AI 自動生成方式とは異なり、ユーザーが自ら制御し、パーソナライズ・楽しさ・創造性 を最大化する
- コードを自動生成しなくても、より簡単で人間に優しいアプリ制作体験を提供する。
Scrappy の対象ユーザー
- 業務プロセス最適化を行う人: 複雑な業務フローを専門家の助けなしに改善したい人
- 教師と学生: コマンドラインや環境設定といった周辺技術なしに、プログラミングの本質へ集中できる
- 趣味の開発者: 大衆向けアプリの複雑さから離れ、素早く複数のプロジェクトを探求したい人
- DIY志向の人: 家や趣味のように、自分だけのアプリを自分で作りたいユーザー
現在、Scrappy で完全な初心者がアプリを作るのはまだ難しい（一部 JavaScript の知識が必要）ものの、共有とリミックスは非プログラマーでも可能。
Scrappy で作るのに向いているアプリは？
- 友人・知人との共有: 大半の Scrapp は複数ユーザーによるリアルタイム共同作業に適している
- 継続的な修正と改善: アプリ実行中でも即座に修正でき、デプロイやビルド工程がない
- 小規模な計算や操作: 複雑なシステムより、共有ドキュメント＋少しのコンピューティングに向いている
- ユーザーの摩擦を最小化: アカウント作成など不要な手順なしに、リンクだけでアクセスして使える
- 信頼できる少人数のユーザー: 権限制御やミッションクリティカル性が必須なら適していない
アプリのアイデア例: カスタムフラッシュカード、会議アジェンダ、オンラインワークショップ管理、家族掲示板、旅行計画表など
Scrappy vs 大衆向けアプリ
適切な一般向けアプリが見つからない、あるいは合うものがない場合、Scrappy で自分で作って共有できる。Scrappy の利点:
- 必要な機能だけを持てる: 不要な要素がない
- 個人的な思い入れ: 自分で作ったアプリは意味も愛着も大きい
- 楽しく修正できる: 色やレイアウトを自由に整え、ユーモアも加えられる
- 簡単なリミックス／共有: 他のユーザーも簡単に修正・再利用できる
- 共同作業中心の設計: 多人数が同時に操作・編集できる
- すぐ使える: アカウント登録なしでリンクをクリックするだけですぐ使える
- 明確なデータ所有権: データはローカルに保存され、完全にユーザーが制御する
Scrappy vs AI ベースのアプリ生成
AI がアプリを自動生成できたとしても、Scrappy の強みは理解しやすさ、リアルタイム共同作業、創造的な所有感 にある
- 理解しやすい構造: 複雑なコードなしの視覚的オブジェクトベース
- リアルタイム共同作業を支援: 複数ユーザーが同時に協力・修正できる
- より多くの楽しさと創造性: 即時フィードバックと能動的な修正の楽しさを提供する
Scrappy vs HyperCard および後継ツール
- インターネットに適した共有: Scrappy のアプリはリンクだけでオンライン共有できる
- リアルタイム共同作業環境: 同時編集／実行をサポート
- 現代的な UI とインタラクション: 無限キャンバス、さまざまなオブジェクトをサポート
- JavaScript スクリプティング: 現代的で一般的な言語で動作
- より多様なインタラクティブオブジェクト: 文字列、数値、日付、JSON などをサポート
- リアクティブな数式と状態接続: スプレッドシートに近い動的な関係を設定可能
今後の計画
- プログラマーではないユーザー のために参入障壁を下げる
- コード補完、より簡単なデバッグ、関係の可視化、分かりやすいエラーメッセージ、AI ベースのアシスタント
- 簡単で素早い共有、公開ギャラリー、モバイル対応の強化
- 機能強化と拡張
- コレクションとデータ処理機能の強化、繰り返しオブジェクトの管理、再利用可能コンポーネントの導入
- Scrappy の拡張性（新しいオブジェクトのサポート）、概念的一貫性の改善など
1件のコメント
Hacker Newsのコメント
このプロジェクトの方向性は気に入っているが、ホスト型SaaSという方式は自分の求めるものとは違う、と感じたという話。小さなカウンターのような1日プロジェクトなら問題ないが、何年も使う小さなアプリなら依存性が問題になるという判断。学習曲線はどれだけ低くなっても結局は存在するし、むしろ長期的に使えるアクセシビリティや簡単な言語、自分でGUIを載せられるツールのほうが望ましい選択肢だと思う。コードは完全に隠される必要はなく、人々が実際にできる方向へ簡単に進めるようにすべきだと考えている。MySpaceでどれだけ多くの人がCSSを学ぶようになったかを思い出せばわかるが、最初はコピペでも、結局は自分なりのものへ調整していく過程だからだ。個人的には最近はHTML/CSS/JSを主に使い、本当にバックエンドが必要なら素のPHP（フレームワークなし）を使う。ただこの方式にはブラウザに縛られる欠点があるが、会社ではこうした方式（AutoHotKeyを含む）で作った小規模プロジェクトが10年以上ほぼ保守なしでうまく動いている。特にAutoHotKeyスクリプトは8年前にmacOSへ移行してから手を離れたが、今でも同僚が毎日何度も使っている。たとえAutoHotKeyがもう動かなくなっても、すでに作ったコードは引き続き使える。しかしSaaS型のソリューションでは、創業者が別のことに関心を移したら作り直しになるリスクがある。こうした「scrappy」な解決策を求める人たちは、そのたびに作り直したいとは思っていない、というのが核心だ。
CardStockは本文では触れられていなかったが、Scrappyと目標もアプローチも似ているように見える。Scrappyと違って、CardStockはオープンソースでローカルでも動く。CardStock / GitHubリポジトリ 参照。Deckerもオープンソースで、Scrappyのロードマップにある要求の多く（テーブルデータ用クエリ言語やグリッドウィジェット、「Contraption」への部品抽象化など）をすでに実装している。Decker のリンク参照。
モバイルで作ったアプリがうまく動くようにすることはロードマップに入っているが、モバイル自体での編集は対象外のようだ（「手のひらサイズのタッチスクリーンはScrappsの編集には不便」との言及）。だが今は、多くの人がモバイルだけを唯一のコンピューティングデバイスとして使う時代で、コードや小説までもモバイルで書くことが多い。だから、多少不便でもモバイル編集インターフェースまで考えれば、このツールの影響力はずっと大きくなることを強調したい。
自分がやったことの中で最高のひとつは、Apple Watchの歩行記録を1枚の大きな地図に載せるシンプルなアプリを1週間で作ってAppStoreに出し、知人と共有した経験だ。1年たった今でも、友人や偶然アプリを見つけた人が街全体を歩いて達成報告のメッセージを送ってくれて、誇らしい気持ちになる。収益はなくても本当にやりがいのある体験だった。OPの言う通り、楽しみのために友人向けの簡単なアプリを作るのは最高の幸せだ。
スプレッドシートほど、実際にエンドユーザーにとって使えるプログラミング環境は見たことがない。
vibe codingはすぐに開発者を置き換えることはないだろうが、こうしたシンプルなシステムにとっては最強の競合になりそうだ。LLMに簡単なアプリ（HTML+内蔵JS）を作らせても、少し直すだけで完成度が高く、見た目すらより良かった。例 参照。
私たちはこのテーマをプログラマーの視点から見ているが、実際の機会はコミュニティ側にあるのではと思う。たとえば家族単位の個人アプリストアのようなものから始めることもできる（Mastersonスタイル）。セキュリティなしで（みんな知り合いだから）、招待なしでは貢献もできない。ただのアイデア提案だけど。
UI要素を空のシートにドラッグ＆ドロップし、グリッドスナップがUI要素のサイズと合わずにずっと格闘し、結局はコード補完もビジュアルプログラミングもAPI支援もAI支援もないまま、生のJavaScriptを打ち込むしかないのだとしたら、これが本当に最終形なのかと疑問に思う。
自分も初心者に対して、ブロックベースではなく「スクリプト可能なコンポーネント」というアプローチに100%賛成だ。今はモバイルなので、後でデスクトップから試すつもり。分析で見落とされているのは、人は「簡単な共有」と「ゼロコスト」を求めているという事実だ。最小限の環境でもアプリ自体を作るのは簡単だが、配布（アプリストアの壁）やホスティングが問題で、家族や知人相手ですら月5ドル払うのはためらわれる。実際、プロの開発者でも同じだ。
「コンピューターは人のために働くべきで、料理やワープロのように誰もが行う活動になるべきだ」といった志向への言及を見て、少し一般論すぎると感じた。「ライブ更新込み、全部無料。LLMが…」のように em-dash（-）が多すぎて、AI生成っぽさが出ているとも思った。個人的にはAIが書いたとわかるコンテンツを見ると急に興味が薄れるタイプだ。制作者のせいではないが、自分もこういうコピーにはあまり惹かれない。