Pixels to Motorsをメソドロジー化する
Pixels to Motorsを始めてLOG167まで書いた。
DAYログを書き、週に数回の記事を書き、実機を動かしながらシミュレーションを回す。この繰り返しの中で、プロジェクトは確実に前に進んでいる。
ただ、ある日ふと気づいた。この積み上げは「私の記録」であって、「他者が応用できるもの」になっていない。
個人プロジェクトとして完結しかけていた。
個人プロジェクトと方法論の違い
個人プロジェクトと方法論（メソドロジー）は、外見は似ている。どちらもログがあり、設計思想があり、試行錯誤の痕跡がある。ただ、目的地が違う。
個人プロジェクトは「自分がどこまで行けるか」が関心事になる。語りの主語は「私はこうやった」。評価軸は作品の質そのもの。
方法論は「他の人が自分と同じように進めるか」が関心事になる。語りの主語は「あなたがこうやれば、こうなる」。評価軸は、他人が再現して成果を出せるかどうか。
リーン・スタートアップ（エリック・リース）、デザイン思考（IDEO）、Working Backwards（Amazon）。これらは全て、特定の個人や企業の内部プラクティスから始まり、再現可能な原則の集合として外部化された瞬間に影響力が跳ね上がった事例だ。
Pixels to Motorsにも、同じことができるはずだと思った。
実は、もうメソドロジーの素材は揃っていた
整理して気づいたのは、プロジェクトの中核にある言葉がすでに方法論の形をしていたこと。
「精度より体験の成立を優先する。精度はあとからお金で解決できる」
これは単なるモットーではなく、優先順位ルールそのものだった。複数の選択肢があるとき、何を捨てて何を取るかの判断軸。リーン・スタートアップの「Build-Measure-Learn」や、アジャイルの「Working software over comprehensive documentation」と同じ構造をしている。
ブランドの三本柱もそうだった。UX × AI × Roboticsの交差点はポジショニング原則、iPhoneを入り口にした低コスト化は参入コスト圧縮の方法論、体験から逆算する設計思想は意思決定ルール。
Claude・Claude Code・Geminiの三役分担も、AI協働のメソドロジーとして独立した価値を持つ。
言語化されていなかっただけで、実践はメソドロジーとして既に機能していた。
方法論として伝わるための5要素
整理してみると、他人に使える形にするには5つの要素が揃う必要がある。
名前。「Pixels to Motors」は既に固有名詞として強いが、「プロジェクト名」から「メソドロジー名」へ格上げする必要がある。英語圏では "The Pixels-to-Motors Method" のように、方法論であることが名前から分かる形にする。
対象となる問題。誰が、どんな問題を解くときに使うべきか。私の場合は「ハードウェア経験が浅いデザイナー／UXエンジニアで、AIロボティクス領域で何かを作りたい人」。これが明確になると、読み手は「これは自分の話だ」と引き込まれる。
段階的な手順。Step 1、2、3と分解する。iPhone＋3Dスキャンで環境をデジタル化する、Unityシミュレーション上で体験を先に設計する、最小構成のハードで実機化する、精度問題はあとから予算で解決する。
判断基準。迷ったときにどちらを選ぶか。設計思想と技術的最適解が矛盾したら、設計思想を選ぶ。新しいハードを買う前に、シミュレーションで検証する。こうしたトレードオフのルール。
失敗と教訓のストック。成功事例だけの方法論は薄っぺらい。LOG83の教訓、LOG162の未解決問題、LOG166のハンドオフ不整合。失敗が豊富にある方法論ほど、読み手に信頼される。
日次ログに組み込む——3層構造で書く
ここからが実装の話。
メソドロジー化は「新しく何かを書き足す」ではなく、「既存のDAYログの語り方を少し変える」で実現できる。具体的には3層構造を意識する。
レイヤー1は事実。何をしたか。既存のDAYログの中心。
レイヤー2は判断。なぜそれを選んだか。複数の選択肢の中で何を採り、何を捨てたか。暗黙知を言語化する層。
レイヤー3は原則。一般化すると何が言えるか。メソドロジーの種になる層。
今までのログはレイヤー1が中心で、2と3は混ざって書かれているか省略されていた。この3層を見出しで区別するだけで、後から方法論として再利用しやすくなる。
運用の持続性が全て
方法論化は、続けなければ意味がない。3ヶ月で息切れしたら、素材は溜まらない。
だから運用ルールは軽めに設計した。週2回のペースで原則を書く。月・木を目安にするが、書けない日はスキップ。無理に絞り出した原則は薄いので、書かない勇気が重要。過去のDAYログを遡って原則を抽出する作業はしない。これから書くものだけ蓄積する。
原則のインフレも避けたい。週1個でも、強い原則が出た週は成功と見なす。量より質で、1年かけて20〜30個の骨太な原則が残れば、それで"The Pixels-to-Motors Method"として外部化できる状態になる。
既存の信条を、P001として登録した
プロジェクトに principles.md と day_log_template.md を追加した。
最初の原則P001として登録したのは、もちろん「精度より体験の成立を優先する」。新しく考えたのではなく、プロジェクト開始時からの信条を、方法論として形式化しただけ。
P002はLOG166の学びを形式化した「ハンドオフ文書は各レイヤーの状態をバイナリで明示する」。P003は「実機で試す前にシミュレーションで検証する」。P004は三役分担のルール。
最初の7個は、全て既存の実践を言語化しただけ。新しい思考を絞り出す作業ではなく、既にある暗黙知の整理。だから負担は軽い。
これからの運用では、「P001が今日も効いた」と既存原則の適用事例を記録するだけの週があっても構わないと思っている。原則は一度書いて終わりではなく、繰り返し適用される場面を示すことで強度が増していく。
海外との接続という、隠れた文脈
正直に書いておくと、このメソドロジー化には、もう一つの動機がある。
日本国内でのフィジカルAIの盛り上がりは本物だが、政治的には外国人誘致の論点が急速に難しくなっている。高度人材の日本への流入は数年単位で不確実な状況にある。
その中で、個人レベルで取れる戦略は国境の外側にネットワークを持つことだ。LinkedInで英語発信を続け、海外のHCI研究者やロボティクスエンジニアと接続しておく。国内政策の揺れに影響されにくいポジションを自分で作る。
その発信を「個人プロジェクトの日記」として英訳しても、刺さらない。「方法論」として発信できれば、海外の実践者から「うちのチームに応用できるか」「共同研究できるか」という実務的な対話が生まれる可能性が上がる。
メソドロジー化は、国内向けの整理であると同時に、国外との接続を作るためのフォーマット変換でもある。
蓄積を、次のフェーズに渡す
167日かけて積み上げてきた暗黙知を、次の100日で形式知に変えていく。
実機を動かすという本体の作業は変わらない。変わるのは、その作業の語り方だけ。
個人プロジェクトから方法論へ。この転換を、これから週2のペースで進めていく。
