この記事は、CYBOZU SUMMER BLOG FES '26の記事です。はじめに25新卒入社でkintoneのAndroidアプリ開発チーム所属の市村です。本記事では2年目になった私が、どんな1年目だったかを振り返ります。1年目のロールモデルの一例として参考にしてもらえたり、kintone Androidがどういうチームか知ってもらえたら幸いです。私は2025年7月に、kintone Androidチームに配属されました。サイボウズの社員歴はすでに1年半に迫りつつありますが、配属を基準に考えるとちょうど1年ほど経っているので、2025年の7月から現在までの振り返りの内容が中心になっています。配属から現在までに関わった機能開発以下が配属からこれまでに取り組んだ機能開発です。 時期 着手内容 2025/07 PDFプレビューで文字検索を追加 2025/08 ログイン画面のUI改善 2025/09〜10 Androidアプリ版の検索AI（kintone AI）を実装 2025/11〜12 Android開発基盤整備 2026/01〜02 未処理一覧ウィジェットの実装 2026/02〜04 書類スキャン機能を追加 2026/05〜06 Androidアプリ版のレコード一覧分析AIの実装 2026/06〜08 Androidアプリ版のスレッド要約AIを実装 入社当初は業務コードに触れた経験がなく、最初はモブプロでほとんど指示通りに動くだけのラジコン状態でした。検索AIの開発に着手したあたりで慣れてきて、一人でタスクを進めることが増えました。 印象に残った仕事：書類スキャン機能の追加一気に開発業務の解像度が上がったのは書類スキャン機能の実装です。着手は2026年2月頃、一人でタスクを回し始めた時期でした。このタスクで初めて自動テストとちゃんと向き合いました。今はAIでテストを簡単に生成できますが、そのカバレッジや保証の仕方が適切かを見極めるのが非常に難しいです。自動テストがないと自信を持って機能追加や変更ができない一方、多すぎればCIのたびに時間がかかり、不安定なテストの割合も増えます。何を保証すべきかは、壊れた時のリスクと、テストの実装・保守コストのバランスで判断します。リスクはユーザーの利用頻度とビジネス的な影響度を加味しての判断が必要で、この観点からどの機能がどの程度

この記事は、CYBOZU SUMMER BLOG FES '26の記事です。こんにちは！サイボウズのトニオ（@tonionagauzzi）です。普段はkintone開発チームにてAndroidアプリを主に開発しています。2026年7月23日（木）に、ディップ株式会社、株式会社ヤプリ、株式会社Voicy、サイボウズ株式会社の4社合同モバイル勉強会、Mobile Tech Flex #2 〜4社合同！私たちが「越境」した話〜をサイボウズ東京オフィスで開催しました。本記事ではその当日の様子をレポートします！mobiletechflex.connpass.comイベントの概要Mobile Tech Flexは、モバイルアプリ開発に携わる人々が集まり、各自の取り組みをLT形式で発表する合同勉強会です。モバイルの勉強会で敷居が一番低いコミュニティを目指し、発表を後押しする場でありたいと思っています。モバイルに関わる方なら職能を問わず誰でも発表できるのが特徴です。詳しくは以下の紹介記事にまとめていますので、ぜひあわせてご覧ください。blog.cybozu.io第2回の開催となる今回のテーマは、越境でした。職能や技術領域の垣根を越えて挑戦した経験談を、エンジニア、QA、PdMの方々から共有していただきました！当日の様子かわいい動物たちがお出迎え！登壇ステージはこんな感じです！乾杯からスタート！猛暑の中お越しいただいた参加者の皆さんと最初に乾杯して、和やかな雰囲気でLTセッションが始まりました。オープニングのビールスポンサーセッション今回は転職ドラフトさんからビールスポンサーとして、オリジナルデザインのビールをご提供いただきました！エンジニアのキャリアをコミュニティと共に支えたいというコンセプトに、主催としてとても共感しています。転職ドラフトさんのオリジナルビール「ひと粒の種、万葉の選択肢。」「雨宿りの、サードプレイス」ビールはユニークで美味しいと評判でした。転職ドラフトさん、この度はありがとうございました！LT (1): チームの仕組みで作る心理的ハードルを下げる越境トップバッターはディップの吉本さん（@tokotoko_kt）。新卒2年目のAndroidエンジニアとして、バイトルアプリのリニューアルプロジェクトに携わっておられます。越境をためらう背景には、前提知識の壁、設計思想の

この記事は、CYBOZU SUMMER BLOG FES '26の記事です。こんにちは、フロントエンドエンジニアのおぐえもん（@oguemon_com）です。今年の9月に、「フロントエンドカンファレンス福岡」（FECF 2026）が7年振りに開催されます。サイボウズはFECF 2026に「Gold Sponsors」として支援している他、当社エンジニア（コサキン）の登壇予定もございます。さて、サイボウズでは、そんなFECF 2026の開催前日にあたる9月11日（金）の夜に、当社福岡オフィスでWebフロントエンドの勉強会を開催します！その名も、「替え玉.web」です。替え玉.webのイメージ画像替え玉.webとは？「替え玉」とは、ラーメンの麺をおかわりする追加注文のことで、福岡が発祥と言われています。「替え玉.web」は、そんな替え玉のように、美味しかった過去の発表をおかわりする勉強会、つまり、「過去の発表の再演が原則」のWebフロントエンド勉強会です。一般的に、IT勉強会の発表は完全新作が求められる傾向があります。しかし、過去の発表を再演することにも数多くのメリットがあると考えています。発表者にとっての主なメリット初回発表時の反省点を活かした、より洗練された発表ができるかつての発表を新たな人たちに届けられる準備の負担が比較的少ない聞き手にとっての主なメリット面白かった題材が集まりやすい、題材に磨きが掛かりやすいので面白い可能性が高まる当時見られなかった発表を見るチャンスが得られる一度見たものも再び見ることで記憶に定着するウケが良かった発表を「替え玉.web」に持ち寄り、参加者の皆さんで改めてその面白さを噛み締めようというのが今回の勉強会の趣旨です。発表者&参加者を募集中！ただいま「替え玉.web」の登壇者と参加者をともに募集しています！いずれも、Webフロントエンドに興味のある方でしたら、学生、社会人、FECF 2026参加予定か否かなど不問で誰でもWelcomeです。詳細や申込についてはConnpassをご覧ください。発表について10分間（質疑応答込）の持ち時間で発表いただける方を募集しています。テーマは「Webフロントエンドに関するもの」ならば何でも歓迎です！また、コンセプトの通り、「過去の発表の再演が原則」です。かつてウケた発表、上手く伝わらなくて悔しい思いを

この記事は、CYBOZU SUMMER BLOG FES '26の記事です。こんにちは。kintoneの開発組織でEMをしている上岡（@ueokande）です。サイボウズでは2025年から本格的にkintoneのEM採用を進めてきました。EM採用を進める中で、採用活動だけでは見えなかった課題や発見がありました。当初は「採用できれば成功」と考えていましたが、実際は採用後のほうが重要で意思決定が難しいことが分かりました。この記事ではこの1年間のEM採用を振り返りながら、採用・配属・オンボーディングを通じて得られた学びと、これからのチャレンジについて紹介します。背景：なぜkintoneのEM採用を始めたのかEM採用を始めたきっかけには、組織設計のいくつかの転換点がありました。2024年より開発組織のインパクト向上のため、EMを軸とした組織設計を進めてきました。マネージャーの役割も変わり、人材マネジメント中心だったマネジメント業務が、プロジェクトの推進、チームの意思決定、機能設計など、製品開発を前進させる役割も担うようになりました。一方で組織拡大によりEM不足が顕在化し、多くのEMが複数組織やプロジェクトを兼務する状態となりました。こうした背景からEMの社内育成だけでなく、外部からも経験のあるEMを採用することになりました。エンジニアリング組織の様々なレイヤーにEMを配置、マネジメント範囲の成果最大化に責任を持つエンジニアリング組織の様々なレイヤーにEMを配置、マネジメント範囲の成果最大化に責任を持つサイボウズの組織設計の移り変わり、および現在のEMの業務は以下の資料も合わせてご覧ください。エンジニアが主導できる組織づくり ー 製品と事業を進化させる体制へのシフト - Speaker Deckkintoneエンジニアリングマネージャー業務紹介 | ドクセル「採用すること」よりも「どこで活躍してもらうか」採用を始めた当初は、EMが不足しているチームに配置すればよいと思っていました。しかし実際には、それほど単純ではなく、選考を重ねるうえでも考え方が徐々に変わりました。EMの中にも、組織づくりが得意な人、技術的な意思決定が得意な人、プロジェクト推進が得意な人など、様々な強みがあります。またkintoneでも、各チームの状況や成果物によって、求める役割は異なります。そのため選考プロ

kube-state-metrics で Deployment Sharding を採用した話この記事は、CYBOZU SUMMER BLOG FES '26の記事です。こんにちは、クラウド基盤本部の藤井です！この記事では、Neco で kube-state-metrics をシャーディング構成へ移行するにあたり、検討した方式と Deployment Sharding を採用した理由を、kube-state-metrics v2.19.1 の実装をもとに紹介します。Neco については紹介ブログもあるのでこちらを参照してください！blog.cybozu.ioなお、本記事の AI Influence Level（AIL）は Level 1です🤖danielmiessler.comkube-state-metricsとはシャーディングを検討した背景シャーディングの方法方法１： Kubernetes API サーバーから取得するリソースを絞り込む方法２： 取得したリソースのうち、メトリクスに変換する対象を絞り込むHorizontal Sharding の仕組みDeployment ShardingAutomated Sharding結局どうしたのかまとめkube-state-metricsとはkube-state-metrics（以後、KSM ）は、Kubernetes の API サーバーから Pod などのリソースを取得し、その情報をメトリクスへ変換するコンポーネントです。メトリクスは KSM Pod の/metrics にアクセスすることで、取得できます。KSMの/metricsにアクセスするとメトリクスを取得できる例えば、次のようなメトリクスが生成されます。kube_pod_status_phase{namespace="argocd",pod="argocd-server-5f898b9cbc-4pbbx",...,phase="Running"} 1kube_pod_info{namespace="argocd",pod="argocd-server-5f898b9cbc-4pbbx",...,pod_ip="10.244.1.7",node="kind-cluster-worker2",...} 1kube_deployment_status_replic...

この記事は、CYBOZU SUMMER BLOG FES '26の記事です。kintone dashboard Teamの開発をしている まつもと です。これまで、kintoneの開発や、海外向けの kintone (kintone.com) の Amazon Web Services (AWS) への移行や、その運用などをしてきました。kintoneとは別基盤で動くダッシュボードに、テナントごとに違うOIDCエンドポイントをどう繋ぐかサイボウズでは、kintoneの性能や利用状況を可視化する「ダッシュボード」を提供しています。kintone本体がサイボウズのクラウド基盤で動いているのに対し、このダッシュボードはAWS上に構築されていて、kintoneとは別のシステムになっています。kintoneにログインしているユーザーがダッシュボードを表示した際にユーザー情報をどうやって連携するかという課題がありました。今回はその認証まわり、特に「テナントごとにOpenID Connect (OIDC) のエンドポイントが異なる」という、kintoneならではの制約にどう向き合ったかを紹介します。kintone特有の制約kintoneはOIDCのエンドポイントが実装されていて、社内で利用できる状態だったので、OIDCを利用して認証し、ユーザー情報を取得する構成は自然な選択でした。一般的なOIDC連携では、IdP (Identity Provider)のエンドポイント、つまりAuthorization EndpointやToken Endpoint、JWKs EndpointなどのURLはサービスごとに1つに決まっていることがほとんどです。多くのOIDCライブラリは「issuerは起動時に1つ設定する」といったことが前提に作られているように思います。kintoneは、example.cybozu.com のように契約(テナント)ごとにサブドメインが割り当てられるマルチテナント型のSaaSで、OIDCのエンドポイントもテナントごとに独立しています。ダッシュボードは全テナント共通の1つのアプリケーションとして提供しているため、アクセス元のテナントに応じて、その場でOIDCエンドポイントを切り替える必要がありました。どのように解決したかテナントの数が限られる場合は個別のOIDC設定を持

この記事は、CYBOZU SUMMER BLOG FES '26の記事です。Cloud Platform部のpddgです。サプライチェーン攻撃やAIによる脆弱性の検出が盛んになった昨今、迅速な影響の把握と更新の適用が求められ、ソフトウェアが抱える依存関係の脆弱性の検出はその重要性が増してきています。一方で、ナイーブに脆弱性を検出するだけでは誤検知（偽陽性）が多くなり、開発者の負担が増えることになります。Goのプロジェクトでは、govulncheckを用いることでモジュールレベルではなく関数のシンボルレベルで影響の有無を検出でき、偽陽性を削減できます。一般的なOSSスキャナーのスキャンとgovulncheckのスキャン結果を組み合わせることで、より正確な脆弱性検出が可能になります。背景ソフトウェアを構成する依存関係に存在する脆弱性を早く検知し、攻撃に繋がる前に早く対応することは現代の開発において重要性が増しています。TrivyやGrype、OSV-ScannerなどのOSSの脆弱性スキャナーを通して、依存関係に含まれる脆弱なライブラリ・モジュールを検知し、開発者に通知することは有効な手段です。これらのスキャナーはモジュールレベルでの検知を行うことが多く、実際に影響を及ぼすかどうかに関わらず脆弱性ありとして報告されることがあります。実際にはあるライブラリの脆弱性が検知されたとき、そのライブラリのうちどのような機能を利用しているかによって影響を受ける箇所は変わってきます。静的解析により当該機能を利用しているかどうかを知ることができれば、より精度の高い脆弱性検知が可能なはずです。govulncheckGoは脆弱性管理のためのデータベースを持っています。このデータベースを用いて、現在のGoのプロジェクト内・もしくはバイナリにおいて依存関係に既知の脆弱性を含むかどうかを調べるのが govulncheck コマンドです。Goのコードもしくはビルドしたバイナリを対象に解析を行い、ソースコードの場合は脆弱性の見つかった機能への到達可能性まで見て影響を受けるかどうかを判定します。そのため、単に依存関係に脆弱性の見つかったライブラリが依存関係として存在するかどうかだけで判断するよりも偽陽性を抑えられます。脆弱性スキャナーとgovulncheckの現在ほとんどの脆弱性スキャナーは現状では依

サイボウズでデザインテクノロジストをしている @saku です。今回は、サイボウズと同時期に W3C に加入した Studio さんと、各社がどうして W3C に加入したのかを、お互いにインタビューするコラボブログ企画を実施します。今回は、 Studio の CTO 諸田さんをサイボウズにお迎えし、 Studio が W3C に加入した経緯やビジョンについてお伺いしました。諸田さんとsakuの対談風景Studio 社の紹介Saku: まず Studio は、何をされている会社か教えてください。諸田: Studio は、Web の制作から公開・運用までを支える、Web サイトビルダーをホスティング込みで提供するサービスをしています。studio.incただツールを提供しているというよりは、社会の皆さんが諦めてしまっている部分を「本当にそこって諦める必要あるんだっけ」と、うちのプラットフォームで解決して、本当にやりたいこと・やるべきことに集中できるようにする、"Unleash Creativity" というビジョンを掲げている会社です。Saku: 構造上サイトを作るのが難しいところなどを一挙に Studio さんが担って、もっとクリエイティブなとこにリソースを割けるようにするというビジョンですね。組織の中に入っていく改善とかも、含まれるんですか?諸田: 長期的には含まれます。今のスコープではサイトから入っていますが、Web サイトビルダーは、そのきっかけとしてやり始めたという感じです。Studioが「これができますよ」ってポンとツールを提供するだけでは、ユーザーも僕らもまだまだ先に繋がらない。ユーザーのやりたいことを本気で支えたいんです。どちらかというと、「自分から発信しよう」とか「社会にこれを表現していこう」で「アクションを起こしていこう」というユーザーの動きが大事で、それを支えたいなという感覚です。それこそモリサワさんなど、分野の違うサービスとも一緒に手を組んでもっと価値のあるサービスにしていきたいですし、今日の話である W3C に入っているということも、そのために必要なことだと思っています。Saku: 社会のクリエイティビティをエンパワーメントするという最終的な目標に向かっていく手段は何でも取れるといい、みたいな感じですかね。諸田: そうですね。「社会」ってニュア

この記事は、CYBOZU SUMMER BLOG FES '26の記事です。こんにちは！サイボウズでフロントエンドエンジニアをしている たくぼう です！kintoneでは、現在フロントエンドの刷新を進めています。刷新では、単に技術スタックを改めるだけでなく、アクセシビリティの対応も併せて実施しています。私が所属するチームが刷新を手がけている「レコード一覧画面」には、「レコード一覧分析AI」というAI分析・要約機能があります。刷新中の画面にこの機能を盛り込むにあたり、「レコード一覧画面」と「レコード一覧分析AI」のチャットダイアログの間でフォーカスをどう受け渡すかを検討しました。あわせて、閉じたときの戻し先についても触れます。レコード一覧分析AIとは？kintoneのレコード一覧の内容をAIが分析・要約する機能です。操作は一般的なAIチャットと同じで、聞きたいことを入力欄に打ち込めるようになっています。よく使う指示は「クイックアクションボタン」としてまとめられていて、入力の手間なく1クリックで送れます。今回紹介するのは、この機能を刷新基盤へ移す際に、実際にissueとして上がった内容です。レコード一覧画面にある「レコードを分析」のボタンを押すと、画面の横にAIチャットのダイアログが開きます。刷新後のアプリ画面では、このダイアログにフォーカス制御が実装されていませんでした。レコード一覧 AI分析・要約機能 刷新後の画面kintone.cybozu.co.jpそもそもフォーカス制御はなぜ大事なのかフォーカスとは、ざっくり言うと「いまキーボード操作の対象になっている場所」のことです。マウスで操作していると普段あまり意識しませんが、キーボードだけで操作する人やスクリーンリーダーを使う人にとっては、フォーカスがそのまま「自分の現在地」になります。たとえばボタンを押してチャットが開いたのに、フォーカスが背後の元画面に残ったままだとどうなるでしょう。キーボードユーザーは、チャットの入力欄までわざわざ Tab を何回も押してたどり着かないといけないスクリーンリーダーは「チャットが開いた」ことに気づかず、何も読み上げてくれないことがある逆に、チャットを閉じたときにフォーカスの戻り先を決めていないと、フォーカスがページのどこかに落ちてしまい、「さっき自分はどこを操作していたんだっけ？」と

この記事は、CYBOZU SUMMER BLOG FES '26の記事です。kintone フロントエンド開発に "技術標準" ができていましたどうも、kintone フロントエンドイネイブリングチームの mugi です。突然ですが表題の通り、kintone でのプロダクト開発では、kintone フロントエンド技術標準 というものが存在します。kintoneフロントエンド技術標準トップページこの記事では、 "技術標準" とは一体なんなのか・何のために作られたのか、などをご紹介します。領域に閉じたフロントエンド開発と技術選定kintone のプロダクト開発では、機能や目的などに応じて責任領域を分け、多くのチームが並列で開発をしています。その中でもフロントエンドについては、チームごとにオーナーシップを持って管理しており、日々の開発はもちろん、利用する技術の選定や保守もチームに委ねられています。FYI: kintoneプロダクトエンジニア業務紹介 | ドクセルkintone 開発組織図FYI: フロントエンド刷新 4年間の軌跡 - Speaker Deck領域ごとにフロントエンドのコードベースが分割されているイメージこれにはチームに一定の責任も伴いますが、次のようなメリットがあります。影響範囲がチームに閉じるため、意思決定が速くなるチームの裁量で、新しい技術に挑戦することもできる特定技術への全体依存を避けやすいなお余談ですが、これは kintone のフロントエンドリアーキテクチャによる恩恵のひとつでもあります。刷新に伴い領域が分割されたことで、小さいチームで身軽に動けるようになりました。blog.cybozu.io自由度とのトレードオフチームで自由に技術選定できるのはメリットも多くありますが、残念ながらそれだけではありません。 実際に開発を進めていく中で、じわじわと次のような課題が見えてきました。すべてをゼロから選定しなければいけないkintone 開発では不定期に新チームが発足し、そのたびに技術選定が発生します。その際、前述の通りチームに裁量があるため、チームが達成したい目的に応じて最適な技術を選ぶことができます。しかし、実際のところ社内の事情を鑑みると「これって毎回選定する必要ある？」「ここから考える必要ある？」という気持ちになるものが多くあります。たとえば

はじめにこの記事は, CYBOZU SUMMER BLOG FES '26の記事です.こんにちは, Garoon開発チームの森脇です.Garoonという中堅・大規模組織向けグループウェア（Webアプリケーション）の運用・保守を行っています.クラウド版Garoonの運用を行っていると, 一見しただけでは発生した事象や影響範囲を推測できないログに遭遇することがあります.nginx | 2026/07/02 06:46:50 [error] 37#37: *1 FastCGI sent in stderr: "the log buffer is full (1024). The access log request has been truncated" while reading upstream, client: 192.168.117.1, server: localhost, request: "GET / HTTP/1.1", upstream: "fastcgi://192.168.117.2:9000", host: "localhost:8080"the log buffer is full (1024). The access log request has been truncated という文字列からは, 何かのバッファがいっぱいになり, アクセスログがトランケート（切り捨て）されていることが読み取れます.FastCGI sent in stderr という文字列からはPHP-FPMがこのログを送信しているように見えます.図1. このログがnginxのerror_logにのみ出力される様子のイメージ図.私がこのログに初めて遭遇したとき, 次の2つの疑問が浮かびました.どのコンポーネントのログが切り捨てられたのか？なぜnginxのerror_logにだけ現れて, PHP-FPM側のログにはこのメッセージが残らないのか？この記事では, この2つの疑問を順に解き明かし, その上でGaroonで取った対応方法と, その対応を振り返っての所感を紹介します.想定読者PHP-FPMとnginxを使った構成でWebアプリケーションを構築・運用・保守している方PHP-FPMとnginxのログの仕組みに興味がある方この記事で得られることこのエラーログの意味と, 自分の環

こんにちは。今回hokatomo（@tomoko_and）さんから実行委員長を引き継いだ、3代目実行委員長のpddgです。普段はSREとして、インフラやバックエンド関連の仕事をしています。サイボウズでは年に2回、社内テックカンファレンスとして「開運まつり」を開催しています。職能も拠点も異なるエンジニアやその周辺メンバーを集め、2日間の交流イベントを通してチームワークを高め、次への行動を繋げることを目的としています。今回は2026年2回目のイベントとなる「開運まつり2026夏」の実行委員長として、イベントの企画・運営を担当しました。この記事では、開催概要の紹介とともに、社内イベントの企画・運営における工夫や学びを共有します。「開運まつり」とは -これまでの開催内容と変わらないコンセプト-開催概要より仕事に活かせるイベントにしたいオーナーごとの工夫の紹介新規参加者・リピーターの双方に楽しんでもらいたいセッション・LTはテンポや形式に差異をつけて飽きさせない思い切った OST の廃止参加者の声社内イベントだからこそ、マンネリ対策が必要おわりに「開運まつり」とは -これまでの開催内容と変わらないコンセプト-サービスの開発・運用に関わる様々な職能のメンバーを集め、2日間の交流イベントを通してチームワークを高め、仕事に活かすためのオフラインのお祭りです。これまでは様々なチームから発表してもらいそのセッションを聴講したり、パネルディスカッション、懇親会、ランダムなメンバーを組みあわせたランチ会、Open Space Technology（以下OST）などを行ってきました。2024年から始まり、これまで年2回夏と冬に開催し、これで6回目の開催となります（前回冬開催時の記事）。サイボウズは日本全国に拠点を持ち、各拠点には様々な職能を持ったメンバーが在籍しています。更にリモートワークも普及しているため、日常的に顔を合わせる機会が少ないメンバー同士の交流が不足しがちです。これを解決する企画の一つとして、オフラインでチームや職能を超えて交流するためのイベントが「開運まつり」です。新たな交流のきっかけとなったり、普段オンライン上のみでやりとりするメンバー同士の交流を深め、新たな視点や気づきを得ることを目的としています。今回の「開運まつり2026夏」では、これまでのコンセプトを維持しつつ、新鮮

この記事は、CYBOZU SUMMER BLOG FES '26の記事です。はじめにこんにちは！サイボウズで kintone のプロダクトエンジニアをしている kura です。本記事では、私の所属するシステム管理/外部連携チームで行なったユーザー理解への取り組みについてご紹介します。なお、本記事はシステム管理/外部連携チームのチームビルディングの内容を一部ブログ化したものです。同チムビル内の他の取り組みについては下記をご覧ください。note.comこれまでの課題感冒頭にも述べたように、現在我々は「システム管理/外部連携チーム」として活動しています。（本記事では主に「システム管理」についてお話しします）プロダクトエンジニアの役割は、ユーザーに届けられる価値を作ることです。開発者の立場として、機能そのものを知ることは前提に、システム管理者の業務そのものについても理解しなければ、価値を作ることはできません。しかし、我々が普段主務としているのはシステム管理業務ではなく、製品機能の検討と開発です。日々の自分たちの業務をもとにシステム管理者の求めるところを解像度高く感じよう、というのも難しく、またアンケート等のフィードバックに頼るというのも限界があります。というのも、システム管理系機能は kintone ユーザーの中でも一部のお客様しか触ることのない領域で、フィードバックも他領域に比べると少なめになってしまうからです。この課題に対して、システム管理/外部連携チームでは担当領域の専門性向上、価値創造という観点での深化を目指し、「システム管理者の徹底的解像度上げワークショップ」と題した取り組みを行いました。ワークショップの内容このワークショップは、次に述べる事前準備+3段階の当日コンテンツで構成されていました。Part0: （事前準備）お客様向けのガイドコンテンツを通じたインプットkintone では、導入後のお客様により効果的な業務改善を行なってもらうため、 kintone SIGNPOST という体系的なコンテンツを提供しています。kintone は非常に自由度の高いクラウドサービスであり、上手な活用にはある種の「コツ」が必要です。そこで弊社では kintone SIGNPOST を通じて、 kintone における概念の理解から実際の業務アプリ構築、その後の継続運用までを実践

この記事は、CYBOZU SUMMER BLOG FES '26の記事です。こんにちは。QA外部コネクトチームのmassanです。QA外部コネクトチームは2025年8月に発足した後、前身の主なタスクだったカンファレンス協賛以外にも様々な試行錯誤をしてきました。今回はそれらをエネルギー効率の観点から振り返ってみようと思います。発信も応援もエネルギーがいる私たちはサイボウズのQAメンバーと社外との繋がりを作る活動をしていますが、その一環として外部発信の応援をしています。そして外部発信は想像に難くない通り、発信者のモチベーションに大きく依存します。つまり、「発信したくない」負荷と「発信したい」エネルギーがあり、このような構造になっています。発信する ＝ 「発信したい > 発信したくない」そんなの当然だ、という声が聞こえてきそうです。外部発信には多かれ少なかれ何らかの負荷があります。テーマ探し、準備時間の確保、内容を社外向けに整理する手間、普段と違うことをする緊張など。一度に大きな負荷を乗り越えられるほど発信したいと思っている人は特別と言っていいでしょう。だとすると、発信を応援する活動は以下のいずれかになりそうです。発信する負荷を下げる発信したいエネルギーを増やす私たちの活動は、この2つに整理できることに気づきました。これらを順番に紹介します。発信する負荷を下げるテーマ付き社内LT → 社外ブログ → スポンサーLTの階段で、発信者も応援者もうれしい昨年末、QA外部コネクトのyuuki(@yuuki_cybozuQA)さんが社内イベント開運まつりにてQAエンジニアのLTレーンを企画してくれるというできごとがありました。その後QA外部コネクト内でバトンをつなぎ、LTの内容をInside Outの記事にするリレーブログを企画しました。さらにその発信の中から特定のカンファレンスに対して推したいものがあったので、協賛先でスポンサーLTをしてもらうということがありました。この一連の流れは以下のようにメリットがたくさんでした。テーマ付き社内LT：発信者の負荷が比較的低い「テーマ付きである」「誘われる」という状況で、発信者はテーマに沿って自分の話すことを決めればよく、また、社外向けに情報をまとめたり、LTの時間以上に詳しい話をする必要はありません。発信活動にyesと言えること、オフライン

この記事は、CYBOZU SUMMER BLOG FES '26の記事です。こんにちは、kintoneライターチームの安田です。私たちkintoneライターチームでは、kintoneヘルプの記事の執筆や、製品文言の検討を担当しています。今回は、チームでAIを活用して業務改善に取り組んだ事例の第2弾として、Claude Codeの「スキル」機能を使ったヘルプ記事のセルフレビューについてご紹介します。第1弾の記事はこちらです。kintoneライターチームが実践するAI活用：Difyアプリによるヘルプアンケート分析ヘルプ記事レビューの課題kintoneライターチームでは、ヘルプ記事を公開する前に、執筆者以外のライターによるレビュー（ライターレビュー）を実施しています。品質を保つために欠かせないプロセスですが、次のような課題がありました。課題1：確認すべき観点が多岐にわたるヘルプ記事のレビューでは、次のような観点をすべて確認する必要があります。記事構成（見出し・構成テンプレート）日本語表現（文体・語尾・冗長な表現）漢字とひらがなの使い分け表記ルール（UI文言・記号・用語・Markdownの使い方）アクセシビリティ（画像の代替テキスト・色だけに頼らない表現・インクルーシブ表現）さらに、私たちのヘルプサイトは多言語対応のために翻訳サービス「WOVN.io」を利用しており、UI文言に翻訳用のタグを付ける独自ルールもあります。正直なところ、人間の目だけですべてを漏れなく確認するのには限界がありました。課題2：細かい指摘にレビュー時間が取られる単純なパターンで機械的に検出できる表記ミスは、文章校正ツール「textlint」を使ってチェックしていました。しかし、文脈によって判断が変わるルールは、こうしたツールでは検出できません。「『場合』と『とき』の使い分けが逆になっている（大前提の条件には『場合』を使う）」「同じ『元に』でも、『元に戻す』は漢字のまま、根拠を表す用法はひらがなで『もとに』と使い分ける」といった、社内のライティングルールに基づく表記レベルの指摘に時間が取られ、「この説明でお客様に伝わるか」という本質的なレビューに集中しにくい状況がありました。また、こうした指摘のやり取りで執筆者とレビュアーの往復が増え、公開までのリードタイムが長くなることもありました。課題3：ルールが複

この記事は、CYBOZU SUMMER BLOG FES '26の記事です。こんにちは。モバイルエンジニアの臼井(@usuiat)です。この記事では、2026年7月17日に開催した「モバイルまつり」と、その中で取り組んだAIハッカソンの様子をご紹介します。モバイルまつりとはモバイルまつりは、サイボウズのモバイルエンジニアがオフラインで集まって開催している社内イベントです。サイボウズのモバイルエンジニアは、それぞれが担当するプロダクトごとのチームに分かれて活動していますが、プロダクトの枠を超えた横のつながりであるコミュニティも大切にしています。モバイルコミュニティではいろいろな活動をしており、モバイルまつりもその一つです。普段はリモートワーク中心のメンバーがオフィスに集まり、アプリ開発の課題について議論したり、最近の業務内容や興味のある技術について話したりして、お互いに交流を深め、信頼関係を築く場として活用しています。モバイルコミュニティはプロダクト横断の活動今回のメインコンテンツはAIハッカソン今回も、全国から20人を超えるモバイルエンジニアが東京オフィスに集まり、濃密な1日を過ごしました。コンテンツは以下の通りです。コンテンツ内容アイスブレイク私は誰でしょう（エピソードを聞いて、誰のエピソードかを当てるクイズ）マネージャートークモバイルエンジニアの活動や今後の方針などをマネージャーが話しましたランチお弁当を食べながら歓談AIハッカソン今回のメインコンテンツリクエストLT運営が指名した数名のエンジニアに、最近の業務内容などを話してもらいました懇親会お酒を飲みながらわいわいメインコンテンツはAIハッカソンでした。3〜4人のチームに分かれて、「喫茶さいぼうずのアプリを作ってください」というお題に取り組みました。3時間ほどの制限時間の中でAIを最大限活用して実際に動くモバイルアプリを作り、成果を発表しました。AIハッカソンに取り組んだ背景モバイルまつりでAIハッカソンを実施することにした理由は、モバイル開発における一歩進んだAI活用を推進していくためです。モバイルエンジニアでAIハッカソンに取り組むのは、今回で2回目でした。前回開催した当時は、まだAIエージェントにコードを書かせることが当たり前ではありませんでした。ハッカソンで楽しみながらAIエージェントを実際に利用して

この記事は、CYBOZU SUMMER BLOG FES '26の記事です。こんにちは。kintone開発チームでスクラムマスターをしている、とうま(@toma_cy)です。私たちのチームでは、自分たちの状態を可視化する取り組みの一つとして、四半期に1回程度、チームアンケートを実施しており、これまでに4回実施しています。目的は、チームの健全性を定期的にチェックし、もし問題がありそうであれば早めに気づき、改善につなげていくことです。ただ、4回やってみて感じているのは、アンケートは「取ること」自体に価値があるわけではないということです。数字の上がり下がりを見るだけでは、チームの良し悪しは判断できません。大事なのは、アンケート結果をきっかけにして、チームで対話することです。この記事では、私たちが実施しているチームアンケートの内容や、実際にやってみて得られた学びを紹介します。なぜチームアンケートを始めたのかチームの状態は、普段の会話や日々の仕事ぶりからもある程度感じ取ることができます。たとえば、次のような感覚です。最近コミュニケーションが少し減っている気がするタスクは進んでいるけれど、少し疲れていそう以前よりも動きやすくなっている気がするこうした感覚はとても大事です。ただ、感覚だけに頼ると、どうしても主観に寄りやすくなります。メンバーによって見えている景色も違います。チームの状態を見るためには、定量的なデータもあるとより良いと思っています。リードタイム、デプロイ頻度、障害対応時間、レビューにかかる時間など、客観的に測れるデータも重要です。ですが、定量的なデータを取得するのが難しい場合もあります。また、チームの雰囲気や心理的な状態、メンバーの感じ方は、数字だけでは捉えにくい部分があります。そこで、比較的始めやすく、メンバーの主観を集められる方法として、定性的なアンケートを定期的に取ることにしました。頻度は四半期に1回程度。「四半期のふりかえり」の場で、アンケート結果を材料の一つとして活用しています。なお、現在では定量的なデータも収集しており、そのツールとして Findy Team+ を使用しています。Findyさんが詳しく記事にしてくれているので、興味がある方はご覧ください。jp.findy-team.ioアンケートで見ている観点アンケートの設計では、SPACEフレームワーク

この記事は、CYBOZU SUMMER BLOG FES '26の記事です。こんにちは、フロントエンドエンジニアのmehm8128です。kintoneには、レコードの一覧を表示するテーブルがあります。このテーブルは横にスクロール可能かつ、見出し行を固定することが可能になっています。さらに、後述するように見出しがインタラクティブにもなっています。このような機能を持ったテーブルにおいて、見出し固定対応に苦戦したのでいくつかポイントを紹介していきます。前提となるデザイン・仕様今回紹介するのはフロントエンド基盤の刷新において開発中のレコード一覧テーブルです。フロントエンド基盤の刷新については以下の記事をご覧ください。blog.cybozu.ioレコード一覧は、レコード一覧画面において画面の大部分を占めるテーブルです。アプリに設定されているフィールドのフィールド名がカラム名になっており、各フィールドに保存されている値がテーブルのセルに表示されています。テーブルとページの左右の端との間には少し余白があり、フィールド数が多いときはテーブルの中身だけ横にスクロールします。kintoneのレコード一覧（開発中の画面）当初の実装では左右の余白がなく、横スクロールは画面全体として横スクロールできるような形にしていたのですが、デザイン改善によって余白が生まれました。また、「先頭行を固定表示」というオプションを有効化することで、縦にスクロールしたときに見出し行が画面上部に固定され、スクロールしたときでもフィールド名を参照できるようになります。そして、一部の種類のフィールドを除き、見出しセルをクリックすることでその見出しの列の値をソートして表示することもできます。実際に今回の改修後レコード一覧テーブルを操作している様子です。見出し固定しているときのテーブルスクロールの挙動（開発中の画面）当初の実装ではposition: stickyを使うだけで見出しを固定できていたのですが、横スクロールが画面全体ではなくてテーブルだけを対象とするようになったことで、CSSだけでの制御が困難になってしまいました。元々は横スクロールが画面全体に対して発生していたのでposition: stickyの基準となるスクロールコンテナも画面全体でした。しかし、テーブルだけを対象として横スクロールを発生させるためにover

この記事は、CYBOZU SUMMER BLOG FES '26の記事です。こんにちは。開発本部 Tech Media Platformチームで、エンジニアの情報発信を支援しているjnkyknです。技術ブログのCybozu Inside Outと、エンジニアポータルサイトCybozu Techの運用・管理などを担当しています。日々の業務の中で、アクセシビリティの重要性を認識しつつも十分に対応できていないと感じることがあります。そんな中で、いただいたご要望をきっかけに改善できた事例をご紹介します。ある日届いた、Cybozu Inside Outへのご要望Cybozu Inside Outの運営にあたり、過去記事の訂正依頼やブログの運営に関するフィードバックを、kintoneアプリ「Cybozu Inside Out評価箱」で受け付けています。今年の2月このアプリに、フロントエンドエンジニアのmehm8128さんから、こんなご要望が届きました。Cybozu Inside Outのリンク（a要素）の文字色が全体的に薄くて、見づらい＆アクセシビリティチェックのツールでも、コントラスト比が不足していると判断されてしまいます。視認性を高めて、アクセシビリティが考慮できているイケてるサイトにしませんか？具体的な数値と根拠、参考になるリンクも添えてくださっていて、「これは対応しなくては！」と思いました。そして決定的だったのは、評価箱に添付されていた「ブラウザ拡張のアクセシビリティ診断ツールAxe DevToolsで実際にブログ記事を診断した結果のスクリーンショット」でした。フロントエンドエンジニアのmehm8128さんから提供された問題箇所のスクリーンショット指摘の中身が具体的で、すぐに行動に移したくなった記事を1本チェックしただけで203件の問題が検出され、そのうち191件がコントラスト比（文字色と背景色の明るさの差を数値化したもの）に関するものです。数字とスクリーンショットで具体的に示されると、インパクトがあります。「まず、何から直すと良いだろう？」と検討を始めました。具体的な指摘ポイントは、大きく3つでした。訪問済みリンク（:visited）のコントラスト比不足WCAG（ウェブコンテンツアクセシビリティガイドライン）のAA基準である4.5:1を大きく下回っていました。目次リン

こんにちは、ソフトウェアエンジニアの @ajfAfg です。この度、AI 活用の知見を共有し合う社内イベント「チーム横断モブプロ大会」を開催しました。その名の通り、チームの垣根を越えてモブプログラミングするイベントでした。本稿では、チーム横断モブプロ大会を開催したモチベーションとイベントの内容をまず説明します。次に特に面白かった AI 活用の知見を著者の独断と偏見で紹介し、最後に今回のイベントを開催して得られた効果を述べます。モチベーション以下の課題感の解決がモチベーションです。あくまで著者個人の課題感である点にご注意ください。AI 活用の知見が個人やチームに閉じており、チーム間で積極的に共有されていない。関連して、個人やチーム間の AI 活用の習熟度に関するばらつきが小さくない。チームが細かく分割されており、チームごとの活動はオーナーシップを持って実施できる一方で、チームを横断して活動できる人が多くはない。各チームが独立して動ける状態は素晴らしいしそのようにすべきだと考えているのですが、チーム外に関心を向けて全体最適を図る活動も同程度に大事なはず。上記の真面目なモチベーションの他に、サイボウズで過去に開催されたモブプロ合宿を再現したい気持ちもありました。もっとワイワイしていこうや！という気持ちです。実施した内容事前に募集した全四人のドライバーが開発する様をナビゲーターが見学する流れとしました1。二ターム制にしており、ドライバーはナビゲーターとしても参加可能でした。イベントの開催時間は二時間で、ドライバーは二並列で進行しました。なお、オフライン限定でした。モブプログラミングの様子細かな狙い先述した内容には以下の狙いがあります:業務の合間に参加しやすくするため、イベントの開催時間を二時間と短くする。時間が短いため、アウトプットよりインプットを重視する。参加ハードルを下げるため参加者全員にドライバーを求めない。独断と偏見で選ぶ、特に面白かった知見Virtual monorepoサイボウズでは最近 virtual monorepo というパターンが大流行しています。詳しい説明は以下の記事に任せますが、ざっくり説明すると virtual monorepo とは複数のリポジトリを横断した AI 操作の簡便化を狙った単一のリポジトリです。例えばフロントエンドとバックエンドそれぞ

この記事は、CYBOZU SUMMER BLOG FES '26の記事です。こんにちは、kintoneダッシュボードチームの柿崎です！ADRで感じていた課題私たちのチームでは、技術的な判断をADRとして残しています。一方で、ADRを書くことについて以下のような課題がありました。ADR作成が後回しになりがち技術的な決定がされたすぐ後、記憶が新鮮なうちに作成したいが、他の優先度の高いタスクに追われてなかなか着手できない。あとで書こうと思っているうちに記憶が薄れ、いざ書こうとすると調べ直しから始めることになり時間がかかる。ADRを書くために必要な意思決定の情報があちこちにあるADRを書く際に必要な情報や裏付けは、作業ログ、仕様書、実装コードなど複数の場所に散らばっている。ADRを書くには、それらを横断して読み直し、要点を再構成する必要がある。やったこと：Claude の Agent Skills で ADR を作成するそこで、ADR作成作業を Claude Code の Agent Skills として定義しました。/create-adr のように呼び出すと、決められた手順に沿って Claude が動いてくれます。ADR 作成スキルの流れは、ざっくり次のようになっています。情報収集 — 社内のドキュメント置き場から、タスクの作業ログ・仕様書などをマークダウン形式でエクスポートして手元に持ってくる情報の探索 — エクスポートしたファイル群と、必要に応じて関連リポジトリの実装コードを読み、テーマに関係する背景・議論・決定事項を見つける内容・構成の合意 — いきなりADR全文を書かず、まずADR内の各項目ごとに内容・構成をユーザーに提示し確認を求め、方向性のすり合わせをする方向性がずれたまま清書すると手戻りが大きいので、清書前に合意するチェックポイントを必ず挟むようにしたClaude が判断に迷った点を明示して質問させて、曖昧なまま進めないようにした清書 — 合意した内容をもとに、過去 ADR のスタイルに沿って本文を書き上げ、出力するここで鍵になるのが、「1. 情報収集」の部分で出てきたタスクの作業ログ の存在です。最終的な意思決定や、そこに至るまでの情報はほぼ揃っている 状態です。情報を残して追跡可能にするというチームの文化があるからこそだと感じています。また、裏付けとして

この記事は、CYBOZU SUMMER BLOG FES '26の記事です。こんにちは！2026年4月にキャリア入社した、QAエンジニアの いこ（@ico_penjelly） です。前回担当した記事では会社全体についての私の所感を書かせていただいたのですが、今回はQAの一員として、サイボウズのQAについて書いてみます。……と言いつつ、私はまだ入社4か月目。サイボウズQAのすべてを知っているとはとても言えません。転職してきたばかりの私の目に映った「ここがすごい」を3つに絞って書きます。外から来たばかりの今だから感じられる驚きもあるはずと信じて……！※あくまで4か月目時点の、私の観測範囲での感想です。あらかじめご了承ください。その1. 品質がQAだけのものじゃないその2. QAの守備範囲が、広くて深いその3. QA組織が、採用も、教育も、外部への発信もやっているおわりに：だから毎日、力不足を感じていますその1. 品質がQAだけのものじゃないこれまで、QAと開発の役割分担がわりと明確な職場も見てきました。だからこそ、サイボウズで品質を考えるのがQAだけの仕事になっていない場面に出会うたび、いいなと思っています。例えば私のチームでは、「この機能のここ改善したいかも」といった検討の段階から、QAも議論に参加させてもらっています。開発エンジニアのリファインメント会議にも参加しています。チームで品質について考えている表れだなと感じたのが、会議でQA以外のメンバーからも「当たり前品質（なくて当然と思われる品質、の意味のQA用語です）」という言葉が自然に出てきたときです。こうした品質意識の背景として、研修も影響がありそうです。サイボウズのエンジニア新人研修には、品質まわりの講義が組み込まれています。「ソフトウェアテスト」や「自動テスト」の講義があり、講義資料も公開されています（リンクは2025年版）「サイボウズのアジャイル・クオリティ」という講義では、品質を「誰かにとっての価値」と捉えてチーム全員で支えるものとして説明されています。個人的にもとても好きな資料です！開発エンジニアが入社後すぐにこうした研修を受けていることも、私のチームに限らず会社全体で品質意識が高く保たれる土壌になっているのだろうな、と勝手に納得しています。その2. QAの守備範囲が、広くて深い入社して面食らったことの

この記事は、CYBOZU SUMMER BLOG FES '26 の記事です。こんにちは！クラウド基盤本部 PDX（Platform Developer Experience）チームのびきニキ（@BkNkbot）です。本記事では、サイボウズの Kubernetes プラットフォームを支える OSS のひとつである Cattage について紹介します。サイボウズの Kubernetes クラスタサイボウズでは1つの Kubernetes クラスタを複数のテナント（Kubernetes クラスタリソースへのアクセス権を持つ開発チームの集まり）で共有しています。この共有のやり方には種類がいくつかあるので、まずは本題に入る前にサイボウズの現状を紹介します。マルチテナンシー複数のユーザーが同じサーバーやアプリケーションなどのシステムやサービスを共有して使う方式をマルチテナンシーと呼びます。この記事においては、1つの Kubernetes クラスタを複数のテナントで共有することを指しています。マルチテナンシーには大きく2つの形があります。ソフトマルチテナンシー: 1つのクラスタを共有し、Namespace, RBAC, NetworkPolicy, ResourceQuota, Pod Security などの設定で論理的に隔離する方式。ハードマルチテナンシー: クラスタや Control Plane を分離（例：クラスタ単位の分割、kube-apiserver 等の仮想クラスタ、専用ノード / ネットワーク）し、強い境界を持たせる方式。サイボウズではソフトマルチテナンシーを採用しています。Argo CDサイボウズの Kubernetes 基盤では Argo CD が標準的なデプロイツールとして使われています。Argo CD は Kubernetes 向け GitOps ツールであり、Git リポジトリに保存されたマニフェストファイルと Kubernetes クラスタの状態を継続的に同期し、宣言的な設定管理を実現します。サイボウズでは Argo CD の AppProject を用いて、各テナントごとにアプリケーションのアクセス制御やリソース制限などを一括で管理しています。過去にもさまざまな Argo CDの記事 が公開されていますので、興味のある方はぜひ読んでみてください！A

この記事は、CYBOZU SUMMER BLOG FES '26の記事です。CIはどれだけ速くてもいいこんにちは。サイボウズで大規模向けグループウェア「Garoon」を開発している赤間です。私たちのプロダクトには、PHPUnitのテストケースが15,000件以上、テストファイルは1,500以上あります。これらを4並列のCIで回しても、PHPUnit本体で約5分程度かかっていました。この記事は、その4並列のPHPUnit実行時間を1並列1分まで短縮した方法を解説します。一言でまとめると、テストケース間の副作用をすべて解消し、PHPUnitのprocess isolationをオフにしました。そして、その過程で最大の難関だった、どのテストが副作用を持っているのか分からない問題を、乱択と二分探索で解決しました。process isolationによるプロセス起動コストprocess isolationとはPHPUnitには、テストケースを1件ずつ別のPHPプロセスで実行する仕組み (processIsolation) があります。これを有効にすると、テストごとにプロセスを起動するため、global変数やstatic変数など、プロセス内に蓄積されるあらゆる状態が毎回リセットされます。つまり、テストがどれだけ行儀悪く状態を汚しても、次のテストには影響しません 1。その代償がプロセス起動のオーバーヘッドです。テスト1件ごとにPHPプロセスの起動、autoloaderの初期化、ブートストラップの読み込みが走ります。1件あたりのコストはわずかに見えても、15,000件分のオーバーヘッドがテスト全体の実行時間を大きく左右します。実際に計測すると、テスト本体のロジックよりも、プロセスの起動と初期化に大半の時間が費やされていました。process isolationを切ることの難しさこのことは以前からも問題になっており、何度かprocess isolationを無効にする試みは行われてきました。しかし単純に無効化してPHPUnitを回すと、ある時点でテストがエラーで失敗してから後続のテストが派手に壊れる状態となり、どこから手をつければいいか分からない状態になる、という経験をしました。確実に発生しているであろう副作用を直そうとしても、どこで発生しているかの特定、および修正していく戦略を練る

この記事は、CYBOZU SUMMER BLOG FES '26の記事です。はじめにこんにちは。開発本部でオンボーディングを担当している久宗（@tignyax）です。前回は「新卒目線による記事」をご紹介しましたが、今回は運営目線による記事として「2026年のエンジニア新人研修の裏側」をご紹介したいと思います！AIの急速な発展や新卒メンバーのバックグラウンドの変化に伴い、事前に設計した研修カリキュラムだけでは対応しきれない場面が増えてきています。この記事では、今年の試行錯誤と、そこから得た「変化への柔軟性と、変わらない本質」についての学びを共有します。研修の目的と目指す状態研修の大きな目的は、「新卒メンバーが一日も早く自身の力を発揮し、チームに貢献できるようになること」です。配属後にスムーズに業務に取り組めることはもちろん、入社1年後にチームや組織に貢献できていると実感でき、今後のキャリアの強固な土台を作ることを目指しています。そのために、「事業・組織・チーム・自身を理解する（自社〜自身の理解）」と、「エンジニアとしての標準スキルやチーム開発の基本を身につける（成長するための力）」の2軸で要素を整理し、同期同士の繋がりも強化できるよう設計しました。研修のカリキュラムとスケジュール講義実習期間（4/23〜5/19）事業理解・組織理解・技術的な講義など、働く上での知識ベースを揃えるインプット＆ワーク期間です。※具体的な講義内容は過去の講義資料公開記事をご参照ください。2026年の資料公開記事については後日公開予定です。実践演習期間（5/20〜5/29）学んだ知識をチームで実践する期間。スプリントや振り返りなどのチームプロセスを、自分たちに合う形にカスタマイズしながら開発を進めます。また、日々の朝会・夕会で感想共有や雑談の時間を設け、横の繋がりも意識して設計しています。研修設計で意識した工夫運営にあたり、特に以下のポイントを意識しました。学習体験のグラデーション：抽象的な講義から徐々に技術講座へと繋げ、ワーク実習をこまめに配置。脳と心身の負担軽減：インプット過多を防ぎ、オンライン環境での孤立防止や日々の体調ケアを徹底。チーム開発の本質と伴走：「チームで開発するとはどういうことか」「理想の擦り合わせがいかに大切か」を体感してもらいつつ、混沌とした場面では適切なタイミングでフォ

この記事は、CYBOZU SUMMER BLOG FES '26の記事です。こんにちは、サイボウズでプロダクトエンジニアをしている大塚です。サイボウズでは現在、kintoneのフロントエンドをGoogle Closure ToolsからReactへ移行する刷新プロジェクトを進めています。私はkintoneアプリに関連する画面のReact移行を担当する「ババロア」チームに所属し、グラフ詳細画面のReact移行にも深く関わりました。この記事では、その中でグラフ描画に関して行った工夫を紹介します。刷新前の構成と課題グラフ詳細画面では、棒グラフ・折れ線グラフ・円グラフなどのグラフ形式の描画にHighchartsというグラフ描画ライブラリを用いています。Highchartsでは、描画内容を表すOptionsオブジェクトを渡してグラフを描画します。このOptionsオブジェクトは、集計APIのレスポンスをもとにフロントエンドで組み立てています。集計APIのレスポンスは、以下のような構造です。{ "schema": { "fieldList": [ { "label": "受付日時 (月単位)", "type": "DATETIME" }, { "label": "問合せ種別", "type": "SINGLE_CHECK" }, { "label": "レコード数", "type": "DECIMAL", "op": "COUNT" } ] }, "records": [ { "fieldList": [ "2018-01", "製品について", 1 ] }, { "fieldList": [ "2018-01", "受発注について", 2 ] } ]}（説明のために簡略化・抽象化しており、実際のレスポンスとは異なります。）この例では、fieldListの1番目が「受付日時（月単位）」、2番目が「問合せ種別」、3番目が「レコード数」にあたります。ただし、レスポンス上で各フィールドのグラフ上の役割が明示されているわけではなく、返ってくるのはあくまで集計結果としてのフィールド一覧とレコード一覧です。また、kintoneのグラフはユーザーが集計条件を設定できるため、レスポンスに含まれるフィールドの数や意味も変わります。たとえば、kintoneのグラフでは「分類する項目」として3つのフ

この記事は、CYBOZU SUMMER BLOG FES '26の記事です。はじめまして！2026年4月にキャリア入社しました、開発本部 kintoneプラットフォーム副本部の いこ（@ico_penjelly） と申します。入社してもうすぐ4か月、長かったような短かったような……その中で私なりに色々体験したり考えたことをまとめるためにも、サイボウズに入って感じたことを一問一答形式で書いていきます！※あくまでキャリア入社4か月目時点での個人的な感想です。完全に主観の話となりますのであらかじめご了承ください。今回答える質問はこの6つです🎩Q. 入社前後でギャップを感じたことは？Q. どんな人が多いと感じますか？Q. どんなチームが多いと感じますか？Q. 仕事のやりがいを感じるのはどんなときですか？Q. ここがおしい！と思うところは？Q. ここがハオ（好）！と思うところは？気になる質問だけのつまみ食いも大歓迎です🍚🍽️それではいってみましょう！Q. 入社前後でギャップを感じたことは？あまりギャップを感じるようなことはありませんでした！3分でわかるサイボウズは今見返しても本当にその通りだなと思います。ただ、情報のオープンさは想像以上でした。公開されている会議資料が多くて、参加していなくても内容が見に行けるkintone内にみなさんがどんどん情報を残すので、データがどんどん蓄積されている各人の分報に書かれた「困っていたけどこうやって解決した」とか、困っている人に他の人がアドバイスしているログなども全部見れるので、同じ悩みに当たったらそれを参照できる会社や人やチームを知ることにも繋がっていて、入社したての身にはとても嬉しい環境です。一方で「あの情報どこだっけ！？」と入社当初は毎日のように迷子になっていたのですが、ありがたいことに社内AIで横断検索までできるようになってから、本当にみなさんの残した資料や知識に助けられています！Q. どんな人が多いと感じますか？ずばり、学園祭実行委員みたいな人が多い印象です！といっても、お祭り騒ぎが好きな人の集まり、という意味ではありません（イベントごとはちょっと苦手、という方ももちろんいます）。それに、気遣い上手で周りの「困った」を拾うのが上手な方がたくさんいらっしゃいます。分報にマウスに悩んでる旨を書いたら、他チームの方がおすすめのマウ...

この記事は、CYBOZU SUMMER BLOG FES '26の記事です。はじめにこんにちは！サイボウズでQA(品質保証)エンジニアをしているすずりん🦒です。入社して1年とちょっと、チームに配属されてからは丸1年が経ちました。現在は、Garoonの品質にかかわる活動を担当するSpicaチームに所属し、品質基準の見直しや社内外から報告された不具合の再現調査・不具合登録に取り組んでいます。先日、先輩たちとのランチで「普段の業務についてのブログってあんまりないよね」という話になりました。思い返せば私自身、入社前は1年後にどんな業務をしているか全く想像できていませんでした。ということで、今回のSUMMER BLOG FES！では、配属から1年間で経験した業務をタスク記録を元に振り返っていきたいと思います。はじめに1年間のタスクを振り返る普段の1日の過ごし方印象に残ったタスク1. 不具合改修のオーナー業務2. リリース基準の改善3. AI活用4. 社外発信・勉強会できるようになったこと・挑戦していることまとめ1年間のタスクを振り返る普段の自分のタスクは、個人のkintoneアプリで管理しています。タスクの進行状況、カテゴリー、作業日時、作業履歴を記録して、今取り組むべきタスクが一目でわかるようにしています。※タスクの粒度は結構バラバラです。ただ、自分がタスクを見たときに内容を手早く理解できるように、1日で終わる程度の粒度にするようにしています。ざっくり、タスクのカテゴリーごとの内訳はこんな感じです。プロセス改善のタスクと不具合関連タスクが同じくらいありました。これらの詳しい内容については、後の章で触れていきます。事務作業や学習などはかなり細かい粒度で登録していたので、件数のわりには実働時間は少ないはずです。普段の1日の過ごし方日によって変わりますが、ある1日のスケジュールはこんな感じです。 時間 やること 9:30 始業！通知を確認して、今日やることの優先順位をつける 10:00 チーム朝会。終わり次第、チームの定常業務や昨日からの続きタスクに取り組むことが多い。 12:00 昼休憩 13:00 問い合わせや、依頼していたレビューへの返信など 14:00 ミーティングがない日は、このくらいの時間から深く考えることが必要なタスクに取り組むことが多い 16:00 デイリーリフ...

この記事は、CYBOZU SUMMER BLOG FES '26の記事です。こんにちは。kintone開発チームのプロダクトエンジニアの宇都宮です。主にkintoneのバックエンドを開発しています。本題に入る前に、この記事に出てくるkintoneの用語を簡単に説明します。kintoneでは、ユーザーが「アプリ」と呼ばれる業務アプリケーションをノーコードで作れます。アプリはデータベースのテーブルに近い存在で、そこに登録される1件1件のデータが「レコード」です。RDBでいう行にあたります。登録したレコードは「一覧」と呼ばれる画面で確認でき、ユーザーはここで条件を指定してレコードを絞り込んだり、並べ替えたりします。アプリにはさまざまな種類のフィールドを配置できます。多くは1つの値を持つフィールドですが、中には1つのフィールドで複数の値を持てるものがあります。たとえば、タグ付けのように複数の選択肢をチェックできる「複数選択」や、担当者を複数人設定できる「ユーザー選択」です。本記事では、これらを「複数値フィールド」と呼びます。1. 件数が増えるほど遅くなる絞り込みkintoneは、レコードが増えても快適に使い続けられることを目指しています。しかし、複数値フィールドで絞り込むと、レコード件数が増えるにつれて実行時間が延びていくことがありました。検証環境では、複数選択フィールドを持つ、レコード数が100万件のアプリで、絞り込みに約3秒かかっていました。数千件のうちは気にならなかった遅さが、数十万〜数百万件の規模になると「一覧がなかなか表示されない」という形でユーザーの体験に影響してきます。この記事では、この絞り込みが遅くなる仕組みをkintoneのデータ構造から順に説明し、MySQLのsemijoin最適化で解決するまでの過程を紹介します。2. kintoneはレコードをどう持っているか原因を理解するために、まずkintoneのデータの持ち方を説明します。kintoneでは、アプリごとにスキーマが自由に変わります。ユーザーがフィールドを追加したり削除したりするたびにRDBMSのテーブル定義を変更するわけにはいかないため、レコード本体はスキーマレスな形でまとめて格納しています。ただ、そのままでは検索できないので、検索用のインデックステーブルを別に持っています。ポイントは以下の3つで

この記事は、CYBOZU SUMMER BLOG FES '26の記事です。はじめにこんにちは！スクラムマスターのOhishiです。スプリントゴールとはスプリントゴールは、スプリントで目指す唯一の目的です。スプリントプランニングで決めるスプリントゴールを設定するのは、スプリント初日に実施するスプリントプランニングの場です。意識していることスプリントゴールを設定する際に意識していることが3つあります。達成率50％くらいを狙うアウトカムを表現する時間をかけすぎないそれぞれ詳細を書いていきます。達成率50％くらいを狙うスプリントゴールは、大体達成率50％くらいの線を狙うつもりで設定しています。長期間ゴール達成が続くと、ゴール設定が低くないかな？と考えますし、逆に未達が長く続く場合は、チームのプロセスや時間の使い方に何かしらの問題が潜んでいる可能性が高いです。 アウトカムを表現するスプリントゴールは、そのスプリントでやるプロダクトバックログの要約ではありません。あるスプリントで「複数枚の連続撮影の体験を確認できる」というスプリントゴールを設定したことがありました。体験を確認する場（シチュエーション）としては、チーム内での動作確認、プロダクトマネージャーに動作確認してもらう、スプリントレビューでのデモなど、いくつか選択肢がありました。どこまで進められるかプランニング時点ではわからなかったため、確認するタイミングや相手は限定せず、あくまで価値に絞ってスプリントゴールを立てました。時間をかけすぎないスプリント内で稼働できる日数が少ない時や、タスクの状況によっては、うまくアウトカムとして表現できないこともあります。うまく運用するには今私が所属しているiOSのモバイルアプリチームは、スプリントゴールに前向きで、効果的に運用できていると感じています。おわりに私のチームでは、スプリントゴールは有効なものとして運用されていると感じますが、もちろん、まだまだ改善の余地はあります。これからもスプリントゴールの設定を繰り返し、チームとして練度をあげていきたいと思っています。