SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine(コードジン) DeveloperZine(デベロッパージン)- エンジニアの意思決定を支える技術情報メディア

ProductZine Day&オンラインセミナーは、プロダクト開発にフォーカスし、最新情報をお届けしているWebメディア「ProductZine(プロダクトジン)」が主催する読者向けイベントです。現場の最前線で活躍されているゲストの方をお招きし、日々のプロダクト開発のヒントとなるような内容を、講演とディスカッションを通してお伝えしていきます。

AI時代の「壁」を乗り越えろ。プロダクトマネージャーが直面するカオスと、現場を動かす「仕組み化」のリアル

ProductZine Day 2026

ProductZine Day 2026

「IBM TechXchange 2026」レポート

「技術的には正しかった」社内基盤が使われなかった理由。PayPalとIBMに学ぶ、社内向けプロダクトの広め方

「IBM TechXchange 2026」レポート

斉木 崇(編集部)[著]

 社内向けの開発基盤や業務ツール、全社に配るAIツールは、作り手が技術的に正しく作っても、それだけでは使われない。社内向けプロダクトがつまずく典型的なところだ。では、使われるようにするには何が要るのか。米アトランタで10月に開かれたIBMの技術者向けカンファレンス「IBM TechXchange 2026」の取材から、3つの事例を取り上げる。開発者に定着しなかった基盤を立て直したPayPal、開発者向けのAIツールを社内のプロダクトマネージャーやデザイナーへ広げたIBM、そしてそのツールを日本で売る現場が感じている「比べられ方」のずれである。

正しく作った基盤が、開発者に使われなかった

 「この取り組みを始めた当初、プラットフォームは技術的には堅実で安全でした。ただ、開発者に受け入れられ、使ってもらうのが本当に難しかったのです」

 IBM TechXchange 2026に先立って開かれた報道関係者向けの説明会で、こう明かしたのは、PayPal Head of Cloud and Platform EngineeringのShyam Patel(シャム・パテル)氏だ。同社でクラウドへの移行と基盤の刷新を率いている。

PayPal Head of Cloud and Platform Engineering シャム・パテル氏
PayPal Head of Cloud and Platform Engineering シャム・パテル氏

 PayPalはいま、システムの土台をクラウド時代に合わせて作り替えている。柱は2つある。一つは、システムを小さな区画に分け、ある区画で起きた障害が全体に広がらないようにする構成への移行。もう一つは、サーバーやデータベースといったインフラの設定を、手作業ではなくコードで書いて管理するやり方(IaC)を全面的に採ることだ。

 PayPalはこの2つをまとめて、社内の開発者向けのプラットフォームにした。開発者がアプリケーションだけでなく、それを動かすインフラも自分で用意できるようにする狙いで、目標に掲げたのは「よりシンプルで速い体験」だった。

 ところが、そのプラットフォームは開発者に定着しなかった。開発者は、よく知らないインフラの設定を自分で書き換えなければならなかったからだ。質疑でパテル氏は具体的な失敗も認めている。

 「最初の失敗は、インフラのコードを1つのリポジトリにまとめて、そのまま開発者に開放したことです。必要な部品を詰め込んだリポジトリを渡したのですが、当然ながら期待どおりにはいきませんでした」

「開発者」といっても、求めるものは人によって違った

 なぜ、リポジトリを渡すやり方ではうまくいかなかったのか。パテル氏は、開発者のなかに違う考え方が混在していたことを挙げる。

 「安全のための制約を付けたうえでリポジトリを渡せば、とても喜ぶ開発者もいます。一方で、とにかくシンプルな窓口が欲しい、何もかも自分でコードを書くのは嫌だ、という開発者もいます。1つのやり方を試してみて、すべての開発者がそれで満足するわけではないと気づいたのです」

 同じ「開発者」という利用者のなかに、自分で細部まで触りたい人と、結果だけ欲しい人がいた。リポジトリを渡すやり方は前者には合っていたが、後者を置き去りにしていたことになる。

 そこでPayPalが用意したのが、AIエージェントを使った窓口である。開発者は社内のポータルで、何をしたいのかを書くだけでよい。例えば、新しい事業のためにこのアプリケーションを動かしたい、データベースと保存領域が欲しい、といった具合だ。依頼を受けたエージェントが段取りを組み、社内の各チームが提供している仕組みを呼び出して準備を進める。最後は、監視の設定やアクセス権限、主要な指標のダッシュボードまでそろった状態で、開発者に「準備ができました」と返ってくる。

複雑さは消さずに、裏側へ移した

 注目したいのは、窓口を簡単にした代わりに、統制を緩めたわけではないことだ。PayPalには、セキュリティに関わるチームが12近くある。それぞれのチームが決めたルールは、開発者の依頼が届いた時点で、何かを変更する前に確認される。そのうえで、承認の手続きを通ってから、ようやくインフラが作られる。クラウド上のインフラはすべて、同じツール(Terraform)を通してしか作らない。これが、全員が合意した唯一の必須ルールだという。

 パテル氏はこの仕組みを3つの層で説明した。いちばん上は、開発者が使うシンプルな窓口。真ん中は、エージェントが段取りを組んで実行を進める層。そして土台は、毎回同じ手順で確実に動き、安全性と信頼性を担保する層である。

PayPalが社内の開発者向けに用意した仕組みの3層(説明会でのパテル氏の説明をもとに編集部作成)
PayPalが社内の開発者向けに用意した仕組みの3層(説明会でのパテル氏の説明をもとに編集部作成)

 「開発者には速く進んでほしい。同時に、インフラについて知っておかなければならない複雑な事柄に、足を引っ張られないようにしたいのです」

 複雑さそのものは減っていない。それを誰が引き受けるかを、開発者からプラットフォームの側へ移したのである。

 もっとも、パテル氏は解決済みの話として語ったわけではない。エージェントが行った変更を、常に誰によるものか後からたどれるようにすること。どこで人の判断を必ず挟むか。そして、開発者や重要な業務の流れを止めずに、それをどう簡単に保つか。こうした課題は「まだ目の前にある」という。窓口の形も、エージェント型を続けるのか、社内向けの開発者ポータルを別に整えるのか、まだ検討中だ。

 PayPalが見誤っていたのは、想定していた利用者の中身だった。同じ開発者でも、求めるものが違ったのだ。では、想定していなかった利用者が「自分たちにも使わせてほしい」と言ってきたら、どうするか。IBM社内では、開発者向けに配ったAIツールに、プロダクトマネージャー(PM)とデザイナーが手を挙げた。

次のページ
開発者向けのツールに、PMとデザイナーが手を挙げた

この記事は参考になりましたか?

「IBM TechXchange 2026」レポート連載記事一覧

もっと読む

この記事の著者

斉木 崇(編集部)(サイキ タカシ)

株式会社翔泳社 ProductZine編集長。1978年生まれ。早稲田大学大学院理工学研究科(建築学専門分野)を卒業後、IT入門書系の出版社を経て、2005年に翔泳社へ入社。ソフトウェア開発専門のオンラインメディア「CodeZine(コードジン)」の企画・運営を2005年6月の正式オープン以来担当し、2011年4月から2020年5月までCodeZine編集長を務めた。教育関係メディアの「EdTechZine(エドテックジン)」...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー