kintoneプロダクトエンジニア業務紹介

kintone プロダクトエンジニア 業務紹介 判断が積み重なるプロダクトと、 エンジニアの仕事 1

⽬次 01 kintoneはいま、次の局⾯にいます P03 02 サイボウズについて P04 03 判断が積み重なるプロダクト、kintone P08 04 プロダクトエンジニアの役割 P14 05 kintoneプロダクトエンジニアが所属する組織とチーム P17 06 採⽤について P23 07 Appendix︓実際の取り組み P27 2

kintoneはいま、次の局⾯にいます kintoneは、4万社規模で使われ続けてきたプロダクトです。 安定稼働や互換性という制約を抱えながら、 プロダクトの前提そのものを更新し続けるフェーズにあります。 ここでは、判断が常に問われます。 この判断に、向き合い続けられる仲間を探しています。 3

サイボウズについて 4

サイボウズについて サイボウズの存在意義 チームワークあふれる 社会を創る サイボウズの理念は「チームワークあふれる社会を創る」こと。 私たちはその理念に沿ってチームワークを⽀えるソフトウェアを 開発し続けてきました。 5

サイボウズについて サイボウズの歩み 2022 売上⾼ (百万円) 単体売上⾼ 30,000 グループ売上⾼ 営業利益 （百万円） kintone 連結売上⾼ 100億突破 連結営業利益 25,000 6,000 5,000 2017- 20,000 2011 2002-2003 15,000 3,000 kintoneをリリース Garoonリリース メールワイズリリース 創業 10,000 4,000 クラウドビジネス転換 パートナービジネス開始 1997 kintone成⻑ 2,000 サイボウズ Office リリース 5,000 1,000 創業期 販売網開拓期・M&A期 クラウド転換期 24 年 20 23 年 20 22 年 20 21 年 20 20 年 20 19 年 20 18 年 20 17 年 20 16 年 20 15 年 20 14 年 20 13 年 20 12 年 20 11 年 20 10 年 20 09 年 20 08 年 20 07 年 20 06 年 20 05 年 20 04 年 20 03 年 20 02 年 20 01 年 20 00 年 20 99 年 19 19 19 98 年 0 97 年 0 kintone成⻑期 https://cybozu.co.jp/company/ir/meeting/pdf/2412_01.pdf 6

• https://cybozu.co.jp/company/ir/meeting/pdf/2412_01.pdf

サイボウズについて サイボウズの推しポイント 理念から製品までがつながっている 「チームワーク＝情報共有」という前提を、製品として実装してきた会社です ⾃分たちもユーザーとして使い、判断を磨いている kintoneを⽇常業務の基盤として使い続け、良し悪しを⾃分ごとで判断しています 制度・ツール・⾵⼟を、チームの判断のために設計している フルリモートも、チームで前に進むための前提です 会社もプロダクトも、まだ途中にある 国内外で成⻑を続ける中で、簡単ではない判断が増え続けています 7

判断が積み重なるプロダクト、kintone 8

開発の知識がなくても 業務に合わせたシステムを かんたんに作成できる クラウドサービス 9

判断が積み重なるプロダクト、kintone kintoneの現在地 15年進化し続けるプロダクトの、今をつくる • 2011年のリリース以降、成⻑してきた⻑期運⽤のプロダクト • 利⽤され続けていること⾃体が、制約であり強み • 既存の価値を守りながら、構造や設計を更新していく必要がある • きれいな0→1ではない環境で、判断⼒が問われる開発 技術的制約 安定稼働 互換性 既存ユーザー 10

判断が積み重なるプロダクト、kintone kintoneの現在地 多様な業務を背負う、影響範囲の広いプロダクト あらゆる業種の、あらゆる⼈の、あらゆる仕事をkintoneが⽀えています 11

判断が積み重なるプロダクト、kintone kintoneの現在地 プロダクトを越えて価値が広がる、プラットフォーム • オフィシャルパートナーは500社以上 • 連携サービスは500以上 • クラウド売上の6割以上が、パートナー経由で⽣まれている • kintone単体では完結しない価値提供が広がっている パートナー 連携サービス 社内外の業務 12

判断が積み重なるプロダクト、kintone 次の挑戦テーマ 成功の次に訪れる、最も難しくて⾯⽩いフェーズ 既存の価値を守りながら、次の成⻑をつくる。 kintoneはいま、その難しさと真正⾯から向き合っています。 挑戦テーマ • ⽣成AI︓業務利⽤を前提とした責任ある設計（kintone AIラボをリリース済み） • エンタープライズ︓全社基盤として耐えるための進化 • グローバル︓前提が異なる世界での再設計 13

• https://kintone.cybozu.co.jp/feature/kintone-ai-labo/

プロダクトエンジニアの役割 14

プロダクトエンジニアの役割 次の挑戦テーマ オーナーシップを持ってプロダクトを実現する • 仕様検討・設計・実装・レビューを通して、プロダクトの構造と品質をつくる • PdM・デザイナー・ビジネスサイドと協働し、技術と価値のトレードオフに向き合う • 運⽤上の不具合や問い合わせから、設計の歪みや改善余地を⾒つけ出す • 「なぜそうなっているか／どう変えるべきか」を問い続け、改善を積み重ねる エンジニアに求められる視点と判断 • ⻑期運⽤で蓄積された技術的制約を前提に、開発を進める必要がある • サービスを⽌めずに改善・刷新するため、影響範囲を⾒極めた段階的な判断が求められる • 将来の開発速度を守るため、未来を⾒据えた全体最適を選び続ける 15

プロダクトエンジニアの役割 技術的なチャレンジ kintoneの開発は、「成熟」と「挑戦」が同居する環境 成熟した⼤規模プロダクトとしての深化 • コード分割による開発効率の向上（P28） 正解のない領域への、次なる拡張 • プラットフォームを拡張する周辺サービス開発 • 古いライブラリの刷新と新しい価値の提供 • 性能ダッシュボード（P29） • ユーザーが安⼼して利⽤できる仕組みの強化 • 外部システムのkintoneアプリ化（P31） • 性能上の安定性向上 • AIの活⽤ • 性能特化アプリ • 開発者向けサービスの拡充 • ガバナンス機能の強化 16

kintoneプロダクトエンジニアが 所属する組織とチーム 17

kintoneプロダクトエンジニアが所属する組織とチーム kintoneの開発組織 ※2026年1⽉時点 kintoneプラットフォーム副本部 約190⼈ エンジニアリング部 プロダクトマネジメント部 プロダクトデザイン部 約140⼈ 販売管理システム 開発部 15⼈ プラットフォーム エンジニアリング部 21⼈ サービスプラット フォーム サブドメインクラス 管理開発部 16⼈ kintoneアプリ 開発部 共通横断開発部 開発者向けサービ ス基盤開発部 kintone Design System 48⼈ 32⼈ サブドメインクラス 管理サービス kintoneシステム 管理サービス開発 ナビゲーション サービス開発 エンドユーザー向け 開発 ダッシュボード開発 kintoneアプリ 管理サービス開発 AI機能基盤開発 ライティング kintoneアプリ サービス開発 モバイル開発 リサーチ kintoneアプリ 基盤開発 8⼈ ローカライズ 18

kintoneプロダクトエンジニアが所属する組織とチーム kintoneの開発組織 ※2026年1⽉時点 kintoneプラットフォーム副本部 約190⼈ エンジニアリング部 プロダクトマネジメント部 プロダクトデザイン部 約140⼈ 販売管理 販売管理システム 開発部 15⼈ プラットフォーム エンジニアリング部 インフラ 21⼈ ミドルウェア サービスプラット フォーム サブドメインクラス 管理開発部 サブ ドメイン16⼈ 管理 kintoneアプリ 開発部 共通横断開発部 社外向け 開発者向けサービ ス基盤開発部 OSS kintone Design System 48⼈ 32⼈ サブドメインクラス 管理サービス kintoneシステム 管理サービス開発 ナビゲーション サービス開発 エンドユーザー向け 開発 ダッシュ ダッシュボード開発 ボード kintoneアプリ 管理サービス開発 AI機能基盤開発 ライティング kintoneアプリ サービス開発 モバイル開発 リサーチ kintone 外部システムのkintoneアプリ 基盤開発 アプリ化 モバイル 8⼈ ローカライズ 19

kintoneプロダクトエンジニアが所属する組織とチーム 技術的なチャレンジ ⾃律したチームで、複雑なプロダクトを前に進める kintoneの開発は、チームで考え、判断し、実装を進めます。 正解が⽤意されていない状況でも、判断を持ち寄り、 ストリーム アラインドチーム 合意して前に進むことを⼤切にしているチームです。 特徴 EM、PdE、QA、SMが所属 ⼈数は合わせて3-8名程度 Designer • 顧客領域ごとのチームが、設計から実装までを担う • 職能を越えて協働し、チームとして品質と進め⽅に責任を持つ • フルリモート前提でも、議論と意思決定が⽌まらない EM PdE Writer QA SM PdM Localize 20

kintoneプロダクトエンジニアが所属する組織とチーム スクラム開発をベースにした1週間（＝1スプリント）の流れ 毎⽇の過ごし⽅（基本） 9:00 10:00 11:00 12:00 13:00 探求時間 朝会（15分程度） ＆ 開発時間 18:00 ⽉曜⽇ ⽕曜⽇ ⽔曜⽇ リファインメント リファインメント リファインメント 個⼈で学習・改善を⾏う プランニング リファインメント 開発時間 16:00 17:00 ⾦曜⽇ 開発チーム全体で実施 昼休み 14:00 15:00 ⽊曜⽇ モブプロやペアプロを ⾏うこともある リファインメント 必要に応じて開催 PdMとPdEの認識を揃える 成果物を披露し 各所からフィードバックを もらう スプリント レビュー ふりかえり 探求時間 21

kintoneプロダクトエンジニアが所属する組織とチーム 開発・リリース体制 リファインメント PdM プランニング 各タスクの実施 PdE Writer Designer QA PdE Designer QA 設計・実装 デザイン PdE 受け⼊れ確認 試験 PdM ⽂⾔作成 PdE Designer テスト PdE Writer PdE QA Writer Designer QA 22

採⽤について 23

採⽤について こういうエンジニアと、kintoneの次に挑戦したい 1. プロダクトの戦略や背景を理解し、チームの判断に主体的に関われる 理想への共感／⾃主⾃律 2. 複雑さやトレードオフを前提に、全体最適を考え続けられる あくなき探求／学びを重ねる 3. 変更の影響範囲を⾒通し、段階的な改善を選択できる やり遂げる 4. 判断の背景を⾔語化し、チームで合意をつくれる 対話と議論／⼼を動かす 5. AI・エンタープライズ・グローバルといった不確実なテーマを、前向きに楽しめる 果敢に挑む 6. フルリモート環境でも、対話を通じてチームの意思決定を前に進められる 対話と議論／公明正⼤／多様な個性を重視 https://cybozu.co.jp/recruit/about/personality/ 24

• https://cybozu.co.jp/recruit/about/personality/

採⽤について 採⽤フロー 書類選考 ⼀次⾯接 ⼆次⾯接 • エンジニア 2名 最終⾯接 オファー⾯談 • リーダー／マネージャー 2名 • ⼈事メンバー 1名 1ヶ⽉半 2週間 • 原則、オンライン⾯接で実施します • 質疑応答を中⼼とした⾯接です（コーディングテストはありません） • 1回の⾯接は50分程度です • 選考期間は1ヶ⽉半程度、オファー⾯談は2週間程度を想定しています 25

最後までご覧いただき ありがとうございました︕ このフェーズに、プロダクトエンジニアとして向き合いたい⽅をお待ちしています https://cybozu.co.jp/recruit/entry/career/product-engineer-kintone.html 26

• https://cybozu.co.jp/recruit/entry/career/product-engineer-kintone.html

Appendix︓実際の取り組み 27

Appendix︓実際の取り組み テーマの具体例① kintoneサーバーサイドの再構築 「⽌めずに進化させる」ために、責務の境界を再設計する 前提 / なぜ難しいか • ⻑期運⽤で蓄積したコードは、問題が「量」ではなく 責務の曖昧さに現れる • 影響範囲が読みにくく、変更のたびに判断コストが上がる • 実際にサーバーサイドは src/main/java 下で 35万⾏規模まで肥⼤化している 判断 / どう進めているか • PdMのメンタルモデルに沿って、機能単位で責務を閉じるようにコードを分割する • 外部に公開されたインターフェースを⽤意し、境界を前提にした設計ルールへ落とし込む • AIは「判断の代替」ではなく、重量級な定義作業を補助し、⼈の設計判断を継続可能にする 得られる価値 • 機能間の結合度が下がり、機能単位で独⽴した開発がしやすくなる • 影響範囲の⾒通しが⽴ち、改善を“段階的に”前へ進めやすくなる https://speakerdeck.com/hirokunimaeta/akitekutiyaconference-2025 28

• https://speakerdeck.com/hirokunimaeta/akitekutiyaconference-2025

Appendix︓実際の取り組み テーマの具体例② 性能ダッシュボードの開発 性能を可視化し、改善の判断を回す 前提 / なぜ難しいか • 数万社規模の環境を対象に、性能を定量化して⾒える化する必要がある • ただ作るだけでなく、「どの指標を⾒れば改善につながるか」という 判断が最初に必要 判断 / どう進めているか • kintone本体とは独⽴した サブサービスとして構築し、⽬的に合わせて技術選択を柔軟にする • 不確実性の⾼いフェーズでは、検証と学習を早く回すことを優先し、マネージド／サーバーレスを活⽤ 得られる価値 • 定量データを根拠に、改善の優先順位・効果検証の 判断サイクルを回せる 29

Appendix︓実際の取り組み テーマの具体例② 性能ダッシュボードの開発 Application Layer Frontend React + TypeScript SWR / Mantine / Highcharts Backend Hono AWS Lambda Data Platform OpenSearch Serverless Fluent Bit / Kinesis / Glue Infrastructure AWS / Kubernetes 30

Appendix︓実際の取り組み テーマの具体例③ 外部システムのkintoneアプリ化 外部データを、kintoneの⽂脈で扱えるようにする 前提 / なぜ難しいか • これまでの業務改善は、主に kintone内の業務・データが対象 • 外部システムを扱うには、接続⽅法や制約を含めた設計判断が必要 判断 / どう進めているか • 外部システムを kintoneアプリのデータソースとして扱う • kintoneで培った 操作や設定の考え⽅を、そのまま外部データに適⽤ • Proxy / Agent ⽅式により、境界と責任を分けて連携する 得られる価値 • kintoneの「外」にある業務・データまで巻き込み、業務改善の対象範囲を広げられる 31

Appendix︓実際の取り組み テーマの具体例③ 外部システムのkintoneアプリ化 これまで︓kintone内のデータを参照 アプリ ユーザー データ Goで開発された 常駐プログラムが常時接続し、 外部システムとの連携を担う 顧客ネットワーク 外部システムのkintoneアプリ化 アプリ Proxy Agent 外部システム kintoneアプリの 知識で活⽤できる 32

Appendix︓実際の取り組み フルリモートの実態 場所に依存せず、チームで判断を進めるための前提設計 前提 / 成⽴するか • kintoneの開発組織は、フルリモートを前提に設計されている • 個⼈作業ではなく、チームで判断する開発が基本 判断 / どう設計しているか • チーム単位で責任を持ち、⽇々の判断を完結させる • ⾮同期・同期を使い分け、議論と意思決定が滞らない形を選択 kintoneプラットフォーム所属 約190名の所属オフィス内訳 東京（129⼈）／⼤阪（22⼈）／松⼭（10⼈） ／福岡（13⼈）／ フルリモート（9⼈）※100km圏にオフィスなし／広島（6⼈）／名古屋（2⼈） ※2026年3⽉時点 33

Appendix︓実際の取り組み フルリモートの実態 ツールと場を分け、判断に集中できる運⽤ ⽇常のコミュニケーション • kintone / Garoon︓情報共有と意思決定の記録 • Slack︓⽇常的な対話 • Zoom / Teams︓判断が必要な同期コミュニケーション 対⾯コミュニケーション • エンジニア系組織を巻き込む 年2回のオフラインイベント https://blog.cybozu.io/entry/2025/08/15/080000 • チームビルディングを⽀援する制度あり https://cybozu.backstage.cybozu.co.jp/n/n0c8c63e003ac 出社率 • 20％弱。強制ではなく、チームの判断で使い分け https://cybozu.co.jp/human-capital/data/#working 34

• https://blog.cybozu.io/entry/2025/08/15/080000
• https://cybozu.backstage.cybozu.co.jp/n/n0c8c63e003ac
• https://cybozu.co.jp/human-capital/data/