こんにちは、フロリアでQAエンジニアをやっている中園です。
現在サイボウズでは kintone のフロントエンドリアーキテクチャプロジェクト（フロリア）と称して、Closure Tools から React へと置き換えるプロジェクトが進行中です。
フロリアの詳細については 次の記事をご覧ください。
今回は、フロリアのチームの一つで、利用者に気づかれない形で React への置き換えを行っている Mira チーム1の開発・テストフローの紹介をします。
"最速で" React に置き換えたい
Mira チームはただ React に置き換えるのではなく「最速で React に置き換える」という目標があります。
フロリアの各チームはそれぞれのチームごとにオーナーシップを持っており、チームごとに意思決定を行っています。Mira チームでは「最速で置き換える」という目標に向かって、開発スピードを向上させるべく開発・テストのフローを最適なものにしようと試行錯誤を繰り返しています。
試行錯誤を繰り返すうちに、kintone の開発チームで行っていた開発・テストのフローとは異なる形になりました。
kintone の開発・テストフローについて
kintone の新規機能を開発をしているチームは、エンジニア・QA のスクラムチームが複数あり、一週間のスプリントで新しい機能の開発を行っています。
プロダクトバックログアイテム(PBI)の「完了」の定義は機能実装完了までとなっており、エンジニアの実装が完了したあとに随時 QA が PBI ごとに機能テストを行うフローになっています。
受け入れテストは自動化されていますが機能テストはすべて手動で行うため、テストが「完了」になるタイミングは PBI のボリュームによってバラつきがあります。
Mira チーム の開発・テストフローについて
フロリアではチームごとに独立した意思決定を行っています。チームがオーナーシップを持って独自のフローで開発とテストを行えることで改善が行いやすい体制になっています。週に一度の振り返りではエンジニア・QA・PO（プロダクトオーナー）のそれぞれの視点から改善点が出せており、その都度自分たちのチームに最適なフローに変えています。
次の図は Mira チームが現在行っている開発のフローです。
PBI の着手時、まず行うのはテストの設計です。QA が事前に用意したテスト仕様書をもとに、QA とエンジニアで設計を行います。テストはできるかぎり自動化する方針ですが、自動化が難しかったりコストがかかりそうなものは手動でテストを実施します。この PBI でどういったテストが必要になるのか、着手段階で QA とエンジニアの間で認識を揃えます。
実装フェーズでは、自動テストとしておもに Unit テストと Integration テストを同時に書いていきます。Mira チームでは Unit テストを「一つのコンポーネントに対してのテスト」、Integration テストを「複数のコンポーネントにまたがるテスト」としています。
機能の実装と自動テストを反復して繰り返し行うことで、より素早くフィードバックを得られます。開発はモブ・ソロのどちらかにこだわることなく、その時々に合った方法を用いています。
詳細な内容については、次の記事をご覧ください。
機能の実装と自動テストの実装が完了したのち、 QA は意図通りにテストが自動化されているかを確認するとともに、自動化できなかった部分の手動テストを行います。また、アクセシビリティやセキュリティのテストはそれを専門とする Design Technologist2 や PSIRT（Product Security Incident Response Team）のメンバーが行います。
Mira チーム では PBI の「完了」の定義に「テストの完了」を含めています。一週間のスプリントですべてを完了させる必要があるため、一つの PBI ができるだけ小さくなるようにしています。PBI を小さくすることで、扱う必要のある範囲が非常に小さくなり、実装・テストがしやすくなるという恩恵がありました。
不具合を見つけられるタイミングが早くなった
開発の段階から自動テストを書くことで実装に対してのフィードバックが早めに得られるようになり、不具合を見つけられるタイミングが早くなりました。
QA による手動テストを実施するタイミングで不具合がほとんど見つからなくなるほどの効果がありました。これによって手戻りが大きく減り、一週間という短期間のスプリントでもテストの完了を含めた PBI の完了が実現できています。
アクセシビリティやセキュリティのテストも同じスプリント内で行いますが、悩んだときには都度専門メンバーに相談できる体制があるので、ここでも手戻りを少なくできています。
実装とテストを短いスパンで繰り返していることからテスタビリティの高い実装ができているので、コードレベルでの保守性も上がっているように感じます。この開発・テストのフローになってから、エンジニアから「自動テストが充実しているので、コードのリファクタリングが怖くなくなった」という声もありました。
既存フローとの整合性が今後の課題
チームが独自のフローで開発を行えていることはよいことだと感じていますが、リアーキテクチャプロジェクトという性質上、置き換えの対象である kintone のデプロイやリリースのフローに合わせないといけない部分も出てきます。こういった点も考慮しながらより開発・テストがやりやすいフローを目指していきたいです。
まだ先の話になりますが、リアーキテクチャがすべて完了したあとの成果物や開発・テストのフローを、 kintone の新規開発チームとどう整合性をとっていくかは今後の課題になりそうです。
一緒に挑戦しませんか？
kintone のフロントエンドリアーキテクチャプロジェクト（フロリア）では、挑戦したいことや課題がまだまだあります。一緒に挑戦するメンバーを次のポジションで募集していますので、気になった方はぜひ応募してみてください。
