--- title: 考え抜いた最強の設計が、1年後果たしてどうなったのか答え合わせする tags: #kintone ダッシュボード author: [Masanori Tani](https://image.docswell.com/user/uta8a) site: [Docswell](https://www.docswell.com/) thumbnail: https://bcdn.docswell.com/page/GEWG9QZMJ2.jpg?width=480 description: 42,000社に選ばれるkintone、ダッシュボード開発の“ベストな設計”は1年後どう変わったか の登壇資料です https://cybozu.connpass.com/event/394341/ published: June 29, 26 canonical: https://image.docswell.com/s/uta8a/K7NN6J-2026-06-29-114048 --- # Page. 1 ![Page Image](https://bcdn.docswell.com/page/GEWG9QZMJ2.jpg) 考え抜いた最強の設計が、 1年後果たしてどうなった のか答え合わせする Cybozu Tech Meetup #27 2026/06/22 谷 昌典 1 # Page. 2 ![Page Image](https://bcdn.docswell.com/page/47ZL9W1MJ3.jpg) 自己紹介 自己紹介 谷 昌典 GitHub, X, mixi2など @uta8a でやってます！ 2023/04 サイボウズ新卒入社 2025/03 kintoneの性能ダッシュボード開発にジョイン(兼任) 2026/04 ダッシュボードチームに異動 趣味はカメラ、音楽 インフラ寄りの話題が好きです 2 # Page. 3 ![Page Image](https://bcdn.docswell.com/page/YJ6WKGL5JV.jpg) 目次 今日の流れ 1. 設計したサービスの背景 → kintoneのダッシュボードについて 2. 技術的意思決定をADR風に振り返る → 選択形式で振り返り 3. うまく行ったもの、うまく行かなかったものを整理 → ADR風の振り返りから、抽象的な学びを得る 3 # Page. 4 ![Page Image](https://bcdn.docswell.com/page/GJ5MPV1GJ4.jpg) 1. 設計したサービスの背景 ©️ Cybozu, Inc. 4 # Page. 5 ![Page Image](https://bcdn.docswell.com/page/LE3W3D1PE5.jpg) 設計したサービスの背景 kintoneのダッシュボード機能の背景 性能ダッシュボード・利用状況ダッシュボード • kintoneとは？ kintoneで実現した業務システムの例(従業員名簿) • 業務改善プラットフォーム • 様々な業務システムを実現できる • →使われ方が多様 • 大規模な利用に対し、お客様の持つ不安を解消したい • この規模で社員が増えていくと大丈夫か • →時系列で性能情報が見れると現状把握に役立つ • もっと活用を推進していくために、現状が知りたい • →時系列で利用状況が分かると推進のヒントになる →kintoneのダッシュボード機能を顧客に提供 https://jp.kintone.help/k/ja/app/app_tutorial 5 # Page. 6 ![Page Image](https://bcdn.docswell.com/page/8EDK4PX37G.jpg) 設計したサービスの背景 kintoneのダッシュボード 3種類のダッシュボードを開発している(1つは社内向け) 6 # Page. 7 ![Page Image](https://bcdn.docswell.com/page/V7PKMNPPJ8.jpg) 設計したサービスの背景 アーキテクチャ(ざっくり) Neco: サイボウズのプライベートクラウド ※各コンポーネントは簡略化しています 7 # Page. 8 ![Page Image](https://bcdn.docswell.com/page/2JVV9K2VJQ.jpg) 設計したサービスの背景 アーキテクチャ(ざっくり) 8 # Page. 9 ![Page Image](https://bcdn.docswell.com/page/5EGLZQR1JL.jpg) 設計したサービスの背景 アーキテクチャ(ざっくり) 9 # Page. 10 ![Page Image](https://bcdn.docswell.com/page/4JQYLKVN7P.jpg) 2. 技術的意思決定をADR風に振り返る ©️ Cybozu, Inc. 10 # Page. 11 ![Page Image](https://bcdn.docswell.com/page/K74WDPM3E1.jpg) 技術的意思決定をADR風に振り返る 概要 • 「アーキテクチャに関わる技術的意思決定」→「1年後どうなったか？」という形式で紹介します！ • 注意点として、だいぶ簡略化しているので実際はもっと複雑な状況になっています 11 # Page. 12 ![Page Image](https://bcdn.docswell.com/page/LJ1YZ98ZEG.jpg) ADR#1: BFFを採用する？しない？ ©️ Cybozu, Inc. 12 # Page. 13 ![Page Image](https://bcdn.docswell.com/page/GJWG9QZ672.jpg) ADR#1 BFFを採用するかどうか なぜ採用したいか - 複数のIdP, サービスと連携したいため メリット・デメリット - BFFを選ぶと、 - フロントエンドとバックエンドの分業がしやすい - BFFは認証とデータの整形に集中、BackendはDBへのクエリに集中 - デメリットは当時あまり見えてなかった。 まとめ 複数の他チームが持つIdP・サービスと連携できる チーム内のバックエンド・フロントエンドエンジニアで協業しやすい形のアーキテクチャ →BFFを採用 13 # Page. 14 ![Page Image](https://bcdn.docswell.com/page/4EZL9W1R73.jpg) ADR#1 BFFを採用するかどうか – 1年後 想定通りだったこと - BFFはフロントエンド、バックエンド実装が分担しやすい - デメリットは見当たらない 想定通りじゃなかったこと - BFF 1つに対して、backend 1つ、kintone本体が接続している - データソース複数を1つのbackendで処理している - 思ったより接続するサービスが少ない 分担の様子 14 # Page. 15 ![Page Image](https://bcdn.docswell.com/page/Y76WKGL17V.jpg) ADR#2: DBはどれにする？ ©️ Cybozu, Inc. 15 # Page. 16 ![Page Image](https://bcdn.docswell.com/page/G75MPV1L74.jpg) ADR#2 DB選定の話 候補 選定基準 - Amazon Timestream - クエリの同時実行に耐えられる安定性 - Prometheus - クエリでスキャンするサイズはあまり重要視しな - Aurora MySQL - Amazon Athena - Redshift い - Glueによる事前集約を想定していたため - 金額コスト - データスキーマが柔軟に変更可能 - OpenSearch →初期の決定: TimestreamとOpenSearchの併用 直近のデータをTimestreamで持ち、古いデータを集約してOpenSearchで持つ 16 # Page. 17 ![Page Image](https://bcdn.docswell.com/page/9J296313ER.jpg) ADR#2 DB選定の話 – 1年後 想定外だったこと Timestream for LiveAnalyticsが新規顧客向けサービス提供を停止 →雰囲気サービス終了に向かっている...(2025/05) →Timestream for InfluxDBはカーディナリティで難しく、リアルタ イム性をその時点である程度諦めてOpenSearch集約に振る (まだリリース前の変更だったので助かった) 想定内だったこと データスキーマが頻繁に変更される 17 # Page. 18 ![Page Image](https://bcdn.docswell.com/page/DEY491Z8JM.jpg) ADR#3: データ収集パイプラインの設計 ©️ Cybozu, Inc. 18 # Page. 19 ![Page Image](https://bcdn.docswell.com/page/VJNYL23978.jpg) ADR#3 データ収集パイプライン部分の設計 データ収集パイプラインの設計時に必要な観点 - rawデータをどういうパイプラインで変換してDBに入れるか？ ↑ ?に入るブロックとしては、入力時のバッファリング(Kinesis)/短い時間単位での集約(Firehose)/raw データ置き場(中間層1)/集約層(Glue)/集約結果のデータ置き場(中間層2)を想定していた 19 # Page. 20 ![Page Image](https://bcdn.docswell.com/page/YE9P4193J3.jpg) ADR#3 データ収集パイプライン部分の設計 設計時の観点 - リアルタイム性は重要視しない - リアルタイム性が必要なら、ストリーム処理が可能なApache Flinkを用いる - データ数/分間がそれなりの規模、業務時間に合わせたピーク→スケールアウト/インに対応できる安定性 - Managedサービスをなるべく選択、バッファリング層としてFirehoseを設ける - 当時は性能データだけを考えていたので、Glueの集約は時間方向の集約のみ(1分単位) 20 # Page. 21 ![Page Image](https://bcdn.docswell.com/page/GE8DQ49LED.jpg) ADR#3 データ収集パイプライン部分の設計 – 1年後 想定通りだったこと - データ量の多さ・ピークに耐えられた 想定外だったこと - 他チームからのデータを受け取ることになった→Firehoseがvalidation層に - 時間単位集約だけでなく、unique user count処理も要件に入った→Glueで処理できた - Glueが思ったより複雑に... 複数の集約ルートに応じてパイプラインが増え続ける構造 21 # Page. 22 ![Page Image](https://bcdn.docswell.com/page/LELMX6WQ7R.jpg) ADR#4: CDKのStack、どこで切る？ ©️ Cybozu, Inc. 22 # Page. 23 ![Page Image](https://bcdn.docswell.com/page/4JMYL5YKJW.jpg) ADR#4 CDKのStackをどこで切るか CDKのStack: デプロイ単位。全部まとめて一つのStackにすると、開発時にmockをデプロイしたい時に不 要なコンポーネントもデプロイしてしまう。 以下のコンポーネントたちのどこでStackを切ると良いだろうか？ 当時の考慮ポイント: 将来的にDBは複数個できるかも？ / DBはデプロイ時間が長い / Stack間になるべく依存関係を発生させた くない / PRのプレビュー環境のように、mockをデプロイするときに不要なものはデプロイしたくない 23 # Page. 24 ![Page Image](https://bcdn.docswell.com/page/PJR9K39679.jpg) ADR#4 Stack間になるべく依存関係を発生させたくない の難しさ 例えば、mockはBackend+DBを置き換えてBFFから見て透過にしたい そうすると、S3(中間層2)とOpenSearch Serverlessの間で切りたくなる 24 # Page. 25 ![Page Image](https://bcdn.docswell.com/page/PEXQL4QDJX.jpg) ADR#4 Stack間になるべく依存関係を発生させたくない の難しさ しかし、いくつか問題が出てくる - Amazon SNSを作成したとき、S3からs3:TestEventが飛ぶ - これにより、先にSNSを作成するという依存関係が発生する(この間で切りづらい) 他にも実体がない状態で権限指定したいが...など →微妙な感じで解決(緑の側にSNS、赤の側にS3からのQueueとOpenSearch Ingestionを入れる) 25 # Page. 26 ![Page Image](https://bcdn.docswell.com/page/3EK9LZ9DED.jpg) ADR#4 CDKのStackをどこで切るか – 1年後 チームで混乱する場面が何度かあった 当時は最強の切り方だと思ってたのに...！ →実際はAWSの都合に左右された苦肉の策なので、もうちょっといい方法がないか検討できたかも →特に今はDBが1つだけなので、その前提だと切り方を変えられた可能性 26 # Page. 27 ![Page Image](https://bcdn.docswell.com/page/L73W3DWP75.jpg) 3.うまく行ったもの、うまく行かなかった ものを整理 ©️ Cybozu, Inc. 27 # Page. 28 ![Page Image](https://bcdn.docswell.com/page/87DK4PK3JG.jpg) うまく行ったもの、うまく行かなかったものを整理 最強だと思っていた設計の答え合わせ • 当時やった〜これが最強！と思ったものは、達成感でそう思っていないか？に注意する • うまく行ったもの ADR#1 BFF や、ADR#3 パイプライン設計 はどれもシンプルでよく採用されている手法 • うまく行かなかったもの ADR#4 CDKのStack は捻り出した解決策 • とはいえ、CDKのStackの切り方はまだまだ世の中に知見がない気もする • 外部要因によって最強だと思っていたものが変わることはある • ADR#2 DB選定 は、AWSのサービス終了の気配によって変わる必要があった • その時の†最強†よりも、要件含めて変わることのできる範囲の把握を継続することが大切 28 # Page. 29 ![Page Image](https://bcdn.docswell.com/page/VJPKMNKPE8.jpg) まとめ ©️ Cybozu, Inc. 29 # Page. 30 ![Page Image](https://bcdn.docswell.com/page/2EVV9KVVEQ.jpg) まとめ その時最強と感じた設計より、シンプルさや変化を大切にした方が良さそう • kintoneのダッシュボード開発で積んだ設計経験を軸に、いくつかピックアップして最強だと思った設計 がどうなったのか振り返った • 得られた教訓 • 考え抜いた複雑な方法よりもシンプルな方法の方が後々良かったりする • 想定通りには行かないので、変化できる範囲を把握することが大事(要件含めて) この次の発表もお楽しみに！ 30