はじめに
みなさんこんにちは。atama plus でWebエンジニアをしている末廣です。
atama plus Advent Calendar 2023 の2日目です。
atama plus のプロダクトチームでは、これから実装する機能が本当に有用なものなのかを確認するために検証用プロダクト（いわゆるMinimum Viable Product）を短い期間で開発し、短期間ユーザーに使ってもらうことがあります。
このような取り組みは、開発の効率を良くするだけでなく、リスクを抑えるのにも役立つため、色々な会社においても、しばしば取られる方針なのかなと思います。
今回は、私が所属しているチームで行った検証用プロダクトの開発で得られた「テストはどれくらいの時期に書くべきか」「仕様はどのくらいの粒度でまとめておくと共有しやすいのか？」という2つの学びについて紹介しようと思います。
得られた学びのまとめ
- 検証用プロダクトの開発期間が1ヶ月を超える場合は、内部品質への投資をすることで手戻りを減らすことができました
- 機能がよく変わる場合は「現状の仕様をまとめたページ」を作ることで、認識齟齬をある程度抑えることができます
検証用プロダクトの進め方
私の所属するチームは、QA 1名、 UI/UXデザイナー 2名、エンジニア 4名 の、合計7名で構成されています。
チームでは複数のトピックの開発アイテムを担うことがあり、今回はUI/UXデザイナー 2名、エンジニア 2名の合計4名を中心に開発し、検証用プロダクトが一通り揃ったところでQAメンバーにも参加してもらう。ということにしました。
今回の開発では、開発期間の見通しを2〜3週間としていたため、UIの検討と実装をある程度並走する方針を取ることにしました。
また、並走している間に、機能仕様が変わることが予想されたため、単体テストを実装せずに進めることとしました。
UI検討と実装を並走することで生まれた難しさ
実装を進め、一通り機能が揃ってきたところで、下記のような難しさが出てきました。
仕様変更が重なったことで、メンバー間で機能挙動について「これ、どんな仕様だったっけ？」のような認識齟齬が生まれる
機能仕様が変更されるため、チーム内の別のメンバーに仕様を共有できない
1つのバグを修正することで、別の場所に影響が出る
難しさをどう解消したか
単体テストを実装した
機能仕様が出揃ったこともあり、単体テストを作成していくことにしました。
今回はServer側のロジックが単純なCRUD処理だったため、基本的にはClient側の単体テストを実装していきました。
下記のような優先度を立てて実装しました。
- バグが出たコンポーネント
- APIレスポンスを別のオブジェクトに組み替えるロジック
- APIレスポンスにより振る舞いが変わるコンポーネント
単体テストを実装することで、以下のような効果を得られました。
それぞれ基本的なことではありますが、実際に効果を得たことで、改めて大事なことだと認識できました。
- 単体テストが失敗することで、想定外のデグレを防ぐことができる
- コンポーネントの実装者以外のメンバーが、変更を入れやすくなる
- どのコンポーネントが、どのように振る舞うかをコードレベルで明示できる
機能仕様を全てまとめたページを作成した
上記の難しさが出た時点でも機能仕様は変更される可能性がありましたが、仕様が変更されるたびに更新すると明記し、「現時点の機能仕様」をまとめたページを作成しました。
ページ内には下記の項目を記載しました。
- 実装画面のスクリーンショット
- 各種機能に対する前提
- 操作
- 期待値
- UTの有無
- E2Eテストの有無
これにより、メンバー間で「今、どんな仕様だったっけ？」という疑問が出た時に、このページを基準にして相談できるようになり、認識齟齬を防止できるようになるとともに、QAメンバーが今、どんな機能に対して単体テストやE2Eテストが実装されているのかを一目で把握できるようになりました。
また、このようなページは形骸化しがちですが、編集のオーナーを決め、仕様変更や確認することが増えるたびにチームに対して更新した旨を都度共有するようにしたことで「仕様はここにまとまっているよ！」という認識を少しづつ広めました。
更新したことを共有することにより、チーム内で「どこに情報をまとめれば良いか」、「どのようなタイミングで修正すれば良いか？」ということも共有することができるため、結果的に編集オーナー以外のメンバーも自主的に修正する機会を増やすことができ、結果として形骸化するのを防ぐことができたと思っています。
ふりかえり
検証用プロダクトの開発がひと段落したところでチーム内で振り返りを実施しました。
よりよくできた点などを共有していく中で印象的だったものを紹介します。
内部品質の損益分岐点が、1ヶ月以内に現れた
「検証用プロダクトの開発開始から1ヶ月たったあたりでバグが出てくるようになった。」
という意見が上がりました。
実際、バグの報告はちょうど開発開始から2〜3週目ごろに上がり始めており、チームではそこから仕様まとめページの作成や単体テストの実装を行い始めていました。
開発期間中、テストを書くタイミングが悩ましいよね。という、話もチーム内でしていた中で、開発メンバーがt_wada さんの「質とスピード」という資料を共有してくれました。
この資料は開発の質と開発のスピードに対して焦点を当てて解説をしてくれており、トピックの一つとして内部品質への投資の時期について言及しています。
資料の中では、質とスピードのどちらかを犠牲にした場合、知らぬうちにもう一つも犠牲にしているため、保守性を犠牲にすることで、短期的にはスピードを得ることができる（諸説あり）。その中でも、「内部品質への投資の損益分岐点は、１ヶ月以内に現れる」と指摘しています。
今回の開発に話を戻すと、初期は内部品質への投資を行わないことを選択したため、スピードを優先したことになります。
結果として、資料で指摘されていた通りに1ヶ月以内にバグの報告が上がりはじめ、テストを書いて内部品質をあげる必要が出てきました。
開発の対応としては、「テストを書く」「仕様のまとめページを作る」ことで内部品質に対して投資をやりなおすことができたため、必要なことはできていたのではないかと考えています。
振り返りを通して、「資料で指摘されていることを実際に体験していた」と認識できたため、チームの内部品質への意識が高まったのではないかと感じています。
まとめ
今回、検証用プロダクトを実装するにあたって直面した困りごとに対して「仕様まとめページの作成」「単体テストの実装」という2つの方法で対応しました。
t_wada さんの資料にある通り、今回のプロダクトの実装においては、1ヶ月ほどで内部品質への投資の損益分岐点が現れていたことが驚きでした。
一方で、バグが出始めた段階で適切に対応することができたため、メンバー間の認識齟齬の低減や、バグの修正を都度行うことができたんじゃないかと感じています。
現在、今回の検証用プロダクトを通して得られた結果をもとに、本番プロダクトの実装を進めています。
「仕様まとめページ」の作成や、適宜テスト実装に言及するなど、内部品質に投資しつつ実装を進めることができています。
次回は3日目。深澤 (@qluto) の「スタートアップのエンジニアの集まりが"組織"になるまでの過程から学んだこと」
です！明日もぜひご覧ください！