こんにちは。クオリティマネージャーのおすぎです。 プロジェクトマネージャーやテストマネージャーといった、プロジェクト管理を担う方であれば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 .

ソフトウェア開発の世界では、アジャイル開発やスクラムが一般的になってきました。そのアジャイル開発のコアとも言えるのが、対話や協調です。この連載では、アジャイル開発におけるコミュニケーション・コラボレーションスキルを解説しながら、ファシリテーションスキルのレベルアップを目指します。 ＜スクラムマスターのためのコミュニケーション講座　連載一覧＞ ※クリックで開きます ・ #イントロダクション：優れたスクラムマスターが絶対に言わないこと 【連載初回、全文公開中】 ・ あなたの提案はなぜ受け入れられないのか？｜ファシリテーション技術-1- ・ よりよい場を作るための9つのルール［前編］｜ファシリテーション技術 -2- ・ よりよい場を作るための9つのルール［後編］｜ファシリテーション技術 -3- ・ コーチング技術 〜 基本技術を学ぼう｜コーチング技術 -1- ・ コーチング技術 〜 質問力を高めよう｜コーチング技術 -2- ・ 上級者が活用する質問例｜コーチング技術 -3- ・ 実践1on1[1] 〜 簡単だけど難しい1on1 ・ 実践1on1[2] 〜 コミュニケーションの方法を使い分けよう！ ・ 実践1on1[3] 〜 相手に合わせたコミュニケーション方法とは？ 第3回目のテーマは、1on1においてコミュニケーション方法を使い分けるために「コミュニケーションのタイプ」を学びます。 前回のおさらい 前回はコミュニケーションの方法について解説しました。 コンサルティング ティーチング（トレーニング・メンタリング） カウンセリング ファシリテーション コーチング 1on1 それぞれ特徴があり、使い分けができることがわかりました。 今回はこれらの方法の使い分け方を解説します。 コミュニケーション相手別の使い分け 私はアジャイルコーチとして働いていますが、コーチングだけでなくコンサルティング（可能な限り現段階でのベストプラクティスを提供する仕事）も行っています。 たとえば、ITに詳しくない方や、新卒で社会人になったばかりの方に対しては、コンサルティングやティーチングが有効です。なぜなら、まだ知らないことが多いため、課題と解決策の間に大きなギャップがあり、なかなかゴールにたどり着けない状況になりがちだからです。 逆にCTOやエンジニアリングマネージャなど、相手のITスキルが高い方の場合はどうでしょうか？ 彼らは私に負けない知識や経験を持っている可能性があります。下手をすれば私より詳しいかもしれません。あるいは、知識や経験がなくても、それを身につけるポテンシャルを持っているかもしれません。この場合、コンサルティングやティーチングによって、学べる機会を奪ってしまう可能性もあります。 そういった人たちに「コンサルティング」や「ティーチング」は有効に機能しません。 こういった問題を避けるために、 相手や課題の領域によって、コミュニケーション方法を変えていく必要があります。 コミュニケーション方法の使い分け コミュニケーション方法の変化についてまとめたのが上記の図です。代表的な3つの方法をベースに解説します。 まず、コンサルティングは解決策を伝える方法なので、未経験者やすぐに解決策が欲しい人に対して有効な手段です。デメリットをあえてあげるなら、学ぶ機会が失われます。 次に、ティーチングやトレーニングは、新しい方法やスキルを学ぶ効果的な手段です。残念ながら、誰でも有効的に学びを得られるわけではなく、学べばスキルを身につけられる人にマッチする方法と言えます。参加するだけでは得られないことも多く、学ぶ姿勢や学びをのちに活用できるスキルが必要です。 最後のコーチングは、相手の中に答えがあるのが前提となるため、あくまで相手が答えを見つけるための支援を行う方法です。支援と入っても、助けるのではなく、一緒に答えを見つけていく伴走型の方法になります。よって、未経験者にコーチするよりも、経験者や自律して考えられる人に対して行うケースが多くなります。 このように、相手の経験やスキルによって、コミュニケーション方法を使い分けて対応していくのが効果的です。相手が求めるものに対して、適切な方法を選ぶのがプロフェッショナルなコミュニケーションの使い手と言えます。 余談ですが、前回でも解説した通り、1on1はコミュニケーション方法を、相手や状況に合わせて使い分けるコミュニケーション方法です。よって、最低限でも上記3つの方法を理解し使いこなせるようになる必要があり、相手や状況に合わせてうまく切り替えながら、クライアント（部下）に成果を出させなければなりません。 さまざまな方法を知るだけでなく、成果も出さなければならないのが1on1が難しい理由のひとつだと思います。 コミュニケーションタイプ別の使い分け 相手の経験やスキルによって、コミュニケーション方法を使い分ける必要性を解説しました。もうひとつ考えておきたいことがあります。それは、コミュニケーションのタイプです。 コミュニケーションのタイプについては、有名なもののひとつにDiSC理論（参考： DISC assessment ‐ Wikipedia ）があります。これはアメリカの学者が提唱したコミュニケーション理論で、おおきく4つのタイプに分類しています。 支配タイプ （D: Dominance）は、問題を克服するために、積極的に力を利用するタイプです。いわゆる従来型のリーダータイプで、チャレンジ精神が旺盛で、成果を追い求める傾向があります。 感化タイプ （i: influence）は、問題を解決するために、人をうまく操るタイプです。持ち前の社交性を活用しながら場の雰囲気を読み取り、着地点をうまく見つけるスキルが高いタイプと言えます。 提案タイプ （S: Submission）は、問題解決のアイデアを受け入れ、決まったことに対しては従順に遂行していくタイプです。協調性が高いため、コミュニケーション相手の立場に立って物事を考えてくれるタイプと言えます。 コンプライアンスタイプ （C: Compliance）は、ロジカルに物事を考えるタイプです。計画を重視し、法令や規則、ルールを厳守します。少し堅いイメージがありますが、慎重に物事を進めてくれる安心感があるタイプと言えます。 血液型占いと同じく、すべての人類が4つのタイプに分けられるわけではないですが、大きく分類することで、それぞれの特徴に合わせたコミュニケーション方法を考えられます。それぞれのタイプ別のコミュニケーションを見てみましょう。 支配タイプへのコミュニケーション 支配タイプは、ぐいぐい進むリーダータイプです。遠回しな表現よりも、単刀直入なコミュニケーションを好む傾向があります。 支配タイプは、細かい点を気にしないので、アクションをゼロから考えるよりも、選択肢をいくつか提示して議論したほうが物事が進みやすくなります。内容が曖昧だと「つまりどういうこと？」となりがちなので、解像度の低いものを持ち込むより、精度が高めのものを持ち込む方が良いでしょう。 支配タイプに何かを伝えたいときはどうするのがよいのでしょうか？ たとえば、細かい点を気にしないので、要点だけを伝える方法があると思います。また、誰かに指示されるよりも自分でリードしたいため、「まかせる」と裁量を大きく与えるのもひとつの手でしょう。 感化タイプへのコミュニケーション 社交性の高い感化タイプは、時代や流行にも敏感で、アイデアをどんどん出していくコミュニケーションを得意としています。よって、相手が出してくる情報をどんどん承認すると（頷いたり関心を持つ）、パフォーマンスが上がっていく可能性があります。 何事もポジティブに受け止めてくれる感化タイプですが、逆に細かい点が苦手なので、支配型から見ると「よくしゃべるけど、結局何がしたいの？」となりがちです。また、細かい点を議論するより、広い視点での議論のほうが盛り上がります。 感化タイプに何かを伝えたいときはどうするのがよいのでしょうか？ 影響力を気にするタイプなので、先にも書きましたが承認を多く行うことが効果的です。いわゆる褒めて伸びるタイプと言えます。逆に、人前で怒られるのが苦手なので、悪いフィードバックは個別に伝え、今後への期待も添えて伝えるといいでしょう。 提案タイプへのコミュニケーション 協調性の高い提案タイプは、衝突をできるだけ避けて物事をすすめるのが得意です。聞くのが上手なので、感化タイプとの相性はとても良いでしょう。 物事を平穏に進めるスキルは高いと言えますが、ディスカッションやディベートといった議論をぶつけるやりとりが苦手です。安定性を求める傾向があるので、チャレンジングな支配タイプが苦手になるかもしれません。 提案タイプに何かを伝えたいときはどうするのがよいのでしょうか？ 協調性の高さから自分の意見が言えていない可能性があるので、何かを決める場合、じっくり何回も確認するのが良いでしょう。相手のことを感じ取る能力に優れているため、こちらからも積極的に言葉をかけたり、しっかり反応したりするふるまいがマッチします。 コンプライアンスタイプへのコミュニケーション コンプライアンスタイプは、計画性が高く、正確に物事を進めるのが得意です。じっくり作戦を練り、確実に成功する方法を選ぼうとします。 逆に言うと変化に弱いと言えます。頭で理解できないと前に進めない傾向もあり、チャレンジングに進めようとする支配タイプとの相性は悪いかもしれません。 コンプライアンスタイプに何かを伝えたいときはどうするのがよいのでしょうか？ 曖昧な言葉を使うより、具体的な言葉を使ったほうが伝わるでしょう。感覚に任せて話すより、ロジカルにロジックを積み上げるほうが共感されます。すぐに結論を出すのが苦手なので、関連するデータや事例を集めて提示するほうが納得感を持ってくれるでしょう。 ＊ 今回は、具体的なコミュニケーションの使い分け方法を解説しました。経験やスキルに合わせて方法を変えたり、相手のタイプによって使い分ける方法を紹介しました。 コミュニケーションタイプの分類は、今回紹介したDiSC理論だけでなく、いろんなものが存在します。 【図解】「タイプ分け 」とは 〜あなたはどのタイプ？タイプ分けで上手くいくコミュニケーション – HELLO, Coaching! あなたは何タイプ？コミュニケーション上手になるための4タイプ診断法 – リクナビNEXTジャーナル 相手だけでなく自分のタイプを見分けることにも利用できます。自分のタイプが分かると、苦手なタイプが分かり、対策を打ちやすくなるからです。 次回は実践例を参考に1on1のレベルを高めていきましょう。 連載一覧 ・ #イントロダクション：優れたスクラムマスターが絶対に言わないこと 【連載初回、全文公開中】 ・ あなたの提案はなぜ受け入れられないのか？｜ファシリテーション技術-1- ・ よりよい場を作るための9つのルール［前編］｜ファシリテーション技術 -2- ・ よりよい場を作るための9つのルール［後編］｜ファシリテーション技術 -3- ・ コーチング技術 〜 基本技術を学ぼう｜コーチング技術 -1- ・ コーチング技術 〜 質問力を高めよう｜コーチング技術 -2- ・ 上級者が活用する質問例｜コーチング技術 -3- ・ 実践1on1[1] 〜 簡単だけど難しい1on1 ・ 実践1on1[2] 〜 コミュニケーションの方法を使い分けよう！ ・ 実践1on1[3] 〜 相手に合わせたコミュニケーション方法とは？ The post 実践1on1[3] 〜 相手に合わせたコミュニケーション方法とは？ first appeared on Sqripts .

こんにちは、AGESTのバックエンドエンジニアのまさです。 今回は、CursorエディタのComposer機能を用いて、AIにテストコードを記述してもらう方法をご紹介します。テストコードはソフトウェアの品質を高めるために重要ですが、手作業で書くのは時間がかかるものです。そこで、AIの力を借りて効率的にテストコードを生成してみましょう。 具体的な手順やコード例を交えながら、詳しく解説していきます。 ※今回ご紹介するCursor Composerは現時点ではPro版でないと使用できないようですので、その点だけご注意ください。なお、Free版には2週間のPro版トライアルがついています。 【参考】 Cursor Pricing（価格表） Cursorエディタとは Cursorは、VSCodeをフォークしたAI活用型の新しいコードエディタです。VSCodeユーザーであれば、馴染みのあるインターフェースと操作性で、移行しても違和感なく利用できます。コード補完機能やリファクタリング支援など、開発者の生産性を向上させるための機能が豊富に備わっています。Composer機能を使うことで、コード全体の分析やコードの自動生成が可能です。 環境構築 Cursorのインストール まずは、公式サイトからCursorをダウンロードし、インストールします。 Cursor公式サイト インストール後、Cursorを起動します。 Cursor起動後、ユーザー設定 > Cursor Settingsを開きます。 設定メニュー内の「Features」内のComposerをenabledに設定します。 プロジェクトの準備 テスト対象のコードを用意します。ここでは、Go言語を使用した例を示しますが、他の言語でも同様の手順で進められます。 example/ ├── main.go └── utils/ 　　　 ├── example.go 　　　 └── item.go テスト対象のコード作成 まずはテストに使用する構造体を utils/item.go に実装します。 package utils // Item構造体を定義します type Item struct { ID int // アイテムのID Name string // アイテムの名前 Price int // アイテムの価格 } 次にテスト対象となる関数を utils/example.go に実装します。 // utilsパッケージに含まれるユーティリティ関数を定義します package utils // ItemsTotalPriceは、与えられたItemスライスの合計価格を計算します func ItemsTotalPrice(items []Item) int { total := 0 // 合計価格を初期化 // 各アイテムの価格を合計に加算 for _, item := range items { total += item.Price } return total // 合計価格を返却 } Composer機能を使ったテストコードの自動生成 テストコードを生成する手順 example.go ファイルをCursorで開きます。 Ctrl + i をキー入力します。 CursorのComposerの入力画面が表示されます。 入力ファイルの「+」を押下し、item.goを追加します。 プロンプトに「ItemsTotalPriceに対するテストコードを作成してください。」と入力します。 ComposerがAIを利用してテストコードを生成します。 生成されたテストコードの確認 自動生成されたテストコードは以下のようになりました。 import ( "testing" ) /** * TestItemsTotalPrice は ItemsTotalPrice 関数のテストを行います。 * * このテストでは、以下のケースを確認します： * 1. 空のスライスの場合 * 2. 1つのアイテムを含むスライスの場合 * 3. 複数のアイテムを含むスライスの場合 * * @param t *testing.T テストを実行するためのテストオブジェクト */ func TestItemsTotalPrice(t *testing.T) { // テストケースを定義 testCases := []struct { name string items []Item expected int }{ { name: "空のスライス", items: []Item{}, expected: 0, }, { name: "1つのアイテム", items: []Item{ {ID: 1, Name: "アイテム1", Price: 100}, }, expected: 100, }, { name: "複数のアイテム", items: []Item{ {ID: 1, Name: "アイテム1", Price: 100}, {ID: 2, Name: "アイテム2", Price: 200}, {ID: 3, Name: "アイテム3", Price: 300}, }, expected: 600, }, } // 各テストケースを実行 for _, tc := range testCases { t.Run(tc.name, func(t *testing.T) { // ItemsTotalPrice関数を呼び出し result := ItemsTotalPrice(tc.items) // 期待される結果と実際の結果を比較 if result != tc.expected { t.Errorf("期待される結果: %d, 実際の結果: %d", tc.expected, result) } }) } } テストコードの解説 アイテムが空の場合 : 空のスライスを渡した場合に合計が0になるかを検証。 アイテムが1つの場合 : 単一のケースで合計価格が正しく計算されるかを検証。 アイテムが複数の場合 : 通常のケースで合計価格が正しく計算されるかを検証。 それぞれのケースで、期待される合計価格と実際の結果を比較し、不一致があればエラーメッセージを出力します。 コードの実登録 上記で確認したテストに問題がなければ「Accept all」を押下します。 再度 Ctrl + i キーを押下すると、エディタ画面に復帰すると、utilsディレクトリ配下にutils_test.goが作成されていることが確認できます。 テストコードの実行 ターミナルで以下のコマンドを実行し、テストを確認します。 go test ./... すべてのテストがパスすれば成功です。 Composer機能の利点 入力ファイルの複数指定 ：Composerの大きな利点はここにあると思います。実は今回のようなケースではgithub copilotでも同様のことは実現できます。ただし実際に実用的な良いコードを生成しようとするならば単一のファイルやコードを入力に生成することは難しく、プロジェクト内の多様なソースを複数参照したうえで生成する必要があります。このCursorのComposerであれば複数のファイルを入力に指定できるため、必要な入力を全て与えることが可能です。 ファイルの生成 ：既存の生成ＡＩではコードを画面に出力することはできても実際にファイルを生成するということはできませんでしたが、Cursorであれば提案された内容のファイルをそのまま出力してくれます。 ファイルの修正の提案 ：処理の修正が必要なとき、そのまま書き換えてしまうのではなく修正候補として表示され、キー入力により同意することで反映されるようになっています。一つ一つの修正内容をしっかりと確認した上で、提案を適用しやすくなっています。 おわりに CursorのComposer機能を活用することで、テストコードの作成が格段に効率化されます。特に、複数のファイルを入力させることにより、今までよりもずっと実用的なコード生成が可能となっています。 また、今回はあくまでテストコードの生成としてご紹介しましたが、もちろんメインのコードの生成も可能です。仕様をプロンプトに入力しコード生成させることでメインのソースを組み立てていくことができますし、既存の処理の修正も可能です。もちろん最終的には自身の目でレビューする必要があるということは他のAIツールと同様です。 今後もAIツールを積極的に活用し、開発効率とコード品質の両立を目指していきたいと思います。 参考 Cursor公式サイト Go言語公式サイト Visual Studio CodeとGitHub Copilotでコーディング効率を革新！AIを駆使した開発ガイド こんにちは。GSです。Visual Studio CodeとGitHub Copilotの組み合わせは非常に強力です。多くの人が「GitHub Copilotを使う＝コード自動補完を使う」と考えているかもしれませんが、Visual Studio Codeのアップデートにより、さらに便利な機能が使えるようになって... 　続きを読む　 Sqripts 関連記事｜Sqripts GenieAIでコードの品質を高めよう｜VSCode拡張機能GenieAIを用いてコード品質を高める手法 こんにちは、バックエンドエンジニアのまさです。前回のVSCodeでgithub copilotを使った開発効率向上の話に引き続き、今回はVSCodeでGenieAIという拡張機能を用いてコード品質を高める手法のご紹介をしたいと思います。OpenAIのAPIキーが必要になりますが、こちらも... 　続きを読む　 Sqripts 関連記事｜Sqripts The post CursorのComposer機能でAIに0からテストコードを作成してもらう first appeared on Sqripts .

本連載ではプロジェクトマネジメントの全体像と、プロジェクトを成功させる上で最低限抑えるべき知識と技術はもちろん、プロジェクトを炎上させないための技術やコツをお伝えしたいと思っています。 みなさんのプロジェクトが今以上に充実し、笑顔でプロジェクト終結を迎えられるよう一緒に学んでいきましょう。 ＜ プロジェクトマネジメント成功の技術 連載一覧＞ ※クリックで開きます 【第1回】プロジェクトマネジメントとは何か？ ［全文公開中］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ 【第8回】コストをプロジェクトの武器にする！ 【第9回】目に見えにくいプロセス管理こそ品質達成の鍵 【第10回】プロジェクトのリスクマネジメント［前編］リスクを徹底的に洗い出す 【第11回】プロジェクトのリスクマネジメント［後編］リスク分析とコンティンジェンシープラン 【第12回】人がプロジェクトの源泉！チームは育てて強くする［前編］ 【第13回】人がプロジェクトの源泉！チームは育てて強くする［後編］ 【第14回】コミュニケーションの本質を知り、使いこなそう！ 【第15回】笑顔で終わるプロジェクトはここが違う！プロジェクトクロージングのTODO ［全文公開中］ 本連載もいよいよ最終回となりました。今回はプロジェクトの終了についてお話しします。 プロジェクト終了（クローズ）時の営みは 【第4回】プロジェクトの統合マネジメント、7つのプロセス の (7) でもお話したように、プロジェクト活動における「最後の活動」です。 ＜統合マネジメント：7つの活動＞ (1) プロジェクト憲章の作成 (2) プロジェクトマネジメント計画書の作成 (3) プロジェクトへの指揮とマネジメント (4) プロジェクトに関する知識のマネジメント (5) プロジェクト実行の監視とコントロール (6) 統合変更管理の実行 (7) プロジェクトクローズ　←こちら ではなぜ改めてこのプロジェクトクローズをおさらいするのでしょうか？それはPMBOKには詳しく書かれていない重要なポイントがあるからです。多くの人がプロジェクトの完了（done）と終結（close）を混同したり、終結に必要な活動をどうしてもおざなり（省略）にしがちです。プロジェクトを正しくクローズすること、これまでの活動をどのように「活かす」ことができるのか。大変だったプロジェクトもそうでなかったプロジェクトも、最後には笑顔で締めくくれるよう改めて学んでいきましょう。 プロジェクトの終結 1) 終結の定義 プロジェクトって成果物が完成したり納品できたら終わりじゃないの？ PMBOKでは「プロジェクト、フェーズ、または契約上の全ての活動を完結するプロセス」と定義されています。つまり、単純に目的目標の達成や成果物の納品「だけ」では物足りないということがわかりますね。またプロジェクトが経た活動や情報が保管（蓄積）且つ完了された状態で、プロジェクトに集結させていたリソース等も適切に解放（返却）させなければなりません。 2) 実施するクローズ活動と終結基準として確認したいこと 全ての文書と成果物が最新状態であることを確認する 全ての課題が解決されていることを確認する（または適切に申し送り事項として管理されていることを確認する） 成果物の検修完了を確認する プロジェクトの会計を終えている（未払い等がない状態を指す） 人的資源（人員）を返却する（プロジェクトから定常業務へ配置転換する） プロジェクトで利用した各種資源の返却や再分配を行う プロジェクト報告など必要なドキュメントを作成し報告を完了する プロジェクトの知識や教訓を特定、整理し、将来活用できるよう情報保管する ステークホルダーの満足度特定（アンケートやヒアリングの実施） これらの対応は相当の時間を要します。またクローズ時に全てを行おうとしても必要な情報が収集できなかったり、プロジェクト冒頭の事は失念してしまうこともあるでしょう。PMはプロジェクト期間を通して、プロジェクト実行や監視と並行してこれらの整理・準備少しづつ進めておきましょう。 組織と未来のプロジェクトへ、フィードバックは完璧に 1) 必ず作ろう終了報告書 プロジェクトは、上手くいったなと思う場合とそうでもない時があるはずです。反省の多いプロジェクトで終了報告を書くのは少々辛く感じるかもしれませんが、プロジェクトが失敗しても成功しても、PMの活動・イベントとして必ずその終了時には「プロジェクト終了報告書」を纏めましょう。「成果物が完成し、いつの間にかPJ体制が解消された」というケースをよく見ます。また「あれ？XXプロジェクトって終わってたんだ、どうだったの？」と周囲に確認されることがないように「正式に終わらせる」ためにも報告が大切です。 以下に簡易的なプロジェクト終了書の項目例を示してみました。項目や記載のボリュームはプロジェクト規模によって異なります。プロジェクトが終了しても残課題や申し送り事項がある場合が少なくありません。その為、終了報告書はプロジェクトの結果報告だけでなく記載した事項を漏れなく「引き継ぐ」という役割も持っています。プロジェクトが成功した場合にも、その成果物を定常業務＝運用に引き継ぐ役割もあります。プロジェクト活動の成果や残課題などを適切に引き継ぐことができなければ、後にプロジェクトに関連する活動でトラブルが発生した際などにズルズルと対応に追われることになるでしょう。 2) 未来に残す手紙 繰り返しになりますが、終了報告書は実施したプロジェクトのみならず、未来の活動（定常業務・プロジェクト・組織の活動等）の為に「プロジェクトで得た経験を蓄積し伝えていく」役割があります。あまりプロジェクト活動が上手くいっていない組織によく見られるのが「何度も同じ失敗や辛い体験を繰り返す」ことです。そうするとメンバーは「また同じことの繰り返しだ…」「全く改善されない…」と疲弊しモチベーションも下がってしまいます。 プロジェクトの目的目標が達成されれば必然的にチームは解散します。その際に適切に終結活動を行わないと、折角のプロジェクト活動で得られた経験や知識、技術も残らなくなってしまいます。よく聞く「XXプロジェクトを経験したXさんなら知っている」という類のものも、経験・知識が蓄積されているように見えて属人的な情報であり、組織の知恵になっておらずとても勿体無いです。プロジェクト終了報告書は別名「教訓報告書」とも呼ばれますが ＜教訓＝Lesson &Learn＞ として知識や技術を残すことがPMとしての最後の重大なお仕事です。 こうしておけばよかった、という改善点もあれば、これは次も使えるといったベストプラクティスは再現できるように継承しましょう。教訓はPMだけでなくメンバーと共に整理できるとよいです。教訓という言い方だと難しく考えてしまうかもしれませんが、未来に残す手紙・メッセージと考えると、スムーズに「伝えたい」ことが書き出せるはずです。 3) 終了報告書に必要なステップ 終了報告書が完成したら、プロジェクトオーナーや主要なステークホルダーに報告し「承認」を貰いましょう。報告に際してはできれば対面が望ましいですが、難しい場合はメールの一文でもいいので「承認した」旨の返信エビデンスを残すようにしてください。承認者であろうプロジェクトオーナーは活動期間中にさまざまな形でプロジェクトに心を傾けてくれた人物です。報告の場でプロジェクトの成果を伝えることはもちろん、PM自身が感じた想いを伝えたり、POへ感謝を伝えることも忘れずに行いましょう。 終了報告書が承認され「PJお疲れ様、終了してもいいよ！」となってはじめてプロジェクトは正式な終了を迎えます。ただしここで「なんだ、XXができていないならPJ終了は認めない」「報告書の記載が不十分」といったように＜差し戻し＞があることはゼロではないので（筆者も経験があります）、そのような事態にならないよう必要十分な報告と申し送り対応の説明などを行うように気をつけましょう！ 自信を持ってプロジェクトを終わらせるために 1) アンケート活用で暗黙知や見えにくい意見をあつめる プロジェクト参加者やメンバーが多い場合や、クロスファンクショナルなチームの場合などには振り返りにプロジェクトアンケートも活用してみましょう。「大勢の場では発言しにくいが、こう思っている」「他でこういう成功例があたので、取り入れてみたい」といったメンバーそれぞれの思いに気付けたりアイデアがでてくることも。2)にあるような「振り返りミーティング」は時間も限られ、またどれだけ工夫をしたとしても発言しにくいケースもあるでしょう。時折「振り返りミーティングを実施したけれど、当たり障りのない発言しかでなかった」「意見がでなかった」と耳にしますが、それらを補完するための工夫としてぜひアンケートを活用してみてください。 ※アンケート実施の際は、アンケート回答がプロジェクト教訓収集等に限定して使用され、個人を特定するものではないといったアンケートポリシーを記載しましょう。 2) 振り返りはナレッジの宝庫 プロジェクト終了の承認が得られた（得られるだろう）時点で、チームでの振り返りミーティング（クローズドミーティング）を準備・実施しましょう。プロジェクトの開始にキックオフがあったように、終了時にはプロジェクトクローズがセットの活動です。終了報告書と同様に、クローズドミーティングはプロジェクトのナレッジを集約し、未来に教訓を残す為に欠かせないイベントですが、目的は経験から学ぶ事であって決してネガティブになったり結果を非難するものではないことに気をつけましょう。またプロジェクトと組織の問題が混同し散漫になりがちですので、それぞれに対する意見は個別に述べてもらうなどの工夫もしてみましょう。 例えば会の冒頭に、以下のような振り返りの目的、ルール、怒ってほしくないことなどを記載し、参加者に伝えるとよいでしょう。 ＜振り返る目的：例＞ プロジェクトで得た気づきを整理、相互に共有し、多角的にプロジェクトを振り返る 後続プロジェクトや定常業務に活かすことのできる教訓を得る 良い点に再現性を持たせ、問題点は繰り返さないようにする プロジェクト結果をレガシーとして残す ＜ルール：例＞ もう一度同じプロジェクトをするなら、または次に向けたポジティブなスタンスで振り返えろう 全てにおいて、個人の称賛/批判ではなく、プロジェクトやプロダクトをより良くするという観点を持とう 振り返りを「次に活かす貴重な教訓＝資産を得る場」だと考えよう ポジティブ&ユーザーハッピーの視点で考えよう 振り返りにはKPTフレームワークやYWTフレームワークなど使い慣れた方法で行います。その場で上手くまとめる必要はありませんので、PMがファシリテーターとなり意見活性を促しましょう。とはいえ「さあ振り返りましょう！」と言ってもなかなか意見は出にくいものです。アンケートで収集した意見を事前にKPT上に書き入れて発言を誘発させるのも方法のひとつですし、発言してくれそうな人や発言しやすい項目をまず選んで、参加者が会話しやすいと感じる雰囲気を作っていきましょう。 振り返りのフレームワーク「KPT」とは。進め方やコツ、成功させる3つのポイント こんにちは、テストオペレーション部のショウです。最近「KPT（ケプト）」を使った振り返りに参加したので、私の体験を踏まえてまとめてみました。まず私から言えることは、”「KPT」は小まめに実施しましょう！”ということです。「KPT」の本領を発揮して成功させるた... 　続きを読む　 Sqripts 関連記事｜Sqripts 3) メンバーに言葉で感謝を伝える プロジェクトクローズドミーティングにはもう一つ重要な意味があります。それはプロジェクトメンバーや関係者を労って、所属していた部門や別のプロジェクトなどに気持ちよく戻れるようにすることです。「本当にありがとう、おつかれさま、またね」と ＜心理的にプロジェクトを終了させる＞ イベントです。言葉にしてプロジェクト活動を讃えあい、感謝を述べ、できる限りモチベーションを高めて次の活動に送りだすことに集中しましょう。またできる限りひとりひとり（もれなく）具体的な労いが言えるように準備したいですね。 その為にクローズドミーティングに軽食などを準備した「打ち上げ」を開催したり、打ち上げにメンバーが所属する上長を招待して「上長からメンバーを労ってもらう」といったテクニックを使うのも効果的でしょう。打ち上げをオフィシャルとしてしっかり実施することにはちゃんと目的があるというわけです。 さいごに 「プロジェクトマネジメントという共通言語としてのフレームワークや方法論の重要性はより高まります」と本連載のはじめにお話しました。それもそのはず、世の中は目まぐるしく変化し、企業組織では常に変化に対応するための多くのアクションが必要となり、現場レベル・部門レベル・全社レベル・短期的・中長期的・小規模プロジェクトから大規模プロジェクトまで、多くのプロジェクトが日々立ち上がる、まさに ＜プロジェクトエコノミー＞ の時代です。 しかし残念ながらプロジェクトマネジメントの手法を実行しただけでは、プロジェクトは上手くまわりません。プロジェクトに関与する人々のモチベーションがプロジェクトの成功や生産性にとても影響するからです。単なる指示命令・監視といったコミュニケーションではなく、相手の個別の価値観や傾向、思考などに寄り添う働きかけや工夫をすることで感情が動き、プロジェクトも動きます。プロジェクトを成功させる為に魔法のような大仕掛けはありませんが、これまでにお伝えしたようなひとつひとつの技術とコツの積み重ねが確実に効いてきます。プロジェクトやメンバーの声や動向に寄り添って、みんなが楽しく笑顔で活動できるようなプロジェクトをみなさんの手で作っていってください！ 【編集後記（Sqripts編集部）】 11ヶ月に渡る西田さんの連載は今回で最終回となりました。 執筆者の西田さん、連載を支えてくださった関係者のみなさま、そして、記事を読んでくださったたくさんの読者のみなさまに心より御礼を申し上げます。 みなさまのプロジェクトが「笑顔で終われる」プロジェクトになることを願っております。 この連載の感想をぜひお聞かせください。 送信フォームはこちらです。 連載一覧 【第1回】プロジェクトマネジメントとは何か？ ［全文公開中］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ 【第8回】コストをプロジェクトの武器にする！ 【第9回】目に見えにくいプロセス管理こそ品質達成の鍵 【第10回】プロジェクトのリスクマネジメント［前編］リスクを徹底的に洗い出す 【第11回】プロジェクトのリスクマネジメント［後編］リスク分析とコンティンジェンシープラン 【第12回】人がプロジェクトの源泉！チームは育てて強くする［前編］ 【第13回】人がプロジェクトの源泉！チームは育てて強くする［後編］ 【第14回】コミュニケーションの本質を知り、使いこなそう！ 【第15回】笑顔で終わるプロジェクトはここが違う！プロジェクトクロージングのTODO ［全文公開中］ The post 【最終回】笑顔で終わるプロジェクトはここが違う！プロジェクトクロージングのTODO first appeared on Sqripts .

こんにちは、QAエンジニアの ノナカ です！ QAのプロジェクトにおいて「今のテストがどれくらい進んでいるのか」または「どれくらい遅れているのか」といった進捗を測定して状況を把握することは、テストの実行を管理する際にとても重要なタスクとなります。本記事ではそういった進捗管理業務において、スプレッドシートに設計したテスト項目書を想定し、テストの「結果」および「実施日」を 、「1.手動」「2.関数」「3.Google Apps Scripts（以下GAS）」の3つパターンで取得する方法をご紹介します。様々なプロジェクトやQA業務、またはGASの使い方などに少しでもお役立てできれば幸いです！ 事前準備 「テスト項目書」シートの作成 まずはじめに、今回の取得対象となる「テスト項目書」を準備しましょう。スプレッドシートにて、簡易的なものを下記に用意しました。今回取得したい部分は、赤枠の「結果」列及び「実施日」列となります。※結果はシンプルに「OK」「NG」のみとし、実施期間は「2024/4/1」～「2024/4/5」の5日間と設定しています。 「進捗管理」シートの作成 続いて、「テスト項目書」シートとは別に１日ごとのテストの進捗を管理できるような「進捗管理」シートを準備します。こちらも簡易的なものを下記に用意しました。 「テスト項目書」シートの「結果」列及び「実施日」列に対応するものが、上図赤枠の各結果行と各日付列となります。上節の「テスト項目書」シートを例に挙げると、F列：「2024/4/1」の8行目「OK」が3件、G列「2024/4/2」の8行目「OK」が1件…というように、各テスト項目に対して「いつ」「結果がどうなったか」をそれぞれ入力する必要があります。 ポイント! – 消化する項目数の予定（予定完了率）について 進捗状況を把握するためには、 計画（理想）に対する実績を比較する ことが必要となります。今回の「進捗管理」シートでは、１日ごとに消化する（テスト結果：OKとなる）項目数を事前に計画して算出しています。算出方法としては、「全体の項目数からテスト全期間を割って平均値を算出する方法」や「テスト項目の消化に掛かる工数・ウェイトや優先度合等から日毎に消化できる項目数を厳密に算出する方法」等があります。今回は前者のパターンで算出しています。 「予定」の算出 今回だと「テスト対象の項目数：10項目」に対して「テスト全期間：5日」なので、「1日あたり2項目の消化」が必要となる計算です。（10 / 5 = 2） 「実績」の算出 実績（テスト結果：OK）の算出方法は、「OK」の値をそのまま関数を使って参照するだけでよいでしょう。 ※今回はテスト結果が「OK」しか設定していませんが、例えば「NG→OK（不具合が解消されたケース）」といったテスト結果もある場合は取得範囲が変わるため注意が必要です。 「◆予定完了率」の算出 「予定完了率」は「その日まで（から）に消化する予定の項目数」に対して「テスト対象の項目数」を割った値を算出する必要があります。ただし、関数の場合は先頭のセルと先頭以降のセルで算出方法が変わるため、下記の通り書き方を少し工夫する必要があります。 先頭のセル（F5セル）のサンプル関数 =F3/$E3 ※「先頭＝テスト初日」の場合、その日「から」消化する予定の項目数となるため、「F3 ＝ 2024/4/1 の予定項目数」を算出する必要があります。 先頭以降のセル（Ｇ5セル）のサンプル関数 =SUM($F3:G3)/$E3 ※「先頭以降＝テスト初日以降」の場合、その日「までに」消化する予定の項目数となるため、「SUM($F3:G3) ＝ 2024/4/1 + 2024/4/2 の予定項目数」を算出する必要があります。 「◆実績完了率」の算出 「実績完了率」でも「予定完了率」と同様の算出方法となります。ただし、参照する行は「予定」の3行目ではなく、「実績」の4行目が対象となります。 補足 今回のテスト項目書は１シートだけですが、例えば複数の項目書を一元で管理したい場合などは、下記のような書き方をすることで全体の進捗を把握することができます。 ※「サマリ」エリアの「予定」および「実績」、「項目数」～「NG」は、各項目書からSUM関数で引っ張ってきています。 複数の項目書を一元で管理する場合のイメージ図 いかがでしょうか。デイリーごとの進捗を把握したいケースの場合、テスト項目書をその都度参照しながら確認していくよりも、格段に把握しやすくなったのではないでしょうか。 それでは次章より、各テスト項目に入力された「結果」および「日付」を取得し、「進捗管理」シートに反映する方法を 「1.手動」、「2.関数」「3.Google Apps Scripts（以下GAS）」の3パターンを紹介していきます。また、それぞれ「手軽さ（誰でも取得可能そうか）」「取得時間（取得に時間がかからなさそうか）」「精密度（取得する値が正確か）」「汎用性（他のファイル等でも管理できそうか）」を筆者の所感として3段階の「★（多ければ多いほど良！）」で評価していきたいと思います。 パターン1 – 手動で取得する 評価 手軽さ　　：★★★ 取得時間　：★☆☆ 精密度　　：★☆☆ 汎用性　　：★☆☆ 解説 テスト項目書に入力された各テスト項目の結果・実施日は、当然ながら人力でカウントすることで手動で取得することができます。ただし人力の場合、ヒューマンエラーによるカウントミスや入力ミスが起きてしまったり、項目数が膨大な場合は取得するだけで工数が膨らむといった問題点があります。反対に項目数が極端に少なく、またテスト期間が極端に短いプロジェクトなどでは非常に有効な手段となるでしょう。 パターン2 – 自動で取得する（関数編） 評価 手軽さ　　：★★☆ 取得時間　：★★★ 精密度　　：★★☆ 汎用性　　：★☆☆ 解説 手動での問題点（カウントや入力のミス、取得に掛かる工数）を回避する方法として、関数を使用する方法が挙げられます。本記事では、「countifs関数」を例に紹介します。 凡例 =COUNTIFS('項目シート名'!「結果」列のセル範囲,結果ステータス,'項目シート名'「日付」列のセル範囲,日付) 「事前準備」章のF8セルに入力する場合のサンプル関数 =COUNTIFS(INDIRECT("'"&$C$10&"'!G:G"),$D8,INDIRECT("'"&$C$10&"'!H:H"),F$2) 上記関数を「進捗管理」シートの各結果行と各日付列のセル（「進捗管理シートの作成」節の赤枠内）に埋め込むことで、対応する結果を自動で取得することができます。メリットとしては手動に比べて遥かに容易、かつリアルタイムでテスト結果を取得できる点となり、デメリットとしては項目書における項目数やテスト期間が増えれば増えるほど（プロジェクト規模が大きくなるほど）、比例して関数の数が増えてしまうため、スプレッドシートに処理の負荷がかかる（例えば起動元のPCの状態によっては開くまでに時間がかかる　等）といった点が挙げられます。そのため、規模感がそこまで大きくないプロジェクトでない限りは、十分有効な手段といえるでしょう。 パターン3 – 自動で取得する（GAS編） 評価 手軽さ　　：★☆☆ 取得時間　：★★☆ 精密度　　：★★☆ 汎用性　　：★★★ 解説 関数のように逐一リアルタイムでテスト結果を取得したくない場合や関数を使用するにはプロジェクト（項目書）の規模が大きすぎる場合、または項目書とは別に用意したスプレッドシートで進捗を管理したい場合などは、Google Apps Scripts（GAS）を使用することが有効です。本記事では、簡単な要件定義からコーディングまでを解説していきます。 要件定義 コーディングするにあたって、まずは要件を定義していきましょう。必要な情報は、取得対象である「テスト項目書」シートの「結果」列及び「実施日」列のデータと、取得した後に入力する「進捗管理」シートの「結果」行と「日付」列の位置、および入力条件となります。それらをまとめた処理のフローを下記に掲載しました。 処理フローのイメージ図 コーディング それでは、上記でまとめた内容を基に、コーディングしていきましょう。要点を絞って解説していきます。 対象のスプレッドシート・シートの指定 まずはじめに、前提として対象となるスプレッドシートおよびそのシート名を指定していきます。 /**対象のスプレッドシート・シートの取得*/   let activeSheet = SpreadsheetApp.getActiveSpreadsheet();  //現在アクティブなスプレッドシート   let activeSheetName = SpreadsheetApp.getActiveSheet().getName();  //現在アクティブなシート   let progressSheet = activeSheet.getSheetByName(activeSheetName);  //「進捗管理」シートの設定   let testSheet = activeSheet.getSheetByName('項目シート'); //「テスト項目書」シートの設定 「progressSheet」を「進捗管理」シート、「testSheet」を「テスト項目書」シートとしてます。今回はテスト項目シート名を直値（’項目シート’）で指定していますが、項目シートが複数ある場合は、「事前準備」章の「進捗管理シートの作成 – 補足」の例にあるように「進捗管理」シートのC列に各項目シート名を記載したうえで、そこから各値を取得する方法などでも対応できます。 「進捗管理」シートの入力位置設定とデータの取得 続いて、「進捗管理」シートに入力するセル位置を設定していきましょう。 /**「進捗管理」シートの入力位置設定とデータの取得*/   let progSheetFirstRow = 8;  //「進捗管理」シートの入力セルの先頭行位置   let progSheetResult = 2;  //「進捗管理」シートの結果の数（OK/NG）   let progSheetFirstCol = 6;  //「進捗管理」シートの入力セルの先頭列位置   let testPeriod = 5;  //テスト期間（人日）   let testTerm = progressSheet.getRange(2, progSheetFirstCol, 1, testPeriod).getValues().flat();  //「進捗管理」シートの入力範囲の取得   progressSheet.getRange(progSheetFirstRow, progSheetFirstCol, progSheetResult, testPeriod).setValue(0);  //「進捗管理」シートを初期化する   let inputData = progressSheet.getRange(progSheetFirstRow, progSheetFirstCol, progSheetResult, testPeriod).getValues();  //値を代入する変数を定義する こちらも「セルの先頭行位置」などを直値で指定していますが、体裁などによって行・列やセルの位置が頻繫に変わる場合などは、検索キーでセル位置を自動で取得する方法なども有効です。 「テスト項目書」シートの入力位置設定とデータの取得 続いて、同様に「テスト項目書」シートに入力するセル位置を設定していきましょう。 /**「テスト項目書」シートの入力位置設定とデータの取得*/   let datafirstRow = 3;  //「テスト項目書」シートの入力セルの先頭行位置   let datafirstColumn = 7;  //「テスト項目書」シートの入力セルの先頭列位置   let datalastRow = testSheet.getLastRow();  //「テスト項目書」シートの入力セルの先頭列位置   let testDate = testSheet.getRange(datafirstRow, datafirstColumn, datalastRow, 1).getValues().flat();  //「結果」列を配列に格納する   let dataDate = testSheet.getRange(datafirstRow, datafirstColumn + 1, datalastRow, 1).getValues().flat();  //「実施日」列を配列に格納する 取得元となる「テスト項目書」シートに対しても、同じように設定・取得していきます。こちらも直値です。 結果および日付の比較判定（「OK」の例） 「要件定義」で定義したように結果や日付の判定を行う処理を最後に記載すれば完了となります。判定処理は「テスト結果が空欄かどうか」「日付が空欄かどうか」「日付が指定したフォーマットかどうか」をそれぞれ判定したうえで、適切な結果だった場合は最後に「OKか」を判定して対象の日付のOK数をカウントし、最後にその値を「進捗管理」シートに転記する、といった処理にしてみました。 /**結果および日付の比較判定*/   //for文で「テスト項目書」シートの最終行までループで比較判定を行う   for (i = 0; i < datalastRow; i++)     //結果が空欄のケース（何もしない）     if (testDate[i] === "") {       ;       //結果が空欄以外＋日付が空欄のケース（何もしない）     } else if (testDate[i] != "" && dataDate[i] == "") {       ;       //結果が空欄以外＋日付が指定フォーマット以外のケース（何もしない）     } else if (testDate[i] != "" && dataDate[i] != "") {       let objectType = Object.prototype.toString.call(dataDate[i]);       if (objectType != "[object Date]") {         ;         //結果が「OK」かつ日付が指定フォーマットのケース       } else if (testDate[i] === "OK" && objectType == "[object Date]") {         key = Utilities.formatDate(dataDate[i], 'JST', 'yyyy/MM/dd');         for (j = 0; j < testPeriod; j++) {           result = Utilities.formatDate(testTerm[j], 'JST', 'yyyy/MM/dd')           keySearch = result.indexOf(key)           if (keySearch > -1) {             inputData[0][j]++;             break;           } else {             ;           }         };       //判定結果を「進捗管理」シートに入力する       progressSheet.getRange(progSheetFirstRow, progSheetFirstCol, progSheetResult, testPeriod).setValues(inputData); 今回は「OK」「NG」の２パターンの結果のみしか定義していませんが、「BK（Blocking）」や「保留」、「NT（No Test ）」などの結果ステータスがある場合も同じような記載方法で処理することができます。 サンプルコード サンプルコードも掲載しておきます。折角なので、確認ダイアログや完了ダイアログの表示も併せてコーディングしてみました。 function AggregateResults() {   /**確認DLGの設定*/   //集計実行日の取得   let today = Utilities.formatDate(new Date(), 'JST', 'yyyy/MM/dd/EE')   //確認DLGの表示   let confirmdlg = Browser.     msgBox("実行確認", today + " 時点のテスト結果を集計しますか？", Browser.Buttons.YES_NO);   if (confirmdlg == "yes") {     ;   } else {     return false;   };   /**対象のスプレッドシート・シートの取得*/   let activeSheet = SpreadsheetApp.getActiveSpreadsheet();  //現在アクティブなスプレッドシート   let activeSheetName = SpreadsheetApp.getActiveSheet().getName();  //現在アクティブなシート   let progressSheet = activeSheet.getSheetByName(activeSheetName);  //「進捗管理」シートの設定   let testSheet = activeSheet.getSheetByName('項目シート'); //「テスト項目書」シートの設定   /**「進捗管理」シートの入力位置設定とデータの取得*/   let progSheetFirstRow = 8;  //「進捗管理」シートの入力セルの先頭行位置   let progSheetResult = 2;  //「進捗管理」シートの結果の数（OK/NG）   let progSheetFirstCol = 6;  //「進捗管理」シートの入力セルの先頭列位置   let testPeriod = 5;  //テスト期間（人日）   let testTerm = progressSheet.getRange(2, progSheetFirstCol, 1, testPeriod).getValues().flat();  //「進捗管理」シートの入力範囲の取得   progressSheet.getRange(progSheetFirstRow, progSheetFirstCol, progSheetResult, testPeriod).setValue(0);  //「進捗管理」シートを初期化する   let inputData = progressSheet.getRange(progSheetFirstRow, progSheetFirstCol, progSheetResult, testPeriod).getValues();  //値を代入する変数を定義する   /**「テスト項目書」シートの入力位置設定とデータの取得*/   let datafirstRow = 3;  //「テスト項目書」シートの入力セルの先頭行位置   let datafirstColumn = 7;  //「テスト項目書」シートの入力セルの先頭列位置   let datalastRow = testSheet.getLastRow();  //「テスト項目書」シートの入力セルの先頭列位置   let testDate = testSheet.getRange(datafirstRow, datafirstColumn, datalastRow, 1).getValues().flat();  //「結果」列を配列に格納する   let dataDate = testSheet.getRange(datafirstRow, datafirstColumn + 1, datalastRow, 1).getValues().flat();  //「実施日」列を配列に格納する   /**結果および日付の比較判定*/   //for文で「テスト項目書」シートの最終行までループで比較判定を行う   for (i = 0; i < datalastRow; i++)     //結果が空欄のケース（何もしない）     if (testDate[i] === "") {       ;       //結果が空欄以外＋日付が空欄のケース（何もしない）     } else if (testDate[i] != "" && dataDate[i] == "") {       ;       //結果が空欄以外＋日付が指定フォーマット以外のケース（何もしない）     } else if (testDate[i] != "" && dataDate[i] != "") {       let objectType = Object.prototype.toString.call(dataDate[i]);       if (objectType != "[object Date]") {         ;         //結果が「OK」かつ日付が指定フォーマットのケース       } else if (testDate[i] === "OK" && objectType == "[object Date]") {         key = Utilities.formatDate(dataDate[i], 'JST', 'yyyy/MM/dd');         for (j = 0; j < testPeriod; j++) {           result = Utilities.formatDate(testTerm[j], 'JST', 'yyyy/MM/dd')           keySearch = result.indexOf(key)           if (keySearch > -1) {             inputData[0][j]++;             break;           } else {             ;           }         };         //結果が「NG」かつ日付が指定フォーマットのケース       } else if (testDate[i] === "NG" && objectType == "[object Date]") {         key = Utilities.formatDate(dataDate[i], 'JST', 'yyyy/MM/dd');         for (j = 0; j < testPeriod; j++) {           result = Utilities.formatDate(testTerm[j], 'JST', 'yyyy/MM/dd')           keySearch = result.indexOf(key)           if (keySearch > -1) {             inputData[1][j]++;             break;           } else {             ;           }         };       };     };   //判定結果を「進捗管理」シートに入力する   progressSheet.getRange(progSheetFirstRow, progSheetFirstCol, progSheetResult, testPeriod).setValues(inputData);   /**完了DLGの設定*/   Browser.msgBox("実行完了", "集計が完了しました。", Browser.Buttons.YES);   return false; }; 応用編 – グラフで表現してみよう！ 取得した結果をスプレッドシートのグラフと組み合わせて表現することで、より視覚的に状況を把握することができます。 「進捗管理」シート × バーンアップチャート 本記事でご紹介した方法の場合、「完了率」といった積み上げする測定方式のため、「バーンアップチャート」で表現すると、もっともシンプルに進捗率が可視化できるでしょう。 また、グラフで表現することは、例えば上記の場合は「2024/4/2」までは予定以上の前倒し気味でテストが進行されてそうですが、「2024/4/3」以降は消化速度が停滞気味になっていることが分かります。「進捗管理」エリア上では「2024/4/3」に不具合が2件検出されているため、これがテスト項目の消化の阻害要因になってそうなので、不具合の状況確認が必要だな、必要に応じて開発側に連携をとる必要があるな、といった わざわざ各テスト項目書を確認しに行かなくても、一目で一次的な状況が推量できる といった利点などがあります。このようなスピード感を持った一次的な状況把握から二次的なネクストアクションを円滑に行うことができれば、適切なインシデントの管理やエスカレーション、場合によってはプロジェクト自体を上手くコントロールできる場合があります。 「進捗管理」シート × テスト結果積み上げグラフ × 信頼度成長曲線 さらに応用編としてより実践的に活用するために、「進捗管理」シートに対してテスト結果の「積み上げグラフ」と「信頼度成長曲線」を組み合わせて下図に表現してみました。コチラはより実践的な運用がイメージできるのではないでしょうか。 ※本格的なプロジェクトに近づけるために、「進捗管理」シートを少し加工して見せ方を変えています。 いかがでしたしょうか。他にも、プロジェクトや進捗状況に応じて様々な取得対象や表現方法等と組み合わせたりして、色々とカスタマイズしてみてください！ おわりに 本記事では、テスト項目書に入力された「結果」および「実施日」を 「1.手動」、「2.関数」「3.Google Apps Scripts」 の3つパターンで取得することで、進捗状況を測定する方法をご紹介しました。進捗を測定して状況を把握・管理することは、プロジェクトにとってボトルネックとなる問題点を認識できたり、またプロジェクトにおける円滑な進行を助長したりすることができます。 ただし、これらはあくまでも進捗管理における「手段」にしか過ぎません。進捗を管理する「目的」とは、『プロジェクトを問題なく成功に導き、高品質な商品やサービスを提供する』ということを忘れてはいけません。進捗状況を測定することだけに囚われて無駄な工数をかけてしまうといった本末転倒とならないようくれぐれも注意しましょう。またそうならないためにも、日々のテスト管理業務に対して上手くツール等を扱い、よりよいQA業務・品質管理に努めていきましょう！ The post テスト結果を取得して進捗状況を測定しよう first appeared on Sqripts .

テストエンジニアが身につけておきたいスキルの一つ「論理のスキル」。 「論理の言葉」の意味や働きに注意が向くようになったら、文や文章の読み書きで実践していきましょう。 この連載では、「論理スキル“実践編”」と題して、「文章の筋道を把握する、主張を理解する」「文や文章の筋道を組み立てる」ことに役立つ 推論の形 を見ていきます。 ＜テストエンジニアのための論理スキル[実践編]　記事一覧＞ ※クリックで開きます 論理のかたち。推論とは ［全文公開中！］ 基本的な推論形式 “または”を使って推論する “ならば”を使って推論する “ならば”と“または”で推論する ソクラテスは電気羊の夢を見るか？ (前編) ソクラテスは電気羊の夢を見るか？ (後編) 前回の「 ソクラテスは電気羊の夢を見るか？(前編) 」では、「定言三段論法」と呼ばれる推論形式の基本事項を紹介しました。 定言三段論法的な推論を自分から意識して組み立てることは少ないかも知れませんが、考えを整理してみたら定言三段論法的に考えると具合がよさそう、ということはあるでしょう。 文章を読んでいて、「これは定言三段論法で表してみると理解しやすいのでは？」と思えるような論理展開に出会うこともあるでしょう。 そんな時「この理屈は、形の上で正しいのかな？」とチェックできるように、今回は定言三段論法が「よい形」であるための規則を見ていきます。 その前に、前回クイズの解答です。 前回クイズ解答 問題(再掲) 下図の「ソクラテスと電気羊」その1～3について考えてみてください。 小名辞S、大名辞P、媒介項Mに当たるのは何か 各文は全称/特称、肯定/否定どれに当たるか 解答 その1。 小名辞Sは「ソクラテス」、大名辞Pは「電気羊の夢を見る」、媒介項Mは「哲学者」です。 大前提①は「すべてのMはPである(全称肯定)」の形、小前提②は「すべてのSはMである(全称肯定)」の形、結論③は「すべてのSはPである(全称肯定)」の形です。 （ちなみに、①M-P, ②S-M, ③S-Pですから第1格、式はAAAです） その2。 小名辞S、大名辞P、媒介項Mはその1と同じです。 大前提①は「あるMはPである(特称肯定)」の形、小前提②は「すべてのSはMである(全称肯定)」の形、結論③は「すべてのSはPである(全称肯定)」の形です。 （ちなみに、①M-P, ②S-M, ③S-Pの第1格、式はIAAです） その3。 小名辞Sは「ソクラテス」、大名辞Pは「哲学者」、媒介項Mは「電気羊の夢を見る」です。 大前提①は「すべてのPはMである(全称肯定)」の形、小前提②は「すべてのSはMである(全称肯定)」の形、結論③は「すべてのSはPである(全称肯定)」の形です。 （ちなみに、①P-M, ②S-M, ③S-Pの第2格、式はAAAです） ソクラテスが電気羊の夢を見られるために 押さえておきたい定言三段論法の「よい形」の規則 ソクラテスと電気羊・その1は、内容(意味)から「これは前提から無理なく結論が導けるな」と思った人は多いのではないでしょうか。 その2、その3では、やはり内容(意味)を見て「この前提からこの結論は、ちょっと無理があるのでは？」「何かおかしくないか？」と、感じた人も多いのではないでしょうか。 内容や意味の面で「？」と感じる主張は、形を調べてもおかしいものです （内容面で正しそうに見えても、形としてはよくない（妥当でない）ものもあります）。 定言三段論法的な推論の“よしあし”が、内容や意味の吟味以前に、形から読み取れることを見ていきましょう。 定言三段論法の「よい形」の規則 (1) 概念の数 登場する名辞(概念)は、三つであること ひとつの主張(大前提、小前提、結論の組)に登場する名辞(概念)は、小名辞S、大名辞P、媒介項Mの3個に限られます。3個より多いと、意味上の混乱が生じたり、媒介する概念がなくなって論が成り立たなくなります(図7-1)。 明らかに異なる名辞(概念)が4つ以上あるのがいけないのはもちろん、言葉の意味や解釈、表現などから名辞が多過ぎる状態になってしまってもいけません。 図7-1 登場する名辞(概念)は三つ 逆に登場する名辞(概念)が3個より少なく見える場合は、名辞が前提の中で省略されている可能性もあります（周知である、議論の背景として共有されている、などから省略されている事柄を補うと、正しい定言三段論法の形になる場合もある）。 そのような場合は実際の論理展開で見かけることも多いものです。主張を注意深く読み込んで「前提が隠れているのでは？」と考えてみるのがよいでしょう（ただし、本当に名辞が足りていない場合もあります）。 定言三段論法の「よい形」の規則 (2) 周延 周延とは、「 その概念が当てはまるすべての対象について言われている 」状態でした（「 ソクラテスは電気羊の夢を見るか？(前編) 」）。 周延の規則①　媒介項は必ず周延されること 媒介項Mは、前提の中で一度は周延 されている必要があります。 媒介項が周延されることで、「Mに関係しているS」と「Mに関係しているP」が結びつき、結論が成り立ちます。 図7-2 周延の規則①　媒介項Mと周延 「ソクラテスと電気羊・その1」で「なるほど、ソクラテスは電気羊の夢を見るね」と判断できるのは、「哲学者」という媒介項が（「すべての」という全称により）周延され、「ソクラテス」という概念と「電気羊の夢を見る」という概念が「哲学者」を介して結びつくからです（それだけではありませんが）。 その2、その3はこの規則に反しており 、媒介項「哲学者」(その2)、「電気羊の夢を見る」(その3)が周延されていません（後述「周延に関する誤謬」参照）。 周延の規則②　前提で周延されていないものは結論でも周延されないこと 小名辞、大名辞は、前提で周延されていない（不周延）なら結論でも不周延 である必要があります（結論で周延されるなら、前提で周延されている必要がある）。 一部についての主張が、無条件で全体に当てはまるとは言えない からです。 なお、 周延されている名辞を結論で周延しないことはできます 。 図7-3 周延の規則②　小名辞S、大名辞Pと周延 定言三段論法の「よい形」の規則 (3) 肯定と否定 肯定と否定の規則①　前提がふたつとも否定なら、結論は出せない 前提がふたつとも否定の場合、結論は出せません 。 図7-4 肯定と否定の規則①　前提がふたつとも否定の場合 図7-4a 肯定と否定の規則①　前提がふたつとも否定の場合 肯定と否定の規則②　前提のどちらかが否定なら、結論は否定 前提のひとつが否定の場合、結論は否定 になります。 図7-5 肯定と否定の規則②　前提のひとつが否定の場合 図7-5a 肯定と否定の規則②　前提のひとつが否定の場合 肯定と否定の規則③　前提がどちらも肯定なら、結論は肯定 前提がふたつとも肯定の場合、結論は肯定 になります。 図7-6 肯定と否定の規則③　前提がふたつとも肯定の場合 図7-6a 肯定と否定の規則③　前提がふたつとも肯定の場合 肯定と否定の規則・同値関係 肯定と否定の規則②③は、それぞれ逆も成り立ちます。(図7-7) 図7-7 肯定と否定の規則②③の同値関係 定言三段論法の「よい形」の規則 (4) 全称と特称 周延の規則、肯定と否定の規則から導出できる派生的な規則ですが、知っておくと便利な規則です。 全称と特称の規則①　前提がどちらも特称なら、結論は出せない 前提がふたつとも特称の場合、結論は出せません 。 図7-8 全称と特称の規則①　前提がふたつとも特称の場合 図7-8a 全称と特称の規則①　前提がふたつとも特称の場合 全称と特称の規則②　前提のどちらかが特称なら、結論は特称 前提の一方が特称の場合、結論は特称 となります。 図7-9 全称と特称の規則②　前提のひとつが特称の場合 図7-9a 全称と特称の規則②　前提のひとつが特称の場合 定言三段論法の「よい形」の規則　補足 ここまで挙げた「よい形」の規則はすべての格（「 ソクラテスは電気羊の夢を見るか？(前編) 」、図6-6）に共通で、 定言三段論法の形の“よしあし”は、これらの規則で調べることができます。 （これらの規則から派生できる規則は割愛しています。 また、これらの規則を踏まえて格ごとに格の形から来る制約があり、その結果「ひとつの格に、妥当な式は6個」となりますが、それらの説明も割愛します） 定言三段論法・気をつけたい落とし穴(誤謬) 定言三段論法の形式面で気をつけたい点は、「よい形」の規則の裏返しと言えます。 概念の数に関する誤謬 「ひとつの主張に登場する名辞(概念)は3個であること」(図7-1)に関して、名辞(概念)が3個より多くなっている誤りを 四個概念の誤謬 といいます。 現れている名辞(概念)の数だけでなく、以下のような点に注意しましょう。 使われている言葉の意味は明確か 多義的な言葉を使ったり、言葉の意味づけが曖昧だったりすると混乱を招く。 「同じ言葉は同じ意味」になっているか 言葉は同じでも、意味することが違っていると混乱を招く。 「同じ概念には同じ言葉」を使っているか 同じ概念を異なる言葉・表現で言い換えたり、（微妙に）違う言い回しを用いたりすると混乱を招く。 図7-10 四個概念の誤謬の例(1) 図7-11 四個概念の誤謬の例(2) 周延に関する誤謬 周延の規則①(図7-2)を守っていないことを、 媒介項不周延の誤謬 といいます（中名辞不周延の誤謬、媒概念不周延の誤謬ともいいます）(図7-12)。 図7-12 媒介項不周延の誤謬の例 周延の規則②(図7-3)を守っていないことを、 大名辞不当周延の誤謬 、 小名辞不当周延の誤謬 といいます(図7-13, 図7-14)。 （こちらは「 不当周延 」です。媒介項の 不周延 とは言葉も意味も違います） 図7-13 大名辞不当周延の誤謬の例 本連載最初の「 論理のかたち。推論とは 」で例に挙げた「イヌの三段論法」は小名辞不当周延の例になっています。（そのまま再掲していますが、大前提は②、小前提が①と並びを変えて読むと理解しやすいでしょう） 図7-14 小名辞不当周延の誤謬の例 肯定と否定の規則に関する誤謬 肯定と否定の規則①(図7-4, 図-4a)に反して結論を出していることを 否定前提の誤謬 や 否定二前提の誤謬 といいます。 また、肯定と否定の規則②(図7-5, 図7-7)に反していることを 不当肯定の誤謬 、 肯定と否定の規則③(図7-6, 図7-7)に反していることを 不当否定の誤謬 といいます。 あんがい縁がある推論の形 前回、今回と、定言三段論法の概要を紹介してきました。 修飾なしで「三段論法」というとこの形を思い浮かべる人は多いと思います（筆者もそうでした）。どのような推論の仕方をするものなのか、感触をつかめたでしょうか。 私たちが目にしたり、考えたりする中には、このような「概念どうしの関係」として表せるものごとや、そうすると考えやすいものごともあります。 「あの人はそそっかしいから、○○だ」といった主張も、「すべてのそそっかしい人は○○だ。あの人はそそっかしい。だからあの人は○○だ」といった定言三段論法の形で整理したり、考えを明確にしたりできる場合もあります。 （そうすると、「そそっかしい人はみな○○なのか？」といった、考えを批判的に見る視点も生まれやすくなります） こういう推論の形があるということ、そしてできればその考え方を知っておくのは有益でしょう。 クイズ ISTQB Foundaton Level V4.0シラバスの記述を元にした主張があります（()内は章節番号）。 それぞれについて、形に着目して、妥当な（よい形の）主張かどうか、今回の説明を元に考えてください。 （解答は次回に） 次回 次回、次々回は、これまで推論の形ごとに紹介してきた「気をつけたい落とし穴」について、 「形式面で気をつけたい落とし穴」をおさらいし、 「内容面で気をつけたい落とし穴」を詳しく探検 していきます。 参考文献 近藤洋逸, 好並英司 『論理学入門』 岩波書店 1979 藤野登 『論理学　伝統的形式論理学』 内田老鶴圃 1968 鈴木美佐子 『論理的思考の技法Ⅱ』 法学書院 2008 図版に使用した画像の出典 Loose Drawing 人物画をお借りしています。 テストエンジニアのための論理スキル[実践編]  連載一覧 論理のかたち。推論とは  【連載初回、全文公開中】 基本的な推論形式 “または”を使って推論する “ならば”を使って推論する “ならば”と“または”で推論する ソクラテスは電気羊の夢を見るか？ (前編) ソクラテスは電気羊の夢を見るか？ (後編) The post ソクラテスは電気羊の夢を見るか？ (後編)｜テストエンジニアのための論理スキル［実践編］ first appeared on Sqripts .