AWS分野のDeveloper Expertsが挑戦する、生成AIプロダクトを成功に導くためのエンジニアリングマネージメントのあり方

── 小西さんのエンジニアとしてのバックグラウンドを教えてください。

前職のセキュリティ関連メーカーを経て、2019年にサイバーエージェントに入社しました。配属先のAI事業本部では、スマートフォン向けパフォーマンス型広告プラットフォーム「Dynalyst」や、店舗サイネージ配信プラットフォーム「ミライネージ」などの広告プロダクト開発に携わりました。

大規模なトラフィックを処理する広告プロダクトから、実店舗と連動するような新規プロダクト開発まで、様々なプロジェクトに携わる中で、バックエンドやインフラエンジニア、開発責任者からエンジニアリングマネージャーと幅広い役割を経験することができました。

2024年にはAWS分野のDeveloper Expertsに就任し、プロダクトにおけるAWSの導入やフォローアップ、「CAゼミ制度 実践AWSゼミ」を通じたAWS技術コミュニティの運営をしています。

現在は、生成AIを活用した業務効率化や事業創出を目的とする「AIオペレーション室」に所属しています。主にプレイングマネージャーとして生成AIを活用したプロダクトの開発、ピープルマネジメントや開発組織の枠組み作りなどに携わっています。

── AWS分野のDeveloper Expertsや、広告プロダクトのエンジニアリングマネージャー、「AIオペレーション室」のプレイングマネージャーなど幅広い分野でキャリア形成をされています。どういったビジョンやキャリアプランのもとに活動しているのですか？

20代の頃は、インフラやクラウドなどの技術習得に専念し、その経験を活かし開発責任者やエンジニアリングマネージャーを任されてきました。プロダクト開発を経て得たクラウドの知見は、Developer Expertsとしての登壇や、AWS社での登壇等で発表することで、業界や技術コミュニティに貢献してきました。

それを経た上で、現在の人生の目標は「大きなビジネスを推進できる人間になること」です。

サイバーエージェントでは毎年たくさんの事業が立ち上がり、「ここだ」というタイミングで成長ドメインに大きくアクセルを踏むダイナミックス感にいつも驚かされます。自分も「何億円もの売上を出すようなプロダクトを開発してみたい」「プロダクトを大きなビジネスになるまでグロースさせたい」という気持ちになります。

一見するとプロダクト開発でのマネジメント軸と、Developer Expertsである技術軸と両軸あるように見えるかもしれませんが、自分にとっては「大きなビジネスを推進できる人間になること」という大きな目標に向かうための両輪だと思っています。

── AWSは、まさにインターネットビジネスを支える代表的なプラットフォームとも言えます。サイバーエージェントのような「インターネット × ◯◯」のビジネスモデルに対して、AWSを導入する際の着眼点を教えて下さい。

AWSのポリシーとして「サービス開発/運用におけるフルマネージドサービスの利用」を推奨しています。そのポリシーには同意ですが、あえて自分なりに言葉を付け加えたいのが「プロダクトの状態やビジネスフェーズに応じたマネージドサービスの選定」です。

つまり、新規に立ち上げたばかりの検証フェーズにあるプロジェクトと、「Dynalyst」や「ABEMA」のような大規模プロジェクトでは、フルマネージドサービスの規模や選定するAWS製品に大きな違いがあります。

「プロダクトの状態やビジネスフェーズに応じたフルマネージドサービスの選定」をする際に、システムに投資できる金額やエンジニアのリソース、ランニングコストなどを含めた上で検討するなど、ビジネス的な着眼点が求められると考えています。

── 例えば、新規立ち上げしたプロジェクトのユーザー規模がどれだけ増えるかは、立ち上げ時には見込めない中、エンジニアは仮説に基づいてアーキテクチャを構築します。ビジネス的なグロースを予見する難しさに、エンジニアとしてどう向き合えばよいでしょうか？

AWSには「ビルディングブロック」という思想があります。サービスの成長に伴いシステムや開発フローが複雑になる中、AWSの膨大なサービス群の中から、プロダクトの要件にあうものを必要に応じて選択し、ブロック遊びのように組み合わせてシステムを構築する手法です。

また「マイクロサービスアーキテクチャ」は、プロダクトを小さな独立した複数のマイクロサービスで構成。API を通じた処理の送受信によって、トラフィック管理やリクエストのフィルタリング、ルーティング、認証などの機能を組み合わせて開発します。これによりスケーリングや開発サイクル向上を可能にし、ビジネスニーズを素早く実現する手法です。

こういった技術的手法を導入する際に重要なのは、その本質であるビジネス的な観点を見失わないことです。ビジネス規模や開発組織の状態、売上とコストを把握した上で、上記のような設計手法を実装していく事は、エンジニアがクラウドを活用する際に、非常に重要な観点になると思っています。

例えば、売上が好調なプロダクトがあったとします。一方でシステムコストが増大すれば、売上を圧迫する事になります。経常利益を増加するためには、売上だけでなく、販売管理費となるシステムコストの抑制も重要な要素になります。

もちろん、エンジニアが販管費を管理する必要はありませんが、エンジニアとしてコストパフォーマンスを意識する価値は十分あります。サイバーエージェントでは、システムコストを継続的に効率化する「みんなで金塊堀太郎」というプロジェクトを実施したりもしています。

特にクラウドに関しては、AWSの不適切な使い方で高額なコストになる可能性もあり軽視できません。ましてや、2024年4月末時点でも世界的なドル高傾向にあります。海外のクラウドを利用する際のコストが増加しているのは明白です。

そんな中、エンジニアとしての技術的な知見やノウハウ、最新情報のキャッチアップや検証が、利益につながるケースもあります。AWSは使用料の予測に基づいた設計や、柔軟にスケールできるような設計、ストレージの適切な選定によって、コストを抑えることもできますし、計画的な運用によって大幅なディスカウントを受けることができます。まさにエンジニアの技術力が、そのまま利益に直結すると言えます。

私はAWSのDeveloper Expertsとして、社内の既存プロダクトのヘルプをする機会も多く、中にはクラウドの予想外のコスト増に困っているプロダクトの相談を受けたりもします。チームメンバーにヒアリングしてみると、AWS製品の間違った使い方をしていてコストが跳ね上がっているケースも少なくありません。

クラウドサービスは従量課金で請求される割合が多く、エンジニアが日々利用するダッシュボード画面から、時間単位でコストや請求金額を確認することもできます。予算管理はエンジニアとは切っても切り離せない関係になります。

── 時代に応じてエンジニアの役割も変わっていきます。これからエンジニアに求められる素養やスキルとは何でしょうか？

ビジネス的な観点を持ちながらも、技術的な検証を欠かさないような、地に足のついたエンジニアリングスキルをもつバランス感覚だと思っています。
例えばAWSは「AWS Well-Architected Framework」を提唱しています。しかし、特定のフレームワークが、サイバーエージェントのように多種多様なビジネスモデルにジャストフィットし、会社全体の開発ワークフローが改善されるかと言うとそうではありません。

むしろ「このフレームワークを適用したのでコストが大幅に抑えられた」とか「この製品に切り替えたことで、レスポンスが急激に改善された」といったケースは稀なのが実態です。

私は「Dynalyst」をはじめとして、プロダクトのアーキテクチャを刷新するプロジェクトに参加してきましたが、前例のない事ばかりで試行錯誤の連続でした。

AWS製品の中から、どのレベルのマネージドサービスを選定するかは、AWS社の担当者と議論しながら行ったりしました。AWS社も製品のリリース初期では、実運用している大規模プロジェクトでの実績がまだ少ないため、サイバーエージェントにおける固有プロダクトでの最適解がない中での共同作業となりました。

そんな中、トラフィックを計測し、ボトルネックを地道に洗い出し、AWS製品の導入/検証を繰り返しながら、最適解に近づけていきました。その際に、実際にAWS製品を手で触って動かして、泥臭く検証を重ねた経験が決め手になったと実感しました。

「AWS Well-Architected Framework」はある意味、空手や剣道でいう「型」のようなものだと思います。型をいくら知っていても、それだけでは強くなれるわけではありません。強くなるためには型を意識しつつ、体で覚えられるまで素振りする必要があります。

推奨されるアーキテクチャなどを参考にしつつ、技術検証やパフォーマンスチューニングを繰り返し検証しながらPDCAを高速で回すことで、ようやくプロダクトに最適化していくと言えます。

そういう点では、私がオーナーをつとめる「実践AWSゼミ」には様々な事業部から十数名のメンバーが在籍しています。各部署やプロダクトにおけるAWS製品の検証結果やノウハウを共有し議論を重ねているので、社内全体の開発力向上に貢献もしています。

── 現在所属している「AIオペレーション室」ではどんなプロダクト開発に関わっていますか？

「AIオペレーション室」は、生成AIを活用しサービスのさらなる価値を創出することを目的にした組織です。サイバーエージェントにおける現在のオペレーション業務を2026年までに6割削減することを目指しています。組織内では、全従業員を応募対象とした「賞金総額1,000万円！生成AI徹底活用コンテスト」で受賞したコンテスト案の開発も進めています。

組織内における私の役割は、生成AIを活用したプロダクトの開発とエンジニア組織のマネージメントです。

開発中のプロダクトの一例をあげると、サイバーエージェントで提供しているメディアサービスのユーザー体験アンケート業務に生成AIを導入するプロジェクトがあります。当社ではユーザーのニーズを把握するためにインタビューを行い、コンテンツとサービスの向上に活用しています。これまで、インタビューは人が行っていましたが、アポイントメントや時間制約など、リソース的な制約がありました。この業務に生成AIを導入する事で、今まで以上のインタビューが実施可能になり、より多くのユーザーの声をキャッチアップする事が可能になります。

更に生成AIを活用する事で、これまでの定型的なアンケートとは代わって、質問の流れや回答の文脈にあわせた対話的なインタビューを実施可能にする事で、よりユーザーの趣味嗜好やニーズの深堀りをする事も可能になります。

他にも、例えば「ABEMA」のような動画配信のサービスでもAIの実装を図っています。スポーツ中継において、歓声が沸き起こる環境音やコメントが多く寄せられたシーン等の特徴的なデータをAIで検知し、ハイライト動画を生成AIで自動作成するといった技術検証と実装を進行中。これにより、本来は膨大な制作時間を要する動画編集の作業を軽減するだけでなく、クリエイターの作業のうちルーチンワークになっている工数を削減する事で、よりクリエイティブな作業に集中できるなどの効果が期待できます。

── 小西さんのビジョンである「大きなビジネスを推進できる人間になること」という観点で言うと、「AIオペレーション室」ではどんな事にチャレンジしてみたいですか？

サイバーエージェント社内には多岐にわたる事業やプロダクトが存在し、これらに「AIオペレーション室」が開発した生成AIプロダクトを導入することで、生産性の向上が期待されます。将来的には、これらの生成AIプロダクトをさらに発展させ、多くの事業ドメインに適用可能な汎用的なプロダクトへ昇華させることを構想しています。AWSはもともとAmazon.comのために開発されたクラウド技術を基に、社外にプラットフォームとして提供していますが、目指す理想像の1つでもあります。

サイバーエージェントのパーパス「新しい力とインターネットで日本の閉塞感を打破する」には、「あらゆる産業のデジタルシフトに貢献する」という言葉が含まれています。まさに我々の生成AIプロダクトもそれに該当します。

社内で継続的に改善を重ねることで、世の中の課題解決や生産性向上に役立つプロダクトにまで成長させられたらと考えています。

── 特に生成AIプロダクトのような前例の少ないケースにおいて、プレイングマネージャーとして心がけている事を教えて下さい。

生成AIプロダクトのように前例のないケースだからこそ、プレイングマネージャーとして、明確なビジョンを示すことを心がけています。

自分は、特にビジョンやスタンスを示すことを大切にしています。例えば「銀行にお金を返さなければならないから、従業員のみなさん会社でもっと働いて利益を出してください」というスタンスの経営者には人はついてきません。同じように「経営陣から売上目標を決められているから、もっと開発スケジュールを早めてくれ」と伝えられても、開発メンバーはがんばれないですよね。

メンバーが純粋に「仕事が楽しいです！」と感じてもらえるような組織は、勢いも活気もあり良いプロダクトが生まれます。技術的な視点や着眼点に対する感性をチームで共有できるような組織を作りたいと思っています。そのためにも、自分自身がビジョナリーであり、道を示せるような存在でありたいと思っています。

サイバーエージェントには若手から「エンジニアリングマネージャーやプレイングマネージャーを目指したい」というメンバーも多数いて、自分も大いに刺激を受けています。自分と同じように「大きなビジネスを推進できる人間」が、若手からどんどん出てくるようなカルチャーにしていきたいですね。