QUO CARD Digital Innovation Lab Tech Blog

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

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

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

(最終更新日:2026/2/10)

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

quo-digital.jp

プロダクト

www.quocard.com

2025年の組織体制について

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

技術スタック

開発の進め方

働く環境

勉強会

技術ブログ

メンバーアンケート

メンバーインタビュー

採用関連情報

open.talentio.com

「未経験の領域」へ踏み出しスキルの幅を拡大。 ユーザーの声を糧に、 チームでサービスの成長を支える外崎さんの挑戦!

こんにちは!

クオカード デジタルイノベーションラボ(以下ラボ)採用担当の金子です。 今回はPayチームの外崎さんにインタビューを行いました。 入社の決め手や日々の業務、働き方についてお話を伺いましたので、ぜひご覧ください。

自己紹介

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

2022年12月に入社した外崎です。 前職では、主に企業公式アプリの受託開発に携わっていました。 現在は長野県からフルリモートで勤務しています。 趣味は、ゲームや映画鑑賞です。

転職のきっかけ・転職軸

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

前職までは受託開発がメインで、区切りごとに違うサービスを作る仕事が多かったのですが、次第に「一つのサービスに深く、長く関わっていきたい」と考えるようになったのがきっかけです。

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

1点目は「自社サービスの継続的な改善に携われること」です。

一つのサービスに長く関わり、ユーザーからのフィードバックを得ながら、プロダクトを良くしていく開発に挑戦したいと考えていました。

2点目は、「リモートワークができる環境があること」です。

2022年当時、前職ではリモートワークが終了しそうな時期でした。私自身はリモートワークでの働き方が合っていると感じていたので、その環境が維持できることも重視していました。

入社の決め手

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

転職軸として重視していた2点がマッチしていたことに加え、「新たな領域にもチャレンジしてスキルの幅を広げられる」と思えたことです。

これまではモバイルアプリの開発がメインでしたが、ラボならバックエンドやインフラなど、新たな領域にも挑戦できて楽しそうだと思いました。また、面接後の結果通知が早かったことも印象が良かったです。

入社後の感想や感じたギャップ

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

歴史のある金融系の会社ということで「お堅くて物事がスムーズに進まない部分もあるのでは」というイメージがありました。

しかし実際に入ってみると、仕事の進め方が非常に柔軟で、スピード感があることに驚きました。具体的には、ChatGPTなどのAIサービスを活用した業務効率化やコード生成など、新しいものを取り入れる動きが非常に早かったのが印象的でした。

担当業務・1日の流れ

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

Payチームで、QUOカードPayのモバイルアプリやWebアプリ、および関連システムの開発・保守を担当しています。

ただ開発するだけでなく、QAチームと連携して品質を上げたり、運用チームと協力してサービスの安定稼働に向けた改善に取り組んだりと、リリース後の先まで見据えた動きを意識しています。

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

ラボでは裁量労働制を採用しており、それぞれの業務やプライベートの予定に合わせて柔軟に働くことができます。 私は基本的に8:00〜16:30の時間帯で勤務しています。以下は、ある1日のスケジュールです。

🕖 7:00 起床

🕖 8:00 業務開始

まずSlackやメールを確認し、タスクを整理・着手します。

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

チームで15分程、進捗や課題を共有します。深掘りが必要な議題は、デイリー後に必要なメンバーが残って話し合います。

🕖 12:00 昼食

フルリモートだとどうしても体重が増えがちなので(笑)、最近は健康を意識して、白米に3割ほど麦を混ぜた「麦飯」を食べています。

🕖 13:00 業務再開

曜日によってはチームでのリファインメントがあったり、週1回技術顧問による勉強会に参加します。それ以外は引き続き開発業務を進めます。

関連記事:

🕖 16:30 業務終了

翌日のタスクを整理して退勤します。

🕖 退勤後

長野に引っ越してからは、明るいうちに近所をドライブしています。長野ならではの温泉や高原を探索するのが最近の楽しみです。

ーSlackでのキャッチアップが非常に細やかな印象ですが、工夫されていることはありますか?

Slackの機能を活用し、「仕組み」で忘れないようにしています。時間がかかりそうな投稿は「ブックマーク」に入れ、チームで確認すべき事項は専用のリストに追加してデイリースクラムの時に確認することで、漏れを防いでいます。

ーPayチームには新メンバーもよく入社しますが、受け入れの際に意識していることはありますか?

特別な意識というよりは、ラボの「仕組み」がうまく機能していると感じます。たとえばSlackの「Times(分報)」です。新メンバーに作業内容を投稿してもらうことで状況が把握できるので、周囲がフォローしやすくなります。

「15分考えてわからなければ発信する」という15分ルールもあるため、質問しやすい環境になっています。

関連記事:

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

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

大きく分けて2点あります。

1点目は、「新しい領域のキャッチアップ」です。

未経験だったWebアプリやインフラ領域は大変でしたが、ドキュメントが整備されていたことや、Slackのヘルプチャンネルでわからないことをすぐに聞ける環境があったのは心強かったです。 また、ペアプロ・モブプロを通じて既存メンバーから知識を吸収できたことで乗り越えられました。

2点目は、「マインドの切り替え」です。

受託開発では「仕様通りに作ること」が求められていましたが、ラボでは、「課題をどう解決するか」という上流から考える必要があります。単にコードを書く以上に、「どう進めるのがベストか」を自分で考える経験が少なかったので最初は苦労しました。ただ、これこそがやりたかったことでもあったので、ラボの進め方についてのWikiを読み込んだりメンバーの動きを参考にしたりして、少しずつ馴染んでいきました。

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

未経験だったWebアプリの改修をチームでやり遂げ、リリースできたときは大きな達成感がありました。 また、App Storeのレビューで「分かりづらい」といった不満の声が、デザイン改善などの結果として少なくなっていくのを見ると、「課題を解決できた」と実感できます。

さらに、「QUOカードPay」は多くの方に使われているサービスのため、テレビ番組のプレゼント企画などで自分の関わっているサービスを目にすることもあり、誰かの役に立っていると感じられて嬉しいです。

ー成長を感じた点、叶えられた点はありますか?

スキル面では、やはりモバイルアプリ以外のWebアプリやインフラ領域にスキルの幅を広げられたことが大きいです。

さらに、希望していた「 一つのサービスに長く関わって改善を続け、ユーザーから直接フィードバックが得られる形」も叶えられました。

マインド面では、ラボの「15分ルール」や「Working Out Loud(作業の可視化)」といった仕事の進め方を通じて、成長を感じています。主体的に考えて動くことを目標にしているので、以前よりもスピード感や当事者意識を持って仕事に向き合えるようになったのが、自分の中での大きな変化です。

今後、挑戦したいこと

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

チームとしては、今年から本格的に取り組んでいる新規システムの開発を無事に形にすることです。既存システムとは違い、まだ「動くものがない状態」からスタートするため、資料ベースでのやり取りで認識がズレないよう、早い段階でプロトタイプを見せるなど、業務サイドと認識合わせをしながら進めていきたいです。

個人としては、これまで以上に業務サイドの方々と密にやり取りをして、サービスの向上やユーザー評価に繋がる仕事の進め方を追求していきたいと考えています。

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

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

ラボはチームで成果を出すことを目指しているので、そういった環境で働きたい方にぜひ来ていただきたいです。

また、 私のように「未経験の領域にも挑戦していきたい」という人をサポートする文化もあります。「自分の経験があることしかできない」と守りに入るのではなく、どんどん新しいことができるようになりたいという意欲のある方と、ぜひ一緒に働きたいなと思っています!

最後に

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

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

quo-digital.jp

Terraform未経験の運用エンジニアが、Claude Codeを活用してインフラ構築した話

はじめに

今回は、運用チームが直面した「大量メール送信時のバウンスレート上昇」という課題を、運用エンジニアのKさんがAIエージェントのClaude Codeを相棒に、未経験のTerraformでインフラ環境を構築して解決した事例を紹介します。

クオカード デジタルイノベーションラボ(以下ラボ)では、AWSの構成管理にTerraformを採用しています。

主にインフラチームが管理を担い、開発チームもリリース作業等の際にコードを触りますが、運用チームは普段、システムの安定稼働やログ・リソースの監視、運用設計をメインミッションとしており、日常的にTerraformを扱う業務はありません。

そのような状況下で、なぜ未経験のTerraformによる構築に自ら挑戦することになったのか。ここからは、実際にプロジェクトを完遂したKさんに、その意思決定から本番リリースまでの過程を振り返っていただきます。

課題と解決の方針

今回のプロジェクトの始まりは、大量メール送信における「バウンスレート(不達率)上昇」というリスクへの対策でした。

課題

以前、Amazon SES経由で大量メール送信を行った際、不達率が上昇しアラートが発報。 現状の対策プログラムは「手動実行」を前提としていたため、夜間・休暇中や休暇明けの大量送信に対し、タイムリーかつ確実に実行することが難しいという運用上のリスクを抱えていました。

方針検討

運用チームは当初、大量送信時のみ一時的に外部配信サービスへ切り替える方針を検討し、インフラチームへ相談を持ちかけました。

しかし、共有IPプランによる配信停止リスクや、切り替えに伴う本番作業の発生、コスト面などで比較検討した結果、配信サービスの切り替えは行わず、「既存の抑制プログラムの実行を自動化・スケジューリングする」という解決策を選択しました。

採用した技術構成

協議の結果、以下の構成で自動化の仕組みを構築することに決定しました。

  • AWS Step Functions: 抑制プログラムを繰り返し実行するためのステートマシン。
  • Amazon EventBridge Scheduler: 送信タイミングに合わせ、起動時刻や回数を柔軟に指定。
  • 監視体制: Step Functionsの実行状況を監視し、失敗時は即座に通知する仕組み。

「Terraformでの構築」を選択した理由

この構築にあたっては、検証段階としてマネジメントコンソールから「手動で構築する」という選択肢もありました。しかし、「後からTerraform化する手間を考えれば、最初からIaCで構築・管理した方が効率的である」という判断に至りました。

未経験からの挑戦の背景

当初、運用チームにはTerraformの経験者が不在だったこともあり、インフラチームへ構築を依頼することも検討していました。しかし、最終的には以下の要素から未経験からの挑戦を決意しました。

  • 整備されたドキュメント: 既存リポジトリのREADMEからファイル構成が把握でき、WikiにはTerraformの開発フローが明文化されていました。「何をどこに書けばよいか」の基準がオープンになっていたことで、未経験ながらも「既存コードを参考にすれば、自分たちでも進められるのではないか」と具体的にイメージできたことが、大きな後押しとなりました。

  • チームを跨いだサポート:インフラチームから「困った時は遠慮なく聞いてください」「レビューするので、できたら教えてください」という力強い言葉をもらいました。専門メンバーにフォローを依頼できる環境があったことは、未経験の領域へ飛び込む際の大きな安心感へと繋がりました。

  • 運用チームとしての展望: 現状、チームとしてスキル面に課題があると感じていました。どうしても現状のルールの中で「気合」で乗り越えがちだったので、なるべく広い視点をもって、色々な選択肢がとれるチームになれるといいなと考えていました。その一歩として、今回の経験を通じてスキルを広げることで、運用チームとしての守備範囲を広げ、より機動的に動ける組織を目指したいという想いがありました。

正直なところ、最初の一歩を踏み出すのは怖かったです。特にインフラチームのサポートがなければ、今回の挑戦はできなかったと思います。

活用ツールと構築ステップ

活用ツール

構築の初期段階ではブラウザ版のClaudeを活用していましたが、プロジェクトの途中でインフラチームよりClaude Code(ターミナルで動作するAIエージェント)の導入を推奨されました。

Claude Codeは、開発チームやインフラチームでは既に導入・活用されており、その有用性が実証されていたツールです。今回のプロジェクトを良い機会と捉え、運用チームでも必要なメンバーへの導入を決定しました。

既存のコードベースを読み込み、コンテキストを理解した上で提案をくれるClaude Codeの導入により、実装スピードと精度はさらに向上しました。

関連記事:

構築ステップ

最初から完璧なものを作ろうとするのではなく、インフラチームの助言を得ながら、以下のステップで段階的に進めていきました。

1. 既存コードの読み込みと全体構成の把握

まずはインフラチームからリポジトリの参照権限をもらい、既存のディレクトリ構成やREADMEを確認することから始めました。 ラボにおける「Terraformの書き方の作法」を、ドキュメントと実際のコードの両面から把握しました。

2. プロトタイプ作成とClaude Codeのによる最適化

当初はブラウザ版Claudeでワークフロー(ASL)や基本構成のイメージを固めていましたが、Claude Code導入後はローカルのモジュール定義を直接参照させることで、より環境に即した精度の高いコード生成が可能となりました

  • ステップ1: まずは、頭の中にあった「EventBridge → Step Functions → 既存Step Functions」という処理フローを、実際の環境で動くリソース定義へと具体化しました。

  * 実施内容: Claude Codeに対し、既存環境における変数定義やリソース間の依存関係を考慮したコード生成を指示しました。初めてだったこともあり、この修正はどういう意味?影響は?といったことも都度Claude Codeに教えてもらいながら進めました。

  * 工夫した点:指示文(プロンプト)自体の作成もClaude/Geminiと対話しながらブラッシュアップを重ねて構築しました。

  • ステップ2: 生成されたリソース定義を、実運用に耐えうる「そのまま適用可能な状態」にブラッシュアップしました。

  * 実施内容: プロジェクト固有の命名規則やTerraformの共通モジュールの構成をClaude Codeに直接参照させ、コード全体の最適化を行いました。

  * 得られた成果: 既存のディレクトリ構造や変数の管理ルールを正確に反映させることで、既存環境に適合したコードを完成させることができました。

3. 検証とセルフレビュー

検証環境で実際にapplyし、意図した通りに動くか検証を繰り返しました。 また、マージ前にはClaude Codeの/self-reviewコマンドを活用し、人間が見落としがちな構文のチェックや命名規則の微調整を行いました。

4. インフラチームによるレビューと本番リリース

検証完了後は、本番環境への影響を最小限にするため、ステップを分けてリリースを進めました。

  • ステップ1: まずは、ステートマシンを構築しました。この際、構築直後に意図しない自動起動が走るのを防ぐため、スケジューラーは DISABLED(無効)状態で設定しました。

  • ステップ2: リソースのデプロイと並行して、Datadogによる監視設定も行いました。構築したインフラが設計通りに動作しているかを正確に把握するため、監視モニタを有効化し、正常な稼働を確認できる状態を整えています。

インフラチームによるレビューを経て、各ステップを本番環境へのapplyし、すべてのプロセスを完遂することができました。

今後は実際に運用しながら、状況に合わせて継続的にブラッシュアップしていきたいと考えています。

今後の展望

今回の事例のように、たとえ未経験の領域であっても、AIなどの新しいツールを駆使して自らキャッチアップし、具体的な解決策を構築していく。

こうした挑戦を積み重ねることで、運用チームとしてサービスの最適化に向けて、メンバー全員が主体的に選択肢を検討・選択できるチームを目指したいと考えています。 運用の性質上、ヒューマンエラーを完全になくすことは難しいかもしれませんが、発生確率を減らすための「仕組み」を実現していきたいです。 現在はまずチームとして着実に成果を出していくことに集中していますが、将来的にはチームの枠を超えて、サービス全体の向上に寄与できる存在へと成長していきたいです。

まとめ

今回のプロセスを振り返ると、ラボの以下の特徴が、結果的に今回の挑戦を支える形になっていたと感じます。

  • AIツールを柔軟に取り入れる環境: 最新のツールを導入・活用することで、未経験の領域であってもキャッチアップし、課題解決へと繋げることができます。

  • ドキュメント化とオープンな文化: WikiやREADMEが整備され、情報が属人化せずオープンに公開されています。これにより、他チームのメンバーであっても必要な情報を能動的に取得することができます。

  • サポート文化: チームを超えた連携やレビュー体制があります。これにより、個人の挑戦を後押しし、結果として組織全体の機動力向上に繋がっています。

最後に

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

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

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

quo-digital.jp

直近入社メンバーアンケート(後編) 「カルチャーを実感したエピソード」と 「マッチする人物像」聞いてみました!

はじめに

本記事は、クオカード デジタルイノベーションラボ(以下ラボ)に関するアンケート結果レポートの後編です。

前編では、入社後に感じた「ギャップ」や「直面した苦労の乗り越え方」など、新メンバーのリアルな葛藤や驚きについてご紹介しました。

続く今回の後編では、「ラボならではのカルチャーを実感した瞬間」や、自身の経験を振り返って思う「ラボにマッチするのはどんな人か?」についての生の声をお届けします。

アンケート概要

今回は、情報の鮮度を重視し、2024年4月以降に入社したメンバーを対象に実施しました。

回答者:2024年4月以降に新たに入社した、ラボ所属のメンバー

質問内容:

(前編)

  • 入社後、想定外の「ギャップ」はありましたか?
  • 入社後、特に苦労した点とそれをどう乗り越えたか教えてください。

(後編)

  • 入社後、ラボのカルチャーを特に実感した具体的なエピソードがあれば教えてください。
  • 自身の経験を振り返って、改めて「どんな人がラボにマッチしている」と思いますか?

アンケート回答紹介

質問:入社後、ラボのカルチャーを特に実感した具体的なエピソードがあれば教えてください。

<Working Out Loudと相互サポート>

(Working Out Loudについての関連記事はこちら

  • Working Out Loudの文化がしっかり機能している点が印象的です。困りごとやトラブルが起きた際にはSlackですぐに情報共有・やり取りができ、問題の早期解決につながっています。

  • 困ったときに質問を投げると、すぐに回答が返ってきます。ラボが目指している「メンバーをサポートする」文化が本当に体現されていると実感しています。特に印象的なのは回答の仕方です。単に答えを教えてくれるだけでなく、「なぜそうなのか」や「こう考えるといいよ」といった気づきを得られる形で返してくれることが多く、自分で考える力が育っていると感じます。

  • Working Out Loud でSlackのtimes(個人の分報告チャンネル)で呟いたことに対してサポートがあったこと

  • 一番感じたのは「Working Out Loud」です。自分が何をやっていて、何に詰まっているのかを常に共有することでいち早くフィードバックを得られ、スムーズに業務を進めることができていると思います。

  • Slackでオープンなコミュニケーションを行うことで、他メンバーがどのような作業を行い、どういった状況なのか可視化されていて、フルリモートの欠点である周りの状況がわからないという課題がケアできていると感じました。

  • 自分で調べてもわからないことは気軽にチームメンバーに聞くことができる環境のため、システムの理解や業務知識を得るのには助かりました。

<スピード感と変化への柔軟性>

  • 使用しているAIツールを乗り換える話が出た際、室長の齋藤さんを筆頭にメンバーで協議・切り替え・移行までたった数日でスムーズに進んだことにびっくりしました。スピード感がある、とはまさにこのことだなと実感しました。

  • 生成AI導入に、ラボのスピード感を強く実感しました。発表後すぐに試し、有用であれば即座にメンバーへ展開され、さらに良いツールが出れば再検証の上で迅速に乗り換えるという流れで実践されていました。

  • この作業ってもっと改善できなか?の一言で、翌々日頃には作業改善(人力で管理していたタスクの自動化、ツール化)されたことがあります。スピード感もあったし、無駄なことは即改善できるのでモチベーションがあがります。

  • 最新の生成AI等のツールを積極的に導入して業務効率化を図る文化が根付いていると感じました。例えば、ドキュメント作成やコードレビューにAIツールを活用することで、作業時間を大幅に短縮できました。

<フィードバックと継続的な改善>

  • 継続的に改善を行う文化を強く感じます。例えば...

    • 何か間違っていそうな時、率直なフィードバックがすぐに飛んでくる
    • 率直なフィードバックをすると喜ばれる
    • スクラムイベントの振り返りで継続的にプロセスを改善する仕組みが根付いている
    • スクラムイベントの振り返りを待たずともクイックな改善を行うことも多々ある
  • 2週間のスプリント期間で出た課題をすぐに振り返り、次のスプリントでは改善策にTryしてどんどん改善していく、今のやり方が常にベストじゃないという思考で、どんどん改善していく、という点はラボのカルチャーを表していると思います。

  • 複数の対応をまとめてリリースしたほうがいいと思いこんで特定の対応のリリースを次の対応のリリースのタイミングまで遅延させる想定であることを発言したところ、リードタイムを短くすることが重要なのでリリース可能なものをそのように遅らせるべきではないと指摘されたことがありました。

<当事者意識と主体的に進める姿勢>

  • 属人化を避けているため、資料が多く揃っているので、初めてやるオペレーションでも問題なくひとりで対応できたこと。司会作業もローテーションで回ってくるため、各人が当事者意識を持って挑むことで、より理解や連携が深まること。

  • 経験の有無に関わらず大体どんなタスクでも自由に取って進めることができるのでいろいろ身につきました。

  • 新規機能開発を行うときにビジネス側の要望を受け取った後はラボが主体となって見積もりやアーキテクチャ設計を行います。懸念点や技術的な制約を洗い出し、担当部署や技術顧問と相談しつつ最適な解決策を模索して作業を進めていきます。このプロセスを通じて、技術的な視点だけではなくビジネス的な知見もチーム内に蓄えることができ、開発経験を重ねる度に精度の高い見積もりや設計が行えるようになっていると感じます。

<本質的なコミュニケーションの重視>

  • テキストコミュニケーションを円滑にするためのルールが明文化されている点です。 具体的には、「Slackを見たらスタンプを送る」「『お疲れ様です』などの挨拶は省略する」といったルールが共有されており、形式にとらわれず本質的なコミュニケーションを重視する姿勢に、ラボらしい合理的なカルチャーを強く感じました。

質問:自身の経験を振り返って、改めて「どんな人がラボにマッチしている」と思いますか?

<自律・自走と探究心>

  • まずは自分で考え・動けること、また、トライアンドエラーを恐れない人がラボに向いているのかなと思いました。(ラボに限らず周りの方が優しいので、エラーを恐れず出来る環境だと思います)

  • 好奇心旺盛な人、考えることが好きな人、とりあえずやってみるタイプの人がマッチしているかなと思います。自分で考えて進めることができるし、色々な意見やアイディアが受け入れられる環境だと思うので、マッチする人にはかなりマッチ度高いと思います。(逆に、指示されたい人、スピード感よりコツコツ積み上げていきたい人はキャッチアップが少し大変な印象です、、)

  • 自分の働く環境は自分で整えていく人。(リモート環境なので物理的な仕事環境も自分で整えていくしかない点も含め)

  • 自律している人・発信力がある人・人に流されない人・探究心がある人

  • 問題を抱え込まず自律自走できる人

  • 自分の役割とやるべきことを自分で考えられる方、自身の課題を改められる方だと思いました。自分ができているかというと不十分な点が多いですが、そう思う点を潰していくことが必要なのかと思います。

  • 臆せずに挑戦していける方にはマッチするのではないかなと思います。

<チームプレイヤー・コーチャブルな姿勢>

  • 一人で黙々と働きたい方よりも、チームで働きたい方に向いている環境だと思います。自分の担当範囲だけに閉じこもらず、チーム全体の状況を見ながら動ける人、困っているメンバーがいれば自然とサポートに回れる人 そういう姿勢を持っている方にとっては、とても働きやすく、やりがいを感じられる場所だと思います。

  • 「チームプレイヤー」である方かなと思います。他人の意見を受け入れられ、かつ自分の意見も述べられる方がマッチしていると思います。

  • Working Out Loudの文化を活かして、困ったときに積極的に発信し、チームと協力しながら問題解決できる人が活躍できる環境だと思います。フィードバックを前向きに受け止め、継続的に学び続ける姿勢も大切だと感じています。

  • 自分の状況を積極的に共有する、Slackの投稿なども積極的に確認し周りの状況も把握するなど、自分から動ける方が向いていると思います。

  • 自律し、自らやるべきことを見つけられる人 ・率直なフィードバックを素直に受け止められる人 ・失敗を組織のプロセスの問題だと認識し、解決に進められる人 ・チームの成果を最大化するのが好きでたまらない人

<スピード感と柔軟な適応力>

  • スピード感のある環境で柔軟に動ける人、そして優先順位を見極めながら本質的な価値にフォーカスできる人がマッチすると感じます。完璧を目指すより、まず試して素早く判断・実行するサイクルに適応できる人が活躍しやすいのではないかと思います。

  • 今までの慣習にとらわれずにチームのやり方や成果を尊重できる方

  • スピード感を持って進めつつも不具合を出さないように石橋を叩いてわたる慎重さも大事になってきます。そのために仕事の進め方であったり、システムの設計やツールにラボ全体で統一感があるので、ルールや文化に適応できる人がマッチしていると思います。

  • 何でも自由に、というよりは、メリハリを大切にしながらチームで成果を出していくスタイルが好みの方。ワーキングアグリーメントなど一定のルール整備がされているため、その意図や合理性を理解し共感できる方がマッチしていると感じます。

<技術への意欲>

  • スキル的にはフルスタック寄りでできることを増やしていきたい人や周りを巻き込んで業務を進めていきたい人

  • 私は前職で経験のあったバックエンドの他にAndroidiOSのアプリの開発に携わりました。より良いサービスを提供するために新しい技術を学ぶ必要があるため、これまで経験したことがない新しい技術に対して積極的に学ぶ姿勢を持っている人がラボにマッチしていると思います。


今回のアンケート結果を振り返り、常に改善を回し続ける姿勢が、ラボのスピード感につながっていること、そしてWorking Out Loudによる状況の可視化が、フルリモートで円滑に連携するための大きな助けになっていることを改めて感じました。

またマッチする人物像については、「自分で考えて動く自走力」と、それをオープンにして「周囲と連携する力」の両面を重視する声が目立ちました。 価値創出に向けてスピード感を持って取り組みつつ、チームでの成果を大切にできる方にとって、ラボはマッチする環境だと言えます。

最後に

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

今回のアンケートから、私たちが大切にしているスピード感や、「価値創出」に向き合うリアルな空気感を感じ取っていただけたなら嬉しいです。

このバリューに少しでも共感し、「自分もこの環境で挑戦してみたい」と興味を持っていただけた方は、ぜひカジュアル面談でお話ししましょう。

チームの成果を最大化してくれる仲間にお会いできることを、心より楽しみにしています。

quo-digital.jp

直近入社メンバーアンケート(前編) 「入社後のギャップ」と「苦労をどう乗り越えたか」 聞いてみました!

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

ラボでは、採用において「バリューマッチ」を大切にしています。

入社したメンバーが、ラボの目指す姿や進め方に共感し、自分らしく力を発揮できることが、チームとしての成果の最大化につながると考えています。

そのため、これまでもブログを通じて、ラボの目指す姿や価値観について発信してきました。

<関連記事>

今回は、さらに一歩踏み込み「実際のところはどうなのか?」というリアルな現状を伝えるため、直近で入社したメンバーにアンケートとってみました。

良い面だけでなく、直面した苦労や想定外だったことも含め、すべて「原文ママ」で公開します。 ありのままを発信することで、ミスマッチを減らし、ラボのバリューに共感してくださる方に、ご興味をお持ちいただけたら嬉しいです。ぜひ最後までご覧ください!

アンケート概要

今回は、情報の鮮度を重視し、2024年4月以降に入社したメンバーを対象に実施しました。

回答者:2024年4月以降に新たに入社した、ラボ所属のメンバー

質問内容:

(前編)

  • 入社後、想定外の「ギャップ」はありましたか?
  • 入社後、特に苦労した点とそれをどう乗り越えたか教えてください。

(後編 ※こちらは次の記事でご紹介します)

  • 入社後、ラボのカルチャーを特に実感した具体的なエピソードがあれば教えてください。
  • 自身の経験を振り返って、改めて「どんな人がラボにマッチしている」と思いますか?

アンケート回答紹介

ここからは、メンバーから寄せられた回答を「原文ママ」でご紹介します。

質問:入社後、想定外の「ギャップ」はありましたか? (入社前のイメージと比べてどうだったか、という視点で教えてください)

<お堅いイメージとのギャップ>

  • 昔からあるサービスなので堅い会社かと思っていたのですが、出社してみると社長との距離が近いことや会社の雰囲気が明るくて居心地がいいことに驚きました。

  • 金融系のためもう少しお堅いイメージを想像していましたが、新しいことを取り入れる(AIコーディングツール導入など)のに前向きなのは意外に感じました。

  • 金融系のサービスを展開しているので、ガチガチの組織体制であると感じていましたが、柔軟で、様々な意見を取り入れるスピード感があるなと感じました。

  • 想像以上にフラットな組織/チームだったこと

<スピード感>

  • 思っていた以上にチームとしてのスピード感があり、メンバー個々にしっかり芯があるなと感じました。

  • 想定以上にスピード感を大切にする文化であることに驚きました。意思決定から実行までのサイクルが速く、組織全体でスピーディーに動いている印象を受けています。

<働き方>

  • 働きやすさの面では怖いくらいギャップなく、本当に残業もないしお休みもとりやすくて、柔軟に働くことができています。 強いて言うと、本当に一人一人の裁量が大きいので、最初は本当に自分が決めて進めていいのか戸惑いも少しあったかなと思います。

  • 思ったよりカッチリしていて、緩く働いていない。ダラダラ長く働くこともせず、メリハリをつけて仕事をしている。

  • MTGが思っていたよりも多くて日によっては自分の作業があまり進まないこともあるので、MTGが多い日は自分の作業は進まない前提で計画を立てています。

<コミュニケーション>

  • 今のところ、ネガティブなギャップは特にありません。 入社前は、リモートワーク中心でテキストコミュニケーションが主体の環境だと、もしかしたら働きづらさを感じるかもしれないと少し不安がありましたが、実際に働いてみると、そんなことはありませんでした。 これは「15分ルール」のような仕組みが整っているおかげだと思います。 質問を投げたときにすぐに反応をもらえるので、作業が滞ることなくスムーズに進められています。テキストベースでも、コミュニケーションの質が高ければ十分に効率的に働けることを実感しています。

  • コミュニケーション手段は後で会話を見返す必要があるため、Slackでのやり取りが主なコミュニケーション手段になります。(もちろん簡単な内容は朝会で質問することも可能ですが、込み入った内容はSlackで事前に内容を展開します。)前職では頻繁にビデオ通話でコミュニケーションをとっていたため、最初は戸惑いがありました。

<開発環境、開発への取り組み方>

  • 開発ツールや使用する技術、監視ツール等使用しているツールや技術がラボ全体で統一感があり、入社直後からスムーズに業務に取り組むことができました。またシステムのアーキテクチャにもこだわりを持って設計されているため、安定性や拡張性が高く、安心して開発・リリースができる環境が整っていると感じました。

  • 入社前はしがないバックエンドエンジニアでしたが、こんな自分でも1年でインフラ・フロントエンド・設計・仕様調整などいろいろ経験できました。

<特になし・ブログなどからのイメージ通り>

  • 特にありません

  • 特になし。 スピード感のある対応を求められる点、AIツールなど良さそう/ダメそうを試してみて判断しすぐに切り替える点、自分達でチームの改善点を出してすぐに改善していくサイクルを回す点、など、入社前に想像していた通り(かつ自分の思想にあっている)です。

  • ちょっと考えてみましたが、特に思いつきません。事前にブログ等で情報を収集して、ある程度の精度で想定ができていたようです。

  • 想像していた文化的なギャップが思っていたより全然少なかった...というのがポジティブなギャップでした Tech Blogの「目指す姿・方向性と進め方」のマインドに惹かれて入社、「全然浸透していなかったらどうしよう...」と心配していましたが、皆さん概ね体現できている印象です

質問:入社後、特に苦労した点とそれをどう乗り越えたか教えてください。

<ラボの進め方への適応>

  • 究極的には言われたことをやればよかった前職とはチームの存在意義からして異なりますので、特定の作業についてどうこうというより、思考回路を根本的に作り替える必要がありました。まだ乗り越えられたとは言えませんが、とにかく今やろうとしている対応によってQUOカードPayの価値が高まるのかどうかをできるだけ考えるように自分に言い聞かせています。(具体性がなくて申し訳ないのですが…)

  • デプロイ作業に至るまでの行動やチーム内で決め事があったときの判断がスピーディなので、自分の中だけで決断を必要以上に思い悩んだりしていると遅延につながるため、アウトプットは早く完了することを心がけた

  • 入社当初は、ユーザー価値・ビジネス貢献・セキュリティ対策など、多岐にわたる課題の優先順位を判断することに苦労しました。ワーキングアグリーメントが整備されており、適切なフィードバックを受けられる環境だったため、ラボのカルチャーを理解しながら徐々に適応できました。

<フルリモートでのコミュニケーションへの適応>

  • 最も苦労したのは、テキストで端的に意図を伝えることの難しさです。対面であれば表情や声のトーンで補える部分も、テキストでは言葉だけで正確に伝える必要があり、これはとても難しいと今でも感じていて、日々試行錯誤しています。先輩方のSlack上のやり取りを観察して、良い表現や伝え方を積極的に学んでいます。「こういう聞き方をすると相手が答えやすいんだな」「この情報を先に出すと話が早いんだな」といった気づきを、実際の業務に取り入れるようにしています。

  • エンジニアリングマネージャーということでラボメンバー全員の考え方や思い、パーソナリティーなどを理解する必要があるが、フルリモート環境では言語外コミュニケーションができず苦労しました。日々の1on1を丁寧に行うことで対応しました。

  • Slackに全てを残す文化のため、不明なことを一旦テキストで記載することが慣れていませんでしたが、まずは要点と自分の仮説をテキストで送り、その上で複雑なニュアンスが必要な場合のみハドル(通話)を依頼するというルールを自分の中で設けました。これにより、記録を残しつつもスピード感を落とさずにキャッチアップすることができました。

  • チャットによるコミュニケーションは文章でのやり取りになるため、より抜け漏れなくこちらの要望を相手に伝えられるように工夫する必要があります、ビデオ通話以上に事前準備をしっかり行い、伝わりやすい文章を書くことやアサーティブコミュニケーションを実践できるよう心がけています。現在はビデオ通話よりSlackによる文章のコミュニケーションの方が効率的にやり取りができると感じております

  • Slackでのやりとりの多さ。集中時間の確保を意識的に行うよう心がけている。

ドメイン知識や技術のキャッチアップ>

  • ドメイン知識の習得に苦労しています。決済だけではなく加盟店業務や発行業務など普段馴染みのないtoBドメイン知識が多くてみんな苦労してそうです。業務フローを書いたり関連部署にヒアリングしたりしてなんとか身につけています。

  • 長い歴史のあるサービスが根底にあるので、ドメイン知識・金融業界知識のキャッチアップに苦労しました。まだまだ乗り越えられてはいないですが、チームメンバーに積極的に質問したり、わからないワードは調べたりして日々頑張ってます。

  • 個人的には分からないことを聞くのが最初は難しかったです。でも、ラボ自体が結構質問が飛び交っているし、最初は他の人のやりとりとかたくさん目にして自然と聞けるようになりました。業務を通して自分で悩むより聞いたほうが早いと気づけたことも大きいかなと思います。

  • 入社直後に新設チームに所属、システム/アプリケーションの理解に苦労... チームメンバーのほとんどが新人のため、チーム内の知見が乏しく情報収集に苦労しました。 以下のような方法で改善を進めました。

    • チームの集合知をフル活用する。お互いが「何が分からないのか分かっていない」前提で情報を出し合うコミュニケーションを徹底する
    • チーム外の知識をフル活用する。チーム外のメンバーや技術顧問の方に相談する
    • AIをフル活用する。Claude, Claude Code, Devin等のAIツールを使い情報収集、整理をする

<その他>

  • 技術選定の方向転換の判断に時間がかかってしまった... 入社後に担当した案件でとある技術の導入を進めていたところ、案件がかなり進んだ段階で導入ができないことが判明しました。チームの検討/検証プロセスに問題があったと判断し、プロセスの改善を行うことで対応しました

  • 前例があるから、以前もそのやり方でやったから、という基準での判断は良くないということを学びました。ラボに入って間もないため、作業のやり方などラボで前例があるから、という理由で採用することもありましたが、その時とは背景が変わっている(時代や考え方の基準)ため、常に最新の思考で頭をリセットして、ベストな方法を考えるようにしなければならない、と考えるようにしています。

  • 前例がない依頼事項に対しての対応に苦労しました。部署も超えて色々な人へご質問・ご教授いただき依頼達成まで漕ぎ着けました。


本記事では、入社直後の「リアルなギャップ」と、苦労をどう乗り越えたかをご紹介しました。

「ラボの進め方」や「フルリモートでのコミュニケーション」への適応に苦労しつつも、周囲に支えられながら乗り越えていくエピソードに、「自走しつつも助け合う」ラボのカルチャーがよく現れていて印象的でした。

「価値を高めるためにどう動くか」と思考をアップデートし続けるなど、変化を楽しめる方には、マッチする環境だと改めて感じています。

次回の記事(後編)では、

  • 入社後、ラボのカルチャーを特に実感した具体的なエピソード
  • 自身の経験を振り返って、改めて「どんな人がラボにマッチしている」と思うか?

について、引き続きアンケート結果をご紹介します。

ラボの空気感をより深く知っていただける内容になっていますので、ぜひ次回の記事もご覧ください!

最後に

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

ラボでは「価値創出」のために、チームで協力して成果を出すことを大切にしています。

今回のアンケートから伝わるような、ラボ独自の進め方やカルチャーに少しでも興味を持っていただけた方は、ぜひカジュアル面談でお話ししましょう!

チームの成果を最大化してくれる仲間にお会いできることを、心より楽しみにしています。

quo-digital.jp

Claude Codeの良い点や悪い点、今後任せてみたいことについてアンケートとってみました!(後編)

はじめに

本記事は、クオカード デジタルイノベーションラボ(以下ラボ)のAIツール「Claude Code」に関するエンジニアアンケート結果レポートの後編です。

前編では、Claude Codeの具体的な活用方法や、導入による変化、効果的な活用に向けた取り組みについてご紹介しました。

後編となる本記事では、ツールの特性に焦点を当て、「良い点・得意な点」「課題点・苦手な点」、そして「今後任せたいこと」について、メンバーの率直な評価をご紹介します。

アンケート概要

回答者:ラボ所属のエンジニア、デザイナー

質問内容:

(前編)

  • Claude Codeの活用方法について教えてください
  • Claude Codeをより効果的に活用するために、個人やチームで工夫していることがあれば教えてください
  • Claude Code導入により、エンジニアリングの方法(開発プロセス・作業時間など)が変わったことがあれば教えてください

(後編)

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

アンケート回答紹介(後編)

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

ソフトウェアエンジニア

1. 開発サポートとコード生成能力

  • 雛形的なコードの作成(いわゆるボイラープレートコードの作成)はかなり得意だと感じます。要件や文脈、大まかな実装方針を伝えると動くコードを返してくれるので「こういう場合どう書けば良いんだっけ...」と悩む時間は0になりました
  • 広範囲にわたる一括修正などは人の手で行うより楽にできる。
  • 実装全般、特に支障なく使えているので得意なのかなと

2. コンテキスト理解

  • コンテキストの理解が過去に使ったAIより長けているように思います
  • 既存の実装を参考にさせるような指示を出すと大体うまく対応してくれる印象です
  • 既存のコードベースを理解して、改修するところ

3. 調査・分析

  • 自律的に考えながら複数のファイルを横断的に調べてくれるので、調査タスクに向いています
  • テーブル構造とソースコードを読ませて、調査に必要なSQLクエリを生成させる。

4.汎用性・連携

  • ターミナルベースで使えるので、どんなプロジェクト(IntelliJ IDEA, Android Studio, Xcode)でも使えるのが良い
  • IntelliJ IDEAと連携ができる

5. 補助ツールとしての活用

  • 人が気がつけない(意識から漏れてしまう部分)も定義されていればそれなりに拾って対象にしてくれる。補助ツール的な立ち位置では有効性が高いと思う

インフラエンジニア

  • 大量にデータがあっても細かいところまでチェックしてもらえるところ

QAエンジニア

  • 作業前に自らコードベースを調査してコンテキストを理解し、タスクを立てて計画的に開発を進める点が優れています。また、簡潔なプロンプトからでも意図を汲み取り、適切なドキュメントやコードを生成できる文脈理解力の高さも特長です。

UI/UXデザイナー

  • 注文通りのUIパーツを作成してくれる

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

ソフトウェアエンジニア

1. コードの品質と出力の信頼性

  • コードの質がインプット内容にかなり左右されると感じます。要件や文脈、できれば実現方法についても整理した上でインプットしないと意図とは違うコードを書いてくることがそこそこあります。また、エッジケースが考慮されておらずリリースすると問題の出るコードも書きがちなので現時点だとレビューと修正は必須かなという感覚です。
  • 最近結構回答精度が低い。/clear忘れると無駄に以前のcontext引き継いで関係ないことし出す(依頼してる私が悪い部分もある)

2. 思考力・理解力

  • 複雑な処理
  • ある程度自律的に考えてくれるものの思慮が浅いことは否めず、Claude Codeによるコードレビュー結果への信頼度は個人的には低めです。(見落としを指摘してくれることもあるのでプラスではあります)また、短絡的にわかりやすい答えに飛びつく傾向があります。判断軸をしっかり自分で持っておかないと、悪い方向に引きずられるリスクがあると感じます。
  • ソースコードの表面的な情報(関数名や変数名)で判断することがあるので、変なソースコード(変数名や関数名とコードの意図が違うコードなど)の場合、間違った情報を回答する。

3. その他

  • 簡単な修正でも回答までに時間がかかるので、自分でやった方が早い場面があるので、使い分けが必要。
  • コーディングのプロンプトを投げた時に少し古い情報を参照していることがある。
  • Teamプランだと無制限に使えない

インフラエンジニア

  • 知らないところは嘘をつく可能性もあるし見落としもあるので指示や追加確認が必要なところ

QAエンジニア

  • コンテキスト情報が不足していると、意図しないドキュメントやコードを生成することがあります。また、生成内容の誤りを指摘した際に、それを間違いではないかのように説明されることがあり、修正のやり取りに時間がかかる場合があります。

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

ソフトウェアエンジニア

  • 現状足りてなさそうなテストコードの追加
  • 負荷試験のシナリオ作成
  • ドキュメント作成
  • MCPを使って様々な情報源から文脈を読み込ませ、より精度の高いコーディングをさせてみたいです
  • 何でも
  • 特になし。(簡単なコード修正をしてくれる手としてしか考えていない。)

QAエンジニア

  • 複数のAI エージェントを同時に動かして並列開発を行う

アンケートの結果から、Claude Codeは「既存コードのコンテキスト理解」や「単純なコードの迅速な生成」といった開発サポート業務に強みがあり、適切に活用することで業務効率化に大きく貢献していることがわかりました。

一方で、「複雑な処理への対応」や「エッジケースの考慮不足」といった課題点も見受けられ、特にコードレビューや最終チェックの過程で人間の判断が不可欠であることも明確になりました。

今後の展望

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

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

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

最後に

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

ラボでは、新しい技術やツールを積極的に取り入れながら、チームで協力して課題解決に取り組める環境づくりを大切にしています。 そんな環境の中で、一緒にチームの成果を最大化してくれる仲間を募集中です! 少しでも興味を持っていただけた方は、ぜひカジュアル面談でお話しましょう。

quo-digital.jp

Claude Codeの活用方法や導入による変化についてアンケートとってみました!(前編)

はじめに

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

<関連記事>

この一環として、AIツール「Claude Code」を新たに導入しました。

本記事では、Claude Codeの活用状況や、そして「Claude Codeをどう使いこなしているか」「導入後に何が変わったか」について、ラボ所属のエンジニアにアンケート形式で聞いた結果をご紹介します。

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

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

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

<関連記事>

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

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

<関連記事>

アンケート概要

回答者:ラボ所属のエンジニア、デザイナー

質問内容:

(前編)

  • Claude Codeの活用方法について教えてください
  • Claude Codeをより効果的に活用するために、個人やチームで工夫していることがあれば教えてください
  • Claude Code導入により、エンジニアリングの方法(開発プロセス・作業時間など)が変わったことがあれば教えてください

(後編 ※こちらは次の記事でご紹介します)

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

アンケート回答紹介(前編)

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

ソフトウェアエンジニア

1. 実装・コーディング支援

  • 実装のプロトタイプ作成
  • 対応内容が明らかな場合の実装の叩き台作成
  • 単純なコード生成
  • SQL作成
  • テストコードの生成
  • (簡単な)ソースコードの修正(ビルドエラー解消、UT NG解消含む)
  • 実装の横展開など

2. 調査・分析

  • 障害調査
  • 問い合わせなどの調査
  • 仕様調査
  • ログ解析、CSV解析
  • 既存コードの調査

3. レビュー・品質管理

  • ルフレビュー
  • コードレビュー
  • テストや負荷試験等のチェック項目の洗い出し

4. ドキュメント作成

  • あらゆるドキュメントの作成

5. 総合的な利用

  • 繰り返し作業の依頼
  • 日々のコーディングではほぼ全てのシーンで使っています。特に以下のような時に使うことが多いです
    • 要件/仕様から関連するコードの洗い出し、最初の修正の作成
    • 共通の変更をまとめて行うなど、単純作業的なコード修正
    • 雛形的なコードの作成(いわゆるボイラープレートコードの作成)
    • エラーの原因調査と対応

インフラエンジニア

  • 新設定の追加、レビュー

QAエンジニア

  • コードベースから仕様調査。ドキュメント生成。コーディング。

UI/UXデザイナー

Claude Codeをより効果的に活用するために、個人やチームで工夫していることがあれば教えてください

ソフトウェアエンジニア

1. 指示の最適化

  • ある程度複雑な作業をする場合、いきなりコンソールで対話を始めるのではなく指示書を書き、Claude Codeに読み込ませて作業を進めさせることが多いです。場合によっては指示書自体も一部だけ作成し、Claude Codeに補完させて完成させることもあります
  • Claude AIで指示書を作成してから、Claude Codeに依頼する
  • より正確な情報を取得するためのプロンプト内容をClaudeに質問する
  • 指示や質問の内容を理解してもらった後、どのようなプロンプトが効果的だったかClaudeに問いかけて教えてもらい次回につなげる等

2. 定型化・共有

  • カスタムコマンドを入れてよく使うプロンプトは定型化している。
  • 専用エージェント設定ファイルを追加して、チームでAIの出力結果を統一できるように取り組んでいます。
  • 先輩方が必要そうな/共通で使えそうなプロンプトをリポジトリに入れてくれている(大感謝)

3. サブエージェントの活用

  • 定型作業用のサブエージェントを使ったりしている
  • subagent化できるタスクじゃないか?自分がタスクやる時多少意識している

4. レビューと品質保証

  • PRを出す際にClaude Codeによるレビュー(主にセキュリティや性能を観点とする)を必須としています

5. 英語学習

  • 英語で質問文を入力した際に、入力された英文を添削して、質問の回答とは別に、質問文の正しい英文を返すようにして英語の勉強にも使っている。

QAエンジニア

  • Claude Codeに調査結果や設計方針をドキュメント化してもらい、そのドキュメントをインプットとして実装を進めています。Claude Codeが文脈を正確に理解した状態でコード生成を行えるため、精度が向上していると感じます。

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

ソフトウェアエンジニア

1. 作業時間の短縮と効率化

  • 単純作業的なコーディングはほぼ任せられるようになっています。また、動くコードにするために必要なお作法的なコードを書く時間がかなり減り、本来やりたい処理の設計実装にかける時間は増えたと思います
  • 実装時間は短くなった:ある程度実装してくれるので、自分で調べる手間が減った
  • 実装の作業時間が減った印象があります
  • 7割ぐらいの完成度までもっていくスピードはかなり上がったと思います
  • 現状、大々的に変わるほどの使い方ができてないですが、単純に作業時間の短縮はあると思います
  • 既存実装の調査が楽になりました
  • ソースコードの一次調査は短時間でできるようになった。
  • AIがAPIの仕様書を作ってくれるようになったので、認知負荷が減った

2. コード品質・レビュー精度の向上

  • メモリリークなど重要な観点のレビューは、Claude Codeにもさせるようにした。
  • AIコードレビューにより、メモリリークの危険や非効率的なコードをレビュー提出前に検知できるようになったので、コードの品質が良くなっていると思う
  • 自己レビューの精度があがった:自分で見ても気付けない点に気づいて指摘してくれる

3. 作業アプローチの変化

  • まずはClaude Codeで楽できないか考えるとこから入るようになった(現実は作業時間が短縮したかというとケースバイケース)
  • 知らない言語でも臆することなくコード修正が出来るようになった。(言語の習得が早くなった)

インフラエンジニア

  • レビューの時間がとても改善しました

QAエンジニア

  • 開発プロセス

    • Claude Codeとの壁打ちで方針を固め、実装案を提案してもらい、それを人間が妥当性を判断するという流れが確立されました。このサイクルにより、効率的な開発が可能になっています。
  • 作業時間

    • 新規開発において、Claude Codeを活用することでプロトタイプの初期実装までの時間が大幅に短縮されました。

UI/UXデザイナー

  • 習得できていない方法も積極的に取り入れられる様になった

本記事では、Claude Codeが導入されたことで、「単純作業の時間短縮」「作業アプローチの変化」といった具体的な成果が現れていることをご紹介しました。

さらに、AI出力の統一を目指した専用エージェント設定ファイルの追加や、プロンプトの共有など、チーム全体で積極的な活用を推進していることもわかりました。こうした具体的な行動に、「チームで成果を出す」というラボの文化が表れていると感じています。

今後、効果的な活用をさらに加速させるには、ツールの特性を深く理解することが不可欠です。

次回の記事(後編)では、

  • 現時点でのClaude Codeの良い点、得意だと感じるところ
  • 現時点でのClaude Codeの課題点、苦手だと感じるところ
  • 今後Claude Codeに任せてみたいと考えているもの

について、引き続きアンケート結果をご紹介する予定です。ぜひ、次回の記事もご覧ください!

最後に

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

ラボでは、新しい技術やツールを積極的に取り入れながら、チームで協力して課題解決に取り組める環境づくりを大切にしています。 そんな環境の中で、一緒にチームの成果を最大化してくれる仲間を募集中です! 少しでも興味を持っていただけた方は、ぜひカジュアル面談でお話しましょう。

quo-digital.jp

ACM's O'Reilly Online Learning Platform導入から1年後の活用状況についてアンケートとってみました!

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

ラボでは、スキルアップ支援を目的として、2024年10月よりACM Skills Bundle Add-Onの特典である「O'Reilly Online Learning Platform」を導入し、希望者は自由に利用できる環境を整えています。

導入から1年が経過した今、メンバーが実際にどのように活用し、どのような学びを得ているのかについて、アンケートを実施しました。 本記事では、その活用状況をご紹介します。

ラボへの応募を検討している方や今後のため広く情報収集している方にとって、少しでも参考になれば幸いです。

参考記事:

アンケート回答者

ラボ所属のエンジニア、デザイナー

アンケート結果

ここからは実際のアンケートの内容を紹介します。

ACM's O'Reilly Online Learning Platformを活用して書籍を何冊読んだか教えてください。

入社したばかりのメンバーもいるため、冊数にばらつきは見られますが、多くのメンバーが積極的に活用していることが分かりました。

ラボでは「知りたいことをピンポイントで探して読む」という使い方が主流です。そのため、この冊数は「完全に読了した」冊数ではなく、「一部でも手にとって読んだ」冊数を含んでいます。

全体で最も多かったのは6〜10冊という結果で、最多読書数は47冊でした。

ACM's O'Reilly Online Learning Platformを利用して読んだ書籍で、特に役に立ったものや面白かったものがあれば、タイトルと感想を教えてください。(複数回答可)

ソフトウェアエンジニア

インフラエンジニア

UI/UXデザイナー


読まれた書籍の傾向からは、「現場の課題解決」を目的とした、実務志向の強い学習姿勢が読み取れます。

特筆すべきは「Beyond Vibe Coding」などのAI活用に関する書籍が複数のメンバーに読まれていた点です。これは、AIツールを積極的に活用しているラボにおいて、その効果を最大化するために自律的に知識習得に取り組む姿勢が表れています。

関連記事:

次にACM's O'Reilly Online Learning Platformを利用して読もうとしている書籍があれば、タイトルと読もうとしている理由を教えてください。(複数回答可)

ソフトウェアエンジニア

インフラエンジニア

  • 直感LLM
    • LLMの仕組みや関連技術を学びたいため

運用エンジニア

  • 現時点では、アカウント継続させていないので、不明(もし、再開して読むならAI関連とか運用関連の書籍で、チーム改善&ラボへの貢献という意味合いで)

UI/UXデザイナー


これらの回答から、今後もそれぞれが業務に直結しそうな知見について、自律的に学習しようとしている姿勢が見受けられました。

最後に

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

ラボでは、自律的に学び、その知見を活かしてチームの成果を共に最大化していく仲間を募集しています。 少しでも興味をお持ちいただけた方は、是非カジュアル面談でお話しましょう!

quo-digital.jp