「技術的には正しかった」社内基盤が使われなかった理由。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はいま、システムの土台をクラウド時代に合わせて作り替えている。柱は2つある。一つは、システムを小さな区画に分け、ある区画で起きた障害が全体に広がらないようにする構成への移行。もう一つは、サーバーやデータベースといったインフラの設定を、手作業ではなくコードで書いて管理するやり方(IaC)を全面的に採ることだ。
PayPalはこの2つをまとめて、社内の開発者向けのプラットフォームにした。開発者がアプリケーションだけでなく、それを動かすインフラも自分で用意できるようにする狙いで、目標に掲げたのは「よりシンプルで速い体験」だった。
ところが、そのプラットフォームは開発者に定着しなかった。開発者は、よく知らないインフラの設定を自分で書き換えなければならなかったからだ。質疑でパテル氏は具体的な失敗も認めている。
「最初の失敗は、インフラのコードを1つのリポジトリにまとめて、そのまま開発者に開放したことです。必要な部品を詰め込んだリポジトリを渡したのですが、当然ながら期待どおりにはいきませんでした」
「開発者」といっても、求めるものは人によって違った
なぜ、リポジトリを渡すやり方ではうまくいかなかったのか。パテル氏は、開発者のなかに違う考え方が混在していたことを挙げる。
「安全のための制約を付けたうえでリポジトリを渡せば、とても喜ぶ開発者もいます。一方で、とにかくシンプルな窓口が欲しい、何もかも自分でコードを書くのは嫌だ、という開発者もいます。1つのやり方を試してみて、すべての開発者がそれで満足するわけではないと気づいたのです」
同じ「開発者」という利用者のなかに、自分で細部まで触りたい人と、結果だけ欲しい人がいた。リポジトリを渡すやり方は前者には合っていたが、後者を置き去りにしていたことになる。
そこでPayPalが用意したのが、AIエージェントを使った窓口である。開発者は社内のポータルで、何をしたいのかを書くだけでよい。例えば、新しい事業のためにこのアプリケーションを動かしたい、データベースと保存領域が欲しい、といった具合だ。依頼を受けたエージェントが段取りを組み、社内の各チームが提供している仕組みを呼び出して準備を進める。最後は、監視の設定やアクセス権限、主要な指標のダッシュボードまでそろった状態で、開発者に「準備ができました」と返ってくる。
複雑さは消さずに、裏側へ移した
注目したいのは、窓口を簡単にした代わりに、統制を緩めたわけではないことだ。PayPalには、セキュリティに関わるチームが12近くある。それぞれのチームが決めたルールは、開発者の依頼が届いた時点で、何かを変更する前に確認される。そのうえで、承認の手続きを通ってから、ようやくインフラが作られる。クラウド上のインフラはすべて、同じツール(Terraform)を通してしか作らない。これが、全員が合意した唯一の必須ルールだという。
パテル氏はこの仕組みを3つの層で説明した。いちばん上は、開発者が使うシンプルな窓口。真ん中は、エージェントが段取りを組んで実行を進める層。そして土台は、毎回同じ手順で確実に動き、安全性と信頼性を担保する層である。
「開発者には速く進んでほしい。同時に、インフラについて知っておかなければならない複雑な事柄に、足を引っ張られないようにしたいのです」
複雑さそのものは減っていない。それを誰が引き受けるかを、開発者からプラットフォームの側へ移したのである。
もっとも、パテル氏は解決済みの話として語ったわけではない。エージェントが行った変更を、常に誰によるものか後からたどれるようにすること。どこで人の判断を必ず挟むか。そして、開発者や重要な業務の流れを止めずに、それをどう簡単に保つか。こうした課題は「まだ目の前にある」という。窓口の形も、エージェント型を続けるのか、社内向けの開発者ポータルを別に整えるのか、まだ検討中だ。
PayPalが見誤っていたのは、想定していた利用者の中身だった。同じ開発者でも、求めるものが違ったのだ。では、想定していなかった利用者が「自分たちにも使わせてほしい」と言ってきたら、どうするか。IBM社内では、開発者向けに配ったAIツールに、プロダクトマネージャー(PM)とデザイナーが手を挙げた。
この記事は参考になりましたか?
- 「IBM TechXchange 2026」レポート連載記事一覧
-
- 「技術的には正しかった」社内基盤が使われなかった理由。PayPalとIBMに学ぶ、社内向け...
- Claude CodeもCopilotもある今、IBM Bobは何が違うのか。TechXc...
- バイナリ、リポジトリ、その次は? AI時代に開発者が共有する「成果物」をティム・オライリー...
- この記事の著者
-
斉木 崇(編集部)(サイキ タカシ)
株式会社翔泳社 ProductZine編集長。1978年生まれ。早稲田大学大学院理工学研究科(建築学専門分野)を卒業後、IT入門書系の出版社を経て、2005年に翔泳社へ入社。ソフトウェア開発専門のオンラインメディア「CodeZine(コードジン)」の企画・運営を2005年6月の正式オープン以来担当し、2011年4月から2020年5月までCodeZine編集長を務めた。教育関係メディアの「EdTechZine(エドテックジン)」...
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか?
この記事をシェア
