記事のサマリー（TL;DR）
- kintone（導入社数42,000社以上）の性能ダッシュボードを小規模チームが開発、四半期ゴールに合わせた柔軟な意思決定が機能した
- BFF＋TypeScript・PRプレビュー環境・Grafana活用の3つの技術選択が並行開発と仮説検証の高速化を支えた
- 「大チームの当たり前をアンラーニングし、小チームの素早さを活かす」という開発スタイルが核心
kintone を業務基盤にする情シス・SaaS 開発担当が注目すべき点
kintone は国内42,000社以上に導入されており、アプリ数・レコード数が増えるにつれてパフォーマンス劣化が利用部門の悩みになりやすいプロダクトです。今回公開された「性能ダッシュボード」は、ユーザー企業側が自らアプリのパフォーマンス指標を確認・改善判断できる機能であり、従来はサポート経由で対処していたボトルネックの自己解決を促します。
また、kintone 上に専用 UI を構築したり外部 API と接続する開発を行っている場合、この性能可視化機能は設計上のボトルネック特定に直接役立ちます。情シス担当が「どのアプリが重いか」を自ら把握できるようになることで、外部委託の設計レビューや改善要件定義のサイクルも短縮されます。
詳細
背景：なぜこのテーマを取り上げたか
サイボウズが提供する kintone は現在 42,000社以上に利用されている大規模プロダクトです。2026年4月8日に開催された Cybozu Tech Meetup では「巨大プロダクトに小さいチームで大きな変化を起こす」をテーマに掲げ、kintone の性能ダッシュボード開発の裏側が公開されました。
「性能ダッシュボード」は、顧客自身がアプリのパフォーマンス問題を把握し、改善に向けた判断ができるよう性能指標を可視化する機能です。単にログやメトリクスを画面に表示するだけでなく、「どの情報を、誰が、どのように使えるか」を設計段階から考え抜く必要がありました。
セッション1：小さなチームで、大きなインパクトを——プロダクトと向き合う面白さ
登壇者：kenny（ダッシュボード開発副部 エンジニアリングマネージャー）
kennyさんは、ダッシュボード開発副部の組織的な取り組みと開発スタイルを紹介しました。
チームのスタンスは「向かう先は同じだけど、走り方は自由」。kintone 本体のビジョンやゴールを共有しながらも、独自の技術スタックと開発プロセスを独立して判断することで最速の動き方を選んでいます。「得意を生かす。得意を超える」という姿勢のもと、インフラ担当が UI/UX の議論に参加するなど専門領域の境界を意図的に超えた活動も行っています。
四半期ごとのゴールに対してチーム内で作戦会議を実施し、意思決定を担う体制も特徴的です。Cybozu Days（サイボウズ製品のユーザー・パートナー・社員が集まる年次イベント）のリリース日に合わせて、提供価値と開発コストの観点から開発内容を柔軟に変更した事例も紹介されました。
セッション2：kintone 性能ダッシュボードの迅速な価値提供を支えた技術的意思決定3選
登壇者：谷 昌典（ダッシュボード開発副部 プロダクトエンジニア）
谷さんは「仮説検証のサイクルを素早く回す」ために採用した具体的な技術的意思決定3点を解説しました。
意思決定①：BFF と TypeScript の採用
BFF（Backend for Frontend）で認証と DB 操作の層を分離し、モックサービスを活用することでフロントエンドとバックエンドの並行開発を実現しました。
意思決定②：開発初期からの PR プレビュー環境整備
プルリクエストにラベルを付与するだけで、DB を含むフルセット環境と DB をスキップしたモック環境を即座に起動できる仕組みを構築しました。開発環境そのものへの投資が開発速度の向上に直結する構造です。
意思決定③：Grafana を活用した表示内容の検証
ダッシュボードの UI を都度開発して試すのではなく、プロダクション環境上に立てた Grafana を使い「どのグラフが顧客にとって意味があるか」を先に検証しました。1回あたりの試行錯誤コストを抑える仕組みとして機能しています。
パネルディスカッション Q&A ハイライト
生成AI機能開発チームの齋藤さんがモデレーターを務め、以下のやり取りが行われました。
Q. 失敗したことややり直したエピソードは？
谷：当初はデータソースを複数想定して BFF を設計していましたが、開発速度を優先してデータソースとサービスを1つに統合しました。今振り返ればこの判断は良かったと思っています。開発を小さく進めてこまめに軌道修正しているため、取り返しのつかないクリティカルな失敗は発生していません。
Q. 大規模プロダクト×小チームで「これだけはやった方がいい」ことは？
kenny：リソースが少ないからこそ、エンジニアをプロダクト作りに巻き込み、チームの方向性を揃えることが主体性とアウトプットの質を上げます。
谷：大きなチームの「当たり前」を小さなチームにそのまま持ち込まず、一度アンラーニングして疑ってみる姿勢が重要です。小チームならではの素早さを活かせる改善を取り入れることが有効です。
Q. 当事者意識を高める工夫は？（視聴者からの質問）
kenny：四半期ごとのプロダクトロードマップ更新のタイミングでチーム全員で議論します。リリース前にはチーム全員でプロダクトを実際に触ってバグ出しをする会も実施しており、プロダクトへの愛着と当事者意識を育てています。
Q. 本番デプロイの自動テストと AI 活用の現状は？（視聴者からの質問）
谷：E2E テストでダッシュボードの表示を確認し、失敗時は CI で落とす仕組みにしています。インフラ面では AWS CDK のスナップショットテストを活用し、リソース変更があればテストが落ちる構成で意図したインフラを常に保証しています。品質保証工程への AI 活用については、現時点ではまだあまり進んでいません。
今後の関連イベント
- 2026年5月21日（木）：kintone フロントエンド16年の軌跡（サイボウズ東京オフィス現地開催）
- 2026年6月22日（月）：性能ダッシュボード開発チーム 続編イベント（企画中）
詳細は connpass にて順次案内予定です。