品質を支える仕組みをチームで作る —— 開発プロセスの可視化と改善

記事の概要

SmartHRのQAエンジニア（QAE）による記事。プロダクト基盤ユニット・権限基盤チームで、体制変更により複数開発を並行で進めることになった結果、それまで暗黙に成立していた開発プロセスがうまく機能しなくなった。そこで開発プロセスを可視化し、品質を守る仕組みを日常のプロセスに組み込む改善をチームで進めた取り組みを紹介する。

背景：個々の判断に支えられていたプロセスの課題

• 速度を優先して必要な確認を省けば手戻り・不具合リスクが高まり、逆に工程や確認項目を増やせば開発が鈍るというジレンマ
• 第一歩として、要求整理から仕様決定、設計、実装、レビュー、テスト、リリースまでの実プロセスを書き出し、「何がわかっていて何がわかっていないか」を把握
• 各工程の目的・インプット・アウトプットを整理し、進め方が明確な工程／不明瞭な工程／課題がある工程に分類して共有

その結果、取り組む課題を2つに絞った：

1. 開発中の成果物へのフィードバックを得る工程を設ける（開発の方向性を確かめる機会が限られていたため）
2. 実装着手前の認識合わせ（リファインメント）を改善する（毎スプリントのリファインメントが開発全体のボトルネックだったため）

施策①：フィードバックを「イベント」から「仕組み」へ

方向性を確かめる機会を組み込む

• 新しい会を設けるのではなく、既存の会の目的と進め方を見直し、定期的にレビューを受ける場として位置付け直した
• 継続可能な仕組みにするため、チーム自身が「誰が・どのような状況で・何を解決するために利用するのか」「どういう状態になれば目的達成か」を整理
• 具体化の方法としてチーム自身でシナリオを設計。盛り込む観点は以下：

• 合意した要求・要件どおりに動作し、ユーザーの課題を解決できるか
• 想定した操作フローと実際の利用者の認識に齟齬がないか
• 操作の難易度や表現・挙動が、ユーザーに不安を与えないか

レビューを通じて生まれた変化

• 実際の操作を通じたフィードバックをもとに、必要な対応をリリース前に取り込めるようになった
• 「ここはわかりづらいのでレビューで見てもらいたい」といった会話がチーム内で自然に生まれるように
• 開発チームだけでは気づきにくい視点を得る場としてレビューが意識され始めた

施策②：リファインメントの「時間」ではなく「インプットの品質」を見直す

課題の背景を整理

• リファインメントは長時間化しても着手可能なチケットが十分増えず、PRレビューでは実装前に検討できた可能性のある指摘も見られた
• 要因を整理した結果、議論の前提となる仕様・バックログの優先度・チケットの情報に改善の余地があると判明
• 議論の土台をあらかじめ作れば、リファインメントでは実装に向けた論点に集中できると考え、バックログの優先度とチケット情報に着目

バックログ品質を改善する運用

• PdM・PdE・QAEが毎週集まり、それぞれの観点を持ち寄る運用を開始：
  • PdM → 提供価値の観点
  • PdE → 実装上の不確実性・技術的な依存関係の観点
  • QAE → 品質リスクの観点
• 具体的な流れ：チケットの進行妨害要因と開発状況の変化を確認 → 各観点から優先度・着手順の妥当性を確認 → 次回リファインメントで扱うチケットの背景・実現したいこと・受け入れ条件・参照資料の有無を確認
• 優先度未定・情報不足のチケットが持ち込まれるのを防ぎ、リファインメントを実装論点に集中させる

改善を続けるための定点観測

• 観測項目：リファインメントの進行状況（1チケットあたり累積時間・完了状況）＋ 実装時の指摘傾向（手戻りにつながり得るPRレビュー指摘）
• データソースはSlackスレッド・会議の文字起こし・チケットに紐づくPRコメント
• Notionのカスタムエージェントでチケットごとの議論内容・所要時間・完了状況を抽出・分類してDBに登録し、継続観測を自動化

まとめ・筆者のメッセージ