プロダクトエンジニアの谷(@uta8a)です。2025年にkintoneのダッシュボード開発チームにジョインして、1年半近くプロダクトエンジニアとして働き、kintoneの性能ダッシュボード、利用状況ダッシュボードのリリースに関わってきました。今日はチーム紹介をします！kintoneを、もっと安心して大規模に活用していくために必要なことkintoneは、様々な業務システムが作れる業務改善プラットフォームです。現在42,000社(執筆時点)に使われているkintoneは、多様な業務を支えています。しかし、大規模利用に伴い足りない部分も出てきました。アプリの操作が重いという問い合わせを、現場からIT部門が受け取るIT部門がkintoneの活用を促進していきたいが、どう使われてきたのか分からないこうした大規模利用に伴う不安への対応や、もっとkintoneの利用を拡大していくための後押しが必要です。これらの課題はお客様が現状を把握できることがまず必要だと考え、kintoneの状態を時系列で把握できるような、管理者向けダッシュボード機能を開発しています。(性能など、改善もセットで必要な部分は別チームで取り組んでいます！ *1 )ダッシュボードの開発によって、例えば次のような効果を目指しています。このペースの利用増だと性能問題が起こりそう。性能カスタマイズオプションを検討しよう社内のkintone活用の実態が分かった。全社導入に向けて動いていきたいこのようにして、もっと安心して大規模にkintoneを活用していける世界を目指しています。もっと安心して大規模にkintoneを活用していける世界を目指していますkintoneのダッシュボード開発チームの取り組み今までに、3つの種類のダッシュボードをリリースしています。性能ダッシュボード大規模利用顧客向けに、アプリの性能情報を見て改善の効果測定に役立てる利用状況ダッシュボード社内のkintone活用状況を見て、活用促進に繋げられる社内向けダッシュボードサイボウズ社内でのお問い合わせ対応や、次に作るダッシュボードを考えるヒントとして利用するこれらのダッシュボードで価値を素早く提供するために、以下のような取り組みをしています。既存プロダクトとビジョンを共有しつつ、作るものを自分たちで決めるダッシュボード開発はkintone本体とは独立した

こんにちは！ QAエンジニアの小竹です。OfficeMobileチームでiOSアプリのQAとして働きつつ、QA外部コネクトチームの一員として他社エンジニアの皆さまとのつながりを生み出す活動に携わっています。サイボウズは、2026年5月29日（金）に開催されたソフトウェアテストのシンポジウム JaSST'26 Tohoku にスポンサーとして協賛しました。この記事では、 JaSST'26 Tohoku でのサイボウズの発表についてご紹介するとともに、発表に使用した資料を共有させていただきます。登壇情報今回はスポンサーセッションに1名が登壇しました。新卒1年目QAがリリース基準の"なぜ"をたどってみた speakerdeck.comこのLTセッションでは、2025年度新卒入社・山形大学出身の「すずりん（@kir1nak.bsky.social）」から、担当製品のリリース基準の裏に潜む背景・目的を探究し、品質保証プロセスの改善に繋げた話を共有させていただきました。セッションをご視聴下さった皆様、本当にありがとうございました！また、SNS上で嬉しいコメントをくださった皆様にも、心からお礼を申し上げます。登壇の様子登壇者からのメッセージ会場でセッションを聞いてくださった皆様、そしてJaSST東北実行委員の皆様、ありがとうございました！学生時代を過ごした東北の地で、このような登壇の機会をいただけたことを非常にうれしく思っています。今回の発表内容が、皆様が取り組む業務改善の一助になれば幸いです！終わりに今回のJaSST'26 Tohokuは、基調講演・事例発表でハーネスエンジニアリングが取り上げられたこともあり、「QAがAIとうまくやっていく」というテーマでの盛り上がりが見られました。「AIを使って何をするか」を模索する段階から一歩進み、AIという新たな「仲間」をチームに迎え、いかにチームワークを発揮してQA活動を推進していくべきかを考えるフェーズに入ってきたことをひしひしと感じますね。サイボウズQAはこれからも「チームワークあふれる社会を創る」という企業理念のもと、AIという頼もしいチームメートとともにチームワークをフルに発揮し、kintoneやGaroon、サイボウズ Office、メールワイズなど、チームを支えるサービスをお客様にお届けしてまいります。QAエンジニア採用強化

はじめにはじめまして、開発本部 kintone アプリ化チームの okarin です。サイボウズは2025年にエンタープライズ事業者向けに、外部システムの kintone アプリ化という機能をリリースしました。この機能は、外部システムのデータを kintone のアプリとして扱うことができる機能なのですが、これを実現するためのアーキテクチャが他ではあまり見ない作りになっているので、ここで紹介していきたいと思います。（本記事では顧客のプライベートネットワーク内にあるシステムをサイボウズ側からの視点で「外部システム」と呼ぶことにします）技術的な制約外部システムのデータを kintone で扱うために、はじめに思いつくのは kintone から外部システムにリクエストを送る構成だと思います。しかしながら、エンタープライズ事業者の現場でこの構成を実現することは難しいです。外部システムはインターネットから到達できるケースは少なく、プライベートネットワークで動いていることが多いです。仮に kintone からのネットワークリクエストを許可しようとすると、プライベートネットワークに inbound 通信を通すという意思決定が必要になり、セキュリティ面のリスクが増え、顧客の運用コストも大きくなります。このような理由から、kintone 側から取りに行くという発想自体を捨てる必要がありました。kintone から外部システムへの通信はできない採用したアーキテクチャそこで今回は「通信の方向を逆にする」という方式を採用しました。kintone から顧客のプライベートネットワークに入るのではなく、顧客のプライベートネットワーク内に Agent をおき、Agent から kintone 側に outbound 接続してもらう構成にしました。outbound 接続であれば、顧客のプライベートネットワークに外部から到達可能な経路を作らずに済みます。アーキテクチャの詳細を以下の図に示します。採用したアーキテクチャgRPC の Bidirectional streaming RPC で顧客側にある Agent からサイボウズ側の Proxy に接続することで双方向に通信可能にするkintone 上で操作が行われたら Proxy にリクエストを送信するgRPC の Bidirectional stre

はじめにはじめまして、開発本部 kintone アプリ化チームの okarin です。先日、 JJUG CCC 2026 Spring に初参加し、 LT で登壇しました。Java は使い始めて4ヶ月程度とまだまだ初学者の身ではあるのですが、 JJUG CCC 2026 Spring に参加してとても良い体験になりました。初学者の方にも参加するきっかけになれば良いなと思い、今回こうして記事にしました。JJUG CCC 2026 Spring のパネル聴講したセッション当日は以下のセッションを聴きました（時間順に並べています）。Enum徹底入門Enum の仕組みから活用パターンまで幅広く解説していました。個人的には Enum はクラスであるということ、 Enum 定義の中に状態と遷移ルールを記載することができる、ということが学びになりました。特に前者は OpenJDK のソースコードを読みにいったり JLS を読みにいくきっかけになりました。www.docswell.com軽量Java基盤の設計 ー DIコンテナに頼らない、長期保守と1秒起動の実現Java のプロダクトは起動やテストに時間がかかりがち、ということでそれを短縮したという話を期待して聴きにいきました。 DI コンテナを使用せずに、サービスロケータを改良した独自の依存解決フレームワークを作成し、起動時間の短縮に成功したという内容でした。 kintone 開発ではなかなか採用しづらいアプローチなのかなと感じましたが、1つのアイデアとして学びになりました。 speakerdeck.comModular Monolith Locally, Microservices in Productionマイクロサービスはローカル開発では立ち上げづらい、サービスを跨いだデバッグがしづらいという課題があり、それを解決するアプローチを解説していました。ローカル開発環境では1プロセスの中で各種サービスを立ち上げてモジュラーモノリスとして振る舞い、本番環境ではマイクロサービスとして振る舞う、というもので面白いアプローチでした。www.docswell.com肥大化するレガシーコードに立ち向かうためのインターフェース分離と依存の逆転こちらのセッションは弊社の前田さんによる発表で、 kintone のレガシーコードを改善した話になります

W3C村井先生 x サイボウズ青野社長 特別対談サイボウズでデザインテクノロジストをしている @saku です。2026年5月14日、第1回 W3C日本会員会議が慶應義塾大学で開催されました。本会議の中で、W3C Japan 30周年特別対談と題し、慶應義塾大学村井先生とサイボウズ青野社長との対談が実施されました。Web やサイボウズの黎明期の話から、インターネットを通じて人々を「横に繋ぐ意義」、日本のデジタル市場の現状や、AI を用いたコミュニケーションの未来まで、さまざまな議論がなされました。当日の白熱した議論の内容をレポートします。Intro(以下 M: 村井先生, A: 青野社長)M: 今日ちょっと楽しみにしてたのは、W3C Japan は 30 年なんですよね。サイボウズっていつできたんだっけ？A: 97 年ですね。M: だから、ほとんど同じ時期を過ごしてきてるんだよね。M: まあ皆さんもサイボウズって会社は知っていると思いますけど、一番最初グループウェアみたいな概念がサイボウズから語られて。M: 今となっては、グループウェアは「どういうふうに人間が集まって力を発揮できるか」っていうプラットフォームだと思うんだけど。M: そこから今 AI 時代になって、大学がね「これから教育をどうしたらいいんだ」っていう話になるじゃない。M: SFC は 90 年にできたけど、最初の頃からグループワークっていう概念を授業の中に取り入れて、多様な人間が集まって力を合わせてってことをやってきてM: でも AI 時代になって、知識を伝搬するっていう話じゃなくて、人間が力を合わせて作るっていうような話になるに至り、これサイボウズがあの時からやられてきたことだと思うんだよね。M: そのへん、どういう風に思われてますかっていう議論ができればと思って、今日来ていただきました。A: こちらこそ、ありがとうございます。サイボウズの歴史A: じゃあ、まず僕が Web とどういう風に付き合ってきたのか、スライドでまとめてきたので、ちょっとぜひ突っ込みながら聞いて頂ければと思います。WebとともにA: タイトルは「Web とともに」っていうことで「フォースとともにあらんことを」といった意味ですね。A: まず私のプロフィールですけど、創業して 28 年で来月 55 歳です。A: もともと情報システ

はじめにこんにちは！デザインテクノロジストをしている saku です:)先日行われた Google の開発者向け年次カンファレンス 「Google I/O」に、弊社メンバーで現地参加してきました。io.googleエントランス付近の Google I/O サイン今年は、2026/5/19~2026/5/20 の2日間、カリフォルニア州の Mountain View にある Shoreline Amphitheatre で開催されました。I/O では、Google の提供する最新技術や製品のアップデートを、セッションや Googler とのディスカッションを通じてキャッチアップできます。弊社からは Web, AI, Android, Flutter にフォーカスして参加してきました。現地参加 OverviewPre-I/O日本からサンフランシスコまでは直行便で 9~10時間ほどでした。帰りは向かい風になるので 11時間で、すごく遠いですね。今回は時差ボケ・前日の予定を考慮して、当日の前々日に到着しました。当日混まないように、前日は Badge pick up があります。I/O swag もこのときから先着順で受け取れます。Find Your Way to register の看板登録を済ませて、Swag を受け取ります。今年のスワッグにはかっこいいタンブラーが入っていて嬉しかったです！Registration テントの中Registration を済ませて I/O Pass を受け取りました今年はなんと新型 gBike のライド体験ができたので、これで Google の BayView Office までサイクリングをしました！山々が望めるのですが、The 「Mountain View」という感じがしてとても爽快です。Google BayView Officeその日のランチは、Google Visitor Center にある Cafe でいただきました。横には Store があって、ここでしか買えない Google グッズが手に入ったりします🧤Google Visitor Center 夕方からは、一部メンバーで Chrome チームのパーティーに行ってきました。Chrome チームのパーティーに参加して、会話をしているI/O Day1待ちに待った Google...

こんにちは、フロントエンドエンジニアのmehm8128です。好きなユーティリティ型はReturnTypeです。2026年5月22、23日に行われたTSKaigi 2026にて、サイボウズはゴールドスポンサーとして協賛し、ブースを出展しました。当日の様子を紹介します。ブースサイボウズのブースでは、「サイボウズのフロントエンドの印象を教えてください！」および「サイボウズ エンジニア社員が何でも話します！！」の2つの企画を行っていました。前者は付箋を貼ってもらう形式、後者は付箋を貼ってもらうか、既に貼ってある付箋の中から気になるトピックを選ぶ形式でした。答えてくれた方には以下のようなノベルティをお渡ししていました（参加者の方のポストの画像をお借りしています🙏）。よく出ていた話題をいくつか紹介します。サイボウズ エンジニア社員が何でも話します！！最近行っているプロジェクトの話として、フロントエンド基盤の刷新に興味を持っていただいている方が多かったです。kintoneは現在、Google Closure ToolsからReactへと移行しており、その過程でJavaScriptからTypeScriptへの移行もしています。フロントエンド基盤の刷新については、以下のスライドを併せてご覧ください。 speakerdeck.comまた、組織でのAI活用についても質問が多くありました。kintoneのフロントエンドにおけるAI活用については、以下の記事をご覧ください。blog.cybozu.iozenn.devサイボウズのフロントエンドの印象を教えてください！サイボウズのフロントエンドと言いつつ、サイボウズ全体の印象でも可としていたところ、ちょうど前日にプレスリリースが出ていたコーポレートロゴのアップデートの件を挙げてくださる方が多くいました。今回のノベルティやパネルではロゴのアップデートは間に合わなかったのですが、次回以降は新しくしていければと思います。他に、W3CやWeb標準関連のイメージがあるという方も多くいました。僕が発案・企画して半年以上続いているWeb標準動向を読んでくださっている方が多く、嬉しかったです。今回はW3Cとサイボウズのロゴを並べたパネルを設置したり、W3Cの新ロゴのステッカーを配布したりしていました。今後もW3CやWeb標準周りの取り組みを行い、発信も行って...

こんにちは！ QAエンジニアの小竹です。 OfficeMobileチームでiOSアプリのQAとして働きつつ、QA外部コネクトチームの一員として他社エンジニアの皆さまとのつながりを生み出す活動に携わっています。サイボウズは 2026年5月29日（金）に開催されるソフトウェアテストのシンポジウムJaSST'26 Tohokuにスポンサーとして協賛します。今回はスポンサーセッション（Lightning Talk）に弊社のメンバーが登壇予定ですので、その概要をご案内します。新卒1年目QAがリリース基準の"なぜ"をたどってみた日時5月29日（金）🕰️タイムテーブルはこちら登壇者すずりん（@kir1nak.bsky.social）内容紹介2025年度新卒入社のQAエンジニアが、担当製品Garoon（※）のリリースクライテリアについて、それぞれの基準がなぜ定められているのかを探求した経験をお話しします。※Garoonはサイボウズが提供する、中・大規模組織（数10名〜数万名規模）向けのグループウェア製品です。登壇者のすずりんは、新卒入社1年目のQAメンバーです。中堅・シニアQAにとっても手強い印象のあるクライテリアの探求に新卒のすずりんがどう取り組んだのか、フレッシュな視点での発表をお楽しみに…！なお、今回セッションに登壇するきっかけとなったブログ記事はこちらです。JaSST'26 Tohokuに参加されるご予定の方も、そうでない方も、よろしければぜひご一読ください。blog.cybozu.io終わりにサイボウズでは「チームワークあふれる社会を創る」という企業理念のもと、kintoneやGaroon、サイボウズ Office、メールワイズなど、チームを支えるサービスを開発しています。 私たちQAエンジニアは、これらの製品の開発プロセス全体を通じて品質を高めるべく日々奮闘しています。今回のJaSST'26 Tohokuへの協賛＆登壇、そしてアフターイベントの開催が、ソフトウェアテストコミュニティへのささやかな貢献となることを願っています。QAエンジニア採用強化中！現在サイボウズでは、チームの一員として活躍していただけるQAエンジニアを募集しています。サイボウズの企業理念に共感いただけるQAエンジニアの皆様、私たちと一緒に働きませんか？募集要項は以下のページにてご確認いただけます。c...

こんにちは。@toma_cy）です。新卒社員6名に向けて、アジャイル・スクラム研修を企画・実施しました。今回の研修では、午前にアジャイル・スクラムの概要を講義形式で学び、午後はチームに分かれてスクラムによる疑似プロジェクトに取り組みました。本記事では、研修プログラムをどのように設計していったのか、実際にやってみて得られた学びや課題について紹介します。アジャイル・スクラム研修を企画している方や、体験型ワークの設計を検討している方の参考になれば嬉しいです。なぜ体験型の研修にしたのかスクラムは、フレームワークとしての構造を理解すること自体は比較的容易です。スクラムにはどのような役割があるのか、どのようなイベントがあるのか。一方で、スクラムを実際に使いこなすことは簡単ではありません。スクラムを理解したつもりで現場に取り入れても、うまくいかないことがあります。たとえば、以下のような状態です。スクラムイベントを実施することが目的になってしまうスプリントレビューが成果物の進捗報告会になり、学びや方向修正につながらないレトロスペクティブをしているが、実際の改善につながらない本来スクラムは、チームで価値を届けるためのフレームワークです。そのため、単にスクラムの用語や流れを理解するだけでなく、実際にチームで悩み、判断し、フィードバックを受けて改善する体験を通じて学ぶことが重要だと考えました。今回の研修では、スクラムを「知っている」状態で終わらせず、短い時間でも「体験したことがある」状態に近づけることを目指しました。研修の全体像研修は1日構成で実施しました。午前の部：講義 時間帯 内容 10:00 - 10:10 研修の概要説明 10:10 - 10:50 アイスブレイク 10:50 - 11:05 アジャイルの概要 11:05 - 11:30 スクラムの目的 11:30 - 12:00 スクラムの概要 午後の部：ワーク 時間帯 内容 13:00 - 13:05 午後ワークの説明 13:05 - 13:15 課題発表 13:15 - 16:00 疑似プロジェクトワーク（4スプリント） 16:00 - 17:00 全体のふりかえり・Q&A 午前の講義では、アイスブレイクに始まり、アジャイルの歴史的背景や概要、スクラムの目的や内容について扱いました。ただし、今回重視したのは、知識を細かく説明

こんにちは！サイボウズのAndroidエンジニア、トニオ（@tonionagauzzi）です！当社では、kintone、サイボウズOffice、Garoonの3プロダクトのAndroidアプリを開発しています。Androidエンジニアの多くは、いずれかのプロダクトの開発チームに所属して活動しています。そんなAndroidエンジニア同士がときどき集まる場として、チョルチャタンマという社内コミュニティがあります。立ち上げの経緯は、以下の記事を参照してください。blog.cybozu.ioちなみに、技術書典サークルのチョルチャタンマも、このコミュニティのことを指しています。2022年に発足したチョルチャタンマは、韓国語で「切磋琢磨」を意味し、その名の通りAndroidエンジニアが互いに学び合い高め合う場となっています。主な活動は、以下の2種類です。定期的な社内イベント不定期の社内外イベント1. 定期的な社内イベント1-1. 技術ミーティング週に一度、各自が得た知識や各プロダクトの技術的な取り組み、Android関連の最新情報などについて共有する時間をとっています。最近では、下記のテーマでミーティングを開催しました。他社のAndroidアプリを触ってみるClaude Codeのベストプラクティスを読んでみる他の人が作ったAIのスキルやエージェントを眺めてみる技術を取り扱うため、参加にあたって無知がバレるのが怖いなどの心理的ハードルがあるかもしれませんが、参加者にそう感じさせないように工夫をしています。たとえば、3. の会では他の人が書いたスキルやエージェントを評論家目線で批評しないことを事前にルールとして決め、合意しました。また、発言しづらい場合もチャットやスタンプを使ったリアクションが活発な印象で、ワイワイガヤガヤとしています。ミーティングの様子（2026年5月18日）2. 相談会こちらも週に一度、開発で困っていることや個人的な悩み、思いついたアイデアなどを気軽に相談・共有する会です。たとえば、以下のような相談が行われます。普段の取り組みを発信したい！プロダクトコードの一部をOSS化したい！新しいOSバージョンの対応どうする？3. ハードルの低いLT日々の業務や学習で得た学びを共有するライトニングトーク会です。発表形式は自由で、完成度が低くても問題ありません。これまでに、

こんにちは！開発本部 開発広報チームの北地（@tos_kitt）です。4月8日に開催した Cybozu Tech Meetup では、「巨大プロダクトに小さいチームで大きな変化を起こす」をテーマに、kintone の性能ダッシュボード開発の裏側を取り上げました。イベント当日は、技術的な工夫だけでなく、チームの意思決定のあり方や、プロダクトに向き合う姿勢まで含めて、学びの多い時間になりました。この記事では、運営者として印象に残ったポイントも交えながら、当日の内容を振り返ります。なぜこのテーマで開催したのかサイボウズが提供するkintoneは、現在42,000社以上にご利用いただいている巨大なプロダクトです。日々機能追加や改善を続けていますが、これだけスケールしたプロダクトになると、新たな機能をどう作り、どう届けるかは決して簡単な問題ではなくなります。今回テーマに取り上げた「性能ダッシュボード」は、お客様自身でアプリのパフォーマンス問題の把握や改善に向けた判断ができるよう、性能指標を可視化する機能です。単にログやメトリクスを画面に出すだけでなく、どの情報を、誰が、どのように使える状態にするかを考え抜く必要がありました。運営者としてこのテーマを取り上げたいと思ったのは、ダッシュボード開発副部の取り組みが、単なる機能開発の話に留まらないと感じたためです。大規模プロダクトの一部を担いながらも、小さなチームだからこそできる意思決定や進め方を選び取り、実際に価値提供につなげています。その実践は、同じように複雑なプロダクト開発に向き合っている方々にとっても参考になるはずと思い、今回のイベントを企画しました。セッションのハイライトセッション1：小さなチームで、大きなインパクトを​ 〜プロダクトと向き合う面白さ〜登壇者：kenny（ダッシュボード開発副部 エンジニアリングマネージャー）kennyさんのセッション動画リンク最初のセッションでは、エンジニアリングマネージャーのkennyさんが、ダッシュボード開発副部の組織的な取り組みや開発スタイルについて話しました。チームの立ち位置として、「向かう先は同じだけど、走り方は自由」というスタンスが紹介されました 。kintone本体のビジョンやゴールは共有しつつも、独自の技術スタックや開発プロセス、意思決定を独立して行うことで、最速で動ける選択

入社5年、同期3人の振り返りこんにちは！2021年にサイボウズへ新卒入社した massan、taguchi、taku3n です。気がつけば入社から5年。同期3人がそろって在籍しているこの機会に、それぞれの5年間を振り返ってみました。massan kintone拡張基盤チームのQAエンジニアです。着物の勉強をしています。 taguchi PSIRTのプロダクトセキュリティエンジニアです。ラーメンが好きです。 taku3n Garoon開発チームのQAエンジニアです。最近ボードゲームにハマってます。 この記事は、QA として入社して１年経った話のリバイバル記事です。※元記事では柔軟な働き方について、現在は実現が難しいものが含まれています。あくまでQA職種の仕事や文化の参考としてご参照ください。最近はどんな業務をしてる？まずは、現在の業務について紹介します。massan 主務では、kintoneを拡張する人を支援する基盤づくりのQAをしています。APIやSDK、去年はMCPサーバーの開発にも関わっていました。兼務も少しあって、kintoneのセキュリティチャンピオン、社外向けの技術交流を促進するQA外部コネクト、QA新卒採用なども担当しています。マネージャーに誘ってもらったり、自分から関わりたいと思って始めたものばかりです。異なる分野を学び、それらを媒介したり組み合わせて生かしたりするのは自分の性格に合っていると感じます。いろんな業務を通してtaku3nやtaguchiさんをはじめとるする他メンバーとも製品を超えて刺激をもらうことができ、日々の業務のモチベーションになっています。taguchi 現在はサイボウズ Office、メールワイズ、販売管理システム、cybozu.com共通管理などのセキュリティを担当しています。具体的には、脆弱性診断、外部べンダー対応、バグバウンティ対応を中心に、担当製品のセキュリティに関する業務全般に携わっています。そのほかにも、PSIRTの新卒採用、情報発信、AIを活用したPSIRT業務・脆弱性診断の効率化にも取り組んでいます。taku3n 主にGaroonのリリース改善に取り組んでいます。具体的には、リリースとデプロイの分離やプロセス改善を通して、高速で安定したリリースの実現を目指しています。その中で、新しく作り上げるリリースフローのテスト

こんにちは、この記事はフロントエンドエンジニアのmehm8128とデザインテクノロジストの小林大輔の共著記事です。サイボウズは2018年に、WAIC（ウェブアクセシビリティ基盤委員会）の会員組織になりました。そもそもWAICとはWAICについては、公式サイトに以下のような説明が記載されています。ウェブアクセシビリティ基盤委員会とは、JIS X 8341-3が2010年8月に改正されたのと時を同じくして誕生した組織であり、情報通信アクセス協議会の取り組みの一つです。JIS X 8341-3改正原案作成メンバーや関連企業、関連省庁、ウェブの利用者から構成されています。JIS X 8341-3の理解と普及を促進するとともに、JIS X 8341-3を利用してウェブアクセシビリティを高めていくために必要な基盤を構築するために、さまざまな活動を行っています。英語ではWeb Accessibility Infrastructure Committeeと言います。頭文字をとって、WAICという略語（「ウェイク」と発音）を用いることもあります。ウェブアクセシビリティのガイドラインとして、W3Cによって定められているWCAGと、それが国際規格となったISO/IEC 40500が挙げられます。WAICでは、それらを日本の規格としたJIS X 8341-3に関連した様々な活動を行っています。サイボウズのPurposeは「チームワークあふれる社会を創る」です。そんなPurposeを掲げているサイボウズにとって、アクセシビリティとは「チームにアクセスできる能力」であると定義しています。そんな思想のもと、サイボウズはWAICでの活動だけでなく、普段の業務において様々な面でアクセシビリティに取り組んでいます。詳しくは以下のリンクをご覧ください。サイボウズの企業理念 | 採用情報 | サイボウズ株式会社アクセシビリティへの取り組み | サイボウズ株式会社QAでがっつりアクセシビリティテストをやるようになった話 - Cybozu Inside Outサイボウズ Office のフロントエンド刷新におけるアクセシビリティ改善の取り組み - Cybozu Inside Outkintoneのアクセシビリティ改善とESLintルールの整備 - Cybozu Inside OutWAICでは現在、以下の5つ

本記事は、2024年入社のQAエンジニア 3人による振り返りブログの3本目です。 blog.cybozu.ioはじめにこんにちは、GaroonというプロダクトでQAエンジニアをしている reo（@i_moqa）です⛄️Garoonの開発チームは複数のチームで構成されているのですが、私はその中のYukimiチームに所属しています。YukimiチームはGaroonで使用しているOSS（オープンソースソフトウェア）の更新や、セキュリティの維持・向上に向けた開発・保守を担当しています。Yukimiチームの詳細については以下の記事をご参照ください。blog.cybozu.io本記事では、新卒1年目から2年目の間で、チーム内外で自分の役割や動き方がどのように変化してきたのかを振り返ります。チーム内のタスクの変化新卒1年目から2年目にかけて、最も大きく変わったのはチーム内のタスクの進め方です。1年目は、スキルトランスファーを受けながら、チーム内で実施されていたタスクを進めることが中心でした。Yukimiチームのタスクは、OSSの更新やセキュリティ対応など影響範囲が広いものが多く、モブプログラミングで進めることも多かったため、進め方や考え方を含めて周囲に支えてもらう場面が多かったと感じています。2年目に入ってからは、チーム体制がスクラムからカンバン方式へ移行しました。これにより、各メンバーが個別にタスクを進める場面が増え、他メンバーと並行して進めながら、自らレビューや情報共有を行う機会が多くなりました。また、一部のOSSやセキュリティに関わるプロジェクトにおいて、リーダーとして関わるようになりましたリーダーとして関わるプロジェクトでは、進捗やタスクの管理に加えて、情報を一から収集・整理し、その結果をもとにステークホルダーと議論し、方針の決定や合意形成まで進める経験をしました。実際にやってみると、自分が関わっていない別プロジェクトをどこまで把握すべきか、どの観点まで見れば十分なのかといった判断を自分で下す必要があり、難しさを感じることも多くありました。それでも経験を重ねる中で、自分の担当範囲だけでなく、チーム全体の品質や進め方に目を向けられるようになってきました。その結果、リスクの共有や観点の補完といった形でチームに還元できている実感を持てるようになったのは、大きな変化だったと感じて

こんにちは！サイボウズ Office で QA エンジニアをしている、水谷（@dog_dog_3dog）です！今回は、新卒3年目を迎える3人のQA同期メンバーのリレーブログの2本目として、「仕事の変化はあるけれど、やってきたことはちゃんと力になっている」というテーマで書いてみようと思います。1年前には想像していなかった今の仕事3年目を迎えた今、私はグループウェア製品の中のLLM アプリの開発チームで、QA のリードとして働いています。今の自分だけを見ると、「もともと自動テストや API テストが得意だったのかな」と思われるかもしれません。LLM アプリの開発に携わることになることも、まして苦手意識のあった自動テストを集中的に実装することになるなんて、1年前の自分はまったく想像していませんでした。もともとはモバイルアプリの QA だった入社して最初に配属されたのは、サイボウズ Office モバイル（Android）の開発チームでした。1週間で 5〜6 機能ほど増えるようなスピード感だったので、毎週たくさんのテスト設計をして、モバイルアプリのテストに追われる毎日でした。とはいえ、1つ1つの機能は Web アプリの機能をモバイルで再現するものが多く、実装単位としては比較的細かいものでした。リファインメントが終われば、すぐにテスト設計をして、次の週には実装が終わり次第すぐにテストを実施する。慌ただしい日々ではありましたが、短期間で新機能のポイントをつかみ、テンポよくテスト設計、テスト実施を進めていく経験を重ねることで、QA としての基礎をしっかり積むことができた期間だったと感じています。そこから仕事が大きく変わったその後、自分の所属するチームで PoC として開発していた LLM 機能が製品に組み込まれることになりました。https://speakerdeck.com/cybozuinsideout/jasst2026tokyo_mizutaniそして今年の2月ごろからは、主務の QA メンバーが自分1人、兼務でサポートしてくださる QA が1人という体制の LLM アプリ開発チームに参画し、バックエンドで利用している gRPC のテストをひたすら書いています。API のインテグレーションテストはそれまでほとんど書いたことがありませんでしたが、Claude Code や

はじめにこんにちは、24卒のQAエンジニアの永田です。本記事は、同期3人での振り返りブログの1本目です。24卒のQAの3人は、それぞれ異なるプロダクトのチームに所属しているため、同じQAという職種であっても業務内容は少しずつ異なります。そんなざつだん会の中で、「入社して3年目が経った記念にブログを書こう！」という話になり、今回の記事を書くことになりました。サイボウズでは内定者アルバイトや入社1年目の振り返りブログが多く公開されていますが、また、先述の通り私たちはそれぞれ異なるチームに所属しているため、QAという職種の幅広さや面白さも感じていただけたら嬉しいです。新卒3年目の変化1年目と大きく変わった点は、所属チームのQAとしてリードしていく立場になったことです。チーム配属時に暖かく迎え入れてくださった先輩QAは、途中で他のチームへ異動されました。実際の業務の中でも、これまでどれだけ先輩に頼っていたのかを思い知らされる場面が多くありました。まだ胸を張って「アプリ設定のQAをリードしています」と言えるレベルではありませんが、着実に自信を持ってできることは増えてきたと感じています。スキル面でも、大きめのタスクから小さめのタスクまで幅広く取り組めるようになり、過去の経験を活かしながら、より漏れの少ない試験設計ができるようになってきました。E2E整理への取り組みE2E整理は、配属当初から取り組んでいるタスクです。背景として、テストケース数の増加により、実行時間の長期化や不安定テストの増加といった課題がありました。1年目は既存のテストケースの確認・整理が中心でしたが、2年目からはそれに加えて実装にも関わるようになりました。実装にあたっては、同じチームのSWEの方々に多くのご協力をいただきました。職種を超えて協力しながら品質を高めていくこうした取り組みは、サイボウズのカルチャーらしい部分だと感じています。これから3年目に入りますが、「チームや周りの人の役に立ちたい」という思いを軸に、これからも取り組んでいきたいと考えています。その思いを実現できるのであれば手段にこだわらず、技術的な領域からマネジメントまで、幅広く経験を積んでいきたいです。最近はAIの力もあり、これまでハードルが高いと感じていた技術的な領域にも挑戦しやすくなってきました。3年目も引き続き、チームに価値を出せるようコ

この記事は、2026年2月に開催された社内カンファレンス「開運冬まつり2026 Day1セッション」のQAエンジニアレーンで発表されたLTをブログ形式にして発信しているものです。2026春QAエンジニアリレーブログ、ついに最後の6本目の記事となります。こんにちは。kintone拡張基盤チームQAエンジニアのmassanです。拡張基盤チームではここ1年半ほど、チーム全員（EM・PdE・QA）でPBIのストーリーポイント（SP）を見積もっています。今回はその経緯、リファインメントでの会話の変化、効果についてお話しします。なんとなくで見積もっていた従来方針チームが立ち上がった当時はスクラムを厳密に取り入れるタイミングもなく、各自自分の見える範囲の作業を中心に見積もっていました。QAはチームに専任で所属しているためリファインメントにも参加していましたが、PBIについての話は検討の背景や仕様、実装面のやりとりが多めでした。QAも見積もりに参加するものの、実装部分をメインに見積もっている気がしてしまい、自分が担当しない作業の見積もりやテスト工数の扱いなどにやりづらさを感じていました。余談ですが、社内の開発チームごとでスクラムの取り入れ状況やリファインメントの進め方は多様です。私自身は以前リファインメントに出るもののQAは見積もりしない、というチームにいました。拡張基盤チームでは立ち上げ当時からチーム全員で見積もる方針を採用しており、やりづらさに気づくきっかけとなりました。テストを含むPBI全体のSPを見積もる方針に変更従来方針でのやりづらさをチームに共有し、改善を検討しました。QAが上流工程でどれくらい発言して良いのか、テストまでチームに考えさせることでより優先すべき懸念点を見落としてしまわないかなど悩みながらの相談でした。QAはQAの作業分だけを見積もって実装工数と足しあげる案もありましたが、結局スクラムの作法に従いリリースまでの全行程をチーム全員で見積もる方針で合意しました。話し合う中で各自の見積もり方針にばらつきがあることや、全体的にコミュニケーションを増やす余地があるということにも気づけました。これ以降はQAも実装部分を含めて見積もり、他メンバーも実装後の作業を見積もり、見積もりが出せない時はお互いに質問するようにしています。会話の変化見積もり方針の変更により、リファイ

インターンシップ/ロゴこんにちは！エンジニアインターン運営チームです。サイボウズでは毎年夏に、エンジニア向けのサマーインターンシップを開催しています。今年はフルリモートに加えて、対面のオフラインでも開催しますのでぜひ実際にサイボウズの雰囲気を体験しにきてみてください！どんなインターン？製品開発を行うチームに加えて、製品開発を支えるチームやプラットフォームに関わるコースなど、全14コースをご用意しています。課題や業務を通して、チームが実際に使っている環境を体験しながら、開発や現場の雰囲気に触れることができます。 社長と話す機会や、気になる社員を指名して1対1で話す時間など、コンテンツ以外の社員との交流も予定しています。サイボウズの風土や雰囲気をインターンを通して感じてみませんか？皆様からのエントリーをお待ちしております！募集詳細以下の日程で募集をしています。募集開始：4月6日(月)10:00募集締切：5月12日(火)23:59 エントリーはこちらから以下の特設サイトより各コースの詳細を確認できます。エントリーもここからできますので、興味のあるコースに応募してみてください！cybozu.co.jpコース一覧就業型・オンライン/対面など、働く環境に合わせた14コースを用意しています。kintone プロダクト開発（オンライン）kintone プロダクト開発（オフライン）kintone プロダクト開発（生成AI）kintone プラットフォーム開発（バックエンド）モバイル開発（iOS/Android - 実務型/育成型）クラウド基盤（Kubernetes基盤開発）クラウド基盤（自社基盤開発）生産性向上（AWS, CI/CDなど）プロダクトセキュリティQA待遇日当 15,000円 ~ 20,000円 （コースにより異なります。）対象2028年4月入社が可能な学生の方(学歴不問)日本国内でインターンに参加できる方参考情報昨年開催したコースごとに開催報告ブログも公開していますので参考にしてみてください。blog.cybozu.io皆さんのエントリーをお待ちしています！

こんにちは！26卒で新卒入社をしたQAエンジニアのまりケロんです。私は2025年9月〜2026年3月までの6ヶ月間、QAエンジニアとして内定者アルバイトをしていました。今回は、サイボウズのQAエンジニア内定者アルバイトでは何をするのか？私が何をしていたのか？を、その時々で感じた感情と共にお伝えできたらと思います！自己紹介QAエンジニア内定者アルバイト、どうやって始めた？kintoneの開発チームに参画しました本題！QAエンジニア内定者アルバイトでは何をする？タスク紹介kintoneについて学ぶ（2025年9月〜10月）QAの業務について学ぶ：初級編（11月）QAの業務について学ぶ：中級編（12月〜1月）QAの業務について学ぶ：上級編（2月〜3月）① メソッド系JSAPIの一例② イベント系JSAPIの一例タスク管理方法内定者アルバイトどうだった？業務面文化・環境面おわりに自己紹介話者がどんな人物か分かっていた方が読みやすいと思うので、簡単に自己紹介します。まりケロんプロフィール： 法学部卒、法科大学院を中退。法律を学んでいたので、理系ではありません。文系卒のQAエンジニア内定者がどんなタスクを経験し、何を感じたかという視点で読み進めていただけたらと思います！QAエンジニア内定者アルバイト、どうやって始めた？オファー面談の際に、人事の方からお話がありました。実業務を通じた実践的な経験こそが、QA業務への理解を深めるうえで最も効果的であると考えたため、その場で「やってみたいです！お願いします。」とお返事をしました。補足：内定者アルバイトの実施の有無は年度によって異なる場合があります。ご関心のある方は、人事の方にご相談ください。kintoneの開発チームに参画しましたサイボウズでは現在、フロントエンド刷新プロジェクトとしてkintoneをGoogle Closure ToolsというフレームワークからReactに移行しています。詳しくは以下の記事をご覧ください。blog.cybozu.ioその中でも、kintoneのアプリに関連する画面のReact化を行っている「ババロア」チームに、QAエンジニアとして参画することになりました。本題！QAエンジニア内定者アルバイトでは何をする？以下に、初日から最終日まで行った主なタスクを時系列順に並べてみました。半年経った今の自分が振り返

この記事は、開運冬まつり2026 Day1セッションのQAエンジニアレーンで発表されたLTをブログ形式にして発信しているものです。2026春QAエンジニアリレーブログの5本目の記事となります。こんにちは、サイボウズでQAエンジニアをしている森長です。グループウェア製品Garoonを担当するSpicaチームに所属しています。私たちのチームは新機能の開発はしておらず、テスト以外の観点でプロダクトの品質に貢献することをミッションとしています。具体的には、リリースプロセス改善、ドキュメント整備、不具合改修のハンドリングなどを担当しています。「Why を残しましょう」と言いながら、自分も忙しさに流されてサボってしまうことがあるので、自戒を込めてこの発表をしました。「なぜそうなっているのか」、分かりますか？コードや仕様書を見たとき、「何をしているか（What）」は書いてあるが、「なぜそうしたのか（Why）」が書いていない。 そんな経験はないでしょうか。Garoonは長年にわたって運用されてきた製品なので、「これは仕様ですか？それとも不具合ですか？」という問い合わせを頻繁に受けます。このような問い合わせに答えるのは私のチームの仕事です。その中で「Whyが残っていたら嬉しいのにな」と思うことがよくあります。日々おこなわれる「考古学」問い合わせを受けて仕様書やヘルプサイトを見れば、そこに書いてあることをもとに「仕様です」と答えられることも多いです。しかし私たちが大事にしているのは、「その仕様は今見ても正しいのか」を考えることです。仕様書に書いてあるから正しい、長年こうだったから正しい、ではなく、ユーザーにとって使いやすいか、今の観点から見て改善できないかを常に考えています。そのために、まるで考古学のように、以下のことをやっています。古い仕様書をさかのぼる過去のやりとりや議事録を掘り起こす類似機能や他社製品と比較するこれは、問い合わせの挙動を仕様であると明記しているところがあるかどうかを探すだけの調査ではありません。未来をより良くするために、手がかりになる過去の「Why」を探します。「なぜそうなっていたのか」が分かれば、「今もその理由は有効か」「変えるとしたら何を考慮すべきか」を議論できます。しかし時間をかけて調べても、当時の意図にたどり着けないことも珍しくありません。仕様書には「〜は

この記事は、2026年2月に開催された社内カンファレンス「開運冬まつり2026 Day1セッション」のQAエンジニアレーンで発表されたLTをブログ形式にして発信しているものです。2026春QAエンジニアリレーブログの、4本目の記事です。こんにちは！GaroonのQA（品質保証）エンジニアをしている福元です。普段はGaroonのTsukimi（インフラ移行）チームで、テスト設計・実施やテストマネジメントを担当しています。2022年に新卒入社し、今年で5年目になります。社内カンファレンスの1レーンとして、「テスト実施以外の、QAエンジニアの活動」というテーマでQAエンジニアによる発表がありました。そのレーンで、チーム配属後から約3年半コツコツ続けている「既存テストの改善活動」について発表したので、その内容をお話しします。「CI通してるんで、ちょっと待ってください！」チームに配属されてしばらく経った頃、開発中にこんなやり取りを何度も見かけました。「CI通してるんでちょっと待ってください！」「今月もリグレッションテスト（200ケース x 4環境）お願いします！」現在は各チームでテストコードの改善やテストケースの見直しが進み、こうした声は少しずつ減ってきていますが、当時はE2Eテストが不安定で、手動テストも過剰にある状態でした。「この分野には興味がある」「なんとなく解決案も思いつく」「空き時間もある」ということで、先輩のakihisa1210に相談し、個人タスクとして改善活動を始めました。取り組んだ内容は大きく3つです。既存テストの修正 ― 不安定なテストを直す既存テストの解体 ― やりすぎていたテストを見直す新規テストの作成 ― テスト構成のバランスを整える既存テストの修正 ― お祈りRerunからの脱却残念ですが、CIで失敗したテストのRerun成功を祈りながら繰り返しても、絶対に成功しないケースがあります。たとえば通知のE2Eテストでは、作成されたデータが環境に残るため、Rerunしてもデータの件数が合わず、その日はもう成功しません。ところが、失敗したテストのRerunではなくCIジョブの再実行や翌日の再実行では環境が作り直されるので成功します。すると「運が悪かっただけか」で済まされてしまい、誰もテストコードを修正していませんでした。こういった冪等に実行できないテストを

この記事は「開運冬まつり2026 Day1セッション」のQAエンジニアレーンで発表されたLTをブログ形式にして発信しているものです。2026春QAエンジニアリレーブログの、3本目の記事です。こんにちは！サイボウズでQAエンジニアをしている tagashira です！kintone システム管理/外部連携チームの機能開発のQAを担当しています。このたび、社内カンファレンスのセッション企画にて、各チームのQAエンジニアが「テスト実施以外の、QAエンジニアの活動」をテーマに発表を行う機会がありました。そこで私は「プロダクトエンジニア×QAエンジニアでもっと”一緒に”つくるリグレッションテスト」というテーマで発表したので、その内容を紹介します。目次機能開発の中で、どのようにリグレッションテストを作ってますか？これまでのリグレッションテストのつくりかた気になっていたこと「越境」してみよう！テストコードの実装をQAが担当してみる得られたもの -QAの視点から-実際にテスト実装をやってみてコードレビューを通じてテスト運用から得られたフィードバック得られたもの -チーム全体の視点から-得られた効果① テスト設計・実装の両プロセスで知識が共有されるように② リグレッションテストがPdE/QA両方の資産であるという実感を得られるように③ PdE/QA間でのリソースの融通が効くように高速化する開発と、リグレッションテストの必要性Coding Agent とテスト実装の落とし穴おわりに - 世は大 Coding Agent 時代！-機能開発の中で、どのようにリグレッションテストを作ってますか？これまでのリグレッションテストのつくりかたさっそくですが、みなさんのチームでは、日々の機能開発の中でリグレッションテストをどのように作っていますか？私の所属するチームでは、次のような作り方をしていました。テストケース設計：QAエンジニア（以下QA）、プロダクトエンジニア（以下PdE）テストケース実装：PdE が実装し、別の PdE がレビューこのような役割分担になっていたことにより、テストケースの設計/設計の見直しはQAの責任（※ただし、実装に備えて PdE も設計から関与する）テストコードの実装/メンテはPdEの責任という暗黙の了解が生まれていました。気になっていたこと上記の進め方をしていたことによ

この記事は、2026年2月に開催された社内カンファレンス「開運冬まつり2026 Day1セッション」のQAエンジニアレーンで発表されたLTをブログ形式にして発信しているものです。2026春QAエンジニアリレーブログの2本目の記事です。こんにちは！サイボウズでQA(品質保証)エンジニアをしているすずりん🦒です。2025年に新卒として入社しました。現在は、Garoonの品質にかかわる活動を担当するSpicaチームに所属し、社内外から報告された不具合の再現調査や不具合登録、リリースプロセスの改善に取り組んでいます。今回はリリースプロセス改善の一環として行った、リリースクライテリア（リリース基準）の見直しについてお話しします。製品の品質を考える際の参考になれば幸いです。目次 リリースクライテリアの課題リリースクライテリアの見直し1．リリースクライテリアの分類2.「CIが通っているかどうか」という項目の見直し改善活動から得られたこと・展望 リリースクライテリアの課題皆様はご自身の担当製品をリリースする際に守らなければいけない基準がありますか？それはどのような理由でつくられた基準なのでしょうか。Garoonをリリースするためには、社内に存在するリリースクライテリアを満たす必要があります。リリースクライテリアには、計8項目が含まれます。以下は項目の例です。取り込みたいPBIはすべて完了しているか開発中に見つかった不具合が修正されているか性能基準を満たしているかセキュリティテストが完了しているかCIは通っているかSpicaチームではこのリリースクライテリアを月に一度の定期リリースごとに定常業務として確認しています。確認作業はリリースの直前に行うため、リリースクライテリアが満たされないと緊急対応やリリースの中止が必要になることもあります。しかし、現行のリリースクライテリアは、「どの項目をどのように確認するか」の手順が書かれているだけで、「なぜその項目が品質のために満たされるべきなのか」がどこにも書かれていません。そのため、満たされない項目があった際、どのように対応していくかを決めるために時間がかかっていました。そこで、この改善活動では、リリース前に行う確認事項を整理することで確認にかかる時間を減らすことを最終目標としました。 本記事では、まず1つ目のステップとして行った、品質特性に...

こんにちは！QAエンジニアの小竹です。OfficeMobileチームでiOSアプリのQAとして働きつつ、QA外部コネクトチームの一員として他社エンジニアの皆さまとのつながりを生み出す活動に携わっています。本記事末尾でご紹介している資料もぜひご覧ください！）サイボウズは、2026年3月20日（金）に開催されたソフトウェアテストのシンポジウム JaSST'26 Tokyo にスポンサーとして協賛しました。会場でセッションにご参加下さった皆様、本当にありがとうございました。また、Discord上でもたくさんの方にリアクション／ご発言いただき、とても嬉しく思っています！この記事では、 JaSST'26 Tokyo でのサイボウズの発表内容をご紹介するとともに、発表に使用した資料を共有いたします。今回はスポンサーセッションに1名が登壇しました。LLMでもいつものテスト技術 〜意外と半分はこれまでのテストでした〜 speakerdeck.comこのセッションでは、新卒入社3年目にしてAI機能開発チームのQA業務をリードする水谷（@dog_dog_3dog）から、LLMアプリのテストについて、現場での経験を踏まえてリアルにレポートさせていただきました。発表を聞いてくださった皆様、Discordでの会話にご参加くださった皆様、本当にありがとうございました。登壇者からのコメントセッションを聴きに来てださったみなさん、ありがとうございました！LLMアプリの品質保証については、自分も正解がわかっているわけではなく、試行錯誤を繰り返しています。そんな自分の経験が少しでも参考になれば嬉しいです！※登壇の感想をZennでも公開していますので、よろしければあわせてご覧ください。zenn.devJaSST'26 Tokyo ファンミーティングを共同開催しました3月30日（月）にサイボウズ東京オフィスにて、スポンサーをはじめとする4社合同でアフターイベントを開催しました。JaSSTでの学びの機会をインプットで終わらせず、会社の垣根をこえて交流の輪を広げたり、気づきを共有したりする場を作りたいと思い、OSTを行いました。当日は定員近い30名弱が足を運んでくださり、用意していた12個の枠いっぱいにテーマが集まりました。実際に出たテーマ（一部抜粋）ホストからのテーマの説明を聞いてうんうんと唸る方、セッショ

こんにちは、フロントエンドエンジニアのmehm8128です。僕は25卒としてサイボウズに新卒入社し、内定者アルバイト時代も合わせると1年半なのですが、正社員としてはちょうど1年が経ちました。弊社1年目ではどんなことができるのかという参考に、書いてみました。フロントエンド基盤の刷新サイボウズのほとんどのフロントエンドエンジニアの多くは、主力製品であるkintoneのフロントエンド基盤の刷新プロジェクトに参加しています。普段は個人としてアクセシビリティに関する発信を多くしていることから、業務でもアクセシビリティ関連のことをメインでやっていると思われていることがあります。しかし実際には、フロントエンド全般に幅広く関わっています。今のkintoneの大部分は、Google Closure Toolsというフレームワークで作られています。しかしこれは2024年にEOLになったこともあり、今では「Google Closure Toolsといえばサイボウズ」と言えるくらい他で見ないものになってしまいました。そこでフロントエンド基盤の刷新プロジェクトでは、kintoneを全てReactに置き換えています。その中でも僕のいるチームはkintoneのアプリ機能という、kintoneの中でも最も基本的な機能の刷新を行っています。アプリ機能の画面では、ユーザーがシュシュっと作成したアプリに対してレコードを追加したり、そのレコードの一覧や詳細情報を閲覧したりすることができます。レコード一覧画面（開発中の画面）もう少し詳しい説明は過去の記事をご覧ください。blog.cybozu.ioblog.cybozu.io現在のチームのメンバー構成としては、EM1人、SWE5人（自分はここ）、QA2人となっています。多いときは内定者アルバイトメンバー含めてもう4人ほど所属していました。内定者アルバイトのメンバーを除くと自分は最年少ですが、フロントエンド基盤の刷新はやることが多く、かつなるべく最短で完了することが求められていることから、新卒1年目の自分でもタスク管理や内定者アルバイトメンバーのサポートを行うことが多くあります。それ以外は、与えられたタスクやコードレビューをひたすらこなしたり、必要に応じて他チームとの連携を図ったりしています。ここからは具体的な業務内容をいくつか紹介していきます。インライン編集

この記事は、2026年2月に開催された社内カンファレンス「開運冬祭り2026 Day1セッション」のQAエンジニアレーンで発表されたLTをブログ形式にして発信しているものです。こんにちは！サイボウズのQAで1番優しいギャルを目指しているyuuki( @yuuki_cybozuQA )です。サイボウズ OfficeとメールワイズのQAを担当しながら、9月から新設された「QA外部コネクトチーム」で外部登壇推進や他社エンジニアの皆さまとのつながりを生み出す活動に挑戦しています。QAエンジニアが、自分の仕事の価値を自分の言葉で伝える時間を作りたい今回、社内カンファレンスのセッション企画にてQAエンジニアのレーンを主催しました。テーマは「テスト実施以外の、QAエンジニアの活動」とし、チームや年次が異なる6名がドキュメント管理、シフトレフト、テスト自動化など多岐にわたるテーマで発表を行いました。さまざまな職能が集まる開運冬祭りで、「QAエンジニアが、自分の仕事の価値を自分の言葉で伝える時間をつくりたい！」という思いから、半年間かけて企画を進めていきました。また、私が開運冬祭りの実行委員として運営をしていくなかで、QAエンジニアとしてもセッションを盛り上げたいという思いもありました。登壇テーマは「ギャルマインドを伝播して、もっと『つながる』モメンタムづくり！」私の発表では、ブログ発信や外部登壇など「社外に出ていく（つながる）活動」のモメンタムづくりについてお話しました。私は、外部活動での気づきをもとに社内にも良い循環をつくることや、技術コミュニティへの貢献をするために発足した「QA外部コネクトチーム」のリーダーを担当しています。QA職能を横断する「QA外部コネクトチーム」については過去の登壇でもお話しています。 speakerdeck.com私はこのQA外部コネクトチームで「ギャルマインド」を軸として活動をしており、発表では以下の3つのギャルマインド要素を紹介しました。① ポジティブに続ける「小さくても、長く続けていくことに価値がある」と思っています。人を相手に、成果に偶発的な要素も多い中で完璧にやろうとすることよりも、細くても続けることで積み重なるものを大切に「継続」をしていきます。無理をすると続けられないので、ポジティブに継続を絶やさないことが大切だと感じています。② 美学私

この記事は kintone の生成 AI チームで連載中の kintone AIリレーブログ 2026 の 11 本目の記事です。 リレーブログでは、生成 AI チームのメンバーが AI トピックに限らずさまざまなことについて発信していきます。こんにちは！kintone 生成 AI チームの 386jp です。以前の記事「cdk8s をもっと使いこなす - kintone AI チームの活用 Tips」にて、 Renovate で独自の YAML ファイルを使って、 Helm Chart やコンテナイメージのバージョン更新を行っている取り組みについて紹介しました。まだご覧になっていない方はぜひご覧ください。この記事では、そのときに活用した Custom Manager について、どういった設定で使っているのかを紹介します。Renovate の Custom Manager とはCustom Manager とは、依存関係の検出方法や更新方法をカスタマイズできる Renovate の機能です。これを使うことで、 Renovate が提供する標準的な更新方法では対応できないような、独自のルールや設定を実装することができます。よくある活用例としては、既存の Renovate ルールでは更新できないバージョン指定を、正規表現を用いて検出対象にしたり、標準のマネージャーが対応していない独自のファイル形式からバージョン情報を検出して更新したりすることが挙げられます。kintone 生成 AI チームでの活用方法以前の cdk8s の記事でも紹介した通り、 Helm Chart やコンテナイメージのバージョンを更新するために、 kintone 生成 AI チームでは Custom Manager を活用しています。例えば、生の Kubernetes マニフェスト (YAML)や、 Docker Compose の設定ファイル (compose.yml など)は、標準的な Renovate のルールを用いることで更新できますが、 cdk8s 上で管理している場合、 TypeScript や Python のコード内にバージョン情報が埋め込まれていると、標準的な Renovate のルールでは更新できません。そこで、 cdk8s を導入する際、 Helm Chart やコンテナイメー

こんにちは！サイボウズの開発広報チーム兼開運まつり実行委員長のhokatomo（@tomoko_and）です。社内テックカンファレンス「開運冬まつり」を開催しました。職能も拠点も違うエンジニアが、2日間の交流と対話を通じて、次への行動に繋げる場です。こうした場が自然と生まれ、改善しながら継続してきた過程にサイボウズの文化を感じています。この記事では、開運まつりそのものだけではなく、背景にあるサイボウズの文化について少しでも伝えられたらと思います。開運まつりとは-交流のきっかけと、新しい視点を持ち帰る場-開催概要この場が成立することが、私たちの文化多角的に関われる場作りセッションでは、いま考えていることを共有する場にOSTでは問いを持ち寄り、対話する参加者の声イベントが成熟してきたからこそ、運営での悩みおわりに開運まつりとは-交流のきっかけと、新しい視点を持ち帰る場-開運まつりは、サイボウズで開発・運用に関わる様々なチームや職能の人が集まり、セッションの聴講や体験型コンテンツ・懇親会・シャッフルランチ・Open Space Technology（以下OST）を通じて交流を深める、オフラインのお祭りです。2024年から始まり、これまで年2回夏と冬で開催、これで5回目の開催です。（前回夏開催時の記事）チームワークあふれる社会を目指しているサイボウズも、コミュニケーションに課題を感じています。これを解決する企画の一つが、開運まつりです。チームや職能の垣根を超えて交流することで、対話のきっかけや、新たな視点を得ることを目的にしています。サイボウズでは開発＆運用を担うエンジニアリンググループの総称として「開運」と呼んでいます。関連するメンバーが一堂に会するということで、開運まつりと命名しました。開催概要日付：2026年2月18、19日の合計2日間場所：サイボウズ東京オフィス開催形式：発表系のコンテンツはハイブリッド、それ以外の交流や対話メインのコンテンツはリアル開催のみコンテンツDay1：セッション（3トラック30テーマ）、懇親会Day2：シャッフルランチ、OST参加人数：オンライン含めて311名運営：実行委員10名、ボランティア16名この場が成立することが、私たちの文化開運まつりは、最初から大きなイベントとして計画されたものではありません。日々の開発や運用の中で生まれた「もっ

この記事は kintone 生成 AI チームで連載中の kintone AI リレーブログ 2026 の 10 本目の記事です。リレーブログでは生成 AI チームのメンバーが AI トピックに限らず、さまざまなことについて発信していきます。こんにちは！ kintone の生成 AI チームでソフトウェアエンジニアをやっている福田です。私たちのチームでは cdk8s を使って Kubernetes マニフェストを管理しています。（cdk8s の詳細は別の記事で紹介していますので、あわせてご覧ください。）cdk8s を使うと TypeScript でマニフェストが書けるだけでなく、Helm チャートと統合したマニフェスト管理も簡単に行うことができて非常に便利なのですが、YAML のマニフェスト生成に時間がかかることがチーム内でも問題になっていました。Kubernetes へのデプロイは、cdk8s で生成した YAML のマニフェストを apply するという方法で行っており、その生成に時間がかかってしまうと、開発のイテレーションが遅くなってしまいます。今回はマニフェスト生成が遅いという問題に対して、その原因の特定と解決方法の実装について共有します。何が遅かったのかcdk8s は TypeScript のコードを実行してマニフェストを生成する仕組みになっているため、コードを実行する際のプロファイルを取ることで、どの部分で時間がかかっているか特定できると考えました。Node.js には --prof オプションがあり、これを使うことで JavaScript のコードの実行時のプロファイルを取ることができます。私たちのプロジェクトでは TypeScript を使っているので、tsc で JavaScript にトランスパイルしてから Node.js で実行してプロファイルを取ることにしました。以下はプロファイリングの結果の抜粋です。 [Bottom up (heavy) profile]: ticks parent name 9129 88.6% epoll_pwait@@GLIBC_2.6 5439 59.6% JS: ~spawnSync node:internal/child_process:1105:19 3741 68.8% JS: ~spawnSync nod

こんにちは、OfficeMobileチームでQAエンジニアをしている小竹です。サイボウズは 2026年3月20日（金）に開催されるソフトウェアテストのシンポジウムJaSST'26 Tokyoにスポンサーとして協賛します。今回はスポンサーセッションに弊社のメンバーが登壇し、生成AIを組み込んだ製品のテストについてお話しする予定です。本記事ではこちらのセッション、およびJaSST'26 Tokyoの後に開催を予定しているアフターイベントについてご案内させてください。LLMでもいつものテスト技術 〜意外と半分はこれまでのテストでした〜日時3月20日（金） 14:25（J3-2） タイムテーブル登壇者水谷 太一 （@dog_dog_3dog​）内容紹介LLMアプリのテストについて知見がなく、どう進めるべきか悩んでいました。しかし、実際にリスク分析からテストスイートを積み上げると、テストの半分は従来型のシステムテストでした。AIもシステムの一部であり、品質保証のこれまでの考え方が十分通用しました。本セッションでは「従来のシステムテストで何を見たのか」、そして「LLM独自のテストをどう設計したのか」について、私たちのチームでの活動をお話しします。登壇者の水谷は、新卒入社3年目ながらAI機能開発チームのQA業務をリードし、外部発信にも熱心なメンバーです。現場での経験を踏まえたリアルなレポートにご期待ください。会場でチラシを配布しています！オフライン会場にて下記のチラシを配布しています。登壇情報や次回以降のイベント情報も掲載していますので、見かけたらぜひお手に取ってご覧ください。JaSST'26 Tokyo チラシアフターイベントを開催します！3/30（月）に、スポンサー4社合同でJaSST'26のアフターイベントを開催予定です！イベントは参加者主導のOST形式で、JaSSTで得た学びや感想をワイワイ語り合えるような場にしたいと考えています。「JaSSTの余韻をQA仲間と共有したい」という方は、ぜひふるってご参加ください。イベントの詳細・お申し込み方法は下記のページにてご確認ください。JaSST’26 ファンミーティング（Connpass イベント告知ページ）終わりにサイボウズでは「チームワークあふれる社会を創る」という企業理念のもと、kintoneやGaroon、サイボウズ Of