こんにちは。ウォンテッドリーでバックエンドエンジニアをしている小室 (@nekorush14) です。ウォンテッドリーへ転職して一年が経過し、AIをプロダクトに組み込む開発に多く携わってきました。今回はこの一年で深めた3つの視点をお話しします。
はじめに
ウォンテッドリーへ転職する前、私はシステムエンジニアとして設計・開発・保守に携わっていました。なりたいエンジニア像から逆算したときにより Web の領域へ近づく必要があると考え、ウォンテッドリーへ入社しました。
【入社エントリー】なぜSIer出身者がウォンテッドリーへ転職したのか | Wantedly Engineer Blog
入社してからは Wantedly Visit の 「AI エージェントモード」、「キャリア AI エージェント」、Perk の 「AI レコメンド機能」の開発を担当してきました。いずれも要件が固まりきらない段階から手を動かし、動くものを見せながら仕様を詰める進め方が中心でした。
本稿では、これらの取り組みを振り返り、一年を通した仕事の捉え方の深まりを共有します。
この一年でやったこと
入社してからの一年はAI をプロダクトに組み込む開発が中心でした。いずれの案件も要件が固まりきらない段階から手を動かし、動くものを見せながら仕様を詰める進め方でした。参画したプロジェクトは以下の通りです。
- 入社直後は分割されていたマイクロサービスの統合プロジェクトに参画し、複数のリポジトリを横断して gRPC エンドポイントの移行と本番反映まで進めました
- Wantedly Visit の「AI エージェントモード」では実装の主担当とプロジェクトの推進役を兼ね、社内リリースから正式リリースまでを通して取り組みました
- 「キャリア AI エージェント」ではバックエンドの主担当として、UI から逆算したスキーマ設計と対話フローの実装に取り組みました
- Perk の「AI レコメンド機能」ではバックエンド/フロントエンドを実装し、推薦ロジックを扱うチームとの I/F 設計も担いました
プロダクト開発以外では、負債返済日での Railsアップグレードや gRPC の自己呼び出しの解消に取り組み、Claude Code の設定やプラグインを社内へ展開しました。加えて、技術ブログの執筆、社外 LT や社内向け研修の講師、カジュアル面談への同席など、開発の外側の役割も増えました。
負債返済日の取り組み | Wantedly Engineering Handbook
71 個の gRPC メソッドを持つマイクロサービスを無停止でモノリスに統合した方法 | Wantedly Engineer Blog
一年を通して、タスクを実装する立場から、要求を分解してロードマップに落とし、他チームと調整しながら進める立場へ役割が移りました。担当する範囲が広がるほど、何を作るかの判断に関わる場面が増えています。
AIが候補者リストを作成提案する「AIエージェントモード」提供開始 | Wantedly, Inc.
AIとの対話で見つける適材適所|「キャリアAIエージェント」をリリースしました | Wantedly, Inc.
福利厚生サービス「Perk」|AIが最適な特典を提案する「AIレコメンド機能」を提供開始 | Wantedly Engagement Suite
一年で深めた3つの視点
この一年の変化は、できなかったことができるようになったという話ではありません。以前から意識していた3つの視点がプロダクト開発の現場でより強く問われ、その結果として深まったことにあります。いずれも前職の頃から持っていた問いや関心から続いています。
プロダクト価値まで踏み込んで設計する
新機能の開発では、画面遷移とデータフローをセットで整理し、想定される操作を頭の中で一通り試して違和感を洗い出すようにしています。加えて、実運用で発生しうる値を推測したモックデータを用意し、PdM やデザイナーと画面を触りながら仕様を詰めます。
前職でも顧客の業務要求に対してこの機能が本当に必要かを問いながら要件を固めていました。転職後はその問いの向く先が変わりました。仕様どおりに動くかを確かめるだけでなく、その仕様がユーザーに届く価値をどう変えるかまで踏み込んで問うようになっています。
設計の段階で私が確認するようにしている問いは以下の通りです。
- その機能がユーザーのどの行動を変えるために必要なのか
- 仕様通りに動いたとして、ユーザーの体験として自然な流れになっているか
- 前提となる利用状況が変わった場合、この仕様の状態で価値が残るか
仕様を決める作業と言いつつ、実態はユーザーに何を届けるかを決める作業に近いものになっています。実装が始まってからこの問いに戻ると、仕様変更に伴う作り直しのコストを払うことになります。
個人の工夫を組織の知見に変える
AI を使う中で見つけた進め方は自分の手元だけとどめず、Agent Skills などに言語化するようにしています。技術選定のように複数の機能へ影響する判断は棄却した選択肢とその理由まで含めて ADR に残します。
アーキテクチャディシジョンレコード(ADR) | Wantedly Engineering Handbook
チームメンバーが開発しやすい状態を作る DevX (Developer Experience) の向上は前職でも意識していました。プロジェクトリーダーとして、レビューの観点や設計の判断をチームで揃えることに時間を使っていました。この点は変わらず重要であり、現在ではより個人の生産性の向上を組織の生産性へ変換する方向に深めています。
自分の工夫を共有する形に変えるときに意識している問いは以下の通りです。
- 言語化した情報で他のメンバーが同じ手順を再現できるか
- 共有にかかる手間が得られる効果に見合う軽さに収まっているか
- 状況が変わったときにも判断の理由を当てはめ直せるか
共有される前提が増えるほどメンバーも AI も揃った判断基準から作業を始められます。各自が個別に検討していた部分が減り、その分をプロダクトの改善や新規施策の検討に充てられます。
AI を前提に仕事を組み立てる
日々の開発では、AI に任せる範囲と自分が判断を持つ位置を作業に入る前に決めています。検証を終えた判断は次に AI が読む前提として共有コンテキストに残しています。
学生時代から人間と AI が協力することに関心を持っていました。これは人間と AI が協力し合うことでこれまでになかった新しい発想が生まれるのではないかと考えていたためです。現在もその興味関心は変わりませんが、実務の進め方へも考えを拡張しています。AI を道具として呼び出すのではなく AI と分担する前提で仕事の組み立て方そのものを見直す実践へ深めました。
進め方を組み立て直すときに意識している問いは以下の通りです。
- 「AI に何をどこまでして欲しいのか」が明確となっているか
- 「AI の出力をどこまで自分で検証するか」が決まっているか
- 検証した判断を AI が次に読める形で残せているか
どこで人が判断するかを先に決めた段階で初めて、AI を前提とした進め方になります。任せる範囲や内容を決めないまま AI を呼び出すと出力の確認に時間が取られ、速度の利点が相殺されてしまいます。
まとめ
今回は入社から一年でプロダクト開発を通じて深めた3つの視点を振り返りました。
以前から持っていた問いや考え方は環境が変わっても土台なっており、この一年でより深めることができました。今後は3つの視点のうち、プロダクト価値まで踏み込んで設計することの延長として、エンジニアでありながらもより PdM に近い考え方で意思決定に関わる必要があると考えています。
今回振り返った3つの視点を伸ばしながら、働く人と会社の出会いをよりよいものにし、働く人が幸せを感じられて「明日が楽しみ」と思える世界を作っていきます。