開発者をはじめ全社の意識変革に取り組み、AIを活用したSaaS企業からAI Platform企業へ転身を図り成長を続けている、AI inside株式会社。同社はどのように組織を進化させたのでしょうか。
オブザーバビリティ（可観測性）を活用した開発者体験の向上とエンジニア組織の変革について深い話題が展開された、『Developer eXperience Day 2024』（主催：日本CTO協会）における講演の模様をレポートします。
本記事はNew Relic株式会社・AI inside株式会社の講演「AIプラットフォーマーへの進化を支える良質な開発者体験とは」での、清水毅氏（New Relic株式会社 上席エヴァンジェリスト）と三谷辰秋氏（AI inside株式会社）による、講演とパネルディスカッションの内容をまとめたものです。
スピーカー紹介
清水 毅 / New Relic株式会社 上席エヴァンジェリスト
オブザーバビリティの導入・実践支援や市場に新しいアイデアを伝えている。ソフトウェア開発、インフラ設計運用、パブリッククラウドでのSaaS SAの背景を持ち、インフラ、パフォーマンス、セキュリティの設計から運用までが得意。とくに日本のIT業界でのエンジニアの地位向上と貢献に深い情熱を持って取り組む。
三谷 辰秋 / AI inside株式会社 Development Group Director of Use Division
東京工業大学を卒業後、システム開発会社を経て、2020年11月AI inside 入社。SREやQAを担う部門を率いた後に、現在は「DX Suite」開発・運用の統括および生成AIをはじめとするAI実運用を行う「運用基盤」の開発を担当。
目次
事業貢献するエンジニアを支える開発者体験とオブザーバビリティ（清水氏）
まず、オブザーバビリティに対する私の理解をお話しします。現代は、オブザーバビリティとして何を見なければいけないのか、わかりにくくなってきました。
従来の監視には以下の手法がありました。
●インフラ監視
●ログ監視
●アプリケーション性能管理
●リアルユーザーモニタリング
現在、New Relicでは、ビジネスオブザーバビリティという、売り上げやEコマースの発注が上がった下がったなどの、ビジネス上の数値の分析が可能です。
しかし、売り上げやサービスレベルが下がったときに、現象の把握だけではなく、その原因特定と修正まで行えないと事業に与えるインパクトは減らせません。ここが、私が意識しているビジネスオブザーバビリティの重要な部分です。
では、開発者体験とオブザーバビリティをつなげるとどうなるのでしょうか。
デベロッパーが主役になる世界に
事業を行う上で、アイデアを出し、開発し、お客様に届けたい。サービスを安定化させたい。機能もどんどん増やしたい。私もこれまでのキャリアの中で、それぞれのフェーズを経験しているのですが、立場ごとにサイロ化が起きていてミッションの中で喧嘩が起きていたことがありました。
VelocityとReliabilityも表面的には異なるので喧嘩になってしまうのですが、お客様に価値を届けたい想いは一緒です。このためにDevOpsとして私も取り組んでいたのですが、現在は変わってきています。
DevSecOpsのフルサイクルで、サイクル全体にデベロッパーが主役になる世界になってきています。デベロッパーがコンテナのデリバリーをやったり信頼性まで担当する時代になっています。
主役であるデベロッパーに対して、Security・Ops・Bizがイネーブリング・エンベデットな形でサポートするようになってきています。そういう会社がうまく機能するようになってきているんですね。
問題の特定と修正に貢献するオブザーバビリティ
OpenAI ChatGPTやGitHub CopilotなどのLLMで、たしかに開発者体験は変わりました。では、ビルド・デリバリー・問題の特定と修正はどこまで楽になりましたか、という疑問についてですが、こうした点にこそオブザーバビリティが生きてきます。
オブザーバビリティが開発チームに提供されると、1か所で原因特定や修正案まで教えてくれるようになります。さらに本番環境・テスト環境を含めてリアルタイムにフィードバックを受けることができます。
これらの指標が1か所にまとまっていて、Biz・Dev・Sec・Opsの要件が1か所に集まるので、オブザーバビリティプラットフォームがコミュニケーションハブになっていくのです。
事業貢献するエンジニアの特徴の話題に戻ります。そうしたエンジニアの特徴は、技術やデータを目的ではなく、事業貢献のための手段としているのです。そして、モチベーションも非常に高いです。チームワークもスピード感もあって、サイロを越えてさまざまなチームと連携できます。ここが非常におもしろいですね。
ここで、実際にこの開発者体験を実践されている三谷様に、AI insideの事例をお話しいただきます。三谷様、よろしくお願いいたします。
AIプラットフォーマーへの進化を支える良質な開発者体験とは（三谷氏）
AI inside株式会社の三谷です。当社がAI SaaS企業からAI Platform企業に進化する過程で、開発者体験をどのように改善したのか、また、そこにNew Relicがどのように寄与したのかをお話しします。
まずは、AI SaaSを提供してきた当社が、なぜAI Platform企業への進化に取り組むのかというお話です。
当社は、「AIで、人類の進化と人々の幸福に貢献する」をパーパスとし、その実現のために「“AI” inside “X”」をビジョンとして掲げています。「“AI” inside “X”」とは、あらゆる環境にAIを組み込んで誰もがその恩恵を受けられる状態をつくることですが、これまでのAI SaaSを提供してサービスの利用企業を増やしていく方法から、AI Platform企業としてユーザーやパートナーと一緒にAIを作り、より広く使ってもらえる状態を整えることが、さらなるビジョン追求につながると考えました。
では、AI Platform企業への進化の過程で、エンジニア組織にはどのような変化が起こったでしょうか。
重要なのは、ゴールの変化です。SaaSの企業としては、より多くのユーザーからロイヤリティを獲得することが重要でしたが、AI Platform企業としては、それに加えて顧客のビジネス価値を最大化することと、そのエコシステムを中心に自社があり続けることが重要になってきます。お客様のビジネスを中心に捉え、その中心に入っていくことを考えました。
これにともない、エンジニア組織も変わる必要があるのではないかと考えるようになりました。これからのエンジニア組織には
– 顧客のビジネス価値の理解
– ビジネスアナリティクス
– アジャイルのアプローチ＝小さく始めて高速で動かす
– クロスファンクショナルチームの推進
が大切になります。エンジニアチームがエンジニアとだけ会話しているのでは、プラットフォームビジネスは難しいだろうと考えました。
ただ、エンジニア組織の変革には課題もありました。具体的には以下の3つです。
– 受託マインド（分業化によるやらされ仕事感）
– 連携負荷（コミュニケーションコスト増大）
– KKD（勘・経験・度胸＝エンジニア個人のノウハウ）による運用
これらをどのように変革していったのかをお話しします。
受託マインドを撲滅する2つの施策
最初に着手したのはゴールの共有です。会社の目指しているところが、個人の目指しているところとつながっているかどうかが大切だと思っています。
会社にはPurpose・Vision・Missionがあり、だからこそプロダクトを通してお客様に価値を提供しています。当社ではAI Platform企業としての思考の転換を、エンジニア一人ひとりに説明しなければならないと考えました。
ただ、これらを1度、上長から説明を受けただけでは、エンジニアには響かないですよね。当たり前なんです。繰り返し繰り返し伝えて浸透させなければなりません。
次に、プロアクティブな価値提供です。
パフォーマンスから顧客像を妄想して検証することが重要です。New Relicはそれができるツールなのですが、ただ導入すれば解決するわけではありません。
導入することによる価値を感じないとエンジニアには触ってもらえないものです。障害が起きたときにすぐわかる・問題が特定できる・さらにシフトレフトして開発段階で問題が特定できる、などを実感してもらいながら、導入を進めました。
New Relicを導入して運用を変えていくと、お客様のビジネスの状態がなんとなく見えるようになってくるんです。この使い方でこんなリクエストが来る、コンポーネント間でこんな通信をしている、そういうことが可視化されます。
そのうち、お客様はこう使っているのでは、という仮説が出てきます。これをもとにお客様のもとに伺ったり営業を通して状況を聞いたりすることで、自分たちの仮説が正しいのかを判断し、実際にお客様がどう使っているのかを明らかにしていきます。こうすることでプロアクティブな価値の提供に視点が変わっていきます。
これまでは、何かが起きてから対応するインシデント駆動・障害駆動でしたが、そこからの変革を実感できました。この時点で、エンジニアはお客様の事業に興味を持ってくれるようになります。すると、新しい機能のアイデアや改善案に視点が切り替わってくるんです。
共通言語で連携負荷を軽減
次に行ったのは連携負荷の低減です。具体的には、プロセスの体系化と社内展開の改善です。運用をされている方は実感したことがあるかもしれませんが、「共通言語」が社内にないものなんですね。
お客様からの声として上がってくるのは「いつもよりちょっと遅い」「なんか遅い」のような表現ですが、現象を確認するエンジニアとしては「具体的に何秒遅いのか」「どのAPIのどの部分が遅いのか」なんです。
これらを解消するために、New Relicを使ってダッシュボードを作り、エンジニアだけでなく、営業、CS、経理なども含む全社員が同じ言語で語れる状態を作りました。
New Relicを使ったダッシュボードは業務委託の方まで見られます。社内で同じ情報を見た結果、「ここを深掘りしていこう」「問題を特定しよう」「修正しよう」というサイクルを回せるようになりました。
KKDからの脱却
KKDからの脱却のために、継続的な改善と最適化を検討しました。ここではデータに基づくフィードバックループの確立が大切だと思っています。
ここまでの対策でエンジニア組織の改善ができるようになりましたが、それをプロダクトへフィードバックしていくことが大切です。
データから得られたインサイトを確認してプロダクトへフィードバックして仮説検証を行う。これでお客様にとって良いものになっているのだろうかというサイクルが回り始めました。
リクエスト量やレスポンス速度など、問題個所の特定や判断にはNew Relicを使いました。我々が検証するだけでなく、お客様にとってビジネス価値はどこにあるのだろうかという視点でも追求することで、初めてわかったことも多かったですね。
データに基づいて改善を進めることによって、自然にKKDから脱却することができました。
清水氏・三谷氏によるQ＆A形式での対談
三谷氏の講演が終わり、清水氏・三谷氏による対談が行われました。清水氏の疑問に対して三谷氏が答える形式で進みました。
開発者体験におけるマネージメント
清水氏：長いお付き合いの中で、三谷さんのチームメンバーがとてもわくわくしているようすが伝わってきます。開発者体験をどう定義してどう提供してきましたか？
三谷氏：チームメンバーに情報をちゃんと提供することが大事です。システムの情報やビジネスの状況をちゃんと伝えられることで、エンジニアから「このお客さんの課題ならこういうソリューションを出そう」という話が出てきます。こういう状態が開発者体験として重要だと思います。プロダクトを通じて自分自身が社会貢献できていることの実感を得られるのが大切ですね。
清水氏：スタートアップのエンジニアの醍醐味の一つとして、自分のコードや作ったシステムが社会を変えているんだと思えることにあると思いますが、どうやってその満足感につなげていますか？
三谷氏：スタートアップやSaaSで開発したいエンジニアは社会貢献したい・社会に対して影響を与えたい、と思うんです。ただ、入社してみたら他から言われるものを作っているだけだった、というギャップを感じることもあるのではないでしょうか。
だから、実感できるようにツールで状況を可視化するとか、お客さんからのフィードバックが入ってくる状態をつくることが大事で、それを通して事業を作っている実感が得られると思います。
全社員がオブザーバビリティを使えるようにしている目的
清水氏：講演の中で触れられていたのですが、経理の方までダッシュボードを開放している目的をお教えください。
三谷氏：大きな会社ではないので、自分ごとになるようにすることが大事です。お客様に相対しているとかプロダクトを作っている、だけではなくて、会社としてプロダクトを作っている一体感は大事です。状況を知ることでお客様とのコミュニケーションも変わり、業務に生かされると思っています。
エンジニアの思考が変わった瞬間
清水氏：新しい開発の仕方に変わるターニングポイントはどこでしたか？
三谷氏：ある日を境に、というより、グラデーションのように変わりました。お客様のことを想像する回数が増えたり、何かしらのアハ体験をする人が社内で増えてくるんです。その結果、自然にミーティングの中で、お客様への価値提供についての話題が出てきます。そこで感じるようになりました。
AI Platform企業としてのエンジニアチームの展望
清水氏：AI SaaS企業からAI Platform企業に変わり、AIの民主化を目指していく中で、これからどのようなエンジニアチームを作ろうとされていますか？
三谷氏：エンジニア組織は、技術的な尖りももちろんですが、顧客視点を持ち続けることが大切だと思います。技術やプロダクトを世の中に浸透させる活動が大事になってくると思います。アーリーアダプターの人たちが使っているだけかもしれないことを、多くの人が使ってくれる状態にするためには足りないものがあって、それに対してどうアプローチするんだ、といった話を深めていきたいなと思っています。
清水氏：ありがとうございました。
取材後記：エンジニアを軸としたデータ共有が組織を育てる
企業のサイロ化・縦割り構造は長年にわたって組織改革の壁となり続けています。オブザーバビリティの概念がこの壁をどう壊していくか、三谷氏の実例は大きなヒントであり光となるのではないでしょうか。壁を壊す主役がエンジニアであることも、誇りとやる気を隆起させますね。
（取材／文：奥野大児）
