こんにちは！開発本部 開発広報チームの北地（@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

この記事は kintone の生成 AI チームで連載中の kintone AIリレーブログ 2026 の 9 本目の記事です。 リレーブログでは、生成 AI チームのメンバーが AI トピックに限らずさまざまなことについて発信していきます。こんにちは！kintone 生成 AI チームの 386jp です。前回の記事「cdk8s をもっと使いこなす - kintone AI チームの活用 Tips」では、 cdk8s を使う上で工夫している実践パターンを紹介しました。今回は、 cdk8s で生成したマニフェストをどのようにデプロイしているか、デプロイ戦略について紹介します。目次:前回のおさらいcdk8s をプロダクション運用する上での 3 つの課題課題1へのアプローチ：マニフェストの事前生成と書き出しの工夫マニフェストを事前に生成するメリットマニフェストの書き出し方の工夫FOLDER_PER_CHART_FILE_PER_RESOURCE の効果課題2へのアプローチ：GitOps 用リポジトリとの分離2 つのリポジトリ構成なぜ 2 つのリポジトリに分けたのか課題3へのアプローチ：段階的デプロイを実現する CI/CD パイプラインデプロイフローの全体像cdk8s コードの PR での変更確認段階的デプロイと自動検証まとめWe are hiring !!前回のおさらい前回の記事では、 cdk8s を使う上での実践パターンとして、以下の内容を紹介しました:core/apps の分離: インフラコンポーネントとアプリケーションを分けて管理YAML による設定管理: 環境ごとの差異を柔軟に管理CRD の型安全な扱い: TypeScript の型定義として取り込み、型安全に記述再利用可能な Construct: 共通パターンをまとめて開発速度を向上cdk8s をプロダクション運用する上での 3 つの課題cdk8s を使って Kubernetes マニフェストを TypeScript で柔軟に生成できるようになった一方で、それを実際のプロダクション環境へ安全かつ確実にデプロイするためには、いくつかの運用上で考えるべき課題がありました。実際にデプロイされるマニフェストが不透明になりがちArgo CD のプラグインなどで動的にマニフェストを生成させた場合、「結局何がデプロイされるの

kintoneの開発部門には、「プラットフォームエンジニアリング部（以下、PfE部）」があります。aki (@aki366) が、PfE部が何をする部なのか、なぜ今このタイミングで立ち上がったのかを、立ち上げメンバーへのインタビューを通してひも解く3部作。今回はその最終回です。第1回：なぜ、kintoneにプラットフォームエンジニアリング部は生まれたのか第2回：探索型開発と向き合う、kintoneプラットフォームエンジニアリングの挑戦人と文化の両面から、PfE部の今とこれからを探るプラットフォームは機能や基盤の進化だけでなく、そこに関わる人たちの考え方や文化も重要です。こんにちは。プラットフォームエンジニアリング部所属の aki (@aki366) です。前回に引き続き 上岡 (@ueokande) さんと 三苫 (@mitomasan) さんにお話を伺っていきたいと思います。この記事の構成は以下の通りです。人と文化の両面から、PfE部の今とこれからを探るPfE部の今Q. 今のPfE部には、どんなメンバーが集まっていますか？Q. このチームらしさはどこに現れますか？PfE部のこれからQ. 今後、プラットフォームとしての役割はどのように進化していきそうですか？Q. そのために、どんな文化を育てていきたいですか？Q. 今、PfE部を拡大させたいと考えている理由は何ですか？PfE部が大切にしたい人の姿勢Q. PfE部にフィットする思考とは？Q. 「こういう人は活躍しているな」と感じる共通点は？最後にここまで読んでくださった方に向けて、メッセージをお願いします。インタビューを終えてPfE部の今Q. 今のPfE部には、どんなメンバーが集まっていますか？上岡：aki：上岡：aki：三苫：三苫：利用者の生産性をどう伸ばせるかを考える。そのうえで、相手の意見にきちんと耳を傾け、フラットに受け止めたうえで、自分なりに咀嚼して判断できる。aki：Q. このチームらしさはどこに現れますか？上岡：「なぜそうしたのか」を技術的な確証を持って説明できるところは強みだと思っています。aki：三苫：上岡：PfE部のこれからQ. 今後、プラットフォームとしての役割はどのように進化していきそうですか？上岡：本当に作りたいものを実現できるようにしていきたいですね。aki：三苫：上岡：aki：Q. そのた

この記事はkintone生成AIチームで連載中のkintone AI リレーブログ 2026 の8本目の記事です。リレーブログでは生成AIチームのメンバーがAIトピックに限らず、さまざまなことについて発信していきます。こんにちは！ kintone の生成 AI チームでソフトウェアエンジニアをやっている福田です。以前の記事で生成 AI チームで Kubernetes の基盤を構築してアプリケーションを運用していることをご紹介しました。アプリケーションを運用する上で、セキュリティは欠かせない要件の 1 つです。セキュリティと一口に言ってもさまざまな側面での対策が考えられますが、アプリケーションによる通信を無条件で許可するのではなく、必要な経路に絞って許可することは最も基本的な対策のひとつなのではないでしょうか。Kubernetes ではこのような要件に対応するための仕組みとして NetworkPolicy という仕組みが用意されています。この記事では EKS Auto Mode 環境で NetworkPolicy をどのように適用しているか、そして、実際に遭遇したハマりどころと解決方法を共有します。NetworkPolicy の基本Kubernetes の NetworkPolicy は Pod の通信を IP アドレスとポート単位で制御できる仕組みです。NetworkPolicy は Namespace 単位のリソースとなっており、1 つの NetworkPolicy リソースを複数の Namespace の Pod に適用することはできません。（ある Namespace の Pod から他の Namespace の Pod への通信を許可することはできます。）指定方法としては ある Pod が通信できる相手を Pod の selector または CIDR 範囲で指定します。それぞれの用途としては、クラスタ内の Pod を指定したい場合は Pod の selector、通信元や通信先としてクラスタ外部を指定したい場合は CIDR 範囲で指定することになります。NetworkPolicy はステートフルに通信を制御するので、通信先の egress が許可されていれば戻りの通信も許可されます。ただし、通信先の Pod に NetworkPolicy が適用されている場

こんにちは！サイボウズでプロダクトエンジニアをしている @daikimkw です。この記事では、kintone のフロントエンド開発で AI をどのように活用しているか、そして kintone 開発全体として生産性を向上させるために今後どのような取り組みをしていくかについて紹介します。kintone 開発での AI 活用については、以下の記事でも紹介しています。サイボウズで利用可能な AI コーディングツールの紹介kintone AI 開発の効率化！Claude Code に Renovate PR レビューをお任せした話チーム専用の Claude Code Plugin マーケットプレイスを作った話また、本記事の取り組みの一部は JS ConfJP 2025 で発表しているので、そちらの動画や資料も参考にしてください。www.youtube.com資料：大規模プロダクトで実践するAI活用の仕組みづくりAI 活用の取り組みkintone は顧客領域ごとに複数チームで開発されており、コードベースの規模も大きく、AI をうまく機能させるにはいくつかの工夫が必要でした。ドメイン知識をマークダウンで管理するkintone は歴史的経緯や最適化のための工夫により、コードを読んだだけでは意図が伝わりにくい設計が多くあります。これらを AI に都度伝える必要がないよう、ドメイン知識をマークダウンファイルとしてリポジトリに配置し、AI が参照できるようにしています。具体的には、JS API・プラグイン機構・グラフなどの複雑な実装の設計背景や、kintone 固有の用語集などです。kintone のフロントエンドはチーム単位でディレクトリが分かれており、その中で pnpm の monorepo として構成されています。この構成を活かし、ドメイン知識のマークダウンもチームごとに配置しています。こうすることで、AI が参照するコードとコンテキストの範囲がチームの担当領域に絞られます。グラフなどの複雑な実装や設計背景も、グラフを管理しているチームに閉じられるため、他チームのコンテキスト消費を抑えられます。frontend/├── teamA│ ├── ai-guide # ドメイン知識をチームごとに管理│ │ ├── js-api.md # JS API の設計│ │ └── glossa

状況が変化する中での意思決定前回記事 なぜ、kintoneにプラットフォームエンジニアリング部は生まれたのか で触れた、プロダクト開発とプラットフォーム開発の 「時間軸の違い」。探索型プロダクト開発（短期）仮説検証 / 変更前提 / 速度重視プラットフォーム（長期）安定運用 / 先回り設計 / 継続投資どちらも正しい。いま私たちが直面しているのは、「どちらが正しいか」ではなく、複数の選択肢の中から何を選ぶかという問題です。選択肢が増えた世界で、どうやって選び続けるのか。こんにちは。プラットフォームエンジニアリング部所属の aki (@aki366) です。この記事の構成は以下の通りです。状況が変化する中での意思決定なぜプラットフォームは難しいのかQ. 今のPfE部で、率直に難しいと感じていることは何ですか？Q. 組織面と技術面、それぞれで課題はありますか？PfE部は何を担う存在なのかQ. インフラエンジニアやSREと比べると、どんなところが違うと思いますか？Q. 改めて、PfE部の役割を一言で表すとしたら何でしょう？Q. 逆に、「これはプラットフォームエンジニアリングっぽくないな」と感じる行動はありますか？PfE部のEMは、いま何に取り組んでいるのかQ. アラインメントで大変なこと、意識してることってありますか？Q. 複数の選択肢が並んだとき、優先順位を決めるのが難しかった判断はありましたか？PfE部が目指す未来とはQ. 少し先の未来ですが、PfE部はどんな状態になっていたら嬉しいですか？変わり始めている今、どう向き合っているのかQ. 今のフェーズの面白さは、どこにあると思いますか？まとめなぜプラットフォームは難しいのかQ. 今のPfE部で、率直に難しいと感じていることは何ですか？aki：前回に引き続き 上岡 (@ueokande) さんと 三苫 (@mitomasan) さんにお話を伺っていきたいと思います。まずは、今のPfE部で率直に難しいと感じていることから伺います。上岡：今だとプロダクト開発側が、デプロイ先のプラットフォーム間の差分として全文検索で使っている OpenSearch か Elasticsearch かを意識しないといけない。補足：国内市場向けのcybozu.comと、グローバル市場向けのkintone.comは異なるプラットフォームを使用してい

この記事はkintoneの生成AIチームで連載中のkintone AIリレーブログ2026の7本目の記事です。 リレーブログでは、生成AIチームのメンバーがAIトピックに限らずさまざまなことについて発信していきます。こんにちは、kintoneの生成AIチームでエンジニアリングマネージャーをしている立山です。みなさんのチームはAIを活用していますか？ここ最近はコーディングエージェントが高速にそこそこいいコードを作ってくれる時代で、個人の開発生産性は上がっていると思います。一方で、チームでAIを活用するというのはまだまだ限られているのではないでしょうか？この記事ではチームでAI、特に自律的に仕事を進めてくれるAIエージェントとの協業のはじめ方についてお話ししようと思います。私たちのチームでは、AIエージェントとの協業を始めるにあたって、以下の3つに取り組みました。仕事を言語化し、Agent Skills として定義する — 「すごいAIシステム」を作る意識ではなく、まず仕事の形を整え、AIに委任できる手順に落とし込むチームで共有可能な資産にする — 個人のノウハウに留めず、チーム全体で使える共通資産として運用する失敗できる環境を整える — AIが失敗しても素早く検知・復旧できる安全網を敷き、安心して委任できるようにする※ この記事ではチームがClaude Codeを使っている前提で話を進めますが、他のAIツールを使っていても同様の考え方が適用できると思います。 なぜチームでのAIエージェント活用が必要なのか仕事を言語化し、Agent Skills として定義するAIエージェントに移譲する仕事の範囲を決める仕事を自然言語・Agent Skillsで記述するチームで共有可能な資産にする失敗できる環境を整えるSmoke Testによるデプロイ検証Application Signals SLOとアラートAIエージェントと協業できる環境の効果チームのナレッジ共有が加速する本業に集中できる開発サイクルのスピードが上がる今後の課題ドキュメントの管理場所の最適解リモートでエージェントを動かす実行環境まとめWe are hiring!なぜチームでのAIエージェント活用が必要なのかAIツールの進化は目まぐるしく、状況は日々変わっています。そのなかで積極的に活用しているのはAIに関心のある一

speakerdeck.comこんにちは！サイボウズOfficeという製品でQAをしている水谷(@dog_dog_3dog)です。社内で「LLMアプリの品質保証 ～LLMの特性から全体像まで～」というテーマで勉強会を主催しました。この記事では、勉強会の内容と開催の背景を簡単に紹介します。資料の内容資料では、ざっくり以下のような流れで話をしています。COMPASからのケーススタディ LLMアプリ独自の品質特性 リスク分析 LLMアプリ全体の品質保証 開催の背景私がLLMアプリの品質保証に取り組み始めた頃、全体像を俯瞰できる資料が少なく、テストの枠組みを考えるのに苦労しました。そこで、今後社内で別のLLMアプリが開発される時に全体感を掴むための一つのきっかけになればと思い、勉強会を実施しました。なお、この勉強会は、産業技術総合研究所（産総研）が主催する「AI品質マネジメント講座」に参加させていただいたことに影響を受けて企画したものです。講座で多くのことを学ばせていただきました。産総研と講師の皆さまには大変お世話になりました。おわりに自分自身もまだまだ試行錯誤の途中ですが、この資料がこれからLLMアプリの品質保証を考える方のとっかかりになれば嬉しいです。

この記事は kintone の生成 AI チームで連載中の kintone AIリレーブログ 2026 の 6 本目の記事です。 リレーブログでは、生成 AI チームのメンバーが AI トピックに限らずさまざまなことについて発信していきます。こんにちは！kintone 生成 AI チームの 386jp です。前回の記事「cdk8s を使ってみた！ - TypeScript で Kubernetes を管理する実践 Tips」では、 cdk8s を導入した背景と実感したメリットを紹介しました。今回は、より実践的な内容として、私たちのチームが cdk8s を使う上で工夫しているパターンを詳しく紹介します。目次:前回のおさらいkintone AI チームでの活用core と apps によるコンポーネント管理config ディレクトリ: 設定ファイルを簡単に管理するresources ディレクトリ: CRD を TypeScript の世界に取り込むsrc/resources ディレクトリ: よく使うマニフェスト定義をまとめるまとめWe are hiring !!前回のおさらい前回の記事では、 cdk8s の概要と、 TypeScript で Kubernetes マニフェストを管理するメリットを紹介しました。今回は、私たちのチームが実際にどのような工夫をしているか、具体的な実装パターンを紹介します。kintone AI チームでの活用私たちのチームでは、複数環境への対応、再利用可能なコンポーネント化を意識して、以下のような構成を採用しています。まずはディレクトリ構成から、全体像を見てみましょう:our-awesome-cdk8s-project├── config # 設定ファイルの保存場所├── resources # CRD の TypeScript 定義を配置└── src ├── apps # k8s マニフェストの内容を記述 ├── core # k8s マニフェストの内容を記述 ├── config # 設定ファイルの parse など ├── resources # 再利用できそうなコンポーネントをまとめたもの ├── test └── utilそれでは、各ディレクトリの役割と使い方を詳しく見ていきます。core と apps によるコンポーネント管理チー

こんにちは！サイボウズのトニオ（@tonionagauzzi）です。普段はkintone開発チームにてAndroidアプリを主に開発しています。今回は、ディップ株式会社、株式会社Voicy、株式会社ヤプリ、そしてサイボウズ株式会社の4社合同でモバイル勉強会を開催しました。本記事では、イベントの概要と当日の様子をお届けします！イベントの概要イベント情報当日の様子LT (1) : AIとなら実現できる事業と品質のシン化の両立LT (2) : OSアップデート：年に一度の「大仕事」を乗り切るQA戦略LT (3) : "レビュー"だけだったAI活用から半年。ヤプリのiOS開発・運用はどう変化したか？LT (4) : 謎現象の解決手段を発見して プチ英雄になりましたLT (5) : Claude × Markdown で仕様書をいい感じに管理したいLT (6) : Kotlin Multiplatform + iOS アーキテクチャの実践LT (7) : バイトルiOSアプリのリアーキテクト / SwiftPMとAIルールで実現するモジュール設計懇親会まとめイベントの概要Mobile Tech Flexは、モバイルアプリ開発に携わる人々が集まり、各自の取り組みをLT形式で発表する合同勉強会です。DroidKaigi 2025の会場やアフターイベントで出会った4社のメンバーたちが2025年末から開催準備を進め、無事開催することができました。今回のテーマは「モバイル開発で自慢したいこと」です。技術的な挑戦、チームの文化、プロダクトへのこだわりなど、各社が「ここを見てほしい！」というポイントを持ち寄って共有することで、お互いの学びを深め、モバイルコミュニティを発展させるねらいがあります。ソフトウェアエンジニアだけでなくQAエンジニアなど幅広い職能に参加させてもらえるよう、職能の壁を越えた交流を意識し、勉強会のテーマ決めを行いました。会場は六本木の株式会社ヤプリで、29名の方に事前申し込みいただきました。六本木の高層からの絶景！おしゃれなカフェスペースでした！イベント情報イベント名：Mobile Tech Flex 〜4社合同！私たちのモバイル開発自慢大会〜開催日：2026/02/16(月) 19:00開始会場：株式会社ヤプリ共催：ディップ株式会社 / サイボウズ株式会社 / 株式会

こんにちは、ソフトウェアエンジニアの @ajfAfg です。弊社には複数のヘルプサイトが存在しますが、その一部を半年ほどで刷新しました。刷新と呼んでいますが、WOVN という多言語化用 SaaS の導入に加え、ヘルプサイトのコンテンツを作成するテクニカルライターの生産性向上を狙った取り組みも含まれていました。本稿では、刷新プロジェクトの中で私が担当した取り組みを紹介します。なお、本稿では特に断りがない場合、旧ヘルプサイトは刷新前のヘルプサイトを指し、新ヘルプサイトは刷新後のヘルプサイトを指すものとします。文脈から明らかな場合は単にヘルプサイトと書く場合もあります。目次目次背景刷新プロジェクトのスコープ刷新プロジェクトにおけるインフラのゴール旧ヘルプサイトのインフラ旧ヘルプサイトのインフラに関する技術的負債ほぼ全てのインフラが手動で構築されていたテストや監視がなかったリージョン間の意図しない差分が多かった事前調査および技術選定コンテンツ管理システム静的サイトジェネレーターホスティングサービスクラウドベンダーインフラ構築WOVN 導入WOVN 導入のモチベーションWOVN の導入方法静的サイトの配信基盤の構築Netlify のリダイレクトの仕組み（redirects）の模倣redirects 速習リダイレクトの基本リダイレクトを強制する404 リライト200 リライトパスを展開する新ヘルプサイトにおける redirects の実装新ヘルプサイトにおける独自仕様WOVN プロキシへのリライトredirects を模倣する仕組みのパフォーマンス登場人物がやや多い理由CloudFront のオリジンとして S3 を設定しない理由DynamoDB の役割検索基盤の構築検索基盤の仕組みGoogle 検索に似るシンタックス・セマンティクスで検索可能にする仕組みプレビュー環境の構築プレビュー環境の要件プレビュー環境の仕組みプレビュー環境の認証監視基盤の構築Terragrunt を用いた Terraform コード設計インフラの要求Terraform コード設計Lambda 関数のコード設計今回の設計で良かったこと・悪かったことテクニカルライターの生産性向上textlint の導入textlint によるリンク切れチェックの仕組みtextlint のプラグイン開発ヘルプサイトを Git