こんにちは。QA事業本部 クオリティマネージメント部 QMグループのヤスゴロウです。 私は15年ほど開発エンジニアを経験した後、QAエンジニアになり今年で16年目です。 現在は、QAコンサルタントの業務を担当しております。 開発エンジニアや開発プロジェクトマネージャー（以下「PM」という）からQAコンサルタントの職種に転職することを迷っている方がいらっしゃると耳にしましたので、お役に立てればと思い、熱く語らせていただきます！ なぜ私はQAエンジニアに転身したのか きっかけ はじめに、私がQAエンジニアになった経緯をお話させていただきます。私の場合は自分からQAエンジニアになることを希望したわけでなく、前職で「CMMI( ※1 )を用いたクオリティーマネージメントシステム（以下「QMS」という）の構築プロジェクト」に入ることを上司に薦められたことがきっかけでした。 私は業務システムやアプリケーションの仕組みを考えて自分の思惑通りの出来栄え(品質)に完成させることにやりがいを感じているシステムエンジニア（以下「SE」という）でしたので、あまりの新天地へのオファーに迷いました。しかし一方で、誰もやったことがないことを社内初でチャレンジして広めることも嫌いではなかったので引き受けることにしました。 実際やってみると、様々な学習が必要だったり、開発担当者をなかなか説得できなかったりなど苦労がありました。とはいえ、社内の有識者のお知恵を拝借したり、社外のCMMIコンサルタントの指導を受けたりして、なんとか皆で力を合わせて社内のQMSを構築することができました。 悟り 経験してみて悟ったことは「QAエンジニアがQMSを構築したりプロセスを改善したりすることは、開発エンジニアが業務システムを構築したり改善(保守開発)したりすることと大差がない」ということでした。プロダクトの品質を向上するための仕組み(システム)を考えたり、業務プロセスと同様に品質担保のためのプロセス(手順)を改善・効率化したりする仕事だと分かったら、段々面白くなってきました。システム構築や改善に興味があれば、誰でもできる仕事なのだと悟りました。 飛躍 その後、QMSは運用フェーズに入ったためQMS構築プロジェクトは解散し、気づいたら部門マネージャーと私だけの間接部門で運用・改善することになっていました。1人で多数のプロジェクトの品質を見るのは大変でしたが、更に独学を繰り返し、開発エンジニアの経験を活かして、ソフトウェアエンジニアリングプロセスの詳細まで踏み込み、要件定義プロセス、設計プロセス、テストプロセスの構築(標準化)をほぼ１人で成し遂げました。 　出来上がってしまうと、あとはPDCAをまわしていくだけになってしまいました。それはそれでやりがいがありましたが、開発好きの私は運用だけでは物足りなくなってきました。 それから、社外のセミナーなどにも積極的に参加して有識者からも学ぶ機会があったとはいえ、所詮独学で自信がないところがありました。また、自信がないところがあるのに社内で一番の品質有識者のように扱われるようになってしまったため、もっと本物の有識者と一緒に働いて学んでみたい、自分がやってきたことが間違っていなかったかを確認したい(答え合わせをしたい)と強く思うようになりました。 いざ転身 このような経緯より、某開発会社の間接部門の「自称QAエンジニア」だった私は、独学で身につけたスキルを活かしてQAエンジニアの職を生業にして極めようと思い、AGESTのQAコンサルタント職へ転職しました。 そして入社後、上司の 高木陽平 さんと1on1をした際に、私のテストプロセス改善のアプローチは「かなりいい線いってたことが分かり大満足」でした。現在も多数の有識者や学習熱心な同僚達に囲まれて、希望通り楽しくお仕事をさせていただいております。 QAエンジニアの職務紹介・品質向上に貢献するアプローチの事例 では、ここからは私がQAエンジニアに転身してから経験したQAコンサルタントの職務と私が悟ってきたことをご紹介させていただきます。 開発プロジェクトにおいて、テストで不具合を見つけて解消することも必須ではありますが、テスト工程まで進捗してから修正することだけでは時間の制約など限界があります。 シフトレフト( ※2 )でテスト工程より前の上流工程から不具合を解消していくと手戻り感を削減することができます。 そのためのQAコンサルタントの職務の１つとして「開発プロセス改善」というお仕事があります。「開発プロセス改善」とは、簡単に言いますと「開発工程で不具合を混入しないような手順に変えたり、ルールを強化したりすることである」と私は解釈しております。（これだけではありませんが。） 私は、この「開発プロセス改善」において、開発経験や開発PM経験をかなり活用できております。 以下、「経験が役に立っているな！」と思う場面を「開発プロセス改善」の事例とあわせて２つご紹介させていただきます。 1.不具合の分析結果を用いて開発工程を改善するアプローチ 市場で発生した不具合、テスト工程で検出した不具合、レビューで検出した不具合(指摘事項)を分析して、混入した工程や原因となった問題を特定し、該当工程のプロセス定義（作業手順、ルール等）や成果物定義（標準文書テンプレート、記述ルール、サンプル等）などを改善するというアプローチです。 当然ながら手順やルール等を変えるためには、当事者である開発現場の皆さんとの合意形成が必要です。品質を向上するためには現状よりも重厚な手順（成果物の記述内容を増やす、レビューを必須にする、承認経路を増やすなど）を提案しなければならないことがよくあることなので、かなり開発現場の納得度の高い提案をしないと受け入れていただくことができません。 開発現場の納得度の高い提案をするためには、開発の知見があると有利であると実感しております。例えば、成果物にこういう記述項目を追加するとよいですよとか、そもそもフォーマットがないケースはフォーマットやサンプルを用意して使ってみませんかとか、自分の経験に基づいて相手が欲しい情報を提案しやすいです。 なによりも、開発担当者から「何故このようなことをやらなければいけないのか？」と問われた際は、自分が開発していた時の教訓等を思い出して例を挙げて説得することもできます。例えば、「なぜ要件ベースライン( ※3 )が必要なのか？」と問われた時、下流工程へ進む前にその時点の要件スコープを顧客と合意しておかないと、後工程で要件変更を受け入れざるを得ない状況に陥ってしまうことがある。また要件変更のために設計以降の工程で手戻りが発生してスケジュールを守れなくなったり、変更のタイミングによってはデグレード( ※4 )を発生させてしまったりすることがある、というようなことです。 あとは、開発経験があると開発担当者のツボにあわせた話がしやすいです。「この人開発者の気持ち分かってくれているなー」みたいな感じで反応が良くなったら改善を進めやすくなります。 困っている開発現場には、学術的な指導よりも今やるべきことを一緒に解決してくれるQAコンサルタントの方が喜ばれます。 2.世のベストプラクティスを用いて開発プロセスのギャップを改善するアプローチ もう１つ別の開発プロセス改善のアプローチ方法による経験をご紹介いたします。 タイトルの「世のベストプラクティス」とは、例えばCMMIのような一般的な理想論（モデル等）と実際のプロジェクトや組織のプロセスを比較して、理想通りでない部分（弱み）を洗い出し、そのギャップを改善していくというアプローチです。 参考： CMMI-DEV,V1.3日本語版 （上図は筆者が記載したもの） 正直初めてCMMIのような学術的な書物を読んだ時には解釈が難しくてドン引きしましたが、読み進めているうちに自分の開発経験や開発PM経験に当て込んで解釈すると、なるほどと思えることが増えました。結局やりたいことは開発プロジェクトのプロセスやプロダクトの品質を向上することであって、そのために理想とする方法論等が書いてあるだけなのだと気づき、「なんだ、意外と難しくないぞ！」と思えるようになりました。 私はQAコンサルタント職に就いてからは、世の有識者が難しい言葉でいろいろ書いてくれている書物などを理解して即時に技術を使いこなせるスキル向上は必要であるとは感じておりますが、すぐに全部暗記までしていなくてよいと確信しております。どこにどのような情報があるか自分の頭の中に知識と経験のインデックスを徐々に作って引き出せるようになっていければよいと悟りました。 ですので、QAコンサルタントとしてやっていけるくらいの知識を身につけるためには、自分自身の開発経験や開発PM経験と結び付けて世のベストプラクティスを学び・解釈すれば、そんなにハードルが高いことではありません。開発プロジェクトの経験がある方なら未知の世界のことは１つも無いというのが私の感想です。 QAエンジニアになってから心がけていること 以上、QAエンジニアには開発経験が役立つ例として、開発プロセス改善の主な2つのアプローチによる私のQAコンサルタント経験をご紹介させていただきました。 最後に開発プロセス改善に限らず、どのQAエンジニアの職務においても、私が最も重要だと考えていることをお話させていただきます。「開発現場に寄り添い、共感し、納得してもらう」ことです。 私は第三者的な立ち位置から開発プロセス改善を初めて実行した時は、正直プロジェクト外からアクションしていくのは難しい！と感じました。自分自身が開発プロジェクトに所属している時は、「みんなルールこうしようぜー」と言うだけで変えられたのに、第三者の立ち位置から提言する場合は、あれやこれやと言い訳されてやってもらえない、挙句の果てには「お前分かっているのか？」「お前に何が分かるのだ！」というような勢いで反感を買うこともあります。 このような経験から得た私の教訓は、「開発現場に寄り添うことが必須である」ということです。 開発現場に寄り添うために私がいつも心がけているのは「自分が同じ立場でこれをやれと言われたらどう思うか？」を常に考え、理想論だけを叩きつけないようにすることです。 弊社のようなQA会社にご依頼をいただく案件は、品質に問題を抱えていたり、品質を向上するために苦戦したりしているわけで、開発現場からすると「時間はないが、品質は担保しなければならない」等の難題に悩まされ、場合によっては猛烈疲弊した状態になっていることもあるわけです。このような開発現場の皆さんに対して、どれだけ役に立つ提案や支援ができるかがQAエンジニアのミッション達成のための肝だと考えます。 私が開発エンジニア兼PMだった時、プロジェクトをうまくまわせずに品質問題を起こしてしまったことがありましたし、そのために寝られない日々をたくさん過ごしたこともありますので、開発現場の痛みを理解するように心がけ、自分のような目にあわないようにするための最善策は何なのかを常に考えるようにしています。 時には強い意志を持って開発現場を動かすアクションが必要な場合もありますが、その時は自分の経験を例に出して提言すれば多くの方々が納得してくれます。まず自分が同じ立場ならどう思うか、どうするか、どうしたいかを真っ先に考えるようにしたら、最適解を導き出すスピードが早くなりました。 反対に、開発現場の声を聞きすぎると改善が進まない場合もあり得るので、どうしたものかと考えていた時期もありました。しかし、この開発現場に寄り添った改善活動の進め方を、社外で知り合った有識者より好評いただいたことがあり、その時から自信を持てるようになりました。 「開発現場に寄り添ってくれるQAエンジニア」と言われたら、嬉しいですよね。 まとめ ・QAエンジニアのお仕事は開発経験や開発PM経験を活用できる場面がたくさんある。 ・品質問題で困っている開発現場には寄り添って一緒に解決してくれるQAエンジニアが喜ばれる。 ・開発現場に寄り添えるQAエンジニアになるためには、第三者的な立ち位置であっても開発担当者と同等の当事者意識を持つとよい。 ・開発担当者と同等の当事者意識を持つためには、開発経験や開発PM経験があると非常に役に立つ。 以上、ご参考になりましたら幸いです。 開発現場に寄り添って、開発プロジェクトのプロセスを改善したり、品質向上を支援したりするお仕事を一緒にしてみませんか？ APPENDIX:用語の説明 (※1)CMMI 「CMMIとは、組織がプロセス改善を行う能力を評価する手法および指標。ソフトウェア開発プロセスの成熟度を測る「CMM」を元に複数の同種の手法を統合した汎用的な手法で、米カーネギーメロン大学CMMI研究所が開発、公表している。」 IT用語辞典 e-Words より引用 (※2)シフトレフト 「シフトレフトとは、製品開発などで行われる特定の工程を通常よりも前倒しして実施すること。IT分野ではソフトウェア開発におけるセキュリティ対策やテストなどで行われることが多い。」 IT用語辞典 e-Words より引用 (※3)要件ベースライン 「ベースラインとは、基線、基準線、基準値などの意味を持つ英単語。字義通り、図形などで何かの基準を表す線分を指す用法と、比喩的に、計画や標準、最低限度などを表す値やデータ、状態などを指す用法がある。」 IT用語辞典 e-Words より引用 「要件ベースライン」とはプロジェクトの要件をステークホルダー間で確認し、決まった内容や範囲(スコープ)を基準とすることである。またその基準をステークホルダー間で合意形成することを推奨する。要件ベースライン決定後の変更は変更管理をして、要件通りの品質を担保するためにはスケジュールやコストの見直し等をおこなう必要があることを説明するための根拠として使用する場合が多い。 (※4)デグレード 「デグレードとは、新しいバージョンのソフトウェアの品質が、以前より悪くなること。また、以前修正した不具合やバグが再発・復活すること。新しいファイルなどを古い内容で上書きしてしまい、更新内容が失われることを指す場合もある。」 IT用語辞典 e-Words より引用 The post 開発エンジニアからQAエンジニアに転身して悟ったこと first appeared on Sqripts .

はじめに 前回 は、テスト駆動開発（Test-driven development、以下TDD）とは何か、TDDの目的は何かについて話しました。今回は、振る舞い駆動開発（Behavior Driven Development、以下BDD）が考案された経緯と、specBDDとscenarioBDDという2種類のBDDの違いについて説明します。 BDDの誕生 BDDはDan Northによって考えられたものです。2006年に自身の記事「 Introducing BDD （邦訳： BDDの導入 – Dan North ）」でBDDという考えに至った経緯が述べられています。 Danの考えたBDDでは、TDDのルールから2つの変更を入れました。 ・クラス名やメソッド名から「test」という単語を取り除く ・テストメソッド名は「should」という単語で始める（日本語の場合、『〜〜すべき』という単語で終わる）ようにする これによって、より「振る舞い（特にユーザー視点での振る舞い）」に注目するようになりました。 Danによると、コードを変更してテストが失敗した時には、以下の3つに分類できます。 ・バグを埋め込んでしまった。悪い子だ。解決法：バグを直す ・意図されたふるまいは変わらず関連性があったが、どこか別の場所に移されていた。解決法：テストを移動し、場合によっては変更する。 ・ふるまいがもはや正しくない。システムの前提が変わってしまっている。解決法：テストを削除する。 BDDの導入 – Dan North から引用 このうち、3つ目の解決法「テストを削除する。」に対して、BDDは大きな効果をもたらします。 元々のTDDでは、「testメソッドを削除する」という行動になってしまい、「本当にテストを削除して良いの？大丈夫？」と不安になります。これは前回話した「TDDによって品質を保証している」という誤解によって、testメソッドそのものの削除に対して非常に億劫になってしまっているからです。 一方、BDDではその心理的ハードルを低くしています。「振る舞いが違うのであれば、『should』で始まっている振る舞いの定義を削除した方が良いよね」という考え方に持っていこうとしています。 Liz Keoghは 有識者との議論の中で 、「『テスト』という言葉を使用する際の問題は、誰もが自分が何をテストしているのかを知っていると想定していることです。」と語っています。逆を言うと、BDDは事実を知らないという前提に立ちやすいと言えます。 振る舞いに注目することのメリット BDDによってユーザー視点での振る舞いに注目すると良いことがもう一つあります。振る舞いに注目すると内部構造に注目せずに済む可能性が高くなります。これは、TDDではあまり得られない（得ることは可能だが、なかなか得ることに気付きにくい）効果でもあります。 例えば、自動販売機についてのプログラミングを考えた時、振る舞いに注目していない例として以下のようなテストコードを書くかもしれません。 import org.junit.jupiter.api.Test; import static org.junit.jupiter.api.Assertions.assertEquals; public class VendingMachineTest { @Test void _残高の引き算のテスト() { VendingMachine vendingMachine = new VendingMachine(); vendingMachine.setCredit(500); //500をセットする vendingMachine.minusFromCredit(100); //100を引く assertEquals(400, vendingMachine.getCredit()); //400になる } } これはTDDで書くことによって、プロダクトコードのロジックも作成できます。 ですが、果たしてこのコードは自動販売機を表すことができているのでしょうか？あまりにも内部構造に注目しすぎています。 一方で、ユーザー視点での振る舞いに注目すると以下のように書くことができます。今回は、Given/When/Thenの形で書くことにします。（Given/When/Thenの形をGherkin記法と呼びます。Gherkin記法については第6回の時に説明します） import org.junit.jupiter.api.Test; import static org.junit.jupiter.api.Assertions.assertEquals; public class VendingMachineBehave { @Test void _1000円札を投入後100円のコーラを購入するとコーラと900円のお釣りが出るべき() { //前提(Given) VendingMachine vendingMachine = new VendingMachine(); Coin coin = new Coin(1000); Goods drinkGoods = new Goods("Cola", 100); //動作(When) vendingMachine.insertCoin(coin); //お金を入れる vendingMachine.purchase(drinkGoods); //商品を購入する //結果(Then) assertEquals("Cola", vendingMachine.dispensingDrink()); //商品が出てくる assertEquals(900, vendingMachine.getChange()); //お釣りが出てくる } } これぞまさに、自動販売機での振る舞いであると感じることができるでしょう。 BDDを行う上で大切にすべきこと Liz Keoghは 先ほどと同じ有識者との議論の場で 、BDDを進めていく前提の考えを定義しました。 ・間違っていると仮定する ・どのように間違っているかを理解するために会話する ・十分なフィードバックを得られたら実装する つまり、振る舞いに注目し、認識が間違っているところがないか議論することこそがBDDで大切にしていることだと捉えたのです。 先ほどの、ユーザー視点での自動販売機の振る舞いに注目した例をもう一度見てみましょう。 import org.junit.jupiter.api.Test; import static org.junit.jupiter.api.Assertions.assertEquals; public class VendingMachineBehave { @Test void _1000円札を投入後100円のコーラを購入するとコーラと900円のお釣りが出るべき() { //前提(Given) VendingMachine vendingMachine = new VendingMachine(); Coin coin = new Coin(1000); Goods drinkGoods = new Goods("Cola", 100); //動作(When) vendingMachine.insertCoin(coin); //お金を入れる vendingMachine.purchase(drinkGoods); //商品を購入する //結果(Then) assertEquals("Cola", vendingMachine.dispensingDrink()); //商品が出てくる assertEquals(900, vendingMachine.getChange()); //お釣りが出てくる } } これを書くことで、色々な疑問が出てくるはずです。例えば以下のような疑問が出てくるかもしれません。 ・1000円札の投入は本当に可能なのか？ ・新1000円札と旧1000円札の両方で投入が可能なのか？ ・購入した場合、必ずお釣りが出てくるのか？（お釣りが出てこないで別の飲み物が買えたりしないのか） ・900円のお釣りとは、500円硬貨1枚＋100円硬貨4枚なのか、それとも100円硬貨9枚なのか？ このように、BDDでは振る舞いについて具体的に考えることで、色々な疑問を発見することを大切にしています。 specBDDとscenarioBDD 自動販売機の振る舞いに注目していない例（内部構造に寄りすぎた例）ですが、Danの作った2つのルール「クラス名やメソッド名から『test』という単語を取り除く」「テストメソッド名は『should』という単語で始める（日本語の場合、『〜〜すべき』という単語で終わる）ようにする」を適用してBDDっぽく書くことができます。 import org.junit.jupiter.api.Test; import static org.junit.jupiter.api.Assertions.assertEquals; public class VendingMachineBehave { @Test void _500円から100円を引くと400円になるべき() { //前提(Given) VendingMachine vendingMachine = new VendingMachine(); //動作(When) vendingMachine.setCredit(500); vendingMachine.minusFromCredit(100); //結果(Then) assertEquals(400, vendingMachine.getCredit()); } } このように、内部構造に寄っており実装レベルの仕様を表現しているBDDを、 Behat の作者である Konstantin KudryashovはspecBDDと名付けました。 一方、お釣りについて記述していた例のように、ユーザー視点の振る舞いに注目して表現したBDDを、 Konstantin KudryashovはscenarioBDDと名付けました。 scenarioBDDの別の言い方としてstoryBDDと呼ぶこともあります。 scenarioBDDに対応したフレームワークを用いて、ビジネス関係者にもより分かりやすい記述をする scenarioBDDはユーザー視点の振る舞いを示そうとしているため、ビジネス関係者にも理解してもらいたいという意図があります（詳しくは第4回でお話しします）。 しかし、Javaなどのプログラミング言語を用いてGiven/When/Thenの形で書くだけだと、プログラミング言語特有の記述（例えばクラスの生成記述など）が気になってしまい、ビジネス関係者には理解してもらいづらいです。 そこで、よりビジネス関係者にも理解してもらいやすくするために、シナリオ部分と実装部分を分けて記述するフレームワークが出てきました。その代表的なフレームワークとしてCucumberがあります。 先ほどまで書いていたユーザー視点での自動販売機の振る舞いのシナリオ部分を、Cucumberを用いて書くと以下のようになります。 Feature: 自動販売機 Scenario: 飲み物を買うとお釣りが出る Given 自動販売機がある When 1000 円札を入れる And 100 円の "コーラ" を選ぶ Then "コーラ" が出てくる And 900 円のお釣りが出る この記述ならば、プログラミング言語に馴染みのないビジネス関係者にも理解してもらいやすくなります。 次回予告 今回はBDDの誕生とspecBDD/scenarioBDDの違いについて説明しました。 ただし、今回説明したscenarioBDDは本来考えるべきことのほんの一部に過ぎません。 実際にscenarioBDDで考えるべき具体的なプロセスおよび例については第4回以降に説明します。 次回は、BDDと振る舞い駆動開発(ATDD)/実例による仕様(Specification by Example)との関係性について話していきます。 連載一覧 TDDとBDD/ATDD(1)　TDDはテスト手法ではない The post TDDとBDD/ATDD(2)　2種類のBDD first appeared on Sqripts .

こんにちは。QAエンジニアのTWです。 普段はソフトウェアのシステムテストを行っています。脆弱性診断について業務で触れる機会があり、脆弱性診断に興味を持ちました。この記事では自分で勉強した内容を共有したいと思います。簡単な内容ですが参考になればと思います。 ※本記事の内容は以下の書籍を参考にしています Webセキュリティ担当者のための脆弱性診断スタートガイド (第2版) 脆弱性診断とは 脆弱性とはプログラムの中に作りこまれたバグのなかでデータを書き換えたり、盗み取られることによって悪用されてしまうバグを指します。 これらの脆弱性を発見するためのテスト手法が脆弱性診断となります。代表的な脆弱性としてSQLインジェクション、クロスサイトスクリプティング(XSS)があります。 SQLインジェクションは悪用されるコードを含んだSQL文が実行されることによってデータベースを不正に操作される脆弱性です。この場合、アプリケーションに実装されたSQLの呼び出し方に不備があることが脆弱性であり、データベースを不正に操作されることで機密情報の漏洩やデータを改ざんされる恐れがあります。 クロスサイトスクリプティング(XSS)はWebサイトに設置されたユーザー入力フォームに攻撃用scriptが埋め込まれたままWebページが出力され、そのページを善意のユーザーが閲覧することで偽のページを閲覧させられたり、cookieの情報を取得されたりする脆弱性です。 脆弱性診断はOSやミドルウェアに対して行う 「プラットフォーム脆弱性診断」とWebアプリケーションに対して行う 「Webアプリケーション脆弱性診断」 がありますが 、今回は「Webアプリケーション脆弱性診断」を実行します。 OWASP ZAPとは OWASP( The Open Web Application Security Project ) という国際的な団体によって作成されたセキュリティ診断ツール(プロキシツール)です。 無料で使用でき、 Webアプリケーション脆弱性診断が可能です。 Badstoreとは わざと脆弱性を持たせたWebアプリケーション(ショッピングサイト)で脆弱性診断のトレーニングを行うことができます。 通称「やられWebアプリケーション」と呼ばれます。Badstore以外にも 「やられWebアプリケーション」は存在します。 OWASP ZAPのインストールとセットアップ OWASP ZAPのインストールとセットアップについて説明します。 1.OWASP ZAPの ダウンロードページ から使用する環境に対応したインストーラーをダウンロードします。(今回はWindows 64bit版をインストールしました) 2.インストーラーを起動し、インストールウィザードを進めてインストールを完了させます。 3.OWASP ZAPを起動します。 以下のダイアログが表示されたら「開始」ボタンを押下します。 4.「ツール」メニューから「オプション」を選択後、「Network」-「Server Certificateｓ」を選択。 ルート証明書が選択されていることを確認し、「保存」ボタンから証明書をエクスポートします。これは次項で説明するブラウザのセットアップで使用します。 ブラウザのセットアップ 今回脆弱性診断で使用するブラウザですが、EdgeやChromeはセキュリティ機能が診断に影響を与えることがあるためFirefoxを使用します。 1.ブラウザを起動後、「設定」メニュー -「一般」 – 「ネットワーク設定」 – 「接続設定」ボタンから以下画面の通りにプロキシ設定を行い、OKボタンで保存します。 2.「設定」メニュー – 「プライバシーとセキュリティ」 – 「証明書」 – 「証明書を表示」ボタンから先ほどOWASP ZAPでエクスポートした証明書をインポートします。インポート時「この認証局によるウェブサイトの識別を信頼する」にチェックをいれます。 Badstoreのインストールとセットアップ Badstoreの正規のサイトでは配布が終了しており、はじめに紹介した参考書籍にて二次配布のリンクが共有されています。 Badstoreはisoイメージとなっており、今回は仮想環境にインストールして使用します。今回は仮想環境としてVMware Workstation Playerを使用します。 1.VMware Workstation Playerを VMware Workstation Player のダウンロード からダウンロードします。 2.インストーラーを起動し、インストールウィザードを進めてインストールを完了させます。 3.VMware Workstation Playerを起動し、「新規仮想マシンの作成」を選択します 4.「インストーラディスクイメージファイル」にダウンロードしたBadStoreのisoイメージを選択し、仮想マシンの作成を完了します。 5.仮想マシンを作成後、「仮想マシンの再生」から仮想マシンを起動します。 6.仮想マシンが起動したら「ifconfig」コマンドでBadstoreのipアドレスを調べます。 7.BadStoreのFQDNである「 www.badstore.net 」とIPアドレスを紐づけるためにhostsファイル（C:¥Windows¥System32¥drivers¥etc¥hosts）を以下のように編集します。 192.168.222.128 www.badstore.net 8.Firefoxで BadStoreのURL にアクセスし、サイトが表示されればセットアップ完了です。 脆弱性診断の実行 まず自動スキャン機能として静的スキャンを実行してみます。 静的スキャンは攻撃用リクエストを送ることなくクロールのリクエスト/レスポンスだけで診断します。 診断対象のWebサイトはいくつかのWebページやリクエスト内容を持っており、診断対象のページが明確ではないですが、診断対象のページを自動的にクロールして、記録してくれるスパイダーという機能があります。 こちらの機能を実行することで自動的にクロールで発見されたページに対して静的スキャンを実行してくれます。自動で遷移できないページに対しては手動で記録する必要があります。 1.標準モードになっていることを確認し、OWASP ZAPのサイト欄からBadStoreを選択し、「攻撃」-「スパイダー」を選択します。 2.「スキャンを開始」ボタンで実行します。 コンテキストを登録していると診断対象としたくないページを設定することができますが今回は説明を省略します。 3.診断対象が自動的に記録され、静的スキャンが実行されます。 下部のMessagesタブを選択後、診断対象のURLを右クリック-「このノードのアラート」を選択すると各URLに対しての検出アラートを確認することができます。 次に、手動スキャンを実行してみます。 手動スキャンを実行するにあたっては最低限必要な診断項目や手順を定義することで、一定レベルの手動診断による脆弱性診断を行うことができる「Webアプリケーション脆弱性診断ガイドライン」を参考にして手動スキャンを実行します。 「Webアプリケーション脆弱性診断ガイドライン」は こちら のサイトから入手できます。 クロスサイトスクリプティング（XSS）が存在するか確認する 今回は前述の代表的な脆弱性であるクロスサイトスクリプティング(XSS)が存在するかどうか確認してみます。 「Webアプリケーション脆弱性診断ガイドライン」のNo.19である検出パターン「<script>alert(1)</script>」を挿入してリクエストを送信します。 まずFirefoxでBadstoreに接続し、商品検索のテキスト入力欄に「1000」を入力し、商品検索します。 2.商品検索時のURLを確認し、OWASP ZAPの履歴から同じURLを探します 3.対象の履歴を選択後、右クリックメニューの「再送信」を選択します。 4.リクエストの「searchquery=1000」部分を以下に書き換えます searchquery=1000<script>alert(1)</script> 5.レスポンスタブを選択し、「送信」ボタンを押下します。 その後レスポンスのBodyからHTMLのBODY部分を確認すると挿入した検出パターン文字列がそのまま表示されていることが分かりました。 埋め込んだ脆弱性が実行されるか確認してみる 今度は実際にブラウザのURLから直接編集したURLを入力してスクリプトが実行されるか確認してみます。 先ほどと同じようにOWASP ZAPの履歴からURLを書き換えて送信したURLをコピーし、ブラウザで接続します。するとスクリプト(<script>alert(1)</script>)が実行され、ダイアログが表示されました。 ちなみに脆弱性の対策としては、以下のように適切にエスケープ文字に置き換えることによってスクリプトの実行を防ぐことができます。 対策⇒「<」と「>」をエスケープ文字に置き換え 　実行前：<script>alert(1)</script> 　実行後：<script> alert(1) </script> まとめ 自身の勉強として脆弱性診断を行ってみましたが、以下理由によりそこそこハードルが高いと感じました。 ・HTML等のWebの知識が必要 　・検出される脆弱性の種類は様々で、脆弱性の内容や対策方法を理解するのが大変 　・自動スキャンで全ての脆弱性を検出することはできず、Webサイトに応じた手動スキャンのスキルが必要 ですが、紹介したトレーニングサイトや脆弱性診断ツールが無償で公開されているため、勉強する環境は整っています。また、ハードルが低くないが故に奥が深く、やりがいのある分野だと思います。 機会を作って、プラットフォーム脆弱性診断についても勉強してみようと思っています。 さいごに さいごに注意事項ですが、脆弱性診断は他人、他社のWebサイトやWebアプリケーションに対して実行してはいけません。 脆弱性診断はWebアプリケーションに対して攻撃を行うことで脆弱性を発見する性質もあり、法的措置を取られる可能性があります。 トレーニングはBadStoreのようなやられWebアプリケーションに対して行うようにしましょう。 さいごまで読んでいただき、ありがとうございました！ The post OWASP ZAP VS. Badstore！脆弱性診断について勉強してみた！！ first appeared on Sqripts .

この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。 第6回目のテーマは、世界で大人気のフレームワーク「スクラム」です。 この内容はUdemyで公開しているオンラインコース「 現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム 入門編 」の内容を元にしています。 シンプルなフレームワーク「スクラム」 現在、もっとも有名な開発手法であるスクラムを解説します。スクラムは日本人の書いた論文をヒントに作られたフレームワークです。アメリカで体系化され、世界に広がり、日本に戻ってきました。 スクラムはとてもシンプルなフレームワークです。よって、改善を行うときは「シンプルかどうか」を忘れずにチェックすると良いと思います。そうしなければ、せっかくの軽量級フレームワークも、いつのまにか重量級フレームワークになってしまい、アジリティ（俊敏さ）が失われてしまうでしょう。 スクラムはスクラムガイドというガイドラインが公開されています。アジャイル開発らしく分厚いドキュメントではありません。 2020年11月現在のガイド だとわずか18ページです。スクラムはシンプルであることが有名ですが、ガイドもシンプルになっています。 逆に言うと、細かい解説のない書き方になっているとも言えるので、読み解くのが難しい人もいるでしょう。たとえば、スクラムを解説する本は、どれも18ページ以上の本ばかりなのが、シンプルさが生み出す難しさを表しています。 スクラムはシンプルですが、いくつもの分厚いスクラムの解説本が発売されているように、シンプルすぎてわかりにくい、解釈に困る、習得が難しい部分があります。この記事ではできるだけそうならないようにガイドできればと思っています。 ただ、スクラムやスクラムガイドがシンプルなのは、自分たちで考えてプラクティスを選ばせるためでもあることを覚えておくと良いでしょう。 スクラムガイドは、スクラムを理解するのにとてもいいドキュメントです。ただ、「スクラムガイドに書いてあるから」や「スクラムガイドに書いていないから」と解説する人がたまにいますが、書いてあるかどうかが重要ではありません。盲目的にガイドを受け入れすぎないように注意したほうがいいでしょう。 スクラムガイドは、時代に応じてどんどん更新されるドキュメントです。このセクションでは、2020年11月バージョンのスクラムガイドをもとに解説を行っていきます。 スクラムの三本柱 透明性、検査、適応はスクラムの三本柱と呼ばれています。 透明性： プロセスや作業、成果物を見えるようにしましょうということです。透明性なくして次の検査は実現できません。 検査： 見えるようになったものを頻繁かつ熱心に検査します。検査によって、次の適用が実現できます。 適応： いわゆる調整です。検査して理想と現実にギャップがあれば、調整して本来あるべき方向に調整していきます。 これらは後述するスクラムイベントの基盤になっています。 スクラムイベント スクラムイベントとは、スクラムのサイクルの中で発生するMTGを指しています。スクラムでは以下のようなイベントを行います。 スプリントプランニング： 短い期間内の計画を立てるイベント デイリースクラム： いわゆる朝礼 スプリントレビュー： 作ったものを検査するイベント。いわゆる成果発表 スプリントレトロスペクティブ： 自分たちを検査するイベント。いわゆるふりかえり スクラムの概要図 スクラムの流れを見ながら、スクラムイベントがどういった役割を持っているか見ていきましょう上記の図は、マウンテンゴート社が公開しているスクラムの全体図です。日本語訳が公開されていたのでこの図を使ってスクラムを使った仕事の流れを見ていきます。マウンテンゴート社は、『アジャイルな見積もりと計画づくり』の著者でも有名なマイクコーンさんのいる会社です。 まず、開発をはじめる前に、プロダクトバックログを作ります。プロダクトバックログは、いわゆる「やりたいことリスト」です。スクラムチームはプロダクトバックログを優先度順で開発し、リリースしていきます。開発やリリースが進むとプロダクトバックログが減っていくので、プロダクトバックログに責任を持つプロダクトオーナーは、プロダクトバックログを定期的にメンテナンス（増やしたり減らしたり磨いたり）していきます。 次に、 スプリントプランニング で計画を立てます。スクラムはスプリントという短い開発期間を繰り返していきます。このスプリントに合わせた開発計画がスプリントバックログです。すでにやりたいことリストはプロダクトバックログとしてあるので、そこからスプリントでやれる量を選び、スプリントバックログを作成します。 やりたいことリスト（プロダクトバックログ）ができて、スプリントでやることリスト（スプリントバックログ）ができたので、いよいよスプリントを開始します。スプリントは通常2週間から4週間のサイクルです。図の中央にある大きな円を描く緑色の矢印がスプリントをさしています。 スプリントの中にもうひとつ小さい矢印があります。これが デイリースクラムミーティング のサイクルです。デイリースクラムはいわゆる朝礼のようなもので、日々の計画の確認や調整を行う場です。 スプリントで開発を進め、最終的にスプリントのおわりに、プロダクトをリリースします。図にはありませんが、リリース前 にスプリントレビュー で成果物を検査し、 スプリントレトロスペクティブ によってスプリントでの開発を検査します。 これがスクラムの流れです。 スクラムはスクラムチームでこの流れを繰り返していきます。みてのとおり、とてもシンプルな流れです。おそらく、部分的に自然にやっているチームも多いでしょう。 スクラムチーム スクラムを行うチームをスクラムチームと呼びます。スクラムチームには、プロダクトオーナー（PO）、開発者、スクラムマスター（SM)がいます。 POは「プロダクトゴール」を決め、「やること」や「やる順番」を定義します。POだけでやることをきめられないのであれば、開発者などに相談しても問題ありません。あくまで、最終的な決定責任がPOにあるというだけです。従来型だと「要件に落とし込む人」に近い存在です。 組織が大きくなると、POがあつまるプロダクトオーナチームを作る場合もあります。 現在の人材市場を見ていると、POを仕事とする人が少ないので、一人のPOが複数チームをみるケースも多く見られます。 次に登場するのは、開発者です。開発者は開発を行います。スクラムガイドでは、フロントエンドエンジニア、バックエンドエンジニア・・・といったふうにこまかく分類されておらず、「開発者」とだけ定義されています。従来型だと「仕様を作り開発・テストする人」に近い存在です。 実際のスクラムチームは、チームだけで開発を完了させられる力が求められます。みなさんの現場で、フロントエンドとバックエンドが1名ずつ必要であれば、スクラムチームにはその2名を参加させる必要があります。 最後はスクラムマスターです。スクラムマスターはスクラムの理論やプラクティスを全員に理解してもらえるよう支援します。従来型だとプロジェクトマネージャーが近い存在です。 今回はスクラムの概要を解説しました。次回は、スクラムチームの責任に焦点を絞って解説を行います。 第1回：アジャイル開発の過去、現在、未来を知ろう！ 第2回：声に出して読みたいアジャイルマニフェスト 第3回：従来型開発とアジャイル開発の違い　その１ 第4回：従来型開発とアジャイル開発の違い　その２ 第5回：アジャイル開発のよくある誤解を解いていこう！ The post 第6回 世界中で大人気の秘密に迫る！スクラムを使ったソフトウェア開発 first appeared on Sqripts .

こんにちは。GSです。 今の時代、開発から運用までLinuxを必要とするケースはとても多いです。 WindowsユーザーがLinux環境が必要な開発を行うとき、WSL2を使うことで手軽に環境を作り利用することができます。 「Windowsは使えるが、Linuxはよくわからない」といった人が、できるだけ手間なく・手が止まることなく使える状態にし、実際に開発や検証に入れるような環境をささっと作り上げる手順をご紹介したいと思います。 ゴール Windows上からGUIを操作することなく、コマンドのコピペで環境を作り上げる 開発に困らないであろう最低限レベルに達するために必要なものをすぐ使えるように 開発や検証行為をLinuxに寄せすぎないようにし、Windowsのツールを十分に活用する WSL2とは？ そもそもWSL2は何なんのでしょうか？ WSL2とは、Windows Subsystem for Linux 2の略称で、Windows上でLinux環境を動かすための機能です。Windows 10 / 11の最新バージョンであれば、デフォルトでWSL2を使用することができます。 「Windows上でLinux環境を動かす」いうだけでなく、Windowsの一部としてのLinux、Linuxの一部としてのWindowsと言わんばかりに非常にシームレスな統合が行われるといったような特徴があります。 このシームレスな統合のお陰で、LinuxからWindows上のアプリをLinuxファイルシステムの上で起動したり、Windows GUIからLinuxへファイルを作成したりといったことも容易にできます。 検証環境（余談） 今回この記事を書くにあたり、 Windows 仮想マシンをダウンロードする – Windows アプリ開発 | Microsoft Developer にあるイメージを使用してWSL2環境構築を行っていきました。 提供されている開発用イメージは、その名の通り開発に必要なソフトウェア（WSL2も含まれる）がある程度セットアップされています。 ですので、それらを一度削除し、限りなくまっさらなWindows環境に戻し検証を行っています。 開発用マシンは英語環境のWindowsとなっています。日本語でセットアップを行いたい方は別途日本語化対応を行ってください。日本語化設定方法については「おまけ」セクションを参照してください。 また、今回の検証はHyper-V用イメージで行っており、Hyper-V内でWSL2を動かすためにホスト側で追加の設定を行っています。 Hyper-V用仮想マシンを、Winという名前に設定し PowerShellを管理者として実行 した上で Set-VMProcessor -VMName "Win" -ExposeVirtualizationExtensions $true というコマンドを実行しています。このコマンドを実行することで、Hyper-V上で仮想マシンやWSL2を実行できるようになります。 Hyper-Vは DISM.exe /Online /Enable-Feature /All /FeatureName:Microsoft-Hyper-V というコマンドを管理者として実行することでインストール可能です。 動作環境確認 CPU 仮想化支援機能がついているCPUが必要です。10年ほど前のPCでも付いている機能なので、それほど問題視する必要はありませんが、動作しない場合はお使いのコンピューターに搭載されているCPUのスペックを確認してください。 Windows バージョン ファイル名を指定して実行（Windows キー + R）より、「winver」を入力することで確認可能。 Windows 10 x64 システムの場合:  バージョン 1903  以降 ( ビルド 18362.1049  以降)。 ARM64 システムの場合:  バージョン 2004  以降 ( ビルド 19041  以降)。 Windows 11 特になし Windows 10で規定バージョンに満たない場合、Windowsそのものを更新する必要があります。 Windows Package Manager（WinGet） 「Windows Package Manager」は、「Windows 10 バージョン 1809」以降および「Windows 11」で利用可能なコマンドラインツールで、アプリケーションのインストール・アップデート・アンインストールを実行できるパッケージ管理システムです。 Linuxでいえば、「apt」や「yum」。Macで言えば「brew」などに相当します。 Windowsといえば、インストールしたいアプリケーションが提供されているホームページへアクセスしダウンロード→解凍→インストールという流れでアプリケーションをインストールすることが多いと思いますが、wingetコマンドであれば、ほしいアプリケーションをコマンド1行で打つだけで即座に導入できるようになります。 wingetのようなコマンドとして Scoop や Chocolatey Software | Chocolatey – The package manager for Windows があります。Scoopは開発者向けのアプリケーション（コマンド）が多く、Chocolateyは一般的なアプリケーションが多いです。 ファイル名を指定して実行（Windows キー + R）より、「cmd」を入力しコマンドプロンプトを開き、 winget --version を入力します。 C:\users\User>winget --version v1.4.11071 コマンドがインストールされ使える状況であれば、上記のようなメッセージが表示されます。 コマンドが見つからずにエラーとなったり、表示されるバージョンが古く更新したい場合などは、 アプリ インストーラー (microsoft.com) よりインストールまたは更新することで、最新バージョンが利用可能になります。 続けてアプリケーションを実際に検索し、インストールしてみます。 Windows Terminalをインストール winget search "windows terminal" と入力してみましょう。 C:\Users\User>winget search "windows terminal" 名前 ID バージョン ソース -------------------------------------------------------------------------------- 'msstore' ソースでは、使用する前に次の契約を表示する必要があります。 Terms of Transaction: https://aka.ms/microsoft-store-terms-of-transaction ソースが正常に機能するには、現在のマシンの 2 文字の地理的リージョンをバックエンド サービスに送信する必要があります (例: "US")。 すべてのソース契約条件に同意しますか? [Y] はい [N] いいえ: y 名前 ID バージョン ソース ------------------------------------------------------------------------------- Windows Terminal 9N0DX20HK701 Unknown msstore Windows Terminal Preview 9N8G5RFZ9XK3 Unknown msstore Windows Terminal Microsoft.WindowsTerminal 1.16.10261.0 winget Windows Terminal Preview Microsoft.WindowsTerminal.Preview 1.17.10234.0 winget wingetコマンドでアプリケーション検索を初めて行う場合、「ソース契約条件に同意しますか？」というメッセージが表示されるので、Yを入力し同意します。 今回は4つ候補表示されました。ソースが msstore となっているものが、ストアアプリからインストール可能なパッケージとなります。 今回はこのストアアプリからも入れられるパッケージをwingetコマンドで入れてみます。 searchコマンドで表示されたIDをwingetコマンドの引数として指定することでダウンロードおよびインストールします（パッケージ名でもダウンロードすることは可能です）。 C:\Users\User>winget install -e --id 9N0DX20HK701 見つかりました Windows Terminal [9N0DX20HK701] バージョン Unknown このパッケージは Microsoft Store から提供されています。winget は、現在のユーザーに代わって Microsoft Store からパッケー ジを取得する必要がある場合があります。 契約の対象 Windows Terminal [9N0DX20HK701] バージョン Unknown バージョン: Unknown 公開元: Microsoft Corporation 発行元 URL: https://github.com/microsoft/terminal 発行元のサポート URL: https://github.com/microsoft/terminal/issues/new 説明: The Windows Terminal is a modern, fast, efficient, powerful, and productive terminal application for users of command-line tools and shells like Command Prompt, PowerShell, and WSL. Its main features include multiple tabs, panes, Unicode and UTF-8 character support, a GPU accelerated text rendering engine, and custom themes, styles, and configurations. This is an open source project and we welcome community participation. To participate please visit https://github.com/microsoft/terminal ライセンス: ms-windows-store://pdp/?ProductId=9N0DX20HK701 プライバシー URL: go.microsoft.com/fwlink/?LinkID=521839 著作権: Copyright (c) Microsoft Corporation 契約: Category: Developer tools Pricing: Free Free Trial: No Terms of Transaction: https://aka.ms/microsoft-store-terms-of-transaction Seizure Warning: https://aka.ms/microsoft-store-seizure-warning Store License Terms: https://aka.ms/microsoft-store-license 発行元は、お客様がインストール前に上記の情報を表示し、契約に同意することを必要としています。 使用条件に同意しますか? [Y] はい [N] いいえ: Y パッケージ取得の確認/要求... パッケージ取得の成功の確認/要求 パッケージのインストールを開始しています... ██████████████████████████████ 100% インストールが完了しました インストールされ、使える状況になっているのが確認できます。 無論ストアからもインストール可能です。 https://www.microsoft.com/store/productId/9N0DX20HK701 URLを見るとわかりますが、wingetで指定したIDがURLに含まれています。 wingetコマンドを使用してのアプリケーション削除は、 winget uninstall -e --id 9N0DX20HK701 のように、installをuninstallに置き換えるだけで行えます。 以降の作業は、コマンドプロンプトではなく Windows Terminalで行っていきます 。 Visual Studio Codeをインストール Windows Terminalを起動し、 winget search -s msstore "Visual Studio Code" と入力します。 PS C:\Users\User> winget search -s msstore "Visual Studio Code" 名前 ID バージョン ------------------------------------------------------- Visual Studio Code XP9KHM4BK9FZ7Q Unknown Visual Studio Code - Insiders XP8LFCZM790F6B Unknown 今回は -s msstore オプションを付け、ストアアプリからインストール可能なアプリケーションのみを検索対象としています。 続けてインストールを行います。 winget install -e --id XP9KHM4BK9FZ7Q と入力。 PS C:\Users\User> winget install -e --id XP9KHM4BK9FZ7Q 見つかりました Visual Studio Code [XP9KHM4BK9FZ7Q] バージョン Unknown このアプリケーションは所有者からライセンス供与されます。 Microsoft はサードパーティのパッケージに対して責任を負わず、ライセンスも付与しません。 契約の対象 Visual Studio Code [XP9KHM4BK9FZ7Q] バージョン Unknown バージョン: Unknown 公開元: Microsoft Corporation 発行元 URL: https://code.visualstudio.com/ 説明: Visual Studio Code is a free, lightweight, and extensible code editor for building web, desktop, and mobile applications, using any programming language and framework. Visual Studio Code has built-in support for Git source control management and powerful integrations with GitHub, an integrated debugger, and smart code completion with IntelliSense and with AI-driven IntelliCode. With over 30,000 extensions and themes in the Visual Studio Code Marketplace, you can customize the features and the look of Visual Studio Code to fit your needs, preferences, and style. You can use Visual Studio Code to build any kind of app, for web, desktop, and mobile. Visual Studio Code supports JavaScript and TypeScript natively and offers extensions for coding in languages such as Python, Java, C/C++, C#, Go, Rust, PHP, and many more. ライセンス: https://code.visualstudio.com/License/ プライバシー URL: https://privacy.microsoft.com/en-US/privacystatement 著作権: ms-windows-store://pdp/?ProductId=XP9KHM4BK9FZ7Q タグ: programming coding code vscode vs editor 契約: Category: Developer tools Pricing: Free Free Trial: No Terms of Transaction: https://aka.ms/microsoft-store-terms-of-transaction Seizure Warning: https://aka.ms/microsoft-store-seizure-warning Store License Terms: https://aka.ms/microsoft-store-license 発行元は、お客様がインストール前に上記の情報を表示し、契約に同意することを必要としています。 使用条件に同意しますか? [Y] はい [N] いいえ: Y ダウンロード中 https://sparkcdneus2.azureedge.net/cachedpackages/973b41be-5827-46f6-ab6d-637c2942eb33_9490453f2d73eb32f365c631bbad3b9d4837af27ce31ad6cb3dad56c50b0a5fa ██████████████████████████████ 6.34 MB / 6.34 MB インストーラーハッシュが正常に検証されました パッケージのインストールを開始しています... インストールが完了しました Visual Studio Codeがインストールされていることが確認できます。 ついでにVisual Studio Code拡張機能も入れてみましょう。 code --install-extension ms-vscode-remote.vscode-remote-extensionpack このコマンドを実行することで、「 Remote Development – Visual Studio Marketplace 」がインストールされます。 この拡張機能を入れておくことで、さまざまな環境に対して接続し、開発や検証作業を行うことが可能になります。 PS C:\Users\User> code --install-extension ms-vscode-remote.vscode-remote-extensionpack WSL2をインストールする Windows 10 バージョン 2004 以上 (ビルド 19041 以上) または Windows 11 を実行している方は、Windows Terminalを 管理者 モードで開き（PowerShellが管理者モードで起動します）、 wsl --install コマンドを入力します。 Windows上からPowerShellやコマンドプロンプトなどを管理者として実行する場合、右クリックから「管理者として実行」を選ぶ方は多いと思いますが、CTRL+SHIFTキーを押しながら起動（マウスクリックやエンターキー）することでも管理者として起動できます。ファイル名を指定して実行（Windows キー + R）で入力したコマンドも、CTRL+SHIFTで実行すれば、管理者モードで開くことが可能です。 コマンドを実行すると、許可ダイアログがあがってくるので、「はい」を選択します。 PS C:\Users\User> wsl --install インストール中: Linux 用 Windows サブシステム Linux 用 Windows サブシステム はインストールされました。 インストール中: Ubuntu Ubuntu はインストールされました。 要求された操作は正常に終了しました。変更を有効にするには、システムを再起動する必要があります。 メッセージの内容から、WSLのセットアップが完了し、Ubuntuがインストールされたことがわかります。 表示されているメッセージの通り、再起動を行いましょう。 wsl —list —online コマンドで、WSL環境へインストール可能なディストリービューション一覧を見ることができます。たとえばDebianをインストールしたいという場合、 wsl --install -d Debian コマンドで可能です。 再起動後、Windows Terminalが自動的に起動し、Ubuntuのインストール処理が進行します。 その過程でUbuntuで利用するユーザーとそのパスワードを設定する必要があります。 今回はユーザー名「ubuntu」、パスワード「ubuntu」で設定しました。 Ubuntu を起動しています... Installing, this may take a few minutes... Please create a default UNIX user account. The username does not need to match your Windows username. For more information visit: https://aka.ms/wslusers Enter new UNIX username: ubuntu New password: Retype new password: passwd: password updated successfully この操作を正しく終了しました。 Installation successful! To run a command as administrator (user "root"), use "sudo <command>". See "man sudo_root" for details. Welcome to Ubuntu 22.04.2 LTS (GNU/Linux 5.15.90.1-microsoft-standard-WSL2 x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/advantage This message is shown once a day. To disable it please create the /home/ubuntu/.hushlogin file. ubuntu@WinDev2306Eval:~$ 以上でWSL2を有効にし、Ubuntuのインストールは完了です。 WSL2をコマンドでインストール出来ない場合 多少古いバージョンのWindows 10だと、 wsl -—install コマンドではインストールできません。 そのため、別途個別に必要なソフトウェアをインストールしていく必要があります。 Linux 用 Windows サブシステムと仮想マシンの機能を有効にする Windows Terminalを管理者として実行 し、以下のコマンドを実行しましょう。 dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart 実行後、再起動します。 Linux カーネル更新プログラム パッケージをダウンロードし、インストールする 再度、 Windows Terminalを管理者として実行。 wget https://wslstorestorage.blob.core.windows.net/wslblob/wsl_update_x64.msi -OutFile wsl_update_x64.msi msiexec /i wsl_update_x64.msi /passive del wsl_update_x64.msi の順番にコマンドを実行し、Linuxカーネルを更新します。 PS C:\Users\User> wget https://wslstorestorage.blob.core.windows.net/wslblob/wsl_update_x64.msi -OutFile wsl_update_x64.msi PS C:\Users\User> msiexec /i wsl_update_x64.msi /passive PS C:\Users\User> del wsl_update_x64.msi WSL 2 を既定のバージョンとして設定する wsl --set-default-version 2 を実行します。 PS C:\Users\User> wsl --set-default-version 2 WSLを更新する wsl —update にて更新します PS C:\Users\User> wsl --update WSL2へUbuntuをインストール PS C:\Users\User> wsl --install -d Ubuntu 以上で、手動によるWSL2とUbuntuのインストールは完了です。 Ubuntuセットアップ まずは、Ubuntuを起動してみましょう。 Windows Terminalを実行します。 画面上部の「 ∨ 」を選択すると、Ubuntuが候補として表示されていることが確認できます。こちらを選択し、Ubuntuを起動しましょう。 systemdを有効化する 今後Ubuntuへインストール及び設定していくアプリケーションのために、systemdを有効にしておきます。 以下のコマンドを 4行分一気に貼り付け 実行します。 cat <<EOF | sudo tee /etc/wsl.conf [boot] systemd=true EOF 以下が実際にインストールしてみた例です。 途中でubuntuユーザーのパスワードを聞かれますので、事前に設定したパスワードである「ubuntu」を入力しました。 ubuntu@WinDev2306Eval:~$ cat <<EOF | sudo tee /etc/wsl.conf [boot] systemd=true EOF [sudo] password for ubuntu: [boot] systemd=true コマンドを実行したら、PowerShellからwslをシャットダウンします。 PS C:\Users\User> wsl --shutdown 再度、Ubuntuを起動すると、systemdが有効になっています。 sshを有効にする まずはopenssh-serverをインストールしましょう。 sudo apt install -y openssh-server その上で、sshを有効にします。 sudo systemctl enable ssh sudo service ssh restart 以上で、sshを使うための最小限の設定は終わりですが、sshに鍵でアクセスしたい場合や、パスワードログインを無効にしたいといった場合、設定を変更する必要があります。 今回は後続で説明するTailscaleのために、初期設定のまま話を進めていきます。 docker dockerとは？ dockerは、コンテナ技術を利用してアプリケーションをパッケージング・配布するためのプラットフォームです。 誤解を恐れずに言えば、ワンコマンドで色々なアプリケーション（Webサーバーとかデータベースサーバーとか）を立ち上げてくれるすごいヤツでしょうか。 インストール 以下のコマンドを実行し、dockerが必要としているパッケージをインストールします。 sudo apt-get update -y && sudo apt-get install ca-certificates curl gnupg -y dockerインストールに必要なGPG情報をセットアップします。 sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg sudo chmod a+r /etc/apt/keyrings/docker.gpg docker関係のリポジトリを追加します。 echo \ "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \ sudo tee /etc/apt/sources.list.d/docker.list > /dev/null dockerをインストールします。 sudo apt-get update -y && sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin 今現在ログインしているユーザーをdockerグループへ所属させます（dockerコマンドを管理者権限なしに実行できるようにするため）。 sudo usermod -aG docker $(whoami) 上記工程をすべて実行した例は以下のとおりです。 ubuntu@WinDev2306Eval:~$ sudo apt-get update -y && sudo apt-get install ca-certificates curl gnupg -y Hit:1 http://archive.ubuntu.com/ubuntu jammy InRelease Hit:2 http://security.ubuntu.com/ubuntu jammy-security InRelease Hit:3 http://archive.ubuntu.com/ubuntu jammy-updates InRelease Hit:4 http://archive.ubuntu.com/ubuntu jammy-backports InRelease Reading package lists... Done Updating certificates in /etc/ssl/certs... 略 0 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... done. ubuntu@WinDev2306Eval:~$ sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg sudo chmod a+r /etc/apt/keyrings/docker.gpg ubuntu@WinDev2306Eval:~$ echo "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null [sudo] password for ubuntu: ubuntu@WinDev2306Eval:~$ sudo apt-get update -y && sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin Get:1 https://download.docker.com/linux/ubuntu jammy InRelease [48.9 kB] Get:2 https://download.docker.com/linux/ubuntu jammy/stable amd64 Packages [19.2 kB] Hit:3 http://archive.ubuntu.com/ubuntu jammy InRelease Hit:4 http://archive.ubuntu.com/ubuntu jammy-updates InRelease 略 Processing triggers for man-db (2.10.2-1) ... Processing triggers for libc-bin (2.35-0ubuntu3.1) ... ubuntu@WinDev2306Eval:~$ sudo usermod -aG docker $(whoami) [sudo] password for ubuntu: この時点で一度WSLを終了し、再度起動し直してみましょう。 終了は例によってPowerShellで行います。 PS C:\Users\User> wsl --shutdown Ubuntuを再起動した後 docker run hello-world と入力してみましょう。 以下のように表示されたら、dokcerのセットアップは完了です。 ubuntu@WinDev2306Eval:~$ docker run hello-world Unable to find image 'hello-world:latest' locally latest: Pulling from library/hello-world 719385e32844: Pull complete Digest: sha256:a13ec89cdf897b3e551bd9f89d499db6ff3a7f44c5b9eb8bca40da20eb4ea1fa Status: Downloaded newer image for hello-world:latest Hello from Docker! This message shows that your installation appears to be working correctly. To generate this message, Docker took the following steps: 1. The Docker client contacted the Docker daemon. 2. The Docker daemon pulled the "hello-world" image from the Docker Hub. (amd64) 3. The Docker daemon created a new container from that image which runs the executable that produces the output you are currently reading. 4. The Docker daemon streamed that output to the Docker client, which sent it to your terminal. To try something more ambitious, you can run an Ubuntu container with: $ docker run -it ubuntu bash Share images, automate workflows, and more with a free Docker ID: https://hub.docker.com/ For more examples and ideas, visit: https://docs.docker.com/get-started/ もう一つテストで実行してみましょう。 今回はnginx（Webサーバー）を起動してみます。 docker run -d --rm --name nginx -p 80:80 nginx 実行後、curlコマンドを使うことで、nginxが起動していることを確認できます。 ubuntu@WinDev2306Eval:~$ docker run -d --rm --name nginx -p 80:80 nginx Unable to find image 'nginx:latest' locally latest: Pulling from library/nginx 5b5fe70539cd: Pull complete 441a1b465367: Pull complete 3b9543f2b500: Pull complete ca89ed5461a9: Pull complete b0e1283145af: Pull complete 4b98867cde79: Pull complete 4a85ce26214d: Pull complete Digest: sha256:593dac25b7733ffb7afe1a72649a43e574778bf025ad60514ef40f6b5d606247 Status: Downloaded newer image for nginx:latest f82668128daf973712be676fc2ed7c18e67c80de57980eb61708aba1109799e8 ubuntu@WinDev2306Eval:~$ curl localhost <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> html { color-scheme: light dark; } body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html> Windowsからも動作確認が行なえます。任意のブラウザでlocalhostを開いてみましょう。 WSL2上のUbuntuの上に起動するdockerで立ち上げたnginxに対し、Windowsからアクセスできることが確認できます。 起動したnginxを終了させるには docker stop nginx を実行します。 dockerコマンドを実行しコンテナを起動させようとしたところエラーが出るという場合、すでにWindows側にdocker関係のプロダクトが入っている可能性が高いです。 WSL2側でdockerを実行したい場合、Windows側のdockerプロダクトはすべて削除しておく必要があります（厳密に言えば、削除しておいたほうが無難です）。 Windowsにインストールする「Docker Desktop for Windows」というdockerプロダクトがあります。こちらを使うことでもWindowsマシンでdockerを使うことは可能です。WSL2にdockerをインストールして使うのと、「Docker Desktop for Windows」を使うのどちらが良いでしょうか？ 個人的な意見としては、WSL2 + dockerが良いかなと思っています。というのも「Docker Desktop for Windows」だと、シンボリックリンクを多用したシェルスクリプトの実行に問題があったり、ファイルシステムのアクセス速度に問題があるからです。 Homebrew Homebrewとは？ Homebrewは、macOSやLinuxなどのオペレーティングシステム向けのパッケージマネージャで、ターミナルからコマンドを実行することで様々なアプリケーションやライブラリを簡単にインストールできます。また、自分でパッケージを作成することもできます。Homebrewを使うことで、より簡単・効率的な開発環境構築が可能になります。 インストール 以下のコマンドを実行します。 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" 実行すると、出力されるメッセージの最後の方に ==> Next steps: - Run these two commands in your terminal to add Homebrew to your PATH: (echo; echo 'eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"') >> /home/ubuntu/.profile eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)" - Install Homebrew's dependencies if you have sudo access: sudo apt-get install build-essential For more information, see: https://docs.brew.sh/Homebrew-on-Linux - We recommend that you install GCC: brew install gcc - Run brew help to get started - Further documentation: https://docs.brew.sh と表示されるので、この内容に従ってコマンドを実行します。 (echo; echo 'eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"') >> /home/ubuntu/.profile eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)" sudo apt-get install -y build-essential brew install gcc 以下が実際にインストールしてみた例です。 ubuntu@WinDev2306Eval:~$ (echo; echo 'eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"') >> /home/ubuntu/.profile ubuntu@WinDev2306Eval:~$ eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)" ubuntu@WinDev2306Eval:~$ sudo apt-get install build-essential [sudo] password for ubuntu: Reading package lists... Done Building dependency tree... Done Reading state information... Done The following additional packages will be installed: bzip2 cpp cpp-11 dpkg-dev fakeroot fontconfig-config fonts-dejavu-core g++ g++-11 gcc gcc-11 gcc-11-base 略 update-alternatives: using /usr/bin/g++ to provide /usr/bin/c++ (c++) in auto mode Setting up build-essential (12.9ubuntu3) ... Processing triggers for man-db (2.10.2-1) ... Processing triggers for libc-bin (2.35-0ubuntu3.1) ... ubuntu@WinDev2306Eval:~$ brew install gcc ==> Fetching dependencies for gcc: gmp, isl, mpfr, libmpc, lz4, xz, zlib, zstd and binutils ==> Fetching gmp 略 🍺 /home/linuxbrew/.linuxbrew/Cellar/gcc/13.1.0: 1,668 files, 320.2MB ==> Running `brew cleanup gcc`... Disable this behaviour by setting HOMEBREW_NO_INSTALL_CLEANUP. Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`). 以上でHomebrewのセットアップは終わりです。 このあとの工程でbrewコマンドを使い、アプリケーションをインストールしていきます。 Tailscale Tailscaleとは？ Tailscaleは、オープンソースのソフトウェアで構成された仮想プライベートネットワークを作成することができるソフトウェアです。 Tailscaleで簡単に繋がるネットワーク | Sqripts という記事を公開しているので、参考にしてみてください。 インストール 以下のコマンドを実行します。 curl -fsSL https://tailscale.com/install.sh | sh コマンド実行後、最下部に sudo tailscale up と表示されるので、そのとおりに実行します。 以下が実際にインストールしてみた例です。 ubuntu@WinDev2306Eval:~$ curl -fsSL https://tailscale.com/install.sh | sh Installing Tailscale for ubuntu jammy, using method apt + sudo mkdir -p --mode=0755 /usr/share/keyrings + + sudocurl tee -fsSL /usr/share/keyrings/tailscale-archive-keyring.gpg https://pkgs.tailscale.com/stable/ubuntu/jammy.noarmor.gpg + curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/jammy.tailscale-keyring.list + sudo tee /etc/apt/sources.list.d/tailscale.list # Tailscale packages for ubuntu jammy deb [signed-by=/usr/share/keyrings/tailscale-archive-keyring.gpg] https://pkgs.tailscale.com/stable/ubuntu jammy main + sudo apt-get update Hit:1 https://download.docker.com/linux/ubuntu jammy InRelease Get:2 http://security.ubuntu.com/ubuntu jammy-security InRelease [110 kB] Get:3 https://pkgs.tailscale.com/stable/ubuntu jammy InRelease Get:4 https://pkgs.tailscale.com/stable/ubuntu jammy/main amd64 Packages [8434 B] Get:5 https://pkgs.tailscale.com/stable/ubuntu jammy/main all Packages [354 B] Hit:6 http://archive.ubuntu.com/ubuntu jammy InRelease Get:7 http://archive.ubuntu.com/ubuntu jammy-updates InRelease [119 kB] Get:8 http://archive.ubuntu.com/ubuntu jammy-backports InRelease [108 kB] Fetched 352 kB in 28s (12.7 kB/s) Reading package lists... Done + sudo apt-get install -y tailscale tailscale-archive-keyring Reading package lists... Done Building dependency tree... Done Reading state information... Done The following NEW packages will be installed: tailscale tailscale-archive-keyring 0 upgraded, 2 newly installed, 0 to remove and 56 not upgraded. Need to get 23.7 MB of archives. After this operation, 44.0 MB of additional disk space will be used. Get:1 https://pkgs.tailscale.com/stable/ubuntu jammy/main amd64 tailscale amd64 1.44.0 [23.7 MB] Get:2 https://pkgs.tailscale.com/stable/ubuntu jammy/main all tailscale-archive-keyring all 1.35.181 [3082 B] Fetched 23.7 MB in 17s (1419 kB/s) Selecting previously unselected package tailscale. (Reading database ... 30170 files and directories currently installed.) Preparing to unpack .../tailscale_1.44.0_amd64.deb ... Unpacking tailscale (1.44.0) ... Selecting previously unselected package tailscale-archive-keyring. Preparing to unpack .../tailscale-archive-keyring_1.35.181_all.deb ... Unpacking tailscale-archive-keyring (1.35.181) ... Setting up tailscale-archive-keyring (1.35.181) ... Setting up tailscale (1.44.0) ... Created symlink /etc/systemd/system/multi-user.target.wants/tailscaled.service → /lib/systemd/system/tailscaled.service. + [ false = true ] + set +x Installation complete! Log in to start using Tailscale by running: sudo tailscale up ubuntu@WinDev2306Eval:~$ sudo tailscale up To authenticate, visit: https://login.tailscale.com/a/XXXXXXXXXXXX Success. https://login.tailscale.com/a/XXXXXXXXXXXX といったようなURLが表示されるので、そのリンクを任意のブラウザで開き、Tailscaleにログインすることで、このWSL2で実行されているUbuntuをTailscaleネットワークに所属させることができます。 この状態でTailscaleに所属している他のマシンからssh接続してみましょう。 今回は同じTailscaleネットワークに参加しているMacから接続してみます。 ❯ ssh -l ubuntu windev2306eval The authenticity of host 'windev2306eval (100.70.248.62)' can't be established. ED25519 key fingerprint is SHA256:pQAdFPFMb3+VFgxq+S0lOFOyVuSvNTV5BrhQsb5sXtU. This host key is known by the following other names/addresses: ~/.ssh/known_hosts:38: 100.70.248.62 Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added 'windev2306eval' (ED25519) to the list of known hosts. ubuntu@windev2306eval's password: Welcome to Ubuntu 22.04.2 LTS (GNU/Linux 5.15.90.1-microsoft-standard-WSL2 x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/advantage * Strictly confined Kubernetes makes edge and IoT secure. Learn how MicroK8s just raised the bar for easy, resilient and secure K8s cluster deployment. https://ubuntu.com/engage/secure-kubernetes-at-the-edge Last login: Thu Jun 29 09:44:49 2023 from 100.116.202.97 このように接続できました。 Macからみて接続しているLinuxが、実はWindowsの中のLinuxとはとても思えない状況で扱うことができます。 もう一つ、別の方法で接続テストをしてみましょう。 dockerの項目で上げた、 docker run -d --rm --name nginx -p 80:80 nginx nginx（Webサーバー）を実行した状態で、WSL2とは異なるマシン上（すなわちWSL2がインストールされたWindows 意外 のコンピューター）のブラウザから、WSL2上のLinuxを開いてみます。 今回はMacのSafariから開いてみました。 このように表示されることから、Ubuntuで起動しているnginxへアクセスできているのが確認できます。 Windows上にWSL2でLinuxをセットアップし、そこへTrailscaleを入れWebアプリケーション開発を行っている場合、同じTailscaleネットワークに所属してる人達が容易に動作確認を行えるので、たとえリモートワークのような作業状況でも、ペアプロや新人教育など多くのシーンで効率の良い作業が行えると思います。 asdf asdfとは？ asdfは、複数のプログラミング言語等のバージョンを管理するためのツールです。インストールやアンインストール、バージョンの切り替えが簡単に行えます。複数のプログラミング言語を使っている場合には、非常に便利なツールとなります。 プログラム言語のバージョン管理意外にも使え、たとえばTerraformのインストールや、Poetryのインストールなど、開発や運用に使われるアプリケーションのいくつかを導入可能です。 インストール 以下のコマンドを実行し、asdfに必要なファイルをインストールします。 sudo apt update -y && sudo apt install -y curl git asdf本体をgithubよりダウンロードします。 git clone https://github.com/asdf-vm/asdf.git ~/.asdf --branch v0.12.0 asdfに必要な設定を行います。 . "$HOME/.asdf/asdf.sh" . "$HOME/.asdf/completions/asdf.bash" echo '. "$HOME/.asdf/asdf.sh"' >> ~/.bashrc echo '. "$HOME/.asdf/completions/asdf.bash"' >> ~/.bashrc 以上でasdfの導入は完了です。 以下が実際にインストールしてみた例です。 ubuntu@WinDev2306Eval:~$ sudo apt update -y && sudo apt install -y curl git [sudo] password for ubuntu: Hit:1 https://download.docker.com/linux/ubuntu jammy InRelease Get:2 http://security.ubuntu.com/ubuntu jammy-security InRelease [110 kB] Hit:3 http://archive.ubuntu.com/ubuntu jammy InRelease Get:4 https://pkgs.tailscale.com/stable/ubuntu jammy InRelease 略 curl is already the newest version (7.81.0-1ubuntu1.10). git is already the newest version (1:2.34.1-1ubuntu1.9). git set to manually installed. 0 upgraded, 0 newly installed, 0 to remove and 56 not upgraded. ubuntu@WinDev2306Eval:~$ git clone https://github.com/asdf-vm/asdf.git ~/.asdf --branch v0.12.0 Cloning into '/home/ubuntu/.asdf'... remote: Enumerating objects: 8446, done. remote: Counting objects: 100% (359/359), done. 略 Or undo this operation with: git switch - Turn off this advice by setting config variable advice.detachedHead to false ubuntu@WinDev2306Eval:~$ . "$HOME/.asdf/asdf.sh" ubuntu@WinDev2306Eval:~$ . "$HOME/.asdf/completions/asdf.bash" ubuntu@WinDev2306Eval:~$ echo '. "$HOME/.asdf/asdf.sh"' >> ~/.bashrc ubuntu@WinDev2306Eval:~$ echo '. "$HOME/.asdf/completions/asdf.bash"' >> ~/.bashrc 開発言語を導入 前項でセットアップしたasdfを利用し、nodejsとpythonの最新バージョンを導入し使えるようにしてみましょう。 そのために、nodejsおよびpythonプラグインを導入します。 asdf plugin add nodejs asdf plugin add python まずはnodejsを入れてみましょう。 asdf install nodejs latest 続けてpythonをいれてみます。 pythonをインストールする前に、別途依存関係のあるファイルを導入してきます。 sudo apt install -y libffi-dev zlib1g-dev libssl-dev libbz2-dev libsqlite3-dev libreadline-dev liblzma-dev tk-dev asdf install python latest インストールしたnodejsとpythonをシステムで使うように設定してみましょう。 asdf global nodejs latest asdf global python latest これで、最新のnodejsとpythonが使えるようになりました。 以下が実際にインストールしてみた例です。 ubuntu@WinDev2306Eval:~$ asdf plugin add nodejs ubuntu@WinDev2306Eval:~$ asdf install nodejs latest Trying to update node-build... ok Downloading node-v20.3.1-linux-x64.tar.gz... -> https://nodejs.org/dist/v20.3.1/node-v20.3.1-linux-x64.tar.gz Installing node-v20.3.1-linux-x64... Installed node-v20.3.1-linux-x64 to /home/ubuntu/.asdf/installs/nodejs/20.3.1 ubuntu@WinDev2306Eval:~$ sudo apt install -y libffi-dev zlib1g-dev libssl-dev libbz2-dev libsqlite3-dev libreadline-dev liblzma-dev tk-dev Reading package lists... Done Building dependency tree... Done Reading state information... Done 略 Setting up tk-dev:amd64 (8.6.11+1build2) ... Processing triggers for man-db (2.10.2-1) ... Processing triggers for libc-bin (2.35-0ubuntu3.1) ... ubuntu@WinDev2306Eval:~$ asdf install python latest python-build 3.11.4 /home/ubuntu/.asdf/installs/python/3.11.4 Downloading Python-3.11.4.tar.xz... -> https://www.python.org/ftp/python/3.11.4/Python-3.11.4.tar.xz Installing Python-3.11.4... Installed Python-3.11.4 to /home/ubuntu/.asdf/installs/python/3.11.4 ubuntu@WinDev2306Eval:~$ asdf global nodejs latest ubuntu@WinDev2306Eval:~$ node --version v20.3.1 ubuntu@WinDev2306Eval:~$ asdf global python latest ubuntu@WinDev2306Eval:~$ python --version Python 3.11.4 next.jsを動かし、そのプロジェクトをVisual Studio Codeで編集してみる 導入したnodejsを利用し、next.jsを動かしてみます。 npx create-next-app@latest --typescript 色々聞かれますが、エンターキーを押して進めていきましょう。 プロジェクトが作成されたら、作成されたディレクトリへ移動し、npmコマンドでnext.jsを起動します。 cd my-app npm run dev 以上で、next.jsアプリケーションが起動するはずです。 動作しているか確認してみましょう。 任意のブラウザから http://localhost:3000/ を開いてみます。 起動していることが確認できました。 次の工程に進むため、起動したnext.jsアプリケーションを停止しましょう。 CTRL+Cキーで停止できます。 ここまで実際に実行した例は以下のとおりです。 ubuntu@WinDev2306Eval:~$ npx create-next-app@latest --typescript ✔ What is your project named? … my-app ✔ Would you like to use ESLint with this project? … No / Yes ✔ Would you like to use Tailwind CSS with this project? … No / Yes ✔ Would you like to use `src/` directory with this project? … No / Yes ✔ Use App Router (recommended)? … No / Yes ✔ Would you like to customize the default import alias? … No / Yes Creating a new Next.js app in /home/ubuntu/my-app. Using npm. Initializing project with template: app-tw Installing dependencies: - react - react-dom - next - typescript - @types/react - @types/node - @types/react-dom - tailwindcss - postcss - autoprefixer - eslint - eslint-config-next added 344 packages, and audited 345 packages in 27s 127 packages are looking for funding run `npm fund` for details 5 moderate severity vulnerabilities To address all issues, run: npm audit fix Run `npm audit` for details. Success! Created my-app at /home/ubuntu/my-app ubuntu@WinDev2306Eval:~$ cd my-app/ ubuntu@WinDev2306Eval:~/my-app$ npm run dev > my-app@0.1.0 dev > next dev - ready started server on 0.0.0.0:3000, url: http://localhost:3000 - event compiled client and server successfully in 153 ms (20 modules) - wait compiling... - event compiled client and server successfully in 95 ms (20 modules) - wait compiling /page (client and server)... - event compiled client and server successfully in 2.3s (463 modules) - wait compiling... - event compiled successfully in 111 ms (225 modules) - wait compiling /favicon.ico/route (client and server)... - event compiled client and server successfully in 301 ms (493 modules) ^C 続けて、WSL2上のLinux環境を、Windows側のインストールされているVisual Stduio Codeで開いてみたいと思います。 code . と入力し、Visual Stduio Codeを立ち上げてみましょう。 Visual Studio Codeのインストール部分で説明した、 Remote Development拡張機能 がインストールされているのなら、問題なく開けるはずです。 ubuntu@WinDev2306Eval:~/my-app$ code . Installing VS Code Server for x64 (695af097c7bd098fbf017ce3ac85e09bbc5dda06) Downloading: 100% Unpacking: 100% Unpacked 1779 files and folders to /home/ubuntu/.vscode-server/bin/695af097c7bd098fbf017ce3ac85e09bbc5dda06. 起動したら、「Trust the authors of all files in the parent folder ‘ubuntu’」にチェックを入れ、「Yes, | trust the authors」ボタンを押しましょう。 左のファイル一覧からapp/page.tsxを開き、「Get started by editing」の部分を「TEST」に書き換えて保存（CTRL+S）し、再度 npm run dev を実行してみましょう。 再度ページを表示してみると、上部が「TEST app/page.tsx」に書き換わっていることがわかります。 このようにして、Windows側のアプリケーションであるVisual Studio Codeを使い、Linux側に置いたファイルをシームレスに編集しながら開発を行うことができます。 便利ツールを入れていこう Homebrewで色々な便利ツールを入れていきます。 lazydocker コマンドが苦手な人でも、わかりやすくdockerの情報を表示し、dockerを操作することができます。 以下のコマンドでインストールし起動できます。 brew update && brew install lazydocker lazydocker dockerに関する詳細な情報を手軽に収集しつつ、ワンキーで色々な操作が行なえます。 lazygit lazydockerのgitバージョンです。こちらもサクサクとgitを操作できます。 brew update && brew install lazygit lazygit 開発を始めたいが、gitのコマンド操作に慣れていないという方におすすめです。 AstroNvim ほとんどの操作やファイルの編集などはVisual Studio Codeで行えます。しかしながらLinuxを触っていると、vimなどで操作をしないといけないシーンに出会うことはよくあります。 そのため、vimの操作を必死に覚えようとするのですが、これが根っからのWindowsユーザーには結構つらい作業だったりします。 vimは適切な設定をおこない拡張機能を入れていくことで使いやすくできますが、そもそもLinuxになれてない、vimになれていない人にとっては、この前段の作業すら困難なわけです。 そこである程度設定済みのvimをいれておくことで、いざというとき作業効率をよくしたり、vimそのものを触るモチベーションを高めることができるのではないか？と思いました。 そういうときに便利なのが、AstroNvimです。 AstroNvimはneovim（というvimの一種）の上に、使いやすくする設定を被せてくれるものです。 以下のコマンドでインストールしてみましょう。 brew install neovim git clone --depth 1 https://github.com/AstroNvim/AstroNvim ~/.config/nvim nvim インストールし、起動を行うと、いくつかのプラグインなどが自動的に入ります。 色々な設定が初期状態で入ってくれているおかげで、ちょっとした設定やコマンドを入力するだけで使いやすいvimベースのIDE環境が手に入ります。 まとめ できる限りコマンド入力にたより環境構築をおこない、ちょっと便利な開発環境を作り上げてみました。実際に開発に使おうとすると、もう少し細かい設定は必要になると思います。 WSL2が登場する前は、Linux開発環境を作る＝仮想マシン（VirutalBox / Vagrantなど）を入れるでした。 WSL2は昔ながらの仮想マシンセットアップと違い、立ち上げるのにそれほど時間はかかりません。 それに加え、仮想マシンではできない・やりにくいWindowsとのシームレスな連携、軽快な動作、仮想マシン以上の作り上げた環境のポータビリティ（エクスポートすることでバックアップ、移動、複製が容易に可）など、仮想マシンにはない多くのメリットがあります。 WSL2を一度も使ったことがないというWindowsユーザーの方は、ぜひ一度触ってみてください。 おまけ LinuxからWindows側のファイルを参照する /mnt/c を参照することで、Windows側のファイルを見ることができます。 vimなどで、直接ファイルを編集することもできます。 ubuntu@WinDev2306Eval:/mnt/c$ nvim /mnt/c/Users/User/test.txt WindowsからLinux側のファイルを参照する ファイル名を指定して実行（Windows キー + R）より、「\wsl$」を入力（\は日本語で言う￥（実際は半角で打つ）のことを指しています）することで、WSL2側のファイルを開けます。 Visual Studio Codeなどで、直接ファイルを開くことできますが、初回は警告が出ます。 Allowを選択することで開くことが可能です。 開発用マシンを日本語環境に設定変更する スタートメニューへ「langu」と打つことで、言語設定変更画面へのショートカットが表示されます。 「Add a language a this device」を選択し、「Langueage & region」画面を開き「Add a language」ボタンを押します。 「Choose a language to install」画面に「japan」と入力することで、日本語が候補に表示されますので、Nextボタンを押して確定させます。 日本語のインストールが作業が終わると「Sign out」ボタンが表示されるので、サインアウトして日本語化は完了です。 ただしこの作業だけでは、キーボードが英語配列認識されていたり、日本語入力ソフトが入っていないなどの問題が残ります。 この問題を修正するには、追加した日本語の横にある「…」を押し、「言語のオプションを開きます」 キーボードレイアウトを「英語キーボード（101/102キー）」から「日本語キーボード（106/109キー）」に変更し再起動します。 最後にタイムゾーンを「UTC+09:00 大阪、札幌、東京」に変更して完了です。 The post Windowsユーザーにささぐ、WSL2を利用した（ちょっと便利な）Linux開発環境作成 first appeared on Sqripts .

はじめましてTMです。私は普段ユーザー受入テストの設計、実装、実施まで一通り行う業務を担当しています。 この記事では、テスト分析・設計といったフェーズで、Chat GPTがどの程度活用できるのか実際に試したプロンプトと、得られた回答を紹介したいと思います。 AIにテスト設計をさせようと思った理由 生成AIであるChat GPTを活用することでテスト分析・設計が楽になるのでは？ 人間が考えた事と同じ事ができるか？ 今回AIを使って行なったこと テスト分析において人間が抽出したテスト要素と同じレベルでAIがテスト要素を抽出できるかの検証 人間がテスト設計し、同じようなアウトプットをAIが出力できるかの検証 ChatGPTがテスト分析・設計できるのか？できないのか？について先に結論を申し上げますと、今回の検証では分析はある程度上手くいきましたが設計では微妙な結果になりました。 上手くいったところだけ紹介したいところですが、上手くいかなかったところも参考になればと思います。 環境 SlackGPT（API） AGESTではSlack経由でChatGPTのAPIを利用できる環境（SlacGPT）が提供されているので、こちらを利用しています。 API版はWeb版と異なりモデルのトレーニングや改善には原則使われないサービスです。 API data usage policies テスト分析・設計をおこなう対象 AIにテスト分析・設計をおこなってもらう対象として、架空のECサイトのコンテンツ横断型ポイント還元キャンペーンを設定しました。 〇開催期間：7月25日（火）17:00〜8月7日（月）23:59 〇キャンペーンへの参加方法： ・キャンペーンに参加するためには、エントリーが必要です。 ・ログイン後、特設ページ内のエントリーボタンからエントリーができます。 ・キャンペーンの開催期間中に発生した購入（サービスご利用）であれば、エントリー前の購入（サービスご利用）もキャンペーンの対象になります。 〇キャンペーン内容： ①ポイント倍率最大50倍！ABCのサービスを複数ご利用でポイントアップ 2サービス以上のご利用でポイント倍率が15倍になるほか、3サービス以上のご利用でポイント倍率が5倍ずつ上昇します。期間中9サービス以上ご利用でポイント倍率が50倍になります。 ※キャンペーン期間中に1サービスあたり500円（税込）以上のご利用が対象になります。 ※ポイント倍率アップに最適な商品として、500円（税込）で販売する商品も多数ご用意しています。 ②土日限定！ポイント倍率+10倍 「ABCポイント還元祭」期間中の土日にサービスをご利用いただくことで、ポイント倍率がプラス10倍になります。 ※対象期間：7月29日（土）、7月30日（日）、8月5日（土）、8月6日（日） ③ABCゴールド会員限定！ポイント倍率+5倍 ABCゴールド会員限定で、ポイント倍率がプラス5倍になります。 ※キャンペーン期間中にABCゴールド会員に登録していて、かつ還元ポイントの集計日である9月15日（金）までゴールド会員に登録していることが条件です。 ※キャンペーン期間中から集計日までに一度でも解約された場合は、集計日にABCゴールド会員に登録していてもポイント付与の対象外とします。 ※キャンペーン期間中であってもABCゴールド会員登録前の購入分は、本施策のポイント付与対象外になります。 ④3日間限定！対象カード決済によるポイント還元 8月1日（火）～8月3日（木）の3日間限定で、対象カードによる決済額の合計に応じたポイント還元を行います。 【ポイント還元率】 ・10,000円以上30,000円未満の利用で8%還元 ・30,000円以上50,000円未満の利用で10%還元 ・50,000円以上の利用で12％還元 〇対象サービス一覧： ・ABCトラベル ・ABC保険 ・ABC外国語 ・ABC証券 ・ABCミュージック ・ABCカーシェア ・ABCTV ※レンタル・購入のみ対象、月額料金は対象外 ・ABCアミューズメント ・ABC通販 ・ABCコミックレンタル 〇注意事項： ※クーポンを利用した場合は、クーポン利用後の決済額を対象として還元ポイントを計算します。 ※ABC保険での取り扱い商品の中には、一部キャンペーン対象外の商品があります。 ※その他の注意事項につきましては、特設ページをご確認ください。 テスト分析において人間が抽出したテスト要素と同じレベルでAIがテスト要素を抽出できるかの検証 テスト要素の抽出（人間） テスト分析では、まずステークホルダーにヒアリングして何を見て欲しいのか確認します。 以下の回答を得られたとします。 サービス横断しているので、複数サービス利用するケースを見てほしい 還元するポイントが増減するので間違えていないか確認してほしい 上記を念頭にしたテスト分析では ポイントに関する要素が重要 と判断しました。 この後のテスト設計に繋げるためにも、まずはポイントに関する要素をテスト対象として抽出します。 開催期間（期間外/期間内） 参加有無（エントリーあり/なし） 複数サービス利用（ポイント倍率最大50倍、2サービス以上15倍/3サービス以上で5倍ずつ上昇） 最低利用金額（500円） 曜日（土日はプラス10倍） ゴールド会員の倍率（会員はプラス5倍） ゴールド会員の期間（キャンペーン期間中の入会/解約）ｘ（サービス利用） 対象カードの還元（8月1日（火）～8月3日（木）の3日間はABC 対象カードポイント還元（8%/10%/12%）） 対象サービス数（10サービス） クーポン（割引後の金額と最低利用金額の考慮） テスト要素を抽出していただく（AI） 今回は要素の抽出なので、結論などは記載して欲しくないため以下のようなプロンプトを実行します　 参考URL Chat GPTの回答 続いてポイントに関する要素を抽出してもらいます、いくつかプロンプトを試したところ以下のプロンプトで求めるものに近い結果が得られました。 Chat GPTの回答 要素の抽出において人間と同レベルの結果が得られたか？ Chat GPTの回答にあって私が抽出した要素になかったものが以下になります。 一部キャンペーン対象外の商品に対する考慮 ポイント倍率アップに最適な商品として、500円（税込）で販売される商品がある 「一部キャンペーン対象外の商品」については、重要なテスト要素となりえるため考慮すべきでした。 次に「ポイント倍率アップに最適な商品」については、最低利用金額500円で考慮しており、特段わけて考える必要はないと判断しました。 逆に人間が抽出したものでAIが抽出できなかったものはありませんでした。 今回はある程度プロンプトがうまくいった成功例と言えます。 テスト分析時の要素の抽出において、 プロンプトを工夫すれば 有用な回答が得られました。 また、今回工夫した点は、 ポイントに関する要素に絞った事 です。 以下のような要素の絞り込みをしていないプロンプトの場合 人間があまり重要ではないと考えた要素（参加方法）も抽出してしまいます。 人間がテスト設計し、同じようなアウトプットをAIが出力できるかの検証 テスト観点を考える（人間） ①複数サービス利用のポイントアップ 複数サービス利用（ポイント倍率最大50倍、2サービス以上15倍/3サービス以上で5倍ずつ上昇） 対象サービス数（10サービス） 利用サービス数 ポイント倍率 1 0 2 15 3 20 4 25 5 30 6 35 7 40 8 45 9 50 10 50 境界値分析を用いて、ポイント倍率がつくケースとつかないケースを確認する 同値分割を用いる（1~2の15倍UPグループ、2~9の5倍ずつUPグループ 9~10は上限到達グループ） テストデータ：1,2,3,8,9,10 対象サービス（10）は最低1回は利用する 利用サービス数ごとにポイント倍率が正しいことを確認する ②土日のポイントアップ 曜日（土日はプラス10倍） 金曜 土曜 日曜 月曜 7/28 7/29 7/30 7/31 8/4 8/5 8/6 8/7 境界値分析を用いて、土曜日になる前後の確認を実施する テストデータ：7/28 23:59:59、7/29 0:00:00、8/4 23:59:59、8/5 0:00:00 境界値分析を用いて、月曜日になる前後の確認を実施する テストデータ：7/30 23:59:59、7/31 0:00:00、8/6 23:59:59、8/7 0:00:00 最初の土日と2回目の土日でポイント10倍であることを確認する（2回目で20倍になったりしない） 土日以外の曜日でポイントがプラス10倍になっていないことを確認する ③ゴールド会員のポイントアップ ゴールド会員の倍率（会員はプラス5倍） ゴールド会員の期間（キャンペーン期間中の入会/解約）ｘ（サービス利用） ゴールド会員 会員 非会員 +5倍対象 +5倍非対象 サービス期間中の入会 入会前 入会後 +5倍非対象 +5倍対象 ポイント付与日までの解約 解約なし 解約あり 解約後入会 +5倍対象 +5倍非対象 +5倍非対象 境界値分析を用いて+5倍対象、対象外の7ケースを確認する ④対象カード決済のポイントアップ 対象カードの還元（8月1日（火）～8月3日（木）の3日間は対象カードポイント還元（8%/10%/12%）） 利用金額 還元率 ～9,999円 0% 10,000円～29,999円 8% 30,000円～49,999円 10% 50,000円～ 12% 境界値分析と同値分割を用いて8%、10%、12%の還元率になる金額をテストする テストデータ：9,999円、10,000円、29,999円、30,000円、49,999円、50,000円、50,001円 ⑤条件適合性 開催期間（期間外/期間内） 参加有無（エントリーあり/なし） 最低利用金額(500円) クーポン（割引後の金額と最低利用金額の考慮） コンディションとアクションなのでデシジョンテーブルで整理してみる – – 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 条件 開催期間内 Y Y Y Y N Y Y N Y N N Y N N N N – エントリーあり Y Y Y N Y Y N Y N N Y N Y N N N – クーポン利用あり Y N Y Y Y N Y Y N Y N N N Y N N – 利用金額は500円以上 Y Y N Y Y N N N Y Y Y N N N Y N 動作 ポイント倍率UPあり X X – – – – – – – – – – – – – – – ポイント倍率UPなし – – X X X X X X X X X X X X X X テストデータNo.1,3,4,5 No.1：クーポンを利用してポイント倍率UPされるケース No.3：クーポンを利用したら金額が500円未満になってしまったケース（他条件は対象） No.4：エントリーを忘れてしまったケース（他条件は対象） No.5：対象期間前に利用してしまったケース（他条件は対象） ※今回はプログラムが処理される順序が不明なブラックボックステストを想定して、デシジョンテーブルの動作単位で整理はしていません。 そのうえで、ひとつの条件で対象外になるケースは各条件が想定どおり動作する確認のために必要と考えました。 テスト観点を考えていただく（AI） AIには、先ほどAIが抽出した後に以下のプロンプトで指示をだしました。 Chat GPTの回答 7つのグループにわけてテスト設計してくれましたが、グループ2：ポイント倍率アップに最適な商品は、ポイント倍率アップに最適な商品として500円の商品が多数ラインナップされることであり、ポイントの増減の観点ではあまり有効とは思えません。 また、「開催期間」や「エントリーの有無」といった条件がどのグループにも現れていない結果になりました。 人間と同じような設計アウトプットが得られたか？ 今回の設計アウトプットを比較すると下図のようになりました。 グルーピングについて あまり有効ではない「グループ2：ポイント倍率アップに最適な商品」をグルーピングしています。また、人間が設計した場合は⑤条件適合性として複数条件をまとめてテスト設計していますが、（プロンプトを与えていないので当然ですが）個別の考慮にとどまっています。 考慮漏れ 要素で抽出した「開催期間」と「エントリーの有無」がなぜか欠落しました。 テスト技法について AIのテスト設計では、7グループ中6グループでデシジョンテーブルが提案されています。 しかしながら、デシジョンテーブル技法は複数の条件のもと、それぞれの場合の振る舞いを整理するために活用する技法で、今回AIがグルーピングしてくれた単位では、条件が少なすぎて有効ではないと考えられます。 具体例として、AIがテスト技法にデシジョンテーブル（と同値分割）を提案したグループ1で、デシジョンテーブルを作成してもらいました。 グループ1に対するデシジョンテーブル作成のプロンプト Chat GPTの回答 グループ1で作成してくれたデシジョンテーブルでは条件が「上限値未満」と「上限値超過」しかないので有効ではない結果となりました。 まとめ 今回の検証方法では、テスト分析では期待したアウトプットに近い結果が得られましたが、テスト設計では人間と同等のアウトプットは得られませんでした。原因は、テスト分析でAIが抽出した要素（グループ分け）をそのままテスト設計のインプットとした事です。 AIはあくまでプロンプトに従って結果を生成しているので、テスト分析の結果から、テスト設計に落とし込む過程で人間が考えた事をプロンプトに明確に指定する必要があると感じました。 おわりに ECサイトの期間限定ポイント還元という、比較的わかりやすいシステムを対象にした今回の検証結果、いかがでしたでしょうか？ 概要レベルで出してくれるアウトプットがそのまま使えそうじゃないか！？と飛びついて使用してみた生成AIですが、実際に活用しようとすると人間側の指示がかなり重要で、テスト分析やテスト設計といったフェーズ事に一気通貫で活用するのは難しい結果になりました。　フェーズごとに人間が介入して訂正する事を前提に考えると、テスト分析の結果はJSON形式などの人間にもわかりやすく、かつAIにも一定の形式になっていて加工しやすいデータ形式でアウトプットすることで、テスト分析からテスト設計への移行が楽になるかもしれません、うまく活用してQCD改善していきたいですね。 最後まで読んでいただき、ありがとうございました。 力こそパワー ■AIを活用したソフトウェアテストのサービス化を視野に、AI技術の研究開発を行う「AGEST AI Lab.」を設立しました 詳しくは こちら から The post ChatGPT！テスト設計できるのかい？できないのかい？どっちなんだい！ first appeared on Sqripts .

本連載では、ブロックチェーンの基本的な仕組みを解説しながら、オンチェーンデータを分析するための基本的な手法について、全8回で紹介します。 第3回となる今回は、暗号資産（仮想通貨）のなかでビットコインに続き第2位の時価総額 （※1） を維持しているイーサリアム （※2） について解説し、ブロックチェーンの仕組みについての理解を深めます。 ※1 CoinMarketCap （2023年6月現在） ※2 Ethereum イーサリアムとは イーサリアムは、ブロックチェーン技術を用いて実装された、分散アプリケーションのためのプラットフォームです。 ビットコインの発明とともに登場したブロックチェーン技術は、 第2回 の連載記事でも解説したとおり、「不特定多数の参加者で構成されるネットワークで、悪意のある参加者が存在したとしても、全体として正しく動き続ける分散アプリケーション」を実現することができます。ビットコインはそれをデジタル通貨として利用しましたが、ブロックチェーン技術は通貨以外にもさまざまな応用が考えられます。 例えば、簡単なマイクロブログサービスを分散アプリケーションとして実装すれば、特定のプラットフォームに依存することなく、いつでも自分のつぶやきを投稿することができ、誰かに検閲されることもなければ、サービス終了とともにデータが消えてしまうということもありません。そのようなさまざまな分散アプリケーションを簡単に実現するためのプラットフォームがイーサリアムです。 イーサリアムの誕生 ブロックチェーン黎明期の分散アプリケーション開発の多くは、ビットコインのコードベースをフォークしてきて、一部を修正するような形でおこなわれていました。第1回の連載記事でも紹介した、「ライトコイン」 （※3） や「ネームコイン」 （※4） などがその典型例です。ビットコインのコードはオープンソースとして一般に公開されており、誰でもダウンロードして実行できるだけでなく、一部を改変して独自のアプリケーションとして実行することも可能です。 しかし、ビットコインをフォークした形のアプリケーション実装では、そのアプリケーションを動かし続けてくれるためのネットワーク参加者を集めることにハードルがありました。一般的なWebサービスなどのアプリケーションであれば、開発者自身がサーバーを準備してアプリケーションを公開するだけで、世界中の人々がそのアプリケーションにアクセスできます。一方、ブロックチェーンアプリケーションの場合、そのサービスを使いたい利用者が自身のマシンにアプリケーションをダウンロードしてきて、そのマシン上でプログラムを実行し続けなければなりません。もちろん、ビットコインのようにある程度の参加者が集まれば、既存のネットワーク参加者のノードに対して通信するだけでサービスを利用できる形になるのですが、安定したサービスを提供できるレベルまでネットワーク参加者を集めるには、よほど共感されるアイデアやメリットがない限り困難でした。 そこで、すでに稼働している既存のブロックチェーンの上に、汎用的なアプリケーション層を構築するサービスも登場してきました。例えば、ビットコインの場合、トランザクションのなかにビットコインの送金だけでなく、メッセージのような小さなデータを書き込むことができる仕様がありました。ビットコインのトランザクションにテキストを書き込むことで、上記の分散型マイクロブログのようなサービスは構築できます。また、より大規模なデータを扱いたい場合でも、そのデータをハッシュ関数で小さなデータに圧縮することで、「過去にそのデータが存在しており、それ以降改ざんもされていない」といった存在証明が可能です。Blockcerts （※5） というサービスでは、大学の卒業証明書や民間の資格証明書などのハッシュ値をビットコインブロックチェーンに刻み、存在証明をおこなうことで、誰もが簡単にブロックチェーン技術を用いた証明書を発行することができます。 しかし、既存のブロックチェーンを他の用途で使うという仕組みは、もともと想定されていないハック的な使い方のため、使い勝手や効率もよくありません。そこで、汎用的な分散アプリケーションを動かすために設計された新しいブロックチェーンシステムとして、イーサリアムが登場しました。 イーサリアムは、当時19歳の学生であったヴィタリック・ブテリンによって考案されました。そのアイデアがホワイトペーパー （※6） として公開されています。2014年ごろから開発が進められているEthereumは、2023年現在までに大きなアップデートを何度も繰り返しているため、ホワイトペーパーだけを読んでも現在のEthereumの全貌を理解することは難しいのですが、当時の背景やコアコンセプトを知ることで現在の仕組みもより深く理解することができると思いますので、興味あるかたはぜひホワイトペーパーも読んでみてください。 ※3 Litecoin ※4 Namecoin ※5 Blockcerts ※6 Ethereum White Paper スマートコントラクト イーサリアムの特徴は、さまざまな分散アプリケーションのロジックを専用のプログラミング言語で記述し、ブロックチェーン上で実行できる点です。ブロックチェーン上で実行する、というのは、トランザクションを発行してブロックチェーン上の状態を変更できる、という意味です。ビットコインの場合も、抽象的にはアカウントごとにビットコイン残高という状態があり、トランザクションの実行後にその状態（残高）が変化する、という形で状態遷移をおこなっています。また、ビットコインのトランザクションも、スクリプトと呼ばれるプログラミング言語でルールが記述されている、という点も似ています。 しかし、ビットコインのスクリプト言語は、通貨の送金という用途に特化しており、無限ループなどを含む任意のロジックを記述することはできませんでした。イーサリアムの場合、無限ループを含む任意のロジックを専用のプログラミング言語で記述し、ブロックチェーンに配置しておくことができます。イーサリアムの利用者は、あらかじめ配置されたプログラムの関数を呼び出すトランザクションを発行することで、通貨の送金だけではないさまざまな用途の分散アプリケーションを利用することができます。 この、イーサリアムにおける汎用的なプログラムを、「スマートコントラクト」と呼びます。スマートコントラクトというアイデアは、デジタル通貨の研究者であるニック・サボが1997年に提唱 （※7） しています。ニックのアイデアは、現実世界における自動販売機のような自動執行される契約をデジタル上でも実装するといったものです。例えば、自動車を運転する権利などを契約に基づいて自動的に移転できるようになれば、自動車を担保にしたローンや、レンタカーの運転権利などを自動で権利者に移転したりすることができます。 2023年現在では、そのようなオンラインで物理的なものの使用権を移転できるサービスも普及しつつありますが、多くは特定企業によるサービス提供だと思われます。イーサリアムの場合、このスマートコントラクトを、不特定多数の誰もが参加できるブロックチェーンネットワーク上で実行し、特定のサービス主体に依存しない、次世代スマートコントラクトとして提唱しています。現在、一般的にスマートコントラクトと呼ぶと、イーサリアムを代表とするブロックチェーン上の分散プログラムのことを指すことが多くなっています。 ※7 The Idea of Smart Contracts ビットコインとのデータ構造の違い 同じブロックチェーン技術の応用であっても、ビットコインとイーサリアムにはさまざまな違いがあります。データ構造における両者の最も大きな違いは、UTXOモデルとアカウントモデルです。 第2回の連載記事でも解説したとおり、ビットコインのトランザクションには「Inputs」と「Outputs」という概念があり、Outputsのうちまだどこにも送られていないものが、自由に使える残高、という考え方です。この未使用トランザクションアウトプット(Unspent Transaction Output)をUTXOと呼びます。 一方、イーサリアムの場合は、通貨の送金だけでなく、文字列や複雑なデータ構造を含む汎用的な状態を管理するため、アカウントに対して通貨の残高データが紐づくアカウントモデルとなっています。 実データを観察する それでは、実際のデータを観察しながら、これまでの解説を確認してみましょう。ビットコインの場合と同様、イーサリアムも自身でノードを立ち上げて、イーサリアムネットワークから情報を取得することもできますし、イーサリアム上のデータをデータベース化したオンラインサービスも数多く存在します。 Etherscan Etherscan （※8） は、イーサリアムが登場した黎明期から存在し、機能拡張を繰り返し現在でも多くのユーザに利用されているエクスプローラーサービスです。図1に、Etherscanのサービス画面例を示します。 図1. Etherscanのサービス画面 ビットコインの場合と同様に、生成された最新のブロックや、ブロックに含まれるトランザクションの一覧が確認できます。ビットコインの場合は生成されるブロックの間隔は10分前後でしたが、イーサリアムの場合は12秒前後のため、頻繁に画面も更新されます。 ※8 Etherscan Dune イーサリアムのオンチェーンデータを用いて簡単にデータ分析をおこなえるサービスとして、Dune （※9） を紹介します。第2回の連載記事で紹介したBigQueryでも、一般公開データセットにイーサリアムのデータセットが含まれており、SQLを用いて柔軟な分析が可能です。Duneはそのブロックチェーン特化版の分析サービスであり、ブロックチェーン特有のデータ構造に細部まで対応していたり、作成したクエリやダッシュボードを他ユーザに共有したり可能なソーシャル要素もあるスタートアップサービスです。 図2は、Duneの共同創業者である @hagaetc が作成したダッシュボード例です。 図2. Dune – @hagaetc / DEX metrics のダッシュボード例 ※9 Dune イーサリアムのデータ構造 Etherscanの実データを参照しながら、イーサリアムのデータ構造について確認していきましょう。 ブロック 多くのブロックチェーンでは、複数のトランザクションをまとめたブロックが、前のブロックのハッシュ値を参照している、というデータ構造は変わりません。イーサリアムの場合も、ビットコインと同様に、ブロックとトランザクションというデータ構造を持っています。 図3. Etherscan – ブロックのサンプルデータ 図3に、Etherscanで表示したイーサリアムのブロックデータのサンプルを示します。Block Heightは、そのブロックチェーンが積み重ねてきたブロックの長さを表します。Transactionsの行を見ると、このブロックには144のトランザクションと、43の内部トランザクションが含まれていることが分かります。 イーサリアムのブロックも、イーサリアムネットワークに参加している不特定多数のノードによって自律的に生成されており、ブロックの生成に成功した参加者が、所定の手数料を受け取れる仕組みになっています。それらに関する情報が、Fee RecipientやBlock Rewardです。 イーサリアムに特徴的な仕組みとして、ガス（Gas）という概念が存在します。これは、トランザクションを発行するための手数料を計算する仕組みに関連する概念です。ビットコインの場合も、トランザクションを発行するために手数料を支払う必要がありますが、その金額は基本的にトランザクションのデータ量（bytes数）に比例します。ただし、トランザクション手数料の設定はトランザクション発行者が任意に決めることができ、優先的に自身のトランザクションを取り込んでもらうために多めの手数料を支払う、といったことも可能です。 イーサリアムの場合、トランザクション発行者が手数料を任意に決められる、という点では同じですが、そのベースとなる値はトランザクションのデータ量ではなく、トランザクションを計算するために消費するリソース量となります。これは、イーサリアムが無限ループを含むようなプログラムの実行も許容する仕組みとなっているため、トランザクションのデータ量が少ない場合でも、実行のために膨大なリソースを消費してしまう可能性があるためです。このトランザクション実行に必要なリソース量を、ガスという概念で表現しています。 あるトランザクションを実行するために必要なガスは、あらかじめ厳密に計算することは難しいものの、同じ入力に対してであれば基本的には一定のガスがかかります。このガスに対して、1ガスあたりの手数料をトランザクション発行者が指定し、Ether(単位: ETH)というイーサリアムのネイティブ通貨で支払います。 トランザクション 図4は、あるブロックに含まれるトランザクションの一覧を表示したサンプルデータです。トランザクションには固有のトランザクションハッシュ（Txn Hash）がIDとして付与されており、誰が（From）、誰に（To）、ETHを送った量（Value）、実行したメソッド（Method）、支払った手数料（Txn Fee）などが共通の情報として含まれます。 図4. Etherscan – ブロックに含まれるトランザクション一覧のサンプルデータ また、リンクとなっている適当なトランザクションのハッシュをクリックすると、そのトランザクションの詳細ページを確認できます。詳細ページに表示される内容はトランザクションの種類によって異なるため、今回は詳細を割愛し、次回以降の連載で必要なトランザクションの種類について深掘りします。 図5に、トランザクション詳細のサンプルページを示します。Overviewのほかに、他のタブを選択することで、表示内容を切り替えることができます。ここでは、Logsタブを開いてトランザクションの詳細なイベントログを表示しています。 図5. Etherscan –トランザクション詳細のサンプルデータ コントラクト Etherscanのページでは、一部のコントラクトについてはソースコードも含めて確認することができます。図5のサイト上の「View Source」から遷移したコントラクトページのサンプルを図6に示します。 図6. Etherscan – コントラクトコードのサンプルデータ イーサリアムのトランザクションの詳細な内容を把握するには、こちらのコントラクトコードまで遡って理解する必要がある場合もあります。また、Etherscanでは、コントラクトコードに実装しているメソッドをサイト上で呼ぶ機能もあります。Read Contractタブでデータ取得系のメソッドを実行することで、そのコントラクトの現在の状態などをノーコードで確認できます。 また、これはまだベータ版の機能ですが、ChatGPTのAPIを利用して、コントラクトコードの内容をAIによって解説したり要約したりといった利用が可能なCode Readerというサービスもアナウンスされました （※10） 。 ※10 Twitter – @etherscan コントラクト規格 イーサリアムでは任意のコントラクトコードを実装して実行できますが、各自がバラバラの仕様でコントラクトを実装すると、他のコントラクトで統一的に扱ったり、データの分析が困難になったりする可能性があります。 そこで、イーサリアムではよく利用されるコントラクトの用途について、標準規格の策定が行われています。その規格化は、インターネットの技術仕様の標準化に用いられているRFC(Request For Comments)をもじって、ERC(Ethereum Request for Comments)と呼ばれています。代表的なERCのコントラクト規格には、ERC-20（Token Standard）やERC-721(Non-Fungible Token Standard)などがあります。詳しくは、実際のデータ分析の回にて解説します。 次回予告 イーサリアムの登場によって、ブロックチェーン技術を活用したスマートコントラクトの開発が容易となり、さまざまな種類の分散アプリケーションが登場しました。また、コントラクト規格の標準化により、統一的なインターフェースで、それらの分散アプリケーションのトランザクションを分析することも可能となりました。 次回の記事では、ブロックチェーン上のオンチェーンデータを分析するためのクエリ言語として、SQLの基礎について解説し、オンチェーンデータ分析の準備を始めていきます。 【 第1回】：ブロックチェーンとは 【第2回】：ビットコインの仕組み The post 【第3回】イーサリアムの仕組み first appeared on Sqripts .

みなさんこんにちは。エリアマネージメント部のゆーてぃです。 今回はテストを始める前にいつも行っていることを記事にしたいと思います。 要求は人によって様々 みなさんは買い物の時にどんなものがあるか見てから決める時があるのではないでしょうか。時には店員さんに「こういう機能がついてる物がほしい」、「●円の予算に収まる物がほしい」、「在庫があってすぐに持って帰れる物から選びたい」などの要求を伝えた上でアドバイスを聞くこともあると思います。 それはテストも同じことで、テストの目的はプロジェクトによって様々で、「これらを満たすようにテストしたい」や「この予算内でテストしたい」、「いついつまでに完了するようにテストしたい」といった内容もあります。 「JSTQB Foundation Level シラバス」にも以下の記載があるように、我々は店員の目線からしっかりと要求事項を整理した上でそのプロジェクトにあったプランを検討し、共通のゴールを明確にして進めることが重要だと考えています。 （以下、JSTQB FLシラバスから抜粋） 「1.4.2 テストの活動とタスク」 テスト計画では、テストの目的と、状況により課せられる制約内でテストの目的を達成するためのアプローチを定義する（例えば、適切なテスト技法とタスクを指定し、納期に間に合うようにテストスケジュールを作成する）。 出典： ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03 では「多端末テスト」に対して「できるだけたくさんの端末でテストしたい」との要求を伺った場合を例として、日頃どのようにゴールを決めているか、一つ一つ説明していきたいと思います。 要求事項を整理 ・目的の確認 多端末テストを行う目的として「画面比が異なることによる表示バグがないか確認したい」や「OS依存の不具合を見つけたい」、「一般ユーザー向けに公開する推奨環境を検討したい」など目的は様々あります。 目的を理解していないと、目的にあった端末を選定できず、テストアプローチも正しく検討できません。目的から外れた効果の薄いテストにならないよう、まずは目的を明確にします。 ・プロダクトタイプ、ユーザー層の確認 テスト対象のプロダクトがどのようなもので、どのユーザー層をターゲットとしているかで、テスト端末の選定幅も変わってきます。たとえば、BtoBなのであれば、ユーザーとなる企業で実際に使われている端末でテストするのが効果的ですし、BtoCなのであれば市場シェア率を考慮した選定を行います。 また、性別、年代によってシェア率は変わりますのでユーザー層を把握した上で端末選定を行うとより効果的になります。 ・制約事項の確認 次にプロジェクトの制約事項について確認していきます。 予算、納期、リソースのすべてに余裕があり、やりたいテストをすべて実行可能なプロジェクトはない。と言っても過言ではないと思います。制約事項を把握することで正しい優先度付けができると考えています。 テストプランの検討 ある程度の情報が揃ったところで一度テストプランを3パターン程検討します。 ・パターン1： 品質優先 のおすすめプラン 要求をしっかり理解した上で、テストの知見、実績ベースの過去データをもとに品質を高めることを優先としたアプローチを検討し、予算、納期への影響を明確にします。 ・パターン2： 品質、納期をキープする プラン 目的の達成、且つ納期に間に合うアプローチを検討し、テスト内容、予算への影響を明確にします。 ・パターン3：一部目的を削り 制約内でテスト するプラン 決められた予算、納期の制約内でテストを行った場合のテスト内容、および品質に対するリスクを明確にします。 そして、テストプランを検討した後は、各パターンの期待される効果を説明した上ですり合わせを行います。もちろん我々としては「品質優先のおすすめプラン」を推奨しますが、プロジェクトによってマッチするものは変わってくると思います。最後はしっかりとすり合わせた後、プランを選択することで、共通のゴールが明確な状態でプロジェクトを進めることができます。 まとめ 今回はテストを始める前にいつも行っていることを「多端末テスト」を一例として記事にしてみました。何れのプロジェクトでも要求は様々だと思いますので、我々はスタート前にしっかりとゴールを決めた上で、プロジェクトを進めることが重要だということを日々念頭において、業務を遂行したいと思います。 The post お客様満足度の高いテストプランの組み立て方～3つの確認でゴールを決めよう～ first appeared on Sqripts .

AGEST Academyです。 本記事では、ソフトウェアテストを始めたばかりの人、まだソフトウェアテストをやったことがない人に向けて、「ソフトウェアテストとは」どういうものかについてご紹介します。 新米テスターの「ぱなも・ホワイト」 とテスト経験258年の「ニャックス・ブラック」 が、それぞれの経験に基づいて楽しくお話しています。 本記事を通して、皆さんの考えるソフトウェアテストについて少しでも触れられましたら幸いでございます。 (1)ニャックスのソフトウェアテスト 新米テスターのぱなもでキュルン。 よろしくキュルン。 テスト経験258年のニャックスだ。 よろしく。 困ってることはあるか？ 先輩にとって、テストってどういうものキュルン？ どうした？ テストの話をしても理解がなくて……うまく伝わらないキュルン。 私も 学校のテストとは 違うのか、問われたことがある なんて答えたキュルン？ 学校のテストは、こうなるべきという決められた解答がある。ソフトウェアテストには、 答えが一つでない 場合もある。 不確実で創造的 なものだ。 すごくわかるキュルン！ 実際は、学校のテストでも「 生徒・教師・保護者・それ以外の関係者 」でそれぞれテストの捉え方が違うはずだ。 関係者が学校のテストについてどう向き合っているのか調べたものを紹介する。 　※ なぜ(学校で)テストをするのか 要約：「言語テスト研究」でよく言及される 「妥当性」や「信頼性」といった基本概念 をとってみても、教師との思惑のずれが見える。「妥当性」とは、「 測ろうとしている能力をテストが測っているか 」を表し、「信頼性」とは「 測ろうとしている能力を安定して測っているか 」を表している。これらの概念の大前提は， テストでは何らかの「能力」を測ろうとしている ということである。 ＜出典＞ 三省堂 TEACHING ENGLISH NOW vol.27 妥当性や信頼性 という表現が非常に興味深い。 このレポートとテストの思想は近い ものだ。 人によってこんなにも捉え方が違うキュルン？ 面白いキュルンっ～～！！ 良いセンスだ。 私にとってのソフトウェアテストは、 価値観の違いが生む人のすれ違いを減らす活動 だ。 （でも、先輩のようにうまく伝えられる自信がないキュルン……） (2)有識者のソフトウェアテスト ソフトウェアテスト技術者資格認定で知られるJSTQBのテストを紹介する 「すべてのライフサイクルを通じて実行する静的、動的なプロセスにおいて、成果物が特定の要件を満足するかを判定し、目的に合致することを実証し、欠陥を見つけるため、ソフトウェアプロダクトや関連成果物に対し、計画、準備、評価すること」 ＜出典＞ JSTQB用語集 – テスト(testing) 難しいキュルン…… 文章は固いかもしれないな。 次に、IEEE Software誌の元編集長で知られるSteve McConnellのものを紹介する。 「ソフトウェアテストは、もっともポピュラーな品質改善方法である」 ＜出典＞ Steve McConnell 品質改善キュルン？ ぱなもくんには、苦手な教科があるだろうか？ 社会が苦手キュルン。 テストの結果はどうだった？ 特に悪かったキュルン……。 テストの結果から社会が特に苦手だということが客観的にも分かる状況であるな。 このケースでは、テストの結果が良くないところを重点的に勉強して、次のテストで結果を出せばいい。 キュルキュルン！ 良くないところをピンポイントで良くしていく、テストの結果が品質改善のきっかけになるキュルンね～！ (3)高橋寿一さんのソフトウェアテスト 興味深い話をしているね 寿一さんにとって、ソフトウェアテストとはどういうものキュルン？ なくてはならないものだね。 そうだな……例えば、 品質マネジメント は 品質保証と品質コントロール に分類されるが、テストが密接に関わっている。 どちらの視点でソフトウェアテストを捉えるかでも議論の余地はあるね。 ぱなもくんだと……例えば、テスターとしてのテストは、製品の良くない事象（不具合）を見つけて、開発者に報告するだろう。そして、修正された製品に良くない事象がなくなっていることを確認し、製品の品質コントロールを手助けしていくことも多いだろう。 その通りキュルン この場合のソフトウェアテストとは、 プロダクト（製品）とその関係者をより良い方向に支援していく仕事 といったところだろうか。 Steve McConnellもいうように、テストはプロダクト（製品）とその関係者双方の品質改善を担うと考えている。 すごい仕事キュルン！！ すごい仕事だよ。 例えば、Glenford J Myersは以下のように言ってるね。 「テストとは、非常に創造的であり、知的に挑戦しがいのある仕事である」 ＜出典＞ ソフトウェア・テストの技法 第2版 Glenford J.Myers テストの仕事は、やりがいでいっぱいキュルン！ ははは、ソフトウェアテストで学ぶべきことはまだまだあるからね。応援しているよ。 (4)まとめ 章 説明 (1)ニャックスのソフトウェアテスト ソフトウェアテストは、答えが一つでない場合がある。もっと不確実性があり、創造的なもの。 (2)ニャックスのソフトウェアテスト ソフトウェアテストは、価値観の違いが生む人のすれ違いを減らす活動 (3)高橋寿一さんのソフトウェアテスト ソフトウェアテストとは、プロダクト（製品）とその関係者をより良い方向に支援していく仕事 出典先 説明 書籍 根岸雅史 ※学校のテスト 「妥当性」とは，「測ろうとしている能力をテストが測っているか」を表し，「信頼性」とは「測ろうとしている能力を安定して測っているか」を表している。これらの概念の大前提は，テストでは何らかの「能力」を測ろうとしているということである。 三省堂 TEACHING ENGLISH NOW vol.27 JSTQB用語集テスト(testing) すべてのライフサイクルを通じて実行する静的、動的なプロセスにおいて、成果物が特定の要件を満足するかを判定し、目的に合致することを実証し、欠陥を見つけるため、ソフトウェアプロダクトや関連成果物に対し、計画、準備、評価すること ISTQB公式 Steve McConnell ソフトウェアテストは、もっともポピュラーな品質改善方法である 知識ゼロから学ぶソフトウェアテスト【改訂版】 高橋寿一 Glenford J.Myers テストとは、非常に創造的であり、知的に挑戦しがいのある仕事である ソフトウェア・テストの技法 第2版 悩みは解決できたか？ 大丈夫キュルン！ これからは、もっと自信を持って話すキュルン♪ 良かった。 不安があればまた聞いてくれ。 本記事では、「ソフトウェアテストとは」というテーマに沿って、様々な表現や解釈があるということをご紹介いたしました。 今回内容に含まれなかった「 市場に出回った不具合による損失 」というものがあります。 JSTQB_FLシラバスでは、これらの損失を「(1)経済的な損失」「(2)時間の浪費」「(3)信用の失墜」「(4)障害や死亡事故」として取り上げています。このように 損失 や リスク といった視点からも、テストの有効性を証明することが可能です。 本記事を通して、ソフトウェアテストのやりがいを少しでもお伝えできていましたら幸いです。 Sqriptsでは、ソフトウェアテストに関する技術や考え方をお役立ち資料で紹介しています。本記事の詳しい内容については こちら からダウンロードいただけます。 The post テストの基礎１～ソフトウェアテストとは？～ first appeared on Sqripts .

この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。 第5回目のテーマは、「アジャイル開発の誤解」です。 この内容はUdemyで公開しているオンラインコース「 現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム 入門編 」の内容を元にしています。 よくある誤解： アジャイル開発はドキュメントを作らない 有名な誤解ですが、これは間違っています。 アジャイルマニフェストにも書かれているように、「ドキュメントよりも、動くソフトウェアを価値としよう」なので、ドキュメントを不要としているわけではありません。 よって、必要なドキュメントがあれば作ります。また、プロダクトの規模が大きくなればなるほど、必然的にコミュニケーションコストがかさむため、ドキュメントが重要になってくるでしょう。 それでは、アジャイル開発におけるドキュメントのイメージを持っていただくため、現場でよく見かけるドキュメントをいくつか紹介します。 インセプションデッキ： アジャイル開発版のプロジェクト憲章のようなもので、プロダクトやプロジェクトにおいて、自分たちのチームは同開発を進めていくか？ チームの共通認識を生み出すための文書です。 システム全体図： アジャイル開発は小さく開発していきますが、開発が進めば進むほどプロダクトは大きくなっていきます。ちょっとずつ組み立てていく過程を経験していれば、大きくなってもある程度理解できますが、途中から入ってきたメンバーにとっては、なかなか全体像が見えないものです。そういった場合、システム全体図のような高い視点のドキュメントが役に立ちます。 複雑な部分の仕様書： 仕様は全部整理しておきたいものですが、「仕様をドキュメントにまとめる」と決めた場合、それ自身が新しい仕事になります。そしてその仕事は、開発が続く限りずっと続いていきます。そのコストを払い続けても、それに見合ったリターンがあるなら良いと思います。もしそうといえないのであれば、まずは重要な部分の仕様書だけ整理しておくといいと思います。 振り返りのログ： アジャイル開発では、定期的にふりかえりを行います。そのときの学びをWikiやホワイトボードツールなどに残しておけば、過去の経緯や過去の学びが情報として溜まっていきます。 よくある誤解： アジャイル開発なら要件をいつでも変更できる？ これもよく見かける誤解です。 アジャイルソフトウェアの12の原則 にも書かれているように、要求の変更はたとえ開発の後期であっても歓迎します。しかし、何でもかんでも変更していては、どんな開発でも進んでいかないでしょう。 変更するということは、その時点で再計画が発生するという意味でもあります。再計画無しの変更は無謀です。これも12の原則にもあるとおり、アジャイル開発であれば、無理や無茶がない、持続可能な開発を促進しなければなりません。 変化の多い現場であれば、開発サイクルを短くしたり、やることを小さくするといいでしょう。大きなものを大きなまま開発しているのであれば、アジャイル開発よりも従来型の方がやりやすいかもしません。 よくある誤解： アジャイル開発は優秀な人にしかできない？ 筆者の回答は「誰にでもできる」です。 12の原則にあるように、アジャイル開発に必要なのは、意欲に満ちた人々です。意欲がないとはじまりません。 また、「試しにやってみよう」ぐらいの意欲だと失敗する可能性が高いです。きっかけとして悪くはないのですが、「必ず成功させよう」という意欲を持ったチームのほうが、成功率が高くなります。 優秀な人たちがチームにそろうといいことがありそうですが、個々の能力が高くても、チームの生産性が上がるわけでないという有名な研究結果が グーグルからも出ています 。チームでの開発が主流のアジャイル開発では、個人の能力だけではだめで、チームという集団での知性が問われるのです。 よくある誤解： アジャイル開発は計画を立てない？ アジャイル開発でも計画を立てます。ただ、計画の立て方が従来型とは異なります。 アジャイル開発は短い期間で開発を繰り返します。小さいものを積み上げていく方法なので、全体像が見えにくいという欠点があります。よって、3ヶ月毎、半年ごと、1年毎、というように、中長期的なリリース計画やロードマップが必要になります。 計画ごとの解像度のイメージ。濃い色になるほど解像度が高くなる。 注意したいのは、計画の解像度です。アジャイル開発は変化に対応していきたいので、従来型のようにかっちり計画をきめてしまうと、解像度は高まりますが、変化に弱くなります。変更があったときに、また解像度の高い計画を立てていては、スピードも出せません。 よって、アジャイル開発では、遠いものは見えにくいので低い解像度。近いものははっきりみえるので高い解像度・・・と、計画の解像度を変えて対応していきます。 つまり、遠くのものはざっくりと計画を管理し、現在に近づけば近づくほど解像度を高めていくのです。 よくある誤解： アジャイル開発は開発生産性を高める？ 従来型でもアジャイル開発でも、開発生産性を高められます。よって、従来型よりアジャイル開発のほうが開発生産性が高いということはないと思います。 アジャイル開発は、従来型の開発生産性の考え方をあまり適用しません。考え方が異なる方法同士なので、導入が難しいためです。 そのかわりといってはなんですが、アジャイル開発では、ベロシティ（チームのアウトプット量）やリードタイム（アイデアがリリースされるまでの時間）といった別の指標を計測して、チームの状態を確認していきます。 よくある誤解： アジャイル開発にはプロジェクトマネージャは必要ない？ アジャイル開発でもプロジェクト型の開発を行っているチームは多いです。期限があるプロジェクトをやるというよりは、プロジェクトを繰り返しながら開発するイメージです。 アジャイル開発であろうと、チームの開発を運営は必要なので、プロジェクトマネジメントの考え方は大切だと思います。ただ、アジャイル開発は自律したチームですので、計画もチームで作り、進捗もチームで見ていくので、チームが自律してしまえば、プロジェクトマネージャーは必要なくなるかもしれません。 もし、現在が、プロマネという役割によってチームが管理されている状況だとすれば、アジャイルチームの目指す自律性を阻害している可能性があります。 よくある誤解： アジャイル開発では設計しない？ ソフトウェア開発において設計は重要な活動ですから、設計はします。 ただ、アジャイル開発は短い開発サイクルをまわしていくものなので、従来型のような明確な設計フェーズはないことが多いでしょう。 短い開発サイクルの中で、設計＞開発＞テスト・・・と繰り返していくイメージになりますが、これだと小さなウォーターフォールになってしまい、期間の最後にまとめてテストすることになり、期間分の手戻りリスクが発生してしまいます。 これを回避するために、機能 ＞ 機能 ＞ 機能 と、期間の中で小さな開発を繰り返していく方法をとっているチームが多いです。 よくある誤解： アジャイル開発にQAは必要？ 従来型の開発の場合、作るべきものが明確なケースが多いので、品質を保証（Quality Assurance： QA）しやすいと思います。ここでいう品質は、仕様通り作られているかが中心になります。 アジャイル開発の場合、小さくリリースしたものに対するフィードバックを元に軌道修正していくので、「これは価値が大きい！」とリリース前に保証するのは至難の業です。ここでいう品質は、リリースしたものの価値の大きさが大きいほど品質が高いと言えます。 よって、アジャイル開発に従来型のQAという考え方を適用するのは難しいと思います。おそらく、網羅性の高いテストをリリースごとに繰り返していく形になるので、QAがフェーズになり、QAフェーズがボトルネックになる可能性が高いでしょう。 アジャイル開発には、アジャイル開発に適したテストや品質の考え方が必要です。まちがっても、速く作るからテストをすっとばそう！とはなりません。 よくある誤解： ユーザの価値、プロダクトの価値が重要？ 最後の誤解は、「ユーザの価値、プロダクトの価値が重要」です。もちろん重要なのですが、注意したい点があるので、あえて最後に解説します。 たとえば、プロダクトを優先させるために、チームが犠牲になり、連日連夜デスマーチを続け、チームが疲弊して離脱者が増える・・・といったケースもたまに見かけます。 アジャイル開発では、持続可能な開発を大切にします。プロダクトを優先させすぎて、それ以外の価値や原則が歪んでしまっていないかを意識するようにしたいものです。何かを犠牲にして何かを達成するのは、決して持続可能な開発ではありません。 また、アジャイル開発はチーム開発が中心になりますが、チームだけでなく個人も大切です。こちらもチームのために、個人が犠牲になるようなことがないようにチーム運営していく必要があります。 よくある誤解： アジャイル開発を導入すればうまくいく？ 世の中には「これを導入して売上UP」のような方法論やフレームワークがたくさんあります。たしかに、そういうベストプラクティスを駆使すれば、現状はよくなるかもしれません。 しかし、アジャイル開発は、成功を約束する方法論ではありません。あくまで成功率を高める手段です。 「アジャイル開発を導入したが良くならなかった」というケースがなくならないのは、この部分を誤解している可能性があります。 第1回：アジャイル開発の過去、現在、未来を知ろう！ 第2回：声に出して読みたいアジャイルマニフェスト 第3回： 従来型開発とアジャイル開発の違い　その１ 第4回： 従来型開発とアジャイル開発の違い　その２ The post 第5回 アジャイル開発のよくある誤解を解いていこう！ first appeared on Sqripts .

こんにちは、エリアマネージメント部の 蟹乃中 味噌太郎  です。 FacebookやTwitter、AmazonなどのWebサイトからExcel、Skypeといったソフトウェアなど様々な国で利用されているサービスがたくさん展開されています。皆さんも一度は利用経験があるのではないでしょうか。 そのような複数の国・言語に対応したソフトウェアをテストする機会もあるかと思います。ブラウザ、Webアプリケーション、スマートフォンアプリなど、システムによって観点が大きく異なることもありますが、今回はブラウザに焦点を当てて、私なりに注意したいポイントなどをご紹介させていただきます。説明には私の所属会社（AGESTとDIGITAL HERATS HOLDING）のホームページを使用します。 表示言語 複数の国で展開されるWebサイトをテストする場合、まず初めに初期表示となるデフォルト言語について確認する必要があります。 言語設定が未設定の場合はデフォルト言語となりますが、どのようにデフォルト言語が設定されているかを確認する必要があります。 単純にシステムのデフォルト言語で表示されるパターンもあれば、上記のようにアカウント毎の設定された地域や国を参照してデフォルト言語が変化するパターンもありますので注意が必要です。 言語設定が行われている場合は、デフォルト言語に影響することなく設定した言語で表示されることをテストする必要があります。 また、表示される言語が異なれば当然ながら単語や文章の長さが変化します。言語が変化することによってレイアウトが崩れてしまうことがありますので、各言語でレイアウトなどを確認するテストが必要となってきます。 リンク設定 リンクの場合、同じページに遷移するので、表示言語に合わせた言語で表示されるのでは？と思われるかもしれません。ですがリンクも表示言語に合わせて設定されている必要がありますので注意が必要です。 日本語に設定しているはずなのにリンク先に遷移すると英語で表示されたり、PDFの書類をダウンロードすると表示言語と異なる書類となっていたりする場合もあります。なので、リンクについても各言語毎にテストするように注意したいです。 実際にAGESTのホームページで確認してみます。 日本語のページだとURLが” https://agest.co.jp ”となっていますが、英語に切り替えると URLが” https://agest.co.jp/en/ ” となっていて、URLが少し変化していますね。次にヘッダにある「会社情報（Corporate）」を日本語と英語の場合で比較してみたいと思います。 まず日本語のリンク設定は、 ” /corporate/ “となっていますね。次に英語では、 ” /en/corporate/ “となっていますので、”/en/ ”がつくことにより英語の会社情報へ遷移するように設定されています。このように言語に合わせてリンクが設定されているため、遷移によって言語が戻ってしまう様なこともなく快適に利用できるというわけです。逆に言語に合わせてリンクが設定されていないと煩わしく使いづらいものとなってしまいます。 エラーメッセージ表示 バリデーションで入力必須のエラーメッセージが表示されるシステムの場合、特定の画面のみ設定言語とは異なる言語で表示されてしまったり、特定のエラーメッセージが設定言語と異なる言語で表示されたりといった不具合が潜んでいることがあります。 ※上図はページ内のテキストは英語表示なのに、エラーメッセージが日本語となっているイメージ画像です。この場合、エラーメッセージも英語で表示されるのが望ましいでしょう。 ここではエラーメッセージを例にしましたが、エラーメッセージに限らず特定の操作によって追加で表示されるようなメッセージやダイアログについては、設定言語に合わせて正しい言語で表示されるかをテストする必要があります。 日時表示がある場合 日時表示がある場合、どのような基準で表示されているかに注意を払う必要があります。例えば、国毎のタイムゾーンに合わせて日時表示が行われていて、「協定世界時（UTC）を基準としてそれぞれのタイムゾーンに変換して表示」している機能があったとします。 “10:00:00(UTC) “をアメリカの日時に変換する場合 （ここでは「CST（米国中部標準時）」に変換されると仮定）、CSTはUTC（協定世界時）から”-6:00:00”となるので、4:00:00（CST）が正しい変換となりますが、 日時が協定世界時（UTC）のままのパターン　 【10:00:00(UTC)  ⇒ 10:00:00(UTC)】  日時が別のタイムゾーンに変換されているパターン　 【10:00:00(UTC)  ⇒ 19:00:00(JST)】 ※JST（日本標準時はUTCから ”+9:00:00”なので19:00:00となります。） 日時は合っているがタイムゾーン表示が異なるパターン 【10:00:00(UTC)  ⇒ 4:00:00(JST)】  上記のような不具合が潜んでいる可能性が考えられます。 さらに、日本ではあまりなじみがありませんがサマータイムというものが国によっては設定されています。サマータイムは特定の期間に適用され、「協定世界時（UTC）基準で1時間進められる」といったものになり、タイムゾーンもサマータイム用のものに変化します。 「CST（米国中部標準時）」を例に挙げると、タイムゾーンは「CDT（米国中部標準時の夏時間）」となります。時間は「10:00:00(UTC)」を基準とすると、CDTの場合はUTCから”-5:00:00”となるので、「05:00:00（CDT）」となります。 そんなサマータイムですが、現在アメリカやヨーロッパで廃止する動きがあります。廃止となれば、サマータイムを採用しているシステムからも機能が廃止されることが考えられますので、それらの取り扱いについてもしっかりと確認しておきたいですね。 ちなみにアメリカでは、夏時間が恒久化される可能性があるようです。 価格の表示について 通貨が国によって異なることは言うまでもありませんが、国によって価格表示の桁数の表現も異なります。日本の場合、小数点に対応していませんが、アメリカでは小数点にあたるセントの単位があります。また、日本では数字の区切りが ”カンマ” で区切られておりますが、国によっては ”ピリオド” や ”スペース”で区切られていることがあります。 価格表示については、小数点の対応・非対応であったり、数字の区切りなどが国によって変化することを考慮してテストする必要があります。さらに、これらはシステムの制御や環境によっても変化するので、テスト対象毎にどのような振る舞いとなるのかを開発者やマネージャに確認するなど、テストする際は事前確認を怠らないように注意が必要です。 少し実践 ではAGESTのホームページを使用して簡単なテストを行いたいと思います。ここでは、英語のTop Pageを使用して、ヘッダーの各リンクからの遷移を中心にテストします。確認する観点は以下の4つで実行したいと思います。 英語の該当ページに遷移すること 特定の位置が指定されている場合は指定の位置に遷移すること 日本語で表示されている箇所がないこと レイアウトなどの表示が崩れていないこと それでは始めます。 Top Pageにあるヘッダーの確認箇所は下図の赤枠で囲った部分となります。 確認するアイテムは以下の4つです。 　・AGESTのロゴ 　・Japanese 　・DIGITAL HEARTS HOLDINGS 　・Inquires では、それぞれクリックしていきます。 【AGESTのロゴをクリック】※ ” https://agest.co.jp/en/ ”に遷移 【Japaneseをクリック】※ ” https://agest.co.jp/ ”に遷移 【DIGITAL HEARTS HOLDINGSをクリック】※ ” https://www.digitalhearts-hd.com/ir/ ”に遷移 【Inquiresをクリック】※ ” https://agest.co.jp/en/inquiry/ ”に遷移 それぞれ確認したところ、” Japanese ”と” DIGITAL HEARTS HOLDINGS ”は日本語のページ、他は英語のページに遷移しておりました。まず” Japanese ”については日本語ページに切り替えるメニューなので、日本語表示となるのが正しい挙動となります。次に” DIGITAL HEARTS HOLDINGS ”については、外部サイトへのリンクとなるので遷移先のデフォルト言語で表示されるのが正しい仕様となります。たとえば” AGESTのロゴ ”や” Inquires ”など本来は英語表示のページに遷移するはずのリンクで、日本語表示のページに遷移してしまう場合は今回の観点では不具合となります。今回はそのような事はありませんでした。 まとめ いかがでしたでしょうか？　こちらで挙げたポイントが全てではなく、システムによっても気を付けないといけないポイントは当然変わるかと思いますので、臨機応変に対応していきたいですね。一番は国や地域に寄り添って考えていくことが大事ではないかなと思います。 The post 多言語対応したWebサイトをテストする時に気をつけたい５つのポイント first appeared on Sqripts .

はじめに 近年、AgileやScrumの普及に伴って、振る舞い駆動開発（Behavior Driven Development、以下BDD）や受け入れテスト駆動開発（Acceptance test–driven development、以下ATDD）にも注目が集まってきました。 そこで本連載では、BDDやATDDとは何か、どのように活用すれば良いのか考えていきたいと思います。 本連載の構成は以下の通りです。 本連載のメインであるBDDやATDDは、テスト駆動開発（Test-driven development、以下TDD）から派生した考えです。つまり「TDDとは何か」という理解がないとBDDやATDDを理解することが難しくなります。そこで今回は、TDDとは何か、TDDの目的は何かについて改めて考えてみましょう。 本連載を読み始める前に確認してほしいこと 対象読者について 本連載では、以下のような読者を対象として考えています。 ・TDDのやり方を知っている、もしくはTDDを実践している ・BDDという単語は聞いたことある ・BDDのやり方は知らない 本記事でTDDのやり方については語りません 本記事では、具体的なTDDのやり方については割愛します。 理由としては、既に素晴らしい教材がネット上にあるからです。特に、 TDD Bootcamp 2020 Onlineの和田卓人さんによる基調講演（動画） は是非ご覧ください。文字上でTDDを語るよりも多くの有益な考え方が示されています。 本記事では、TDDのやり方を知っている前提で、なぜTDDを行なうべきか、何を目的としているのかについて話します。 TDDはテスト手法ではなく開発手法である 「TDDとは開発手法もしくは設計手法の1つである」という理解が必要です。特に、TDDという名前から「テスト手法の1つである」という勘違いが非常に多いです。 TDDとは、「テストの方法」ではなく、あくまでも 「手段としてテスト（テストコード）を用いた開発方法」 です。 TDDは以下の3つを満たしながら作成していきます。 ・Red…設計の指針や直近のゴールを明確にする（そのためにテストコードを記述する） ・Green…ゴールを達成する（つまりテストコードがPassする）コードを愚直に実装する ・Refactor…ゴールを達成させたまま（つまりテストコードがPassしたまま）、実装したコードを改善していく ゴールを示す具体的な手段としてテストコードを用います。 BDDを考案したDan Northも自身の記事「 We need to talk about testing （邦訳： テストについて話し合わなくてはならない） 」の中で、以下のように述べています。 TDD、BDD、ATDD、および関連するメソッドは、その名前が示すように、テストに取って代わるものではありません。これらは主に設計および開発手法です。 （中略） プログラマーは自分が単体テストを書いていると思っています。そうではありません。彼らは、設計の指針となる簡単な具体例をテストコード形式で書いているに過ぎません。 TDDを行う主目的は素早くフィードバックを得るためである。 TDDとは、「手段としてテストを用いる開発手法」という説明をしました。 それでは、なぜTDDを行うのでしょうか？ TDDを行う主目的は、「素早くフィードバックを得ること」です。 開発をして、顧客からフィードバックをもらうには、通常1週間以上、長いと半年以上かかります。これは、リリースサイクルや顧客との関係性によって期間が変わります。この状態だと、フィードバックを貰った時に、開発が終わってからかなりの時間が経っているため、そもそもどのように開発したのか思い出したりするところから始めることになります。（以降の画像および説明は「 私が経験したソフトウェアテストの変遷(JaSST’18 Tokyo招待講演) 」を参考に作成） それでは、顧客からのフィードバックが来るまで待ち続ける必要があるのでしょうか？そうではなく、もっとフィードバックを短くする方法があります。 例えば、「受け入れテスト」などと名付けて、リリース前の評価環境で実際にテストしてフィードバックをするかもしれません。 これならば、顧客に提供するよりは短い期間でフィードバックを行うことができます。しかし、まだまだフィードバックまでの期間が長くなります。 そこで、システムテスト、統合テスト、単体テストなど様々な手段によって、もっと短いフィードバックを検討することができます。 ここまで書いた「単体テスト」「統合テスト」「システムテスト」「受け入れテスト」は、品質保証手段として行われるテストです。（[注釈]JSTQBシラバスのテストレベルの記載を参考に単語を選定しました。実際の現場では、「APIテスト」「UIテスト」など、違う単語を用いているかもしれません） 一方、品質保証を目的としないで作成するテストとして、開発者自身が作成するxUnitテストがあります。 テストを作る目的は違いますが、フィードバックまでの長さという軸で見ると、xUnitテストは他のテストよりも短いことが分かります。 それでは、xUnitテストの実施が一番短いフィードバックなのでしょうか？いえ、さらにフィードバックを短くすることができます。 実装とUnitテストの作成の順番を逆にすれば良いのです。 これがテストファーストな開発です。この考え方を用いているのがTDDです。 TDDは、上に書いたテストファーストな開発の考え方に加えて、「失敗するUnitテストを1つ作成したら、そのテストがPassするように実装を行う」「テスト実行を終えたら、次のUnitテストの作成を行う前に、リファクタリングによるコードおよび設計の改善を行う」という考え方も必要となります。 TDDもテストファースト開発の1つとして考えると、TDDを行う主目的は「素早くフィードバックを得ること」と考えて良いでしょう。 つまり、如何に素早いフィードバックを得て開発に活かすのかという、開発手法および設計手法としてTDDがあると考えることができます。 TDDによってどの程度素早くフィードバックを得ているのかについては、 TDD Bootcamp 2020 Onlineの和田卓人さんによる基調講演（動画） をご覧ください。 また同様の主張については、やっとむ/安井 力(やすい つとむ)さん作の記事「 テスト駆動開発（TDD）への招待 」もご覧ください。 回帰テストへの流用という副次的な効果 TDDを行う主目的は「素早くフィードバックを得ること」ですが、実際にTDDを行なって得られる副次的な効果として、回帰テストへの流用があります。 TDDで作成したテストは自動化されているため、そのまま回帰テストの材料として利用することができます。 つまり、別機能を開発する際のデグレードの防止に役立つのです。しかし、これはあくまでも副次的な効果です。TDDの主目的ではありません。 品質保証の考え方を注入する ここまでで、TDDを行う主目的は「素早くフィードバックを得ることである」という説明をしました。それに加えて、品質保証を入れることも目的の1つとして、TDDに取り組むことはできないのでしょうか？私は可能だと思っています。 その具体的なやり方については、秋山 浩一さん作の記事「 Fizz Buzz問題とTDDとテストと 」をご覧ください。 次回予告 今回はTDDとは何か、TDDの目的とは何かについて話しました。 次回は、BDDがどのような考えで誕生したかについて話します。 The post TDDとBDD/ATDD(1)　TDDはテスト手法ではない first appeared on Sqripts .

こんにちは、バックエンドエンジニアのまるです。 この記事では、Elasticsearchの検索において、matchとmatch_phraseの違いについて解説します。 Elasticsearchとは Elasticsearchは、オープンソースの分散型検索エンジンです。大量のデータを高速かつ効率的に検索、分析するために利用されます。テキストデータ、数値、地理情報、日付など、あらゆる種類のデータを扱える汎用的な検索エンジンです。 本記事では日本語の全文検索に絞った解説をします。 matchとmatch_phrase Elasticsearchの検索には、matchとmatch_phraseという2つのクエリがあります。どちらも「フィールド内に指定された単語が含まれること」を条件としたクエリですが、以下のような違いがあります。 matchクエリは、指定した単語がフィールド内のどこにあっても検索することができます。検索ワードは形態素解析され、デフォルトでは単語のOR検索となります。 match_phraseクエリは、指定した単語がフィールド内で 連続して 出現している場合にのみ、検索することができます。matchと同じように検索ワードは形態素解析されますが、単語が連続している必要があります。 説明だけでは理解しづらいと思うので、サンプルデータを使った例を見てみましょう。 matchクエリ 初めに、日本語の全文検索をしたいので、kuromojiでindexを登録します。 PUT test_index { "mappings": { "properties": { "title": { "type": "text", "analyzer": "kuromoji" } } } } サンプルデータとして以下の3つの例文を登録します。 POST /test_index/_bulk { "index": {}} { "title": "ログイン機能のテスト仕様書" } { "index": {}} { "title": "探索的テストの仕様書" } { "index": {}} { "title": "書を捨てよ町へ出よう" } 登録が終わったら、さっそく「テスト仕様書」というワードでmatch検索してみましょう。 GET /test_index/_search { "query": { "match": { "title": "テスト仕様書" } } } Responseは以下のようになります。 （Responseは見やすいように一部省略、整形しています。以降同様） "hits": [ { "title": "ログイン機能のテスト仕様書" }, { "title": "探索的テストの仕様書" }, { "title": "書を捨てよ町へ出よう" } ] 3つ全てヒットしました。上2つはともかく、「書を捨てよ町へ出よう」という文がヒットするのはおかしいように感じられます。これは、検索ワードが形態素解析されてトークンという単位に分割され、トークンのOR検索として処理されているためです。 検索ワードがどのように分割されているのかは_analyzeで見ることができます。 GET /test_index/_analyze { "field": "title", "text": "テスト仕様書" } { "tokens": [ { "token": "テスト", }, { "token": "仕様", }, { "token": "書", } ] } 「テスト仕様書」というワードは、「テスト」と「仕様」と「書」に分割されて検索に使われます。デフォルトではトークンのOR検索となるため、「書」を含む「書を捨てよ町へ出よう」がヒットした、ということです。 分割された単語すべてが含まれてほしい場合は、operatorオプションにANDを指定すればよいです。 GET /test_index/_search { "query": { "match": { "title": { "query": "テスト仕様書", "operator": "AND" } } } } "hits": [ { "title": "ログイン機能のテスト仕様書" }, { "title": "探索的テストの仕様書" } ] 「テスト」「仕様」「書」が全て含まれる文だけがヒットしました。 match_phraseクエリ match_phraseは、指定した単語がフィールド内で連続して出現している場合のみヒットします。 同じサンプルデータを使ってmatch_phrase検索してみましょう。 GET /test_index/_search { "query": { "match_phrase": { "title": "テスト仕様書" } } } "hits": [ { "title": "ログイン機能のテスト仕様書" } ] 「ログイン機能のテスト仕様書」という文だけがヒットしました。これは、match_phraseの場合「テスト」「仕様」「書」が この順序で連続して 出現する文のみがヒットするためです。従って完全一致検索のように使うことができます。 完全一致検索では厳しすぎるのでもう少し柔軟な検索をしたいという場合には、slopというオプションを使うとよいです。slopオプションには「各単語の間にいくつの余計な単語を含んでよいか」を指定することができます。 GET /test_index/_search { "query": { "match_phrase": { "title": { "query": "テスト仕様書", "slop": 1 } } } } "hits": [ { "title": "ログイン機能のテスト仕様書" }, { "title": "探索的テストの仕様書" } ] 「テスト」と「仕様」の間に1つ余計な単語が含まれていてもヒットすることが確認できます。 終わりに この記事ではElasticsearchのmatchとmatch_phraseの違いについて解説しました。Elasticsearchは非常に汎用的な検索エンジンですので、他のクエリと組み合わせてもっと詳細で柔軟な検索を実現することもできます。 この記事がみなさんのお役に立てば幸いです。 The post Elasticsearchで押さえるべき！matchとmatch_phraseの違いを徹底解説 first appeared on Sqripts .

こんにちは。まーくー＆くまねこです。 懲りずにまた二人で出てきました！ 今回はソフトウェアテストの学び直しとして、まーくーがアジャイルソフトウェア開発技術者検定試験を受けてきました！まーくーがやった学習内容の紹介や感じたことを会話形式でお話させて頂ければと思います。 最後まで楽しんで読んで頂ければ幸いです！ 自己紹介 まーくー QA業界経験2x年のベテラン（おじさん）エンジニア。 前回のブログ（ ゆるっと♪ファームウェアテストよもやま話 ）でJSTQB ALTM試験を受けると匂わせましたが、もう少し準備期間が必要そうです くまねこ QA業界経験1x年のエンジニア。 フェンスに腰掛けJSTQBの学習をしていたところ、またもまーくーさんに呼び出される(笑) イラストby くまねこ それでは、二人のやりとりをお楽しみください。 まーくー学び直しを決意する！ まーくー ：くまねこさんさぁ、アジャイル開発ってちゃんと理解している？ くまねこ ：どうしたんですか？唐突に・・・ まーくー ：いやね。テスト業界に入って20年以上経つけど本格的なアジャイル開発プロジェクトって、まだがっつり参画した経験が無いんだよね。。。 くまねこ ：まぁ、前回話していたファームウェアテストの現場は基本ウォーターフォール型開発でしたからね。 まーくー ：そうなんだよね。アジャイルライクなプロジェクトには少し関わったことはあるし、書籍「 アジャイルサムライ 」とかは読んだことはあるけど、実際「アジャイル開発」をちゃんと理解しているかって不安なのよ・・・ くまねこ ：渡る世間はアジャイルばかり？増えてますもんね。 まーくー ：JSTQBのFL Extensionとしてアジャイルテスト担当者というのがあるけど、日本ではまだテストが実施されてないからなぁ。。。 くまねこ ：海外で受験するとか(笑)あっ、まーくーさん。アジャイルソフトウェア開発技術者検定試験というのがありますよ！ まーくー ：なんですと！じゃ、学び直しも兼ねてアジャイルソフトウェア開発技術者検定試験受けるぞ！！！ くまねこ ：えー！急展開(笑) アジャイルソフトウェア開発技術者検定試験とは？ まーくー ：ところで・・・ちと聞きづらいんだけど、アジャイルソフトウェア開発技術者検定試験てなに？ くまねこ ：全然知らないんですか？？？アジャイルソフトウェア開発技術者検定試験コンソーシアムさんが運営している、アジャイル開発のスキルを客観的な尺度で分析・判定する試験のことですよ！（くまねこ調べ） アジャイルソフトウエア開発技術者検定試験 アジャイル開発のスキルを客観的な尺度で分析・判定するのが、アジャイルソフトウエア開発技術者検定試験です。 試験システムとして、CBT(Computer Based Testing)を採用しています。いつでも、どこでも受験することができます。4肢択一スタイルの問題、平均で70%の正解率を得られるよう、難易度を調整しています。 合格基準は80％以上の正解率です。 ※ アジャイルソフトウェア開発技術者検定試験のご案内「アジャイル検定とは」 より 受験料 10,000円(税別) 受験料には受験受付、試験の実施、合格者への証明書等、一切が含まれています。 ※アジャイルソフトウェア開発技術者検定試験のご案内「受験するには」 ]より まーくー ：おぉ、Lv1の認定内容として「アジャイル開発に参加するのに必須となる知識が出題されます。（中略）すべてのアジャイル開発に必要なスキルが認定されます。」って書いてある。まさに自分のアジャイル開発に対する知識レベルを確認するのにちょうど良い感じだね！まさにうってつけ♪ 学習方法のイメージを立ててみた まーくー ：でも、せっかくだから合格したいよねー。合格した人はどんな学習方法だったのだろうか？Webで調べてみよう！ くまねこ ：情報提供している人で5時間程度の学習時間で合格している人もいるみたいですよ！！！ まーくー ：なにぃぃぃ！あら？でもその人はかなりのアジャイル経験者みたいだね。びっくりしたぁ。私のアジャイル開発経験はちょびっと齧った程度なので アジャイル検定公式テキスト （以下テキスト）中心の学習をしっかりやらなくては！そして知識に厚みを持たせるため「アジャイルサムライ」を読み直す！ くまねこ ：気合入ってますね！（学習方法のイメージという割には気合に偏ってる気が・・・） まーくー ：テキストは120ページほどだし、文章も読みやすそうだから繰り返し読むことができそうだよ。 くまねこ ：じゃ、さっさと気合で試験申し込んじゃいましょう！ まーくー ：えぇぇ！（展開が早い・・・）まだ学習始めてないし・・・ くまねこ ：この日が良いんじゃないですか？ まーくー ：（他人事だと思って・・・ええぃ、背水の陣じゃ！）その日（10日後）のテスト申し込んだよ！最寄り駅の隣の駅前がちょうど空いてたし。 くまねこ ：もうやるしかないですねー！(￣ー￣)ﾆﾔﾘ 申込みの詳しいやり方、CBTの様子などは、下記記事をご参照下さい♪ アジャイルソフトウェア開発技術者検定Lv1 受験レポート アジャイル検定公式テキストを読んで 数日後・・・ くまねこ ：まーくーさんアジャイル検定の学習は進んでいますか？ まーくー ：ぼちぼちでんなー（笑） くまねこ ：（なぜエセ関西人？） まーくー ：予定通りテキストを1回読み終えたよ！このテキストって、下記の構成で簡潔に且つアジャイル開発の基礎知識が学習できるんだ。演習問題もついてるし♪問題は基本的な内容なんだけど、しっかりテキストに書いてあること理解してないと間違えてしまう問題もあったり、学んだ内容のチェックにはちょうど良い感じなんだ！ アジャイル検定公式テキスト目次（抜粋） 第1章　アジャイル開発の概要 第2章　アジャイル開発に対する基礎知識 　　 　理解度確認！ 演習問題 第3章　アジャイル開発におけるプロジェクト管理 　　 　理解度確認！ 演習問題 第4章　開発チームの運営 　　 　理解度確認！ 演習問題 第5章　アジャイル開発の各種手法 　　 　理解度確認！ 演習問題 （ 書籍の詳細　アジャイル検定公式テキスト より） くまねこ ：それは良かったですね！ まーくー ：うーむ・・・ くまねこ ：どうしたんですか？ まーくー ：でもテキストを読むと・・・アジャイル開発に携われるエンジニアってかなり開発者よりじゃなきゃダメなんじゃないか？って印象を受けたんだよね。特に多能工のところなんてコーディング出来ない私にはちと「ハードル高っ！」って感じたのよね。。。 多能工 「アジャイル開発は、設計、実装、テストを同時に行うと説明しました。アジャイル開発を行う開発者には、これらを全てできるスキルが必要です。」 ※アジャイル検定公式テキストP8より くまねこ ：僕もアジャイル開発では開発者とかテスターとか分かれてないって聞いたことあります。あっ、でもJSTQBに「アジャイルテスト担当者」ってシラバスあるくらいだから、テスターの知見を活かせるところも多々あるんじゃないですかね？ まーくー ：そっか、JSTQBの「アジャイルテスト担当者」のシラバスも読んでみれば、テスターのアジャイル開発への関わり方が分かるかもしれないな！そして自信を失わなくても済むかもね(笑)よしっ！アジャイルサムライは今回はスキップして、JSTQBの「アジャイルテスト担当者」のシラバスを読んでみよう！ 「テスト技術者資格制度 Foundation Level Extensionシラバスアジャイルテスト担当者」を読んで 試験前日・・・ くまねこ ：まーくーさん、また会いましたね。どうですか調子は？ まーくー ：さっとだけど、 テスト技術者資格制度 Foundation Level Extensionシラバスアジャイルテスト担当者 Version 2014.J02 ）（以下JSTQBシラバス）読んだよー。 テスト技術者資格制度 Foundation Level Extensionシラバス アジャイルテスト担当者 目次（抜粋） 0. 本シラバスの紹介 0.1 本書の目的 0.2 概要 0.3 試験のための学習の目的 1 .アジャイルソフトウェア開発 1.1 アジャイルソフトウェア開発の基本 1.2 アジャイルアプローチの特徴 2.アジャイルテストの基本的な原則、プラクティスおよびプロセス 2.1 テストにおける従来型アプローチとアジャイルアプローチの違い 2.2 アジャイルプロジェクトでのテストステータス 2.3 アジャイルチームにおけるテスト担当者の役割とスキル 3.アジャイルテストの方法、技法、およびツール 3.1 アジャイルテストの方法 3.2 品質リスクの評価とテスト工数の見積り 3.3 アジャイルプロジェクトの技法 3.4 アジャイルプロジェクトにおけるツール くまねこ ：じゃ、随分理解が深まったんじゃないですか？ まーくー ：うーん。おじさんの頭脳だと、テキストとJSTQBシラバスを絡めて理解を深めるにはもっと読み込まないとこまないとダメっぽい(笑) くまねこ ：どういうことですか？ まーくー ：考えてみれば当然のことなんだけど、JSTQBシラバスの方はアジャイル開発の概要とともにテスト担当者に必要なことを書いているんだ。でもテキストの方は開発者目線（開発担当者、テスト担当者を分けずに）で書かれている。アジャイル開発の概要や、プロジェクト管理方法、XPやテスト駆動開発などアジャイル開発の進め方なんてところはテキストと共通なんだけど、違う目線の文章を読んだことで逆に混乱したというか・・・ くまねこ ：えー！！！ まーくー ：読み込みが浅いせいなのか、目線の違いを整理しきれなかった。例えばJSTQBシラバスにある「チーム全体アプローチ」と同じ意味を持つ言葉をテキストで探しちゃったりして、結局見つけられなかったりとか・・・テキストの第3章なんかで言及しているのかな？って気はしたんだけど。。。 くまねこ ：完全に混乱しちゃってますね。。。試験は明日ですよね？どうするんですか？？？ まーくー ：「アジャイルソフトウェア開発技術者検定試験」なんだから、もう一回基本に戻ってテキストを復習しようと思ってる 試験が終わって・・・ くまねこ ：まーくーさん、試験はどうでしたか？ まーくー ：前日の夜はポイントだと思うところに貼った付箋箇所を中心に再度テキストを読み直して、当日朝も喫茶店で付箋箇所の復習をして臨んだよ。 くまねこ ：試験問題自体はどんな感じだったんですか？ まーくー ：CBTで試験問題を持ち帰れないから説明は難しいけど、問題のレベルとしてはテキストと変わらない感じで、しっかりとテキストを読み込めば、比較的答えを導き出すのは難しくなかったかも・・・ くまねこ ：かも？？？ まーくー ：やっぱり、学習方法で迷子になったりしたから十分な理解が進んでなかったみたい。4択問題で2択までには絞れるのだけど、決め切れない問題が多々あったよ。試験時間60分で60問と時間が限られているので、自信の無いところはマークを付けておいて、とりあえず最後まで問題を回答して残り時間30分。1/3くらいが悩んだ問題（多すぎ？）だったから、それを回答して残り10分。最後の最後の見直しでギリギリ1分前に回答完了って感じだった・・・ くまねこ ：試験の結果ってすぐ出るんですよね？どうだったんですか？？？（興味本位ニャニャ） まーくー ：あんまり言いたくないけど・・・ギリギリで合格！試験終了後のアンケート答えると、その次の画面で結果が表示されるから、ドキドキしたよ！ くまねこ ：不合格だったらこのブログ書けなかったですしね(笑) まーくー ：（うっ、図星 ）こんにゃろ！ ※氏名とプロメトリックID、点数を加工してます。点数は恥ずかしくて出せませんでした 受験を振り返って くまねこ ：いやはや、急な展開でしたが、受かっちゃうなんてさすがです！今回、試験を受けてみていかがでしたか？ まーくー ：そうだね、期間が短かったからこそ、自分なりには集中して学習できたかな（迷子にもなったけど）。ギリギリだったけど最低限の成果を上げられてホッとしたよ。さらに理解を深めるには、テキストの読み込みがもっと必要だと感じている。設問の中で正解はわかるけど、理解が浅いと間違えている箇所を判別するのが難しいって印象だった。 それに「アジャイルソフトウェア 開発技術者 検定」っていうぐらいだから、開発者の視点に絞って学習した方が試験的には近道だったかもしれない。テストの視点は、応用編かなぁ…実際の現場ではテスターがいることもあるみたいだけど、アジャイル開発では原則として役割がテスターのみって人はいないとされているしね… 今後の業務の中で、今回学習したことを取り入れて、テスト以外の領域にも目を向けて動いていけたらなって思ってるよ！（目指せ多能工？） 今の気分は「まだまだ知識が足りないなら、本屋に出て参考書を買えばいい！誰も「どうして？」なんて聞かないから♪Come on 」って感じかな？ くまねこ ：Yeeeeeeeeeeaaaaaaaaaah!  \ / おわりに まーくー ：いやー、結構勢いで受験を決めて動き出したけど、今回の「アジャイル検定公式テキスト」はアジャイルの原則を理解するのに良い教材だと思う（公式だしね！）。それに自分のようなおじさんでも頑張れば新しい資格も取得できる！って分かったのは良かったかな？これをきっかけに多能工を目指して、プログラミングも学習してみようかな？って思ったり思わなかったり（笑） くまねこ ：まーくーさんがプログラム…！そしたら僕がテストしますね！ まーくー ：くまねこさんは愉快犯だからなぁ…突拍子もない観点でテストされそう（笑） 最後に妄想が膨らんでしまいましたが、ゆるっとまーくーの学び直しをご紹介させて頂きました。今回はここまでです！ くまねこ ：くまねこでございま～す。次回のまーくー＆くまねこは、 まーくー、JSTQB ALTM試験、いったいいつ受けるの？まだでしょ！（仮） くまねこ、探索的テストを探索する？（仮） の2本でーす。 二人 ：最後まで読んでいただき、ありがとうございました♪次回もまた見てねー ﾉｼ ﾉｼ The post ゆるっと♪学び直し！アジャイルソフトウェア開発技術者検定試験 first appeared on Sqripts .

前回は テスト自動化ツールの選定【前編】～ツールの比較表をどう活用するか | Sqripts にて、テスト自動化ツールを選ぶ際のツール比較表の活用方法について説明しました。 ​ 今回はテスト自動化ツールの中でも、とくにAI自動テストツールを選ぶ際のポイントについて考えてみたいと思います。 ​ 注意点として、本記事中では特定のツールをお勧めしたり、Yes/Noで答えていけば最適なツールが判別できるフローチャートを提示したり、といったことは行いません。ツール選定には、開発しているソフトウェアやサービス、開発スタイル、メンバーのスキル、会社のルールなどさまざまな条件が関係するためです。 ​ 誰にでもあてはまる「ツール選びの正解」は存在しませんが、本記事ではツールを選択する際のポイント・考え方を提示して、皆さんがなるべく後悔のないツール選定をするお手伝いができればと思います。 ​ なお、本記事中の「テスト自動化」は前編と同様、E2Eテストなどテスト対象のUI、とくに画面を操作して行うようなテストのことをターゲットとします。 AI自動テストツールとは 最初に確認の意味もこめて、AI自動テストツールについて簡単に説明します。 ​ まず、”AI自動テストツール”というと、 AIを自動でテストするツール AIで自動テストをするツール の2通りが考えられます。 ​ 厳密な定義はありませんが、本記事の執筆時点では一般的に後者の”AIで自動テストをするツール”、つまりAIの力を借りてテストの自動化や自動実行をするツールのことを指して”AI自動テストツール”と呼びます。 ​ テストの自動化や自動実行においてAIを使うことができる場面は複数ありますが、現在の主流はテスト実行やテスト自動修復にAIを用いているものがほとんどです。テスト自動化における問題として「作成した自動テストが動かなくなる、メンテナンスが大変」などが挙げられますが、AIによるテスト自動修復機能があることによってメンテナンスの手間を減らすことができます。その結果、自動テストの運用を継続しやすい、というメリットがAI自動テストツールにはあります。 ​ 現在日本語で利用できる主なAI自動テストツールには以下があります。 mabl Autify MagicPod 他にもUIが英語のものも多数ありますし、20年以上の歴史を持つ自動化ツールにここ数年でAIが搭載されたりと、昨今のAIの盛り上がりと相まってさまざまな選択肢がある状態です。ツールを選ぶ側にとってはありがたい反面、テスト自動化にこれから取り組もうという組織においては逆にどれを選んだらよいかわからず、手が止まってしまう原因にもなっています。 何を基準に選ぶか AI自動テストツールを選ぶにあたっては、何を基準にしたらよいのでしょうか。 考慮すべきポイントはたくさんあり、本記事中でもすべては網羅しきれませんが、大きく分けて以下の2つ 機能面：ツール自体の持つ機能や特性 サポート・環境面：ツール会社のサポートや開発・コミュニティの活発度合いなど について考える必要があります。 それぞれ、詳しくみていきましょう。 機能面 機能面について最初に考えるべきポイントは、「テスト対象の操作と、期待結果との突き合わせができるか」です。 システムテストの自動化ツールは「PCアプリケーション」「Webアプリケーション」「モバイルアプリケーション」のうち1つ以上に対応しています。テスト対象に対応しているアプリケーションを候補として選ぶのが最初のステップです。どの形式のアプリケーションに対応しているかは、公式サイトやパンフレットに必ず記載があるため、調べることは簡単です。 ​ PC、Web、モバイルアプリケーションのうち自分たちが操作したい対象に対応していることが確認できたら、次はテスト対象のバージョンやOS、フレームワークごとの対応状況を調べます。 とくに注意が必要なのは、 ブラウザの種類 Safari、IEなどのブラウザが操作できるか モバイルOS Android、iOSそれぞれ対応しているか モバイルアプリのフレームワーク Flutterなどのフレームワークに対応しているか です。意外と見落としがちな点なので、ツールの候補を絞る段階で確認をしましょう。 ​自動化したいテストケースのうち、これが出来なければ意味がないという重要なテストや、ハッピーパス等と呼ばれるもっとも基本的なテストをいくつかピックアップし、操作手順や結果確認の内容をテストツール会社に確認をしてもらうのもひとつの手です。万が一対応していない操作などがあっても、アップデートによる対応予定などがあれば教えてもらえる可能性もあります。 ​ 以上は選定にあたっての必須の事項、これが満たされていなければツールが使えない、という条件です。ツール選定にお困りの方でも、ここまではたどり着けた方が多いかもしれません。 ​ 問題はこの先です。必須事項を満たすツールに絞ってもまだいくつもの候補があり、明確な理由を持って選べない、選んだけれども後々使いこなせなかった、といった失敗が起こりがちです。 ​ こうした失敗を避けるためには、 自動化する段階にだけ目をむけるのではなく、自動テストを使う段階のことを考えましょう 、というのがこれまでツール選定でつまづいた・失敗した事例から私なりに出した結論です。 ​ よく「テスト自動化」や「システムテスト自動化」という言い方がされますが、実際には テストを自動化する 自動化したテストをメンテナンスしながら使い続ける の2つの段階があります。 ​ 自動テストツールを選択する際、「テストを自動化する」部分、つまりそのツールでテスト対象が動かせるかどうかや、「誰でも簡単に自動化できるか」などを基準に選ぶことが多いです。この点を考慮することはもちろん大切です。 しかし、実際にツールを使うにあたっては後者の「自動化したテストをメンテナンスしながら使い続ける」割合のほうが大きくなります。ここを考慮せずにツールを選ぶと、あとで失敗しやすくなってしまいます。 ​ 自分たちが自動化したテストをどのように使うのかを具体的にイメージし、それを自動化ツールが実現可能かどうかについても調べるようにしましょう。 ​ どのように使うのか、とは、たとえば以下の要素を含みます。 自動テストをいつ、どのように実行するのか 例）週次、日次など決まったタイミングで実行 例）CI/CDパイプラインに組み込み、pushをトリガーに実行 どんな環境で、どんな用途で実行するのか 例）本番環境で死活監視的に実行 例）ステージング環境で、リリース前のリグレッションテストを実行 実行結果を誰が・どのように見るのか 例）テストエンジニアがツールのダッシュボードで確認する 例）開発者がチャットツールへの通知で確認する 例）レポートをPDF出力したものをPdMが確認する 自動テストが失敗したとき、検知・分析・テストの修正はそれぞれ誰がどんな流れで行うのか 例）テストエンジニアが自動テストの失敗を検知し、原因を分析。テストの問題であればテスト自動化エンジニアに報告し、不具合の可能性が高ければ開発者に報告 例）開発者が自動テストの失敗を検知・分析し、必要があればテストの修正まで行う ​上記はあくまでも一例ですが、自組織でテスト自動化を行う際の「いつ、誰が、どう使うか」がイメージできたでしょうか？ここがハッキリしていない場合は、ツール選定の基準もあいまいになりがちです。 ツール選定の前に、まずは自分たちのやりたいことを明確にしましょう。 ​ 自動テストをCI/CDパイプラインに組み込むのであれば、既存のソースコード管理システムとの連携について調査が必要ですし、実行結果をテストエンジニアがツールのダッシュボードで見るのであれば、ダッシュボードの見やすさが検討ポイントになる。といったように、具体的な使い道を想定して、その実現可否をツール選定のポイントにするという順番で考えると、検討時の漏れを減らせます。 ​ 機能面のポイントについてまとめます。 まずはテスト対象に対して行いたい操作ができる、対応しているツールを絞り込む 個別の機能について考える際は、テストを自動化する段階だけでなく自動テストを使う場面を具体的にイメージし、必要な機能を考える サポート・環境面 前編 において、比較表に現れづらい選定ポイントの例として 使い勝手 サポートの質 開発・ユーザーコミュニティの活発さ ​を挙げました。 ​ このうち、使い勝手の面はトライアルを通じて必ず確認することになるため、選定の過程で漏れる可能性は低いでしょう。 そこで、ここでは考慮から漏れがちな残りの2つ、サポートの質や開発・ユーザーコミュニティの活発さなど、ツール外部の環境面について見ていきます。 ​ サポートの質は、AI自動テストツールに限らず、有償のツールを選定するうえでは大切なポイントです。 昨今ではツールを開発している各社にカスタマーサポートやカスタマーサクセス担当者がおり、手厚くフォローしてもらえるようになっています。 ​ サポートについては、とくに以下の点について確認しておくとよいでしょう。 日本語サポートの有無 問い合わせの方法 メール、ツール上でのチャット、専用のSlack、など 問い合わせへの返答時間 サイト上の「＊営業日以内」だけでなく、過去の実績値も オンボーディングの有無や時間、回数 ​ツールの導入をはじめて利用が軌道にのるまでは、ツールの効果的な使い方や既存のテストプロセスにどうツールを入れていくかなど、相談したい事項が多数発生します。 ここでサポートの協力を得てスムーズにテスト自動化を立ち上げられるかどうかも、その後の成否に関わってきます。 そのため、どのくらい手厚くサポートが受けられるのか、サポートとのやりとりはスムーズか、などは選定段階でよく見ておきましょう。 ​ そして、サポートの対応だけでなく、開発・ユーザーコミュニティの活発さも大事になってきます。 ​ 昨今はどの自動化ツールも、開発している各社が自分たちでユーザーコミュニティを運営もしくは積極的に関わるなどで、そのツールを使っている人・会社同士のコミュニケーションを活発に行うようはたらきかけています。 ​ ツールの操作方法を知るだけであれば、公式ドキュメントなどで十分です。しかし、実際にツールを導入・活用するには、操作方法を知っているだけではうまくいかないことも。 他社での活用事例や社内で普及・推進するための施策など、ユーザー同士で相互に情報交換を行うことができれば、テスト自動化の成功に近づきます。 ​ こうした取り組みの背景には、AI自動テストツールの多くが買い切りではなくサブスクリプション型の料金体系になっていることがあると考えています。つまり、ツールを開発している各社にとっては、自分たちのツールを導入した企業がずっと使い続けてくれることで自社の売上が増えていきます。そのため、なるべくユーザーに解約せず使い続けてもらうために、ユーザーがうまく活用できるための取り組みを手厚く行ってくれるのです。 ​ そこでユーザー側がツールを選ぶ際には、このコミュニティの活発さや開発の関わり度合いに関しても見ておくと役に立ちます。 ​ 具体的なポイントは以下です。 コミュニティの活発さ 参加人数（社数）、投稿の頻度、質問に対する回答がついているか 開発側の関与の度合い コミュニティ内でのQ&Aや、イベント開催などに積極的に関わっているか 雰囲気は合うか 自分たちも積極的に他ユーザーと関わっていこう、という気になるか ​サポート・環境面のポイントについてまとめます。 サポートのしやすさや返答のスピード感に加えて、とくにテスト自動化のスタート時に重要なオンボーディングの手厚さを確認する コミュニティにおけるユーザー間のやりとりも、ツールを活用するうえで必須の要素になっている。コミュニティの活発さや雰囲気を確認する​ ツール会社に対する見方を考え直す ここまで、機能面・サポートや環境面の2つの側面から、AI自動テストツールの選定ポイントを説明してきました。 ​ 機能面に関しては、ソフトウェア開発に関わる他のツールに通じるところが多かったのではないか、と思います。 一方で、サポートや環境面について意識していただきたい点があります。 ​ それは、 テスト自動化ツールを開発・販売している会社は、ただツールを売っている「ツールベンダー」ではない ということです。 ​ 前項で説明したように、AI自動テストツールはサブスクリプション型の契約が多く、ツールを使い続けてほしい、と考えています。 そのため、ツールを開発している会社は導入した企業に対してさまざまなフォローを行い、テスト自動化をビジネスの成功につなげてほしいと思っています。 ​ つまり、AI自動テストツールを開発している各社は顧客に対してツールを売っているのではなく、ツールを使って実現できる未来を一緒に目指すビジネスパートナーである、と捉えるべきです。AI自動テストツールを選ぶということは、ビジネスパートナーを選ぶことと同じです。 ​ 本記事のタイトルとは一見矛盾するように見えるかもしれませんが、AI自動テストツールを選ぶということは、テストを自動化して達成したい姿・目的があるはずです。達成に向けて「ツールを選ぶ」という視点とともに、ぜひ「パートナーを選ぶ」という視点でも考えてみてください。 まとめ ​本記事ではAI自動テストツールを選ぶ際のポイントについて、機能面とサポート・環境面の2側面から説明をしました。 ​ テスト自動化に限らず、ツールを選ぶ際は会社や開発チームの体制などさまざまな条件が複雑に関わってきます。そのため、読んでくださった方全員に共通するような「選び方」はなく、各々が考えなければなりません。 ​ しかし、本記事中でも触れた以下の点、 テストを自動化する段階だけでなく、自動テストをメンテンナンスしながら運用している状態を具体的にイメージすること ツールを開発・販売している会社をツールベンダーではなくビジネスパートナーとして捉え、テストが自動化できた先の理想像を目指す手伝いをしてもらうこと​ これらを要として、関連する詳細な条件について検討していただければ、適切なツールを選択できるでしょう。 付録：ツールを選ぶ際のその他の確認点 ​記事中で触れたポイント以外で見落としがちな点についてリスト化します。 ツール選定時の参考にしてください。​ 自社のルール・規約への適合 ツール、SaaS利用時のルールを満たすか アカウント管理ルール（LDAP連携必須、など）を満たすか 最新環境への対応 モバイルOSの新バージョンに対して、OSリリースからテスト実行可能になるまでの期間はどのくらいか 今後の機能拡充予定・製品ロードマップ ソフトウェア開発や品質・テストに対する考え方 ツールの稼働率 直近での障害や定期メンテナンス等の状況 テスト自動化ツールの選定【前編】～ツールの比較表をどう活用するか The post テスト自動化ツールの選定【後編】～AI自動テストツールを選ぶ時に気をつけるべきポイント first appeared on Sqripts .

こんにちは、エリアマネージメント部のりきおです。 本記事では、テスト業務において検出された不具合に対して、「不具合ランク」を用いた品質分析のアプローチ方法とその活用事例についてご紹介していきます。不具合の分析作業やリスクアセスメントなどのマネジメント業務の際に少しでもご参考になれば幸いです。 準備作業 致命度・再現度の定義 まずは不具合ランクを算出するための準備として、「 致命度 （＝不具合発生時のシステムやステークホルダに対する影響度合）」と「 再現度 （本記事ではユースケースとしての遭遇しやすさ）」の2軸を設定し、「Sランク」～「Dランク」をそれぞれ定義して振り分けることで、発生した不具合がどの位置づけにあるかを識別することができます。 ※今回は以下のように設定していますが、対象システムやプロジェクト規模等によってこれらの定義の基準や粒度感は異なります。 例えば、「特定の管理者アカウントが〇〇画面で✕✕操作をしたとき、アプリが落ちる」といった旨の不具合であれば、「特定の管理者アカウント（特定のユーザーかつ特定の機能）でアプリが落ちる（クラッシュ）」不具合となるため、致命度＝A・再現度＝B と判定することができます。 「優先度」との区別 インシデントレポート等で検出した不具合を報告する際の指標として「優先度」が挙げられることがあります。この優先度を「テスト項目での阻害影響（発生した不具合によってテストが実施できない影響度合い）」に設定し、致命度及び再現度と区別することによって、より明確な情報をステークホルダに提示することができます。 テストマネージャーや開発者はこれらを総合して判断して修正順位を割り当てることで、適切にテスト（リスク）をコントロールすることができる場合があります。 分析作業 致命度・再現度のランクの算出 続いて、上節で定義した致命度・再現度の各評点をもとに不具合ランクを算出します。以下の通り、Sランク～Dランクを評点 × ウェイトで振り分けて計算することで各ランクを量的に算出することができます。 ウェイト（重みづけ）について プロジェクトの方針やテスト対象によっては、致命度と再現度のウェイト（不具合としての重み）が異なる場合があります。例えば、「ある程度の検出数は許容するが致命度の高い不具合が発生することは問題」となるケースもありますし、反対に「内容に関わらずそもそも不具合が発生すること自体が問題」となるケースもあります。こうした基準の振り幅は、ウェイトで重み付けすることで対応することができます。 不具合ランクの算出 「致命度のランク * ウェイト (1.1)」＋「再現度のランク * ウェイト (0.9)」 で求めた値を振り分けることで総合的な不具合ランクを算出します。今回は以下のように各ランクの評点範囲を設定しました。 一覧化すると以下のようになります。 準備作業で例に挙げた 致命度：A（＝4.4点）・再現度：B（＝2.7点） の不具合であれば、不具合ランクは「A（＝7.1点）」という結果になります。 インシデントレポートでの運用 インシデントレポートといった不具合が一覧で記載されたドキュメントでも、不具合ランクを導入することができます。今回はスプレッドシートに「致命度」「再現度」「評点」「不具合ランク」の4列を導入して運用する例をご紹介します。 各不具合に対して、致命度・再現度をプルダウンリストから選択すると、評点・不具合が関数で自動出力される仕組みとなっています。 関数 参考までに評点・不具合ランク列の各関数をご紹介しておきます。 ・評点 =(IF(致命度のセル番号="S",5,IF(致命度のセル番号="A",4,IF(致命度のセル番号="B",3,IF(致命度のセル番号="C",2,IF(致命度のセル番号="D",1)))))*致命度のウェイトのセル番号)+(IF(再現度のセル番号="S",5,IF(再現度のセル番号="A",4,IF(再現度のセル番号="B",3,IF(再現度のセル番号="C",2,IF(再現度のセル番号="D",1)))))*再現度のウェイトのセル番号) ・不具合ランク =IF(評点結果のセル番号=0,"",IF(評点結果のセル番号>=9,"S",IF(AND(評点結果のセル番号>=7,評点結果のセル番号<9),"A",IF(AND(評点結果のセル番号>=5,評点結果のセル番号<7),"B",IF(AND(評点結果のセル番号>=3,評点結果のセル番号<5),"C",IF(評点結果のセル番号<3,"D")))))) 不具合ランクで品質を『見える化』する 上図のように集計した不具合をグラフ化することで、「 欠陥の偏在 」や各機能に対する影響度合いなどを『見える化（可視化）』して測定することができ、これらは不具合や品質を分析する際に有効な情報として提供できます。 欠陥の偏在とは？ リリース前のテストで見つかる欠陥や運用時の故障の大部分は、特定の少数モジュールに集中する。 テストの労力を集中させるために欠陥の偏在を予測し、テストや運用での実際の観察結果に基づいてリ スク分析を行う。 JSTQB Foundation Level シラバス – 1.3 テストの 7 原則 より 活用事例 アドホックテストでの活用事例 機能テストで検出された各不具合を分析し、その結果をもとにアドホックテストを行うプロジェクトがあったとします。各機能ごとの不具合数が上図の場合、純粋な検出数だけを考慮して分析すると 「機能A ＞ 機能B ＞ 機能C」 の優先度でアドホックテストを行う方針となりそうですね。 しかし、不具合ランクを導入し、かつ各機能ごとの不具合ランクが以下の状態だった場合はどうでしょう。 一概に 「機能A ＞ 機能B ＞ 機能C」 の優先度は割り付けられないのではないでしょうか。 このように、不具合ランクを定義して不具合を分析すると、これまで定義前では見えてこなかった品質を可視化することができる場合があります。 ※不具合ランクは絶対的な指標ではありません。運用する際は、プロジェクトや不具合といったあらゆる状況を加味したうえで、適切な用途を心掛けましょう。 おわりに 品質分析は、対象のプロジェクトや検出された不具合の状態に応じて様々なアプローチ方法があります。今回ご紹介した不具合ランクの定義を含め、各方法や状況を適切に判断・運用し、商品やサービスに対してよりよい品質の分析・向上・担保に努めていきましょう！ The post 不具合ランクを定義して品質を『見える化』する first appeared on Sqripts .

この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。 第4回目のテーマは、前回と同じく「従来型開発とアジャイル開発の違い」となり、前回とは異なる観点で比較を続けていきます。 この内容はUdemyで公開しているオンラインコース「 現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム 入門編 」の内容を元にしています。 見積もりと計画づくりの比較 見積もりと計画づくりを比較してみましょう。見積もりと計画づくりは、チーム運営でとても重要な要素だと思います。ただ、ここにも大きな違いがあるため、従来型のプロマネ経験者であれば、アジャイル開発のやりかたに少し困惑する部分があるかもしれません。 繰り返しになりますが、従来型は、作るものが決まっていて、計画を長く見通せるものが得意です。よって、リリースから逆算して計画を立てて行くのが基本になります。 やることが決まっているので、この方法が通用しますが、逆に言うと、プロジェクト初期にやることを洗い出せない場合は、うまくスケジュールを作れません。おそらく定番なのは、「経験上これぐらいかかる」とざっくり工数を見積もり、スケジュールを立てる方法でしょう。ただ、このやり方だと、早期に見積もりを正確にしなければ、やることが意外にも大きくなってしまった場合、大きなリスクになります。 アジャイル開発は、短いリリースを繰り返していきます。アジャイル開発は、小さな成果物をちょっとずつリリースしていくので、ゴールまで成果を積み上げていく形のスケジューリングになります。 短いリリースは、タイムボックスで管理を行います。タイムボックスとは、固定の時間、固定の人数という箱をイメージしてください。この箱の中にやること（ユーザーストーリー）を詰め込み、小さくリリースを繰り返していきます。何を入れるべきかを考えるために必要なのが優先順位です。 見積もりと計画づくりの比較図 プロジェクト期間の比較 プロジェクトの期間を比較します。アジャイル開発の場合は、プロジェクトじゃない場合もあるので、開発サイクルを比較します。 これまでになんども解説してきましたが、従来型は大きな開発を扱うのが得意なので、中長期的なプロジェクトが多くなります。従来型では、中途半端なプロダクトやシステムは顧客が望まないので、プロジェクトの中で完成を目指します。 アジャイル開発は、短くて1週間、長くて1ヶ月ぐらいの短期的な開発を繰り返していきます。小さく作って、大きく伸ばしていく方法です。この特性を生かした開発は、プロダクトを作りながら考え調整していくスタートアップでとても有効です。 品質の比較 品質について比較してみましょう。品質についても大きく考え方が変わってきます。 従来型の場合、テスト工程（フェーズ）が存在する場合が多いでしょう。つまり、それぞれの工程で品質を高める・維持するのも重要ですが、テスト工程の中で可能な限り品質を高めていきます。よって、テスト工程はとても重要です。 そして、基本的に、プロジェクトが終了するまでに品質を高めます。リリース後や納品後の品質向上は基本保証せず、別契約に移るケースが多いでしょう。 さて、ここまでに何度も出てきていますが、あらためて考えていただきたいことがあります。 ここで語られている品質とは何でしょうか？   従来型の場合、プロジェクトの内容や条件が契約で決まっているケースが多いので「契約通りのものが作られたか」が品質と言えます。 従来型では、作るものがだいたい決まっているので、ただしいプロセスで作れば、正しいものが出来上がるはず・・・という考え方が中心にあります。 この従来型の品質に対する考え方は、検証（Velificaiton)が中心になっていると言えます。あらかじめ作るものが決まっており、正解が存在するため、できあがった後に答え合わせできます。これがここでいう検証です。 アジャイル開発では小さな機能をどんどん開発し、リリースしていくので、小さい単位で品質を維持していきます。アジャイル開発では、リリースを繰り返すので、リリース後も品質を高められます。アジャイル開発では開発が続く限り、継続的にテストを行っていきます。 明確なテスト工程を定めると小さなウォーターフォールになるため、小さな機能をひとつひとつ作っていく形を取ります。手戻りを避けたいので、開発サイクルの後半にまとめてテスト工程を作るのを避けていこうとします。 アジャイル開発では、何が正解かわからないので、リリースごとに得られるフィードバックからヒントを学び、プロダクトをどんどん改善し、正解に近づけていこうとします。成果がでてやっと品質が高いと言えます。アジャイル開発における品質をまとめると、妥当性（Validation)が中心になっているのがわかります。 契約の比較 契約の比較をしてみましょう。 従来型の場合、やりたいことが決まっている顧客が、開発の専門組織に開発を発注するパターンが多いと思います。顧客は開発を発注し、開発側が受注する受発注の関係性になります。開発側の企業は成果物の納品まで契約に従って開発を進めます。 受発注型の契約は、納品時に「完成した」「してない」や「欲しい物じゃない」などでもめるケースが多いため、トラブルを防ぐための契約が重要です。よって、請負契約が中心です。 アジャイル開発を取り入れる企業をみると、自前で開発組織を持っているケースが多いので、社員の雇用契約以外の契約がない場合が多いです。自社で開発できるので特別な契約は必要なく、従業員が勤務時間に開発するだけです。 もし、自社の開発者が少ない場合は、外部に頼むケースもあるでしょう。しかし、何を作るかがはっきりしないアジャイル開発の場合は、完成の義務を追わない準委任契約が適しています。「ビジネスが必ず成功する機能を作ってください」と言われても約束できないので、完成の義務を負わない形にならざるをえません。 予算の比較 従来型の開発であれば、やることがすべて決まっている前提なので、プロジェクトを見積もるときに、かかる費用を綿密に計算できます。これらの費用をベースにして、年間計画を立てている企業も多いと思います。 アジャイル開発における予算管理は、よく質問される内容です。 基本的に予算の考え方は、従来型でもアジャイル開発でもかわりません。アジャイル型だと、アジャイルチームの人件費のみを定期的に計算する形が多いように思います。 アジャイル開発だと、プロダクトが続く限り開発が続くため、どこをひとくぎりとして予算を計算するか悩ましいところだと思います。たいていの企業は四半期、半期あたりで予算を立てるケースが多いように感じます。 ただ、このやりかただと、予算が固定されるので、変化に強いはずであるアジャイル開発でも柔軟な対応ができなくなってしまいます。 たとえば、プロダクトがヒットして急に人材を増やしたいときや、アクセスが集中したのでサーバを一気に増やしたい場合、予算が半年間固定されてしまうと柔軟に追加予算を使えません。対応策としては、予算を1年から3年先までの年間計画や人員計画に合わせてざっくり確保しておきます。また、予備的な追加予算も確保しておいて、緊急時に柔軟に追加投資してもいいでしょう。 様々な比較を終えて 前回と今回に分けて、従来型とアジャイル開発の様々な比較を行ってきました。こうやってひとつひとつ比べると、それぞれの違いがよく見えてきます。また、思った以上に違いが多いことにも気がつけるはずです。 そのとおり。従来型とアジャイル開発は、ほとんど違うと言ってもいいぐらい違いがあります。違いは優劣ではなく、それぞれに得意不得意があるだけでしかありません。 完璧なプロセスは存在しないため、それぞれの得意不得意を考慮してプロセスを選択していく必要があるのです。 第1回：アジャイル開発の過去、現在、未来を知ろう！ 第2回：声に出して読みたいアジャイルマニフェスト 第3回：第3回 従来型開発とアジャイル開発の違い　その１ The post 第4回 従来型開発とアジャイル開発の違い　その２ first appeared on Sqripts .

Seleniumとは Seleniumの特徴 SeleniumはWebブラウザの操作を自動化することができるフレームワークです。現時点のSeleniumのコンポーネントは、簡単にブラウザ操作をレコードして再生できる「Selenium IDE」、プログラミング言語を利用してより複雑な操作を実現できる「Selenium WebDriver」、Selenium WebDriverを複数のOSやブラウザで動かすことができる「Selenium Grid」があります。 オープンソース（Apache License Version 2.0） であるため無料で利用できます。多くの人に長い間利用されているフレームワークであるためWeb情報や書籍が豊富にあり、 公式のサポート も充実しています。利用時に直面する問題はすでに質問されていることが多く、また解決済みである場合がほとんどです。たとえ誰も見たことがない問題が発生したとしても、Webサイトで質問をすれば世界中の利用者から情報やサポートを得ることができます。 Seleniumが活用される場面 Webアプリケーションのテスト 主にWebアプリケーションのテストで利用されています。自動テストはテストの実装に時間がかかりますが、テスト実行時間が手動テストよりも短くなる場合が多くあります（※操作対象によっては自動テストでも速度が出ない場合もあります。）。そのため、何度も繰り返し実行するリグレッションテストや、データを変更して同じテストを何十パターンも実行するデータ駆動テストで活用されています。 Jenkins、Travis Cl、BambooなどのCIツールと組み合わせると、アプリがデプロイされたら自動的にテストを実行する、毎週木曜日の21時にテストを実行するなどの定期実行が可能です。また、テストの開始終了をメールやSlackなどのメッセージングアプリに通知させたり、 単体テストフレームワークの組み込みのレポート機能 を利用することでテスト結果の視認性を高めたりすることも可能です。様々なツールやフレームワークと組み合わせることで、頻繁かつ手軽にテストができ、結果をすぐに確認できる環境を構築することができます。 クローリング、Webスクレイピング Web上の情報を広く収集するクローリングや、Web上の特定の情報を収集するWebスクレイピングで利用されています。手動でデータを収集するよりもはるかに高速に実行できます。Webアプリケーションのテストで紹介したClツールなどと組み合わせることで、定期的に新しい情報を自動収集することができます。ブログへのアクセス数を毎日取得してレポートに出力、特定のワードでSNSサイトやWebブログを検索しヒット数の推移を記録、自社および競合他社の製品の口コミや価格変動などマーケティング情報を自動収集するといった利用方法があります。 RPA Webブラウザを使用するタスクの自動化でRPAツールとして使用することができます。日報の入力やメール送信の自動操作、業務で使用するWebアプリへの自動ログイン、業務データの自動作成など、業務効率化に利用されています。 Seleniumのコンポーネント Selenium IDE Webブラウザの操作を簡単にレコーディングして再生することができます。ブラウザの拡張機能であるため、自動テストの作成にプログラミング言語は必要なく、自動テストの入門としても適しています。 動作環境 操作対象のブラウザ ：Chrome、Firefox、Edge OS：上記ブラウザアプリが使用できるOS Selenium IDEは簡単に作成できますが、簡単なブラウザ操作しかできません。より複雑な操作を行いたい場合は以下のコンポーネントを利用します。 Selenium WebDriver Webブラウザを自動操作することができます。プログラミング言語でコードを書く必要があります。2018年から WebDriverはW3C（Web 標準の開発に取り組む国際コミュニティ）の推奨事項 になりました。主要なブラウザベンダーはWebDriverのサポートを行うため、安定した動作が期待できます。 動作環境 操作対象のブラウザ ：Chrome、Firefox、Edge、Safari、Opera、Internet Explorer OS ：Microsoft Windows、macOS、Linux 主要な プログラミング言語 ：C#、Ruby、Java、Python、JavaScript （上記5つはSeleniumプロジェクトでサポートされています。） その他プログラミング言語 ：Go、Haskell、Perl、PHP、R、Dart、Pharo Smalltalk （これらはSeleniumプロジェクトでサポートされていません。ライセンスも異なる場合があるため、利用する前に調査が必要です。） Selenium Grid 複数のOS、ブラウザでテストを並列実行することができます。WebDriverを利用して作成したテストスクリプトが必要です。 動作環境 Java 11 もしくはそれ以上がインストールされていること Selenium IDEの使い方 簡単に自動操作ができるSelenium IDEを紹介します。 環境構築 Chrome、Firefox、Edgeのいずれかのブラウザアプリを起動し、 こちらのリンク からSelenium IDEの拡張機能を追加します。 ※後述するSelenium WebDriverの説明でChromeを使用するため、できればChromeを利用することをお勧めします。 レコーディングする操作 テスト自動化の学習用の練習サイト にアクセス ブラウザ画面を最大表示にする 「ログイン」ボタンをクリック 「メールアドレス」をクリックして「ichiro@example.com」を入力 「パスワード」をクリックして「password」を入力 「ログイン」ボタンをクリック 「ログアウト」ボタンをクリック ブラウザを閉じる 操作のレコーディング ブラウザ右上にある拡張機能ボタンをクリックして「Selenium IDE」を起動します。 「Record a new test in a new project」を選択し、プロジェクト名を入力して「OK」ボタンをクリックします。 ベースURLに「https://hotel.testplanisphere.dev/ja/index.html」を入力して「START RECORDING」ボタンをクリックします。 手動で「レコーディングする操作」の操作を行います。 操作が終わったらSelenium IDEウィンドウの右上にある「Stop recording」ボタンをクリックします。 上記操作で作成したシナリオはこちらです。 レコードの再生 Selenium IDEウィンドウの上にある「Run current test」ボタンをクリックすると、自動でブラウザが立ち上がりレコードした操作が実行されます。操作が速すぎて見えない場合は、ストップウォッチアイコンの「Text execution speed」ボタンから実行速度を遅くすることができます。 Selenium IDEの制限 Selenium IDEが対応しているのは簡単な操作のみであり、画面スクロールなどレコードできない操作があります。また、操作対象はChrome、FireFox、Edgeのみです。Selenium IDEでレコードできない操作をしたい、別のブラウザを操作したい場合はSelenium WebDriverを利用する必要があります スクリプトのエクスポート Selenium IDEのレコードはいくつかの言語でエクスポートすることができます。 レコードタイトルを右クリックすると表示されるメニューから「Export」を選択します。 エクスポートする言語とテストフレームワークを選択します。次のSelenium WebDriverの使い方で使用するために「Python pytest」でダウンロードしています。下にあるチェックボックスはすべて空欄にしてください。 以下のpythonファイルがエクスポートされます # Generated by Selenium IDE import pytest import time import json from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.common.action_chains import ActionChains from selenium.webdriver.support import expected_conditions from selenium.webdriver.support.wait import WebDriverWait from selenium.webdriver.common.keys import Keys from selenium.webdriver.common.desired_capabilities import DesiredCapabilities class Test(): def setup_method(self, method): self.driver = webdriver.Chrome() self.vars = {} def teardown_method(self, method): self.driver.quit() def test_(self): self.driver.get("https://hotel.testplanisphere.dev/ja/index.html") self.driver.set_window_size(1874, 1096) self.driver.find_element(By.LINK_TEXT, "ログイン").click() self.driver.find_element(By.ID, "email").click() self.driver.find_element(By.ID, "email").send_keys("ichiro@example.com") self.driver.find_element(By.ID, "password").click() self.driver.find_element(By.ID, "password").send_keys("password") self.driver.find_element(By.ID, "login-button").click() self.driver.find_element(By.CSS_SELECTOR, ".btn-outline-success").click() self.driver.close() Selenium WebDriverの使い方 Python pytestでエクスポートしたSelenium IDE（Chromeを利用）のレコードを、Selenium WebDriverを利用してChromeで動かす方法を説明します。 環境構築 以下の説明ではWindowsPCを利用します。 Google Chromeブラウザを準備します。 こちらのページ からPythonをダウンロードしてインストールします。 ※pipを使用してモジュールをインストールするため、Python 3.4以降を使用してください。 自動操作に必要なPythonモジュールをインストールします。コマンドプロンプトを開いて以下のコマンドを入力します。 pip install pytest pip install selenium Chromeの「設定」＞「Chromeについて」からChromeのバージョンを確認します。 こちらのページ からGoogleChromeのWebDriverのダウンロードページに遷移し、前の手順で確認したChromeのバージョンに対応するWebDriverをダウンロードします。 ダウンロードしたドライバを解凍し、ドライバファイルとエクスポートしたスクリプトファイルを同じフォルダに入れます。 スクリプトの実行 コマンドプロンプトを開き、「cd」コマンドでスクリプトとドライバを入れたフォルダに移動します。 cd {フォルダのパス} 「pytest」のコマンドを入力してスクリプトを実行します。 pytest ブラウザが自動で立ち上がり操作が実行されます。 ※実行ログに以下のエラーが表示される場合がありますが、テストに問題はありません。 　エラーの詳細が気になる方は こちら を参照してください。 ERROR: Couldn't read tbsCertificate as SEQUENCE ERROR: Failed parsing Certificate まとめ SeleniumはWebブラウザの操作を自動化するためのフレームワークであり、主にWebアプリケーションのテストやWebスクレイピング、クローリングに活用されています。Seleniumには3つのコンポーネントがあります。 Selenium IDE: ブラウザの操作を簡単にレコーディングして再生することができるコンポーネントです。プログラミング言語は必要ありません。ただし、簡単な操作に限られます。 Selenium WebDriver: プログラミング言語でコードを書くことでWebブラウザを自動操作することができるコンポーネントです。主要なブラウザやプログラミング言語をサポートしており、Selenium IDEより複雑な操作が可能です。 Selenium Grid: WebDriverを使用したスクリプトを利用して、複数のOSやブラウザを操作するためのコンポーネントです。 ブラウザ操作を行う目的や操作の内容にあわせてコンポーネントを選択することが重要です。 The post WEBアプリケーションのテストができるSeleniumとは？ first appeared on Sqripts .

こんにちは。 エンジニアの nobushi です。 今回は Python のマイグレーションツール Alembic を実際に運用してみたいと思います。 以前の ブログ で Alembic を紹介しましたが実際にどう運用するかについてまでは触れませんでした。 今回は GCP の CloudRun を主体としたシステムでの運用方法について紹介したいと思います。 CloudRun CloudRun は GCP のサーバーレスなコンテナ実行環境で、とても簡単にコンテナを実行することができます。 ロードバランサも内蔵されていてリクエスト数に応じて自動的にスケーリングしてくれるため、 特に何もしなくても堅牢なコンテナアプリケーションを運用できます。 しかし、この CloudRun ですが何でもできるというわけではなく HTTP 、 gRPC 等のリクエストを契機としてその処理中のみ動作する、というのが基本になっています。 ここで問題になるのが Alembic のマイグレーションです。 Alembic のマイグレーションはコマンドで動作する仕様のためコマンドの実行が必要です。 HTTP リクエストを契機としてコマンドを実行するという手もありますがセキュリティホールになりかねません。 CloudRun のままではマイグレーションを実行するのは難しそうです。 ComputeEngine ComputeEngine はプレーンな仮想マシンです。 実行に際して特に制限等がない代わりにマシンスペック、スケーリングの管理等は全て自分で行う必要があります。 もちろんコマンドを実行することも問題なくできるので Alembic のマイグレーションも実行できます。 CloudRun がオールインワンで運用しやすいのに対して ComputeEngine は自由度が高い代わりに手間がかかる、 と言ったところでしょうか。 運用案 前述の通り ComputeEngine は自由度が高く任意のコマンドも実行できるので Alembic のマイグレーションを実行するのにも特に不都合はありません。 ただし管理の手間がかかりますので、できればサーバーレスである CloudRun を使用したいというケースも多いと思います。 そこで CloudRun を主体として運用しながら Alembic のマイグレーションには ComputeEngine を使う、という方法です。 CloudRun はコンテナの実行環境ですが ComputeEngine もコンテナをそのまま実行可能です。 そのため同じアプリケーションを動かすのは難しいことではありません。 イメージとしては以下の通りです。 A は運用時の構成で、 アプリケーションのコンテナを CloudRun で実行し CloudRun は Database に接続しています。 しかし、このままでは前述の通り Alembic のマイグレーションを実行することができません。 そこで、マイグレーションが必要な変更のデプロイ時に B の構成を一時的に立ち上げます。 B は A と同じコンテナを実行し、同じデータベースに接続します。 この B でマイグレーションを実行し、完了したら削除します。 Terraform Terraform の場合、前述の [A.通常の運用構成] と [B.マイグレーション時のみ構築] を別々の実行単位（ディレクトリ）で構築します。 以下はマイグレーション側のterraformの例です。 terraform { backend "local" {} } provider "google" { project = "<project-name>" region = "us-west1" zone = "us-west1-c" } variable "container_image" {} data "google_sql_database_instance" "db" { name = "db" } data "google_service_account" "app" { account_id = "app-sample" } module "app_container" { source = "terraform-google-modules/container-vm/google" version = ">= 3.1.0, < 3.2.0" container = { image = "${var.container_image}" command = ["sh"] args = ["-c", "alembic upgrade head"] env = [ { name = "DB_HOST" value = "${data.google_sql_database_instance.db.private_ip_address}" }, ] } } resource "google_compute_instance" "migration" { name = "migration" machine_type = "e2-micro" boot_disk { initialize_params { image = module.app_container.source_image } } network_interface { network = "default" access_config {} } metadata = { gce-container-declaration = "${module.app_container.metadata_value}" } service_account { email = data.google_service_account.app.email scopes = [ "<https://www.googleapis.com/auth/cloud-platform>", ] } } ポイントは以下の通りです。 terraform { backend "local" {} } マイグレーション実行後には破棄すれば良いのでバックエンドはローカルに設定しています。 data "google_sql_database_instance" "db" { name = "db" } data "google_service_account" "app" { account_id = "app-sample" } データベースインスタンスとアプリケーション用のサービスアカウントは [A.通常の運用構成] の側で管理されている前提です。 そのため、こちらではすでにあるインスタンスを参照することになるため data で記述します。 module "app_container" { source = "terraform-google-modules/container-vm/google" version = ">= 3.1.0, < 3.2.0" container = { image = "${var.container_image}" command = ["sh"] args = ["-c", "alembic upgrade head"] env = [ { name = "DB_HOST" value = "${data.google_sql_database_instance.db.private_ip_address}" }, ] } } コンテナは [A.通常の運用構成] と同じものを私用しますが起動コマンドが異なります。 [A.通常の運用構成] ではWebサーバーの立ち上げコマンドを指定しているはずですが、 こちらでは Alembic の実行コマンドを指定しています。 これによりこちらのサーバーではマイグレーションを行うだけでコンテナは終了します。 この .tf ファイルを実行者のPC等から実行し、 ログ等でマイグレーションの正常終了を確認したらこのコンテナ環境自体が不要なので破棄 ( destroy ) します。 所感 マイグレーションを実行する場合には CloudRun のように自由度が低い場合に困りますが コンテナが主体であれば一時的に別のコンポーネントで実行することは簡単なので そういうアプローチで良いと思います。 また、マイグレーションを行うだけであれば終わったら破棄する前提にできるので セキュリティについてはあまり考慮しなくても大丈夫、という点もポイントです。 The post PythonのRDBマイグレーションツール「Alembic」をGCPのCloudRun主体の構成で運用してみる first appeared on Sqripts .

本連載では、ブロックチェーンの基本的な仕組みを解説しながら、オンチェーンデータを分析するための基本的な手法について、全8回で紹介します。 第2回となる今回は、ブロックチェーン技術が最初に発明された暗号資産（仮想通貨）であるビットコインの仕組みについて、技術的な観点やその目的などを中心に解説します。 ビットコインのデータ構造 本連載の最終的なゴールは、オンチェーンデータと呼ばれるブロックチェーン上のパブリックデータを用いたデータ分析ができるようになることですので、ブロックチェーンのデータ構造の理解が重要となります。 もちろん、異なるブロックチェーンシステムでは、データ構造が異なる部分もあります。そのため、複数のブロックチェーンのデータ構造を比較することで、多くのブロックチェーンに共通するデータ構造と、特定のブロックチェーンに固有のデータ構造が理解できるようになります。 今回はビットコインのデータ構造について概観し、次回記事にてイーサリアムのデータ構造を見ていく予定です。両者を比較することでブロックチェーンのデータ構造についての理解が深まると思います。 実データを観察する まずは、具体的なビットコインブロックチェーンの実データを見てみましょう。 ビットコインは誰もが参加可能なP2P型のアプリケーションですので、OSSとして公開されているプログラムを用いて誰でも自分のノードを立ち上げて、ビットコインのネットワークから情報を取得することができます。 しかし、ビットコインのデータをデータベース化して利用しやすくしたオンラインサービスも数多く存在していますので、まずはそれらを使ってデータにアクセスしてみましょう。 Google BigQuery Google Cloudが提供するデータウェアハウスサービスとして広く使われているBigQueryでは、同じくGoogle Cloudが提供する一般公開データセット（※1）を用いて簡単にデータ分析を始められます。 この一般公開データセットには、医療や経済、科学などをはじめ、さまざまなジャンルのデータが含まれており、主要なブロックチェーンのオンチェーンデータも提供されています。 また、BigQueryは従量課金制のクラウドサービスですが、毎月の無料枠も設定されており、課金を有効にしなくても一般公開データセットを用いた分析を始められます。詳しくはGoogle Cloudの公式ページのドキュメントを参照してください。 Google CloudとBigQueryのセットアップをおこない、テーブルID: 「bigquery-public-data.crypto_bitcoin」を検索すると、図1に示すようなビットコインのオンチェーンデータを格納したテーブルを表示できます。テーブルには「blocks」と「transactions」があり、アイコンの異なる「inputs」「outputs」は、他のテーブルから計算されたビューと呼ばれる特別なテーブルを示します。 BigQueryの画面上で特定のテーブルを選択し、「スキーマ」タブを選択するとテーブルのスキーマ定義が確認でき、「プレビュー」タブを選択するとテーブル内のサンプルデータを確認できます。 図1. BigQueryのBitcoin Cryptocurrencyデータセットにおけるblocksテーブルのサンプルデータ ※1 BigQuery の一般公開データセット Blockchain Explorer 多くのブロックチェーンには、オンチェーンデータにリアルタイムにアクセスし、トランザクションの内容などを確認するための「Explorer」と呼ばれるオンラインサービスが提供されています。 ビットコインでも、多くのExplorerサービスが提供されています。図2は、Blockchain.com Explorerと呼ばれるサービスの画面です。 図2. Blockchain.com Explorerのサービス画面 ※2 Blockchain.com Explorer トランザクションのデータ構造 実データをもとにしながら、まずはビットコインの送金の単位であるトランザクションのデータ構造について概観してみましょう。 Blockchain.com Explorerで適当なトランザクション（例: Hash ID e2d6a46ff3c0ac7977c4e56250cc8e3a3bfb566cf1fbc1f41975ce927f268daa）をクリックしてみると、そのトランザクションの概要（図3）が表示されます。 図3. Blockchain.com Explorerでのトランザクション表示例 それぞれのトランザクションには、Hash IDと呼ばれる固有のIDが振られています。トランザクションの中で特に重要なデータ構造は、「Inputs」と「Outputs」です。「Inputs」は、過去に自身がビットコインを受け取ったトランザクションを参照し、「Outputs」は新たにビットコインを送るアドレスを指定します。このビットコインのトランザクションの形式は、お金の取引を「借方」と「貸方」の2面で表現する複式簿記の考え方に似ています。 図4. 複式簿記とビットコイントランザクションの比較イメージ 複式簿記は、お金の取引を原因と結果に分け、借方と貸方に記載します。図4の複式簿記の例では、後払いで代金を受け取る権利である売掛金50,000円を、普通預金で受け取り、支払い手数料を自社負担した場合の記載を示しています。ここで、借方の普通預金と支払手数料の合計と、貸方の売掛金の合計は一致しています。 ビットコイントランザクションの考え方も、取引の原因に該当する「Inputs」と、結果に該当する「Outputs」の合計が常に一致する、という考え方です。厳密には、「Inputs」の合計を「Outputs」の合計が超えることはなく、差額がある場合はこの取引を実行するための手数料として定義されるため、結果的に両者の合計が一致する形になっています。 ブロックのデータ構造 図5. ビットコインホワイトペーパーにおけるブロックのデータ構造イメージ 上記のトランザクションを、複数まとめたデータ構造がブロックです。ブロックにも、固有のHash IDが割り振られています。そのHash IDの計算は、ある入力に対して固定長のランダムな値を返す「ハッシュ関数」と呼ばれる関数でおこなわれます。このハッシュ関数に、「そのブロックが含んでいるトランザクション」「一つ前のブロックのHash ID」「Nonce」などを入力して、ブロックのHash IDが計算されています。Nonceとは、「number used once」の略で、一度だけ使われる使い捨てのランダムな値です。 ビットコインのブロックがなぜこのようなデータ構造になっているのかを理解するためには、ビットコインが解決しようとしてる課題が何なのかという前提の説明が必要です。少し脇道に逸れますが、ビットコインが解決しようとした課題について、身近な事例に落とし込んだ解説をしてみましょう。 ビットコインが解決しようとした課題 ビットコインが解決しようとした課題を正確に理解するためには、コンピュータサイエンスにおける分散システムの基礎知識が必要です。厳密な議論をおこなうためには本連載のみでは紙面が足りませんので、ここでは「現実世界で独自の通貨を流通させる」という仮の事例を想定しながら、どのような問題が起こりうるのかを思考実験として考えみましょう。 実世界で独自の通貨を流通させる思考実験 子どもの頃、学校の教室内で独自の通貨を流通させて遊んでいたことがある、という人もいるかもしれません。ここでは、学校の教室で独自の通貨を流通させてみるという思考実験を通じて、通貨システムと分散システムの課題について考えてみます。 レベル0. 物理的な通貨の発行 教室内で独自の通貨を流通させるためには、まずは通貨の発行が必要です。よく事例として挙がるのは、瓶の王冠やシャープペンシルの芯など、ある程度の数量が均質化された品質で入手でき、個人での偽造が難しいものを通貨として利用する事例でしょう。 通貨の代表的な役割として、「価値の尺度」「交換の手段」「価値の貯蔵」が挙げられるため、これらの役割を満たすための機能性が通貨には求められます。 特に、通貨の価値を担保するためには、その通貨が使えるユーティリティを確保するという「強制通用力」と、決められた手順以外で勝手に通貨を増やしたりできない「偽造防止」という性質が重要です。 ここでは仮に、「教師の持つ印鑑で押印された紙幣」を通貨として設定してみます。教師の持つ印鑑は複製が難しく、紙幣をコピーしてもすぐに見分けられるという前提を置いて、「偽造防止」が成立しているものとします。 また、「強制通用力」としては、教師の出題する宿題などを免除したり、教師の準備した文房具などと交換できたりといったユーティリティを想定します（ここではその是非については深入りしません）。教師と生徒の間で、この独自紙幣を用いた取引が成立するようになると、通貨としての価値が確立され、生徒間同士での取引でも使われることが期待できます。 現実世界では、日本の中央銀行が偽造の困難な紙幣を発行し、法律で強制通用力を持たせる（租税貨幣論と呼ばれる考え方では、日本の居住者は日本円で税金を納めなければならないというユーティリティを持たせる）という事例に対応しています。 レベル1. データ化された通貨の発明 上記のように発行された紙幣が広く利用されるようになると、いくつかの課題が発生しそうです。例えば、大量に発行された紙幣を「毎日持ち運ぶのが大変」「枚数を数えたり額面を足し合わせたりといった計算が大変」「紛失・盗難に遭うリスクがある」といった問題が考えられるでしょう。 これらの課題を解決する一手段として、通貨をデータ化して管理するという解決方法を導入してみます。 データ化といっても、ここでは「ノートにお金のやりとりを記録した帳簿をつくる」といった形のアナログな手段を想定します。帳簿は教師が管理し、個々の取引は教師が承認し押印することで効力を持つこととします。 この仕組みは、現実世界での銀行口座や電子マネーのようなものに該当します。大量の紙幣を持ち歩かなくても自身の持っている残高を帳簿が保証してくれますし、帳簿が適切に管理されている限りは紛失や盗難などのリスクもありません。 レベル2. システムの分散化 教師が管理する帳簿を導入しても、別の課題が発生します。例えば「教室など帳簿が存在する場所でしかやりとりできない」という課題が考えられます。物理的な紙幣を使っていたときは、部室や学校外でも生徒間で紙幣を用いた取引ができていましたが、教師が管理している帳簿に記載しなければ取引が成立しないとすると、毎回教師の下にうかがって記載してもらう必要があり、利便性を損ないます。 そこで、帳簿を記載するノートを分散化することが考えられます。生徒各自が毎日、自分の取引に関連するノートの一部を持ち帰ることができ、教室外でも取引を記載できるようにします。教室外でやりとりを記録したノートは、毎日教室で教師がチェックし、押印することで効力を持つこととします。矛盾したやりとりがあれば、どちらかを無効にする等で解消します。最終的な取引の確定には最長丸1日かかりますが、教室外でも取引を発生させることができるようになります。 現実世界では、インターネットなどのネットワークを介した分散システムを構築することに該当します。 レベル3. 管理者の分権化 分散化した帳簿を導入しても、さらなる課題が存在します。最も大きな課題として、「承認者（教師）が不在のときに停止する」という問題が発生します。例えば、教師が病気や出張などで長期間不在となってしまうと、この通貨システムは承認が行われず機能停止してしまいます。 これは、処理の一部（取引の発生）を分散化したとしても、特権的な操作（取引の承認）を一部の管理者（教師）に依存してしまっていることが原因です。 この課題を解決するためには、取引の承認を生徒自身が行えるよう、権限を分権化することが考えられます。 例えば、生徒が毎日持ち回りで承認者の役割を担うようにして、もしその生徒が何らかの事情で対応できないときは、次の生徒が繰り上がりで承認作業をおこなう、といった運用です。 レベル4. 悪意を持った参加者への対策 生徒が持ち回りで承認作業をおこなう運用にした場合、一部の生徒による不正行為が発生しないか、という懸念が持ち上がることがあります。 例えば、自分が承認者のときに自分に有利なように取引を改ざんしたり、そこまではしなくとも、仲の良くない生徒からの取引申請を意図的に受け入れなかったり対応を遅れさせたり、といった検閲行為がされる可能性があります。 （こういった問題は教師が承認者を担う場合でも存在していましたが、教師への信用によって顕在化しにくい状態だったと言えます） こうした問題は、分散システムの領域では「ビザンチン将軍問題」（※3）として有名です。ビザンチン将軍問題とは、ビザンチン帝国の将軍たちが、物理的に離れた場所にいながら、敵国に攻撃するか撤退するかについてどのように合意形成すべきか、という問題です。このとき、将軍たちの中に複数名の裏切り者がいる場合でも、正しく合意形成を行うことができるアルゴリズムが考案されており、このようなアルゴリズムを「ビザンチン障害耐性」のある合意アルゴリズムと呼びます。 詳細なアルゴリズムの挙動については説明を省きますが、参加者たちがお互いに情報を共有しあい、矛盾した情報がある場合は多数決で情報を訂正しながら全体の合意を得る、といった流れがおおまかなアイデアになります。 ただし、古典的なビザンチン障害耐性アルゴリズムは、ネットワーク参加者のうち、裏切り者（ビザンチン障害ノード）が全体の3分の1未満であることが必要とされています。裏切り者が全体の3分の1以上の場合は解決手段が発見されていませんでした。 ビットコインのブロックチェーンは、このビザンチン将軍問題を、一部の妥協を許した形であれば、よりゆるい条件（ビザンチン障害ノードが全体の50%未満）で合意形成に到れるアルゴリズムを示した、と評価されることもあります。 ※3 Leslie Lamport, Robert Shostak, Marshall Pease: “The Byzantine Generals Problem”, ACM Transactions on Programming Languages and Systems, Vol.4, No.3, pp. 382-401, 1982. https://lamport.azurewebsites.net/pubs/byz.pdf レベル5. 不特定多数の参加者による利用 教室内に不正を働く可能性のある生徒が混ざっている状態において正しく取引を記録する仕組みが構築できたとしても、さらに困難な要求をされることがあります。 それは、自分たちのクラス以外の生徒など、不特定多数のメンバーも、そのクラス内で流通している通貨を使えるようにしたい、という要求です。 最初のレベル0の物理的な通貨であれば、通貨が本物であることが証明できればクラス外のメンバーなど誰でも通貨を使うことは可能でした。 しかし、物理的な紙幣を廃止し、データとしての通貨を利用しているレベル1からレベル4の状態は、いずれもクラス内の閉じた参加者の中で使われることが前提でした。 現実世界でも、現金のような物理的な通貨は、それをつかう人が誰であっても平等に使用することができる一方、銀行預金や電子マネーのようなデータ化された支払い手段は、信頼された特定の人々しか利用できない、といった制限がありました（例えば、子どもは親権者の同意がなければ銀行口座を作れない、等）。 レベル5に該当するような「不特定多数の誰もが自由に使えるデジタル通貨」の発明は、長らく開発者にとっての夢でしたが、ビットコインの登場によって初めてこの問題が実用的なレベルで解決されたのです。 余談ですが、昨今キーワードとして話題になる「Web3」という言葉は、レベル1～2のようなWebシステムを「Web2」として、レベル3以上の分権化の仕組みを実現したWebを指す言葉として使われることがあります。 レベル3～4の問題は従来の技術で解決できる範囲ではあったものの、多くのWebサービスはレベル2止まりのシステムでビジネスをおこなっていました。そこに、ビットコインがレベル5の問題を解決するソリューションとして登場し、レベル3以上のシステムの重要性が再評価されはじめています。 ただし、レベル3以上の問題のうち、どこまでを実現できていれば「Web3」と呼べるのか、という解釈については、意見が割れているところです。 ビットコインの発明 分散システムとしてのビットコインの新規性は、上記のレベル5の問題で示したような不特定多数が参加するネットワークにおいて、ビザンチン障害耐性を持った合意形成のための現実的な解を示したことです。 しかし、ビットコインの革新性はそれにとどまらず、通貨としての強制通用力の担保や、ゲーム理論的なインセンティブ設計などのアイデアもバランスよく取り込み、実運用に耐える全く新しいデジタル通貨システムを発明したことでしょう。 最後に、ビットコインの特徴といえるポイントをまとめます。 ブロックの特徴 ビットコインのブロックには、前述のとおり、そのブロックに含まれるトランザクションや、一つ前のブロックのIDなどから計算されたHash IDが振られています。 そのHash IDは、ある値以下の数値になるようにルールが設定されており、そのルールを満たす調整のために加えられたランダムなデータが前述のNonceです。 新しいブロックを生成するためには、このNonceを大量のパターンで試し、たまたまHash IDがある値以下になるようなパターンを見つけなければなりません。この処理に大量のコンピュータリソースが必要となる設計となっています。 ナカモトコンセンサス ビットコインにおいて、あるトランザクションが承認されているかどうかは、そのトランザクションを含むブロックの連鎖に対して、どれくらいのコンピュータリソースを投入されたで判断するルールとなっています。2つの矛盾するトランザクションがあった場合、そのトランザクションを含むブロックやその後続のブロックを発見するために、より多くのリソースを消費したほうを正しいとみなす、といったアイデアです。 このアイデアは「ナカモトコンセンサス」とも呼ばれ、分散システムにおける「不特定多数の参加者」という扱いにくい対象を、コンピュータの計算リソースという定量的な数値に置き換え、それによる多数決の問題に帰着させたことに革新性があります。 このアイデアの欠点として、「どのトランザクションも、あとから覆される可能性は永久にゼロにはならない」という点があり、伝統的な金融サービスからは懸念を示されることがあります。 しかし、「トランザクションの覆る可能性が、ある一定の確率以下（0.0000….1%未満等）になればゼロとみなして良い」という妥協を許せば、現実的に機能するシステムとなることが、ビットコインの運用によって証明されつつあります。 通貨としての通用力・インセンティブ設計 国の中央銀行が発行する法定通貨の場合、最終的には「その国の税金をその法定通貨で支払わなければならない」という点が、通貨としての通用力を担保している、という考え方があります。 ビットコインの場合、ビットコインを送金するための手数料をビットコインで支払わなければならないことが通用力の根拠となっていると考えられます。 また、インセンティブ設計に関しては、トランザクション手数料や新しく発行されるビットコインが、ブロック生成者に報酬として付与される仕組みとなっており、システムの持続可能性や不正の抑制を実現しています。 ビットコインの価値を信じる人は、ブロックの生成を通じてビットコインを得ることでビットコインの仕組みの維持に貢献し、ビットコインに貢献する人が増えることでさらにビットコインの信頼性が向上し価値も向上する、という好循環が生まれやすい仕組みとなっているのです。 次回予告 ビットコインの発明によって、これまで技術的に実現が困難だと思われた不特定多数の参加者で構成される分散システム上で、新しいデジタル通貨の概念である仮想通貨（暗号資産）が登場しました。 その後、ビットコインを実現した要素技術が「ブロックチェーン」という名前で抽象化され、ビットコイン以外の仮想通貨（アルトコイン）や、より汎用的な分散台帳システムに応用されはじめました。 次回の記事では、ブロックチェーン技術を用いた「ワールド・コンピュータ」の実現を目指すイーサリアムについて解説し、ビットコインと比較しながらブロックチェーン技術の理解を深めます。 第1回：ブロックチェーンとは The post 【第2回】ビットコインの仕組み first appeared on Sqripts .