2024.12.10
“放置系”なのにサイバー攻撃を監視・検知、「統合ログ管理ツール」とは 最先端のログ管理体制を実現する方法
リンクをコピー
記事をブックマーク
てらら氏(以下、てらら):最初の「freee流アジャイルQAとは」は以上にして、次のテーマに行こうと思います。
次は「アジャイルコーチから見た、freeeの開発の特徴」というところで、アジャイルコーチの洋さんから物申す感じでお願いします。
中村洋氏(以下、中村):物申す感じ(笑)。freeeさんにはめちゃくちゃたくさんのプロダクトがあります。前提として、私が見ているのはたぶん3つか4つ、5ぐらいのチームです。なので、先ほど湯本さんが言ったように、私が見えている範囲がfreeeさんのすべてではないという前提で話すと、わりとどのチームも、エンジニアとQAという呼び名というかロールが、専門家として存在しているのは共通項です。
チームによってわりと濃淡があるのですが、エンジニアとQAが協働しようとしているところがあります。協働の度合いとか、矢印がけっこうチームによるなと思っていて。
壁越しに、できたから「よろしゅう」と投げていることはないにしても、「できたら教えてくださいね」という(感じで)ちょっと薄めなところもあれば、「何作るの?」とか「どんなテストをするの?」というところから入って、一緒にテストコードを書こうとしたりとか、そういうことをしている現場もあります。
そのあたりは、先ほど言ったように、プロダクトのフェーズやそのチームが持っているスキルセットによってけっこう変わっている印象はありますね。湯本さんは、そのあたりどうですか?
湯本剛氏(以下、湯本):本当に千差万別で、いろいろなフェーズがあるというか。なので、「freeeの開発の特徴」と一概にうまく言えないかなと思います。
中村:そうですね。私が見たあるチームでおもしろかったのは、とある現場でみんなで集まってコードを書いてミーティングをしている時に、「E2Eテストをどうしようか」みたいな話をしたわけですね。QAの人もエンジニアの人もいて「じゃあこのフレームワークを使ってやろうか」と言った時に、みんながそこでワチャワチャとモブでコードを書き始めたんですよ。
「こうやったら動くよ」と言って、「じゃあこういうテストはどうするの?」とQAの人が言って、「それはこういうふうにして、こういうメソッドを使えばいいよね」という話をして。その場でけっこう良い感じにエンジニアの人とQAの人それぞれの専門性を活かして物を作っていて、ああいう風景はすごくいいなと思いました。
湯本:それはすごくいい。そうなってくるとすごくいい。
中村:そういうチームが増えていったらいいなと思いますね。
てらら:ゆもつよさん的にはそういったところを目指していきたいみたいなところもあるんですかね。
湯本:それこそfreeeカード Unlimitedとか、大きいリリースをしなきゃいけない時に、3チーム、4チームが同時に作ったやつをインテグレーションさせるんだったら、QAのほうで統合計画みたいなものを作って「じゃあ、こことこことここがつながったら、Aの環境のやつをBの環境に入れましょう」みたいなことを考えていくようなことを、すごく良いチームはやります。
要はみんなでというか、「開発しやすくする」ということをQAも一緒に考えるようになっていくと、本当にいい感じですよね。開発しやすいというのもあるけど、それがわかっていたほうがテストもしやすいんですよね。
中村:そうですね。結局、後ろのタイミングでQAが入ってしまう、入ってしまうというか関わり始めると、前のコンテキストやどんな前提だったかのキャッチアップも難しくなるし、難しくなると当然抜け漏れも発生して、「このテスト仕様はどうなんだろう」という無駄がけっこう発生すると思っています。
先ほども言ったように、「もっと前から入ったらええやん」と言った時に、「それは自分の仕事じゃないから」とか「ふだんのテストが忙しいから」と言って後回しにすると、もっと大きいツケを後で払うなと感じることはあります。
湯本:そうなんですよ。そうなんですけど、実際はどこからその壁を乗り越えるかみたいなのが(問題として)あります。新規のプロダクトはけっこうやりやすかったと思うんですよね。最初からどういうふうにやっていけばいいかの話もしやすいし、「こういうことをやろうと思っているんです」ということも、作るほうというか、チーム全体が新しいから「やってみようよ」となります。
freeeの良いところですよね。「やってみようよ」と言ったら「そうだね」みたいな感じにすぐになってくれるのはすごく良いところなので、新しいとやりやすいです。
しかし、やはりある程度できちゃっているところに新しい何かを入れるというのは……。みんなもちょっとビックリしちゃうし、その変化によってどれだけ遅れちゃうかみたいな、やりづらくなっちゃうことをどうしようみたいなことも考えないといけないので、ちょっと難しくなるのかなと思っていますね。
中村:それでいうと、私がfreeeさんの現場を見ている中で、チームの立ち上げから見ているチームは、今のところはまだないんですね。新規事業でもある程度できているチームを見ていることはあるんですけど。
それでいうと、QAの方はfreeeさんでは最初からチームに入っていますか? それともわりとできてからちょっと関わることが多いですか?
湯本:わりと(プロダクトが)できてから関わることが多いです。
中村:そのあたりがもったいないかもしれませんよね。もっと早くから入って、例えばアジャイルでよく使うインセプションデッキみたいなやつと一緒に作って、「どんなコンセプトで、どんな品質を、どう高めたいねん」みたいな話をしていくことから入るのもいいかもしれないなと思いましたね。
湯本:そう。入れているところはそれこそインセプションデッキとかをみんなでやって、「じゃあどういうのを作りましょうか?」とかのユーザーストーリー(作り)にBizとかも入っていて、「何がMVPだ」みたいなことを決めるところからQAが入っていっているので。だから意見も言いやすいですよね。QAの人がどういう品質のものをお客さんに届けるべきなのかを自分で考えられるようになるので。
中村:そうですね。
湯本:言われたら咀嚼するんじゃなくて。
中村:先ほど「遠慮がある」と言ったことで今話しながら「そこもあるのかな?」と思ったのが、いわゆる心理的安全性の話になるのですが、「これは自分だけが知らへんのとちゃうかな?」といって聞けない怖さや、エンジニアの人やビジネスの人がプロダクトの方向性を知っていると思って、自分だけ知らへんかったら「ちょっと聞けへんな」と。
「なんでそんなもんも知らんの?」と言われたり、「その人たちの時間を奪うかもしれへん」みたいになってしまって、聞けずにちょっと遠慮しちゃうような側面もあるのかなとは思ったりしました。
湯本:QAがという意味で?
中村:そうそう。そうですね。最初から入ってへんゆえにね。
湯本:だからお互いに距離が遠いとそういうことが起きて。QAの人たちはそう思ってちょっと遠慮して「全部知らないし言いづらいな」となる一方で、開発のほうのプロダクトマネージャーも「そんな早い時から入ってきてもらっても申し訳ないよ」と。
中村:そうですね。「申し訳ない」という言葉を時々聞きますね。
湯本:だから「ある程度場が整ったら呼びますから、それまではいいです」みたいなことになるんですよね。それを打ち破る壁みたいなものが必要で、「場が整っていないところから出たいです!」みたいな感じでやらないと、次の第一歩に進まないということがあるんですよ。
中村:そうですね。確かにそれはありますね。場が整っていないところに出ても「自分は何の役に立つんやろう」みたいな、また別の怖さみたいなものもあるし。このあとちょっと出てくると思うんですけど、でもそんなのは自分が品質を作り込むとか担保する専門家としての観点としてしゃべれば良いと思っていて、貢献できると思っているんですよね。それを「テストできるものが出来上がってからやりますわ」では、やはり遅いとは思ったりします。
湯本:その場が整っていないところからみんなで物を作っているから、最終的に(テストが)できるわけですよね。
中村:そうですね。
湯本:それを「QAは場が整ってからでいい」というのは、もしQAの人が「場が整う前に行っても、どうせ自分はまだよくわからないからいいや」みたいな気持ちでいるんだったら、それは本当に良くないです。
中村:もったいないと思いますね。
湯本:同じチームに入るつもりがない行動になっちゃうんですね。
てらら:例えば、入りたいけど入れないQAの人がいた場合に、ちょっと後押しするような言葉とかがあれば。「こういうマインドでいけば入れる」とか、「インセプションデッキのこの分野はQAとして責任を持つべきだから、ガッといったほうがいいよ」とか、何かコメントはあります? 「というよりかは『お前もチームの一員なんだ!』という気持ちを持ってほしいな」とか。
中村:そうですね。アンチパターンからいくと、例えば誰か1人の個人に「QA、お前はもっとがんばって入って来いよ!」と言うのは、それができたらみんなやっているはずなので、わりと難しい話やと思っています。どちらかというと、場や環境などの「そもそも俺たちのチームって、どんなことをするんだっけ?」という場作りに時間を割いたほうが、私はうまくいくんとちゃうかなとは思ったりします。人の個性を変えるのは難しいと思っているので。
てらら:湯本さんは、そのあたりはどうですか?
湯本:だから最初がいいんですよ。場を作りやすいから。
(一同笑)
中村:そうですね。みんなもたぶん経験があると思うのですが、学校で、友だち関係が出来上がってから転校生が入るのはめちゃくちゃしんどいじゃないですか。
湯本:そうそう!
中村:いろいろわからへんこともあるし。「そんなんも知らんの?」と内輪ネタをされるのもツラいみたいな。
湯本:僕は転校を4回ぐらいしているから、それはわかる。
中村:なるほど。
てらら:そうなんだ。
中村:という感じで、最初から作るほうが結果的にコスト(が少なくて済む)というか、スムーズに進むし、いろいろなものの関係性も出来上がるから、わりとやりやすいと思う。その文脈でいうと、人をバンバン入れ替え過ぎないというところもけっこうあるとちゃうんかなとは思っていますね。「このチームで勝ち抜くんや!」みたいなところはけっこういるかなと思いました。
湯本:そうですよね。それはQAだけじゃないですけどね。
中村:もちろん。
湯本:エンジニアもね。しょっちゅう入れ替えるのは良くないですよね。
中村:そうですね。
てらら:そんな感じでこのテーマは以上にしたいと思います。
(次回に続く)
関連タグ:
2024.12.10
メールのラリー回数でわかる「評価されない人」の特徴 職場での評価を下げる行動5選
2024.12.09
10点満点中7点の部下に言うべきこと 部下を育成できない上司の特徴トップ5
2024.12.09
国内の有名ホテルでは、マグロ丼がなんと1杯「24,000円」 「良いものをより安く」を追いすぎた日本にとって値上げが重要な理由
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.12.10
職場であえて「不機嫌」を出したほうがいいタイプ NOと言えない人のための人間関係をラクにするヒント
2024.12.12
会議で発言しやすくなる「心理的安全性」を高めるには ファシリテーションがうまい人の3つの条件
2024.12.06
嫌いな相手の行動が気になって仕方ない… 臨床心理士が教える、人間関係のストレスを軽くする知恵
PR | 2024.11.26
なぜ電話営業はなくならない?その要因は「属人化」 通話内容をデータ化するZoomのクラウドサービス活用術
2024.12.11
大企業への転職前に感じた、「なんか違うかも」の違和感の正体 「親が喜ぶ」「モテそう」ではない、自分の判断基準を持つカギ
PR | 2024.11.22
「闇雲なAI導入」から脱却せよ Zoom・パーソル・THE GUILD幹部が語る、従業員と顧客体験を高めるAI戦略の要諦