古いFigmaファイルを開いた
2年前に手作業で作ったFigmaファイルを、久しぶりに開いた。
ある業務アプリの案件。PM、CRM設計、画面遷移、UIモック、全部自分でFigmaに起こした。NestJS、React、Flutter、PostgreSQL、GCP。アーキテクチャ設計も含めて、一人で引いた。
当時、Claude Codeは存在しなかった。
あの頃は全部、手だった
画面ひとつ作るのに、半日かかることもあった。
コンポーネントを並べて、色を決めて、遷移を引いて、余白を整えて。ユーザーの動線を想像しながら、ボタンの位置をピクセル単位で調整する。頭の中にある業務フローを、視覚的に翻訳する作業。
効率は悪い。だが、その非効率な時間の中で、手が覚えていくものがある。
「この画面の前に、ユーザーは何をしているか」「この項目を省いたのは、運用フローで別システムが担うから」「ここに確認ステップを入れたのは、現場の人間が判断を間違えやすい箇所だから」
画面のレイアウトではなく、設計判断が手作業の中に埋まっていく。
チームメンバーの一言
今、あの案件の改修フェーズに入っている。ただし体制は2年前と全く違う。AI 7名のプロジェクトオーナーチームで動いている。
担当メンバーが過去のFigmaファイルを調べながら、こう言った。
「この手作業Figmaに込められたデザイン判断の中に、まだ眠っているコンテキストがある」
正直、背筋が伸びた。
2年前の自分が手で作ったファイルの中に、AIチームがまだ掘り起こしていない設計判断が残っている。画面の配置やボタンの色ではなく、「なぜそうしたか」という意思決定の層。コードには残らない。Figmaのレイヤー構造にも明示されない。作った本人の頭の中にだけある。
それを少しずつ言語化して渡していく。2年越しの引き継ぎだ。
AIに渡せるもの、渡せないもの
AIにFigmaファイルを渡せば、画面は再現できる。レイアウトを解析し、コンポーネントを特定し、コードに変換する。その精度は年々上がっている。
だが、設計判断は再現できない。
「なぜこのフローにしたか」「なぜこの項目を省いたか」「なぜこの画面遷移の順序なのか」。これはFigmaのどこにも書かれていない。画面の見た目の裏にある、業務理解と現場感覚の蓄積。実際に手を動かし、クライアントと会話し、運用を想像した人間にしか持てないもの。
AIが優秀であるほど、この「渡すもの」の質が問われる。指示が薄ければ、アウトプットも薄い。指示に厚みを出せるのは、自分の手で同じ領域を通ってきた人間だけだ。
手作業の本当の資産
12年間、デザインもコードもインフラも企画も、全部一人でやってきた。
その12年で蓄積された「なぜそうしたか」の総量が、今AIチームに渡す設計図の厚みになっている。
2年前のFigmaファイルは、その一部に過ぎない。他にも無数の案件で、手作業で作った成果物がある。それぞれに「なぜ」が埋まっている。古い成果物ほど、自分でも忘れかけている判断が眠っている。
AIの時代に、手作業の経験は無駄になったか。逆だ。手作業でしか得られない設計判断の蓄積こそが、AIを動かすための最も希少な資源になった。
問いの立て方が違う
「AIがあるのに、なぜ手で作ったのか」。この問いは間違っている。
正しい問いは、「手で作った経験がなかったら、AIに何を渡すのか」だ。
AIは優秀なパートナーだ。だが、共に描く設計図の解像度は、人間の側が自分の手でどれだけの領域を通ってきたかで決まる。
2年前のFigmaファイルを開いて気づいた。あれは過去の成果物じゃない。未来のAIチームに渡すための、設計図の原本だった。
手を動かした時間は、一秒も無駄になっていない。