kintoneのダッシュボード開発チームの紹介 - チャレンジ & わいわい
プロダクトエンジニアの谷(@uta8a)です。2025年にkintoneのダッシュボード開発チームにジョインして、1年半近くプロダクトエンジニアとして働き、kintoneの性能ダッシュボード、利用状況ダッシュボードのリリースに関わってきました。今日はチーム紹介をします！ kintoneを、もっと安心して大規模に活用していくために必要なこと kintoneは、様々な業務システムが作れる業務改善プラットフォームです。 現在42,000社(執筆時点)に使われているkintoneは、多様な業務を支えています。しかし、大規模利用に伴い足りない部分も出てきました。 アプリの操作が重いという問い合わせを、現場からIT部門が受け取る IT部門がkintoneの活用を促進していきたいが、どう使われてきたのか分からない こうした大規模利用に伴う不安への対応や、もっとkintoneの利用を拡大していくための後押しが必要です。 これらの課題はお客様が現状を把握できることがまず必要だと考え、kintoneの状態を時系列で把握できるような、管理者向けダッシュボード機能を開発しています。 (性能など、改善もセットで必要な部分は別チームで取り組んでいます！ *1 ) ダッシュボードの開発によって、例えば次のような効果を目指しています。 このペースの利用増だと性能問題が起こりそう。性能カスタマイズオプションを検討しよう 社内のkintone活用の実態が分かった。全社導入に向けて動いていきたい このようにして、もっと安心して大規模にkintoneを活用していける世界を目指しています。 もっと安心して大規模にkintoneを活用していける世界を目指しています kintoneのダッシュボード開発チームの取り組み 今までに、3つの種類のダッシュボードをリリースしています。 性能ダッシュボード 大規模利用顧客向けに、アプリの性能情報を見て改善の効果測定に役立てる 利用状況ダッシュボード 社内のkintone活用状況を見て、活用促進に繋げられる 社内向けダッシュボード サイボウズ社内でのお問い合わせ対応や、次に作るダッシュボードを考えるヒントとして利用する これらのダッシュボードで価値を素早く提供するために、以下のような取り組みをしています。 既存プロダクトとビジョンを共有しつつ、作るものを自分たちで決める ダッシュボード開発はkintone本体とは独立したチームとして開発している プロダクトエンジニアとして、kintone本体の理解を深めつつダッシュボードの役割を考えて開発 チームで意思決定の精度を上げていく 開発速度だけでなく、何を作るか、どういう順番でタスクを進めるかといった意思決定に関する会話がチームで行われる ツール・環境・プロセスを柔軟に試して取り入れる AIツール(Claude Codeなど)はもちろん、小さなチームだからこそ柔軟にやりやすいように開発プロセスを変えていける強み Findy Team+を利用して開発にまつわるメトリクスを活用した振り返り 個人的には、特に意思決定の精度は高いなと感じます。AIによってやることが高速になっても、無駄なことをたくさんやっていたらあまり嬉しくないです。結局何をやるか、どういう順番で進めていくかという意思決定の精度が重要だと思います。例えば、チームの朝会で会話を通してその視点あるなぁ...という気持ちになったりすることがあり、チームで意思決定の精度を上げていると思っています！ チャレンジ & わいわい チームの雰囲気としては、kintone開発の中でも比較的パイオニア寄りというか、小さく実験的なチームなのでチャレンジしていこうという感覚が強いです！とりあえずやってみたいことは試してみて、ダメだったら撤退できる環境であり続けたいと思っています。チャレンジ！ あと、あまり枠組みにとらわれずわいわい越境していこうというのも特徴的です。例えば、私はもともとAWS周りのインフラをメインで取り組んでいたのですが、チームで働く中でフロントエンドのタスクを取ったり、デザイナーやEMと作るものについて議論したりと活動範囲を広げることができました。 リリース後のオンラインお祝いや、対面でのチームビルディングも盛り上がります！わいわい！ 対面でのチームビルディングでみんなで作ったご飯。盛り上がりました。 一緒に働きましょう もっと安心して大規模で使えるkintoneを目指して、ダッシュボード開発に一緒に取り組んでくれる仲間を募集しています！ cybozu.co.jp 小さなチームで大きなインパクトを起こすことに興味があれば、ぜひカジュアル面談からでもお話しましょう。 *1:性能カスタマイズオプション など
- kintone
- AWS
- フロントエンド
サイボウズにフロントエンドエンジニアとして新卒入社して1年が経ちました
こんにちは、フロントエンドエンジニアのmehm8128です。 僕は25卒としてサイボウズに新卒入社し、内定者アルバイト時代も合わせると1年半なのですが、正社員としてはちょうど1年が経ちました。弊社1年目ではどんなことができるのかという参考に、書いてみました。 フロントエンド基盤の刷新 サイボウズのほとんどのフロントエンドエンジニアの多くは、主力製品であるkintoneのフロントエンド基盤の刷新プロジェクトに参加しています。 普段は個人としてアクセシビリティに関する発信を多くしていることから、業務でもアクセシビリティ関連のことをメインでやっていると思われていることがあります。しかし実際には、フロントエンド全般に幅広く関わっています。 今のkintoneの大部分は、Google Closure Toolsというフレームワークで作られています。しかしこれは2024年にEOLになったこともあり、今では「Google Closure Toolsといえばサイボウズ」と言えるくらい他で見ないものになってしまいました。そこでフロントエンド基盤の刷新プロジェクトでは、kintoneを全てReactに置き換えています。 その中でも僕のいるチームはkintoneのアプリ機能という、kintoneの中でも最も基本的な機能の刷新を行っています。アプリ機能の画面では、ユーザーがシュシュっと作成したアプリに対してレコードを追加したり、そのレコードの一覧や詳細情報を閲覧したりすることができます。 レコード一覧画面（開発中の画面） もう少し詳しい説明は過去の記事をご覧ください。 blog.cybozu.io blog.cybozu.io 現在のチームのメンバー構成としては、EM1人、SWE5人（自分はここ）、QA2人となっています。多いときは内定者アルバイトメンバー含めてもう4人ほど所属していました。 内定者アルバイトのメンバーを除くと自分は最年少ですが、フロントエンド基盤の刷新はやることが多く、かつなるべく最短で完了することが求められていることから、新卒1年目の自分でもタスク管理や内定者アルバイトメンバーのサポートを行うことが多くあります。それ以外は、与えられたタスクやコードレビューをひたすらこなしたり、必要に応じて他チームとの連携を図ったりしています。 ここからは具体的な業務内容をいくつか紹介していきます。 インライン編集機能の実装 前述の内定者アルバイト時の記事にも記載したのですが、インライン編集は僕がメインで実装した大きい機能のうちの1つです。 レコード一覧のテーブル行で編集ボタンをクリックすると、テーブル上でそのレコードの情報を編集できます。記事にも書いたのですが、モード切り替え、各フィールドのUI配置、編集した値の保存処理、データの変換処理という複数の作業が必要で、規模が大きいタスクでした。 インライン編集（開発中の画面） kintoneはアプリのフォームに様々な種類のフィールドを配置することができ、それぞれ特徴が違います。例えば以下のような特徴を持つフィールドがあります。 値を編集できるフィールド 例：文字列（1行）フィールドやユーザー選択フィールド 値を編集できないフィールド 例：ラベルフィールドや作成者フィールド フィールドの中にフィールドを入れられるフィールド 例：テーブルフィールドやグループフィールド 編集画面では編集できるけどインライン編集では編集できないフィールド 例：添付ファイルフィールドやルックアップフィールド jp.kintone.help これらを踏まえて、編集できないときの表示や、そもそもテーブル上に表示しない場合、通常は編集できるけど特定のユーザーには編集権限を与えられていない場合、などを意識しながら実装する必要がありました。もちろん全部1人で実装したわけではないですが、基盤部分は僕が実装したのでkintoneのアプリ領域の複雑さを体験できる良いタスクでした。 グラフ設定ダイアログの実装 グラフ設定ダイアログは、半年ほど前に実装したものです。こちらも多くの部分を僕が実装しました。 kintoneでは、アプリに登録されたレコードの情報をグラフ形式で閲覧することができます。レコード一覧画面・レポート画面の「グラフを設定」ボタンをクリックして開くダイアログ上で、グラフの種類や集計に使うフィールド、絞り込みなどの設定をすることができます。 jp.kintone.help グラフ詳細画面（開発中の画面） グラフ設定ダイアログ（開発中の画面） アプリ設定画面でも同様のグラフ設定画面があり、そちらは既に他チームが実装済みだったので、中心となるロジックはそちらから取ってくることができました。しかし、アプリ領域の仕様・既存コードとの整合性を取ったり、URLのパラメータから取得した初期値をグラフ設定ダイアログ用に変換して適用したりする作業にかなりの時間を費やしてしまいました。 反省点としては、もう少しコンポーネントテストやロジックの単体テストを多く書きながら進められると良かったのかもしれません。ちなみに最近『単体テストの考え方/使い方』を読んだので、個人的にフロントエンドテストについてもう少し探求してみたいと考えています。 デザイナー・デザインシステムチームとの連携 チームの中でも、僕はデザイナーチームやデザインシステムチーム（厳密にはデザインテクノロジストという、デザインシステムに限らず開発チームとデザイナーチームとの橋渡しをする役割を持っているチーム）との連携を取ることが多いです。僕がロジック寄りの領域よりも、HTMLやCSS、アクセシビリティなどUI方面の領域に興味を持っていることから、いつの間にか自分がこの役割を担うことが多くなっていました。 具体的な例として、定例ミーティングを紹介します。 週1で30分、僕が所属する本体開発チームに加えてデザイナーチーム、デザインシステムチームの3チームから一部のメンバーが集まって合同でミーティングを行い、アプリ領域の開発を進める上での相談事を持ち込んで議論しています。 例えば本体開発チームからは、以下のような議題を持ち込むことが多いです。 デザイナーさんに作ってもらったデザインを実装する上で技術的に難しく、妥協案を相談したい部分 少し複雑なインタラクション実装において、アクセシビリティを確保するための実装方針 既存のデザインシステムのI/Fのままでは実現するのが難しそうな箇所 <img src="https://cdn-ak.f.st-hatena.com/images/fotolife/c/cybozuinsideout/20260401/20260401113023.png" alt="Garoon予定にmehm8128が投稿したコメント。「カレンダーの年月の入力欄＋ポップアップがkDSのInputDateと違う（日の入力欄がない）ことに気づいたので、そこ&
- React
- フロントエンド
- UI
- アクセシビリティ
- Web標準
kintone フロントエンド開発における AI 活用の取り組み
こんにちは！サイボウズでプロダクトエンジニアをしている @daikimkw です。 この記事では、kintone のフロントエンド開発で AI をどのように活用しているか、そして kintone 開発全体として生産性を向上させるために今後どのような取り組みをしていくかについて紹介します。 kintone 開発での AI 活用については、以下の記事でも紹介しています。 サイボウズで利用可能な AI コーディングツールの紹介 kintone AI 開発の効率化！Claude Code に Renovate PR レビューをお任せした話 チーム専用の Claude Code Plugin マーケットプレイスを作った話 また、本記事の取り組みの一部は JS ConfJP 2025 で発表しているので、そちらの動画や資料も参考にしてください。 www.youtube.com 資料：大規模プロダクトで実践するAI活用の仕組みづくり AI 活用の取り組み kintone は顧客領域ごとに複数チームで開発されており、コードベースの規模も大きく、AI をうまく機能させるにはいくつかの工夫が必要でした。 ドメイン知識をマークダウンで管理する kintone は歴史的経緯や最適化のための工夫により、コードを読んだだけでは意図が伝わりにくい設計が多くあります。これらを AI に都度伝える必要がないよう、ドメイン知識をマークダウンファイルとしてリポジトリに配置し、AI が参照できるようにしています。具体的には、JS API・プラグイン機構・グラフなどの複雑な実装の設計背景や、kintone 固有の用語集などです。 kintone のフロントエンドはチーム単位でディレクトリが分かれており、その中で pnpm の monorepo として構成されています。この構成を活かし、ドメイン知識のマークダウンもチームごとに配置しています。こうすることで、AI が参照するコードとコンテキストの範囲がチームの担当領域に絞られます。グラフなどの複雑な実装や設計背景も、グラフを管理しているチームに閉じられるため、他チームのコンテキスト消費を抑えられます。 frontend/ ├── teamA │ ├── ai-guide # ドメイン知識をチームごとに管理 │ │ ├── js-api.md # JS API の設計 │ │ └── glossary.md # 用語集 │ ├── app1 │ ├── app2 │ ├── pnpm-workspace.yaml ├── teamB │ ├── ai-guide │ ├── app1 │ ├── app2 │ └── pnpm-workspace.yaml └── ... Agent Skills をチーム横断でリポジトリ管理する kintone 開発では、もともと各チームで Agent Skills を整備していました。 kintone リポジトリのルートに共通の Agent Skills もいくつかありましたが、チームによっては不要な Agent Skills が混ざっていると不要なコンテキスト消費につながってしまいます。一方で、チームの中だけに閉じていると知見がサイロ化してしまいます。 そこで、お互いの Agent Skills を参考にしつつ、チームごとに必要なものだけを選んで導入できるように、kintone 開発全体で共有する共通リポジトリを用意しています。 kintone-skills/ ├── kintone-development/ │ └── skills/ # 汎用 Agent Skills ├── teamA/ │ └── skills/ # チーム固有の Agent Skills └── teamB/ └── skills/ Claude のプラグインマーケットプレイスの構造に準拠させているため、 /plugin から追加でき、Cursor など他のツールでも vercel-labs/skills 経由で利用できるようになっています。ルールは設けず自由に追加できる運用にすることで、他チームがどんな Agent Skills を作っているか見える化し、知見がサイロ化しないようにしています。 具体的な Agent Skills の紹介 実際に使っている Agent Skills をいくつか紹介します。 文言の検討 kintone は多言語対応しており、新しい機能を実装するときには複数言語の文言を用意する必要があります。ただし、デザインシステムのライティングガイドラインや既存の文言パターンとの一貫性を保つのは手間のかかる作業です。この文言作成・レビューのワークフローも Agent Skills 化し、効率よく文言の検討を進められるようにしています。 以下は、「input:type=file にホバーしたときに相当する文言を検討して。」と入力した時の結果です Claude Code とのやり取りのスクショ セッション情報をファイル出力する AI とのやりとりはセッションが途切れたり、サマリー化（Compact）されるとコンテキストが失われます。そこで、AI とのやりとりや、実装計画を全てファイルに出力して残すようにしています。 実装開始時に、次のようなディレクトリを作成します。 0123_feature-name/ ├── plan.md # 実装計画 └── prompt.md # やりとり履歴 plan.md には、実装計画、タスクの分解、進捗を記録します。prompt.md には、生のプロンプト内容と、それに対してどう実装したかを記録します。どういう指示を出して、AI がどう判断したかが残るため、コンテキストの復元に役立ちます。 この 2 つのファイルにより、セッションが途切れても作業を再開でき、計画と実装を別のエージェントに任せるなど、柔軟にエージェントを切り替えることもできます。 エージェントによっては、実装計画専用のプランモードがありますが、プランモードを抜けるタイミングでファイル出力等のコンテキストを忘れてしまうため、今はプランモード相当のサブエージェントを使用しています。プランモードを抜けるタイミングで Hook させ、思い出させることができればもっと良いのですが、今のところはこのようになっています。 ドメイン知識を継続的に育てる ドメイン知識を管理するマークダウンファイルは実装が進むにつれて内容が実態と乖離していきます。そのため、定期的に実装とドキュメント内容に乖離がないかチェックするための Agent Skills も用意しています。 MCP の活用 Agent Skills だけでなく、MCP も AI の作業範囲を広げるのに役立っています。 kintone には kintone Design System チームが管理するデザインシステムがあり、デザイントークンやコンポーネントの仕様が Figma や npm パッケージとして管理されています。 note.com Figma で構築されたデザインの反映には Figma MCP や Chrome Devtools MCP 等を活用し、デザイントークンの取得から動作確認まで AI に任せています。 また、kintone Design System チームでは、コンポーネントの情報や仕様を取得できる MCP サーバーも開発しています。これにより、AI がデザインシステムの仕様を直接参照しながらコードを生成できるようになっています。 これからの課題 AI 活用が進む一方で、まだ解決できていない課題もあります。開発工程での AI 活用が進んでも、全体のリードタイムを短縮するには、デザインや品質保証のプロセスも一緒に変えていく必要があります。現状は、各チームが試行錯誤しながら、うまくいった取り組みを横展開していくという形になっています。この動きを加速させるために、組織横断での AI 活用推進の取り組みもやっています。こちらについては、また 1 〜 2 ヶ月後に誰かが書く記事を参考にしてください。 おわりに kintone 開発における AI 活用は、個人の生産性向上から始まり、開発チーム横断でのナレッジの共有、そして他職能を跨いだ活用推進へと広がりつつあります。開発速度以外も AI を使って加速させていきたいですね！
- 生成AI
- フロントエンド
- デザインシステム