00:00
みなさんこんにちは、TRY-CATCH FMです。このポッドキャストは、IBMに新卒へ同期入社した中堅エンジニアの二人が、
プログラミング学習、最新のテクノロジー、働き方、転職などについてゆるく話していきます。
はい、ではご質問お願いします。
なんかね、これも本当、新卒くらいから持っている話なんだけど、
新卒の頃から、タクシー乗って住所伝えて行ってもらうときに、
そこに最短で行ける道、かつ最安で行ける道順で行ってくれれば、もうそれで十分じゃないですか。
なのにさ、じゃあ何々通り通って、何々のところの交差点で右折して、そこから何々通り入っていけばいいですかね、とかっていう運転手は何なの?
いらんかーってなるよね、なんだろうねあれはね。
何なんだろうね、それが最安ならそれで行ってくださいって言ったら、その答えしかないんだけどな。
フレーム対策とかなのかな、この道行くって言っといたよね、みたいな。
うーん、何なんだろう、普通にGoogleマップで検索して行ってくださいって感じなんですけどな。
そうねー、街中でキャッチして乗るときはさ、ちょっとわからんじゃないんだよね、
すぐ走り出さないといけなくて、走り出しながら聞くみたいなさ、邪魔になっちゃうからみたいなときはわからないじゃないんだけど、
なんかもうあらかじめ、うちの会社の、僕らの元いた会社のさ、前のすげー余裕があるところでさ、今入力できるやんってときも聞くもんね。
まあね、でも多分、チェースによっては、多分その目的地への最速の方法を知ってる乗客が多分いて、
それ多分普通の道で行っちゃうと、いやいやこっちの方が速いのに、なんでその道で行くんだよ、みたいなクレームがあるのかな、わかんないけど。
うーん、いやでもさ、道の名前とか知らんよね、俺もう10年東京住んでるけど。
車もまあ乗るっちゃ乗るけど、ただカーナビのあれに従って行ってるだけだから、ほんとね、道の名前とかね、ほぼわからんのよね。
なんか住んでたときの家の近所の道の名前がかろうじてわかるくらいで。
会社の周りも何通りかよくわからんし。
ね、ほんとにタンナナとかヤスクニ通りとかもそれくらいしかわからんのかな。
03:07
だからね、聞かれても、なんかああはいとかっていう術しかないよね。
なんか多分レアケース対策だよね、あれは。そういうめっちゃ詳しくて、クレームをつけられると嫌だから言ってるけど大半の人には迷惑みたいな。
迷惑というかね。
SIRの現場で言うたらもうなんかすごい自由的な話をして、この実装法でやりますけどいいですかみたいな。クライアントに聞いてるのと同じだからね。
確かにね。
いや知らんけどみたいな。知らんけどそれがいい感じにできるんだったらそれでやってくれっていう回答になってしまうよ。
今後はね、きっとなんかパッと言っただけでそこのところに、もう今はだいぶカーナビとかもさ言ったらその場所に公表してくれたりとかになってるから、
だんだんそこがもうじゃあこれの通り行きますねで終わりにするとかになっていって、
だんだんタクシーの運転手の技量的なものっているんだっけみたいな話になって、自動運転がそこにのまみに乗ってきてみたいので多分なくなっていくんだろうなって感じがするよね。
なんか今、歯医者アプリとかあるじゃない?
はいはい。
なんかそれにフィードバック機能とかあるのかな?わかんないけど。
フィードバックはどういう意味での?
まあ要はその乗り心地とかさ、運転の良し悪しとか、接着とか、あれあんのかな?
僕この前使った、なんだっけちょっと待ってね、なんてやつ入れたっけ、GOかな?旧日本タクシーかな?
はいはいはい。
のやつがあって、それは普通にあった。乗り終わった後になんかこういろいろ言うみたいなやつがあって。
なるほどね。
じゃあまあその時に言うべきなんやろうね。
そんなシュラライブ聞かれても困りますみたいな。
もうなんか広域への攻撃としてあれだよ、タクシー会社の本社にお客様からの好意見を叩き込んでやればいいんだよ。
ああホームページとかあるのかな?わかんないけど。
電話くらいはあるでしょ少なくとも。
まあでもそこまでやってまでなんか届けたいあれでもない。
まあね。
一時的な本というか、もう10年後にはタクシーが今の業態じゃない可能性が高いし。
自動運転かもしれんからな。
電車より安くなるんでは?みたいな話とかもあったりすんじゃん。
前記事なんか読んだけど、自動運転になるとタクシーの価格13分の1くらいになるみたいな研究があるらしくて。
電車より安くなるって感じだと思うよ。数十円とかで行けるみたいな。
06:06
そうだよね。
バスとかもさ、それと一緒に自動化されるとさ、規定路線のバスがもうちょっと細かく運行できるようになりつつ安くなるじゃん。
まあ、かなりだよね。
そうだね。そういう未来をちょっとね、期待しますよ。
そうだな、このタクシーは。
はい、じゃあ本題の方に行きましょうか。
えっとですね、前回前々回と質問回答会をやってるんですけども。
はいはい。
もう一個回答してない、いただいた質問がありまして。
ちょっと読み上げていきますね。
普段関わっている案件でテストはどのように行われていますか?
ウォーターフォールで開発を行っています。開発は外注中心で耐性も行うことがあり、
大体納品されたプログラムのシステムテストで起きた不具合でスケジュールが遅延します。
何とかならないかと予防策を築くのですが改善されません。
QAチームがある企業が多いのか、開発もテストも同じチームでやる企業が多いのか、
などテストに関することが気になっているのでお題に挙げていただきますと幸いです。
というご質問をいただきました。ありがとうございます。
ありがとうございます。
まあそうですね、システムテストQAとかQuality Assuranceとかって言いますけど、
システム開発をやるにおいては避けては通れないところだと思うんですけど、
僕たちが一緒に働いてたとき、つまりIBMではどんな感じでやってたかっていうのをまず振り返ってみますか?
そうですね。
プロジェクトによって、特にIBMではこうやりましょうっていうのはあんまないような気がして、
プロジェクトごとにポリシーが異なる、クライアントごとにポリシーが異なる、みたいな感じだったと思うんだけど、
どんな感じだったかな?もちろん固い系のプロジェクトに行ったときもあるし、
結構緩めなプロジェクトに行ったときもあると思うけど、固めとかだとどうだった?固めの金融系とかだと。
金融の大規模の開発、テストに関わったのって保守の運用保守拡張の案件ではあったんだけど、
大規模な方は開発のバグ取りのところの管理とかまでで一回出たりしちゃったから、テストフェイスにいなかったりしたんだよね。
多分、設計の段階でやってるのが理想ではある。
09:04
ITAというのか、機能テストくらいまではある程度組んでおける方が良いし、
僕が運用保守拡張をやってたもう10年ものみたいなプロジェクトがあったんだけど、
そこはもう外部設計書しかないんだけどね。基本設計書しかないと詳細設計書を兼ねてるような外部設計書があって、
それをやってるときにお客さんに、ITAレベルのものまではテストケースこんなのやる予定ですっていうのをお見せするような感じでやってた。
そこ以降は、ITAやってる間にITPというか他の多機能連携のテストとか、システムテストとか。
システムテストは外部との兼ね合いがあったりするんで、そこは早めにスケジューリングしとこうねみたいなのはあるけど、
どんなケースをやるかっていうのはある程度設計の段階でやってるのが理想ではあったと思うんだけど、
僕が入った開発の方の大規模のやつとかはそんな余裕ないよねって。
まあまあまあ。ITAとかITBとかめっちゃ懐かしいな。何の企画だっけ?
何テストだっけあれ。
インテグレーションテストか。
インテグレーションテスト。
AはAかな。
多分そうだと思うよ。
それが失敗してどんどん何回もやるってなったら、ITB3とかっていう感じになっていくんだよね。
何回やってるんだよみたいな。
ITAの流度というか細かさがプロジェクトによって違って、
うちではITAって呼んでたけど、あっちのプロジェクトではITBって呼んでるなこれ。
まあそれはありますね。
ITA1、ITA2がデフォで分かれてるプロジェクトがあったりね。
あとはゆるめ系のプロジェクトとかだと、普通に海外にアウトソーシングする場合とかもあって、それをテストする。
テスト設定は自分でやってた気がするな。シナリオテストを組んでた気がする。
エクセルとかにまとめて、実施内容と期待値みたいな感じで。
それは日本でやるなり、そのテスト自体も別の誰かにやってもらうなりしてっていうケースがノーマルだったような気がするけど。
フロントエンドだと特にその辺難しいよね。どこまでやるかとかね。
まあでも開発者がテストするっていうのは良くないので。
12:00
基本は別の人がやってたっていう感じかな。
だからちょっと外注したものをテストするちょっと怖い感じはあるよね。
逆にどういうふうに動いてほしいかっていうのをこっちが外注したから握ってるはずなので。
こっちがテストをこうなればこれが満たせてれば良しとしますっていうのを持ってるっていう前提のもとやってるのかもしれないけど。
だったらまあ分かるけど。
システムテストっていうのが僕らが思ってるぐらいような大きい範囲のいろんなシステム連携のテストを指してるのかSTというか。
システムのテストのことを指してる。このまま指してるのかが分からないけど。
結構たぶん納品されたプログラムの、もう納品された後のテストの話をしてるっぽいんだよねこれ。
そうだったでしょうね。
なんで納品する前にテストしてないんだっていうのは置いといて。
まあでもそこでもテストしてるけど。
え、どうかな?
まあたぶん本番環境入れてみたらなんかダメでしたとか。
まあちょっと要件が微妙に違いましたとか。
要件というか要件に対して満たせてませんでしたとか。
起こり得るんじゃないかな?たぶんこのケースだと。
そうだね。で、外注してる。
うちみたいにオフショアのところに出してオフショアがやべえことやってますとかだったらちょっと話は変わってくるんだけど。
それだけ毎回そこの品質がやばくて遅延するんだったらそこ使い続けるのかっていう話はちょっとした方がいいと思って。
まあね。
それを置いておくとかその次のところと一緒にやるにしても、
バグって不具合って起きるものなので、
どのぐらい不具合って起きるんですっていうのを今までの実績から出して、
このぐらいの規模だとこのぐらいのバグは出るはずなんですと。
なので今のところいくつ潰れました?今回全然ないけど本当に大丈夫とか。
今回めっちゃ出てるけどなんでだろうみたいなのをトレースしつつ、
ある程度平均的に出る分ぐらいは予定に組み込んでおかないと遅延は毎日続くよねっていう。
なるほど。ちょっと話は戻すと、
iBeamの時はそんなにQA専門部隊がいなくて、
エンジニアロールの人がQAになるみたいな感じだったと思うんだけど、
COSDAの働いてるスタートアップだとどういうイメージで進んでます?QAって。
そうだね。ちょっとだけ補足しておくと、
iBeamの時僕全然入ってなかったけど、
僕がいた部署って実は品質改善とかテスト自動化とかの。
15:05
組織だったんだけど、テスト関連で炎上したプロジェクトへのヘルプとか。
テストをなんとかちゃんとした形で終わらせようとかの方のヘルプが多くて、
自動化のアセットとかの導入とかにはなかなか至れてなかったっていう感じではあったね。
なのであんまりうちはQAっていう組織単位であんまり進めてないかなっていう感じがするけど、
外部から見ると実はそうでもなかったりするから、
テスティングってあんまりそもそも業界全体でまだまだ進めきれてないものなのかもしれないね。
それはそんなイメージありますね。
iBeamの話はそういうのとして、今新しく入ったところだとやっとQAっていうような名前がつく人が
来てくれたくらいの感じだったはずなので、ちょっとこれからまた僕もその人と話をしたりして、
いろいろと今後どうしていくのかとか聞くことになります。
そこはガッツリ進んでるとかではないんだけど、テストとしては開発者がちゃんとテストコードを書いて、
プルリク出すときにちゃんとそこも含めて見てねっていう感じのことはしてます。
コードレベルではそこのテストをちゃんとやって、
あとはリリース前に、まだかなり少人数のところなので意味とかはちゃんと考えて、
こういうことをやるリリースだからここのテストをあらかじめこのステージング環境でやっていこうねとか、
そういうことはやるよねっていうくらいですね。
テストコードとか書いてるの?
書いてる。
ローカルメソッドに関しては必ずしも全部書かなくていいんだけど、
基本的にはカブレッジ100%にはなる。
しなさいっていうよりは、なるよね。
今、5で普通に書いてたらなるでしょっていう。
ならなかったら理由があるはずよね。なんでそこを通れないのかみたいなところがあるし、
そこを通れてないテストケースがあるってことはそもそもテストの想定漏れてるんじゃないっていうのを一応確認はしてるんだと思う、みんな。
一応やっぱりカブレッジ100%が正義ではないっていうのは、
巷で言われたりもしてるし、それも理解はできるんだけど、
うちとしては別にそういう特殊なとこっていうよりは、100%になるんじゃないっていう感じでやってると思う。
はいはいはい。なるほどなるほど。
でもすごいよね。スタートアップでテストコードちゃんと書いてるっていうところ、どうなんだろうね。最近のテストコードって。
でもCICD、マージしたときとかプッシュしたときに勝手に回すっていうのをGitHubで組んでるとこも結構多いんじゃないかな。
18:02
あと金融系だからそういうのちゃんとやるみたいな風潮もあったりするのかな。
あと僕が言うの忘れてたけど、僕がやってるのはバックエンドのチームなので、フロントエンドはまた別の話だと思います。
バックエンドはテスト回しやすいから。
フロントエンドは確かに結構もしかしたら頻繁に変わるとかであれば、始めから書かないっていう、チーム間で合意するっていうのもアリだとは、俺は個人的には思ってるから。
どうしてるのか今度聞いてみるけど、ルールとか基準決めてコードは書いてないところかもしれないね。テストに関しては。
今度見てみる。聞いてみておきます。
三宅のところはどんな感じ?
弊社はですね、QAチームっていうのがいまして。
チーム横断型のというか、さっきこすたが言ったみたいに、一つのQAチームっていうところから各授業チームみたいなところに派遣されていって、各チームのQAを手伝うみたいな。
QAエンジニアの方がいて。
ある程度開発が終了してきたら、QAエンジニアの人にコンタクト取って、何日までにQAを終わらせたいんですけど、これくらいのスケジュールで進めていただけますか?みたいなところをやって。
それが新しいプロダクトとかだと、ある程度仕様の説明とか。こういう動きをしますみたいな。
そしたらQAの人がテストケースっていうのを考えてくれるんですよ。
そういう意味では、エンジニアがテストケースを作るよりは、ちゃんと専門というか経験のある方がやってくれているので、または緻密なテストケースが作れているんじゃないかなと思う。
それをエンジニアとか、PDMとかもレビューするみたいな感じのテストケースを。
良さそうですねってなったら、QAを進めていくっていう。
QAでスケジュールカツカツでやってたりもするので、バグが出たらすぐエンジニアの方で引き取って直していくみたいな感じで進めてて。
なのでQAとバグフィックスが同時進行で進むみたいなことが結構ありますね。
そしたら回帰テストどうするんだみたいな話もあるかもしれないんだけど、
そこらへんのエンドツーエンドのテスト自動化みたいなのをしてるから、またバグで修正してQA環境にデプロイしたら、またもう一回その自動化のツールでテストをかけるみたいな感じのことをして、ある程度品質担保してるみたいな感じかな。
21:07
感じてくれてたらわかるよみたいなね。
そうそうそうそう。みたいな感じでやってますかね。今のところはいい感じに進んでいるような気がする。
でっかいSIRとかだと、うちの部署がそうだったようにそこをやりきれるかどうかっていう話が難しくなるけど、
ミヤチンとかみたいに結構メガベンチャーというかさ、割と大きくていろんなアプリとかサービス作ってるんだけど、作ってるからQAチーム持ってるみたいなところが一番バランスよく、品質を均一にというか、品質保証をしながらやる規模とか動きやすさ的に一番良さそうだなって感じがしたい。
なるほどね。まあそんな感じですね。なのでやっぱりバグ出る前提で。
QAする時間プラスアルファバグフィックスをする時間プラス第2回目のQAをする時間っていうので、ある程度バッファーを持ってスケジュールを組むところをやってますよね。
なので排水の陣でやらないっていうのは大事ですよね。
前の僕らの会社は割と排水の陣のプロジェクトが多かったけどね。
ここはね、過去のリスクとかを見た上で、これくらいQAとバグフィックスの期間を持ってないと導入に耐える品質になりませんよっていうところをクライアントなり上の決済者なりに説明するっていうのが
幸せにシステム開発をやるコツじゃないかなと思いますよね。
リーダーとかQAの担当者とかがそれをやってくれるのが一番いいんだろうなって感じはするよね。
開発者がそれを全部お客さんに説明しきってスケジュール確保するの無理だからさ。
そんなところですかね。ちょっと回答になっているかわからないんですけど、僕たちはこんな感じでQAをやっているというような感じです。
はい、じゃあこんな感じでですね。週2回のペースで配信しているので、Apple PodcastもしくはSpotifyでお聞きの方はぜひフォローお願いします。
じゃあ今日はこんな感じで終わりましょう。ありがとうございました。
ありがとうございました。またね。
