ある程度できるようになったときに、その組織をどうやって大きくするか。出来る人をどうやって増やすか。開き直って新人をどんどん投入した。新人は「こういうものだ」というと素直に聞いてくれるので、良い開発プロセスになっているところに新人を投入。中堅を入れるときはその人次第。頑固な人は頑固だし、素直なひとは素直だし。自分に権限があったので、強く言い続けた、というのが大きい。立場上上だった、というのが一番大きいと思う。Q3届いたデバイスが思い通りにうごかない、エミュレータとちがった、という場合にどうやったか。Layer1の担当者がプログラムのデバイスドライバを作る。実際のハードウェアで動きが違ったときにどうするか、それを担保しないといけない。Layer1のひとたちだけが、実機でもテストをしていた。実機とエミュレータの違いがあったら、エミュレータに必ず反映していた。実機で問題が起こってエミュレータで起きない場合、エミュレータでも同じものが「起きるように」変更していた。そこより上のレイヤーの人たちが実機を使わなくていい、ということを担保していた。せきさんA4困難は困難でわかっていたが、実際にはあんまりマルチスレッドしてない。実際にはちょこっとだけスレッド使ってやろう、ということでやってた。Q5システムテストレベルまで全部自動化すると、Flaky対策。テストコードとプロダクトコードの品質のバランス。(伊藤注:この質問を聞き取れず。)A5かなりFlakyは出てくる。テストコードも製品コードと同じくらい作りこむ、リファクタリングするというのが大前提。Goのチャネルを使ってうまいことマルチスレッドできるんじゃないかと思ってGoを使ってみた。それでもやっぱりデッドロックとか、Flakyな部分はよくあった。ソースコードを見ただけではわからないようなビミョウなタイミングでのバグに遭遇したこともあった。3か月前の改修の影響でたまったまバグが出たこともあった。そのくらい、マルチスレッドはFlaky。開発時代にやっていたことのお話、中々聴けない内容なのでとてもおもしろかった、というのがまず1つ。あと,やっぱりJasst全体通して感じたのは、「品質良くするために自分たちで環境含めて工夫してる」ということ。ツールの開発をするレベルから。GoogleのJohnMicco氏の講演もそうだったのですが、よいものを作るために何をすれば良いかを常に考えて、それを実践しているのが当然、なんですよね。柴田さんのお話にもあった、開発へのフィードバックをなるべく速くしたほうが良い→じゃあテストファーストだな、とか。自分たちで改善をして“当たり前”を常にアップデートしている組織(個人)と、昔からの当たり前を引きずっている組織(個人)で、ギャップがとてつもなく開いていることを実感しました。Ito都内でテストエンジニア&ブロガーをやっているyoshikiitoです。ソフトウェアエンジニアの学習方法や成長するための考え方、会社に依存せず自分の力で生きていけるエンジニアになる方法などについて興味があります。仕事は主にソフトウェアテストやテスト自動化。趣味は浦和レッズと読書と技術書を買って積むこと。