はじめに こんにちは。リテールハブ開発部小売アプリチームの池です。 エンジニアチームのマネージャーになってから、気づけば1年半が経ちました。 この1年半を振り返ると、悩みながら行動を続けてきた時間でした。マネージャーとしてどう行動すべきか日々悩みながら試行錯誤し、周りの支援を借りつつ、自分なりにこれだと思うことを試しては失敗を重ね、走り続けてきました。その中で意識していたのは、ただ失敗を繰り返すだけではなく、そこから得られる学びを積み重ねて次に活かすことです。 この記事では、マネージャーが日々何を考え、どんな判断をしているのかを共有したいと思います。また、失敗談が中心にはなりますが、同時にマネージャーという仕事は「人やチームと向き合う仕事」であり、多くの魅力とやりがいがあることも伝えられたらと思っています。マネージャーに興味があるエンジニアの方、同じ立場で悩んでいるマネージャーの方、あるいはマネージャーが何を考えているか知りたいチームメンバーの方にとって、少しでも参考になれば幸いです。 今回は、自身の振り返りも兼ねて、その中でも特に強く心に残っているマネージャーとしての意思決定に関する学びをピックアップして振り返ります。 背景 私がマネージャーになった当時のチーム状況を説明します。 1年半前の当時、私のチームでは以下の業務を並行して進めていました。 自社でゼロから新規開発している小売アプリの開発 事業譲渡で引き継いだ5つの小売アプリの運用保守 エンジニアは私を含めて3名、デザイナー1名、PdM1名の計5名を中心に、上長の支援を得ながらそれらの業務をこなす必要がありました。 引き継いだアプリそれぞれの全容は十分に把握できておらず、わからないことだらけです。コードから仕組みを読み解きながら運用保守、顧客からの問い合わせ・要望に対応する日々でした。チームも発足して間もなく体制が整っておらず、PdMも入れ替わりで着任したばかり。そこに新規開発も並行して進めていて、カオスな状態でした。 そんな中で、私は初めてマネージャーを担うことになりました。 失敗①：チームの方針を明確に示さなかった 一つ目の失敗は、マネージャーとして方針を明確に示すことの重要性と、それがチームに与える影響の大きさを理解していなかったことです。 その当時、少ない人数のチームで新規開発と既存運用が同時に走り、毎日やることが尽きません。私自身もプレイヤーとして動かないと回りませんでした。「まずは足元の開発を回すこと」が最優先で、開発や調整、障害対応と、自身も一人のプレイヤーとして目の前のタスクを一つずつ処理し、なんとか回すことに必死でした。 一方で、私はマネージャーになったばかりです。方針を示すことの大事さを理解していませんでした。どこを目指すのか、何を優先するのか。そういったことを言語化するという発想自体が薄かったのだと思います。 そして、方針を明確に示さずに全てをうまく回そうという意識のまま、大きな対策を打たずに走り続けていました。その結果、チームはどこに向かっていいかわからない状態になっていきました。 重要でないことに時間を使ってしまう 自律的な判断が難しくなる 方針がないと、迷いながら働くことになります。技術負債をどこまで許容するのか、属人化をどこまで受け入れるのか、ドメイン理解にどれだけ時間をかけるのか、作り込みすぎないラインはどこか、各々の判断のズレが積み重なりチームはさらに忙しくなっていきました。 結果的に「全部をそのままやる」ということが暗黙の方針となり、当然ながら、すべてが中途半端になり目標達成も遠のきます。メンバーの不満も溜まり、私自身も時間で解決しようと夜遅くまで働くことが増えました。疲弊するばかりで状況は良くなりません。 方針が全てを解決するわけではないですが、方針を示さなかったからこそ、余計な忙しさを生んでいたのだと思います。 学び 忙しくても、方針を示すことだけは省いてはいけません。 何を最優先にするのか 何を後回しにするのか どこまでやれば十分か このような方針があるだけで、チームは「何に時間を使うべきか」を考えられるようになります。 今は、「やること／やらないこと」を明確にすることを意識し、忙しい時ほど立ち止まるようにしています。 失敗②：チームを見ずに手法を当てはめた 2つ目の失敗は、解決策から入ってしまったことです。 マネージャーに役割が変わると求められるスキルは変わり、人やチームを動かすスキルが必要になります。しかし当時の私は、その変化を十分に受け止めきれていませんでした。マネージャーとしての理解も引き出しもなく、何をすればいいのかわからない。そんな状態です。 わからないなら学ぶしかないと思い、本や記事を読み、過去の自身の成功体験や他社の成功事例に答えを求め、「これが正解だろう」と思ったものをチームに適用しました。 その一つがスクラム開発の導入です。自分の過去の経験からスクラムをやることでチームが良い方向に進むと、どこかで信じていました。マネジメントに自信が持てない中で、実績のある手法を頼ろうとしていたのだと思います。 スクラム自体は良い手法ですが、そのときのチームのフェーズや状況には合っていませんでした。本来私がやるべきだったのはプロセス改善ではなく、チームの課題を見つけてどう解決するかを考えることです。 スクラムをうまく運用できなかったことにも問題はありますが、チームの課題を見ずに形式的に導入しても効果は限定的になります。その結果、重要ではない会議や作業、議論が増えていきました。 たまたまチームの問題とスクラムの手法がマッチしていた箇所では効果が出たものの、全体としては納得感も高まらず、次第に形骸化して空回りしていき、最終的にはスクラムをやめる判断をしました。 失敗の原因は手法そのものではなく、チームを見ていなかったことでした。 学び まずやるべきことは、手法を探すことではなく、チームの状態を観察して明らかにすることでした。 何が一番のボトルネックなのか どこにエネルギーを割くべきなのか メンバーは何に困っているのか それらを言語化した上で解決策を考えるべきでした。 チームはそれぞれ、プロダクトのフェーズや事業状況も、メンバーの性格・スキルも異なります。当然、課題やボトルネックもチームごとに違います。同じ状況のチームは存在しません。だからこそ、マネジメントにどのチームにも当てはまる画一的な手法はありません。 特に、ベンチャー企業の新規事業で限られたリソースと期間で目標を達成する必要がある環境を踏まえると、何を優先し何を捨てるかの判断は大きく変わってきます。そのためにも、まずはチームを観察し、置かれた状況を把握した上で、行動を考える必要がありました。 一方で、考え過ぎて動けなくなるのもまた問題です。すべてを理解してから動くことはできません。実際には、軽く試し、軽く失敗し、そこから学ぶことも多くあります。行動してみて初めて見えてくる課題もあれば、後から納得感がついてくるケースもあります。 今は、観察しながら動き、チームの反応を見て調整することを意識しています。 失敗③：一度決めた方針を続け過ぎてしまった 3つ目の失敗は方針を見直さなかったことです。 失敗①②を経て、私はチームの状況を見て方針や行動の意思決定を意識するようになりました。 たとえば、初期フェーズで作るものがある程度決まっている状況では、ドメイン理解を一定に留めることや属人化を許容するという判断をしました。その時点では合理的な判断だったと思います。 しかし問題は、その方針を見直すべきタイミングで見直さなかったことでした。 プロダクトの状況は変化し、チームの構成も変わり、メンバーも成長しているのにもかかわらず、その判断だけが更新されないままになっていました。 その結果、以下のような影響が徐々に現れてきました。 技術的な判断の拠り所が持てない場面が増えていく 「自分たちが作っているものは本当に価値があるのか」という空気がチームに漂い始める 属人化が固定して急な休みが取りづらくなる アラート対応の担当者が偏る 変化の兆しには気づいていましたが、対策を打てていない自分もいました。方針を決めた後の運用ができていなかったのです。 学び 方針にもメンテナンスが必要です。定期的に見直さないと現実との乖離が大きくなっていきます。 チームが不健全な状態になっていないか チームの熱量や納得感は下がっていないか このような、出ていたはずのシグナルをしっかりと見逃さず、短いサイクルで方針が実状に合っているかを問い続ける必要があります。 方針は一度決めて終わりではなく、状況の変化に合わせて更新し続けるものだと学びました。 おわりに 本記事では、マネージャーとしての意思決定に関する3つの失敗を振り返ってみました。実際にはもっと多くの失敗をしています。 大事なことは、失敗しないことではないと思っています。 マネージャーの仕事に正解はないと、この1年半で実感しました。完璧な判断を下し続けることはできません。それでも、打席に立ち続けることはできます。迷いながらでも決める。うまくいかなければ振り返って次に活かす。その繰り返しで前に進めると思っています。 一方で、失敗ばかりを書いてきましたが、マネージャーの仕事にはそれ以上のやりがいがあると感じています。一人では到底成し遂げられないことをチームで実現できたときの達成感。エンジニアとは異なる視点やスキルが求められる中で、自分自身が成長していく実感。そして何より、メンバーの成長や変化に向き合いながら、チームが前に進んでいく過程を間近で見られることの面白さ。マネージャーの醍醐味だと思っています。 まだまだ未熟ですが、これからも打席に立ち続け、学び続けていければと思います。

はじめに こんにちは、2025年12月入社の齋藤です！ 本記事では、2025年11月・12月に入社したメンバー8名に入社直後の感想をお伺いし、まとめました。 KINTOテクノロジーズ（以下、KTC）に興味のある方、そして、今回参加してくださったメンバーへの振り返りとして有益なコンテンツになればいいなと思います！ 齋藤 諒太  自己紹介 KINTO開発部でフロントエンドエンジニアとして働いています。新潟県出身で今は大阪市在住です。 業務としては主にKINTOのシミュレーションや申し込み、マイページの開発を行っています。 前職ではRailsやNext.jsで構成された比較メディアサイトの開発をフロントエンド・バックエンドの領域を問わず担当していました。 趣味は自作PC、ゲーセン、ペットの猫をこねることです。よろしくお願いします。 所属チームの体制は？ Osaka Tech Labに3人、室町オフィスに6人の合計9人のチームです。 1週間単位のスプリントで開発を進めています。毎週のプランニングでタスクを決め、レトロスペクティブで成果と課題を振り返ります。 毎日デイリースクラムで進捗を共有し、互いの状況を把握することで効率的な開発体制を維持し、短いサイクルで改善を重ねています。 チームの雰囲気はどんな感じ？ 拠点や勤務形態が多様でオンライン中心ですが、不明点があればすぐに質問でき、相談もチーム内外で活発に行われています。 課題や改善案があればADRを通じて提案できます。ADRはアーキテクチャに限らず、チームのルールや方針を幅広く決めるための仕組みとして活用しており、誰でもカジュアルに新しいアイデアを発信し、継続的な改善を進められる環境です。 KTCへ入社したときの入社動機や入社前後のギャップは？ これまで培った技術や知識を活かせる環境で働きたいと考え、以前から関心を持っていたKINTOのサブスクリプションサービスに、ユーザーとしてだけでなく開発者としても携わりたいと思い入社しました。 入社後、大きなギャップはありませんが、Osaka Tech Labは思っていたよりもまだ人数が少なく、落ち着いた雰囲気だった点はギャップかもしれません。 オフィスで気に入っているところ JCTと駅直結の利便性です。外部イベントも開催され、気軽に参加できるうえ、雨でも濡れずに出社できます。 フクロウさん ⇒　齋藤 諒太さんへの質問 おすすめのアプリやサービスありますか？ 10年以上1Passwordを使っています。覚えておくのは1Passwordのマスターパスワードだけで済み、強力なパスワードを自動生成して保存・同期してくれるのでとても楽です。さらにクレジットカード情報の管理機能や、パスワードの使い回し・漏えいを自動検出して通知するセキュリティ監査機能も備わっています。Windows、Mac、iOS、Androidに加え、ブラウザ拡張機能にも対応しており、ほぼすべての環境で使える点も魅力です。 うえぽん  自己紹介 デジタル戦略部DataOpsG所属となります！ 前職はSESエンジニアとして多様な業種、システムにかかわってきました。 趣味は釣りで最近は月に1回程度しか行けていないので食卓と話題のネタを仕入れに行かなければ。という意気込みです！ よろしくお願いします。 所属チームの体制は？ チーム内でもデータの蓄積を行う基盤チーム、蓄積したデータを提供する仕組みを扱うnicolaチームという構成になっていて、全体で9名の体制です。 チームの雰囲気はどんな感じ？ それぞれの強みを生かして日々業務や技術・知識習得に取り組んでいます。 共有の場では積極的に深掘りをしてチームとしての向上心が高いと感じています！ KTCへ入社したときの入社動機や入社前後のギャップは？ 特定の分野で技術を磨き自身の強みとしたい！ フルスタックエンジニアとしての経験を活かせる！ 入社前に丁寧な説明をしていただけて、業務環境についてギャップはなかったです。 オフィスで気に入っているところ 名古屋オフィスは駅の地下街から直結されているため悪天候の影響を受けずに出社できます！ 齋藤 諒太さん ⇒　うえぽんさんへの質問 これまで多くの現場を経験されたとのことですが、特に印象に残っている現場はありますか？ 銀行関係の現場なこともありセキュリティー意識がとても高かったです。（検証環境エリア、本番環境エリア共に作業者・作業理由・作業時間の事前申請必須など） また、利用者がいない時間に更新するため、深夜当番と早朝当番を月1でやっていました。 debugon  自己紹介 Engineering Officeでアクセシビリティを社内文化にする仕事をしている辻です。KTCには辻さんが何人かいらっしゃるので、私のことは debugon と覚えてください。 AIで音楽を作るのが趣味です。 所属チームの体制は？ それぞれの専門領域を持つメンバーが、東京、名古屋、福岡で活動するチームです。 専門的な知識を生かしつつ、他のメンバーの専門性との化学反応を生かし、社内の様々なチームの力を最大限に発揮できるように共創しています。 チームの雰囲気はどんな感じ？ 複数拠点で活動するチームなので、オンラインやオフラインでコミュニケーションをしっかりとっています。 「食べ物」の話しが好きなメンバーが多いので、食べる話になるとSlackチャンネルが盛り上がります。 KTCへ入社したときの入社動機や入社前後のギャップは？ モビリティカンパニーに文化としてアクセシビリティの考え方を広めたくて入社しました。 「一緒に良いものを作っていきたい」という考えの方がたくさんいらっしゃるので、とてもやりがいを感じています。 オフィスで気に入っているところ トヨタ車の模型がたくさん置いてあって、それぞれの形を手で触って確認できたことがうれしかったです。 うえぽんさん ⇒　debugonさんへの質問 AIで音楽作成されるとのことですが、どんなジャンルの音楽が好きですか？制作に使うお気に入りのツールやソフトあれば教えてください！ 音楽を作るときには Suno を使っています。ジャズが好きなのですが、気分のままにこれまでに聞いたいろいろなジャンルの音楽を思い出しながら作っています。 なかぴー  自己紹介 障害者雇用枠で2025年12月に入社しました。在宅勤務です。 経歴としましてはSIerのエンジニアからキャリアをスタートして、事業会社の社内SE、PM、ITコンサルタントの経験があります。 伴走型のPMで、「餅は餅屋」をモットーに駆けずり回るスタイルでフットワークには定評がありました。 約1年半前に脳出血で左半身麻痺になりました。完全在宅の時短勤務で働けることが有難いです。 所属チームの体制は？ 開発支援部人事グループの中の労務総務チームです。チームは自分を含めて4名です。 チームの雰囲気はどんな感じ？ 定例会では休日の様子も共有し合って和やかな雰囲気です。 KTCへ入社したときの入社動機や入社前後のギャップは？ 入社動機：経験を活かしてエンジニアの方のサポートが出来そうだと感じたから。 入社前後のギャップ：1on1が多い。激務な職場が多かったのですが、今は業務量を調整してもらえて有難いです。 オフィスで気に入っているところ 室町オフィスがあるコレド室町はお洒落な商業ビルで駅直結なのでリハビリを頑張って出社したいです。 debugonさん ⇒　なかぴーさんへの質問 お気に入りのデスクアイテムや文房具は？ とにかく忘れないように、付箋を頻繁に使っています。シンプルなものが一番使いやすいです。 miurat  自己紹介 デジタル戦略部DataOpsGにデータエンジニアとしてジョインしました。 前職では、事業会社でデータ基盤構築やデジタルマーケティング関連の仕事に従事してきました。 趣味は、テニス、ゴルフでボールを打つことが好きです！ 所属チームの体制は？ メンバーは東京・名古屋・大阪の3拠点あわせて計9名です！ チームの雰囲気はどんな感じ？ チーム全体の雰囲気は風通しが良く、相談や雑談もしやすい雰囲気です。 また、好奇心旺盛なメンバーが多く、最新のトレンドや業界ニュースなどを積極的に共有し合う文化が根付いています。 KTCへ入社したときの入社動機や入社前後のギャップは？ ビジョン・バリューに共感したからです！ 入社後のギャップは、ドキュメントが整っているなと思いました！ オフィスで気に入っているところ 大阪オフィスは、高層階の為、景色が綺麗です。また、駅直結なので、通勤が便利です！ なかぴーさん ⇒　miuratさんへの質問 データ分析で心がけていることは何ですか？ 誰もがストレスなく使えるよう、複雑さを取り除いたシンプルな設計と、データの品質維持を心がけています。 でこぽん  自己紹介 Cloud Infrastructure G にエンジニアとしてジョインしました。 前職では AWS 専業のエンジニアとしてシステム開発やお客様の内製化支援などを行っていました。 趣味はテニスや登山で、主に神奈川の山を登ってます！ 所属チームの体制は？ 10名程度の組織で、サービスを支えるインフラチーム、中長期的な課題への改善を繰り返すカイゼンチーム、そしてトヨタグループの CCoE を支えるソリューションチームがあり、私はソリューションチームに所属しています。 チームの雰囲気はどんな感じ？ 和気あいあいな雰囲気です。 お昼は出社しているメンバーのほとんど全員で外に出て神保町のいろいろな美味しいお店を開拓しています。 二郎系ラーメンを食べる人が多くいます。 KTCへ入社したときの入社動機や入社前後のギャップは？ ビジョンに対してチームで前向きに進んでいけそうな雰囲気に魅力を感じました。 入社後のギャップも特になく、自由な雰囲気で成果を出していくことができると思います。 オフィスで気に入っているところ 神保町オフィスに在籍しているのですが、周りに美味しいお店が無限にあります！ miuratさん ⇒　でこぽんさんへの質問 ストレス発散方法を教えてください！ 同僚や友人とお酒を飲みに行くことです🍻 Yanaggy  自己紹介 プロダクトマネージャーとして入社しました。 TOYOTA UPGRADE FACTORY/LEXUS UPGRADE FACTORYというクルマの「アップグレード」をWebで申し込めるサービスを担当しています。 漫画から小説までいろんな本を読むのが好きです。 所属チームの体制は？ チームはFE/BEエンジニア、SRE、QA、ディレクター、PDMなど約10名からなり、東京、大阪にまたがっています。 PDMは東京1名、大阪1名の2名体制です。毎朝オンラインで話して案件状況や課題をシェアしながら案件を進めています。 チームの雰囲気はどんな感じ？ 拠点は離れていますが、Slackの非同期コミュニケーション、オンラインでのデイリーMTG、ちょっとした相談など同期コミュニケーションを使い分けながら仕事を進めています。 KTCへ入社したときの入社動機や入社前後のギャップは？ これまでは金融やデジタルコンテンツのシステム開発をしており、次は実物のあるモノに関わる業界で仕事したかったのと、小寺さんがインタビューで語っていた「最初のクルマ、最後のクルマ」のコンセプトにひかれたからです。 良いギャップとしては職務・職種の経歴、年齢層など思ってたより様々な背景を持ったメンバと仕事できるのが刺激的です。 オフィスで気に入っているところ 大阪オフィスの机が広い。あとJCTと呼ばれているイベントを行える広いスペース。社内外の様々なイベントが開催されています。 でこぽんさん ⇒　Yanaggyさんへの質問 Osaka Tech Lab 周辺で一番お気に入りのランチもしくは居酒屋があれば教えてください！ 九州ラーメン亀王。高校生の時から通っているラーメン店です。オフィスから少し離れていますがよく行きます。 フクロウ  自己紹介 開発支援部人事G採用チームに配属。 これまで在宅でバックオフィス業務に加え、デザインや動画制作などのクリエイティブ業務も経験してきました。 昨年まで療養期間がありましたが、体力づくりを経て、最近は本格的に筋トレに取り組もうと考えています。 所属チームの体制は？ 開発支援部人事G採用チーム（7名）に所属しています。 採用計画に沿って、募集・面接・進捗共有などを進めながら、より良い採用に向けて日々改善しています。 チームの雰囲気はどんな感じ？ オンラインでのMTG参加はまだ多くありませんが、問題点の共有や改善に積極的に取り組む姿勢がうかがえます。 笑い声も絶えない和やかな雰囲気もあります。 KTCへ入社したときの入社動機や入社前後のギャップは？ 障害者雇用という立場ではありますが、面接時、他社に比べて良い意味で特別扱いされすぎず、他のメンバーと同じように見てもらえている点にとても好感。 入社後も必要な配慮は十分過ぎるほどありつつ、想像していたようなギャップは特に感じていません。 オフィスで気に入っているところ 完全在宅のためオフィス出社の機会はありませんが、社内外の様々なイベントに参加してみたいなと思っています。 Yanaggyさん ⇒　フクロウさんへの質問 体力・健康維持のためにやっていることはありますか？ 基本的な体調管理はもちろん、障害の特性的に、体温と気温、食事の温度などは常に気にしています。 さいごに みなさま、入社後の感想を教えてくださり、ありがとうございました！ KINTOテクノロジーズでは日々、新たなメンバーが増えています！ 今後もいろんな部署のいろんな方々の入社エントリが増えていきますので、楽しみにしていただけましたら幸いです。 そして、KINTOテクノロジーズでは、まだまださまざまな部署・職種で一緒に働ける仲間を募集しています！ 詳しくは こちら からご確認ください！

はじめに こんにちは、新規事業部フロントエンドブロックの 池田 です。普段は 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 ↩