品質スプリント、独自の開発フローでチーム再建

イラスト:記事タイトルと開発メンバー、著者の横道だけ色が塗られている

開発室 コンテンツ開発ユニット マネージャーの横道です。

この記事は「エディトルブログキャンペーン」 4 日目の記事です。昨日の記事はフロントエンド、バックエンド両方の調整、開発をしている垣花の「フロントエンド、バックエンドの架け橋〜その仕事私が調整します」でした。

エディトル開発チームのプロジェクトマネージャーとして 1 年ほど取り組んで来ました。この 1 年で行ってきた施策を少し紹介しますので、チーム状況を改善したい方の参考になればと思います。

エディトルのプロジェクトマネージャーに就任した経緯

2018 年からエディトルを開発していますが、当時私が担当しているユニットでは複数プロダクトで中規模の開発を進めていました。エディトル専任で見ることができなかったため、別の人にプロジェクトマネージャーとして牽引してもらっていましたが、その担当者が退職することになり 2019 年 3 月から私がエディトルのプロジェクトマネージャーを引き継ぐ形で就任しました。

疲弊したチーム

就任したばかりのときは、一言でいうと「疲弊したチーム」でした。障害が大量に発生しリリースが間に合わない、そんな状態でした。

仕様の変更と食い違い

プロジェクトマネージャーに就任した当時は運用方法の変更にシステム改修が追いついておらず、開発中に仕様の変更や認識のズレが頻繁に起きている状況でした。その影響で開発スケジュールはずっと遅延トレンドで推移し、もはや達成できないのが当たり前の状況になりつつありました。

若手で構成された開発メンバー

ウィルゲートは全体的に若手のメンバーが多いですが、エディトルの開発チームも例に漏れず若手のメンバーが多いです。経験が少なく、自分の仕事に追われるので精一杯で他メンバーのフォローが出来る状況ではなく、とてもチームして成り立っている状況ではありませんでした。

チームの再建

このままではメンバー自体の能力が高くてもうまく行かないので、チームとして機能するために大きく 2 つ施策を実施しました。
その時に参考にしたのがマズローの要求5段階で、まず精神的に安定することを急ぎました。

ferret-plus.com

負のリセットと継続的な改善

スケジュール遅延が頻繁に起きていたので、チームメンバー全員を不安になり余裕がなくなって居たことに気づきました。開発がうまく行かないことや改善に対する対策が打てないもどかしさから更に不安に感じていきました。
そこで徹底的にスケジュール遅延の解消に務めました。

スケジュール遅延の解消

機能をリリースするたびにスケジュールの引き直しを行っていたので、開発をスタートした時点でリセットされているつもりになっていました。
しかし実際は遅延しながら急ピッチで開発を進めた機能なので不備があったり、内部の作りが悪く開発の効率を酷く低下させていました。
そこで、一度機能開発をストップさせてチームメンバー全員でシステム負債の解消だけをすることに決めました。その結果、すべてのシステム負債の解消までは至りませんでしたが、開発時にシステム負債による効率の低下が起きづらい状況になりました。

開発のスコープによる原因と打ち手

当時は開発要件を決めてリリースするまでを 2 ヶ月くらいのスコープで行っていました。若手メンバーだとその 2 ヶ月のスケジュールを正確にスケジュール引くことはは難しく、後半になるほどスケジュールの正確性が失われてしまう状況になっていました。
さらにスコープが長いことで、開発が終わるのか分からないという不安が高まりやすくなり、遅延した場合に何が原因だったか分かりづらくなって解消もできない悪循環に陥っていました。
これに対する打ち手は単純で、開発のスコープを小さくするという事でした。

[スコープの分け方]

  • 開発期間が 2 週間以下・・・今まで通り開発計画して進める
  • 開発期間が 2 週間以上・・・機能を 2 週間程度に切り分けて開発を進める

[検索ページを作成する時の例]

  1. 検索フォームと一覧表示デザインを作成
  2. 検索処理と一覧表示に当て込み

と言った形に 1 つの機能を複数期間に分けて開発するスケジュールを切って開発を進めるようにしました。
見通し安くなったため、開発スケジュールが立てやすく、開発遅延が発生した時には原因の発見をしやすくなりました。

システム負債を継続的に解消するために

ただ 2 週間で開発期間を切っただけではそれまでやってきた開発の流れと対して変わりません。そこで明確に「要件定義と設計を行う週」と「負債を解消する週」を設けて運用することにしました。

f:id:m_yokomichi:20200130192436p:plain

  • 設計スプリント:要件・設計を行う期間、開発時に検証が必要な場合はこの期間に検証に当ててもよい
  • 開発スプリント:設計した内容で開発する期間、この期間の間に開発者同士でテストの実施も行う
  • 品質スプリント:開発時に発生した負債を解消する期間、以前からある負債や新しいツール導入もこの期間に行う

このスプリント制度を導入したことで、開発スプリントで発生した負債をすぐに解消することができ、システム負債による効率低下を防ぐとともに、効率を上げるためのツール導入も行えるようになりました。
制度導入したばかりのときは少し遅延したり、以前からの負債によるバグが発生していましたが、スプリントを回すたびにスピードと品質が上がり、遅延がほぼ発生しない状態になりました。

半年継続してみて

初めは開発スプリントと品質スプリントだけで切り分けて運用していましたが、設計フェーズも明確に切り分けることで集中できることが分かったので紹介した形に落ち着きました。

機能規模と優先度によってスプリントのサイクルは微妙に調整していますが、これからも品質を高める動きは継続していきたいと思います。

明日はエディトル開発チームに内定者インターンとして参画している勝俣で「エディトルの開発インターンでやったこと」です。乞うご期待です!