「テストコードにはテストの意図を込めよう」の発表報告&補足説明&質問回答 #vstat

先日、「リーダブルなテストコードについて考えよう~VeriServe Test Automation Talk No.3~」というイベントで登壇してきました。

veriserve-event.connpass.com

今回は発表内容に対する補足と、発表に対していただいた質問に回答します。気になるところだけでも読んでもらえればと思います。

目次

発表内容

私の発表スライドはこちらです。

speakerdeck.com

他2人の発表スライドはこちらになります。

speakerdeck.com

speakerdeck.com

伊藤さんによる登壇報告の記事はこちら

blog.jnito.com

申込者数は驚異の1000人超え!*1

当日も多くの方に来ていただき、これぐらいの人数の前で発表するのが久々すぎて緊張しました。

そんな中、私が発表して思った感想はこちら

特に、私の発表を聞いて、こういう風に思ってくださった方がいたのは嬉しかったです。

発表に対する補足

発表に対しての補足が2点あります。

【補足1】都道府県のテストについて

こちらのスライドについての補足です。

発表資料15ページ

イベント当日には口頭で補足しながら発表したのですが、このスライドの前提として、どの都道府県がどの地方に属しているかのテストは別にあるとしています。

今回、このような前提にしているのは、あくまでも開発者が話している「地方ごとに送料が変わるのを確認」を表現することを目的としています。

もちろん、送料計算を47都道府県分書いても構いません。ただし、例えば同様に「地方ごとに配送日数が変わるのを確認」という別のテストが必要になった場合、

@Test
public void _青森県の場合送料が1000円 {

}

@Test
public void _広島県の場合送料が1000円 {

}

...(同様に残り45都道府県分行う)

というテストに加え、

@Test
public void _青森県の場合配送日数が2日 {

}

@Test
public void _広島県の場合配送日数が3日 {

}

...(同様に残り45都道府県分行う)

というテストも行うことになります。(47+47=94通りのテストが必要)

実際にテストコードを作成する場合は、「都道府県と地方の紐付けに関するテスト」と「地方と送料の紐付けに関するテスト」と「地方と配送日数の紐付けに関するテスト」で分けて表現することになると思います。(47+7+7=61通りのテストが必要)

テストの意図が複雑に絡み合っていると、テストケース数が必要以上に多くなったり、将来テストコードを見返した時に何をテストしたいのか分かりづらくなっている可能性があるので、やはりテストの意図を改めて見つめ直してほしいかなと思います。

【補足2】Parameterized Testsへの利用について

こちらのスライドに対しての補足です。

発表資料22ページ

「このような表で整理したならばParameterized Testsにそのまま活用できるのではないか?」という意見がありました。

私としても活用できると考えています。

しかし、その際には同じテストの意図のものだけでParameterized Testsのケースをまとめることを考えた方が良いと思います。

具体的には、表をそのまま移して以下のようなParameterized Testsを作成するのは止めた方が良いです。

@ParameterizedTest
@CsvSource({
    "'テスト太郎', 0, true, false",
    "'テスト太郎', 1, true, true",
    "'テスト太郎', 4, true, true",
    "'テスト太郎', 5, true, false",
    "'', 2, true, false",
    "'テ', 2, true, true",
    "'最大文字数テスト太郎', 2, true, true",
    "'最大文字数を超えた太郎', 2, true, false",
    "'テスト太郎', 2, true, true",
    "'テスト太郎', 2, false, true"
    })
void _予約可否のテスト(String reservedName, int numberOfReservations, boolean isPrint, boolean expected) {
    assertEquals(expected, isReserved(reservedName, numberOfReservations, isPrint));
}

元々整理していた表は、「予約人数に関するテスト」と「予約名の文字数に関するテスト」と「予約番号の印刷に関するテスト」の3つが合わさった表現されています。

そのままParameterized Testsに持っていってしまうと、実施しているテストケースは、これらの3つのどれをテストしたいのか、テストの意図は何なのかが見えなくなります。

なので、Parameterized Testsに持っていこうとする場合も、テストの意図を意識してほしいなと思います。

例えば、こんな感じに一つずつテストの意図を分けた上でParameterized Testsに持っていくのは良いと思います。

@ParameterizedTest
@CsvSource({
    "0, false",
    "1, true",
    "4, true",
    "5, false"
})
void _予約人数が1名以上4名以下の場合予約できる(int numberOfReservations, boolean expected) {
    assertEquals(expected, isReserved("テスト太郎", numberOfReservations, true));
}

また、先ほど示した送料の事例の場合、仮に東北地方と関西地方で同じ送料500円だったとしても、東北地方と関西地方の都道府県をまとめて1つのケースにしてParameterized Testsに変換しようとするのは良くないです。

テスト設計技法の言葉で言えば、同値分割法における同値クラスが何なのか考えてみるのが大事だと思います。

いただいた質問の回答

今回は参加者が多かったこともあり、事前や当日にたくさんの質問をいただきました。そちらにも回答していきます。

【質問1】リーダブルなテストコードの勉強方法はありますか?

例えばTDDBCに参加してみるのはいかがでしょう。

devtesting.jp

このイベントではTDDの体験も重要ですが、コードレビューを貰えるのも貴重です。

私がTAとして参加している場合は、今回の発表のようにテストコードやテストメソッド名についての指摘が多めになりますので、機会があればぜひ。

【質問2】テストコードのメンテナンスをするにあたってのリファクタリングの頻度はどれくらいか?

個人的には、「さあ、リファクタリングをしよう」と思っていたら負けだと思っています。

特にUnitテストの場合、常にリファクタリングして、テスト実行してる習慣になっていることが大事かなと思います。

リファクタリングの頻度を学べる動画はいくつかありますが、TDDBC Online #1 でのt_wadaさんの基調講演と、TDDBC Sendai Xのペアプロデモは特にオススメです。

youtu.be

youtu.be

【質問3】レビューをする際、機能自体のレビューにかけた時間に対してテストのレビューにかける時間はどのくらいの割合で行っていますか?

レビューの目的によります。

例えば、私の場合はテストコードがほぼ100%に近いぐらいの割合で見ると思いますが、それはレビュアーが私だけでないため、他の人がプロダクトコードのレビューをしているから実現できているだけだと思っています。

全ての人を合わせて見たときの割合というのは計測したことが無いので分かりません。申し訳ないです。

【質問4】どれが非効率な自動テストなのかが分からない状態(自動化したテスト仕様とマッピングがない)の場合、何から管理すれば良いか。

まずは管理云々の前に、それぞれの自動テストが何をテストしたいものなのか明らかにするところからではないかと思います。

【質問5】テストファイルの構造について。1つにまとめる?複数作る場合はどんなファイル構造?

E2Eテストの場合、featureごとにまとめたいです。

ファイル構造については、『The BDD Books - Formulation』に案が載っているのでそちらも参考にしてください。現在、鋭意翻訳中です。

leanpub.com

【質問6】レガシーな巨大リポジトリにテストを追加しようと思って二の足を踏んでいるのですが、どういったファイルからテストを書いていますか?また、どうすればレガシーコードにテストを導入しやすいでしょうか?目的や優先度、テストの書き方など、考慮すべきポイントがあれば教えて下さい。

まずは、「一番外側の振る舞いをテストで抑える」やり方と「内側の中で一番リスクがありそうな部分(例えば金額計算)からテストを書く」やり方があるかと思います。具体的にはケースバイケースだと思います。

レガシーコードに対してどのように書いていくかについて詳しくは、手前味噌になりますが、技術同人誌を以前に書いたのでそちらも参考にしてください。

leanpub.com

【質問7】テストを書いた時に、テストのコード量に応じて仕様変更に対して動きが重くなると思いますが (テストを沢山直さないといけない)これは仕方がない事なのでしょうか?何か工夫はありますか?

仕方のないこと、というよりも良いことだと思います。

なぜなら、そのようなテストがない場合、成功するかもしれないテストも含めて手動でテストを実行しなければいけなかったり、テストしなかった結果リリース後に大きな問題に発展するかもしれません。

それらに対して、「失敗したと判明したテストのみを対象としてテストもしくはプロダクトコードを直す」という作業は比較的コストが安い行動であり、幸せなことかと思います。

【質問8】意図が伝わるという観点で、テストコードには積極的に日本語を含めたほうが良いのでしょうか?コメントで補足するくらいなら日本語を含めよう、みたいなポリシーはありますか?

発表中にもお伝えしましたが、難しい英語で書いて伝わりづらいのであれば、テストメソッド名は日本語にした方が良いと考えています。

あとはプロジェクトでのチーム構成によります。全員日本語話者であれば日本語で良いと思いますし、OSSのように全世界でメンテナンスされていく場合は英語で書いた方が良いと思います。

【質問9】そもそもテスト設計はどのように管理されていますか?システムもしくはExcelMarkdownなど。

現在の所属での話ではなく、今までの経験上の話になりますが、

という感じです。これらの成果物のURLをJiraのチケットに貼っておくような運用を取ることが多かったです。

おわりに

今回は「リーダブルなテストコードについて考えよう~VeriServe Test Automation Talk No.3~」のイベントの補足的なことを書きました。

この記事を見てさらに聞きたいことがありましたら、Twitterにリプライを投げてください。よろしくお願いします。

*1:しかも私はほぼ宣伝をしてない…!

BDD/ATDDを学ぶ上で最適な書籍『The BDD Books - Discovery』を翻訳して出版しました! #bddbooks

2018年2月に出版された『The BDD Books - Discovery』日本語に翻訳してLeanpubにて出版しました!

表紙はこんな感じ。

書籍紹介および購入はこちらから。

leanpub.com

原著はLeanpubおよびAmazonにあります。

本書籍(翻訳版)は、今までと同様Leanpubを利用しています。

今までLeanpubを利用して出版した書籍はこちら。

nihonbuson.hatenadiary.jp

本記事では、この本がどんな内容なのか、そしてどんな想いで翻訳・出版に至ったかを書きます。

どんな想いで翻訳・出版に至ったか

想いについては、本書の訳者まえがきに書いた内容を一部抜粋して紹介します。

訳者まえがき

読者の皆さんは、「BDD」「振る舞い駆動開発」と聞いて、どんなことをイメージするでしょうか?

「Given/When/Then を用いた方法」というイメージを持つかもしれません。 テスト自動化やプログラミングを連想するかもしれません。結果として、本書籍の読者対象が開発者専用というイメージを持たれるかもしれません。

ただし、それは違います。 特に、3 冊ある「The BDD Books」シリーズの 1 冊目である本書籍は、開発者やテスターだけでなく、PO やビジネスチームの方々にも読んでいただきたい本です。

本書籍は、「business」という単語が非常に多く出てきます。 これは、単なるプログラミング手法としてではなく、どのようにビジネスチームと一緒に製品を作り上げていくのか、しきりに考えているためです。

(中略)

BDD やテスト自動化と聞くと、まずはどのように自動化のコードを書くのか考えがちです。本書籍ではそのような現状に対して警鐘を鳴らし、その前に考えるべきものを明確に示しています。 著者は、本書籍の範囲である「Discovery」の段階で、冒頭書いた「Given/When/Then」を使用することに拘ってはいけませんと言っています。(詳しく は第 2 章「構造化された会話」をご覧ください)

先ほど書いたように、本書籍は 3 冊ある「The BDD Books」シリーズの 1 冊目です。 本書籍は要件定義の段階の話が多く、コーディングの話は 3 冊目の『Automation』で多く語られると予想しています。しかし、1 冊目から読むことを著者は強く推奨しています。私も同じ意見です。なぜならば、仮に 3 冊目の「Automation」を読んで、自動化できたとしても、得られるメリットは非常に限定的だからです。

BDDやテスト自動化において、本書籍のような部分を説明している書籍に出会うことは非常に少ないです。特に、日本語で書かれている書籍で限定すると、ほとんど無いに等しいでしょう。なので、私は翻訳することにしました。

また、本書籍の第2章「構造化された会話」で、WIMPチームという具体的な事例を用いて説明している点が素晴らしいです!これは、「具体例を用いて説明することこそ重要である」というBDDで大切にしている考え方を、本書籍自身が体現しているといっても過言ではありません。

そのため、読者の皆さんも(開発者/テスター/PO/ビジネスチームのメンバーのどなたでも)、きっと楽しく読み進めることができるはずです。

(中略)

最後に、本書籍を読んで、BDDをしている方々やこれからBDDを始めようとしている方々のお役に立てば幸いです。

訳者まえがきの補足

Agile, DevOps=自動化?

AgileやDevOpsというと、どうしても「自動化」がセットで語られることが多いです。

AgileやDevOpsでのテストの事例を探すと、すぐに「自動テスト」についての事例を見つけることができるでしょう。

「自動化」「自動テスト」は確かに重要です。しかし、AgileもDevOpsも自動化が全てではないはずですし、それ以外にも大切にしていることがあるはずです。

例えば、DevOpsDays Tokyo 2021にて、DevOpsDaysの創始者であるPatrickは下記のように語っていたようです。(kobaseさんのブログ記事より引用)

「DevOps=自動化」と結びつけられている時がある 元々の意図はそこではなかった

「DevOps Interview with Q&A」のメモ #DevOpsDaysTokyo 2021 - 名前考えるの苦手

本書籍も同様に、自動化だけでなく、それ以前に考えるべきことがあると教えてくれています。特に、SpecFlow(ATDD/BDD フレームワーク)の作成者かつメインコントリビュータと、『The Cucumber for Java Book』の著者が本書籍を書いていることが素晴らしいです。つまり、「もっと自動化ツールをどんどん使おうぜ!」と言いがちな立場の人たちが、「自動化ツールを使う以前に考えるべきことがあるだろ」と言ってくれているのです。

本書籍は「The BDD books」シリーズの1冊目

Cucumberのサイトでは、BDDで行う上で、ユーザーストーリーから動くソフトウェアができるまでの過程を、3つのプロセス「Discovery」「Formulation」「Automation」に分けて説明しています。

参照元:Behaviour-Driven Development

「The BDD books」シリーズでも、この3つのプロセスに当てはめて書かれています。

今回の『The BDD Books - Discovery』は1冊目として上記の画像の「Discovery(発見)」に焦点を絞って説明しています。

日本語書籍の少なさ

訳者まえがきで次のように書きました。

BDDやテスト自動化において、本書籍のような部分を説明している書籍に出会うことは非常に少ないです。特に、日本語で書かれている書籍で限定すると、ほとんど無いに等しいでしょう。

同じような感想を、今回の書籍のレビュアーにもなっていただいた @goyoki さんもツイートしています。

一方で、日本国内でもATDD(受け入れ駆動開発)の利用事例が増えていると感じています。

そこで、ATDD, BDD(振る舞い駆動開発), Specification by Example(SbE, 実例による仕様)といった分野についての本を翻訳しようと考え、数ある中から本書籍を選びました。

謝辞

本書籍の日本語翻訳版を公開するにあたり、今回も下記のたくさんの方々にサポートいただきました。本当にありがとうございました!

  • 浅黄友隆(@tom_asa)さん
  • 井芹洋輝さん
  • 末村拓也(@tsueeemura)さん
  • 東口和暉(@hgsgtk)さん
  • 根本紀之(@nemorine)さん
  • てらひで(@terahide27)さん
  • @koma_koma_dさん
  • 石田礼(@movrish)さん
  • 伊藤由貴(@yoshikiito)さん
  • きょん(@kyon_mm)さん
  • 山口鉄平(@teyamagu)さん

さいごに

繰り返しとなりますが、本書籍は開発者・テスターのみならず、POやビジネス関係者にもおすすめの本です。

内容も一部会話形式になっており、非常に分かりやすいと思いますので、興味のある方はぜひご購入の検討をお願いします!

Developers Summitで発表しました #devsumi

ここでの報告が遅くなりましたが、先月、Developers Summitで発表をしました。

発表内容

発表資料はこちら

speakerdeck.com

2022/04/24追記:講演動画はこちら(動画視聴にはCodeZineのログインが必要です)

codezine.jp

今回は二部構成にしました。

第一部「Agileの中で行われるTesting活動」

第一部では、さらに2つに分けて紹介しました。

「Sprint開始前に行う活動」では、実例マッピングを取り上げて紹介しました。これは、Scrum Fest OsakaやDevLoveでも発表した内容に少し追加して話しました。

「テスト活動面に注目したScrumの例」では、実際にScrumでテスト活動を取り入れていくとどのような形になるのか、一例を紹介しました。

第二部「Agile Testingとは特別な存在なのか」

第二部では、下記のようなAgile Testingの年表を紹介しつつ、1998年以前にあるTesting活動ではAgile Testingで言われているようなものと同じような考え方が存在していなかったのか考察しました。

次の登壇に向けて

今回は上記のような構成で話した結果、聴講者の満足度は高かったようです*1

ただし、第二部については時間の都合で語りきれなかったというのが正直なところです…。

なので、この第二部の部分をさらに掘り下げた発表を、Scrum Fest Niigataのプロポーザルとして提出しました!

confengine.com

第二部について興味のある方、プロポーザルが万が一通った場合は、Scrum Fest Niigataでお待ちしてます。

www.scrumfestniigata.org

*1:アンケート結果からの判断

QA(テスター)が開発工程の上流に参加して実際に行うこと

はじめに

本記事は、ソフトウェアテストの小ネタ Advent Calendar 2021の24日目の記事です。*1

目次

QAが開発工程の上流に参加する目的はインプット?

近年、単にテストをするだけでなく、「要件定義レビュー」「設計レビュー」「リファインメント」「Planning」といった開発工程の上流(早い段階)にQA(テスター)も参加する話を聞くようになりました。

しかし、その際に下記のようになっていないでしょうか?

レビュー時にQAは聞いているだけ?

レビューをインプットの場ではなく、フィードバックを与える場にすべきだと個人的には思っています。

QAによるフィードバックの例

とはいえ、「レビューの時やリファインメントの時にどういう風にフィードバックすれば良いの?」と疑問に思っている方もいるかもしれません。

そんな方に、参考になりそうな動画を見つけたので共有します。

youtu.be

この動画の4分6秒あたりから、スリーアミーゴスミーティング*2の例があります。

英語の動画ですが、比較的平易な英語なので、理解はしやすいかと思います。また現在、日本語字幕を選択できるようにしてもらう設定追加を動画の管理者にお願いしています。

より価値のあるミーティングにするためのポイント

ここでのポイントは2点あります。

  • 具体的な例を用いて議論する
    • 具体的な例で話さないと、「何となく良さそう」と錯覚してしまいます
  • 何を確認すれば、今回のfeatureがOKなのか意識する
    • 後の受け入れ基準になる可能性があります

特に、2つ目のポイントはQAが得意な分野(のはず)です。

スリーアミーゴスの参加者は、それぞれで注目ポイントが異なります。

  • PO…今回のfeatureで実現したいことに注目している
  • 開発者…今回のfeatureはどのようにすれば実現できるかに注目している
  • QA…今回のfeatureが「完成した」と判断するためには、何を確認すれば良いのかに注目している

これはあくまでも得意分野なだけであり、完全に担当を分けているわけではありません。例えば、開発者が「実現したいこと(POの得意分野)」について考えても良いですし、POが「何を確認すればOKなのか(QAの得意分野)」について考えても良いです。

しかし、QAがこの得意分野を活かしてフィードバックをすることで、会全体がより価値のあるものになると思います。

おわりに

今回は、開発工程の上流でQAがフィードバックをする方法について、動画も踏まえて紹介しました。これからの業務に役立ってもらえれば幸いです。

ちなみに、今回紹介した動画はCucumber Schoolというサイトの第1章をYoutube上に公開しているものになります。

cucumber.io

こちらのサイトでは、CucumberというBDDツールを使う以前に考えておくべきことを動画を使って紹介しているので、CucumberやBDDツールを使わない人や、QA、POなどにもオススメのサイトです!*3

こちらのサイト内の動画も、随時日本語翻訳できればと考えていますので、「まだ英語しかないから…」と思っている方も、日本語字幕がついた際にはぜひご活用ください!

*1:1日遅れましたが、24日目の記事です

*2:開発者、QA、POの代表者が参加する要件定義段階のミーティング

*3:以前の記事でもそうでしたが、BDDツールの前段の部分の重要性をCucumberというBDDツールのコミュニティが積極的に行っていることは非常に価値があると思っています! nihonbuson.hatenadiary.jp

複数条件が関わる題材を用いてテスト設計から自動テストのケース作成まで考える(後編)

はじめに

本記事は自動テスト・テスト自動化 Advent Calendar 2021の24日目の記事です。

今回はとあるお題に対して、テスト設計からテスト実装、そして自動テストまで作成してみることで、私が普段どんなことを意識しているか記述します。

後編である本記事では、自動テストに適用した場合の話を書きます。

前編はこちら。

nihonbuson.hatenadiary.jp

発表スライド&発表動画

speakerdeck.com

www.youtube.com

目次

  • はじめに
  • 発表スライド&発表動画
  • 目次
  • 今回のお題
  • 前編での成果物
  • PICTを使ってテスト総数を減らしてみる
    • 欠点1:網羅しているのはあくまでも二因子間だけである
    • 欠点2:有則な条件でPICTを使うと、見逃してしまうケースが出てくる可能性がある
    • 欠点3:テストに失敗した際、何が原因なのか分かりづらくなる
  • テスト設計の内容は自動テストの理解容易性にも影響する
    • このPICTの組み合わせをそのまま自動テストで表現する
    • デシジョンテーブルの例を活用して自動テストで表現する
  • おわりに
  • 参考文献

今回のお題

お題:座席順番待ちシステム

続きを読む

複数条件が関わる題材を用いてテスト設計から自動テストのケース作成まで考える(前編)

はじめに

本記事はソフトウェアテスト Advent Calendar 2021の22日目の記事です。

今回はとあるお題に対して、テスト設計からテスト実装、そして自動テストまで作成してみることで、私が普段どんなことを意識しているか記述したいと思います。

前編である本記事では、テスト実装までの話を書きます。

発表スライド&発表動画

speakerdeck.com

www.youtube.com

目次

  • はじめに
  • 発表スライド&発表動画
  • 目次
  • 今回のお題
  • 因子水準を考える
  • 因子水準表を元に全組み合わせを書く
  • 予約番号の印刷を任意にする
  • 名前に関する条件と人数に関する条件を別表に分ける
    • 名前と人数の条件を掛け合わせる必要もあるのでは?
  • 人数の同値クラスを考える
  • 合計人数という因子を追加する
  • ここまでのまとめ
  • テスト観点との関係性について考える
    • 初期のテスト観点
    • 無則な観点を削った場合
    • 人数の条件でまとめた場合
    • 合計人数の条件を含めた場合
  • 別のテスト技法を用いて考える
  • テスト設計の成果物を元に、テスト実装を行う
    • ポイント1:テスト設計番号と対応させている
    • ポイント2:テスト設計とテスト実装は1:1の関係ではない
    • ポイント3:テスト設計では省略している内容(実装実施時要検討事項)がテスト実装では現れる
  • まとめ
  • おわりに
  • 参考文献

今回のお題

お題:座席順番待ちシステム

続きを読む

【翻訳記事】テスト自動化の対象となるテストシナリオの整理に役立つBRIEFの原則

はじめに(翻訳記事の前提となる知識など)

本記事は自動テスト・テスト自動化Advent Calendar 2021の7日目の記事です。

最近、BDDなどでのテスト自動化を行うにあたり、Discovery(発見)*1→Formulation(定式化)→Automation(自動化)という流れが考えられるようになりました*2

記事「Behaviour-Driven Development」内の画像を引用し翻訳

この中の「定式化」では、後に自動化するテストシナリオの整理を考えます。*3

テストシナリオを作成する際に、ただ単にGherkin記法(Given/When/Thenなどを用いた記法)を利用するだけでは、保守性の低いテストシナリオが作られてしまいます。

そこで今回は、保守性の高い状態でテストシナリオを記述する際に役立つ原則「BRIEFの原則」について書かれた記事「BRIEFの原則を保った状態でシナリオを書いてください(原題:Keep your scenarios BRIEF)」を翻訳して紹介します。*4

cucumber.io

具体的なテストシナリオを使った解説は、書籍『Formulation』を読んでください*5

*1:以前に紹介した「実例マッピング」は発見フェーズの具体的なプラクティスの1つになります。 nihonbuson.hatenadiary.jp

*2:個人的には、この考え方はISTQB(JSTQB)の「テスト分析→テスト設計→テスト実装」というテストプロセスの考え方に近いかなと思っています。細かく考えると違いはあるのですが…。どちらにせよ、自動テストを考える前に自動テストの対象となるテストシナリオを整理することが重要だという考え方を主張しているのは良いことだと思います。しかも、「Cucumber」という、「BDDで自動化をどんどんしようぜ!」と言いそうなコミュニティがこういう主張をしていることは非常に価値があります。

*3:なお、仮に「自動化」を行わなかったとしても、「発見」「定式化」をすることは非常に価値があると、オリジナルの記事を書いたSebは自身の著書の中で述べています。私も同じ意見です。

*4:翻訳にあたり、著者本人の許可をもらいました。Thank you, Seb!

*5:現在は英語版しかありませんが、日本語翻訳版も検討しています

続きを読む