【マイレース開発記録(29)】自分の特性と開発スタイル
Yokoこのシリーズでは、Webアプリケーション「マイレース（My Race）」の開発過程を記録しています。
今回は、コードや機能の話から少し離れて、「自分の特性と、どのような開発スタイルを選んだのか」
について書いてみたいと思います。
このテーマは、私にとっては単なる内省ではなく、AIとの共同開発という形を選んだ理由とも深く関係しています。
発達特性と、開発の難しさ
私は発達特性の影響で、いくつかの課題を抱えています。
例えば、
- 細かな誤記やケアレスミスが起きやすい
- 情報量が増えると整理が難しくなる
- 思考が頭の中で散らばりやすい
といった点です。
プログラミングという仕事は、一見すると論理的で整理された世界のように見えます。
しかし実際には、
- 多くのファイル
- 複雑なロジック
- 非同期処理
- フロントエンドとバックエンドの連携
など、同時に扱う情報量が非常に多い分野でもあります。
過去にプログラマーとして働いていた頃、私はこの情報量の多さの中で、「常に追いつかなければならない」という感覚を持っていました。
その結果、努力を続けるほど疲弊してしまい、一度この世界から離れる決断をしました。
思考を「外に出す」開発
今回マイレースを開発する中で、私は一つの方針を意識していました。
それは、
思考を頭の中に閉じ込めないことです。
具体的には、
- ロジックを文章として書き出す
- 小さなコード単位で検証する
- 結果を見ながら構造を整理する
という方法を繰り返してきました。
例えば、今回のアプリでは
- レースロジック
- ゾーン判定
- メッセージ生成
- Canvas描画
など、複数の要素が連携しています。
最初から完成形を目指すのではなく、
- 小さく動かす
- 問題を確認する
- 修正する
というサイクルを繰り返すことで、徐々に全体の形を作っていきました。
AIとの対話がもたらした整理
この開発スタイルを支えてくれたのが、AIとの対話です。
AIを使うことで、次のようなことが可能になりました。
- ロジックを言語化して整理する
- エラーの原因を段階的に検証する
- コードの構造について意見を聞く
ここで重要なのは、
AIにコードを書いてもらうことではありません。
むしろ、
- 自分の考えを説明する
- AIの提案を読み直す
- 必要な部分だけを採用する
という形で、思考を整理するための対話相手として使うことが中心でした。
このプロセスは、私にとって非常に大きな変化でした。
以前は、行き詰まったときに「どこから直せばいいのか分からない」という状態になることが多かったのですが、AIとの対話を通じて、
- 問題を分解する
- 仮説を立てる
- 一つずつ確認する
という流れを作れるようになりました。
デバッグという「思考の訓練」
今回のプロジェクトでは、いくつものバグや設計ミスにも遭遇しました。
例えば、
detect_zoneの二重定義- ゾーン判定の条件の混乱
- Canvas描画のズレ
- メッセージロジックの不整合
などです。
こうした問題に向き合う中で、デバッグという作業が、単なる修正ではなく、
思考を整理する訓練
であることを実感しました。
問題が起きたときには、
- 何が起きているのか
- どこで起きているのか
- なぜ起きているのか
を順番に確認します。
このプロセスは、AIとの対話とも非常に相性が良く、自分の思考を言語化する習慣につながりました。
自分に合った開発スタイル
今回の開発を通して、私は自分に合った開発スタイルが少し見えてきました。
それは、
- 小さく作る
- 検証する
- 構造を整理する
という方法です。
一気に完成させるのではなく、段階的に形を作っていくことで、
- 理解を深めながら
- バグを減らしながら
- 再現性のある形で
開発を進めることができました。
発達特性は、ときに困難を生む要素でもありますが、
同時に、
- 細部を確認する習慣
- 構造を言語化する姿勢
につながる面もあると感じています。
AIとの共同開発は、そうした特性を補いながら、思考を整理し、開発を前に進めるための環境になっています。
次回予告
次の記事は、
として、
- 一人でも開発を進めるための環境
- AIとの壁打ちの使い方
- 小さな検証を積み重ねる方法
について書く予定です。
マイレースの開発は、単なるアプリ制作ではなく、自分の開発スタイルを再構築するプロジェクトでもありました。
この記録が、同じように試行錯誤しながら学んでいる人にとっても、何かの参考になればうれしく思います。
＼ 最新情報をチェック ／
