はじめに
hey のネットショップ開設サービス「STORES」 の開発フロントエンド組織で EMをしています、 daitasu と申します。
2022年の上半期、私たちのフロントエンドチームで「除雪部」という技術負債解消ワーキンググループ(以下、WGとします)を立ち上げました。
この記事では、「除雪部」とは何なのか、なぜ設立したのか、何をしているのか、半年間の振り返りをご紹介します。
「除雪部」とは
除雪部は、フロントエンド内で、通常のプロジェクト(以下、PJTとします) と並行して、有志数名で集まり、技術負債の解消をハンドリングするWGです。
フロントエンド関連で負債に感じている課題を集約し、優先度付け、必要な各所への連携やタスクの分解をして、「負債を各メンバーが対応可能な状態まで落とし込むこと」、「負債の解消を一歩でも前に進めること」を役割として動いています。
なぜ設立したのか
STORES を開発するテクノロジー部門リテール本部において、フロントエンドチームは、およそ4年ほど前に立ち上がりました。 当初はメンバー1名のチームでしたが、現在では10名を超えるフロントエンドエンジニアが所属しています。
また、フロントエンドチームはそれぞれ各開発ラインに属しており、それぞれのラインで普段の開発を進めています。
組織が大きくなり、プロダクトとしてもスケールしていく一方、以下のような積もりに積もっていく課題というのもあります。
- 「やりたいよね」で終わっているタスク
- なんとなく課題になりそうだとは思っているけれど具体的に言葉にできていないタスク
- やることは明確に分かっているけれど、ボール落ちしているタスク
とはいえ、こういった負債はさっと修正できるものもあれば、ある程度のコストを掛ける必要があったり、様々なステークホルダーを巻き込んで推し進めるなど、腰が中々上がらないタスクも多々あります。
そのため、こういった課題(雪)を見出し、負債の解消(除雪)をハンドリングする部隊を設けることで、通常のプロダクト開発を進めつつも 重ための改善も進めていこう！ という思いから立ち上げました。
前段として
私たちのチームでは、今まで改善系のタスクは各プロダクト開発ラインでのPJTの隙間で進めたり、運用週 という仕組みの中で改善タスクを進めたりしてました。
運用週
運用週は、週変わりでフロントエンドチーム内で担当者をローテーションしていきます。 その週の間、役割としては、主に以下4つを率先して対応する担当者として動きます。
- お問い合わせ対応
- カスタマーチームから届くユーザお問い合わせや不具合報告などを最優先で対応します
- パッケージアップデート
- STORES では renovate を利用しています
- renovate があげる依存関係の更新PRを確認し承認したり、その他Nuxt等のバージョンアップなどを担います
- Sentry 対応
- Sentryで受け取るエラーの中で、優先度の高いものから消化をしていきます
- 改善タスク
- 上記のような緊急度の高いものがない場合は、溜まった改善系のタスクを各自消化します
こういった仕組みの中で極力負債を減らせるように工夫してきたのですが、 運用週では 1週間という制約があり、お問い合わせの対応もあるので、中々重い改善に着手がしづらい状況が続いていました。
プロダクト開発の隙間に行うにしても、ステークホルダーが多かったりすると個人の判断で決めにくいですし、 抽象度が高いタスクだと、気軽には踏み込みづらい、といったタスクが残りがちという課題がありました。
何をしているのか
では「除雪部」は何をするのか。
通常業務と並行し、WGとして動く「除雪部」にとって、負債の解消まですべてを担うのは荷が重いです。 そのため、「除雪部」の役割としては、以下のスコープではじめました。
- 技術負債がボール落ちしないように集約・見える化すること
- 各開発ラインでプールしている改善タスクや普段の会話で「やりたいよね」で止まってしまうタスクを集約できる仕組みを作る
- 開発ラインや運用で手が空いた時に 初動速く 改善にあたれるようにする
- 課題を出し合う文化を促進する
- 集めた改善タスクを優先度付け、分解し、踏み込みやすく する
- 改善タスクの緊急度についての議論を行い、対応したほうが良い を分かりやすくする
- 個人や自チームのみの判断で進められないものは連携を図り、 あとはやるだけ にする
- 特定タスクの改善モチベーションが高いメンバーがいれば、大臣としてやっていきを後押しする
- やれるものは「除雪部」で対応する
- 改善はチーム全体を巻き込んで進めたほうが属人性の観点でもよい
- 一方、消化できそうなものは「除雪部」でもどんどん消化していく
このようにして、チーム全員での技術負債の改善やっていき！ を推し進めました。
半年間の歩み
課題のブレスト、集約
まずはじめに、元々各開発ラインや個人で課題に感じていたものを集めていき、ブレストしたりする中で、タスクをまとめるところからはじめました。 Boardとしては GitHub Project を用いて集約しました。
優先度付け
洗い出した課題に対し、急いだほうが良いのか、対応負荷はどのくらいかなどを議論し、マッピングを行いました。
Board の整理、「対応可能」へのもっていき
課題を集約したBoardを「Backlog」「タスク分解中」「他チーム待ち」「対応可能」「対応中」「Done」に分け整理し、極力 対応可能 に持っていけるよう毎週の定例の中で議論と不明瞭な点の分解・解決を行いました。
タスクの消化
定例で議論して消化できるものや除雪部メンバーが宿題的に調査・対応できるものは対応していきました。 この半年に改善Boardに分解して置いて、運用やプロダクトライン、大臣、除雪部WG で消化したタスクの例をいくつか書きます。
- stale の追加
- Issueの定期自動削除を行う stale の追加を行いました
- フロントエンドのドキュメント全般の改善
- 運用週の改善
- 運用週は1人ずつの1週ごとで今までローテを進めていました
- 一方、人数も増え、ローテの機会が遅いこと、対応タスクが個人に依存し、属人性が上がってしまうなどの課題がありました
- チームで懸念を議論し、運用週の役割の再整理や複数人ローテに変更するなどを行い、改善タスクとプロダクト開発タスクを並行して進めやすい形を検討しました
- Node.js のバージョンアップ
- 各リポジトリのNode.js バージョンアップも運用の中で進み、対応を追えました
- TypeScript 化対応
- STORES のダッシュボードは現在TypeScript で実装を進めていますが、すべてがTSではなく、過去に JavaScript で実装した部分も残っています
- 後々改修が発生しそうなページに対して TypeScript 化のIssueを切り、後々楽に改修することができるよう、対応を進めました
- 軽微な不具合対応
- プロダクト開発で出た軽微な不具合は「後で直そう」といって直されずに残されがちです
- それらもBoard に集約して運用等で消化する仕組みを立て、以前よりは少し進めやすくなりました
- 不要なPR、Issue、ラベルの削除
- 開発が進むと、不要なPRやIssue、ラベルが増えてきます
- それらで不要なものを確認して消去を進めました。stale の追加もこの一環です
- チームのレビュー依頼Botの移行検討
半年間の振り返り
良かったこと
- 除雪Board という明確な改善置き場と管理する部隊ができたことで、課題を気軽に置きやすくなった
- 運用週の仕組みと合わせることで、大変なタスクもみんなで倒す、がやりやすくなった
- 初期は課題出しがあまり進まなかったが、徐々に改善タスクが出て、消化も進むようになっている
- 普段避けがちな技術負債を俯瞰して見るWGができたことで、今まで検討しなかった課題も検討するようになった
改善点
- まだ出来て半年で、改善タスクの量もまだコントロール可能な範囲。増えてくると管理しきれなくなる可能性はある
- 運用週の仕組みを変更し、複数人になったことでローテの頻度は上がってしまう
- 改善タスクや属人性の課題は改善された面があるが、プロダクト開発リソースとの塩梅は考えないといけない
- 今後とも定期的な振り返りと改善が必要
- 消化していくサイクルができたものの、WG という有志の形で進めており、規模感が大きい技術負債はどうしても対応に時間がかかる
- PdM を巻き込んでロードマップに乗せるなど、機能開発とのバランスも議論が必要
- 改善タスクがフロントエンドに閉じているが、バックエンドやSRE の観点で感じている課題も集約したい
- フロント起因の課題しか見えず、他職種観点で見えている課題感でフロントエンドのコミットが必要なものもある
- そういった踏み込みづらいもの に一層踏み込んでいきたい
おわりに
除雪部を立ち上げて半年が経ちました。
改善タスクの集約と消化のサイクルとしては回しやすくなったかなと思うものの、まだ課題は山程ありそうです。 とはいえ、仕組みとして「除雪するぞ！」というやっていきムーブメント を作っていく部隊があるのは半年の所感としては良かったです。
もっともっと除雪して、どんな大雪も雪かき出来るように継続していこうと思います！
