先に公開した私の考えるfreeeQAの目指す姿に続いて、QAが目指すべきことを実現させるためのfreeeの開発体制について、私が理想だと思っていることを書きます。といっても、書くことは開発体制の中でのQAチームの位置付けについてだけです。
私の理解したfreeeが開発で目指していること
freeeの開発が目指していることは、スピード重視だと理解しています。前回も書きましたが、価値をできるだけ速く届けることがとても大事だからだと思っています。なので、きっと、開発として重要になるのは、スコープを小さくし、スピードを速くすることであり、そのようなことを実現する、例えばマイクロサービスアーキテクチャーへの進化だと思います。開発で考慮しなければならない４つの要素である、スピード、スコープ、コスト、品質をレーダーチャートにするとこんな感じだと思います。
4つの要素を小さくしていくことで、スピードが速くなってきます。
ただ、前回も書いたように、traditionalなQAを続けることで起きてしまうと思われる懸念が、松プランのテストによって、コストだけがバランスを崩すことです。
どこでも起きてること
誤解を恐れず書いてしまいますが、こういう懸念は、スタートアップのITサービス企業がみんな通る道なのではないかと思っています。
- まずはサービスを立ち上げるために、あまりQAについては考えないで、どんどんプロダクトをアウトプットする。
- サービスが世の中に受け入れられると、利用者が増えるので品質をちゃんと考えないといけないフェーズに入る。
- 今まであまり品質について考えてこなかったので、単純にQA＝テストになってしまい、traditonalなビッグバンテストを行なってしまう。
ここでなんとかしないと、
- traditonalなビッグバンテストが常態になり、スピード、スコープ、期間といった他の要因からみてバランスができないほどコストがかかりすぎてしまう。
ってなってしまうかもしれません。QAにかけるコストがテストだけでいっぱいいっぱいなので、アーキテクチャーも泥団子になってしまいます。
古い体質のITは、すでに最終段階の「バランスができないほどコストがかかりすぎてしまう」という局面に入っている開発をしているところもあります。その理由のほとんどはテスト工程でコストがかかりすぎることです。対応策として最初はテスト、そのうちテストだけでなく開発全体でなるべく安い人材に切り替えていくというコストだけ気にして生産性が全くおかしくなる深みにはまっていきます。
現時点から進化していき、理想としてたどり着く、QAと開発の関係の目指す理想像はこう考える! と言うイメージは以下のとおりです。
左側が、現在の典型的なQAチームとの関係を表していて、右側が目指す理想の姿へ移行していくことを表しています。ただ、このイメージ図だと、想定よりも小さくなってしまって何が書いてあるかわかんないですね（笑）
現時点の体制と期間のイメージ
現時点の部分だけ切り抜いて、再掲します。今から書くことはちょっと極論かもしれず、全部が全部そうではないとは思いますが、典型的な例として捉えてください。
- 開発とQAは同じチームではありません。開発から依頼を受けた別チームがQAのためのテストを行います。開発のある中間の時点から入って、品質を保証するために、より安全な方向に傾き、テストをリッチでゴージャスな松プランにする傾向になります。そうなると、開発よりもQAが人数が多くなることがあります。特に、安全第一になるあまりに、変更内容や品質リスクの検討も不十分なままとにかく網羅だけを考えると、常に松プランになってしまうことが多いかもしれないです。
- そのため、開発よりQAによるテストの期間の方が長くなってしまうといったことがおきることもあるようです。そしてQAへの依頼が殺到すると、テスト担当者の人数が不足して、QA待ちの状態という空白の期間ができてしまいます。
- もし本当に松プランが必要であり、開発の関係者全員の合意の上での松プランであれば問題ないかもしれませんが、コストは膨らむばかりです。松プランを選ばなくても大丈夫な体質にしていくのが本来論だと思います。
あるべき理想の体制と開発期間イメージ
理想的な将来の方も切り抜いて再掲します。
- QAへテストを依頼するということはなくなり、開発の中にQAとしてのテストを行うロールを持ちます。QAとしてのテストをする人は、別のテスト専任者がチームにいてもいいですし、開発担当者の誰かがテスト担当者を兼任してもいいと思います。会計、人事労務、申告だと、QAのためのテスト専任者が数名チームにいた方がよいかもしれません。プロダクトの特徴によって臨機応変にしていくんだと思います。
- 開発期間はこれまでよりも長くなるかもしれませんが、QAを含めたトータルのデリバリー期間としては短くなります。
- QAと開発の区切りはないので、改めてコミュニケーションを取るための時間を削減することができ、臨機応変に開発チームの意思でQAのためのテストを始められます。
- 品質はmoving targetです。その時その時で求められるものごとは変わります。QAとしてテストを行うメンバーだけでなく、開発関係者全体がチームとしてそのタイミングで充分だと思える品質を検討して、コストとスコープと開発期間に合わせたテストを行うのが得策です。そんな中、チームが品質リスクを検討し、テストで網羅すべき箇所を限定するのは非常にイマドキなよいやり方です。そしてテストの結果からライクリフードリスクを鑑みてテストを追加するのが良いでしょう。この場合、テストケースをちゃんと書くより、テストチャーターを書いた方が良いです。
- インパクトリスクだけが大きいテストを人ではなく機械（つまり、自動テスト）にやってもらうことで、QAの期間が短縮します。インパクトリスクだけが高いテストは総じてリグレッションテストにできることが多いです。リグレッションテストを自動化するためにはちゃんとテストケースをかいたほうがよいです。また、リグレッションテストは、リリースとは非同期に常に行うようにすると、さらにQAの期間が短縮します。
- そのかわり、非同期に行うリグレッションテストで見つかったハッピー（リグレッションハッピー）はgo liveの後でもできるだけ早く修正して本番へデプロイすべきで、このような理想の姿は、速攻デプロイができるかにかかってきます。
- QAチームやSETが持っていた役割は全て開発チームへ大政奉還し、開発チームが自分たちでQAをするのがうまくできるために、横断的支援をするチームへと変化するべきだと思います。つまり上記したようなテストをしていけるように支援をするということです。また、QAチームは、組織として品質をどう捉えるかを取りまとめる係になり、品質に関する情報集約、分析をして、組織が求める品質のために注力すべきところを特定して改善推進をしていくべきだと思います。そして、開発チームのみんなが自分たちのチームでQAやテスト自動化ができるようになり、他チームからの支援も不要になれば、最終的にはQAだけを専任で行う部署は不要となります。開発者、開発チームが自分たちでQAできるようになるからです。究極はこれを目指したいです。
いきなりジャンプはできない
こんな理想ばかり書いてきましたが、現状から理想のイメージにすぐに変わるのは現実的ではないと思っています。また、いきなり変えると品質確保もままならなくなる可能性もあり、危険です。ただ、freeeには、理想ドリブン と言う素晴らしい言葉がある通り、理想に向けて、さまざまなアクションが必要であり、それを経て到達できるのだと思います。さまざまなアクションにはどんなことがあるか、現時点で思いつくことを次回分として書いていきます。
