手放すほど、自分が立つ -非エンジニアがコードを書く現場で見つけた「判断の手触り」-

マーケティングリサーチャーだった僕が、ある日開発チームに放り込まれた。開発経験ゼロ。1年間CursorやAIを触り倒した結果、ある逆説に気づいた。手放せば手放すほど、自分の輪郭がはっきりする。

これは、その1年間で見えたものの話だ。

プロローグ｜Cursorの画面を前に、指が止まった

「これ、僕が触っていいんですか？」
開発チームに合流した初日、目の前のCursorというコードエディタを開いて、最初に出た言葉がそれだった。
画面の左側にはファイルツリーがズラッと並び、右側にはコードがびっしり詰まっている。何かを触ったら全部消えるんじゃないか。変なところをいじって情報漏洩でも起きたらどうしよう。キーボードの上で、指が止まっていた。
マーケティングリサーチャーとして4年半。調査設計、分析、報告書。そういう仕事をずっとしてきた人間が、なぜか開発チームにいる。「リサーチの視点が必要だから」と言われたけど、周りはエンジニアばかりで、飛び交う会話の半分も理解できなかった。JSON？ GitHub？ プルリクエスト？
AIはエンジニアのものだと、本気で思っていた。
それから1年。僕はチームの中でも相当な頻度でAIを触り倒し、自分でプロトタイプを作り、ユーザーテストまで回すようになっていた。その過程で、ひとつの感覚にたどり着いた。
AIに任せられる仕事と、どうしても自分でやらなきゃいけない仕事がある。その境界線にあるのは、スキルでも経験年数でもなかった。何度もAIの出力を手直しするうちに、画面を見つめたまま手が止まる瞬間が増えた。「何か違う」とは分かるのに、何がどう違うのか言葉にならない。椅子の背もたれに体重を預けて、天井を見て、もう一度画面に戻る。その繰り返しの中に、確かに何かがあった。判断の手触りとでも呼ぶしかないものだった。
この記事は、AIに仕事を取られる、AIはエンジニアのもの、と怯えていた非エンジニアの1年間の記録だ。そして、手放した先に見えてきた、少し不思議な逆説の話でもある。

1章｜AIに任せられなかった、本当の理由

「それ、AIでよくない？」
開発チームに合流して間もない頃、調査票の設計をしていたときに言われた一言だ。
正直に言う。イラッとした。
調査票設計は、見た目はシンプルだけど、実はものすごく頭を使う仕事だ。回答者の負荷を考えながら、商材の特性に合った設問を組み、最終的なアウトプットから逆算して項目を設計していく。複数の視点を同時に走らせないと成り立たない。
AIでもある程度のものは作れるかもしれない。それは冷静に分かっていた。でも「よくない？」と軽く言われた瞬間、自分の中で何かがザワッとした。
今振り返ると、あのザワつきの正体は取られる恐怖だったんだと思う。でも、もっと正確に言うと存在の確認が脅かされた感覚に近い。
一番キツかったのは、周りがどんどんAIを使いこなしているように見えたこと。同じチームにいるのに、自分だけ別の世界にいる感覚。ランチの会話でGitHubの話題が出るたびに、笑顔でうなずきながら内心焦っていた。あの頃の自分は、何に対して焦っているのかすら整理できていなかった。
そして当時気づいてなかったんだけど、もう一つ重要なことがあった。自分の仕事の境界が曖昧だから、余計に手放せない。どこまでが自分で、どこからがAIに渡せるのか、その線引きができてない人間は、全部を握りたくなるんだ。
合流前の自分は、AIを何度か触ってみては使いこなせないと思っていた。リサーチの企画段階で試しても出力がなんか違う。分析の補助に使っても微妙にズレてる。やっぱり自分でやった方が早いと、結局自分の手に戻していた。
でも今思うと、それは効率の問題じゃなくて、手放すのが怖かっただけなんだよね。自分の手を離れた瞬間、それは自分の仕事じゃなくなる気がした。最終チェックには必ず人の目を入れておきたいという感覚。それ自体は間違ってないんだけど、その感覚が自分の仕事の全部に広がっていた。何もかも自分の手で握っていないと不安だった。
仕様書をNotion AIで何度も壁打ちして叩き上げていたとき、ふと気づいたことがある。AIと対話すればするほど、自分が何を求めているのかが鮮明になっていく。「違う」と言い続けることで、「じゃあ自分は何が正解だと思っているのか」が輪郭を持ち始める。
たとえば仕様書の構成をAIに3パターン出させたことがある。どれも筋は通っていた。でも「これじゃないんだよな」と感じる自分がいる。じゃあ何が違うのか。言語化しようとして初めて、自分はユーザーの行動フローを起点に考えたいんだという軸に気づいた。AIがなければ、その軸は無自覚のまま埋もれていたと思う。

2章｜職能の接合点で、何が起きたか

転換のきっかけは、自分の決意じゃなくて環境だった。
事業部が非エンジニアにもAIコードエディタのCursorをほぼ上限なく使っていいという方針を出した。「触ってもらった方が会社としても嬉しい」と言ってもらえたことで、僕の中にあったエンジニアの領域に踏み込んでいいのかという遠慮が、少しだけ溶けた。振り返ると、あの環境がなければ今の自分はいない。「触っていい」と言われることと、実際に触る勇気は別物だけど、少なくとも入り口は開いた。
最初の決意はシンプルだった。上手に使おうとしない。分からないことをその場でAIに聞く。それだけ。
もちろん、怖さが消えたわけじゃない。最初のひと月は、AIが出力したコードをそのまま貼り付けて動かなくて、何時間も原因が分からなかった。エラーメッセージを読んでも意味が分からない。隣のエンジニアに聞くのも申し訳ない。やっぱり自分には無理だ、と何度も思った。
それが少しずつ変わったのは、エラーをAIに「これ何？」と聞けばいいと気づいてからだ。エンジニアへの質問も「ここまでは調べたんですけど」と前置きできるようになった。質問の精度が上がると、返ってくる答えも変わる。

言語の壁が、関心の壁になる

周りが話すGitHubやプルリクエストについて最初は半分も理解できなかった。でも知らないことを知りたいと思えたかどうかで、その後がまるで変わった。
知らないことを知りたいと思えなかったら、開発チームの分担表に名前があっても視界から外れる。言語の壁は、すぐに関心の壁になる。僕は知らないが知りたいに変わった瞬間に、接合点に立てるようになったと思う。エンジニア会話で気になった単語をその場で調べ、Notionにメモを貯める。すぐに理解できないことはAIに要約させて、足場を固めていく。この積み重ねが、気づけば自分の中で当たり前になっていた。

プロトタイプが、通訳になる

3ヶ月目の金曜日、夕方の定例で自分が作ったプロトタイプをチームに見せた。「え、これTKさんが作ったの？」。コードの品質がどうとかじゃなくて、リサーチャーが仮説を動くものにして持ってきたこと自体が新しかったらしい。
ある日、Notionで壁打ちした仕様書からプロトタイプをいくつか作った。そこにDify（AIアプリを組み立てられるローコード開発ツール）を使ってAIを吹き込み、ユーザーに実際に触ってもらって検証も回した。仮説を試作にして、試作を検証に繋げる流れを1人で回せるようになったとき、自分のリサーチスキルとAIの実装力がセットになって、業務と技術の間を通訳し始めたと感じた。
以前は「この機能がほしい」と言葉で伝えるしかなかった。今はプロトタイプを添えて「こういうイメージです」と見せられる。たとえば「この機能、技術的にはできるけどサーバーコストが月○万増えますよ」という話に、以前は頷くしかなかった。今は「じゃあこっちの実装なら軽くなりませんか」と返せる。正解じゃないかもしれない。でも会話のテーブルに座れている。それだけで提案の通り方がまるで違う。

エンジニアが、僕に質問するようになった

モックを作り、試作を繰り返していくうちに、開発チームとの距離が変わった。最初はリサーチの人という枠で見られていたと思う。でも一緒にものを作る回数が増えたとき、枠が外れた。水曜の午後、あるエンジニアが画面を共有しながら、少し困った顔で聞いてきた。「この入力フォームのバリデーション、どのタイミングで出すのがユーザー的に自然ですか？」。技術の話じゃなくて、ユーザーの行動を聞かれている。これまでの調査設計で積み上げた回答者の動線感覚が、ここで求められていた。
「ここの仕様、TKさんはどう思います？」と聞かれるようになったとき、自分はこのチームの一員になれたんだと感じた。
ただ、全部が報われたわけじゃない。自分で作ったツールが製品にならないこともある。他の人が使うこともない。もったいないなと正直何度も思った。でも、触り倒して一番残ったものは、新しいスキルじゃないし、浮いた時間でもなかった。一緒に作る中で「この人に聞こう」と思ってもらえる関係性ができたこと。それが、自分の立ち位置を変えた一番大きなものだったと思う。

3章｜開発チームでしか磨けない「判断の手触り」

AIの出力を見て、「合ってるけど、これじゃない」と感じたことが何度もあった。
でも一度だけ、その違和感を無視したことがある。
チームの定例で共有するサービスの機能要件を、AIにまとめさせたときだった。木曜の夜、翌朝の定例に間に合わせなきゃいけなくて時間が押していた。出力をざっと読んで、まあ要点は合ってるだろう、とほぼそのままPMとチームに共有した。定例が始まってすぐ、PMが資料を見ながら言った。「この優先度の根拠、このまま進めていいの？」。血の気が引いた。読み返したら、AIがまとめたデータ解釈が微妙にズレていた。数字は合っている。でも文脈を踏まえた「意味づけ」が、自分のものじゃなかった。
あの夜、修正版を書いていた。PMの「このまま進めていいの？」がずっと頭の中で鳴っていた。悔しいとか恥ずかしいとか、そういう単語じゃ足りない。自分が出したものを、自分で信じ切れてなかったのに出した。その後ろめたさが一番重かった。コーヒーが冷めていたことに、1時間くらい経ってから気づいた。
あの夜を境に、合ってるけど、これじゃないという違和感を、絶対に無視しなくなった。

動くものにしないと通らない環境

見た目が思っていたのと違う。ここにボタンがあったら動線的に不便。全体のトーンが自社のブランドに合っていない。最初はその違和感をうまく言語化できなかった。でも何度も向き合ううちに、自分でブランドのデザイン基準をAIの参照先として接続し、こう作れという基準を設計する側に回っていた。
不満を感じた。だから自分で基準を作った。
この動きの中にこそ、「手触り」がある。
でも気づいたのは、これが開発チームにいるから見えたことだってこと。プレゼン用の資料ならまあいいかで済ませた違和感が、開発チームではそのまま通らない。エラーを出したら動かない。レビューで指摘される。誰かが利用する前提で作る環境で、自分のまあいいかは即座に剥がされる。
単独で働いてると、曖昧な判断はずっと曖昧のまま残りやすい。でも「動くものにしないと通らない」環境では、違和感を無視する選択肢がない。たとえばプロトタイプの画面で「このラベル、もう少し優しくできないか」と感じていた違和感を、前の職場なら言語化できないままにしていた。でも開発チームではレビューで「ここ、違和感あるよね」と先に指摘される。誰かに見られる環境で作ることで、自分の中のぼんやりした感覚が急に輪郭を持って返ってくる。自分一人じゃ絶対にここまで磨けなかった。他人の目が自分の感覚を鍛えてくれる。開発チームは僕にとって、そういう環境だった。
もう一つ覚えているのは、ユーザーテスト用の調査票をAIに作らせたとき。出力された設問は一見まともだった。でも回答者が3問目あたりで飽きる構成になっている。設問の順番、選択肢の粒度、自由記述欄の位置。これまでの調査経験で身体に染み込ませた回答者の呼吸みたいなものが、AIの出力には抜けていた。自分で直した。直しながら、ああこれが自分の仕事なんだと思った。
判断の手触りという言葉は、最初からあったわけじゃない。1年間を振り返ったときに、ようやく名前がついた概念だ。あの合ってるけど、これじゃないと感じ続けた違和感の蓄積が、この言葉になった。最初は単にAIがイマイチなんだと思っていた。でも違う。AIが80点を出せるということは、80点の能力はあるということだ。残りの20点にこそ、自分の判断が詰まっている。
手触りがある仕事には、共通する性質がある。言葉にすると当たり前に聞こえるかもしれない。でも、体で分かるまでに1年かかった。
まず、文脈が身体に入っていること。商品企画の背景、会議の空気、話し手のトーン。テキストにならない情報を、自分が経験として持っている。これまでの案件の蓄積でしか語れないサービスの全体像とか、営業が実際に現場で使うとしたらどうなるかとか。そういう言語化は、自分の身体を通さないと出てこない。
判断の根拠が完全には言語化できないこと。これが一番もどかしい。なんとなくこっちが正しいという感覚の奥には、過去の案件で培った構造化の勘みたいなものがある。何百回と繰り返してきたこの情報はここに置くべきだという感覚。データとして抽出できるものじゃなくて、経験として身体に染みついたものだ。
あとは、結果に対する覚悟だ。間違ったら自分が責任を負う。その重みが判断の質を変えるんだと思う。あの定例の事故のあと、もう二度とAIのまま出さないと決めたときの覚悟は、誰にも代われないものだった。AIは、指摘しなければ同じミスを何度でも繰り返す。だけど僕は繰り返さない。あの夜の冷めたコーヒーの味が、まだ残ってるから。
開発チームで1年間一緒に働いて気づいたのは、これが職種を問わないということだ。エンジニアにも手触りがある仕事とない仕事がはっきり分かれていた。アーキテクチャの根幹に関わる判断には手触りがあるし、定型的なコーディングにはない。手触りは職種に宿るんじゃなくて、仕事の性質に宿る。あるエンジニアが「定型処理はAIに任せるけど、認証周りの設計は絶対に自分でやる」と言っていた。理由を聞いたら、少し間を置いて「一個ミスったら全部崩れるから。そういう仕事は、自分の手で確かめないと怖くて夜眠れない」と言った。その「怖い」は、僕が調査票の設問順を組み替えるときに感じる怖さとまったく同じだった。逆に、議事録の整理やデータの転記は、エンジニアもリサーチャーも「AIでいい」と口を揃える。手触りがない仕事は、誰がやっても同じだから。
逆説的なんだけど、AIに渡せる仕事を渡せば渡すほど、自分の輪郭がはっきりしていく。手放した分だけ、これは自分じゃなきゃダメだという部分が浮き彫りになる。取られるんじゃない。余計なものが剥がれて、芯だけが残る。そういう感覚に、少しずつ近づいている。

4章｜開発チームが教えてくれた問い

この1年を経て、自分の中に3つの問いが残った。
①これは僕の判断か、それとも作業か。
開発チームには、よく似た問いがある。「これは実装の問題か、それとも要件の問題か」。技術的な骨子なのか、それとも実現したいことの定義なのか。実装を任せて、要件を握る。エンジニアが常に分けて考えているこの問いは、僕の「判断か作業か」と形は違うけど、構造は同じだった。
データの集計やグラフの作成は作業だった。でも、どのデータを見せるか、どの順番で伝えるかは判断だった。その線引きが見えた瞬間、肩の力がふっと抜けた。ああ、全部を握らなくてよかったんだと。
②AIが作ったもので満足できるか。
AIが作ったもので満足できるなら、それは誰の手でも同じ仕事だったということだ。満足できないなら、そこに自分の手触りがある。僕はAIが作った調査票を見て、満足できなかった。だから直した。そこにこれまでの調査経験があった。
③なぜチームは自分に聞くのか。
スキルや経験年数じゃない。この人じゃなきゃ出せない判断があるからだ。あのエンジニアがバリデーションのタイミングを僕に聞いたのは、技術的に難しかったからじゃない。ユーザーの動線を身体で知っている人間の判断が必要だったからだ。
3つとも即答できるなら、その仕事には手触りがないのかもしれない。でも1つでも詰まるなら、そこにあなたの手触りがある。
判断の手触りは、最初から持っているものじゃない。触って、任せて、違和感を覚えて、取り戻す。そのサイクルを回した先に、少しずつ輪郭が見えてくる。僕は1年かかった。でも最初の一歩は、1日でいい。

1年前、Cursorの画面を前に「これ、僕が触っていいんですか？」と聞いた自分に、今なら答えられることがある。
触っていい。
むしろ、触らないと見えないものがある。
思い返せば、僕が最初にやったことは「上手に使おうとしない。分からないことをその場でAIに聞く」、それだけだった。事業部がCursorを上限なく使っていいと言ってくれた環境はありがたかった。でもあの一歩自体には、環境は要らなかった。
僕はたまたまマーケティングリサーチャーだった。でもこれは営業でも経理でも人事でも同じだと思う。どの職種にも、その人にしかない手触りがある。AIはそれを奪わない。むしろ浮き彫りにしてくれる。
手放した分だけ、自分が立つ。触った分だけ、自分の手触りが見えてくる。AIはエンジニアのものじゃない。あなたの手触りを見つけるための道具だ。

#創作大賞2026  #ビジネス部門