ヌーラボの松本です。「Backlog Playプロジェクト」に2017年2月から途中参加し、プロジェクト解散の2019年7月までメンバーの一員として動いていました（プロジェクトの概要は 時系列でみる！4年の歳月をかけてPlay Frameworkで「大規模リプレイス」した話をご覧ください）。
このBacklog Playプロジェクト(以下、Play化プロジェクト)では、期間によって私の役割は変わりました。
参加した当初は開発メンバーとしてコードを書いていましたが、2018年4月からプロジェクト終了の2019年7月までは、開発をしながらプロジェクトの取りまとめをしていました。
マネジメントのような役割ははじめてだったので、いろいろ未熟な点もありましたが、プロジェクトの機能リリースを早めるために、不具合対策や手戻り削減といった問題と向き合いました。
本記事では、私のPlay化プロジェクトでの役割の変遷を振り返りながら、不具合対策や手戻り削減のために取り組んだ「7つの取り組み内容と反省点」をお届けします。
※なお、この記事は以前にDevLove関西で発表した内容をベースにしています。興味があればこちらも参照ください。
目次
開発メンバーだった時期と当時の課題（〜2018年4月）
まず、2017年秋にPlay化プロジェクトに開発メンバーとして参加していた頃の話をします。
それまでは、ほとんどのプロジェクトメンバーは他のプロジェクトをしつつ片手間にPlay化プロジェクトを進めていました。
当時の状況としては、ダッシュボード関連のリリースがようやく終わり、今後リリースしていく上で必要な環境の整備はできたと思われつつも「課題詳細・追加機能のリリースに苦戦している」といった具合でした。
この頃は、チームメンバーは6人でした。新たに増えた3人のうち1人が社内Jenkinsマスターのikikkoこと中村で、彼がマネージャーとしてPlay化プロジェクトを管理・運営することになりました。
当時の課題
当時の一番の問題はプロジェクト全体のリリース計画が立てられていない、ということでした。
各機能リリースの大まかな完了予測日もないので、プロジェクトの完了日はおろか、課題詳細や追加機能の進捗管理もできていない、といった状況でした。
状況の可視化のためにカンバンを導入
状況を可視化して、これらの問題を把握するために、ikikkoがカンバンを導入しました。
カンバンをしばらく運用したことで、仕掛かり中（WIP）の機能が多くなっていることがわかりました。例えば、半年以上前にコードを書き終えていた機能がリリースされていないこと、各機能のリリースが終わっていない状態で他の機能のコードを書き続けた結果「実装済みにはなっているがリリースできていない」という事態が発生していました。
カンバンのハマりどころと気にかけてること by ikikko
カンバンで問題が明らかになり、その解決策として、ikikkoは “WIP数（仕掛かり中のタスク）を1に制限するルール” を決めました。実装作業に携わる人数を減らしたことで、機能をリリースする方に注力できるようになり、ある程度信頼のおけるリリース計画を立てることができるようになりました。
まさに、6つのカンバンのプラクティスに従って可視化をしたことで、ワークフローのボトルネックが明らかになり、WIP制限をすることで進捗が管理されリードタイムも改善されました。
チームの取りまとめ時期と取り組みの開始（2018年4月〜2019年7月）
2018年4月にikikkoがPlay化プロジェクトを抜けて、別プロジェクトに注力することになりました。そこで、私が代わりにプロジェクトを取りまとめるようになりました。
最初は「チームリーダーをやりませんか」という話をもらっていましたが、書けるならコードも書きたいという気持ちと、管理側の経験が今までであまりなかったので大きいプロジェクトに足踏みをしてしまいました。なので、プロジェクトを見つつも空いた時間にコードを書くという立場でプロジェクトをまとめていくことにしました。
具体的には、ikikkoが導入したカンバンや開発プロセスは維持しつつ、何らかの指標から問題のありそうな部分を見つけて、それを改善しようと考えていました。そのための指標として、これまでのリリースのリードタイムをより細かく測定して、そこからボトルネックを見つけて解消する取り組みをしました。
取り組み1: リリースプロセスの詳細な計測と問題の究明
この時点での問題は「リリースに時間がかかりすぎている」でした。しかし、不具合によるステップの手戻りも多く、どこが問題かわかりづらい状況でした。
そこで、カンバン上のステップごとに、日数でどれくらい留まっているのか計測して、手戻り時には別の値として計測しました。
これを示したのが以下の図です。これは、あるひとつの機能をリリースしたときに要した日数をカンバンのステップごとに表したものです。赤い点線は手戻りがあったことを示しています。この場合は5回手戻りがあり、全体として約250日かかったことがわかります。
ある機能をリリースしたときのステップごとに留まった日数
これを含めて別の機能のリリースも調べてみたところ、主な問題として
- 手戻り回数が多い
- 手戻り後にリリースにかかる日数が長い
- ドッグフーディング環境や検証環境に出たまま留まっている日数が長い
ことがわかりました。
取り組み2: 社外の人にE2Eテスト依頼
以上で発覚した「検証環境に出たまま留まっている日数が長いのを短くする」ことを実現するために、チームの心理的な負担であるE2Eテストをチーム外の人に任せて、プロジェクトメンバーは必要なことのみに集中できるようにしました。
社外に依頼する前は、機能を作った本人がテストを書き、E2Eテストをしていましたが、テストが得意な社外の複数の方に依頼することで、テスト実施期間は短くなり、エンジニアがテストの実施に時間を取らなくてよくなりました。
※社外メンバーの選定については、Backlogエンタープライズ版のリリースチームが、社外の方にテストをお願いしてよかったという話を聞いたため、私たちもその同じ人にお願いしました。
取り組み3: E2Eテスト項目のクロスレビュー
次に手戻りの回数を減らす取り組みを優先しました。
当時発生していた不具合は以下のような様々なパターンがありました。
- 特定の条件で発生する不具合
- 以前あった不具合によって生まれたデータ依存型の不具合
- すべてのスペースにリリースしてもしばらくしないと発生しない気付きにくい不具合
その一方で、出す前に気付けたのではないかと思われる、ロジックミスなどによる不具合も何回か発生しており、それらをなくすことを目的にテストの漏れや不備などがないかクロスレビューをしました。
このとき「手戻りはユーザーに影響のある不具合があるから発生する、チームとしては不具合でユーザーに影響を及ぼす回数を減らしたい」と考えました。また、一度リリースしたものに不具合があり、後から直すこともあったので、その心理的な負担も減らす狙いもありました。
クロスレビューをしたことで、不具合が特に多かった文字列（日本語や絵文字）周りに注意を払えたり、漏れやすかったパフォーマンスに関するテストも事前にできたりしました。
取り組み4: 各ステップの進入・退出条件の設定
検証環境までのテストを終えている状態で以下のステップは、その機能の実装者が自由にコントロールしていました。
- いつドッグフーディング環境へ出すべきか
- ドッグフーディング環境での検証期間をどれくらい取るべきか
- 一部スペースへのリリース期間はどれくらいにすべきか
そのため、実装者の気分に依存していました。他の人も「その人に任せているから…」とタスクが滞留しているのに気付けないことがありました。
そこで、以下の2点をルール化しました。
- 検証環境でテストを終えたらすぐにドッグフーディング環境に出す
- ドッグフーディング環境での検証期間は1週間にする
これによって、メンバー同士で次のステップに進めるかの確認が不要になり、無駄に待っていたような状況が解消され、スムーズに次のステップにタスクが流れるようになりました。
取り組み5: 複数の機能を並行にリリースする
チーム内にSREの方が参加したり、リリースの作業自体も慣れたりしたことから、ある程度リリースがスムーズに進むようになってきました。なので、コードを書く人数を増やすと、今度はリリース待ちの機能が増えてきました。
そこで、複数の機能を並行にリリースするようにしました。不具合があったときの切り分けが難しくなる懸念はありましたが、本番環境に出すときには別のスペース群に出すといったことをして、なるべくお互いのリリースが影響し合わないようにリリースしました。
取り組み6: 退出条件の期間を短くする
管理者だけが使える機能など、機能によってはドッグフーディング環境でほとんど使われないことがわかりました。
時間をかけても不具合がほとんど報告されなかったので、「そのような機能はたとえ不具合が発生しても同様にユーザーへの影響が小さい」と判断して、前述の滞留日数を短くしました。
取り組み7: 検証環境でのテストを内部でやる
「取り組み2:社外の人にE2Eテスト依頼」とは逆の流れですが、テスト対象の機能によってはデータベースを直接見たり、更新したりするほうがテストが楽なものもありました。
また、テスターの方のスケジュール調整に時間がかかることもあったので、テストの量によっては社内でさっとやって、検証環境でのテスト期間を短縮を試みました。
7つの取り組みの「結果」
以上の7つの取り組みをした結果、各機能のリリース期間がどのように変化したのかを示します。
各機能を検証環境にリリースしてから本番環境に出して完了するまでの期間
この図は検証環境にリリースしてから、本番環境に出して完了するまでの期間を機能ごとに表わしたものです。色はどの環境にリリースしているかを大まかに示しており、ここでは手戻りは考慮していません。
2018年以降はリリースに要する時間が短くなっているのがわかると思います（ジョブ系、スケジュール系は他と違うので時間がかかっていますが）。
また、これは各機能をポイントで見積ったものが、どのようにリリースされていったのかというプロジェクト全体の進捗を表わすバーンダウンチャートを以下に示します。
Play化プロジェクトのバーンダウンチャート (2017年7月〜2019年7月)
リードタイムを短かくしつつも、一定の割合でプロジェクトを進められていることがわかります （先の図と同様にジョブ系、スケジュール系のリリースが始まってからは進捗が緩やかになっていますが）。
7つの取り組みの所感と「反省」
状況を知るためには有用だと思われた他の値もいくつか記録していましたが、リードタイムに関するものが取り組みとして、取り組み化しやすかった印象があります。
「カンバン仕事術」を参考にしながら、自分たちが弱いと思っていたリリース周りのリードタイムの改善により注力できました。
反省点1. 取り組みを同時に実行したことで効果の分析ができなかった
結果として、リリース時間は短くなりましたが、一度にいろいろな取り組みをしたので、どれが効いているのかわからない結果になってしまいました（加えて、そもそもチーム自体がリリースに慣れてきたからという要因もあります）。
当初は改善のサイクルとしてちゃんと回そうとしていましたが、リリースする機能のサイズが大きく、かつ早めに手を打ちたかったので、一度にいろいろな取り組みをしてしまいました。
それによって、どの取り組みが有効かがわからなくなり、主観や体感による結果のみになりました。定量的な分析があまりできなかったのは、よくなかったと感じます。もし、リリースするサイズを小さく、細かくできていたら、小さいサイクルで細かい改善を1つずつ取り組めたかもしれません。
反省点2. 内向きのプロジェクトだったにも関わらず社内への情報共有が甘かった
「Backlogの全機能をそのままにウェブフレームワークを置き換える」というプロジェクトの性質上、価値が内向きになるにも関わらず、社内での情報の共有が十分でなかったという反省があります。
Backlogチーム内では、週ごとに進捗を共有したつもりでいましたが、別のチームから見ると進捗が伝わっていないという状況でした。せめて四半期くらいの粒度で適切なマイルストーンを設けておけばよかったなと反省しました。
まとめ
このプロジェクトが進行していた時期は、会社としてもBacklogのユーザーが急激に増え、Backlogのチームメンバーの数が増えたり、チーム構成も変わったり、まさに「変化の時期」にありました。そのため、メンバーの異動も多く、チーム内での価値感も大きく差がありました。
また、Play化プロジェクトは、全機能をそのまま置き換えるというもので、使いづらく感じる機能があってもそのまま移植しなければならないことが多く、たとえリリースしたものをユーザーに提供しても、個人的には「ユーザーにとっての価値をほとんど届けられてないのではないか…」とむなしく感じることがありました。
それでも最後までPlay化プロジェクトをやりきることができたのは、私以外のチームメンバーの頑張りによるところが大きく、心から感謝しています。
また、ここまで大きいプロジェクトの取りまとめができたのも非常に良い経験でした。
当初は、チームの取りまとめをしつつ空いた時間にコードが書けるかと思ったらそんなことはなかったです。データの更新やミーティングの準備などで結構時間が取られますし、チームメンバーがやりたがらないタスクを取るようになるからです。両立は難しいことを実感したのもとても良い経験でした。
このような経験をさせてくれた、ヌーラボとPlayチームの皆さんに謝辞を送り、記事を締めたいと思います。
次回の連載は「Backlogのコードメンテナンス性を向上させるために気をつけたこと」です。来週もお楽しみに！
■ Play化プロジェクト連載一覧
Play化プロジェクトメンバーが執筆した他の記事もぜひご覧ください。
- 開発チームが大規模リプレイスを成功させるために取り組んだ “7つの取り組みと反省”
- Backlogのコードメンテナンス性を向上させるために気をつけたこと
- JVM上で動くWebアプリケーションがリソースを食いつぶす原因を探るためにやったこと
- SREは大規模なリプレイスプロジェクトで発生した様々な問題にどう取り組んだか
- 大規模プロジェクトに途中参加して感じたこと
- 長期プロジェクトを効果的に “ふりかえる”ためにBacklogチームでやったこと
