https://blog.cybozu.io/entry/2026/02/17/120000

「この部って具体的に何をするんだろう？」

プラットフォームエンジニアリング部に配属されて、最初に浮かんだのはそんな戸惑いにも似た疑問でした。
こんにちは。プラットフォームエンジニアリング部所属の aki (@aki366) です。

kintoneの開発部門には、「プラットフォームエンジニアリング部（以下、PfE部）」があります。
私はPfE部が自分の入社直前に新たに設立されたことを、入社後に知りました。「プラットフォームエンジニアリング」という言葉自体は、知っていましたし入社後の勉強会などを通じて触れてもきましたが、実際の現場でどんな課題意識があり、どういう狙いで部を設立したか――そこまでは、正直まだ輪郭をつかみきれていませんでした。

社内外からも、「kintoneのPfE部って何をする部なの？」「なぜ今、このタイミングで立ち上がったの？」といった声をよく耳にしますし、それは私自身が抱いていた疑問でもありました。

そこで今回、PfE部立ち上げを牽引してきたお二人に直接インタビューしました。

本記事では、PfE部が生まれた背景や狙いを、対談形式でひも解く3部作のインタビューをお届けします。
第1部の本作ではPfE部ができた生い立ちについてお送りします。

「kintoneのPfE部って、なんだろう？」
そんな疑問を持ったことがある方にとって、本記事が少しでも理解の一助となれば幸いです。

この記事の構成は以下の通りです。

自己紹介

aki：
改めまして、今回インタビュワーとしてお話を伺うkintone開発組織でPfE部の aki (@aki366) です。
まずは自己紹介と、ご自身がどんなタイプのエンジニアかお聞きしてもいいですか？
ちなみに私の趣味は週末のサウナと、今年小学生になる娘の成長を楽しむことで、エンジニアのタイプは、対話を重ねながら小さく動くものを作って前に進めるタイプだと考えています。今日は宜しくお願いします。

開発本部/kintoneプラットフォーム副本部/プラットフォームエンジニアリング部/サービスプラットフォーム副部/サービスプラットフォーム（Yakumo）チーム / 奥田晃洋

三苫：
PfE部の副部長をしています三苫 (@mitomasan) です。
年末に寒さで腰を痛めてしまったので今日はコルセットを巻いてインタビューに臨んでいます。冬場は腰にきますのでお気をつけください（笑）。
エンジニアのタイプで言うと、割と手を動かすときには泥団子的に手早く進めてしまうタイプなんですが、安定感のあるエンジニアでありたいと心がけています。今日はよろしくお願いします。

開発本部/kintoneプラットフォーム副本部/プラットフォームエンジニアリング部副部長三苫亮

上岡：
同じくPfE部の部長をしています上岡 (@ueokande) です。
趣味はドライブで、ロードノイズをBGMとして聴きながら長距離ドライブするのが好きです。
エンジニアのタイプで言うと、割と慎重派で障害対応は大好きなタイプですね。今日はよろしくお願いします。

開発本部/kintoneプラットフォーム副本部/プラットフォームエンジニアリング部部長 / 上岡真也

aki：
ありがとうございます。それでは早速お話を伺っていきたいと思います。

なぜ今、PfE部が生まれたのか

Q. PfE部が立ち上がる前って、どんな状況だったんでしょうか？

上岡：
まず前提として、僕や三苫さんが「新しく部を立ち上げるぞ」と決めたわけではないです。
kintoneの開発組織は、2024年から今までずっと、EMやアラインメントの取り組みを続けてきました。
事業価値に沿った形の組織構造とかや、チームが活動できる体制は、ずっと続けていたというのがまず背景としてあります。（ ref:サイボウズ流エンジニア組織の作り方 | CodeZine , ref:エンジニアが主導できる組織づくり | SpeakerDeck ）

上岡：
今あるチームや部は、以前は組織図に載ってなくて、当時はまとめて「バックエンド」と呼んでました。
アラインメント強化のために組織の形も変えて、公式的なチームや組織構造を、2025年の8月に組織図上に反映しました。
その時に「バックエンド」と呼んでいたものを、改めてPfE部として命名したという背景があります。

aki：
アラインメントの取り組みが2024年ぐらいから進んでいたんですね。以前もバックエンドという名前ではあるけど、プラットフォーム的な役割は担っていた、というイメージだったんでしょうか？

三苫：
そうですね。PfE部という名前にした背景とそれ以前がどうだったのかをお話しすると、以前のバックエンドと呼ばれていた時はサーバーサイドやその下の基盤、CI/CDパイプライン周り、ミドルウェアなど、お客様が直接目に触れることのないサービスの裏側の部分を担っているチームだったので「バックエンド」とまとめていました。ただ、それだと自分の責任範囲の部分をカッチリとやる、支えるという意識に寄りがちで、その基盤の上で稼働するサービスなど周囲の利害関係者とのつながりをあまり意識できない仕事のやり方になっているのが課題だと感じていました。

三苫：
たとえば、グローバル市場向けのインフラ基盤を担っているチームだと、その基盤のサービスレベルを維持する、稼働率をすごく高くしようとする取り組みも多かったんですが、一方でkintoneという製品自体の進歩に働きかける業務があまりできていなかったんですね。「基盤側がこうなっていれば、きっと製品全体で生産性が上がるようになる」という取り組みに目が行きにくい感じになってるのを変えたいと考えていて、そこがプラットフォームエンジニアリングという考え方がフィットすると思いました。

aki：
つまり、インフラやミドルウェアのサービスレベルの維持や稼働率に注力していた一方で、アプリケーションと一体で見たときに、基盤はどうあるべきか、全体を踏まえた判断が弱かったイメージですね。

三苫：
そうですね。上岡さんが言ってたアラインメントの話にもつながりますが、kintoneプラットフォーム全体としての方向性があって、そこから各チームへのアラインメントが取れて、それに沿う形で「自分達の領域をどう伸ばしていくか、取り組んでいくか」の部分が弱かったわけです。ですので、PfE部にしたというのも部内だけの事情での取り組みというより全体のアラインメントを取る流れとも一致している感じですね。

Q. もしこのままバックエンドのままだったら、厳しかったポイントってありますか？

上岡：
やっぱりプラットフォームってめっちゃ重要で、プラットフォームの作り方によって、アプリケーション開発側の生産性は10倍にも20倍にもなれば、 1/10にも1/20にもなるんですよね。もちろん既存のインフラとかバックエンドの保守運用も大事ですけど、プラットフォームを作るっていう視点は薄かったと思います。

上岡：
他にも「バックエンド」という名前がしっくりきてなかった問題がありまして。「kintoneのバックエンド」って聞くと、社外から見たらサーバーサイドを開発してるんでしょ？みたいな誤解がありましたね。

aki：
私も「バックエンド」と言えば、サーバーサイドを思い浮かべますね。

Q. PfE部を立ち上げると決めたとき、率直にどんな気持ちでしたか？

上岡：
部を立ち上げたのは、組織図としてファイナライズする1つの過程だったので、実際の変化は少なかったと思います。
ただ名前が変わったことで、「プラットフォームエンジニアリングって何だっけ」とか、一人一人が自分のチームとプラットフォームエンジニアリングを照らし合わせる機会を見かけたのは、嬉しかったかなと思います。業務がいきなり変わった訳ではないんですけど、そういった考えるきっかけを1つ作れたっていうのは、いいことだったかなと思いますね。

三苫：
プラットフォームエンジニアリングという名前にはしたけど、考え方そのものの理解は自分も含めてメンバー全員十分ではないだろうとも思ってました。
なので、ここはみんなで学んでいく必要があると思い、毎週の勉強会を開催しました。みんなで勉強しながら浸透させていかないと、誤解が生まれるだろうなとか、勉強したけどまだ腑に落ちないとかがあるので、継続的に考え方をインプットする必要があると思っています。

Q. なぜ “プラットフォームエンジニアリング” という選択をしたのですか？

三苫：
たとえば、プラットフォーム側で稼働率を 99.99% から 99.999%、その9を1つ増やす取り組みと、基盤をこう変えたら新機能を作る速度が10倍に上がる取り組みが2つあったとします。その時、kintone の開発組織で今は新機能を作る速度が遅くて困ってるという事実を知らずに9を1つ増やす方に力を入れてしまうというような事が起きないようにしたかったということです。

aki：
なるほど…。kintoneのプロダクト開発は、まず作ってみて価値を確かめながら進めることも多いと伺っています。
そうした進め方だと、基盤側がどこに投資するかの判断は、より難しくなりそうですね。

三苫：
両方とも大事なんだけど、アラインメントが取れてないと、全体の利益の総和が小さい選択をしてしまうことがあると思っていて、そこをkintoneプラットフォーム全体として一番効果の高いものを選べるようになりたかったわけです。

aki：
プロダクトとしての視点をより意識することでプラットフォーマーとして良い選択ができることが重要ということですね。

三苫：
名前に関しての変遷でいうと、世間での潮流なども踏まえて決めたところもあります。自分たちの役割を表す名前の候補として SRE や DevOps とかプラットフォームエンジニアリング以外にもあり、実際それぞれの考え方は独立しているというよりも関連していました。最終的には信頼性を高めるとか、どのようにインフラを扱うという所ではなく、インフラを提供するにあたってどういう考え方や態度でとりくむべきかという所でプラットフォームエンジニアリングが一番しっくり来るかなっていう所に落ち着きました。

上岡：
ようやく答えにたどり着いたなって感じがありますね。

aki：
名前を変えたことによって、社内外に対しても、自分たちの役割やミッションをより正確に伝えられるようになった訳ですね。

立ち上げ初期のリアル

Q. 部の立ち上げ当初、一番大変だったことを教えてください

上岡：
部を組織図上に乗せる時に、以前も今と同じ数のチームがあったのですが、その3つのチームってやってることって非対称というか、kintoneとそれ以外のプロダクトで境界が非対称だったり、組織図とシステムの境界線が、cybozu.comとkintone.comで非対称だったりしてます。8月のタイミングで各チームを再編成するとか、あるいは分割とかして整理しようかなって悩んでて。半年近く話していました。

aki：
時間を掛けて話していたんですね。

上岡：
三苫さんと大阪オフィスで「こうでもない、ああでもない」とチーム編成に関する議論を重ねて、最終的に当時のチームの業務範囲とかチームメンバーは編成せずに、名前だけ変えることにしました。

三苫：
チームの編成はそのままになっていますね。チーム編成はいくつか案も出しましたが共感はあまり得られず、最終的に「あるべき形はこうなんだよね」という共通認識と、「だからこう変えるんだ」っていうのを、共感を得られないまま変えてしまうのはよくないなと。

aki：
業務範囲自体は今の状態を維持しつつ理想とするところに向かうために、部の名前を適切なものに変えて自分達のやりたいことをまず認識できるようにしたのが今で、次はマインドとかやるべきことの目線を合わせていくイメージですね。その先に組織自体の見直しをしていく可能性もありそうですね。

三苫：
そうですね、これからプラットフォームとして価値を提供していくときに、いびつさや課題が出てくると思います。まだ棚上げのまま持ってきているところもあるので。これらは都度、課題として取り組んでいく必要があると思ってます。

Q. 社内からはどんな声や反応がありましたか？

上岡：
「バックエンド」から「プラットフォームエンジニアリング」って名前にしたとき、実際やることはガラッと変わらないのですが、そこで「業務内容大きく変わるんだ」「方向性が大きく変わるんだ」みたいな形で受け取られたのが、最初あったかなとは思いますね。それも悪いことではないと思っていて、考える1つのきっかけが出来たのかなと僕はポジティブに思ってますね。

aki：
確かに単純に部の名称が変わると、「自分たちがやることが一気に変わるんじゃないのか？」という反応は出てきそうですね。

aki：
三苫さんは社内から、どんな声や反応がありましたか？

三苫：
うーん、そうですね。正直想定外だったなという点では、名前が長くて呼びづらい。というのがありました（笑）

全員：
（笑）

三苫：
部の名前がこんなにしっくり来ないのかなとは思っています。
例えば、グローバル市場向けのインフラ基盤を開発しているチームの正式名称は
「開発本部 / kintoneプラットフォーム副本部 / プラットフォームエンジニアリング部 / サービスプラットフォーム副部 / サービスプラットフォーム（Yakumo）チーム」
といった所属になります。誤解を招くよりもそのものの名前をつけた方がいいだろうと判断したのですが、言いにくさの影響がちょっと大きいなと普段のコミュニケーションでも感じています。これはちょっと想定よりも大きかったかなと思ってます。

上岡：
ちょっと長い上にもう少し愛着の持てる名前にすればよかったなとは思いました。サービスプラットフォームはちょっと一般的すぎたかな、っていうのは今振り返って思います。

aki：
自分も長いなとは思っていたので、安心しました（笑）