プロダクトデザイナーが担当プロジェクトを1から6へ：5つのワークフローと Claude Skill の原文まで公開
- VRフィットネス企業のプロダクトデザイナーが、半年間で同時進行のプロジェクトを1から6へ。イテレーションは数日単位。
- 本人の整理では、AIが変えたのは速度より「1人のデザイナーがカバーできる面積」。ただ本当に有用なのは、5つのワークフローそれぞれに実物スクショが付いている点です。
- いちばん価値あるものは全部スクショの中：Claude Skill の完全な起動条件と出力テンプレ、AIが書いたデータロジック文書、分岐プロトタイプはわずか2フィールドで実装。
何をしたか：半年間で担当プロジェクトが1から6へ
Krystian Zun は VRフィットネス企業 FitXR のプロダクトデザイナーで、0→1プロダクトを8年以上手がけてきました。半年前は一度に1案件だけ見ていましたが、今は6つ同時進行。ブレインストーム、システム論理、プロトタイプ、チケット、進捗更新まで自分で回し、イテレーションは数日単位です。本稿は、この半年で積み上げた5つのワークフローを一気に公開したもの。しかも各セットに実物スクショ付き。Claude Skill の完全定義、AIが生成したデータロジック文書、分岐プロトタイプの実装は、そのまま写せます。
本人の整理はこうです。AIはふつう「同じ仕事をより速く」の加速ツールだと思われがち。1年使ってみて彼が思うのは、その枠組みは的を外しているということ。本当に変わったのは規模——1人のデザイナーがエンドツーエンドで持てる範囲です。速度は副産物。頭が良くなったわけでも、残業を始めたわけでもなく、変えたのは注意力をどこに使うか。残りは AI に渡した、と強調しています。
変化の起点は FitXR。自分がいた中でいちばんテンポが速い場所だった、と彼は言います。最初の数か月は実験を連発し、すぐに壁に当たりました——追いつく方法が要る。それ以来、詰まるたびに同じ問いを自分に投げます。
この仕事に、AIをねじ込めないか？
Krystian Zun
一部を手放せないか。もっと速くできないか。もっと良い結果にできないか。試行錯誤の連続で、AIが役に立たない／むしろ遅くなる／手でやった方が早い場所も見えてきた、と言います。残念ながらその具体例は一つも出てこない。本稿でいちばん惜しい穴で、末尾でまた触れます。
メンタルモデル：AIが伸ばすのはT型人材の「横」
デザイン界には「T型人材」（T-shaped）という古い言い方があります。縦棒はいちばん深く掘った専門——UX、UI、リサーチ、モーションなど。横棒は他領域にまたがって物事を前に進める幅。同じ水準・同じ速度は要らず、仕事を動かせれば足りる、というものです。
AIが伸ばすのはその横棒です。不得意な領域でも、かなり速く動けるようになりました。
ここで彼はかなり正直な限定を置いていて、そのまま覚えておく価値があります。この伸びは領域でも人でも違う。たとえば高品質なビジュアルデザインではAIはまだ弱い——少なくとも彼自身の基準・自分への要求では。一方、デザインに詳しくない開発者がシンプルなランディングをAIに作らせると、十分見られるものが上がってくる、と。
第二層のモデルは「デザイナーの仕事とは何か」。彼は芯まで剥がします。問題を理解し、ビジネス・技術・プロダクトをまたぐ関係と影響を理解し、それらをひとつにまとめる案を見つける。実務では、方向と発想を何度も入れ替え、合った瞬間までイテレートする、ということです。
AIはこのループを速く回します。彼はAIをスケッチや紙プロトタイプのように使う、と言います。成果物そのものが本題ではなく、「当たり前」の層を越えて思考を押し出すことが本題だ、と。
ワークフロー1：週報とチケットは Claude Skill に任せ、彼は承認かスキップだけ
まず前提。ここが写しやすさを決めます。FitXR には従来型のプロダクトマネージャーがいません。プロジェクトとその日常運用は、担当の現場が自分で抱えます。スケジューリング、すり合わせ、チケット作成、進捗更新、マネジメントへの報告——すべて本業のデザイン／エンジニアリングの上に載る。だから自動化できるものは徹底的に自動化する、という姿勢です。
使っている組み合わせは Claude + Skills + Slack・Granola・Linear に繋ぐ MCP。Granola は会議記録ツールで、通話を文字と議事に起こす。Linear はチームのプロジェクト／タスク管理ツールです。
チェーンは3ステップ：
Granola がコンテキストを拾います。チームはリモートで、文脈は Slackスレッド、スタンドアップ、会議通話に散っています。これがあると、会議中はメモに伏せず、本当に場にいられる。週末になると Skill が文字起こしと Slack を走査し、職能・同僚ごとに Linear の進捗更新を下書きします。
2つ目の Skill は「ドリフト」担当。彼らのチームは「Slackで決めたら、もうSlackの外に出ない」ことで悪名高い、とのこと。この Skill は会話と Linear のチケットを突き合わせ、範囲が変わったのに未同期、状態の誤記、決めたのに未記録などをマーク。各提案を本人が一度見て、承認かスキップ——数分で終わります。
今は6案件に同時に巻き込まれています。同じ大きな絵の中でも、細部・難所・断片はそれぞれ違う。数か月前なら、この投入度では1案件しか見られなかった。本人の判断はこうです。全部を手作業で追えば、フルタイム1本分になりやすい。AIは投入と理解の代わりにはならないが、反復的で極端に時間を食う部分は外せる、と。
Skill 原文はスクショの中：起動条件の書き方と出力テンプレ
この節の内容は本文では一言も触れられておらず、上のスクショ中央から読み取ったものです。Skill 名は linear-status-update。起動は「スラッシュコマンド＋自動」。
説明文のほとんどは「いつ出るか」に費やされている
説明の大半は、ユーザーがどう口にするかの列挙です：draft an update for the project、write a status update、update Linear based on slack、write a project update from our meetings、pull together a project update、さらに「任意のソース（Slack、Granola、会議）×任意の行き先（Linear、プロジェクト更新）」の組み合わせ。最後に保険の一文：
直近の動きを Linear 更新にまとめるなら、この Skill を使う。ユーザーが「skill」の語を出していなくても。
スクショ内の Skill 説明、当サイト訳
この書き方自体が学びどころです。Skill を書く人は「どうやるか」に力を注ぎがちで、出るべき場面で呼ばれない。起動条件が具体で、人の実際の言い回しに近いほど、信頼性が上がります。
ステップ3：書き出す前に、何が新しいかを整理
Step 3: Identify what's new
Before drafting, work out:
- What has happened since the last update?
- What decisions were made?
- What was completed? What's in progress?
- Are there any timeline changes, milestone shifts, or blockers?
- Is there any significant engineering or enablement work worth
calling out?
Focus on substance. Ignore noise like channel join messages, bot
notifications, and minor logistics. If something was already
covered in a previous update, don't repeat it.日本語対照：書き出す前に整理する。前回更新から何が起きたか。どんな決定があったか。完了したもの／進行中は何か。タイムライン変更、マイルストーンの移動、ブロッカーはあるか。言及に値するエンジニアリングやイネーブルメントはあるか。実質に集中。チャンネル参加通知、ボット通知、細かい事務はノイズとして無視。前回更新で既に触れたことは繰り返さない。