本記事は、ソフトウェア開発者向けのオンラインメディア「CodeZine（コードジン）」からの転載記事です（オリジナル記事）。
AI時代の羅針盤となる「プロダクトエンジニア」という考え方
近年、特に生成AIの進化に伴い、ソフトウェア開発におけるエンジニアの役割は大きな変革期を迎えている。このような時代背景のなかで、改めてその重要性が注目されているのがプロダクトエンジニアという概念だと、内山氏は言う。
プロダクトエンジニアの概念は、3つの要素から成る。第一に、エンジニアとしての基盤であり、どう作るか（How）、つまり設計や実装のための「技術」だ。第二に、なぜ作るのか（Why）に関わる「事業」だ。これは、なぜやるのか、いつやるのかという事業指標への理解やロードマップ策定への関与が求められることを意味する。そして第三に、何を作るのか（What）を決める「ユーザー体験」。ユーザーの課題を発見し、解決方法を模索する視点だ。
プロダクトエンジニアには、フルスタックエンジニアと同様、広範な知識が必要とされる。フルスタックエンジニアがフロントエンドからインフラまで、プロダクト開発に必要な技術全般（How）を網羅するのに対し、プロダクトエンジニアは、その技術力を核としながら、さらに事業（Why）やユーザー体験（What）といった非技術領域にまで越境していく点に特徴がある。
技術・事業・ユーザー体験の3要素は、相互に強く依存し合っている。例えば、どれほど優れた技術を用いて素晴らしいプロダクトを開発しても、事業として成立しなければ存続できない。また、ユーザーに実際に利用されなければ事業は成長せず、事業が持つリソースによって採用すべき最適な技術も変化する。内山氏は「技術・事業・ユーザー体験の3要素は、エンジニアにとって常に重要だった。プロダクトエンジニアという概念は、3要素を越境して開発を行う重要性を、改めて明確にしたものだ」と、その意義を強調する。
それでは、なぜ今プロダクトエンジニアを重視しているのか。内山氏はその理由として、生成AIやAIエージェントの登場を挙げる。かつては人間が主体でAIが補助するという関係性だったコード作成は、今やAIが主導する形へと変化しつつある。AIがコードを書く作業を代替しつつある今、人間は「なぜ作るのか」「何を作るのか」といった、より上流の問いに時間を割くべきだと内山氏は言う。
Assured流「全員が事業を創る」プロダクト開発のリアル
内山氏が所属するアシュアードは、Visionalグループの一員としてサイバーセキュリティ事業を展開している。同社が提供するクラウドサービスのセキュリティ信用評価「Assured」は、クラウドサービスのセキュリティ評価情報の提供によって、企業の安全なクラウド活用を支えるサービスだ。Assuredは、専門家による独自調査や、公開情報をもとに、各クラウドサービスのセキュリティ対策情報をデータベース化している。Assuredを利用することで、ユーザー企業は、サービス導入のたびにチェックシートを依頼・確認する手間を省ける。またサービス事業者は、一度Assuredの評価シートに回答するだけで、複数のユーザーへ一元的な情報提供が可能になる。このほか、自社で利用中のクラウドサービスを把握する「サービス検知機能」や、委託先企業・サプライチェーンのリスクを評価するサービスも提供しているという。
内山氏は、同社におけるプロダクトエンジニア的な開発への取り組みとして、このAssuredのサービス検知機能の開発事例を紹介した。同社では、開発チーム制とプロジェクト制による開発を併用しているという。各プロジェクトは、職能を横断して特定の課題を解決するために編成され、開発チームからも数名のエンジニアが参加する。
サービス検知機能の開発にあたり、プロジェクトチームは事業・ユーザー体験・技術の3つの観点からアプローチを行った。
まず事業の観点では、開発する機能の本質的価値を定義するところから始めた。他社の既存製品が多数存在する中で、「クラウドサービスのみを検知対象とする」という点に、自社で開発する意義を見出した。そして本質的価値についての仮説を立てたら、商談に同席して、ユーザーへのヒアリングを通して仮説を検証する。本質的な価値が明確に定義できたら、関連するKPIを特定し、必要なデータを収集して、可視化やモニタリングを行う。加えて事業の観点では、期限設定が非常に重要だと内山氏は言う。スケジュールが遅延すれば、市場動向など外部要因によって、開発のニーズが薄れたり、開発中止になってしまったりすることもあるからだ。そこで、期限を念頭に置いて、必要な開発期間をロードマップに落とし込む。
次にユーザー体験と技術の観点では、既存製品の課題に着目した。CASB（Cloud Access Security Broker）に代表される既存製品は、プロキシサーバーを介して通信を監視制御する方式なので、ユーザーにとっては導入のハードルが高い。また通信障害がユーザーの業務停止に直結してしまうので、高い可用性が求められ、技術的な要件も厳しくなる。今回の開発は、あくまでクラウドサービスの可視化のみが目的だ。そこでプロジェクトチームは、ユーザー負担が少なく、開発負荷も抑えられるアプローチとして、アクセス先の情報をブラウザ拡張機能で取得する方式を採用した。設計・実装フェーズでは、背景や目的、技術的制約を文書化するADR（Architecture Decision Record）を活用し、チーム内での合意形成を徹底したという。
こうした活動に加え、エンジニアが主導して機能の背景や価値を全社に共有する勉強会を開催するなど、職能にとらわれず「プロジェクトのためにできることは何でもやる」姿勢で取り組んだ。
同社には、実は「プロダクトエンジニア」という名の職種は存在しないと、内山氏は言う。それは、「役割を越境して事業を創る」、つまり職能を超えて、あらゆるメンバーが事業貢献を行うことが同社の文化に根付いているからだ。だからすべてのエンジニアには、自ずとプロダクトエンジニアとしての振る舞いが求められると、内山氏は語る。
「Assuredにおけるプロダクトエンジニアは、『役割を越境して事業を創る』という文化のもと、自分にできることは何でも実行するという働き方、あるいはあり方を持っていると言えます」（内山氏）
プロダクト開発を前進させる2つの改善
内山氏は、Assuredのプロジェクト制開発における課題や、それに対しての改善策について紹介した。
1つ目の課題は、属人性の高まりだ。プロジェクトにアサインされた特定メンバーにドメイン知識や実装が集中してしまい、プロジェクト外のメンバーへのナレッジやコンテキスト共有に支障が出た。そこで、マイルストーンごとにプロジェクトのアサインを変更することにした。その際には必ず新メンバーへの引き継ぎが発生するため、知識が特定の個人に留まるのを防ぎ、属人性の軽減につながる。
2つ目の課題は情報共有だ。以前は、実装担当者に渡される開発チケットの情報が不十分で、背景を理解しないまま作業が進む、ハイコンテキストな開発に陥りがちだった。そこで、企画の早い段階でチーム全体にプロジェクトの目的や背景を共有。さらに各チケットに、何を達成するべきかという受入条件を明記し、チームで合意してから開発を進めるようにした。加えて、相対見積もりを導入し、メンバー間での認識のずれについて議論をして、情報の解像度を高めるようにした。同社では、こうした地道な取り組みを通して、開発フローの改善を重ねているという。
最後に内山氏は、プロダクトエンジニアの重要性について次のように語り、講演を終えた。
「プロダクトエンジニアの役割は、ユーザーの価値と事業の成長を最大化することにある。生成AI時代だからこそ重要な考え方となるので、今後も取り組みを強化したい。Assuredは、役割を越境して事業を創るメンバーを募集しているので、興味を持ってもらえるようであればぜひ会話させてほしい」（内山氏）
