子どもの頃に携帯を壊した——そこから「デバッグ」という考え方と開発の土台が育った話。
「開発」という言葉を知るより前に、私はもうシステムを分解しはじめていた。
はじめて携帯を壊したのは小学5年生のとき。当時使っていたのは Symbian という OS が載った古い Nokia——スマートフォンが広まる直前、まだ指ではなく爪やスタイラスで操作していた世代の機械でした。
当時は何もわからないまま、ただ「システムを更新したら何が変わるんだろう」と試した。結果はあっけなく——アップデート失敗、文鎮化。OS は起動せず、ロゴ画面で固まったまま動かなくなりました。
正直、怖かった。でも諦めるよりも先に、別の気持ちが湧いてきた——「なぜ死んだのか? まだ救えるんじゃないか?」。知識はなかったけれど、「壊れる手順があるなら、その逆をたどれば直せるのでは」という直感だけがあった。
フォーラムを何度も漁り、見よう見まねで手を動かし——本当に蘇生に成功した。そのとき味わったのは、それまで知らなかった感覚だった。
エラー → 原因 → 検証 → 修復 → 成功。先生も教科書もなく、すべて自分で手探りして理解した一連の流れ。この瞬間から私は「エラーが理解できるものに変わる」感覚に取り憑かれた。
中学に上がる頃、それを入り口にして、貯めたお金で中古の HTC HD2 を買い、本格的に「ROM 焼き(カスタムROMの書き換え)」の世界に入っていった。
HTC HD2 は当時もっとも伝説的な端末のひとつ。元は Windows Mobile——旧世代の最後の輝き——を積んでいたが、ハードが優秀だったおかげで Android、Windows Phone、さらにはデュアルブートまで焼き込めた。私はただ、システムごとの違いを自分の手で体験したかった。
私は単に「改造で遊びたい」わけではなかった。なぜ違いが生まれるのか、なぜある ROM は速く、ある ROM は遅いのか——その理由が知りたかった。
ROM 焼きは、私にとって最初のデバッグ練習場だった。失敗するたび、起動しなくなるたびに、私はこう動いた。
原理は知らず、感覚と試行錯誤だけが頼り。けれど一回ごとの失敗を学習の機会として積み重ねるうちに、自分なりの「非公式だが効く」エラー対応パターンが育っていった——どう壊れるか、だいたいどう救えるか、どの手順が一番事故りやすいか。
気づけば、私はただ ROM を焼くのが好きなのではなく、エラーの裏にある原因を分解するのが好きなのだった。一台を救うたびに、それは「直した」だけでなく、システム全体の動き方をより深く理解できた、ということだった。
私はシステムの「壊れ方」から入り、そこを逆算してどう動いているのかを読み解くのが好きだ。ROM 焼きを通じて、ひとつひとつのエラーには文脈があり、救えた一台ごとに「構造・ロジック・相互作用」とは何かが少しずつ見えてきた。
中学の頃にはお小遣い稼ぎとして、人の端末を改造する仕事も受けていた。ノートパソコンを持って客先(よく喫茶店)まで出向き、その場で目の前で改造する。途中で何が起きても臨機応変に対応し、同時に接客もこなさなければならなかった。
振り返れば、これが人生で最初の仕事だった。技術だけでなく、突発対応や人とのやり取りまで、ここで得た経験は小さくない。
そして今に至るまで、私はこのやり方で少しずつ学び続けている。純粋な CS 出身ではないけれど、Game Design の Higher Diploma で基礎的なプログラミングと Unity でのゲーム開発に触れた。本当に私を伸ばしたのは、授業の外で延々と続けた独学・実験・失敗して直す、という過程だった。
ツールを学ぶのに近道はなく、ほとんどは自分で試して掴んだ。機能が作れないたびに、一歩ずつ検証し、資料を調べ、何度もデバッグして「なぜ間違うのか」をはっきりさせる。
コードは教科書通りの構造ではないかもしれない。それでも、まず機能が確実に動き、安定して動くことを確かめてから、構造を整え直し、自分で理解・保守できる状態に持っていく。
私は「エラーを分解すること」がとりわけ得意で、プロトタイプで解法を試す癖がついている。デバッグに成功するたび、それは私にとって単なるバグ修正ではなく、システム全体の動き方をより深く理解する瞬間だからだ。