00:00
皆さん、こんにちは。株式会社10X品質管理部のブロッコリーです。
この10X.fmは、10Xを作る大ミッションに、小売りチェーン向けECプラットフォームStaylerを提供している株式会社10Xのメンバーが、キャリアや日々の出来事、学び、プロダクトに対する思いを包み隠さずリアルにお届けしていくポッドキャスト番組です。
今回は、私、ブロッコリーがホストとなり、他社の方をゲストに招いて、QAについて語っていく企画、QA部屋をお届けします。
ということで、今回のQA部屋のゲストは、株式会社ナレッジワークでQAエンジニアを担当されている河野哲也さんです。河野さん、よろしくお願いします。
はい、よろしくお願いします。
河野哲也さんのプロフィール
それでは、まず河野さんのプロフィールについて紹介いたします。
河野哲也さん。
1976年、福岡県大阪市に住んでいます。
2011年、福岡県大川市生まれ。工業高校卒業後、日本無線に入社。ハードウェアの品質管理に従事する。
その後、電気通信大学夜間試行室に入学。ソフトウェア品質保証テストを専門とし、博士課程まで進学する。
博士号取得後、2011年、日立製作所に入社し、ソフトウェアのQAエンジニアのキャリアをスタートさせる。
2017年、DNA。
2021年、メルカリ。
2023年、ナレッジワークに入社。
すべてQAエンジニアとして従事する。
工学博士ですね。
はい、それでは河野さん、改めてよろしくお願いします。
はい、よろしくお願いします。ナレッジワークの河野です。
はい。
このプロフィールとか、もともとの河野さんの印象を踏まえて、今回ここは話したいと思っていたところがいくつかあります。
今回、河野さんにお声がけした理由としては、
結構、一度就職した後に大学入学して、そこから日立製作所、そしてウェブ業界、結構転職とか最近されていたっていう、その経緯とかがすごいユニークだなと思っていて、お声がけしたのと、
あとは、経歴には詳しくはあんまり書かれてなかったんですけれども、結構テスト設計についても聞いてみたいなと思って、お声がけしました。
はい。
ということで、
最近の話からちょっと、
はい。
ナレッジワークでの役割
深掘っていきたいなと思うんですけれども、まず今、所属しているナレッジワークさんって、具体的にどういうことをされたりしていますか?
そうですね。
ナレッジワークだと、一応、タイトルとしてはQAエンジニアとして従事しているんですけど、主に大きく2種類の役割で働いています。
まず1つ目が、スクラムの中で、1、QAエンジニアとして働いているので、そこはテスト設計とかテスト実行。
はい。
一通りのQAエンジニアとしての業務をやっているところですね。
もう1つ目が、QAグループのチームの基盤を作るとか、そのチームとして推進するような役回りで、具体的に言うと、中長期ビジョンを少し考えましょうみたいなところの旗振りをやったりとか、あとは弊社のイネーブルメントっていうところを謳っていますので、QAエンジニアをどうイネーブルメントするのかっていうところで、キャリアのラダーを作るとか、そういったものを作っています。
はい。
ありがとうございます。
ありがとうございます。
ありがとうございます。
キャリアのラダーを作るとか、スキルの棚下ろしをするとか、そういったところの旗振りをしているっていうところが、主な役回りで動いています。
なるほど。
今、2つ目のほうでおっしゃっていた、中長期的な戦略っていうのは、QAに関する部分ですか、それともQAも含めた開発とか全体の話なんですかね。
主にQAグループで、中長期、分かりやすく言うと3年後どういう状況になるんですかね。
3年後どういうチームでありたいかみたいな、どういう価値観で仕事をしていたいかみたいなところを、今のメンバーで整理をしていて、ただ、今も採用続けてますので、これからメンバー増えていく中で、そういったところをブラッシュアップをしていきたいなと思うんですけど、なんか道しるべみたいなのがないと、みんなの意識が散漫となるみたいなことも起こりやすいので、そういったところをみんな一緒の方向見てやりましょう的なところをちょっと進めています。
QAのキャリアについて
その中で先ほどキャリアラーダーっていう話もありましたけども、結構QAのキャリアっていうと、なかなかモデルケースがそんな多くないかなと思ってるんですけど、その中で考えて、言える部分とか言えない部分もあるかもしれないですけど、QAのキャリアってどう組み立てていくのかなっていうのは、自分も今興味が聞いてて興味湧いたんですけれども、
どういうふうにキャリアって作っていっている、今考えているのってあったりします?
悩ましいですね。悩ましいんですけど、一つはQAのマネージャーとQAエンジニアみたいな大きな役回りを一応決めています。
ただ細かいキャリアというか、どちらかといったらスキルって言った方がいいかもしれないんですけど、我々今大きく3つの柱を立てていて、ただこれ全然僕勝手に決めてる部分も多いので、
3つの柱で、1つがQAのエンジニアリングとしてのスキル。1、QAエンジニアとして、要はチームの中に入って、そういうQAの業務をどうこなすかっていうスキルですね。
もう1個が品質マネジメント。どちらかといったら、チームの中というよりは全体を見ながら品質メトリックスをどう取るのかとか、品質を保証するための仕組みをどう作るのかっていうところの旗振りができるとか、
どちらかといったら上流に入っていくようなアプローチに近くなると思うんですけど、その品質マネジメントのスキル。最後がテストオートメーション。いわゆるE2Eをどう書くか。もう少し踏み込んでいくと、CIとかCDのところにどう貢献できるかとか。
一方でプロダクト側のAPIのテストとかユニットテストとかにQAエンジニアが入り込むっていうのも面白そうだなっていうところで、そういったところのストレッチするスキルだと思うんですけど、
そういったスキルも将来的にあるだろうっていうふうな見通しでやってます。
今のお話聞いてると、例えば別のところの話で言うと、QMファンネルとかっていうふうに言って、テストエンジニアリング、QA、あとはセット。QMファンネルの中でパイプラインエンジニアみたいな言い方をしていますけれども、
それとも近いようなお話?
聞こえたんですけれども、どうですかね?近いのか?それともそれとはまたちょっと違う概念なのか?
正直QMファンネルっていうのは参照してないんでよく分かんないんですけど。
なるほど。
ただ、近いのは近いのかもしれないですけど、ただ品質マネジメントみたいな文脈はあんまりないんですかね?QMファンネル。
そうですね。QMファンネルの場合はどっちかっていうと、パイプラインエンジニアは今お話の中のテスト自動化とかCI、
CD、APIの部分に近くて、それとは別にあるのがQAとTE、テストエンジニアリングって呼んでいる部分で、
それの多分QAっていうふうにQMファンネルの中で呼んでいる部分が、
この中で言うと、Qエンジニアリングスキルと品質マネジメントの両方が入っているように聞こえました。
ちょっと違う感じですかね?
そうですね。僕の感覚としては、
テストエンジニアリングと、
クオリティ・アシャーランス・エンジニアリングを分けるのってあんまり良くない気がしていて、
一体となった方がいいと思うんですよね。
なのでそこはあんまり分けてなくて、QAエンジニアリングの中にテスティングが入っている。
ただそのQAエンジニアリングと品質マネジメントはちょっと分けた方がいいと思っていて。
なのでそういうタッチ位置。もちろん全然明確に切り分けができるとは思ってないです。
ただスキルの強弱って言ったら、品質マネジメントよりに強くなっている。
っていうスキルの持ち方もあるし、品質マネジメントはあんまり興味がないとか弱いとかいう立場でQAエンジニアリングが強いよね、みたいな見え方とかもあると思うので。
そこはあんまり切り分けというか、お互い親和性はあるんだけど、多分QMパネルから言うとそういう違いがあるかなっていうのは今聞いた感じだと。
自分の中の理解ですね。
なるほど。結構自分がコンノさんのお話聞いてて、
逆にQAエンジニアリングとやっぱり品質マネジメントは結構近い領域だとは思っているので、そこを分けて表現するというか、完全に分かれるわけではないにしても、そうやって分けて考えているっていうのがすごい興味深いなと聞いてて思いました。
なるほど。
ちなみにあともう一つ、先ほど二つの動き方っていう話で、後者の方、中長期的な戦略とかキャリアラダーの話聞きましたけれども。
それをやると、
それをやりつつも、スクラムであったりとか、そういうような開発チームに入ってQAをするっていうのって、同時進行でやると難しかったりしません?
なんか工数が取れないとか、そういう悩みってなかったりするんですか?
さすが鋭いですね。
逆に言うと、そこの、要は現場の仕事がやっぱり忙しすぎて、あんまり時間やっぱり取れないんですよね。
なので、やっぱりちょっと空き時間でやるみたいな、どうしても後ろ回しになる。
で、なりやすいっていうのはおっしゃる通りで、あと僕、採用も関与してるので、
現場の、要はスクラムの中でテストとかQAこなすっていうところと、採用っていうところがもうプライオリティ高く動いてるので、
おっしゃるように、だいぶ後回しになってるのは現実的なとこですね。
なので、多分私の同僚とか全然やってないでしょって言われたら反論ができない状況です。
なるほど。
先ほどおっしゃってた中だと、テスト設計とかだけではなくて、テスト実行までやられてるってなると、結構工数負荷はありそうだなって思ったのと、
あとはやっぱり自分も採用もやりつつやってるので、似たような境遇なので、やっぱりそこは大変なんだろうなって思いながらちょっと聞いてました。
なるほど。
そうですね。
ちなみに、ちょっとナレッジワークさんという、今いる所属のところのお話聞きましたけれども、
ちょっと前に戻ると、2021年がメルカリに転職されて、さらにその前が2017年がDNAに転職されているっていう、
3つともウェブ業界と言いますか、そういう似たような業界ではあるんですけれども、
そこの3社って会社ごとの、実はQAの動き方の違いとか、もちろん今はメルカリさん、DNAさん、また違ってたりするかもしれないですけれども、
コーノさんが所属していた頃の、
DNAさん、メルカリさんと今のナレッジワークさんで、コーノさんの動き方であったりとか、QAチームの動き方だったりとかで、何か違ってあったりするんですか?
思いっきり違いますね、3つとも。
DNAだとどちらかと言ったら、プレイングマネージャー的に動いてる段階はあったんですけど、やっぱりその時も自分で手を動かすというよりはメンバーを巻き込みながら、
どちらかと言ったらドキュメントのレビューをするとか、テストケースのレビューをするとか、
そういった立ち位置の方が多かったので、実際に自分で手を動かしてテスト実行までやるっていうのはあんまりやってなかったんですよね。
なので、QAエンジニアと言っているんですけど、QAマネージャー的な立場で仕事をするみたいな役割もあったので、
その辺の行き来をしているっていうのがDNA時代ですね。
メルカリはどちらかと言ったら、QAエンジニアとして業務に携わることが多かったので、
そのエピック1個持って、設計から実行まで、
やるみたいなのもありましたし、メルカリ上位してすぐだと新規プロダクトの立ち上げから入ったのが1つありまして、
それだとQAエンジニアとして1人目で入って、そのQAがうまくサイクルが回るように仕組みを作っていくみたいなのをやってたので、
そうなると若干ナレッジワークで今やってるのにちょっと近くなってきて、
仕組みをうまく回すみたいなところは今ナレッジワーク、本当に100人以下のスタートアップなので、
そういった役割で動くことはあるんですけど、
ただスクラッチから作ったわけじゃないので、
ナレッジワークだと今動いてる中で改善をする仕組みを作っていくみたいな役割なので、
キャリアの違い
どちらかといったら動いてるところで入っていくみたいな役割で今仕事してるので、
近いとは近いって言えば近いんですけど、
フェーズ的な開発のフェーズ的には若干違いがあるっていう感じですね。
ちなみにその前、さらに1つ、
前でいくと日立製作所さんに2011年ですか、
入社して2011年から17年だから大体6年間ぐらいやられていたってことですけど、
日立製作所さんってどっちかっていうとウェブなのか、
会社の中でもいろいろとやっているプロダクトによっては違うと思うんですけれども、
少しその後に転職された3社とも経路が違う部分ってあるのかなと思うんですけれども、
違いってあったりしますかね。
いや、経路はもうほぼ真逆ですよ。
真逆というか会社の風土としては真逆ですよね。
ただ触っているプロダクトって言ったら、
当時ストレージ管理ソフトウェアのプロダクトの旧エンジニアで働いていたので、
そうなった時には一応ブラウザベースでプロダクト触るような役割で動いていたので、
そんなに遠いわけではないんですけど、
ただ対象がミドルウェアだったので、
サーバーを自分で立てて、そこにインストールして、
そこからテスト環境を作るみたいなところをベタなところをやっていたので、
そういったところの違いは若干あったっていうのか、
プロダクトとしての違いですかね。
あと社風はもうほぼ真逆ですよね。
そこはもう真逆です。
そこの違いですね。
その社風の真逆っていうのがどう真逆なのかが、
自分がそこまで分かってないんですけど、
あんまり変なこと言えないですもんね、この話も。
言える範囲でお願いします。
仕事っていうのをDNAに入ってから気づいたのは、
仕事って自分で探すんだなみたいな。
仕事って与えられるものじゃなくて、
自分で見つけて、自分でその仕事を持って、
見つめるみたいなやり方をしなきゃいけないんだなっていうので、
日立製作所の場合はどちらかというと仕事って与えられるみたいな状況が多かったので、
そこの違いは大きいですよね。
なので上から落ちてきたものを捌くみたいな部分もあるんですけど、
DNA以降はどちらかといったら上からというよりは自分の周りにあるのとか、
隣にある仕事を探ってくるみたいな感じの違いが大きな違いですね。
なるほど。
実際、そうですよね。
日立製作所さん、DNAさん、メルカリさん、ナレッジワークさんだと、
社員数でいうとどんどんどんどん少なくなってる。
ちょっとDNAとメルカリがどっちがどっちだか、
間違いですよ。
ちゃんと覚えてないですけど、
基本的にどんどん少ないところに転職していってるなっていう印象はあって、
そこのどう自分でというか課題をどう拾ってくるか、
もしくは与えられるかとかっていうのは確かに、
聞いて、ああ、なるほどなと思いました。
うん。
なるほど。
ちなみに、そういういろいろな違いはあるにしても、
逆にその日立製作所さんも含めて共通して、
なんかこれって考え方としてすごい大事だよねとか、
どこでも重要だよねって思えるようなことなんかあったりしますか?
そういう意味だと、やっぱりQAエンジニアとして働くみたいな、
その教授というか価値観みたいなところは、
会社というか、多分僕がそういうのを持ってるっていうのが共通してるのかもしれないんですけど、
やっぱり日立製作所でQAエンジニアとしてのキャリアも、ある意味ソフトウェアの領域だとそこから僕はキャリアスタートしてるので、
そこでいろいろQAエンジニアとして学んだことは多いし、
それかやっぱりDNAでもメルカリでも現職でも役に立ってるので、
そこはやっぱり共通して、QAエンジニアとして基礎的なところはそこで、
身についているので、そこはどこに行ってもあんまり変わらないなっていうところは、
逆にそれは日立製作所でいろいろ学んだっていうのが、すごく僕としてはありがたい感じなんですけど、
それはどこでも役に立つなっていうところはありますね。
QAエンジニアとしての共通点
なるほど。自分も複数回転職した身なので、ある程度共感できる部分があるというか、
特に1社目で入って学んで、転職がまだ、
転職してなかったりすると、果たしてそこで学んでいることが、
例えば自分だったらQAとして、
QAとして汎用的なスキルの話なのか、
それともその会社特有だからこそのスキルの話なのかっていうのが、
最初1社目で入っただけだと、違いが見えなかったりするものが、
自分個人的には転職して2社目3社目っていったときに、
これって結構どこでも使える大事な基礎的な部分なんだなっていうのと、
これは結構会社独自なんだなっていうのが、
すごい転職して分かったところとか、個人的にはあるんですけど、
やっぱり本野さんもそういうところはある感じですかね。
そうですね。ただ、ひたち製作者はどちらかといったら、
ソフトウェアの品質保証の、結構歴史を作った部署にいたので、
ある意味教科書的なところは、
業務で経験できてたんですよね。
そうなったときに、DNAメルカリってなると、
若干その教科書的に外れた言葉を使ってたりとか、
ちょっと方言があったりっていうのは感じるところはあったので、
逆に僕は1社目でそういうところに入ったっていうのは、
すごく良かったなとは今もずっと思ってますね。
なので、ブロッコリーさんが言うように、
いくつかの会社経験すると、
共通的に必要な技術であったりとか、
用語の定義であったりとか、
そういったところは共通化されるのでいいなっていうところは、
もちろんあると思うし、
やっぱりもう一つは、
僕は人質製作所のときから社外に出たのがやっぱり大きかったですよね。
社外に出てると、
大体社外の人たちと話をしてて、
通じるかどうかが多分なんですよ。
そのときに話が通じてたので、
他の会社に行っても、
それなりに話ができる人なんだなみたいなのは、
自分の中で理解できる、
テスト設計へのこだわり
そういうのができたのでそれは大きかったですよね。
確かにそこは自分もありますね。
社外に出て、
これって他の会社であったりとか、
他の人には通じないなっていうところも、
見えてきたのは確かにあります。
なので社外に出るのは結構僕はお勧めしてるんですよね。
ちなみに河野さんの社外に出るっていうところで言うと、
すごい、
河野さんのイメージとして強いのが二つあって、
一つが、
今はもうされてない気がしますけど、
Skipシンポジウムで、
あれは実行委員の一人っていう。
委員ですね。
実行委員ですね。
実行委員の一人としてなられていたのと、
二つ言いましたが三つですね。
Skipシンポジウムの実行委員と、
あとは若手も実行委員されていたのと、
あとはテスト設計コンテストで出場されていたのと、
あとはテスト設計コンテストで出場されていたのと、
あとはテスト設計コンテストで出場されていたのと、
3つが自分の中では印象深いなと思うんですけれども、
その3つとかですかね。
それとも他にも、
これ結構社外で出てよかったとかってあったりするんですか。
これ結構社外で出てよかったとかってあったりするんですか。
これ結構社外で出てよかったとかってあったりするんですか。
そうですね。
確かに、その3つかな。
あとはソフトウェアシンポジウムの委員とか、
委員っていうかあれですね。
どちらかと言ったら、
プログラム委員の方にはずっと関わってるので、
そこももう一つかなって感じですかね。
そうすると特に今出ていたような実行委員とか
あとはテスト設計コンテストだと出場者としてですけれども
結構テストエンジニアリングもちろんQAもそうですけど
テストエンジニアリング特にテスト設計コンテストとかっていうと
テスト設計をどうやっていくかっていうのを競い合うところだと思うんですけれども
河野さんの中でテスト設計とかそういうことに対して
こだわりっていうとそんなのないよっていうのかもしれないですけど
テスト設計に対するこだわりとか思いとかってあったりするんですか
こだわり思い
こだわりというよりどちらかといったら
何ですかね
僕業務でテスト設計やるときって何ですかね
辛さ半分楽しさ半分なんですよ
なので業務として
やるというか知的好奇心でこの複雑な仕様を
どう単純シンプルにテスト設計するのかっていうところが
結構面白みがあって
それを違う人にレビューしてもらって
お褒めの言葉いただくとかは結構モチベーションを保っている部分があるんですけど
そこをやっぱり妥協せずにきちんと
他の人が見ても分かりやすいテスト設計をするみたいなところは
結構こだわりが
あってで多分ベースがねこれ松尾谷さんなんですよおそらく
松尾谷さんのやっぱりテスト設計とかをリアルで僕見てたので
そこのやっぱり上手いテスト設計をするっていうところが
やっぱり知的好奇心があるのでそこはなんか妥協せずに
今でもなんか自分の中でスキルアップするみたいな
モチベーションを持ってやってますね
結構今コロナさんのおっしゃってた中で
その実際に
プロダクトとか対象物に対して
ある点から見るというか
どう単純化するとか
まさにモデリングとかとも関わってくるとは思うんですけれども
多分最初にテストっていう話を聞いて
テスト実行をするとか
そういうのを思い浮かべている人にとっては
あまりない視点だと思うんですよね
テストっていうもの自体にモデリングする
単純化するっていうところ
なんかそこって
やっぱ日立製作所さんに最初に入っていって
そこを学んでたとか
松本さんからのやつを見ていたとかっていうところはあると思うんですけれども
なんか最初にそれを気づくのってなかなか
自分で気づくって難しい人が多いんじゃないかなって思うんですけれども
なんかそういうのを気づくきっかけとかってあるんですか
やっぱり周りの人でそうやってる人を見つけられたら
ラッキーぐらいな感じなんですかね
あー
でも一つやっぱあるのが
大学時代にちょっと戻るんですけど
大学のやっぱり研究室のゼミとかで
僕の同級生とか後輩とかが
結構そのモデリングとかの研究とか
モデリングからテストみたいな研究をしてる人間がいたので
そういったのでいろいろ議論して
モデリングとかその何ですかね
ある視点でそのモデルを書くみたいなところって
なんかやっぱ面白みは感じてたわけですよね
それから大学の後半の方は
松尾谷さんと一緒に仕事させてもらうようになって
この仕様からこのモデル作るんだみたいな
なんかその驚きというか
こんな感じで作るんだみたいなところの
なんかどちらかといったら目から鱗が落ちるみたいなのを見て
なんかやっぱちょっと自分もその辺
実践でやらなきゃいけないなみたいなのを気づいたので
それは大きかったですね
うん
ただあんまりなんかそのフィードバックを受けるみたいなの
あんまりやってきてないので
そこはなんか意外となんか
僕の弱点かもしれないですね
僕のなんかテスト設計とかあんまりこう
なんかここ行けてないよねみたいなの
あんまり受けたことない気もするので
ただ学生自体も死ぬほど受けてるので
フィードバックと自己批判
それが生きてるかもしれないですね
なるほど
そういう意味だとそれこそさっき途中でもお話
自分の顔から言った
テスト設計コンテストを出場されて
まあ
2連覇されてるじゃないですか
はいはい
その時もそんなになんか
フィードバックというか
こうした方がさらにいいんじゃないみたいな
そこまでなかった感じなんですか
えっと
フィードバックは審査員からフィードバック受けてます
うん
ただ周りからフィードバックは一切受けてなくてあれは
全部自分で一応考えて作ったんですよね
うん
ただあの
フィードバックというか
いろいろ参考にしたものがあります
そういう意味だと
あの
清水芳雄さんのUSDMを参考にはしてますし
あとはどちらかといったら
僕がテスト設計コンテストで作ってたのは
松尾谷さんのそのCFDみたいな
なんか物事の捉え方みたいなところ
そういったのは結構参考にはしてるんですよね
ただまあその参考にするものはあったけど
なんかそのフィードバックとか
あれもあんまり議論して
何かものを作ってったっていうのもあんまりないので
そこはなんとなく自分で作り上げた感はありますね
なるほど
じゃあもう本当に複数人でいろいろ話していって
どんどんどんどん洗練していくみたいな
そういうものではなくても
本当に一人で考えて作り上げたっていうのが多いっていう感じ
そうですね
なので僕のテスト設計コンテストの成果物は
水のりが言ってたんですけど
思いつきレベルって言われてるゆえにかもしれないですね
なるほど
結構そこは興味深いなと思っていて
あの
テスト設計と他者への伝え方
特に
あの
I
テスト設計今まで学んでなかった人とかにとっては
なんかいろいろそういう壁打ちしてもらって
どんどんどんどん洗練していくことによって
だんだんだんだん身につくみたいなことが
多いなとは思っていたんですけれども
河野さんどっちかっていうと
それこそさっき言ってた大学時代とか
そういうのを経て
なんか
いやこういうもんでしょっていう風になっている
っていう風に聞こえたんですけれども
そうすると
じゃあ今度は今
あの
河野さんの立場になって
なんか
それこそ周りの
QAエンジニアなり
もしくは開発者なりに
なんか
フィードバックをするとか
っていうのって
なかなか難しかったりしないんですかね
いやこういうもんでしょっていう風にならないんですかね
それはないですね
それはなくて
結構フィードバックちゃんとできてるイメージはありますけどね
できてないって言われそうだけど
そこはなんかあんまりないですね
うん
ただ
なんとなくフィードバックあんまり受けてないって今言ってたんですけど
おそらくその大学の中の研究の過程でものすごい多分僕フィードバック受けてるので
それがペースにあるから
なんか自分が作った生活に対して
なんか自己批判ができるようになってるのかもしれないですね
なので自分から見たら
なんかその第三者のレビューをしてる時に
この人がどうわからないのか
なんかなんでこの生活ができるのかって感じで
この人ができてるのかみたいなのがなんとなくわかるんですよ
僕は
なんでかって言ったら僕結構容量が悪いので
あの容量が悪いからこそ
なんか他の人がわからないことがわかる逆に
で容量ない人でなんか他の人がわからないことが多分わからないと思うんですよね
そこのなんか違いなのかなって気がするんですよね
そこはすごい自分も共感できるというか
自分のちょっと話になっちゃいますけど
自分は
あの
大学生時代に塾講師のアルバイトしてて
なんか塾講師のアルバイトしてると
特に勉強がすごいできる子に対しては
なんかある程度
それこそその教える側のレベルがちゃんとできていれば
ある程度教えられるんですけど
電気通信大学での研究
逆に勉強がまだうまくできてない子に対して
すごい勉強ができる先生が入っても
いやこれこれで当たり前でしょみたいに
うんうん
こんな感じでうまく指導ができないっていうところがあって
自分はそこはあんまりなかったので
そこまで勉強できてなかった子に対してもうまく接することはできたんですけど
そこはやっぱり人によって
自己批判になるのかわからないですけど
なんかそのこの部分がうまくできないんだよね
わからないんだよねっていうところを理解して進めるっていうのは
あの訓練が必要なのか
その人の特性によるものなのか
ちょっとよくわかってないんですけど
人によるな違いがあるなっていうのは自分は感じてました
それは人によりますね思いっきりね
ただ自分がどういうタイプなのかっていうのを理解できてるのが
多分大事だと思うんですよね
なんかこう自分がやっぱり物分かりが悪いって
なんか表現は良くないですけど
自分はちょっと容量が悪いとか
他の人より理解がスムーズではないみたいなのを
自己理解できてると
逆に他の人よりちょっと理解するの時間かかるとか
自分が理解できた後に他の人に伝えるときには
結構ちゃんと伝えられることが多くて
なんかクシュって理解できてる人が
他の人に伝えると
なんかあんまりうまく伝わんないわけですよね
なんでかって言ったら
分かんない人の気持ちがあんまり分かんないから
そこがなんか
分からない人なりに何かこう
逆に言うと
他の人に伝えるっていうのは
その分からない人のすごいメリットだと僕は思って
そこはすごい感じていて
テストに対してもそうですけど
それこそスクラムとかでやっていく
スクラムのイベントの中で
リファインメントであったりとか
開発者がこういうのを作りたいんですよって
一言で終わるところに対して
旧エンジニアとして入って
ごめんなさいここちょっと全然まだ分かってないんですけど
みたいな一言から入っていって
開発者がそこを
すごい開発者の
正確にもよるかもしれないですけど
分かってもらおうとして
結構ちゃんと説明をしようとして
その結果
これってパターンAとパターンBとパターンCっていうのがあって
パターンAはこういうふうに対応して
パターンBはこういうふうに対応して
パターンCのこと忘れてたなみたいな
なんか
詳しくちゃんと説明しようとした結果
ほころびが見つかるみたいなことは結構あるので
それは旧エンジニアとしても
すごい大切なというか
そういう
なんか
自分さっき容量が悪いっていう話してましたけど
分からないっていうところをちゃんと理解して
なおかつそれを聞きに行くとかっていうのができると
別にテストを作るだけではなくて
そういうところでも生きてくるのかなっていうのは
常日頃感じているところではあります
そうですね
なるほどありがとうございます
ちなみにさっき話の途中で出てきて
どうしても多分自分と河野さんが
喋るとなると
ここは避けられない話題にはなると思うんですけれども
途中で電気通信大学に入学されて
研究をしていたっていう話ありますけれども
電気通信大学
自分も電気通信大学出身だし
なおかつ学部学科も一緒ぐらいな感じです
当時はシステム工学科ですよね
そうですね
当時はシステム工学科で
もちろん同級生とかではないんですけれども
若干かぶっている部分があったっていうのは
先日聞いて判明はしたんですけれども
どういう経緯でそもそも
電気通信大学に入ろうっていう風になったんですか
なるほどそこから聞きます
電気通信大学選んだのは
当時は社会人だったんですよね
先ほど経歴述べられたように
日本無線っていう三鷹市にある会社に勤めていて
で
5年ぐらい働いて
ちょっと大学行きたいなっていうので
大学を探したんですよね
夜間の大学じゃないと難しいなっていうところが一つと
もう1個は近い大学っていうので
当時インターネットも普段使えるような状況じゃなかったので
東京都の地図を買ってきて
自分の家から一番近い大学はどこだっていうのを調べたんですよ
そしたら電気通信大学が一番近くて
調べてみたら夜間のコースもあるし
何なら自転車で行けると
国立で学費も安いと
ここに行くしかないなっていうので
電気通信大学を選んだ
すごいなんかスラムダンクのルカワみたいな
近いからっていう理由っていうのを初めて聞きました
全然いい大学なので
全然間違ってはなかったですけどね
夜間子コース入学して
博士課程まで進学するっていう話でしたけども
先ほど研究室でいろいろと鍛えられたみたいな話もありましたけれども
研究室でいうと
自分も結構社会人になってから関わりが多かった
西さんが多分研究室の先生だったと思うんですけれども
自分は西さんの講義とか受けてはいたんですけれども
システム工学科の先生であったので
研究室でどういうふうに
どんなことをされていたのかっていうのを
自分はそこまでよく知らないんですけれども
研究室の中で西さんってどういう感じで
研究というかされてたんですかね
なるほどね
ちょっと話を戻すと
僕電通大一回受験して落ちてるんですよね
2回目の受験で
なんとか潜り込むぐらいな感じで
なんとか入学をできて
僕が4年生の時に
電通大だと大体研究室に入るので
そこで研究室を選ぶみたいな状況になりました
その時に
僕は西さんって呼ばなくて
西先生ってずっと呼んでるんですけど
西先生が着任する1年目の
1期生で僕入ってるんですよ
なので僕は大学をそのまま受験して
1発目で通ってたら
おそらく西先生の研究室に入ってなくて
おそらく違う人生を歩んでたので
そこで1回落ちて良かったっていうのが実はあります
1期生で入って
当時西先生は大学に入る前が
SQCっていう会社でコンサルをやってた
立場から大学の先生になったので
当時は厳しかったですよ
あの
おそらく最近知ってる人とは全然別人ですね
なので
いろいろ今だと
多分説明できないとか
喋れないぐらいのことやってましたけどね
当時は厳しかったんですけど
研究のスタイルとしては
どちらかといったら
研究というよりは産業界に役に立つかどうか
という判断軸
もう一個が僕の中だと
まともな社会人を輩出する
っていうのがもう一個かなっていうので
おそらくうちのゼミ出て社会人出たら
結構社会って緩いんだなみたいなのを言ってる
卒業生もいるぐらいなので
まあ厳しくはあったけど
そこを卒業したら
逆に言うと何ですかね
もうあの社会の方が
あのもうちょっと皆さん優しいみたいな
そういうところありますね
はい
なるほど
実際前半の話に戻っちゃうかもしれないですけど
あのまあ
日産と日立製作所での経験
電通代で日産のところで鍛えられて
っていう話ありました
その後日立製作所に入って
日立製作所さんもさっき言ってたように
本当にしっかりしている
基礎をしっかりしている会社さんだなと思ってるんですけども
それでも日産のところでやっていて
やっていたから
緩いなは違うかもしれないですけど
そういった部分ってあったりするんですか
そこはもう全然あれですね
普通にいる多分
その日立製作所の当時行った人たちとは
もう多分物の見え方が多分違ってたと思いますね
なのでまあ課題とかも
あのまあやっぱり一緒に
まあ仕事してたら大体課題ってあるんですけど
そこの課題の目の付け方とかもやっぱり
他の同僚とやっぱりちょっと違うかなっていうのは
自分の中では思ってましたけど
もちろんそれは言えないですけど
自分の中だと
まあその辺の感度というか
それはだいぶ違うなっていうのは
まあそこは全然思ってましたね当時も
その課題に対する感度であったりとか
あと先ほどちょっと前に言ってた
その自己批判の部分とか
具体的にどういった部分っていうのが
もしかしたら聞いてる人イメージ
まだ湧いてないってところもいるかもしれないんですけど
なるほど
例えばその研究室の中で
えっと
自己批判とかっていう考え方か分かんないですけど
どう役立てたのか
なんか具体的なエピソード的なやつってあったりします
それで言うと
まずその自己批判という点で言うと
やっぱりその研究してたので
やっぱりずっと論文を書いてたわけですよね
当時で論文に対して
やっぱりずっと赤ペンを入れてくれたんですよね
西先生がでそれがかなり大きくて
で
論文ってやっぱり日本語で書いてるんですけど
日本語ってやっぱりロジカルに書かない
もちろんどの言語でもロジカルに書かなきゃいけないですけど
ロジカルに書く上のその裏側で見えてるモデルというか
どういう論理立てで書いてるんだみたいなところから
話し合って決めていくみたいなところがあったので
それを一緒にやりながら
いろいろ指摘を受けるから
その指摘を自分でできるようになるっていうのが
恐らく身についてだと思うんですね
それがやっぱり期間が長いんですよ
僕たって5、6年一緒にずっとやってるんで
それがやっぱりある程度の期間がないと
自己批判とテスト設計
多分それは無理だと思うんですけど
それが5、6年という積み重ねで
自分で自分のドキュメントをある程度見れるようになった
っていうのはあるかもしれないですね
課題の感度っていうと
どちらかといったら
課題を見つけるための土台を作るみたいなのは
意外と
得意というか
当時から清水吉弥さんのPFDを書いて
プロセスを表現してみて
じゃあ課題どこにありますかって言って
じゃあみんなで小丸が成果物で指さしてくださいって言ったら
指さすとこは大体みんな一緒なんですよ
そしたらもう課題は全然わかってるわけですよね
ただ課題を共通認識するとか
課題がここにあるっていうのを
特定できる状況にしてあげるとか
そういったところは
あの結構日立時代にもやってたので
やってたというか
後半ぐらいですかね
なんか初めからそういうのやり始めると
なんかめんどくせえやつ来たって思われるんで
後半ぐらいやっぱりみんな
ある程度理解できた状態だと
それをやりつつ
その課題をみんなで発見しやすくするみたいな
ところやってましたね
結構先ほど言ってた
実行批判というかの中で
日本語というものに対して
論理立ててるみたいなところって
自分は西さんとそんな
研究室が一緒ではなかったので
そこまで深くは関われてないにしても
日々の言動であったりとかで
垣間見える部分はあったりして
それは自分が大学時代も感じていたし
社会人になってからも感じた部分として
例えばそれこそ
当時のツイッターとかで
こういうAっていうものに対して
Bって思うみたいなことに対して
西さんの多分返し方って
それってAなんじゃないの?
っていうのが
Aっていう言い方っていうよりかは
どうしてBだと思ったのかっていうところ
そっからの論理立てが
どうなっているのかを探るっていうのを
結構されてたような気がしていて
ある視点から見ると
それはBじゃなくてAなんだけれども
その人が考えているもの
その人の考え方では
Bっていう風な結論付けられるんだったら
それはそれでいいっていう風に
思っているように
ツイッターのやり方とか
やり取りを見ていて思って
ただそこに対して結構
相手の反応としてあるのは
すいませんAが答えでしたね
っていうことになっちゃって
いやそうじゃなくて
なんでBだと思ったのか聞きたいんだけどな
みたいなのですれ違いで終わっちゃうみたいな
そういうことは
西さんとの会話を見てて
結構そういうやり取りは
見てたんですけど
そういうのもやっぱ研究室の中で
議論の中でどうしてそこが
そう思うのかっていうのを
言語化するみたいな
そういうの結構研究の中で
されたりしたんですかね
それはあの優しいバージョンの西先生ですね
私はそんなやり取りないですね
AがBであるって書いてたら
その根拠っていう詰められません
その根拠はっていうので
いや常識的にこうでしょうみたいなこと言うと
もうボコボコにされますね
なのでAからBって言うと
こういう論理を組み立てるとか
その論理構造を作るのであれば
その根拠はっていうので
なんならどっかの論文を引用するぐらいじゃないと
なかなかこう
ゼミが先に進まないぐらいな感じです
じゃなければAからBってなった時に
何かしらのモデルを書いて
モデル上これしかありえないみたいな
やり方だと結構納得する
なのでそういうモデルで整理をし
した上でAからBにしかも行けないよねみたいな
こう論理立てをすると
ある程度物事が進む
ただAからBというモデルを作ったら
そのモデルの発展で
じゃあBだったらどうなるの
Bだったらどうなるの変ですね
A'だったらどういう結果になるのっていうのを
そのモデル上で結果がどうなるかっていうのが
逆に言うと予測できたりするじゃないですか
それをなんかこう研究でやってたりしますね
なんかそこは今のお話聞いてると
結構日々のテストとかテスト設計とか
そういうところにもやっぱり生きていく話だなと思っていて
結構テスト設計とかテストを考える上で
やっぱりロジカルにやっていかないといけない部分だと思っていて
なんとなくこれを選びましたではなくて
テスト設計をしてとか
あることをやっていかないといけない部分だと思っていて
テスト設計の意図の書き方
視点から見てモデリングした結果
こういうところが必要だと思うので
この部分をテストしますとかっていう風に
言えることは大切だと思っていて
なんか今のお話にも通ずる部分があるなっていうのを
ちょっと聞いてて思いました
うんうん
なんかテスト設計ってあんまり根拠を書かないですよね
うん
なぜそういう設計にしたのかっていうのが
あんまり根拠を書かないので
本当はどっかに根拠を書いた方がいいんですよね
うん
例えばデシジョンテーブルになんでその条件選んでるんですかっていうのか
あんまり根拠が出ない場合には
自分はこういう根拠でそれを選んでますっていうのを書いた方が良かったりしますよね
うん
なんか自分も最近すごい思うのは
テスト設計
テスト実行を今までやってた人
もしくはテスト手順書を書いていた人が
テスト設計っていうことを知るようになると
デシジョンテーブルなり状態遷移なり
とりあえず書こうっていう風になるんだけれども
今河野さんがおっしゃってたように
どうしてそれを選んだのかっていうのが
抜けがちになるなっていうのはすごい見てて思っていて
それがもしかしたら
そのテスト設計で
例えばデシジョンテーブルのあるパラメータを選ぶ理由として書かれているのが
本来的にはもしかしたらテストプロセスでいうテスト分析の部分に当たったりとか
あとはあんまりテスト分析とかっていう言葉が
ちょっと分析っていうのがふんわりとしている部分とかもあったりするので
自分の場合はどっちかっていうと
テストの意図っていう言い方をしてたりするんですけれども
どうしてそれを選んだのか
パラメータとしてそれを選定してデシジョンテーブルを組み立てたのかっていう意図であったりとか
そもそもデシジョンテーブルを作ろうと思った意図であったりとか
っていうのは
自分もテスト設計のレビューとかする上で結構聞いたりはするし
それが意図が
ないとそれこそさっきの
コーナーさんとイースさんとのやり取りじゃないですけど
なんとなく選んだんですっていう話になると
どうしてなんとなくそれを選んだのっていう
そんなコン詰めることはあんまりしてないかもしれないですけど
そこはやっぱり気になっちゃうなっていうのは思いました
意図っていう言い方を結構自分は最近は使うようにしてます
それは大事かもしれないですね
だから第三者の人が
逆に言うと
例えばブロッコリーさんが設計した
成果物を見たときに
そういう意図が書いてあると
勉強になるわけですよね
そういう根拠でこれをやってますっていうのが説明してあれば
なるほどねっていうのが
勉強しようとしてる人が
わかるので
かなりメリットがあるでしょうね
書いてる人は結構めんどくさいのはめんどくさいですよね
そうですね
そこはもしかしたら
記述として残さずに
レビューのときにこういう意図で
選んでるとかっていう風に
口頭で言ってしまうことも
実際問題あったりはしますけど
それはパラメータを選ぶ意図もそうだし
あとは
ディッションテーブルで組み合わせて
考えたときに
これは削るっていうときの削る意図とか
どっちかっていうと
そっちがすごい言語化する意識が
強いかもしれないですね
なんとなく
これを選びましたではなくて
これとこれって
条件としては同じ状態であるとか
何かしらの理由が
これとこれが同じものとして見ているので
その中の一つのこっちを選びましたとか
そこははっきりと
自分を伝えるようにしているし
レビューのときに
どうしてこれを選んだのっていうのは
結構聞いちゃうかもしれないです
自分も説明してることが多いですかね
レビューのときに
ここはこういう根拠で
この条件選んでますってことは
多いかもしれないですね
ただもう一個
その意図がちゃんとしてあって
狙い通りに設計するっていうのがあると思うんですけど
もう一個が
僕はテスト設計で
とりあえず書いてみるっていうのが
結構重要だと思っていて
ずっと分析をして
テスト設計の試行錯誤
テスト設計技法をどれにしようかなっていうのを
悩んでるって結構無駄だと思ってて
であれば
とりあえずデッションテレビで書いてみようと
書いてみた結果
なんかぎこちないよねとか
書けないよねみたいなところから
いやそもそもこれ状態整理図まず書いた方がいいんじゃない
みたいなところってあるじゃないですか
なんか試行錯誤を本当はやった方がいいと思ってて
その試行錯誤をやると
なんとなく仕様を見たときに
これからデッションテレビの方が良さそうだよね
っていうのがなんとなく
勘どころがついてくるんですけど
私も初めから正解を求めるようなやり方をしてしまうと
その外れを引いてないから
この正解ばっかりに
言っちゃうとあんまり良くないと思ってて
それがなんか僕の中では
結構その
トライアル&エラーを何回かやってるのは
自分の中でもあるので
そこはなんとなく
自己批判に近い話になってくるかもしれないですけど
その外れを何回か引いてみるっていうのは
大事だと僕は思ってます
なるほど
自分もそうですね
今コナンさんがおっしゃったように
ディシジョンテーブル書いてって
あれこれ状態整理図じゃねってなるのもあるし
あとはディシジョンテーブル書いてった結果
最初にパラメータを
値を出した時に
単純な計算で言えば
掛け算で
パターン数が出るわけで
そうするとどう考えても
パターン数が例えば200とかになったら
これ全部掛け合わせるの
本当にいいのかなとか
っていうのでそもそもディシジョンテーブルを
分けた方がいいんじゃないかとか
もしくはこれとこれって
そもそもパラメータの
組み合わせとしてありえないよねみたいな
金属を見つけたりとか
っていうのも多分最初から
頭の中で考えるっていうよりかは
実際とりあえず
書いてみるというか書こうとした瞬間に
数が多い
っていうところから
きっかけで次につながっていくのは
結構自分も経験上あるかな
って思いました
すごいテスト設計の
ところは結構
特にもしかしたら
ここ聞いている
人でQAエンジニアとか
あとはもしくは開発者で
テストどうすればいいんだろうって思う人にとっては
新鮮というか
そうなのか
って思うところなのかもしれないですね
ありがとうございます
役に立つ話ができてる自信はないけどね
すごいいい話だったなと思います
でちょっともうそろそろ
結構な時間喋っているので
一旦ここら辺までにしてすいません
結構今までの
今までいろいろな会社に行ったりとか
大学の話とか
自分の方から質問ばっかりして
いったんですけれども
これ最後に逆に河野さんから
自分に質問とかがあれば
お聞きしたいなと思うんですけれども
何か質問ありますか
はい2つあります
2つはい
まず1個目が
なんかそのブロッコリーさんって
なんかこうキャリアをどう考えてるのかな
みたいなのが結構気になっていて
でまあまあ尖ってるじゃないですか
いろいろやってることとかね
うんなので
例えば5年後とか10年後とかって
どういうキャリアとか
どういう仕事してのかなみたいなので
自分の中でなんとなくこうあるのであれば
ちょっと共有してもらえると
多分他の人も気になってるところだと思うんです
そうですね
5年後とか10年後がどうなってるかって言うと
難しいんですけど
なんかそれこそ今ここの
ここまでの話で言ってた
テスト設計の話であったりとか
っていうのが
まあすごいそれこそJSTQBをはじめとして
いろいろな取り組みによって広がってはいるものの
まだ知らない人とかっていうのも
結構いるところは多いかなと思っているし
そういう知識だけでなんとか
ある程度の底上げができるとしても
知識だけではうまくいかない部分
それこそさっき河野さんとも話してましたけれども
とりあえずやってみて
そっからいろいろフィードバックをもらって洗練して
いくみたいな
そういうところを
なんだろうな
そういう体験も含めて
どんどん広めていきたいなっていう
ところは思っています
じゃあそれをどうやって広めるのっていうのは
まだ全然考えられてはいないですけれども
なんか自分が一人のQAとして
なんかもちろんQAエンジニアとして
テスト設計して実行するっていうところもそうですけど
どっちかっていうと
それもやりたいなと思いつつも
そういう広めていく活動
それこそ今の若手の実行委員とかもそうかもしれないですけど
それをもっともっと広めていきたいなっていう
そんぐらいですかね
ふんわりとした感じですけど
なんかあんま納得してなさそうな顔してますけど
まさしく2問目の質問にほぼつながってるんですけど
なんかテストとかそのQAのコミュニティというか
社外でやっぱりそのQエンジニアの人たちと
やっぱりつながりがあると思うんですよね
今若手の人たちが
若手の実行委員とか
まあいろいろ外で活動されてるところって
なんかどういうモチベーションとか
どういう思いでやってるんですか
なんかこう極端な話
目の前の業務だけやってればいいっていうところもあるわけじゃないですか
それはなんか社外に出て
いろいろ貢献をしてるっていうのは
なんかどういう思いがあるのかなっていうところですね
なんだろう
すごいかっこいい言葉になると
どんどん
なんだろう
日本全体なのか分かんないですけど
を良くしたいっていう部分はあって
なんか自分がやったところで
自分が関わってる会社しか良くならない
自分それこそ若手であったりとか
まあそういういろいろな活動で
こういう考え方があるんだっていう風に
その人が取り入れてくれると
その参加した人
それでいい刺激をもらったって思う人ほど
どんどんどんどん
いろいろな会社に広がって伝播をしていくと思っていて
そこにモチベーションがあるっていうのがあります
あともう一つあるのが
さっきテストやQAのコミュニティにつながりがあると思うが
っていうお話ありましたけれども
自分はそこに加えて
やっぱり開発のコミュニティにも
積極的に関わりたいなと思っていて
それこそ何回かJJAG
Javaのユーザーグループのところに登壇したりとか
デベロッパーズサミットに登壇したりとか
あとはジャストレビューって
自分が自己委員長やってるのも
あれはどっちかっていうとレビューの話なので
別にQAとかに閉じた話ではないところをやろうとしていて
別にQAとかQAエンジニアとかっていう
閉じたところではなくて
実際にテストを書いてみる
開発にも知ってもらうことによって
その組織全体がもっと
QAが頑張って品質を良くするではなくて
開発する
実は一緒にみんなで良くするっていうことに
取り組んでほしいなと思っているので
そこも含めて
どんどん広まってほしいっていうところが
モチベーションとしてあります
QAエンジニアのモチベーション
なんかちょっと小蕎麦良い感じですけど
なるほど
完全に同意ですね
その辺は僕はちょっとあまり開発エンジニア向けの
僕はちょっとあまり開発エンジニア向けの
貢献が全然できてないので
その辺もちょっとこう
いろいろチャレンジしたいなっていう思いありますね
なるほど
ありがとうございます
はいということで
逆質問ももらったところで
じゃあ一旦ここまでということで
エンディングに入っていきたいと思います
はいエンディングです
本日は株式会社ナレッジワークの河野さんをお招きして
QAについて語ってきました
最後に河野さんから何か宣伝とか
告知したいことがあれば
お願いしたいです
はい3つ持ってきました
まず1つ目が
ナレッジワーク
QAエンジニア積極採用中なので
カジュアル面談から
お受けしてますので
ナレッジワークのホームページに行って
採用のページ
辿ってもらえれば
そこからアクセスできると思いますので
よろしくお願いします
2つ目が
今年の7月と9月に
連続して
続きものの
Kindle本を書きましたので
QAの内製化について書いてますね
そういったQAの内製化をしたいという
困っている人には
向けに書いてますので
よかったら読んでください
3つ目が
プライベートの話かもしれないですけど
書籍出版して
自分の時間も取れるようになってきたので
副業を少しやりたいなとも思ってますので
QAの支援をして
そういったところで何か
お手伝いしたい会社さんいれば
お受けしてますみたいなところですかね
あとは先ほどブロッコリーさん言ったように
QAのコミュニティを
ちょっと良くするみたいなところも
プライベートの時間で
オンラインサロンみたいなのやったら
面白そうだなとか思ってますので
そういったのもちょっと年明けから
少し動きたいなと思ってますので
興味ある人
ぜひ参加してくださいって感じですかね
はい以上です
はいありがとうございます
ありがとうございます
じゃあちょっと自分のほうからも
宣伝が二つあります
一つは先ほど逆質問で
自分が答えた
開発に対してもっていうところに
紐づくことになるかなとは思うんですけれども
来年ですね
2024年の1月10日から12日に行われる
Regional Scrum Gathering Tokyo RSGT
と呼ばれているイベントがあるんですけれども
そこで自分が
1月11日に登壇をします
今の10Xの自分が所属しているチームでの
自分
あとは自分のチームでの取り組みっていうのを
紹介したいなと思っています
実際お茶の水のソラシティカンファレンスセンターで
行われるんですけれども
ちょっと現地の参加チケットは
売り切れになってしまったんですけれども
オンラインで
の試聴のチケットはまだありますので
興味がある方は
是非お買い求めいただければなと思います
二つ目なんですけれども
技術評論者さんから出ている雑誌ですね
ソフトウェアデザインの2月号ですね
1月18日発売になるんですが
そのソフトウェアデザインの2月号に
ソフトウェアテストをテーマとした特集記事が載りますので
ソフトウェアテストをテーマとした特集記事が載りますので
ソフトウェアテストの特集記事
そのソフトウェアデザインの2月号にソフトウェアテストをテーマとした特集記事が載りますので
そのソフトウェアテストをテーマとした特集記事が載りますので
そこの特集記事
第1章から第4章があるんですけれども
第1章を私が担当することになりました
一応もう記事の内容自体は終わって
今編集の方に見ていただいている段階なんですけれども
特集
特に詰まったりするようなところがなければ
ソフトウェアデザインの雑誌
2月号に多分
第一特集と聞いてはいるんですけれども
乗るのが
もし興味のある方はお買い求めいただければなと思います
このソフトウェアデザインもどっちかというと
QAとかテストエンジニア向けというよりも
開発者向けの雑誌にこういうふうなテストの話題で
載るっていうのはなかなか珍しいことだと思うんですけれども
すごいそこはお声掛けいただいてありがたかったですし
自分なりの考え方をできるだけ言語化しに載せたので
興味のある方はぜひお買い求めください
2月号になります
1月18日発売予定です
ということで私の方から宣伝は2個なんですが
それ以外にも10Xのところとして
10Xでは現在様々な職種のメンバーを募集しています
この10XFMを聞いて10Xに興味を持った
カジュアルに話を聞いてみたいと思われましたら
番組概要欄にある採用情報もしくは
10Xのホームページのリクルートからご応募をお待ちしております
また10XFMではリスナーさんからのお便りも募集しています
エピソードの感想や10Xのメンバーに聞いてみたい質問など
どんなことでも構いません
もちろん今回の感想であれば
河野さんにもお伝えしたいなと思っています
こちらも番組概要欄にあるお便りホームからの投稿
またはTwitter
今だとXですね
ハッシュタグ10XFMでポストをお願いいたします
最後にSpotify、Apple Podcastなど
お聞きのPodcastアプリで番組のフォローを忘れなく
最新エピソードを配信時にお知らせが届いたり
また過去エピソードの再生済み、未再生が一目で分かるようになり
大変便利です
ということで本日のお相手は
ブロッコリーと株式会社ナレッジワークの河野さんでした
河野さんありがとうございました
河野さんはい、ありがとうございました
それではまた次回
ありがとうございました
