記事のサマリー(TL;DR)
- サイボウズ新卒QAエンジニアが、1年間でプロセス改善・不具合対応・AI活用に取り組んだ実務を公開
- Claude Skills と kintone MCP サーバーを連携し、複数アプリをまたぐ定常業務を自動化
- JaSST’26 Tohoku への初登壇やブログ2本執筆など、社外アウトプットも1年目から積極的に実施
kintone × Claude MCP 連携を実務に使う日本企業が注目すべき点
本記事はサイボウズ社内の実践事例であるが、kintone の MCP サーバーを Claude と接続して複数アプリをまたぐ業務フローを自動化したという内容は、kintone を業務基盤として使う国内企業にとって再現性の高い事例だ。
kintone のデータはアプリ単位で分散しがちであり、複数アプリをまたいだ作業には従来は手作業が伴っていた。Claude の Skills 機能にフロー全体を登録し、MCP 経由で kintone と接続することで「見落としがちな作業手順の自動実行」と「類似不具合の横断検索」を実現している点は、QA 部門だけでなく情シス・業務改善担当者にとっても参考になる構成だ。
特に、kintone 上で管理しているタスク・不具合・リリースフローのような定型業務に対して、Claude を起点に複数アプリを横断操作するパターンは、専用 UI を持たない中規模の業務システムにそのまま適用できる。「Skills に手順書を丸ごと登録する」というアプローチは、LLM にプロセスを覚えさせる最も手軽な方法の一つとして注目に値する。
詳細
はじめに
サイボウズの QA(品質保証)エンジニア・すずりん氏は、入社から1年とちょっと、Garoon の品質にかかわる Spica チームに所属し、品質基準の見直しや社内外から報告された不具合の再現調査・不具合登録を担当している。
「入社前は1年後の業務が全く想像できなかった」という経験から、配属から1年間で経験した業務をタスク記録をもとに振り返る記事を、CYBOZU SUMMER BLOG FES ’26 の一環として公開した。
1年間のタスクを振り返る
日常のタスクは個人の kintone アプリで管理している。進行状況・カテゴリー・作業日時・作業履歴を記録し、優先順位を可視化する構成だ。タスクの粒度は「1日で終わる程度」を意識して登録している。
1年間のタスクをカテゴリー別に集計すると、プロセス改善タスクと不具合関連タスクがほぼ同じ割合を占めた。事務作業や学習は細かい粒度で登録しているため、件数の割に実働時間は少ない。
普段の1日の過ごし方
| 時間 | 内容 |
|---|---|
| 9:30 | 始業。通知確認と当日タスクの優先順位付け |
| 10:00 | チーム朝会。終了後は定常業務や継続タスクに着手 |
| 12:00 | 昼休憩 |
| 13:00 | 問い合わせ対応・レビュー返信 |
| 14:00 | ミーティングがない日は深く考えるタスクに集中 |
| 16:00 | デイリーリファインメント |
| 17:00 | リファインメント後、タスク継続 |
| 18:30 | 終業 |
最近はミーティングよりも個人で進めるタスクのほうが多く、午後に集中タイムを設けている。
印象に残ったタスク
1. 不具合改修のオーナー業務
Garoon では、機能開発をベトナムチームが担当している。日本チームはオーナーとして「どの不具合をどのように改修するか」を決定し、実装・テストをベトナムチームに依頼する体制だ。
単純な不具合の場合の改修フローは比較的シンプルだが、リリースノートや KB(https://kb.cybozu.support/)への掲載が必要な不具合・脆弱性不具合については、関係チームへの連絡・文言作成・改修内容確認が加わり、フローが大幅に複雑化する。
新人として一から学び始めた際、このフローは先輩から口頭で教わるものだった。そこで学習を兼ねてフローをドキュメントに整理したところ、関係チームと手順の多さを改めて実感したという。
不具合修正後にはデグレ(他箇所への影響)が発生していないか、期待結果が正しく担保されているかの確認も必要であり、単純な「直す」作業以上の工程が含まれている点も整理して初めて明確になった。
2. リリース基準の改善
定期リリースごとに確認しているリリース基準を、「目的から見直す」アプローチで再整理した。この活動はブログ記事「目的から見直すリリース基準の改善活動」として公開済みであるほか、JaSST’26 Tohoku での登壇資料(Speaker Deck)にもまとめられている。
「なぜこの基準が存在するのか」という問いから出発し、リリース基準の根拠を言語化したこのプロセスは、多くの開発現場で暗黙知になりがちな品質基準の形式知化という観点から参考になる。
3. AI 活用:Claude Skills × kintone MCP で業務フローを自動化
社内での Claude Code 導入の進展に伴い、Claude の Skills 機能を使った業務効率化に取り組んでいる。
具体的な活用内容は以下の2点だ。
① 不具合改修フローの Skills 化
前述の複雑な不具合改修フローを丸ごと Skills に登録することで、見落としがちな作業手順を確実に実行できるようになった。
② 類似不具合の横断検索の Skills 化
ある機能で発見された不具合が、類似する他機能でも発生していないかを探す作業を Skills 化した。以前より効率的に横断検索できるようになったという。
さらに、kintone の MCP サーバーを Claude と接続することで、複数の kintone アプリをまたいだ定常業務の自動化にも成功している。kintone MCP サーバーについては公式の cybozu developer network にも詳細が公開されている。
4. 社外発信・勉強会への参加
「分かった気になっていたことを明確にするために、学んだことを自分の言葉で発信する」という方針のもと、1年目から積極的に社外アウトプットを行った。
社外イベント参加
- JaSST’26 Tokyo
- スクラムフェス新潟 2026
- WACATE 2026 夏
社内勉強会・イベント
- 開運冬まつり QA エンジニアセッションで発表
アウトプット活動
- ブログ執筆 2本(「未経験25卒 QA エンジニアがチームで業務を担当するまで」「目的から見直すリリース基準の改善活動」)
- JaSST’26 Tohoku 登壇(初の社外登壇):登壇資料「新卒1年目 QA がリリース基準の”なぜ”をたどってみた」を Speaker Deck で公開
- JaSST’26 Tohoku 参加レポートのブログ執筆
できるようになったこと・挑戦していること
この1年で、担当領域の業務を一人でこなし、改善提案や他チームへの連絡・告知を行う経験を積んだ。
一方で「渡されたタスクをこなす」フェーズから、「なぜこの検証をこのタイミングで行うのか」という大きな問いから改善活動を設計するフェーズへ移行しつつあり、大きなタスクの進行順序の整理が現在の課題の一つだという。
対応策として取り組んでいるのが、問いを具体的なタスクに分解してから実行するアプローチだ。「何がクリアされればこの検証の目的は果たされているか」「そのためになぜこの基準が有効なのか」という問いを、実際に手を動かせる粒度に先に分割することで、作業中にゴールから逸れないよう工夫している。
脇道で気になった問題は、タスクアプリに「👀気になる」というステータスで保留する仕組みを用意し、後で取り組めるよう管理している。
まとめ
1年間を振り返ると、プロセス改善・不具合改修オーナー業務・AI 活用・社外発信と、幅広い種類のタスクを経験できた。フロー改善や改修オーナー業務はチーム外の関係者への考慮事項が多く、成長の機会が多かったとしている。
今後は、フロー改善の具体化・不具合分析への取り組みを通じて、Garoon の品質向上に貢献していく方針だ。