候補はすぐ隣にいる。今すぐできる実践例
プロダクトエンジニアは、単にコードが書けるだけの存在ではない。丹羽氏は、その本質を「テクノロジー・UXデザイン・ビジネスの三領域をまたいで、機能開発全体に対してオーナーシップを持つ存在」と定義する。
たとえばテクノロジー領域では、1機能を自走して実装できるフルスタックな技術力に加え、多様なソリューションを生み出せる応用力や、高速なイテレーションを可能にする開発生産性が求められる。
UXデザイン領域においては、Lean開発に基づく仮説検証や、オブジェクト指向UI（OOUI）、情報アーキテクチャなどを通じて、ユーザー体験の設計にも関わる必要がある。
ビジネス領域では、顧客理解やドメイン理解に加え、KPIやビジネスモデルへの理解を深めることで、事業そのものへの解像度を上げていく。
こうした三領域を越境していくことに、プロダクトエンジニアとしての価値がある。領域の狭間で価値が毀損するからこそ、オーバーラップする知識と思考が必要とされるのだ。
そのうえで、アセンドではプロダクトエンジニアに必要な素養を、より具体的な行動レベルに落とし込んだ「5つのコンピテンシー」として定義している。
- 課題へのオーナーシップ
- 越境とキャッチアップ
- 迅速な仮説検証
- アンラーンとコミュニケーション
- ドメインに対する好奇心
これらは一見新しいようでいて、実は多くの開発現場にすでに存在してきた資質でもある。「シニアのテックリードやリーダークラスのエンジニアには、こうした素養を備えている人が少なくない」と丹羽氏は話す。そのうえで、これまで“暗黙のうちに”存在していた役割を職種として定義することで、組織としてのプロダクト志向を明確にし、事業の推進力に転換できるという考え方だ。
テクノロジー・UX・ビジネスの三領域を越境しながらキャッチアップもしていくことは容易ではない。ただし、近年のAIやツールの進化によって、そのハードルは確実に下がりつつある。実際アセンドでも、さまざまなバックグラウンドを持つメンバーがプロダクトエンジニアとして活躍するようになってきたという。
こうした話を聞くと、プロダクトエンジニアリングに今すぐ取り組んでみたくなる人も多いだろう。ただ、所属する組織に専用のロールや体制が整っていないことを理由に、自分には難しいと感じてしまうケースもあるかもしれない。それでも丹羽氏は、「今日から始められる実践は充分にある」と力を込める。
アセンドでは、5つのコンピテンシーを軸に据えた実践を積み重ねてきた。その中でも、とりわけ再現性が高く、すぐにでも取り入れられるアプローチとして、以下の4つを紹介する。
1．検証の2つの“はやさ”を高める
「迅速な仮説検証」のコンピテンシーに基づく実践で、鍵になるのは2つの“はやさ”だ。
1つ目は「顧客検証のスピード」。アセンドでは、Figmaなどで実装前にデザインモックを作成し、顧客からのフィードバックを早期に得ている。さらにFeature Flag（以下、フィーチャーフラッグ）を活用し、開発中の機能を一部の顧客にだけ先行公開。限られた環境で小さく検証を行うことで、混乱を防ぎつつ本質的な学びを得ている。「いかに機能を“作らないか”、つまり価値の見極めをいかに早く行うかが重要だ」と丹羽氏は確信をにじませる。
2つ目は「開発生産性」だ。アセンドでは、Four Keys（デプロイ頻度／変更リードタイム／平均修復時間／変更失敗率）を重視し、これらの指標を愚直に改善していくことで、実装スピードと安定性の両立を図っている。
2．表層的な要望に惑わされない
「仮説そのものの質」に向き合うことも、プロダクトエンジニアリングの実践のひとつだ。安易な発想から導き出された「それはそうソリューション」に飛びつくのではなく、表層の要望の背景にある根本的な課題を捉え直す。仮説を問い直し、プリミティブな課題へと再定義することで、より本質的かつエレガントな「Wow! Solution」へとつながっていく。
3．現場訪問によるアンラーン
「プロダクトはリリースして終わりではない」と丹羽氏は語る。実際にプロダクトが使われている現場に足を運び、自らが立てた仮説の不確かさに気づくことも少なくないという。こうした現場での学びは「アンラーン（脱学習）」の起点となり、前提を疑い直す姿勢や、新たなインサイトの獲得につながる。
4．ドメイン駆動設計の活用
4つ目の実践が「ドメイン駆動設計（DDD）」だ。丹羽氏は「そもそも、プロダクトはドメインから生まれるもの」という前提を再確認し、この手法の有用性を強調する。
特定の業界・業務の構造や課題を理解することで、UX設計の精度が高まり、機能の優先順位に対する納得感も醸成される。同時にビジネス領域では、競合との差別化や商談における説得力の源泉になる。
