今回は、 第5回の「営業」の回 に続き、再び「幕間」として、技術とは少し異なる、しかしQAエンジニアにとっては避けて通れないテーマについてお話しします。 そのテーマとは、「品質」です。 QAエンジニアと名乗る以上、「品質」という言葉は常に私たちの隣にあります。 私はこの言葉をなんとなく分かった気で使っていました。 そして、(今となっては幸いなことに)あるタイミングで、この言葉を明確に言語化する必要に迫られました。 その過程で出会ったのが、TQMという品質マネジメントに関わる包括的な方法論です。 私自身、TQMの専門家と呼べるほど成熟しているわけではありません。しかし、この考え方に触れたことが、私が「品質」をどう捉え、それをどう自分のキャリアの土台とするかに、決定的な影響を与えました。 今回は、このTQMという概念を通じて、私がどのように「品質」という言葉に向き合ってきたかをお話しします。 記事一覧：技術を土台にして自分なりのQAエンジニアを組み立てる -あるQAの場合 【第1回】専門性をつなげて、あなたらしいQAエンジニアの像をつくる 【第2回】テストを設計する専門性 【第3回】テストマネジメントはテストマネージャーだけの技術ではない 【第4回】テストプロセス改善：思考の補助線としての専門技術 【第5回】幕間：異業種経験を土台にする 【第6回】テスト自動化：「設計原則」を知り、当たり前の技術にする 【第7回】スクラムマスターの専門性を持ったQAエンジニアとして 【第8回】幕間：「品質」という言葉に向き合う “品質”という言葉を使うことの畏れ多さ 「品質」という言葉は開発現場でよく使われます。 一方で、「品質はなんもわからん」と口にするベテランのエンジニアや品質保証の専門家も多く見受けられます。 QAエンジニアとして「品質」という言葉を意識し始めた頃、私自身はこう思っていました。 「“品質”という言葉を軽々しく使ってしまうことは失礼に当たるし、本質を理解していないことになる」 今振り返ると、自分の虚栄心からそう思い込んでいたのかもしれません。 今でも「品質」という言葉を使う時には、多くの人が思い悩みながらも言語化を避けてきた恐ろしさ、そして先人達への畏れ多さを感じずにはいられません。 それでも、あえてその「魂」の部分に向き合い、自分なりに腹落ちさせるプロセスを経たことは、私のQAエンジニアとしてのスタンスを大きく変えるきっかけとなりました。 QAエンジニアという職能の捉え直し 現在の日本のソフトウェア開発現場において、『QAエンジニア』といえば、『テストをする人』や『テストの専門性を持っている人』を指しているのが実情です。私自身もその一人です。 しかし、TQMにおける「品質保証」という視点から捉え直すと、QAエンジニアの職能はもっと大きな範囲に広がるのではないか、と考えられるようになりました。 「顧客との間で明示的に約束しようがしまいが,徹底的に満足させてやろうとすること」 『 マネジメントシステムに魂を入れる 』p.54 TQMでの「品質保証」について学んだのはこの書籍ではないですが、私がこういった捉え方と出会ったとき、私はこの上なく自由さを感じました。私のQAとしての活動に、文字通り魂が宿ったと感じました。 そして、この目的を達成するためには、いわゆる「テスト」という活動だけでは不十分だと私は考えています。 私がSqriptsなどのプロフィールで、単なる「QAエンジニア」ではなく、あえて 「 テストに専門性を持つQAエンジニア 」 と書いているのには、実はそうした背景があります。 私はあくまで、「テストの専門性」を土台（強み）として持っているQAエンジニアに過ぎないと考えています。そう考えれば、世の中にはもっと多様な土台を持つQAエンジニアがいて良いはずだと思うのです。 プロダクトマネジメントに専門性を持つQAエンジニア SREに専門性を持つQAエンジニア カスタマーサクセスやマーケティングに専門性を持つQAエンジニア どのようなバックグラウンドであれ、「品質」という目的のためにその専門性を発揮するのであれば、それは胸を張って「QAエンジニア」と名乗ってよいのではないか。 TQMの思想に触れる中で、私はそう確信するようになりました。 品質保証を広義に捉えることの危うさ 「品質保証」をこういった広義に捉えることはある種の危うさをはらんでいます。 それは「品質保証の責務を押し付けられた」あるいは「QAが品質保証を放棄した」と捉えられることです。 現実との差分として、そういった捉え方をするのは自然なことだと思います。 だからこそ私は今まで語ってきたさまざまな専門性と接続して、建設的に、そして納得感を持ってチームに実装していく必要があると感じています。 専門性の組み合わせ 「品質」という概念を深掘りしたことによって、他の専門性との結びつきもより強固になりました。 スクラムマスター（アジャイル）との組み合わせ 「品質」という言葉の本質を捉えようとすると、「アジャイル」という概念がより鮮明に理解できるようになりました。 例えば「アジャイルソフトウェア開発宣言」で語られている価値観は、驚くほどTQMの思想と合致しています。 品質を単なる「仕様通りであるか（品質特性）」だけで理解するのではなく、「顧客にとっての価値」や「提供側としての在り方」という本質的なところから考えることなどです。 スクラムやアジャイルの実践は、単なるフレームワークの導入ではなく、「本質的な価値提供のために、我々はどう行動すべきか」という問いをより強固なものとします。品質への深い理解は、アジャイルなチームビルディングを行う上での強力な土台になると考えるのです。 テストマネジメントと品質マネジメント かつての私は、「テストマネジメント」と「品質マネジメント」をほぼ同一のものとして捉えていました。しかし今は、これらを明確に区別して考えています。 品質マネジメントという全体の中に、テストマネジメントが位置づけられる。 この視点を持つと、テストの役割がより柔軟に見えてきます。 品質を作り込むために、テストはどうあるべきか。 そう考えると、典型的には「シフトレフト」の必要性にまず気付けると思います。 あるいは、「シフトライト」や「運用でカバーする」という判断、さらには「オブザーバビリティ」を高めることや、マーケティングの視点からのフィードバックが必要になるかもしれません。 「テスト」という枠組みを超えて、様々なステークホルダーと「品質」を共通言語に会話ができるようになる。これが、品質マネジメントの視点を持つ最大のメリットだと感じています。 実務において、「品質」を脇に置くことも考える 正直なところ、実務の現場において、「品質とは何か？」といった哲学的な議論を頻繁に持ち出すべきではないと私は考えています。 定義論争は時に不毛なものになりえます。 特にQAエンジニアの実務において、個人の胸の内に留めておくということもチームを健全に前に進めるためには必要になるでしょう。 私自身、哲学的な議論が大好きです。 一方で 「私たちはどういった世界を実現したいのか」、 「そのために、お客様やステークホルダーにどういう状態になってほしいのか」、 そういったことを建設的に議論するほうが、プロジェクト、あるいは世界は前に進むことも多いでしょう。 大切なことは「顧客満足のために在りたいスタンスを取り続けられること」だと思っています。 そしてその議論の中で使われる言葉は、必ずしも「品質」という言葉でなくても構わないと思っています。 「品質」という言葉を使ってしまうと、今まで「品質」という言葉をつかってこなかったチームにとってマウントを取られた気分になりえます。 実際に私は「QAエンジニアとして品質について理解している」そういった気持ちでいたことがあります。 そんな時に、別の言葉で表現したり、脇に置いて前向きに対話していくことで、私は「いきいきとした」チームになっていく姿をたくさん見てきました。 そして、それこそが品質を扱う私の働き方の醍醐味だと思うようになったのです。 それでも品質を言語化すること 最後まで読んでいただきありがとうございます。 本稿を読まれた皆様は、「QAエンジニア」を名乗っている、あるいは目指しているのではないでしょうか。 皆さんのアイデンティティの核である「品質」、あるいは「品質保証」について、一度じっくりと考え、自分なりの言葉で向き合ってみてはいかがでしょうか。 ここであえて、私なりに品質について一言で表しましょう。「誰かがハッピーになること」です。 「品質」。 畏れ多い言葉です。 しかし、そこから逃げずに自分なりの答えを持てた時、それは「自分はなぜここにいるのか」「自分の専門性はどこで活かせるのか」という、QAエンジニアとしての揺るぎない土台になると、私は信じています。 参考文献 書籍『マネジメントシステムに魂を入れる』 ／飯塚悦功（著）、公益財団法人日本適合性認定協会（編集）日科技連出版社、2023年 やまずん、QAとしての自分の考えを表明するためのポジションペーパー https://55ymzn.com/me/positioning_paper_of_qa/ 【連載】技術を土台にして自分なりのQAエンジニアを組み立てる -あるQAの場合 【第1回】専門性をつなげて、あなたらしいQAエンジニアの像をつくる 【第2回】テストを設計する専門性 【第3回】テストマネジメントはテストマネージャーだけの技術ではない 【第4回】テストプロセス改善：思考の補助線としての専門技術 【第5回】幕間：異業種経験を土台にする 【第6回】テスト自動化：「設計原則」を知り、当たり前の技術にする 【第7回】スクラムマスターの専門性を持ったQAエンジニアとして 【第8回】幕間：「品質」という言葉に向き合う The post 【第8回】幕間：「品質」という言葉に向き合う first appeared on Sqripts .

はじめに こんにちは、新規事業部フロントエンドブロックの 池田 です。普段は ZOZOマッチ のアプリ開発を担当しています。ZOZOマッチは、ファッションの好みからZOZO独自のAIが「好みの雰囲気」の相手を紹介するマッチングアプリです。開発にはFlutterを採用しています。 フロントエンドブロックは2024年に発足したチームです。発足間もないチームゆえに、開発を進める中でさまざまな課題に直面しました。本記事では、私たちが「課題をチーム全体で認識し、解決していける文化」を築くために取り組んできたことを紹介します。発足間もないチームでチームビルディングに悩んでいる方や、メンバー間の連携・知見共有に課題を感じている方、新規事業部の取り組みに興味のある方の参考になれば幸いです。 目次 はじめに 目次 背景・課題 取り組み KPTによる改善サイクル KPTから生まれた改善施策 進捗・困りごとの可視化 AIエージェントツール知見共有の仕組みづくり PRレビュー速度の改善 まとめ 背景・課題 フロントエンドブロックは3名と外部パートナーで構成されるチームです。新規事業部では、市場の変化に素早く対応しながらプロダクトを成長させていく必要があります。そのため、少人数でもスピード感を持って開発を進められる体制と、走りながら改善していける柔軟性が求められます。しかし、発足から日が浅いこともあり、チームとして改善サイクルを回す文化がまだ根付いていませんでした。開発プロセスや技術的な課題に直面しても、その解決が個人の力量に左右される状況があり、課題が個人の中に閉じてしまっていました。 具体的には以下のような問題がありました。 メンバーの困りごとが見えにくい ：各メンバーの抱える課題や悩みがチーム内で可視化されておらず、助け合いやサポートが難しい状態だった 改善を議論する場がない ：課題を感じても、改善案を提案・議論する場が整備されていなかったため、ナレッジがチームに蓄積されなかった こうした状況を打開するには、まずチーム全体で課題を共有し、改善を積み重ねていける仕組みづくりが必要でした。 取り組み ここからは、これらの課題に対してチームで取り組んできた改善施策を紹介します。まず改善サイクルを回すための仕組みとしてKPTを導入し、その中で見えてきた具体的な課題に対して個別の施策を実施してきました。 KPTによる改善サイクル チームとして改善を回していく文化を根付かせるため、KPT形式の振り返り会を実施しています。KPTでは、Keep（良かったこと）・Problem（課題）・Try（次に試すこと）の3つの観点で振り返ります。案件でやって良かった取り組みや大変だったことを洗い出し、次の案件へ活かせるようにしています。 振り返りの流れ 振り返りにはMiroを活用しています。具体的な流れは以下のとおりです。 付箋の記入 ：各メンバーがKeep・Problem・Tryの各エリアに付箋を貼る 投票 ：特に議論したい項目に投票し、優先度を付ける 議論 ：投票数の多い項目を中心に議論し、Problemに対しては具体的なTryを設定する 議論の際は、単に事象を共有するだけでなく、一歩踏み込んだ振り返りを意識しています。Keepについては「なぜうまくいったのか」を深掘りし、成功要因を言語化することで再現性を高めています。Problemについては「今後どうすればうまくいくか」をチームで話し合い、具体的な改善策を導き出すようにしています。次回の振り返りでは前回のTryの効果を検証し、継続するか改善するかを判断します。このサイクルを回すことで、個人の中で閉じていた課題がチーム全体で共有され、改善へつなげられるようになりました。 ツールと頻度の選定 振り返りツールにはいくつかの選択肢を試しました。当初は Findy Team+ のKPT振り返り機能や Parabol を使っていました。しかし、Miroに慣れているメンバーが多かったことと、付箋からJiraチケットへの変換が容易だったことから、最終的にMiroを採用しました。 頻度は隔週1時間程度で実施しています。 KPTを継続する中で、メンバー自らが課題を発見し改善策を提案するボトムアップの文化が根付いてきました。以降で紹介する施策も、その多くはKPTでメンバーから挙がった声がきっかけになっています。今後は付箋の数が減ってきたタイミングで、イベントタイムラインなどを取り入れることも検討していきたいと考えています。 KPTから生まれた改善施策 進捗・困りごとの可視化 KPTで「メンバーの困りごとが見えにくい」という課題が挙がりました。開発初期は特に実装するチケットが多く、誰がどのタスクを進めているのか、どこまで進んでいるのかが見えづらい状況でした。メンバーの進捗を日常的に把握するため、以下の取り組みを行っています。 朝のSlackスレッドでの共有 毎朝Slackのリマインダーが自動投稿されるので、出勤したらそのスレッドに今日やることを書くようにしています。テキストで残すことで、非同期でも状況を把握でき、困りごとがあればすぐにフォローできる体制が整いました。 スレッド内でのやり取りなので、気軽に質問を投げられるのもポイントです。業務に関する質問だけでなく、雑談や改善提案の話もそこから自然と生まれるようになりました。 夕会でのアクティブなスプリントの確認 フロントエンドブロックでは毎日夕会を実施し、今日やったタスクと困っていることを共有しています。 以前はメンバーがそれぞれやったことをConfluenceに書いて報告していました。しかし、この方法にはいくつかの課題がありました。 アサインされているチケットがどれくらいあるのか見えづらい レビュー待ちのチケットが溜まっているのか把握しにくい 書く人によってタスクの粒度が異なり、状況を正確に把握しづらい これらの課題を解決するため、Jiraのアクティブなスプリントを画面共有しながら進捗を確認する運用に変更しました。スクラムボードのアクティブなスプリントでは、現在進行中のタスクをステータス別（未着手・進行中・レビュー待ち・完了など）に並べカンバン形式で確認できます。 この変更により、各メンバーがアサインされているチケットやステータスが一目でわかるようになりました。ステータスが長く変わっていないチケットも把握できるため、困っていることがないか声をかけやすくなりました。また、報告のために文章を書く手間が減り、ボードを見ながら自然と議論が生まれるようにもなりました。 また、夕会では明日やることも共有しています。アサインされているチケットが前倒しで完了した人にはチケットが多い人から分配するといった、チーム内での負荷調整もこの時間で実施しています。 AIエージェントツール知見共有の仕組みづくり KPTでは「AI活用をチーム全体に広げたい」という声が挙がりました。ZOZOではClaude CodeやGitHub Copilotなど、さまざまな開発AIエージェントツールを利用できる環境が整っています 1 。新規事業部では、こうした新しい技術やツールを積極的に取り入れ、開発プロセスの改善にチャレンジできる文化があります。私たちのチームでは、執筆時点ではClaude Codeをメインに、実装からPR作成・レビュー・CI修正まで開発プロセス全体で活用しています。特定のツールに限定するルールは設けておらず、Codexなど他のツールで検証するメンバーもいますが、チーム全体としてはClaude Codeの利用が中心です。しかし、AIツールを使いこなしているメンバーとそうでないメンバーとの間に差があり、チーム全体で活用していくにはまだ改善の余地がある状態でした。 この状況を改善するため、チーム内で知見を蓄積・共有するための仕組みを整備しました。 AI関連の知見を集約するSlackチャンネル AI活用に関する知見を集約する専用のSlackチャンネルを開設しました。このチャンネルにはエンジニアだけでなく、PMやビジネスなどのメンバーも参加しており、日々の業務改善にAIを活用できないかざっくばらんに話し合っています。チャンネルでは以下のような情報を共有しています。 「こういう場面で使えた」という活用事例 ツールの設定方法やTips 勉強になった記事の共有 記事を共有する際には、チームとして取り組めそうな部分についても議論しています。チャンネルを開設したことで、メンバー全体のAI活用度が向上しました。また、AIに関する質問や相談が気軽にできるようになり、知見がチームへストックされるようになりました。 Claude Codeプラグインの共有リポジトリ Claude Codeにはプラグインとマーケットプレイスという機能があります。プラグインはClaude Codeの機能を拡張するための仕組みです。 公式ドキュメント では以下のように説明されています。 Plugins let you extend Claude Code with custom functionality that can be shared across projects and teams. プラグインには、再利用可能な命令セットである「スキル」、外部ツールと連携するための「MCPサーバー」、イベント駆動型の自動化を行う「フック」などのコンポーネントを含めることができます。マーケットプレイスは、これらのプラグインを配布・共有するためのカタログです。マーケットプレイスを追加すると、そこに登録されているプラグインを簡単にインストールできます。 私たちはこの機能を活用し、プロジェクト用の共有リポジトリを作成しました。このリポジトリは以下の目的で整備しています。 プロジェクト全体でAI活用できる環境を整備する チーム間でのAIの知見を共有できるようにする 車輪の再発明を防ぐ リポジトリには、各チームが必要なプラグインを追加していく運用にしています。現在はAtlassian MCP関連、Git関連、FlutterやWeb関連など、さまざまな用途のプラグインが集約されています。 リポジトリの構成は以下のようになっています。 plugins/ ├── atlassian-mcp/ ├── browser/ ├── flutter/ │ ├── .claude-plugin/ │ ├── skills/ │ └── .mcp.json ├── git/ │ └── .claude-plugin/ └── commands/ ├── branch/ ├── commit/ ├── issue/ └── pr/ └── help.md 各プラグイン（ flutter/ 、 git/ など）の中には、 .claude-plugin/ ディレクトリやスキル、MCPサーバーの設定ファイルが含まれています。 commands/ ディレクトリには、ブランチ作成やコミット、PR作成などの汎用的なカスタムコマンドを集約しています。 運用としては、新しいコマンドやプラグインを追加したい場合はPRを出してもらい、レビュー後にマージする流れです。また、新規プラグインをメンバーがキャッチアップできるよう、リポジトリの更新内容を先述のAI知見共有チャンネルへ自動投稿するGitHub ActionsのWorkflowも導入しています。 共有リポジトリを整備した1つ目のメリットは、Claude Codeのマーケットプレイス機能を活用することで、導入の手間を大幅に削減できる点です。プロジェクトの .claude/settings.json に extraKnownMarketplaces を設定すると、メンバーがプロジェクトを開いた際にプラグインがインストール候補として提示されます 2 。この設定ファイルはGitで管理されるため、チーム全体で共有でき、新しいメンバーも特別な手順なしで利用を開始できます。また、マーケットプレイスの自動アップデート機能を有効にすると、プラグインに更新があった際に自動で最新バージョンに更新されます 3 。そのため、チーム全体で常に最新のプラグインを利用できます。 { " enabledPlugins ": { " flutter@xxxx-marketplace ": true , " git@xxxx-marketplace ": true } , " extraKnownMarketplaces ": { " team-tools ": { " source ": { " source ": " github ", " repo ": " org/claude-plugins " } } , " project-specific ": { " source ": { " source ": " git ", " url ": " https://github.com/org/claude-plugins.git " } } } } 2つ目のメリットは、アプリ・バックエンド・Webの各チームで個別に管理していたスキルを一元管理できるようになり、知見の共有が促進された点です。同じようなプラグインを各チームで作成する重複作業がなくなり、他のチームが活用している便利なスキルをキャッチアップしやすくなりました。 PRレビュー速度の改善 KPTでは「PRレビューが遅い」という課題も繰り返し挙がっていました。レビュー依頼からマージまでのリードタイムが長く、各自の実装タスクが優先されることでレビューが後回しになりがちでした。この状況を改善するため、以下の取り組みを行いました。 Findy Team+によるレビュー状況の可視化 Findy Team+を利用し、PRのレビュー時間やサイクルタイムを可視化しています。KPT振り返り会では、Findy Team+のサイクルタイム分析やレビュー分析を定期的に確認しています。全体の指標を俯瞰しつつ、数値が悪化している項目を重点的にチェックすることで、開発プロセスのどこにボトルネックがあるのかをチームで共通認識として持てるようになりました。 実際にこの分析を通じて、KPTで挙がっていた「PRレビューが遅い」という課題がデータでも裏付けられました。感覚的な指摘が数値として可視化されたことで、具体的な改善アクションへつなげられるようになりました。 Google Engineering Practices Documentationの輪読会 レビュー待ち時間が長いという課題を受けて、 Google Engineering Practices Documentation の輪読会を実施しました。このドキュメントでは、コードレビューが遅れることによる弊害として以下の点が挙げられています。 チーム全体の開発速度が低下する ：新機能やバグ修正のリリースが遅延し、チーム全体のベロシティに影響を与える 開発者の不満が増加する ：レビューの滞りは開発者のモチベーション低下を招き、チームの雰囲気にも悪影響を及ぼす コード品質が悪化する ：レビューの遅れはPRの肥大化を招き、結果的にレビューの質も低下する悪循環に陥る 輪読会を通じて、これらの弊害をチームで共有しました。また、コードレビューはタスクの合間に行うものではなく、優先度の高い作業として扱うべきという認識を揃えることができました。さらに、輪読会はメンバー同士がコードレビューに対する考え方や心理的なハードルを知る機会にもなりました。「どこまで指摘すべきか迷う」「実装チケットを優先的に終わらせたい」といった悩みを共有することで、お互いの視点を理解し、レビューの進め方について建設的な議論ができました。 AI活用による効率化 レビュー時に「不具合の原因や実装背景が分かりづらい」「動作確認の手順が不明確」といった意見も挙がっていました。これらの課題についても、Claude Codeを活用して改善に取り組んでいます。具体的には、以下のようなカスタムスキルを整備しました。 スキル 用途 /pr-create 変更内容の要約に加え、不具合の原因や実装背景、動作確認の手順を含めたPRを作成する /pr-review コード規約やベストプラクティスに基づいたレビューコメントを生成する /pr-ci-fix CIの失敗原因を分析し、修正してコミットする /flutter-code-review ZOZOマッチアプリのコード規約をスキルとして登録し、実装やレビューの際に規約に沿った指摘ができるようにする これらのスキルにより、定型的な作業の時間を削減し、本質的なレビューへ集中できるようになりました。 さらに、Codexを活用したPRの自動レビューも導入しています。PRをオープンすると自動でCodexがコードレビューを実施するため、レビュアーはCodexの指摘を踏まえつつ、人間ならではの観点でレビューできるようになりました。 PRレビュー改善の成果 これらの取り組みの結果、Findy Team+の各分析で改善が確認できました。 サイクルタイム分析では、以下の改善が見られました。 PR作成数が約3倍に増加 ：AI活用の促進やレビュープロセスの改善により、PRを細かく分割して作成する文化が浸透しました オープンからマージまでの平均時間を約70％改善 ：レビュー待ち時間の可視化やCodexによる自動レビューの導入により、レビューのリードタイムが大幅に改善しました 一方で、グラフからはPR作成数が多い週ではマージまでの時間が増加する傾向も見て取れます。PRの量が増えるとレビュー負荷が高まり、結果としてリードタイムが延びてしまうという課題が残っています。今後は、レビュー体制の強化やさらなる自動化を通じて、PR数が増加してもマージまでの時間を維持・短縮できる仕組みづくりに取り組んでいきたいと考えています。 レビュー分析でも、Codexでの自動レビューとClaude Codeのスキル整備の前後で、各指標に改善が見られました。 指標 改善前 改善後 オープンからレビューまでの平均時間 10.3h 7.5h レビュー依頼からレビューまでの平均時間 10.1h 8.1h レビューからアプルーブまでの平均時間 17.1h 9.3h 特にレビューからアプルーブまでの平均時間は17.1hから9.3hへと約46％改善しました。Codexによる自動レビューでレビュアーの負担が軽減されたことに加え、輪読会を通じてレビューの優先度に対する意識が変わったことも、この改善に寄与していると考えています。 まとめ 本記事では、発足間もないチームが「課題をチーム全体で認識し、解決していける文化」を築くために取り組んできたことを紹介しました。KPTによる振り返りを起点に、進捗・困りごとの可視化、AIエージェントツールの知見共有、PRレビュー速度の改善といった施策を実施してきました。これらの取り組みを通じて、個人の中に閉じていた課題がチーム全体で共有され、継続的に改善を回せる体制を整えることができました。今後はDevinやFigma MakeといったAIツールも活用しながら、チーム内の改善にとどまらず、プロジェクト全体に対しても改善を働きかけていきたいと考えています。発足間もないチームでチームビルディングに悩んでいる方や、改善サイクルを回す仕組みづくりに課題を感じている方の参考になれば幸いです。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 hrmos.co 2026年1月時点におけるZOZOで利用可能な代表的なAIツールは「 ZOZOにおけるAI活用の現在 ~開発組織全体での取り組みと試行錯誤~ 」をご参照ください ↩ Configure team marketplaces - Claude Code ↩ Configure auto updates - Claude Code ↩

こんにちは。ファインディのPlatform開発チームでSREを担当している 原 です。 ファインディでは、普段私たちが開発しているファインディのプロダクトの裏側や、開発メンバーが日々どのように働いているのかをお伝えするために、Findy Tech Talkという技術系のオフラインイベントを開催しています。 今回は、そのイベントの第二弾となる「Findyのサービスを支える、横断SREチームのマネジメントと技術の挑戦」を開催しまして、その当日のそれぞれの登壇内容について書いていこうと思います。 findy-inc.connpass.com 今回のイベントでは、Platform開発チーム(以下、SREチーム)が登壇し、チームのミッションや普段の業務内容について各々の立場から発表していきました。 本記事では、イベントでの登壇内容をベースに「横断SREチーム」の立ち上げ戦略や、AI(Devin/Claude Code)による運用自動化、未経験からのキャリア形成など、登壇者自身からダイジェスト版にてお届けしていきます！！ 登壇内容 SREチームをどう作り、どう育てるか ― Findy横断SREのマネジメント Platform SREの軌跡：Terraform汎用化とAIで進めた「インフラ基盤」の構築と、その成果 フリーランスからSREへの転身 SREとしての第一歩：3週間の活動報告 BEから未経験でSREへ：オンボーディングとトイル改善の記録 まとめ 登壇内容 SREチームをどう作り、どう育てるか ― Findy横断SREのマネジメント speakerdeck.com SREチーム サブマネージャーの 安達(@adachin0817) です。Findyのサービスを横断的に支えるSREチームの立ち上げから現在までの3年間における「技術的な挑戦」と「マネジメントのリアルな葛藤」の2つについてお話させていただきました。 SREチームは、この3年間で多岐にわたる基盤整備と改善を実行し、着実に土台を整えてきました。 基盤のコード化・標準化 全環境のTerraform import化や、GitHub Actionsのテンプレート化を実施。 オブザーバビリティと信頼性の向上 Datadogの導入や、全サービスにおけるSLI/SLOの計測。 セキュリティの強化 Shisho Cloud(CSPM)やTakumi(SAST/DAST)を導入し、SOC2 Type2への対応。 開発体験の向上 開発環境の改善に加え、AI(Devin等)を活用した運用・構築の自動化など、先進的な取り組みも行う。 また、技術面だけでなく、チームビルディングやタスク管理の苦労、そしてその解決策についてもまとめていきました。 サブマネージャーとしてはマネージャーの右腕となり、メンバーへの技術指導・リスクマネジメント（過稼働の防止など）・ロードマップの策定を担っています。 チーム結成当初は、ビジョンやミッションが抽象的だったり、誰がどのサービスの責任を持つかが不明確で属人化しやすいといった課題がありました。 そこで「SREよもやま会」を実施してチームの方向性やマインドセットを議論し、GitHubのカンバンやロードマップでタスクと優先順位を可視化・管理する改善を行いました。 去年から新サービスが増加し続ける中で、SREチームだけで全ての工数や問い合わせを抱え込むことには限界が見えてきました。 そこで今後は、SREチームが全てを巻き取るのではなく、各部署内でSREの知識や運用方法を展開・定着させるEnabling(SRE社内留学制度)を推進する方針へとシフトしていきます。 具体的には、ドキュメントや動画を用いた学習、Sandbox環境での実践（SRE社内留学制度）などを通じて各部門の自律性を高め、組織全体としてスケールできるSRE体制への成長を目指しています。 去年のチームの振り返りについては次のTechBlogに記載されていますので、ぜひご覧ください。 tech.findy.co.jp Platform SREの軌跡：Terraform汎用化とAIで進めた「インフラ基盤」の構築と、その成果 speakerdeck.com 原からは、「Platform SREの軌跡：Terraform汎用化とAIで進めた「インフラ基盤」の構築と、その成果」と題して発表しました。 入社してから1年間で行った取り組みの中から、Terraform汎用モジュールとDevinを用いたAI活用でのトイル削減についてピックアップして紹介しました。 昨年ファインディがリリースした新サービスについて、品質を保ちつつスピード感を持ってインフラ環境構築を行う工夫を紹介しました。 SREチームが担当したサービスは次のとおりです。 Findy Conference Findy AI+ Findy Team+ AIチャットボット Findy ID Findy Insights アーキテクチャ壁打ちAI by Findy Tools 品質とスピードの両立を目指した「汎用モジュール」では、ファインディのプロダクトで頻繁に利用するリソースをモジュール化して、モジュールごとにパラメーターを指定すれば環境が立ち上がる仕組みを整備しています。 汎用モジュールを使ったインフラ環境構築は、今では開発者自身に担当してもらうこともあり、SREチームのEnabling活動の一環となっています。より構築しやすい汎用モジュールにアップデートし続けていきます。 詳しい内容は、次のTechBlogにも記載されています。 tech.findy.co.jp tech.findy.co.jp もう一つ、Devinを使ったAI活用によるトイル削減についての事例を複数紹介しました。 例えば、SREチームではコーポレートサイトの運用も担当しており、会社概要や利用規約の変更依頼が来ることがあります。以前はソースコードを直接編集していましたが、現在はこれらの作業をDevinに任せています。 Slackのワークフローから申請するとDevinが自動起動する仕組みを整備しました。事業部からの依頼をワークフロー経由で受け付けることで、SREチームはPRレビューのみに注力でき、工数削減を実現しました。 このように、汎用モジュールやAI活用でのトイル削減について紹介しました。 発表の最後では、ログ基盤の整備やAIOpsなど今後の取り組みについても触れました。これからも信頼性向上に向けたプラクティスを続けていきます。 フリーランスからSREへの転身 SREとしての第一歩：3週間の活動報告 speakerdeck.com SREチームの もずます(@mozumasu) です。 フリーのインフラエンジニアからSREへの転身を果たし、入社後3週間の活動報告をさせていただきました。 フリーランスから正社員になって変化したことや、お気に入りの自動化の仕組みなどを紹介しました。 まず現状の把握として、Findy ToolsのTerraform構成に触れました。現在は汎用モジュールがなく、environmentsとmoduleで管理しており、環境ごとのtfファイルでmoduleを呼び出す構成になっています。 運用を楽にするための自動化も進んでおり、次のようなツールが組み込まれています。 Renovate: 依存関係の自動アップデート tfcmt: PRに対してTerraform planの結果を自動コメント Trivy: 脆弱性スキャン この3週間で、主に2つの大きな取り組みを行いました。 SLO定点観測会の改善 SREチームと各プロダクトのエンジニアで、隔週で「SLO定点観測会」を実施しています。 これはDatadogやGrafanaを見ながらサービスの状態（SLO、ステータスコード、レスポンスタイム、APM、インフラリソースなど）を確認し、SLI/SLOの達成状況を把握する会です。 以前は、ダッシュボードの画像をGeminiで画像解析し、その結果をNotionに自動記載するという運用をしていました。 しかし、この運用には次の課題がありました。 画像から分かる情報が冗長に記載されてしまう 重要な情報が埋もれやすい 解析結果が誤っていることがある 議事録の準備に工数がかかる そこで手法を見直し、現在では「注視するべき部分（項目）のみを手動で記載する」というシンプルな形へと変更しました。 DatadogのダッシュボードをClaude Codeで作成 現状、SLO、Synthetic Testing、Slack通知などはTerraformで管理していますが、ダッシュボードのレイアウトなどはTerraformの管理外になっています。既存のダッシュボードをエクスポートすると約2000行のJSONになり、非常に可読性が悪いという印象を受けました。 そこで今回、Claude Codeを使ってこれを解析し、HCL（Terraform）化を試みてみました。 結果として、HCLにしても約1500行と行数自体はそこまで劇的に減りませんでしたが、HCLであれば変数の参照ができるようになるため、ダッシュボードをコード管理するならHCL化するメリットは十分にあると感じました。 入社からの3週間で、Datadogの設定やSLO定点観測会の改善など、SREとしての第一歩を踏み出すことができました。 今後はセキュリティ周りの改善などにも力を入れていく予定です。 BEから未経験でSREへ：オンボーディングとトイル改善の記録 speakerdeck.com SREチームの 富田 です。「BEから未経験でSREへ オンボーディングとトイル改善の記録」というタイトルで登壇予定でしたが、当日は諸事情により欠席となりました。 この記事では、発表予定だったスライドをもとに、SREとして未経験から立ち上がるまでの過程と、実際に取り組んだトイル改善の内容をお伝えします。 バックエンドエンジニア（BE）から未経験でSREへキャリアチェンジした背景と、入社してからの半年間で行った取り組みの中から、「SLO定点観測会」と「GitHub Actionsを用いたトイル削減」についてピックアップして紹介します。 BEとして働いていた時代、当時のCTOが自ら新サービスの環境構築やデプロイフロー改善を行う姿を目にしました。その経験から、アプリ開発にとどまらず開発環境そのものを整備し、エンジニアの開発生産性を支えたいと考えるようになりました。これがSREへ転向したきっかけです。 SREへ転向してから取り組んだこととして、1つ目は「SLO定点観測会」です。 SREチームの各担当と各プロダクトのエンジニアが隔週で集まり、DatadogやAmazon Managed Grafanaを見ながらアプリケーションの状態を確認する定点観測会を行っています。 この会でモデレータを務めることで、次のような学びを得ました。 対話しながらDatadogを確認することで身についた、実践的なダッシュボードの読み方 開発者の視点を聞きながら状況を判断することで得た、複数の角度からシステムを捉える力 「なぜこの数値になっているのか」を問い続けることで養われた、分析的な視点 地道な積み重ねですが、SREとして考える力の土台になっていると感じています。 2つ目は、ファインディのサービスの一つ「Findy Conference」の運用で発生していたトイルの削減事例です。 Findy Conferenceはセッション終了時などに瞬間的なトラフィックが集中するため、事前にコンテナ数の調整が必要でした。 以前は本番環境のAWSマネジメントコンソールにて手動で作業しており、ペアオペ必須で毎回約1〜2時間弱もの時間がかかっていました。 このトイルを削減するため、GitHub Actionsのworkflow_dispatchとAWS CLIを活用し、GitHubの画面上からフロントエンド・バックエンド両方のコンテナ数を変更できる仕組みを構築しました。 これにより、約2時間かかっていた作業が数分へと大幅に短縮されました。さらに、本番環境での手動介入がなくなったことでヒューマンエラーの心配が解消され、SRE以外のエンジニアでも安全にコンテナ調整が可能な状態を実現しました。 詳しい内容は次のTechBlogで紹介しています。ぜひご覧ください。 tech.findy.co.jp 以上が、登壇で伝える予定だった内容です。BEからSREへ転身し、できることから着実にトイル削減に挑戦した記録が、同じような境遇の方の参考になれば幸いです。 まとめ 以上、SREチーム主催のFindy Tech Talk「Findyのサービスを支える、横断SREチームのマネジメントと技術の挑戦」での登壇内容となります。 イベント当日は多くの方に参加いただき、賑やかな中開催することができました。参加いただいたみなさん、本当にありがとうございました！ いただいたアンケート結果より、またブラッシュアップしたFindy Tech Talkをお届けできればと思います。 次回イベント開催の際はぜひお越しください！ 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらからご覧ください。 herp.careers