アジャイルコーチから見たfreeeの開発の特徴
てらら氏（以下、てらら）：最初の「freee流アジャイルQAとは」は以上にして、次のテーマに行こうと思います。
次は「アジャイルコーチから見た、freeeの開発の特徴」というところで、アジャイルコーチの洋さんから物申す感じでお願いします。
中村洋氏（以下、中村）：物申す感じ（笑）。freeeさんにはめちゃくちゃたくさんのプロダクトがあります。前提として、私が見ているのはたぶん3つか4つ、5ぐらいのチームです。なので、先ほど湯本さんが言ったように、私が見えている範囲がfreeeさんのすべてではないという前提で話すと、わりとどのチームも、エンジニアとQAという呼び名というかロールが、専門家として存在しているのは共通項です。
チームによってわりと濃淡があるのですが、エンジニアとQAが協働しようとしているところがあります。協働の度合いとか、矢印がけっこうチームによるなと思っていて。
壁越しに、できたから「よろしゅう」と投げていることはないにしても、「できたら教えてくださいね」という（感じで）ちょっと薄めなところもあれば、「何作るの？」とか「どんなテストをするの？」というところから入って、一緒にテストコードを書こうとしたりとか、そういうことをしている現場もあります。
そのあたりは、先ほど言ったように、プロダクトのフェーズやそのチームが持っているスキルセットによってけっこう変わっている印象はありますね。湯本さんは、そのあたりどうですか？
湯本剛氏（以下、湯本）：本当に千差万別で、いろいろなフェーズがあるというか。なので、「freeeの開発の特徴」と一概にうまく言えないかなと思います。
中村：そうですね。私が見たあるチームでおもしろかったのは、とある現場でみんなで集まってコードを書いてミーティングをしている時に、「E2Eテストをどうしようか」みたいな話をしたわけですね。QAの人もエンジニアの人もいて「じゃあこのフレームワークを使ってやろうか」と言った時に、みんながそこでワチャワチャとモブでコードを書き始めたんですよ。
「こうやったら動くよ」と言って、「じゃあこういうテストはどうするの？」とQAの人が言って、「それはこういうふうにして、こういうメソッドを使えばいいよね」という話をして。その場でけっこう良い感じにエンジニアの人とQAの人それぞれの専門性を活かして物を作っていて、ああいう風景はすごくいいなと思いました。
湯本：それはすごくいい。そうなってくるとすごくいい。
中村：そういうチームが増えていったらいいなと思いますね。
「開発しやすくする」ことをQAも一緒に考えるといい感じになる
てらら：ゆもつよさん的にはそういったところを目指していきたいみたいなところもあるんですかね。
湯本：それこそfreeeカード Unlimitedとか、大きいリリースをしなきゃいけない時に、3チーム、4チームが同時に作ったやつをインテグレーションさせるんだったら、QAのほうで統合計画みたいなものを作って「じゃあ、こことこことここがつながったら、Aの環境のやつをBの環境に入れましょう」みたいなことを考えていくようなことを、すごく良いチームはやります。
要はみんなでというか、「開発しやすくする」ということをQAも一緒に考えるようになっていくと、本当にいい感じですよね。開発しやすいというのもあるけど、それがわかっていたほうがテストもしやすいんですよね。
中村：そうですね。結局、後ろのタイミングでQAが入ってしまう、入ってしまうというか関わり始めると、前のコンテキストやどんな前提だったかのキャッチアップも難しくなるし、難しくなると当然抜け漏れも発生して、「このテスト仕様はどうなんだろう」という無駄がけっこう発生すると思っています。
先ほども言ったように、「もっと前から入ったらええやん」と言った時に、「それは自分の仕事じゃないから」とか「ふだんのテストが忙しいから」と言って後回しにすると、もっと大きいツケを後で払うなと感じることはあります。
湯本：そうなんですよ。そうなんですけど、実際はどこからその壁を乗り越えるかみたいなのが（問題として）あります。新規のプロダクトはけっこうやりやすかったと思うんですよね。最初からどういうふうにやっていけばいいかの話もしやすいし、「こういうことをやろうと思っているんです」ということも、作るほうというか、チーム全体が新しいから「やってみようよ」となります。
freeeの良いところですよね。「やってみようよ」と言ったら「そうだね」みたいな感じにすぐになってくれるのはすごく良いところなので、新しいとやりやすいです。
しかし、やはりある程度できちゃっているところに新しい何かを入れるというのは……。みんなもちょっとビックリしちゃうし、その変化によってどれだけ遅れちゃうかみたいな、やりづらくなっちゃうことをどうしようみたいなことも考えないといけないので、ちょっと難しくなるのかなと思っていますね。
QAが後からチームに加わるのはもったいない
中村：それでいうと、私がfreeeさんの現場を見ている中で、チームの立ち上げから見ているチームは、今のところはまだないんですね。新規事業でもある程度できているチームを見ていることはあるんですけど。
それでいうと、QAの方はfreeeさんでは最初からチームに入っていますか？ それともわりとできてからちょっと関わることが多いですか？
湯本：わりと（プロダクトが）できてから関わることが多いです。
中村：そのあたりがもったいないかもしれませんよね。もっと早くから入って、例えばアジャイルでよく使うインセプションデッキみたいなやつと一緒に作って、「どんなコンセプトで、どんな品質を、どう高めたいねん」みたいな話をしていくことから入るのもいいかもしれないなと思いましたね。
湯本：そう。入れているところはそれこそインセプションデッキとかをみんなでやって、「じゃあどういうのを作りましょうか？」とかのユーザーストーリー（作り）にBizとかも入っていて、「何がMVPだ」みたいなことを決めるところからQAが入っていっているので。だから意見も言いやすいですよね。QAの人がどういう品質のものをお客さんに届けるべきなのかを自分で考えられるようになるので。
中村：そうですね。
湯本：言われたら咀嚼するんじゃなくて。
中村：先ほど「遠慮がある」と言ったことで今話しながら「そこもあるのかな？」と思ったのが、いわゆる心理的安全性の話になるのですが、「これは自分だけが知らへんのとちゃうかな？」といって聞けない怖さや、エンジニアの人やビジネスの人がプロダクトの方向性を知っていると思って、自分だけ知らへんかったら「ちょっと聞けへんな」と。
「なんでそんなもんも知らんの？」と言われたり、「その人たちの時間を奪うかもしれへん」みたいになってしまって、聞けずにちょっと遠慮しちゃうような側面もあるのかなとは思ったりしました。
湯本：QAがという意味で？
中村：そうそう。そうですね。最初から入ってへんゆえにね。
湯本：だからお互いに距離が遠いとそういうことが起きて。QAの人たちはそう思ってちょっと遠慮して「全部知らないし言いづらいな」となる一方で、開発のほうのプロダクトマネージャーも「そんな早い時から入ってきてもらっても申し訳ないよ」と。
中村：そうですね。「申し訳ない」という言葉を時々聞きますね。
湯本：だから「ある程度場が整ったら呼びますから、それまではいいです」みたいなことになるんですよね。それを打ち破る壁みたいなものが必要で、「場が整っていないところから出たいです！」みたいな感じでやらないと、次の第一歩に進まないということがあるんですよ。
中村：そうですね。確かにそれはありますね。場が整っていないところに出ても「自分は何の役に立つんやろう」みたいな、また別の怖さみたいなものもあるし。このあとちょっと出てくると思うんですけど、でもそんなのは自分が品質を作り込むとか担保する専門家としての観点としてしゃべれば良いと思っていて、貢献できると思っているんですよね。それを「テストできるものが出来上がってからやりますわ」では、やはり遅いとは思ったりします。
湯本：その場が整っていないところからみんなで物を作っているから、最終的に（テストが）できるわけですよね。
中村：そうですね。
湯本：それを「QAは場が整ってからでいい」というのは、もしQAの人が「場が整う前に行っても、どうせ自分はまだよくわからないからいいや」みたいな気持ちでいるんだったら、それは本当に良くないです。
中村：もったいないと思いますね。
湯本：同じチームに入るつもりがない行動になっちゃうんですね。
場作りに時間を割いたほうがいい
てらら：例えば、入りたいけど入れないQAの人がいた場合に、ちょっと後押しするような言葉とかがあれば。「こういうマインドでいけば入れる」とか、「インセプションデッキのこの分野はQAとして責任を持つべきだから、ガッといったほうがいいよ」とか、何かコメントはあります？ 「というよりかは『お前もチームの一員なんだ！』という気持ちを持ってほしいな」とか。
中村：そうですね。アンチパターンからいくと、例えば誰か1人の個人に「QA、お前はもっとがんばって入って来いよ！」と言うのは、それができたらみんなやっているはずなので、わりと難しい話やと思っています。どちらかというと、場や環境などの「そもそも俺たちのチームって、どんなことをするんだっけ？」という場作りに時間を割いたほうが、私はうまくいくんとちゃうかなとは思ったりします。人の個性を変えるのは難しいと思っているので。
てらら：湯本さんは、そのあたりはどうですか？
湯本：だから最初がいいんですよ。場を作りやすいから。
（一同笑）
中村：そうですね。みんなもたぶん経験があると思うのですが、学校で、友だち関係が出来上がってから転校生が入るのはめちゃくちゃしんどいじゃないですか。
湯本：そうそう！
中村：いろいろわからへんこともあるし。「そんなんも知らんの？」と内輪ネタをされるのもツラいみたいな。
湯本：僕は転校を4回ぐらいしているから、それはわかる。
中村：なるほど。
てらら：そうなんだ。
中村：という感じで、最初から作るほうが結果的にコスト（が少なくて済む）というか、スムーズに進むし、いろいろなものの関係性も出来上がるから、わりとやりやすいと思う。その文脈でいうと、人をバンバン入れ替え過ぎないというところもけっこうあるとちゃうんかなとは思っていますね。「このチームで勝ち抜くんや！」みたいなところはけっこういるかなと思いました。
湯本：そうですよね。それはQAだけじゃないですけどね。
中村：もちろん。
湯本：エンジニアもね。しょっちゅう入れ替えるのは良くないですよね。
中村：そうですね。
てらら：そんな感じでこのテーマは以上にしたいと思います。
（次回に続く）
