テクブロ — 技術ブログの新着まとめ

既読のみCybozu

34件

フィード

Cybozu·4日前

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
フロントエンド

Cybozu·4日前

JaSST'26 Tohoku 参加レポート

こんにちは！ 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エンジニア採用強化中！現在サイボウズでは、チームの一員として活躍していただけるQAエンジニアを募集しています。サイボウズの企業理念に共感いただけるQAエンジニアの皆様、私たちと一緒に働きませんか？募集要項は以下のページにてご確認いただけます。 cybozu.co.jp カジュアル面談も実施していますので、まずは話だけ聞いてみたい、という方もお気軽にお声がけください！カジュアル面談のお申し込みたくさんのご応募を楽しみにお待ちしています！

テスト
品質保証
生成AI

Cybozu·4日前

外部システムを kintone アプリとして使うためのアーキテクチャ紹介

はじめにはじめまして、開発本部 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 streaming RPC でサイボウズ側の Proxy から顧客側の Agent にリクエストを送信する Agent から Adapter にリクエストを送信する Adapter で外部システム固有の API 呼び出しに変換して API を呼び出すコンポーネント役割 kintone 外部システムのデータを kintone のアプリとして表示・操作する。 Proxy Agent からの outbound 接続を待ち受ける。接続後は kintone からのリクエストを Agent に転送する。 Agent Proxy へ outbound 接続する。Proxy からのリクエストを Adapter に送信する。 Adapter Agent からのリクエストを外部システム固有の API 呼び出しに変換する。外部システム Adapter からの API 呼び出しを受け付ける。顧客が運用している業務システムなど。この仕組みによって、kintone からのリクエストを顧客側にある外部システムに送信することができます。 Agent と Adapter を分けているのは、外部システムごとに異なる API の差異を Adapter に閉じ込めて、 Agent を共通基盤として切り出すためです。Agent は kintone との通信を担う共通部品としてサイボウズが提供し、外部システム固有の変換ロジックだけを Adapter として顧客が開発します。この責務の分割により、外部システムによって Agent 側に変更は原則不要になります。通信方式の比較 Agent - Proxy 間の双方向通信を実現する方式として、今回は最終的に gRPC の Bidirectional streaming RPC を採用しました。他にもいくつか検討した方式があるため、以下で各方式のメリット・デメリットを詳しく見ていきます。 Bidirectional streaming RPC 今回採用した gRPC の Bidirectional streaming RPC は、HTTP/2 上で双方向ストリーミングを行う通信方式です。一度接続を確立すると、kintone からのリクエストと外部システムからの応答の両方を流せるため、Agent からの outbound 接続一本で双方向通信が成立します。メリット Protocol Buffers によるスキーマ駆動開発が可能 gRPC を採用することで Protocol Buffers のエコシステムを活用できる。メッセージの仕様を .proto で厳密に定義し、そこから各言語のクライアントコードを生成して SDK として配布できる。これにより、Adapter を開発する顧客は型安全に実装を進められる。バイナリプロトコルで効率が良い JSON 等のテキスト形式に比べてペイロードが小さく、Agent - Proxy 間の通信コストを抑えられる。社内に知見があるサイボウズ社内で gRPC を採用しているプロダクトが複数あり、障害対応や運用ノウハウを活かせる。デメリット顧客に Adapter の開発負担が生じる gRPC のリクエストを外部システム固有の API 呼び出しに変換する Adapter を、顧客側で開発・運用してもらう必要がある。 SOCKS over SSH SSH のリモートポートフォワーディング（ssh -R）を使い、Agent 側の OpenSSH プロセスを SOCKS5 プロキシとして振る舞わせる方式です。 SOCKS5 は指定された宛先への任意の TCP 接続を中継することができるプロキシで、RFC1928 で定義されています。SSH トンネルと組み合わせることで、通信を暗号化しつつプライベートなシステムへのアクセスを可能にします。これは Grafana Cloud の Private Data Source Connect (PDC) で採用されている手法で、Grafana Cloud からプライベートネットワーク内のデータソースへ接続するために使われています。仮にこの方式をサポートした場合は以下のようなアーキテクチャになると想定しています。 SOCKS over SSH を採用した場合のアーキテクチャ Agent が ssh -R オプション（リモートポートフォワーディング）で Proxy に SSH 接続し、Proxy 側にポートを開く kintone から Proxy にリクエストを送信する Proxy が 1. で開いたポートに SOCKS クライアントとして接続する。この通信は SSH トンネルを通って Agent に届く（SOCKS over SSH） Agent の ssh プロセスが SOCKS を終端し、SOCKS リクエストで指定された宛先（外部システム）に TCP 接続してリクエストを転送するメリット顧客が Adapter を開発する必要がない Agent は L4 の TCP 転送をそのまま中継するだけなので、外部システムごとの変換コンポーネントを顧客が用意しなくてよい。デメリット外部システムごとの差異を kintone 側で吸収することになる SOCKS は L4 の TCP 転送しか行わないため、kintone が外部システムの API を直接呼び出すことになる。Grafana のように接続先が標準的なプロトコル（SQL など）であれば成立するが、顧客固有の業務システムが対象の場合は、システムごとの変換ロジックをサイボウズが用意し続けることになり、運用コストが大きい。開発チームでの SSH サーバーの運用経験が乏しいサイボウズ側で SSH サーバーを運用することになるが、障害発生時の対応に不安が残る。 WebSocket HTTP の Upgrade を使い、1本の TCP 接続の上で双方向のメッセージをやり取りする方式です。メリットシンプルで広くサポートされている多くの言語・ミドルウェアが標準で対応しており、双方向通信を比較的少ない実装で実現できる。デメリットスキーマ駆動の型安全性が標準では得られない WebSocket 自体はフレーミングまでしか規定しないため、メッセージのスキーマ定義は自前で設計することになる。サーバー間通信では WebSocket の強みを発揮できない WebSocket の最大の利点はブラウザが標準 API として備えている点にあるが、Agent - Proxy 間にブラウザは介在しないため、その恩恵を受けられない。まとめ「外部システムのデータを kintone で扱う」という一見シンプルな機能ですが、エンタープライズ事業者のセキュリティ要件と折り合うために、通信の向きを逆にするというアプローチを取りました。こうした制約と向き合いながらシステムを設計することは、エンジニアとしてやりがいがあると思います。サイボウズでは今プロダクトエンジニアの仲間を増やしているところなので、こうした課題と向き合うプロダクト開発に興味がある方は、ぜひ下記のリンクからご応募ください。 cybozu.co.jp

kintone
gRPC
システム構成
ネットワーク
セキュリティ

Cybozu·2026/06/05

Java 初学者にこそ JJUG CCC への参加を勧めたい - JJUG CCC 2026 Spring 参加レポート

はじめにはじめまして、開発本部 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.com Modular Monolith Locally, Microservices in Production マイクロサービスはローカル開発では立ち上げづらい、サービスを跨いだデバッグがしづらいという課題があり、それを解決するアプローチを解説していました。ローカル開発環境では1プロセスの中で各種サービスを立ち上げてモジュラーモノリスとして振る舞い、本番環境ではマイクロサービスとして振る舞う、というもので面白いアプローチでした。 www.docswell.com 肥大化するレガシーコードに立ち向かうためのインターフェース分離と依存の逆転こちらのセッションは弊社の前田さんによる発表で、 kintone のレガシーコードを改善した話になります。具体的には、 Web に公開しているインターフェースを Controller 層からより内側の Service 層でも利用することで、RecordData という複雑なクラスへの依存を解消していきました。この改善活動があったからこそ、いま現在自分たちがスムーズに開発を進められているんだと実感する内容でした。長年続いているプロダクトを開発している人にとって面白い内容だと思うので、詳しくは以下の資料をご覧ください。 speakerdeck.com 大規模なメトリクス収集の仕組みをアーキテクチャ変更して得た学びこちらも弊社の谷さんによる発表です。 kintone の性能ダッシュボードを開発するにあたって、初期段階では価値検証のためコストの低い実装を行い、実際に価値があるとわかった段階でスケーラビリティを考慮してアーキテクチャを見直して設計した、という内容でした。価値を最速で届けるためのアプローチとして、最初から完璧なものを作る必要はない、というのはシステム設計の時に考えるべきポイントの1つだと感じました。 www.docswell.com Inside Stream API Java の Stream API の内部実装をみていく話でした。仕組みがどうなっているのかを知るのが好きなので聴きにいったのですが、全てを理解するのは難しいセッションでした。しかし、OpenJDK のソースコードを読みたい欲が高まったので、聴きにいってよかったと思います。 speakerdeck.com なぜJavaのジェネリクスには「PECS原則」が必要なのか？ - Scala/Kotlinと比較して理解するワイルドカードの設計思想 Java のジェネリクスを学んだ時に PECS（Producer Extends Consumer Super）という言葉が何度か出てきたのですが、実は今までしっくりきていませんでした。このセッションを聴いてようやく PECS が何を意味しているのかが分かり、 <? extends T> や <? super T> が理解できるようになりました。また、 Kotlin はこれらを out/in で表現することができ、違反した使い方をしようとするとコンパイラで検知してエラーになるという点は便利だなと思いました。 www.docswell.com switch式で始めるJava流パターンマッチング Java 21 から導入されたパターンマッチングに関する解説になります。まだパターンマッチングに慣れていないので、改めて勉強になりました。 www.docswell.com Javaコミュニティをもっと楽しむための9箇条 Java 初学者にはとても助かる内容でした。そもそも JJUG ってなに？というところから、日本にどういう Java コミュニティがあるのか、もっと Java コミュニティを楽しむにはどうすると良いのかを知ることができました。 speakerdeck.com Javaコミュニティの関心の変遷を可視化する：JJUG CCC 発表データから見る変化と不変これまで JJUG CCC でどういう内容の発表が行われてきたのかをデータ分析して解説していました。なんとなくこういうテーマが多い、というものではなく、しっかりと定量的に分析しているところが非常に面白かったです。 speakerdeck.com LT すべてのセッションが終わった後に参加者交流会兼 LT大会がありました。想像していた以上にテンションの高い LT 大会で驚きでした。 LT の中では絵文字の話が印象に残りました。 Java 21 では Character.isEmoji('🤧') が false を返すなど、なぜそんな仕様になっているのか、と突っ込みたくなるような内容からスタートしていて面白かったです。 yuji.software また、自分も LT で登壇しました。 Java の経験は浅いですが、 ./gradlew build の仕組みを調べて整理して話すことができたのでよかったです。 www.docswell.com まとめ JJUG CCC に参加してみて、初学者でも楽しめる場だと分かりました。参加する前までは難しい内容なのかな、と思っていて少しハードルがあったのですが、実際には初学者向けのセッションもあり、非常に勉強になりました。自分にはまだまだだから、と思っている方にこそ JJUG CCC への参加をお勧めしたいです。この記事が参加のきっかけになれば幸いです。

Java
Gradle
カンファレンス

Cybozu·2026/06/01

W3C Japan 30年の軌跡、そして次世代へ：村井先生×青野社長が問う、日本が人類に果たすべき役割とは？

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: もともと情報システム工学科出身で、子どもの頃からコンピューター少年で、コンピューター触るのが大好きで、というのが僕のもともとのスタートです。 A: そんな中サイボウズを作って、今 1,400 名くらいの規模になりました。 A: で、これお恥ずかしいんですけど、僕らの業績です。サイボウズの歩み A: 一部では「サイボウズってずっと順風満帆に成長してきたんじゃない？」って言われることもあるんですが、もうとんでもない話でして。 A: 2011 年の「クラウド」がなければ、本当に成長が止まってた可能性があります。 A: 停滞期にクラウドというテクノロジーがきて、毎月サブスクリプション課金ができるようになったと。 A: このビジネスモデルの転換で、ようやく成長できるようになったというのが僕たちです。 A: これがサイボウズ Office という、僕らが作ったグループウェアの初期バージョンですね。初期の「サイボウズOffice」 M: いやー、覚えてる覚えてる。 A: おお、ありがとうございます！ A: もうブラウザがすごいでしょ？若い人、知らないでしょ？ Netscape 。当時はこれが、シェア 96%とかだったんですよね。 A: で、これを見たときに僕は感動をしまして。 A: 当時僕はパナソニック(旧松下電工)だったんですけど、ぜんぜんコンピュータがわからない人、マウスを持つ手が震えるような人を相手にしてたんですが A: どうやったら、この人たちにコンピュータを便利に使ってもらえるようになるかを、ずっと考えてました。 A: で、何とかみんな E メールが使えるようになりました、ワープロも使えるようになりました。 A: 次は？って思ったときに Web が出てきて、これスゴイじゃんと。 A: このインターフェースなら、人でも絶対いけるわと。 A: で、近くにいた課長を捕まえてですね、ブラウザを渡して、ちょっと好きなように使ってくださいって言ったら、釣り情報を検索して、今度の週末はあそこで釣れるみたいなのを、調べはじめたんですけど。 A: スゴイなと。 A: このインターフェースで何か仕事で使えるものを、と思ったときに、まさに近くにあるホワイトボードですよね。 A: みんなが行き先やスケジュールを書いたり、紙を貼ったりしてたやつ、あれを Web に置き換えれば生産性がぐっと上がる。 A: 遠くから電話かけなくても、お互い情報共有できる。そういう世界を作りたくて、勢い余って会社をやめて作ったというのが、このサイボウズになります。 A: そこから時は流れまして、今や kintone というのが僕らの主力商品になっています。 A: クリックするだけの Web から、今やヌルヌル動かせるようになったので、これを使って、誰でもシステムが作れるようになるんじゃないかと。 kintoneシステム開発を民主化する「ノーコード開発基盤」 A: 全くプログラム分からない人でも、データベースなどが作れて便利になる時代をイメージして作ったのが、この kintone になります。クラウドと API A: さらに、僕がクラウドのすごいと思っているところは "API" ですね。 A: システムがデータセンター側に行っただけではなく、そこに REST のような API が当たり前に備わるようになったので、データがシステムを超えて当たり前に繋がるようになった。 A: ハイパーテキストの時代は、テキストが繋がったわけですが、認証も含めて Web がシステムとして繋がっていくような世界が広がってきて、これでまたジャンプアップしたなと感じています。 A: なので kintone は単体で使うというより、いろんなシステムと連携/拡張して使って頂いてます。 A: そして去年、ついに W3C に加入させて頂きました。 2025年4月 W3C会員企業加入 A: 僕らは業務で使う Web を専門に実践してきましたので、その辺りで我々ができることに貢献できればと思っております。 A: Web の進化とともに、みんなが楽しく働ける社会を作っていきたいと思っております。 A: 以上です。 M: はい、ありがとうございました。拍手 Web にスケジューラが無かった？ M: 最初のところ懐かしいよね。 M: あの頃僕も実はね、 WIDE のメンバーに賞金つけたことあるんですよ。 A: そうなんですか？ M: 当時カレンダーソフトみたいなのはあったんだけど、スケジュールが調整できなくて、みんなで働けるようになってなかったんだよね。 M: パソコンのスケジューラは、システム手帳の延長だから、カレンダーも一人で管理するもので。 M: ところが私はその頃から、スケジュールを秘書に任せるようになった。それを WIDE の人と共有できないから、一緒に働くことができるカレンダーを誰か作ってよって呼びかけて。 M: 80 年代の終わりに、自腹切って賞金つけるから、みんな書いてくれってやったけど、ちょっとうまく行かなかったですね。 A: ああ、そうでしたか。 M: それでサイボウズが出てきて、よしこれだ！サイボウズ！グループウェアやってるな！と。 M: 青野さんたちはもう、インターネットのストーリーにビジネスを見てた。 M: これでやっと仕事ができると思ったけど、そもそもアカデミアって、そういう仕事のスタイルじゃないんだよね。 M: 僕らはインターネットを作ってきて、最初はずっと大学を繋いできたわけ。 M: ところが、さっきおっしゃったように人が使うようになってくると、人間の生活や仕事にインターネットの環境が貢献できるようになってくる。 M: 日本で最初の Web は、確か天体の写真のサイトだったんだけどさ。 M: そうやって Web を使い始める人が現れて、面白いなと思って。繋いで動かしてっていうのが、インターネット黎明期だったけど。議論するお二人 M: 人間のために、仕事のために、そういう発想でインターネットを使ってくれる人が出てきたのが、めちゃくちゃ嬉しかったんだよね。 A: あー、そういう視点で捉えてくださったんですか。 M: めちゃくちゃありがたかったですね。 M: 人に使ってほしい、そのためにインターネット作ってるんだけど、本当にそれを使って、しかもビジネスに役立ててくれるっていうのは、めちゃくちゃありがたくて。 Web のマネタイズ M: ところが Yahoo! を作った Jerry Yang は、どうやったらインターネットでビジネスができるか、いつも悩んでたんだよね。 M: Yahoo! ですらそこで悩んでた。 M: ちょうどその頃、Sun Microsystems がリレハンメルオリンピックの Web ページ作ったんですよ。そうすると世界中からアクセスが来たのね。 M: そこで、これは何かビジネスチャンスなんじゃないかと気がついて、それで Yahoo! は、広告モデルのビジネスを始めるんですよ。 M: 何か Web がアクセスするとか、あるいは元を辿れば FTP で接続するとか、それをどうビジネスに繋げるかみんな悩んでたんだよね。 M: FTP で取ってくるのに課金してるわけでも、会員制でもないしさ。Web ページ立ち上げても課金する方法がないし、じゃあどうしようって言ってたときに、広告でいけるかもしれないと彼は思ったんだよね。 M: 実はラジオ放送ができた時も、最初は「みんなに聞こえちゃうオルゴールみたいなものには、絶対に投資効果はない」と言われて、1800 何年に、一度リジェクトされてるんだよね。そこに、広告を付けてビジネスとして蘇った。 M: インターネットがビジネスのために役に立って、ビジネスを効率化させるみたいなことを、少なくとも日本で最初に始めた青野さんはすごいなと思ったよ。 A: いえいえ、見ていただいたとおり、全然もうずーっとマネタイズで苦戦して伸び悩んでましたから。 M: まあでも最近はすごい伸びてるから、見せていただいてよかったです。 A: そういう意味では Netscape ちょっと映しましたけど、あそこもブラウザを最初は売ろうとしてたけど、ブラウザを売るっていうビジネスモデルは、結局のところ成立するのは難しかったんですよね。 A: 確か 6000~7000 円くらいで売ってたんですけど、シェアを取りに無料のやつが出てきた瞬間に、ビジネスとして成立しないので。 A: ほんと Web とマネタイズっていうのは、いろんなところがチャレンジしながら、上手くいかないのを乗り越えながら今に至るっていうね。 A: この辺も、知っといて頂きたいなと思いますね。ビジネスと標準化 M: 一方ね、ビジネスっていうのは「競争領域」で、W3C みたいな標準化っていうのはいわば「協調領域」を作っていくっていうもので M: インターネットも標準化と、知財やビジネスとの競争との継ぎ目があって M: ビジネスだと普通は、標準化とか協調とか、みんなでオープンにするとか、そういう発想ってあんまり取り組めなくて。 M: だからこういう標準化の組織にみんな来て共有しようよって言っても、なかなか出しそびれる。あるいは会社のアドミニストレーションを説得するのが難しいとかね。 M: そういう悩みってあるんですけど、それについてはどう思いますか？ A: いやー、それはもう常にせめぎ合いじゃないですかね。企業としては技術は独占したい。良いものを思いつけば囲いたい。それによって利益を確保したいがありますけど。 A: それを行き過ぎると今度そこは排除されて、オープンなものに流れていくのも、僕は何かせめぎ合いをずっとやってるイメージがありますけどね。 A: 僕はよく OS で表現するんですけど、Windows はインターネットが出てきた頃に圧勝したんですよね。 A: Windows95 がインターネットブラウザをつけた瞬間に、世の中のパソコンの 95% が Windows になっちゃって。これ OS の市場終わったと思ったんだけど。 A: 今そんなことないじゃないですか。 A: 今サーバーは Linux がほとんどだし、スマートフォンだって今や Windows のスマートフォンなんてほぼ無いわけだし。 A: なので、せめぎ合い。独占とオープンとが常にしのぎを削っているくらいの状況に、均衡を作るのが大事かなと。 A: どっちかが勝ち過ぎちゃうと、よろしくないんじゃないかなと思ったりします。 M: その話は歴史的には何度も繰り返していて、僕も IETF で同じような経験をしていて。 M: プラットフォームとしてこれ作ろうよって言ったら「いや、これ僕の知財だから共有したくない」って言われて。 M: しょうがないから「じゃあ、みんなで作ろう」って言って。だんだんそれができて、出来が良さそうだなとなると「出そうかな？」って言い出した事件っていうのがあるんですよ。 M: 会社名は言えませんけど、あるネットワークルータを作っていた会社に Shortest Path First のアルゴリズムがあって。でも「出さない」って言ってたんですよ。 M: かわりに「これでみんなでやろう」って言って作ったら、それなりのモノが出来て。頭に "Open" の "O" を付けようってことを決めたんです。 M: それで "OSPF(Open Shortest Path First)" っていうのができたんだけど、そしたらその会社が「出す」って言い出して。 A: はい。 M: やってた人らは、目に涙を浮かべて怒ってたことを覚えてるんですけど。「じゃあ最初から出せよな」みたいな。 M: そういうせめぎ合いっていうのは、その後もずっとあるわけですよね。オープン vs ビジネス M: ここで、俺たちのプロダクトはすごく価値があって、これで儲けるんだぞって言ってたものを、オープンに標準化できるタイミングってどこにあるんですかね？ A: い

W3C
kintone
ノーコード

Cybozu·2026/05/29

Google I/O 2026 現地参加レポート

はじめにこんにちは！デザインテクノロジストをしている 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 にフォーカスして参加してきました。現地参加 Overview Pre-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 チームのパーティーに行ってきました。 I/O 中ではしっかりできないようなディスカッションができて、想像もしていなかったとても貴重な時間となりました。こうした偶発的な機会や会話に恵まれるところも、現地参加の意義だとしみじみ感じます。 Chrome チームのパーティーに参加して、会話をしている I/O Day1 待ちに待った Google I/O 1日目は、AM 10:00~ の Keynote からキックオフです！道路の混雑が予想されたので、ホテルの朝食をスキップして早めに到着します。Amphitheatre と I/O パネルが見えたときは、流石に「いよいよ！」という感じがして気持ちが高まりました😆 セキュリティチェックを通って中へ。長蛇の列の奥に I/O のサインが見える Keynote の列に並んでいる間に、用意されていた軽食をいただけます。そんなこんなで、CEO Sundar Pichai の登場から始まる Keynote で I/O 2026 がキックオフ！配信で見てた世界が目の前に現れて、感動がすごかったです！Search & Antigravity は色んな意味で結構面白いなと思いました。 Google I/O 2026: Sundar Pichai’s opening keynote CEO Sunder Pichai 登場の瞬間 Google Keynote のあとは、Developer Keynote。ここでは各領域の開発者にフォーカスした主要トピックが扱われます。全体を通して、主に Antigravity と各領域のその他 AI 関連の機能が feature されている印象を受けました。個人的には、 Antigravity が今年はどのくらい浸透し、開発者市場に影響していくのかが気になるところです。 Developer Keynote 15 updates from Google I/O 2026: Powering the agentic web with new capabilities, tools, and features in Chrome | Blog | Chrome for Developers 15 updates from Google I/O 2026: Powering the agentic web with new capabilities, tools, and features in Chrome | Blog | Chrome for Developers 17 Things to know for Android developers at Google I/O! | Android Developers' Blog https://developer.android.com/blog/posts/17-things-to-know-for-android-developers-at-google-i-o WebMCP | AI on Chrome | Chrome for Developers https://developer.chrome.com/docs/ai/webmcp Modern Web Guidance | Chrome for Developers https://developer.chrome.com/docs/modern-web-guidance Chrome DevTools for agents | Chrome for Developers https://developer.chrome.com/docs/devtools/agents I/O ではランチの提供があります。また、会場にはスナックやフルーツ、ドリンクのカートが常にあって、手ぶらで行っても食べ物には困らないと思います！ Snack Bar のカートが常時出回っている多くの種類のランチボックスが用意されており、好きに選べるそのあとはテントを回りながら午後のセッションをいくつか聴きます。こんな感じで Chrome, Cloud, AI, Android のテント, AI Sandbox などがあり、それぞれの demo を体験できたり Googler とキャッチアップができたりします。未公開製品を扱う AI Sandbox は waitlist 制で、順番が来ても中で 1時間くらい待つそうです。テントではディスカッションができる AI Sandbox 他にも、Nano Banana を用いたプリクラブースや、AI で生成されたラテアートを披露するブースなど、趣向が凝らされた出展でテーマパークのように飽きることなく過ごせます。 <figure class="figure-image figure-image

Android
Flutter
Web
生成AI

Cybozu·2026/05/26

TSKaigiにゴールドスポンサーとして協賛し、ブースを出展しました

こんにちは、フロントエンドエンジニアのmehm8128です。好きなユーティリティ型はReturnTypeです。 2026年5月22、23日に行われたTSKaigi 2026にて、サイボウズはゴールドスポンサーとして協賛し、ブースを出展しました。当日の様子を紹介します。ブースサイボウズのブースでは、「サイボウズのフロントエンドの印象を教えてください！」および「サイボウズエンジニア社員が何でも話します！！」の2つの企画を行っていました。前者は付箋を貼ってもらう形式、後者は付箋を貼ってもらうか、既に貼ってある付箋の中から気になるトピックを選ぶ形式でした。答えてくれた方には以下のようなノベルティをお渡ししていました（参加者の方のポストの画像をお借りしています🙏）。よく出ていた話題をいくつか紹介します。サイボウズエンジニア社員が何でも話します！！最近行っているプロジェクトの話として、フロントエンド基盤の刷新に興味を持っていただいている方が多かったです。 kintoneは現在、Google Closure ToolsからReactへと移行しており、その過程でJavaScriptからTypeScriptへの移行もしています。フロントエンド基盤の刷新については、以下のスライドを併せてご覧ください。 speakerdeck.com また、組織でのAI活用についても質問が多くありました。 kintoneのフロントエンドにおけるAI活用については、以下の記事をご覧ください。 blog.cybozu.io zenn.dev サイボウズのフロントエンドの印象を教えてください！サイボウズのフロントエンドと言いつつ、サイボウズ全体の印象でも可としていたところ、ちょうど前日にプレスリリースが出ていたコーポレートロゴのアップデートの件を挙げてくださる方が多くいました。今回のノベルティやパネルではロゴのアップデートは間に合わなかったのですが、次回以降は新しくしていければと思います。他に、W3CやWeb標準関連のイメージがあるという方も多くいました。僕が発案・企画して半年以上続いているWeb標準動向を読んでくださっている方が多く、嬉しかったです。今回はW3Cとサイボウズのロゴを並べたパネルを設置したり、W3Cの新ロゴのステッカーを配布したりしていました。今後もW3CやWeb標準周りの取り組みを行い、発信も行っていく予定なので、ご注目ください。 Web標準動向に限らず、Frontend WeeklyやFrontend Monthly、サイボウズフロントエンド通信などの発信活動についても知ってくれている方が多くいました。また、OSSについての言及もいくつかありました。サイボウズはいくつかのパッケージをGitHubのOrganizationでOSSとして公開していたり、OSSへの寄付を行ったりしています。少し前に僕が中心となって動き、フロントエンド周りのOSSへの追加寄付も開始しました。下記のOSSに、新しく寄付しました！mise, pnpm, Vitest, Tanstack, open-web-docs, dnd-kit, HonoサイボウズのOSSポリシーや、OSS推進チーム（OSPO）については、https://t.co/29matndLKR をご覧ください。#CybozuTech— Cybozu Inside Out (@cybozuinsideout) 2026年3月24日その他OSSポリシーの公開なども行っています。アクセシビリティについても挙げてくださる方が多かったイメージです。 kintone Design Systemや、前述の新コーポレートロゴのアクセシビリティ上の考慮の話の印象が強いようです。個人的にも最近ウェブアクセシビリティ基盤委員会（WAIC）にてサイボウズメンバーはこんな活動をしています - Cybozu Inside Out | サイボウズエンジニアのブログという記事を出したりと、アクセシビリティ周りの発信を行っています。業務に残された「良くない型」で考える「TypeScriptの難しさ」弊社のSajiさんが「業務に残された『良くない型』で考える『TypeScriptの難しさ』」というタイトルで登壇しました。 speakerdeck.com kintoneの実際のコードベースに残ってしまっている@ts-ignoreや@ts-expect-error、asキャストなどをAIで分析し、7つの頻出パターンを紹介するというものでした。それらのパターンに対して解決策を紹介し、今後より型安全なコードが書けるようになるセッションでした。僕はSajiさんと同じチームということもあり、事前にいくつか一緒に案出しをしていました。複雑なロジックが多いとどうしても型が複雑になりがちですが、型ガードをちゃんと書くとか定期的に棚卸しするとか、工夫できるところは残っているので、今後より堅牢なシステムを構築していきたいです。また、型以外にもkintoneの複雑なドメインロジックによる苦しみはたくさんあるので、どこかで紹介できればと思います。気になったセッション Oxlintはいかにしてtsgolintのlint ruleを呼び出しているのか | TSKaigi 2026 次世代リンターで探る、tsgo 時代における型認識カスタムルールの現実解 | TSKaigi 2026 静的解析への投資がAI時代のコード品質を支える ── カスタムESLintルールの設計と運用 | TSKaigi 2026 今回はOxlintやlinter系のセッションが多かった印象で、上に挙げた2つ以外にもいくつかありました。僕が最近個人的にOxlintのアクセシビリティのルールにcontributeしていることもあり、今回はこれらのセッションを楽しみにしていました。アクセシビリティのルールはtype-awareではなくてtsgolint側を触ったことはまだなかったので、内部構造など初めて知ることが多く面白かったです。 linterはAIコーディングのガードレールとして今後も必須のものとなっていくと考えているのですが、「静的解析への投資がAI時代のコード品質を支える ── カスタムESLintルールの設計と運用」のセッションにあったようなリポジトリ固有のルールの整備はあまりできていないことに気づきました。静的解析でできる範囲は限定されてしまいますが、今後自分たちのコードベースでもlinterのカスタムルールを作るという手段を視野に入れていきたいと思いました。また、サイボウズ社内でも最近ESLintからOxlintへの移行を検討し始めています。外部のプラグインなども含めて今後開発が進んでほしいなと思うし、自分でも貢献できる部分があればしていきたいと思います。おまけ当日企画として休憩室にマッサージのコーナーがあったのですが、弊社フロントエンドエンジニアのおぐえもんさんが受けていました。 <img src="https://cdn-ak.f.st-hatena.com/images/fotolife/c/cybozuinsideout/20260526/20260526170032.png" alt="マッサー&#x30B8

TypeScript
React
ESLint
アクセシビリティ

Cybozu·2026/05/22

サイボウズは JaSST'26 Tohoku で協賛＆登壇します！

こんにちは！ 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エンジニアの皆様、私たちと一緒に働きませんか？募集要項は以下のページにてご確認いただけます。 cybozu.co.jp カジュアル面談も実施していますので、まずは話だけ聞いてみたい、という方もお気軽にお声がけください！カジュアル面談のお申し込みたくさんのご応募を楽しみにお待ちしています！

テスト

Cybozu·2026/05/22

新卒社員向けアジャイル・スクラム研修を体験型で設計した話

こんにちは。 kintone開発チームのスクラムマスターをしている、とうま（@toma_cy）です。新卒社員6名に向けて、アジャイル・スクラム研修を企画・実施しました。研修の企画・運営は、私を含むスクラムマスター3人で担当しました。今回の研修では、午前にアジャイル・スクラムの概要を講義形式で学び、午後はチームに分かれてスクラムによる疑似プロジェクトに取り組みました。本記事では、研修プログラムをどのように設計していったのか、実際にやってみて得られた学びや課題について紹介します。アジャイル・スクラム研修を企画している方や、体験型ワークの設計を検討している方の参考になれば嬉しいです。なぜ体験型の研修にしたのかスクラムは、フレームワークとしての構造を理解すること自体は比較的容易です。スクラムにはどのような役割があるのか、どのようなイベントがあるのか。こうした内容は、講義でも説明できます。一方で、スクラムを実際に使いこなすことは簡単ではありません。スクラムを理解したつもりで現場に取り入れても、うまくいかないことがあります。よくある失敗のひとつが、フレームワークを守ること自体に意識が向きすぎてしまい、方法が目的化してしまうことです。たとえば、以下のような状態です。スクラムイベントを実施することが目的になってしまうスプリントレビューが成果物の進捗報告会になり、学びや方向修正につながらないレトロスペクティブをしているが、実際の改善につながらない本来スクラムは、チームで価値を届けるためのフレームワークです。そのため、単にスクラムの用語や流れを理解するだけでなく、実際にチームで悩み、判断し、フィードバックを受けて改善する体験を通じて学ぶことが重要だと考えました。今回の研修では、スクラムを「知っている」状態で終わらせず、短い時間でも「体験したことがある」状態に近づけることを目指しました。研修の全体像研修は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 午前の講義では、アイスブレイクに始まり、アジャイルの歴史的背景や概要、スクラムの目的や内容について扱いました。ただし、今回重視したのは、知識を細かく説明することではありません。午後のワークでスクラムの流れを体験できるよう、講義は必要な前提知識をそろえる位置づけにしました。またアイスブレイクでは、午後のワークで使うオンラインホワイトボードに軽く触れてもらい、ツール操作に慣れてもらう意図も含めました。オンライン研修でどうスクラムを体験してもらうか今回の研修はオンラインで実施しました。そのため、物理的な紙や付箋を使ってワークを行うことはできません。そこで、オンラインホワイトボードツールを使い、オンライン上で完結できる形式にしました。 ※今回の研修ではMiroを利用しました。午後のワークでは、まず疑似プロジェクトの背景や内容を確認してもらい、その後、以下の流れで進めてもらいました。バックログ整理・スプリントプランニングプロダクトバックログアイテムの作成・更新優先順位付けスプリントで扱うアイテムの決定プロトタイピングオンラインホワイトボード上で遊園地のレイアウトを作成スプリントレビュー成果物のデモ顧客からのフィードバックふりかえり次のスプリントに向けた改善アクションを出す ※ これを4スプリント分繰り返しました。ワークの題材午後のワークでは、架空の遊園地開発プロジェクトを題材にしました。参加者は、顧客企業から新規施設開発を依頼された設計会社のプロジェクトチームという設定です。顧客の要望をもとに施設の設計案を考え、4スプリントを通じてレビューと改善を繰り返します。題材として遊園地を選んだのは、実装を伴わなくても、体験や導線、施設構成を表現しやすいと考えたためです。なお、実際に研修で使った設定は、記事の最後に付録として載せています。研修プログラムもアジャイルに作る研修プログラムを作る際は、研修の中身だけでなく、作り方自体もアジャイルに進めることを意識しました。最初から完成度の高いプログラムを作ろうとしすぎると、設計に時間がかかり、実際に試して改善する時間が少なくなってしまいます。そこで今回は、まず簡単に研修プログラムの案を作り、すぐに自分たちで試してみることから始めました。まずはスクラムマスター3人で試す最初に、スクラムマスター3人で研修プログラム案を作り、自分たちで複数回試しました。実際に受講者役としてワークを回してみることで、資料を眺めているだけでは気づけない課題が見えてきます。たとえば、以下のような点です。オンライン上で迷わず作業できるか使用するツールの負荷が高すぎないかスプリントの時間は適切か題材は議論しやすいか優先順位を考える場面があるか顧客にとっての価値を考えるきっかけがあるか試した結果をもとに改良し、また試す。約2か月の準備期間の中で、プレ実施も含めて16回ほど打ち合わせや試行を重ね、研修プログラムを素早く形にしていきました。研修の題材としてスクラムを扱う以上、研修づくり自体も「作って、試して、学んで、改善する」進め方にできたのは良かった点です。若手メンバーにプレ実施に参加してもらう運営側だけで試した後、社内の若手メンバーに受講生役として参加してもらい、プレ実施を行いました。運営側だけで確認していると、「説明したつもり」「伝わるはず」という前提で見てしまう部分があります。そこで、新卒社員に近い目線で受けてもらい、講義のわかりにくさやワーク中に迷いやすいポイントを確認しました。プレ実施では、以下のようなフィードバックをもらいました。スクラムの良さを実感できた優先順位を考える大事さをリアルに体験できた楽しく取り組めた自分たちが必要だと思ったものが、顧客にとって本当に必要なものとは限らないと学べた実務でも役立てることができそう特に、「チームで考えたものが、必ずしも顧客にとって本当に必要なものとは限らない」と体験を通じて学んでもらえたことは、今回の研修で狙っていた学びのひとつでした。また、「実務でも役立てられそう」と感じてもらえたことは、運営側としても大きな自信につながりました。一方で、研修プログラムの改善点も見えてきました。たとえばスプリントレビューについては、「どのように振る舞えばよいのかわからない」というフィードバックがありました。そこで、午前の講義にスプリントレビューの目的をより丁寧に説明する資料を追加し、単なる進捗報告ではなく、成果物をもとにフィードバックを受け、次に何を学ぶかを考える場であることを伝えるようにしました。また、ふりかえりについても、不慣れな参加者にとっては何を話せばよいか迷いそうだという意見がありました。そのため、午後のワークでは、うまくいったこと、難しかったこと、次のスプリントで試したいことなど、話してほしい観点をアジェンダとして補足しました。プレ実施を通じて、研修の狙いが伝わっていることを確認できただけでなく、受講者がどこで迷うのかも具体的に把握できました。ワークに埋め込んだ学びの仕掛け今回の研修では、単にスクラムイベントを順番になぞるだけではなく、実務で起こりがちな状況を疑似的に体験できるように設計しました。特に意識したのは、スプリントレビューを「成果物を見せる場」で終わらせないことです。 3スプリント目で前提を揺さぶる要望を出す 3スプリント目のスプリントレビューでは、顧客役から前提を揺さぶるような要望を出すようにしました。いわゆる「ちゃぶ台返し」に近いフィードバックです。狙いは、参加者がその要望をそのまま受け取るのか、それとも「なぜその要望が必要なのか」を確認できるのかを見ることです。実務でも、顧客やステークホルダーから一見すると無茶に見える要望が出ることがあります。そのときに背景や目的を確認できれば、表面的な要望とは別の、より軽量な解決策を提案できるかもしれません。この仕掛けでは、顧客役にあらかじめ背景となる課題を設定しておきました。この体験を通じて、スプリントレビューが単なる進捗報告ではなく、顧客から学び、次の方向性を考える場であることを伝えたいと考えました。当日の様子当日は、午前の講義後、午後から2つのチームに分かれて疑似プロジェクトに取り組みました。ワークでは、架空の遊園地開発プロジェクトを題材に、各チームが設計案を考え、バックログを更新しながら、4スプリントを通じて提案内容を改善していきました。ワークを通じて生まれた学びワークの中では、チームごとに異なるつまずきや学びがありました。その中でも、特に印象的だった場面を2つ紹介します。小さく作って見せることの大切さあるチームは、スプリント1・スプリント2で、顧客に見せられる成果物をほとんど出せませんでした。そのチームは、計画や検討にしっかり時間を使っていました。一方で、スプリントレビューの時点では、顧客が確認できるものが少なかったため、顧客役として「まずは成果物を見たい」とフィードバックしました。その後、チームが実際に手を動かして作り始めると、思っていたよりもスムーズに形になっていきました。この出来事を通じて、計画を立てることは大切である一方で、計画に時間を使いすぎると、フィードバックを得るための材料が出せず、学びの機会も遅くなってしまうことを体験してもらえました。まずは小さく作って見せる。そして、顧客からの反応をもとに次の改善につなげる。このサイクルを実際に体験できたことは、今回の研修の大きな学びのひとつでした。顧客の要望の背景を探る難しさ別のチームでは、3スプリント目のレビューで、顧客役から前提を覆すような要望を受けました。前述の「ちゃぶ台返し」の仕掛けです。今回そのチームは、要望の背景を深掘りするよりも、まずは要望を受け入れて対応する方向に進みました。そのため、すべてのワーク終了後に「実は顧客には本質的に解決したい課題があった」という種明かしをしました。また、スプリントレビューでは成果物を見せるだけでなく、顧客の反応から学び、「なぜその要望が出てきたのか」を探ることも重要だと伝えました。同じワークに取り組んでいても、チームごとに異なるつまずきや学びが生まれました。こうした偶発的な学びが生まれるのは、体験型研修ならではだと感じています。新卒社員からのフィードバック研修後のアンケートでは、楽しく学べたというコメントがありました。とても面白い研修でした。全体として面白く学ぶことができました。体験型のワークにしたことで、前向きに取り組んでもらえたのは良かった点です。また、スクラムの流れを理解できただけでなく、自分の苦手分野や経験不足に気づけたという声もありました。スクラムの流れについて知ることができました。疑似的に体験することで、自分の苦手分野を把握できました。講義だけではなく、実際にチームで考え、作り、フィードバックを受ける形にしたことで、自分の課題に気づくきっかけにもなったのではないかと感じています。実務とのつながりについても、ありがたいフィードバックをもらいました。社内での運用を交えた話があり、実務でのイメージがしやすかったです。陥りやすいトラブルも含めて実習できたのが良かったです。チームやプロダクトに貢献する役割のスクラムマスターに魅力を感じました。スクラムの進め方だけでなく、実務でどのように活かせそうか、またスクラムマスターがどのようにチームやプロダクトに貢献するのかを感じてもらえたことは、運営側としても嬉しいポイントでした。一方で、改善につながるフィードバックもありました。 1スプリントの時間がかなり短く、慌ただしく感じました。遊園地という題材に少し馴染みにくい部分がありました。楽しく学べたという手応えがあった一方で、スプリント時間や題材には改善の余地があります。これらのフィードバックは、次回以降の研修改善に活かしていきたいと考えています。実施して見えた課題手応えがあった一方で、今回の研修プログラムには課題も見えてきました。ツール操作の負荷オンラインホワイトボードツールは共同作業に便利な一方、操作に慣れていない参加者にとっては負荷になる場面がありました。本来はスクラムやチームでの意思決定に集中してほしいため、次回はワーク前に基本操作を確認する時間をもう少し設けたいです。午前中のアイスブレイクでツールに触れてもらうだけでなく、午後のワークで使う操作を具体的に練習しておくと、よりスムーズに入れそうだと感じました。題材への馴染みやすさ今回は遊園地を題材にしましたが、遊園地にあまり詳しくない参加者にとっては、ややイメージしづらい部分もありました。題材への理解に時間を使いすぎると、本来学んでほしいスクラムの体験に集中しづらくなります。次回は、より多くの人がイメージしやすい題材にするか、補足情報を用意することを検討しています。スプリント時間とワーク量のバランス短時間でスクラムの流れを体験してもらうため、1スプリントの時間を短めに設定しました。ただ、その割にやることが多く、参加者にとっては慌ただしく感じる部分もありました。また、講義、ワーク、レビュー、ふりかえりと内容を詰め込んだ結果、休む時間も少なくなってしまいました。短い時間で優先順位を考えること自体は学びになりますが、考える余白やふりかえる時間も必要です。特にオンライン研修では、画面を見ながら議論や作業を続けるため、想像以上に集中力を使います。次回は、スプリント時間とワーク量のバランスを見直しつつ、適切に休憩を入れられる構成にしたいと考えています。おわりに今回は、新卒社員向けに実施したアジャイル・スクラム研修について紹介しました。オンライン研修という制約はありましたが、実装を伴わない題材にすることで、チームで考え、作り、フィードバックを受け、改善するスクラムの流れを体験してもらうことができました。また、研修プログラム自体も、最初から作り込みすぎず、スクラムマスター同士で試し、若手メンバーへのプレ実施を通じて改善しながら作っていきました。今回見えた課題も踏まえて、今後も参加者がスクラムの本質的な学びに集中できるよう、研修内容を改善していきます。付録：ワークで使った架空プロジェクトの設定（抜粋）最後に、実際の研修で使った架空プロジェクトの設定を一部抜粋して載せておきます。研修やワークショップを設計する際の参考になれば幸いです。架空プロジェクトの設定プロジェクトの背景事業会社Aは、全国でレジャー施設を展開する大手企業です。近年、レジャーに求められる体験は多様化しており、家族で楽しむだけでなく、カップルや友人同士、さらに外国人観光客にも魅力的な施設づくりが求められています。こうした市場の変化を受け、事業会社Aは遊園地の開発プロジェクトを立ち上げました。プロジェクトの目的本プロジェクトの目的は、幅広い来園者が一日中楽しめる遊園地をゼロから企画・設計することです。今回、事業会社Aは施設の企画を行う立場として、外部の設計会社に設計提案を依頼しています。そのため本研修では、参加者は設計会社のプロジェクトチームとして、顧客の要望をヒアリングしながら、施設の設計案を提案していきます。皆さんの役割皆さんは、事業会社Aから新規施設開発を依頼された設計会社のプロジェクトチームです。今回は、2つの設計会社がそれぞれ案を考えて提案する形でプロジェクトが進んでいる、という設定です。そのため、皆さんにはそれぞれの設計会社のメンバーとして、顧客の要望をもとに施設の設計案を検討してもらいます。研修の中で最終的にどちらの会社が選ばれるかは決めません。大切なのは勝ち負けではなく、顧客と対話しながら要望を整理し、よりよい提案を考えることです。顧客の主な要望エリア 4つの異なるテーマを持つエリアを作ることその他施設「救護室」を必ず1つ設置すること「トイレ」を各テーマエリアに最低1つは設置すること「レストラン／カフェ」と「ショップ（お土産屋）」を1つ以上設置すること園内の移動と安全性来場者が歩くメインの通路を明確に示すこと人気アトラクションには、行列のための待機スペースを設けることエ

アジャイル
スクラム
研修

Cybozu·2026/05/19

Androidチームのミーティング「チョルチャタンマ」を紹介します！

こんにちは！サイボウズの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 日々の業務や学習で得た学びを共有するライトニングトーク会です。発表形式は自由で、完成度が低くても問題ありません。これまでに、以下のような発表がありました。 Claude Codeの便利なカスタムスラッシュコマンドとテクニック Claudeを活用してチームのドキュメンテーション文化を改善中の話 AI-DLCの紹介 URLとURIの話 RSGT2026オフライン参加の感想こうして見ると、AI活用話が多いですね。準備時間を取らなくても気軽に発表できる効果は大きく、普段の業務で得た知見の共有にピッタリな会です！ 2. 不定期の社内外イベント 2-1. 報告LT Google I/Oなどの大規模な技術カンファレンスの内容を報告するLT会を開催しています。過去の報告LTの内容については、以下の記事を参照してください。 blog.cybozu.io 2-2. 勉強会 Kotlin Coroutines、Material3、Flutter、Docker & Kubernetesなど、特定の技術テーマについて深く学ぶための勉強会を随時開催しています。読書会も行っており、最近はGoogleのソフトウェアエンジニアリングに関する輪読会を行いました。 2-3. インターン開催毎年のインターンシップを企画・開催しています。サイボウズのインターンシップでは、1日・3日・1週間といった期間の選択肢や、実務コース・育成コースといった対象別の選択肢から、内容に合わせた形態を選べるようになっています。Androidチームでは毎回、どのチームで受け入れるか、どんなコンテンツにするかを話し合って決めています。新卒採用に直結する大切な取り組みなので、参加してくださる学生さんにとって学びのある時間になるよう、工夫を重ねています。 2-4. カンファレンス協賛 DroidKaigiやKotlin Festなどのカンファレンスにスポンサーとして協賛しており、以下のような話し合いを実施しています。スポンサー企画配布チラシとノベルティの準備ブース準備プロポーザルのアイデア出し発表のリハーサルたとえばDroidKaigiは毎年秋開催ですが、例年では春ぐらいから動き出しています。どういった目的でブースを出すか、どのようなノベルティを用意するかをエンジニアたちが決め、イベントに詳しい部門の支援を受けています。ブースだけではなく登壇にも力を入れており、モバイルエンジニアの多くが登壇のネタ探しに参加し、セッションが通過したメンバーには資料レビューや発表練習までやっています。まとめサイボウズのAndroidコミュニティ「チョルチャタンマ」では、定期的な社内イベントで日々の学びや悩みを気軽に共有し合い、不定期の社内外イベントで勉強会・インターン・カンファレンス協賛などを通じて視野を広げる活動を行っています。「切磋琢磨」という名のとおり、kintone・サイボウズOffice・Garoonとプロダクトの垣根を越えてAndroidエンジニアが集まり、知識や経験を持ち寄って互いに高め合える場になっています。心理的なハードルを下げる工夫を重ねながら、技術の話だけでなく普段の悩みやアイデアまで気軽に話せる雰囲気が、このコミュニティの大きな魅力です。コミュニティの活動内容については、これからも改善を重ねていきます。Androidエンジニアが楽しく成長し続けられるコミュニティであり続けたいと思います。さいごに私たちは、一緒にAndroidコミュニティを盛り上げる仲間を募集しています！興味ある方はぜひ、以下のサイトから採用情報をご確認ください！ cybozu.co.jp cybozu.co.jp

Android
コミュニティ
インターン

Cybozu·2026/05/07

成長し続ける大規模プロダクトを、小さなチームでどう切り拓くか？開発陣のセッションから見えた意思決定の現在地

こんにちは！開発本部開発広報チームの北地（@tos_kitt）です。 4月8日に開催した Cybozu Tech Meetup では、「巨大プロダクトに小さいチームで大きな変化を起こす」をテーマに、kintone の性能ダッシュボード開発の裏側を取り上げました。イベント当日は、技術的な工夫だけでなく、チームの意思決定のあり方や、プロダクトに向き合う姿勢まで含めて、学びの多い時間になりました。この記事では、運営者として印象に残ったポイントも交えながら、当日の内容を振り返ります。なぜこのテーマで開催したのかサイボウズが提供するkintoneは、現在42,000社以上にご利用いただいている巨大なプロダクトです。日々機能追加や改善を続けていますが、これだけスケールしたプロダクトになると、新たな機能をどう作り、どう届けるかは決して簡単な問題ではなくなります。今回テーマに取り上げた「性能ダッシュボード」は、お客様自身でアプリのパフォーマンス問題の把握や改善に向けた判断ができるよう、性能指標を可視化する機能です。単にログやメトリクスを画面に出すだけでなく、どの情報を、誰が、どのように使える状態にするかを考え抜く必要がありました。運営者としてこのテーマを取り上げたいと思ったのは、ダッシュボード開発副部の取り組みが、単なる機能開発の話に留まらないと感じたためです。大規模プロダクトの一部を担いながらも、小さなチームだからこそできる意思決定や進め方を選び取り、実際に価値提供につなげています。その実践は、同じように複雑なプロダクト開発に向き合っている方々にとっても参考になるはずと思い、今回のイベントを企画しました。セッションのハイライトセッション1：小さなチームで、大きなインパクトを〜プロダクトと向き合う面白さ〜登壇者：kenny（ダッシュボード開発副部エンジニアリングマネージャー） kennyさんのセッション動画リンク最初のセッションでは、エンジニアリングマネージャーのkennyさんが、ダッシュボード開発副部の組織的な取り組みや開発スタイルについて話しました。チームの立ち位置として、「向かう先は同じだけど、走り方は自由」というスタンスが紹介されました。kintone本体のビジョンやゴールは共有しつつも、独自の技術スタックや開発プロセス、意思決定を独立して行うことで、最速で動ける選択をしています。また、「得意を生かす。得意を超える」という姿勢を掲げ、個人の高い専門性を発揮するだけでなく、インフラ担当がUI/UXの議論に参加するなど、専門性の境界を超えた活動を行っています。さらに、四半期ごとのゴールに対し、チーム内で作戦会議をして意思決定を担う点も挙げられました。Cybozu Days*1のリリース日に間に合わせるため、提供価値や開発コストの観点から作るものを柔軟に変更した事例も紹介され、これらはメンバー一人ひとりの当事者意識によって支えられているとのことでした。セッション2：kintone性能ダッシュボードの迅速な価値提供を支えた技術的意思決定3選登壇者：谷昌典（ダッシュボード開発副部プロダクトエンジニア）谷さんのセッション動画リンク続いて、プロダクトエンジニアの谷さんが、性能ダッシュボード開発において「仮説検証のサイクルを素早く回す」ために行ってきた、具体的な技術的意思決定について話しました。迅速な価値提供を支えた意思決定の1つ目として、BFFとTypeScriptの採用が挙げられました。BFFで認証とDB操作の層を分離し、モックサービスを利用することで、フロントエンドとバックエンドの並行開発を実現しています。2つ目は、開発初期段階でのプルリクエストのプレビュー環境整備です。ラベルを付与するだけで、DBを含むフルセット環境や、DBをスキップしたモック環境を即座に立ち上げる仕組みを構築し、開発環境自体への投資が開発速度の向上に繋がっているとのことでした。 3つ目は、Grafanaを活用した表示内容の検討です。ダッシュボードのUIを都度開発して試すのではなく、プロダクション環境上に立てたGrafanaを用いて、どのグラフがお客様にとって意味があるかを検証することで、1回あたりの試行錯誤のコストを軽くしている仕組みについても紹介されていました。パネルディスカッションとQ&Aタイム後半は、視聴者のみなさんからの質問も交えながら、さらに開発の背景を掘り下げる時間となりました。生成 AI 機能開発チームの齋藤さんがモデレーターとなり登壇者の二人と対談しました。ここでは、その中でも特に印象に残ったやり取りを一部ご紹介します。なお、全編気になる方は、下記リンクからぜひご視聴ください！パネルディスカッションとQ&Aタイムの動画リンク Q. 失敗したことややり直したエピソードは？谷 : 当初はデータソースを複数想定してBFFを設計したのですが、開発速度を優先してデータソースとサービスを1つに統合した事例があります。この点については、現在となってはこの判断は良かったと振り返っています。一方で、開発を小さく進めてチーム内で相談しながらこまめに軌道修正を行っているので、取り返しがつかないようなクリティカルな失敗は発生していません。 Q. 大規模プロダクト×小チームで「これだけはやった方がいい」ことは？ kenny : リソースが少ないからこそ、エンジニアをプロダクト作りに巻き込むことでチームの方向性を揃え、主体性やアウトプットの質を上げることが重要だと考えています。谷 : 大きなチームでの "当たり前" を小さなチームにそのまま持ち込むのではなく、一度アンラーニングして疑ってみる姿勢が重要です。小さなチームだからこその素早さを活かせる改善を取り入れていくのが良いのではないでしょうか。 Q. 当事者意識を高める工夫は？（視聴者からの質問） kenny : 四半期ごとのプロダクトロードマップ更新のタイミングで、チーム全員で議論するようにしています。また、リリース前にチーム全員でプロダクトを実際に触ってバグ出しをする会も実施しており、こうした取り組みを通じてプロダクトに対する愛着や当事者意識を育てています。 Q. 本番デプロイの自動テストとAI活用についてをどうしているか？（視聴者からの質問）谷: E2Eテストでダッシュボードが表示されることまでを確認し、失敗した場合はCIで落とす仕組みにしています。また、インフラ面ではAWS CDKのスナップショットテストを活用しており、リソースに変更があればテストが落ちるようにすることで、常に意図したインフラ構成になっていることを保証しています。なお、品質保証の工程におけるAIの活用については、現時点ではまだあまり進んでいません。イベントを振り返って運営者の立場として一番心に響いたのは、メンバーが自律性を持って活動し、変化を楽しみながら明確な方向性を持って挑戦している姿です。 kennyさんが語っていた「自律的なチーム」「明確な方向性」「挑戦」という3つの掛け算が生むワクワク感や、自分たちで決めた機能が何万というお客様に届くインパクトを糧にする当事者意識。そして、領域を横断してでも本当にお客様に価値があるものを追求し、初期案に固執せず変化そのものを楽しもうとする谷さんの姿勢。そこには、巨大なプロダクトならではの挑戦の難しさを楽しさに変え、自らの手でプロダクトを切り拓いていく、魅力的なエンジニアの姿があると感じました。当日参加できなかったみなさんにも、この記事を通じて、そんなチームの雰囲気や実践の様子が少しでも伝わっていれば嬉しく思います。それぞれの現場でプロダクト開発に向き合う上で、何かのヒントになれば幸いです。次回以降のイベントのお知らせサイボウズでは、このように各開発チームが日々議論を重ねながらプロダクトを磨いています。ご興味を持っていただけた方は、ぜひ今後のイベントにもご参加ください！今回はオンラインでしたが、次回、次々回はサイボウズ東京オフィスでの現地開催を予定しています。 2026年5月21日（木）： kintoneフロントエンド16年の軌跡 2026年6月22日（月）：性能ダッシュボード開発チーム続編イベント ※現在企画中です。詳細はconnpassなどで順次ご案内します。ぜひチェックしてみてください。また、サイボウズの開発組織に興味を持っていただけた方は、カジュアル面談でお話できると嬉しいです。カジュアル面談受付フォーム *1:サイボウズ製品のユーザー、パートナー、社員が集まり、活用事例や最新の取り組み、展示を通じて知見を得られるイベント

TypeScript
BFF
Grafana
AWS CDK
アジャイル

Cybozu·2026/04/30

QAとして入社して5年が経ちました

入社5年、同期3人の振り返り body { font-family: "Hiragino Sans", "Meiryo", sans-serif;} .intro { background: #f5f4f0; border-radius: 8px; padding: 1rem 1.4rem; margin: 1.5rem 0; } dl { margin: 1rem 0; } dt { font-weight: bold; margin-top: 1.2rem; } dd { margin-left: 1.8rem; margin-top: .2rem; } .ref { font-size: .9rem; color: #666; margin-top: 1rem; } .ref a { color: #0073e6; } /* メンバーごとのカラー */ dt.massan { color: #c49000; } /* kintone */ dt.taguchi { color: #3d8fa8; } /* Cybozu */ dt.taku3n { color: #1a4db8; } /* Garoon */ /* 方法①：フォトライフ画像の枠線を消す＋中央揃え */ img.hatena-fotolife { border: none; display: block; margin: 0 auto; } こんにちは！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のリリース改善に取り組んでいます。具体的には、リリースとデプロイの分離やプロセス改善を通して、高速で安定したリリースの実現を目指しています。その中で、新しく作り上げるリリースフローのテスト活動も行っています。その他では、他チームからのGaroonの品質に関する問い合わせ対応、テストアーキテクチャ設計、QA新卒採用、アシスタントマネージャーなどにも取り組んでいます。 3人の所属する組織図概略 ref. サイボウズの QAエンジニアについて / about cybozu QA 5年間でどう変わった？次に、入社からの5年間でどのような変化があったかを振り返ります。 massan 入社してすぐ、kintoneQAのインプロセス化がそれまで以上に進み、開発チームも担当領域の分割が進みました。kintone全体を見るのではなく、開発チームに所属して自分の担当領域に絞って見るようになったんです。オーナーシップは持てるようになりましたが、その反面、過去の資産に頼れない場面も多くなりました。そんな中、プロダクトの初期段階から頼ってもらえるQAになるべく、新規立ち上げされたkintone拡張基盤チームに配属されました。立ち上げから1年以上経ちますが、固定化されたテスト実施タスクは少なく、品質戦略の策定、テストフローの整備、テスト資産化など業務は多岐にわたります。自分のスキルや知識がチームの品質の上限になってしまうので、ISTQBをはじめとする勉強で体系的な知識をつけたり、カンファレンスに行って知見を増やしたりしています。最近は脆弱性周りに気を配ったり、シフトライトの強化を検討したりもしていて、4月はtaguchiさんのいるPSIRTに体験入部してきました。5年も経つと同期同士でも専門性が違ってきて、改めて身近に頼れる同期がいることのありがたさを実感しています。 taguchi 最初は製品の脆弱性診断を中心に担当していましたが、その後、担当製品に関わらずPSIRT全体の診断にも目を向けるようになりました。現在も診断全体の効率化は継続的に進めています。さらに、プロダクト全体のセキュリティを見る立場も担うようになり、業務への関わり方や役割は変化してきました。また、PSIRTにはプロジェクトを小規模なチームを編成して進められる仕組みがあります。自分がジョインした当時にはなかったのですが、常に複数のプロジェクトが同時並行で進んでおり、最近ではPSIRT業務を支える根幹のひとつになっています。この仕組みのおかげで、セキュリティの技術的な部分だけでなく、PSIRTそのものについて考える機会も増えましたし、オーナーシップを持って進めていく経験にもつながっています。 taku3n 入社当初は、Garoonの膨大な仕様を理解することに必死で、手動テストプロセスやリリースプロセスの基礎を学ぶ毎日でした。その一方で、現場作業を少しでも効率的にするための改善活動を通して、プロセス改善に興味を持ち始めました。転換点は、3年目にリリース改善チームへ加わったことです。それまでのQAのみのチームから、SWE（ソフトウェアエンジニア）と同じチームで活動するインプロセスな体制に変わり、よりシフトレフトを意識するようになりました。テスト対象もプロダクト単体からリリースの仕組み（CI）に変わり、品質を担保する方法を探りつつ構築していきました。この活動を通して、いかに安全かつ高速に価値を届けるかというプロセスの品質に、強く向き合うことになりました。現在は、品質の可視化やリリースとデプロイを分離するフィーチャーフラグの導入プロジェクトのリーダーとして、リリース運用の土台からアップデートする効率化に取り組んでいます。5年間の積み重ねを経て、今はより広い視点でプロセス全体を捉え、改善策を提案していけるようになりました。今後も「楽をするための努力」を続けていきたいです！ AIとどう向き合ってきた？ 5年間の中でも特に大きな変化だったのが、AIの台頭です。QAとしてAIとどう向き合ってきたかを話してみました。 massan ひとりQAでチームの工数も限られる中、AIなくしてはチームの開発が成り立たないレベルになっていると思います。テスト設計など自分がこれまで行ってきた業務をAIに依頼するだけでなく、やりたかったけれど時間や一部スキルが足りずにできなかったことにも手を出せるようになり、チームへの貢献度が上がりました。たとえば、細々したケースの全数テストや、セキュリティアラートを受けた際の影響調査、修正、テストなどに活用しています。一方で、MCPサーバーの開発ではユーザーのAI利用を助けるような立場にもなり、AI利用の両面を経験しています。 taguchi ここ5年間のAIに関する動きとしては、サイボウズ内でもAI関連機能の開発が進み、それに伴ってPSIRTでもAIに対する診断を内製化する動きがありました。推進を担当したメンバーのおかげで、今ではテスターのほぼ全員がAIに対する診断を行える状態になっており、開発者向けに社内で勉強会を実施するなど、チームとしてAIセキュリティに関する知見も蓄積されています。脆弱性診断へのAI活用という文脈では、昨年からAIエージェントによる診断も導入しています。開発がますます高速化する中で、PSIRTとしてもそれに追随できるよう、今後さらにAIを活用した診断の自動化を進めていきたいと考えています。 taku3n 4年目にAIを活用したGaroonの新機能開発チームにQAメンバーとしてジョインしたことが大きな転機でした。精度検証やプロンプトチューニングといった、これまでにない領域でのQA活動は手探りの連続でしたが、AIの品質保証プロセスを一から作り上げる経験ができました。なんで5年経っても3人ともいるの？最後に、同期3人がそろって5年間在籍し続けている理由を聞いてみました。 massan 正直、転職のモチベーションは増えたり減ったりしてきました。でもプロジェクトが多いので、これまで自分の成長段階それぞれにちょうど良いチームや役割をあてがってもらううちに気づけば5年が過ぎていました。サイボウズはQA組織が大きいのが特徴で、知見の共有や相談、他チームの事例などに手軽にアクセスできるのが良いところです。その一方で、自分は小さいチームのひとりQAなので「自分が動かないと何も変わらない」という状況もあります。興味があることを無闇にやらせてもらえるとは感じませんが、自分が稼いできた信頼貯金で新しいことをさせてもらえるだろうという実感はあります。あえてあげるなら、これが大きな理由かもしれません。6年目となる最近はその貯金をちゃんと使って、自律的にチームや事業への貢献を増やす方法を学んでいる段階だと思っています。 taguchi 環境の良さは大きいですね。チームの雰囲気はもちろん、いろんなことに挑戦できる環境や気軽に相談できる場が整っていると感じます。自分としても、興味のある領域に関わらせてもらっている感覚がありますし、新しいツールの導入や「やってみたい」と思ったことをすぐに試せるスピード感もあります。このあたりの印象は入社した頃からずっと変わっていなくて、会社全体としてそういった雰囲気があります。そうした環境がモチベーションの維持にもつながっていると思います。 taku3n 一番の理由は「今取り組んでいることが面白いから、もっと続けたい！」という思いが強いからです。振り返ってみると、この5年間のうちに何度か所属チームが変わり、向き合う課題もさまざまでした。ちょうどコンフォートゾーンに陥りそうになったタイミングで新しい変化が起き、そのたびに目新しい挑戦がありました。最初は難しくても、やり込んでいくうちにその面白さにハマっていく。そんな刺激的なサイクルに自ら挑みながらも、会社に後押ししてもらえていたと実感します。また、大きな課題にぶつかって悩んでいるときも、チームとして解決しようと協力してくれる温かいメンバーが周りにいることも大きいです。サイボウズは「チームワークあふれる社会を創る」という理念に共感した人が集まっている組織なので、自然と現場でもチームワークがあふれています。こうした環境があるからこそ、変化を楽しみながら5年間走り続けてこられました！

QA
セキュリティ
AI
プロセス改善

Cybozu·2026/04/28

ウェブアクセシビリティ基盤委員会（WAIC）にてサイボウズメンバーはこんな活動をしています

こんにちは、この記事はフロントエンドエンジニアのmehm8128とデザインテクノロジストの小林大輔の共著記事です。サイボウズは2018年に、WAIC（ウェブアクセシビリティ基盤委員会）の会員組織になりました。 2025年までは、実際に委員として活動しているサイボウズのメンバーは小林大輔1名でしたが、2026年から新しくmehm8128が作業協力者として活動を開始しました。そこで、改めてサイボウズ社員がなぜ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 Out kintoneのアクセシビリティ改善とESLintルールの整備 - Cybozu Inside Out WAICでは現在、以下の5つの作業部会が活動しています。作業部会1: 理解と普及作業部会2: 実装作業部会3: ガイドライン作業部会4: 翻訳作業部会6: JIS X 8341-3 改正原案作成委員会 JIS X 8341-3の改正に関する準備──ウェブアクセシビリティ基盤委員会作業部会6 作業部会1には小林が、作業部会2にはmehm8128が所属しています。よって今回は、特にこの2つの作業部会に焦点を当ててそれぞれの目線で活動内容の紹介をしていきます。作業部会1（小林大輔） WG1に参加した理由私がWAIC WG1に入会したのは、「ウェブアクセシビリティの重要性を一人でも多くの方に届けたい」という強い想いがあったからです。転機となったのは、ロービジョン（弱視）の方によるユーザビリティテストを目の当たりにしたことでした。自分が開発したサービスが、当事者の方にはほとんど利用できない。その現実を前に「アクセシビリティの低いサービスを作ることは、単なる技術不足ではなく、本来届けるべき価値や機会をユーザから奪い取ることなのだ」と痛感しました。意識せずとも、私たち開発者は開発したものによって「誰を社会に招き、誰を排除するか」決めてしまっています。だからこそ、作り手としての責任と可能性を伝えていきたい。そんな思いでWAICの活動を続けています。ウェブアクセシビリティセミナーの開催私が所属する作業部会1は、JIS X 8341-3の理解と普及に努めるワーキンググループです。ウェブアクセシビリティを啓発するセミナーの運営やウェブコンテンツの作成など、さまざまな活動を行なっています。詳細は以下の記事をご覧ください。 waic.jp 特に私が深く携わったのはセミナーです。ウェブアクセシビリティを啓発するセミナーを企画する、動画を制作する、実際に登壇するといったさまざまな活動を行なってきました。特に毎年開催しているCEATECウェブアクセシビリティセミナーは私が最も力を入れた活動のひとつです。ウェブアクセシビリティの初学者を対象として、ウェブアクセシビリティの概要やさまざまな民間企業の取り組みなどを紹介しています。動画のアーカイブがYouTubeで公開されていますので、ぜひご覧いただければと思います。第1部：ウェブアクセシビリティ最前線（CEATEC2025オンラインセッション） youtu.be 第2部：インクルーシブデザインによるアクセシビリティ改善（CEATEC2025オンラインセッション） youtu.be さまざまな立場の方と一緒に取り組める環境作業部会1にはWebサービスを開発する企業のほか、Web制作を行う企業、大学、省庁など、さまざまな立場の方が参加しています。多様な立場の方と日本のウェブアクセシビリティの普及について議論できることは、自分自身の見識を広げてくれています。作業部会2（mehm8128） WG2の活動については、作業部会2（実装） | ウェブアクセシビリティ基盤委員会（WAIC）に以下のような説明が記載されています。 WG2（実装ワーキンググループ）では、JIS X 8341-3の実装に必要な資料の作成及び公開、また実装の際に生じる諸問題の解決に向けた議論を行います。 JIS X 8341-3に沿った「実装」に関する様々な活動が対象となりますが、WG2では特に「AS情報」と呼ばれるものに力を入れています。 ASとは、アクセシビリティサポーテッドの略です。これはWCAGで定義されている言葉で、達成基準を達成するためのテクニックがユーザーエージェント・支援技術の組み合わせでサポートされている方法であることを示す概念です。「サポートされている」とは、例えばスクリーンリーダーの場合には開発者が伝えたい情報が正しく読み上げられる状態を表します。例えばChromeとNVDAの組み合わせでサポートされている（アクセシビリティサポーテッドな）方法でも、SafariとVoiceOverの組み合わせではサポートされていない方法であれば、その組み合わせではアクセシビリティサポーテッドとは言えません。サイボウズで僕が関わった開発業務で出てきた、アクセシビリティサポーテッドでなかった技術の例を紹介します。 kintoneのレコード一覧には、テーブルの見出しをクリックするとテーブル列をソートできる機能があります。当初はソート状態を表すためにaria-sortの利用を検討していたのですが、PC Talkerで読み上げられないことから不採用になってしまいました。結果的には、現在のソート状態を表す上下矢印のアイコンに「昇順」「降順」を表す代替テキストを付与することで、解決しました。*1。レコード一覧の見出しクリックによるソート（開発中の画面） aria-sortを用いる方法はテクニック集にはまだないパターンですが、達成基準の「達成基準 4.1.2 名前 (name)・役割 (role)・値 (value)」に対応する方法だと考えられます。また、ARIA-ATにはまだテストがありませんが、APGのパターンとして掲載されています。 www.w3.org その他参考：aria-sort_attribute (aria) | Accessibility Support このように、WAI-ARIAをはじめとしたアクセシビリティに関連するWeb技術では、相互運用性の問題がしばしば存在します。少しでも多くの環境でWCAGの達成基準がアクセシビリティサポーテッドな状態を実現するためには、相互運用性の現状を把握できるAS情報の整備や、実際に相互運用性を高めていく活動が必要です。それでは、WG2の具体的な活動を2つ抜粋して紹介します。 ASテスト整備 WG2ではASテストを作成し、そのテスト結果をAS情報としてまとめ、Webサイトにて公開しています。 ASテストはWCAGのテクニック（達成方法集）を基にWG内で検討し、テストケースを作成します。リポジトリはwaic/as_testに公開されているので、誰でも改善・修正提案をissueやPRを作成して送ることができます。 WG2内では、主に以下の2つを議論します。どのテクニックを優先してテストケースにしていくのかテクニックがアクセシビリティサポーテッドであることを確認するために、どのようなテストケースを作成すればいいのかこの過程でWCAG側のドキュメントの不備が見つかることもたまにあるので、個人的にはそれらをもっと積極的にAGWG側にフィードバックしていきたいと考えています。参考：主な活動内容に「W3C WCAGワーキンググループ等との国際協調」の記載があります*2。 AS情報の公開作業 ASテストの結果は、AS情報としてホーム：アクセシビリティサポーテッド（AS）情報に公開しています。ちょうど最近数ヶ月でAS情報の更新作業を行っています。作業はwaic/as_infoで行っており、僕もレビュー作業に関わっています。最近はUI改善もいくつか行いました。今後は後述のWCAG3の状況も考慮に入れながら、情報の表示方法などを改善していきたいと考えています。また、AS情報として公開するためのASテストを実施できる体験会も定期的に開催しています。ASテストを実施する際にWeb上で利用できるツールを最近作成しました（まだ実験的です）。その他、以下の記事にWG2の活動についての記載があります。 <iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwaic.jp%2Fnews%2Fciaj-column-3%2F" title="日本のウェブアクセシビリテ

アクセシビリティ
W3C

Cybozu·2026/04/28

QAエンジニアとして 1年目 → 2年目の仕事はどう変わった？これまでの変化を振り返る

本記事は、2024年入社のQAエンジニア 3人による振り返りブログの3本目です。まだ読んでいない方は、ぜひ1本目・2本目もあわせてご覧ください！ 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やセキュリティに関わるプロジェクトにおいて、リーダーとして関わるようになりましたリーダーとして関わるプロジェクトでは、進捗やタスクの管理に加えて、情報を一から収集・整理し、その結果をもとにステークホルダーと議論し、方針の決定や合意形成まで進める経験をしました。実際にやってみると、自分が関わっていない別プロジェクトをどこまで把握すべきか、どの観点まで見れば十分なのかといった判断を自分で下す必要があり、難しさを感じることも多くありました。それでも経験を重ねる中で、自分の担当範囲だけでなく、チーム全体の品質や進め方に目を向けられるようになってきました。その結果、リスクの共有や観点の補完といった形でチームに還元できている実感を持てるようになったのは、大きな変化だったと感じています。（以下の記事で紹介されている取り組みも、そのようなプロジェクトの一つとして、自分がリーダーとして関わったものです） blog.cybozu.io チーム横断活動への関わり 1年目は、自分の担当範囲やチーム内の文脈で考えることが中心でしたが、2年目に入り、徐々にYukimiチーム外の活動にも視野を広げられるようになってきました。きっかけとなったのは、社内勉強会で井芹洋輝さんをお招きして実施された「高品質と高スピードを両立させるテストアプローチ」という講演と、その内容を踏まえてGaroonチーム内で行われた勉強会です。 speakerdeck.com この勉強会を通じて、「Garoon全体としてのテストアーキテクチャをどう設計するべきか」という問いが生まれました。これを起点として、Garoon開発内でチームをまたいでアイデアを出し合う場を継続的に設けています。具体的には、テストレベルごとの責務を整理し直しながら、既存のテストにおける課題を洗い出し、改善に向けた議論を進めています。こうした取り組みに参加する中で、それぞれのPBIごとに実施するテストを積み上げていく視点だけでなく、それらをどのように組み合わせてプロダクト全体の品質を担保するかという課題に向き合うようになりました。その中で、難しさを感じる場面も多い一方で、全体設計として品質を捉えることの面白さも実感しています。また、チームを越えて議論することで、それぞれが持っている前提や暗黙知が言語化され、新たな気づきにつながる場面が多いと感じています。このような対話を通じて、品質に対する認識をすり合わせていくこと自体が、プロダクト全体の品質向上につながる重要なプロセスだと考えるようになりました。セキュリティ領域への広がり 2年目に入り、QAエンジニアとしての役割を意識しつつも、それをチーム全体にどう還元できるかを考えるようになりました。特に、Yukimiチームでは、QAエンジニアとWebエンジニアといった職能を越えて動くことが求められていると感じています。そのため、自身の担当領域にとどまらず、OSSの脆弱性調査やセキュリティ対応などにも主体的に関わるようになりました。また、チームとしてもプロダクト全体のセキュリティに目を向けるようになり、役割もOSS対応中心から徐々に広がってきました。そうした流れの中で、その一環としてセキュリティチャンピオン活動に参加し、OWASPなどの基礎知識の学習や、『安全なWebアプリケーションの作り方』の輪読を通じて、体系的に学ぶようになりました。 blog.cybozu.io このような環境の変化を踏まえて、「このチームの中でどう価値を出すか」を改めて考えるようになりました。単に任されたタスクやプロジェクトを進めるだけでなく、チームとして注力している領域に主体的に関わることが重要だと考えるようになりました。その中で特に意識したのが、OSSの脆弱性対応や情報のキャッチアップです。OSSの新たな脆弱性をいち早く検知し、影響を評価して対応につなげることが求められます。そうした中で、自ら脆弱性を検知し、調査を進めていくようになりました。また、こうした取り組みと並行して、個人的にもセキュリティ領域の学習に力を入れるようになりました。以前社内CTFに参加した際に、手を動かしながら攻撃や防御の仕組みを理解していくプロセスに面白さを感じていたこともあり、その延長として学習を継続しています。現在は、TryHackMe を用いたハンズオン形式の学習や社外CTFへの参加、書籍でのインプットなどを通じて、少しずつ知識と経験を積み重ねています。 blog.cybozu.io これらの取り組みを通じて、1年目は脆弱性情報を追うだけで精一杯でしたが、2年目に入り、それらに対してどのように向き合い、どのようにアプローチしていくかの引き出しが少しずつ増えてきたと感じています。また、セキュアサプライチェーン対策など、より実践的な経験を積めるタスクにも挑戦しています。 3年目に向けてこの1年は、社内外問わずさまざまなことに挑戦してきました。 2年目は、目の前のタスクをこなすだけでなく、チームやプロジェクト、プロダクト全体に対して価値を出す経験が少しずつ増えてきたと感じています。一方で、個々の取り組みがまだ点で終わってしまっており、それらをつなげてユーザー・Garoon開発チームのメンバーに価値を届けることが次の課題です。 3年目は、これまでの経験をもとに、個々の取り組みを再現性のある形に整理しながら、チームやプロダクト全体により踏み込んで関わっていきたいと考えています。おわりに（3人の振り返りブログを通して） 3人それぞれの記事、いかがでしたでしょうか。同じQAエンジニアという職種でありながら、サイボウズでは所属するチームやプロダクトが異なると、日々の業務内容や直面する課題、成長のかたちもこんなにも違うのだと、改めて実感しています。これらの記事がQAエンジニアという職種に興味を持っているみなさんや、同じように日々奮闘しているエンジニアのみなさんにとって、少しでも参考になれば幸いです。これからも3人で切磋琢磨しながら、チームや組織に貢献できるQAエンジニアを目指していきます！

QA
セキュリティ
アジャイル

Cybozu·2026/04/27

モバイルQAで積んだテスト設計が、gRPCの自動テストを支えてくれた

こんにちは！サイボウズ Office で QA エンジニアをしている、水谷（@dog_dog_3dog）です！今回は、新卒3年目を迎える3人のQA同期メンバーのリレーブログの2本目として、「仕事の変化はあるけれど、やってきたことはちゃんと力になっている」というテーマで書いてみようと思います。 1年前には想像していなかった今の仕事 3年目を迎えた今、私はグループウェア製品の中のLLM アプリの開発チームで、QA のリードとして働いています。その中で、LLM アプリのバックエンドで使っている gRPC API のテストを、2か月で 500〜600 シナリオほど実装しました。今の自分だけを見ると、「もともと自動テストや API テストが得意だったのかな」と思われるかもしれません。でも、実際はそうではありません。むしろ、自動テストにはかなり苦手意識がありました。 LLM アプリの開発に携わることになることも、まして苦手意識のあった自動テストを集中的に実装することになるなんて、1年前の自分はまったく想像していませんでした。もともとはモバイルアプリの QA だった入社して最初に配属されたのは、サイボウズ Office モバイル（Android）の開発チームでした。そのチームではスクラム開発を採用していて、毎週のように新機能が実装され、それに合わせてテスト設計とテスト実施を繰り返していました。 1週間で 5〜6 機能ほど増えるようなスピード感だったので、毎週たくさんのテスト設計をして、モバイルアプリのテストに追われる毎日でした。 2年弱で、合計 200 近いテストスイートを作っていたと思います。とはいえ、1つ1つの機能は Web アプリの機能をモバイルで再現するものが多く、実装単位としては比較的細かいものでした。リファインメントが終われば、すぐにテスト設計をして、次の週には実装が終わり次第すぐにテストを実施する。慌ただしい日々ではありましたが、短期間で新機能のポイントをつかみ、テンポよくテスト設計、テスト実施を進めていく経験を重ねることで、QA としての基礎をしっかり積むことができた期間だったと感じています。そこから仕事が大きく変わったその後、自分の所属するチームで PoC として開発していた LLM 機能が製品に組み込まれることになりました。昨年のゴールデンウィークごろに、「実際に製品として開発して半年後にリリースする」という方針が決まり、その流れで私は LLM アプリの QA を担当することになりました。どんな流れで、どんな業務をしているかはご興味あればこちらをご参照ください。 https://speakerdeck.com/cybozuinsideout/jasst2026tokyo_mizutani そして今年の2月ごろからは、主務の QA メンバーが自分1人、兼務でサポートしてくださる QA が1人という体制の LLM アプリ開発チームに参画し、バックエンドで利用している gRPC のテストをひたすら書いています。 API のインテグレーションテストはそれまでほとんど書いたことがありませんでしたが、Claude Code や Codex を活用しながら、1日あたり 20 ケース前後を書けるようになりました。 Skillsを作成して、テスト観点をAIに渡して、自動でテストスクリプトを生成してもらっています。もちろん最初からそうだったわけではなく、最初は格闘しながら 1 日 1 本書くのがやっとでした。1か月ほどかけて coding agent との付き合い方を覚え、ようやく 1 人でもある程度進められるようになった、という感覚です。正直に言うと、バックエンドサービスの堅牢化のために自動テストを追加していく仕事がメインになる、というのは、少し前の自分には考えられなかったことでした。今でも苦手意識はありますし、わからないことばかりで、本当に手探りで進めています。それでもやれているのは、前に積んだ基礎があるからそれでも、この大きな仕事の変化を少しずつこなせるようになってきたのは、入社してから培ってきた「テスト設計の技術」があるからだと感じています。モバイルアプリのチームでずっとやってきたテスト業務は、バックエンドでマイクロサービス間の通信を行うための、gRPC のテスト設計や実装にもそのまま活きています。たとえば、網羅的なテストを考えるためのデシジョンテーブル、何を同値として扱うかを整理する同値分割、エラーケースを漏れなく考えるためのユースケースや異常系の洗い出し、どれもテスト設計の基礎基本です。今は、自動テストのコードを書くことがQAとしての仕事の中心になり、AIの力も存分に借りながら、この新しい課題に日々取り組んでいます。でも、「何をテストすべきか」「どの程度の網羅性のテストをすべきか」を考える力は、間違いなく過去２年間の経験で積み上げてきたものです。もしテスト設計の基礎ができていなかったら、実装をどうするか以前に、「そもそもこのテストはちゃんと設計できているのか」という大きな不安を抱えながら仕事をすることになっていたと思います。おわりに 3年目を迎えるにあたって、このブログで一番書きたかったことは、頑張ってこなしてきた仕事の経験は、新しいことをするときにもちゃんと自分を助けてくれる。ということです。仕事の内容や、求められるスキルが大きく変わることは避けられないことです。でも、その変化の中でも、これまで積み上げてきた基礎はなくならないし、きちんと自分の身を助けてくれます。最近は、そんなことを実感しながら仕事をしています。明日は、同期のれおくんのブログも上がるのでお楽しみに！！

QA
gRPC
生成AI

Cybozu·2026/04/24

新卒3年目QAの振り返り：少しずつできることが増えてきた話

はじめにこんにちは、24卒のQAエンジニアの永田です。 kintoneのアプリ設定チームに所属しています。本記事は、同期3人での振り返りブログの1本目です。 24卒のQAの3人は、それぞれ異なるプロダクトのチームに所属しているため、同じQAという職種であっても業務内容は少しずつ異なります。そのため入社してから月に1回、ざつだん会を開き、各自の近況報告や悩み相談などをゆるく共有しています。そんなざつだん会の中で、「入社して3年目が経った記念にブログを書こう！」という話になり、今回の記事を書くことになりました。サイボウズでは内定者アルバイトや入社1年目の振り返りブログが多く公開されていますが、初めての環境で試行錯誤しながら成長していく時期を過ぎ、後輩もでき、「ピカピカのビギナー」から少し成長したタイミングでの振り返りも面白いのではないかと思っています。また、先述の通り私たちはそれぞれ異なるチームに所属しているため、QAという職種の幅広さや面白さも感じていただけたら嬉しいです。新卒3年目の変化 1年目と大きく変わった点は、所属チームのQAとしてリードしていく立場になったことです。チーム配属時に暖かく迎え入れてくださった先輩QAは、途中で他のチームへ異動されました。最初は寂しさもあり、「先輩なしでやっていけるのだろうか」という不安が大きかったです。実際の業務の中でも、これまでどれだけ先輩に頼っていたのかを思い知らされる場面が多くありました。一方で、先輩の異動は「自分が独り立ちできるはずだ」と認めてもらえた証拠でもあるのではないかと考えるようになり、日々タスクに向き合ってきました。まだ胸を張って「アプリ設定のQAをリードしています」と言えるレベルではありませんが、着実に自信を持ってできることは増えてきたと感じています。スキル面でも、大きめのタスクから小さめのタスクまで幅広く取り組めるようになり、過去の経験を活かしながら、より漏れの少ない試験設計ができるようになってきました。 E2E整理への取り組み E2E整理は、配属当初から取り組んでいるタスクです。背景として、テストケース数の増加により、実行時間の長期化や不安定テストの増加といった課題がありました。そのため、E2Eの回帰試験ケースの内容を見直し、重要度を判断しながら適切なテストレベルに振り直す取り組みを進めてきました。 1年目は既存のテストケースの確認・整理が中心でしたが、2年目からはそれに加えて実装にも関わるようになりました。 QAとしての関わり方の幅が広がったと感じています。実装にあたっては、同じチームのSWEの方々に多くのご協力をいただきました。 QAでも実装しやすいようにリファクタやヘルパーメソッドを整備していただいたり、モブで一緒に進めていただいたりと、多くのサポートを受けました。職種を超えて協力しながら品質を高めていくこうした取り組みは、サイボウズのカルチャーらしい部分だと感じています。これから 3年目に入りますが、「チームや周りの人の役に立ちたい」という思いを軸に、これからも取り組んでいきたいと考えています。その思いを実現できるのであれば手段にこだわらず、技術的な領域からマネジメントまで、幅広く経験を積んでいきたいです。最近はAIの力もあり、これまでハードルが高いと感じていた技術的な領域にも挑戦しやすくなってきました。そうした環境も活かしながら、新しいことにも積極的に取り組んでいきたいと思います。 3年目も引き続き、チームに価値を出せるようコツコツと成長していきます。おわりに最後まで読んでいただき、ありがとうございました。本記事は同期3人での振り返りの1本目として、私の視点からの変化や取り組みをまとめました。このあと、他2人の記事も公開される予定ですので、異なるチームで働くQAの視点の違いもぜひ楽しんでいただけたら嬉しいです。 QAという職種の幅広さや面白さ、そして3年目というタイミングだからこそ見える景色が、少しでも伝わっていれば嬉しいです。

Cybozu·2026/04/17

不確実性を下げるリファインメントでのQAの関わり方

この記事は、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も実装部分を含めて見積もり、他メンバーも実装後の作業を見積もり、見積もりが出せない時はお互いに質問するようにしています。会話の変化見積もり方針の変更により、リファインメントでの会話にいくつか変化がありました。 QAも実装を見積もる方針の変更により、実装しないが実装も含めて見積もるという自分の立場を明確にできました。これによりそれまで聞きづらかった質問もしやすくなりました。以下は一部の例です。　　作業量の目安に確信はあるか実装の難易度をPdEはどう感じるか外部仕様から見た影響範囲の認識は合っているかもちろん質問内容はPBIによって変わりますが、実装方針を理解するよりも実装工程で生まれるリスクはどれくらいあるかを洗い出すイメージで会話しています。不確実な部分を事前に知っておくと回収のための心算もできますし、QA側からそれらを解消できるアイデアを出せるかも知れません。他メンバーもテストを見積もる他のメンバーがテストについてどれくらい知っているか、自分自身も未知でした。テストについてのイメージがばらばらだと、いくつかの弊害をもたらすことがあります。テストが終わり次第リリースしたい場合、日程の認識がずれるテストが重そうに見えると、開発の心理的なハードルになる不要/過剰なテストについて、QA以外の視点で判断できない新しい方針では他のメンバーにもテスト以降を見積もってもらうという前提で、積極的に情報を出すようになりました。例えば、詳細な機能テストが必要か、β版なので最低限でよいのかの質問や、具体的なテストケース、実際にテストするときにこそ認識合わせが発生しそうな箇所などです。これによってPBIで目指す品質に大きな認識の齟齬がないかも確認できますし、リリース可能になるまでのイメージをより明確にメンバーで共有するきっかけにもなります。他にも、自分のスキルや経験的にすぐできるテストかどうかや、タスクに関連するAIの活用状況など、直接工数に影響する観点も共有しています。もちろん毎回のリファインメントで劇的に成果を出すわけではありませんが、テスト周りの状況を共有することで他のメンバーからアドバイスやアイデアをもらえることもあります。テストのPBIの見積もり例（自動テスト実装について話し合いSP2に）効果リファインメントでの情報量が上がった従来方針でも、新しい方針の開始したてでも、自分（QA）だけが異なる見積もりを出してしまうことへの心理的なハードルがありました。実際にQAなど特定の職能だけが違う見積もりを出すこともあり、その度に一人ひとりコメントを出してすり合わせていきました。（拡張基盤チームはリファインメントの参加者が概ねいつも４人以下なので全員発言することが多いです。）そうして回数を重ねるごとに職能による見積もり差は減っていきました。チームで合意をとったことにより質問への心理的なハードルは下がり、言い意味で雑に気になったことを聞けるようにもなりました。 QAからのコメント出しについて、どうしてもテストの話をするとリリースが遅くなるような、消極的なイメージを伴ってしまうことがあります。もちろん必要なテストを遠慮を理由に削ることはできませんが、守るべき観点を守りつつ、より早く安心してリリースできる方法を模索したいという気持ちもこめてテストの情報を出すようになりました。会話量を増やすと情報量は増え、お互いの作業について複数の視点から見ることができ、知らない・見えないことによる不確実性を下げることができます。テストを含む実装以降の認識合わせをすることでリリース可能な状態になるまでのタスクがより明確になり、リリース日程やリリースする機能単位の認識合わせも以前より自然に行えるようにもなりました。（副次的）協力が柔軟になった QAも一員としてチームに所属していますが、自分自身にあった習慣や慣れにより、テスト活動に関してQAしか知らない領域を作ってしまっていたように思います。例えば、チームのカンバンにはテスト実施がわかるステータスはありますが、テスト設計をいつどうやってしているかはほとんど見えません。方針を変えてからはQAである自分の発言量が少し上がり、テスト設計の話をするようになったのはもちろん、QAが主導するPBI（テスト全般の改善など）についてもリファインメントで話すようになりました。これによりチームにQAの仕事を知ってもらえる機会ができ、テスト改善のレビューをしてほしい場合など協力を依頼しやすくなりました。まとめ・LTの反応自分にとってのやりづらさを解消したかっただけのところが、QAがチームの開発でより動きやすくなるきっかけになりました。リファインメントでPBI全体のタスクを見積もる方針にすることで情報量は増え、リリースまでの工程や各タスクでの懸念をチームで確認することができます。このLTをまとめるにあたってスクラムマスターに壁打ちの相談をしたところ、「見積もりがずれることに対してネガティブに感じるケースは多いが、この話ではポジティブに受け止められていそう」という感想をもらえました。チームの大きさや開発の進め方によってこのような見積もり方針が合うかは違いそうですが、個人作業の多い自チームで効率よくQAの考えを上流工程にもっていく仕組みができたのかなと思っています。リレーブログのおわりに 2026春QAエンジニアリレーブログでは「テスト実施以外の、QAエンジニアの活動」をテーマに記事を発信してきましたが、いかがだったでしょうか。私自身は開運冬まつりのいちLT登壇者でしかありませんでしたが、社内で多くのメンバーに聞いてもらえたLTを社外に見える場所にも発信したい、そして社外交流のきっかけにもしたいという思いから今回のリレーを提案しました。幸い、QAエンジニアレーンの登壇者全員にリレーブログへの参加を快諾してもらうことができました。まだ桜が咲き終わらないうちに全ての記事が無事公開に至り、陰ながら嬉しいばかりです。各記事をご覧くださったみなさまに、少しでもサイボウズのQAエンジニアの活動について知ってもらえたら幸いです🌸 blog.cybozu.io

スクラム
アジャイル
ふりかえり

Cybozu·2026/04/16

エンジニアインターンシップ2026を開催します！

インターンシップ/ロゴこんにちは！エンジニアインターン運営チームです。サイボウズでは毎年夏に、エンジニア向けのサマーインターンシップを開催しています。今年はフルリモートに加えて、対面のオフラインでも開催しますのでぜひ実際にサイボウズの雰囲気を体験しにきてみてください！どんなインターン？製品開発を行うチームに加えて、製品開発を支えるチームやプラットフォームに関わるコースなど、全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 皆さんのエントリーをお待ちしています！

インターン

Cybozu·2026/04/14

サイボウズのQA内定者アルバイトって何をするの？

こんにちは！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エンジニア内定者アルバイトでは何をする？以下に、初日から最終日まで行った主なタスクを時系列順に並べてみました。半年経った今の自分が振り返り、タスクの分類分けもしてみました。各項目には感想も添えています。また、タスク紹介後に、タスク管理方法についても記載しました。タスク紹介 kintoneについて学ぶ（2025年9月〜10月） kintoneヘルプサイトを参照しつつ、kintoneを操作してみる kintoneのアプリ領域にどのような機能があるかを知る kintoneアプリ画面の回帰試験実施感想：一度操作しただけで全てを理解できれば良いのですが、さすがにそうはいきません。この時期は「とりあえず、いろんなアイコンをクリックしてみよう！」「お、ここでレコードを追加・編集できるのか〜」といった理解度で、地道に仕様理解を進めていきました。 kintoneのPC画面は以下のような感じです。（サンプルデータを利用しています。）既存仕様の理解が目的のため、Closure版の画面を主に操作しました。レコード追加時は、プラスボタンをクリックし、レコード編集時は、ペンアイコンのボタンをクリックします。 kintoneのPC画面ここでじっくり時間をかけてkintoneの機能を理解したことで、後のテスト実施の際に「少なくともどの機能をテストすれば良いか」が分かるようになります。……とは書きましたが、分からないこともあります。そんなときは、kintoneヘルプサイトを調べたり、kintoneの機能仕様書を覗いてみたり、「これはkintoneのどこをクリックしたら表示される機能ですか！」と勇気を出して聞いてみたりして解決していました。半年間で幾度となく質問をしましたが、質問に対して返信が返ってこなかったことは一度もありません。 QAの業務について学ぶ：初級編（11月） UI（PC画面）の手動テスト（QAの先輩が設計したもの）の実施テスト設計方法を学ぶ UI（PC画面）の手動テスト設計感想： 11月前半は、QAの先輩が設計されたテストの実施をしながら、kintoneの使い方を理解しようとしていた時期でした。kintoneのヘルプサイトをこまめに参照しつつ、9月〜10月で学んだkintoneについての知識をテスト実施で活かそうと奮闘していました。そして11月後半からは、テスト設計もタスクに加わるようになりました。これまではQAの先輩が作成したテストを実施するのがメインだったので、私にとって新しい挑戦でした。初めて取り組んだテスト対象は、「コメント欄でユーザーのメンションをクリックすると、そのユーザーのユーザー情報ポップアップが表示される」という機能でした。ものすごい時間をかけて初めてのテスト仕様書を作成した訳ですが、QAの先輩は、私が作ったようなテストをものの5分で作成されたりします。もちろん、私がテスト設計する際に急かされたりすることは一切ありませんでした。ただ、私は、スピーディーなテスト設計を見て非常に感化されました。将来的には、素早くテスト設計を行うことができるQAになりたいです。 QAの業務について学ぶ：中級編（12月〜1月） UI（モバイル画面）の手動テスト実施 UI（モバイル画面）の手動テスト設計不具合報告感想：この時期からkintoneモバイル画面のテスト実施が始まりました。kintoneモバイル画面とは、スマートフォンでkintoneにブラウザログインする際や、スマートフォン向けkintoneアプリにログインした際に表示される画面のことです。 kintoneのモバイル画面は以下のような感じです。（サンプルデータを利用しています。）テスト対象であるReact刷新後のレコード一覧画面のスクリーンショットを載せておきます。 kintoneのモバイル画面そして、新たに不具合報告というタスクにも取り組むようになりました。テスト実施の結果、期待結果に合致していればPassed、合致していなければFailedとなります。Passedとなったテスト対象はそのまま開発フローの次のステップに回りますが、Failedは不具合なので実装者に報告する必要があります。不具合報告は、初めのうち「あれもこれも伝えたい！でも適切な表現が思い浮かばない！」という状態で、読み手にとってかなり読みづらい文章になっていたと思います。振り返ると、不具合を修正するSWE（ソフトウェアエンジニア）にとって、不具合を特定しやすい文章がまったく分かっていなかったことが原因だと思います。そこで、ババロアチームの皆さんの不具合報告の内容を観察することから始めました。不具合のスクリーンショットや動画があると、視覚的にわかりやすい。短い文章ではあるが、読み手にとって理解しやすい文章は端的で洗練されている。どの不具合報告の内容にも真似したい要素があったので、全てを織り交ぜ、どんな不具合報告を行うときも使う型を作成しました。さらに、現在はAIの力を借りて、自分が作成した型に伝えたい事象に合致する言葉を見つけられるようになりました。ただ、意味を理解していない言葉は使いたくないので、AIが出力した言葉の意味を理解し、自分の表現として使えるようにする学びは欠かせません。以下は、テスト実施でFailedになった項目について、不具合改修Issueとして登録するかを確認している様子です。メッセージには、返信またはスタンプが必ず返ってくるので、安心してコミュニケーションを取ることができていました。 SlackでSWEとやり取りしている様子 QAの業務について学ぶ：上級編（2月〜3月） JSAPIの手動テスト実施不具合報告感想：ついに総まとめ！2025年9月〜2026年1月に取り組んできた種類のタスクも引き続きありましたが、メインはkintone上でJSAPIが正しく動作するか確かめるテストの実施でした。ここでいうJSAPIとは、kintone JavaScript APIのことを指します。ブラウザ画面上の情報を取得・操作できるAPIのことで、下記に詳しい情報が載っています。 cybozu.dev JSAPIのテストは主に2種類あり、それぞれ以下のようなテスト方法でした。 ① メソッド系JSAPIの一例項目内容テスト内容モバイルのレコード追加画面で、レコード追加ボタンの表示・非表示ができるかを確認するテスト実施方法レコード追加画面で下記スクリプトを実行するスクリプト kintone.mobile.app.showAddRecordButton(state) 参考 showOrHideAddRecordButton（公式ドキュメント）期待結果レコード追加ボタンの表示・非表示を切り替えることができる ② イベント系JSAPIの一例項目内容テスト内容レコード追加画面を開いたときに、alertが表示されることを確認するテスト実施方法下記スクリプトをkintone内のアプリに適用する → レコード追加画面を開くスクリプト下記コードブロック参照期待結果レコード追加画面を開いた際に、「test」と書かれたアラートが表示される参考 create.show イベント（公式ドキュメント） kintone.events.on('mobile.app.record.create.show', function() { alert("test"); }); ①②いずれも、期待結果通りであればPassed、そうでなければFailedです。Failedとなった項目は、UIのテスト実施時と同様に、不具合として実装者に報告します。タスク管理方法<

QA
kintone

Cybozu·2026/04/13

仕様ですか？不具合ですか？ — 未来のチームを救うために「Why」を残す

この記事は、開運冬まつり2026 Day1セッションのQAエンジニアレーンで発表されたLTをブログ形式にして発信しているものです。 2026春QAエンジニアリレーブログの5本目の記事となります。こんにちは、サイボウズでQAエンジニアをしている森長です。グループウェア製品Garoonを担当するSpicaチームに所属しています。私たちのチームは新機能の開発はしておらず、テスト以外の観点でプロダクトの品質に貢献することをミッションとしています。具体的には、リリースプロセス改善、ドキュメント整備、不具合改修のハンドリングなどを担当しています。「Why を残しましょう」と言いながら、自分も忙しさに流されてサボってしまうことがあるので、自戒を込めてこの発表をしました。「なぜそうなっているのか」、分かりますか？コードや仕様書を見たとき、「何をしているか（What）」は書いてあるが、「なぜそうしたのか（Why）」が書いていない。そんな経験はないでしょうか。 Garoonは長年にわたって運用されてきた製品なので、「これは仕様ですか？それとも不具合ですか？」という問い合わせを頻繁に受けます。このような問い合わせに答えるのは私のチームの仕事です。その中で「Whyが残っていたら嬉しいのにな」と思うことがよくあります。日々おこなわれる「考古学」問い合わせを受けて仕様書やヘルプサイトを見れば、そこに書いてあることをもとに「仕様です」と答えられることも多いです。しかし私たちが大事にしているのは、「その仕様は今見ても正しいのか」を考えることです。仕様書に書いてあるから正しい、長年こうだったから正しい、ではなく、ユーザーにとって使いやすいか、今の観点から見て改善できないかを常に考えています。そのために、まるで考古学のように、以下のことをやっています。古い仕様書をさかのぼる過去のやりとりや議事録を掘り起こす類似機能や他社製品と比較するこれは、問い合わせの挙動を仕様であると明記しているところがあるかどうかを探すだけの調査ではありません。未来をより良くするために、手がかりになる過去の「Why」を探します。「なぜそうなっていたのか」が分かれば、「今もその理由は有効か」「変えるとしたら何を考慮すべきか」を議論できます。しかし時間をかけて調べても、当時の意図にたどり着けないことも珍しくありません。仕様書には「〜は不可」と書いてあっても、「なぜ不可なのか」が書かれていないケースがあるからです。「Why」がないと判断しにくい例架空の CMS（記事や投稿を管理するシステム）の記事管理機能を例に、「Why」がないと判断に迷うケースを考えてみましょう。あるCMSでは、「下書き」「公開済み」の記事は、一覧画面での一括削除・記事詳細画面での個別削除のどちらもできます。ところが「予約公開待ち」の記事だけは、一括削除ができず個別削除しかできません。仕様書には「予約公開待ち：一括削除不可」とだけ書かれています。なぜ不可なのかは書かれていません。誤って大量の予約投稿を消してしまわないよう、1件ずつ確認させたかったのか？当時は何らかの技術的な制約があったのか？「予約公開待ちの記事も一括削除できた方が便利なのでは？」と感じても、Why が分からない以上、「直すべきなのか」「あえて残すべきなのか」を判断する材料がありません。特に影響範囲が広い機能であれば、根拠なく「とりあえず直そう」という判断もとりにくいです。もし当時決定した仕様の理由が残っていれば、「その制約は今も有効か」を判断できたはずですし、改善に踏み切る根拠にもなりえると思います。「Why」がないと、改善の機会を逃す「仕様かどうか」は仕様書やヘルプサイトを見れば分かります。しかし「直していいのか」という判断や、ユーザーへの説明に必要な根拠は、その背景にある「なぜそうなっているか」がなければ答えられません。「当時の意図」は、その場にいた人の頭の中にしかありません。コードや実際の挙動からは読み取れず、時間が経てばその人も忘れてしまいます。一見おかしな挙動でも、「あえてそうしている」理由があることは多々あります。技術的な制約、業務ルール、当時のユーザー要望など…それらが分かれば、「今も同じ制約があるのか」「状況が変わったなら直せるのではないか」という議論ができます。しかし Why が失われていると、現状を変えることへの心理的ハードルが上がってしまいます。「Why」を残す、3つの始め方「ちゃんとした理由書を書こう」と思うと重く感じてしまいますが、完璧なドキュメントでなくて構いません。私が実践しやすいと感じている方法を3つ紹介します。 1. リンクを貼るだけでもOK 議論したSlackのスレッド、議事録、Issueのリンクを仕様書や Pull Request の説明欄に貼るだけで十分です。「なぜか」のコンテキストが参照できる場所を示しておくだけで、未来の調査コストは大きく変わります。 2. テンプレートに「背景」欄を作る要件定義書や設計書のテンプレートに「背景・理由」欄を設けると、書かざるを得ない仕組みになります。「フォーマットがあるから書く」という状況は、個人の意識に頼るより確実です。「Architecture Decision Record（ADR）」というプラクティスをご存じでしょうか？設計の意思決定について、「背景」「検討した選択肢」「決定」「その結果」といった形式で短く残すものです。テンプレートの一例として参考になります。 3. 「理由なし」と書く「特になし（なんとなくそうした）」という記録も、立派な情報です。理由がないなら、仕様を変えても問題ないか、と判断できます。まとめ：ドキュメントは未来のチームのために書いたドキュメントは、何年も経ってから見返されることのほうが多いと日々感じております。今日残した一行の「Why」が、数年後の自分や、チームメンバーを救うかもしれません。また、最近業務でAIを使う機会が増えるなかで、改めて感じているのが「AIはコンテキストを持たない」ということです。セッションをまたぐと、多くのAIツールではそれまでの会話の文脈がリセットされます。「なぜこの実装になっているのか」「当時どんな議論があったのか」そういった背景をAIに伝えるには、どこかにドキュメントとして残っている必要があります。 JaSST'26 Tokyoの基調講演では「AIにとってはドキュメントが全て」という発言もあり、他の講演でもAIへコンテキストを渡すことの重要性が語られていました。AIを活用するためにも、コンテキストを渡す手段としてのドキュメントの重要性はこれからますます高まると感じています。最後に、発表・ブログ執筆にあたって QA外部コネクトチーム（社外登壇支援などを行っているチーム）に大変お世話になりました！ありがとうございました！ 2026春QAエンジニアリレーブログ、次回もぜひ読んでくださると嬉しいです！

ドキュメント
QA
設計

Cybozu·2026/04/10

QAエンジニアによる既存テストの改善活動

この記事は、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ジョブの再実行や翌日の再実行では環境が作り直されるので成功します。すると「運が悪かっただけか」で済まされてしまい、誰もテストコードを修正していませんでした。こういった冪等に実行できないテストを見つけては、冪等に実行できるように修正する、ということを繰り返しています。既存テストの解体 ― 毎月200ケース x 4環境、本当に必要？チーム配属直後、毎月決まった定常タスクがありました。約200ケースのテストを、ブラウザ4環境で実施するというものです。最初は「こんな機能があるんだ」と新鮮な気持ちで取り組んでいましたが、何回かやっていると、ふと思いました。「このテストケース、環境ごとにやる必要あるかな？」チームメンバーの力も借りながら、不要なケースの削除や手動テストから自動テスト（E2Eテスト）への移行を進めていきました。 E2Eテストの実行速度も改善する手動テストは減らせたものの、自動テストの方にも問題がありました。 Garoonの開発では、ブランチ名に -with-e2e を付けるとコミットごとにE2Eテストが実行されます。開発者はこれを使ってリリース可能な状態のアーカイブをQAに渡してくれるのですが、テスト数が約600件。不安定なテストも紛れていたため、「いつになったら実行終わる？」という状況でした。こちらもテストケースの削除・統合を行い、実行速度の改善を進めています。新規テストの作成 ― E2Eテスト偏重からの脱却「テストが多くて困っているのに、新しくテストを作るの？」と思われるかもしれませんが、理由があります。 Garoonの自動テストは、手動テストを自動化する際にすべてE2Eテストとして実装されたため、E2Eテストとユニットテストの二層構成になっていました。E2Eテストはユーザー視点で動作を保証できる反面、不安定で実行時間が長いです。この構成はバランスが良いとは言えません。そこで、E2Eテストとユニットテストの間に位置するインテグレーションテストの導入を提案しました。今回導入するインテグレーションテストは、ブラウザを使わずにHTTPリクエストを直接送信し、レスポンスのHTMLやJSONを検証するテストです。このテストでは、ある程度ユーザー視点での動作保証ができて、かつE2Eテストよりも安定して短時間で実行できます。これまでは個人活動として進めてきましたが、影響範囲が大きく、チームとしてのアドバイスも欲しいということで、2026年1Qから開発チーム内の公式プロジェクトとして活動を始めました。改善活動のために勉強したこと個人で一から始めた活動だったので、たくさんのことを勉強しました。現在実行されているテストの内容を理解する既存のテストコードの書かれ方を把握する（プログラミング言語自体の理解も含めて）自動テストの理想的な状態とは何かを考えるインテグレーションテストの実装方法を調べる進め方としては、書籍やWebで調べて、実験してみて、その結果を先輩やAIに相談する、という繰り返しでした。改善活動の難しさと楽しさ難しさ同意を得ること: 影響範囲が大きいので、いろいろな人に「こんなことをしたいんだけど、どう？」と相談しながら、同意を得られる案を作り上げるのが大変でした。時間の確保: TsukimiチームのQAとして一番時間を割いていた業務はテスト設計・実施なので、テスト業務の合間に進めていました。改善を一気に進めたい気持ちをぐっと抑えつつ、コツコツ続けてきました。楽しさ成果が目に見える: 手動テスト数が減ったり、自動テストの実行速度が上がったりと、効果がはっきり見えるのでやりがいがあります。仕事の幅が広がった: CI周りや自動テストの中身を把握しているので、関連するタスクの依頼や質問が増えました。幅広く頼ってもらえるのは、素直に嬉しいです。今後の展望まずは、インテグレーションテストへの移行を進めていきます。改善が終わったらどうなるか？また次の改善が始まります。テストの改善に終わりはないので、引き続きコツコツ取り組んでいきます。開運冬まつり2026のQAエンジニアレーンでは、他にもさまざまなテーマで発表がありました。他の発表者のブログも順次公開予定ですので、ぜひそちらもご覧ください！

QA
テスト自動化
E2Eテスト

Cybozu·2026/04/06

プロダクトエンジニア×QAエンジニアでもっと”一緒に”つくるリグレッションテスト

この記事は「開運冬まつり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の責任という暗黙の了解が生まれていました。気になっていたこと上記の進め方をしていたことによって、QAである私は、テストコードの責任が暗黙的にPdEに寄ってしまうことが気になっていました。また、実装のプロセスに関与していないことによって、実装の観点をQAが持ちづらいことや、その後の運用・保守の観点をQAが持ちづらいといった機会損失があると感じていました。「越境」してみよう！そう考えた私は、次のようなTryをチームで行うことにしました。テストコードの実装をQAが担当してみるリグレッションテストの作り方を、次のように変更しました。テストケース設計：引き続きQA, PdEで実施テストコード実装：実装 → QA, レビュー → PdE テスト実装のタイミングとしては、PdEがプロダクションコード, 単体テストコード実装完了後、QAに完了連絡をしてもらうようにしました。そのタイミングでQAが、プロダクションコード実装ブランチからリグレッションテスト実装用のブランチを切って、実装を行うようにしました。得られたもの -QAの視点から- 実際にテスト実装をやってみて本体実装の詳細を知らなくてもテスト実装できるという気づきがありました。これまで、「本体実装の詳細を知らないとテスト実装ができないかも？」という思い込みがあったのですが、実際には、正しい振る舞いや仕様と公開インターフェースを理解できていればテスト実装は可能でした。また、副次的ではあるのですが、実装の詳細を知らないことによって、内部構造に依存しない、変更に強いテストが書けるという気づきもありました。これを裏返すと、実装の詳細を知らないと書けないテストは、設計を見直した方がよさそうといった会話もチームの中で生まれました。コードレビューを通じてテスト実装を担当してみると、テストケースの観点を満たせてはいるものの、実装観点からみて愚直なコードや不要な処理を書いてしまうことがありました。今回のTryでは、コードレビューでPdEに関与してもらう形で進めていたため、実装の観点からレビューをもらい、洗練されたコードに磨き込むことができました。普段の業務の中で、あまりコードレビューをしてもらう機会は多くないため、QAにとって貴重な実装観点の学びの場になりました。テスト運用から得られたフィードバックテストの運用の中で、CI での不安定な挙動といったトラブルにも遭遇しました。テストケースに複数の観点が混在し実行時間が伸びて時々タイムアウトする問題については、テストケースを分割するという運用から設計へのフィードバックがありました。また、タイミングに依存している実装になっているため、実行時の状況に応じて時々失敗する問題については、不安定になりにくい実装への見直しという運用から実装へのフィードバックがありました。いずれも、運用を通じて設計・実装へとフィードバックが生まれた事例です。得られたもの -チーム全体の視点から- 得られた効果 ① テスト設計・実装の両プロセスで知識が共有されるように PdE/QAお互いがそれぞれのプロセスに関わることで壁が崩れ、これまで一緒に行っていたテスト設計だけでなく、テスト実装も含めた両プロセスで知識が共有されるようになりました。 ② リグレッションテストがPdE/QA両方の資産であるという実感を得られるように QA視点では、実装・運用まで関与したことで、テストコードまで含めた今後の改善に積極的に取り組みやすくなりました。 ③ PdE/QA間でのリソースの融通が効くようにチームでの開発の進め方として、機能開発の中でQAにテスト設計だけではなく実装まで担当してもらうことを選択できるようになりました。これにより、PdE/QA間でのリソースの融通が効くようになるという効果が得られました。「テストコードはPdEに実装してもらうもの」という認識だと、そこに主体的に改善を入れていくのはなかなか難しいと感じていましたが、設計から実装、運用まで関わることで、QAにもテスト全体へのオーナーシップが生まれました。高速化する開発と、リグレッションテストの必要性プロダクションコードの実装がCoding Agentで日に日に高速化していく時代ですね。変更量が増えるほど、既存機能を壊していないことの保証が重要になります。高頻度かつ高速な保証のために、自動化されたリグレッションテストが整備されていることが今後の高速な開発における前提になると考えます。 Coding Agent とテスト実装の落とし穴 Coding Agent はテスト実装も担ってくれますが、落とし穴があると考えています。それは、「人力よりも実装コストがかからないのだから、とにかくテストを増やしてカバレッジを上げればいい」という思考に陥りやすいというものです。何をテストしているのかが曖昧になりやすく、目的が不明瞭な大量の既存のテストをベースにさらにたくさんのテストが実装されます。その結果、メンテナンスコストが膨らみ、テストの恩恵を感じにくくなることに繋がります。チームでリグレッションテストの方針を明確にし、AIにはその方針に沿って作業を代替してもらうことが重要です。おわりに - 世は大 Coding Agent 時代！- 今回の取り組みを通じて、メンバー間で「越境」してお互いの領域に踏み込むことが、リグレッションテストをチーム全員がオーナーシップを持った資産にする第一歩になると感じました。 Coding Agent がテストを量産できる時代だからこそ、「何を・なぜテストするのか」の手綱を握れるチームをつくることが、これからの備えになると考えています。読んでいただいたみなさんにとって、何か少しでも参考になる箇所があれば幸いです。次回のセッションの記事もお楽しみに！

QA
テスト自動化
アジャイル

Cybozu·2026/04/03

目的から見直すリリース基準の改善活動

この記事は、2026年2月に開催された社内カンファレンス「開運冬まつり2026 Day1セッション」のQAエンジニアレーンで発表されたLTをブログ形式にして発信しているものです。 2026春QAエンジニアリレーブログの2本目の記事です。こんにちは！サイボウズでQA(品質保証)エンジニアをしているすずりん🦒です。2025年に新卒として入社しました。現在は、Garoonの品質にかかわる活動を担当するSpicaチームに所属し、社内外から報告された不具合の再現調査や不具合登録、リリースプロセスの改善に取り組んでいます。今回はリリースプロセス改善の一環として行った、リリースクライテリア（リリース基準）の見直しについてお話しします。製品の品質を考える際の参考になれば幸いです。目次リリースクライテリアの課題リリースクライテリアの見直し 1．リリースクライテリアの分類 2.「CIが通っているかどうか」という項目の見直し改善活動から得られたこと・展望リリースクライテリアの課題皆様はご自身の担当製品をリリースする際に守らなければいけない基準がありますか？それはどのような理由でつくられた基準なのでしょうか。 Garoonをリリースするためには、社内に存在するリリースクライテリアを満たす必要があります。リリースクライテリアには、計8項目が含まれます。以下は項目の例です。取り込みたいPBIはすべて完了しているか開発中に見つかった不具合が修正されているか性能基準を満たしているかセキュリティテストが完了しているか CIは通っているか Spicaチームではこのリリースクライテリアを月に一度の定期リリースごとに定常業務として確認しています。確認作業はリリースの直前に行うため、リリースクライテリアが満たされないと緊急対応やリリースの中止が必要になることもあります。しかし、現行のリリースクライテリアは、「どの項目をどのように確認するか」の手順が書かれているだけで、「なぜその項目が品質のために満たされるべきなのか」がどこにも書かれていません。そのため、満たされない項目があった際、どのように対応していくかを決めるために時間がかかっていました。そこで、この改善活動では、リリース前に行う確認事項を整理することで確認にかかる時間を減らすことを最終目標としました。本記事では、まず1つ目のステップとして行った、品質特性による分類と、CIで確認しているワークフローの整理を紹介します。リリースクライテリアの見直し 1．リリースクライテリアの分類まず、リリースクライテリアにある各項目について、なぜそれを確認する必要があるか、目的を明確に書き出しました。書き出した目的を分類することで、「項目を満たした場合にどのような品質を保証できるか」が整理され、リリースクライテリアのゴールを明確にしたいと考えたためです。分類には、品質の状態を可視化することに有効な「ソフトウェアの品質特性」を活用しました。参考にした記事：ソフトウェアの「品質特性」とは？8つの品質特性と31の品質副特性、5つの「利用時の品質」を詳しく紹介| Qbook この分類を行ったことにより、Garoonのリリースクライテリアには次のような特徴があることが判明しました。機能適合性に関する項目が多い「CIが通っているかどうか」という項目の中で、複数の特性にまたがっている部分があるまた、項目が満たされていなかった際に取るべきアクションについても、品質特性ごとに分類したことで具体的に考えやすくなりました。 2.「CIが通っているかどうか」という項目の見直し GaroonのCIの中にはE2Eテストもあればユニットテスト、構文チェックなどもあり、CIで一括に実行される複数のワークフローは、それぞれ担保できる品質の種類が異なります。しかしながら、それぞれのCIワークフローが何を担保しているかはドキュメント化されているわけではなく、必要に応じて追加・削除を繰り返しながら管理されている状態でした。このため、リリースクライテリアの1つ、「CIが通っているか」を満たしていたとしても、ただ「CIが通った」事実が分かるだけで、結局何が保証されているのかが不明瞭でした。今回は1つのマージコミットで動いているCIの内容をすべて書き出して、動いているワークフローの中身を元に「テストの種類」「テスト対象」「テスト目的」を一覧にしました。これらを各ワークフローのコードから把握するためには、Github Copilotを活用しました。この一覧を作成したことで、CIで何のためにどのワークフローが動いているかをいつでも探すことができる状態になりました。また、各項目が先に分類した品質基準にどう対応しているかを明確にすることもできました。改善活動から得られたこと・展望今回の調査では、既存のリリースクライテリア項目は概ね適切であり、問題の原因はその分類と目的が明確でなかったことにあることが分かりました。また、根本の原因を解消するために、リリースクライテリアが満たされなかった際に取るべき行動をより明確にするための改善活動も始まりました。 Garoonの品質を維持・向上するため、元あった課題をすべてクリアできるよう、1歩ずつ取り組んでいきます！

Cybozu·2026/04/03

JaSST'26 Tokyo 参加レポート

こんにちは！ QAエンジニアの小竹です。 OfficeMobileチームでiOSアプリのQAとして働きつつ、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.dev JaSST'26 Tokyo ファンミーティングを共同開催しました 3月30日（月）にサイボウズ東京オフィスにて、スポンサーをはじめとする4社合同でアフターイベントを開催しました。 JaSSTでの学びの機会をインプットで終わらせず、会社の垣根をこえて交流の輪を広げたり、気づきを共有したりする場を作りたいと思い、OSTを行いました。当日は定員近い30名弱が足を運んでくださり、用意していた12個の枠いっぱいにテーマが集まりました。実際に出たテーマ（一部抜粋）ホストからのテーマの説明を聞いてうんうんと唸る方、セッションが終わっても話し込む方などが印象的でした。皆さまによる自律的な参加に助けられ、クロージングまで和気藹々とした雰囲気で運ぶことができました。終了後は「いろんな人と話せた」、「こんな話ができて嬉しかった」、「話し足りなかった」などの嬉しいご感想をいただき、運営としてもいち参加者としても充実した時間を過ごすことができました。スポンサーとしてLTの時間もいただき、サイボウズからはQAエンジニアのmassanがQA外部コネクトチームのご紹介をしました。私たちは今回のファンミーティング運営や一部協賛活動、外部登壇の推進など社外との繋がりを増やす取り組みをしていますが、どのような思いでチームとなり、何をめざしたいかをお話ししました。 LT資料 speakerdeck.com 終わりに近年、急激に生成AIが社会に浸透していることもあり、今回のJaSST'26 TokyoではAIに関する多彩な講演を満喫できました。 AI4QA／QA4AI、どちらのキーワードも非常に身近なものになり、今後のJaSSTも楽しみですね。また、今回はアフターイベントでたくさんの方と交流できたのも、とてもよい経験になりました。これからも協賛・登壇など様々な形で技術コミュニティへ貢献していけるよう、サイボウズQA一同頑張って参ります。直近では、2026年5月8〜9日に開催されるスクラムフェス新潟に協賛予定です。こちらでも、参加者のみなさまと交流できるのを楽しみにしています！