この記事はトレタ Advent Calendar 2019 21日目の記事です。
こんにちは。QAエンジニアの坂田です。
トレタに入社して1年が経ち、既存サービスのエンハンス開発やいくつかのリニューアルプロジェクトに携わってきました。プロダクト品質向上やメンバーへの貢献を模索するなかでQAエンジニアが仕様を書くという試みをテーマの1つとして行ってきましたので、今回はその話をしたいと思います。
なお、本記事では「プロダクトの外部的な振る舞いを定義したもの（UI仕様）」のことを「仕様」と呼びます。テストの仕様ではありませんのでご注意ください！
そもそもなぜ仕様を書くのか
仕様を書く目的を私なりにざっくり表現すると、以下のような感じになります。
- リリース前：プロダクト設計の不明瞭さや矛盾を早期検知・解決するため
- リリース後：プロダクトの振る舞いが本来どうなっている（べき）か確認するため
リリース前は開発フェーズ、リリース後は運用フェーズと言い換えると分かりやすいかもしれません。
仕様はメンテが大変、すぐ陳腐化する、などの理由でそもそも書かれないことも多いと思いますが、それはリリース前ではなく後者（リリース後）のドキュメント保守の不毛さが原因だと考えています。
最近ではソースコードやテストケースなどの最終成果物で仕様を分かりやすく表現し、中間的な仕様書の保守をなくしてしまおう、という考えも主流になっています。 リリースを経て最終成果物が揃っている段階であれば、個人的にはこの考え方に大賛成です。
ここで問題なのは、前者と後者が混同され、保守が大変だからという理由で前者（リリース前）の目的での仕様作成も行わない判断が下されがちなことです。
リリース前は、要件検討〜UI設計〜実装〜テストの全てのフェーズで設計を反復的に更新する必要が生じます。 また、後ろのフェーズで不明瞭さや矛盾が見つかれば、都度前のフェーズへ戻って設計を見直すことになります。
そのため開発フェーズにおいては、可能な限り早い段階から設計の問題点を解消しつつ、プロジェクト全体に及ぶ頻繁な設計変更に追随し、メンバー間で常に認識を揃えるための何か（つまり仕様）が必要です。
個人的な考えですが、開発フェーズでは「プロダクト設計の不明瞭さや矛盾を早期検知・解決する」ために仕様を書くのは意義があるし、むしろそれに特化させてしまって良いのではないか、と考えています。
なぜQAエンジニアが書くのか
通常、QAが仕様をレビューすることはあっても、書くことはあまりないかもしれません。 にも関わらず私が仕様を書こうと思ったのは、以下のように着手しやすい状況だった、というのが大きいです。
- ゼロからではなく既存プロダクトの動作をベースに仕様を書き起こすことができた（リニューアルプロジェクトの場合）
- プロジェクト参入時点で画面デザインや遷移図などのドキュメントが揃っていた
- キャッチアップのための時間的余裕があった
実際に仕様を書いてみて、QAが仕様を書くのは自分のためにもチームのためにも利点が多いと実感しました。 具体的にいくつか挙げてみます。
仕様作成へのモチベーションがある
困ったことに、そもそも仕様（あるべき振る舞い）が分からないとQAはテストを設計できません。 そうした状況を日頃から経験しているQAは、テストに足りない情報を集めて仕様を整理する、という行動を元々取ってきており、それをプロジェクト早期から行っておくことへの強いモチベーションがあります。
早期に第三者視点で仕様をチェックすることで品質が上がる
個人的に一番重要と考えているのがこれです。 実はテストで見つかるバグのほとんどは実装の不手際ではなく、重要な要件に誰も気づいていなかったり、仕様に綻びがあったり、仕様の認識がずれていたことが原因だったりします。
ソフトウェアテストには「初期テスト」という原則があり、プロジェクト終盤のテストでバグを見つけるよりも序盤で設計の問題点を早く潰した方が何倍何十倍も少ないコストで対処できます。
QAは通常テストを行うことで品質をチェックしますが、むしろより重要なのは、どれだけ早期に仕様の不明瞭さや矛盾を沢山発見し解決に導いていけるかだと考えています。
その意味で、QAがテストに使える粒度でちゃんと仕様を書き、同時に仕様作成のベースとなるドキュメントを第三者視点でチェックする役割を持つ意義は大きいです。
実装フェーズやテストフェーズで本来のタスクに集中できる
仕様が書かれない場合、実装フェーズでデベロッパが細かい仕様を検討しながらコードを書いていくことになります。 その結果、デベロッパはシステムの内部構造やアルゴリズムの検討など本来のタスクに集中できなくなり、外部の振る舞いまで扱う必要が生まれ、複雑度は格段に上がってしまいます。
仕様策定作業を後工程に丸投げせず先に行っておくことで、各フェーズで本来のタスクに集中できるようになり、開発スピードも向上します。
デザインから開発への橋渡しができる
QAは元々テスト設計などで「ユーザに対して果たすべき機能」を「システムが行うべき振る舞い」として表現する能力を身につけています。
これはまさに仕様を書く際にも発揮される能力で、システム構造や内部処理を念頭に置きながらデザインで意図された機能や振る舞いを書いていくことで、必要な情報を開発に必要な粒度で漏れなく記載することができます。
デベロッパにちゃんとテストを書いてもらえる
期待する動作が仕様で整理されているとデベロッパがユニットテストや結合テストを書きやすくなり、実際に書いてもらえる、という利点もあります。
仕様を書いてみて学んだこと
最後に、QAエンジニアが仕様を書いてみて学んだことと反省点を整理します。
- 良かった点
- 仕様を細部まで書こうとすることで初めてデザインや仕様の不明瞭さや矛盾点を発見できることが多かった
- 仕様を書いている途中で色々とテスト観点が浮かび、それをテストフェーズに活かせた
- プロジェクトのスムーズな進行や品質向上に多少なり貢献でき、PMやデベロッパから感謝された
- 反省点
- 仕様を詳細に書いたつもりでも、仕様漏れによる手戻りがいくつか発生してしまった
- QAのプロジェクト参画時期が、仕様を書くには少し遅いタイミングだった
- プロジェクトメンバーに仕様を読んでもらう努力が足りず、仕様が認識されていないことがあった
- プロジェクト完了まで仕様書をちゃんと更新し続ける意識と覚悟が必要
次にやりたいこと
テーマは変わりますが、E2EテストレベルでBDD（ATDD）を実践していきたいです！
一緒に働く仲間を探しています
トレタのQAエンジニアはお互いの自主性を尊重しつつ、プロダクト品質向上・生産性向上のために積極的に幅広い役割を担っていくことが可能です。
SET（Software Engineer in Test）も求めていますので、ご興味ある方はぜひ下記からご応募ください！
