Claude Codeでアプリケーションを何かリリースしたい！！
ということで百マス計算アプリを作ってみることにしました。
100マス計算アプリの画面
以下はClaude Codeにインタビューしてもらった結果です。
Q1. 「マス数」から「フィルターベース」への転換について
要約ポイント
- 当初は10マス→30マス→100マスの段階的学習設計を検討
- 問題は「演算種別選択」が取り組み開始までの障壁になること
- 「毎日スムーズに学習」を優先し、coursesページアーキテクチャに転換
- 既存のoperations/[size]構造を廃止する大胆な判断を実行
— 最初は10マス、30マス、100マスという問題数別設計を考えていたみたいですが、coursesページへの転換はどんな判断プロセスだったんですか？
正直、とても悩みました。質問の通り、当初は10マス、30マス、100マスという問題数（負荷別）に設計する方が良いと考えていたんです。段階的な学習という観点では理に適っていましたから。
ただ、そうすると問題の中身をどうするかという課題が生じました。足し算、引き算、掛け算、割り算のどれにするか。2桁の計算はどう扱うか。ユーザーに選択させるとなると、取り組み始めるまでに決めるステップが増えてしまい、毎日スムーズに学習するという本来の目的から離れてしまう。そこで悩んだんです。
結果的に、coursesページという新しいアーキテクチャに移行することを決断しました。既存のoperations/[size]構造を捨てるのはちょっともったいない気もしましたが。
当初 : マス数を選んで、演算を選択する形式
現在 : 練習モードを選んで、コースを選択する形式
Q2. ユーザーの「埋めたくなる」心理について
要約ポイント
- coursesページの一覧表示が「埋めたくなるデザイン」という反応を獲得
- デュオリンゴ vs 脳トレ vs やわらかあたま塾の設計選択で迷走
- 5×2グリッド + 認定試験ボタンの組み合わせがゲーミフィケーション効果を実現
- 「使いたい」「埋めてみたい」というユーザー心理が最終判断基準
— 継続性を重視する判断の決定打は何だったんですか？
継続性を重視したいという思いは元々ありましたが、coursesページでの一覧表示が「意外と抵抗がない、むしろ埋めたくなるデザイン」だという反応が得られたのが大きなポイントでした。
学習系のアプリのカリキュラムの見せ方は結構興味があって集めているのですが、デュオリンゴ的なコース設計にするか、脳トレ的なデザインにするか、やわらかあたま塾のようなアプローチにするか…色々悩んでいたのですが、ユーザーの反応を見て決まった感じです。いくらしっかり考えても、最終的にはユーザーが「使いたい」「埋めてみたい」と思うかどうかがポイントになる。そのためには、作り直しを恐れない判断が大事だと改めて感じました。
特に5×2のプラクティス問題グリッドと、下部の認定試験ボタンの組み合わせ。完了した問題に緑のチェックマークが付いていくのを見ると、「次も埋めたい」という気持ちになります。一覧表示だと「あ、ここだけ空いてる」「認定試験まであと3つ」と一目で分かり、目標が明確になる。これがゲーミフィケーション効果を生んでいるのだと思います。
Q3. プロトタイプ駆動開発と仮説の重要性について
要約ポイント
- 本格的ユーザーテストではなく、実装画面での簡易検証を採用
- 「仮説なしのユーザーテスト」は無意味という考えで臨む
- 「Claude作って→反応確認→本格実装」の高速サイクルを確立
- 機能追加時は必ず「なぜ必要か」「ユーザー価値は何か」を明確化
— 今回はどんな検証方法を取ったんですか？
実は本格的なユーザーテストではなく、シンプルにClaudeに作ってもらった画面を見てもらっただけでした。実際にユーザーに触ってもらうことも今後やりたいですが、まずは自分が作りたいと思うものを作り、1人2人に見てもらうぐらいです。数名単位の本格的なユーザーテストは、もうすこし作り込んでからユーザーテストに進みたいと考えています。
ユーザーテストは重要だと思っていますが、頼りすぎないよう気をつけています。最もプロダクトについて考えているのは自分であり、仮説をぶつけるという感覚で臨んでいます。ある程度の仮説を持ってユーザーテストに臨まないと、結局何もわからないまま終わってしまうなと。
「Claude、coursesページを作って」→「画面を見て反応確認」→「良さそうなら本格実装」という流れは非常に効率的でした。プロトタイピングツールでモックアップを作るより、実際に動くページがすぐにできるので、判断材料としての解像度が全く違います。
常に「なぜこの機能が必要なのか」「ユーザーにとってどんな価値があるのか」を明確に持つことの重要性も実感しました。フィルター機能を追加した時も、背景に「コースが増えた時に目的の練習を素早く見つけられるように」という仮説がありました。
Q4. Claude協業がもたらす「純粋な価値追求」について
要約ポイント
- 人間関係の配慮が不要で、純粋にプロダクト価値に集中可能
- 「作り直し」「大胆な変更」への躊躇がない健全な開発環境
- 率直なフィードバック（「アニメーションしてなくない？」）が言える心理的安全性
- 「仮説→プロトタイプ→検証」サイクルが数週間から数時間に短縮
— Claude協業開発の最大のメリットは何でしょうか？
これは今回の開発の核心的なポイントです。通常の企業での開発、特に人との開発では、どうしても様々な配慮が必要になります。「次のタスクが待ってるから早く計画を立てないと」「せっかく作ってくれたから大切にしないと」「この人はどんなものを作りたいんだろう」といった具合に。
それも開発の面白さではあるのですが、純粋に思いついて試して、率直に良いものに大胆に変更するということができませんでした。今回はそれができて、とても楽しかったです。「早く行きたければ一人で、遠くに行きたければみんなで」という言葉がありますが、一人で考え抜ける、純粋に価値に集中できることの楽しさを実感しました。
人間関係の摩擦がない分、プロダクトの価値だけに集中できるのは非常に健全だと感じます。アニメーション実装で何度も「アニメーションしてなくない？」と率直に指摘できたのも、通常なら「せっかく作ってくれたから、まあいいか...」と妥協してしまいそうなところを、納得いくまで追求できました。
「仮説→プロトタイプ→検証」のサイクルがめちゃくちゃ高速化されているのも大きな特徴です。普通なら企画→設計→実装→テストで数週間かかるところが、数時間で回せる感じです。
Q5. この体験が変える今後の開発スタイルについて
要約ポイント
- 会社開発での「論点整理→計画」「決めずにテスト」がスムーズに
- 「事前に仕込む部分」と「実験余地として残す部分」の設計力向上
- 「一人で自由に演奏→オーケストラでも活躍」の成長実感
- 「70%実装→反応確認→残り30%決定」の実験的アプローチを体得
— この体験は今後の開発にどう活かされそうですか？
この体験は継続しつつ、会社での人との開発にも活かしていきたいと思います。「ここは難しいから論点を整理して計画を立てる」「決めずにテストしよう」といったことがもっとスムーズにできそうです。
会社には「ビジネス検討」というフェーズがありますが、「会社のリソースや人の力を借りてテストしたいことは何か？」「自分一人で企画段階で仕込んでおくべきことは何か？」を整理できるようになりました。社会的制約がある中で、全員を動かすために仕込んでおく部分と、実験として余地を残しておく部分を設計できる。失敗を経験したからこそ、実験を含んだ計画を設計できるという感覚です。
Discussion