この連載では、1人目QAとしてのチームの立ち上げや組織づくりに関して、私が実践したことや試行錯誤中のことも含めてお伝えします。 前回の記事 では、QA組織立ち上げのための２人目以降のQAエンジニア採用にあたって考えることについて解説しました。 【第2回】2人目以降のQAエンジニアの採用 この連載では、1人目QAとしてのチームの立ち上げ、組織づくりに関して、私が実践したことや試行錯誤中のことも含めてお伝えします。前回の記事ではQA組織立ち上げの流れや組織の形について解説しました。今回は2人目以降のQAエンジニアを採用する際に私が考えたポイ... 　続きを読む　 Sqripts 関連記事｜Sqripts 今回は、QAエンジニアの採用が進んだ先でチームとして成果を出すための、チームビルディングについてご紹介します。 QAエンジニアに限らずどのロールにおいても、ただ採用を行ってメンバーを増やせばよいわけではありません。メンバーがその能力を発揮し、成果を出すための仕組みや関係構築が必要です。私も現在所属している部署では、QAエンジニアを採用しチームを構築している最中です。採用やチーム構築にあたっては、過去に所属していた企業でのノウハウを用いて取り組んでいます。本記事では、チームビルディングに関する一般的なポイントから、とくにQAチームにおいて重要な点についてご紹介します。 そもそもチームビルディングとは QAチームの話に入る前に、まずは一般的なチームビルディングについて見ていきましょう。 チームビルディングはチーム（組織）をビルド（構築）することですが、前述の通り単純に人を集めるだけではいけません。『チーム・ビルディング[新版] 人と人を「つなぐ」技法』によると、チームビルディングとは「チームを機能させるための働きかけ」である、とされています。 チーム（組織）は、グループ（集団）とは違います。チームがチームであるためには 共通目的 貢献意欲 コミュニケーション が必要です。チームビルディングではこれらの要素をそろえて、個人の集まりであるグループから、共通の目的に向かうチーム（組織）へと進めていくことになります。成果を出せるチームに育てていくこと、と捉えても良いかもしれません。 チームビルディングの基本ステップ 同書では、チームビルディングの基本ステップ、という考え方が紹介されています。 『チーム・ビルディング』P31 図1-10 チーム・ビルディングの基本ステップ をもとに作成 チームビルディングの要素としてよく雑談などが取り上げられます。これらは①会話に該当し、チーム内の関係性を築く、土台としての役割です。チームビルディングにはその先があり、対話や議論を通じて意味の探求・行動の変革につなげ、そしてふりかえり（省察）をしてチームづくりにフィードバックと続きます。 QAチームでのチームビルディング ここまでは、一般的なチームビルディングの定義や意味について説明しました。ここからは、QAチームの立ち上げフェーズを、タックマンモデルで考えてみましょう。 タックマンモデル 『チーム・ビルディング』P19 図1-3 タックマンモデル をもとに作成 タックマンモデルとはチームの成長の段階を表したもので、以下の4段階があります。 形成期：メンバーが集まり関係性を築く時期 混乱期：メンバーの考え方の枠組みや感情がぶつかり合う時期 統一期：共通の規範や役割分担ができあがっていく時期 機能期：チームとして機能し、成果を出していく時期 ※各期の呼称は情報源によって複数ありますが、今回は前述の書籍に合わせています。 チームビルディングをうまく行うことで、機能期に至るまでを早められます。 QAチーム形成期 形成期はメンバーが集まり関係性を築く時期のため、とくにチームビルディングにおける基本ステップのうち、 ①会話 を通じた土台づくりが行われると考えています。 雑談や分報（Times）などを通じて会話や自己開示の機会を増やし、相互のキャラクターなどを理解する施策が一般的です。 このほか、エンジニアチームの形成期には「スキルや得意分野の可視化」を行うのが個人的にオススメです。QAチームのメンバーそれぞれが 【第1回】QA組織立ち上げの流れと組織の形 | Sqripts でも触れたQMファンネルにおけるスペシャリティ QAスキルアセスメントの結果 今こそQAスキルアセスメントについて考えてみた（JaSST新潟レポートにかえて） | Sqripts QAのスキルアセスメントシートを作って適用してみた – freee Developers Hub Test.SSFをもとにした所有スキル Test.SSF Skill Standards Version 1.0 などを可視化・共有することで、相互のスキルや得意な分野を把握できます。このようなスキルの可視化・共有は関係性作りに有効で、とくに「誰が何をできるか」だけでなく「チーム全体として経験がない分野は何か」がわかります。補うための勉強会を開催してさらなるコミュニケーションの機会にしたり、QAエンジニア教育のための仕組みやコンテンツ整備をしたり、といったアクションが取れるためです。 QAチーム混乱期 「混乱」や「感情がぶつかり合う」というと表現が強めなので、どちらかといえば「方向性がまだ定まっていない時期」くらいに捉えておくのが良いと考えています。 QAチームを立ち上げてメンバー間の関係性が出来てくるとともに、チームとして会社や組織の中でどのように価値を発揮するのかや、ミッション、業務の進め方など大きなレベルのものごとを定める必要があります。 個人的な意見ではありますが、この「チームのミッションや方向性を定める」という活動自体が、とくに立ち上げ中のチームにおけるチームビルディングでは大きな意味があると考えます。もちろん組織化ができあがったあとであれば仕方ありませんが、チーム立ち上げのいわゆる初期メンバーとしてJoinするのであれば、そのチームの方向性や大きな意思決定に関われないと面白くありませんよね。 私もまさにQAチームを立ち上げている最中ですが、最初に自分が立てた「QAチームのミッション」等はメンバーがJoinしてある程度組織の状況をキャッチアップしてもらった時点で、一緒に再検討するようにしています。 QAチーム統一期 統一期は、共通の規範や役割分担ができあがっていく時期、です。形成期のところでスキルや得意分野の共有について触れましたが、そこでトライした分担などが固まってきます。この段階では、チームの方向性と現在とのギャップもハッキリしてくるため、たとえば「SET:Software Engineer in Testが必要」といったロールごとの明確な人材募集をかけたり、あるいはQAチームと開発チームの関係性についても形が見えてくるころです。 QAチームの形のパターンについては、 第1回 アジャイルな品質・QA組織パターン | Sqripts も参考にしてみてください。 混乱期から統一期にかけて、チームビルディングの基本ステップにおける ②対話 や ③議論 に相当するやりとりが必然的に増えてきます。ここで細かいテクニックですが、定例会などで雑談タイムを設けていた場合は、雑談＝ ①会話 のためのMTGと、チームとしての方針や個々の業務について話し合うMTGをそれぞれ別枠で用意するのがオススメです。混ざっていると、業務のトピックによって雑談が飛んだり、逆に雑談が盛り上がって議論の時間がなくなったりするので、明確に分けたほうがいいですね。 QAチーム機能期 機能期は、チームとして機能し、成果を出していく時期です。ここまで来ればあとは何もしなくてOK・・・ではありません。チームビルディングの基本ステップにあるように、 ④省察 を行いながら、関係づくりなどのステップが回っていきます。「チームができあがったのでもうコミュニケーションは減らしていいよね」とはいきませんよね。 ベースができて安定してきたチームでより成果を出すために、 QAエンジニアの育成・教育 QAエンジニアの評価 なども（もしまだあいまいであれば）整備する必要があります。 まとめ 今回はチームビルディングの概念や考え方の説明と、QAチームにおけるチームビルディングについて、タックマンモデルの各段階をもとに概要をご紹介しました。 ポイントになるのは、単純にコミュニケーションの機会を増やせばよいというわけではなく、そこから対話や議論へと進めていくことです。そのためには、チームの方向性・ミッション、チームの構造パターンなどを一緒に考え、試行錯誤することが大切だと考えています。 今回ご紹介した書籍以外にも、チームビルディングやエンジニア組織に関する書籍や資料は数多くあるため、ぜひ読んで参考にしてみてください。 参考 チーム・ビルディング[新版] 人と人を「つなぐ」技法（日本経済新聞出版） チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで（翔泳社） 【第13回】人がプロジェクトの源泉！チームは育てて強くする［後編］ | Sqripts 【連載】QA組織の立ち上げ方－1人目QAが語る実践と工夫－ 記事一覧 【第1回】QA組織立ち上げの流れと組織の形 【連載初回、全文公開中】 【第2回】2人目以降のQAエンジニアの採用 The post 【第3回】QAチームビルディング first appeared on Sqripts .

新卒でフロントエンド開発者をしています、イソダです。 本記事では、私があるプロジェクトで技術選定を行う際に活用したツール「Genspark」とその機能「Sparkpage」について、その利用体験を通して得た知見を共有します。 Genspark、Sparkpageとは？ Genspark は、AIを活用した検索ツールです。自然言語での質問に対して、ウェブ上の複数のソースから関連情報を収集し、回答を提供してくれます。 Gensparkには「 Sparkpage 」という便利な機能があります。この機能は、AIによる調査結果を基に、ウェブサイトのブログ記事のようなものを作成してくれます。 Sparkpageのメリットは次が挙げられます。 目的に合った情報を即座に提供 利用者が調査したい対象に特化したウェブページが存在しない場合でも、AIが最適なブログ記事を作成してくれます。 カスタマイズ可能な情報提供 情報収集や特定のテーマに合わせたページ作りが簡単です。 活用シーンとしては、次のような場合が挙げられます。 希望する調査対象にぴったり合った情報が見つからない。 独自の目的に合わせた情報をブログ形式でわかりやすく提示したい。 Sparkpageは、情報収集やコンテンツ作成を効率化したい人にとって強力なツールです。 Gensparkを使用した動機 今回の技術選定を進めるにあたり、次のような理由からGensparkを利用しました。 インフラに関する知識が不足していた。 技術選定する対象に関する基礎知識が不足していた。 限られた期間内での調査・分析が必要だった。 調査対象 今回の調査対象はChange Data Capture（CDC）サーバーというものです。データベース内の変更データをキャプチャし、リアルタイムで別のシステムに転送する技術です。この技術を利用することで、データ同期やイベントドリブンなアーキテクチャの実現に役立てることができます。 今回の技術選定では、以下の3つのCDCツールを検討しました。 PeerDB Debezium pgstream これらのツールについて、それぞれのメリットとデメリットを検討しました。 Gensparkでの実際の調査 ここでは、Gensparkを使用して実際に行った調査の内容を紹介します。 調査の流れ 1. 質問の入力 Gensparkのインターフェースに、今回知りたい内容をそのまま入力しました。(音声入力した内容をコピペしてるので、文章は一部誤りがあります) Gensparkへの質問 2. 情報の収集1 Gensparkは、複数のソースから情報を収集し、以下のような回答を提供してくれました。 スクリーンショットは回答の一部ですが、それぞれのツールのメリットデメリットを挙げてくれています。 Gensparkの回答内容 回答の文章の末尾にある丸1, 丸2, …は参照した文献を示しています。カーソルを合わせてURLリンクをクリックすることで参照文献に飛ぶことができます。 参照文献 3. 情報の収集2 回答の下の方にはSparkpageができています。 回答結果にあるGensparkpage Sparkpageを見ると、今回知りたい内容にぴったりのブログ記事が作成されています。 Sparkpageの目次 Sparkpageの「はじめに」にはCDCサーバーの概要を簡潔にまとめてくれています。 「はじめに」の章でCDCサーバーの概要とユースケースを紹介してくれている 次に続く章で各ツールの特徴と利点、デメリットを説明してくれています。 PeerDBの特徴と利点 pgstreamの特徴と利点 各方法のデメリット 「Googleクラウドでの実装」の章では、各ツールがGoogle Cloud Pub/Subと統合できるかを解説してます。 Googleクラウドでの実装 この章でpgstreamはGoogle Cloud Pub/Subと統合できるかの正確な回答がなかったので、筆者自身が追加の調査を行い、統合できることを確認しました。 Googleクラウドでの実装」内のpgstreamに関する段落。Pub/Subに関する記述がない 最後の「結論と推奨事項」では、各ツールのメリットデメリットを比較して、ある評価軸ではどのツールが優れているかの解説をしてくれています。 結論と推奨事項 Sparkpageを読むことで、 CDCサーバーの概要 各ツールのメリットデメリット Google Cloud Pub/Subと統合できるかどうか ツールを選択する上の評価軸と各評価軸においてどのツールが優れているか を一度に把握することができました。 4. 情報の分析と確認 Gensparkによってある程度の情報を収集できたので、それを参考に分析と情報の不足を補ったり、AIの回答が正しいかの調査を行いました。具体的には、Gensparkが挙げてくれたメリットデメリットを参考に評価軸を決めて、その軸に沿って追加の調査を行ったり、AIが提示してくれた参考文献を読み込んでAIの回答に間違いがないかの確認を行いました。 基礎知識は既に把握できてるので、追加の調査もすいすい進みました。 このように、Gensparkを活用することで、効率的に情報の収集と分析を行うことができました。 Gensparkが活躍したポイント 今回のプロジェクトでは基礎知識が乏しい状態だったため、いきなりツールを試すのではなく、事前にそれらの背景や特徴を理解しておくことが重要でした。その際にGensparkが以下の点で役立ちました。 基礎知識の迅速な習得 初心者でもわかりやすいCDCサーバーの概要を含めたブログ記事を提示してくれました。 各ツールのメリット・デメリットの比較情報を提示 3つのツールを横並びで比較できる資料を提供してくれたことで、調査の効率が大幅に向上しました。 これによって、短時間で各ツールの概要や特徴を理解し、より適切なツール選定を行うことができました。 まとめ 技術選定において、基礎知識の習得や情報収集は多くの時間を必要とします。特に私は、インフラやデータベースの経験が浅いため、知識のキャッチアップを効率よく行うことが大きな課題でした。しかし、Gensparkを活用したことで、限られた時間の中でもスムーズに調査と分析を進めることができました。 The post 技術選定の調査がGensparkで捗った話 first appeared on Sqripts .

ソフトウェア開発の世界では、アジャイル開発やスクラムが一般的になってきました。そのアジャイル開発のコアとも言えるのが、対話や協調です。この連載では、アジャイル開発におけるコミュニケーション・コラボレーションスキルを解説しながら、ファシリテーションスキルのレベルアップを目指します。 ＜スクラムマスターのためのコミュニケーション講座　連載一覧＞ ※クリックで開きます ・ #イントロダクション：優れたスクラムマスターが絶対に言わないこと 【連載初回、全文公開中】 ・ あなたの提案はなぜ受け入れられないのか？｜ファシリテーション技術-1- ・ よりよい場を作るための9つのルール［前編］｜ファシリテーション技術 -2- ・ よりよい場を作るための9つのルール［後編］｜ファシリテーション技術 -3- ・ コーチング技術 〜 基本技術を学ぼう｜コーチング技術 -1- ・ コーチング技術 〜 質問力を高めよう｜コーチング技術 -2- ・ 上級者が活用する質問例｜コーチング技術 -3- ・ 実践1on1[1] 〜 簡単だけど難しい1on1 ・ 実践1on1[2] 〜 コミュニケーションの方法を使い分けよう！ ・ 実践1on1[3] 〜 相手に合わせたコミュニケーション方法とは？ ・ 実践1on1[4] 〜 実例をもとに1on1をレベルアップ ・ 【最終回】さらなる成長のためのコミュニケーショントレーニング 最終回のテーマは「コミュニケーションのトレーニング」です。 前回のおさらい 前回までは、ファシリテーション、コーチング、1on1と、具体的なコミュニケーション技術を解説してきました。この連載の最後は、学んだ技術を磨いていくための技術の解説です。 人見知りでもアジャイルコーチはできる 私は独立して、アジャイルコーチとして仕事をしています。前職などではエンジニアリングマネージャとして、メンバーの育成や採用を通して部署の立ち上げを行っていましたが、もともとコミュニケーションが得意な人間ではありません。 たとえば、もう40歳を超える年齢になりましたが、買い物に行って店員さんに「あの、この服のMサイズありますか？」と聞けません。店員さんが忙しそうなら「買うのやーめた」とすぐ諦めます。イベントの懇親会などにも多く出席しましたが、話かけるのが苦手なので、たいていは会場のすみっこでちびちびビールを飲んでいます。 こういう話をお客さまに話すと「またまた〜」と一蹴されますが、この話は本当です。こんな私でも、仕事で訓練を積むことで、人並みにコミュニケーションスキルを身につけられるようになりました。 コミュニケーションが苦手な人は多いですが、コミュニケーションスキルはあとでどうにでもなると思います。 それでは、どのようにそのスキルを学んでいくかを考えていきます。 国際コーチング連盟の認定資格を学ぶ 国際コーチング連盟（通称ICF）は、国際的なコーチング資格を運営している団体です。日本にも支部があります（ 一般社団法人国際コーチング連盟 日本支部 ）。 ICF認定資格 は、ACC（アソシエート認定コーチ）、PCC（プロフェッショナル認定コーチ）、MCC（マスター認定コーチ）の3つがあり、毎年多くの人が認定されています。 個人的な感覚になりますが、普段から1on1などに慣れているならACCは簡単だと思います。しかし、PCCになると独学では難しい部分があるため、スクールで様々な人とセッションを持つのがおすすめです。PCCにもとめられるレベルは、PCCマーカーという形で公開されているので、PCCマーカーの内容を眺めてみるといいでしょう（参考： PCCマーカーを使いコーチとしてのスキルや振る舞いを鍛えていく方法 ）。 MCCレベルは達人です。コミュニケーションの取り方、間、質問内容、ふるまいかた、どれをとっても自然な所作なので、わかるひとにしかわからないスキルに感じています（私自身もPCCの勉強をすることでMCCのすごみに気がつきました）。 ICF認定資格は、国内にも認定スクールがたくさんあるので、自分にあったスクールに通うといいと思います。 期間的にはACCやPCCで1年ずつぐらいかかります。これはスクールで単位（CCUと呼ばれる）を取るのに時間がかかるからです。また、ICF認定資格は最低限必要となるコーチング経験がACCだと100時間以上、PCCだと500時間以上、MCCだと2,500時間以上必要になるため、条件を満たすために時間がかかる人も多いです。 アジャイルコーチやスクラムマスターの仕事をしているなら、ICFは基礎的なコーチングスキルを学ぶのにぴったりです。最近だと、海外企業で専任コーチを雇う傾向が強く、今後、国内でも専任コーチが求められてくると思います。実際に、専任コーチをやとっているIT企業もあります。ICFのコーチングはとても純粋で、独自路線を嫌い、王道を歩み続けている印象があるため、基礎を学ぶにはピッタリと言えます。 コミュニティで学ぶ コーチングなどは地元にコミュニティがあったりします。私の場合、お世話になったメンターコーチにおすすめされた 日本コーチ協会神奈川チャプター に所属しており、イベントなどにたまに参加して腕を磨いています。 スクールは比較的高い金額を身銭を切って参加している方が多い影響か、比較的意識高く学ぼうとする人が多いため、企業向けのビジネスコーチを目指す方が多い印象があります。 一方、ローカルのコミュニティだと、料金は抑えめです。その影響か、主婦や定年を迎えた方など、一般の方々が多い印象です。一般的なパーソナルコーチを目指すのであれば、お互いいい練習相手になると思います。 ファシリテーションであれば、 FAJ：特定非営利活動法人 日本ファシリテーション協会 があります。基礎講座が定期的に開催されており、とっかかりとして学ぶには最適でしょう。コーチングを学んだ方であれば、ファシリテーションの基礎講座に共通点が多いことに気が付きます。傾聴や質問は、両者に共通するスキルなのです。 1on1で学ぶ 私は一人で働いているため、客観的に自分を見てくれる人がお客さましかいません。たとえお客さまでも、厳しいフィードバックを伝えにくいと思う方も多いです。 そこで、私の場合は、信頼できるパートナーを選んで、定期的に1on1をしてもらっています。パートナーも似たような仕事をしているので、お互いに悩みを持ち寄ったり、共通のテーマで意見を交換したりしています。 現在1on1をしているパートナーとは付き合いも長く、家族ぐるみの付き合いなので、定期的な1on1が近況報告にもなっています。 コロナ全盛期では、外部とのやりとりが途絶えてしまいましたが、こういったつながりによって、切磋琢磨することができました。 自分たちで学ぶ 先生役がひとりいればとてもよいですが、もしいなければあなた自身が先生になればよいでしょう。認定資格やコミュニティで学んだことを現場で実践すれば、わかっていること、わかっていないことが明確になり、どんどんスキルが付いてくるでしょう。 1on1やふりかえりのあとに、ふりかえりのふりかえりをするのも有効な手です。 今回良かったところはどこか？ 今回いまいちだったところはどこか？ 次にどう活かすか？ を簡単にふりかえり、改善サイクルを回していきます。 1on1だと上司部下の関係が多いので、部下に聞くのをためらう人も多いはずです。しかし、1on1は相手の場です。いいところやいまいちなところを正直に話してもらえる関係性を築けば、1on1は成功したも同然でしょう。 ＊ この連載では、「スクラムマスターのためのコミュニケーション講座」と題して、スクラムマスターに求められるコミュニケーションについて解説してきました。コミュニケーションスキルは、スクラムマスターだけでなく、アジャイルコーチやエンジニアリングマネージャ、ソフトウェア開発に関わる方であれば、必ず役立つスキルだと思います。 エンジニアに限らず、人として生きる限り、一番良く使うスキルかもしれません。 それなのにコミュニケーション技術は、なかなか教えてもらえません。なんとなくMTGを仕切ったり、ファシリテーションをやったりする機会は多いのに、具体的なスキルアップ方法が学びにくいのはとてももったいないことだと思います。 そんな思いからできたのが「チームが自走するためのコミュニケーション入門」というトレーニングでした。毎回やるたびに改善を重ね、バージョンはv2.1になっています。この記事はこのトレーニングをベースにしています。 今回は、コミュニケーショントレーニングについて解説しました。 これまでにコミュニケーション技術を解説してきたので、具体的な手段を手に入れることができたはずです。さらに今回、腕の磨き方も解説したので、やる気さえあればどんどん上達できる場が整いました。 次はみなさんが、その成果を発揮する番です！ みなさまの現場において、すばらしいコミュニケーションが行われ、素晴らしいプロダクトが生まれることを祈っています。 連載一覧 ・ #イントロダクション：優れたスクラムマスターが絶対に言わないこと 【連載初回、全文公開中】 ・ あなたの提案はなぜ受け入れられないのか？｜ファシリテーション技術-1- ・ よりよい場を作るための9つのルール［前編］｜ファシリテーション技術 -2- ・ よりよい場を作るための9つのルール［後編］｜ファシリテーション技術 -3- ・ コーチング技術 〜 基本技術を学ぼう｜コーチング技術 -1- ・ コーチング技術 〜 質問力を高めよう｜コーチング技術 -2- ・ 上級者が活用する質問例｜コーチング技術 -3- ・ 実践1on1[1] 〜 簡単だけど難しい1on1 ・ 実践1on1[2] 〜 コミュニケーションの方法を使い分けよう！ ・ 実践1on1[3] 〜 相手に合わせたコミュニケーション方法とは？ ・ 実践1on1[4] 〜 実例をもとに1on1をレベルアップ ・ 【最終回】さらなる成長のためのコミュニケーショントレーニング The post 【最終回】さらなる成長のためのコミュニケーショントレーニング first appeared on Sqripts .

こんにちは！QAエンジニアのうえやまです。 現在、E2Eテスト自動化に携わっている中で「メンテナンス性の高いロケーター」を使うことの大切さを実感しています。 本記事では簡単なロケーターの解説から始め、私が普段意識しているロケーターの書き方を実体験とあわせて紹介していきます。 ロケーターとは？ UI自動テストツールにおいて「入力欄」や「ボタン」等の要素を指定する部分です。例として以下のように書きます。 id=signIn ：システムIDがsignInの画面要素 xpath=//input[1] ：上から１番目の入力エリア xpath=//button[text()=’サインイン’] ：テキストが「サインイン」のボタン ※細かい文法はツールによって異なるようですが、本記事ではSeleniumに近い文法で紹介します。 「良い」ロケーターとは？ 良いロケーター＝メンテナンス性が高い＝変更が入っても壊れづらい メンテナンス性とは「コード/スクリプトの保守性」を指します。 変更とは主に「ソースコードの変更」を指します。（e.g. 要素の階層変更、テキストの変更） 以下のような変更があった際はスクリプト修正が必要になります。 仕様の変更 オブジェクトIDの変更（要素をID指定している場合） ⇒ツールによっては自動修復してくれるものもあるようです。 一意のロケーター idとname どちらも識別子としての役割を果たしますが、以下の違いがあるようです。 idは一意性あり nameは一意性なし（グループ化された要素の識別に使用されることが多いとこのこと） nameを指定する場合は画面上で一意であるか確かめる必要がありそうですね。 次に、「xpath」で一意性を持たせる書き方を紹介します。 水色の要素を指定したい時、以下だけだと当てはまる要素が複数あります。 //a[@class=’hoge’] ですが、親要素も指定することで一意にすることが出来ます。 //li[@id=’topics2′] / a[@class=’hoge’] 「xxが存在すること」のような期待値確認でこれらを意識することで、「Aのテーブルに存在することを確認したかったのに、Bのテーブルに存在する時でもOK扱いになってしまった」のようなミスを防げます。 汎用性の高いロケーター テストを作っている時に「これ他のケースでも使うだろうな」と思った部品（e.g. ログイン動作、データの初期化）は共有ステップとして登録しておくと後が楽になります。またスクリプトの可読性も上がります。 さらに汎用性の高いロケーターにしておくと「過去の自分ナイス！」または「○○さんさすが！」ということになります。 例えば自分が今作っているのはタブAのテストだとしても、BとCもテストすることが決まっているなら変数にして他のタブでも選択出来るような作りにしておくと良いです。 Tips : text指定の使い分け text指定する場合は「文字列自体が正しいかチェックしたい時」または「変更されにくいテキストであること」が望ましいと考えます。 経験談として、ツールが推奨してくるtext指定のロケーターをやみくもに採用し、ソースコードのリファクタが入った際に元々入っていたスペースが消えてＮＧが多発するということがありました。影響範囲の調査と対応に１日かかり、その後も何らかのコード修正がきっかけで同じ問題が散見されてます。text以外で指定するか、containsを使った部分一致で文字列指定していれば防げた例です。 どんなロケーターを使うとより良いテストが出来るか、またリスクがあるか考えながら実装出来ると良いですね。 実践編 私がロケーターを作成する時の方法を紹介します。 テストを作っていると、ツールのロケーター生成には出てこないけど「こういう感じで要素指定したいから自分で書きたいな」という箇所が出てきます。その時に一々ロケーターを実装して流して失敗してを繰り返すのは大変なので、以下の方法でパスが通ることと一意であることを確認してから実装します。 F12または右クリック→検証で開発者ツールを開く ctrl+Fでセレクター検索窓を出す パスを書いてみる ヒットすれば要素にハイライトが当たります。画像では右下の数字が「3 of 6」になっていて、「同じパスの要素が6個あるうち、今は上から3個目にハイライトが当たっているよ」という意味になります。 目的の要素を一意に指定出来るまで試行錯誤する 1 of 1になったら成功。パスをコピーして実装する。 今回は親要素を指定して一意にしました。 おまけとして、ロケーターを探してくれるツールも紹介します。 POM Builder Chromeのアドオンに入れて、先ほど紹介した開発者ツールの中で使うツールです。 お手軽に推奨のロケーターを生成してくれます。 ただ、万能ではないので複雑なロケーター指定をしたい場合はやはり自分で作成する必要があります。 最後に 私自身も自動テストについてはまだまだ研究中ながら、実践を通して得た知識を紹介しました。テスト実装初心者の方やロケーターの書き方に興味がある方に少しでも参考になれば幸いです。 メンテナンス性が高いロケーターを書いて、壊れづらい自動テストを作りましょう！ 最後まで見ていただきありがとうございました。 The post メンテナンス性が高いロケーターを書いて、壊れづらい自動テストを作ろう！ first appeared on Sqripts .

あなたはQAエンジニアとして、どのようにキャリアを積んでいけばよいか、迷ったことはありませんか？ 私はたくさんあります。 組織やプロジェクトによって、QAエンジニアの役割や責務は大きく異なります。しかし、どんな環境でも共通して押さえておくべきポイントが存在します。 『目的』『ハードスキル』『ソフトスキル』『継続的な学習』『マインドセット』『仲間』です。 この連載では、ソフトウェア開発のQAエンジニアとして働き始めた皆様に向けて、私の実体験をもとに「こんなことを知っておけばよかった」という、ちょっとした気づきを共有します。 一緒にソフトウェア開発のQAエンジニアとしての充実したエンジニアライフを築くためのヒントを探っていきましょう。 連載の第一回となる本記事では、それらのポイントについて概要を紹介したいと思います。 これらのポイントは、続く第2回以降の記事で深堀りしていきます。 なお、本連載では今後”QA”と表現していますが、これは単にソフトウェア開発におけるQAを指します。 顧客のことを考えて仕事をしよう 仕事の『目的』は、単にタスクをこなすことや数字を上げることではありません。最も重要なことは「顧客に価値を届けること」だと私は考えています。 つまり、「あなたの仕事を待っているお客様がいる」ということです。 こういった視点はQAエンジニアにとっても非常に大切です。 あなたがテストや品質保証の活動で携わっている製品やサービスは、必ず誰かにとって価値があります。 その価値を守り、きちんと届けることがQAエンジニアとしてのあなたの役割です。 これらの考えは、TQCにおける「顧客志向」という原則にも通じる部分があり、QAエンジニアとしても参考にしていただけると思います。 本テーマは連載の第2回で取り上げます。 QAエンジニアの必須スキル：ソフトウェアテスト 一言でQAエンジニアと言っても、多種多様な役割やあり方が存在します。 とはいえ、その中でもソフトウェアテストは基本的なスキルだと言っていいのではないでしょうか。 テストという活動は、高品質の製品を、自信を持って世の中に送り出すために必要不可欠な活動の一つです。 QAエンジニアとして重要な『ハードスキル』として、ソフトウェアテストについて知り・理解し・考えていくことが、あなたのQAエンジニアとしての活動を充実させる道標になると思っています。 本テーマは連載の第3回、第4回で取り上げます。 チームで働いているということ QAエンジニアとして、一人で働いていることはほとんどないのではないでしょうか。 QAエンジニアが専任のロールとして置かれている現場では、まず誰かが何かを作らないと品質保証の活動ができない場合がほとんどだと思います。 QAエンジニアに課せられた責務を一人で完結させられる人は稀です。実際にQAエンジニアは様々なステークホルダーと協力して、効率的に、そして効果的に仕事を進める必要があります。 『ソフトスキル』として、チームプレイヤーとしての心構えや、効果的で誠実なコミュニケーションの取り方についてきちんとキャッチアップして、チームの中で貢献することが必要となります。 QAエンジニアにとってチームで働くということは、個々の役割を理解し、他のメンバーとの協力を通じてチーム全体でより良い製品を顧客に提供することを目指すことです。 本テーマは連載の第5回で取り上げます。 スキルアップするためのスキルをつける 一般的に、IT業界では技術や知識体系のアップデートが早いと言われています。これは事実です。 QAエンジニアも同様に、この先生き残るためには学習を継続して、自分を成長させることが必要不可欠になります。 これはスキルアップすること自体をスキルとして捉えて、身につけることと同じです。 『継続的な学習』をするために必要な習慣や心構えを知り、自走できるQAエンジニアとなることが成長への道を開くと考えます。 また、学習をするために様々なプラットフォームを利用したり、イベントに参加することもいい手段だと思います。 本テーマは連載の第6回で取り上げます。 目の前の現場を改善するマインドセット スキルや知識だけでQAエンジニア生活を充実させるのは難しいでしょう。 学んだ知識やスキルを実践し、現場の働き方を改善できてこその良いQAエンジニアではないかと私は考えます。 QAエンジニアは仕事の性質上、様々な問題や課題に出会うことになります。 これらの問題や課題について、決して他責にして終わってしまうのではなく、自分から改善のきっかけを作っていけるような動きが求められます。 そのためには、柔軟な思考や前向きな考えといった『マインドセット』を身につけることが必要になります。 これらはエンジニアとしてだけではなく、どんな職種においても力を発揮できるマインドセットです。 本テーマは連載の第7回で取り上げます。 あなたは一人でない ここまでのポイントをしっかりキャッチアップして頑張っていても、実際の職場では孤独に感じることはあると思います。 「改善したいのは私だけでは？」「努力しているのは自分だけでは？」と感じてしまう日もあります。 もしそう感じているのならば、そう感じているのはあなただけではないと、私は断言できます。 社内に仲間がいないと思ったら、思い切って社外に飛び出して『仲間』を探してみましょう。 QAというニッチな領域にも様々なイベントやコミュニティが存在します。 また、QAだけではなく、様々なエンジニアコミュニティや他業種のコミュニティに参加するのもいいと思います。 本テーマは連載の第8回で取り上げます。 一番大切なのは自分自身 これらの内容は今後の連載のアウトラインとなりますので、今後読んでみたいと思ってくださった方はぜひSqriptsへの 会員登録 をお願いします。 記事執筆時点(2024/11/27)では無料で会員登録が可能です。 本記事ではもう一つだけ、紹介したいことがあります。 社会人として一番大切なことはなんでしょうか？ ビジネスマナーやマインドセットやスキル、もしかしたら人脈と思う方もいらっしゃると思います。 私は全部違うと思います。 一番大切なことは『体調管理』です。 体調を崩してはどんな仕事も充実しませんし、自分自身がいい状態でいることはよりよい人生を歩むために大切なことです。 どんなに優れたスキルや知識があっても、体調管理ができなければ充実したQAエンジニアライフは続きません。 心身の健康を維持して、QAエンジニアとしての道を力強く進んでいくために、まず自分自身を大切にしてください。 自分自身の健康のために、以下の書籍から学ぶことをおすすめします。 今後の連載では、それぞれの記事で同様の形で私からおすすめの書籍を紹介していきます。 ヘルシープログラマ ｜O’Reilly Japan 「アジャイル式」健康カイゼンガイド ｜翔泳社 セルフケアの道具箱――ストレスと上手につきあう100のワーク ｜晶文社 それでは皆さん、健康を大切にしながら、充実したQAエンジニアライフを楽しんでください！ The post 【第1回】充実したQAエンジニアとしてスタートするためのガイドライン first appeared on Sqripts .

こんにちは。クオリティマネージャーのおすぎです。 プロジェクトマネージャーやテストマネージャーといった、プロジェクト管理を担う方であればPMBOKについて勉強した方もいらっしゃると思います。 PMBOKはプロジェクトマネジメントの世界標準になっているもので、アメリカの非営利団体であるPMI（プロジェクトマネジメント協会）( ※1 )( ※2 )が、プロジェクトマネジメントの知識を体系化して標準化したものです。 私もプロジェクトを任されるようになった際、困ったことがあればPMBOKに倣おうと思い、PMBOKの書籍を手元に置いていました。 しかし、書籍を読んだからといって上手くいくとは限らず、「自分のプロジェクト管理はPMBOKに倣えているのか」「PMBOKで謳っていることを正しく実践できているのか」と自信を持つことができずにいました。 そんなときに会社の先輩から教えてもらったのがPMPでした。 PMP取得により仕事の変化を実感でき、私のキャリアの大きな分岐点になりました。 そんなPMPのメリットをご紹介します。 PMPとは PMPはProject Management Professional（プロジェクトマネジメント・プロフェッショナル）の略で、PMIが認定するプロジェクトマネジメントの国際資格です。 PMPで問われる知識やスキルはPMBOKガイドに基づいており、PMPの資格取得者はプロジェクトマネジメントの体系的な知識を備えているとみなされます。 日本で聞くことはほとんどありませんが、海外ではPMPの資格保有がプロジェクト受注の要件になることもあるようです。 受験資格に「プロジェクトマネジメントの実務経験」と「PMIが認定している公式な研修受講」が必要な点と、資格取得後も3年ごとに資格更新が必要な点も特徴です。( ※3 ) また、プロジェクトマネジメントの資格として比較されるものに、情報処理推進機構が実施するプロジェクトマネージャー試験( ※4 )があります。 プロジェクトマネージャー試験はIT分野を対象にした国家資格ですが、PMPは分野を問わず、あくまでプロジェクトを対象にした民間資格です。 IPAが定義しているITスキル標準（ITSS）では、PMPはレベル3、プロジェクトマネージャー試験はレベル4、と位置付けられており、プロジェクトマネージャー試験と比較すると取得しやすいと言われています。 PMPのメリット PMI日本支部のホームページには、PMP取得により期待できる効果として以下の３つが記載されていますので、私の経験も踏まえて紹介します。 スキルアップ キャリアアップ 人的ネットワークの拡大 スキルアップ PMBOKはIT分野に特化したものではなく分野に特化せず横断的に活用できるものですので、どのようなプロジェクトであってもなんとかなる、という自信が持てるようになります。 私がプロジェクト管理を任され始めた当初は、プロジェクトの立ち上げやプロジェクトを引き継ぐとなった際に「何から手をつければ良いかわからない」「どこに課題があるかわからない」といった事が多く、自身の対応に自信が持てなくなっていました。 しかしPMP取得後は、プロジェクトの立ち上げやプロジェクトの引き継ぎがあっても、PMBOKのフレームワークに沿って対応すれば問題ないと自信が持てるようになりました。 また、プロジェクトマネジメントに対する知見も増えてきます。 プロセス上の問題点に気づくことで継続的な改善に繋げれますし、ステークホルダーへの説得力も増し、信頼を得ることにも繋がります。 PMPを取得するとCCR( ※5 )と呼ばれるプログラムへの参加が必要になり、CCRプログラムを通じて3年ごとの資格更新が必要になります。 CCRプログラムは資格保有者の継続的な学習活動や能力開発を支援するものです。 PMP所有者は資格を維持するために継続的に学習を続けるため、必然的にスキルが身についていきます。 私も書籍を読んだり、e-Learningやセミナーなどを活用して資格維持に努めています。 キャリアアップ PMPの取得により資格手当が出る企業もあれば、昇給や昇格に繋がる企業もあるかもしれませんが、私が最も実感しているのは安定して成果が出せるようになったことです。 それまでは過去に経験した方法や前任者の方法を踏襲してプロジェクトを管理していましたが、想定していない事象が発生した際に上手く立ち回れないことが多かったです。 しかしPMBOKの知識エリアに沿って事前に備えることができるようになり、プロジェクトの成功率が上がっていきました。上司や周囲からも信頼されるようになり、重要なプロジェクトを任せて貰えるようになっていきました。 また、PMPの資格が認定されると名刺への記載が可能になり、プロジェクトマネジメントの専門知識を持っていることを対外的に示すことができるようになります。名刺交換の際もPMPの記載を見ると好意的な反応をしてくださる方が多い印象があります。 人的ネットワークの拡大 PMPの受験資格を得るためには公式な研修への参加が必須条件になっています。 また、PMIが主催するセミナーや勉強会も頻繁に実施され、SNSのコミュニティーも多くあります。 私もPMP資格更新に必要なポイントを得る目的でセミナーに参加することがあります。 そのような場には、共通の目的や目標あるいは同じような課題を抱えた方が集まっています。 PMPは様々な分野の方が取得されていますが、PMPで学んだことが共通言語としても活用できるので、コミュニケーションがとりやすいです。 自己紹介や身の上話をしていく内に、自分にあったコミュニティーを紹介して頂いたこともあれば、自社が提供しているサービスを紹介して案件化するなどビジネスに繋がったこともありました。 また、PMPは3年ごとに資格更新が必要で、その要件を満たすことに苦労される方もいるため、PMP所有者同士で情報交換するなど仲間意識が芽生えやすかったりもします。 勉強方法 私がPMPを取得したときはPMBOK 第6版が最新版でしたので、今と若干内容が異なっているかもしれませんが、参考までに私がPMP合格に至った勉強方法をご紹介します。 なお、勉強期間は4ヶ月でした。 ①「5つのプロセス群」「10の知識エリア」「49のプロセス」を暗記する 下記は知識エリアとプロセスをまとめた表です。 私が最初に取り組んだのは、この知識エリアとプロセスの表を元に、どの知識エリアにどのようなプロセスがあるのかを徹底的に暗記することでした。知識エリアごとにノートに書き出し、正しく記載できるまで何度も繰り返し書いて覚えました。 ②各プロセスごとのITTOを理解する ITTOとは Inputs Tools&Techniques Outputs の頭文字を取ったもので、「インプット」「ツールと技法」「アウトプット」のことです。 PMBOKのプロセスは、「インプット」となる成果物や情報を、「ツールと技法」を使用して、「アウトプット」となる成果物や成果を作り出す活動です。 あるプロセスの「アウトプット」の成果物が、別プロセスの「インプット」になることもあります。 その関連を理解します。 私はPMBOKの書籍を読みながら、実際の活動を頭の中でイメージしていました。 各プロセスでの活動がどの成果物に影響するのか理解する必要がありますが、はじめにプロセスをしっかりと暗記できていたので、関連が理解しやすかったです。 ③過去問を解く PMPの試験は制限時間230分で180問（採点されないダミーが5問含まれます）が出題され、正答率60％程度が必要と言われます。 なので、その正答率を安定してクリアするまで、がむしゃらに過去問を解きます。 過去問を解いては書籍での復習を繰り返しました。 私は過去問を2冊準備しましたが、2冊続けて正答率が70%を超えることを自身に課しており、その努力の甲斐あって無事合格するに至りました。 さいごに 昨今のプロジェクトマネジメントはPMBOKが主流であり、例えば計画書と呼ばれるものはPMBOKに準拠していることがスタンダードになっています。 これまでプロジェクトマネジメント業務を自己流で進められていた方も多いと思いますが、PMBOKの体系だった知識を身につける事で、今まで以上にスムーズにプロジェクトマネジメント業務を進めることができます。 PMPの受験資格の要件を満たすことが難しい方は、CAPM（Certified Associate in Project Management）( ※6 )というPMPの下位に相当する試験も準備されています。 こちらもPMBOKの基礎的な内容が問われるもので、PMBOKの理解を深めるのに役立ちます。 PMBOKは1996年に第1版が発行され、最新版は2021年に第7版が発行されているように、プロジェクトマネジメントの世界も進化し続けています。 私もその進化に遅れを取らないように、これからもスキルアップを怠らないようにしたいと思います。 ▼関連記事｜PMP保持のプロジェクトマネージャー西田美香さんの連載記事もおすすめです。 【第1回】プロジェクトマネジメントとは何か？ 私は仕事柄、所謂炎上プロジェクトの火消しや、前任PMが胃潰瘍で離脱して…といった「修羅場」をなんとか制御してクローズまで持っていくといった役割を担うことが多くあります。ここで質問です、プロジェクトを成功させるには炎上プロジェクトを鎮火する技術プロジェ... 　続きを読む　 Sqripts 関連記事｜Sqripts 出典 ※1 PMI（Project Management Institute, Inc.） https://www.pmi.org/ ※2 一般社団法人 PMI日本支部 https://www.pmi-japan.org/ ※3 PMP®資格について https://www.pmi-japan.org/pmp_license/pmp/ ※4 プロジェクトマネージャー試験 https://www.ipa.go.jp/shiken/kubun/pm.html ※5 資格の更新について https://www.pmi-japan.org/pmp_license/renewal/ ※6 CAPM試験について https://www.pmi-japan.org/pmp_license/capm/ The post PMP®資格取得のすすめ first appeared on Sqripts .

テストエンジニアが身につけておきたいスキルの一つ「論理のスキル」。 「論理の言葉」の意味や働きに注意が向くようになったら、文や文章の読み書きで実践していきましょう。 この連載では、「論理スキル“実践編”」と題して、「文章の筋道を把握する、主張を理解する」「文や文章の筋道を組み立てる」ことに役立つ 推論の形 を見ていきます。 ＜テストエンジニアのための論理スキル[実践編]　記事一覧＞ ※クリックで開きます 論理のかたち。推論とは ［全文公開中！］ 基本的な推論形式 “または”を使って推論する “ならば”を使って推論する “ならば”と“または”で推論する ソクラテスは電気羊の夢を見るか？ (前編) ソクラテスは電気羊の夢を見るか？ (後編) 気をつけたい落とし穴(前編・形式面) 【最終回】気をつけたい落とし穴(後編・非形式面) 今回は、ここまで取り上げてこなかった「非形式面（意味内容の面）で気をつけたい落とし穴」を紹介します。 気をつけたい、さまざまな落とし穴 意味内容面の落とし穴(誤謬) 非形式面(意味内容面)の落とし穴(誤謬) とは、推論の形に関わりなく混入する、以下に該当するものを指します。 言語そのものの性質や、言葉の使い方に起因する誤り 前提や結論そのものの間違いや、根拠と結論との関連性の薄さ（関連のなさ）に起因する誤り 妥当(正しい形)であり、かつ、前提もすべて真である演繹的推論を 健全である といいますが、意味内容面の誤りは健全な推論の大敵です。 わかりやすい例。 ①地球は平らであるか、または、太陽が地球の周りを回っている。 ②地球は平らではない。 ③従って、太陽が地球の周りを回っている。 形は妥当な選言三段論法であるものの、選言肢がどちらも偽ですから選言部分全体が偽となり、健全ではありません。 が、見た目の形に惑わされてしまうといったことが起こります。 意味内容面の誤りは 演繹的な推論に限らず、言語コミュニケーション全般で気をつけたい落とし穴 でもあります。 （うっかり落とし穴にはまることもありますし、残念ながら、 意図的に誤謬を含む主張をする 人もいます） 図9-1 非形式面(意味内容面)の落とし穴 本記事での取り上げ方 意味内容面での落とし穴は 多種多様 なので、何かしらの分類をガイドにするのがよいでしょう。 個々の誤謬の特徴を理解する助けになる 読んでいる文章や自分の考えごとに対して、「こんな落とし穴にはまっていないか」 「こんな種類の間違いを犯していないか」と注意を向ける助けになる 本記事では『論理学入門』(文末参考文献参照)を参考にしました （用語は本連載に合わせて変更しています）。 言語上の誤謬 (fallacy in dictione)：推論に用いる 言語そのものの性質から生じる誤り 言語外の誤謬 (fallacy extra dictionem)：主張の内容や論点、前提についての 不注意や勘違い、考え違いから生じる誤り 図9-2 非形式面の誤謬の分け方 注意点として、 どちらの種類も、本記事で紹介しているものがすべてではありません 。 これらの分類は排他的なものではありません。複数の分類に該当する誤りもあります（視点によって分類が変わる）。 誤謬の名称は、人により文献によって名称が異なることもあります。 いくつかの落とし穴が重複したり関連したりして間違った推論を形づくることもあります。 言語上の落とし穴(誤謬) 「言語上の誤謬」とは、言語そのものの特性（見方によっては、言語に内在する問題とも言えます）に起因する誤りです。 次のようなものが挙げられます。 多義あるいは文章曖昧の誤謬 強調の誤謬 合成の誤謬、分解の誤謬 多義あるいは文章曖昧の虚偽 定言三段論法で気をつけたい落とし穴 で「四個概念の誤謬」を紹介しましたが、そもそも言語には曖昧さがつきまといます。それがコミュニケーションを円滑にしたり効率を高めたりする一面もありますが、考えを明瞭に述べたい時には注意を払うべきです。 図9-3 多義、あるいは文章曖昧の誤謬 強調の誤謬 主張（文や発言）の中の一部の語句や表現を強調することで明言されていない意味合いが生じたり、強調箇所が変わることで異なる意味合いが生じたりします(図9-4)。 誰でも思い当たることがあるのではないでしょうか。 図9-4 強調の誤謬 読み手/聞き手の立場なら、文字/テキストでは フォントや文字サイズ、文字修飾など 、口頭のコミュニケーションでは 発音や抑揚など に気をつけましょう。 書き手/話し手の立場としては、強調の表現を使う時には読み手や聞き手にどんな印象を与えそうかよく考えましょう。 合成の誤謬、分解の誤謬 「個別の構成要素について言えること(性質、特徴、傾向など)が、全体についても当てはまる」と考えるのを 合成の誤謬 、 逆に「全体について言えることが、個別の構成要素にも当てはまる」と考えるのを 分解の誤謬 といいます。 図9-5のような思い込みをしたことはありませんか？　どちらも私たちが囚われてしまいがちな誤りですが、 正しい場合もある だけに、「全体と部分」に言及している時には注意したいところです。 図9-5 合成の誤謬、分解の誤謬 言語外の落とし穴(誤謬) 主張や話題の内容や論点、また前提や根拠についての不注意や勘違い、考え違いから生じる誤りです。 次のようなものが含まれます。 論点窃取(論点先取)の誤謬 論点相違の誤謬 前提の誤謬 因果関係の誤謬 論点窃取(論点先取)の誤謬 結論として言われるべき事柄を前提にして推論してしまう誤り。 循環論法 とも言います。 図9-6 論点窃取(論点先取)の誤謬 論点の窃取(先取)に似ているものに 多問の誤謬 があります。 「はい」か「いいえ」で答えるクローズド・クエスチョン形式の質問で、見かけはひとつでも、本来個別に回答されるべきふたつ以上の質問を含んでいるものを指します(図9-7)。 質問者は自分に都合のいい質問への回答として対応できるため、回答者には厄介な質問です。 図9-7 多問の誤謬 論点相違の誤謬 結論を導くのには本来不適切だったり不十分だったりすることや、結論には関係のないことを、前提や根拠にしてしまう誤りです。 ひとことで言えば「的外れ」「筋違い」「そんなことは言っていない」なのですが、昔から見られる誤りでもあるらしく、こうした誤りに陥る（または、用いる）例は跡を絶たないようです。 この類の誤謬には仲間が大勢います。 図9-8 論点相違の誤謬 不純動機 。 主張の内容を論じるのではなく、 発言の動機 を取り上げて、反論したり擁護したりする誤り。 人に訴える論証(対人論証) 。 主張の内容を論じるのではなく、 発言者の人となり、性格や地位などの属性、個人的な事情など を取り上げて、支持や反論をする誤り。 （例：「正直な人の提案は優れている。Aさんは正直な人だ。だからAさんの提案は優れている」） 衆人に訴える論証 。 主張の内容を論じるのではなく、 強い感情的な言葉を用いて聴衆の熱狂や感情を刺激 し、誘導しようとする誤り。 仲間に「威力に訴える論証(脅迫論証)」や「憐みに訴える論証」「笑いや嘲笑に訴える論証」などがあります。 無知に訴える論証(未知論証) 。 論点の真偽が立証されていないことを根拠に結論を主張する誤り。 （例：「バグが残存していることは証明されていないから、もうバグはない」） （ISTQBを教えてあげましょう） 権威に訴える論証(権威論証) 。 主張の内容を論じるのではなく、 発言者の権威や、伝統などを根拠に 正当性を主張する誤り。 （例：当該分野の権威であるというだけの理由で、当人の当該専門分野における主張はすべて正しいと主張する） （例：ある分野で権威である人なら、専門外の分野での主張も正しいと受け入れる） 藁人形論法 ( ストローマン論法 。ダミー論証とも)。 元の主張を 単純化・拡大解釈などで論旨を歪曲したり、異なる主張にすり替えたり して「元の主張とは異なる主張」を作り出し、これに反論したり否定したりする誤り。 （例：「テストの自動化はテストチームのモラルを下げるからダメだよ。公然と手抜きができてしまうし、人の目が行き届かなくなるのだからね」） 燻製ニシンの誤謬 。 元の主張の 本来の論点に対して取るに足りない事柄を論点にし 、聞き手の注意・関心を本来の論点から逸らそうとする誤り。 （例：「スケジュールがきついって？　時間はたっぷりあるけどバグがモグラ叩き状態のプロジェクトの方がいい？」） 前提の誤謬 推論の前提自体に混入してくる誤りです。（この分類は本記事独自の分類です） 推論の形が妥当である場合、この類の誤りが混入していても形としては正しく見えてしまいがちです。 図9-9 前提の誤謬 誤った二分法 。 主張の前提となる事実や状況の認識・理解を過度に単純化し、選択肢は提示されるものだけに限られると考えてしまう誤り。 （選択肢がふたつより多い場合も含む） （例：「テスト結果の問題か、実装成果物の問題か、どちらかだ。テストは10回中10回の再現を確認しているのだから、実装成果物に問題がある」） 偶然の誤謬 。 一般性や普遍性を欠いている（特定の条件や例外的な条件の下で成り立つ）事柄を前提としてしまう誤り。 （例：「インスペクションは欠陥検出効果が高い。前のプロジェクトで採用したらその通りだった。このプロジェクトでもインスペクションを採用しよう」） 因果関係の誤謬 前提から結論に至る原因と結果の関係を混同したり、勘違いしたり、考え違いしたりする誤りです。 （本節の各誤謬は『誤謬論入門』(文末参考文献参照)を参考にしています） 図9-10 因果関係の誤謬 起こった事象から因果関係を考える、というのは、ソフトウェアテストやソフトウェア品質保証の仕事（欠陥分析や原因分析）、またデバッグ作業ではつきものです。 これらの誤謬に「してやられた！」とならないように気をつけてください。 因果関係の過剰な単純化。 ある結果を引き起こす原因となる要因の数や種類、結果に至るまでの過程などを 十分調べずに 「Aが原因でBが起こった」と単純化する誤り。 前後即因果の誤謬。 「事象Aの後に事象Bが生じた」という時間的前後関係だけを見て、「Aが原因でBが起こった」と思ってしまう誤り。 「故障が発生し(A)、その後にソフトウェアが暴走した(B)」としても、時系列の前後は必ずしも因果関係を意味しません。 原因と結果の混同。 時系列や事象のインパクトなどにつられて、原因と結果を取り違える誤り。 「故障が発生し(A)、その後にソフトウェアが暴走した(B)」事例では、Bが原因でAが起こったのかも知れません。 共通する原因の無視。 ふたつ(以上)の事象や状態について、共通する原因が引き起こした結果である可能性を見落とす（そして、それら事象の間に因果関係を求めてしまう）誤り。 関連がありそうなものごとを見ると関連がありそうに思えてしまいがちですが、 「故障が発生し(A)、その後にソフトウェアが暴走した(B)」事例では、A, Bに共通する別の原因があるかも知れません。 “ならば”(条件法)の前件と後件に関する誤りについては「形式面の誤謬」で説明しましたが、 必要条件 と 十分条件 も間違えがちです。 ということは、落とし穴になりやすいということです。 図9-11 必要条件と十分条件 必要条件と十分条件の混同 必要条件と十分条件を取り違える。 P だけ が結果Qの原因だと思ってしまう。あるいは、 Pを満たしていないのに結果Qが起こる筈はないと思ってしまう （P以外にもQの原因になるものはあり得る）。　など 両刀論法に対峙する 誤謬そのものではありませんが、 内容が偽であっても形式上は妥当な主張 を作りやすい 両刀論法 に出くわした時の対処方法を紹介します。 前提2で提示される選言肢のそれぞれを「角」と見なして、大きくふたつの対処法があります。 「角」に突かれないように、「角」から逃れる 「角」に突かれないように、「角」を捉える 「角」から逃れる 前提2の選言判断に不備を見つけて反論する考え方です（“二者択一”とは限らない、など）。 選言肢不完全の誤謬 を突く方法と言えます。 「角と角の間に避ける」、「角の間をすり抜ける」などとも呼ばれます。 図9-12 両刀論法の「角」から逃れる 図9-13 両刀論法の「角」から逃れる・例 「角」を捉える 前提1の仮言判断に不備を見つけて、それを手がかりに反論する考え方です（ 論点相違の誤謬 を犯している、など）。 仮言判断の瑕(きず) を突く方法といえます。 図9-14 両刀論法の「角」を捉える 図9-15 両刀論法の「角」を捉える・例 [実践編]むすび 「テストエンジニアのための論理スキル[実践編]」は、今回で終わりです。 [ 入門編 ]で紹介した 論理の言葉 が、実際の推論でどんな風に用いられるか、といったことを中心に、基本的な推論の形と、推論の組み立てにおいて気をつけるべきことを見てきました。 みなさんの論理スキルに対する意識を高めるお役に立てたなら幸いです。 なお、「実際の文や発言で、論理の言葉になる語句や言い回しにはどんなものがあるか」を、 筆者のnote で紹介しています。 そちらもぜひご覧になってみてください。 わかっちゃいるけどやめられない？　論理の言葉・実際編(仮) (T3:Pt1:Ch04)｜mottie (nob_mottie) 「論理の言葉」は、実際にはさまざまな語句・言い回しの形で現れるよ、というお話です。 論理の言葉は、難しい？ 論理スキルやで取り上げている「論理の言葉」ですが、「かつ」だの「および」だの「または」だのの語句が「教科書的」に感じる人、実際にはどんな... 　詳細はこちら　 note（ノート） 関連情報 参考文献 近藤洋逸, 好並英司 『論理学』 岩波書店 1979 藤野登 『論理学　伝統的形式論理学』 内田老鶴圃 1968 鈴木美佐子 『論理的思考の技法Ⅱ』 法学書院 2008 T・エドワード・デイマー(著), 小西卓三(監訳), 今村真由子(訳) 『誤謬論入門　優れた議論の実践ガイド』 九夏社 2023 図版に使用した画像の出典 Loose Drawing 人物画をお借りしています。 テストエンジニアのための論理スキル[実践編]  連載一覧 論理のかたち。推論とは  【連載初回、全文公開中】 基本的な推論形式 “または”を使って推論する “ならば”を使って推論する “ならば”と“または”で推論する ソクラテスは電気羊の夢を見るか？ (前編) ソクラテスは電気羊の夢を見るか？ (後編) 気をつけたい落とし穴(前編・形式面) 【最終回】気をつけたい落とし穴(後編・非形式面) The post 【最終回】気をつけたい落とし穴(後編・非形式面)｜テストエンジニアのための論理スキル［実践編］ first appeared on Sqripts .

こんにちは。kobaです。 Windows向けアプリのテスト自動化の業務をしていた際に、rbenvを使用してRuby環境を構築し、プロジェクトごとにバージョンを切り替えていました。しかし、開発環境のバージョンアップやパッケージの依存関係によるエラーの発生など、環境構築が手間に感じることがありました。 そこで、WSL2を利用したLinux環境の構築と、Dockerを利用したRuby環境の構築を実践してみました。 本記事で紹介する環境構築手順のメリット 迅速なセットアップ : WSL2とDockerを活用することで、Windows上でLinuxと多言語の開発環境やサーバーを迅速に構築できます。 再現性のある環境 : Dockerを利用することで、どのマシンでも同じ開発環境を再現でき、依存関係や環境の違いによる問題を回避できます。 開発効率の向上 : VSCodeとWSL2の連携により、Windowsの利便性を保ちながらLinuxの強力な開発ツールを利用できます。 自動化の可能性 : DockerとDocker Composeを使用することで、開発環境の構築やテストの実行を自動化し、手作業を減らせます。 柔軟な環境管理 : DockerfileとDocker Composeを使えば、プロジェクトごとに異なるバージョンや設定を簡単に管理できます。 概要 本記事で紹介する方法を使うことで、開発環境の構築が大幅に簡素化され、再現性のある環境を作ることができます。また、Dockerを利用することで、依存関係や環境の違いに悩まされることなく、どのマシンでも同じ環境を再現することができます。 今回紹介した例以外にも、他言語の開発やサーバー構築など様々な用途で活用できると思いますので、一例として開発環境構築の際の参考になればと思います。 Linux環境構築 WSL2のインストール WSL2（Windows Subsystem for Linux 2）は、Windows 10およびWindows 11でLinux環境を実行できる機能です。WSL2は実際のLinuxカーネルを使用しており、開発者はWindows上でLinuxツールやアプリケーションをシームレスに利用でき、特にDockerなどのコンテナ技術の利用が容易になります。 こちら の手順を参考にWSL2をインストールします。  WSL のインストール コマンド wsl --install を使用して Linux 用 Windows サブシステムをインストールします。 Windows コンピューター上で、好みの Linux ディストリビューションによって実行される Bash ターミナルを使用します。Ubuntu、Debian、SUSE、Kali、Fedora、Pengwin、Alpin... 　詳細はこちら　 learn.microsoft.com 関連情報 PowerShellで以下のコマンドを実行します。（※Windows 10 バージョン2004 以上 (ビルド19041以上) またはWindows 11を実行している必要があります。） wsl --install インストールが完了したらPCを再起動します。再起動後、Ubuntuが自動でインストールされます。   ユーザー名とパスワードの入力を求められるので、任意のユーザ名とパスワードを入力します。 VSCodeのインストール エディターとして VSCode（Visual Studio Code） をインストールします。インストール後、必要な 拡張機能を追加 します。   VSCodeはデバッグやコードの可読性を向上させる拡張機能を追加することができ、 自分で開発しやすい環境にカスタマイズできます。今回は必要最低限の拡張機能のみご紹介します。 WSL（WSL拡張機能）   WSL拡張機能と併用することで、WSLをフルタイムの開発環境としてVSCodeから直接使用できます。 Japanese Language Pack（VSCodeの日本語化）   VSCodeはデフォルトで表示言語が英語になっていますが、この拡張機能を追加することで日本語表記のUIに変更することができます。 Ubuntuの初期設定 VSCodeからUbuntuに接続します。   画面左下の青色のリモート接続アイコンをクリックします。   画面上部のリモートウィンドウから「WSLへの接続」を選択します。   リモート接続アイコンの横に「WSL:Ubuntu」が表示されていればUbuntuに接続完了です。   ターミナルを開いてUbuntuの初期設定をおこないます。 ターミナルはタスクバーの「ターミナル＞新しいターミナル」から開くことができます。   パッケージの更新とアップグレードを実施します。 sudo apt update && sudo apt upgrade 日本語環境の設定をおこないます。 sudo apt install -y language-pack-ja sudo update-locale LANG=ja_JP.UTF-8 PowserShellからWSLを再起動します。 wsl --shutdown Dockerのインストール インストールするDockerについて WindowsでDockerを利用する場合、    Docker Desktop for Windows：WindowsにDockerをインストールする Docker Engine：WSL2上のUbuntuにDockerをインストールする の2種類から利用できます。   今回は WSL2上のUbuntuにインストールする Docker Engine を使用します。 インストール手順 Docker Engineインストール  ドキュメント に記載している手順を参考にDockerのインストールを進めていきます。 インストールにはいくつかの方法が用意されていますが、今回は 便利スクリプトを使ったインストール の手順で構築を進めていきます。 Ubuntuのターミナルから以下のコマンドを実行します。 curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh ユーザーを docker グループに追加します。 sudo usermod -aG docker $USER systemdを有効にする DockerのサービスをUbuntuの起動後に常駐させるために systemdを有効にする 必要があります。 Ubuntuのターミナルから wsl.conf を作成して開きます。 sudo vi /etc/wsl.conf 次の行を追加します。 [boot] systemd=true エディターを保存して終了後、PowerShellからWSLを再起動します。 wsl --shutdown Ubuntuのターミナルを開き、以下のDockerコマンドが実行できるか確認します。 docker run hello-world 以下の赤枠のメッセージが表示されていれば、Dockerのインストールは完了です。   DockerでRuby環境を構築 ここからはインストールしたDockerを利用してRuby環境を準備します。 Dockerfile作成 DockerfileはDockerイメージの作成手順を定義するファイルです。 sample_dir ディレクトリを作成し、その中に Dockerfile を作成します。 # ベースイメージ FROM ruby:3.2.3 # コンテナ内の作業ディレクトリを指定 WORKDIR /app/project # ローカルマシンの./sample_dirの内容をコンテナ内の/app/projectディレクトリにコピー COPY ./sample_dir /app/project # コンテナが起動した際にデフォルトで実行されるコマンドを指定 CMD ["/bin/bash"] Dockerコマンド 作成したDockerfileをもとにDockerイメージを作成し、コンテナを起動します。 以下のコマンドを実行します。 docker build -t sample/ruby . docker run -it --name ruby sample/ruby Ruby環境のコンテナが作成され、ローカルのRubyファイルもコンテナ内の指定したディレクトリにコピーされていることも確認できました。 ruby環境は exit コマンドで抜けることができます。 活用例 ここからは活用例ということで、実際にCucumberを利用した自動テスト開発環境の準備をしていきます。 Gemfile作成 任意の場所に sample_dir ディレクトリを作成し、 Gemfile を以下の内容で作成します。 source "https://rubygems.org" gem 'cucumber' gem 'rspec' Dockerfile作成 sample_dir 内に Dockerfile を作成し、以下の内容を記述します。 FROM ruby:3.2.3 WORKDIR /app/project COPY . /app/project # ライブラリをインストールするコマンドを実行 RUN bundle config --local set path 'vender/bundle' \     && bundle install CMD ["/bin/bash"] 先ほど紹介した Dockerコマンド で起動することもできますが、 今度は Docker Compose を利用します。 docker-compose.yml作成 Dockerfileと同階層に docker-compose.yml を以下の内容で作成します。   services: cucumber:     build: .     environment:       TZ: Asia/Tokyo     volumes:       - .:/app/project volumes: の指定で、ローカルにあるファイルをコンテナ内の指定したディレクトリに同期します。 ローカルファイルを更新するとコンテナ内のファイルも更新されます。 docker composeコマンド実行 docker compose のコマンドを実行します。 docker compose run --rm cucumber オプション --rm の指定で、コンテナの終了時にコンテナを自動削除します。 Cucumberの初期設定 Ruby環境のコンテナ内でCucumberの初期設定を行うコマンドを実行します。 bundle exec cucumber --init コマンドを実行するとCucumberで必要なディレクトリが生成されます。 features ディレクトリ features/step_definitions ディレクトリ features/support ディレクトリ /env.rbファイル 今回はCucumberの チュートリアル を元に実装します。 features/is_it_friday_yet.feature ファイルを作成し、以下の内容を記述します。 Feature: Is it Friday yet?   Everybody wants to know when it's Friday   Scenario Outline: Today is or is not Friday     Given today is "<day>"     When I ask whether it's Friday yet     Then I should be told "<answer>"   Examples:     | day            | answer |     | Friday         | TGIF   |     | Sunday         | Nope   |     | anything else! | Nope   | 次に、 features/step_definitions/stepdefs.rb ファイルを作成し、以下の内容を記述します。 module FridayStepHelper   def is_it_friday(day)     if day == 'Friday'       'TGIF'     else       'Nope'     end     end end World FridayStepHelper Given("today is {string}") do |given_day|   @today = given_day end When("I ask whether it's Friday yet") do   @actual_answer = is_it_friday(@today) end Then("I should be told {string}") do |expected_answer|   expect(@actual_answer).to eq(expected_answer) end テストの実行 コンテナ内のruby環境で cucumber コマンドを実行すると、ドキュメントに載っているような結果が出力できます。 新規実装の例のため、コンテナ内で実行コマンドを叩きましたが、ある程度実装が進んでいる場合、Dockerfileの CMD に cucumber コマンドを記載することで、Docker コンテナ起動時にテストが実行され、結果を表示するところまで進めることができます。 FROM ruby:3.2.3 WORKDIR /app/project COPY . /app/project RUN bundle config --local set path 'vender/bundle' \     && bundle install # cucumberコマンドを実行する CMD ["cucumber"] これで docker コマンドを実行すると、 コンテナ起動＞テスト実行＞結果出力＞コンテナ削除 まで1コマンドで実行できます。 また、 docker-compose.yml でファイルを同期する設定にしているので、ローカルでコード修正後にdockerコマンドを実行すると、修正したコードで実行結果をすぐに確認でき、効率的に開発を進められます。 最後に 今回は、Windows上でWSL2を利用してLinux環境を構築し、その上にDockerを使ってRuby環境を整える手順を解説しました。これにより、開発環境のセットアップを迅速かつ効率的に行う方法を学びました。 この基礎を活かして、さらなる自動化や効率化を図ることができます。例えば、CI/CDパイプラインに組み込んで自動テストを行うことで、開発プロセス全体の品質とスピードを向上させることができます。また、他の開発言語やフレームワークにも応用できるため、幅広いプロジェクトで役立てることができます。 環境構築を行えることで様々な対応への汎用性が上がるので、ぜひ、この記事を参考にして、自分の開発環境を構築・改善してみてください。 参考 Windows Subsystem for Linuxに関するドキュメント WSLを使用してWindowsにLinuxをインストールする方法 systemdを使用してWSLでLinuxサービスを管理する docker docs   Docker Engine 概要 Ubuntuでのインストール（便利スクリプトを使ったインストール） Dockerfile記述のベストプラクティス Docker Composeの概要 Compose仕様 Dockerコマンドラインの利用   docker compose Cucumber Introduction 10 Minute Tutoria The post WindowsでLinuxとRuby環境を最短手順で構築してみた first appeared on Sqripts .

この連載では、1人目QAとしてのチームの立ち上げ、組織づくりに関して、私が実践したことや試行錯誤中のことも含めてお伝えします。 前回の記事 ではQA組織立ち上げの流れや組織の形について解説しました。 【第1回】QA組織立ち上げの流れと組織の形 以前の連載である1人目QAとしての立ち回りでは、会社や開発組織の1人目QAになった人がどのような活動をするのかや、品質保証を浸透させる際のアプローチなどについて触れました。今回の連載では1人目QAとしてチームを立ち上げていく部分、組織づくりに関して、私が実... 　続きを読む　 Sqripts 関連記事｜Sqripts 今回は2人目以降のQAエンジニアを採用する際に私が考えたポイント等についてご紹介します。 私が所属している部署ではQAエンジニアの採用を行っており、現在は2名体制で動いています。現時点では「10名、20名とどんどん拡大！」という状態ではないため、すでに大きな体制を構築している会社さんとはフェーズが異なるという前提でお読みください。現職のQA組織は小規模ですが、前職で採用含めてチームを作った経験もあるため、そこで得た知見とあわせてお伝えします。 これから2人目以降のQAを採用しようとしている会社さんや採用に関わっている1人目QAの方にとって、何かヒントになれば幸いです。 2人目の採用にあたって考えたこと 私は今の会社に入るにあたり、「QAチームを作るところもやってほしい」と言われていました。開発組織の規模を考えても、また部署で唯一のQAである自分が病気等で離脱する可能性などを考えても、チーム化するというのは自然な流れだったと思います。 そのため、入社直後から2人目のQAエンジニアの採用活動もスタートしたわけですが、採用にあたってはただ求人を出せばいいわけではありません。 現状の開発組織において、どのような形で品質保証をしていきたいのか そのためにはどのような体制にしたいのか どのようなスキル・経験を求めるのか などを整理し、それに応じた募集文面や媒体の選定などが必要です。 現状の開発組織での品質保証の形や体制などは、組織のこと・開発プロセスのことを把握していない段階で決めることは困難です。この時点ではあくまでも方向性程度で問題ありません。社内には「QAを採用したい！」と思った主な人物（開発部長やCTOなど）がいるはずなので、その方と相談をしつつ、ある程度「こうあるべきではないか」という仮説を設定する、くらいのニュアンスです。 そして 前回の記事 に書いたようなヒントをたよりに、体制や開発チームとの関わり方を決めていきます。このとき、いきなり理想の体制にはならないことにも注意が必要です。 たとえば開発チームが複数ある組織で、かつ理想として「各開発チームに担当のQAが1人ずつ付く形にしたい」と考えたとします。開発チームが5つあったとしたら、いきなりQAを5人採用するのは難しいですよね。 この場合、最初は開発チームの外から支援するタイプのQA組織として立ち上げて、QAエンジニアの採用が進んだら担当制に変えよう、といった中長期的なプランを描くことになります。 QAエンジニアのタイプについて考える 2人目以降のQAエンジニアとしてどのような人を採用する際にもう一つ、私はよく「QAエンジニアのタイプ」で考えます。 ここで言うタイプ、というのは特定の定義を指しているわけではありません。QAエンジニアの分類の仕方を総称して、タイプ、と表現しています。 たとえば、過去の連載でも何度か触れた「 QMファンネル 」で言うところのスペシャリティもタイプといえるでしょう。QMファンネルとは、テストエンジニアとSETとQAを整理してバランスをよくするためのものです。 テストに強みがあるのか 自動テストや開発スキルに強みがあるのか スクラムマスターやマネージャーなどの方面から組織にアプローチするのが得意なのか など、その人の得意分野で分けるというのが一つの方法です。 他に、私が個人的に使っているタイプとして、志向で分けるというものがあります。 QAエンジニアは、大きく以下2つの志向性があるのではないかと考えています。 ①組織・プロセス志向 ②プロダクト志向 もちろんこれはあくまでも一例なので、ご自身で考えていただいても大丈夫です。 このタイプわけを使って、2人目およびそれ以降のQAエンジニア採用を考えます。 作戦：同じタイプで攻める 1人目のQAと同じタイプを2人目として採用する作戦です。大まかに以下のような特徴があります。 メリット 二人のタイプや志向性がそろうので意見が一致しやすく、物事が進みやすい 詳しい人同士での議論や意見交換ができる デメリット 対応できる業務や課題の範囲が狭くなる たとえば、QMファンネルのPE：パイプラインエンジニアとしてのスペシャリティを持った人が1人目のQAをしている組織に、同じPE方面が得意な2人目が加わった、とします。この場合は、自動テストやそのインフラ整備はスムーズに進むでしょう。しかし、もしかすると開発プロセスやテストプロセスの改善、利用時品質の向上などの施策は進みづらいかもしれません。中には複数のスペシャリティを持ったスーパーQAエンジニアもいますが、そのような方が採用できるのはレアケースでしょう。 解決したい課題が明確な場合は、この同タイプ作戦で課題に特化したスキルを持つQAに絞って採用するのも一つの手です。 作戦：別タイプで攻める 上記とは反対に、1人目QAとは異なるタイプを2人目として採用する作戦もあります。個人的にはこちらのほうが一般的だと感じています。 メリット 得意分野が異なるので、組織の幅広い課題に対応できる デメリット それぞれのスキルによっては、相互に相談がしづらい 個々の施策においてはスピード感が出づらい 1人目QA、私も1年半ほど続けてみて感じたのですが、「相談・議論相手がほしいなぁ」と思うことが多々あります。先の例で言えば、PE同士であれば自動テストの高度な話を議論できるかもしれません。しかしタイプが異なるとそれぞれ詳しい範囲も違うので、会話にはなれども、議論のレベルに至らない場合もあります。 このように、とくに2人目のQAを採用していよいよチーム・組織化を、という場合にはタイプを考えて検討をすることが大切です。 現実問題：採用できた人の活かし方を考える タイプで考えましょうと言っておきながら覆すようですが、「採用できた人の活かし方を考える」ほうが現実的な場合も多いでしょう。 今はQAエンジニアの採用、とくにチームの立ち上げに関われるようなリーダー・マネージャクラスの採用は難しいと言われています。そのため、「タイプが違うから見送り」としてしまうのはもったいない場面もあります。 募集要項自体はある程度幅を持たせて出したうえで、採用候補者のスキルや特徴を活かす方向で業務内容を調整するのが現実的です。面接で候補者の方から「どのような人を求めていますか？」と聞かれることもありますが、主体的に動けることや整っていない道を進める人というポイント以外、スキルやスペシャリティに関しては「お持ちのスキルを活かせる業務を一緒に考えましょう」とお答えしています。 2人目の先で考慮する点 前述の通り、私は現在2名体制のチームにいます。ただ、前職などでチームを立ち上げた際には3人目、4人目と拡大していった経験があり、この段階で大事だと感じたポイントがありました。 それは 「物申せる人」をチームに加える ということです。 リーダーになってメンバーを募るときのリスク 1人目QAとして、ある程度経験のある人を採用できた、とします。そしてその後、たとえば1人目に比べると経験が浅い若手メンバーが2人目3人目とJoinして・・・という形でチームができあがっていくこともあるでしょう。 このようなシチュエーションでは、誰のせいでもなく、メンバーがイエスマンになってしまう可能性があります。 当然ながら、1人目のQAが最も社歴が長く、内部の情報という点では一番多く持っています。これに加えて、QAとしても経験も豊富となると、1人目が全部一番詳しい状態のはずです。そうなると、2人目以降で入ったメンバーとしては「1人目の＊＊さんが言っているんだから間違いないだろう」という、良く言えば信頼、悪いく言えば無意識の甘えが出てきます。 1人目QAの意見が全部通ったり、必要以上に発言に重みが出てしまったりすると、チームとして間違った方向に進んでしまう可能性があります。繰り返しになりますが、誰にも悪意がなくともそうなる危険があります。 また、1人目QAの側もすべてを知っているわけではありません。いろいろな取り組みをする中で、「これでいいのだろうか」や「誰かに相談したい」と思うこともあります。そのようなときに、メンバーが「＊＊さんが言うならそれで！」という態度を取り続けてしまうと、1人目QAにとってはチームで仕事をしているのに孤独を感じる状況になることも。 これらの問題を防ぐために必要なのが、「物申せる人」です。 もちろん、なんでもかんでも反対するのはダメです。しかし、1人目QAとして組織を立ち上げている人に対してでも「そこは違うと思う」「もっとこうしたほうがいいと思う」といった意見を言える人、対等に意見を言い合える人が必要です。 物申せる人にもいくつかありますが、 1人目QAと同じくらいのキャリア・経験がある方 経験は浅いが、（相手を尊重したうえで）意見が言える人 など、どのようなパターンでもよいでしょう。 個人的感覚では、4, 5名のチームになったころにはこうした「物申せる人」を入れたくなります。 まとめ：志向性などQAのタイプでほしい人材や組織の形を描きましょう 今回は2人目とそれ以降のQAエンジニアを採用する際に考えるポイントについて、いくつかご紹介しました。 ここで挙げたものがすべてではありません。しかし、QAエンジニアの職務の幅が広がっている今、単純に「QA募集」ではミスマッチが起こりやすいように感じています。 QAチームを構成するメンバーのスキルや志向性などをどの程度そろえて、もしくはバランスよく分けていくのか等を考えることで、求める人材が具体化できたり、採用のミスマッチが減らせたりといった効果が期待できます。 QAエンジニアの採用をされる場合は、ぜひ参考にしてみてください。 【第1回】QA組織立ち上げの流れと組織の形 以前の連載である1人目QAとしての立ち回りでは、会社や開発組織の1人目QAになった人がどのような活動をするのかや、品質保証を浸透させる際のアプローチなどについて触れました。今回の連載では1人目QAとしてチームを立ち上げていく部分、組織づくりに関して、私が実... 　続きを読む　 Sqripts 関連記事｜Sqripts The post 【第2回】2人目以降のQAエンジニアの採用 first appeared on Sqripts .

こんにちは！フロントエンドエンジニアのつかじです。 今回は、私たちの開発チームで導入した「 Vercelのv0 Teamプラン 」について、その魅力や実際に使ってみて感じた効果、そして活用方法を詳しくご紹介します。 v0とは？ まず、 v0 についてご存知ない方のために簡単に説明します。v0は、Vercelが提供する AIを活用したUI自動生成ツール です。自然言語での入力から直感的にUIを生成し、 React、Svelte、Vue、そしてHTML+CSS として出力することができます。 v0の主な特徴 自然言語によるUI生成 ：テキストでの指示から、即座にUIコンポーネントを生成。 複数のデザインバリエーション ：同じ指示から複数のデザインを提案し、最適なものを選択可能。 React/Next.jsとの高い互換性 ：生成されたコードは即座にプロジェクトに統合可能。 カスタマイズの容易さ ：生成後のコードを自由に編集・調整できる。 v0 Teamプランとは？ 次に、 v0 Teamプラン について詳しく見ていきましょう。v0 Teamプランは、2024年10月15日に発表された、チーム全体でv0の機能を効率的に活用できるように設計されたプランです。詳しくは こちら をご覧ください。 ■ v0 plans for teams are here 主な特徴 チームメンバーとの共有 ：生成したコンポーネントやプロジェクトをチーム内で共有可能。 クレジットの集約管理 ：チーム全体でクレジットを共有し、効率的に利用。 カスタム指示の設定 ：チーム全体で共通のカスタム指示を設定し、一貫性のある開発が可能。 導入の経緯 私たちの開発チームでは、プロトタイピングの効率化とデザインの一貫性を図るためのツールを探していました。そこで目を付けたのが、AIを活用してUIを自動生成できる v0 でした。個人での試用期間を経て、その有用性を実感し、チーム全体で活用するために v0 Teamプラン の導入を決定しました。 実際に使ってみて感じた効果 1. プロトタイピングの高速化 自然言語での指示から即座にUIを生成できるため、プロトタイピングに要する時間が大幅に短縮されました。 迅速なデザイン提案 ：アイデアをすぐに形にし、チーム内で共有。 複数案の比較検討 ：異なるデザインバリエーションを簡単に生成し、最適なものを選択。 2. コードの統一性と品質向上 生成されるコードは、 Tailwind CSS や shadcn/ui といったモダンな技術スタックを基盤としており、コードの品質と統一性が向上しました。 一貫したスタイリング ：チーム全体で同じスタイルガイドに基づいた開発が可能。 可読性の高いコード ：メンテナンス性が向上し、後続の開発がスムーズに。 3. カスタム指示による開発効率の飛躍的向上 v0 Teamプランの大きな魅力の一つが、 カスタム指示 を活用できる点です。 カスタム指示とは、v0に対してプロジェクト固有の要件やガイドラインを設定できる機能です。これにより、AIがUIを生成する際に、チーム独自のルールやベストプラクティスを考慮することができます。v0 Teamプランでは、このカスタム指示機能を活用することで、以下のような効果を実感しました。 チーム知識の集約 ：v0のプロジェクトごとにカスタム指示を設定することで、チームメンバー全員が同じ指示を基に開発できます。個々の知見が埋もれたり忘れ去られたりすることなく、チーム全体で共有・活用できます。 独自資料の活用 ：プロジェクトに独自のアーキテクチャ手法、スタイルガイド、ドキュメントをソースとして追加できます。これにより、v0はチーム特有の情報を参照しながら、より適切なUIを生成します。 多様なドキュメント形式のサポート ：PDF、TXT、コードファイルなどのドキュメントをソースとして追加可能で、プロジェクトに合わせたカスタムな生成が期待できます。 具体的には、よく使うコンポーネントやデザインパターンをカスタム指示として登録し、必要なときにすぐに呼び出せるようになりました。これにより、新機能の実装やページ追加時にも、一貫性のあるデザインと効率的な開発が可能となりました。 例えば、カスタム指示として「UIライブラリにはMantineを利用」と記載した instruction.txt を追加すると、 アプリケーション生成の指示を出す際に、特にChatで指示をしなくても、Mantineライブラリを利用してコードを生成してくれます。 また、カスタム指示はチーム内で共有・更新が可能なため、プロジェクトの進行に伴って指示内容を改善・拡充することができます。これにより、常に最新の開発手法やデザイントレンドを取り入れたUIを提供できるようになりました。 まとめ Vercelの v0 Teamプラン を導入したことで、チームの開発効率やコラボレーションが飛躍的に向上しました。AIを活用したUI自動生成により、プロトタイピングがスピードアップし、デザインの一貫性も確保できます。フロントエンド開発において、新しいツールや技術を積極的に取り入れたいチームには、v0 Teamプランは非常におすすめです。 The post 最近話題のVercel v0 Teamプランを導入してみた！その効果と活用方法を紹介 first appeared on Sqripts .

ソフトウェア開発の世界では、アジャイル開発やスクラムが一般的になってきました。そのアジャイル開発のコアとも言えるのが、対話や協調です。この連載では、アジャイル開発におけるコミュニケーション・コラボレーションスキルを解説しながら、ファシリテーションスキルのレベルアップを目指します。 ＜スクラムマスターのためのコミュニケーション講座　連載一覧＞ ※クリックで開きます ・ #イントロダクション：優れたスクラムマスターが絶対に言わないこと 【連載初回、全文公開中】 ・ あなたの提案はなぜ受け入れられないのか？｜ファシリテーション技術-1- ・ よりよい場を作るための9つのルール［前編］｜ファシリテーション技術 -2- ・ よりよい場を作るための9つのルール［後編］｜ファシリテーション技術 -3- ・ コーチング技術 〜 基本技術を学ぼう｜コーチング技術 -1- ・ コーチング技術 〜 質問力を高めよう｜コーチング技術 -2- ・ 上級者が活用する質問例｜コーチング技術 -3- ・ 実践1on1[1] 〜 簡単だけど難しい1on1 ・ 実践1on1[2] 〜 コミュニケーションの方法を使い分けよう！ ・ 実践1on1[3] 〜 相手に合わせたコミュニケーション方法とは？ 第11回目のテーマは、実例をつかった1on1のレベルアップです。 前回のおさらい 1on1について、対話、さまざまなコミュニケーション方法、相手に合わせた対応などを学んできました。 ここでは総仕上げとして、実践例をもとにさらなるレベルアップを目指していきます。1on1は解説しにくいテクニックですが、会話例を紹介するとともに、その裏側でどのような考え方や意図があったのかも解説していきます。 1on1は「特にないです」からが本当の勝負 上司　「最近、調子どう？」 部下　「普通です」 上司　「なにか話したいことありますか？」 部下　「特にないです」 この「特にないです」は、言葉の裏側がわかりにくい言葉のひとつです。本当にないのか、話しにくいのか、これだけでは全容が見えません。 こういう場合は、対話のきっかけをさがすといいでしょう。たとえば、相手に念を押すコミュニケーションを取るなら以下のようになります。 上司　「なにか話したいことありますか？」 部下　「特にないです」 上司　「 つまり、仕事がすべてうまくいっているということなんですね？ 」 この方法は悪くありませんが、相手によっては「煽られている」と感じるようなので、言い方には注意が必要です。 もう少し自然に深堀りするなら以下のような方法もあります。 上司　「なにか話したいことありますか？」 部下　「特にないです」 上司　「じゃ、質問させてもらうけど、 前回の1on1から今回の1on1までにあったNewなことはなんですか？ 」 仕事を淡々とこなすだけでは、成長するのが難しいはずです。単調な仕事ももちろんあるでしょうが、そのなかでNewなこと（新しい発見）がなかったかを確認する質問です。大抵の場合、Newなことはありますし、なければ「そのときどう考えたか？」を深掘れます。 1on1において「特にないです」ははじまりの合図です。ここからが勝負と考え、さまざまな切り口の質問を用意しておくとよいでしょう。 ネガティブなことを伝える 成長のために、乗り越えなければならない壁がある場合があります。特に人の欠点はなかなかなおらないことが多いでしょう。ほとんどの場合、人生が変わるぐらいの変化が起きない限り、人はそう簡単に変わらないものです。 上司と部下の関係において、相手の欠点やマイナスな部分をどう扱うかは悩ましいテーマです。サンドイッチ型のフィードバックのようなテクニックもありますが（ほめる ＞ ネガティブなことを伝える ＞ ほめる と、ポジティブな要素でネガティブをサンドイッチにして伝える作戦）、私の場合、小手先のテクニックで感情を操作されるのは好きではなく、できるだけ正直なコミュニケーションを取りたいので、ネガティブもポジティブも直接伝えるようにしています。もちろん、相手との関係性やタイミングは重要です。 上司　「チームからのフィードバックを見ていると、あなたのパフォーマンスがでていないと考えている人が多いみたいです（事実の提示）」 部下　「え、そうなんですか。知らなかったです。。。（ギャップの発見）」 上司　「具体的には、〜〜だったときのあなたの◯◯な反応を見て、チームの雰囲気が悪くなったそうですね（具体例を伝えて状況を明確にする）」 部下　「あぁ。。。たしかにそういう時がありました」 上司　「事実なんですね（事実の確認を行う）」 部下　「でも、あのときは〜〜だったので仕方ない部分がありました」 上司　「それはチームメンバーに伝えましたか？（何をして何をしていないかの確認）」 部下　「いえ。言えませんでした」 上司　「我々に今できることはなんでしょうか？（過去できなかったことではなく、今に標準を絞り、できることをアクションに落とし込む。部下だけでなく「我々」で解決することをしっかり伝える）」 部下　「そうですね。まず、当時の自分の状況を伝えてみようと思います。事実、雰囲気が悪くなったのは間違いないので、それについてはきちんとお詫びしようと思いました」 コミュニケーションの問題の多くは、ちょっとしたすれ違いによるものです。何が事実で何が事実でないのかを明確にしましょう。あくまで事実を元に会話を進め、関係性の中にあるギャップを見つけます。 なぜこのギャップが生まれたのか？ このギャップの意味はなんだろうか？ どうすればこのギャップが生まれなくなるのだろうか？ と深堀りしていきます。 個人とチーム アジャイルチームの場合、ほとんどの現場において「なぜこのチームが存在するのか」が明確にあるはずです。この「なぜ」はモチベーションの源泉になるため、チームのコアとなり、迷ったときの判断材料になります。 「デザイン部分の問題だから、デザイナーとフロントエンドメンバーの連携に課題があったのかな？」 「実作業はそうかもしれないけど、それをお互いに気がつけなかったことや、作業者以外のメンバーも気がつけなかったから、ここまで問題が大きくなってしまったんじゃないだろうか？」 「 我々はチームとして『自律したチーム』を目指していますよね 。自律したチームだったら、今回の問題はどう回避していたんですかね？」 個人の視点で詰まってしまったら、チームの視点で考えてみるのも手です。問題は誰かが持っているものではなく、みんなの前にあるものです。チームとしてどうするか考えるきっかけを作るために、上記のような質問が使えるでしょう。 1on1は誰のための時間か？ 部下　「◯◯さんのときはいつもこうなるんですよね。もちろん、彼だけの問題だとは思わないんですが、こちらでできることにも限界があるんで」 上司　「そうなんですね（言いたいことがたくさんありそうなのでもう少し聞こう）」 部下　「はい。前にも〜〜があったので、自分もサポートしたのですが、感謝の言葉もなく、それが当たり前みたいな態度なので、ついカッとなったことがあります」 上司　「なるほど。カッとなってしまったんですね（ネガティブなことも承認）」 部下　「さすがに我慢の限界が来ました。同じように思っている人多いんじゃないですかね」 上司　「言いたいことがたくさんありそうですね。ひとつ聞いてもいいですか？」 部下　「はい。なんでしょう？」 上司　「 1on1はあなたのための時間です。ずっと◯◯さんの話をしていますが問題ないですか？ 」 誰かを変えることはとても難しいものです。よって、一般的には「誰かを変えるのではなく、まず自分を変えよう」という考えが主流だと思います。 しかし、頭ではわかっていても、1on1の場でずっと誰かの話をする人は多いです。残念ですが、その場にいない人の話をしても、何かが好転することはありません（気持ちはすっきりするかもしれませんが）。また、本人のいないところで話されるネガティブな会話は、たいていの場合、本人に漏れます。相手に伝わった結果、また悪い結果につながり負の連鎖になってしまうわけです。 誰かの悪口を言ってしまうと、 あなた自身が問題になってしまいます。 我々はあくまで、「問題を解決する側」に回らなければなりません。あなた自身が問題になってはならないのです。 ＊ 今回は、いくつかの事例を交えて、1on1でのやりとりとその背景にある考え方をまとめてみました。こうやってみてみると、1on1で上司役になる人は、相手の言葉や反応に対して、さまざまな思いを巡らせ、相手の考えを深めるための質問を行っていきます。 1on1はテクニックだけでなく、実践経験も求められます。会話なので反応や反射も相手に合わせて行っていかなければなりません。 次回はいよいよ最終回。これまで学んできたことを更にアップグレードするためのトレーニング方法を解説します。腕を磨いて、コミュニケーションの達人を目指しましょう！ 連載一覧 ・ #イントロダクション：優れたスクラムマスターが絶対に言わないこと 【連載初回、全文公開中】 ・ あなたの提案はなぜ受け入れられないのか？｜ファシリテーション技術-1- ・ よりよい場を作るための9つのルール［前編］｜ファシリテーション技術 -2- ・ よりよい場を作るための9つのルール［後編］｜ファシリテーション技術 -3- ・ コーチング技術 〜 基本技術を学ぼう｜コーチング技術 -1- ・ コーチング技術 〜 質問力を高めよう｜コーチング技術 -2- ・ 上級者が活用する質問例｜コーチング技術 -3- ・ 実践1on1[1] 〜 簡単だけど難しい1on1 ・ 実践1on1[2] 〜 コミュニケーションの方法を使い分けよう！ ・ 実践1on1[3] 〜 相手に合わせたコミュニケーション方法とは？ The post 実践1on1[4] 〜 実例をもとに1on1をレベルアップ first appeared on Sqripts .

こんにちは。まーくー＆くまねこです。 ゆるっとシリーズ第7話です。[ 前回 ] から引き続き、まーくーの学び直し回です！ 書籍「基本から学ぶソフトウェアテスト」を読んで、現在でも活かせる内容があるのか？ くまねことの会話形式でお話しさせていただきます。 最後まで楽しんで読んでいただければ幸いです！ ゆるっと♪Blogシリーズの記事一覧はこちら（クリックで開きます） 第1話 ゆるっと♪ファームウェアテストよもやま話 第2話 ゆるっと♪学び直し！アジャイルソフトウェア開発技術者検定試験 第3話 ゆるっと♪どうやってる？探索的テストの世界！ 第4話 ゆるっと♪学び直し！ [書籍]基本から学ぶソフトウェアテスト！ 第5話 ゆるっと♪学び直し！[書籍] 基本から学ぶソフトウェアテスト！② 　　　 ～あきらめてしまわないでね 難しさ感じても～ 第6話 ゆるっと♪学び直し！[書籍] 基本から学ぶソフトウェアテスト！➂ 　　　 ～きっとそこに信じていた、バグ管理の姿があるはずさ♪～ 自己紹介 まーくー QA業界経験2x年のベテラン（おじさん）エンジニア。 月日が過ぎ去るスピードが速まってる気がする今日この頃。加えて、忘却のスピードも速まっている気が・・・覚えるスピードと忘れるスピードの果てしない戦いが続いている。。。 くまねこ QA業界経験1x年のエンジニア。 体重が増加するスピードが速まってる気がする今日この頃。食欲と体重の果てしない戦いが続いている。。。もぐもぐ。 イラストby くまねこ 今日も2人のやりとりをお楽しみください！ エンジニアである限り！学び直しの旅は続く… (*´Д｀) Sigh… （ JSTQB Advanced Level Test Manager(ALTM) の試験勉強に全然手がついて無いけど、そろそろ始めないとなぁ…） おつねこ！どうした中年？ため息なんてついちゃって！ あっ、まーくーさん！おつねこです！JSTQB ALTM試験の勉強時間を取りたくても、なかなか時間が取れなくて… （中年はスルーか ）業務しながらだと難しい部分はあるよね。でも世の中のソフトウェアは日々進化していくから、常に知識をアップデートして行かないといけない。エンジニアである限り学び直しの旅は続くのさ！（きっ、決まった！！！ ） （おぉぉ…なんだかわからないけど、悦に浸ってる～！何か、話をしよう…この勢いでいつものやっちゃおうかな？ALTM試験のプラスになるかもだし！ニヤニヤ） Great! では早速、今回は前回の続きで学び直ししていきましょー！書籍は我らが神の師匠が書いた本「 基本から学ぶソフトウェアテスト ]」。今日は第2部の第7章ですね！ Let’s Go！Come On↷ Yeah～！ \ /（訳：あれ？いつもと逆じゃない？？？） 第7章 テストケースの設計を読んで① 本章ではテストケースの設計について学べるとのこと…主にブラックボックステストを中心に書かれているね。章の冒頭にも書いてある通り、時間さえあればいくらでもテストケースを実行すれば良いけど、実際はそうはいかないよね。そこで、テストケースの設計（テスト設計）をしっかりしていこう、ということだね。 そうですね。テスト対象に対して、どのように効率よく、良いテストが行えるようになるのか、学び直しましょう！ OK！最初は「質の高いテストケースとは？」というところから記載されているね。やっぱり、無駄にケース数が多くなったり、目的から離れた意味のないケースを作ってしまうと時間も勿体ないし、良いテストにならないよね。 質の良いテストの特徴 優れたテストケースは以下の基準を満たしている。 ・不具合を検出できる可能性が高いこと ・重複がないこと ・最善であること ・単純すぎず、複雑すぎないこと ・検出の方法が明示してあること 基本から学ぶソフトウェアテスト より ここでのポイントを見ていくと、「単純すぎず難しすぎない・無駄を減らす」というところでドキュメント作成時のバランス感覚も大切だと感じました。基本は前述のポイントを踏まえるのですが、実際にテストを担当する人のレベルに応じて書き方を工夫していく必要もあると思います。 テスト経験が少ない方にざっくりとした内容のケースだとテストが進められないですし、熟練した方に対して記載が多すぎると読ませ過ぎで逆に効率が上がらないとか…見極めが大事ですね。 そして、効率よくテストケースを設計していくために「同値分割」「境界値分析」「状態遷移」などの技法も活用していくことが書かれています。この辺りは以下の記事からも学べるので、読み直しておきたいです。 テスト技法に関する/Sqripts記事（抜粋） ■同値分割　　 「同値分割法」を使ってみた ■境界値分析　 「境界値分析」をテスト設計に取り入れる ■状態遷移　　 ゆるっと♪ファームウェアテストよもやま話 　　　　　　　 幅広いソフトウェアとテストレベルで適用可能な状態遷移テスト 　　　　　　　　　　　　　　　　　　　　　　その他いっぱいあります なるほどね。私がこの中で面白いなと思ったのは、 “ 直感を信じる ” というところだね。「論理的に説明できないが」って言っちゃってるのが面白いし、経験的にも分かる話だよね。これ読んだ時、以前くまねこさんが突拍子も無いところから障害を検出していたことを思い出したよ。 Oh! Be a strange boy↺! まーくーさんと同じプロジェクトだった時ですね。仕事後の帰り道、白い街灯がとても優しかったですね…まーくーさんが「負けないで」って囁いているようで…懐かしいです（遠い目）。自分で言うのもなんですが、作成したテストの消化ペースに気を配りながら、条件を＋αしたり、色々とイマジネーションを働かせてテストするのが割と得意な気がします！ YES！きっとそこに信じていたくまねこさんのテストがあるはず！他にも気になるものはあったかい？ そうですね…「機能等価テスト」でしょうか。テストの名前としては聞き慣れていなかったですが、テスト対象を類似機能や他社製品の似た機能で比較するということのようですね。この手法ってテスト実施だけではなく、仕様検討のフェーズなどでも使えそうですよネッ☆ そうだネッ☆彡 第7章 テストケースの設計を読んで② テスト設計レビュー依頼？ 次は「回帰テスト」についてだね。この本では回帰テストを「修正がうまくいったかのテスト」と定義していて、目的として「バグが本当に修正されたかどうかをチェックする」「関連するバグを探す」「他の部分を確認する」の3つを挙げている。プログラムを守るために万全の備えが必要ってされているけど、回帰テストする時にくまねこさんが気を付けていることってあるかな？ Yes! そうですね、書籍に記載のポイントを踏まえつつ、開発メンバーとコミュニケーションが取れる時に影響範囲や気になっている部分をヒヤリングして、テスト内容に反映していきますね。 なるほどね。コミュニケーションも大切にしているんだね。開発メンバーからの情報も活かしてテストをすれば、より良い回帰テストにできそうだね。その他、本の中で気になっていることってあるかな？ 「回帰テストのためのテストライブラリ」のところですね。不具合を見つけたテストケースを全て回帰テストに組み込むと、次第に工数も膨らんでくるので、重複している部分の間引きやテストの組み合わせを適宜再検討するなどして、テストの最適化をしたいですね。さっき話した開発からの修正の原因・対策コメントも、ここでも参考になりますね。 回帰テストは「新たな障害が見つかる可能性がかなり小さい」から、効果を残しつつ工数を減らす工夫が大事だよね。減らした工数でスマートに仕事を終え、夜に繰り出す俺は寂しがり屋のキング！キンキンキン… キンキンキン…って・・・ King! まとめ 第7章も終わりだね。テストケース設計から回帰テスト、（ここでは触れなかった）テスト実施まで見てきたけど、どうだったかな？ 今までの経験で自然と身についていたこともありましたが、本章を読み直すことで改めて理解をすることができました。テスト初心者の方が本書を読みながらテストを行うのも良いですし、作業を教える立場の方は相手により理解してもらえるような表現ができるようになると思いました。あっ、まーくーさん！全15章のうち、半分ぐらい来ました！ Wow！結構進んだね！ （やばいそろそろJSTQB AL試験勉強も始めなきゃ…！） この調子で自分に負けたりせず、前進していかなければ…バーイ！ ﾉｼ 三 Yeeeeeeeeeeaaaaaaaaaah！ \ / （どうしよそろそろJSTQB AL試験勉強始めなきゃ…！） 次回予告 さて、今回はここまでにしようか。頭の中がJSTQBのALでいっぱいになってきたけど笑、次回はどんな感じかな？ 次回のまーくー＆くまねこは、 JSTQB ALTM試験、やばいよやばいよ！今度こそ受けるよ！（仮） JSTQB ALTM試験、どうしよどうしよ！（仮） の２本でーす！ 最後まで読んで頂き、ありがとうございました！よろしければ、過去のゆるっと♪シリーズもお楽しみください！次回もまた見てねー ﾉｼ 三 ﾉｼ 三 ゆるっと♪シリーズ 第1話 ゆるっと♪ファームウェアテストよもやま話 第2話 ゆるっと♪学び直し！アジャイルソフトウェア開発技術者検定試験 第3話 ゆるっと♪どうやってる？探索的テストの世界！ 第4話 ゆるっと♪学び直し！ [書籍]基本から学ぶソフトウェアテスト！ 第5話 ゆるっと♪学び直し！[書籍] 基本から学ぶソフトウェアテスト！② 　　　 ～あきらめてしまわないでね 難しさ感じても～ 第6話 ゆるっと♪学び直し！[書籍] 基本から学ぶソフトウェアテスト！➂ 　　　 ～きっとそこに信じていた、バグ管理の姿があるはずさ♪～ The post ゆるっと♪学び直し！[書籍] 基本から学ぶソフトウェアテスト！④～君がおしえてくれたテストの名前は～ first appeared on Sqripts .

近年のWindowsアプリケーションは多機能かつ複雑になっています。その状況下でもソフトウェア開発においては高い品質と同時に開発サイクルの短縮やコスト削減が求められます。リグレッションテストを効率的に行うことで人的リソースを有効活用し、高品質のソフトウェアをリリースするためにはテストの自動化の導入が重要になってきています。 この記事ではWindowsの機能を用いて TestArchitect を活用したWindowsアプリケーションの自動化、CI/CDツールとの連携、Windowsの機能を活用したテスト自動化の特徴とその効果的な活用方法を解説します。 ▼ 関連記事 テスト自動化ツールTestArchitectでのWebブラウザベーステストの効果的な活用方法 開発者やエンジニアが毎日直面する課題に対して、テスト自動化は時間の節約、精度の向上、リリースサイクルの加速をもたらします。迅速なフィードバックと継続的な改善プロセスを可能にする自動化テストの枠組みを採用することで、効率的かつ信頼性の高いソフトウェ... 　続きを読む　 Sqripts 関連記事｜Sqripts Windowsアプリケーションの自動化 Windows上で動作するアプリケーションのテストを自動化します。テストスクリプトやツールを利用してアプリケーションの機能のテストを検証することで手動のテストに比べて効率的にテストを実施し、デグレの検出を行うことが可能です。 TestArchitectでは他の自動化ツールと比べても豊富な標準関数があるため、テキストボックスの読み込み/書き込みやボタンの押下、ラベルの情報読み込みだけでなく、アプリ内の表やツリーパネルのパスの読み込みなど多様な操作を自動化できることが特徴です。 またTestArchitectではレコーディング機能を使うことでスクリプト作成を容易にします。レコーディング機能とは操作した手順を記録しスクリプト化する機能です。ただスクリプトを作成するだけではなく、画面のテキストボックスやラベル、ボタンなどスクリプト作成に使用するオブジェクトのインタフェース登録も同時に自動で行うことが可能になるため、非常に簡単かつ効率よくスクリプト作成を行うことができます。 TestArchitectとCI/CDツールとの連携 TestArchitectはJenkinsなどのCI/CDツールとの連携ができます。CI/CDパイプラインにTestArchitectで作成した自動テストを組み込むことで開発の速度と品質が大幅に向上します。実行結果はSlackで通知することも可能です。 CI(継続的インテグレーション)とCD(継続的デリバリー/継続的デプロイメント)はソフトウェア開発のプロセスを効率化し、品質を向上させるための重要な手法です。 CI/CDを組み込むことの利点は以下です。 ビルドの検証： 各コード変更がビルドされテストすることでビルドの一貫性と品質が保つことができる 機能テスト： 新しい機能や変更が意図通りに動作することを確認できる 回帰テスト： 既存の機能が壊れていないことを確認できる パフォーマンステスト： アプリケーションのパフォーマンスが望ましいレベルにあることを確認できる 自動化範囲の広いTestArchitectで作成したスクリプトをCI/CDに組み込むことでより効率的なソフトウェア開発が可能になります。 Windowsの機能を利用した自動化 TestArchitectではWindowsコマンドを行う関数も搭載されています。Windowsコマンドで取得した情報を変数に格納してTestArchitectの標準関数と連携させて１つのスクリプトで多様な処理を自動化することも可能になります。またマウス操作やキーボード操作も行うことができるため、人が操作するレベルに近い操作を自動化することが可能です。 PCのメモリ情報を取得するコマンドの実行例 Windowsの機能を活用することでアプリケーションだけでなくOSレベルの機能や設定を含めたシステム全体のテストを行うことが可能になります。 データ駆動型の自動化 データ駆動型の自動化(Data-Driven Testing、DDT)とは、スクリプトを複数のデータセットで繰り返し実行する手法です。これにより同じテストケースを異なる入力値で何度も実行し、異なるデータセットを効率的にテストすることができます。TestArchitectでは予め作成しておいたExcelファイルやCSVファイルを読み込むほか、TestArchitect内に登録しておいたデータを使用したデータ駆動型の自動化が可能です。 データ駆動型のテストでは準備されたデータを１行読み込み、スクリプト内のそれぞれの変数に格納して処理を行います。処理が終われば次の行のデータを読み取りし同じように処理を行います。それを格納されたデータ行を全てで行います。このように１つのスクリプトで複数のデータパターンのテストを実行することが可能です。 データ駆動型の自動化を行う利点は以下です。 再利用性の向上： 同じテストスクリプトを多くの異なるデータセットで実行できるため、スクリプトの再利用性が高まります。 メンテナンスの効率化： データの変更をする際に、スクリプトを変更する必要がなくデータセットの変更を行うことができるため、メンテナンス性が非常に高いのが特徴です。 大量データの実行： 人間では難しい大量データのテストもTestArchitectでは自動で行うことが可能です。数千、数万という人間では到底やりきれない膨大な数のデータ数でも自動で処理を行うことができるため人的リソースの効率化が可能になります。 以上により、データ駆動型の自動化は入力パラメータの組合せが多岐にわたる場合や、同じ機能を異なるデータでテストする場合に非常に有効なテスト手法です。 TestArchitectを使ったリモート実行/並列実行など多様な実行方法 TestArchitectの特徴として、実行するPCをリモートで実行することや並列実行を行うことが可能です。TestArchitectの機能を活用しリモートホストやホストに接続されたデバイスでテストを起動できます。この機能を利用することで、次のような利点があります。 複数のプラットフォームおよびハードウェア構成で、同じ、または異なるデータセットを使用して、テストを並行して実行が可能。 2台以上のマシン間の通信を伴うアプリケーションのテストが可能。 同じ共有リソースにアクセスするアプリケーションを含む同時実行テストが可能。 同期を必要とするシナリオの例として、マシン A がメッセージを送信し、マシン B がそれを受信してチェックするテストを設定すると仮定します。このシナリオでは、マシン A と B の実行を同期して、A がメッセージを送信した後にのみ B がメッセージをチェックする必要があります。 TestArchitectは単純な実行だけでなくPCのリモート実行や複数PCの列実行が可能になり活用の幅が広がります。 まとめ TestArchitectはWindowアプリケーションの自動化はもちろん、WindowsコマンドなどWindowsの機能を活用したテストの自動化に対応できることが特徴です。その他、データ駆動型の自動化で大量パターンの確認など人間による手動のテストで実現が困難なテストの実現や、リモート実行/並列実行やCI/CDへの取り込みなど活用する範囲が広いのが特徴です。 ソフトウェア開発者やテストエンジニアは、今後これまで以上に複雑かつ多様なシステムに対応した開発プロセス/テストプロセスの検討を続けていく必要があります。また、同時に開発サイクルの短縮やコスト削減への対策も行わなければなりません。TestArchitectを活用することは、これらの課題に対する1つの課題解決につながると考えています。 今回紹介した TestArchitect の導入により、これまでの手動で行っているテストに比べ、多様で正確かつ効率的なテストが実施でき、活用次第で飛躍的にテストが変わることは間違いありません。 テスト自動化ツールTestArchitectでのWebブラウザベーステストの効果的な活用方法 開発者やエンジニアが毎日直面する課題に対して、テスト自動化は時間の節約、精度の向上、リリースサイクルの加速をもたらします。迅速なフィードバックと継続的な改善プロセスを可能にする自動化テストの枠組みを採用することで、効率的かつ信頼性の高いソフトウェ... 　続きを読む　 Sqripts 関連記事｜Sqripts The post テスト自動化ツールTestArchitect｜Windowsアプリケーションでのテストの活用方法 first appeared on Sqripts .

こんにちは。Sqripts編集部です。 近年、ECサイトを標的としたサイバー攻撃が急増しています。個人情報やクレジットカード情報の漏洩事件が相次ぎ、被害を受けた企業は甚大な経済的損失だけでなく、顧客からの信頼をも失うリスクに直面しています。このような状況を受け、経済産業省は独立行政法人情報処理推進機構(IPA)と連携し、ECサイトのセキュリティ強化に向けた新たな取り組みを進めています。 経済産業省「ECサイト構築・運用セキュリティガイドライン」 独立行政法人情報処理推進機構(IPA)「ECサイト構築・運用セキュリティガイドライン」 脆弱性診断強化の背景 経済産業省とIPAは2023年3月に「 ECサイト構築・運用セキュリティガイドライン 」を公開しました。このガイドラインは、ECサイトを運営する企業にセキュリティ対策の重要性を理解してもらい、具体的な対策を講じるための指針となっています。 注目すべきは、 2025年4月より本ガイドラインの運用が開始 される予定であることです。（現在はトライアル期間として位置付けられています） ガイドラインでは、ECサイト事業者に対して 「定期的な脆弱性診断の実施」 と 「本人認証の導入」 が強く推奨されています。 この動きは、増加するサイバー攻撃からECサイトを守り、安全な電子商取引環境を維持するための重要なステップと言えるでしょう。また、経済産業省はガイドライン運用開始前の情報漏洩を防ぐため、ECサイト事業者が適切な措置を講じることを期待しています。 https://www.meti.go.jp/policy/netsecurity/guideforecsite.html （１）「経営者編」＜セキュリティ基本対策及び実行すべき取組＞ 脆弱性診断とは 脆弱性診断は、ECサイトのセキュリティ上の弱点や欠陥を特定し、対策を講じるためのプロセスです。具体的には以下のような手順で行われます。 脆弱性診断 実施手順の例 脆弱性診断には、主に以下の2種類があります。 ▼関連記事 脆弱性診断とは？その必要性や診断方法について 脆弱性診断とは脆弱性診断とは、情報システムに存在するセキュリティホール（脆弱性）を見つけ出し、それを評価・報告する作業のことです。これにより、組織はそのシステムの防御策を強化し、潜在的な攻撃から身を守ることができます。脆弱性診断の目的脆弱性診断の... 　続きを読む　 Sqripts 関連記事｜Sqripts 本人認証とは 今回策定された内容では、 「本人認証の導入」 も対策強化の対象となっています。これは、正規のユーザーのみがECサイトにアクセスできるようにするための仕組みです。一般的な方法としては以下があります。 パスワード認証 ：ユーザーIDとパスワードによる認証 二要素認証 ：パスワードに加え、スマートフォンのアプリやSMSなど別の手段で本人確認を行う 生体認証 ：指紋や顔認証など、身体的特徴を用いた認証 本人認証を強化することで、不正アクセスやなりすましのリスクを大幅に低減できます。 ガイドラインの運用開始がECサイト事業者に与える影響 脆弱性診断と本人認証の強化は、ECサイト事業者に様々な影響を及ぼすと予想されます。 まず、セキュリティ投資が増加することが考えられます。診断費用や認証システムの導入・運用にかかるコストが新たに発生するためです。また、セキュリティ対策を担当する人員の確保や教育が必要となり、運用体制の見直しを迫られる可能性があります。さらに、脆弱性対策を実施する際にECサイトの一時停止が必要になる場合もあり、サービス停止のリスクも考慮しなければなりません。加えて、認証プロセスの追加により、顧客の利便性が低下する可能性があり、顧客体験への影響も懸念されます。 ガイドラインの運用開始がECサイト事業者に与える影響 一方で、このガイドラインに沿った対策の強化にはいくつかのメリットも期待できます。 まず挙げられるのが、セキュリティレベルの向上です。脆弱性の早期発見と対策により、サイバー攻撃による被害リスクを大幅に低減できます。また、セキュリティ対策の強化を積極的にアピールすることで、顧客からの信頼獲得につながる可能性があります。さらに、将来的な法規制への先行対応となるため、コンプライアンス面でも有利になります。最終的には、セキュアなECサイトとしてのブランド価値が向上し、競争力の強化にもつながるでしょう。 セキュリティ対策強化のメリット これらの影響とメリットを総合的に考慮し、ECサイト事業者はガイドライン遵守への対応を戦略的に進める必要があります。 対策の具体例 「ECサイト構築・運用セキュリティガイドライン」では、ECサイトの構築時と運用時それぞれにおけるセキュリティ対策要件が示されています。それぞれの項目を見てみましょう。 ＜セキュリティ対策要件及び具体的な実践内容＞ ECサイトの構築時におけるセキュリティ対策要件一覧 https://www.meti.go.jp/policy/netsecurity/guideforecsite.html ECサイトの構築時におけるセキュリティ対策要件一覧 ECサイトの運用時におけるセキュリティ対策要件一覧 https://www.meti.go.jp/policy/netsecurity/guideforecsite.html ECサイトの運用時におけるセキュリティ対策要件一覧 「必須」となっているものについては必ず対策をする必要があります。 対策すべき項目が多いように感じるかもしれませんが、これらの要件を満たすことで、ECサイトのセキュリティレベルを大幅に向上させることができます。 ECサイトの脆弱性診断について ECサイトのセキュリティ強化において、脆弱性診断は極めて重要な役割を果たします。ガイドラインでは、ECサイトの公開前に脆弱性診断を行い、発見された脆弱性に対策を講じることが強く推奨されています。 前述の通り、脆弱性診断には主に「Webアプリケーション診断」「プラットフォーム診断」の2つの種類があります。 診断方法としては、 ツールによる自動診断 人手による手動診断 ツールと人手を組み合わせたハイブリッド診断 があります。 今回のガイドラインでは、 「脆弱性診断は、原則、第三者（外部委託先事業者、自社以外の第三者）による脆弱性診断を実施」 することが求められています。これは、客観的かつ専門的な視点から診断を行うことで、より確実にセキュリティリスクを特定するためです。 また、診断の質と深さも重要です。ガイドラインでは、ツールによる自動診断だけでなく、 熟練した専門家による手動の診断 を行うことにも触れています。これは、自動化ツールでは検出できない複雑な脆弱性や、サイト固有の問題を発見するために不可欠なアプローチです。手動による診断は費用が高くなる傾向がありますが、ツールでは見つけられない脆弱性を発見でき、結果として精度の高い診断が可能となります。 診断を外部に依頼する場合は、IPAが公開している 「情報セキュリティサービス基準適合サービスリスト」にある「脆弱性診断サービス」に記載されている事業者を選定することが推奨 されています。自社で診断を行う場合でも、脆弱性診断を行う技術者には高度なスキルが要求されます。 情報セキュリティサービス基準適合サービスリスト 診断の範囲は、プラットフォーム診断とWebアプリケーション診断の2種類を実施することが推奨されています。 Webアプリケーション診断 では、 ログイン画面 サイト利用者情報登録/変更画面 商品検索画面 注文・決済画面等 を最低限の診断対象とすべきとされています。 診断結果は通常、危険度「高」「中」「低」の3段階で分類されます。ガイドラインでは、危険度「高」「中」の脆弱性については、必ず対策を講じてからECサイトを公開することを求めています。発見された脆弱性の危険度とECサイトへの影響度を慎重に評価し、適切な対応を判断することが重要です。 このような詳細な指針は、ECサイト事業者がより効果的にセキュリティ対策を実施できるよう配慮されたものです。適切な脆弱性診断の実施、特に熟練した専門家による綿密な診断は、安全なECサイト運営の基盤となる重要なステップと言えるでしょう。 https://www.ipa.go.jp/security/guide/vuln/guideforecsite.html IPA 情報処理推進機構 「ECサイト構築・運用セキュリティガイドライン」 対策実施のステップ 「新規にECサイトを構築する場合」及び「ECサイトを運営中の場合」において実務担当者が実践すべき内容はガイドラインでは以下のように示されています。 新規にECサイトを構築する場合に担当者が取り組むべき内容 https ://www.meti.go.jp/policy/netsecurity/guideforecsite.html IPA 情報処理推進機構 「ECサイト構築・運用セキュリティガイドライン」 ECサイトをすでに運営中の場合に担当者が取り組むべき内容 https ://www.meti.go.jp/policy/netsecurity/guideforecsite.html IPA 情報処理推進機構 「ECサイト構築・運用セキュリティガイドライン」 これらを踏まえ、運営中のECサイト事業者が脆弱性診断強化に向けて準備を進める際に推奨されるステップを以下に示します。 運営中のECサイトの脆弱性診断 導入 準備のステップ ECサイトを運営する企業における課題と対応策 ECサイトを運営する企業にとって、セキュリティ対策の強化は資金面や人材面で大きな負担となる可能性があります。しかし、この課題に対しては様々な対応策が考えられます。まず、セキュリティ機能が充実したECプラットフォームを利用するなど、クラウドサービスを活用することで初期投資を抑えつつ、高度なセキュリティ対策を実現できます。また、専門企業による脆弱性診断や監視サービスを利用することで、自社で専門人材を抱えることなく、高品質なセキュリティサービスを受けることができます。 コスト面での負担を軽減するには、優先度の高い対策から順次実施し、段階的に導入することでコストを分散させる方法があります。さらに、中小企業向けのIT導入補助金等の活用も検討すべきでしょう。これらの外部リソースの活用と並行して、社内でのセキュリティ意識向上も重要です。従業員に対するセキュリティ教育や社内研修を実施することで、組織全体のセキュリティレベルを底上げできます。 最後に、業界団体等を通じて他社の取り組みや最新情報を積極的に収集し、自社の対策に活かすことも効果的です。これらの対応策を組み合わせることで、効果的かつ効率的にセキュリティ対策を強化することができるでしょう。 ECサイト運営企業における課題と対応策 今後の展望 脆弱性診断の導入強化は、ECサイトのセキュリティ強化に向けた重要なマイルストーンとなります。しかし、サイバー攻撃の手法は日々進化しており、一度の対策で終わりではありません。今後予想される展開としては以下のようなことも考えられます。 対象の範囲拡大 ECサイトが対象となっていますが、ECサイト以外の個人情報を扱うサイト全般に対象が拡大される可能性 診断頻度の増加 年1回から四半期ごとなど、より頻繁な診断が求められる可能性 AI活用の進展 人工知能を用いた高度な脆弱性診断ツールの登場 業界標準の確立 ECサイトセキュリティに関する認証制度の創設 国際的な基準との調和 グローバルなeコマース市場に対応した基準の統一化 脆弱性診断の準備で終わりではなく、継続的な運用の体制を整えることも急務となっています。 まとめ ECサイトにおけるガイドラインの運用開始は、安全な電子商取引環境を維持するための重要な施策です。事業者にとっては一時的なコスト増や運用負担の増加が避けられませんが、長期的には顧客からの信頼獲得や競争力強化につながる投資と捉えることができます。 セキュリティ対策強化に向けた準備期間は残り少なくなっています。ECサイト事業者は、「ECサイト構築・運用セキュリティガイドライン」を参考に、自社のセキュリティ対策を見直し、必要な投資や体制整備を進めることが求められます。同時に、セキュリティは技術面だけでなく、運用や従業員教育など総合的なアプローチが重要です。 サイバーセキュリティの分野は日々進化しており、一度の対策で安心することはできません。継続的な改善と最新動向のキャッチアップが不可欠です。ECサイト事業者は、セキュリティを「コスト」ではなく「投資」と捉え、安全なオンラインショッピング環境の構築に向けて、積極的に取り組んでいくことが望まれます。 「脆弱性診断」に関するお悩み、お聞かせください。｜株式会社AGEST サイバーセキュリティ診断｜お役立ち資料｜株式会社AGEST（アジェスト） 本資料は、以下の3点がまとめてわかる内容になっています。 セキュリティ診断の重要性 AGESTのセキュリティ診断の特長 導入事例 / お客様の声 「セキュリティ対策が十分にできているか心配」「セキュリティ強化の方法を模索している」といったお 　詳細はこちら　 株式会社AGEST（アジェスト） 関連情報 The post 脆弱性診断と本人認証の導入強化について解説 ～ ECサイト事業者に求められる対応 first appeared on Sqripts .

こんにちは、K.Oです。 今回は、オープンソースのAIアプリケーション開発プラットフォームであるDifyを使い、チャットフロー機能を活用して簡単にアプリケーションを構築する方法をご紹介します。 AIアプリケーションを効率的に構築したい方に向け、直感的なUIを使ってインタラクティブなAIアプリを簡単に作成するヒントをお伝えできれば幸いです。 Difyとは 基本機能と特長 Difyは、AIアプリケーションを効率的に構築・展開できるオープンソースのプラットフォームです。その主な特長は以下の通りです。 直感的なUI ：コードなしでも、ドラッグ＆ドロップでアプリケーションを設計できます。 多彩な機能 ：チャットフロー、ワークフロー、ナレッジベース、LLMを活用した応答生成など、豊富な機能が搭載されています。 拡張性 ：外部ツールやサービスとの連携が容易で、機能を柔軟に拡張できます。 本記事で扱うチャットフロー機能の概要 チャットフロー機能は、ユーザーとの対話型アプリケーションを簡単に作成できる機能です。ドラッグ＆ドロップでノードをつなぎ、ユーザーの入力に応じてフローを変化させることで、インタラクティブな応答を提供できます。たとえば、ユーザーが特定の質問を入力すると、その質問に応じて異なる処理や応答を行うことができます。 作成するサンプルアプリケーションの概要 AIの発展に伴い、AIが提案するテストケースやシナリオを人間がレビューする機会が増えています。今回は、JSTQB Advanced Level テストアナリストの資格の勉強をすることで、テストケースのレビュー能力が向上すると考え、Difyを使って練習問題を生成するアプリケーションを構築しました。 具体的には、ユーザーのリクエストに応じて、以下の4つの条件に分岐し、それぞれに適した返答を生成するアプリケーションを目指します。 JSTQB Advanced Levelの練習問題を生成 問題への回答に対するフィードバックを提供 ソフトウェアテストに関する質問・相談への返答 その他の情報に対する適切な返答 環境構築 必要なツールのインストール 以下のツールをインストールします。 Docker Visual Studio Code（VSCode） Git 　※GitHubからリポジトリをクローンするために使用します。 Dockerを利用してVSCodeのターミナルからDifyを立ち上げる リポジトリのクローン git clone https://github.com/langgenius/dify.git クローンしたリポジトリ内の docker ディレクトリに移動 cd dify/docker Dockerコンテナの起動 docker compose up -d これらのコマンドをVSCodeのターミナルから実行します。これでDifyがローカル環境で立ち上がります。 参考： Dify Difyを利用できる状態にする 次にブラウザで  http://localhost/install にアクセスし、アカウントを作成してログインしたらDifyを利用できる状態になります。 Difyでアプリケーションを構築する 準備設定 LLMのAPIキーをセットアップする Difyでは、OpenAIやAnthropicなどのさまざまなAIモデルを利用できますが、今回は毎日一定回数まで無料で利用できるGeminiモデルのセットアップ方法をご紹介します。 APIキーを取得する GoogleのAIプラットフォームである Google AI Studio にアクセスし、GeminiのAPIキーを取得します。 Difyにて、APIキーを設定する方法 画面右上のユーザーメニューから設定画面を開き、「モデルプロバイダー」タブを選択します。利用可能なモデルプロバイダーの一覧から「Gemini」を選択し、取得したGeminiのAPIキーを設定します。 RAGを利用する RAGとは RAG（Retrieval-Augmented Generation）は、AIモデルが応答を生成する際に、外部のナレッジベースから情報を取得し、その情報を活用して回答を生成する技術です。これにより、モデルは最新かつ正確な情報を提供できるようになります。 RAGのメリット 最新情報の提供 ：ナレッジベースを更新することで、常に最新の情報をユーザーに提供できます。 専門知識の活用 ：特定の分野に特化した情報を取り入れることで、専門的な質問にも対応可能です。 応答の精度向上 ：外部データを参照することで、モデルの回答の正確性と信頼性が向上します。 DifyでのRAGの活用方法 Difyではナレッジ機能を使って、RAGを簡単に設定できます。 ナレッジに必要な情報をアップロードし、チャットフロー内で「知識取得ノード」を利用することで、ユーザーの質問に対して適切な情報を提供できます。 チャットフロー機能の基礎知識 Difyを使ったチャットフローの作成は、簡単で直感的に行うことができます。いくつかの基本的なポイントを紹介します。 直感的なUIとノード（ブロック）でフローを構築 ドラッグ＆ドロップでフローを作成 Difyのチャットフローエディタでは、ノードをドラッグ＆ドロップで簡単に配置し、フローを構築できます。視覚的にわかりやすく、複雑な設定が必要なく、手軽にチャットフローを作成可能です。 ノード間のシームレスなデータ連携 各ノードはユーザーの入力や処理結果を次のノードに自動的に渡す仕組みが組み込まれています。これにより、ユーザーのリクエストに応じて適切に応答を生成できるフローを簡単に作成可能です。必要に応じて、データの受け渡しの設定も調整できます。 ノードの設定 今回、チャットフローを作成する際に使用したノードについて、基本的な役割を紹介します。 開始 チャットフローのスタート地点であり、ユーザーからの入力を受け取ります。基本的に特別な設定は不要ですが、必要に応じて開始時のメッセージを設定することもできます。 質問分類器 ユーザーの入力を解析し、意図や質問の種類に応じてフローを分岐させます。分類条件は曖昧にならないよう、明確ないくつかのクエリを定義して設定します。各カテゴリーには対応する次のノードを指定します。 知識取得 事前にアップロードしたナレッジを指定して関連情報を検索し、応答生成に活用します。これにより、RAGを実現します。ナレッジの情報が最新かつ正確であることを確認し、定期的な更新を行うことが応答の信頼性を維持するために重要です。 LLM 大規模言語モデル（LLM）を使用して、ユーザーへの応答を生成します。使用するAIモデル選択し、モデルの振る舞いを指定するシステムプロンプトの設定を行うことができます。 回答 LLMノードで生成された応答をユーザーに返します。LLMノードからの出力をそのまま表示するか、必要に応じて追加の情報を含めることができます。 ※2024年10月現在の情報に基づいて記載しています。チャットフロー機能は現在BETA版であり、日々アップデートされています。最新の情報や詳細な機能については、 Dify公式ドキュメント をご確認ください。 サンプルアプリケーションを実行する 最後に、プレビュー機能を使ってアプリケーションを実行し、動作確認を行います。ユーザーが送信した情報に基づき、質問分類器を通して処理が分岐し、それに応じた適切な回答が返されることを確認します。 RAGに基づいたJSTQB Advanced Levelの練習問題を生成 テスト設計に関する問題をリクエストしたところ、想定通りに処理が分岐し、回答が生成されました。 チャットプレビューウィンドウでは、次のように回答が返ってきました。 回答の最後に『引用』が表示され、RAGのプロセスを通じて生成された情報に基づいていることを確認できます。これにより、生成された回答が信頼できる外部のデータソースを参照していることがわかります。 ユーザーの回答へのフィードバックを生成 次に、生成された問題に対する回答として選択肢を送信すると、想定通りに処理が分岐し、新たな回答が生成されました。 チャットプレビューウィンドウでは、次のように正誤判定とその説明が返ってきました。 念のため、誤りとなる選択肢も送信してみたところ、正しく判定され、その根拠も返してくれています。 他の選択肢もすべて試してみたところ、期待通りに正しく判定され、さらに説明も返ってきました。 また、「質問・相談への返答」や「その他の情報への返答」は、例外的なリクエストにも対応するよう設定していました。 たとえば、不適切な内容を送信した場合には、 その他の情報を処理するフローに分岐し、次のような返答が得られました。 所感 実際にアプリケーションを動かしてみたところ、想定通りに機能しました。特に、設定したLLMモデルによって生成される練習問題の質に差がある点が興味深かったです。より高性能なモデルを使用することで、正確な条件分岐や高品質な応答を得ることができました。 まとめ チャットフロー機能を使うことで、ユーザーとのインタラクティブな対話とタスクの自動化を両立したアプリケーションを効率的に開発できます。Difyを活用することで、自然言語で実用的なアプリケーションを作成できるのが大きなメリットです。 例えば、法律相談やカスタマーサポートの自動応答など、さまざまな用途に応用可能です。また、DifyはPerplexityやNotionなどの外部サービスとも連携でき、さらに機能を拡張して幅広い場面で活用することができます。 最後までお読みいただき、ありがとうございました。この記事が、皆さんのアプリケーション開発に少しでも役立てば幸いです。 参考 Dify公式サイト JSTQB Advanced Level シラバス日本語版テストアナリスト PDF Google AI Studio The post Difyのチャットフロー機能で学習支援アプリケーションを構築する first appeared on Sqripts .

こんにちは、セキュリティエンジニアの河村です。 今回は SIMスワップ攻撃 について解説します。 SIMスワップ攻撃とは簡潔に説明すると、攻撃者が被害者の電話番号を自分の管理するSIMカードに不正に移行させることで、被害者の個人情報や金融資産にアクセスする詐欺手法です。昨今、有名人が被害にあったりしていることから、この攻撃が話題にあがることが増えています。 この攻撃は対策を知らないと汎用的なセキュリティ意識を高めていても防ぎづらく、高額な被害が発生するケースがしばしばあります。 本記事ではこの攻撃について、押さえておきたいポイントをまとめ、解説します。 SIMスワップの概要 SIMスワップ攻撃の概要 以下でSIMスワップによる攻撃の標準ケースの場合の手順と概要を示します。 1. ターゲットの情報収集 攻撃者は、ソーシャルエンジニアリングやフィッシングなどを通じて、ターゲットの個人情報を集めます。これには、氏名、生年月日、住所、メールアドレス、電話番号、場合によっては口座情報などが含まれます。 2. 携帯電話会社に対する正規利用者へのなりすまし 集めた情報を使って、攻撃者はターゲットの携帯電話会社に対して、自分がターゲットであるかのように偽ります。そして、携帯電話を紛失した、SIMカードが破損した、などの理由で新しいSIMカードへの切り替えを要求します。 携帯電話会社は通常、いくつかのセキュリティ質問や本人確認手続きがありますが、攻撃者は前もって集めた個人情報を使ってこれらの確認手続きを突破します。場合によっては、ソーシャルエンジニアリングでオペレーターを欺くこともあります。SNSや個人ブログで取得した生年月日、住所、会社名などを用いて心理的にオペレーターを欺き、偽造された免許証やマイナンバーを用いて物理的にもオペレーターを欺きます。 SIMスワップ攻撃における、携帯電話会社への詐欺の手順 3. 新しいSIMカードに電話番号を移行 攻撃者が携帯電話会社をだますことに成功すると、携帯電話会社はターゲットのSIMカードを紛失扱いとし、再発行されたSIMカードを攻撃者は入手します。これにより、ターゲットの電話やSMSを攻撃者が受け取ることができるようになります。 4. 2段階認証の突破 多くのオンラインサービスや銀行口座は、SMS認証を使ってセキュリティを強化しています。攻撃者は、ターゲットの電話番号を手に入れることで、SMSを使った2段階認証コードを受け取り、ターゲットのオンラインアカウントに不正にアクセスすることが可能になります。 5. 資金や情報の盗難 攻撃者は銀行口座や暗号通貨ウォレット、その他の個人アカウントに不正アクセスし、資金の移動や個人情報の盗難を行います。また、これらのアカウントを悪用してさらなる詐欺行為を行うこともあります。 被害の影響 金銭的被害 : 銀行口座やクレジットカード情報が盗まれ、資金を不正に引き出される可能性があります。 個人情報の漏洩 : メールやSNSアカウントにアクセスされ、個人情報やプライベートなメッセージが流出する恐れがあります。 信用の損失 : 攻撃者が被害者になりすまして不正行為を行うことで、社会的信用が損なわれる可能性があります。 これらからわかることは、この攻撃において、攻撃者は直接的に被害者に攻撃をする必要が必ずしもない点があげられます。たとえ被害者が個人情報の管理をしっかり行ったところで、熟練のソーシャルエンジニアリングで被害者の周りの人物からの情報の漏洩の脅威を完全に防ぐことはほとんど不可能です。従って、SMS認証を使用している以上、この攻撃に対する完全な対策は現状ありません。 SIMスワップ攻撃の事例 いくつか具体的な事例をみていきましょう。 1. 東京都議員の事例 東京都議会議員のK氏は、携帯電話が乗っ取られる被害に遭った経験を共有しています。最初にPayPayから身に覚えのないチャージ通知が届き、不審に思いながらも放置していたところ、大きな金額の決済が試みられ、SMSが受信できないなどの異常が発生しました。ソフトバンクショップを訪れると、名古屋の店舗でマイナンバーカードの目視確認のみで不正な機種変更が行われていたことが判明。警察に通報し、被害を最小限に抑えるための措置を講じましたが、ソフトバンクの対応が間に合わず、追加で10万円の被害も明らかになりました。 K氏は、「身に覚えのない通知には即座に対応し、利用停止などの措置を取るべき」と警告しています。 また、政治家等、職業柄住所や生年月日を公表している方は狙われやすい可能性があるとも言及してます。 2. Twitter（現X）の元CEOの事例 Twitterの元CEOで共同創設者であるD氏のアカウントが、2019年8月30日にハッキングされました。ハッカーはそのアカウントから差別的なコメントや爆破予告のツイートを投稿しました。Twitterはこの事実を認め、アカウントを保護し、同社のシステム自体には侵害がないと発表しました。 ハッキングはモバイルプロバイダーのセキュリティ上の不手際によるSIMスワップ攻撃によって行われ、犯行グループは「Chuckling Squad」とされています。彼らはD氏のツイートを通じて自身のDiscordサーバーへの参加を呼びかけていましたが、Discordは迅速にそのサーバーと所有者を削除しました。 いずれの事例も被害は甚大です。FBIによると、 2021年の被害総額は6,800万米ドル  にのぼると推定されています。 'SIM swap' scams netted $68 million in 2021: FBI Criminals obtain an individual's SIM card through phishing tactics by pretending to be the victim's mobile carrier, according to the FBI. 　詳細はこちら　 ABC News 関連情報🔗 SIMスワップ攻撃の防止策 SIMスワップ攻撃を防ぐためには、いくつかの重要な対策を講じる必要があります。まず、携帯電話キャリアのアカウントには独自のPINコードやパスワードを設定し、不正なアカウント変更を防ぐことが推奨されます。加えて、セキュリティ質問や他の認証手段を活用することが有効です。 次に、個人情報の管理においては、SNSやオンラインプラットフォームでの情報共有を最小限にし、攻撃者に個人情報を悪用されないように注意を払うことが重要です。また、フィッシング詐欺への警戒も必要で、不審なメールやテキストメッセージに含まれるリンクをクリックしないようにし、個人情報の提供を避けるべきです。これらの防止策によって攻撃者が正規利用者になりすますことを防げます。 当然ながら二要素認証（2FA）は推奨されているが、その中でもSIMスワップ攻撃の恐れのあるSMS認証よりもGoogle AuthenticatorやAuthyといった認証アプリを使用したパスキー認証が望ましいです。 参考 ： IPA「情報セキュリティ10大脅威 2024」 (PDF) アカウントの監視も重要で、重要なアカウントに対しては、不審なログインや活動が発生した際に通知が届くように設定することが推奨されます。また、定期的にパスワードを変更し、異なるサイトで同じパスワードを使い回さないようにすることも必要です。 参考 ： Kaspersky「SIMスワップ詐欺とは？ 攻撃に対する対策を紹介します」 調査を行っての考察 SIMスワップ攻撃は複合的なソーシャルエンジニアリングの組み合わせと言えます。攻撃のエントリーポイントは身分証明の脆弱性であり、さらに2FAを突破することで被害が発生します。 身分証明の問題点としては、電話番号や生年月日、住所などの個人情報に身分証明書としての役割を任せすぎてることに問題があるよう私は思います。なぜならばこれらはSNSを用いたり、もしくは職業柄公開しないといけない、第三者からの漏洩等の形で攻撃者にとって容易に入手できるものであるからです。 電話番号はお手軽な所得要素として信頼されていますが、通信会社はこのような用途を意図しておらず、後出しで高度なセキュリティ要件が求められており、この攻撃ではそこにつけ込まれています。 参考： WIRED「How to Protect Yourself Against a SIM Swap Attack」 改善案として、日本の場合本人認証としてマイナンバーを用いることをより徹底するべきだと私は思います。それも番号としての個人番号ではなく、耐タンパー性が確保されており、原理的に複製・改竄が（ほぼ）できないICチップを用いた身分証明を普及させることが重要だと思います。身分証明を偽ることを困難にすることでSIMスワップ攻撃以外のあらゆるソーシャルエンジニアリング攻撃に繋がる、大きな弱点を防げるからです。 しかし、この身分証明の問題点の改善は現実的に一朝一夕に行えるものではありません。また、個人や一企業の働きかけで簡単に変えれるものでもありません。そこで今すぐ行えることとして身分証明の脆弱性を突破されたあとに攻撃者が行う2FA、つまりSMS認証への攻撃を防ぐことを実践するべきだと思います。対策としては身分証明書の問題からのエスカレーションが出来ないパスキー認証の導入が推奨されます。ただしパスキー認証はユーザー側が認証ソフトをいれることが必要であり、ユーザー側に普及するまでは少々ユーザビリティが低下するため普及がなかなか進んでいないのかと思ってます。 総じて、一度狙われると多大な被害が出かねない攻撃であるにも関わらず、対策となるパスキー認証の普及率はまだ高くありません（※Yahoo!JAPAN が 2019 年と 2022 年の両方で Android でパスキーを使用したユーザー グループを調査したところ、パスキーを引き続き使用しているユーザーの割合は 38% でした。 参考： Web.dev「Yahoo!JAPAN、パスキーの導入率を 11% に増やし、SMS OTP の費用を削減」 ）。 携帯会社やアプリ開発者に対策をしてもらわないといけないため、根本的対策が行われるまでに時間がかかりそうで、今後も被害が拡大する恐れの高い攻撃だと思いました。この記事を通して、一人でもSIMスワップ攻撃の被害に遭う方が減らすこと出来たらいいなと思っています。 The post SIMスワップ攻撃について知っておきたいこと｜事例や対策を解説 first appeared on Sqripts .

テストエンジニアが身につけておきたいスキルの一つ「論理のスキル」。 「論理の言葉」の意味や働きに注意が向くようになったら、文や文章の読み書きで実践していきましょう。 この連載では、「論理スキル“実践編”」と題して、「文章の筋道を把握する、主張を理解する」「文や文章の筋道を組み立てる」ことに役立つ 推論の形 を見ていきます。 ＜テストエンジニアのための論理スキル[実践編]　記事一覧＞ ※クリックで開きます 論理のかたち。推論とは ［全文公開中！］ 基本的な推論形式 “または”を使って推論する “ならば”を使って推論する “ならば”と“または”で推論する ソクラテスは電気羊の夢を見るか？ (前編) ソクラテスは電気羊の夢を見るか？ (後編) 気をつけたい落とし穴(前編・形式面) ここまで、基本的な推論の形を取り上げて、その考え方を解説してきました。 今回と次回は、推論を読んだり組み立てたりする際に「気をつけたい落とし穴（誤謬）」に焦点を当てます。 今回は、各回でも説明した「形式面で気をつけたい落とし穴」のおさらいです。 まず前回クイズの解答から。 前回クイズ解答 問題(再掲) ISTQB Foundaton Level V4.0シラバスの記述を元にした主張があります（()内は章節番号）。 それぞれについて、形に着目して、妥当な（よい形の）主張かどうか、 前回 の説明を元に考えてください。 解答 問1。 媒介項「人間」は大前提①（全称肯定の主語）で周延されており、周延の規則①を守っています。 大名辞「エラーを犯す」は大前提①、結論③とも不周延。小名辞「開発者」は小前提②で全称の主語、③で特称の主語で、どちらも周延の規則②を守っています。 ①②③いずれも肯定であり、肯定と否定の規則③を守っています。 以上から、妥当な形です。ちなみに第1格のAAIという式です。 問2。 媒介項「欠陥」が①（特称の主語）、②（肯定の述語）ともに不周延であり、周延の規則①に反しています。 また、①②とも特称文ですから、全称と特称の規則①に反しています。 この2点から、非妥当な形です。 一見、意味内容は正しそうに見えるかも知れませんが、媒介項が①と②で同じ概念(の範囲)を指しているかどうか不明です。 媒介項には別の問題もあります。 ①では「欠陥」と言っているのに対し、②では「欠陥の原因」と言っています。両者は同じ概念と言えるでしょうか？ ちなみに第1格です。式の形はIIIになります(前述の理由から、すべての格で非妥当)。 問3。 媒介項「テスト」は①で周延されており（全称の主語）、周延の規則①を守っています。 大名辞「デバッグ」は①③で周延されています（否定の述語）。 小名辞「ホワイトボックステスト」は②③ともに「ホワイトボックステストの全体」（全称）と解釈できます。 大前提①が否定、結論③が否定で、肯定と否定の規則②を守っています。 以上から、妥当な形です。ちなみに第1格のEAEという式です。 問4。 媒介項「コミュニケーションの問題」は②で周延されており（全称の主語）、周延の規則①を守っています。 大名辞「リスク」は①③ともに不周延、小名辞「人の問題」は②③ともに不周延で、どちらも周延の規則②を守っています。 ①②③いずれも肯定であり、肯定と否定の規則③を守っています。 以上から、妥当な形です。ちなみに第3格のIAIという式です。 推論の形式で気をつけたい落とし穴 各回で説明してきた推論形式には、形式面で気をつけたい落とし穴(誤謬：ごびゅう)があります。 今回、復習を兼ねて一覧できるようにしました。 これらは、その推論形式の性質から 意味内容の真偽とは関係なく 「これは間違った推論」と言えてしまう誤りです。 いくら内容面では正しいと思えるとしても、形の上で問題があるものは筋道を損ねてしまっており、よい主張とは言えません。 “または”で気をつけたい落とし穴 “または”は包含的 論理の言葉としての“または”（選言。“入門編”では論理和(OR)として紹介)は、「PとQがともに真でも成り立つ」という性質を持っています。 参照 ・ 論理スキル[再]入門 [第3回] プログラムレベルのロジック(2)解説編・基本の論理演算 ・ 論理スキル[実践編]“または”を使って推論する この特徴から 包含的選言 などとも呼ばれます。 図8-1 “または”(論理和(OR))の真理値表 選言三段論法での誤謬 この性質から、選言肢の一方が真だからといって、他方が偽であるとは言えません。 図8-2は誤り です（PとQを入れ換えても同じ）。 （ 選言三段論法の回 では“タイプB”という本連載独自の呼称を使っています） 図8-2 選言三段論法の非妥当な形 （排他的な“または”なら誤りではないが） 日本語だと同じ“または”という語になりますが、 「P, Qどちらかが真だが、ともに真ということはない」「Pが真であるか(その場合Qは偽)、または、Qが真(その場合Pは偽)」 という場合を表す“または”があります。 これは“排他的選言”や“排他的論理和(Exclusive OR, XOR)”などと呼ばれます(図8-3)。 この意味の“または”である場合は、図8-2の形は正しくなります。 図8-3 排他的な“または”(排他的論理和, 排他的選言)の真理値表 （どちらでも正しいのはこちらの形） 選言三段論法 で、包含的選言でも排他的選言でも正しいのは、選言肢の一方を否定し、残る選言肢を結論とする形です（図8-4。PとQを入れ換えても同じ）。 （ 選言三段論法の回 では“タイプA”という本連載独自の呼称を使っています） 図8-4 選言三段論法の妥当な形 どちらの意味で使われているか、どちらに該当するのか、に気をつける 残念ながら、私たちが日ごろ使う言語では、どちらの選言かによって異なる言葉を使い分けるようにはなっていません。 文や主張の中に“または”が現れた場合は、どちらの意味なのかを選言肢の内容や文脈から判断する必要があります。 例。 ヨーロッパ向けの製品を担当するには、フランス語の知識か、またはドイツ語の知識が必要です。 フランス語の知識とドイツ語の知識を両方持っていても仕事の妨げにはならないでしょうから、この“または”は包含的な選言と解釈できます。 【非妥当】「担当しているミオさんはドイツ語ができるから、フランス語はできないかもね」 【妥当】「担当しているエマさんはドイツ語はできないそうだから、フランス語に堪能ということなんだろう」 両方の知識を持っている人は担当できないという条件がつくなら、【非妥当】の方も正しくなります（が、そういう条件にしている理由が気になりますよね……）。 例。 ハルトさんは、エマさんか、または、ミオさんのどちらかと結婚するだろう。 重婚を認めていない国/地域であれば、この“または”は排他的選言と解釈するのが自然でしょう。 【妥当】「ハルトさんはミオさんと結婚する。だから、ハルトさんはエマさんとは結婚しない」 “ならば”で気をつけたい落とし穴 “ならば”と逆・裏・対偶（何度でも確認しましょう） 条件法“ならば”と逆・裏・対偶のうち、 「PならばQ」が正しい(真である)時に正しいと言えるのは対偶「QでないならばPでない」のみ です。 参照 ・ 論理スキル[再]入門[第6回] 文レベルのロジック (2)条件・場合を表す言葉 図8-5 条件法と逆・裏・対偶 仮言三段論法での誤謬――前件否定と後件肯定 混合仮言三段論法 で、 「①PならばQ。②Q。③従って、P」は 「PならばQ」の「逆」 を、 「①PならばQ。②Pではない。③従って、Qではない」は 「PならばQ」の「裏」 を、それぞれ言っていることになります。 （前者が 後件肯定 の誤り、後者が 前件否定 の誤り） これは誰しもうっかり間違えてしまいがちな、陥りやすい「落とし穴」です。 森高千里というミュージシャン/シンガーのヒット曲に次の一節があります（発表は30年ほど前）。 私がオバさんになったら　あなたはオジさんよ 「私がオバさんになっても」作詞・森高千里 森高千里さんが2024年夏のライブ(野外フェス)に出演した際の写真が先日ネットに公開されたそうですが、往時から全然変わらぬお姿とか。 （参考： 別サイト(J-CASTニュース)の記事 ） その姿とこの歌詞から、 ①森高千里がオバさんになったならば、我々はオジさんである。 ②だが、森高千里はオバサンになっていない！ ③従って、我々はオジさんではない！！ という推論が成り立つ！　のでは！！　……と考えたくなりますが、残念ながらこれは前件否定です。 直感や願望、見た目のインパクトなどから、つい「わかりやすい」推論に飛びついてしまうというのは、ありがちなことです。 （論理的には、そして現実にも、森高千里さんがオバさんにならないからといって、男子がオジさんにならないとは限らないわけです） （ただし、逆と裏が成り立つ場合はある） “ならば”が、「PならばQ」と同時に「QならばP」を主張する 等値(同値)の“ならば”（双条件法） であるならば、元の主張が正しい時に逆や裏も正しくなります。 参照 ・ 論理スキル[再]入門[第6回] 文レベルのロジック (2)条件・場合を表す言葉 ・ 論理スキル[実践編]基本的な推論形式 図8-6 双条件法の働き(仮) 双条件法の例①。 ある数Xが1より大きい自然数で、かつ1と自分自身を除き約数を持たない時、そしてその場合に限り、Xを素数という。 用語や概念の定義では双条件法は重要な役割を果たします。なぜだと思いますか？ 双条件法の例②。 志望者がフランス語か、またはドイツ語の知識を持っている場合、そしてその場合に限って、ヨーロッパ向けの製品を担当することができる。 条件法の“ならば”の場合に対して、「ヨーロッパ向けの製品を担当できる条件」はどう違うでしょうか？ “ならば”の前後に気をつける 等値の“ならば”はそれと分かる言い回しなしに使われることもありますから、なおさら、前件と後件の意味内容とつながりには注意を払いましょう。 例。 「あの科目は、テストの結果が悪かったら単位は取れない。単位が取れなかったということは、テストの結果が悪かったんだ」 テストの得点だけが単位取得の評価項目なら、この“ならば”は等値(同値)の“ならば”であり、推論は正しいと言えます（例文では情報がないので、正しいと断言するのは早計です）。 他にも評価項目があるなら（出席回数/出席率など）、この推論は 後件肯定 の誤りです。 例。 「もしあなたがこの手紙を読んでいるなら、私は既に死んでいるということだ」 小説、映画、ドラマなどでしばしばお目にかかる場面ですが、 「あなた」がその手紙を読んだのに「私」が生きているということはなく、「私」が死んだ時のみ「あなた」の目に触れるのでしょうから、これは等値(同値)の“ならば”、双条件法と考えてよいでしょう（なので、ミステリーやスリラーでは、実は死んでおらず……という展開が活きるわけでしょうね）。 両刀論法でも気をつける 両刀論法 も“ならば”を用いた推論ですから、前件否定や後件肯定には気をつけましょう。 定言三段論法で気をつけたい落とし穴 前回 取り上げた形ですが、おさらいしましょう。 四個概念の誤謬 以外は、形から判断がつきます。 概念の数に関する誤謬 定言三段論法に4個(以上)の概念が登場してしまうと（ 四個概念の誤謬 。 媒概念曖昧の誤謬 などともいいます）、概念(名辞)どうしの関係がつけられず、正しい推論ができなくなります。 特に次のような場合に気をつけましょう。 使われている言葉の意味は明確か 「同じ言葉を同じ意味」で使っているか（文によって違った意味に解釈できることはないか） 「同じ概念には同じ言葉」を使っているか（文によって違った概念を指していると解釈できることはないか） （言葉の意味や使い方が揺らいでいないか、というのは、定言三段論法に限らず気をつけたいことでもあります） 周延に関する誤謬 媒介項Mが特称(主語の場合)か、または肯定(述語の場合)でしか現れていないなら、 媒介項不周延の誤謬 （周延の規則①の違反）です。 図8-7 媒介項不周延の例 大名辞不当周延の誤謬 、 小名辞不当周延の誤謬 （周延の規則②の違反）は、それぞれの名辞(概念)の全称/特称、肯定/否定に注意しましょう。 図8-8 大名辞不当周延、小名辞不当周延の例 肯定と否定の規則に関する誤謬 否定二前提の誤謬 (肯定と否定の規則①の違反)、 不当肯定の誤謬 (同②の違反)、 不当否定の誤謬 (同③の違反)は、全体の形を見ましょう。 図8-9 否定二前提の誤謬、不当肯定の誤謬、不当否定の例 次回 次回は、演繹的な推論に限らず、考えを組み立てたり述べたりする際に 意味内容の面で「気をつけたい落とし穴」 を取り上げます。 これまでで取り上げていない“落とし穴”がたくさん出てきます。お楽しみに。 参考文献 John Nolt, Dennis Rohatyn(著), 加地大介(訳) 『現代論理学 (Ⅰ)』 オーム社 1995 レイモンド・スマリヤン(著), 高橋昌一郎(監訳), 川辺治之(訳) 『記号論理学　一般化と記号化』 丸善出版 2013 鈴木美佐子 『論理的思考の技法Ⅰ〔第2版〕』法学書院 2013 弓削隆一, 佐々木昭則 『例解・論理学入門』 ミネルヴァ書房 2009 近藤洋逸, 好並英司 『論理学入門』 岩波書店 1979 藤野登 『論理学　伝統的形式論理学』 内田老鶴圃 1968 鈴木美佐子 『論理的思考の技法Ⅱ』 法学書院 2008 図版に使用した画像の出典 Loose Drawing 人物画をお借りしています。 テストエンジニアのための論理スキル[実践編]  連載一覧 論理のかたち。推論とは  【連載初回、全文公開中】 基本的な推論形式 “または”を使って推論する “ならば”を使って推論する “ならば”と“または”で推論する ソクラテスは電気羊の夢を見るか？ (前編) ソクラテスは電気羊の夢を見るか？ (後編) 気をつけたい落とし穴(前編・形式面) The post 気をつけたい落とし穴(前編・形式面)｜テストエンジニアのための論理スキル［実践編］ first appeared on Sqripts .

はじめまして、QAコンサルタントのツルリンです。 2024年6月8日(土)に実施されました、第32回 初級ソフトウェア品質技術者 資格試験に合格することができましたので、合格体験記として、JCSQEに関する情報と受験に向けた私の取り組みをご紹介します。 これから初級ソフトウェア品質技術者 資格試験を受験する方のお役に立てれば幸いです。 受験の動機 QAコンサルティングに必要となるソフトウェア品質向上に関する包括的かつ体系的な知識修得のために受験しました。コンサルティング業務遂行や担当プロジェクトの成功においては、包括的かつ体系的なソフトウェア品質向上に関する知見を確立することが重要であり、最新の方法論やベストプラクティスに精通し、問題解決や品質管理において的確なアプローチを提供できる専門家となることが求められていると感じています。今回の受験を通じた知識修得が信頼できる相談相手としての地位を築くための基盤となると信じており、より深い専門性と専門知識を身につけることで、クライアントに対する価値提供を最大化するための一歩にできると考えて、受験しました。 JCSQEとは JCSQE （ソフトウェア品質技術者資格認定：JUSE Certified Software Quality Engineer）とは、すべてのソフトウェア技術者が品質技術を身につけ、実践していくことにより、ソフトウェア品質の向上を実現することを目的とした資格試験です。一般財団法人日本科学技術連盟（JUSE）が主催しており、初級試験は年2回（6月と11月）、中級試験は年1回（11月）、定期的に実施されています。 JCSQE ソフトウェア品質技術者資格認定 ソフトウェアの品質技術を高め、継続的・効果的に品質向上を目指すために、あなたのソフトウェア品質力を認定します。 　詳細はこちら　 JCSQE ソフトウェア品質技術者資格認定 関連情報 初級ソフトウェア品質技術者資格試験の概要 出題範囲：初級ソフトウェア品質技術者資格試験 シラバスVer.3.0に準拠 ※主参考図書『ソフトウェア品質知識体系ガイド ‐SQuBOK Guide‐第3版』 試験時間：60分 問題数：40問 出題形式：マークシート形式 合格ライン：70%程度 SQuBOK Guide について SQuBOK Guide （ソフトウェア品質知識体系ガイド：Software Quality Body of Knowledge）は、JCSQEの主参考図書になっています。 SQuBOK Guideにはソフトウェアの品質マネジメントや品質技術に関連する技法から、事例、関連文献、国際規格などが網羅的に整理されていて、ソフトウェア品質に関するトピックの全体像が把握でき、知識が整理できるようになっています。 初級ソフトウェア品質技術者資格試験 シラバスVer.3.0の項目は、SQuBOK Guide 第3版の目次と完全一致しています。 ソフトウェア品質知識体系ガイド （第3版） －SQuBOK Guide V3－ | Ohmsha 本書は、ソフトウェア、ITシステムの専門家である著者らが長年取り組んできたソフトウェアの品質について体系立てて整理し、簡潔に解説したものです。第1版発行から13年、第2版から6年が経過し、ソフトウェアを取り巻く環境は大きく変化しました。これを踏まえ、従来... 　詳細はこちら　 オーム社 関連情報 受験申込み 試験料 15,400円（税込） 最初に、受験地域を選んで申込みを行います。その後、受験可否の連絡があり、期限までに受験料を振り込んで、初めて受験登録完了となります。 受験地域は、宇都宮、東京、名古屋、大阪、福岡から選択できました。 会場定員の都合により、申込のタイミングによっては、受験できないことがあるため、上記のような流れになっているようです。早めに申し込む必要がありそうです。 受験準備・勉強方法 参考書籍と学習リソース JCSQEサイトの 学習方法 を参考に以下を使って勉強しました。 ソフトウェア品質知識体系ガイド － SQuBOK Guide － 第3版（約330ページ） 初級ソフトウェア品質技術者資格試験（JCSQE）問題と解説【第3版】 過去の出題内容 初級ソフトウェア品質技術者資格試験 出題解説問題の一部が解説付きで公開されています。 また、上記に加えて、試験対策アプリ（テス友）も活用しました。 勉強方法と時間配分 勉強期間は、約2カ月でした。 【2か月前】 SQuBOK Guideを3週間くらいで一通り確認し、初級ソフトウェア品質技術者資格試験（JCSQE）問題と解説も1週間くらいで全問を解きました。 【1か月前】 初級ソフトウェア品質技術者資格試験（JCSQE）問題と解説【第3版】を4周しました。 過去の出題内容も記憶するレベルまで繰り返し確認しました。 テス友で朝10問・夜10問を目標に繰り返し回答しました。 【試験直前の1週間前～直前】 ラストスパートとして、問題集とテス友を中心に最終確認を行い、間違った問題、自信のない問題のポイント、解説などをA6サイズの手のひら大ノートに復習のために整理したり、メモしました。 【受験当日】 A6サイズの手のひら大ノートを試験会場に持参し、間違った問題を中心に試験開始直前まで確認しました。 気を付ける点 専門用語の定義がJCSQEと他の資格とで微妙に異なる部分がありますので、JCSQEの定義を正確に把握する必要があると感じました。 レビュー技法は、公式なものからカジュアルなものまで、多くの種類があり、試験では、目的、参加者、実施方法などの違いをかなり細かいレベルで問われますので、表形式でまとめるなど、整理しておく方が良いと思います。 試験は、SQuBOK Guideからの出題になりますが、SQuBOK Guideは300ページ以上あり、網羅的な記載で、重要ポイントも特に明示されていませんので、暗記するのは厳しいです。私は、問題集やテス友を繰り返して、既出問題を確実に得点できるように心掛けました。 受験当日の流れ・受験後の感想 試験会場、流れ、注意事項 試験は、大阪会場で受験しました。受験者は約50名でした。 試験会場には、試験開始40分前（9時50分）から入室可能でした。 開始10分前から試験終了までは退室できず、退室すると失格となります。 試験問題は持ち帰ることはできません。 試験終了後、配布された受験票控えに印刷されたQRコードからアンケートに回答します。（所属企業に関する情報や合格した場合、氏名掲載を希望するかなど） 実際の試験での難易度と感想 試験時間60分で、40問を回答する形になります。時間は十分にありました。 SQuBOK Guideから満遍なく出題されているように感じました。半分程度は問題集、過去の出題内容、テス友で解いた記憶のある問題であったように思います。 40問中、30問は自信あり、残り10問は確信がなく、再確認を行いましたが、8割以上は正解できたという感触で、それほど難しくはないと感じました。 合格発表・結果の確認方法 試験日：　6/8(土)10:30～11:30 合格発表：8/1(木)午前 受験地域別に合格者受験番号がWebサイトに掲載されます。 氏名掲載希望者は、氏名が掲載されます。 第32回結果：260名中、139名合格（合格率53.5%） 結果通知：8/5(月)午前（電子メール） 認定証到着：8/8(木) 試験結果のお知らせと資格認定証が送付されてきました。 試験結果のお知らせには、採点結果が記載されていました。90点でした。 まとめ 今回の私の受験の取り組みをまとめると以下のようになります。 SQuBOK Guideで、ソフトウェア品質の全体像を把握する。 問題集、テス友を繰り返して、記憶として定着させる。 間違った問題は、ノートに書き出して、同じ間違いをしないように復習を行う。 また、余裕があれば、再度、SQuBOK Guideを確認することで、試験問題とSQuBOK Guideの内容がつながって、更に理解が促進されると思います。 今回の初級ソフトウェア品質技術者 資格取得を通じて、SQuBOK Guideを何度も確認することで、ソフトウェア品質の全体像を体系的に把握できたことが一番の成果であったと感じました。 是非、機会があれば、中級ソフトウェア品質技術者資格試験にもチャレンジしてみたいと思います。 The post 初級ソフトウェア品質技術者 資格試験(JCSQE)の受験体験記 first appeared on Sqripts .

以前の連載である 1人目QAとしての立ち回り では、会社や開発組織の1人目QAになった人がどのような活動をするのかや、品質保証を浸透させる際のアプローチなどについて触れました。 今回の連載では1人目QAとしてチームを立ち上げていく部分、組織づくりに関して、私が実践したことや試行錯誤中のことも含めてお伝えします。 初回である今回は、連載全体で対象とする部分の概要とQA組織を立ち上げる際の流れ、序盤に考えることになる「QA組織の形」について見ていきます。 QA組織を立ち上げる際の流れ QA組織の形について考える前に、まずはQA組織を立ち上げる前後の流れについて整理してみましょう。業種や開発組織の規模などによっても異なりますが、ここ最近筆者がみるのは以下のような流れです。 1人目QA採用フェーズ 立ち上げフェーズ 組織化・拡大フェーズ その後 順に概要を説明します。 1. 1人目QA採用フェーズ その名の通り、これまで組織にいなかったQAエンジニアを新たに採用するフェーズです。採用される側のQAエンジニア個人としてはこのタイミングでできることは基本的になく、開発部門のトップやCTO、個々の開発者などががんばる段階です。 この段階にある各社さんは、 QAエンジニアのイベントに顔を出し、交流する カジュアル面談で外部のQAに話を聞く 他社のQAに副業として支援やアドバイスを受ける など、さまざまな工夫をしながら情報を集め、採用を目指しています。 2. 立ち上げフェーズ 1人目のQAエンジニアが無事採用できたら、立ち上げフェーズになります。参画した1人目QAを中心として組織を作っていく段階です。 この段階において、1人目QAにはさまざまな役割があります。 大きくは 組織づくり と 品質向上のための活動 です。 QAエンジニアを採用したということは、開発組織としてなんらかの狙いがあります。障害が多くて困っているなど急ぎの課題を抱えている場合もあれば、今は問題ないけれど組織の今後を考えていまのうちに・・・という場合もあります。 いずれにせよ、1人目QAには開発組織内に向けたなんらかの活動と成果が求められます。これは当然ですね。このような活動を総称して、ここでは 品質向上のための活動 と呼ぶことにします。 また並行してQA 組織づくり に対しても貢献が求められます。実際に私も1人目QAとしての業務を始めた当初は、むしろこちらの割合が多いくらいでした。2人目以降の採用のため、募集要項を作成や、会社の状況や開発組織のようすなどを積極的に社外に発信したりしました。 3. 組織化・拡大フェーズ 組織化・拡大フェーズは、QAエンジニアの採用が進み、複数人のチームで動き始めている段階です。 社内に複数の開発チームが存在する場合にはQAエンジニアがそれぞれ担当を持つなど、このあと触れる開発組織とQAとの関わり方・組織パターンがわかれてきます。 4. その後 3の組織化・拡大フェーズまでの流れはある程度各社さん共通になるかと思います。しかしこの先は組織の形や規模、プロダクトの特性などに応じてさまざまな方向に分かれます。 たとえば開発組織がそれほど大きくない場合は「しばらくQAは今の体制でいこう」といった、いったん拡大をストップしてメンバーの中でできるQA活動に注力する選択もあるでしょう。 一方で規模の大きな組織、プロダクトが大きかったり、複数のプロダクトがあったりする場合には「採用して育てる」という方針をとる会社もあります。この場合は、自社内でジュニアなQAエンジニアを育てるための教育コンテンツ整備やグレード設定・評価の仕組み作りなどもQAエンジニアが担うことになります。 ここまでの内容を図にしたものが以下です。 QA組織のフェーズと活動の例 以前の連載である「 1人目QAとしての立ち回り 」は、 2. 立ち上げフェーズ における 品質向上のための活動 が主な範囲でした。 今回の連載では、主に 2. 立ち上げフェーズ 3. 組織化・拡大フェーズ における、組織づくりの面を対象とします。 QA組織の形を考える ここからは、QA組織を立ち上げる際に考えるべきポイントのひとつである、組織の形について説明します。 QA組織を立ち上げよう！と考えたときに、いきなり採用を始めるわけにはいきません。もちろん、優秀なエンジニアの採用が困難な昨今、採用活動を始めるのは早い方が良いですが、単純に複数人がいればQA組織になるわけではありません。 開発組織や会社におけるQAの立ち位置や、将来的にQA組織が何を担おうとしているのかがまず先にあって、それに応じた最適な（と思われる）組織の形があるはずです。 QA組織の形は会社や開発組織によってさまざまなものが考えられ、単一の正解はありません。自組織にとって最も良い形を模索していくことになるでしょう。 なにもないところから最適な形を考えるのは難しいため、ヒントとなる考え方を2つ、ご紹介します。 組織の形を考えるヒント：QMファンネル 1つ目は QMファンネル（3D版） です。 しばしばQAと一括りにされる、テストエンジニアとSETとQAを整理してバランスをよくするための「QMファンネル（3D版）」 QMファンネル（3D版） として、上記の資料中では説明されています。 QAエンジニアが3つ（テストエンジニア、パイプラインエンジニア、QAエンジニア）のスペシャリティに分かれており、それぞれについて5つのロール（スプリット、インプロセス、コーチ、コンサルタント、プロモーター）が存在します。 組織の形を考えるにあたって、これらのスペシャリティ×ロールをどのような構成にするのかを検討するとよいでしょう。 資料中では「ダメなロールバランスのTE組織の例」として、ロールのバランスが悪いパターンについても例示されており、こちらも見ておくと失敗を避ける役に立ちます。 ダメなロールバランスのTE組織の例(2) 斧を研がない木こり QMファンネル（3D版） より 組織の形を考えるヒント：QA組織パターン 2つ目は、このSqriptsでも連載中の 藤原 大 さんが公開している QA組織パターン – 構造ごとのメリットデメリットまとめ です。 こちらの資料では、開発チームとQAチームがどのような関係性・人の構成になっているかのパターンが6つ紹介されています。 たとえば私が現在の組織で目指しているのは、「QA組織横断組織体制（アサイン型2）」に近いものになります。 QA横断組織体制（アサイン型2） QA組織パターン – 構造ごとのメリットデメリットまとめ より このパターンでは横断組織としてのQA組織があり、そこに属するQAエンジニアがそれぞれ担当の開発チームを持つスタイルです。まだまだ組織を作っている最中なのでこの形は実現できてはいませんが、いずれは、と考えています。 このように、理想とする組織の形について検討しておくことは、採用のうえでもQA活動を行って組織にさまざまなものを浸透させていくうえでも大切です。 組織の形を考える過程では、QAチームのミッションや開発チームへの関わり方などについてもあわせて検討する必要が出てきます。たとえば開発チーム複数に対してQAが1名だとすると、内部に入り込んでのQA活動を行うのは限界があります。したがって、外から開発組織にアプローチするような動き方がメインになるでしょう。 このような開発組織へのアプローチについては、以前の記事 【第2回】組織に品質保証を浸透させるアプローチ | Sqripts にて触れていますので、こちらもご覧ください。 【第2回】組織に品質保証を浸透させるアプローチ 前回の記事では、1人目QAとは何かや1人目QAに求められているもの、そして1人目QAとしてJoinした後の立ち回りなどについて説明しました。今回は1人目QAが実際に組織の中で「品質保証」を浸透させる際のアプローチについて説明します。1人目QAの役割である「品質文化の... 　続きを読む　 Sqripts 関連記事｜Sqripts まとめ 今回は、主に1人目QAがJoinする前後の流れや、QA組織の形などについて説明しました。 1人目QAを採用する前からこういった内容が検討できるとベターですが、基本的には1人目として採用されたQAエンジニアが主体となって考えていくことになるでしょう。とくに組織の形については決まった正解がなく、悩むことも多いかもしれません。本記事でご紹介したヒント等を頼りに検討してみてください。 次回からは、 2人目以降のQAを採用する際の考え方 QA組織のチームビルディング QAとして、チームとしてのキャリアの作り方 教育や評価 など、チームを作るうえでのポイントについて幅広く触れる予定です。 【第1回】1人目QAの位置づけと、開発組織へのアプローチの仕方 ​「1人目QA」というワードを、2020年ごろからよく聞くようになりました。​もちろんそれ以前から、組織の中で1人目のQAとして活動をされてきた方はたくさんいました。しかし、QAエンジニアという職種の認知が広まったことで「いままでQA専門の人は居なかったけど、ウ... 　続きを読む　 Sqripts 関連記事｜Sqripts The post 【第1回】QA組織立ち上げの流れと組織の形 first appeared on Sqripts .

AIの世界では、ChatGPTをはじめとする生成系AIが広がり、テキスト生成モデルである大規模言語モデル（LLM）の仕事での利用も増えています。 今回紹介するオープンモデルLLMは、AI技術の発展において重要な役割を果たしています。ChatGPTのようなクローズドなLLMモデルは高性能ですが、LLMを活用したツール作成や検証などの研究目的での利用にはコスト面の課題があります。オープンモデルLLMは 無料で利用できるため、スタートアップや予算の限られたプロジェクトなどでも、柔軟に対応できる点が評価されています。また、Google Colabを使えば高性能な環境を用意せずにオープンモデルLLMを試せます。 この記事では、GPT-3やGPT-4に比べてコンパクトながら高性能な、GoogleのオープンモデルLLM「Gemma」をGoogle Colabで使用する方法を解説します。 オープンモデルLLM「Gemma」とは Gemmaの概要 Gemma は、Googleが開発した軽量で最先端のオープン型大規模言語モデル（LLM）です。Google DeepMindとGoogleの他のチームによって開発され、ラテン語で「宝石」を意味する名前が付けられています。また、Googleは2024年6月に「Gemma」の新バージョンGemma 2をリリースしました。 特徴とメリット オープンモデル : Gemmaは誰でも自由にダウンロードして利用できるオープンモデルです。 軽量: 「Gemma2 2B」「Gemma2 9B」「Gemma2 27B」の3つのサイズがあり、なかでも「Gemma2 2B」は軽量でありながら高性能を実現しており、モバイルデバイスや組み込みシステムでの活用が期待できます。 商用利用可能 : 利用規約に同意すれば、Apache License 2.0のもとで商用利用が可能です。 コスト効率 : 無料で利用できるため、スタートアップや予算の限られた組織にとってアクセスしやすいです。 幅広い利用可能性 : Google Colabなど、さまざまな環境で実行可能で、手軽に利用できる環境が整っています。 安全性 : 学習データから特定の個人情報や機密データを除外しており、安全性が高いです。 高いパフォーマンス : 主要なベンチマークで高い性能を発揮しています。 Google Colab環境の準備 それでは、Gemmaを動かす環境であるGoogle Colabについて説明します。 Google Colabについて Colab（正式名称「Colaboratory」）では、ブラウザ上で Python を記述・実行できます。Colab には、AIなど重い処理を高速に実行できるGPUが使用でき、しかも無料で使えます。特徴としては、以下の点があります。 環境構築がほぼ不要 簡単に操作が可能 無料でGPUが使用できる 共有が簡単にできる 注意点 便利なGoogle Colabですが、無料プランは次のような制限があります。 90分何も操作しないとリセットされる インスタンス起動してから12時間経つとリセットされる GPUを使いすぎると、しばらくGPUを使えなくなる（CPUは使用可能） 有料プランにすることで、上記を制限なく使うことができます。また、より速いGPUが使えたり、より多くのメモリを使えたりするメリットもあります。無料プランで物足りない場合は、検討してみても良いでしょう。また、Google Colabを使用するにあたり、APIキーやパスワードのような機密情報を扱う際には、コードに直接埋め込むことは推奨されません。秘匿情報を安全に扱うために「シークレット機能」を使いましょう。具体的な使い方は、後ほど説明します。 事前準備 早速、Google Colab を使っていきましょう。まずは、Gemmaを動かすための新規のノートブック(作業する場所)を作成するところから解説します。 Google アカウントにログインした上で、以下の公式サイトにアクセスしてください。 https://colab.google/ [New Notebook]をクリックして、新規のノートブック(作業する場所)を作成します。 すると、このような画面が表示されます。 新規のノートブックの[編集]-[ノートブックの設定]を選択し、ハードウェア アクセラレータで、「T4 GPU」を選択します。「CPU」のままでGemmaを動かすと、処理スピードが非常に遅いので、必ず変更してください。 Gemmaを利用するために、KaggleでAPI Tokenが必要です。まずは、以下のサイトにアクセスし、[Request Access]を押下して、Kaggleに登録して、Gemma利用規約に同意してください。 https://www.kaggle.com/models/google/gemma/ 以下のように表示されれば登録完了です。 次に、API Tokenを生成します。アカウント設定ページにアクセスして、[API]のセクションで「Create New API Token」をクリックします。ダウンロードしたjsonファイルに、usernameとkey(API Token)が記載されています。これは、後ほど使用します。 これで事前準備は完了です。 Gemmaのセットアップ手順 それでは、早速Gemmaを動かしてみましょう。 Gemma in PyTorch に記載されている情報を参考に、実行していきます。 まずは、先ほど入手したusernameとkey(API Token)を、「シークレット」に登録します。「新しいシークレットを追加」を押下して、KAGGLE_USERNAMEと、KAGGLE_KEYを追加、usernameとkey(API Token)をそれぞれの値の部分に入力します。 次にシークレットの情報をプログラムで読み込みます。 [+コード]を押下して、次のプログラムコードを入力します。全て入力が終わったら、「Shift + Enter」を押します。これにより、先ほど入力したセルのプログラムを実行して次のセルが選択されます。（以後、プログラムコードの実行は全て「Shift + Enter」で行います。） import os from google.colab import userdata # `userdata` is a Colab API. os.environ["KAGGLE_USERNAME"] = userdata.get('KAGGLE_USERNAME') os.environ["KAGGLE_KEY"] = userdata.get('KAGGLE_KEY') これで、KAGGLE_USERNAMEとKAGGLE_KEYをプログラム中で使用できます。プログラム中に直接usernameとkey(API Token)を記載すると、セキュリティ的に良くないので、シークレット機能を活用してください。 次にGemmaを動かすのに必要な各種ライブラリをインストールします。 !pip install -q -U torch immutabledict sentencepiece モデルの重みをダウンロードします。 ここでは、Gemma2 2Bモデルの指示用調整（IT）「2b-it」を選択しています。9Bや27Bモデルは、無料のGoogle Colabでは、メモリの関係で動かせませんでした。 # Choose variant and machine type VARIANT = '2b-it' #@param ['2b', '2b-it', '9b', '9b-it', '27b', '27b-it'] MACHINE_TYPE = 'cuda' #@param ['cuda', 'cpu'] CONFIG = VARIANT[:2] if CONFIG == '2b': CONFIG = '2b-v2' import os import kagglehub # Load model weights weights_dir = kagglehub.model_download(f'google/gemma-2/pyTorch/gemma-2-{VARIANT}') # Ensure that the tokenizer is present tokenizer_path = os.path.join(weights_dir, 'tokenizer.model') assert os.path.isfile(tokenizer_path), 'Tokenizer not found!' # Ensure that the checkpoint is present ckpt_path = os.path.join(weights_dir, f'model.ckpt') assert os.path.isfile(ckpt_path), 'PyTorch checkpoint not found!' モデル実装をダウンロードします # NOTE: The "installation" is just cloning the repo. !git clone <https://github.com/google/gemma_pytorch.git> import sys sys.path.append('gemma_pytorch') from gemma.config import GemmaConfig, get_model_config from gemma.model import GemmaForCausalLM from gemma.tokenizer import Tokenizer import contextlib import os import torch モデルをセットアップします # Set up model config. model_config = get_model_config(CONFIG) model_config.tokenizer = tokenizer_path model_config.quant = 'quant' in VARIANT # Instantiate the model and load the weights. torch.set_default_dtype(model_config.get_dtype()) device = torch.device(MACHINE_TYPE) model = GemmaForCausalLM(model_config) model.load_weights(ckpt_path) model = model.to(device).eval() サンプルテストの実行 具体的なプロンプト（LLMに対する命令）を入力し、その応答を確認してみましょう。 Wikipediaの「人工知能」 の冒頭の解説文章を要約させてみます。 ※以下では、文章を途中省略していますが、実際に実行する際は、Wikipediaの文章を入力しています。 prompt = """ 次の文章を100文字に要約してください。 人工知能（じんこうちのう、英: artificial intelligence）、AI（エーアイ）とは、「『計算（computation）』という概念と『コンピュータ（computer）』という道具を用いて『知能』を研究する計算機科学（computer science）の一分野」を指す語]。 （中略） 「われわれは少し先までしか分からないが、多くのやるべきことが残っているのは分かる」。 """.strip() # Generate sample model.generate( prompt, device=device, output_len=4096, ) 要約結果は次のようになりました。 Gemma2の出力 AIの発展が非常に急速な進歩を遂げている一方で、今後さらに発展する可能性は十分にあり、その将来の進化をどのように予測するのかについては、まだ明確な答えは見つかっていない。 <end_of_turn> ChatGPT-4oとの比較 大規模な商用モデルであるChatGPT-4oと比較してみました。 ChatGPT-4oの出力 人工知能（AI）は、計算機を用いて知能を研究する計算機科学の分野であり、言語理解や推論などをコンピュータで実行させる技術である。AIは歴史的に大きく発展してきたが、未来に向けてさらなる課題が残っている。 Gemma2とChatGPT-4oの出力結果を比較すると、どちらも要約の質は非常に高く、甲乙つけがたいと言えます。どちらも程よくまとまっており、ユーザーにとって有益な情報を提供しています。ただし、処理速度に関してはChatGPT-4oが圧倒的に優れており、これは使用しているマシンスペックの違いによるものと思われます。どちらのモデルもそれぞれの強みを持っており、用途に応じて使い分けることで、より効果的にAIを活用することができます。 Colab上のGemma2：3分 ChatGPT-4o：5秒 実務に利用できるか さて、簡単に動かすことができたGemmaですが、実務に使えるかどうか、考えてみましょう。オープンモデルLLMであることから、次のようなシチュエーションで有益ではないでしょうか？ 運用におけるコスト削減したい、低コストで試験的に導入したい セキュリティが厳しい環境でも社内データをLLMで活用したい 特定ドメインにおける自動化、効率化を図ったり、社内サーバーで安定して運用したい 社内のドキュメントを簡単に要約したい ただ、課題がないわけではありません。 パフォーマンス 商用のLLMに比べ、OSSモデルのパフォーマンスはやや劣る場合が多いです。特に、生成タスク（クリエイティブな文章作成やコード生成など）では、商用モデルの方がより洗練された結果となります。 スケーラビリティ 大規模なOSS LLMを実務環境に導入するには、計算リソースが必要となり、その運用コストがかさむ場合があります。また、OSS LLMのモデルは商用モデルと比べて最適化されていないことが多く、パフォーマンスのチューニングが必要となってきます。 特定分野への適用 OSSモデルは一般的なデータで訓練されていることが多く、特定の業務ドメイン（例えば法務や医療）に対する特化はされていません。そのため、専門的なドメインに適応させるには追加のデータセットとトレーニングが必要です。一方、クローズドなモデルでは、特定のドメインに対応するよう事前に最適化されている場合が多く、専用のトレーニングデータやパラメータ調整が行われているため、特定分野への迅速な適応が可能です。これにより、企業や専門機関は必要なセキュリティやプライバシー保護を維持しつつ、高精度なモデルを利用できるメリットがあります。 まとめ 本ブログでは、Google Colabを利用してGemmaを実行することで、誰でも簡単に高度なAI技術を試すことができることが、確認できました。Gemmaに加え、Llama3やBLOOMなど多くのオープンソースLLMが存在し、それぞれの特徴と強みを活かして、AI活用の幅広い選択肢が提供されています。 AI技術の進化により、誰でも高性能なAIを手軽に利用できる時代が到来しました。技術の民主化が進み、個人や中小企業でもAIを活用したサービスやツールを簡単に開発・利用できるようになっています。弊社でも、AIを活用したサービスとして「AIテクニカルコードレビュー」や「AIデバッグ」を提供しており、これらのサービスは開発プロセスの効率化と品質向上に大いに貢献しています。今後もAI技術の進化に伴い、さらに多様なサービスが登場し、私たちの生活やビジネスに新たな可能性をもたらすことが期待されます。 ▼関連記事はこちら AIを使ってコードレビューをやってみた ｜Sqripts AIの目で見るバグの世界 ｜Sqripts The post Googleの作ったオープンモデルLLM「Gemma」をGoogle Colabで使ってみる first appeared on Sqripts .