kintone Androidチーム配属1年目を振り返る、サイボウズ新卒エンジニアのブログ

記事のサマリー（TL;DR）

• サイボウズのkintone Androidアプリ開発チームに2025年7月配属の筆者（25新卒入社）が、配属から約1年間に担当した機能開発と、その中で得た学びを振り返った記事です。
• 担当した開発には、PDFプレビューの文字検索追加、検索AI（kintone AI）の実装、書類スキャン機能の追加、レコード一覧分析AIの実装などがあります。
• 印象に残った仕事として書類スキャン機能での自動テストの考え方、最も苦労した仕事としてkintoneのWebフロントエンド・バックエンドにもまたがったレコード一覧分析AIの実装を挙げています。

詳細

はじめに

筆者は25新卒入社で、kintoneのAndroidアプリ開発チームに所属する市村氏です。本記事は2年目になった筆者が1年目を振り返る内容で、CYBOZU SUMMER BLOG FES ’26の記事として公開されました。筆者は、1年目のロールモデルの一例として参考になること、またkintone Androidチームがどのようなチームかを知ってもらうことを目的としているとしています。

筆者は2025年7月にkintone Androidチームに配属されました。サイボウズでの社員歴は1年半に迫っていますが、配属を基準にすると約1年が経過しているため、本記事は2025年7月から現在までの内容が中心になっています。

配属から現在までに関わった機能開発

配属からこれまでに取り組んだ機能開発は以下の通りです。

入社当初は業務コードに触れた経験がなく、最初はモブプログラミングでほとんど指示通りに動くだけの状態だったといいます。検索AIの開発に着手したあたりで慣れてきて、一人でタスクを進めることが増えたとしています。

印象に残った仕事：書類スキャン機能の追加

開発業務の解像度が一気に上がったのは、書類スキャン機能の実装だったといいます。着手は2026年2月頃で、一人でタスクを回し始めた時期にあたります。

このタスクで初めて自動テストと向き合ったとのことです。筆者は、AIでテストを簡単に生成できる現在でも、そのカバレッジや保証の仕方が適切かを見極めるのは難しいと述べています。自動テストがないと自信を持って機能追加や変更ができない一方、テストが多すぎればCIのたびに時間がかかり、不安定なテストの割合も増えるとしています。

何を保証すべきかは、壊れた時のリスクと、テストの実装・保守コストのバランスで判断するとし、リスクはユーザーの利用頻度とビジネス的な影響度を加味して判断する必要があるため、どの機能がどの程度重要かをチーム内で議論したと説明しています。

この経験から筆者は、自動テストはコードベースにあるものだからといってソフトウェアエンジニアが単独で決めるものではなく、「プロダクトとして何を保証するか」という方針とセットで決まるべきものだと再認識したと振り返っています。設計判断の文脈ではプロダクトの性質や戦略とセットで判断する必要があると知ってはいたものの、テストに対する考えが浅く、別々に考えてしまっていたと述べています。この頃から、自動テストを含む実装判断を局所的にではなく、より俯瞰した視点で検討する意識を持つようになったとしています。

一番苦労した仕事：レコード一覧分析AIの実装

最も苦労した仕事はレコード一覧分析AIの実装だったといいます。このタスクはAndroidアプリだけでなく、kintoneのWebフロントエンド・バックエンドにも関わる、kintoneプロダクト全体にまたがるものでした。なぜAndroid以外の開発に関わったのかについては、別記事「AndroidのWebViewでJavascriptInterfaceを使うときの落とし穴」で説明しているとしています。

実装にあたっての壁は大きく3つあったといいます。

1つ目は要求される技術知識の拡大です。キャッチアップ量が多く、情報量に圧倒される状況だったとしています。使用言語、フレームワーク、アーキテクチャがAndroid開発とは異なるため、実装は事前にすり合わせて進め、実装中に生じた疑問は適宜質問や相談をして解決したとのことです。

2つ目は対人・組織的なコミュニケーションです。領域をまたぐことで関係者が一気に増え、疑問や相談の内容に応じて複数のチームへの相談が必要になったといいます。以前やりとりしたスレッドが埋もれ、どこで相談していたか分からなくなることもしばしばあったとのことです。筆者はこうしたコミュニケーションが苦手で、チームメンバーに助けてもらうことが多かったと述べています。

3つ目は開発基盤・プロセスの複雑さです。環境構築ではドキュメント通りに進まないことが多く、準備の段階で苦労したとしています。実装中はpushのたびに大量の自動テストが実行され、頻繁に失敗したため、原因究明に時間がかかったといいます。

やり始めて初めてわかる困難が多かったため、気づいたことを共有してチームの知見として蓄積したとのことです。AI環境の整備が進んでいたことで、キャッチアップ自体は効率的に進められたとしています。時間はかかったものの、最終的には乗り越えてリリースまで完了できたと述べています。

2年目のいま、これから

2年目になり、重たいタスクにもアサインされて取り組むことが増えたといいます。やること自体は変わっていないものの、タスクの中でできることは増えているとしています。チームからは、少しレベルの高いことに挑戦して失敗し、そこから学びを取り込むというプロセスを多めに与えられている実感があると述べています。

これからの目標として、kintoneのWeb側の開発に慣れることに加え、1年目で感じた課題に向き合っていきたいとしています。技術面では、プロダクトの性質を含めた様々な視点を加味して実装判断ができるようになりたいとしており、技術を支えるチームのプロセスについても改善案を出して貢献したいと述べています。1年目で得た学びを糧に、2年目もプロダクトとチームの両方に向き合いながら、できることを着実に増やしていくとしています。