AIにコードを任せる時代、エンジニアの価値はどこにある？Assuredが実践する「事業を創る」プロダクト開発術

【17-C-8】プロダクトも事業も開発する、プロダクトエンジニアの役割

Assured流「全員が事業を創る」プロダクト開発のリアル

　内山氏が所属するアシュアードは、Visionalグループの一員としてサイバーセキュリティ事業を展開している。同社が提供するクラウドサービスのセキュリティ信用評価「Assured」は、クラウドサービスのセキュリティ評価情報の提供によって、企業の安全なクラウド活用を支えるサービスだ。Assuredは、専門家による独自調査や、公開情報をもとに、各クラウドサービスのセキュリティ対策情報をデータベース化している。Assuredを利用することで、ユーザー企業は、サービス導入のたびにチェックシートを依頼・確認する手間を省ける。またサービス事業者は、一度Assuredの評価シートに回答するだけで、複数のユーザーへ一元的な情報提供が可能になる。このほか、自社で利用中のクラウドサービスを把握する「サービス検知機能」や、委託先企業・サプライチェーンのリスクを評価するサービスも提供しているという。

Assuredの概要

サービス検知機能について

　内山氏は、同社におけるプロダクトエンジニア的な開発への取り組みとして、このAssuredのサービス検知機能の開発事例を紹介した。同社では、開発チーム制とプロジェクト制による開発を併用しているという。各プロジェクトは、職能を横断して特定の課題を解決するために編成され、開発チームからも数名のエンジニアが参加する。

　サービス検知機能の開発にあたり、プロジェクトチームは事業・ユーザー体験・技術の3つの観点からアプローチを行った。

　まず事業の観点では、開発する機能の本質的価値を定義するところから始めた。他社の既存製品が多数存在する中で、「クラウドサービスのみを検知対象とする」という点に、自社で開発する意義を見出した。そして本質的価値についての仮説を立てたら、商談に同席して、ユーザーへのヒアリングを通して仮説を検証する。本質的な価値が明確に定義できたら、関連するKPIを特定し、必要なデータを収集して、可視化やモニタリングを行う。加えて事業の観点では、期限設定が非常に重要だと内山氏は言う。スケジュールが遅延すれば、市場動向など外部要因によって、開発のニーズが薄れたり、開発中止になってしまったりすることもあるからだ。そこで、期限を念頭に置いて、必要な開発期間をロードマップに落とし込む。

　次にユーザー体験と技術の観点では、既存製品の課題に着目した。CASB（Cloud Access Security Broker）に代表される既存製品は、プロキシサーバーを介して通信を監視制御する方式なので、ユーザーにとっては導入のハードルが高い。また通信障害がユーザーの業務停止に直結してしまうので、高い可用性が求められ、技術的な要件も厳しくなる。今回の開発は、あくまでクラウドサービスの可視化のみが目的だ。そこでプロジェクトチームは、ユーザー負担が少なく、開発負荷も抑えられるアプローチとして、アクセス先の情報をブラウザ拡張機能で取得する方式を採用した。設計・実装フェーズでは、背景や目的、技術的制約を文書化するADR（Architecture Decision Record）を活用し、チーム内での合意形成を徹底したという。

　こうした活動に加え、エンジニアが主導して機能の背景や価値を全社に共有する勉強会を開催するなど、職能にとらわれず「プロジェクトのためにできることは何でもやる」姿勢で取り組んだ。

プロジェクト制による開発体制

　同社には、実は「プロダクトエンジニア」という名の職種は存在しないと、内山氏は言う。それは、「役割を越境して事業を創る」、つまり職能を超えて、あらゆるメンバーが事業貢献を行うことが同社の文化に根付いているからだ。だからすべてのエンジニアには、自ずとプロダクトエンジニアとしての振る舞いが求められると、内山氏は語る。

　「Assuredにおけるプロダクトエンジニアは、『役割を越境して事業を創る』という文化のもと、自分にできることは何でも実行するという働き方、あるいはあり方を持っていると言えます」（内山氏）