)お叱り!翻訳をやり始めると悩みが出ます。DeepLとどう付き合うかです。最近のDeepLはかなり精度がよく、日本語もしっかりしているため、翻訳時にかなり使っていました。自分の訳がDeepLを越えられないことも多く、結構な部分をdeepLの翻訳に頼っていました。したところ、レビューアのマスから「DeepL臭がプンプンするぜっ!!(JOJO風)」というお叱りを受けました。マスのお叱りマス、カズさんの最強コンビからの指摘を受け、自然な日本語になるようにかなり検討しました。今のところ、「DeepLはいい訳を出すけど、自然な日本語になるにはもう少しかかりそう。頼りすぎると、自分で日本語を考える力が奪われそう」というのが自分の結論です。翻訳時に気を付けたポイント自分が翻訳時に気を付けたポイントBEST3を書き留めます。Youを省略したいため、受動態が多いですが日本語だとちょっと違和感があります。「レビューは実施される」みたいな訳です。日本語としてもあっていますが、ちょっと違和感がありますよね。自分の中では、使い分けをしていて、自チームや自組織などコントロールできる箇所は能動態にしました。アンダーコントロールなものは受動態にしています。これはカズさんに多く指摘されましたが、主語と述語がねじれていることが多くありました。一文を主語、述語のみで読んでみると違和感を感じることができます。日本語にしたときのテンポを気にしました。助詞や動詞も含めて音がまどろっこしいところなどはスッキリするように直しました。関係代名詞で繋いである長文は、前から訳しつつ、途中で切って長くならないように修正しました。自分が翻訳でかなり悩んだ個所を載せておきます。下記の例文は第16章のレビューの推奨手法の章の一文です。[Yad17].deepL訳(2021/12/10翻訳)このことは何十年も前から分かっていたことですが、未だにレビューに費やす時間はほとんどの場合、悪いコードを書き直すのに必要な時間よりも短いと信じていない開発者がたくさんいます[Yad17]。nemorine訳このことは何十年も前から分かっていたが、多くの開発者は「レビューに費やす時間は、ほとんどの場合、悪いコードを後から修正する時間よりも少ない」ということを信じていない[Yad17]。ここは「短い」「信じていない」「たくさんいる」と続き、なかなか上手い訳になりませんでした。カッコを付けるとスッキリしたのを覚えています。いうことで、組版ができてからも何度も読み返し、ギリギリまで頑張った甲斐があって、自分として納得できる日本語訳ができたと思っています。いつか翻訳に挑戦したいと思いました!流れ弾ちなみに翻訳が終わりそうなときにこんなTwitterが流れてきて、あやうく死にかけました。><この翻訳は、翻訳ソフトを使った翻訳ではないかという疑いです。2021年10月11日この場を借りて、キチンと言ってくれたマスとカズさん、誘ってくれたみずのりに感謝したいと思います。付き合ってくれたオーム社の石田さんにもめちゃくちゃ感謝しています。教育Twitterで見かけて買って読みました。難しすぎる問題(パニックゾーン)をやらせても成長しない。これは大人も同じだと思う。子育てと職場の両方で思い当たるフシがあり、反省しすぎて死にそうです。2021子供に対する親の間違ったやり方を優しく指摘してくれる本だと思います。理論がキチンとしているので納得感が違います。言語化できていなかったところや、心理学、ゲーミフィケーション、アンガーマネジメントなどが簡潔に述べられているのでとても良い本だと思いました。リファレンスがガッチリついているのも嬉しいですねーこれは新人育成とかに悩んでいる方にも必要な本だと思います。Amazon自分がグッときたところ「人は自分の力を大幅に超えるものにチャレンジしても成長できない」これは以前のチームのときからずっと思っていました。自分は「人が学ぶには段階」があるという認識をしていたのですが、それと同じことが書かれていました。この本では3つに分けています。パニックゾーンは学習できないとのことです。ここがいいところパニックゾーン・・・過度なストレスパニックゾーンは会社の業務のみならず、スポーツも同様で、スノーボードで自分の力量を超えた斜度で滑っても全く上手くならないんですよね。実体験としてイメージできます。脳は2階建て川口さんに教えてもらったファスト&スローに載っている脳のシステム1、システム2の話が出てました。2階の脳は建設中なのでときどき不具合を起こすのは当然なので大目に見ること。以下の「す・い・さ・つ」のときは2階の脳は働きにくくなるとのことです。:お腹がすいているい:いらついているさ:さびしいつ:つかれているお腹すいてるとホントに無理です。結果ではなく、行動に注目することコントロールできない結果ではなく、コントロールできる行動に着目してくださいということが書いてました。結果はどうあれ、行動ができていればまずはOK、褒めるときも行動を褒めるというスタンスがとても良いと感じました。自分はKPTなどのふりかえりのTryで結果系と行動系を意識するようにしています。テスト自動化JaSST東北で一緒に活動している伊藤さん(ぷっちゃん)がエバンジェリストとして登場するということで途中から参加しました。いいことが沢山あったので、メモを書き残しておきます。自動化で工数削減できますか?工数削減をメインにすると変な方向に進む。どこをターゲットにするか明確にできれば削減自体はできる。自動化によってテスト実行を削減できたぶん、メンテに人がかかることがある。テスト実行工数は夜間実施や並列実施で時間が減る。無駄がいっぱいあるようだと見た目の工数削減はできる。自動化で品質が上がりますか?テストで品質が上がりますか?と同じ質問。現状認識するところが自動テスト。その後で開発が頑張ることで品質が上がっていく。Podなど)が強いと感じている。SaaSの場合、環境構築やメンテで躓かないのが良い。テストピラミッドから考えて、単体テストが充実している場合はAPIテストを飛ばすのもありでしょうか?正直ケースバイケーステストピラミッドはたたき台と思っているので、自分達で納得感を持ったピラミッドを作ることが重要。SaaSが普及した場合は、テスト設計するより、SUTを操作しながら探索する方法が優位になるでしょうか?優位になるかは必ずしもそうではないと思う。テスト設計をすることで、チームの品質に対する共通認識が得られる。探索的テストがやりっぱになっている場合は安心感が得られない可能性はある。mablのオンプレ版のリリース予定はありますか?いまのところなし。ツールは手段でしかないと思いますが、ツールを使うことが先行してしまう場合もありませんか?個人レベルでは手段先行もありかと思う。使ったことがない人とかには効果的だと思う。アジャイル開発と自動テストの関係性についてどう思いますか?(会場内のアジャイルテスター比率は2/150)名乗っていないだけではないか?マルチロールで大変なイメージ。自動化エンジニアもアジャイルテスターの一つではないか。[藤原さん]海外で一番人気なのはコンサルさんとそれを利用する会社のセッション。[藤原さん]前職で手動でも早くテストを実施して、開発と一体化していたのはアジャイルテスターだと思った。テスト自動化が上手くいくのはどういうケースでしょうか?時間をしっかりかける。リーダーシップを取る人が少なくとも一人は必要。運用にのせたらメンテをする。プロジェクトの最初から自動化の算段を立てる。QAが自動化するのとエンジニアが自動化するのとどちらがいいでしょうか?ユニットはエンジニア、E2EはQAがいいかも。理想の形が組織ごとにある。人数比も影響ありそう。自動化の比率はどれくらいが適切なのでしょうか?完全自動化はありますか?操作しやすい比率なので気を付けないと恣意的になる可能性がある。体感の参考値は既存テストケースの3~4割が自動化すると一段落する感じ。テスト全体の中のスコープやテスト目標をどう決めていますか?リーン開発の現場より、テストのリスク、手動テストのコスト、自動化のコストを考え、優先順位をつけてどこまでやるかを考える。手がけるテスト自動化と手動テストや他の自動テストとの相乗効果を生み出すためには?(技術的なレベルでは)CIパイプラインを構築する。E2Eの流れを考えて重複を避け、前のレベルでできていないところをカバーする。*1手動で影響範囲を出すか機能的に重要なところか。実行を効率化して、変更ごとにすべてのテストをやるという方向もある。新規開発のときは動くものが後ろになるため、E2Eの自動化が難しいと思います。SaaSを使って、書き捨てでもいいから対応してしまうというのは一つの手だと思う。1回目は手動、2回目は自動。[藤原さん]自動化をする過程のときに、探索的な手動テストをやってしまう。自動化エバンジェリストになるために必要なスキルは?色々な対象の自動化を知るのが第一歩。事例としてもっておくだけでも良い。エバンジェリストは実装技術でトップである必要はない。ありがとうございました!*1:たぶんGoogleの話。Micco氏が回帰テストの自動選択の話していました。読者になるこのブログについて検索リンクテストする人。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。