QUO CARD Digital Innovation Lab Tech Blog

クオカード デジタルイノベーションラボの技術ブログです

固定記事:クオカード デジタルイノベーションラボについて(リンク集)

本記事では、クオカード デジタルイノベーションラボにご興味をお持ちの方向けに、参考になりそうな情報をまとめました。 気になる情報があれば是非ご覧いただけますと幸いです。

(最終更新日:2025/10/27)

クオカードデジタルイノベーションラボ採用LP

quo-digital.jp

プロダクト

www.quocard.com

2025年の組織体制について

目指す姿・方向性と進め方

技術スタック

開発の進め方

働く環境

勉強会

技術ブログ

メンバーアンケート

メンバーインタビュー

採用関連情報

open.talentio.com

「裁量ある環境」「学び続けられる環境」を求めて転職した、運用エンジニアKさん入社1年の歩み

こんにちは! クオカード デジタルイノベーションラボ(以下ラボ)採用担当の金子です。今回は、運用チームのKさんにインタビューを行いました。入社の決め手から日々の業務、そして今後の挑戦まで、たっぷりお話をお伺いしました。ぜひ最後までご覧ください!

自己紹介

ー自己紹介をお願いします!

2024年9月に運用エンジニアとして入社したKです。現在は静岡からフルリモートで勤務しており、夫と猫との3人で暮らしています。これまでは、金融系システムのバックエンド開発や、化学メーカーでのユーザサポート、損害保険会社でのバックエンド開発保守などに携わってきました。趣味は猫と戯れることと野球観戦です。

転職のきっかけ・転職軸

ー転職を考えたきっかけや、転職の際に重視した点について教えてください。

転職のきっかけは、夫の地方移住希望です。前職が都内へのフル出社だったので、働き方を見直し、フルリモートが可能な企業への転職を検討し始めました。

ただ、「フルリモートだから」というだけで決めるのではなく、仕事内容や働く環境も重視したいという思いが強くありました。

重視した軸は、主に以下の2点です。

1. 属人化している環境ではなく、裁量をもって働きたい

2. 新しいことを学び続けたい

前職ではある程度決まったレールの中で作業を進めることが多かったため、裁量を持てる環境と、新しいことを学び続けられる環境を求めていました。これまでの経験を活かせる運用ポジションを中心に、これらの軸を満たせる職場を探しました。

入社の決め手

ークオカードに入社を決めた理由について教えてください。

テックブログの記事や選考を通して、自分の転職軸が叶えられると感じたことが決め手です。

特に「自己管理できる組織を目指している点」や「メンバーが主体的に進めている環境であること」を知り、この組織で成長したいと感じました。

また、不安に感じていたフルリモートについても、15分ルール(15分考えてわからなければ質問する)やWorking Out Loud(自身の作業内容をオープンに発信する)といった進め方が根付いていることを確認でき、「ここなら大丈夫そう」と安心できたことも大きかったです。

関連記事:

入社後の印象とフルリモートへの適応

ー実際に入社されてみて、ギャップなどはありましたか?

ブログや面接で聞いていた通りだったので、ギャップはほとんどありませんでした。ただ、今まで経験したどの職場よりも、制度や進め方に独自性があるなと感じました。

特に良いと感じているのは、独自の評価制度によって、より本質的な作業に集中できるようになった点です。以前の会社では目標設定や評価面談にかなりの工数を割いていましたが、ラボではその工数を削減し、本来の作業に集中できています。

また、スピード感にも驚きました。より課題解決に繋がる方法があれば、すぐに改善される文化です。 例えば、チケット管理一つをとっても、リマインダーで十分とチームで判断すれば、翌日には運用が変わりました。

関連記事:

ーフルリモートへの適応はどうでしたか?

当初は少し不安もありましたが、すぐに困っても声をあげられる安心感を感じました。これは、15分ルールWorking Out Loudが、本当にそのまま運営されているおかげだと感じています。

最初は「こんな些細なことを聞いて大丈夫かな」と躊躇することもありましたが、他の人も積極的に質問していて、質問自体が歓迎されている雰囲気を強く感じました。「早めに聞いたり相談するほうがスムーズ」だと気づき、今では躊躇することなく何でも聞けるようになりました。

担当業務・1日の流れ

ー現在の担当業務について教えてください。

QUOカードPayのシステムの運用、監視、障害対応、問い合わせ対応、運用設計などを担当しています。

システム全体を俯瞰的に見る場面が多く、複数のシステム間の繋がりや、外部システム・データベースの関連を広く捉えるよう意識しています。

特に障害発生時には、単なるエラーログだけでなく、CPU使用率やトラフィック、過去の傾向など、広い視野で原因を特定するように努めています。

関連記事(同じく運用チームMさんのインタビュー):

ーこれまでのご経験が活かされている点はありますか?

ユーザサポートやベンダーコントロールの経験から、ゴールから逆算して全体を見通し、マルチタスクを進めていく対応力は運用チームで役立っていると思います。

また、バックエンドエンジニアの経験は、システムの大まかな処理の流れの理解や、エラー調査時の「あたり」を付けるのに役立っていると感じています。

ーラボでは、チームで成果を出すことを重視していますが、その中で意識されていることがあれば教えてください。

主に以下の2点を意識しています。

1点目は、オープンな議論の促進です。運用チームではイレギュラーな作業が多いこともあり、「どう進めるのがベストか?」とチームに問いかけ、意見を出し合う機会を設けています。これにより、メンバー全員の知恵を結集し、多角的な視点から最善策を見つけ出すことができていると感じます。

2点目は、属人化の防止です。作業経験のないメンバーにも「やってみませんか?」と挑戦してもらえるよう声をかけています。これにより、チーム全体のスキルセットと対応範囲が広がり、安定して成果を出し続けられる体制作りに繋がると考えています。

ー1日の流れについて教えてください。

ラボは裁量労働制を採用しているため、業務やプライベートの予定に合わせて柔軟に働くことができます。 私は基本的に8:00〜16:30の時間帯で勤務しています。

🕖7:00 起床

猫タイム(ごはんやブラッシング)と朝食。

🕖8:00 勤務開始

Slackやメール確認。タスクの棚卸しと目途立て、メインタスク対応。

🕖11:00 デイリースクラム

チーム内で進捗共有、相談、問い合わせ確認。割り込みタスクの確認も行う。

🕖13:00 昼食

お昼はSNSで見かけるズボラ飯を試したり、家にあるものでちゃちゃっと済ますことが多いです。

🕖14:00 勤務再開

🕖16:30 勤務終了

業務を終えたあとは、再び猫タイムや買い物、シーズン中は野球観戦を楽しみます。プレイボールから見れるのが嬉しいです。

大変だったこと・やりがいに感じること・成長した点

ー特に大変だったことについて教えてください。

入社後、直面した課題はAWS環境への理解でした。前職がほぼオンプレミス環境だったため、クラウドの経験が浅く、キャッチアップが必要でした。

入社後は、まず管理コンソールを触り、ドキュメントを読み込むところからスタートしました。本番環境のほかに自由に試用できる検証環境が用意されているため、手順に沿って挙動を確認しました。わからない点はメンバーに聞き、実践を通じて理解を深めていきました。

ーやりがいを感じるのはどんな時ですか?

まず大きな変化として、全てのタスクにおいて「自分で考えて仕事をする」ようになりました。目的や意味を深掘りし、不要な作業を削減することで、一つひとつのタスクをやりきった時にやりがいを感じるようになりました。

具体的なターニングポイントは、依頼されたクエリ作成への対応時です。当初、依頼通りに作成したクエリに対し、チームレビューで多角的な視点でフィードバックをもらい、依頼の背景にある真の目的まで深く考えられていなかったことに気づきました。

これを機に、依頼があった際は単に言われた通りに対応するのではなく、「何に使い、どう活かしたいのか」という目的まで深掘りし、依頼された範囲を超えて課題解決につながる提案を自ら行うよう意識が変わりました。

また、現在脆弱性診断の担当として、新しい知識を日々学べていることにも楽しさを感じています。診断企業の選定や、新しい検証環境での挙動確認など、常に新しい挑戦が続いていることにやりがいを感じています。

ー成長した点や、叶えられたことはありますか?

スキル面では、圧倒的に判断力や実行力が身についたと思います。「ある程度見通しがたったらやってみよう」と主体的に行動できるようになりました。

生活面では、プライベート時間が充実しています! 通勤時間がなくなり、好きなことに割ける時間が増え、念願の猫タイムも増えました(笑)その分、仕事にもより前向きに取り組めていると感じています。

今後挑戦したいこと

ー今後挑戦したいことはありますか?

今後挑戦したいことは大きく2点あります。

1点目は、運用全体の効率化を進めることです。チーム内の作業を自動化し、空いた時間を分析や改善に当てていきたいです。具体的には、ログやリソースをモニタリングし、課題の発見・対応することで、障害を未然に防ぐ体制を強化したいです。

2点目は、開発チームやインフラチームが本来の作業に集中できるように、現在他チームで発生している運用作業を巻き取っていくことです。最近、ライブラリ更新作業の移管を始めましたが、まだまだ効率化の余地があるので、自動化を推し進めたいと考えています。 ラボで導入しているAIツール(Claude、Devin、Geminiなど)を活用し、具体的な効率化を構築していけるような知見をつけていきたいです。

関連記事:

選考を考えている方へのメッセージ

ー選考を考えている方へメッセージをお願いします。

運用チームはQUOカード Payシステムの全体を俯瞰的に見ることが多く、日々新たな学びがあります。新たな知識を得ることが好きな方や、裁量を持って主体的に取り組みたい方におすすめできる環境です。

また、チームで協力し、活発な議論を通じてお互いに高め合えるような方に、是非きていただきたいです。

最後に

ここまでお読みいただき、ありがとうございました!

クオカードデジタルイノベーションラボでは、運用チームを始め各チームで新しい仲間を募集しています。 少しでも興味をお持ちいただけた方は、是非カジュアル面談でお話しましょう!

quo-digital.jp

RAGを用いた社内情報検索システムを構築した話

今回は、クオカード デジタルイノベーションラボ(以下ラボ)のインフラチームがRAG(Retrieval-Augmented Generation)を用いた社内情報検索システムを構築した話をご紹介します。

まだ構築したばかりで、これから本格的な効果測定を行う段階ですが、今回の記事が、これから社内RAGシステムの構築を考えている方の参考になれば幸いです。

RAGとは

RAG(Retrieval-Augmented Generation)は、大規模言語モデル(LLM)の弱点を補う技術です。LLMは汎用的な知識は豊富ですが、社内の特定情報や最新情報にアクセスすることはできません。 そこで、RAGは以下の2つのステップで、より正確な回答を生成します。

  • Retrieval(検索):質問に関連する社内ドキュメントや情報を検索する。
  • Generation(生成):検索で得られた情報を基に、LLMが回答を生成する。

これにより、LLMの持つ高度な文章生成能力と、社内ナレッジを組み合わせ、より正確で信頼性の高い回答を得られるようになります。

なぜRAGが必要だったのか?

ラボでは、作業手順や技術的な知見がBacklogのWikiに集約されています。

しかし、知りたい情報がどこにあるのかを探すのに時間がかかったり、そもそも「その情報があること」を知らなかったりすることが課題でした。また入力したキーワード次第で欲しい情報にhitしないという問題がありました。

そこで、自然言語で質問するだけで、関連情報を素早く教えてくれる仕組みがあれば、業務がもっと円滑に進むと考え、RAGの構築に着手しました。

構築の前提と方針

このプロジェクトのゴールは、社内ナレッジの検索効率を上げ、メンバーの生産性を向上させることです。実用に耐えるものが構築できるか不明だった為、何よりもスピード感を重視し、「まずは動くものを作り検証する」ことを最優先に進めました。 スピード感を出すために、以下の前提を設けました。

  • 対象データソース:ラボメンバー全員が閲覧可能なBacklog Wiki
  • 利用者:ラボメンバーのみ
  • 環境AWSの既存ステージング環境
  • 目標:1〜2週間でSlackから質問できる状態にする

構築ステップと技術選定

構築は以下の4つのステップで進めました。基本的にTerraformで構築し、一部手作業が必要な部分は手順書を作成することで、属人化を防ぎました。またセキュリティ面を考慮し、IAMロールなどに設定する権限は必要最小限に抑えました。

1. Backlog WikiデータのS3への配置

  • 作業期間:1日

  • 内容:Backlog APIを利用し、Wikiの全ページを取得してS3バケットに配置する(1wiki1ファイル)Lambda関数を作成しました。

  • ポイント:ファイル分割や差分取得は後回しにして、まずは全量取得することで、次のステップに早く進むことを優先しました。

  • 余談:Lambdaを実行したところ取得できたWikiページが1000件で、実装ミスを疑いましたが本当にぴったり1000件でした。

2. RAGシステムのコア部分構築

  • 作業期間:3日

  • 構成Amazon Bedrock Knowledge BaseOpenSearch Serverlessを組み合わせました。この構成を選んだ理由は、以下の通りです。

  * 構築の手間が少ない: Bedrock Knowledge Baseは、S3のデータを指定するだけで自動的に埋め込み(Embedding)を生成し、ベクトルデータベースに格納してくれます。

  * 運用が楽OpenSearch Serverlessも同様に、インフラ管理の手間が少ないマネージドサービスです。コストが安いAurora(+pgvector)を使う方法も検討しましたが、構築・運用の手間を考慮し、OpenSearch Serverlessに軍配が上がりました。

  * 高い親和性AWSのサービスで統一することで、連携がスムーズになります。

  * ハイブリッド検索に対応:Bedrockが自動でベクトル検索とキーワード検索を組み合わせたハイブリッド検索を行うことで、検索精度向上が期待できます。

3. データの定期更新仕組みの構築

  • 作業期間:1日

  • 内容:Backlogの更新分を定期的に取得し、S3にアップロードしKnowledge Baseにデータ同期する仕組みを構築しました。これにより、RAGの知識も常に最新の状態に保たれます。

  • ポイントAmazon EventBridge Schedulerを利用して、Lambdaの実行とKnowledge Baseの同期を自動化しています。

4. Slack連携

  • 作業期間:2日

  • 内容:特定のプライベートチャンネルでRAGへの質問を受け付け、回答を返す仕組みを実装しました。これにより、質問のハードルが下がり、ラボメンバーが気軽に使えるようになりました。

  • ポイントhttps://docs.aws.amazon.com/chatbot/latest/adminguide/connect-bedrock-agents.htmlBedrock AgentAmazon Q Developerを利用する方法で、ノーコードで構築できました。

  • 余談:スレッド内で会話を続けようとするとBedrock Agentから反応がなかったのですが、AWSサポートに問い合わせて、チャンネルへの投稿を選択せずに「@Amazon Q」をメンションすることで会話を続けられることが分かりました。

費用

試算すると月額約$380(約57,000円)でした。これは主にOpenSearch Serverlessの利用料です。構築後に実際に発生したコストを見た感じでは、試算を超えることはなさそうでした。

活用状況

運用開始から2週間で、39件のやり取りがありました。いくつかの事例をご紹介します。

1.「SESのバウンス率増加時の対応」

Backlogの検索では「バウンス率増加」で0件、「バウンス率」で10件ヒットしました。

RAGに質問したところ、関連するWikiページを即座に提示してくれたため、必要な情報にたどり着くまでの時間を大幅に短縮できました。

2.特定の電文種別に関する処理

Backlogで「IF XXX(該当のI/F名)」を検索すると14件ヒットし、目的の情報を見つけるまでに時間を要しました。

RAGに質問した結果、求めていた処理内容を直接教えてもらい、スムーズに作業を進めることができました。

これらの事例から、質問内容によっては、RAGが情報検索の効率を大幅に向上させる場合があることが確認できました。

まとめと今後の展望

今回の構築で、「小さく始めて、素早く検証する」ことの重要性を再認識しました。

短期間で動くRAGシステムを構築できたことで、今後の改善や拡張に向けた良いスタートを切ることができました。

今後は、以下の点を検討していく予定です。

  • 精度調整:より正確な回答ができるよう、チューニングを進めます。Knowledge BaseやBedrock Agentの設定など深く考えられていないので、改善の余地は多いと思っています。

  • 他データソースへの拡張:必要に応じて、Backlog Wikiだけでなく、Google Driveなど、他のナレッジソースも取り込むことを検討します。

  • 社内への展開:今のところラボメンバーのみを対象としていますが、ラボ内で効果があれば、社内全体に展開し、組織全体の効率化に貢献したいと考えています。

最後に

ここまでお読みいただきありがとうございました!

ラボでは、AIツールなどの新しい技術を積極的に取り入れながら、チームで協力して課題解決に取り組むカルチャーを大切にしています。

そんな環境の中で、私たちと一緒に成果を最大化してくれる仲間を募集中です。 少しでも興味をお持ちいただけた方は、ぜひカジュアル面談でお話しましょう!

quo-digital.jp

3人の子育てとキャリアを両立!ママエンジニア Kさんのラボでの挑戦と成長!

こんにちは!

クオカード デジタルイノベーションラボ(以下ラボ)採用担当の金子です。今回は、新規開発チームのKさんにインタビューを行いました。 入社の決め手から日々の業務、子育てと両立する働き方のリアルまで、たっぷりお話をお話を伺いました。ぜひ最後までご覧ください。

自己紹介

ー自己紹介をお願いします。

2024年8月に入社したKです。 前職では、主に複合機関連のソフトウェア開発に携わっていました。 現在は宮崎からフルリモートで勤務しており、夫と3人の子ども、2匹の猫たちと暮らしています。 趣味はドラマや映画の鑑賞で、社内で専用の雑談チャンネルを立ち上げ、みんなでおすすめを共有しあったりしています。

転職のきっかけ・転職軸

ー転職を考えたきっかけや転職の際に重視した点について教えてください。

1番下の子が小学生になったらフルタイムで働きたいと考えていたのですが、前職では勤務時間の自由度が低く、子育てとの両立が難しいと感じていました。そこで、柔軟な働き方ができる環境への転職を決意しました。

転職の軸は、この働き方の実現に加え、2つの点を重視しました。

1つは、要件定義や設計といった上流工程にチャレンジできることです。これまでは指示されたものを作ることが多かったので、「何を作るか」という段階から関わりたいと考えていました。

もう1つは、ユーザーとの距離が近い環境であることです。自分が開発したものがどのように使われ、ユーザーにどう届いているのかが見えにくかったため、自社サービスを通してユーザーの反応を直接感じながら、開発に取り組みたいと思っていました。

入社の決め手

ークオカードに入社を決めた理由について教えてください。

テックブログの記事や選考を通して、自分の転職軸が叶えられると感じたことが決め手です。

特に、「脱社内外注」への取り組みに強く惹かれました。開発の上流から深く関わりたいと考えていた私にとって、「エンジニアはシステムを作る存在ではなく、顧客(利用者)の課題を解決する存在」という考え方は非常に魅力的でした。

また、ブログで、実際に子育て中のメンバーが柔軟な働き方をしている様子を知り、ここなら安心して働けると感じたことも大きな決め手となりました。

関連記事:

入社後の感想・ギャップ

ー実際に入社してみてどうでしたか?

転職で求めていた、働き方の柔軟さ上流工程への関わりユーザーとの距離の近さは、すべて実現できていると感じます。上流工程の業務は今も勉強中ですが、とても面白いです。

良い意味でのギャップだったのは、スピード感が非常に速いことです。生成AIツールなどの導入や技術選定がスピーディで驚きました。 また、アジャイル開発でのリリースの速さにも驚きました。最初のリリース時は「本当に大丈夫かな?」と少し不安でしたが、チームメンバーが一緒に立ち会ってくれたので、不明点を確認しながら進めることができ、安心しました。

ーフルリモートでの働き方にはすぐに慣れましたか?

入社前は、フルリモートでうまく仕事を進められるか不安もありました。しかし、ラボには「15分考えてわからなければ質問する」というルールがあり、実践してみると、皆さんとても丁寧かつ迅速に答えてくれるので、すぐに不安は解消されました。

また、自身の作業内容をオープンに発信する「Working Out Loud」にも徐々に慣れてきました。自分の作業を可視化することで、チームメンバーが状況を把握しやすくなり、チーム全体の連携がスムーズになっていると感じています。

関連記事:

担当業務・1日の流れ

ー現在の担当業務について教えてください。

現在は新規開発チームに所属し、新規開発を担当しています。社内の各部署と連携し、要件の検討やスケジュールの調整を行う機会も多いです。

業務を進める上では、少しでも疑問に思ったことは、「15分ルール」に則って確認することを徹底しています。「これで合ってるだろう」と自己判断で進めて、後で認識のずれが生じないよう気をつけています。

また、コミュニケーションはテキストが中心のため、相手がひと目で理解できるよう工夫しています。具体的には、太字で強調したり、箇条書きにしたり、イメージ画像を添付したりして、簡潔に意図を伝えることを心がけています。

一1日の流れについて教えてください。

ラボは裁量労働制を採用しているため、業務やプライベートの予定に合わせて柔軟に働くことができます。 私は子どもたちの準備を終えて学校に送り出した後から仕事を始め、夕方は習い事の送迎や夕食の準備に充てられるよう、基本的に8:00〜16:30の時間帯で勤務しています。

以下は、ある1日のスケジュールです。

🕖5:00 起床

最近は健康のため、20〜30分ほどウォーキングやジョギングをしています。

🕖 〜7:30 子どもたちの準備

朝食の準備などを行い、学校へ送り出します。

🕖8:00 勤務開始

🕖11:00 デイリースクラム

チーム内で進捗を共有したり、相談事項や問い合わせの確認を行います。

🕖12:00 昼食

録画してあるドラマなどを見ながら昼食をとります。

🕖13:00 勤務再開

🕖16:30 勤務終了

業務を終えたあとは、子どもの習い事の送迎や夕食の準備をします。 子どもの用事があるときは、 勤務時間を早めたり、中抜けしたりと、柔軟に働くことができています。

大変だったこと・やりがいに感じること・成長した点

ー特に大変だったことについて教えてください。

最も大変だったのは、ドメイン知識の習得と業務理解です。 専門用語が多く、新規開発のためインプットすべき情報や決めるべき事が膨大で、今も全体像を把握するのが難しいと感じています。しかし、業務を深く理解しなければ、求められているものや提供すべきものがわからないため、不明点は確認しながら、一つずつ理解するよう努めています。専門用語については用語集を活用し、インプットしています。

もう一つ大変だったのは、AWS周りのキャッチアップです。 転職活動中にAWSの入門資格は取得したものの、業務での使用経験はありませんでした。入社後は、実際のシステムを見ながら、不明点があれば都度調べて質問し、少しずつ理解を深めていきました。

ーやりがいを感じる瞬間について教えてください。

ユーザーや他部署の方から直接フィードバックをもらえる時に、大きなやりがいを感じます。現在は新規開発を担当しているため、エンドユーザーからの声はこれからですが、以前、他部署の方から「クエリを改善してほしい」と依頼を受け、背景や課題をヒアリングしながら対応したところ、「とても使いやすくなった」と言われ、嬉しかったです。

また、チームで働くことにやりがいを感じています。現在はチーム一丸となって新規開発に取り組んでおり、同じゴールに向かって進んでいる感覚がとても楽しいです。一人で黙々と作業するよりも、チームで協力して何かを成し遂げる方が好きなので、大きなやりがいにつながっています。

ー転職により成長を感じた点はありますか?

前職では「これを作ってください」と言われたものをそのまま作ることが多かったのですが、現在は要件定義や設計といった上流工程から携わることで、「何のために作るのか」「何が課題で、解決のためにはどうするのが良いのか」という視点で考える重要性に気づくことができました。経験豊富なメンバーの進め方を見て学ぶ中で、想像力や広く物事を見る力の必要性を実感し、少しずつではありますが、そうした視点を持てるようになってきたと感じています。ただ、まだ十分とは言えないため、日々意識して取り組み、さらに成長していきたいと考えています。

また、AWSや外形監視システムなど、これまで触れる機会がなかった新しい技術にも触れ、少しずつ知識を身につけている状況です。実際に手を動かしながら学ぶことで、徐々に理解が深まってきていると感じます。

知識を深めるためには、積極的に質問したり、ACM's O'Reilly Online Learning Platformを活用して関連書籍を読んだりしています。さらに、週に一度の勉強会で学んだ内容を、後で自分で深掘りすることもあります。

関連記事:

今後挑戦したいこと

ーさらに今後挑戦したいことはありますか?

チームとしては、新規開発のリリースに向けて、引き続き属人化しない仕組みづくりを継続していきたいです。これからさらに新しいメンバーが増えても、密な情報共有を行うことで、誰かが急に休んでも問題なくチームで成果を出せる状態を維持していきたいと考えています。

個人的には、バックエンド開発がメインの経験なので、フロントエンド開発にも挑戦したいです。以前、社内向けの管理画面で少し経験しましたが、今後より本格的な機会があれば、ぜひ手を挙げてみたいと思っています。

選考を考えている方へのメッセージ

ーラボへの選考を考えている方へメッセージをお願いします。

子育てをしていると、様々な理由でキャリアを諦めてしまう場面が増えてくると思います。しかし、ラボは「それでもキャリアを諦めたくない」という思いを持つ方にとって、働きやすい環境です。 柔軟な勤務体制はもちろん、業務が属人化しない仕組みが整っているため、急な休みや中抜けにも対応することができます。そのため、仕事と子育てを無理なく両立することができます。

働きやすい環境の中で、チームで成果を出していきたいという意欲のある方に、ぜひ来ていただきたいです。

最後に

ここまでお読みいただき、ありがとうございました!

クオカード デジタルイノベーションラボでは、新規チームを始め各チームで新しい仲間を募集しています。 少しでも興味をお持ちいただけた方は、是非カジュアル面談でお話しましょう!

quo-digital.jp

クオカード デジタルイノベーションラボにおけるAIツールの導入方針、活用事例、今後の展望について

本記事では、クオカード デジタルイノベーションラボ(以下、ラボ)におけるAIツールの導入方針、活用事例、今後の展望についてご紹介します。

導入方針

室長主導でスムーズな導入

ラボでは、室長の齋藤が中心となり、AIツールの導入を推進しています。

齋藤は技術動向に常にアンテナを張り、有望なサービスがあれば即座に導入を検討し、メンバーに共有のうえ導入を進めています。 これにより、通常は複数の部署を経ることが多い承認プロセスも、最小限の調整でスピーディーに進められています。

また、AI分野は変化が速く年間投資額を事前に決めにくいため、都度社長に確認する形になりましたが、即確認してもらえるので、迅速な導入が実現しています。

さらに、ツール導入に必要な事務手続きは事務担当が代行する事で、担当者の負担を減らし、導入プロセス全体を円滑に進めています。スピード感を妨げる社内ルールの見直しも行い、ボトルネックを解消することで、迅速な導入を実現しています。

関心のある人から試し、課題解決に繋がりそうなものを取り入れる

新しいツールは、まず関心を持ったメンバーがトライアルから始めています。 実際の業務で使ってみて効果を検証し、「課題解決に役立つ」と判断できたものを正規採用しています。

この方法により、現場のニーズを反映した導入が可能になり、メンバーも納得感を持って活用を始められています。

現在の導入状況

以下のようなAIツールを導入し、それぞれの特性に応じた使い分けを進めています。

  • ChatGPT(2025/8で利用終了、Gemini、Claudeに移行)
  • Cursor(2025/9で利用終了、Claude Codeに移行)
  • Gemini
  • Devin
  • Claude
  • Claude code
  • Circleback
  • RAGを活用した内製ツール(効率的な情報検索を実現するため、ナレッジ共有に利用しているBacklogのWikiと連携)

これらの活用方法などについては、以下の記事で紹介しています。

活用する上で意識していること

ラボでは、AIツールは万能ではないことを前提に活用しています。 得意・不得意や自動化できること・人の判断が必要なことを理解し、エンジニアが出力を確認・補完しながら作業を進めています。

現時点のAIツールは、人の作業を効率化したり、人の能力を拡張するための補助ツールとして位置づけています。この前提を踏まえ、業務内容に応じて最適なツールを選び、効果的な活用方法を模索しています。

さらに、出力の確認方法や活用結果をチーム内で共有し、知見を蓄積することも意識しています。

効果的な活用に向けた取り組み

導入したツールを効果的に活用するため、次のような取り組みを行っています。

活用ルールの策定

安心して利用できる環境を整えるため、以下のようなAIツールを活用した開発ルールをBacklogのWikiに明記しています。ルールは利用ツールや業務状況に応じて随時更新しています。

  • AIの出力は、常に自分の意図と照らし合わせて検証すること
  • コードレビュー依頼を出す前に不明点が無くなるまでセルフレビューすること
  • 理解していないコードはマージしないこと

AI利用時に良い結果を得るための工夫

ラボでは、意思決定の際に「クネビンフレームワーク」を参考にしています。込み入った領域の課題に対しては、AIツールを調査ソースや壁打ち相手として活用しています。ただし、指定をしないと発言を全肯定してしまうことがあるため、以下の条件を指示に含めるか、デフォルト設定にしています。

  • Constructive & Critical – 客観的で根拠ある分析を行う
  • Evidence-Based – 信頼できる情報源に基づく
  • Up-to-Date – 最新の確かな情報を使用する

これにより、より正確で信頼性の高い情報を得やすくしています。

参考記事:

ナレッジ共有によるAIツールの活用促進

ラボでは、AIツールの活用に関する知見を広げ、チーム全体の生産性向上を目指して、以下のナレッジ共有に取り組んでいます。

1. 参考書籍の共有

AIツールの活用知見を深めるため、チームで参考書籍を共有しています。直近では「Beyond Vibe Coding」の読書を推奨し、その要約をWikiにまとめています。 ラボでは「ACM’s O'Reilly Online Learning Platform」を導入しているため、メンバーはいつでもオライリーの書籍を閲覧できます。

関連記事:

2. 日常的な情報共有

Working Out Loud」を通じて業務内容を可視化したり、「15分ルール」に基づきSlackのヘルプチャンネルで気軽に相談できる環境を整備しています。これにより、成功体験だけでなく失敗からの学びもチーム全体で共有し、AIツールとのより良い付き合い方を模索しています。

関連記事:

こうした日常的なナレッジ共有を通じて、ツール導入の効果を最大化し、チーム全体の生産性やスキル向上につなげています。

今後の展望

The End of Programming as We Know It」で語られるように、AIの進化により、エンジニアの役割は「コードを書く人」から「AIと協働してソフトウェアを作る人」へと進化しています。

ラボでは、以前の記事「脱社内外注を進めています」で述べた通り、「エンジニアは顧客(利用者)の課題を解決する存在である」という考え方を大切にしており、この価値観はAI時代においてさらに重要性を増すと考えています。

AIは日々進化しており、最適なツールは状況によって変わります。そのため、ラボでは目的に応じたツールの柔軟な使い分けを進め、人がより戦略的・創造的な業務に集中できる体制づくりを目指しています。

最後に

ここまでお読みいただきありがとうございました!

ラボでは、AIツールなどの新しい技術を積極的に取り入れながら、チームで協力して課題解決に取り組むカルチャーを大切にしています。

そんな環境の中で、私たちと一緒に成果を最大化してくれる仲間を募集中です。 少しでも興味をお持ちいただけた方は、ぜひカジュアル面談でお話しましょう!

quo-digital.jp

「ユーザーに近い環境で開発したい」という想いを実現し、価値創出に向けて奮闘する豊永さんの挑戦

こんにちは!

クオカード デジタルイノベーションラボ(以下ラボ)採用担当の金子です。

今回はPayチームの豊永さんにインタビューを行いました。 入社の決め手や日々の業務、働き方についてお話を伺いましたので、ぜひご覧ください。

自己紹介

ー自己紹介をお願いします。

2024年6月に入社した豊永です。

前職では、主にEC基幹システムなどの受託開発に携わっていました。

現在は福岡からフルリモートで勤務しており、妻と2歳の娘と暮らしています。

趣味は、気になる技術系イベントへの参加や、娘と遊ぶことです。 最近はPostmanのイベントや、ラボの技術顧問・川島さん主催の「アーキ部」にも参加しました。 娘の成長にあわせてアウトドアの機会も増え、自分の体力も自然と鍛えられてきたように感じています。

関連記事:

転職のきっかけ・転職軸

ー転職を考えたきっかけや転職の際に重視した点について教えてください。

前職では受託開発が中心でしたが、よりエンドユーザーに近い環境で開発がしたいと考え、転職を決意しました。

転職の軸としては、以下の3点を重視していました。

1つ目は、「自社でサービスの開発・運用に携われること」です。

受託開発ではクライアントの要望に応えることが最優先となり、自分の意見やアイデアを反映させにくいと感じていました。 さらに、発注者を介すことでユーザのニーズが直接見えにくく、実現スピードも遅くなることも課題に感じていました。こうした経験から、「よりエンドユーザーに近い環境で開発を行いたい」と考えるようになりました。

2つ目は、「開発スタイルが自分に合っていること」です。

バックエンド・フロントエンド問わず幅広く開発に携わってきたため、今後もそのスタイルを継続したいと考えていました。

3つ目は、「身近なサービスであること」です。

自分自身がユーザーとして馴染みのあるサービスであれば、ユーザ視点を持って開発に取り組みやすく、よりやりがいを感じられると考えていました。

入社の決め手

ークオカードに入社を決めた理由について教えてください。

最初に求人を見たとき、技術スタックが自分の経験とマッチしていると感じ、カジュアル面談をお願いしました。

面談では、ラボの室長齋藤さんの開発や組織づくりに対する考えに共感し、「このチームで働きたい」と感じました。 特に「脱社内外注」への取り組みや、「エンジニアが働きやすい環境づくり」に注力している点に魅力を感じ、入社を決意しました。

関連記事:

入社後の感想・フルリモートへの適応

ー実際に入社してみてどうでしたか?

最初の率直な感想としては、「良い意味で平和だな」と思いました。

これまでの職場では、技術的な議論が白熱しすぎて、意見の押し付け合いになることもありました。 しかしラボでは、ガイドラインにもあるようにアサーティブなコミュニケーションが根付いており、お互いの意見を尊重しながら建設的に話し合える雰囲気があります。 意見を「聞く」姿勢と、「伝える」ための安心感が両立していて、自分の考えを率直に共有しやすい環境だと感じています。

カルチャーの違いは多少ありましたが、入社前にブログや採用面談で得た情報とのギャップはなく、とても働きやすい環境だと感じました。

関連記事:

ーフルリモートでの働き方にはすぐに慣れましたか?

フルリモートは初めてでしたが、前職でのリモート対応の経験もあり、大きな戸惑いはありませんでした。 最初は「隣の席にいる先輩にすぐ聞けない」ことに少し寂しさを感じたものの、今では“15分ルール”(=15分調べて分からなければヘルプチャンネルで質問)に従って、気軽に相談できるようになりました。

関連記事:

また、チャットで質問を投げておき、返事を待つ間に別の作業を進めるなど、効率的な進め方も自然と身についてきたと感じています。

さらに、ガジェット好きということもあり、自宅の作業環境を整えるのも楽しかったです。

担当業務・1日の流れ

ー現在の担当業務について教えてください。

現在はPayチームに所属し、QUOカードPayのECサイトやモバイルアプリ、Webアプリ、関連システムの開発・保守を担当しています。

インフラチームや新規開発チームといったラボ内の他チームとの連携だけでなく、業務部門の方々と直接やりとりをする場面も多くあります。 そのため、システムに関する知識だけでなく、業務フローの理解やビジネス全体の流れに対する理解も非常に重要だと日々実感しています。

ー1日の流れについて教えてください。

ラボでは裁量労働制を採用しており、メンバーはそれぞれの業務やプライベートの予定に合わせて、柔軟に働くことができます。私は基本的に9:00〜17:30の時間帯で勤務しています。

以下は、ある1日のスケジュールです。

🕖 7:00 起床

朝ごはんの準備や娘の支度をします。

🕖 8:30 保育園送り

娘と一緒に歩いて登園しています。 たまに泣くこともありますが、毎日楽しく通ってくれています。

🕖 9:00 業務開始

まずはSlackを確認し、タスクを整理・着手します。

🕖 11:00 デイリースクラム

チーム内で進捗を共有したり、相談事項や問い合わせの確認を行います。

🕖 12:00 昼食

前日の晩御飯の残りを食べることが多いですが、気分転換にコンビニで買うこともあります。家の近くに飲食店が少ないので、結果的に節約にもつながっている気がします(笑)

🕖 13:00 業務再開

ラボでは「Working Out Loud」という進め方を大切にしており、Slackの Times(分報)チャンネル に作業内容を投稿しながら進めています。 作業を共有することで自分の思考整理にもなり、他のメンバーからフィードバックをもらえることもあるので、とても有意義だと感じています。

🕖 17:30 業務終了

業務を終えたあとは、保育園から帰ってきた娘と一緒に遊んだり、晩御飯の準備や寝かしつけなど、家族との時間を過ごします。

娘が寝た後は、好きな番組を見たり、技術書を読んだりすることが多いです。 ラボでは ACM's O'Reilly Online Learning Platformを導入していただいており、好きな時にO'Reillyの書籍が読めるのがとてもありがたいです。

関連記事:

大変だったこと・やりがいに感じること・成長した点

ー特に大変だったことについて教えてください。

最も苦労したのは、ドメイン知識のキャッチアップです。

QUOカードPayのサービス特有の用語や、決済システムならではの専門用語が日常的に飛び交っており、それらに慣れるのが大変でした。(現在も学び中ですが)

ただ、用語集やドキュメントが整備されており、質問すればすぐに答えてくれる人が多いため、比較的スムーズに慣れることができたと感じています。

ーやりがいを感じる瞬間について教えてください。

自分が開発した機能に対して、ユーザーからのレビューや、「業務が円滑になった」といった社内のフィードバックをもらえたときに、大きなやりがいを感じます。 たとえば、管理画面のスマートフォン対応に関するバグを短期間で修正・リリースした際、業務改善に直結し、感謝の声をいただけたのは嬉しかったです。

また、新機能のリリース後に実際の利用状況を見て、「ちゃんと使われている」と実感できたときには、大きな達成感があります。

ー転職により成長を感じた点、希望を叶えられた点はありますか?

これまではバックエンド中心の開発を担当していましたが、現在はインフラも含めたフルスタックな開発に携わることで、インフラに関する知識も身についてきたと感じています。 特にAWSまわりは、これまでのキャリアではあまり触れる機会がなかったため、非常に勉強になっています。

また、転職時に希望していた「エンドユーザーに近い環境で開発をしたい」という点も実現できています。業務部門の方々と直接やり取りする機会が多く、ユーザーのニーズをダイレクトに感じながら開発に取り組めています。 「こういう課題があるから、こうしたい」といった方向性が共有された際も、エンジニアの立場だからこそ気づける改善点や工夫を提案し、それを反映しながら進められるのは大きな魅力です。

さらに、フルリモートかつ裁量労働制という働き方により、娘と過ごす時間が圧倒的に増えました。前職では夜遅く帰宅することも多く、寝顔しか見られない日もありましたが、今では朝食や夕食を一緒に囲むことができています。

今後挑戦したいこと

ーさらに今後挑戦したいことはありますか?

今後は、業務部門との連携をさらに強化し、ユーザーのニーズをより早く形にできるよう努めたいです。そのために、業務知識やビジネス全体の理解もさらに深めていきたいです。

また、新しいメンバーも増える中で、スピード感を持って価値を提供できるチームであり続けるため、チーム内のコミュニケーションもさらに強化していきたいと思っています。入社当初、メンバーからの迅速なヘルプに助けられた経験があるので、今度は自分が新しい仲間を支えられるよう尽力したいです。

選考を考えている方へのメッセージ

ー最後に、ラボへの入社を考えている方へメッセージをお願いします。

ラボは、チームで協力しながら主体的に仕事を進めることが好きな方にとても合う環境だと思います。

また、子育てと仕事を両立しているメンバーも多く、ワークライフバランスを大切にしながら無理なく働ける柔軟な体制が整っているのも大きな魅力です。

自分の成長とワークライフバランス、どちらも大切にしたい方にぜひおすすめの環境です。

最後に

ここまでお読みいただき、ありがとうございました!

クオカード デジタルイノベーションラボでは、Payチームを始め各チームで新しい仲間を募集しています。 少しでも興味をお持ちいただけた方は、是非カジュアル面談でお話しましょう!

quo-digital.jp

メンバーインタビュー#09 QAチームリーダーに聞く、USDM方式導入・テスト自動化・生成AI活用の取り組み

こんにちは!クオカード デジタルイノベーションラボ(以下、ラボ)の採用担当・金子です。

今回は、プロダクトの品質を支えるQAチームのリーダー・dobbyさんにインタビューを行いました。

2回目のインタビューとなる今回は、QAチームが要件定義の段階から関与するようになったことでの効果や自動化の推進、生成AIの活用についてお話を伺いました。

なお、1回目のインタビューでは、dobbyさんの入社理由や入社後のエピソード、「dobby」の由来についてもお話いただいています。ぜひ、あわせてご覧ください。

開発チームとの密な連携と主体的な行動

──2度目のインタビュー、ありがとうございます! 前回から半年ほど経ちましたが、改めて現在の開発チームとの連携について教えてください。

大きな変化はありませんが、引き続きQA観点での早期キャッチを目的に、開発チームのデイリースクラムに参加し、スプリントプランニングの結果も都度確認しています。 また、テストケースの観点出しでは開発メンバーにレビューを依頼するなど、日々連携しながら進めています。

──日々の業務で意識していることはありますか?

こちらも引き続きになりますが、「主体的に動くこと」を大切にしています。 たとえばバグ起票の通知を受け取った際には、受け身にならず自ら内容を確認し、テスト項目の追加や影響範囲の調査を行っています。

また、質問やチケットを起票する際には「なぜこの対応が必要なのか」「背景は何か」といった意図を明確に伝え、認識のズレが起きないよう心がけています。

シフトレフトとUSDM方式による上流品質の向上

──QAチームで進めている「シフトレフト」について、どのように捉えていますか?

「バグの早期検出を通じて、上流の品質を高める手法」として捉えています。 そのため、要件定義の段階から関与し、仕様の曖昧さや漏れを早期に検出して改善に繋げることを重視しています。

──特に効果を感じた取り組みはありますか?

USDM方式を活用したテストケースの洗い出しは、とても有用だと感じています。 USDM方式(Universal Specification Describing Manner)は、要求仕様を正確に記述するための手法で、ユーザーストーリーを起点に要件や仕様を整理することができます。 これにより、仕様の抜け漏れを早期に発見できるようになり、重要度の高いテストケースを優先的に洗い出すことが可能になります。

わかりやすくまとまっている参考記事として、Skyさんが公開されている以下のページをご紹介します。

ある案件では、USDM方式を活用したことで、仕様の抜けやエラー処理ステータスの不足を早期に発見することができました。開発チームから「助かりました」と言ってもらえたのが、印象に残っています。

──導入の背景と現在の運用は?

一人目QAエンジニアとして入社した当初から、「限られたリソースの中で、ユーザー視点で優先度が高いテストを、いかに効果的に行うか」という課題感がありました。その解決策として、USDM方式を導入しました。

現在は、要求仕様書をもとにQAチームで観点を洗い出し、Miroのマインドマップに整理。その内容を開発チームにレビューしてもらい、テストケースの作成に活用しています。

すべてをUSDM方式で進めているわけではなく、詳細なAPI仕様に基づき、網羅的に確認したいフェーズでは機能ベースのテストも併用しています。プロジェクトの目的やフェーズに応じて、使い分けています。

──運用面での課題や今後の展望は?

マインドマップの情報量が増えるにつれて視認性が低下し、レビュー時の負荷が高くなる点が課題です。 また、観点を掘り下げていく中で、本来の目的を見失ってしまうこともあります。

今後は、視認性を担保しつつ、「この要件は何を解決するためのものか?」という本質を捉えた観点抽出ができるよう、フォーマットの整備を進めたいと考えています。

さらに、担当者によって観点の粒度にばらつきが出やすいため、チェックリストの共通化などを通じて、チーム全体の品質の平準化にも取り組んでいきたいです。

自動化の戦略と段階的な推進

──テスト自動化の現状と今後の方針を教えてください。

現在、APIテストとE2Eテストの一部について自動化を進めています。

APIテストは、主にバックエンドの安定性を担保する目的で進めており、発行や決済などの主要フローに加え、エラー系や境界値のケースも網羅的にカバーしています。 PostmanとNewmanを用いたテストを、GitHub Actionsと連携し、プルリクエスト単位での自動実行を実現しています。

現在は、ローカル環境で実行しているAPIテストを、検証環境でも動かせるよう整備中です。インフラチームの協力で環境構築は完了しており、今後はCodeBuildを活用してGitHub Actionsから検証環境で自動実行できるようにしたいと考えています。

フロントエンドのE2EテストにはPlaywrightを導入し、社内システムの動作確認やフォーム送信、画面遷移など、クリティカルパスとなるユーザーフローを中心に自動化を進めています。Headlessモードでの高速な実行に加え、失敗時にはスクリーンショットやログ出力を活用し、原因特定の効率化にもつながっています。今後は、ECサイトやモバイルアプリへの対応を進めていく予定です。

──自動化における優先順位は?

ユーザーへの影響が大きい機能、特に決済部分などを優先しています。 ユーザーシナリオに沿ったテスト設計をベースに、自動化が難しい箇所については手動テストも併用しながら、効率と網羅性のバランスを意識したテスト戦略を進めています。

生成AIの活用と今後の活用方針

──生成AIの活用状況を教えてください。

APIテストの自動化やE2Eテストの実装、自動テストのコードレビュー、仕様の一次確認など、さまざまな場面で活用しています。

現在は主にDevinとCursorを使っています。 使用感としては、Devinはコードレビューや仕様の一次確認に、Cursorはテストケースの洗い出しやコードの実装支援に適していると感じており、特性を踏まえて使い分けながら活用しています。

──生成AIを活用する際に意識していることは?

ツールごとに得意・不得意があり、さらに日々進化しているので、常に最新の情報をキャッチアップしつつ、適材適所で活用することを意識しています。

また、最終的には必ず人の目での確認を行うことで、品質を担保するようにしています。

──今後、新たに生成AIを活用したい箇所はありますか?

今後は、機能ベースでの網羅的なテスト設計にもAIを活用し、さらに効率的かつ抜け漏れの少ないテストを目指していきたいです。

今後のチャレンジと、応募を考えている方へのメッセージ

──今後、チャレンジしたいことはありますか?

まずは、チーム全体のスキルの平準化に向けて、観点だしやテスト設計のフォーマット整備、ナレッジ共有の仕組み作りに注力していきたいと考えています。

また、今後はモバイルアプリのE2Eテストにもチャレンジしたいです。Webアプリと比べて使用ツールも異なるため、まずはチームでインプットしながら、段階的に進めていけたらと考えています。

──最後に、ラボへの応募を検討している方にメッセージをお願いします。

ラボは、新しい技術や手法について、課題解決につながるものであれば積極的に受け入れてくれる環境です。

責任者の齋藤さんをはじめ、チーム全体が生成AIの導入や業務改善に前向きなので、主体的に動いて業務改善など進めていきたい方、新しい手法にチャレンジしてみたい方にはぴったりの職場だと思います。


以上、dobbyさんへのインタビューをお届けしました。

プロダクト品質の向上に向けて、USDM方式の導入や、生成AIの活用など、日々工夫と挑戦を重ねている様子がとても印象的でした。

最後に

ここまでお読みいただき、ありがとうございました!

クオカード デジタルイノベーションラボでは、一緒に働く仲間を募集しています。 「課題を自ら見つけて解決していきたい」 「新しい技術や手法にもどんどんチャレンジしてみたい」

そんな思いをお持ちの方は、まずはぜひカジュアル面談でお話しましょう!

quo-digital.jp

Cursorの活用方法や良い点・課題点、今後任せたいことについてアンケートとってみました!

はじめに

クオカード デジタルイノベーションラボ(以下ラボ)では、「エンジニアが本質的な業務に集中できる環境を作る」ことを目指し、自動化や効率化を推進するさまざまなツールの導入・運用に取り組んでいます。

関連記事

この一環として、AIツール「Cursor」を新たに導入しました。 (※追記:2025/9で利用終了し、現在はClaude Codeに移行しています。)

本記事では、Cursorの活用状況や、使ってみて感じた良い点・課題点、今後任せたいことなどをアンケート形式で聞いてみた結果をご紹介します。

Cursorの導入を検討している方や、ラボへの応募を検討中の方にとって、少しでも参考になれば幸いです。

ラボにおけるAIツール導入状況

現在ラボでは、以下のAIツールを導入・活用しています。

関連記事

そして今回、実装やコード調査、仕様検討などの開発支援を目的に、「Cursor」を導入しました。

また現在は、「Claude」 の試用も一部メンバーで開始しており、こちらも今後の導入を視野に入れています。

AIツールにはそれぞれ得意分野や特性があり、進化のスピードも非常に早いため、ラボでは今後もより良い選択肢があれば柔軟に取り入れ、日々の課題解決に活用できる体制を整えています。

アンケート概要

回答者:ラボ所属のエンジニア

質問内容:

  • Cursorの活用方法について教えてください
  • 現時点でのCursorの良い点、得意だと感じるところを教えてください
  • 現時点でのCursorの課題点、苦手だと感じるところを教えてください
  • 今後Cursorに任せてみたいと考えているものがあれば教えてください

アンケート回答紹介

Cursorの活用方法について教えてください

ソフトウェアエンジニア

コードの調査・実装

  • 既存コードの調査
  • ボイラープレートや定型的なコード生成
  • 実験的なコード生成
  • テストコードの実装
  • 新規コード実装

仕様・改修に関する検討

  • 仕様調査
  • 改修方法の素案検討
  • 改修内容の妥当性の確認
  • 修正を任せるよりも、調査や修正方針の検討で使うことが多い。「xxをしている箇所はどこ?」「xxが使われるケースは?」「xxの場合どのような動きになる?」「xxにするためにどのような修正方針がよいか?」といった使い方をしている。

インフラエンジニア

  • 開発/レビュー

QAエンジニア

  • E2Eテストの実装
  • テストケース洗い出し

Cursor導入により、エンジニアリングの方法(開発プロセス・作業時間など)が変わったことがあれば教えてください

ソフトウェアエンジニア

✅プラス面

調査時間の短縮

  • やりたいことをベースに「どうすべきか」の解答が出てくるため、作業中の調査にかかる時間が大幅に削減されていると実感。
  • 既存の実装を調べたり理解したりする際も、Cursorに聞けば大体解決するため、作業時間が短縮されている。
  • 主に現状実装の調査にかかる時間がかなり減った。

実装の効率化

  • 特にテストコードでは、Cursorが大枠を作ってくれるため、あとは細かい部分を実装するだけで済み、非常に楽になった。  

    改修方針の併走支援

  • 改修方法の素案をCursorに提示してもらい、チャットでやりとりしながらブラッシュアップしていく流れが多くなった。

⚠️マイナス面

レビュー時間が増加する場合がある

  • AI生成されたコードに対するチェックの目が緩くなっている場面もあり、結果としてレビューに費やす時間が増えていると感じることがある。

インフラエンジニア

✅プラス面

  • 現状調査やレビューの時間が大幅に減りました

QAエンジニア

✅プラス面

  • 実装時間が短縮されています(外枠を作ってくれるので、チューニングしながらデバッグできる)

現時点でのCursorの良い点、得意だと感じるところを教えてください

ソフトウェアエンジニア

プロジェクト内のコード検索・調査

  • プロジェクト内のコードの横断検索ができる
  • リポジトリや指定ファイルのコンテキストを前提に調査や提案をしてくれる
  • プロジェクト全体を見てくれるので、調査ではかなり正確な答えが返ってくる

実装に関する支援

  • リアルタイムでのコード修正内容の確認ができる
  • 実装に関する質問への回答や解説が得られる
  • バックエンドの実装全般で活用できる(※フロントは未使用のため不明)

応答スピード

比較的応答速度が速いため、回答待ちのストレスが少ない

インフラエンジニア

  • コード全体の横断検索ができる

QAエンジニア

  • コードをより深く解析することができる

現時点でのCursorの課題点、苦手だと感じるところを教えてください

ソフトウェアエンジニア

指示通りに動作しない場面がある

  • 大きなタスクの丸投げ
  • 複数リポジトリを横断した質問の回答
  • たまに指示していないコード修正をする。よくやられるのがTODOコメントを消されること。消さないで!と頼んだら、なぜかTODOコメント以外の実装部分を消されたことがあった。
  • 提案だけ求めているタイミングで先走って修正される時がある

動作の安定性

応答を返さないことがよくあったが、1.0になってからそういったことは殆どなくなった。

その他

インフラエンジニア

  • 間違った提案をしてくるところがある

QAエンジニア

  • まだまだ網羅的なテストケース洗い出しは確認が必要
  • たまにコードを解析するところが間違うので、コードファイルを具体的に指定してから実装してもらうこともある

今後Cursorに任せてみたいと考えているものがあれば教えてください

ソフトウェアエンジニア

  • 仕様に関するwikiドキュメントの素案作成など
  • 具体的にこれというのはないが、今後も開発プロセスの一部として調査や方針検討に用いていく

インフラエンジニア

  • ドキュメントの横断検索

QAエンジニア

  • より幅広い範囲のWebアプリのE2Eテスト
  • Appium/Seleniumを使用したモバイルアプリのE2Eテスト

アンケートの結果から、Cursorはコードの調査や実装、仕様検討といった開発支援業務に強みがあり、適切に活用することで業務効率化に大きく貢献していることがわかりました。

一方で、文脈に依存するタスクや、複数リポジトリにまたがる複雑な指示に対しては、意図しない動作や期待通りの回答が得られない場面もあるという課題も見受けられました。

今後の展望

ラボでは、こうしたAIツールとの協働をより良いものにしていくために、「どのように指示すれば意図が正しく伝わるか」「どのように活用すれば効果的か」といったノウハウをチーム内で共有しながら、さらなる課題解決につなげていきたいと考えています。

また、AIツールごとの特性を理解し、目的に応じて柔軟に使い分けることも、より効果的な活用に不可欠だと感じています。

脱社内外注を進めています」の中で目指す姿として記載した「エンジニアはシステムを作るだけでなく、顧客(利用者)の課題を解決する存在」であり続けるため、今後もAIツールと協働し、創造的かつ戦略的な役割に集中しながら、より良いサービスづくりにつなげていきたいと考えています。

最後に

ここまでお読みいただき、ありがとうございました!

ラボでは、新しい技術やツールを積極的に取り入れながら、チームで協力して課題解決に取り組める環境づくりを大切にしています。

そんな環境の中で、一緒にチームの成果を最大化してくれる仲間を募集中です!

少しでも興味を持っていただけた方は、ぜひカジュアル面談でお話しましょう。

quo-digital.jp