こんにちは！Avvyでテックリードをやっている@fortkle (ふぉーとくる)です。
今回は、私がエンジニアとして働く際に大事にしていることを書こうと思います。
新卒研修で得た学び
いきなりですが、皆さんは「化粧品・コスメ」についてどのくらい詳しいでしょうか？ というのも、いまから10年ほど前、私は「化粧品の口コミサイト」を運営する会社に新卒で入社しました。 そこで受けた新卒研修で印象的なものがあったのでまず初めに取り上げたいと思います。
その研修とは、「コンビニやドラッグストア、百貨店など、化粧品が販売されているさまざまな "場所"（販売チャネル） に実際に足を運び、どこで、どんな商品が、誰向けに、どのような方法で販売されているか」を丸一日使ってレポーティングする研修でした。
それまで「化粧品を買うユーザーは"女性"（10年前ですので...）」ぐらいの解像度しかなかった私にとって、実際に売られている商品の特性や、来店しているお客様、その販売手法などの違いから「ユーザー」や「商品」というものの解像度がグンと上がった印象的な研修でした。
そしてこの気づきが、「ユーザーの要求を本当に理解しないとプロダクトは的外れになる」 という学びにつながっていきます。
「要求」と「要件」、そしてAgentic Coding
まず、「要求」と「要件」の違いについて明確にしましょう。
- 要求：「これがやりたい」という消費者や顧客の要望のこと。ユーザーストーリーもこれを伝える手法だと思っています。
- 要件：その要求を実現するために実装すべき機能や性能のこと。機能要件だけでなく、品質などに関わる非機能要件なども含まれますね。
開発サイクルの中で、一般的に多くのエンジニアは設計や実装などの「HOW（どのように要件を実現するか）」にフォーカスすることが多いと思います。 PdM/POが要求を定義し、それを元に要件を整理して、エンジニアがその要件を満たすようにプログラムを書いていく、という流れですね（完全に分業するスタイルは私の好みではありませんが）。
--- title: "青いエリア = エンジニアが関与していた領域" --- flowchart LR RQ[要求] RM[要件] DE[設計・実装] QA[試験] RL[製品] RQ --> RM --> DE --> QA --> RL classDef engineer fill:#E0F7FA,stroke:#00798C,stroke-width:1px,color:#003844; classDef normal fill:#F5F7FA,stroke:#A3AAB5,stroke-width:1px,color:#222; class RQ normal; class RM,DE,QA,RL engineer;
しかし、最近ではAgentic Codingが普及し、AIがコードを書くことを前提とした開発スタイルがかなり一般的になってきました。 高速に設計・実装を進めることができるため、相対的に「要求」の部分が開発サイクルにおいてボトルネックになってきているチームも増えている印象があります。
さらにAIの性能の進化に伴い、例えばPdM/POが記述した要求・要件定義の文章をそのままAIへの指示として使っても瞬時にある程度の完成度まで持っていけるケースもちらほら見かけるようになってきました。
このように、設計や実装などAIに任せられる部分が増えてくると、「要求」を正しく理解し、その問題点を指摘したり代替案を提示できたりすることが今後エンジニアに求められる価値の1つになってくると思います。 つまり、エンジニアも「要求」を正しく理解することの価値が高まっているということです。
--- title: "エンジニアが関与していくべき領域（つまり全て）" --- flowchart LR RQ[要求] RM[要件] DE[設計・実装] QA[試験] RL[製品] RQ --> RM --> DE --> QA --> RL classDef engineer fill:#E0F7FA,stroke:#00798C,stroke-width:1px,color:#003844; class RQ,RM,DE,QA,RL engineer;
なぜ要求を理解することがこれほど大事なのか。まとめるとこんな感じですね。
- AIや自動化の進化
- コードを書くことの相対的価値は下がり、「何を作るべきか」を定義できる人材が求められている。
- 要件だけでは不十分
- 「仕様通りに作ったけど、結局使われない機能」──これはよくある失敗です。その裏には「要求の理解不足」が潜んでいます。
- ユーザー体験の複雑さ/要求理解の難しさ
- 数字やログだけでは捉えきれない行動や心理を理解することが、プロダクトの質を大きく左右します。
要求を正しく理解するために
こうした背景を踏まえると、「要求を理解する力」をどう鍛え、実際の開発に活かしていくかがエンジニアにとって重要になります。
ここからは、私自身がこれまでのキャリアの中で実践してきた具体的な取り組みを紹介していきます。
1. ユーザーインタビューに参加する
私が新卒研修で行ったように実際のユーザーに会いにいきましょう。実際に "売り場" へ行き、ユーザーの行動やチャネルごとの違いを観察するんです。 「ユーザーはこうだろう」という思い込みが覆され、要求を知る第一歩となるはずです。
会いに行くのが難しければ、時間を貰って会いにきてもらいましょう。ユーザーインタビューの場にエンジニアとして参加するんです。 まだユーザーインタビューが行われていない職場なのであれば提案して実施してみましょう。 「なぜその機能を使うのか」「どんな場面で困っているのか」を直接聞くことで、データでは見えない要求をつかみ、開発議論で「なぜ作るのか」を語れるようになるはずです。
2. 利用者の隣に座る（社内管理画面の開発）
社内のスタッフ用に、管理画面を作ることってよくありますよね。実際に、そのスタッフが管理画面を使ってる横に座って1日仕事をしてみてください。 ちらっと横に目をやると、設計・実装段階では想定していなかった使い方や課題を発見することができるかもしれません。
3. ユーザーの1人になる
いわゆる「ドックフーディング」というやつですね。 いま私は Avvy というスマホで簡単にVtuberになれるライブ配信アプリを作っていますが、この会社に入るまで実はライブ配信アプリというものに全く触ったことがありませんでした。 かろうじてニコ生を見たことがあるぐらいで、あとはYoutubeでVtuberの配信や切り抜きを見るぐらいでした。
そこでサービスを作る前に私が一番最初にやったことは、いま市場にでているライブ配信アプリを手当たり次第に触りまくることでした。 配信では一般的ですが入室時に名前を読み上げられるのが恥ずかしくてすぐに抜けてしまったのも良い思い出です。
特に一番やりこんだライブ配信アプリでは偶然にも推しと呼べるような配信者と出会い、1年弱推し続け、その配信者がアプリ内で一番上のユーザーランクになるまで一緒に駆け上がる体験を経験することができました。 毎日配信に参加して雑談したり、そこで出会ったTO（トップオタ）と作戦会議をしたり、1周年をお祝いするビデオを作ったり、各種機能をいかに効果的に使っていくか情報交換をしたり、、そういった視点は自分が当事者の一人として使い込まなければ到底理解できないものです。
本質的に、私はそのサービスのターゲットユーザーではなかったかもしれませんが、どんなユーザーがそのサービスを使うのか、確かに存在するユーザー像をとても高い解像度で理解できたと思っています。これは開発議論の場において「ユーザーだったらどう思うかな？」という自分以外のユーザーの視点が必要になった時にとても強力な武器になります。
最近は、配信者側の体験も理解しようと思い、さまざまなプラットフォームで配信も試しています。まだまだ始めたばかりなのでもう少し続けてみようと思います。
最初はスマホ1台で手軽にできることが価値だったのに、エンジニアの性なのか機材にこだわりはじめ、いつのまにか自宅の配信環境が整ってきてしまいました。
おわりに
エンジニアは「要件を実装する人」から、「要求を理解して形にする人」へ。役割は確実に広がっています。 前述した取り組みはあくまで一例ですが、こういった実践を通じて、要件にとらわれずその背後にある要求やユーザー心理に踏み込むことができるようになりたいですね。
宣伝
私が所属するAnotherBall株式会社、Avvyチームでは積極的に採用活動を行っていますので、ご興味ある方はぜひご応募ください！
