Open2

【作業ログ】どう作ろう3_ゲームから始まるタスク管理ツール

初心者
個人開発
学習
ログ
作業
yy

やったこと

https://zenn.dev/incapablean/articles/3cb9d08cb639ba

ゲームコンテンツの作成とテスト

  • great, good, failゾーン生成
  • 各ゾーンランダム生成
  • バー進行

実装の作業内容と作業時間

このアプリの総制作時間は8Hで設定したところ、現段階で8H経過。

原因

TDDによる開発手法を知らない、分からない、慣れていない

時間経過による問題

価値があるか分からないものにコストを掛けている

対策と方向転換

  • 学習に比重を置き、時間がかかることはあきらめる（今後の開発時間短縮のための投資）
  • 自前でコードを読み書きすることに、時間制限を設ける。以降はChatGPTによるコード生成に頼る（が、理解することには時間をかける）

考えたこと

ChatGPTによるコード生成の恐怖

  • 簡単なプロンプトで自分の力量以上のコードが作れてしまう
  • さらにそのコード読んでいくとまるで理解したかのように感じてしまう
    👉実際に同じものを書こうとすると書けない（本当の理解に達していない）ため、学習目的としては問題あり。
  • もちろんこれはChatGPTの使い方に問題あり。もっと深い理解へ到達するための使い方をしなければならない。
  • また単純にCSの基礎学習は常に必須

次にやること

ゲームコンテンツの作成とテスト

  • ゲーム画面の描画
  • ゲームコントローラー
  • スコア計算
yy

ChatGPTによるフィードバック

いいまとめです —思考が整理されていて、問題認識・原因・対策まで一貫しているのが素晴らしいです。以下、妥当性の評価・批判（改善点）・発展のための水平思考的アイデア（創発案）、そして**具体的な次アクション（実務）**を出します。ChatGPTを学習補助に使うための「安全な使い方」やTDDを学ぶための実践プランも含めます。長めですが実践で使える内容に絞りました。

1) 現状評価（妥当性）

  • 問題把握：TDDに慣れていない → 妥当。TDDは習得に時間がかかるし、最初は遅く感じるのが普通です。
  • 対策の方針（学習に比重／ChatGPTに生成補助を頼る）は合理的：学習投資で将来の速度向上を図るのは正しい選択。ただし「以降はChatGPTに頼る（理解は続ける）」の運用ルールが曖昧だと、理解不足のまま依存してしまうリスクがあります。
  • 時間管理の問題認識（価値不確実な作業にコストを掛けている）：的確。早期に小さく価値検証（MVP）すると良い。

2) 建設的批判（改善点・注意点）

  1. 学習に“全部”振るのはやりすぎる危険

    • 学習も重要だがプロダクトを少しずつ動かす（リリースableな小さなインクリメント）ことはモチベーション維持とフィードバック獲得に必須。

  2. ChatGPT生成コードの“受け取り方”が弱い

    • 「動いた」＝「理解した」ではないという自己認識は正しい。だが放置すると技術負債になる。生成されたコードを自分で改変して壊して直す訓練を必ず組み込むべき。

  3. TDDを学ぶ方法が不明瞭

    • 単に「TDDを学ぶ」と言うだけでなく、非常に小さな機能単位で学ぶ（例：バーがクリックで止まる）ことを推奨。

3) 実践的アドバイス（すぐ出来ること・やり方）

以下は「学びながら前に進む」ための具体アクション群。どれも今のゲームに直接応用できます。

A. ミニTDDサイクル（1機能の例）

対象：クリックでバーを止める機能（まずはこれだけをTDDで作る）

  1. Fail（赤）を書く（テストを書く）

    • テスト例（pseudo / Jest + DOM）：
test('クリックでバーが停止する', () => {
  // 初期化
  const bar = new ProgressBar();
  bar.start();
  // クリック（シミュレーション）
  bar.clickStop();
  expect(bar.isMoving()).toBe(false);
});

  1. Green（実装して通す）

    • 最小限の実装（start, clickStop, isMoving）だけ実装してテストを通す。

  2. Refactor（改善）

    • コードをリファクタ、命名改善、重複排除、もう一度テスト確認。

ポイント：最初はDOMを直接触らず、**ロジック部分（純粋関数・クラス）**を先にテストする。DOM連動はその後で結びつける。

B. 具体的に書くべきテスト群（優先順位）

  • ゾーン生成ロジック

    • 各生成で great/good/fail の割合が期待範囲に入る
    • 隣接ゾーンが重ならない／最小幅を保つ

  • バー進行ロジック

    • 進行は一定速度で増える（シミュレーションで増分を検証）
    • 端まで到達したら fail と判定

  • 停止操作とスコア

    • クリックで停止 -> zone 判定 -> スコア反映
    • 連続クリックでスコアが二重に入らない

  • 再現性（テスト向け）

    • RNGにシードを入れて deterministic に（テストが安定）

C. ChatGPTを“教育ツール”として安全に使うワークフロー

  1. テストファーストのプロンプトを出す

    • 「この機能のためのJestテストをまず書いて。テストが失敗する状態で出力して」→そのテストを実行・確認。

  2. 小刻みに実装させる

    • 「最低限の実装だけを書いて。次にリファクタ案を出して」→自分でリファクタを試す。

  3. コードの意図説明を求める

    • 「この関数は何をしている？1行ずつ日本語で説明して」→理解チェック。

  4. 誤りを意図的に入れさせる

    • 「この実装にバグを一つ入れて。どこを直すべき？」→デバッグ訓練。

  5. 再実装課題

    • 生成コードを“いったん閉じて”自分で同じ機能を実装してみる（タイマー or 控えめな制約付き）。

D. 学習・理解を深めるための“アクティビティ”

  • リバースエンジニアリング：ChatGPT生成コードを一度手でコメントアウトし、各ブロックの役割を日本語で書く。
  • コード・カラオケ：声に出してコードを説明しながら書く（Rubber ducking の進化形）。
  • 写経＋変形：生成コードを写経した後、変数名／アルゴリズムを変更して同じ動作を保てるか確かめる。
  • ペアプログラミングの疑似体験：ChatGPTに「あなたはペアの相手。僕が書いたコードのレビュー15行以内で改善点3つ挙げて」と指示する。

4) 次にやること（実務的チェックリスト）

（時間は示しません — ユーザーのペースで進めてください）

  1. ゲーム画面の最小描画（まずは見える形で動くもの）

    • プレイフィールド、バー、ゾーン（視覚的に分かる）を描く（canvas or DOM）。
    • 描画はロジックと分離（Renderer と GameLogic）。

  2. ゲームコントローラー（入力）

    • 入力イベント（クリック／キーボード）を Controller が受け取り、GameLogic に伝える設計。
    • Controller はテスト可能にする（イベントの”シミュレーション呼び出し”で動作確認）。

  3. スコア計算と表示

    • ScoreManager を作る（得点ルールは関数化して単体テストを用意）。
    • スコア表示は Renderer が参照するだけ。

  4. テスト第一で1機能ずつ

    • 上の「ミニTDDサイクル」を繰り返す。ゾーン生成→バー移動→停止→スコア。

  5. テスト環境を整える

    • Jest + jsdom（フロントロジック）か、もし純粋ロジックなら Node 環境でテスト。

  6. CI（任意）

    • GitHub Actions 等で npm test が動くようにしておくと成長を視覚化できる。

5) 水平思考的（発展）アイデア — 斜め上を行く提案

  • ゾーン・エディタを作る：エディタ画面でゾーン位置を手でセット → 保存 → テスト用シナリオを作る。学習とデバッグが捗る。
  • シード付き再生機能：RNGにシードを入れ、同じシードで再現できるデバッグモード（テスト安定化に有効）。
  • 難易度自動設計：プレイヤーの失敗率に応じて great/good/fail の幅を動的に調整する実験をしてみる（A/Bテスト）。
  • 可視化ツール：時間軸でバー位置・ゾーン位置をプロットするデバッグビュー（問題箇所が一目で分かる）。
  • プロパティベーステスト（fast-check等）：色んなランダム入力で仕様が壊れないかを検証する。
  • Accessibility / Keyboard-first：モバイルだけでなくキーボード操作やスクリーンリーダ対応を早めに考えると良い。

6) ChatGPTに投げるべき具体プロンプト（テンプレ）

  • 「Jestで『クリックでバーが止まる』テストを書いてください。DOM操作は最小限にしてクラス ProgressBar のメソッドだけテストする形で。失敗テストを見せてください。」
  • 「上のテストを通すための最小実装（ProgressBar）をES6クラスで作って。各メソッドを日本語で1行ずつ説明して。」
  • 「生成された実装に意図的にバグを入れて。それを修正するためのデバッグ手順（console.logをどこに置くか）を示して。」
  • 「この ZoneGenerator のロジックを、RNGシード対応で deterministic に書き換えて。サンプルシードで期待出力を教えて。」

7) 最後に — まとめ（要点）

  • あなたの方針（学習に比重を置く）は合理的。ただし小さく動く成果物を同時並行で残すこと（学習のモチベ維持と価値検証）を強く推奨します。
  • ChatGPTは「コードを作る先生」ではなく「コーチ兼短期アシスタント」として使うと学習効果が高い：テストを書かせる → 実装させる → 説明させる → 自分で再実装 のループを回してください。
  • 実務的には「Renderer / GameLogic / Controller / ScoreManager / ZoneGenerator」の責務分離をまず行い、各モジュールを小さくテストしていくと失敗が見えにくくならず学べます。