プロダクト開発に関わるなら、最初に読んでほしいこと

こんにちは、ウォンテッドリー株式会社執行役員 VPoE の要 (@nory_kaname )です。

2025年1月からMobile領域のエンジニアリングマネージャーを兼務することになり、Wantedly Visitのプロダクト開発にも携わるようになりました。この1年間でMobile Chapterの体制は、3名から6名のチームと新しく入社したメンバーの割合が高くなっています。また、開発組織全体でも、続々と新しいメンバーが増えています。中には、プロダクト開発がはじめてというメンバーもいるため、あらためてウォンテッドリーにおけるプロダクト開発とはどういうことなのか、まとめてみました。

すでに入社した方々、これからSaas事業やサービス事業に関わってみたい方々、ウォンテッドリーの開発に興味を持っていただけるであろう方々に読んでいただけると幸いです。

はじめに

「プロダクト開発をやりたい」と思うエンジニアは多いですが、その言葉が何を指すのかは人によって解釈が異なり共通認識になっていないこともあります。日本語で「プロダクト」はしばしば「製品」と訳されますが、エンジニアやデザイナーにとっては自分が関わるシステムや画面をイメージする方もいると思います。一方で、セールスやカスタマーサクセスにおいては「ユーザーに使われ、継続利用いただけるもの」としてごく当たり前にイメージできます。

私たちWantedlyが提供しているのは、有形の商品ではなく、無形商品としてのSaaSです。物理的な形がないからこそ、ユーザーに価値が届いているのか、その流れが目に見えにくい難しさがあります。だからこそ「作りたい」だけでは不十分です。ユーザーの課題に真正面から向き合い、チームで協働し、自らの能力を磨き続けることが求められます。料理でいえば、レシピ通りに作っても食べてもらえなければ意味がないのと同じです。

そして何より大切なのは、これが開発組織として大事にしている文化です。文化は誰か一人がつくるものではなく、一人ひとりの行動の積み重ねによって形づくられます。日々の選択や姿勢が組織全体の空気となり、未来のプロダクトの質を決めていきます。

プロダクト開発とは「ユーザーの課題解決」

システム開発とプロダクト開発は、似ているようで目的が大きく異なります。システム開発では「決められた仕様を正しく作ること」がゴールになりがちです。仕様書に沿って設計し、コードを書き、テストをして完成する。そこまで終われば、成果として区切りがつきます。

一方で、プロダクト開発のゴールは「ユーザーの課題を解決すること」にあります。ここで重要なのは、自分が作りたいものや技術的に実現できるものではなく、ユーザーが本当に求めている価値に焦点を当てることです。いくら立派なシステムを完成させても、ユーザーが使ってくれなければ存在価値は生まれません。

この違いを理解するには「Build – Measure – Learn」のリーンサイクルを回すことが欠かせません。仮説を立てて（Learn）、最小限のものを作り（Build）、実際のユーザーの行動データを集め（Measure）、そこから再び学び直す。このループを何度も回すことで、少しずつ課題解決に近づいていきます。

ただし、このサイクルはスマートに一発で回せるものではありません。むしろ失敗の連続でしか回せないのです。「とりあえず出してみたけど、ほとんど使われなかった」「データを見たら、想定と真逆の使い方をされていた」「ユーザーインタビューで、全然違う課題を指摘された」──現場ではそんなことの繰り返しです。机上で完璧な仮説を立てても、ユーザーに触れてもらわなければ検証できません。

逆に、機能としては小さな改善でも、ユーザーの不便を解消するだけで大きな価値が生まれることもあります。たとえば、ボタンの位置を変えただけで離脱率が大きく改善する、といったようなケースです。派手な新機能よりも、こうした細かな修正の方がユーザーに喜ばれる場合がある。これが「ユーザーの課題にフォーカスする」という姿勢の具体的な意味です。

結局のところ、プロダクト開発とは「仮説をぶつけ、反応を確かめ、また修正する」という地道な営みの積み重ねです。成功に見えるプロダクトの裏には、数えきれない試行錯誤と失敗が横たわっています。だからこそ「自分が作りたいもの」ではなく「ユーザーにとって価値があるもの」を中心に据えることが、プロダクト開発に携わるエンジニアに求められます。

Try & Error を支えるチームの力

ユーザー課題の仮説検証は、一人の力では成り立ちません。プロダクトは「ユーザーに届けられ、使われてはじめて意味を持つ」ものです。だからこそ、エンジニア・デザイナー・プロダクトマネージャーといった多職種が、それぞれの得意分野を活かしながら力を掛け合わせる必要があります。「誰か一人に依存する」のではなく、「チームとして最高のモノにする」ことを追求します。

ここで重要になるのが、リーダーのスタンスです。リーダーが全てを決めて指示を下す「ヒエラルキー型」もあれば、メンバー同士が直接つながり合う「ネットワーク型」もあります。どちらかが常に正解というわけではありません。局面によってはトップダウンで迅速に決断することが必要な時もあれば、メンバーの知見を持ち寄ってフラットに議論する方が成果につながることもあります。

リーダーの役割は、この二つの型をうまく使い分けること。まるで指揮者が曲の進行に応じてテンポを変えるように、リーダーは「今の状況にはどちらの型がふさわしいか」を判断し、柔軟にチームを導いていく。そうすることで、それぞれの専門職が互いを尊重し合い、Try & Error のサイクルを力強く回せるチームができあがります。

スピードは“端折る”ことではない

プロダクト開発においてスピードは欠かせません。けれどもここでいうスピードとは、ただ作業を省いたり工程を飛ばすことではありません。端折ることではなく、“質を保ったまま速くする”ことが本当の速さです。

料理にたとえると分かりやすいでしょう。玉ねぎのみじん切りを「速くやる」方法は、切る工程を端折って大きめにざく切りにすることではありません。そんなものを料理に入れたら食感は悪く、全体の味も損なわれてしまいます。大事なのは、包丁の入れ方を工夫したり、まな板の上での手の動きを滑らかにしたりして、同じ細かさを保ちながら短時間で仕上げることです。質を損なわずに速くする工夫こそが、プロダクト開発におけるスピードです。

さらに重要なのは、脳の使い方そのものが異なるという点です。新しい動作をゆっくり丁寧に覚えるときには、意識を集中させて頭で順序を考えながら取り組みます。しかし、素早く動作を行うときには、無意識に手が動くくらいまで体に染み込ませる必要があります。スポーツ選手がフォームを繰り返し練習するように、エンジニアも日々の鍛錬で「迷わず最短で動ける思考回路」をつくっていく必要があります。

たとえば、ある作業に1時間かかっていたとしましょう。これを30分に短縮する方法は「手を抜くこと」ではありません。作業フローを見直す、不要なやり取りを削る、自動化できる部分を見つける、思考の手順を整理する、そうした工夫を積み重ねることで、同じ品質を保ちながらスピードを高めることができます。

そしてスピードを磨くことは、単なる効率化以上の意味を持ちます。Try & Error のサイクルを素早く回せるようになり、より多くの学びを得られます。スピードがあるからこそ、失敗を恐れずに試し、次の改善につなげられる。プロダクト開発におけるスピードは、質を犠牲にするものではなく、学びを加速させることにつながります。

個で強く、チームで最強

チームで成果を出すためには、まず一人ひとりが強くなければなりません。プロダクト開発は多職種の協働で進みますが、他の職種から敬意を得るには「その人に任せれば安心だ」と思ってもらえるだけの専門性が必要です。基礎能力の向上は、チームに貢献するための前提条件です。

ここでイメージしやすいのが「オーケストラ」です。バイオリン、フルート、打楽器、どのパートも一流の奏者がいて、はじめて全体としての音楽が完成します。もし一つの楽器が音程を外せば、全体の調和は崩れてしまうでしょう。プロダクト開発も同じです。一人ひとりが専門分野でベストを尽くすことが、チーム全体の成果を押し上げます。

また、リーダーはこのオーケストラにおける指揮者の役割を担います。指揮者は自分で音を奏でるわけではありませんが、理想の響きを思い描き、そのビジョンに沿って全体を導きます。メンバーがそれぞれの力を発揮できるように調整し、方向を示し続けることがリーダーの役割です。

プロダクト開発で求められるのは 「個で強く、チームで最強」 というチームです。お互いに敬意を持ち、専門性を持ち寄って協働して最高のアウトプットができることが、プロダクト開発における強いチームの理想像となります。

生成AI時代に求められる力

ここ数年で生成AIの存在感は急速に高まりました。設計書からコードを生成したり、テストコードを自動で作成したり、リサーチの幅を一気に広げたりと、エンジニアの仕事の進め方そのものが変わりつつあります。今や「すべてを自分の手でやらなければならない」時代ではなくなっています。

とはいえ、生成AIは万能ではありません。AIがあるからといって、誰でも同じ成果を出せるわけではないのです。むしろ、設計力や問題解決力のある人ほどAIを効果的に使いこなし、スピードと質を同時に高められます。逆に基礎的な力が不足していると、AIの出力を正しく評価できず、誤った方向に進んでしまい、かえってスピードが遅くなります。

たとえば、設計の意図が明確であればAIに具体的な指示を与え、高い精度のコードを生成させることができます。テストケースを網羅的に洗い出す力がある人なら、AIを補助的に活用して品質を一気に高められます。リサーチの方向性を定められる人ほど、AIの情報収集力を活かして幅広い知見を獲得できます。

AI時代に求められるのは「AIを使いこなす力」と「自分自身の専門性を磨く力」の両輪です。AIは魔法の杖ではなく、使いこなす者の力を増幅させる道具にすぎません。だからこそ私たちは、日々の鍛錬で基礎を固めながら、新しい道具をいち早く取り入れ、進化し続けることが求められます。