2024.12.19
システムの穴を運用でカバーしようとしてミス多発… バグが大量発生、決算が合わない状態から業務効率化を実現するまで
リンクをコピー
記事をブックマーク
てらら氏(以下、てらら):最後が「freeeの伸びしろ」をテーマに話をしてもらえればと思います。
中村洋氏(以下、中村):難しい。
てらら:では、洋さんからお願いします。
中村:そうですね。伸びしろというとちょっと上からになるんですけど。(私が)見ているチームは、うまくやれるところもけっこう増えてきていると感じています。でも、やはりまだまだ「エンジニアさん」とか、「QAさん」とか、冒頭で話したような遠慮とか、「自分が言っていいんだろうか」とかはけっこうあると思っています。
そのために、一人ひとりのエンジニアリングを伸ばすための学びの時間を取るのも必要だし、途中で言ったような、チーム雰囲気を作るために時間を使うとか、お互いのことを知るようなこともけっこう必要かなと思っています。
QAの人は、先ほども湯本さんが言ったように、バグをゼロにするということに情熱を出す人がいて、それはそれでいいんですけど、プロダクトやユーザーのことをもっと知ればもっといいのになと思っています。うまくやっているチームは、みんなで一緒にユーザーのところに見に行っているんですね。
例えば、プロダクトマネージャーとかプロダクトオーナーだけが行っているとか、プロダクトデザイナーだけが行っているとかじゃなくて、みんなで見に行って「あ、こういうふうにしているんや」みたいなことをけっこうやっていると思います。
なので、そのあたりが伸びしろかなと思ったりもするし、チームといった時に、QAの人だけが外れているようなことが無くなっていくと、もっといい安定したチームが増えていくんとちゃうかなと感じています。
湯本剛氏(以下、湯本):だから、例えばユーザーテストでデザイナーとPMだけじゃなくて、QAの人もシャドウでいいから行かせてもらうとかね。
中村:そうそう。実際にうまくやっているところのスプリントレビューは、一応そのプロダクトマネージャー、プロダクトオーナー、あとはプロダクトデザイナーが進行しているんですね。お客さんにオンラインで入ってきてもらって、「あなたには〇〇という状況があります」「それでこういう仕分けを起こしてほしいです」と言ってシナリオを渡して、「じゃあやってみてください!」と言って、新しい機能をテストしてもらうわけですね。
いわゆるYouTubeの実況動画のように、頭に浮かんだことをしゃべるのを見てもらっています。その時はチーム全員、エンジニアだけじゃなくてQAもみんな入って、カメラはオフにしていますが眺めて、「あ、ここは気づかへんのか」とか「こういうことを思うんやな」みたいなことをやります。
そのあとで「このプロダクトを次にどう進化させるとユーザーにとってわかりやすいんやろうね」とか「使ってくれるんやろうね」という話をみんなでやっていますね。
湯本:一応、経理の人が使うプロダクトなので、freeeの経理部の人に使ってもらって、(使いづらければ)「使いづらい」と正直に言ってもらっています。けっこうボロクソに言われたりしていますね。
中村:いいですね。
湯本:だけどそういうのも大事ですよね。
中村:そういうところがたぶん伸びしろだなと思っています。先ほども言ったように、「自分はテストをするだけだから」とか、別の役割の人が「最初から巻き込むのはもったいないから」と言うと、たぶん一見効率的には見えるけど、効果の高いプロダクトは作りづらいんちゃうかなとは私は信じているんですね。そのあたりが伸びしろかなと思いますね。
てらら:なるほど。 ゆもつよさんがそれをやっていく? みんなでやっていく?
湯本:俺?
(一同笑)
中村:ゆもつよさんにやってほしいんですけどね(笑)。あとは若手の方にね。
湯本:そう。若い人がやってほしい。今日来ているQAエンジニアの若い人にやってもらいたい。
てらら:そういう意味だと、ゆもつよさんからQAエンジニアに向けて、あらためて「こういうQAエンジニアというかエンジニアを目指してほしい」みたいな話はありますか?
湯本:同じことを言っている老人みたいになっちゃって。
(一同笑)
だいたい一緒になっちゃうんですけど(笑)。とにかく自分で考えるということですよね。自分で考えて、考えるためにはちゃんと知らないといけないので、ユーザーのことを知るとか、チームのことを知ることは必要だし、考えて自分がどうあるべきか。
特に品質のところが自分の専門なら、「このレベルのものをお客さんのところに出していいのか悪いのか」という自分なりの意見(を言えるようになる)。「自分なりの」といってもあまり“俺俺”じゃまずいので、ハッピーの重篤度をちゃんと……。ハッピーはバグのことですね。
中村:もう(説明しなくても)いいと思いますけどね(笑)。
湯本:ハッピーの重篤度をプロダクトごとに全部定義して、あまり独りよがりにならないようにしています。そういうのを基にチームに対して(意見を)言えるようになってほしいです。
中村:ちょっとごめんなさい、いいですか?
てらら:大丈夫ですよ!
中村:今日の“アジャイルQA”は、“アジャイルQA”という1つの名称の話でもあるし、ある意味エンジニアとQAと一緒にやっていくという話なんです。先ほども言ったように「違うよね」という前提を持っていない人がけっこういて、違った意見に対して「なんでそうじゃないの?」という聞き方をする人がわりといるんですよね。
「だって専門性が違うんだから(意見が)違って当たり前やん」という話です。違って当たり前だし、違っているからこそ変な片方の視点で終わらないという話があります。だから違うことを責めるような言い方をしないで、むしろ違う意見が出てきて良かったと思えるような関係が作れると良いなと思います。それはQAだけじゃなくてみんなですけど。
湯本:そうですね。言うほうも、「なぜそうなのか」というところを真摯な気持ちでちゃんとしゃべらなきゃいけないし、そういうことに対して聞いてくれるようなチームを作っていくということ。これはQAだけじゃなくて全部そうです。エンジニア同士とかでも十分言えることかなと思いますよね。
中村:そうですよね。そういうことを言いたかったです。
てらら:ありがとうございます。いい話でした。
てらら:もう少し時間がありますが、他に何か話したいことはありますか?(笑) (バグの)重篤度の話はしましたっけ? ゆもつよさんのこだわりがある。
湯本:ゆもつよさんこわだりの重篤(笑)。重篤度をちゃんと定義しましょうということを全社的に、それこそ標準化じゃないですが、やっています。標準化は間違えるとすごく良くないんだけど、それを合わせないといけないところを合わせるというのはめちゃくちゃ実は重要なことで、(そういう意味での)標準化は良いと僕は思っているんですね。
そこを間違えちゃいけないんだけど、特にバグの重篤度、ハッピー……。バグと、ハッピーとどちらで言ったほうがいいかわからなくなっちゃった(笑)。
中村:「バグ」でいいんじゃないですか?(笑)
湯本:バグの重篤度を今は決めています。何が本当にやばいのか、何がやばくないのかを決めるのは当たり前なんですが、それをプロダクトごとにやってほしいというのもまたポイントです。
中村:そうですね。
湯本:アプリというか、「freee会計」というプロダクトの中でも、ワークフローをやっているところとか、会計帳簿を作るところはぜんぜん違うんですよね。だからそれぞれの重篤度が必要で、基盤だったら基盤の重篤度とか、カードだったらカードの重篤度みたいな話でやっていくのが大事です。
それもQAがリードするというか、品質のことだから「そういうのをやろうよ」と言ってリードするのがいいけれど、みんなで決めることがまたすごく重要です。
みんなで決めることによって、エンジニアもプロダクトマネージャーもデザイナーも、みんなどういうものがやばいのかという目線合わせができるんですよね。なのでそういうことを推してやっています。
中村:なるほど。いいですね。結局「バグの数が何件か」とか「バグ率がどうか」というのはデータとしてはいいけれど、結果としてユーザーがどんなふうに困るのかとか、どれぐらいの人が何ができなくなるのかをちゃんと解像度をあげていかないと、「何でも直す」というほうになっていって、いけないと思います。
プロダクトも進化していく上で、やばいポイントが変わると思うんです。そんなに頻繁には変わらないですよ? そんなに頻繁には変わらないけど、プロダクトの状態によって、前はここやったけどそれでもやばい体験が届けられて、結果的にここが死んでもっとやばいことになるんやったら、こちら側に力をかけるみたいな。そういう観点も必要かなと思ったりしますね。
湯本:そうですね。データを取らないのは良くないと思いますが、そのデータの数字だけで判断するのも良くなくて。その中身まで入っていかなきゃ実際は何もわからないというのはあります。それをわかりやすくというか、みんなで共通の目線にするのが重篤度でやっています。
中村:いいですね。
湯本:これも2020年ぐらいに1回、重篤度の定義をやったんですけど、3年も経つと……。
中村:変わりますもんね。
湯本:プロダクトも変わるし、人も変わるし、いろいろ変わって、なんなら「知りません」という人もどんどん増えてきちゃって、「またやらなきゃ」ということでやっています。
中村:なるほど。そんな感じですか?
てらら:ありがとうございます。ということでお別れの時間となってしまいました。次回以降もここばなを企画しているので、ぜひご期待ください。
最後にライブ配信がおもしろかったと思う方は、ぜひチャンネル登録とグッドボタンをお願いします。それでは今回の配信は終了です。ありがとうございました! まったねー!
(会場拍手)
関連タグ:
2024.12.20
日本の約10倍がん患者が殺到し、病院はキャパオーバー ジャパンハートが描く医療の未来と、カンボジアに新病院を作る理由
2024.12.19
12万通りの「資格の組み合わせ」の中で厳選された60の項目 532の資格を持つ林雄次氏の新刊『資格のかけ算』の見所
2024.12.16
32歳で成績最下位から1年でトップ営業になれた理由 売るテクニックよりも大事な「あり方」
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
PR | 2024.12.20
モンスター化したExcelが、ある日突然崩壊 昭和のガス工事会社を生まれ変わらせた、起死回生のノーコード活用術
2024.12.12
会議で発言しやすくなる「心理的安全性」を高めるには ファシリテーションがうまい人の3つの条件
2024.12.18
「社長以外みんな儲かる給与設計」にした理由 経営者たちが語る、優秀な人材集め・会社を発展させるためのヒント
2024.12.17
面接で「後輩を指導できなさそう」と思われる人の伝え方 歳を重ねるほど重視される経験の「ノウハウ化」
2024.12.13
ファシリテーターは「しゃべらないほうがいい」理由 入山章栄氏が語る、心理的安全性の高い場を作るポイント
2024.12.10
メールのラリー回数でわかる「評価されない人」の特徴 職場での評価を下げる行動5選
Climbers Startup JAPAN EXPO 2024 - 秋 -
2024.11.20 - 2024.11.21
『主体的なキャリア形成』を考える~資格のかけ算について〜
2024.12.07 - 2024.12.07
Startup CTO of the year 2024
2024.11.19 - 2024.11.19
社員の力を引き出す経営戦略〜ひとり一人が自ら成長する組織づくり〜
2024.11.20 - 2024.11.20
「確率思考」で未来を見通す 事業を成功に導く意思決定 ~エビデンス・ベースド・マーケティング思考の調査分析で事業に有効な予測手法とは~
2024.11.05 - 2024.11.05