はじめまして！QAエンジニアのたくぞーです。　 テスト設計を行う上で、必要なテスト要件を網羅できているか不安に感じる…という方は少なくないのではないでしょうか。テスト設計時の仕様把握において、内容そのものの理解はもちろんですが、情報を十分に整理できていないと必要なテストの抜け漏れに繋がります。 テスト設計業務での仕様把握をきっかけに、テスト設計で活用できる情報整理の方法はないかと思い調べてみました。今回はそれぞれの概要やメリット、筆者の経験上の活用事例を交えてご紹介していきたいと思います。 テスト設計に使える情報整理術 デシジョンテーブル まず初めに デシジョンテーブル を紹介します。ブラックボックステスト技法の1つなので、ご存じの方も多いのではないでしょうか。複雑な条件（入力）の組み合わせによって、アクション（出力）が異なるシステムの場合に効果的です。条件とアクションの関係性をテーブル（表）に可視化することで組み合わせを整理しやすく、必要なテスト条件を漏れなく検討することができます。 簡単な活用例を交えて紹介します。ある会員限定の通販サイトの料金計算に関する下記の仕様があるとします。 会員ランクは「ゴールド」「シルバー」「ブロンズ」の3種類 購入代金から会員ランクに応じた下記の割引が適用される ゴールド：10%OFF　 シルバー：5%OFF　 ブロンズ：割引なし クーポン適用で購入代金から5%OFFする 会員ランクによる割引とクーポンによる割引は併用可能 これらの仕様をデシジョンテーブルで表すと下記の通りです。 ※存在しない条件の組み合わせ（異なる会員ランクの組み合わせ）は省略しています。 上記仕様では会員ランクの種類とクーポンの適用有無によって割引率が変動するため、各会員ランクとクーポン適用を条件部分に、各条件に対して「X」「Y」の値を記載します。その上でアクション部分に該当する割引率と「X」の値を記載します。 今回はシンプルな仕様なのでケース数は少ないですが、複雑な仕様となるとケース数も増大します。そのような時にデシジョンテーブルは効果的です。注意点としては、存在しない組み合わせなどの不要なケースを含めてしまったり、反対に必要な組み合わせを省略してしまうことが考えられるので、その点は気をつけましょう。 デシジョンテーブルは使う頻度も多く、筆者の場合はデシジョンテーブルと合わせてフローチャート部分をテスト分析・設計する時にも活用します。その際、分岐時の条件を条件部分に、その条件に応じた結果をアクション部分に入れて整理すると、必要なテスト条件を漏れなく効率的に検討でき、特に分岐が多い時はより効果的です。 また、デシジョンテーブルに関する詳細は下記の記事で詳しく取り上げられているので興味がある方はこちらも読んでみて下さい。 ▼参考記事 いまさらデシジョンテーブルというものを考えてみた ｜Sqripts 状態遷移図/状態遷移表 続いては 状態遷移図、状態遷移表 です。こちらもブラックボックステスト技法の1つですね。状態間が遷移するようなシステムやソフトウェアの場合に、状態とイベントの関係を図や表で可視化できるので全体像が把握しやすくなったり、考えうるパターンを整理することができます。 こちらも簡単な活用例を交えて紹介します。エアコンのリモコン操作に関する下記の仕様があるとします。 ボタンは「冷房」「暖房」「除湿」「停止」がある　 停止中に「停止」以外のボタンを押下すると運転中に切り替わり、各ボタンに応じた状態に遷移する 「冷房」ボタン：冷房　 「暖房」ボタン：暖房　 「除湿」ボタン：除湿　 運転中の各状態で「停止」以外のボタンを押下すると、各ボタンに応じた状態に遷移する 運転中の各状態で「停止」ボタンを押下すると、停止中に遷移する これらの仕様から、各状態とイベントの関係を状態遷移図で表すと下記の通りです。 各状態はそのまま状態として表し、各ボタン操作はイベント、イベントによる遷移は矢印で表しています。 次に、作成した状態遷移図の内容を踏まえて状態遷移表を作成します。 遷移前の状態を行に、イベントを列に入力し、イベント実行後の遷移先を表内に当てはめていきます。また、イベントを実行しても遷移が発生しない組み合わせには「-（ハイフン）」を入れます。 このように、状態遷移図では視覚的に全体の流れを把握できるため仕様を整理しやすくなり、状態遷移表では遷移しない組み合わせや無効な遷移も表すので必要なテスト条件の抜け漏れ防止に繋がります。 筆者の場合、例に挙げたような状態間の遷移を伴うシステムは当然のことながら、画面間の遷移を整理したい時にもよく活用します。画面数やイベント数が多いシステムになるほど作成や更新の手間は多少ありますが、用意しておくことで深く仕様を理解することができ、結果的にテスト分析・設計を円滑に行えた経験もあります。注意点としては、規模が大きいほど複雑化しやすく、逆に理解しづらくなってしまうことがあるので、適切に分割したり表記方法を簡潔にするなどの意識が必要です。 状態遷移図、状態遷移表に関する詳細な記事についても下記で取り上げられているのでご興味のある方は読んでみて下さい。 ▼参考記事 幅広いソフトウェアとテストレベルで適用可能な状態遷移テスト ｜Sqripts ロジックツリー ロジックツリー とは、ある課題や物事の要素をツリー状に分解して整理することにより、解決策を導き出していくフレームワークです。各要素を左から右に樹木が枝分かれしていくような形で階層化して整理していきます。 ロジックツリーにはいくつか種類がありますが、「 要素分解ツリー（WHATツリー） 」と呼ばれる、構成されている要素を網羅的に分解していく手法が整理しやすいかと思います。テスト対象となる画面や機能といった各要素を、WHATツリーを用いて段階的に分解（整理）していくことで、全体像を把握しやすく、テストすべき内容を整理することができます。 これまでと同様に簡単な活用例を紹介します。ログイン画面に関するテストを行うことになり、下記の仕様があったとします。 ユーザーID/パスワードを入力してログインする　 ユーザーIDは4～20文字の範囲で、半角英数字と半角記号が使用できる　 パスワードは8～64文字の範囲で、半角英数字と半角記号が使用できる 大文字・小文字・数字・記号の中から3種類以上含める必要がある　 ログインに成功すると会員画面に遷移する　 ユーザーID/パスワードの範囲内の文字数/文字種を入力し、ログインに失敗した時はログイン画面上にエラーAを表示する ユーザーID/パスワードの範囲外の文字数/文字種を入力し、ログインに失敗した時はログイン画面上にエラーBを表示する 「パスワードを忘れた場合はこちら」リンクから、パスワード再設定画面に遷移する これらの仕様からどのようなテストが必要かを分析する際、WHATツリーを使うと下記のように整理することができます。 テスト対象となる画面を起点に機能⇒観点の順に階層を分けていき、右にいくにつれてより詳細度の高い観点を記載していきます。筆者の場合はこのように、画面や機能の関係性をツリー上に展開してテスト観点を整理する際に活用していますが、実際に型に当てはめて可視化しながら整理できるので、頭の中だけで考えたり箇条書きで書いてみるよりも、観点が抜け漏れてしまう可能性がぐっと下がる印象を持っています。 検討すべき要素が多い場合はもちろん、要素が少なくても不安と感じる場合には一度WHATツリーを活用してみて下さい。 仮説思考 仮説思考 は限られた情報や知識・経験から最も可能性の高い結論を仮説立て、その仮説に基づいて検証を行い正確な情報を確認する思考方法です。テスト設計においては、テストベースの情報が少ない場面で活用できます。限られた要件や仕様から仮説を立てることで、テストベースを読むだけでは一見分からない要件や仕様について検討することができます。 筆者の場合、上記のロジックツリーの例と関連しますが、あるシステムのログイン画面に関する仕様把握を行っていた時に、認証に失敗する時の入力条件や、認証失敗時に該当のエラーを表示することはテストベースに明記されていましたが、一定回数失敗した時にロック状態になるといったことは明記されていない状況がありました。 過去に類似機能のテストを行った時はロック状態に関する仕様が存在していた経験から、その仕様が考慮されていない可能性があるといった仮説を立てて関係者に確認を行い、結果的にはそのシステムの性質上考慮は不要という結論に至りましたが、もし考慮が必要である場合には、何回失敗するとロック状態になるか、ロック状態はどのように解除されるか、という疑問も連想できるので仕様の有無と合わせて確認しておきましょう。 注意点としては、知識や経験に依存しすぎて仮説に頼ってばかりでは、返って柔軟なテスト設計ができない場合もあります。そのため、仮説は適切な場面に応じて立てて検討したほうが良いでしょう。 フェルミ推定 フェルミ推定 は予測することが困難な数値を、既知のデータや情報から論理的思考に基づいて概算を推定する手法です。限られた情報から答えを求めるという部分は、仮説思考と共通する部分になりますね。 テスト設計においては、数値に関する情報が不足している状況で活用することができ、限られた仕様や知識から概算を推定し、テストベースには記載されていなかった仕様について検討することができます。 筆者の場合、ある大企業向け業務システムのユーザー登録機能の仕様把握を行っていた時に、どれくらいのユーザーを登録できるかといったテストを検討する必要があったのですが、テストベースとして参照できるものに登録上限数が定義されていないという状況がありました。一見どこまでテストするのが妥当なのか見当が付かない数値でしたが、日本で最も従業員の多い企業が約35万人で、ここ5年で約3万人増加というデータを知っていたため、バッファ分を考慮しても50万人登録できるようであれば十分と考えることができます。 もちろん関係者に上限数を確認する必要はありますが、確認する際にただ確認するのではなく、上記の様に妥当性を提示することで客観的な根拠を得ることもでき、仕様の誤りの修正や仕様の決定を関係者がスムーズに行えるようになります。 その他の情報整理術 多面的な視点から物事を捉える ここまではテスト設計に活用できる各情報整理の手法について紹介してまいりましたが、その他にも意識的な技術として、多面的な視点から物事を捉える重要性についても紹介いたします。　 例えば、ある物事を特定の視点からしか捉えることができないとすると、他の視点から捉えることができる部分を見落とすことになり、その物事の本質を捉えることができません。これはテスト設計においても同様で、テスト対象の本質を捉えることができないと見当違いなテスト内容を検討してしまったり、考慮漏れという事態にも繋がります。 様々な視点から物事を捉えるために 「鳥の目、虫の目、魚の目、コウモリの目」 といった4つの視点を表す言葉が存在するため、概要について説明いたします。簡潔に表すと下記の通りです。 これらの視点はいずれも仕様把握において重要と考えています。 多少の主観を含みますが、テスト対象に関する理解を効率よく深めるには、はじめに鳥の目を意識する必要があると考えています。筆者の場合、テスト対象の全体像を把握しきれていない状態で詳細部分の分析から進めてしまったことで、より理解に時間がかかってしまったり、見当違いのテスト内容を検討してしまったという経験もあります。 まずは、テスト対象の全体を俯瞰して見ることを心がけ、その上で虫の目を意識して詳細部分の分析を行いましょう。そうすることで効率よく理解を深めるだけでなく、テストベースに明記されていない要件や仕様に気づける可能性も向上します。 また、その時にコウモリの目を意識してユーザー視点で仕様について考えることも必要です。ユーザー視点で考えてみると妥当ではないと捉えることができる仕様や、要件や仕様の誤りに気づける可能性もあります。 他にも、時間に特性を持つテスト対象においては魚の目を意識して、過去→現在→未来といった各時間軸でどのような違いがあるかを検討し、テストベースに明記されてなければ関係者に確認しましょう。 また、仕様把握を行う際には、下記の記事の記載内容と合わせて実践することでより高い効果が得られると思いますので、こちらの内容についても合わせて読んでみて下さい。 ▼参考記事 良い仕様把握は良い品質に繋がる 〜仕様把握をする時のコツ 5選を紹介〜 ｜Sqripts まとめ 改めて今回ご紹介した情報整理術と、その使い分けについて以下表にまとめました。 筆者の主観も多少含みますが、活用するときの基準の1つとして捉えていただければと思います。 今回ご紹介した情報整理術はあくまでも一例に過ぎませんが、テスト分析・設計をはじめとした様々な分野・業務においても活用することができるものです。　 各特性を把握いただいた上で実際に試していただき、自分にあったものをご活用いただけますと幸いです。 そして、これらを活用する際には参画しているプロジェクトの状況を考慮する必要があります。例えば、プロジェクトが繁忙期であったり、保守的なプロジェクトにおいて、これまで使用していない技法を用いると逆効果となってしまう可能性もあるため、状況に応じて適切な技法をご活用いただければと思います。 また、決してこれらだけを活用すればいいというものではありませんので、その点はご理解いただけますと幸いです。 最後まで読んでいただき、ありがとうございました！ #デシジョンテーブル #状態遷移図 #状態遷移表 #ロジックツリー #仮説思考 #フェルミ推測 The post テスト設計に使える情報整理術のご紹介 first appeared on Sqripts .

帰納的な推論 と 発見的な推論(アブダクション) は、 私たちがソフトウェア開発の現場/実務で（知らず知らずにでも）駆使している思考の形です（それどころか日々の暮らしでも使っています）。 それほど“自然な”思考の形ですが、どんな考え方で、どんなところに注意すると質の高い思考ができるのか、基本知識を押さえておくと実務のレベルアップにつながります。 今回は、推論の形を今一度おさらいし、本連載で取り上げるふたつの推論の概要を知りましょう。 「論理的」はつまらない？ 演繹的な推論の特徴 [実践編]で見てきた論理(演繹的推論、図1-1)には、次のような特徴があります。 前提に含まれていることだけから、論理の言葉の働きに従って一定の結論が導かれる 前提と結論には必然的な関連がある 前提が正しい(真)ならば、結論も正しい（と認めざるを得ない） 前提にないこと(意外な事実、新奇な発見、etc.)が結論で出てくることはない 図1-1 演繹的推論 演繹的な推論は、既知の事実/知識や普遍的な真理に基づいて個別の場合/個別の主張を論じる場合や、主張の正しさを論証する場合に活躍します。 論証(検証)のための論理 といった形容をされることもあります。 半面、「結論で主張することはみな前提にあることばかり」「当たり前のことを言うだけ」「新たな知見を得るものではない」と批判されることもあったそうです。 [実践編]で例として出てきた 「今日は雨だからAさんは自宅にいる」 にしても、 「ソクラテスと電気羊」 にしても、 前提からは思いもしないあっと驚く結論を出すのではありませんから、そのような“批判”も頷けなくはありません。 前提はどこから来る？ そうした批判の詳細や当否はここでは掘り下げませんが、「前提に含まれていることを基に」というその前提は、そもそもどこからどうやって出てきたのでしょうか。 356日欠かさずAさんの自宅を見張り、天候による過ごし方の違いを観察したのでしょうか。 「すべての哲学者は電気羊の夢を見る」という前提を得るために、すべての哲学者の見る夢を調べ上げたのでしょうか。 どちらも現実的にきわめて困難、ないし不可能でしょう。 そもそもどちらの例でも、その前提は演繹的な推論では得られそうもありません。 「発見」のための論理 非・演繹的な推論 演繹とは異なる形を持つ、非・演繹的な推論があります。 非・演繹的な推論その①は、「 帰納(帰納的推論) 」です。 図1-2 非・演繹的な推論①(帰納) 非・演繹的な推論その②は、「 アブダクション 」といいます。 図1-3 非・演繹的な推論②(アブダクション) これらの推論には次のような特徴があります。 結論として、前提に含まれていない 新たな知識 を引き出す （パン屋のチェーンP全体の営業終了時刻(または終了基準)） （特定のパンの売れ行きと近所の学校の生徒の購買傾向との関係） 前提と結論との間に必然的な関連がなく、なんらかの「 飛躍 」がある （調査した店舗が当てはまるからといって、すべての店舗がそうとは限らない) （焼きそばパンが残っていたのは、近所の学校の休校とは関係ないかも知れない） 前提が正しい(真)からといって、結論が正しいとは限らない 正しいと言える 蓋然性(確からしさ) が相当程度にある、にとどまり、誤りがある可能性を否定できない 結論が正しげに思えても、事例が追加されるなどして前提が変わると、それまでの結論が成り立たなくなる可能性をはらむ （よその街の店舗を調べたら、16時以降も店を開けているかも知れない) （近所の学校の休校が明けても売れ残るかも知れない） 演繹的な推論に比べると「(正しさの度合いが)弱い」半面、 新たな知見を得る際には大活躍する、 発見に寄与する論理 と言えます。 帰納的推論の概略 図1-4 帰納的推論 一般化 複数の有限個の事例から、同様の事例すべてに共通するもの(規則・法則、性質、原因、etc.)を見出す 「特殊から普遍へ」「部分から全体へ」などとも称される 蓋然的 有限個の事例を基に考えているので、「きっとそうだろう」「そうであるに違いない」とまでしか言えない。“間違い”の可能性が常にある 結論の確からしさは前提の質と量に依存する あくまで仮説 「きっと」「に違いない」が示すように、結論を導いただけでは「仮説」どまり アブダクションの概略 仮説の形成 結果(事象や事実)を説明する仮説(因果関係、法則、理論、etc.)を考える 蓋然的 「結果を説明する原因/理由や、結果に至る過程(プロセス)」は仮説の域を出ないので、“間違い”の可能性が常にある あくまで仮説 考えついた段階では道半ば 「その考えで矛盾なく整合的に説明できる」ことの論証を経てようやく仮説になる 綿密な論証や、実証（実際にそうであることの確認）が望まれる 論証が控えていてこその「発見」 ……ここまで読んできて、「論理の言葉なんかより、新しい知識を形成する「発見」の方が重要で、大事なのでは」と思う人もいるかも知れませんが、 三つの種類の推論はそれぞれに持ち場があり、それぞれに重要 だと考えてください。 一般化も説明仮説も、「すべての場合に当てはまるのか」「本当にその原因・過程でこの結果に至ったのか」などを確かめることで説得力が出ます。 その際には演繹的な推論が欠かせませんし、その論証で誤りがあったら、せっかくの発見が台無しになってしまいます（[実践編]の「 形式面の落とし穴 」、「 非形式面の落とし穴 」を参照）。 気をつけたい落とし穴(前編・形式面)｜テストエンジニアのための論理スキル［実践編］ テストエンジニアが身につけておきたいスキルの一つ「論理のスキル」。「論理の言葉」の意味や働きに注意が向くようになったら、文や文章の読み書きで実践していきましょう。この連載では、「論理スキル“実践編”」と題して、「文章の筋道を把握する、主張を理解する... 　続きを読む　 Sqripts 関連記事｜Sqripts 【最終回】気をつけたい落とし穴(後編・非形式面)｜テストエンジニアのための論理スキル［実践編］ テストエンジニアが身につけておきたいスキルの一つ「論理のスキル」。「論理の言葉」の意味や働きに注意が向くようになったら、文や文章の読み書きで実践していきましょう。この連載では、「論理スキル“実践編”」と題して、「文章の筋道を把握する、主張を理解する... 　続きを読む　 Sqripts 関連記事｜Sqripts この連載では 「一般化」を指向する推論（細部に違いのある形がいくつかあります）を「帰納的推論」として扱います。 「因果関係や結果に至る過程(プロセス)などの説明仮説の発見」を指向する推論を「アブダクション」とします。 なお、アブダクションと呼ばれる形の推論は古代ギリシアには「アパゴーゲー」と呼ばれていたようです。そのギリシア語に当たる英語として提唱者のチャールズ・パース(論理学者・哲学者)がつけた名称が「アブダクション」だそうです。 アブダクションには「誘拐」というよくない意味があるのですが、本連載ではパースの命名を尊重してこの名称を用います。 ちなみに、日本語だと「仮説形成」という語を使う人もいます。 さらに余談ながら、パースはレトロダクションとも呼んでいたそうです。日本語だと「遡及推論」とする人もいます。 「目の前の事実(結果)から“遡って”考え、原因から結果への道筋を説明する仮説を考える」ということでしょう。 （実は）（あんがい）おなじみの論理 帰納もアブダクションも、私たち誰もが生活の中で行なっている推論 です。 図1-2, 1-3を見て、 こうした推論はどちらも、日ごろからしている と感じた人も多いのではないでしょうか（そう感じてもらえそうな例を挙げました）。 また、ミステリーが好きな人はこうした思考に見覚えがあるでしょう。 名探偵が見せる「灰色の脳細胞の閃き」の多くは、帰納やアブダクションを思わせるものがあります。 （そんなわけで、この連載では「品質探偵コニャン」が随所に登場します！） ソフトウェア開発で働く帰納やアブダクション こうした思考は、ソフトウェアの開発でも行なわれています。 特に動作確認やデバッグ以降の作業で大活躍します。 また、開発終了後のプロセス改善(原因分析)などでも重要な働きをします。 図1-6 ソフトウェア開発で働く帰納、アブダクション 私たちが実務でやっていることの一端を振返ってみましょう。ここに挙げた以外にも、「こんな局面でこんな考え方をしている！」と思い当たる人もいるでしょう。 いずれも、 当てずっぽうや“なんとなく”で行なうことではありません 。 動作確認や設計中のデバッグでは……( 帰納的な推測 ) 期待と異なる振舞い(インシデント)が見つかったら、 詳細(入力やデータの内容、操作や手順、設定や構成、etc.)を確認する 詳細の一部を変えて動かし、同じ結果になる場合の共通項を考える （共通項がインシデントの原因かどうか、実際に動かしたり、ソースプログラムを調べたりして確かめる） （共通項から、「詳細の一部を変更したらどのような結果になるか」推測する） テストで故障が検出されたら……( 帰納的な推測 、 アブダクション的な推測 ) 同じ故障を起こしている他のテストがあったら、 詳細(事前条件、入力データ、操作や手順、設定や構成、etc.)に共通項がないか考える 詳細に共通項がある他の機能/フィーチャーに同様のテストをする(類推) 故障を引き起こす原因を考え(仮説)、それに基づいた詳細でテストをする(仮説の実証) テストからのデバッグ（故障の原因究明、欠陥の除去）では……( アブダクション的な推測 ) 当該の故障を起こす原因と、故障に至る過程やそうなる理由を考える(仮説) 原因箇所(候補)を見つけたら、それが故障を引き起こすことを机上で、または実際に動かして再現する(仮説の検証) 欠陥を修正したら当該の故障が起こらないことを確認する(仮説の実証) プロセス改善時の原因分析では……( アブダクション的な推測 ) 対策を施すべきエラー(誤り)について、そのエラーがどの工程で、なぜ発生したか(発生原因)や、なぜ検知できなかったか(見逃し原因)を、結果であるエラーから遡って推測する(仮説) （通常、エラーに至るまで「原因と結果の連鎖」があるので、それぞれについて「結果を引き起こした原因」を掘り下げる） 「原因」を掘り下げたら、「原因」から結果であるエラーに至る過程を机上で再現する(仮説の検証) （「原因」がいくつか考えられる場合は、再発防止にとって最も重要なものを選定する） これらの論理の仕組みや考え方、留意点を、これから見ていきましょう。 参考文献 近藤洋逸, 好並英司 『論理学入門』 岩波書店 1979 鈴木美佐子 『論理的思考の技法Ⅱ』 法学書院 2008 藤野登 『論理学　伝統的形式論理学』 内田老鶴圃 1968 米盛裕二 『アブダクション　仮説と発見の論理』 勁草書房 2007 図版に使用した画像の出典 Loose Drawing 人物画をお借りしています。 品質探偵コニャン：Produced by Sqripts . No Unauthorized Reproduction. The post 【第1回】見つけるための論理｜実務三年目からの発見力と仮説力 first appeared on Sqripts .

この連載では、ソフトウェア開発のQAエンジニアとして働き始めた皆様に向けて、私の実体験をもとに「こんなことを知っておけばよかった」という、ちょっとした気づきを共有します。 一緒にソフトウェア開発のQAエンジニアとしての充実したエンジニアライフを築くためのヒントを探っていきましょう。 ＜QAエンジニアのスタートガイド 記事一覧＞ ※クリックで開きます 【第1回】充実したQAエンジニアとしてスタートするためのガイドライン 【第2回】「誰のためか」を意識しよう QAエンジニアやテストエンジニアとしてキャリアをスタートしたばかりの頃、多くの人は「与えられたタスクをこなす」ことに集中してしまいがちです。 しかし、それだけでは充実した社会人生活を送っているとは言えない、と私は考えます。 ここでは、充実したQAエンジニアとして過ごすために大切なことをお伝えします。 それは「目的意識」です。 本記事では、充実したQAエンジニアとして過ごすために欠かせない「目的意識」についてお伝えします。特に、「顧客志向」の重要性を中心に、これがQAエンジニアとしての働き方にどのように影響するかを解説していきます。 筆者の背景 私は最初からエンジニアだったわけではなく、営業職からキャリアをスタートしました。 エンジニアのような「何かをつくる」ではなく、営業職として「サービスを顧客に売る」という、顧客と直接関わるような働き方をしていました。 その後、第二新卒でテストエンジニアとして転職しました。転職後の最初の現場ではテストに限らず、リリース後の保守チームでの仕事にも携わったことがありました。 その中で特に重要だったことは「お客様の声をきちんと聞いて、不満を解消する」ということでした。 これらの経験を通じて、「サービスやプロダクトを使ってくれるお客様が実在する」というリアルな実感を、心に刻んだのでした。 営業と保守の経験から学んだ顧客の存在 営業経験からの学び 営業の働き方は多岐に渡りますが、私が経験した営業は「売り上げノルマに責任を持ち顧客が”注文する”と言ってくれるまでなんでもする人」という働き方でした。 営業を通じて、「どんなに優れた製品やサービスでも売れなければ使われない」という現実を痛感しました。 実際に営業を経験することで、営業職に対する印象も変わりました。これまで私は営業職とは単に「コミュニケーションが得意な人」というフワッとしたイメージしか持っていませんでしたが、実際はそうではないことに気がつきました。 製品や顧客のことをしっかりと理解して、課題に心から共感し、顧客をハッピーにするために全力を注ぐ。その結果として売れるーーそれが重要なのだと感じました。 課題解決を待っている顧客がいて、彼らを満足させることが何よりも重要だったのです。 保守経験からの学び エンジニアになったあと、私はテスト業務だけでなく、保守運用の業務にも携わっていました。ここでの保守運用とは「製品が実際の現場で使われている中でのお客様の困り事を解決する」という業務でした。 テストを十分にしていても、製品が使用されている現場では新たな問題が発生するということがありえます。 実際の現場でしか起こりえない問題もありますし、テストから漏れてしまった問題もあります。そういった問題を解決して、「顧客が求めている価値を取り戻す」という経験をしました。 ここでも私は「実際に製品を使用してくれている顧客がいる」ということを実感するのでした。 製品というものの本質 製品とは、単なる成果物ではなく、「顧客に対して価値を提供するもの」だと私は考えます。 ここで重要なことは、製品を単なる機能やサービスの集まりとして捉えるのではなく、現実の顧客に対して、価値を提供したり、問題解決するものであるということです。価値というものは提供側だけで完結するものではなく、「顧客」がいて成り立つものなのです。 たとえば、ネットワーク機器であれば、「IPv4のプロトコルが使えること」が機能としてあったとしても、実際の価値は「エンドユーザーの利用者が安心してインターネットにつながる」ことだったりします。「ネットワークのプロトコルで正しく通信できる」といった作り手から見た仕様にすぎません。 「正しく動作する」ことだけでなく、あくまで顧客のニーズを満たすことが必要なのです。 QAエンジニアとその使命 QAエンジニアのQAとはQuality Assuaranceつまり、品質保証を担う人だというのが共通理解として成り立つと考えます。本記事では「品質」とは「製品の価値」、保証とは”請け負うこと”ですが、ここでは「最終的に説明と確約ができること」とします。 本記事での品質保証とは「製品の価値が損なわれていないことをきちんと確認して、顧客やステークホルダに対する説明と確約ができる状態」を目指します。 QAエンジニアの使命として、「製品の価値を守り、顧客が期待する、あるいはそれ以上の体験を保証する」というものがあるというのが私の理解です。 品質保証のあり方やロールの定義については様々な考え、文化、規約があることは承知していますが、本記事では上記の位置付けであるとご承知いただければと思います。 製品の価値を守る QAエンジニアの使命には「製品の価値を守る」があります。 まず第一に、「顧客が製品を使うことで被害を被ってしまう状態から守る」ということがあります。これは、製品に問題があった場合に、人の命に関わることや財産を失ってしまうことに繋がってしまう場合があります。あるいはそういった損失に繋がらなくても、個人情報の流出なども挙げられると思います。QAエンジニアはこれらのリスクから顧客を守る必要があります。 次に、「顧客が期待することを達成できない状態から守る」というものもあります。例えば、「せっかくお金を払ってインターネットを使うためにパソコンを買ったのにブラウザが開かないじゃないか」といった、元々顧客が欲していたニーズを満たさない場合があります。「顧客がどう使いたいのか」をきちんと把握して、そうした状況を回避することもQAエンジニアの責務だと考えます。 最後に、「顧客が期待すること”以上”の感動を届ける」という考え方もあります。例えば、全く新しい予約体験を提供するアプリの場合、それらの体験に対しても自信を持って製品を送り出す必要があります。ここでも、ただ単に製品を送り出すだけではなく、「顧客にとってどういった価値があるか」ということを明確にしてリリースする必要があります。 価値を保証する 「価値を保証する」の使命についても言及します。 「QAエンジニアとして自信を持って送り出す」ということは重要ですが、顧客に製品の価値が守られていることをしっかりと説明して、請け負える状態にすることも同じく重要です。 単に自分で確認してそれで終わりではなく、顧客やステークホルダといったQAエンジニア以外の人に対しても理解できるうように、守られた価値についてきちんと報告する、あるいはできるようにしておくことで、QAエンジニアはその役割を十分に果たせたと言えると考えます。 QAエンジニアの仕事を充実させる顧客志向 もし、この記事を読んでいる方がQAエンジニアになりたてで、普段の仕事に対して「こんな作業は退屈だな」といったことを感じている場合、「誰のために仕事をしているのか」を意識してみて欲しいです。 「誰か」があなたの仕事を待っていることに気づいてみてください。そうすることで普段の仕事や業務に意味を見出せるのではないでしょうか。 こうした考え方により実際の仕事の進め方も変わってきます。 たとえばテスト実行の場合、「バグの起票」では「誰にとって困るか」を言語化できます。「顧客にとってどうなるか」をきちんと言語化することで、「バグです」「仕様です」といった不毛な押し問答を防ぐことができます。 また、テスト実行が単なる作業の消化ではなくなります。実際のリアルなユーザーに思いを馳せながらテスト実行ができるということがあります。 さらには、プロダクトのテスト以外の活動にも目を向けることができるようになります。製品が顧客に価値を届けるにあたって必要なものはプロダクトだけでしょうか？ユーザーサポートやマーケティングなどが関わるようなプロダクトに携わる方が多いのではないでしょうか。 「顧客が何を求めているか」をリアルに捉えることで、QAエンジニアとしての仕事にやりがいを感じられるようになると私は考えます。 日本における品質管理での”顧客志向”について 日本における品質管理のあり方として、「TQC(Total Quality Control)」という手法があります。 TQCでは、「顧客志向」が重要な原則とされていますので、もし気になった方はぜひ調べてほしいです。ソフトウェア開発におけるQAの業務に全てが結びつくわけではありませんが、QAにとって大切な原則やマインドセットについて学べます。 参考文献として以下を挙げます 現代品質管理総論 （朝倉書店） 「品質は誰かにとっての価値である」という言葉を聞いたことのある方はいらっしゃると思います。ただ、この文章で「誰か」を「エンドユーザー」と捉えることには誤解があります。 ここで大事なことは「製品へのニーズを持っている人は多様である」ということです。顧客の多様性というのは上記の「現代品質管理総論」でも語られています。 また、「品質は誰かにとっての価値である」の原著を知りたい方は以下の書籍を参考にしてください。 ソフトウェアの文化を創る1 ワインバーグのシステム思考法 （共立出版） また、「価値にフォーカスする」という考え方はプロダクトマネジメントの原則でもあります。品質保証だけでなく、プロダクト作り全般について気になった方は以下の書籍を参考にしてください。 プロダクトマネジメント ビルドトラップを避け顧客に価値を届ける （O’Reilly Japan） おわりに 日々の仕事の中で、「自分は何のためにこの作業をしているのだろう？」と考えることがあるかもしれません。 そんな時は、「誰がこの製品やサービスを待っているのだろうか」と顧客を思い浮かべてみてください。目的意識はQA業務の充実のみならず、自分自身のQAエンジニアライフの充実につながるのではないでしょうか。 【連載】QAエンジニアのスタートガイド 記事一覧 【第1回】充実したQAエンジニアとしてスタートするためのガイドライン 【第2回】「誰のためか」を意識しよう The post 【第2回】「誰のためか」を意識しよう｜QAエンジニアのスタートガイド first appeared on Sqripts .

はじめまして、開発9年生、QAコンサル2年生のせとです。 先日、UI/UX改善のお仕事にて初めてユーザビリティテストについて携わり、様々な気づきを得たので備忘の意味も込めてこの記事で内容の紹介を簡単にしたいと思います。 ユーザビリティとは そもそもユーザビリティとはなんでしょうか？ 感覚的には、サイトの使いやすさや見やすさなどがわかりやすいところかと思います。 ユーザビリティの定義については JIS Z 8521 により定義され、主に人間工学的観点から「特定のユーザが特定の利用状況において，システム，製品又はサービスを利用する際に，効果，効率及び満足を伴って特定の目標を達成する度合い」として概念をまとめられています。 また、 JIS Z 8520 ※1 や JIS Z 8530 ※2 が深く関連しており、この3規格を主として定義づけされています。 ※1 　 JISさんぽ (01) JIS Z 8520:2022 「人間工学－人とシステムとのインタラクション－インタラクションの原則」 ｜Sqripts JISさんぽ (02) JIS Z 8522:2022 「人間工学－人とシステムとのインタラクション－情報提示の原則」 ｜Sqripts ※2 　 JISZ8530:2019 人間工学－インタラクティブシステムの人間中心設計 も併せてご参照ください。 ユーザビリティテストでやったこと 今回AGESTにて実施したユーザビリティテストでは、２つのロールを用いてロールごとの視点から評価を行っていきました。 ひとつは、評価するシステムを詳しく把握している「専門家」、もうひとつは評価するシステムを初めて触る「ユーザー」です。 ２つのロールをベースに、ユーザビリティテストでは大きく分けて2つのテストを実施しました。 ヒューリスティック評価 　←本記事で書く内容 WEBサイトやソフトウェアなどのユーザビリティ(使い勝手や分かりやすさ)を評価する手法の一つで、制作者や専門家がガイドラインや自身の経験則などに照らして評価する方式 ※3 ※3 　 ヒューリスティック評価（ヒューリスティック調査 / ヒューリスティック分析）とは – IT用語辞典 e-Words ユーザーテスト 機器やソフトウェア、WEBサイトなどを利用者に実際に操作してみてもらうテスト ※4 ※4 　 ユーザーテスト（ユーザビリティテスト / 操作性テスト）とは – IT用語辞典 e-Words 今回はヒューリスティック評価について何をしたか、簡単に書きたいと思います。 ヒューリスティック評価 ヒューリスティック評価では、「専門家」としてWEBシステムの評価を行います。 今回の評価にあたり、以下２点のアイテムを用意し、WEBレイアウト、表示物、文章、コントラスト、リンク構成などのWEBサイトを構成する要素から、応答性、操作性、入力規則、制約などのシステムの評価を実施しました。 JIS Z 8520 に記載されているインタラクションの7原則を軸に作成したチェックシート 実際に使用するユーザーを想定した「ペルソナ」とWEBサイト閲覧時の状況を想定した「シナリオ」（ ペルソナ／シナリオ法 ） 実際にWEBサイトを操作していく上でユーザビリティとして明確に低評価となる部分は以下の点がありました。 背景と文字色のコントラスト比の悪さ（コントラストスコアが低く、見えづらい） カルーセルメニューであることがわかりづらい コンテンツの案内が不足している ボタンが小さく押しづらい リンク構成が直感でわかりづらい 一方でペルソナになりきって操作をしていると、普段はあまり気にしないような細かい部分に気づくことが多かったと感じました。 文章の文字サイズ（周囲の文字やバナーなどに埋もれて相対的に見えづらい） ペルソナに対してWEBレイアウトが不親切（ハンバーガーメニューやナビゲーションウィンドウなどがわかりづらい） ペルソナ目線でメインコンテンツがどういうものか理解しづらい いつもは気にならないような部分も、ペルソナ目線（老眼、弱視、操作不慣れ、IT初心者など）で考えたときに「これは使いづらいかも？」を注意深く拾って行く必要があったので、私の人生で一番WEBサイトと向き合った作業だったと思います。 これらの問題点に対して改善案をまとめてお客様へ報告し、改善すべき内容について認識していただきました。 改善案を上げるにあたり、まず意識したことは「現状の状態から整えられるレベルの改善から始められるもの」です。 今回ユーザビリティテストを求められたお客様は、「AGEST目線から迅速かつ的確な改善提案をしていただき、共により良いUI作りができることを期待しています。」と、多大なる期待をいただきましたので、それに応えるべく時間をかけずに改善できる且つ目に見えて変化がわかるところを重点的に挙げていきました。 上記に挙げた問題に対する改善案の提案例として、以下の内容があります。 コントラスト比を改善し、文字の視認性を向上する。 サイト全体の案内を見直し、動線やコンテンツの内容がわかるようなラベリングを意識する。 レスポンシブルデザインを意識し、ボタンやリンクなどのサイズを見直す。 まとめ ユーザビリティは、要件定義としては非機能要件にあたり、開発現場としては性能要件やセキュリティ要件などが重視され他の非機能要件より優先度が低くなりがちです。 しかし、ユーザビリティを軽視した場合に起こりうるリスクとして、使用感の悪さによるサイト離脱率の増加や、悪評によるアクセス率の低下を招きかねません。 そのような事態を防ぐべく、他の非機能テスト（性能テストや脆弱性診断等）と併せてユーザビリティテストを実施してWEBサイトの利便性評価を正しく行い、ユーザーにとって快適で使いやすいWEBサイトへ改善していくことについて考えていただけたら幸いです。 次回後編にて「ユーザーテスト」について書きたいと思います。 ▼AGESTでは、ユーザビリティ診断についてのご相談も受け付けておりますので、ご気軽にお問い合わせください。 UI/UX向上支援サービス｜お役立ち資料｜株式会社AGEST（アジェスト） 本資料では、UI/UX向上支援サービスの概要について詳しくご紹介しています。製品のUI/UXに関する“お悩み”がある方は是非ご覧ください。フォームにご登録頂くと、ダウンロードURLがメールで送付されます。 　詳細はこちら　 株式会社AGEST（アジェスト） 関連情報 <出典> 三樹 弘之，JIS Z 8520 インタラクションの原則．J-Stage JIS Z 8521：2020　人間工学−人とシステムとのインタラクション− ユーザビリティの定義及び概念,日本産業規格 JIS Z 8530：2019　人間工学−インタラクティブシステムの 人間中心設計,日本産業規格 ペルソナ／シナリオ法を使ったユーザー中心のデザイン．株式会社イード．2009 JISさんぽ (01) JIS Z 8520:2022「人間工学－人とシステムとのインタラクション－インタラクションの原則」 ｜Sqripts JISさんぽ (02) JIS Z 8522:2022「人間工学－人とシステムとのインタラクション－情報提示の原則」 ｜Sqripts ヒューリスティック評価（ヒューリスティック調査 / ヒューリスティック分析）とは – IT用語辞典 e-Words ユーザーテスト（ユーザビリティテスト / 操作性テスト）とは – IT用語辞典 e-Words The post 初めてのユーザビリティテスト～前編～ first appeared on Sqripts .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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