状況が変化する中での意思決定
前回記事 なぜ、kintoneにプラットフォームエンジニアリング部は生まれたのか で触れた、プロダクト開発とプラットフォーム開発の 「時間軸の違い」。
- 探索型プロダクト開発（短期）
- 仮説検証 / 変更前提 / 速度重視
- プラットフォーム（長期）
- 安定運用 / 先回り設計 / 継続投資
どちらも正しい。
しかし前提が違うまま進むと、意思決定の場面で難しさが表面化します。
いま私たちが直面しているのは、「どちらが正しいか」ではなく、複数の選択肢の中から何を選ぶかという問題です。
選択肢が増えた世界で、どうやって選び続けるのか。
本記事では、その構造を掘り下げます。
こんにちは。プラットフォームエンジニアリング部所属の aki (@aki366) です。
この記事の構成は以下の通りです。
- 状況が変化する中での意思決定
- なぜプラットフォームは難しいのか
- PfE部は何を担う存在なのか
- PfE部のEMは、いま何に取り組んでいるのか
- PfE部が目指す未来とは
- 変わり始めている今、どう向き合っているのか
- まとめ
なぜプラットフォームは難しいのか
Q. 今のPfE部で、率直に難しいと感じていることは何ですか？
aki： 前回に引き続き 上岡 (@ueokande) さんと 三苫 (@mitomasan) さんにお話を伺っていきたいと思います。 まずは、今のPfE部で率直に難しいと感じていることから伺います。
上岡：
理想としては、プラットフォームを意識せずに開発者がデプロイできる状態にしたい。
今だとプロダクト開発側が、デプロイ先のプラットフォーム間の差分として全文検索で使っている OpenSearch か Elasticsearch かを意識しないといけない。
プロダクト開発側にプラットフォームを意識させてしまってます。
補足：国内市場向けのcybozu.comと、グローバル市場向けのkintone.comは異なるプラットフォームを使用しています。前者は国内のオンプレKubernetes、後者はAWSを採用しています。詳しくはこちらを参照ください。
aki：
なるほど。2つの基盤で異なる部分の扱いが難しいイメージですかね。
三苫：
その難しさには、kintoneの開発スタイルも大きく影響しています。
プロダクトは探索的に進めており、「作れば必ず伸びる」と確信しているわけではありません。実際、「どの程度の見込みで作るのか」と問われても明確には答えられない。
まず作り、価値があれば伸ばし、時間がかかりそうならやめて別を探す。一方、プラットフォームは体制を整えてからリリース・運用する性質があります。
そのため、探索型のプロダクトにプラットフォームが合わせようとするとミスマッチが起きやすい。タイムラインをどう揃えるか、何に取り組むのが効果的か。それをどう説明し納得してもらうかが難しい点です。
aki：
仮説検証を早いサイクルで回したいプロダクト開発側と、安定して動かしたいプラットフォーム側。どちらも正しいけど、一方の主張が強く出ると噛み合わないですよね。
上岡：
分からないからこそ、試行錯誤しているという感じですね。
Q. 組織面と技術面、それぞれで課題はありますか？
上岡：
組織面では、チームの分け方です。
部の外から見たときに、「この部、このチームに何を頼めばいいのか」が少し分かりにくい。そこはこれから探索するフェーズかなと思っています。
三苫：
技術面で言うと、新機能の作り方がかなり変わってきています。
長年kintoneの開発手法はモノリス中心でした。
cybozu.comの基盤は基本的に1つで、自由にサービスをデプロイできるわけでもなかったので、プロダクト開発チームは限られた環境の中で頑張るしかなかった感じですね。
それが、今ではK8sの導入により新機能を別サービスとして立てられるようになってきています。
ここからさらにプロダクト開発の動きは加速していくはずですし、今その始まりの段階にあります。
そして、それに合わせてプラットフォームとして対応すべきニーズも現場から具体的に上がってきています。
aki：
まさに今、その変わり始めているタイミングですね。
プラットフォーム側としても「どう支えるか」だけではなく、「どう進化を後押しできるか」を考えられるフェーズに入ってきている感じがしていて、難しさである一方で、変わり始めていること自体に可能性も感じました。
PfE部は何を担う存在なのか
Q. インフラエンジニアやSREと比べると、どんなところが違うと思いますか？
上岡：
僕の解釈だと全く別物だとは思ってないんですよね。プラットフォームエンジニアはプラットフォームを1つのプロダクトとして扱って、そこに対する事業価値とか、あるいはプラットフォームそのものの価値を高めるところにフォーカスして、そこの手段がSRE的なアプローチもあれば、インフラエンジニア的なアプローチもあるイメージです。
aki：
完全に別物であるという訳ではなくて、何にフォーカスするか、っていう見方が違う感じですね。
三苫：
やっぱり、プラットフォームを使ってもらうためにも、機能が足りないから使われないのか、稼働率が低いから信頼してもらえないのか、理由は複数あるんだけど、どちらか1つに集中してもプラットフォームというプロダクトの価値が上がる訳ではないと思っています。
両方を見てバランスを取って伸ばしたり、ボトルネックとなるところを対応していくっていうことが違う感じですかね。
それと、提供価値の一部だけを見ないことも重要で、与えられた要件で精度高く作るというよりも、利用側を慮って「ここが辛いんだね、だからこうしたら良くなるかも」と自ら課題を見つけ、対応して進んでいく。 そこがプラットフォームエンジニアリングかなって思います。
Q. 改めて、PfE部の役割を一言で表すとしたら何でしょう？
上岡：
一言で表すなら、プラットフォームの価値を高めてプロダクトの事業価値を高める部かなと思ってます。
三苫：
僕は曖昧な表現をするんですけど、人間の体幹に当たる部分かなと思っています。
製品開発チームは外界と触れる部分そのものを作っていっているんですけど、それを素早く安定的に動かすとなると、体幹がしっかりしてないとできないと思っています。
手を動かすには骨と筋肉が必要で、そこに血液がちゃんと流れているみたいなとこですよね。
プラットフォームはお客様が触れないけど、体幹の部分が外側と内側とがきちんと協調するように支える部分かなと思っています。
上岡：
いい例えですね。このサービス体幹いいとか、ちょっと体幹悪いって言えますね。
aki：
誰もがイメージできる、分かりやすい例えですね。
Q. 逆に、「これはプラットフォームエンジニアリングっぽくないな」と感じる行動はありますか？
三苫：
プロダクト開発側から「これを作ります」と言われたとき、性能要件や可用性を確認する問いかけも必要ですが、仕様が降りてきてその要件だけで作るのは少し違うと思っています。
プラットフォームを1つのプロダクトとして提供している立場として、プラットフォームのオーナーシップはPfE部が持ってるんですよね。
なので、要件や機能が降ってくるのを待つのではなく、自分たちが「こうしていく」と意思決定していく部分が大きいです。
プラットフォームエンジニアリングという名前をなぜつけたの？という話に戻って、要件が降ってくる前提の仕事をする進め方は、PfE部の名前を付けた部のやるやり方ではないってことですね。
仕事の進め方や態度的なところが大きいと思います。
aki：
「プロダクトとして提供してる」という視点が重要ということですね。
三苫：
例えばユーザーが「kintoneを買います」と言うとき、「その代わり、要件はこうしてください」と言うわけではないですよね。
kintone側が定めた可用性やデータ保護の水準を示し、それにユーザーが納得して使ってもらう。
利用側が可用性を厳密に定義して要求するなら、それって受託開発ですよね。
aki：
たしかに。PfE部として、なりたい姿から離れますね。
上岡：
やっぱりインフラ系って、こういった要件でインフラ用意してくださいと頼まれる側であることが、歴史的に多いかなと思っていて。
一方で、プラットフォームとして提供するときに、本番ワークロードに適していない構成だったら、アプリケーションを工夫できるかもしれないし、プラットフォーム側から「何かこういった使い方できませんか？」とか、「別の手段がありますよ」という形で提案できるのがいいとは思いますね。
aki：
たしかに。プロダクト開発をしている人達との対話がプラットフォームエンジニアとして重要ということがお二人の話を聞いて理解できました。
PfE部のEMは、いま何に取り組んでいるのか
Q. アラインメントで大変なこと、意識してることってありますか？
三苫：
上位の抽象的な方向性と、現場で実際にやることの間。
大きな方向性から実務に至るまでのロジックを、情報を落とさずに伝えるのが難しいですね。
抽象的な方向で「よし、やっていくぞ！」と盛り上がっても、「で、これは何でしたっけ？」と具体まで繋がらないと、普段のやることに気持ちが乗らない。
要するに「総論賛成、各論反対」みたいなのが真ん中で生まれる。
そこを上手く繋げるのは難しいし、これからも頑張りたいです。
aki：
上岡さんはどうですか？
上岡：
組織全体でアラインメントする上で大事なのは、チームの代表者やEMが方向性を理解して、自分の言葉で伝えることです。
今のkintone開発組織は、チームの代表者や、その上位の三苫さん、さらに上位のkintone開発全体を見るEMがいます。
部やチーム・メンバーが実行するには、間に立つEMが翻訳するのが大事かなと思ってます。
aki：
アラインメントって「分かりやすい方針が上から降りてくる状態」になって、メンバーの主体性が薄れてしまう可能性ってないんでしょうか？
上岡：
アラインメントはトップダウンではありません。
チーム単体にとって重要なことがあるかもしれないけど、事業全体としても大事なことがある。
アラインメントって組織全体で同じ方向を向いてゴールを目指すのが大事なんですよね。
方向を揃えるというのは、全員が回れ右するのではなく、それぞれのチームが持っている選択肢の中で、道を見つけることだと思っています。
三苫：
僕らが今後やっていきたいのは、数ある選択肢の中からチーム自身が「これが最善」と見出し、「これをやる」と決めたときに、それが事業全体の方向性とも合致していると認識を揃えて進めることです。
「このチームはこうする」と上から決めればトップダウンになります。そうではなく、まずメンバーに選択肢を出してもらい、その中から何を選ぶかを共に考える形が望ましい。
上岡：
元Spotifyの人が書いたアラインメントできていない例え話で、「川を渡るために、こっちの人は橋をかけるぞ、こっちの人はトンネルを掘るぞ」っていうのがあって。
こういう状態を起こさないために、たとえば「みんなでトンネルを掘るぞ」って活動の方向性を揃える。 あるチームはトンネルを掘るのが苦手かもしれないけど、皆でトンネルを掘るなら全体で川を渡れる、を達成できると思います。
aki：
分かりやすい例えですね。
ここまで、方向をどう揃えるかという話を伺ってきました。
その上で、実際の判断の場面についても聞いてみました。
Q. 複数の選択肢が並んだとき、優先順位を決めるのが難しかった判断はありましたか？
三苫：
そうですね、例えば "E2E基盤の安定化" のように、安定性を高める投資と、"Argo CD の導入" のように開発体験を高める投資のどちらを優先するかで、認識が揃わないことがありました。
別のチームでは、"デプロイ頻度を上げる取り組み" と、"全体パフォーマンス課題への対応" という選択肢があって、最終的にはデプロイ頻度向上を優先していますが、この選択で良かったのか、今でも少し悩ましいですね。
上岡：
いま三苫さんが挙げたような例も含めてなんですけど、プロダクト開発側とプラットフォーム側が対立している、という話ではないですね。
プロダクト側に投資すれば開発生産性が上がるし、プラットフォーム側に投資すれば可用性が上がる。
どちらも合理的なんですよね。
だからこそ、いま何を優先するのかを決める必要がある感じかなと思います。 どういう活動であっても何らかの価値があると思いますが、その中で何を選ぶかが重要になってきます。
PfE部が目指す未来とは
Q. 少し先の未来ですが、PfE部はどんな状態になっていたら嬉しいですか？
上岡：
プラットフォームって Google Cloud も AWS もたくさんある中で、この部が作っているものを選んでもらう。
そのために魅力を知ってもらって、使った人から「これめっちゃ便利じゃん、使おう」ってなる状態ですかね。
例えば、「kintoneがあって良かった」と言われるように「プラットフォームがあって良かった」と存在感を持てると嬉しいですね。
aki：
そう言ってもらえると本当に嬉しいですね。
三苫さんは、どんな状態になっていたら嬉しいですか？
三苫：
3つあって1つ目は、利用側のチームが自律的に完結できるフルサイクルな構造にしたいんですよ。
機能を作ってデプロイするところまでを自律的にプロダクト開発側で行えるサイクルを回したい。
今まさに進めている Argo CD（ ref: ）の導入で、マニフェストを書いてデプロイする流れを開発チームの責任で回せるようになります。
そうなるとプラットフォームがセルフサービス型になって、理想的な状態に近づくと思っています。
三苫：
2つ目は、PfE部もプロダクト開発側のように疎結合で自律的に回っていくチームにしたいですね。
PfE部の中がモノリスだと柔軟に変えづらくなる。
お互いが疎結合でありながら、アラインメントされたチームの形が実現できたら嬉しいですね。
三苫：
3つ目は、プラットフォームをプロダクトとして捉えるなら、マーケティング視点は絶対必要だと思っていて。
その視点が身についてリサーチして作る、作ってアピールできる、を各チームが自律的にできる状態になると嬉しいです。
変わり始めている今、どう向き合っているのか
Q. 今のフェーズの面白さは、どこにあると思いますか？
上岡：
伸びしろだらけの、埋蔵金のようなチームだと思っています（笑）
技術的な伸びしろもありますが、どちらかと言えば「プラットフォーム提供者としての意識」の方が伸びしろだと思いますね。そこが一番大事で、そこの意識を変えたら、多分課題は勝手に解決するかなと思っています。
三苫：
組織としてはこれから拡大していくフェーズだと思っています。kintoneの機能開発も進み、チームもスケールしていく展望があります。
分散して開発できる体制を目指す中で、プラットフォームが必要とされる場面は確実に増えています。ただ、組織構成自体は大きく変わっていないので、新しいプラットフォームが出てきたときに、どこが担うのかがまだ整理しきれていない。そこは組織面の課題ですね。
aki：
やることも増えるし、組織もスケールさせないといけない。
正解が一つに定まらない中で、何を選ぶかを決め続けなければならない。
だからこそ今は、面白い。
まとめ
何が一番よい選択か、誰もわからない。
複数の正解がある世界で、どう選ぶかを設計しようとしている組織。
始めたばかりだからこそ、選び方を設計し続けています。
それが、いまのPfE部の現在地です。
次回は、PfE部というチームの「中身」に焦点を当てます。
いま、このフェーズでどんな人たちが挑戦しているのか。
そして、これからどんな仲間と一緒に進みたいのか。
続きでは、チームそのものについてお届けします。
──────────────
◀ 前の記事：なぜ、kintoneにプラットフォームエンジニアリング部は生まれたのか
次の記事 ▶：理想のプラットフォームを目指す、kintoneプラットフォームエンジニアリング部の仲間たち
──────────────
イベント情報
採用情報
【変更履歴】 2026年3月9日 次の記事のリンクを追加。
