QUO CARD Digital Innovation Lab Tech Blog

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

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

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

(最終更新日:2026/4/3)

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

quo-digital.jp

プロダクト

www.quocard.com

2026年の組織体制について

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

技術スタック

開発の進め方

働く環境

勉強会

技術ブログ

メンバーアンケート

メンバーインタビュー

採用関連情報

open.talentio.com

「プロフェッショナルスポーツチームのような組織」を目指す姿勢に共感。スクラムの実践とマインドアップデートで、価値創出に奮闘するFさんの挑戦

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

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

自己紹介

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

2025年4月に入社したFです。

前職はSIerで、WindowsアプリやWebアプリの開発に携わっていました。

現在は地方からフルリモートで勤務しています。 最近は子供が小学生・中学生と大きくなってきたので、休日に一緒にキャッチボールをしたり外で遊んだりして過ごしています。

転職軸

ーー転職で重視した点について教えてください。

大きく2点あります。

1つ目は、キャリアの方向性です。経験を積むにつれてマネジメント業務を期待されるようになりましたが、自分としてはプレイヤー(Individual Contributor)として、現場でスキルを磨きながら貢献し続けたいという思いがありました。

2つ目は、働き方の改善です。前職はフル出社で、夜21〜22時まで働き、そこから1時間かけて帰宅する生活でした。ワークライフバランスを整え、健康的な生活を送りたいと考えました。

入社の決め手

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

以前一緒に働いていたメンバーがラボにいて、話を聞いたのがきっかけです。

転職軸として、プレイヤーとして現場で貢献し続けられる環境を重視していたこともあり、ラボが「プロフェッショナルスポーツチームのような組織」を目指している点に強く共感しました。階層組織ではなく、一人ひとりが技術と責任を持ち自律的に動く、フラットな組織を実際に見てみたいと思い入社を決めました。

関連記事: クオカード デジタルイノベーションラボが目指す姿と進め方について

実際に入社しての感想

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

実際に「プロフェッショナルスポーツチームのような組織」を目指す文化が浸透していると感じました。

フルリモートでのコミュニケーションについても、今のところ特にデメリットは感じていません。相手の反応が見えない手探り感はありますが、自分から発信することを意識しています。

困ったときは、過去のSlackやBacklogのWikiにヒントがありますし、メンバーに聞けばすぐに助けてくれるので、安心して取り組めています。

担当業務

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

現在はECチームに所属し、QUOカードPayのオンラインストアの開発を担当しています。他部署への仕様に関するヒアリングや問い合わせにも対応しています。

ーーコミュニケーションで心がけていることはありますか?

相手に合わせた「翻訳」を意識しています。 特に非エンジニアの方とはバックグラウンドが異なるので、こちらの思いをそのまま投げるのではなく、相手が知りたい情報や分かりやすい用語を選ぶようにしています。

相手がこちらの意図を汲み取るのに悩む時間をなくし、一回でスムーズに伝わる状態を作ることで、チーム全体のスピード感にも繋がると考えています。

ーー前職でのどのような経験が、今の業務に活きていると感じますか?

前職で、上流の要件定義から深く携わっていた経験です。単に言われたものを作るのではなく、「なぜこれを作るのか」「どうすればもっと良くなるか」を発注元と議論してきたことが、今に繋がっています。

ラボでも、ユーザーや他部署が抱える課題に対して、自ら解決策を模索し改善し続ける姿勢が求められるので、そうした場面で前職で培った視点を活かせていると感じます。

1日の流れ

ーー1日のスケジュールを教えてください。

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

🕖 4:00 起床

2時間ほどウォーキングや筋トレなど、一人で自由に使える時間として過ごします。

🕖 6:00 子供と一緒に朝食

🕖 7:00 子供と一緒に登校

地域の登校見守り監視員として横断歩道に立ちます。

🕖 7:30 帰宅

YouTubeを見ながらラジオ体操や自衛隊体操をしています。習慣化しないとやらなくなってしまうので、意識的に時間を設けています。

🕖 8:00 業務開始

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

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

チームで15分ほど、進捗や課題を共有します。

🕖 12:00 昼食

🕖 13:00 業務再開

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

関連記事:

🕖 16:30 業務終了

🕖 退勤後

子供の宿題を見たり、ゲームをしたり、読書したりします。

書籍はACM's O'Reilly Online Learning Platformを活用したり、Amazonで中古本を買って読むことが多いです。

関連記事:

🕖 21:00 子供の寝る時間に合わせて一緒に就寝

大変だったこと

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

ECチームは入社して日の浅いメンバーも多く、当初は過去の経緯を把握しきれないことが課題でした。SlackやWiki、GitHubの履歴をひたすら遡り、情報を掘り起こす作業には時間を費やしました。

ただ、そこは今、AIを活用することで効率化できています。 私にとってAIは「優秀な部下が増えた」ような感覚です。丸投げするのではなく、自分の手足として動いてもらい、出てきた成果物を自分で確認してハンドリングする。主体性はあくまで人間が持つというスタンスで活用しています。

また、インフラ周りのAWSなど経験が浅い領域のキャッチアップも大変でしたが、ドキュメントの参照やAIの活用、専門チームへのヒアリングを通して、知見を深めることができています。

関連記事:

やりがいを感じたこと

ーーどんな時にやりがいを感じますか?

自分が実装したものが即座にリリースされ、リアルタイムで運用改善やUX向上に直結することです。前職ではユーザーの反応を得るまでに半年かかることもありましたが、今のスピード感はラボならではだと感じています。

また、リリースして終わりではなく、そこからさらにフィードバックを受けて改善を回していけることに、大きな手応えを感じています。

ーースピード感を出すために、心がけていることはありますか?

最近、チーム内での意思決定のスタイルを見直しました。室長の齋藤さんからの助言もあり、「合議制でスピードを落とすのではなく、各自の判断でまずは実行し、フィードバックをもらいながら修正していく」という考え方を取り入れています。

これまでの経験とは違う進め方ですが、柔軟にこなせるよう意識して取り組んでいるところです。

成長した点/叶えられた点

ーー転職して得られた収穫について教えてください。

キャリア面では、スクラムの基本的なプロセスを実践できていることが大きな収穫です。

これまでは言葉のイメージこそありましたが、具体的にどう機能し、どんな効果をもたらすのかまでは掴めていませんでした。 実際に運用してみることで、そのメリットを肌で感じ、理解が深まりました。結果として、開発の進め方や自分のマインドにも良い影響を与えていると感じます。

生活面では、完全に朝型へシフトしたことです。4時起きで体を動かしてから仕事に入るといった、健康的な生活が送れるようになったと思います。

今後挑戦したいこと

ーーこれから挑戦したいことを教えてください。

まずチームとしては、自分たちで正しい方向へ進める力を養いたいです。そのためには、日々新しい情報を積極的にインプットし、それを実務の改善にどう活かせるかを模索しながら、チームへ還元していきたいと考えています。

来月スクラムマスター研修にも挑戦するので、その学びもチームの改善に繋げていきたいです。

個人としては、SIer時代の「お客さんに判断を委ねる」マインドから脱却することです。事業会社のエンジニアとして「自ら決めて動く」ことを基本に据え、周囲のフィードバックをもらいながら迅速に修正・改善していくスタイルを、確立させていきたいです。

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

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

技術力はもちろん重要ですが、それ以上に日々の業務やコミュニケーションの中で自ら課題を見つけ、改善案をオープンに発信できるマインドを持った方と、ぜひ一緒に働きたいです。

また、フルリモートという環境は、地方在住の方や子育てなどでキャリアを諦めかけている方にとって、可能性を広げてくれる働き方だと思います。「地方だから」「子育てがあるから」とキャリアを諦めず、今の環境を活かして挑戦したいという方に、ぜひおすすめしたいです。

最後に

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

quo-digital.jp

技術顧問による週1の相談・勉強会についてアンケートとってみました!

はじめに

クオカード デジタルイノベーションラボ(以下ラボ)では、週に1度、技術顧問の方をお招きして、相談や技術レクチャーの場を設けています。

前回の記事(2024年3月)から月日が経ち、チームには新しいメンバーも増え、回数も積み重なってきました。

そこで今回は、改めて相談・勉強会を通してどんなことを学び、実務にどう役立てているのか、メンバーにアンケートをとった結果をご紹介します。

技術顧問による相談・勉強会について

講師の方や具体的な開催方法については、ぜひ前回の記事をご覧ください。

アンケート回答紹介

ここからは、実施したアンケートの回答をご紹介します。

質問内容

1. 技術顧問への相談で、実務に役立ったエピソードを教えてください

2.過去に取り上げられた書籍やレクチャーの中で、特に印象深かった、学びになったものとその理由を教えてください

3.技術顧問による相談・勉強会を通しての変化(設計力や視座の変化など)について教えてください

1. 技術顧問への相談で、実務に役立ったエピソードを教えてください

セキュリティ・認証に関する相談

  • 認証処理関係の実務を行なっていた時、セキュリティとユーザビリティのトレードオフをどのように調整すべきか悩み、相談させていただきました。その際、いくつか私個人では出せなかった仕組み、解決策を提案いただき、実際に導入することとなりました。

  • 過去何度か相談させていただき、どの相談についても基本的に実務に役立っておりますが、直近の例でいえば、CSP(Content Security Policy)のホワイトリスト対応について、複数の対応案があり、どの案がよいか相談させていただきました。

  • セキュリティ関連の相談事項でいくつか役に立ったことがありました。セキュリティなのであまり詳細は書けないですが、より堅牢にするための相談、セキュリティとユーザビリティとのバランスをとるための相談、など様々な観点で役に立ちました。

データモデリング・テーブル設計に関する相談

  • 新規サービスの開発に必要なデータモデルの作成でいろいろアドバイスをいただいて大変助かりました。

  • テーブル設計に関して、チーム内で煮詰まっていた(案は出てもどれがベストか選択できていなかった)が、相談して新たな視点でアドバイスをいただいて検討が進んだと感じた。

  • イミュータブルデータモデル設計の考え方はテーブル設計する上で参考になりました。

その他

  • feature flags の話はチームでも取り入れるタイミングだったので、実例や考え方など大いに参考になった。

  • DB論理障害に関する相談

  • 実務上で直面している課題に対してのアプローチや知見を直接相談して聞けるので検討時の視野を広げるのにとても役立っています。(自分達だけでは見えなかった角度からのアプローチ等が得られる)

2.過去に取り上げられた書籍やレクチャーの中で、特に印象深かった、学びになったものとその理由を教えてください

意思決定・技術選定の考え方

  • 「決めない技術選定」現実のビジネスに対して何を決めて・何を決めない(曖昧にするのではなく柔軟にする)を判断していくというのはAIの進展に対してまだ人間が優位を持てる部分であり、今のエンジニアの価値として大きなポイントだと感じたので、エンジニア不要論の中での今後の戦い方の良き参考になると感じたため。

  • 最近ですが「決めない技術選定」という題で話された内容(何を決めるか、何を決めないか、意思決定をADRに残す)が印象深かった。

設計思想・プログラミング原則について

  • 「Parse, don’t validate」の回が特に印象深かったです。当時は、レイヤの切り方や各レイヤの責務分割が設計において重要だと考えていましたが、それよりも、システムへの入力を検証(Validate)するのではなく、業務的に正しい状態の型へ変換(Parse)することのほうが設計としては重要だとわかり、設計の考え方が変わったためです。この「Parse, don’t validate」については、この回に限らず、何度かレクチャーしていただいているため、これまでのレクチャーの中で重要度が高い印象があります。

  • 「Balancing Coupling in Software Design」今まで設計での判断の基準が直感的でしたが、根拠を言語化できる知識が身につくのでチームで議論する際には役に立つと思いました。

システム設計について

  • 「イミュータブルデータモデル」テーブル設計する上での新たな考え方として参考になった。

  • 「データモデリングワークショップ」上流設計の知見が浅い自分にとっては、考え方・やり方とても参考になった。

ドメイン知識・システムの堅牢性について

  • クレジットカード等の決済代行とECサイトとの統合パターンの資料、レクチャーが興味深かったです。もともと興味があり、かつ決済なのでクリティカルな部分なためです。

  • DB論理障害に関する相談の際にレクチャーいただいた各対応策について(実務に直結するテーマだったため)

古典的名著による基礎力の向上

  • 特にこれ!という物はないです。PoEAAやデータ指向アプリケーションデザインのように古典的名著を取り上げていただくことがほとんどなので、大体全ての書籍で基礎力の向上や再学習に役立っていると感じます。

3.技術顧問による相談・勉強会を通しての変化(設計力や視座の変化など)について教えてください

視座の高まりと「引き出し」の増加

  • 自分だけだとなかなか見えなかったであろう視座や視点を徐々に身に付けられている実感はあります。

  • 設計や開発の仕方の思考が広がったと思う。

  • 実務への直結の有無を問わず、各課題に対する対応策や考え方などの引き出しが増えたように思います。

解像度を上げ、実務に活かす

  • 方法論のみではなくサンプルコードや実務経験のエピソードを交えてレクチャーいただけるため、方法論は理解していたものの実務の設計/実装に活かせていなかった知識を実務に活かせるようになっていると感じます。

  • なんとなく意識していたようなことについても、勉強会で理由・なぜそうなのかを押さえることができて、他の場面にも応用できる「原則」として自分の中に定着してきた→ 技術的な手法等について解像度が上がった。

設計プロセスの深化

  • 設計時に型で表現することを大事にする姿勢が自然と染み込まれている感じがする。

  • テーブル設計に関する相談を通して、業務の概念を正確に捉えてからシステムに落とし込む、という順序の大切さを実感した。(未経験の領域でもあったので大変勉強になった)

その他

  • 設計で迷った時などは勉強会で共有いただいた資料を参考にする機会は増えました。

  • 以前よりは実際に作ってみることを重視するようになった気がします。


アンケートの回答から、実務の課題解決はもちろん、メンバーそれぞれの視座が高まり、チーム全体の地力が底上げされていることがわかりました。

最後に

クオカード デジタルイノベーションラボでは、より良いサービス開発を実現するため、エンジニアの技術力向上に向けた取り組みを大切にしています。

もし、ラボの文化や開発環境に少しでも興味を持っていただけたら、ぜひカジュアルにお話ししましょう!

quo-digital.jp

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

こんにちは!

クオカード デジタルイノベーションラボ(以下ラボ)採用担当の金子です。 今回は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の投稿なども積極的に確認し周りの状況も把握するなど、自分から動ける方が向いていると思います。

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

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

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

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

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

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

<技術への意欲>

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

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


今回のアンケート結果を振り返り、常に改善を回し続ける姿勢が、ラボのスピード感につながっていること、そして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