※この記事は、2026年1月に開催されたイベントでの発表内容をレポートしたものです。
登壇者はこの方
遠藤瑞希
パーソルキャリア株式会社
エンジニア
2022年5月PCA入社、新卒で中小SES会社に就職。PCAは2社目。 Windows業務アプリケーションを中心に、基幹システムや販管システムのリニューアルや機能追加を行ってきました。PCAではdoda CONNECT継続開発（事業連携チーム）にアサインされ、現在はエンジニアリーダーとしてチームを牽引しています。アジャイル開発は今のチームが初経験でした。
遠藤：本日は、「長期スクラム〜変わるメンバー、進化し続けるチーム、受け継がれる意思〜」というタイトルで、チーム紹介から始まり、現在抱えている課題、それに対する解決の取り組み、そしてこれからチームがどのように続いていくのかという順番でお話しさせていただきます。
チーム紹介
Connect継続開発チーム
私たちのチームは「Connect継続開発チーム」という名称で活動しています。メンバー構成は、ディレクター5名、エンジニア8名（OJT中の新卒を含む）、デザイナー1名の総勢14名です。
担当プロダクトは「doda CONNECT（デューダコネクト）」というサービスです。これは、転職支援サービス「doda」をご契約いただいた企業様に無償提供している採用管理システム（ATS）です。
チーム自体は2020年頃に発足し、約5年が経過しています。プロダクト自体はさらに前から存在しますが、継続開発チームとしてはこの5年で形作られました。去年の9月には初期メンバーが全員卒業し、現在は「バージョン2」とも言える新しいチームへの転換期を迎えています。
スプリントイベント
現在は2週間を1スプリントとして回しています。以前は火曜日に丸1日かけてスクラムイベントを行っていましたが、時短勤務のメンバーが増え、16時までに終わらないという課題がありました。
そのため現在は、スプリントレビューのみ月曜日にオンラインで実施し、火曜日はなるべく出社して、対面で「振り返り」や「プランニング」を行う形にしています。
また、火曜日の午後には「フリータイム」を設けています。ここではチームビルディングを中心に、月次の振り返りや勉強会、さらには初詣やクリスマス会といった季節のイベントも行い、ワイワイと楽しむ時間を大切にしています。
使用ツール
タスク管理にはJira、ドキュメント管理にはConfluence、コミュニケーションにはTeamsを使用しており、これらがスクラムの根幹を支えています。
振り返りフォーマット
振り返り（レトロスペクティブ）では、「ヨット」のフォーマットを使用しています。私たちのチームでは、スクラムとしては少し珍しいかもしれませんが、複数の案件を同時進行しているため、案件ごとにゴールを定めて進めています。
振り返りの冒頭には必ず、メンバーへの感謝の気持ちを共有する時間を設けています。スタンプをたくさん使い、明るい気持ちで議論ができる雰囲気作りを心がけています。議論の内容は、ヨットの「追い風（良かった点）」と「碇（課題点）」をメインに書き出し、メンバー投票で票が集まったものを中心に深掘りして、ネクストアクションを決定しています。
課題
私たちが直面している課題は、大きく「プロダクト起因」と「メンバー起因」の2点があります。
プロダクト起因の課題
担当している「doda CONNECT」は、10年以上前に作られた非常にレガシーなシステムです。都度改修は行われているものの、誰も知らない仕様があったり、ドキュメントが存在しなかったり、構造が複雑だったりします。
さらに社内の他システムとの連携が根深く、一つの案件をこなすにも事前の徹底的な調査が欠かせません。「品質担保のための多大な工数」と「スクラムとしての迅速な価値提供」をどう両立させるか、常に試行錯誤しています。
メンバーによる課題
現在のチームは、内製メンバーがエンジニアリーダーとして1名、その他の主なメンバーはパートナー会社の方々が多いという構成です。パートナーメンバーは定期的に入れ替わりが発生するため、ナレッジが蓄積しにくく、スキルセットやコミュニケーションがリセットされてしまうという課題があります。
このプロダクトの難しさとメンバーの流動性のなかで、いかにスクラムを回し続けるかが大きな壁となっています。
今までの取り組み
これまでお話ししたプロダクトやメンバーの課題に対し、私たちが具体的に取り組んできたことを3つご紹介します。前提として、毎スプリントの振り返り（ヨット）で出た課題には都度アクションを設定していますが、ここでは長期的な視点で行った大きめのテコ入れをピックアップします。
デザインドックの導入
先程お話した通り、プロダクトが難解であるため、あらかじめ調査をしっかり行う必要があります。本来、スクラムであれば設計フェーズを挟まずに実装から始めたいところですが、以前そのように進めてみたところ、実装やテスト（UT）の段階でレビューの手戻りが多発したり、うまく動かなかったりと、メンバーへの負担が非常に大きくなってしまいました。
以前はExcelで設計を管理しており、ファイルサーバーから過去の類似案件を探すのが大変だったり、ナレッジの発掘に苦労したりしていました。
そこで、調査と設計を適切に行うために「デザインドック」を導入しました。デザインドックとは、詳細設計ほど細かくはありませんが、「なぜその実装方針にしたのか」という根拠に重点を置いたライトな設計書だと捉えています。
現在はConfluence上にテンプレートを用意して作成しているため、後からの検索効率が大幅に向上しました。これにより、調査タスクの成果がチームの資産として蓄積されるようになっています。
チームビルディング
メンバーが入れ替わっても、チームの軸がブレたりコミュニケーションがリセットされたりしないよう、さまざまな取り組みを行っています。出社日のフリータイムや半期に一度の1日合宿を活用しています。
- アイスブレイク系： マシュマロタワーを作ったり、紙飛行機を用いてスクラムの体験・理解を深めるワークショップを行ったりしています。
- お手紙交換会： 日頃言葉にできない期待や感謝を、職種に関係なく全メンバーが手書きでお手紙に書いて交換する会を実施しました。
- 顧客視点の養成： 「自分たちが顧客になって改善案を練る」プロジェクトを行っています。例えば、カフェ・ベローチェの社員になりきって競合店舗と比較調査し、改善策を考えるワークショップや、他社ユーザーへのインタビューに基づいた改善案作成など、エンジニアもディレクターも全員参加で実施しています。
ここで大事にしているのは「お互いを知る」「信頼とリスペクト」「顧客目線を養う」の3点です。これらを定期的に行うことで、メンバーが変わってもチームの雰囲気や軸が維持される環境を整えています。
魔改造スクラム
スクラムの原型は意識しつつも、型に縛られて息苦しくなっては本末転倒です。自分たちの現状に合わせた最適化を常に探求しています。
- 設計フェーズの導入： 手戻り防止のため、スクラムとしては珍しいかもしれませんが、一律で設計期間を設けています。
- プランニングの2段階化： 「企画をフィックスさせる場」と「実際に着手するためのポイント見積もり（スプリントプランニング）を行う場」の2回に分けて実施しています。
- PO役割の分散： 専任のスクラムマスターは置かず、開発リーダーがその役割を担ったり、プロダクトオーナーの役割を分散させたりしています。
今のメンバーで、今のプロダクトをより良くするために一番やりやすい形を最優先し、振り返りを通じて良いと判断すれば迷わず改善し続ける。この姿勢を大切にしています。
チームの未来
軸はブレさせずに進化し続ける
最後に、私たちのチームの未来についてです。
プロダクトとして「顧客目線を第一に」すること、スクラムとして「価値提供を早く」すること、そして何より「自分たちがこのプロダクトとチームを愛している」こと。これだけは、メンバーや組織、AIなどの時代が変わっても、絶対にブレずに受け継いでいきたいと考えています。
その時々に最適化されたスクラムチームで、価値提供をし続けられていると思っています。これからも強いチームであり続けられるよう、この軸を信じて歩んでいきます。
パーソルキャリアのエンジニアリング組織における「技術」や「人」、「組織」については技術ブログ「techtekt（テックテクト）」の方でも発信しています。また、私たちの組織に興味をお持ちいただいた方は、採用サイトもあわせてご覧ください。
▼▼ ぜひ他登壇者の発表レポートもご覧ください！
