開発スピードと品質をどう両立させるか
てらら氏（以下、てらら）：では次ですが、次は「開発スピードと品質をどう両立させるか」というテーマで話してもらいたいなと思います。じゃあ、ゆもつよさんお願いします！
湯本剛氏（以下、湯本）：はい。まずスクラムだと、スプリントというタイムボックスみたいなものがあって、テストが全部終わって、スプリントが終わった時に出すことで、一応きれいな円になるんですよね。だけど、実際に僕がやっているところは、そこを完全にできていることはそんなになくて。だた、そこを目指すためにいろいろと努力はしています。いろいろなことをやって、「どうやったらそれが実現できるのか」ということをやります。
またfreeeカード Unlimitedの話になりますが、すごく良かったのは、飲みに行った時に、プロダクトマネージャーの人とエンジニアとQAのみんなで「どうやったらこれをスプリントの中で入れられるかな？」とか。
スライドを見て「これだよね！ 目指すのは」みたいな。「（目指すのは）QAだけじゃなくてね」ということがありまして。
中村洋氏（以下、中村）：ありましたね。飲んだ時ですよね？
湯本：はい！ あの時に（中村さんも）いましたよね。
中村：みんなで盛り上がっていた時ですよね？
てらら：一緒にいたんだ（笑）。
湯本：ああいうのがすごくいいなと思っていますね。
スプリントの最初からQAにタスクがあったほうが良い
てらら：それは具体的にどういうことをしたんですか？ どういう資料だったんですか？
湯本：タイプ1、タイプ2、タイプ3、タイプ4みたいなのがあって、タイプ1は何個もスプリントが終わってからテストをする。タイプ2は……。ちょっと細かいところは違うかもしれないですが、そういうイメージですよね。
中村：（タイプ2は）スプリントが1個終わった後に、そこでできたものを次のスプリントでテストをするという、ちょっと後ろにずれていくパターンですよね。
湯本：そうですね。
中村：タイプ3は、スプリントの前半はQAが動いていないんだけど、後半で動くみたいな話。タイプ4は本当にずっと一緒、本当に最初から最後まで活動していくというパターンですよね。
湯本：そうそう。
中村：それで「俺らは（タイプ）4を目指すべきだ！」みたいな話をして、「いけるんとちゃう？」みたいな話で盛り上がって、「Slack」に投稿していましたよね（笑）。
湯本：そうそう（笑）。そういうことをやっていました。要は、スプリントの最初から、そのスプリントの中でのゴールを達成するためのタスクがQAあるわけですよね。今のチームでの最初のプランニングだっけ？ 週の最初にやる時に、スプリントゴールとQAのゴールを一緒に決めるとか、あとはストーリーチケットに受け入れ基準を書くとかをしていくと、最初からいっぱい仕事が出てくるんですよね。
中村：そうですね。テスト設計をするとか、テストデータを作るとか、テストをしやすい環境を作るとか、たぶんいくらでもやることはあって、その物が来るまで待つという発想ではないはずなんですよね。
湯本：そうなんですよ。ただ、そのようにQAとしていろいろと考えるのもあるんだけど、これは結局QAだけでできる問題じゃなくて、やはりチームなんですよね。チームとして考えなくてはいけなくて。
例えばちょっとしたバージョンアップだったら、そのフロントとバックエンドを合わせて「これをできればそのまま出せますよ」「お客さんに価値を提供できますよ」というものを1週間で作るようにプランニングに入れればテストもしやすいとか。
前半で作って後半にテストをするということはQAだけではできなくて。チーム全体で考えていかないとできない話です。
1週間でいきなり出せないとか、何週間かやっていかないと出せないにしても、例えばフロントだけを作るんだったら、フロントだけでもテストをできるようにする。
要は、QAも一緒に入って最終的にやるようなチケットの切り方とか、バックエンドだけでも、例えばAPIまでを作ってAPIで叩けば何かしら結果が見ることができるとか、そういうところまで作るようにして、それがインテグレーションされていく感じのストーリーの組み立て方にすると、QAが入れるというか、早く入って価値がある。「早く入って良かった」と言えるようになるので、そういうふうに考えていかないといけない。
それこそ複数の機能で1つのMVPのプロダクトを出すんだったら、一番肝だと思うところから作ってもらうとかね。そういうこともQAのほうで言えるわけですよね。
中村：そうですね。
湯本：それを言うことも大事だし、そういうことを受け入れるチームみたいな（笑）。
中村：そうですね。「効率良く」みたいなキーワードで、一気に作ってたくさんテストをするのが効率が良いという人もまだまだいるなと感じていて、そんなことをすると、だいたいしんどくなっていくのが目に見えています。
湯本：そうそう。それは昭和のやり方。
中村：昭和（笑）。だいぶ古いですけどね（笑）。
てらら：昭和は（自分はまだ）仕事をしていない。
（一同笑）
価値があるのかわからないものが手元に残り続けるのはリスク
中村：先ほど湯本さんが冒頭で言ったように、そもそも「価値があるかは出してみないとわからない」という世界で勝負をしています。であれば、作れば作るほど手元に（価値が）わからない状態、本当に売れるのかわからない状態のものがどんどん残り続けていくのはめちゃくちゃリスクだと思っています。
それであれば、多少はオーバーヘッドをしてもいいから、アジャイルで速く小さく作ってどんどん出していくのが、やはり私はいいなと思っていたりします。
先ほどの湯本さんの説明で1個だけ補足をしておくと、スクラムの場合は、スプリントが終わった時、リリースするかどうかは別として、リリースがいつでもできる品質を保つのが大前提になるんですね。
リリースをするかどうかは、例えば外的な環境、広告を打つとか、どこかと協賛する関係で待つことはあっても、いざとなったらいつでもリリースできるような品質を整えておくことは求められるかなと思っています。
そうすると、先ほど言った、APIだけでもパッと見て「ちゃんと叩いたらこういうJSONで返ってくるな」ということがステークホルダーのほうでわかれば「あ、いけるじゃん」とか。
「こういう場合はどう動くの？」という話を見て、「あ、そっか。それじゃあテストが漏れているな」とか「これはたぶん、こうしたほうがもっと使いやすくなるんとちゃうの？」というフィードバックがそこで生まれるので、そういうのもありなんちゃうかなとは思いますね。
必ずしもユーザーからだけのフィードバックだけですべてが解決するとは思わないので、そういうところも工夫の余地はいっぱいあるんちゃうかなとは思ったりします。
湯本：内部品質というか、設計的な作りが良いかどうかみたいなのもわかりますしね。
中村：そうですね。もちろんそれだけをやっていて、結局ユーザーがホンマに使ってくれているかを見いひんのは、それはそれであかんのですけど。
かといって、アジャイルQA的な文脈で話した時に、「塊が大きくて、このままだとユーザーに出せないから、スプリントレビューには出しません」とか、「QAするのはもっと後になります」みたいなことを言うんですけど、先ほど湯本さんが言ったように、出さないけれど、APIだけでもちゃんと期待する品質が確保されているかとか、「もっと使いやすくなるんちゃうか？」とか、そういう観点はあっても良いと思います。
湯本：そういう切り方をしてほしいんですよ。
中村：そうですね（笑）。
バックログの切り方はトライアンドエラーを繰り返すことで良くなる
中村：湯本さんと一緒になったチームのバックログの切り方は、何回もトライアンドエラーをやっていたなと思いますよ。
「これをするとこういうふうになってうまくいかんかった。でも、ここらへんはうまくいったからそれを継承しながら、次のスプリントではどんな切り方を工夫するか」みたいな、そのチームじゃないですが、バックログの切り方とかは、他の現場でもどうやったらうまく速く出せるかみたいなところは何回もやっているトピックではありますね。
湯本：フィードバックを受けて、学んで、成長していくというのは繰り返されるんですよね。バックログの切り方然り、チケットの流し方然り。本当に細かいことを言うと、チケットの流し方は「レーンをどう切っておけばQAにとってわかりやすいか」とか。あとは「これと、この機能をセットにしてからリリースしたいと思っているけど、その全体像をどうやって把握するか」とか。
そういうことを、チケットの切り方とかレーンの並べ方とか、それこそハッピーが出た時……、「ハッピー」というのはバグのことですが、バグが出た時にどういうふうにチケットを切って回していくかは、たぶん10回ぐらい変わっているんじゃないですかね？ もう10回以上変わっているかもしれないですね。
中村：そうですね。たぶん私がfreeeカード Unlimitedのチームを見た時の最初のレーンは、流し方や割り方から見ると、だいぶ変わっていると思いますね（笑）。歴史を見ていくと変わっていることはわかると思います。
湯本：ということができるのも、良いことなんだろうなと思うんですよね。そうやって自分たちが「こうやったらうまくできる」「速くできる」ということを、トライアンドエラーというか、やっていくことでだんだん良くなっていくのがいいなと思います。
中村：そうですね。
「うまくいったこと」をコピーしても成功しない
中村：これはアジャイルQAの話から逸れるかもしれませんが、アジャイルコーチとして支援している時によく言っているのが、「あるチームでうまくいったことを隣のチームにコピーしようとしないでください」ということです。
そこに集っている人やプロダクトも当然違うわけで、成長の角度も違うわけですよね。それで標準化やコピーをしようとすると、だいたいうまくいかなくなります。
とはいえ、組織の中である発見があったのであれば、それを見に行ったり話を聞きに行って、「なんでこのチームはこのやり方にたどり着いたのか」をちゃんと観察したり、話を聞いて、「それで僕らはどないしたらええんやろな」「こっちはこっちで実験していきましょう」みたいな話はよくしていますね。横展開とか標準化という言葉があまり好きじゃないタイプなので（笑）。
湯本：私は標準化を推進しているのでちょっとアレなんですけど、ただ言いたいことはわかるんですよ。プロセスややり方をコピーするのはうまくいかなくて。僕がいつも言っている標準化というのは、「アウトプットを誰が見てもわかるようにしましょう」ということで、要はインターフェイスを合わせましょうということ、「アウトプットを標準化しましょう」と。
中村：いいですね。
湯本：アウトプットがみんな違うと、キャッチアップに時間がかかるじゃないですか。書いてあることが同じということでは、どれだけ仕事がしやすくなるか。ただ、どうやってそこまでたどり着くのかは人それぞれというか、合わせないほうがいいですね。
中村：そうですね。だから先ほど言ったことで、例えばスクラムだったら透明性、検査、適応がありますが、もし2チームで連携してするんだったら、こことここの透明性をある程度合わせておく必要はあると。ただ、その透明性を実現するためのやり方とか、何を大事にするかはそれぞれのチームでたぶんルートが違うというか、そういう感じはありますよね。
そういうのがチームごとにけっこう違っていておもしろいなとは思います。だいぶテーマから逸れていきましたけどね（笑）。
てらら：ぜんぜん大丈夫ですよ。すごくためになる話で聞き入ってしまいました。ありがとうございます。「開発スピードと品質をどう両立させるか」というテーマに関しては話してもらったとおりというところで、次のテーマにいきたいと思います。
（次回に続く）
