フロントエンド刷新プロジェクトで実践した開発プロセスの改善事例

この記事は、CYBOZU SUMMER BLOG FES '24 (Frontend Stage) DAY 11 の記事です。

こんにちは。サイボウズでフロントエンドエンジニアとして働いているshin-chanです。

普段は kintone のフロントエンド刷新プロジェクト（通称フロリア）の中でソフトウェアエンジニア（以下、SWE）として実装に取り組みながら、昨年からはその中の１チームである Reactone チームのプロダクトオーナー（以下、PO）としても活動しています。

本日は、フロントエンド刷新の活動を行う中で Reactone チームで実際に取り組んだ開発プロセスの改善事例について紹介します。

フロリアの詳細については、以下の記事をご参照ください。

またプロジェクトの今までの取り組みについては以下のリンク先もご参照ください。

Reactone チームの活動について

Reactone チームは kintone のアプリ設定画面のフロントエンド刷新に取り組んでいるチームです。

現在はフォームの設定機能などを含むページのコードベースを、React & TypeScript をベースとしたものに置き換える活動に取り組んでいます。

Reactone チームの過去の取り組みについては以下の記事もご参照ください。

自分が PO になった頃のチームの状況

自分は 2022 年の 11 月末に Reactone チームに参加しました。そこからしばらくは SWE メンバーとして活動していましたが、参加してから 1 年弱経った昨年の 10 月頃から PO も兼任しています。

その当時はフォームの設定機能の刷新を開始して半年ほどが経過した頃でしたが、チームは開発プロセスに以下のような問題を抱えている状態でした。

1. 各種ゴールを設定しているが、うまく扱いきれない

Reactone では 1 週間を 1 スプリントとしたスクラム開発を採用しており、そのため毎スプリントのゴールはもちろん、四半期単位での開発目標をプロダクトゴールとしても定めています。

ですが当時はチーム内でゴールをうまく扱いきれず、以下のような状況が発生していました。

スプリントゴールの設定に難航する
- 各スプリントで実施する PBI を優先順位順に選択することは出来るが、それらをうまくスプリントゴールとして表現できない
- 毎回スプリントプランニングの終盤に「今週のゴールはなんだろう……？」とみんなで頭を悩ませてしまう
- 無理やり言語化はするが、納得感に欠けるゴールになってしまう
  - 「□□ と △△ の PBI を完了させる」など
プロダクトゴールに紐づいたスプリントゴールを設定できていない
- 毎スプリントの活動をプロダクトゴールに関連づけられておらず、そのため四半期の中盤〜終盤で「このままだとプロダクトゴール達成できない？」ということに気づく

2. 開発リソースが少なく、ボトルネックが生まれやすい

当時、チーム内には SWE が３人と QA が１人という状況で開発を行なっていました。

決して開発が進められないほど少ない人数ではないのですが、メンバー１人の休暇や会議の予定などで開発が滞りやすい状態になっていました。

そのため開発プロセスが安定せず、（その他にも色々な要因があるとは思われますが）スプリントゴールの未達が 2 ヶ月以上も続くような状況に陥っていました。スプリントレトロスペクティブの際にも「最近チーム全体のモチベーションが低下している？」という議題が上がるようになりました。

実践した取り組み

以下では、前節のようなチームの状況を改善するために実践した取り組みのうち、特に効果があったと思われるものについて２つ紹介します。

1. スプリントプランニングで１週間のスケジュールを立てる

以前はスプリントプランニングの場において、今回のスプリントに投入する PBI とその担当者を決める運用を行なっていました。

現在では、プランニングの際に以下の画像のように「そのスプリントの中でどのように PBI を対応するか」というスケジュールを組むようにしています。

スケジュールを組むことで、以下のような効果が得られたと考えています。

毎回のスプリントゴールの達成に自信を持ちやすくなった
- スプリント内のメンバーの勤怠状況等を考慮し、どこがボトルネックになりそうかなどを考慮した上で計画を立てられる
- 人員リソースが少ない中では、ベロシティのような統計指標にしたがうだけではスプリント中に PBI が完了するか否かを予測しにくかったのが改善された
自分たちの開発の進め方に対して学びが得られた
- この手法を続ける中で、例えば以下のようなことを学んだ
  - スプリント中に QA による試験完了まで持っていくなら、機能刷新対応はスプリント最終日の前日午前には実装が終わってなければ間に合わない
  - スプリントの後半は検出した不具合の対応や既存コードのリファクタなど、QA による確認が少なく済む PBI の方が着手しやすい
  - PBI A → PBI B のように依存関係がある複数の PBI を 1 つのスプリントに投入すると完了しない可能性が高い
  - etc......
デイリースクラムの場で、メンバー間の認識を揃えやすくなった
- 作成したスケジュールを確認・更新することで、スプリントゴールの達成可能性の検査や、ゴール達成のための計画見直しがスムーズに行えるようになった

2. プロダクトゴールを各スクラムイベントで確認する

以前は設定した後に四半期の中であまり意識できていなかったプロダクトゴールでしたが、各スクラムイベントで確認する機会を設けるようにしました

スプリントレビュー
- 成果物に加えて、毎回以下の２つの確認することで今後の動き方の認識を揃える（or 変更する）
  - プロダクトゴールに対する進捗
    - 現在まで完了している PBI、対応中の PBI、残りの期間で実施する予定の PBI を確認
  - 直近スプリントの計画
    - プロダクトゴールを達成するために、次スプリント・次々スプリントではどのようなことに取り組むべきかを確認
- プロダクトゴールに対する「検査」「適応」の場になる
スプリントプランニング
- スプリントレビューで確認した「プロダクトゴールに対する進捗」「直近スプリントの計画」に基づいて、スプリントゴールの草案、及び選択する PBI を決める
- 実際には前項で述べたスケジュールも作成するので、以下のような手順でスプリント計画（スプリントバックログ）を策定する
  1. スプリントゴールの草案を PO が提示し、そのスプリントの予想ベロシティも参考にしながら、ゴールに紐づく PBI を選択する
  2. スケジュール上に選択した PBI を並べて、スプリントゴールを達成できるかをチーム全員で確認する
  3. 2 の確認に基づいて選択する PBI／スプリントゴールの案／スケジュールを調整し、チーム合意の下でスプリントゴールを確定させる

この取り組みにより、以下のような効果が得られたと考えています。

チーム内でプロダクトゴールに対する認識が統一できた
- 「プロダクトゴール達成するためには、今のスプリントで先に〇〇に取り組んだ方が良さそう」「このままだとプロダクトゴール達成厳しそうなので、そろそろ計画見直しが必要そう」といったような会話がチーム内でいつでも自然とできる状態になった
スプリントゴールの設定が、自然とプロダクトゴールに紐づくようになった
- 以前のスプリントプランニングは、PBI を選択してからゴールを考えていたので「これらの PBI を一言で表現するならなんだろう？」に難航していた
- 現在のスプリントプランニングは”プロダクトゴール達成のためスプリント計画を策定する場”になっており、メンバーのプロダクトゴールに対する認識が揃っている状態なので、メンバー全員が納得感を持てるゴールが設定しやすくなった