👀概要

パーソルホールディングスデジタル開発部テクニカルアライアンス室の古田です。
この半年間、チームが抱える課題の解消プロセスをチームに定着させる活動をしてきたのでみなさまにご紹介します。
せっかくやるならということで、メンバーのマインド醸成や育成、チーム間コミュニケーション向上にもつながるような内容にしようと考えて取り組みました。

👨‍👩‍👧‍👦対象者(Who)

パーソルホールディングスの内製開発についてご興味がある方
チーム課題や技術的負債に向き合うチーム作りを進めたい方

📌関連リンク

TECH DOOR: エンジニアが自らつくる、エンジニアがはたらきやすい環境づくり―「Tech Harbor」プロジェクトとは？

🗒️目次

背景
構想
プロセス
ポイント
- スクラムとの類似点／相違点
- 工夫した点
成果
反省
まとめ

📝️内容

背景

私たちの内製開発組織は発足後からずっと拡大を続けています。
発足から3年経つ現在、今後も高品質なプロダクト開発に安定的に取り組むためには、累積したチーム課題や技術的負債に対し、そろそろ組織的に向き合っていく必要があると考えていました。
そんな折、デジタル開発部で「部内横断施策をやっていこう」との機運が高まり、それならばということで、チーム課題の解消に取り組んでいくことを提案しました。

また、私たちは「自走するチーム」を目指しています。
スピード感を持って変化に対応していくには、課題解消に積極的に向き合うマインドはもちろん、課題を見抜く力や、周囲を巻き込んで物事を推進していく力が必要です。
せっかく取り組むなら、チームメンバーがこういったスキルを身につけられる仕組みがいいと考えました。
さらに、部内横断なのでチーム間のコミュニケーションもより深められればと考えました。

構想

私は普段SREとしてプロダクト開発に携わっていますが、チームマネジメントの経験とスクラムの知識（資格）が少しあります。
チーム課題をバックログやインペディメントリストのように管理して、それをスクラムのロールやイベントっぽく取り組んでみたらどうだろう？とアイデアを思い浮かべ、やりたいと考えたことが実現できそうかどうか、仕組みの構想を練っていきました。

プロセス

そして作り上げたのが、チーム課題を下図のようにチケット管理する仕組みです。

チケットのステータス遷移は、大まかに言うと「作成→優先順位付け→処理→完了」です。
起票は誰でも可能で、内容確認が必要な場合は議論を経て、どの優先順位で処理するかを決めます。
参加したいメンバーが挙手し「作業ペア」を組み、チケットの受け入れ基準を満たすように作業を進め、受け入れ確認OKとなれば完了です。

基本構造としてはよくあるバックログ管理で、ごく普通のフローかなと思います。

ポイント

構想する中で、スクラムに似せたり寄せたりした方がいい部分、スクラムとは変えた方がいい部分をそれぞれ考えました。
加えて今回工夫した部分についてもご紹介します。

スクラムとの類似点

ロール

スクラムに登場するロールと似た役割で定義しています。

スクラムのロール	本プロセスのロール	役割
PO	課題オーナー	・チケットを効果的に管理する・チケットの優先順位を決める
SM	運営	・プロセスを円滑に進行する・プロセスを改善する
Dev	メンバー	・チケットを消化する

会議体・イベント

スクラムイベント※ と似た会議体・イベントを設計しています。
（※ バックログリファインメントを含む）

スクラムイベント	本プロセスの会議体・イベント	内容
バックログリファインメント	チケット確認回	・チケットの内容を議論する・チケットの優先順位を検討する
スプリントプランニング	プランニング回	・作業ペアを決める・取り組むチケットを選択する
スプリントレビュー	レビュー回	・取り組んだチケットを紹介する
スプリントレトロスペクティブ	ふりかえりアンケート	・作業ペアが取り組み方や　プロセスをふりかえる

また、スクラムがスプリントを繰り返すように、本プロセスが一定のリズムで反復継続するように会議設計をしています。

週1時間の会議枠を設定
1か月（＝4週）で1サイクル
会議枠の使い方
- 第1週～第3週：チケット確認回
- 第4週：レビュー回＋（次サイクル向けの）プランニング回

スクラムとの相違点

受け入れ基準

受け入れ基準を誰が・どのタイミングで書くかはスクラムで明確に決まっていませんが、POが中心となって、チケットへ取り組む前に書くことが多いように思っています。
今回のプロセスではそうせずに、作業ペアがチケット選択後に受け入れ基準を書き、それを課題オーナーと合意する形にしました。
これは、どこまで何をやるかを自分たちの裁量で決定することをチームメンバーに意識してもらい、自走する力を高めたかったからです。

スプリントゴール

スクラムではゴールを設定し、確約（Commitment）と集中（Focus）でゴール達成を目指す、とされています。
今回のプロセスでも同様のスタンスで進めたかったところですが、チームメンバーにはこのプロセスよりも開発業務や組織のタスクに優先して取り組んでもらう必要があったため、スクラムで求めるレベルの価値基準の実現が難しいと判断し、スプリントゴールのような目標は設定しませんでした。

工夫した点

チケット種別

課題を見抜く力を養うために「仮説」を設けたところが工夫点です。
「業務課題」は、要望があり後から追加しました。

チケット種別	内容	取り組み方
技術課題	問題点・困りごとが実際に発生しているもの・プロダクトの技術的負債・開発作業上のトイル	課題を解消する
技術課題（仮説）	問題点・困りごとがまだ発生していないもの・問題が潜んでいる予感がする・よい方法を知らないことが問題かもしれない	問題の有無を確認する
業務課題	技術的な要素はないが、日々の業務において問題点・困りごとが実際に発生しているもの	課題を解消する

作業ペア

私たちは3つの開発チーム（横断チームを除く）で活動しています。
チーム間のコミュニケーション向上を図るべく、以下の目的や狙いを考えて、チケットは「別チームメンバー同士が」「2人で」取り組むルールにしました。

組合せ
- 同じチームのメンバーは普段から密に接している
- 新鮮なコミュニケーションを取る機会を創出したい
人数
- 1人でチケットに取り組むのは、単純に楽しくないだろう
- 3人以上でチケットに取り組むのも狙いから外れる
  - 自分から意見を発信する機会や、相手個人を見つめる機会が減ってしまいそう
  - 多数対少数で分かれたときに困りそう
    - 合意形成のリーディングやファシリテートで時間がかかりそう
    - 少数にならないよう、意見を控える傾向が出そう

成果

プロセスを半年間（＝6サイクル）続け、21件の課題を解決しました（2026年3月時点）。
それ以外にもたくさんの成果を得ることができたと考えています。

このプロセスの存在がチームにとって当たり前になった

以前は問題点や困りごとに気づいても、それを個々のチームメンバーが書き溜めて、赴くままに取り組む程度の運用しかできていませんでしたが、今では問題点や困りごとを見つけたら「このプロセスに乗せて解消しよう」と考えるようになり、自然にチケットが起票されるようになりました。

チームが課題へ向き合うコツを得た

反復継続するプロセスを通じて、チケットの取り扱い方、つまり課題への向き合い方が上手くなったと感じています。
チケットを分割する／別のチケットで起票し直す／受け入れ基準を見直すといった行動から、課題をどのような切り口で解消まで持っていくかを学ぶことができました。

プロセスの価値に賛同・理解してもらえた

うれしいことに、プロセスが目指すチームの理想や将来像に賛同してくれた既存メンバーや、価値を高めるために自律的に行動している姿に感動した新規参画メンバーが、チケット管理やプロセス運営に熱心に参加してくれるようになりました。
仕組みを考えた立場としては、頑張ってよかったなぁ…としみじみ感じています。

反省

一方で、うまくいかなかった部分や、もっと改善できる部分も見えてきています。

チケット選択の裁量が小さい

当初、チケットはプロダクトバックログのように「優先順位」で並べ、上から順に選択する方法にしていました。
ところがこの方法は、作業ペアが前向きに取り組みたいと思うチケットを選択できないケースがあり、それがプロセス参加の障壁になっている可能性がありました。
この点は、チケットを「優先度」で並べ、優先度高のチケットから選択してもらう方法に変更し、改善を図っています。

挙手制の参加スタイル

スプリントゴールの箇所で説明した通り、チームメンバーは他に優先して取り組む作業があるため、参加は挙手制ということで整理しました。
しかし、メンバーの開発業務が繁忙になったり組織のタスクが増えてくると、どうしてもこのプロセスに参加するモチベーションが下がってしまい、なかなか参加者を募るのが難しい状態に陥ってしまいました。
参加のメリットをもっと大きなものにすること、例えば参加によって成長できることをより深く伝えたり、部内におけるこの活動の位置づけを見直してもらうよう働きかけるなどが、必要な対策になってくるかもしれません。

まとめ

エンジニアの活動において、チーム課題や技術的負債にどう向き合って解消していくかは、組織やチームそれぞれで考え方・進め方が違うものだと思っています。
今回紹介した内容が、みなさまの活動の参考になれば幸いです。