こんにちは。2026年6月にウォンテッドリーへ新卒で入社し、iOSエンジニアとして働いている乙津(@rotsu1)です。

はじめに

ウォンテッドリーのモバイルチームはiOSDC Japan 2026に向けてテックブックを執筆しました。この記事では私が担当した章を書き直し、iOSエンジニア以外にも読める形にしています。

入社して最初の1ヶ月はAIを使わずに実装し、2ヶ月目からはAIを解禁して、施策の検討から実装までAIを使うようになりました。ところが、AIと壁打ちしてもPRDはまとまらず、AIが書いたコードは動いても中身を自分で説明できない場面に何度もぶつかりました。

AIを使って速く作れるようになったいま、作ったものを自分の言葉で説明できる力はどう身につければよいのか。私がぶつかった2つの壁を振り返りながら、この問いを考えていきます。

壁1: AIと壁打ちしてもPRDが書けない

AIと壁打ちすれば、アイデアは尽きることなく出てきます。ただ、アイデアが増えても解決策が見えてくるとは限りません。

入社して2ヶ月目、私はキャリアAIエージェントの継続率を伸ばす施策を任されました。キャリアAIエージェントはWantedly Visitのアプリにある、会話しながらキャリアの相談や募集探しができるAIチャット機能です。一度使ったユーザーになかなか戻ってきてもらえず、継続率が伸び悩んでいました。

当時のキャリアAIエージェントのUIはLINEのような対人のチャットアプリと同じで、すべての会話が1つの画面に履歴として積み上がっていく作りでした。最終的にはいま主流のAIチャットアプリのように、相談ごとにスレッドを分けられる形(複数スレッド化)に変えています。

ただ、そこにたどり着くまでに一度つまずきました。

施策を考えるときは会社の課題からユーザーの悩み、具体策の順に絞り込んでいくのが一般的な手法です。売上やKPIといった会社の課題を起点にユーザーの悩みをいくつか挙げ、インパクトが最も大きいものを選びます。そして、その悩みに対する具体策の中から最も効果的なものを選びます。

私はこのうち、ユーザーの悩みを考える段階で詰まりました。AIと壁打ちすると、「デザインが悪い」「回答が長い」「話題が混ざる」「入力が面倒」「求人が少ない」など候補はいくらでも出てきます。しかし、どれがユーザーの悩みなのかを決められず、候補が増えるほど思考はまとまらなくなりました。

そこで他のAIアプリ(ChatGPTやClaude)と見比べてみると、デザインが違うことに目が留まりました。そこから、なんとなくユーザーにとって学習コストが高いのだろうという仮説を立て、「他の生成AIアプリのデザインを踏襲しよう」という解決策を思いつきました。この仮説と解決策をPRDにまとめてPdMに提案したところ、「結局、何が使いづらいの？」と聞かれ、GOはもらえませんでした。

原因は「学習コストが高い」が抽象的すぎたことです。私はアプリ目線で他のアプリと何が違うかばかりを見ていたので、見えていたのは「デザインが違う」というアプリの違いだけでした。ユーザーがどんな場面で困っているのかまでは考えられていなかったのです。

AIとの壁打ちが空回りしていたのも同じ理由です。AIから引き出せる内容や質はプロンプトの立て方で変わります。しかし、ユーザーがどんな場面で何に困っているのかという視点をもとにプロンプトを考えなければ、アイデアは増えても、それが課題の解決につながるのか、現実的なのかを判断できません。判断の根拠がないので、PRDを書くときもPdMに口頭で伝えるときも説明の歯切れが悪くなります。AIとどれだけ話しても、その結果を自分の言葉で語れなければPdMからOKはもらえません。

断られたPRDを上司に見てもらったところ、「ユーザー目線で考えれば、何をすればいいかは自然と見えてくる」と言われ、ターゲットを決めてから目的、場面、ユーザーの悩みの順に考えるよう助言をもらいました。アプリを見比べることしかしていなかった私にとって、その助言はまったく新しい見方でした。助言に沿ってターゲットを1人決め、そこから連想ゲームのように一歩ずつ考えをつなげていきました。

こうして順に考えていくと、あれほど出てこなかったユーザーの悩みにたどり着けました。悩みが決まれば、具体策は自然と浮かびます。

この内容で改めて提案したところ、PdMからGOをもらい、リリースまで進められました。解決策は最初の仮説と同じですが、違ったのは理由です。抽象的な「学習コストが高い」が具体的な「過去の会話に引きずられ、新しい相談を始めづらい」に変わったので、PdMにも「これなら継続率が上がるかもしれない」と思ってもらえました。

上司からもらったこの見方がなければ、AIと壁打ちしても材料が増えるだけで、ターゲットからユーザーの悩み、具体策までを一本の筋として説明できません。ユーザー目線で考えると、作りたい物が見えてきます。候補ばかりが増えて行き詰まったとき、私に足りなかったのは問いの数ではなく、ターゲットを1人決めることでした。

壁2: AIで実装すると技術の理解が残らない

PRDが固まったあと、実装のほぼすべてをClaude Codeに任せました。コードは正常に動き、レビュー依頼も問題なく通っていました。

とはいえ、すべてのレビューがそのまま通るわけではなく、指摘を受けることもあります。そうした場面では指摘が正しいかを自分で判断できず、言われたとおりに直すだけでした。それでは次に同じ設計判断が来ても、また判断できません。ミーティングで実装について質問されたときも答えられず、議論に入る前に話が終わってしまいました。

原因は実装方針を自分で考えないままAIに任せ、出てきたコードをそのまま採用していたことでした。壁1で何を目指すかを決めないままAIと壁打ちしていたのと同じく、実装でもなぜその形なのかを考えないままAIにコードを書かせていたのです。コードもまた、なぜその実装なのかを自分で説明できて、はじめて理解できていると言えます。動くコードが手元にあっても、私にはその説明ができませんでした。

上司の助言を受けて変えた実装の進め方

上司からもらった3つの助言

このままでいいのか不安になり、毎週の1on1で上司に相談したところ、3つの助言が返ってきました。

• 変わりにくい原理を押さえる
• 最初からわかっている必要はなく、レビューを通して学べばよい
• 学んだことは次の実装で先にAIへ渡す

変わりにくい原理の例にはOSのスレッドやビルドの仕組み、モバイルの描画の仕組み、画面の状態を管理する仕組みがあります。道具が変わってもこうした原理は残るので、理解しておけば技術的な壁にぶつかったときに原因の仮説を立てられます。仮説があれば問題を突き止められ、解決策の実装はAIに任せられます。

レビューの指摘を自分の頭のSkillにする

Claude Codeには繰り返し使う手順や知識をSkillとしてファイルに書いておき、必要な場面でAIに読み込ませる仕組みがあります。ClaudeにSkillをファイルとして置いておくように、私もレビューの指摘を自分の頭の中にインプットするようにしました。助言を実践に移すため、実装は引き続きAIに任せたまま3つの工程を足しています。

1つ目の工程ではAIの出力をそのまま採用せず、自分で読み直して考え直します。なぜこの実装なのかを自分で説明できない箇所があれば、そこはレビューやミーティングで聞かれたときにも答えられません。

2つ目の工程では指摘をその場の直し方で終わらせず、同じ問題が次に起きたときの対処法として言葉にします。たとえばレビューでデータ競合を指摘されたとします。この指摘を「あの画面のあの関数の直し方」として覚えていると、一度きりで終わります。「複数の非同期処理が同じデータを更新する箇所では競合が起きる」という形で覚えておけば、別の実装にも持ち込めます。指摘をこうして条件と対処法の組に言い換えることが上司の言う「変わりにくい原理を押さえる」なのだと、私は受け取っています。

3つ目の工程では言葉にした対処法を次の実装のプロンプトに前置きします。前置きの中身は起きうるデータ競合やエッジケースと過去の指摘を踏まえた設計方針です。

このリポジトリでは複数の非同期処理が同じキャッシュを更新するため、
書き込み箇所ではデータ競合が起きうる。
キャッシュへの書き込みは1か所にまとめ、呼び出し側から直接更新しないでほしい。
次のエッジケースにも対応してほしい。
- 同じキーへの書き込みが並行して走った場合
- 書き込みの途中で読み出しが入った場合

前置きしておけば実装の抜け漏れが減り、何に気をつけて実装したのかを自分で説明できるようになります。

1ヶ月目はコードを自分で書くことで知識を定着させていました。いまはプロンプトに書き出すことで定着させています。何が起きうるのかを自分の言葉で書けなければ、プロンプトに前置きできません。書けない箇所があれば、そこが理解できていない箇所だとわかります。実装の速さはAIに任せたまま、理解はプロンプトを書く段階で手元に残せるようになりました。

まとめ

2つの壁はPRDを考える場面と実装する場面という別々のところで起きましたが、どちらも自分が何を考えるべきかわからないままAIを使っていた点で同じでした。壁打ちなら何を目指すのか、実装ならなぜその形にするのかという軸を持たなければ、AIをどれだけ使っても無駄打ちになります。AIを使うかどうかで学びが決まるわけではありません。AIに何を問い、何を渡し、出てきたものをどう扱うかを自分で考えることが学びになります。

その軸は最初から自分の中にあったわけではありません。上司からはPRDでユーザー目線という見方を教わり、実装では変わりにくい原理に立ち返る見方をもらいました。どちらも自分でやってみて失敗し、それを見てもらったからこそ受け取れた視点です。最初は自分だけで抜けに気づけなくても、レビューを受けるたびに新しい視点で見られるようになります。

入社したとき、仲CEOから「新卒には1年の窓がある」という言葉をいただきました。その1年は何をやってもいいし、どんなに初歩的だと思う質問をしてもいい、という意味だと教えてもらいました。この言葉に背中を押されて、私は臆せず挑戦し、人に見てもらうようにしています。AIを前提に開発を始めた方や、新卒を迎える立場の方が学び方を考えるときの材料になればうれしいです。