はじめまして！テストエンジニアのずっきです。 昨年、異業種からQA業界に転職し、現在はQA事業に携わる部署でテスト実施および設計業務に従事しています。将来は、テスト計画から完了に至る一連のテストプロセスを管理できるプロジェクト管理者を目指して、日々精進しながら業務に取り組んでいます。 今回は、そんな私が異業種からQA業界へなぜ転職を志したのか…転職においてどのような不安があったのかを、私と同じく異業種からQA業界への転職を考えている皆さんの一助となるようにブログに綴らせていただきます。 これまでの経歴について 私は、管理栄養士として病院勤務経験を経て、異業種の品質保証業界に転職しました。現在は、テスト実施および設計に携わり、高い品質保証を提供できるQAエンジニアになるべく奮闘しています。 前職について 職種 ：病院管理栄養士 業務内容 ：病院食の献立作成、栄養管理、栄養指導など 異業種からQA業界への転職 自己紹介にも記載した通り、長らく管理栄養士として従事していましたが、将来のキャリアパスに不安を抱くことが多く、以前から興味があったITエンジニアへの転職を考えるようになりました。ITエンジニアに関するスキルや経験がなく、強みとなるものがない…このような理由から行動に移せずにいましたが、生活環境が変わった節目に、ITエンジニアへの転職を強く志すようになりました。 転職に当たっての不安要因と解消法 異業種への転職にあたって「自分に適性がなかったらどうしよう…」「想像していた仕事と違ったらどうしよう…」「自分に務まるのか…」など、さまざまな不安がありました。そこで、短期のプログラミングスクールに通い、実際に体験したことで、さらにエンジニアとして活躍してキャリアを築きたいと強く思うようになりました。 スクールでは、基本的なプログラミングスキルを習得しましたが、最大の収穫は「自分にエンジニアとしての適性があるかどうか」を自覚できたことです。特に、転職活動中に重視していたのは、前職での思考や能力が活かせるかどうかでした。異業種かつ未経験の私にとって、何が武器になるのかを模索した結果、前職で培った思考や能力がQAエンジニアとして最適であると実感しました。 前職の経験がQAエンジニアとしてどのように役立っているかについてお話しする前に、まずはQAエンジニアの仕事内容や役割について簡単に確認しましょう。 QAエンジニアとは QAとはQuality Assurance（品質保証）の頭文字です。QAエンジニアとは文字通り、システムやソフトウェアの品質管理業務を通じて、品質を保証するエンジニアです QAエンジニアの仕事内容とは？年収や必要資格を解説 つまり、普段使用しているアプリケーションやシステムが問題なく使用できているのは、開発した製品が市場に出る前に、テストされて品質が保証されているからです。 QAエンジニアの役割 ITシステムやアプリケーションはSEやプログラマーなどのITエンジニア職により設計・開発が行われます。QAエンジニアは、開発されたシステムやアプリケーションが設計通りに作られ期待通りに動作するか、使いやすい仕組みかを確認し、問題がある場合は是正に繋げる役割を持っています。 QAエンジニアとは？仕事内容や将来性を解説 異業種時代のこんな思考、習慣、経験が役に立つ！ 1. 学習習慣 前職では、病院で栄養士として患者さんの栄養管理業務に従事しておりました。栄養管理業務では、病気に関する知識や薬と食事の相互作用、禁忌などの医療に関する知識が必要不可欠です。そのため、日々の生活の中で「学習時間」を確保する習慣を確立しました。 学習習慣の形成には、下記のようなメリットがあります。 習慣化により、集中して学習に取り組むことができる 学習することに抵抗がなくなる 自分に適した学習方法が確立される ▼学習習慣がなぜ重要なのか？▼ 専門性を高めるためには、「学習」と「経験」が重要だと感じてます。特に学習は参考書や動画教材などで効率的に知識を吸収できる方法です。 異業種・未経験から現在の品質保証会社に入社し、様々な専門スキルの重要性を実感しました。特に、QAエンジニアの知識を提供する「JSTQB Foundation Level資格」は、実施業務や設計業務に従事する者にとって基礎的な知識が体系的に記載されており、ＱAエンジニアであれば取得推奨の資格です。私もこの資格を取得しましたが、テスト活動がどのような要素で構成されているのかを理解することで、業務の目的を明確に認識できました。また、テスト設計時のテスト技法にも役立てています。資格を取得することでスキル向上だけでなく、第三者に自分のレベルを証明できるメリットもあります。 2. リスク管理 病院という特殊な場所では、ミス（誤り）が患者の生命に直結します。たとえば、アレルギー物質の混入を予防するには、混入しにくい環境を整える必要性があります。そのためには、リスクの識別・調査・対策を行う必要があります。 ▼リスク管理がなぜ重要なのか？▼ 品質保証でも、将来起こりうるリスクを過去の事例や経験から推測して、対策や予防を行うことでリスクを回避・軽減することができます。また、プロダクトリスクだけでなくプロジェクトの進行上のリスクも発生します。たとえば、テスト実施業務において計画していたスケジュールと実際の進捗に乖離があり、期限までにテストが完了できないといったプロジェクトリスクが考えられます。テスト実施の早い段階で、期日までに完了が困難であると識別できれば、原因を調査します。たとえば、テスト実施者の経験不足な場合もあれば、テスト対象に不具合が多発していて実施業務が中断している場合もあるでしょう。適切な対策を講じてリスク回避や軽減を図ることができます。 3. 情報収集力 前職の業務の一つに、「栄養管理」という業務がありました。栄養管理とは、入院患者の栄養状態や食事摂取状況をもとに、病状に合わせた栄養評価を行い、食事内容や食習慣のアプローチを決定して栄養状態を改善することが目的です。 栄養状態を改善するためのアプローチを決定するにあたり、電子カルテから現在の栄養状態を正確に確認するだけでなく、症例と比較して今後の栄養状態を予測し、対策を考えることも必要です。客観的なデータだけでなく、患者さんからの聞き取りを行うことで、より個々に合わせたアプローチ方法の策定に役立てることができます。 ▼情報収集力がなぜ重要なのか？▼ QAエンジニアは、テスト活動全体のプロセスに関与します。テストプロセスは、計画、分析、設計、実装、実行などのテスト活動で構成されています。例えば、テスト設計では対象システムの仕様把握を行いますが、実際の現場では完全な仕様書がないことが多いため、テスト設計者として仕様書に記載のない仕様や、欠落していたり曖昧な部分を特定することも重要です。仕様の欠落、矛盾、曖昧さに対して、すぐに開発者や管理者に確認を求めるのではなく、他のテストベースを参照したり、あるいは開発者側で作成されたシステムアーキテクチャやコードを分析し、自分で不明点を補うことが求められる場合もあります。また、既存システムの回帰テストでは、過去のドキュメントやステークホルダーとのやり取りからシステムに関する情報を収集することもあります。収集した情報は、製品の品質に直結するため、最新バージョンの仕様であるかの確認を慎重に行う必要があります。 4. 文章力 前職の業務の一つに「栄養指導」という業務がありました。文字通り、患者さんの病態に合わせた食事の取り方について指導・アドバイスを行います。栄養指導でやり取りした内容や目標設定は、200文字程度でまとめてドキュメント上に記載します。その際に、重要な情報を簡潔にまとめ、第三者も理解できるように記載することが重要でした。また、次回の栄養指導時に評価できるように定量的に情報を記載する能力が求められていました。 ▼文章力がなぜ重要なのか？▼ テスト実装フェーズでは、明確なテスト手順や期待される結果の記載が必要です。不明確な手順や曖昧な期待結果では、テストの結果として合格/不合格の正しい判定ができず、誤った判定をしてしまう可能性があります。そこで重要になるのが「文章力」です。 下記例を参考に文章力の重要性を解説します。 例）「自動販売機に硬貨を投入したらパネルに投入額が表示される」といった機能 テスト手順 期待結果 手順1. 10年前に買ったお気に入りの財布から硬貨を出す 手順2. 硬貨を入れる 手順3. パネルの表示を確認する 金額が表示されていること 上記のテスト手順と期待結果には修正が必要な個所がいくつかあります。 不要な手順 ： テストの目的は対象機能の表示確認（投入した金額がパネルに表示されること）であり、手順1の「10年前に買ったお気に入りの財布から硬貨を出す」はテストの目的に関係ない情報であり、余計な内容です。不要な手順や冗長な文章は、テスト実施者を混乱させ誤った結果を招く可能性があります。 不明確な定義 ： 手順2の「硬貨を入れる」では、具体的な硬貨の種類が明記されていません。「日本円」「USドル」あるいは「ゲームのコイン」など、硬貨の種類が不明瞭です。硬貨の種類が明確でないと、誤った硬貨が使われた場合にテストが不合格になる（偽陰性）可能性があります。 期待結果の曖昧さ： 期待結果の「金額が表示されていること」も漠然としています。正確な金額（例えば「10円」と表示されること）を指定しないと、「10円」を投入して「100円」と表示されても合格になってしまう可能性があり、偽陽性の結果を招くことがあります。 上記を踏まえて修正したテスト手順と期待結果は下記になります。 観点 前提条件 テスト手順 期待結果 表示確認 ・硬貨を準備しておく ・パネルの初期値が「0」であること 1.自動販売機の硬貨投入口に10円硬貨を1枚入れる 2.パネルの表示を確認する 10円と表示されていること この修正により、手順が明確になり、期待結果も具体的で正確な内容となります。 このように、文章力を駆使してテスト手順を適切に表現することで、誤解や誤判定を防ぎ、テストの信頼性が向上します。 文章力の向上は、論理的思考力にもつながります。テストエンジニアにとって論理的思考が重要である理由について、過去のSqriptsに興味深い記事が掲載されていますので興味のある方は、ぜひ以下のリンクをご参照ください。 ※参照： テストエンジニアのための論理スキル[再]入門 [第1回] なぜ、テストエンジニアに(も)論理のスキルは重要なのか テストエンジニアが身につけておきたいスキルの一つに「論理スキル」があります。この連載では、「プログラムのレベル」「文や文章のレベル」に分けて、論理スキルの基本である「論理の言葉」を徹底解説します。第1回の今回は、論理スキルが重要である理由、身につけ... 　続きを読む　 Sqripts 関連記事｜Sqripts まとめ｜ 推奨スキル/資格 本記事では、前職で培ったスキルや考え方が、どのようにQAエンジニアとして活かされているかについてお話しましたが、QAエンジニアを目指すにあたっては、専門知識があることに越したことはありません。 QAエンジニアの知識を提供する「 JSTQB Foundation Level資格」 は、実務経験が全くない私でも取得することができ、難易度もそれほど高くありません。QAエンジニアに興味を持っている方や、これから目指す方は資格取得を目指してみてください。 JSTQB学習のススメ #1 〜JSTQBとは〜 みなさん、はじめまして！　ゆーすけです。「ブログにテスト領域でなんか書いてー」とミッションがおりてきまして、何が書けるかなー、って考えてみました。テストエンジニアといえばテスト技術、テスト技術の資格といえばJSTQB。そういえば、デジタルハーツって「JS... 　続きを読む　 Sqripts 関連記事｜Sqripts 　　　　　　　　　　　　　 非テストエンジニア、JSTQB（FL）を受けてみた こんにちは！WEBコンテンツ制作者のくるみです。今回はソフトウェアテストの知識が浅いWEBコンテンツ制作者が、JSTQB認定テスト技術者資格（Foundation Level）に合格したお話です。動機現在、私はWEBコンテンツ作成に従事していますが、今年の春の組織変更により所... 　続きを読む　 Sqripts 関連記事｜Sqripts The post 異業種から未経験でQA業界へ転職！前職の経験はQAエンジニアとしてどのように活かせるのか？ first appeared on Sqripts .

こんにちは、セキュリティエンジニアの河村です。 今回は白揚社出版の｢情報セキュリティの敗北史｣の書評をお届けします。 情報セキュリティの敗北史 ：アンドリュー・スチュワート 著　小林啓倫 訳（白揚社） ▼書籍情報はこちらです。 情報セキュリティの敗北史 サイバー攻撃の脅威はなぜ増え続けるのか?   相次ぐ個人情報の大規模漏洩、米・中・露による国家主導のハッキング、企業・病院を標的にして猛威を振るうランサムウェア…   IT社会が急 　詳細はこちら　 www.hakuyo-sha.co.jp 関連情報 本の概要 本書は、情報セキュリティに関する出来事を、コンピューターの黎明期である1940年代から現在に至るまで、時系列に沿って解説しています。現代のホットなテーマも、過去に遡ってその文脈を理解することで、より深く本質を捉えることができると感じました。また、情報セキュリティの経済学など、通常の教科書ではあまり詳しく取り扱われないテーマにも触れられており、非常に興味深い内容となっています。 章ごとの概要 以下に、本書の各章で特に注目したい内容をピックアップしてご紹介します。 1 情報セキュリティの｢新次元｣ 第二次世界大戦前後のコンピューター黎明期、ENIACなどのエピソードから始まります。この時代のコンピューターにはネットワークは存在しませんでしたが、情報の閲覧に権限設定があったり、「タイムシェアリング型」という形で、原始的な情報セキュリティが存在していたことがわかります。 2 研究者たちの期待、成功、失敗 主に1970年代までの基礎研究について述べられています。1970年に提出された「ウェア・レポート」では、 大規模なソフトウェアシステムにおいては、エラーや異常が完全に無いことを検証するのは事実上不可能 情報セキュリティの敗北史(P.28) 攻撃者がそのような抜け穴を計画的に探し、利用することも考えられる 情報セキュリティの敗北史(P.28) といった、脆弱性とクラッキングについての洞察が記されており、その先見性には驚かされます。この時代、これらは理論レベルでの研究に留まっていましたが、国家秘密として扱われるなど、その戦略的重要性はすでに認識されていました。 また、1974年にはサルツァーとシュローダーが情報セキュリティの三要素「CIA（機密性、完全性、可用性）」や「フェイルセーフなデフォルト」などを提唱しています。 3 インターネットとウェブの誕生、不吉な予兆 冷戦期に、国家レベルで通信の可用性を確保するため、人間の脳の構造をヒントに、パケットを用いた原始的な通信手段がランド研究所のポール・バランによって1960年代に「分散化とパケットスイッチング」として提唱されました。これが基となり、ARPANETが形成されました。ARPANETの発展に伴い、@を用いたメールシステムが導入され、RFCやTCP/IPなどネットワークの基礎が築かれました。 このように、ARPANETは発展し、やがて現在のインターネットへと進化していきます。しかし、1983年にはフレッド・コーエンによって世界初のコンピュータウイルスが作成され(P.62)、1990年にはロバート・T・モリスがインターネットに甚大な被害をもたらすウイルスを作成・拡散し、史上初めてインターネット関連の有罪判決を受けることとなります(P.66)。 UNIXやC言語も1970年前後に開発されました(P.70)。 1990年前後にブラウザが一般化し、情報セキュリティの重要性が急速に高まりました。ネットワーク脆弱性スキャナSATANが開発されましたが、これは攻撃にも利用できるため、賛否両論が巻き起こりました(P.82)。 4 ドットコム・ブームと魅力的なフィードバック・ループ 1990年代、インターネットの普及に伴い、インターネット関連株が過剰に上昇するドットコム・ブームが巻き起こりました。 この急速な発展に伴い、JavaやActiveXなどのモバイルコード技術が普及しましたが、これらには多くの脆弱性が発見されました。また、サーバサイドの脆弱性として、SQLインジェクションなどのコマンドインジェクションが問題視されました。SSLプロトコルも登場しましたが、根本的な解決には至りませんでした。 アンダーグラウンドマガジン「Phrack」の共同編集者の一人であるハッカー「Route」は、90年代に活躍し、TCP/IPプロトコルスイートを攻撃しました(P.96)。彼が広めた「SYNフラッド攻撃」は、プロトコルのセキュリティ上の弱点を示すものでした(P.98)。 Phrack 　http://www.phrack.org/ こうした背景から、イーベイやヤフーなどの大手企業はセキュリティ確保が困難になり、セキュリティの重要性が増大したものの、多くの企業にとってそれは難題でした。ここで成長したのが情報セキュリティ産業です。しかし、企業が提案したスキャナーやファイアウォールには多くの問題がありました。例えば、ファイアウォールによる偽陽性の検知が顧客のセキュリティ意識に悪影響を与えることがありました。 また、ハッカーに対する一種の崇拝的感情が生じ、フィードバック・ループが形成されたのもこの時期です。エクスプロイトを投稿する文化ができ、脆弱性に関する知見が共有される一方で、スクリプトキディ（技術的に未熟なハッカー）の増加という問題も浮上しました(P.116)。こうしてセキュリティ業界とハッカーが共に成長する一種の共生関係が生まれました(P.117)。 この時期、ハッカーとセキュリティ業界の原動力として「恐怖」が非常に強力であることが明らかになりました（FUD: fear, uncertainty, doubt）。この動向に否定的な意見もあり、マーカス・J・レイナムは「ハッキングがクール」という考え方を「コンピュータセキュリティにおける最も馬鹿げた考えの一つだ」と述べています(P.121)。 5 ソフトウェアセキュリティと｢苦痛なハムスターホイール｣ ドットコムブームの間に生まれたフィードバック・ループにより、企業がパッチを適用しなければならない新たな脆弱性の数は増える一方でした。「ペネトレイト・アンド・パッチ（脆弱性を見つけてパッチを当てる）」という方法論では、企業は進展せず、常にパッチの適用が求められる状況が続き、ある専門家はこれを「苦痛なハムスターホイール」と呼びました(P.124)。 1998年頃には、基盤となるOSが強固なセキュリティサポートを提供していない場合、Webサーバーやアプリケーションがセキュリティを実現できるという考え方が誤っていることが認識され始めました(P.125)。 この頃、ほとんどセキュリティサポートを提供していなかったWindows OSは2000年代初頭に大規模な攻撃を受けました。2001年のCode Redや同年のNimdaなどの大規模攻撃は、企業にマイクロソフト製品の使用を再考させるきっかけとなりました(P.128-129)。 こうした中、2002年にビル・ゲイツが全社宛てに送信したメールをきっかけに、マイクロソフト社は「新しい機能の追加に注力する」から「設計段階からセキュアであり、デフォルトでセキュアであること」へと基本哲学を変更し、結果的に大成功を収めました(P.132-134)。 こうした対策がなされた後も、Slammer、Blaster、Welchia、SoBig、Sasserなどの大規模インターネットワームが発生し、暗い未来を予感させるものでした(P.139)。経済的損失の大きさや、少人数で作成できる点から、感染したコンピュータのネットワークが国家レベルの攻撃に利用されることが明白になりました。 マイクロソフトはパッチ適用に関して、毎月第二火曜日にサービスパックとしてまとめて提供するようになりました(P.146)。しかし、ハッカーはパッチをリバースエンジニアリングして脆弱性を特定し、これが新たな攻撃のきっかけとなることもありました(P.146)。 2004年、マイクロソフトは「セキュリティ開発ライフサイクル(SDL)」の運用を開始しました(P.148)。このアプローチは、セキュリティを実装する際のベストプラクティスとして広く採用され、アドビやシスコにも影響を与えました(P.149)。 一方、オラクルは異なるアプローチを取った結果、マイクロソフトは成功し、オラクルは失敗したと言えます(P.153)。フィル・ヴェナブルズは「必要なのはセキュリティ製品ではなく、セキュアな製品」だと指摘しました(P.155)。この方法論を徹底したアップルも、iPhone 5s以降に搭載されたセキュリティチップ「Secure Enclave」で成功を収めました(P.156)。このチップは、セキュリティ特化のハードウェアをメインプロセッサから独立させ、スマートフォンの盗難リスクに対する優れた対策となりました。 各社がセキュリティに注力する中、ハッカーにとって脆弱性を攻撃するコストは増大し、ターゲットは次第に人間の脳へと移行していきました。 6 ユーザブルセキュリティ、経済学、心理学 1999年、プリンストン大学のエドワード・フェルテンは「豚のダンスとセキュリティのどちらかを選ぶよう迫られたら、ユーザーは常に豚のダンスを選ぶだろう」と述べました(P.160)。一般的に、ユーザーのセキュリティ意識は低いものとされてきました。 セキュリティは最も弱い部分に合わせて全体の強度が決まるため、強固なセキュリティシステムも、管理者の弱点により全体が脆弱になります。 「ユーザブルセキュリティ」の研究は1999年には始まっており(P.162)、優れた暗号化プログラムがあっても、ユーザーインターフェースの設計が悪ければ、目的を達成できないというユースケースが示されています。ユーザーは通常、セキュリティに関心がなく、セキュリティに関する設定において、ユーザーに判断させないことが望ましいとされました。これは2005年のSOUPS（Symposium on Usable Privacy and Security）での研究発表で明らかにされました(P.165)。 フィッシングは2003年に新しいタイプの攻撃として言及され、2005年頃から注目を浴びるようになりました。(P.167) ファイアウォールによって多くの攻撃はブロックされるようになりましたが、メールはファイアウォールを通過するため、ハッカーはこれを利用しました。 パスワードは1961年にMITで開発された「互換タイムシェアリングシステム」で初めて使用されました(P.173)。パスワードは本来シンプルなセキュリティ機構ですが、ユーザーの心理的問題から複雑化し、さまざまな問題が発生しています。 グラフィカルパスワードや生体認証などの代替技術は、パスワードよりも優れた認証手段を目指していますが、使いやすさの面でまだ完全な代替にはなっていません。 ケンブリッジ大学のセキュリティ工学教授ロス・アンダーソンは情報経済学への扉を開きました(P.183)。2001年には「なぜ情報セキュリティの実現は困難なのか—経済学の視点から」が発表されました。 心理学の観点では、フィッシングやソーシャルエンジニアリングを行っていたハッカーは、セキュリティ研究者を大きくリードしていました。 経済学的には、情報セキュリティを高めることが必ずしもプラスであるとは限りません。過剰なセキュリティを達成するためのコストが、セキュリティリスクの期待値を上回る場合もあります(P.197)。情報セキュリティの分野では、このようなコストとリスクのバランスが考慮されていないことが多いです。 7 脆弱性の開示、報酬金、市場 2000年代初頭には、ゼロデイ脆弱性を公表することが必要だというコンセンサスがありました(P.206)。しかし、脆弱性をソフトウェア企業やハッカーが際限なく探し出し、一種の「デススパイラル」に陥っているとも言えます(P.208)。 ゼロデイ脆弱性の公表の是非は、パッチが存在する脆弱性を悪用するハッカーが大勢いるのと、パッチが存在しない脆弱性を悪用するハッカーが少数いるのとで、どちらがより悪質かという問題です(P.213)。これは「ディスクロージャ」の問題です。 かつての脆弱性を完全に公表するフルディスクロージャから、責任ある開示「レスポンシブル・ディスクロージャ」へと徐々に変化しました(P.216)。 ゼロデイ脆弱性は攻撃にも防御にも利用されます。NSA（アメリカ国家安全保障局）は2014年に公表されたHeartbleed脆弱性を、少なくとも2年前からゼロデイ脆弱性として攻撃に利用していたと非難を受けています(P.220)。NSAには、米国の敵国への攻撃と国内のコンピュータセキュリティの確保の二つの使命が与えられていました。 2010年代に入り、多くの企業がバグ報奨金制度を導入しました。これにより、研究者は報酬を得るために、企業にとって有益な脆弱性を探すインセンティブが働きます。 こうした硬直した時代に、ハッカーはアピールのための「スタントハッキング」を発明しました(P.233)。これは、自動車や航空機、医療機器など日常に使用される機器に対するハッキングを行い、その結果を公表するものです。これにより、セキュリティの脆弱性が一般人にとって恐ろしい脅威であるという認識が広まりましたが、実際にはハッカーたちが自己利益のために誇張し、歪曲した幻想と言えます。 8 データ漏洩、国歌によるハッキング、認知的閉鎖 ここでは、情報セキュリティの3つの汚名について述べます。 一つ目は「データ漏洩」です(P.238)。データ漏洩により流出した金融取引や既往歴などの個人情報は、ブラックマーケットで売買され、犯罪者によって成りすまし犯罪などに利用されます。この種の攻撃では、被害を受けた企業と利用者の両方に多大な負担がかかります。 二つ目は「国家によるハッキングがもたらす害」です(P.250)。中国61398部隊によるオーロラ攻撃をきっかけに、APT（Advanced Persistent Threat）という言葉が生まれました。中国と同様、ロシアもハッキング能力向上に多大な資源を投入しており、「ファンシーベア」はロシアの軍事諜報機関GRUと関連する大規模ハッキンググループです。彼らは大統領選挙時にヒラリー・クリントンのホームページに侵入し、改ざんするなど積極的に政治的主張を行いました。中国、ロシア、米国が到達したハッキング能力は、個人では到底到達できない領域です。 三つ目の汚名は「情報セキュリティ分野における『認知的閉鎖』によって生じる機会費用」です(P.264)。閉鎖的なコミュニティ内で構築された虚偽の現実（エコーチェンバー）が、情報セキュリティ分野でも見られるという問題です。1983年にUNIXの共同開発者ケン・トンプソンは、「マスコミやテレビ、映画が、破壊者を『天才的な若者達』と呼び、ヒーロー視する」ことが、「極めて危険な状況を生みつつある」と警鐘を鳴らしていました(P.266)。バグ報奨金制度などを通じて、この傾向はさらに顕著になったと言えます。 9 情報セキュリティの厄介な本質 セキュリティに関する主張には反証可能性がないという問題があります(P.276)。効果のないアドバイスを反証することが難しく、NISTの「組織と情報システムのためのセキュリティおよびプライバシー管理策」などは500ページを超える膨大な量です。その結果、混乱と非効率が生じ、情報セキュリティを専門とする企業ですら、自社のセキュリティ維持が困難になっています。 セキュリティ標準の共通目標は、情報セキュリティの特定の側面において、複雑さを軽減し、より管理しやすくすることです(P.281)。情報セキュリティ分野では、統計の乱用が長年問題となっています(P.284)。恣意的に操作された統計を用いて、実態よりも悪く見せる逆インセンティブが存在します。 コンピュータセキュリティの根本的なジレンマとして、セキュリティを望む人々が、セキュリティを評価・改善するための判断能力に欠けていることが挙げられます(P.294)。 情報セキュリティにおける攻守のバランスは、今後の課題となっています。現在、攻撃する方が簡単であり、守る方が困難という状況が続いています。 「多層防御」は、層が多ければ多いほど良いという考え方が一般的ですが、これがかえって複雑性を増し、セキュリティに悪影響を及ぼすこともあります。 本を読んで 本書を読み進める中で、現在問題となっているさまざまなセキュリティ上の課題も、実は突然現れたものではなく、長い歴史の中で徐々に形成されてきたことがよくわかりました。情報セキュリティの問題は、その時々の技術や社会の動向と密接に関連しており、時系列を追うことで、問題がどのように発展し、どのように解決されてきたかを理解する手がかりとなります。 また、本書を通じて気づいたのは、情報セキュリティの教科書の多くが、依然として情報セキュリティ分野に閉じた視点で書かれていることです。経済学や心理学など、他分野の視点を取り入れることが、より実践的で効果的なセキュリティ対策を構築するために重要であると感じました。現代のセキュリティ問題は、技術的な側面だけでなく、ユーザー行動や組織の経済的動機といった多様な要因が絡んでおり、これを無視することはできません。 先日起きたKADOKAWAやニコニコ動画に対する攻撃も、本書で提唱されている「情報セキュリティの3つの汚点」から解釈することができます。データ漏洩、国家によるハッキング、そして認知的閉鎖といった問題は、現代のセキュリティリスクの根本的な要因として依然として存在しており、これらを理解し、対策を講じることが求められています。 本書は、やや難解な部分もありますが、情報社会の未来を見据えたキャリアを積みたい人にとっては、非常に価値のある内容です。情報セキュリティの歴史的背景や、技術的な進展だけでなく、経済学や心理学といった多様な視点が取り入れられており、現代のあらゆる情報社会での活動に活かせる内容でした。読んで損をすることは決してありませんので、ぜひ手に取ってみてください。 『｢技術書｣の読書術』書評 こんにちは、セキュリティエンジニアの河村です。この度初めてsqriptsに記事を執筆することになりました。数回にわたって技術書を紹介していく予定です。今回は技術書を読むための本、『｢技術書｣の読書術』の書評を行います。本の概要『｢技術書｣の読書術』は、数々の... 　続きを読む　 Sqripts 関連記事｜Sqripts The post 『情報セキュリティの敗北史　脆弱性はどこから来たのか』書評 first appeared on Sqripts .

ソフトウェア開発の世界では、アジャイル開発やスクラムが一般的になってきました。そのアジャイル開発のコアとも言えるのが、対話や協調です。この連載では、アジャイル開発におけるコミュニケーション・コラボレーションスキルを解説しながら、ファシリテーションスキルのレベルアップを目指します。 第8回目のテーマは「1on1」です。 ＜スクラムマスターのためのコミュニケーション講座　連載一覧＞ ※クリックで開きます ・ #イントロダクション：優れたスクラムマスターが絶対に言わないこと 【連載初回、全文公開中】 ・ あなたの提案はなぜ受け入れられないのか？｜ファシリテーション技術-1- ・ よりよい場を作るための9つのルール［前編］｜ファシリテーション技術 -2- ・ よりよい場を作るための9つのルール［後編］｜ファシリテーション技術 -3- ・ コーチング技術 〜 基本技術を学ぼう｜コーチング技術 -1- ・ コーチング技術 〜 質問力を高めよう｜コーチング技術 -2- ・ 上級者が活用する質問例｜コーチング技術 -3- ・ 実践1on1 〜 簡単だけど難しい1on1 前回のおさらい 前回までは、ファシリテーション、コーチングと解説してきました。この連載で紹介する最後のコミュニケーション方法は「1on1」です。 1on1は、今ではよく使われる方法ですが、学びにくい方法とも言えます。そういった理由と学び方、使い方をここでは解説したいと考えています。 心理的安全性のための対話 心理的安全性を生み出すための対話 我々は会話だけでなく、討論、議論、対話とさまざまな方法で相手と情報交換します（参考： 誤解されがちな議論と対話の違い｜CULTIBASE Radio｜Management #6 ）。 会話や雑談は、お互いの印象を良くする効果があります。特に理由なく「天気がいいですね」なんて言いません。なにかしらのつながりを求めて会話を行っているはずです。 討論はどの主張が正しいかを決めるもので、議論は意思決定を行うためのものです。どちらも結論を求めるので、勝負をつけるためのコミュニケーションと言えます。 ファシリテーションの回でも解説しましたが、現在は多様な個性が集まるため、正解のない世界が広がりつつあります。この世界ではなかなか白黒つけられません。しかし前に進まなければならない現実もあります。 このときに役立つのが対話です。 対話によってお互いの主張や考えを明確にして、心理的安全性を高めていきます。 対話とは何か？ 対話はお互いをわかり合うためのツールです。簡単にまとめると 私はこういう考え方をしています。 あなたはこういう考え方をしています。 お互いの考え方には違いがあります。 という情報交換になります。お互いの情報を交換し、その違いを理解するだけですが、交換により新しい情報を双方が得ます。これによって、相手の理解が深まり、選択肢が広がり、勝ち負けでは決められない物事を前に進める準備ができます。 そして、我々はこの状況を踏まえて、結論を出さなければなりません。 お互いのことを理解した状態を作り、それを踏まえた上でどうするかを決める必要があるのです 。 このあたりはリーダーシップの話にも通じるため、ここでは深く説明しませんが、対話によって対話後の議論が少しスムーズになります。対話の実践例を以下に紹介します。ここでは「関係性がうまくいっていない二人」に対して対話を促しています。 Aさん「私はあなたの◯◯がとても嫌だと思っている」 Bさん「私こそあなたの□□を不愉快に感じています」 私「お互いにそう思っていることがわかりましたね。では、このわかった情報をふまえて、もう一度相手のことをどう感じるか教えてください」 Aさん「・・・。相手もそう思っているとは思わなかった」 Bさん「こちらも相手が同じように思っているように思わなかった」 私「また理解が進みましたね。では繰り返し、この情報を踏まえて・・・（繰り返していく）」 お互いがお互いを100％理解するのは不可能です。なのに、我々は「理解したつもり」になりやすい。はじめのうち、それは小さなすれ違いでしかないかもしれませんが、のちに大きな間違いを生み出していきます。よって、このような対話を活用し、お互いが歩み寄り、解決策への協力体制を築いていきます。 1on1と対話 1on1は、対話を中心に相手の成長を支援する方法です。主に人材育成の手段として使われ、企業内だと上司部下の関係性の中で成果を追求していく方法と言えます。 上司と部下という特性上、コーチングのようなパートナーシップを作るのは難しいですが、リーダーやマネジメントのあり方が変化している時代にあわせて、マネジメントとメンバー間に対等な関係性を作ろうとする企業も多くなってきました。「マネージャ ＝ 管理・偉い」 といった価値観も「マネージャ ＝ 支援・対等」へと変わろうとしています。 対等な関係性を意識するため、1on1は基本的に部下が話したいことを話す時間になります。ただ、1on1の特性上、成果を求めるものになるので、1on1をやる意味や、期待する成果や効果は、1on1をはじめるまえに合意しておきます。そうすることで、1on1がただの雑談になるのを防ぎ、期待する成果を出すための場に変わります。 1on1で話す内容は守秘義務によって守られています。安心安全な場を作るために、1on1で話した内容はお互いに他言すべきではありません。中には共有した方がいい情報も出てきます。そういった場合は、双方合意の上で共有します。 くりかえしになりますが、1on1は対話によってお互いの理解を深めていきます。しかし、上司として、時にはコンサルタントとしてアイデアを提供したり、ティーチャーとして解説したり、コーチとして支援したりと、さまざまな帽子をかぶり、かぶりなおしながら対応していくケースも多いでしょう。 そのためには、さまざまなコミュニケーション方法の理解が必要です。理解だけでなく、実践経験も積まなければなりません。1on1は簡単にはじめられるツールですが、扱うのが難しいツールとも言えるのには、こういった理由があります。 1on1のフォーマット例 スクラムマスターだとあまりないかもしれませんが、アジャイルコーチだとスクラムマスターやアジャイルチームを育成する場合があります。筆者の場合、そういった育成に1on1を活用しています。 私がよくやっている1on1のフォーマットは現在以下のようになっています。 近況 アイスブレイク。仕事とやプライベートの雑談 アクションの確認 前回決めたアクションを共有する アクションについて、アップデートがあればその内容を聞く 今日話したいこと 次のアクション クライアントに伝えたいこと（あれば） 前回学んで今回アップデートすること 前回の1on1後に個人でふりかえりを行い、アップデートすることをここにメモして次回その内容を試す この流れを1on1で繰り返し、初回や3ヶ月おきなどに目標を設定して、方向性を調整します。 アジャイルチームやスクラムマスターを相手にすると、以下のようなトピックが多くなります。 これってスクラム的に正しいんだっけ？ こういうときにアジャイル開発だとどうするんだろう？ チームでこっちに進むためには何をすればいいんだろう？ はじめは方法（How）や手段（What）が気になるものです。しかし、1on1を続けていくうちに知っていることが増え、知らないことが減るので、相談内容が変わっていきます。 こういう正解のないケースの場合、どういう選択肢があるのだろうか？（アジャイル開発の原理原則を理解した上で、どう判断するべきかを悩むようになる） キャリアを考えた場合に、どういったアクションを行っていくべきだろうか？（アジャイル関係ないけど、人生にとって大切なテーマに向き合えるようになる） リーダーシップとはなにか？ 自分にマッチするリーダーシップは何なのだろうか？（アジャイルチームの一員から、ひとつ上のリーダーシップに関心が移る） ここまでくると、コーチングが機能します。時には自分の経験を提供する場合もありますが、このレベルの人であれば、自分で答えを見つけられるスキルをもう身につけているからです。 ＊ 今回は、1on1について解説しました。1on1は幅広いスキルが求められ、相手に応じた対応も必要なので難しい技術と言えます。しかし、対話を用いたコミュニケーションは心理的安全性を高め、大きな成長が期待できます。ここまで世界的に1on1が広がっているのも、その効果の高さがあるからでしょう。 初心者が陥りやすい罠としては、上司と部下という関係上、「相手の話を聞くのではなく、自分の話を語ってしまう症候群」があります。その場合は、特効薬として、「1on1で自分の話をしない宣言」をしてみてください。相手の話を聞くだけで、新しい発見がたくさんあることに気がつくはずです。 次回は1on1のなかで利用されるさまざまなコミュニケーション方法を学びます。 連載一覧 ・ #イントロダクション：優れたスクラムマスターが絶対に言わないこと 【連載初回、全文公開中】 ・ あなたの提案はなぜ受け入れられないのか？｜ファシリテーション技術-1- ・ よりよい場を作るための9つのルール［前編］｜ファシリテーション技術 -2- ・ よりよい場を作るための9つのルール［後編］｜ファシリテーション技術 -3- ・ コーチング技術 〜 基本技術を学ぼう｜コーチング技術 -1- ・ コーチング技術 〜 質問力を高めよう｜コーチング技術 -2- ・ 上級者が活用する質問例｜コーチング技術 -3- ・ 実践1on1 〜 簡単だけど難しい1on1 The post 実践1on1 〜 簡単だけど難しい1on1 first appeared on Sqripts .

こんにちは。バックエンドエンジニアのカズです。 最近、開発効率を向上させるためにAIを活用することが増えてきています。この記事では、Claude　3.5 SonnetのArtifacts機能をどう開発に活用するかについて共有したいと思います。 Claude 3.5 Sonnetとは Claude 3シリーズはAnthropic社の生成AIモデルであり、Claude 3.5 Sonnetは2024年6月21日にリリースされました。このモデルでは、従来のモデルの2倍の処理速度を実現し、自然言語処理、推論、判断能力が向上している点や、画像や動画の視覚情報を理解することができるマルチモーダル対応や、コード生成を行うことができるようになっています。 Artifacts機能とは Artifactsの具体例としては、以下のようなものがあります。 プログラマー向け: まとまったコードブロックやReactコンポーネント ビジネスユーザー向け: 詳細なレポートやプレゼンテーションの資料 デザイナー向け: 複雑な図表やダイアグラム •ウェブ開発者向け: 完成度の高いウェブページのHTMLコード しかし、ユーザーの質問への回答にArtifactsを利用するかどうかは、回答の長さや複雑さに基づいてClaude側で自動的に判断されます。また、同じ言語の複数のコードファイルが、コメントで区切られて1つのArtifactsにまとめられることがあります。 使ってみる Claude 3.5 Sonnetは こちら のサイトで利用できますが、Artifacts機能は初期設定ではOFFになっているので、 設定画面 のEnable ArtifactsをONにします。 今回は、この機能を使って、Reactで簡単なSNSサイトを作ります。 LLMの特性上、この記事での画面レイアウトとは別のものが生成される可能性がある点に注意してください。 まずは、「 Reactを使って簡単なSNSサイトを作ってください。 」と指示を行います。 このように数秒でWebサイトが完成しましたが、まだユーザー認証やコメント機能の追加が行われていないので、次に、「 ログイン機能とコメント機能を追加してください。 」と指示を行います。 指示通りの機能が追加されました。 しかし、編集や削除機能が足りないため、まだ未完成の状態です。 次に、「投稿の編集・削除機能を追加してください。」と指示を行います。 このように、簡単な指示を3つほど与えるだけで、シンプルなSNSサイトが完成しました。 この状態ではまだサーバサイドの実装ができていないので、実際のアプリケーションでは実装を行う必要がありますが、その実装についても生成を行うことができます。以下の画像は、その一部の例となります。 このように導入手順まで示して解説が行われます。 しかし、生成されたコードは必ずしも完璧ではなく、使用前に必ず確認し、エラーや文法、セキュリティやライセンスについて確認する必要があることに留意してください。 まとめ このように、ソフトウェア開発の初期段階で素案を作成し、アイデアの説明をスムーズにすることや、開発中の問題解決に役立っていると感じます。 一方で、間違っているコードがあり実際に実行してみると動かないなど、チェックや修正が必要な点も多々あるため、自分自身の知識も必要だと考えます。 AI生成は開発プロセスを大幅に加速させる可能性を秘めていますが、それを活用する人間の判断と専門知識が最も重要です。これらの注意点を守ることで、AIの力を最大限に活かしつつ、安全で信頼性の高いソフトウェア開発を実現できるでしょう。 The post Claude 3.5 SonnetのArtifacts機能を使ってみた first appeared on Sqripts .

本連載ではプロジェクトマネジメントの全体像と、プロジェクトを成功させる上で最低限抑えるべき知識と技術はもちろん、プロジェクトを炎上させないための技術やコツをお伝えしたいと思っています。 みなさんのプロジェクトが今以上に充実し、笑顔でプロジェクト終結を迎えられるよう一緒に学んでいきましょう。 ＜ プロジェクトマネジメント成功の技術 連載一覧＞ ※クリックで開きます 【第1回】プロジェクトマネジメントとは何か？ 　［連載初回全文公開中：Sqripts会員以外の方も全文お読みいただけます］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ 【第8回】コストをプロジェクトの武器にする！ 【第9回】目に見えにくいプロセス管理こそ品質達成の鍵 【第10回】プロジェクトのリスクマネジメント［前編］リスクを徹底的に洗い出す 【第11回】プロジェクトのリスクマネジメント［後編］リスク分析とコンティンジェンシープラン 【第12回】人がプロジェクトの源泉！チームは育てて強くする［前編］ 【第13回】人がプロジェクトの源泉！チームは育てて強くする［後編］ 【第14回】コミュニケーションの本質を知り、使いこなそう！ プロジェクトマネジメントを勉強する人やPMが必ず出会う言葉に「PMの仕事のXX％はコミュニケーションである」というものがあります。PMP試験でも問われる古典的な質問ですが、その正解は「90％」です。とはいえ実際に90％やそれに近い数字かは別として、コミュニケーションがプロジェクトとPMにとって大変重要なのは間違いありません。 しかし、よくよく考えてみるとこの「コミュニケーション」というのが曲者です。単純に対話するだけでなく、聞く、公式・非公式の伝達、相手への説得、メディアの活用などあらゆる場面でコミュニケーションという言葉が使われ、とても複雑で曖昧な要素を含むからです。 プロジェクトをマネージメントするにあたりコミュニケーションやスキルが大切だ、と言われ否定する人は少ないでしょう。だからこそ、この「漠然としたコミュニケーション」を「使いこなす」ために、「具体的にどのようなコミュニケーションが必要なのか」を分解・整理していきましょう！ プロジェクトにおけるコミュニケーションとは 1) 概念 PMは異なる文化・組織的背景を持つステークホルダーの橋渡し役を務め、プロジェクト活動に必要な「情報交換（送受信）」を円滑に行う必要があります。プロジェクト情報の収集、配布、保管、マネジメント、監視、最終的な廃棄などを適切且つ確実に行うために、以下のようなステップでコミュニケーションマネジメントの計画を立て、実際にマネジメントし、計画が想定通りに進んでいるか監視します。 2) 情報交換のメカニズム 情報交換におけるメカニズムや種類は目的や状況に応じて使い分けなければなりません。情報交換の効率や効果を高めるために、これらの要素を理解し切に活用していきましょう。また必ずしも同じ情報交換方式を使い続ける必要はありません。重要なのは、その時々に適した方法を「意識的に選択し、活用できているか」です。 伝達手法 　　　：書面、物理的または電子的（言語・非言語） 口頭 　　　　　：対面またはリモート 正式または略式 ：正式な書類またはソーシャルメディアなど 身振り 　　　　：口調や顔の表情、ボディーランゲージ メディア 　　　：写真、行動、簡潔な言葉の選択、聴覚 言葉の選択 　　：一つのアイデアを表現する一つ以上の様々な語句 3) コミュニケーションの活動対象とその側面 内部 　　　：プロジェクト内および組織内のステークホルダー 外部 　　　：顧客、ベンダー、その他の外部ステークホルダー 正式 　　　：正式な会議（定例および臨時）、会議の議題と議事録など 略式 　　　：電子メール、SNSなど簡略的なコミュニケーション活動 書面と口頭 ：口頭（言葉と声の抑揚）と非言語（ボディランゲージ） 公式 　　　：年次報告書、規制当局や政府機関への報告書 上方 　　　：上級経営層のステークホルダーへ向けたもの 下方 　　　：プロジェクトの作業に貢献するチームなどへ向けたもの 水平 　　　：プロジェクト管理者やチームの同僚へ向けたもの 4) コミュニケーションスキルというものの実態 ひとつの例として、プロジェクトのスケジュールを承認・合意するまでのシーンで考えてみましょう。 上記はごく簡略した流れであり、また進め方はこの流れに限らないでしょう。しかし言えることは、コミュニケーションと呼ばれる活動は細かく分解でき、多彩なスキルで構成されているということです。冒頭にお伝えしたように複雑で曖昧な要素を持ち、あえて言えば「まとまった実態がない」のです。ですから、コミュニケーション能力がある・ない、必要だ、と漠然と語るのではなく、どのようなコミュニケーションスキルが不足していたのかを細かく考えたり、その結果に沿った対応することが必要ですね。 なぜプロジェクト内のコミュニケーションは上手くいかないのか 1) コミュニケーションはメンバーの数だけ煩雑になる（N理論） PMは「コミュニケーション・チャネルの総数を意識せよ」と言われますが、どういうことでしょうか？ コミュニケーション・チャネルとはプロジェクト（あるいは組織）内のコミュケーション経路を指します。そしてチャネル数はコミュニケーションに関わる人の数です。 コミュニケーション・チャネル数の計算式は：n(n-1)/2 n=ステークホルダーの人数 ひとりの人から見たコミュニケーションの 相手 が5人だとすると、チーム6人全員の組み合わせは 6人×（6-1）＝30、コミュニケーションは双方向であることから 30/2＝15 がチャネル数なります。ここで直感的に感じるのは、人が増えれば増えるだけコミュニケーションは複雑化する、つまり誤解やコンフリクトの可能性が増えるということです。「一応XXさんに情報共有しておいて」「XXさんは直接活動しないけれど、体制にいれておく」といった安易なメンバー増幅はとても危険だということです。「適切に最小限のメンバーで活動すること」が、コスト面で考えたプロジェクトにもコミュニケーションマネジメントにも効果を発揮します。 2) 「ノイズ」を理解して、転ばぬ先のコミュニケーション コミュニケーションは単純化すると以下のような送信者・受信者の関係（モデル）があります。 双方向のコミュニケーションはシンプルに見えて実はやっかいです。なぜならそこには常に「ノイズ」が発生し、必ずと言って良いほど自分が思うことはシンプルに相手に伝達されないからです。できることはそのノイズの存在を受け止めた上で「いかにノイズを小さくする工夫が（少なくともこちらから）できるか」に尽きます。 みなさんが伝えたいことは、他者が正しく理解できるようなテキスト、音声、媒体などで構成されていますか？ そのメッセージに合わせた媒体を選択しましたか？（口頭伝達が望ましいメッセージなのに、安易にメールを選択するなど） ノイズを考慮した上で、メッセージが受け取られ且つ正しく理解されているか確認を怠りませんでしたか？ ノイズの例） 物理的ノイズ　: 通信路における物理的な干渉（例: 声の届きにくさ、通信機器の故障） 心理的ノイズ　: 受信者の気分や状態による情報の受け取り方の変化（例: ストレスや集中力の欠如） 言語的ノイズ　: 言葉の意味や用法に関する誤解（例: 専門用語の使い方） 3) その他の考慮しておきたい事項 考慮したいこととしては、コロナ禍以降増えたリモートワークを含め、チームメンバーの物理的な場所やグローバルチームであればメンバーのタイムゾーン、使用できるコミュニケーション方法/技術/ツールとコスト効率、チームの多様性に考慮した言語の適用やルール決め、チームの知識レベルに合わせたリポジトリの活用など様々です。プロジェクトにフィットしたコミュニケーション環境を注意して設定するようにしましょう。 ミスコミュニケーションは必ず起きる。誤解に対処し続けることが大切 コミュニケーションにおける誤解とは、情報の発信者と受信者における「解釈の齟齬」です。 どれだけ綿密に計画しコミュニケーションを図っても、誤解の発生をなくすことはできません。注意しながらもプロジェクト内に誤解や衝突が発生した際には、すぐにPMが解消に向けてアクションしましょう！コミュニケーション・マネジメントに簡単な近道はありません。 1) コミュニケーションの5Cを抑える コミュニケーションにおいては、これら5つの「C」を意識することで、情報伝達の誤解を未然に防ぐことができます。 2) やっぱり基本のコミュニケーション・スキルが大切  PMBOKでは以下のようなスキルをPMに要求しています。この中に「メンバのスキルを（PMが）向上させる」とありますが、PMがすべての情報を管理したり架け橋になることは現実的に不可能ですので「プロジェクト・チーム全体で対処できるようにPMが働きかける必要がある」とわかりますね。コミュニケーションはPMひとりが頑張れば叶うものではなく、チームや組織全体で創って行けるように働きかけたいですね。 さいごに プロジェクト計画後はコミュニケーションと実行管理（監視・コントロール）にPMリソースの多くが注がれます。コミュニケーションは常に「思うように行われない」と考え、情報を伝えたり報告を受けるだけで満足せず、あらゆる伝達方法を駆使しながら「正しく伝わっているか」を確認し続けなければなりません。コミュニケーションを現場の力に変えていきましょう。 連載一覧 【第1回】プロジェクトマネジメントとは何か？ ［連載初回全文公開中］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ 【第8回】コストをプロジェクトの武器にする！ 【第9回】目に見えにくいプロセス管理こそ品質達成の鍵 【第10回】プロジェクトのリスクマネジメント［前編］リスクを徹底的に洗い出す 【第11回】プロジェクトのリスクマネジメント［後編］リスク分析とコンティンジェンシープラン 【第12回】人がプロジェクトの源泉！チームは育てて強くする［前編］ 【第13回】人がプロジェクトの源泉！チームは育てて強くする［後編］ 【第14回】コミュニケーションの本質を知り、使いこなそう！ The post 【第14回】コミュニケーションの本質を知り、使いこなそう！ first appeared on Sqripts .

皆様こんにちは、ざわ です。 2024年8月23日(金)に開催された、JaSST’24 Hokkaidoに参加してきました。 初めてのJaSST参加で緊張しましたが、有意義な時間を過ごすことができました！ 基調講演の内容を主に、参加レポートを書いていきたいと思います。 今回のテーマ：りすっきりんぐテスト(テストリスキリング) 今回のテーマは、「りすっきりんぐテスト」とし、テスト技術・知識を学び直し、より深くそして新たに身につけることを目指します。 (中略) みなさんと一緒に学び直し、新たな可能性を考え、再度(Re)すっきりとした気持ちでテストに向き合える。そんなシンポジウムにしたいと思います。 JaSST’24 Hokkaido 開催要項 日々、技術が進歩していく中で、自分の技術はその進歩に追いついているだろうか？ また、追いつくために今、何を学び、身につけていけばいいのだろう？ そんなことを考えていた私にとって、「リスキリング」というテーマは特に心に響くものでした。 (「りすっきりんぐ」が可愛らしくて、ぐっと肩に入っていた力が抜けたのは秘密。。。) 普段、テスト設計やテスト実装を主に担当する中で、すでに知っていて活用している内容もあれば、普段あまり触れない部分の話もありました。知っているからと、振り返ることを怠っていた部分も、新たな知識とともに見直すことで、見落としていたかもしれない部分が見えてきました。まさに「再度(Re)すっきり」という気持ちです。 基調講演：「ソフトウェア品質のダンジョンマッピング」 登壇されたのは、株式会社 日立製作所 サービスプラットフォーム品質保証本部 担当部長の鈴木一裕様です。 広く奥深いソフトウェア品質の世界を、RPGの剣と魔法のダンジョンに見立て、戦士や僧侶などのRPG職業がそれぞれQAで何が得意なのかを考え、自分が現場から離れている今、どの職業に該当するか…そうか、マッパーだ！ という発想から、このタイトルになっているようです。(マッパーという職業は初耳でした！) ソフトウェア品質のダンジョンを進みながら、次々と登場するキーワードを数珠繋ぎにしていく中で、自分が知らなかった分野を学び、リスキリングのネタを見つけてほしいというお話でした。(RPGに例えられるとワクワクしますね！) 基調講演は90分間でしたが、大変面白く、また興味深く拝聴したので、あっという間に感じました。 大まかな講演の流れ 「ソフトウェア品質保証」という広大なダンジョンに、どこから踏み込んでいくのか…。まず、多くの人々が入口とするであろう「テスト実行」から始まり、次に「バグ管理とバグ分析」→「テスト管理・計画」→「テスト実装」→「テスト分析・設計」→「レビュー」→「プロセス改善」→「品質と価値」→「QAエンジニアの仕事」という流れで進んでいきます。 最後に「90分ではとても歩き切れませんでした」とおっしゃっていましたが、こうして概要を見ただけでも、ソフトウェア品質のダンジョンがいかに広く深いかが伝わってきますよね。すべてについて語りたいところですが、ダンジョンはあまりにも深遠ですので、今回は特に重要なポイントをピックアップしてレポートしたいと思います。 なぜあなたのテスト実行は退屈なのか？ ダンジョンは「テスト実行が退屈だという方はいますか？」という問いかけから始まりました。 この問いかけに積極的に手を挙げることはなかったとしても、誰しもがテスト実行中に「退屈だ」と感じる瞬間があるかもしれません。会場内の皆様も同じように感じたのではないでしょうか…私もそうでしたし、私の席から見える範囲では、挙手された方はほとんどいませんでした。(とはいえ、鈴木様もこれを想定されていたのか、会場を和ませる笑いに変えてくださいました) テスト実行が退屈に感じられる要因として、以下の点が挙げられました。 要因1 : 単調な繰り返し 要因2 : テストの必要性が不明 要因3 : 厳密すぎる手順 要因4 : 無秩序なプロセス 要因5 : バグが出ないことへの苦しさ これらの要因は、これまでの経験からもよく理解できるものばかりです。それに対して、対策として以下の5つのアプローチが示されました。 自動化 テスト分析・設計 柔軟なテストおよび探索的テスト ユーザ価値の深い理解 テストの目的の確認 ただし、各要因に対する対策は一つだけではなく、複数のアプローチが有効であることが多いです。 例えば、要因3の「厳密すぎる手順」については、対策として「テストの自動化」と「柔軟なテストおよび探索的テスト」が示されています。テスト実行は本来、知識や理解力、観察眼、さらにはコミュニケーション能力など、さまざまな能力が求められる難易度の高い作業です。プロダクトを理解し、お客様にとっての価値を判断するのは、結局のところ人間の力によるものであり、そのため「テスト実行を推していこうよ」という考え方が示されました。確かに、QAは上流の作業だけでは完結しません。 手動でテスト設計を主な業務としている私にとって、求められているテストがどのようなものであるか、そしてプロダクトの価値をしっかりと見極めて分析・設計を明確に行うことは、非常に重要であり、またすぐにでも実践すべきことだと思います。それは「退屈でない」テスト実施だけでなく、QAの質を向上させることにも繋がるのではないでしょうか。 テスト設計を進めるうえで、改めて「分析」の重要性を見直し、明確で価値のあるQAを実践していきたいと考えています。例えば、過去の事例から学ぶことも大いに有効だと思いますので、まずは鈴木様が紹介されていた本を読んでみるつもりです。過去事例を知り、知見を広めていくことで、同様のケースでなくても応用できると思いますし、自分とは異なる考え方を知ることができ、そうして取り入れた知識や視点でプロダクトに向き合うことで「分析」の一助になるのではないかと思っています。 テスト実行に限らず、他の点についても同様ですが、多角的な視点で物事を見つめることが重要であると感じました。 テスト分析の必要性 テスト設計技術も進化しており、従来の技法の親戚的な技法や、アジャイル開発、機械学習、AIとともに普及が進んだ技法、非機能要件やドメイン固有のテスト技法が挙げられています。この分野は常に進化し続けており、勉強のし甲斐があるというお話がありました。 基調講演から話は逸れますが、今回のワークショップ「技法を探せ！」では、示されたお題に従ってどのようなテスト技法を適用できるかを探し、また他の参加者が見つけたテスト技法を知ることで、今後のテスト設計に役立てることが目的とされました。 限られた時間の中ではなかなか難しく、知識や技術をうまく応用するためには、やはり勉強を続けて身につけていく必要があると感じました。 「テスト分析の必要性」という見出しをつけましたが、設計の話に移ってしまいました。なぜなら、これらの設計技術を活用してテスト設計を行うには、「テスト分析」が先に行われるべきだからです。 テスト設計は「プロダクトの何をテストするのか」という点から始まりますが、その「何」を決めるためにはテスト分析が不可欠です。テスト分析は「テストを通じてどのように品質保証するのか」という全体像を描く技術として位置づけられています。 テスト設計を進める中でテスト分析を行っているつもりでも、全体像を描けているかというと、まだ足りないと感じることがあります。「QAエンジニアとして、この全体像を描く技術を身に着けるべきだ」との指摘がありましたが、「全体像を描く」というスキルはテスト設計だけでなく、管理などの分野にも重要であると感じました。 生成AIの活用 今回の基調講演では、生成AIの活用についても言及されました。 バグ分析： 生成AIを使ってバグ分析を行うようになる可能性 テスト設計： 生成AIを活用したテストの適用により、機械学習におけるテスト設計の課題を解決していく レビュー： 「チェックリストベース」のレビューを生成AIで実施できるようになる可能性 様々な部分で活用が進められているAIですが、具体的な用例とともに言及されたのは、AIをうまく活用するためには「言語化能力」が改めて求められるという点です。 確かに、生成AIに対して内容が明確でない問いかけを行うと、求めている答えとは異なる返答が返ってくることがあります。単なる趣味で一文尋ねた場合でもそのように感じることがあるため、QAの各分野に活用する際には、人間側のロジカルな言語化能力を鍛える必要があると感じます。 QAとは直接関係がないのですが、小学生の社会・算数・理科の成績と国語の成績には高い相関関係があるという学術記事を読んだことがあります。かなり古い記事なので、その内容が現在も学術的に認められているかは分かりません。 しかし、読解力や表現力などの国語の基礎学力が他の教科に影響を及ぼすという点と、生成AIに内容を理解してもらうために言語化能力が必要だという話は、人間とAIのやり取りにも相関関係があるように感じられて、興味深いと思いました。 技術の勉強は、学んだ直後にすぐ応用できるほど簡単なものだけではないかもしれません。しかし、技術の習得を続ける中で、それを自分なりに理解し、応用できるようになるためには、ロジカルな思考力と表現力が必要だと改めて感じました。 これらの能力は、QAの分野だけでなく、社内外でのコミュニケーションにおいても重要だと思います。「日本人はハイコンテキストであることを自覚する」というお話もありましたが、私自身、つい「こう言えばこう伝わるはず」と前提を置いて話してしまい、言葉が足りなくなることがあります。 「伝える」ということは、自分がしっかりと理解していないと難しいものです。例えば、ユーザー目線のテストを行う際にペルソナを用意するように、知識がない状態をイメージし、その状態でどのような伝え方をすれば理解を促せるかを考えることは、自分の中で情報を整理し、かみ砕いて理解するための有効な手段だと思います。 技術やツールについての情報を取り入れることも重要ですが、こうした考え方を取り入れることで、今すぐにでも実践できることから始めていきたいと考えています。そうして技術だけでなく、言語化といった基本的な能力も鍛えていきたいと考えています。 「今」の品質 従来の品質メトリクスとアジャイル開発における品質メトリクスの違いについて、旧来のメトリクスは「開発」にフォーカスし達成した状態を評価しているのに対し、アジャイルでは「開発」と「運用」が一体となり、達成する能力そのものが品質として評価されるという点を比較して紹介されていました。 私自身はアジャイル開発に携わったことはありませんが、アジャイル開発に限らず、近年のQAの進化により、後者のアプローチが求められているように感じることがあります。それは、QAの手法が日々進化し、よりユーザ視点での「価値」を重視するようになってきているからかもしれません。 求められる品質を理解し、ユーザ視点での「価値」を開発側に伝えることが重要だと感じています。先に述べた「こうしていきたい」という考えにも関連しますが、「しっかりと分析」し、「ロジカルに言語化」することで、「品質」への理解が深まるのではないかと思います。これらのスキルを磨いて、自分のQAをより価値のあるものにしていきたいと考えています。 おわりに いくつかの点に絞ってレポートしましたが、いかがでしたでしょうか。私の感想としては、今の生成AIでは担えない「人間」としてのQAエンジニアの価値を見出していけたらいいなと強く感じた90分間でした。 基調講演では、面白く興味深いお話もあれば、つい背筋が伸びてしまうような重要なお話も盛りだくさんでした。ソフトウェア品質ダンジョンの広さを感じつつも、少しだけ覗けたという印象です。その中で、「リスキリングのタネ」も随所に見つけることができました。 鈴木様が公開されている 講演スライド は、ソフトウェア品質ダンジョンのマップを手に入れたい方にとって有益ですので、ぜひ見てみてください。私はこれからもソフトウェア品質ダンジョンに潜り、リスキリングのタネを育てていきたいと思います。 最後まで読んでいただきありがとうございました。 JaSST'24 Hokkaido ソフトウェア品質のダンジョンマッピング 2024年8月23日に開催された、JaSST’24 Hokkaido 基調講演の資料です。https://www.jasst.jp/symposium/jasst24hokkaido/details.html#S2 　詳細はこちら　 Speaker Deck 関連情報 The post JaSST’24 Hokkaido 参加レポート｜りすっきりんぐテスト(テストリスキリング) first appeared on Sqripts .

先日、 有名エンターテインメント企業が受けたサイバー攻撃 は、 さまざまな問題を引き起こす大惨事 となりました。 サービス停止だけでなく、暗号資産による身代金支払い、関連事業の情報漏洩、第三者によるデータ拡散および脅迫… 他人事ではなくなったサイバー攻撃に、私たちはどう立ち向かうべきでしょうか。 今回、そのヒントを得るために、株式会社マクニカ主催、株式会社AGEST共催で開かれたオンラインセミナー「 EDR導入成功の鍵：インシデントレスポンスと運用の最適解 」に参加しました。 セミナーレポートという形で、EDRから講じるサイバー攻撃への対抗策をお届けします。 結論：EDRは導入すべき このセミナーを通じて最も強く感じたのは、EDR（Endpoint Detection and Response）は現代のサイバーセキュリティ対策として不可欠だということです。 高度化・複雑化する現代のサイバー攻撃に対し、従来のアンチウイルス対策だけでは十分に対応できなくなっています。今や、ゼロトラスト思考、つまりすでに脅威が存在するという前提に基づいた迅速な対応が求められています。被害を最小限に抑えるためには、EDRによる高度な検知能力と迅速な対応が不可欠です。これらの理由から、EDRの導入はサイバーセキュリティ対策の要となると考えられます。 この結論に至った経緯と、EDR導入・運用の具体的な方法について、セミナーの内容に沿って詳しく見ていきましょう。 まずは、マクニカ社のセッション内容からレポートします。 サイバー攻撃の現状 まずは、サイバー攻撃が複雑化していることについて、掘り下げた内容の解説がありました。 セミナーでは、サイバー攻撃の攻撃手法の変遷を表す以下の図が示されました。 セミナー資料より 上の図は、サイバー攻撃の攻撃手法の変遷を表しています。 2010年代を皮切りに、Emotetやランサムウェアに代表されるような 金銭目的の犯行 、しかも犯罪のスペシャリストや国家単位によるものが多くなっています。 従来の個人の好奇心を主とした愉快犯的な攻撃とは異なり、昨今の組織的な攻撃は、ビジネスとして明確な目的をもって行われるため、より高度化する傾向にあります。ウイルス感染を完全に防ぐこと、あるいは、感染してしまったことに気づくことは非常に困難になってきました。 セミナー資料より 中でもランサムウェアの被害は甚大で、企業規模問わず、多くの企業がその被害に遭っているという事例が紹介されました。 2024年1〜6月に発生したランサムウェア被害事例（一部）の図が示され、データ暗号化により、1か月以上も業務に支障が発生したり、データの復号化を条件に金銭を要求されていたりするなど、会社経営そのものを脅かすものばかりだったのが印象的でした。 注目すべきは 従業員数 で、千人単位の企業もあれば、約20人ほどの企業もあります。このことからもわかるように、もはや誰もが知る有名企業ばかりが狙われる時代ではなく、あらゆる企業がサイバー攻撃の対象となっています。改めて、セキュリティに対する意識を一新しなければならないと感じました。 従来のセキュリティ対策の限界 サイバー攻撃の現状を踏まえると、従来のセキュリティ対策には明らかな限界があることが分かります。 主な課題として以下が挙げられます。 新種の脅威への対応力不足 ：既知のパターンに基づく対策だけでは、日々進化する攻撃に追いつけません。 事後対応の遅れ ：攻撃を検知してから対応するまでに時間がかかり、被害が拡大するリスクがあります。 可視性の欠如 ：侵入後の攻撃者の動きを追跡し、全容を把握することが困難です。 これらの課題に対応するため、より高度で包括的なセキュリティソリューションが求められています。そこで注目されているのが、次のセクションで詳しく説明するEDRです。 EDRとは？ ここで、EDRについて復習したいと思います。 EDR（Endpoint Detection and Response） とは、エンドポイント（PCやサーバーなど）のセキュリティを強化するための先進的なツールです。主な特徴は以下の通りです。 リアルタイム監視 ：エンドポイントの活動を常時監視し、不審な動きを即座に検知します。 高度な脅威検知 ：従来のアンチウイルスでは検出困難な新種や未知の脅威も、行動分析やAIを用いて発見します。 迅速な対応 ：脅威を検知したら、自動的に隔離やネットワーク切断などの対策を実行します。 詳細な調査 ：攻撃の全容を把握するため、詳細なログや証拠を収集・分析します。 集中管理 ：企業内のすべてのエンドポイントを一元的に管理し、セキュリティ状況を可視化します。 EDRは、従来の「防御」中心から「検知と対応」を重視する現代のセキュリティ対策の要となっています。 このような特徴を持つEDRは、現代のサイバー攻撃に対して非常に効果的だと言えます。では、EDRがどのようにしてサイバー攻撃を「見える化」し、対応を可能にするのか、セミナーでの内容を具体的に見ていきましょう。 サイバー攻撃を「見える化」するEDR 前述の通り、攻撃者の大半が愉快犯的な罪を犯していた2000年代は、「 防ぐことを前提としたセキュリティ対策 」が主流でした。 一方、犯罪のプロ集団や国家のような、より高度な攻撃を仕掛けてくる攻撃者がいる現在では、攻撃を事前に防ぎきることは難しく、 侵入した脅威に対して、より迅速に対応するセキュリティが主流 となっています。 EDRは、検知された脅威がどのような影響を及ぼしていて、どうすればよいのかを把握するために、多数のエンドポイントから集めた膨大な情報を、シンプルな情報に変換する 可視化ツール です。 そのため、起こっていることを迅速に把握し、対処までをスムーズに実行しなければならない現在のセキュリティ対策において、必要不可欠なツールだと理解が進みました。 セミナー資料より ただし、EDRだけで事業をすべての脅威から守り抜くこともやはり困難であり、依然として従来型のセキュリティ対策である アンチウイルス（AV） や 次世代型アンチウイルス（NGAV） は有効だという説明がありました。 AVやNGAVが欠けてしまうと、EDRに上がるアラートが膨大になってしまい、アラート対処をする工数が膨れ上がるそうです。 EDRで上がるアラートが多すぎて、そのアラートを無視してしまうアナリストが全体の3～4割ほどいるという調査結果も紹介され、驚きました。 一方、EDRが欠けてしまうと、万が一AV、NGAVをすり抜けてしまった際には、被害を特定するまでに相当な日数を要し、被害範囲が広範囲に及んでしまうとのこと。 侵入されてから攻撃に気づくまでに、 20日前後の時間を有した 例もあると聞き、EDRの重要性を再認識しました。 どちらか一方だけではなく、従来型（AV、NGAV） + EDRを組み合わせて活用することが、高度なセキュリティ対策としては有効だと学びました。 自社に適切なEDRを選べていないかも？ ここまでを読んで、「わが社はEDRを導入しているから問題ない」と安堵する人はどれくらいいるだろうかと考えさせられました。 セミナーでは、EDRはただ導入すればいいものではなく、要点を押さえた製品でなければ、結局は被害を最小限に抑えることは難しいと強調していました。 EDR製品を選択する際の重要な点は「 二度と感染させない、という視点に立った製品選定かどうか 」です。 もう少し詳しくセミナーの内容を見ていきましょう。 ファスト・フォレンジックを実現できるか あるセキュリティベンダーは、攻撃者が システムへ侵入してから横展開を始めるまでには約1時間24分かかる のだそうです。 言い換えると、この1時間24分の間に、侵入経路や原因、侵害が及んでいる範囲を正確に突き止め、ネットワークから隔離することができれば、被害を最小限にとどめられる可能性が高いということだと理解しました。 つまり、EDR製品の選定においては ファスト・フォレンジックを実現できるかどうか を意識しなければならないということです。 フォレンジックとは、サイバー攻撃や内部不正の際に、被害の裏付けとなるデジタル証拠を収集・解析する手法です。中でも必要最低限のデータを抽出し解析するファスト・フォレンジックは、インシデント時の適切で迅速な初動対応において重要であるとのことでした。 ファスト・フォレンジックとは： 早急な原因究明、侵入経路や不正な挙動を把握するため、必要最低限のデータを抽出及びコピーし、解析すること 。 （NPO法人デジタル・フォレンジック研究会による定義） グローバル規模の調査では、 ランサムウェアの被害に遭った企業のうちの約4割が、2度目の被害に遭っている という報告が紹介されました。フォレンジックを怠ると、調査不十分で被害の原因がわからず、2度目の被害を誘発する恐れがあるそうです。1時間24分という限られた時間の中で、被害を最小限に抑えつつ、二度と感染させない環境を作るには、ファスト・フォレンジックを実現できるEDR製品でなければならないと感じました。 ファスト・フォレンジックの重要性は、EDR選定の核心と言えるでしょう。ここまで見てきたマクニカ社のセッションの要点を、改めて整理してみましょう。 マクニカ社のセッションまとめ ここまでのマクニカ社でのセッションでは、EDR製品の必要性と、選定のポイントについて解説されていました。改めて、重要なポイントをまとめました。 サイバー攻撃は2010年代以降、より複雑化・高度化し、従来の対策では追いつかなくなった 特にランサムウェアの被害は、企業規模問わず世界中で拡がっている （すべてを防ぐことは実質不可能なため）「防ぐことを前提としたセキュリティ対策」から、EDR + 従来のアンチウイルス製品を活用した、「侵入した脅威に対して、より迅速に対応するセキュリティ対策」が主流になりつつある 適切なEDR製品を選ぶには「二度と感染させない」という視点が重要 迅速にデジタル証拠を収集・解析するファスト・フォレンジックが実現できるかどうかが、「二度と感染させない」という視点におけるキーワードになる セミナーでは、ここからAGEST社にバトンタッチ。EDRの運用の実態に迫ります。 実は多いEDRを活用できていない企業 続くAGEST社のセッションによると、あるレポートでは、 EDRを導入している企業の50％以上が「EDRを最大限に活用できていない」と答えているそうです 。 EDRはベンダーが用意したルールをもとに、攻撃と疑わしいものを検知し、製品自身がアラートを上げますが、 検知能力が高いほどアラートの数は増えるとのことでした 。 一方で、脅威かどうかの最終判断や駆除対応は、 専門的な知識を有したユーザー自身によって行わなければなりません 。 セキュリティレベルを上げれば上げるほど、より専門的な知識を持って対処する必要があるということで、EDR運用の難しさを感じました。 EDR運用は専門企業にアウトソースすべき 事例：脅威除去に至る経緯 実際にAGEST社のお客様事例で、EDRや従来型セキュリティだけで脅威を防ぎきれず、最終的にAGESTのセキュリティ専門チーム（SOC）が対応して事なきを得た事例が紹介されました。 ユーザー端末からGoogle広告経由で業務利用するためのソフトウェアをダウンロード 　↓ DLファイルを実行 ※マルウェアは暗号化された状態で正規ファイルと共にダウンロードされた。AVではダウンロードをブロックすることができず 　↓ EDRが不審なふるまいを検知、実行をブロック ※ファイルそのものは悪性と判定されなかったが、振る舞い検知によって実行をブロックすることができた 　↓ SOCチームがログ分析を実施し原因を特定 　↓ 正規ファイルに偽装されたファイルだけでなく、さらに複数の悪性ファイルがダウンロードされていたことを突き止め、全ての脅威を除去 この事例から、EDRはただ導入するだけでは不十分（今回のケースでいえば、ログ分析の知見がなければ端末内の悪性ファイルをすべて除去することはできなかった）と理解しました。 専門知識を持った人材が複数いてはじめて、（24時間365日体制の）強固なセキュリティ環境を構築できるということです。 EDR運用をアウトソースする際のチェックポイント EDR運用をアウトソースする際のポイントはいくつかあるそうですが、必ず確認しておきたい点として以下が挙げられました。 実績はあるか？ 採用したいEDRに対応しているか？ サービスでカバーされる作業領域は？ ※最重要 インシデント時の初動対応は？ 報告やコミュニケーションの方法が選べるか？ 海外にも拠点がある場合）海外拠点にも対応できるか？ なお、AGESTではフルアウトソースのEDR運用代行サービス DH-MDR を提供しているとの紹介がありました。 AGESTのEDRライセンス + 運用代行サービス EDRライセンスの取得から丸投げ運用でエンドポイントを安全に管理。AGESTのEDR運用支援サービスは累計監視台数70万台を突破！安心してお任せいただけます。 　詳細はこちら　 株式会社AGEST 関連情報 まとめ このセミナーを通じて、従来の対策では防ぎきれない高度なサイバー攻撃に対処するためには、迅速な対応が不可欠だということを学びました。エンドポイントにおける多くの情報を可視化するEDRは導入に大きなメリットがあり、また、どのように活用するかが重要であることも理解が進みました。 特に印象に残った点は2つあります。 1つ目は、迅速にデジタル証拠を収集・解析するファストフォレンジックを実現することの重要性です。 2つ目は、運用をアウトソースして最適化することの有効性です。 EDRを導入している企業も、これから検討を始める企業も、この2つを考慮しつつ、今一度セキュリティのあり方を見つめ直す必要があることを実感しました。 今回のセミナーは、サイバーセキュリティの最新動向と、EDRの重要性、そして効果的な運用方法について深く学ぶことができる、有意義な機会となりました。 The post 「EDR導入成功の鍵：インシデントレスポンスと運用の最適解」から見えたEDR活用｜セミナー参加レポート first appeared on Sqripts .

テストエンジニアが身につけておきたいスキルの一つ「論理のスキル」。 「論理の言葉」の意味や働きに注意が向くようになったら、文や文章の読み書きで実践していきましょう。 この連載では、「論理スキル“実践編”」と題して、「文章の筋道を把握する、主張を理解する」「文や文章の筋道を組み立てる」ことに役立つ 推論の形 を見ていきます。 ＜テストエンジニアのための論理スキル[実践編]　記事一覧＞ ※クリックで開きます 論理のかたち。推論とは ［全文公開中！］ 基本的な推論形式 “または”を使って推論する “ならば”を使って推論する “ならば”と“または”で推論する ソクラテスは電気羊の夢を見るか？ (前編) 今回と次回で、「三段論法」と言われると思い浮かべる人が一番多いと思われる形式の三段論法を取り上げます。 今回はこの形式の三段論法の基本的な事項の紹介です。「大前提・小前提・結論」だけでなく、押さえておきたい事柄があります。なんとなく知っていたという人も、今回で「三段論法」の理解を深めましょう。 その前に、前回クイズの解答ですね。 前回クイズ解答 問題(再掲) 問1～問3の主張が両刀論法のどの形に該当するか、また妥当な形かどうか考えてください。 解答 問1。①のふたつの仮言判断A, Bは、前件も後件も異なります。②でA, Bそれぞれの後件を否定し、③でA, Bそれぞれの前件の否定を結論としています。 複雑破壊的 両刀論法です。 問2。①のふたつの仮言判断A, Bは後件が同じです（プロジェクトが遅延する）。②でのA, Bそれぞれの前件肯定から、③A, Bの後件を結論としています。 単純構成的 両刀論法です。 問3。①の「新しいことを考える時間も減る」には、「テストに時間を割く」という前件が省略されている、つまり、前件が同じ仮言判断A, Bがあると考えられます。 ②でA, Bそれぞれの後件を否定し、③でA, Bの共通の前件を否定しています。 単純破壊的 両刀論法です。 問1～問3のいずれも、形は妥当です。（内容については……どう考えますか？） ソクラテスは電気羊の夢を見るか？ ソクラテスに申し訳ないので いつも死なせてばかりでは申し訳ないので、ちょっと毛色を変えてみました。 図6-1の主張その1～3のそれぞれで、前提(①、②)から結論(③)が言えると思いますか？（内容の真偽ではなく、主張の形として） 図6-1 ソクラテスは電気羊の夢を見るか？ 概念と概念の関係を推論する 「ソクラテスと電気羊」の特徴 「 “または”を使って推論する 」、 「 “ならば”を使って推論する 」、 「 “ならば”と“または”で推論する 」 の各回で見てきた三段論法は、文と文をつなぐ 論理の言葉 の意味と働きで結論を導き出していました。 「ソクラテスと電気羊」にはそのような論理の言葉は使われておらず、断定的な文が並んでいるだけです。 定言三段論法 このような、すべての文が断言形式の文で構成される形の三段論法を、 定言三段論法 や断言三段論法といいます。 各文は 主語 と 述語 というふたつの言葉(概念)からなります。図6-1の例では、「ソクラテス」「哲学者」「電気羊の夢を見る」が主語や述語に当たります。 定言三段論法はこれらの文に現れる「 言葉(概念)どうしの関係性 」を論じるもので、前提に出てくる 主語と述語の関係（包含関係の成否） から結論を導き出します。 定言三段論法の構造 三つの概念：S, P, M 主語や述語は何かしらの概念を表す言葉で、S, P, Mの三種類が登場します。 小名辞(S) (小概念)： 結論の主語 になる言葉(概念)です。 小名辞Sが現れる前提を小前提 と呼びます。 大名辞(P) (大概念)： 結論の述語 になる言葉(概念)です。 大名辞Pが現れる前提を大前提 と呼びます。 媒介項(M) (中名辞、媒概念)： 大前提、小前提の両方に現れ 、SとPの間を取り持つ言葉(概念)です。 図6-1の例・その1では、「ソクラテス」が小名辞S、「電気羊の夢を見る」が大名辞P、「哲学者」が媒介項Mとなります(図6-2)。 図6-2 小名辞S, 大名辞P, 媒介項M 結論は常に「小名辞Sが主語、大名辞Pが述語」ですが、大前提、小前提では、S, P, Mが主語・述語のどちらになるかは主張内容によって変わります。 なお、小名辞・大名辞の区別は、それらが指す概念の大きさと一致するとは限りません。 文の並び：大前提→小前提→結論　とは限らない 慣習的には大前提・小前提・結論と並びますが、これは決まりではなく、三つの文はさまざまな並びがあり得ます（3つの文を並べる順列ですから、6通り）。「結論を最初に述べて、その理由や根拠として大前提・小前提を述べる」といった並びはよく見かけます。 文の種類：AEIO 大前提、小前提、結論の各文には、主語と述語に関して 修飾 がかかります(図6-3)。 主語の概念が適用される範囲（判断の「 量 」といいます）。 その範囲によって 全称 と 特称 に分かれます。 全称判断：主語の概念が当てはまる全体について述べる文。例：「 すべての SはPである」 特称判断：主語の概念が当てはまるうちの一部について述べる文。例：「 ある SはPである」 ※固有名詞は全称として扱います。 述語にかかる判断の性質（判断の「 質 」といいます）。 肯定 と 否定 があります。 肯定判断：述語が当てはまると主張する文。例：「すべてのSはP である 」 否定判断：述語が当てはまらないと主張する文。例：「すべてのSはP でない 」 図6-3 全称/特称と、肯定/否定 全称/特称と肯定/否定の組合せで、A, E, I, O, 4つの種類の文があります(図6-4)。表中の丸括弧内は、同じことを言い換えた形です。 全称否定(E)に注意してください。文全体を否定する（「すべてのSがPである、というわけではない」）のではなく、述語だけを否定した「 Sであるものはすべて、Pではない 」という意味になります。 図6-4 文の種類：AEIO AEIOそれぞれにおける、主語と述語の包含関係は図6-5のようになります（Sが主語、Pが述語）。 (あるかも)は、その文では言及していない部分です（該当する要素があるかも知れない）。 図6-5 AEIOそれぞれの、SとPの関係 主語と述語の状態：周延 文の主語と述語は、 その概念が当てはまるすべての対象について言われている か、そうでないか、ふたつの状態を持ちます。 前者の状態を、その主語や述語が 周延されている といい、後者を 周延されていない(不周延) といいます。 前提から「なるほど、ソクラテスは電気羊の夢を見るね」と判断できるとしたら、「ソクラテス」という概念と「電気羊の夢を見る」という概念が結びつかなければなりません。周延という状態はその鍵になります。 周延/不周延は、全称/特称、肯定/否定に応じて決まります(図6-5, 図6-6)。 主語について。 全称判断では、主語は周延 されます（「Sという概念が当てはまるすべて」だから）。 特称判断では、主語は周延されません （Sのすべてについては言っていない）。 述語について。 肯定判断では、述語は周延されません （SでないPがあるかも知れない）。 否定判断では、述語は周延 されます（「Pでない」と断言できるのは、Pという概念が当てはまるすべてについて言えるから）。 図6-6 文の種類(AEIO)と周延/不周延 定言三段論法の形 （本章は読み飛ばしても問題ありません） 定言三段論法の形：格(figure) 三つの文を大前提・小前提・結論の順に並べた時、S, P, Mが主語/述語のどちらになるかで概念の並び方(配列)が決まります（結論は必ず「Sが主語、Pが述語」で決まっている）。 これを「 格(figure) 」といい、第1格から第4格まで四つの格があります(図6-7)。 図6-7 定言三段論法の4つの格 M-Pが「哲学者は電気羊の夢を見る」だとすると、P-Mは「電気羊の夢を見る者は哲学者である」という文になります。Sがソクラテス、Mが哲学者なら、M-Sは「哲学者はソクラテスである」という文を表します。 定言三段論法の形：式(mood) 大前提・小前提・結論がそれぞれAEIOのどれになるかという観点から見た定言三段論法の形を「 式(mood) 」といいます。たとえば、 「大前提がA、小前提がA、結論がA」なら、AAAという式 「大前提がE、小前提がI、結論がO」なら、EIOという式 といった具合です。 格ごとに妥当な式がある というわけで、定言三段論法の形は、「格は第1格で、式はAAA」とか、「第2格のEAE」「第3格のIAI」といったように、格と式で表すことができます。 大前提・小前提・結論の3つの文がそれぞれ4種類(AEIO)あり得ますから、格ひとつ当たりの式は 4 × 4 × 4 = 64 通りあることになります （格は4つあるので組合せ総数は 64 × 4 = 256 通り）。 が、これはあくまで機械的な組合せで、 そもそも、矛盾を生じたり結論が得られないなどの非妥当な式がある さらに、格(図6-7)ごとに、取れる式に制約がある そうした無効な式を取り除くと、格ごとに妥当な式の数はかなり減ります（格ひとつ当たり、6通り）。また、格ごとに妥当な式は異なります。 「よい形」を見分けるために とはいえ、「格」や「式」の知識はともかく、格ごとの妥当な式を憶えるのは、意義はありますが、やみくもに暗記するのもツラいものがあります。 式の妥当/非妥当に関係するのは 文の種類(AEIO)と、主語・述語の周延/不周延 です。ここに着目して、 定言三段論法がよい形であるための規則 （とできればその理由）を理解することを心がけるのがよいでしょう。 クイズ 下図(図6-1と同じです)の「ソクラテスと電気羊」その1～3について、今回の説明を基に考えてみてください。（解答は次回に） 小名辞S、大名辞P、媒介項Mに当たるのは何か 各文は全称/特称、肯定/否定どれに当たるか 次回 次回は定言三段論法がよい形であるための規則（それは具体的な主張が「よい形」かどうか見分けるためのヒントでもあります）を取り上げます。 参考文献 近藤洋逸, 好並英司 『論理学入門』 岩波書店 1979 藤野登 『論理学　伝統的形式論理学』 内田老鶴圃 1968 鈴木美佐子 『論理的思考の技法Ⅱ』 法学書院 2008 図版に使用した画像の出典 Loose Drawing 人物とベッドの絵をお借りしています。 テストエンジニアのための論理スキル[実践編]  連載一覧 論理のかたち。推論とは  【連載初回、全文公開中】 基本的な推論形式 “または”を使って推論する “ならば”を使って推論する “ならば”と“または”で推論する ソクラテスは電気羊の夢を見るか？ (前編) The post ソクラテスは電気羊の夢を見るか？ (前編)｜テストエンジニアのための論理スキル［実践編］ first appeared on Sqripts .

こんにちは、QAコンサルタントのODCオジサンです。今日は抽象と具体という、ちょっと変わった話をしたいと思います。 このテーマを選んだ理由 仕事中に提案書・報告書・会議の議事録などのたくさんの書類を眺めていると、これを書いた人はどうしてここまで細かく書いているんだろう？とか、ここもうちょっと詳しく知りたいんだけど丸められちゃってるな、と読み手としての期待とずれてしまっていることが多いと感じます。また、プレゼンテーションや発表の場でもしかりです。細かい説明にムダな時間を割いてしまって、肝心の本題に入れずに会議時間をオーバーしてしまうことってないでしょうか？ このブログでは「抽象」と「具体」という概念をもう一度見直して、「抽象」と「具体」を自由に行ったり来たりできるとこんないいことがあるよ、というのをお伝えしたいと思います。単に日常生活だけでなく、ビジネス全般やソフトウェアテストにも使えるよ、といった応用までいけるといいかなと考えています。前半は『具体⇔抽象トレーニング思考力が飛躍的にアップする29問』（細谷功）（以下、細谷本）の内容をベースに、「失敗学」や不具合分析の例を加えてまとめていきます。 抽象と具体とは 抽象と具体とは、二つの対立概念です 『具体⇔抽象トレーニング思考力が飛躍的にアップする29問』（細谷功） それぞれ辞書を引くと、 抽象：事物または表象からある要素・性質をぬきだして把握すること 具体：物事が、直接に知覚され認識しうる形や内容を備えていること 大辞泉 となっています。具体はまぁそうかなという感じですが、抽象は定義自体が難しいですね。 日常生活で抽象と具体という言葉が使われる状況を考えてみましょう。何かを説明するときに「具体的にどういうことですか？」とか「もう少し具体的に話してもらえますか？」ということってないでしょうか。「具体」にはわかりやすいイメージがあります。その一方で、「抽象」にはなんだかわかりにくい、難しいもののようなイメージがあります。「あの人の話は抽象的でわからない」のような場合です。 抽象と具体の特徴を表すと次のようにまとめることができます。 抽象 具体 直接目に見えない 実体と一見乖離している 分類してまとめて対応できる 解釈の自由度が高い 応用が利く 学者の世界 直接目に見える 実体と直結 一つ一つ個別対応 解釈の自由度が低い 応用が利かない 実務家の世界 ※「細谷本」より引用 なぜ抽象と具体が重要なのか？ 抽象と具体がなぜ重要かについては「細谷本」から引用します。 社内勉強会などのイベントを何か開催するところを想像してください。イベント後に上司から次のような指示を受けたことはないでしょうか？ パターン1 A「本は本棚に返して、お皿は食器棚に戻して、椅子と机は倉庫に返して….」 B「要は片付けろってことですよね？」 パターン2 A「この部屋のものを片付けて」 B「えっ、抽象的で何を言っているかわかりません。もっと具体的に言ってください。本やお皿はどの棚に返す、とか、総務部の誰に連絡すればよいのかとか…」 『具体⇔抽象トレーニング思考力が飛躍的にアップする29問』（細谷功） パターン1でAさんは「具体病」のように見えます。 すべて具体的事例がないと理解も実行もできない 言われたことをそのまま実行することしかできず、一切の応用が利かない 一度ルールや線引きが行われるとそれを絶対的なものと信じて疑わず、環境の変化に適応できない 『具体⇔抽象トレーニング思考力が飛躍的にアップする29問』（細谷功） 会社の同僚や上司がみなAさんのようになってしまった場合を想像してみてください。 一方でパターン2でAさんは「抽象病」のように見えます。 いかにも賢そうに見える。べき論を語るのが好き 他人の行動・失敗に対して理想論でアドバイスするだけで実際にアクションすることがない ベストを尽くす、徹底的に強化します、など目標や施策がすべてあいまい 『具体⇔抽象トレーニング思考力が飛躍的にアップする29問』（細谷功） こちらはこちらで問題です。必要な問いかけをしても何も返してくれないので、それこそ途方に暮れるしかなくなります。一方で、何かを言うとまとめてくれそうなので、抽象化のレベルさえ合っていれば仕事が早く進みそうです。 これらの「抽象病」「具体病」ですが、いずれもどちらかに偏ってしまっているのが問題なので、うまく行き来できるようになるのが重要ということになります。 ではなぜ抽象と具体が重要なのでしょうか？ 人間は新しい知識を獲得するごとに、それを個別の事象として記憶するか、他に応用できないか考えるクセがついています。例えば木に落ちる雷に一度でも遭遇したことのある人は、これはたまたま偶然だったのだと考えて、それ以上の分析をやめてしまう人が一定数います。一方で、雷はどういった場所に落ちやすいかを調べて、木の下を避けるとか避雷針を立てて雷を回避する策を考える人がいます。これが目の前の「木に落ちる雷」といった具体的な事象から、「雷の性質」という抽象概念に登れる人と登れない人の差になってきます。 具体から一度抽象に移り、再び具体に戻ることによって、人間は知の拡大を続けてきました。これを表すのが『知のピラミッド』（細谷本）です。 知のピラミッド『具体⇔抽象トレーニング思考力が飛躍的にアップする29問』（細谷功） この『知のピラミッド』の具体例については「応用例」の方で述べますが、これを使って知識を拡大できないと、様々な知識を例え獲得できたとしても、単なるバラバラな事象になってしまい、膨大な具体的な知識の塊となって、人間の頭の中に入らないで捨てられてしまいます。抽象化と具体化を繰り返すことで、バラバラな事象から一定の法則や理論の形で知識を蓄えることができ、他の場面に活かすことができます。 これはあらゆる仕事にも当てはまります。抽象病や具体病に陥ることなく、抽象と具体を行ったり来たりできる人こそ、具体から抽象を吸い上げて、それを知識として蓄えることで活用できるので、真の仕事力を持っていると言えます。 では「抽象化」「具体化」について見ていきましょう。 抽象化 抽象化で一番大事なことは「目的のために必要な情報以外を取り除く」ことです。例えばリンゴで例えると、自分が仮にリンゴを販売したい農家だとして、売り上げを上げるために必要な情報はリンゴの「個数」「重さ」「糖度」などであって、その他の情報、例えば「販売経路」「梱包方法」などは実際に購入するときには必要かもしれませんが、「売る」という目的には直接は関係ないので取り除きます。こうして重要な情報だけを抜き出して構造化したものが「モデル」となります。 先ほどの片付けの例でいくと、「本棚に返す」「食器棚にしまう」「倉庫に返す」の共通点を見つけていきます。そうすると、何かを本来それが合った場所に戻すらしいぞ、となって「片付け」という上位概念がでてきます。 図：is-a関係 これはAならばBの関係になっているので（本棚に返す→片付け、食器棚にしまう→片付け、倉庫に返す→片付け）、is-a関係と呼ばれます。 こうした「一言で述べる」以外に抽象化で使えるテクニックを細谷本から抜粋します。 自由度を上げる：一部を変数にしてみる（「タンメン」を食べる→「ラーメン」を食べる） Whyを問う：因果関係を考える 全体を俯瞰する ：隣との関係性でなく一歩上の視点に立つ 『具体⇔抽象トレーニング思考力が飛躍的にアップする29問』（細谷功） ※筆者加筆 具体化 具体ばかり述べる人は必要ないような話をしてしまいましたが、実は抽象化した後に具体化しないと、何も実行できなくなりますので、実は具体化も重要です。抽象化も具体化もバランスが取れていることが大事です。 先ほどの例だと「片付けろ」だけでは具体的に何をどこに移動させるかが示されていないので、その場にいる人に聞いて動かすものを指定してもらいます。あるいは手順書に何か書かれているかもしれません。 具体化のテクニックを細谷本から抜粋します。 自由度を下げる：変数に具体値を当てはめる（例：「ラーメン」を食べる→「タンメン」を食べる） Howを問う：実現手段を考える 数字と固有名詞にする ：ダイエットしなさい→「オートミール」を朝に100グラム食べなさい 『具体⇔抽象トレーニング思考力が飛躍的にアップする29問』（細谷功） ※筆者加筆 モデリングの世界ではhas-aという関係を使うと具体化できます。例えば「車」はさまざまな部品でできていますが、「車」という製品を作るには個々の部品を考えて設計製造する必要があります。 図：has-a関係 プロジェクト管理の世界では「WBS(Work Breakdown Structure)」というものがありますが、あれもhas-aの関係で成り立っています。「要件定義」には「顧客要求の引き出し」「要件定義書作成」「要件レビュー」などが含まれる、のように大きなプロセスを個々のアクティビティやタスクに分解していきます。これも具体化の事例です。 抽象と具体の応用例① 抽象と具体を行ったり来たりできるようになるとこんなことができるようになるという事例です。『失敗学 実践編: 今までの原因分析と対策は間違っていた!』（濱口 哲也、 平山 貴之）（以下、濱口本）より引用します。 とある病院で、看護師が入院患者AさんとBさんを食堂に連れて行き、食前薬を渡すときにAさんにBさん用の薬を渡してしまった。そうなるとBさんの薬が見当たらないので薬局に探しに行っている間にAさんがBさんの薬を服用する直前で防止できた。 『失敗学 実践編: 今までの原因分析と対策は間違っていた!』 （濱口 哲也、 平山 貴之） という事例です。未然防止はできていますが、一つ間違えると人命に関わるヒヤリハットです。 この事象の再発防止策として、抽象化を行わないと「名前と薬の確認を徹底する」や「本人を示すタグと名前を照合することを徹底する」というのを思いついてしまいます。そうするとこの病院の特定の病室や、似たようなシチュエーションでしか使えない単なるチェックリストになってしまいます。 これを1段階抽象度を上げると、格段に応用の利くものになります。 AさんとBさんの区別が付かなくなったことと、それぞれの薬の区別が付かなくなったことの両方の事象を一歩上から見ると『本体とラベルを分離すると識別不可能』（濱口本）となります。つまり、Aさん本人と、ラベルを示すもの（名前を聞く、タグを確認する）を切り離してしまうと、区別がつかなくなるのでかならずセットにした状態を保ちましょう、ということになります。 これは応用範囲が広いです。例えば、最近の病院では患者を間違えないために患者の足にタグのようなものを付けると思いますが、それはここから来ています。また、人工授精後の受精卵は、シャーレの蓋に名前を書くだけでは蓋を取った途端に区別が付かなくなってしまうので、シャーレの中身（培地）の方に名前を書く（または識別可能なものを置く）、となります。 抽象と具体の応用例② ソフトウェアテストの現場から、テストで検出した不具合を分析する例を見てみましょう。 車載オーディオ製品で、その製品の仕様上聞けてはいけないはずの特定地域の放送局（A局）が聞けるようになっていました、という不具合がありました。聞けたわけですから、製品品質としては悪くないわけです。テストベースとした仕様書がA局は聞けることになっていたため、それを使って設計したテストでは合格となっていました。ところがマーケティングが後から横やりを入れてきて、結果的に欠陥という扱いになりました。 この例を抽象化してみましょう。「ビジネス要件をきちんと分析していなかった」→「ビジネス要求が最優先」→「より優先度の高い要求に上書きされる」。 これを他の例に当てはめてみましょう。昨今ソフトウェア開発は新規より派生開発が増えています。新規機能や改変対象の機能については、要件定義・設計・コーディングまでしっかりとトレーサビリティを確保しながら開発を進めることが多く、またそういったトレーサビリティを確保するための方法論がいくつかあります。ところが新規機能や改変機能に気を取られて、隠れた要求の変化に気がつかないケースがまれにあります。そうした変化した要求が残っていないか、あるいは時間の経過とともに新しい要求が発生していないかをレビュー観点として残し、設計レビューで活用することは未然防止として意味があります。「より優先度の高い要求に上書きされる」という抽象化された法則を、ソフトウェア欠陥を防止する目的で使う例として挙げさせていただきました。 まとめ 抽象と具体について、事例を交えて説明してきました。具体的な事象を我々は普段目にしているわけですが、そこから抽象化して本質を見極めるにはある程度訓練が必要です。身近なものに対しても、これは一体どういうことだろう、というように一歩上の視点から眺める訓練をしておくと、仕事にも役立ちますので一度試してみてはいかがでしょうか？ 出典 『具体⇔抽象トレーニング思考力が飛躍的にアップする29問』（細谷功） ISBN-13 ‏ : ‎ 978-4569845999 『失敗学 実践編: 今までの原因分析と対策は間違っていた!』（濱口 哲也、 平山 貴之） ISBN-13 ‏ : ‎ 978-4817195999 『大辞泉』（小学館） ISBN-13：978-4095012131 The post 抽象と具体 ～真の仕事力のための抽象化と具体化のテクニック～ first appeared on Sqripts .

この連載では、ITエンジニアにとって親和性が高く「スキルアップしたい」と思う方にとっては役に立つであろう知的生活について、いろいろなアクティビティやツール、仕事での活用方法などについてご紹介します。知的生産・知的生活の考え方や、「そもそも知的生活とはどうあるべきか」等の話ではなく、できるだけエンジニアの普段の生活や仕事に役立てられるテクニックよりの話をするつもりです。 今回は、蓄積した情報をどのように組み合わせ、実際のアウトプットにしていくかについて解説します。とくに文章としてアウトプットする場合を前提に話を進めますが、プレゼンテーションなど他の形式のアウトプットであっても通じる部分があると考えています。 ＜ITエンジニアの仕事を楽しくする知的生活　記事一覧＞ ※クリックで開きます 【第1回】知的生活とはなにか？エンジニアにどう関係するのか ［全文公開中！］ 【第2回】知的生活の母艦としてのツールを選び、活用する 【第3回】技術書以外の本を読み、仕事に活かすには 【第4回】デイリーページを用いて日々の作業を記録する これまでのおさらい 今回は連載の最後なので、まずはここまでの流れについて簡単にふりかえります。 最初は”知的生産”とは何かからはじめ、主に知的生活の母艦に情報を蓄積することを説明してきました。情報を蓄積する具体的な例として、読書と、仕事中のメモについて取り上げました。 本連載の第一回では、以下のように書きました。 いきなり「アウトプットしましょう」と言われても難しいという方も多いと思います。今後の連載の中では、小さいアウトプットから大きなアウトプットにつなげていく流れについても解説します。 今回扱うのはまさにこの部分です。たとえば「会社のテックブログを書かなければいけないが、なかなか進まない」といった悩みはいろいろなところで耳にします。ここでの問題は、何もないところからアウトプットを生み出そうとしていることでした。テストベースからいきなりテストケースを導出するのが良くないように、頭の中からいきなり文章としてのアウトプットを出すのは大変です。 これまでの内容を実践していただくことで、さまざまな情報が手元にある状態になっているはずです。ここから、最終的なアウトプットを作るまでの流れに沿ってご説明します。 アウトプットをつくるまで 大まかな流れは以下になります。 テーマを設定する 材料を集める 構成する 形にする それぞれ詳しくみていきましょう。 1. テーマを設定する なんらかのアウトプットをする際、テーマは与えられることもありますし、自分で考えることもあるでしょう。 （たとえばこのSqriptsでの連載は私自身がテーマを考えている、「好きに書かせてもらっている」状態です）。 ここでは、自分でテーマを考えるところから説明します。もしテーマがすでに与えられている、決まっているという場合は次の材料集めからのスタートです。 テーマを自分で考える場合であっても、完全になんでも良いということは少ないはずです。技術に関すること、品質に関すること、マネジメントに関することなどなんらかの方向性はあるでしょう。まずはこれをたよりにして、具体的なテーマを考えていきます。 アウトプットというものは、基本的には「受け手にとってメリットがあること」だと考えています。SNSで「腹減った」とつぶやいていても、それは一般にアウトプットとは思われないですよね。そうではなく、たとえば困っていることを解決するヒントを与えたり、これまで受け手が知らなかった情報を得られたり、といったメリットを提供する必要があります。誰に対してどのようなメリットを提供するのかをおおまかにでも良いので考えて、それをテーマに設定しましょう。 今回はとくに「仕事を通じて得た知見」をアウトプットしようという内容なので、自分が過去知らなかった・できなかったことや自分が解決した課題をテーマに据えると考えやすいです。このとき、前回までにご紹介した日々の記録が効いてきます。自分自身が成長すると、仕事上のいろいろなことが「当たり前」になります。この「当たり前」は、他者にとっては有益なノウハウであることも多いのですが、なかなか自分自身では気づけません。そこで過去の記録やメモを見返すことによって、自分が当時できなかったこと・わからなかったことを 通じて「当たり前の再発見」ができます。自分にとっての当たり前を探してテーマに設定すること、これも1つの方法として試してみてください。 2. 材料を集める テーマが決まったら、関連する材料を集めます。これは 【第3回】技術書以外の本を読み、仕事に活かすには でも少し登場しましたが、まずは知的生活の母艦に対してキーワード検索をかけるのがよいでしょう。情報が蓄積されていれば、関連するものがいくつか出てきます。 しかし、ここでヒットするのはあくまでもアウトプットのための「ネタ」であり、多くの場合は追加で情報を集めることになるでしょう。たとえばWeb記事をメモしておいた場合は、その記事が参照している他の記事や書籍を見に行くこともあるかもしれません。あるいは、意味が正確に理解できていない単語があり、あらためて調べることもあるでしょう。これら追加での情報収集の過程が、よく言われる「アウトプットをすると勉強になる」ことにつながっています。アウトプットを前提としたインプットを行うことでより学びが深まるという副次効果も得られます。 【第3回】技術書以外の本を読み、仕事に活かすには この連載では、ITエンジニアにとって親和性が高く「スキルアップしたい」と思う方にとっては役に立つであろう知的生活について、いろいろなアクティビティやツール、仕事での活用方法などについてご紹介します。知的生産・知的生活の考え方や、「そもそも知的生活と... 　続きを読む　 Sqripts 関連記事｜Sqripts 3. 構成する 材料が集まったら、最終的なアウトプットの骨組みを決めていく構成段階に入ります。 【第2回】知的生活の母艦としてのツールを選び、活用する でもご紹介した、 Dynalist などのアウトライナーを使うのが私のオススメです。 【第2回】知的生活の母艦としてのツールを選び、活用する この連載では、ITエンジニアにとって親和性が高く「スキルアップしたい」と思う方にとっては役に立つであろう知的生活について、いろいろなアクティビティやツール、仕事での活用方法などについてご紹介します。知的生産・知的生活の考え方や、「そもそも知的生活と... 　続きを読む　 Sqripts 関連記事｜Sqripts このような形で、材料・メモをアウトライナーに書き出したあとで、構成も同じページに書いていきます。見出しと内容を階層化したり、階層ごとの並び替えなども容易です。このようなツールで文章の全体構造を検討してある程度決めたあとで、実際の文章として書き起こすことが大切です。 4. 形にする 前項で決めた構成にそって文章を書いていきます。ここまでのステップを経ていれば、いきなり真っ白なエディターに文章を書き始めるのに比べてだいぶ進みやすいはずです。 しかし、実際に文章を書き始めてから「やはり構成がしっくりこない」「違う内容を書きたくなった」といったことも起こり得ます。これは構成の検討が不十分だったわけではなく、よくあることです。文章を形にしつつ、構成を変更したくなった場合はアウトライナー側でも編集するなど、行き来をしながら完成に向かいましょう。 知的生活でITエンジニアの仕事を楽しく 本連載で繰り返し書いていますが、知的生活とは「なにかあたらしい情報や価値」であるアウトプットを出すため、日常的にいろいろな情報をあつめて処理・思考すること、でした。 アウトプット、とくに業務上求められている成果物以外のものを出していくことで、 知的生産の過程における深い学び アウトプットに対するフィードバック が得られます。 この2点に、連載タイトルにもある「ITエンジニアの仕事を楽しくする」という要素が詰まっています。成長というと大げさな表現ですが、知らなかったことを知ること、出来なかったことができるようになることは誰しも楽しさを感じるポイントです。また、自分がアウトプットしたことに対してフィードバックがあることもまた、楽しさや励みにつながるでしょう。 知的生活だけでは、仕事上の大きな困りごとや不満をすぐに解決、とはいかないかもしれません。しかし、なんとなく閉塞感・停滞感がある、身が入らないといったモヤモヤに対しては効果があると信じています。 とくにITエンジニアをしていて、普段の仕事やキャリアに悩むタイミングが来ている方や、少し上の先輩が悩んでいそう＝もうすぐ自分にもやってきそうという方にはぜひ、本連載でご紹介した知的生活を取り入れてみていただきたいです。 ITエンジニアの仕事を楽しくする知的生活　連載一覧 【第1回】知的生活とはなにか？エンジニアにどう関係するのか ［全文公開中！］ 【第2回】知的生活の母艦としてのツールを選び、活用する 【第3回】技術書以外の本を読み、仕事に活かすには 【第4回】デイリーページを用いて日々の作業を記録する The post 【第5回】仕事を通じて得た知見を文章でアウトプットする first appeared on Sqripts .

こんにちは！テストエンジニアの藤江です。普段はテスト実施管理者として、顧客の課題やお困りごとに最前線で対応しています。 今回は先日開催したウェビナー「 開発者を困らせるバグ起票をなくすテスト管理のコツ （オンデマンド配信中）」についての振り返りと、発表を行うことの意義についてお話しします。発表の経験を共有し、皆さんにとって有益な情報をお届けできればと思います。 あの不具合報告、どういう意味？-開発者を困らせるバグ起票をなくすテスト管理のコツ- | 株式会社AGEST... 「あの不具合報告、どういう意味？」PM・開発者の皆さんであれば一度は発した事があるのではないでしょうか？自社のテストチームや外部のテストベンダー、または開発チーム内で不具合報告として上がってきた起票内容がわかりづらいために無駄なコミュニケー 　詳細はこちら　 株式会社AGEST（アジェスト） 関連情報 1. ウェビナーでの発表内容の概要紹介 ウェビナーでの発表内容を軽くおさらいします。主に不具合管理について3つのポイントをお話しました。 欠陥レポート報告のポイント 欠陥レポートには内容を見て、何が問題なのかを理解し、問題を解決することができる情報が記載されている必要があります。具体的な内容として一意な識別子、簡潔なタイトル、観測日、環境特定情報、再現手順、期待結果と実際の結果などが必要です。この中で特にポイントとなるのは以下となります。 条件(端末や権限等)、最後の手順、期待結果、実際の現象で簡潔なタイトルを記載 再現手順は初期状態から記載し、入力値も指定する 期待結果には、期待の根拠となる資料も添付する 不具合管理者としての改善策と効果 不具合管理者として、不具合報告をどのように整理すると効率が上がったかという話をしました。改善のポイントとしては以下となります。 文言の揺れを無くし、後から類似不具合の追いかけや内容検索ができるようにする 複数メンバーが並列で動作確認を行った際に、仕様変更の通知漏れや同根の不具合に起因する不具合報告の重複が発生していないかをモニタリングする 仕様理解を進めて仕様確認のリードタイムを減らして、実施効率を上げる 不具合管理のよくある失敗事例 不具合が再現できない、優先順位が不明、対応内容が不明確など、よくある失敗事例についても共有しました。こちらについても下記の観点での問題解決を提案しました。 再現が難しい報告には文章以外の手段として動画や画像等の共有を行う。再現確認の範囲を広げてみる 不具合対応者のタスク過多などによって、対応の優先順位が不明な状態になっていたら、現状把握と優先度の見直しを行い、現実的な対応スケジュールを提案する 最初に取り決めたルールが守られていない場合、ルールの見直しと周知を行う 2. ウェビナーを振り返って アンケート結果について ウェビナー終了後に行ったアンケートの結果、以下のようなフィードバックをいただきました。 非常に参考になった：8件 参考になった：28件 どちらともいえない：5件 参考にならなかった：1件 また、26件の回答としてセミナー開催の案内が欲しいとの声もあり、概ね好評をいただいております。 やってみた感想 オンサイトでの講演と違って、視聴者の表情が分からないためオンサイトよりキツイと事前に聞いていましたが、実際に行ってみると自宅のリモート環境での講演だったこともあり30分独り言を喋っているような感覚になりました。特に講演する側に立つと、改めて以下が大事だと感じます。 前列でリアクションを取って頷いたりする人の存在 事前準備として、作成した資料の読み上げと講演時間の確認 口頭で補足する内容の整理や情報の根拠の再確認 これらを通して発表内容に関する理解や解像度は発表の相談を受ける前と比べるとかなり上がったと感じます。とはいえ、事前準備をどれだけ行っても不安で緊張してしまうものなので、とにかく発表の機会があれば受けてみるという姿勢が大切だと感じました。初めての発表を終えると、次はもっと長い発表にも挑戦しようという気持ちが湧いてきます。次の目標は90分間くらいの長い時間でJaSSTの講演など出来るようになることです。 次にやってみたい工夫 今回は一方通行の話し方になってしまい、独り言の感覚だったので、次回は対談形式や参加型のディスカッション形式で進めたいと思います。立場や所属の違うメンバーを交えての対談だったり、何かのテーマを決めてのフリートークに近い形でより印象に残りやすい講演が出来れば良いなと考えています。また、不具合の動画を出して、それを文字でどう伝えるかをライブ形式で書いていく、チャット欄を使って視聴者にも概要を記載してもらって内容を評価するなど、インタラクティブな要素も取り入れて双方向の講演となるようにして、出来るだけ反応が見える講演にしたいです。 3. 発表や勉強会等に参加することの意義について セミナーやカンファレンス等のイベントに参加することで様々な気づきがあります。主に私が考えるメリットとしては以下となります。 発表することの主なメリット 発表の振り返りを行うことで、発表で得られる体験を再認識し、上記の工夫の検討といった具体的な目標や次のためのモチベーションに繋がります。 発表を通じて、自分の知識や経験を再確認し、自信とモチベーションを高めることができます。 発表の準備の過程で、内容を整理することでより深く理解することができます。 参加者からの質問やフィードバックを通じて、新しい視点やアイデアを得ることができます。 参加することの主なメリット 専門分野の講演やワークショップに参加することで、日常業務とは違った視点での考え方や知識を習得できます。 他の参加者や講演者との交流を通じて、新しい人脈を作ることができます。 同じ分野に興味を持つ人や同じ悩みを持つ人と交流し、様々なフィードバックを受けることで理解を深めることができます。 色々な提案を行う際に、●●社さんはこんな形で導入した事例があります。といった形で具体的な前例を示すことができます。 4. セミナー参加者や読者の皆様へのステップアップの提案 一度行ってノウハウを学んで終わりというわけではなく、学んだことの継続的な実践と確認が大事となります。例えるならセミナーや勉強会というのは効率的な筋トレ方法を聞いた状態で、実際に使える知識となるのは継続して学んだことを実践した後となります。そのため色々な勉強会やイベントに参加してみて、興味があったら実践してみることが重要です。 参加をお勧めするイベント 例えば、以下のようなイベントや配信があります。 ASTERのyotube配信 ：JaSST Kyushuの 過去の講演 やセッションが視聴できます。 ASTERのセミナー ：定期的に開催されるセミナーで最新の知見を学べます。 LTや対談等の軽量なイベント ： JaSST nano や Connpass などのプラットフォームで開催されるライトなイベントに参加するのもお勧めです。 セミナーやシンポジウム、カンファレンスなど ： JaSST や テスト設計コンテスト など、上記である程度の雰囲気が掴めたら是非大規模なイベントにも参加してみてください。 TestingCommunityJPのSlackチャンネル ：業界の最新情報や知見を共有するコミュニティに参加することも有益です。 最後に 登壇等のアウトプットをすることによって知識が増え、理解が深まります。発表や外部との関わりを通じて、他の人のアウトプットを吸収する機会も増えるのでさらに自分の知識を広げることができます。業務知識として得た価値観を俯瞰してみることができるようになるのもインプット、アウトプットの大きなメリットとなります。 私は今回のウェビナーを通じて多くの方に不具合管理の重要性とその実践方法について紹介し、様々なフィードバックを受けることができました。こちらを元に引き続きよりよい不具合管理を目指していきます。 アウトプットやインプットを増やすことで新しい発見や成長の機会が得られることは間違いありません。読者の皆さんの中からこのブログをきっかけに勉強会への参加や登壇を考える方が出てくれると嬉しいです。 関連記事 インプット、アウトプットに興味をお持ちの方には、Sqripter伊藤由貴さんによるこちらの特集もおすすめです！ 【第1回】知的生活とはなにか？エンジニアにどう関係するのか みなさんは、知的生産や知的生活ということばを聞いたことはありますか？初めて聞いた、という方はもしかしたら「堅そう」とか「えらそう」といった印象を持つかもしれません。ところが、私はこの知的生産・知的生活は「ITエンジニア皆に知っておいてほしい」と考え... 　続きを読む　 Sqripts 関連記事｜Sqripts The post ウェビナー登壇の振り返りと参加の意義について first appeared on Sqripts .

ソフトウェア開発の世界では、アジャイル開発やスクラムが一般的になってきました。そのアジャイル開発のコアとも言えるのが、対話や協調です。この連載では、アジャイル開発におけるコミュニケーション・コラボレーションスキルを解説しながら、ファシリテーションスキルのレベルアップを目指します。 今回のテーマは「上級者の質問力」です。 ＜スクラムマスターのためのコミュニケーション講座　連載一覧＞ ※クリックで開きます ・ #イントロダクション：優れたスクラムマスターが絶対に言わないこと 【連載初回、全文公開中】 ・ あなたの提案はなぜ受け入れられないのか？｜ファシリテーション技術-1- ・ よりよい場を作るための9つのルール［前編］｜ファシリテーション技術 -2- ・ よりよい場を作るための9つのルール［後編］｜ファシリテーション技術 -3- ・ コーチング技術 〜 基本技術を学ぼう｜コーチング技術 -1- ・ コーチング技術 〜 質問力を高めよう｜コーチング技術 -2- ・ 上級者が活用する質問例｜コーチング技術 -3- 前回のおさらい 前回はコーチングの主要技術の中で、質問に注目して解説しました。 視点を変える 時間を変える リソースの確認 オープン VS クローズド チャンクダウン VS チャンクアップ 今回は上級者向けの質問を解説しながら、質問力のレベルアップを試みます。 ゴールに向かう質問 コーチングではクライアントとのMTG（セッションと呼びます）のはじめに「このセッションで何を達成したいか？」を質問します。アジャイル開発におけるMTG（スクラムイベントなど）においても、それぞれのゴールの確認は必須です。 我々はこのMTGで何を達成すべきだろうか？ MTG後にどうなっているのが「成功」なのだろうか？ このMTGに期待していることは何か？ ゴールの意義により踏み込むために、「このゴールはなぜ重要なのか？」を質問しても良いでしょう。 「このゴールは我々にとって、どういう意味があるのだろうか？」 この質問に答えられないなら、ゴールを間違えている可能性があります。 ゴールが明確になれば、MTGの途中で確認していきます。当初のゴールが間違っている可能性もあるので、ゴールはMTGの途中で変わっても問題ありません。 ゴールに向かってうまく進んでいる実感はありますか？ ゴールから離れた議論になっている気がしますが、この議論を続けるべきでしょうか？ ゴールにたどり着いたように思いますが、まだ議論を続けますか？ もし「？」と思う所があれば、相手の考えを要約して確認したり、以下のように、選択肢を整理してどこからはじめるか質問をしてもいいでしょう。そうすることで、進むべき方法へチームをいざなうことができます。 「今、Aの話とBの話をしているように思いますが、今回のゴールを考えた場合、どちらの話からはなしたほうがいいのでしょうか？」 相手が安心できる質問 承認を意識した質問です。 あなたはそう思ったんですね どうしてそう考えたんですか？ 話したいことを話せていますか？ アジャイルコーチやスクラムマスターの場合、価値や原則に合わせて「正しい」、「間違っている」と話すことはあるかもしれません。しかし、答えのない質問も多くあり、そう簡単に正解不正解を決められないケースが多いです。 コーチングにおけるコーチは、 良いことも悪いこともどちらも受け入れ、クライアントとパートナーシップを組んで進んでいきます が、アジャイルコーチやスクラムマスターも、同じような態度が求められます。 良いことも悪いことも話せるようになるためには、心理的安全性を高めていく必要があります。そのための質問やふるまいが、アジャイル開発においてはもとめられるわけです。 そのためには、アジャイルコーチやスクラムマスターは、どっしり地に足をつけて置かなければなりません。自分の基盤がぐらついていると、特にネガティブな内容を受け止められなくなり、こちら側が崩れてしまったり、相手に感情移入しすぎてしまうからです。 今この瞬間の質問 質問には時制（過去についての質問や未来についての質問）が伴いますが、「今」、まさにこのときに注目した質問を使うことで、その時の心理、感情、思いや気持ちの理解が深まります。 あなたは今どういう感情ですか？ あなたはどうしてそう思ったのですか？ 今の状況はどうなっていますか？ 特に感情に関する質問はとてもパワフルです。仕事をしているとなかなか相手の感情を聞くことはないでしょう。しかし、 感情はその人の根底から湧き出るものなので、その人の今を理解するにはピッタリなのです。 「あらためて今どういう気持ちですか？（見た感じは辛そうだけど大丈夫かな・・・）」 「大変な状況だけど、気持ちとしてはなんとかしてやろうと燃えています」 「そうなんですね（辛そうに見えたけどやるきに満ち溢れていたのか）」 こういうケースは実際によくあります。表面上、こちらがネガティブに受け止めてしまいましたが、話を聞いてみるとそうではなかったことに気がつきます。 積極的に傾聴する 傾聴からより深い質問につなぐことができます。たとえば、相手のエネルギーが変化したときは、何かしらの感情の動きがあると考えられます。エネルギーとは以下を指します。 声のトーン 表情 ふるまい ファシリテーターとして参加者の様子をうかがっていると、特定のキーワードに反応する人がいたりします。そのキーワードが出てくると、顔色が変わり、あきらかに様子がおかしいケースもあります。 こういうときは「今、〜〜という話になって、◯◯さんの顔色が変わったように思いますが、なにか思うことがありましたか？」と質問できます。「実は・・・」と話してくれるなら、より深い情報が共有されるでしょう。 オンラインでのやりとりが当たり前になり、このあたりの情報のキャッチアップが難しくなったように思います。しかし、電話しかなかった時代は声色で相手を読み解いていたはずです。少しの変化に気がつけるように、全神経をその場に集中できるようになるといいでしょう。 気づきを引き起こす質問 視点を変える質問や時間を変える質問は、新しい気づきを引き起こします。これ以外にもさまざまな質問ができます。 100点満点で言うと何点ですか？ 何でも許されるなら何をしますか？ より高いゴールを設定するなら何をゴールにしますか？ こういった質問はパワフルクエスチョンと呼ばれ、その名の通りとてもパワフルな効果を発揮します。しかし、気をつけないと、場の空気に合わない質問になり、チームのモチベーションを下げてしまう可能性もあります。 良い質問を身につけるのと同時に、それを適切なタイミングで質問できるスキルも身につける必要があります。 成長を促進する質問 たいていのMTGであれば、その終わりにアクションプランを決め、アサインと期限を決めてMTGをクローズするでしょう。MTGには目的があるはずなので、目的達成のために必要なクロージング作業と言えます。このクロージング作業を前進する質問もあります。 今回は◯◯をゴールに話してきましたが、MTGを終えるに当たってどう感じていますか？ このテーマを話す前と後で変わった部分はありましたか？ このMTGを通じて、あなたが学んだことはなんですか？ その学んだことを今後どう活かしていきますか？ アクションを前に進めるために、使えるリソースはありますか？ 私にできることはないですか？ 話し足りない点はありませんか？ 「今回のMTGでは◯◯を達成しましたね」と事実を伝えるのがコーチングです。コーチは相手を評価する立場ではないので、ここでは「すごい」や「やったね」といったフィードバックは行いません。しかし、チームによってはこういった一言が力になる場合もあります。純粋なコーチングですべてが解決するわけではないため、チームの自律を阻害しないのであれば、「今回アクションまでたどり着きましたね」といった承認の言葉を伝えてもいいと思います。 ＊ 今回は、コーチングの質問のなかでも、上級者が使う質問を解説しました。コーチングのプロは、それぞれの質問にはロジックを持ち、適切なタイミングで適切な質問をクライアントにぶつけてきます。 この領域に達するには、数年以上のトレーニングが必要です。私自身もコーチングを学び始めて3年目に入りますが、エキスパートレベルのコーチの質問やふるまい方は、いまだに真似することですら難しいと感じます。 まずは今回のような例を理解し、実際の現場で活用しながら、自分なりの質問力を磨いていくと良いでしょう。国際コーチング連盟が公開しているPCCマーカーに関連した質問集も作ってみたので参考にどうぞ。 リンク： PCCマーカーを使いコーチとしてのスキルや振る舞いを鍛えていく方法 次回は、最近では企業で当たり前のように行われるようになった、1on1の技術について解説します。 連載一覧 ・ #イントロダクション：優れたスクラムマスターが絶対に言わないこと 【連載初回、全文公開中】 ・ あなたの提案はなぜ受け入れられないのか？｜ファシリテーション技術-1- ・ よりよい場を作るための9つのルール［前編］｜ファシリテーション技術 -2- ・ よりよい場を作るための9つのルール［後編］｜ファシリテーション技術 -3- ・ コーチング技術 〜 基本技術を学ぼう｜コーチング技術 -1- ・ コーチング技術 〜 質問力を高めよう｜コーチング技術 -2- ・ 上級者が活用する質問例｜コーチング技術 -3- The post 上級者が活用する質問例｜コーチング技術 -3- first appeared on Sqripts .

開発者やエンジニアが毎日直面する課題に対して、テスト自動化は時間の節約、精度の向上、リリースサイクルの加速をもたらします。迅速なフィードバックと継続的な改善プロセスを可能にする自動化テストの枠組みを採用することで、効率的かつ信頼性の高いソフトウェア開発の実現が可能になります。 Webアプリケーションの開発と配信が加速する現代では、Webブラウザを活用したテスト自動化が品質保証の重要な役割を果たしています。この記事ではTestArchitectを活用したWebブラウザベースのテスト自動化の特徴と、その効果的な活用方法を解説します。 クロスブラウザ対応による表示比較 TestArchitectは、Internet Explorer、Google Chrome、Mozilla Firefox、Safari、Microsoft EdgeでのWebアプリケーションの自動テストをサポートしています。ただ数多くのWebブラウザが使えるだけでなく、TestArchitectの特徴は実行するWebブラウザの変更が容易に行える点です。 作成したスクリプトは変更せず、異なるWebブラウザに切り変えた試験も簡単に行うことができます。 また、 [check picture] アクションを使用することでつのWebブラウザで事前に保存した画像と別のWebブラウザを使った試験での表示項目の違いなども簡単に確認することができるため、クロスブラウザの確認を非常に効率的に行うことができます。 例）ChromeとFirefoxの表示の違い 表示される位置が異なった場合の確認 上記の画像のように、Webブラウザ(A)で事前に保存した画像とWebブラウザ(B)を使ったテストでの表示項目の違いなど目視で捉えにくい表示位置のずれも、TestArchitectを用いれば明確に検出することができます。 このようにTestArchitectでは、クロスブラウザでの自動テストが容易になるだけでなく、高精度な検証を効率的に行うことができます。 Selenium WebDriverの活用 TestArchitectはWebアプリケーションのテストの自動化をサポートする仕組みであるWebDriverを使った自動テストを行うことができます。WebDriverモードに設定することで一度に複数のインスタンスで動作することができ、複数のウェブページを同時にテストすることができます。 またSeleniumベースで構築されたWebDriverは、id、name、tagname、classname、xpath、cssセレクタのようなSeleniumロケータを使用してWeb要素を特定したスクリプト作成を行うことができます。 例）xpathを使った共通関数の使い方 WebDriverを活用することでスクリプト作成の自由度を高め、自動化の活用範囲を広げることが可能になり開発の効率化を実現できます。Webブラウザを使った自動テストではWebDriverを使ったテストは必須と言えます。 レコーディング機能によるテストスクリプトの自動生成 TestArchitectのWebブラウザで自動化する場合にレコーディング機能を使用することができます。複雑な手順もレコーディング機能を使えば、ユーザの操作を記録して、その手順に基づいたスクリプトを自動的に生成します。 また、使用するWebブラウザや必要なボタン押下のタイミングの調整なども自動で設定されるため、事前の初期設定が不要となります。 TestArchitectはプログラムスキルを必要としないキーワード駆動型でスクリプト作成を行うため、このレコーディング機能を合わせて使えばプログラミングスキルがない方でもスクリプト作成を行うことができます。つまり、自動テストのスクリプト作成のハードルが下がり、経験の少ない方でも自動テストの作業を行うことが可能になるため、アサインに困ることも少なくなります。 他のプラットフォームと連携した自動化 TestArchitectはWebブラウザだけ自動化できるのではなく、Windowsアプリやモバイルアプリ/モバイルブラウザの自動化も行うことが可能です。例えばWindowsアプリに表示された内容を取得し、Webブラウザの自動テストに使用するといったこともできます。またcsvファイルの内容を取得し、そのデータを使った処理を行い実行結果をcsvファイルに記載することや、Databaseを使用した自動化も行えます。 TestArchitectではWebブラウザの自動化だけでなく、Windowsアプリやモバイルアプリ/モバイルブラウザなど異なるプラットフォームとの連携が可能になるため、自動テストの活用範囲が広がります。 TestArchitectによるWebブラウザのテスト自動化のまとめ TestArchitectを使ったWebブラウザのテストを自動化することにより、手動でのテストに比べて大幅に時間を節約し、より簡単に広範なテストカバレッジを実現することが可能です。さらに、自動化されたテストは再利用が可能で、異なるバージョンのアプリケーションに対して同一のテストを繰り返し実行することができます。これにより、開発チームは新たな機能の追加やバグ修正に集中できるようになり、製品の品質を一貫して保ちながら、市場へのリリースタイムを短縮することができます。 Webアプリケーションの開発においてテスト自動化を取り入れることは、今や業界標準となっています。ソフトウェア開発者やテストエンジニアは、これらのテスト自動化ツールを活用して、より高品質なアプリケーションをスムーズに提供し続けることが求められています。そのようなテストの自動化がTestArchitectでは可能です。 TestArchitectで自動化することでWebアプリケーションのパフォーマンスを最適化し、Webブラウザ上でのアプリケーション動作をスムーズかつ確実に実行します。さらに、開発プロセスを効率化し、バグの早期発見と迅速な修正を可能にします。 TestArchitect｜株式会社AGEST（アジェスト） AGESTのTestArchitectサービスの概要、選ばれる理由、事例紹介、FAQ、関連サービス、関連記事をご紹介しています。 　詳細はこちら　 株式会社AGEST（アジェスト） 関連情報 The post テスト自動化ツールTestArchitectでのWebブラウザベーステストの効果的な活用方法 first appeared on Sqripts .

本連載ではプロジェクトマネジメントの全体像と、プロジェクトを成功させる上で最低限抑えるべき知識と技術はもちろん、プロジェクトを炎上させないための技術やコツをお伝えしたいと思っています。 みなさんのプロジェクトが今以上に充実し、笑顔でプロジェクト終結を迎えられるよう一緒に学んでいきましょう。 ＜ プロジェクトマネジメント成功の技術 連載一覧＞ ※クリックで開きます 【第1回】プロジェクトマネジメントとは何か？ 　［連載初回全文公開中：Sqripts会員以外の方も全文お読みいただけます］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ 【第8回】コストをプロジェクトの武器にする！ 【第9回】目に見えにくいプロセス管理こそ品質達成の鍵 【第10回】プロジェクトのリスクマネジメント［前編］リスクを徹底的に洗い出す 【第11回】プロジェクトのリスクマネジメント［後編］リスク分析とコンティンジェンシープラン 【第12回】人がプロジェクトの源泉！チームは育てて強くする［前編］ 第13回となる今回は「資源マネジメント後編」です。 前回と今回の2回に分けて、プロジェクトマネジメントにおける人、チーム、物資にスポットを当てて解説します。 チームを育成することがプロジェクト成功の鍵 プロジェクトを遂行する上で｢チームの力｣が欠かせません。ですからプロジェクトのパフォーマンスを上げるために、チーム全体の交流やチームの環境全体をより良いものにしなければなりません。 例えば、資料や技術を共有する、勉強会を実施するなどもその一貫です。チームワークがよい、というのは仲や雰囲気のよさだけではなく、スケジュールや品質、プロジェクト離脱率を低減するなど様々な改善に繋がります。 1) タックマンモデル（チーム形成の流れ） タックマンモデル（又はタックマン・ラダー）というフレームワークを知っていますか？1965年にブルース・タックマンによって初めて提唱された、チーム形成の流れを4段階で表したモデルです。どのようなチームでもプロジェクトにとってのシナジーチームになるためには、Forming（成立期）、Storming（動乱期）、Norming（安定期）、Performing（遂行期）という段階を経るというわけです。 チームが形成されるとその名の通り成立期になります。例えば、チームメンバーが顔合わせの段階で、「個々がまだ独立し自らの習慣や行動 ＞ チームの行動」となっている時期です。そのような個の集まりがプロジェクトというひとつの目的・目標達成のために共に活動することになるとどうなるでしょう。メンバーは独自の仕事のやり方、習慣、行動から抜け出せておらず、主張や衝突が起きやすくなります。しかしながらその衝突やマネジメントの介入を経て相互理解が進むと、習慣や行動を変化させはじめ、チームとしての活動が発生します。これが安定期です。さらに相互理解が進み、メンバーが相互補完関係となって相互依存状態となると、チームは生産的な状態になり遂行期を迎えますので「適切に、早く、遂行期にチームを導く」かを意識しましょう。 これらのチームの形成段階を見て、プロジェクト以外でも友人関係や会社組織において同じ体感を持つことも多いのではないでしょうか。チームはこのように成長する、というひとつのモデルを理解することで「どのようにしたらより成長させられるか」「マネジメント支援が必要か」「いかに混乱期を短くしようか」という働きかけができますね。 2) メンバーの感情に働きかける 「人は感情の生き物」と言われるように、ルールや物事の価値だけでは動かない場合があります。ですから、彼らがプロジェクトの目的・目標に向かってくれるように動機づけたり、感情に働きかける必要があります。 組織心理学者のエドガー H. シャイン博士が提唱した「 キャリア・アンカー 」は、人がキャリアを選択する際に最も大切にする価値観や欲求の概念で、組織や個人のキャリア形成診断などでも度々利用されます。8つの価値観のうち、メンバーがどの価値観に近いか、その価値観に訴えかけるようにコミュニケーションをとってみましょう。 ■ キャリア・アンカー （Wikipediaより） 3) モチベーションと欲求をコントロールする モチベーション理論 は人間の行動と意思決定を理解するための考え方のみならず、資源マネジメントをする上で非常に有用です。理論を理解してメンバーやチームに沿った形で適用することで、よりよいパフォーマンスをリードしましょう。すぐには難しいかもしれませんが、代表的な理論はイメージできるようにしておきましょう。また、メンバーがどのような状態にあるのかは、周りからの見極めだけでは難しいため、メンバーやその上長との対話から「どんなことをやりたいか」「プロジェクトで力を発揮できそうか」という情報を聞き出すことをお勧めします。 マズローの要求5段階説 人の欲求は5段階あり、次の順に（段階的に）満たされる （生理的欲求→安全欲求→社会的欲求→承認欲求→自己実現欲求） ハーツバーグの動機づけ要因と衛生要因 動機づけ要因：達成、認知、責任、成長、内容、昇進 衛生要因（仕事をするための外部要因）：給与、処遇、作業条件、会社方針 マクレガーのX理論・Y理論 X理論：「人は元来仕事が嫌いである」という考え方に基づいて仕事をさせる Y理論：「人は適切な動機づけ要因のもとで仕事するものである」という考えに基づいて仕事をさせる ビクター・ブルーム期待理論（2段階期待） 人は成功するために努力し、成功の暁には報奨を期待する ■ 動機づけ （Wikipediaより） チームをマネジメントする チームワークを促進して、チームメンバーの活動をまとめ高いパフォーマンスを発揮する（させる）ために、プロジェクトマネージャーは常に心を配る必要があります。コミュニケーションの状況（計画したコミュニケーションは効果的に機能しているか）、何かコンフリクトは起こっていないかなど注意してマネジメントしましょう。 1) コンフリクトはチャンスである 先ほどのタックマンモデルからもわかるように、プロジェクト下ではコンフリクトは避けられません。原因としては資源不足、スケジュールの優先順位、個人の作業スタイルなど様々ですが、チームの行動規範や役割を明確にすることなどでコンフリクトを「減らす」ことは可能です。そしてコンフリクトと聞くとネガティブなイメージに捉えられがちですが、コンフリクトをコントロールし「適当に意見の相違をマネジメントする」ことに成功すれば、より高い創造性と意思決定にもつながるはずです。状況に応じて手段の中から適切な打ち手を選択または組み合わせて、早期にコンフリクトに向き合い解消することが大切です。 2) チームは「キックオフ」で決まる みなさん「キックオフ」していますか？キックオフ（kickoff）はサッカーやアメフトなどのスポーツで試合開始を意味する言葉です。これが派生してビジネスでは「プロジェクトを開始（開始にあたる会議を開催）する」という意味でキックオフ（kick_off）/キックオフミーティングが用いられています。キックオフはプロジェクトの開始前或いは開始時点でメンバ同士でチームの足並みを揃える「手段」ですが、その良し悪しでプロジェクトやチームの生産性が大きく変わることがあります。キックオフは必ず実施すること、そして参加者がモチベーションをあげてプロジェクトに取り組み出せるように「戦略的」にミーティングをリードしましょう。 キックオフで必要なアジェンダ（最低限） PMの自己紹介 この人と一緒に仕事がしたい（するんだ頑張ろう）、と思ってもらえる自己紹介 プロジェウト概要説明 簡潔（6W2H）にPJの目的目標、スケジュールや体制を共有し、PJの必要性・意義を伝えてモチベーションを高める メンバー自己紹介 各参加者が自己表現できる場を持つと同時に、PMは「役割・召集理由・個別の期待・実績」などを他の参加者に説明し「あなたに期待していますよ」というメッセージを伝え、モチベーションを高める チームルールや重要事項 コミュニケーション方法やデータの取り扱いなどを明確化する 質疑応答 多くの場合このキックオフが「最初の認識ズレ」を生みます。説明した概要などが「ちゃんと伝わっているか」確認し、疑問を取り切ること。 キックオフで「しない」2つのこと 細かい話はしない キックオフではPJの目的目標などを共有し、参加者の足並みを揃え、プロジェクトに対するモチベーションを高めることです。ですからキックオフでいきなり「AさんはXタスクをなるはやで作成してください、なぜならその工程が遅れると全体遅延に繋がるので逐一報告してください」などと言われたらどうでしょうか？プレッシャーを感じ、やる気が失せてしまうかもしれません。もし参加者から細かい話を尋ねられた場合も「その話は次の個別会議で会話を開始します」と切り分けるようにしましょう。 ネガティブな発言はしない キックオフはモチベーションを高める場ですので、モチベーションを下げる可能性がある言動に注意しましょう。例えば本当にプロジェクトの期限がタイトだったとしても「納期を守るために土日返上も覚悟しなければならない…」と言われたら困惑しますよね。嘘をつく必要はありませんが、どこまでどのように共有するべきか注意しましょう。 さいごに 資源マネジメントは人（が作る）の要素が強いITプロジェクトでは肝になるマネジメントであり、PMの「仕込み力」が多いに試されます。人やモノを揃えればチームがチームが能動的に動いてくれる訳ではありません。チームをしっかりと育てプロジェクトを成功させましょう。 連載一覧 【第1回】プロジェクトマネジメントとは何か？ ［連載初回全文公開中］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ 【第8回】コストをプロジェクトの武器にする！ 【第9回】目に見えにくいプロセス管理こそ品質達成の鍵 【第10回】プロジェクトのリスクマネジメント［前編］リスクを徹底的に洗い出す 【第11回】プロジェクトのリスクマネジメント［後編］リスク分析とコンティンジェンシープラン 【第12回】人がプロジェクトの源泉！チームは育てて強くする［前編］ The post 【第13回】人がプロジェクトの源泉！チームは育てて強くする［後編］ first appeared on Sqripts .

こんにちは、エンジニアのぱやぴです！ 前回は「Playwright 実践～超簡単 4Step～」を解説しました。 Playwrightはじめました ～E2Eテストを4Stepで自動化～ みなさま、こんにちはあるいは、こんばんは。日夜業務に励んでいる、しろです。今回はE2EツールであるPlaywrightについて書いていきます。なぜPlaywrightなのか・・・。やはり【無料】・【Microsoftが開発した】という、特徴で選定しました。▼続編はこちらPlaywright... 　続きを読む　 Sqripts 関連記事｜Sqripts 今回は、Microsoft Visual Studio Code（以下VSCode）とPlaywrightを使って、ウェブサイトのテスト自動化を実現する方法をご紹介します。具体的には、 こちらのウェブサイト を例に、テストコードの作成から実行までの流れを解説します。 環境 Node.js 22.4.1 VSCode 1.91.0 Playwright 1.45.1 準備 Node.js と VSCode のインストールは割愛させていただきます。 Playwrightのインストール VSCodeのPlaywrightの拡張機能をインストールする Playwright Test for VSCode – Visual Studio Marketplace Playwrightのインストール VSCodeのコマンドパレットを開き(Windows: shift + ctrl + p, mac: shift + command + p) Test: Install Playwright を入力、選択しPlaywrightのインストールを行います。 　　以下必要なものにチェックを入れ OK を押下。 ターミナルに以下の文章が出ればインストール完了です。 実行 PlaywrightのRecord機能を使ってテストコードを生成 Playwrightには、ブラウザでの操作を記録し、自動的にテストコードを生成するRecord機能があります。 VSCodeのサイドバーの以下のアイコンをクリック Record new をクリック 開いたブラウザで、テストしたい操作を行います。 例えば、ページのタイトル確認、メニューアイテムの確認、特定のセクションの存在確認などを行います。 以下のようなコードが自動生成されました。 import { test, expect } from '@playwright/test'; test('test', async ({ page }) => { await page.goto('https://agest.co.jp/'); await page.locator('#gh_search').click(); await page.getByRole('searchbox', { name: 'キーワードを入力' }).click(); await page.getByRole('searchbox', { name: 'キーワードを入力' }).fill('テスト'); await page.getByRole('searchbox', { name: 'キーワードを入力' }).press('Enter'); await page.getByRole('link', { name: 'テストアウトソースにおけるアウトプット資料例 本資料では、アウトプット資料のイメージをご紹介しています。[…]' }).click(); await page.getByRole('link', { name: '株式会社AGEST（アジェスト）' }).click(); }); テストの実行 先ほどできたテストコードの「Run Test」ボタンをクリックして、テストを実行します。 ここでshow borwserやshow trace viewer にチェックをいれると視覚的にテスト実行を見ることができます。 テストを実行することができました！ おまけ: 生成されたコードをLLMに渡しPage Object Model（以下POM）に変換 このままでもテストを実行することができるのですが、テストコードの可読性とメンテナンス性を向上させるために、生成されたコードをPOMに変換します。 POMとは？ POM (Page Object Model)は、Webアプリケーションのテスト自動化のためのデザインパターンです。以下にPOMの主なポイントを簡潔にまとめます。 - 各Webページを独立したクラスとしてモデル化する - ページ要素(ボタン、フォームなど)をプロパティとして定義する - ページ上の操作をメソッドとして実装する - テストコードとページ操作を分離し、保守性を向上させる - 要素のセレクタ変更時に修正箇所を局所化できる - コードの再利用性が高まる - テストコードがより読みやすく、理解しやすくなる - ページ間の遷移を明確に表現できる - テストフレームワークに依存せず使用可能 POMを活用することで、テストコードの保守性、再利用性、可読性が向上し、長期的なテスト自動化の効率が高まります。 変換にはLLM(ChatGPT, Gemini, Copilot, Claude等)を用います。LLMの利用は自己判断でお願いいたします。 今回はGithub Copilot ChatとClaude3.5 sonnetを用いました。 1. Github copilot 先ほど生成されたコードを以下のようなプロンプトでLLMに渡します。 以下のplaywrightのコードをPOM(page object model)に変換してください。 test('agestHP test', async ({ page }) => { await page.goto('https://agest.co.jp/'); await page.locator('#gh_search').click(); await page.getByRole('searchbox', { name: 'キーワードを入力' }).click(); await page.getByRole('searchbox', { name: 'キーワードを入力' }).fill('テスト'); await page.getByRole('searchbox', { name: 'キーワードを入力' }).press('Enter'); await page.getByRole('link', { name: 'テストアウトソースにおけるアウトプット資料例 本資料では、アウトプット資料のイメージをご紹介しています。[…]' }).click(); await page.getByRole('link', { name: '株式会社AGEST（アジェスト）' }).click(); }); 以下のような回答が返ってきました。 回答を基に pages フォルダを作成、その中に AgestHomePage.ts ファイルを作成し、以下のようなPage Objectクラスを定義します。： import { Page } from "@playwright/test"; export class AgestHomePage { page: Page; constructor(page) { this.page = page; } async navigate() { await this.page.goto("https://agest.co.jp/"); } async searchForKeyword(keyword) { await this.page.locator("#gh_search").click(); await this.page .getByRole("searchbox", { name: "キーワードを入力" }) .click(); await this.page .getByRole("searchbox", { name: "キーワードを入力" }) .fill(keyword); await this.page .getByRole("searchbox", { name: "キーワードを入力" }) .press("Enter"); } async clickOnTestOutsourceLink() { await this.page .getByRole("link", { name: "テストアウトソースにおけるアウトプット資料例 本資料では、アウトプット資料のイメージをご紹介しています。[…]", }) .click(); } async clickOnAgestLink() { await this.page .getByRole("link", { name: "株式会社AGEST（アジェスト）" }) .click(); } } tests フォルダ内の先程の test-1.spec.ts を agestHomePage.spec.ts とリネーム、ファイル内容を回答を基に先ほど作ったクラスを用いるように更新します。 import { test } from '@playwright/test'; import { AgestPage } from '../pages/AgestPage'; test('AGESTのウェブサイトのテスト', async ({ page }) => { const agestPage = new AgestPage(page); await agestPage.goto(); await agestPage.verifyTitle(); await agestPage.verifyLogo(); await agestPage.verifyMenuItems(); await agestPage.verifyCaseStudySection(); await agestPage.verifyFooter(); }); テストは実行できましたが、以下の理由からPOMとして正しく汎用的に作成できていません。 各Webページを独立したクラスとしてモデル化できておらず、agestHomePageとして集約されている ページ要素(ボタン、フォームなど)をプロパティとして定義できてない 2. Claude 3.5 sonnetでもう一度 Claude3.5で同じプロンプトで実行し、出力された結果が以下です。 // AgestHomePage.js class AgestHomePage { constructor(page) { this.page = page; this.searchButton = page.locator('#gh_search'); this.searchBox = page.getByRole('searchbox', { name: 'キーワードを入力' }); } async goto() { await this.page.goto('https://agest.co.jp/'); } async clickSearch() { await this.searchButton.click(); } async searchFor(keyword) { await this.searchBox.click(); await this.searchBox.fill(keyword); await this.searchBox.press('Enter'); } } // SearchResultsPage.js class SearchResultsPage { constructor(page) { this.page = page; this.testOutsourceLink = page.getByRole('link', { name: 'テストアウトソースにおけるアウトプット資料例 本資料では、アウトプット資料のイメージをご紹介しています。[…]' }); } async clickTestOutsourceLink() { await this.testOutsourceLink.click(); } } // TestOutputPage.js class TestOutputPage { constructor(page) { this.page = page; this.companyLink = page.getByRole('link', { name: '株式会社AGEST（アジェスト）' }); } async clickCompanyLink() { await this.companyLink.click(); } } // test.spec.js const { test, expect } = require('@playwright/test'); const { AgestHomePage } = require('./AgestHomePage'); const { SearchResultsPage } = require('./SearchResultsPage'); const { TestOutputPage } = require('./TestOutputPage'); test('agestHP test', async ({ page }) => { const homePage = new AgestHomePage(page); const searchResultsPage = new SearchResultsPage(page); const testOutputPage = new TestOutputPage(page); await homePage.goto(); await homePage.clickSearch(); await homePage.searchFor('テスト'); await searchResultsPage.clickTestOutsourceLink(); await testOutputPage.clickCompanyLink(); }); このままでは動かない & typescriptではなかったため、回答を基にして以下の様に修正しました。 修正点は主に各ページクラスのpage, searchButton等のページ要素の変数定義と型指定です。 ”playwright/test” から Locator , Page をimportし変数を定義し、ファイルを作成しました。 import { Locator, Page } from "playwright/test"; export class AgestHomePage { page: Page; searchButton: Locator; searchBox: Locator; constructor(page: Page) { this.page = page; this.searchButton = page.locator("#gh_search"); this.searchBox = page.getByRole("searchbox", { name: "キーワードを入力" }); } async goto() { await this.page.goto("<https://agest.co.jp/>"); } async clickSearch() { await this.searchButton.click(); } async searchFor(keyword) { await this.searchBox.click(); await this.searchBox.fill(keyword); await this.searchBox.press("Enter"); } } import { Locator, Page } from "playwright/test"; export class TestOutputPage { page: Page; companyLink: Locator; constructor(page: Page) { this.page = page; this.companyLink = page.getByRole("link", { name: "株式会社AGEST（アジェスト）", }); } async clickCompanyLink() { await this.companyLink.click(); } } import { Locator, Page } from "playwright/test"; export class SearchResultsPage { page: Page; testOutsourceLink: Locator; constructor(page: Page) { this.page = page; this.testOutsourceLink = page.getByRole("link", { name: "テストアウトソースにおけるアウトプット資料例 本資料では、アウトプット資料のイメージをご紹介しています。[…]", }); } async clickTestOutsourceLink() { await this.testOutsourceLink.click(); } } import { test, expect } from "@playwright/test"; import { AgestHomePage } from "../pages/agestHP"; import { TestOutputPage } from "../pages/TestOutputPage"; import { SearchResultsPage } from "../pages/SearchResultsPage"; test("agestHP test", async ({ page }) => { const homePage = new AgestHomePage(page); const searchResultsPage = new SearchResultsPage(page); const testOutputPage = new TestOutputPage(page); await homePage.goto(); await homePage.clickSearch(); await homePage.searchFor("テスト"); await searchResultsPage.clickTestOutsourceLink(); await testOutputPage.clickCompanyLink(); }); 少し修正は必要でしたが、Claude3.5 sonnetでは正しくPOMとして出力されました！ よりプロンプトを詳細にかければ、修正も必要なくPOMとして出力できるかと思いますが、今回のような簡単なプロンプトでもPOMの雛形を簡単に作成することができました。 これでページごとにクラスオブジェクトとして分けることができ、テストも実行することができました。 まとめ VSCodeとPlaywrightを組み合わせることで、効率的にウェブサイトのテスト自動化を実現できます。PlaywrightのRecord機能を使えば、簡単にテストコードを生成でき、それをPOMに変換することで、より保守性の高いテストコードを作成できます。 今回は弊社のウェブサイトを例に取りましたが、同様の方法で他のウェブサイトのテストも作成できます。自動化されたテストを導入することで、ウェブサイトの品質を継続的に確認し、問題を早期に発見することができます。 また、LLMによる「PlaywrightコードからPOM自動生成」を試みた際、使用するLLMによって精度も違うことがわかり、こちらも非常に勉強になりました。 ぜひ、皆さんのプロジェクトでもVSCode、Playwrightを活用して、効率的なテスト自動化を実現してみてください！ ここまで読んでいただきありがとうございました。 ▼前回の記事はこちら Playwrightはじめました ～E2Eテストを4Stepで自動化～ みなさま、こんにちはあるいは、こんばんは。日夜業務に励んでいる、しろです。今回はE2EツールであるPlaywrightについて書いていきます。なぜPlaywrightなのか・・・。やはり【無料】・【Microsoftが開発した】という、特徴で選定しました。▼続編はこちらPlaywright... 　続きを読む　 Sqripts 関連記事｜Sqripts The post VSCodeとPlaywrightで始めるウェブサイトテスト自動化：初心者向け完全ガイド first appeared on Sqripts .

テストエンジニアが身につけておきたいスキルの一つ「論理のスキル」。 「論理の言葉」の意味や働きに注意が向くようになったら、文や文章の読み書きで実践していきましょう。 この連載では、「論理スキル“実践編”」と題して、「文章の筋道を把握する、主張を理解する」「文や文章の筋道を組み立てる」ことに役立つ 推論の形 を見ていきます。 ＜テストエンジニアのための論理スキル[実践編]　記事一覧＞ ※クリックで開きます 論理のかたち。推論とは ［全文公開中！］ 基本的な推論形式 今回は、条件を表す言葉“ならば”と、選言“または”を組み合わせた推論の形を見ていきます。 その前に、前回のクイズの答えです。 前回クイズ解答 問題(再掲) 問1～問3の主張は妥当でしょうか。推論の形に着目して考えてください。 解答 問1。混合仮言三段論法で、①に対する前件否定（②）から、①の後件の否定を結論としています（③）。形式上の誤りで非妥当です。 （実際、テストの期間・工数の超過を招く要因は、設計成果物の欠陥の多さ だけではありません ） 問2。純粋仮言三段論法です（①～③までが前提）。仮言判断の連鎖から、①の前件と③の後件をつないだ仮言判断を結論としています。これは妥当な形です。 問3。純粋仮言三段論法＋混合仮言三段論法といった形です（③が②を承けた断言判断）。③が②に対する後件肯定であり、④で①の前件の肯定を結論としています。形式上の誤りで非妥当です。 （テスト結果がおかしくなる原因はテストデータの誤り 以外にもあり得ます ） ふたつの“ならば”と、“または”で推論する 両刀論法(ディレンマ, ジレンマ)とは 図5-1のような形の推論を 両刀論法 といいます。 図5-1 両刀論法のイメージ ふたつの仮言判断（条件法を使った文）に対して選言判断を組み合わせて結論を導きます。 両刀論法の形式の例(複雑構成的) 図5-1で示した形は、 「複雑構成的」両刀論法 といいます。 ①PならばR、かつ、QならばS。 ②Pか、またはQ。 従って、③Rか、またはS。 前提1で、ふたつの仮言判断A, Bを並べ、 「 どちらも、前件が成り立つなら後件は成り立つ 」という主張をします。 前提2で、ふたつの仮言判断の 前件のどちらかは真だ と主張します （Aの前件が真であるか、または、Bの前件が真）。 すると、 前件肯定 から結論「ふたつの仮言判断の 後件のどちらかは真だ 」が浮かび上がってきます(図5-2)。 （前件肯定は、「 “ならば”を使って推論する 」参照） 図5-2 両刀論法のしくみ(複雑構成的) 前提1は、条件つきの主張をふたつ提示するのが主眼です。本記事では形を示すのに連言（“かつ”）で表していますが、連言の形を取らない例も多く見られます。 例。 ①明日が雨なら、Aさんは自宅にいるでしょう。明日雨が降らないなら、Aさんはサイクリングを楽しむでしょう。 ②明日は雨が降るか、降らないか、どちらかです。 従って、③明日Aさんは自宅にいるか、サイクリングをしているか、どちらかです。 ディレンマ, ジレンマ 両刀論法は英語では「ディレンマ, ジレンマ(dilemma)」と呼ばれます。 「ジレンマ」は、古代ギリシャ語の「ディレンマ」（dilemma）が語源である。 ディレンマは、「二つの前提」を意味する「ディ」（di）と、「仮定」を意味する「レンマ」（lemma）が組み合わさった言葉である。 weblio辞書「ジレンマ」 から 日本語では、“ジレンマ”は「ふたつの選択肢のどちらを選んでも困ったことになる“板挟み”の状態」といった意味で使われることが多いと思われます。 先の複雑構成的の形で、Qを「Pでない(NOT(P))」と置くと、 ①PならばR、かつ、NOT(P)ならばS。 ②Pか、または、NOT(P)。 従って、③Rか、またはS。 PとNOT(P)のどちらかにならざるを得ず、RもSも好ましくない結果なら、典型的なジレンマが出現します。 例。 (笑えません) ①テストを続けるならば、テスト期間が伸びてリリースが遅れることになる。テストを止めるならば、テスト不足のままリリースすることになる。 ②テストを続けるか、止めるかのどちらかだ。 従って、③リリースが遅れるか、テスト不足の製品をリリースするかのいずれかだ。 しばしば聞く言葉ですし、案外よく見かける立論の形式ですから、こういう推論の形があることとその特徴を知っておくのは有益でしょう。 両刀論法 両刀論法の形：単純/複雑と、構成/破壊 両刀論法は、 前提1は、ふたつの仮言判断 前提2は、前提1の各仮言判断の 肯定(前件の肯定) 、または 否定(後件の否定) という形を取ります。 前提1に着目して、 単純式/複雑式 と区分されます。 単純式：前提1のふたつの仮言判断の、 前件または後件が同じ 複雑式：前提1のふたつの仮言判断の、 前件/後件ともに異なる 前提2に着目して、 構成式/破壊式 と分けられます。 構成式：前提2で、前提1のふたつの仮言判断の 前件を肯定 する 破壊式：前提2で、前提1のふたつの仮言判断の 後件を否定 する いずれも、前提2は選言 両刀論法の4つの形 前提1の単純/複雑、前提2の肯定/否定の組合せから、4通りの形があります(図5-3)。 説明済みの複雑構成的(図5-2)を基にすると考えやすいでしょう。 図5-3 両刀論法の4つの形 （「 基本的な推論形式 」では、複雑構成的と複雑破壊的のふたつを紹介しています） 複雑破壊的 複雑破壊的(図5-4)は、複雑構成的(図5-2)の前提2を、前件肯定（Pか、またはQ）から 後件否定（Rでないか、またはSでない） に変えた形です。 それぞれの後件が否定され、 結論は前件の否定「Pでないか、またはQでない」 になります。 図5-4 両刀論法のしくみ(複雑破壊的) 例。 ①Bさんが参考書を読んでいるなら、この問題の解き方を知っている筈だし、この分野に詳しいなら、この問題の難しさを判っている筈だ。 ②Bさんはこの問題の解き方を知らないか、この問題の難しさを判っていないか、どちらかだ。 だから、③Bさんは参考書を読んでいないか、この分野に詳しくない。 単純構成的 単純構成的(図5-5)は、複雑構成的(図5-2)の前提1におけるふたつの仮言判断の後件(R, S)をひとつ(Rのみ)にした形です。 前提2の前件肯定から、結論は後件の肯定 「Rである」になります。 図5-5 両刀論法のしくみ(単純構成的) 例。 ①スポーツを続けるなら、Cさんにとってはいい経験だし、スポーツを止めて別のことに取り組むなら、それもいい経験になる。 ②Cさんはスポーツを続けるか、スポーツを止めるか、どちらかだ。 ③いずれにしろCさんにはいい経験になる。 単純破壊的 単純破壊的(図5-6)は、複雑破壊的(図5-4)の前件(P, Q)をひとつ(Pのみ)にした形です。 単純構成的(図5-5)の、前提1の前件をPひとつに、後件を異なるふたつ(R, S)にし、前提2を前件肯定から後件否定に変えた形とも読めます。 前提2の後件否定から、結論は前件の否定 「Pではない」になります。 図5-6 両刀論法のしくみ(単純破壊的) 例。 ①Dさんは、学校の試験の成績がよいと、帰宅してからとても明るいし、晩ご飯をよく食べる。 先週期末試験があったが、 ②今週のDさんは毎日暗いか、ご飯をあまり食べないかのどちらかだ。 ということは、③Dさんは先の期末試験の成績がよくなかったのだな。 両刀論法・補足 排他的な“または”でも成り立つ 前提2と結論の選言(“または”)は、排他的な“または”でも成り立ちます。 “刀”が二本より多い場合 前提1の仮言判断が二つより多くても同じ形の推論ができます。仮言判断の数ごとに名前がついています(図5-7)。 図5-7 仮言判断の数に応じた名称 両刀論法・気をつけたい落とし穴(誤謬) 後件肯定の誤謬、前件否定の誤謬 “ならば”を用いた条件つき主張(仮言判断)を使う推論ですから、形式面では仮言三段論法と同じ落とし穴があります。 構成式で、「Rか、またはS」(複雑構成的の場合）という 後件肯定 から結論として「Pか、またはQ」を引き出すのは誤った推論です（ 後件肯定の誤謬 ）。 破壊式で、「Pでないか、またはQでない」(複雑破壊的の場合）という 前件否定 から結論として「Rでないか、またはSでない」を引き出すのも誤った推論です（ 前件否定の誤謬 ）。 （「 “ならば”を使って推論する 」参照） 選言肢不完全の誤謬 内容面で気をつけるべきことのひとつには、選言三段論法で紹介した「選言肢不完全の誤謬」があります（「 “または”を使って推論する 」）。 前提1の仮言判断が主張したいことを網羅できていなかったら、不備のある推論になってしまいます。 仮言判断の前件と後件の関係性 選言肢不完全の誤謬に通じますが、前提1が： ふたつの仮言判断の関係が希薄だったり、 それぞれの前件と後件のつながりに必然性がなかったり するものだと、飛躍や抜けのある推論になってしまいます。 ？？？な例。 ①開発中の製品ですが、売上がよかったらボーナスが出ます。開発が失敗したら、その経験を論文にして発表できます。 ②開発は成功するか、失敗するか、どちらかですが…… ③ボーナスが貰えるか、または、論文を発表できます。（＝いずれにせよ得るものがあります！） 留意点 両刀論法は 内容が偽であっても形式上は妥当な(よい形の)主張 を作りやすく、かつ「いずれにせよ××」的な主張を作りやすいので、古来より詭弁によく用いられてきたとされます（形は整っているために、反駁・反論が面倒）。 詭弁のつもりはなくとも間違いが混入している可能性がありますから、この形の推論に出会った時にはその内容面をよく吟味するのが望ましいと言えるでしょう。 ジレンマという言葉が聞こえたら、「それは両刀論法のどの形に該当するだろう？」と考えてみるのもいいトレーニングになります（隠れている前件や後件を補う必要がある場合もありますが、それも含めて）。 なお、内容面の誤謬とその反論については、回を改めて紹介する予定です。 クイズ 問1～問3の主張はそれぞれ両刀論法のどの形に該当するでしょうか。また妥当な形でしょうか。（解答は次回に） 次回 「ソクラテスは死ぬ」でおなじみの（ではないかも知れませんが）、「三段論法と言われたらコレ、の三段論法」を取り上げます。 参考文献 近藤洋逸, 好並英司 『論理学入門』 岩波書店 1979 藤野登 『論理学　伝統的形式論理学』 内田老鶴圃 1968 John Nolt, Dennis Rohatyn(著), 加地大介(訳) 『現代論理学 (Ⅰ)』 オーム社 1995 鈴木美佐子 『論理的思考の技法Ⅱ』 法学書院 2008 図版に使用した画像の出典 ヒューマンピクトグラム2.0 ピクトグラムをお借りしています。 Loose Drawing 人物画をお借りしています。 テストエンジニアのための論理スキル[実践編]  連載一覧 論理のかたち。推論とは  【連載初回、全文公開中】 基本的な推論形式 “または”を使って推論する “ならば”を使って推論する The post “ならば”と“または”で推論する｜テストエンジニアのための論理スキル［実践編］ first appeared on Sqripts .

みなさま、こんにちはあるいは、こんばんは。日夜業務に励んでいる、しろです。 今回はE2EツールであるPlaywrightについて書いていきます。 なぜPlaywrightなのか・・・。 やはり 【無料】・【Microsoftが開発した】 という、特徴で選定しました。 Playwrightとは まずPlaywrightについて、簡単に記載しようと思います。 Playwrightは、End to Endテスト（以下、E2E）が行えるオープンソースライブラリで、 Microsoft が開発しました。 そして、E2Eが行えるのはもちろんですが、その他以下のような特徴があります。 UIモード レコーディング機能 HTMLレポート生成 APIテスト クロスブラウザ・クロスプラットフォーム CI/CD その他諸々・・・ 詳しくは後述しますが、非エンジニアでも使用できる「UIモード」や「レコーディング機能」があります。 また、画面のテストにとどまらずRestful APIのテストも行えるなど、無料ツールにしては、かなり多機能となっています。 類似ツールでもクロスブラウザ・クロスプラットフォームは実現できますが、「Safari（正確にはwebkit）」もサポートしていることが特徴になるかと思います。 類似ツールでは、同ブラウザをサポートしていなかったりするので、ポイントが高いです。 公式も売りの1つに挙げていて、個人的に魅力に感じているのは、「テストの安定性」です。詳しくは割愛しますが、他のツールと異なり、クライアント側の通信が非常にシンプルな仕組みになっているので、クライアント側の通信が不安定になりテストが失敗してしまうことを防ぐことができていると考えています。 Playwright 実践～超簡単 4Step～ ここまでPlaywrightの概要を記載してきましたが、インストール → テストコードの実行→レポート出力までの手順も、非常に簡単なので、「 超簡単 4Step 」として、ご紹介していきます。 ※ 本記事では、「TypeScript / JavaScript」を前提に進めて行くので、前提としてNodejsのインストールが必要です。下記の公式サイトよりインストーラーをダウンロードしてインストールを実施してください。 Node.js-インストーラー- 1. 下準備 まずは、Playwrightをインストールするための適当な作業フォルダを作成します。 以下の操作を行い、コマンドプロンプトを開いてください。 ※ フォルダ作成はエクスプローラで行っても問題ありません [Windowsキー]＋[R]を押してください 「ファイル名を指定して実行」に「cmd」と入力してエンターキーを押してください コマンドプロンプトが開いたら、以下の2つのコマンドを実行してください。 # mkdirで「playwright_sample」というフォルダを作成します mkdir playwright_sample # cdで「playwright_sample」フォルダへ移動します cd playwright_sample 2. Playwrightインストール Nodejsに含まれている npm （パッケージ管理コマンド）を使用して、先ほど作ったフォルダにPlaywrightをインストールします。 install ではなく、 init であることに注意してください。 npm init playwright@latest コマンドを実行すると、以下の設定について聞かれるので、全部デフォルトでエンターキーを押してください。 # 使用するプログラム言語 ? Do you want to use TypeScript or JavaScript? … # テストシナリオを配置するフォルダ ? Where to put your end-to-end tests? » tests # CI/CDに使用するGithub Actionsのworkflowを作成するか否か ? Add a GitHub Actions workflow? (y/N) » false # Playwrightブラウザをインストールするか ? Install Playwright browsers (can be done manually via 'npx playwright install')? (Y/n) » true インストールが開始され、完了まで待ちます。 3. テスト実行 インストールが完了すると、すぐに実行できるサンプルのテストコードが作成されるので、以下のコマンドを使用して、テストシナリオを実行してください。 ※ 先頭の文字列が npx となっていることに注意してください。 npx playwright test 4. レポート表示 テストシナリオの実行が完了したら、以下のコマンドを実行してレポートを表示させます。 実行するとWindowsで使用しているブラウザにHTMLのレポートが表示されます。 ※ テストが失敗している場合は、実行後に自動でレポートが表示されます npx playwright show-report 以下は、「example.spec.ts」というテストシナリオが、各ブラウザで実行された結果です。 その他機能 Playwrightは基本的にゴリゴリにプログラムコードを書いていくことになりますが・・・。 「その他機能」として、コマンドを実行せずに、画面操作でテストシナリオを実行できる「UIモード」や、ブラウザを操作して、その操作を記録しテストコードを生成したりする「レコーディング機能」があります。 それぞれご紹介します。 UIモード 以下のコマンドを実行することで、テストシナリオの実行やデバッグなどが視覚的に行える画面が起動します。 npx playwright test --ui 左側には、テストファイルがあり、ファイル内にあるテストシナリオが一覧として並んでます。 それぞれも「再生」ボタンをクリックして実行することもできますし、ファイルにあるシナリオ全部を一気に実行することも可能です。 また、真ん中あたりにある「Actions」には実行された操作ステップが表示され、「Action」には操作した画面が表示されています。 レコーディング機能 以下のコマンドを実行することで、ブラウザが起動し操作することで、テストコード（操作）が記録されていきます。 記録された内容は、別ウィンドウで確認することができます。 npx playwright codegen また、ブラウザの上部にあるアイコンをクリックすることで、レコーディングの再開・停止や、要素の取得、 値の検証（以下、アサーション）も追加することができます。 そのためコーディングが苦手だったり、非エンジニアでも簡単なテストシナリオの作成ができます。 Playwrightでよく登場する（しそうな）関数 テストコードを自分で実装もしくは、レコーディングした際に登場するであろう関数を紹介していきます。 以降の「{}」は引数を表しています。 ページを開く page.goto({URL})： 引数に指定したURLを開きます 例） page.goto('<https://playwright.dev/>') 要素取得 page.getByRole({tag name etc…})： WAI-ARIAロールで定義されている heading などを指定し要素を取得します。 以下の例のように「h1」タグ＋その中にある値で要素を取得するような使い方ができます。 例） page.getByRole('heading', { name: 'Installation' }) ※ WAI-ARIA ロール page.locator({css name etc…})： 引数にCSS名を入力することで要素を検索できます。 またIDや、Xpathでも検索できます。 例1）IDを使用する page.locator('#'sample') 例2）Xpathを使用する page.locator("//h2[@class='sample']") 操作 page.getByRole({tag name etc…}) .click() ： .click() を記載することで、取得した要素をクリックします。 例） page.getByRole('heading', { name: 'Playwright enables reliable' }).click() page.locator({css name etc…}) .fill({input string}) ： .fill() を記載することで、取得したテキストボックス（エリア）に値を入力します。 例） page.getByRole('検索', { exact: true }).fill('playwright') アサーション Playwrightでは値のアサーションをするために、expectという関数を使用します。 expect関数にドットつなぎで使用します。 expectの引数には、 getByRole や、 locator で取得した要素を設定します。 以下のように設定可能です。 例1）直接引数に設定する expect(page.getByRole('heading', { name: 'Installation' })).toBeVisible() 例2）変数に格納してから設定する const element = page.getByRole('heading', { name: 'Installation' }) expect(element ).toBeVisible() expect({locator}).toBeVisible()： 要素が表示されているかアサーションします。 例は前述のように使用します。 expect({locator}).toContainText({title string})： 指定した要素に特定の文字列があるかアサーションします。 例） expect(page.getByRole('banner')).toContainText('Get started') expect(page).toHaveTitle({title string})： 検証対象のサイトのタイトルがあるか確認します。 例） expect(page).toHaveTitle('Sample Title') あとがき Playwrightを調査したところ、インストールの方法などは、公式からの情報（ドキュメント）も多いので、コーディング経験が少しでもあれば、比較的導入しやすいように感じました。 一方で、テストシナリオの実行はコマンドプロンプトを使用しなくてもUIツールでできますし、実行するためのテストシナリオ作成もレコーディング機能を使用することでブラウザ操作を記録できるので、簡単なテストケースなら非エンジニアでも作成ができそうです。 また、本ツールが無料ということもあり、コスト面でCI/CDに組み込みやすいと感じます。 以上、Playwrightの紹介ですが、本記事を読んで興味が出たら、お試しいただけたらと思います！ The post Playwrightはじめました ～E2Eテストを4Stepで自動化～ first appeared on Sqripts .

こんにちは。今回、Udemyにて「ゼロから始めるソフトウェアテスト技法」の講座を公開させていただきましたことをお知らせします。 本記事では、公開された講座がどのようなものなのか、ソフトウェアテストの近い未来をお伝えします。 講座の紹介 本講座の「ゼロから始めるソフトウェアテスト技法」では、ソフトウェアテスト技法の基礎から、よくある仕様を使ってソフトウェアテスト技法の実践的な適用方法を解説したものです。 本講座は、次のような方に見てもらいたい内容となっています。 ソフトウェアテスト未経験者 ソフトウェアテスト経験者 ソフトウェア開発者 エンジニアを目指す学生 このように、本講座は「 テストをこれから学ぼうという方 」から「 ある程度のテスト経験がある方 」までを対象としています。 ソフトウェアテスト技法の基本的な概念をしっかりと押さえたうえで、よくある仕様を使ってソフトウェアテストの考え方を解説します。 また、ソフトウェアテストの考え方で間違いやすいことを紹介しながら解説していますので、ある程度のテスト経験がある方にもお勧めです。 本講座は、次のような課題解決の一助になればと思い公開させていただきました。 思いつきでテストをしている 似たようなテストを繰り返している ソフトウェアテストのコストが非常に大きくなってしまう （費用対効果が得られない） ソフトウェアテストをしても不具合が見つからない （リリース後に不具合が見つかる） 開発やテストを学び始めの方は、「 思いつきでテストをしている 」や「 不具合を出さないためにひたすら動作チェック（テスト）している 」といったことが起こりがちです。 このようなソフトウェアテストには、「 どのようなテストをしたのか思い出せない 」であったり、「 テストをしても不具合が見つけられない （後日に他の人から指摘される）」といった問題が起こります。 気付かぬうちに似たようなテストを繰り返していれば、不具合を見つけにくくなります。 この場合、テストのコストに対してテストの効果が得られないため、漠然とした不安だけが残ります。 そこで、本講座で取り扱ったのが、ソフトウェアテスト技法です。 ソフトウェアテスト技法には、これまで不具合が起こりやすいと言われてきたノウハウが詰まっているため、正しく理解し使用することで、テストの効果を高めることができます。 講座の概要 本講座で取り扱う概要を紹介いたします。 1: ブラックボックステスト ソフトウェアテスト技法の導入として、ブラックボックステストとは何か、なぜソフトウェアテスト技法が必要なのかを解説します。 キーワード ： ブラックボックステスト、コスト、期限、全数テスト、不具合、入力、出力、テスト条件、要求、仕様、仕様の理解、テスト数の削減、同値分割法、境界値分析、デシジョンテーブル、状態遷移テスト、ペアワイズテスト、カバレッジ 2: 同値分割法、境界値分析 同値分割法、境界値分析の基礎を学び、その後は実際に仕様を読みながらテスト技法を適用していきます。また、テスト実施に使用できる代表値の考え方や、テスト数の考え方についても解説します。 キーワード ： 同値分割法、境界値分析、入力、出力、データの集合、同値クラス、同値クラス分割、有効同値クラス、無効同値クラス、代表値、境界、境界値、2値の境界値、3値の境界値、カバレッジ 3: デシジョンテーブルテスト 状態遷移テストの基礎を学び、その後は実際に仕様を読みながらテスト技法を適用していきます。また、状態遷移図や表の書き方やテストケースの考え方についても解説します。 キーワード ： 状態遷移テスト、状態、イベント、有効な遷移、無効な遷移、状態遷移図、状態遷移表、マトリクス、UML、N/A、カバレッジ、見える化、テストケース 4: 状態遷移テスト 状態遷移テストの基礎を学び、その後は実際に仕様を読みながらテスト技法を適用していきます。また、状態遷移図や表の書き方やテストケースの考え方についても解説します。 キーワード ： 状態遷移テスト、状態、イベント、有効な遷移、無効な遷移、状態遷移図、状態遷移表、マトリクス、UML、N/A、カバレッジ、見える化、テストケース 5: ペアワイズテスト ペアワイズテストの基礎を学び、その後は実際に仕様を読みながらテスト技法を適用していきます。また、ペアワイズテスト表の作り方やテストツール（ペアワイズ作成ツール）を使用方法についても解説します。 キーワード ： ペアワイズテスト、テスト削減、コスト、リスク、トレードオフ、ペアワイズカバレッジ、パラメータ、値、全網羅テスト、ランダムテスト、Pict、カバレッジ、ペアワイズテスト表 1.　講座で学べること ソフトウェアテスト技法には、ホワイトボックステストとブラックボックステストがあります。 ブラックボックステストは、入力と出力に着目し内部構造を意識しないことで、テスト条件を効率的に抽出します。システムの要求や仕様に基づき、システムが期待通りに動作するかどうかを確認します。 ブラックボックステストは、仕様に基づくテスト技法に分類されています。 ホワイトボックステストは、内部構造に焦点を当てており、コードカバレッジなどを意識して行われます。内部構造の品質を確認するのに非常に役立ちます。 ホワイトボックステストは、構造に基づくテスト技法に分類されています。 ホワイトボックステストの最も代表的なものは、制御フローテストです。基本情報技術者試験でも取り扱っています。 ホワイトボックステストの制御フローテストは、基本情報技術者試験でも取り扱っていることもあり、学生の頃から学ぶことが多いです。 一方のブラックボックステストは、なかなか馴染みがなく、私もソフトウェアテストに関心を持つようになってから知ることになりました。 また、ホワイトボックステストは内部構造の理解がなければ、テストの有効性を理解できませんが、ブラックボックステストはどのように利用するかというユーザーの理解があれば、テストの有効性を理解することができます。 ブラックボックステストは、これまでお話したようにあまり知られていません。 そのため、本講座では、 ソフトウェアテスト技法のブラックボックステスト に焦点を当てています。 ここからは、本講座で取り扱う内容について紹介します。 同値分割法、境界値分析 【説明_同値分割法】 同等に処理されると想定したデータの集合を振り分ける技法 【ポイント】 データの集合をどのように振り分けるかはテスト技術者の経験にも左右されるため、同値クラスの分け方や代表値の取り方を詳しく解説 【同値分割法の解説例】 【説明_境界値分析】 同値クラスが数値または順序付けできる値で構成される場合に使用できる 同値分割法を拡張した技法 【ポイント】 2値、3値境界値分析の強度の違いや仕様のどこに境界があるかを適切に理解できるよう詳しく解説 【境界値分析の解説例】 デシジョンテーブルテスト 【説明】 仕様の複雑な条件（入力）の組み合わせによって、発生するアクション（出力）を整理できる技法 【ポイント】 複雑な条件の組み合わせで必要なテスト数（ルール）の算出方法や、抜け漏れなく条件を組み合わせる方法を詳しく解説 【デシジョンテーブルテストの解説例】 状態遷移テスト 【説明】 入力が同じでも、状態ごとに変化する動作を抜け漏れなく視覚的に整理できる技法 【ポイント】 仕様から状態遷移図、状態遷移表の作り方やテストケースの作り方を詳しく解説 【状態遷移テストの解説例】 ペアワイズテスト 【説明】 テスト条件が多く全網羅テストを行うことが困難である場合において、一定の規則性を持って根拠あるテスト削減するテスト技法 【ポイント】 ペアワイズがもたらすコスト削減とリスク増加の考え方から、ペアワイズ表の作り方、ペアワイズテスト作成ツールの使い方までを詳しく解説 【ペアワイズテストの解説例】 ソフトウェアテストのこれから 1.ソフトウェアテスト業界の市場 ソフトウェアテスト業界の市場は、技術の進化やデジタル化の進展に伴い、急速に変化しています。今回は 情報通信機器の保有状況（世帯）とインターネットの利用状況（個人） という2点の変化を取り上げます。 情報通信機器の保有状況（世帯） 2020年における世帯の情報通信機器の保有状況は、「モバイル端末全体」（96.8％）の内数である「スマートフォン」は86.8％、「パソコン」は70.1％、「固定電話」は68.1％となっています。 情報通信白書令和3年版 情報通信機器の保有状況（世帯） 世帯におけるスマートフォンの保有割合（86.8％）とパソコンの保有割合（70.1%）と比較した場合、その差は16.7%であり、多くの世帯でパソコンよりもスマートフォンを保有するというデータが出ています。 2010年におけるスマートフォンの保有状況は9.7%となっており、2020年では大幅に増加（86.8%）していることがわかります。続いて、2010年におけるパソコンの保有状況は83.4%であり、2020年では70.1%と年々減少している傾向が見受けられます。 間近のデータでは、モバイル端末全体の保有状況「2020年：96.8%」、「2021年：97.3%」、「2022年：97.5%」とさらに増加しています。また、スマートフォンの保有状況は、「2020年：86.8%」、「2021年：88.6%」、「2022年：90.1%」とさらに増加しています。 報告書及び統計表一覧(世帯編)　令和4年報告書 https://www.soumu.go.jp/johotsusintokei/statistics/pdf/HR202200_001.pdf これらのデータから、情報通信機器はほとんどの世帯で保有されるようになっており、パソコンよりもスマートフォンを保有する世帯が多いということがわかりました。 次に、インターネット利用状況（個人）について取り上げます。 インターネットの利用状況（個人） 2020年のインターネット利用率（個人）は83.4％となっています。また、端末別のインターネット利用率は、「スマートフォン：68.3%」、「パソコン：50.4%」となっています。 インターネット利用率 端末の種類 情報通信白書令和3年版 インターネットの利用状況（個人）、インターネット利用端末の種類 https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r03/html/nd242120.html インターネット利用率の推移では、年ごとの増加は見受けられないものの、約8割程度を維持していることがわかります。また、スマートフォンでのインターネット利用が主流（68.3％）となり、次点のパソコン（50.4％）と比較しても17.9％上回っている状況です。 これらの状況から、今後もモバイル端末を中心としたソフトウェアの需要が増えると考えられます。それに伴い、ソフトウェアテスト市場もさらに拡大することが予測されます。 また、ここ数年は、新型コロナウイルス感染症の感染拡大に伴う感染症対策の一環として、ビジネスの変化が起こりました。 世界のEC市場の売上高は、2021年 542.0兆円（前年比19.5%増）と大きく増加しています。インターネットやモバイル端末が普及し続ける理由の一部とも言えるでしょう。 このような進化と変化に適応するために、ソフトウェアテスト業界でも、今後さらなる技術の進化が不可欠と言えます。 AGEST Academyでは、ICT活性化の一環として、eラーニングやUdemyの学習コンテンツ、メタバースオフィス（バーチャルオフィス）を利用した全国研修を行っています。 ゼロから始めるAIテスティング/今からでも遅くない AIテスティングの全てを学ぼう！ 30年以上の経験を持つ世界的なソフトウェアテストのエキスパートであるスチュアート・リード博士が、実際の演習をもとに解説します 　詳細はこちら　 Udemy 関連情報 ゼロから始めるソフトウェアテスト技法～基本から実践へ　現場で使えるテスト技法を学ぼう！～ なんとなくテストしていたり、テストに漠然とした不安を感じていませんか？少ないコストでより多くのバグを見つけるために、「正しく理解」すれば「強力な武器」になるソフトウェアテスト技法をソフトウェアテスト専門会社のプロが教えます。 　詳細はこちら　 Udemy 関連情報 2.ソフトウェアテスト技術とAI 本章では、ソフトウェアテスト技術とAIについて取り上げます。 AIの急速な普及に伴い、ソフトウェアテスト業界だけのことではありませんが、技術者の将来が懸念される声が挙がっています。例えば、生成AIでは「開発コードを作る」「テストを作る」「音楽を作る」「画像を作る」「翻訳できる」など、様々な用途があります。 筆者は、ChatGPTを検索エンジンと同じような意図で使う場合があります。対話ベースで知りたいことを深堀していけるという点で、調べごとが抽象的な場合に有効です。 非常に多くの用途で使用されるAIですが、今後どのようになっていくのでしょうか。 技術者が不要になる時代が来てしまうのかどうかという点を踏まえながらお伝えしていければと思います。 AIの動向 世界のAI市場規模（売上高）は、2022年には18兆7,148億円（前年比78.4％増）まで成長すると見込まれており、その後も2030年まで緩やかな加速度的成長が予測されています。 日本のAIシステム市場規模（支出額）は、2022年に3,883億6,700万円（前年比35.5％増）となっており、今後も成長を続け、2027年には1兆1,034億7,700万円まで拡大すると予測されています。 情報通信白書令和5年版 AIの動向 https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r05/html/nd249100.html これだけ勢いのあるAI市場ですので、ソフトウェアテストやソフトウェア開発に将来性があるかどうかを不安視する声も挙がっています。 次から生成AIを利用するにあたっての課題（生成AIを巡る議論）について取り上げます。 生成AIを巡る議論 要機密情報の取扱いや、個人情報保護、回答の正確性などの課題が指摘されています。 また、作成した偽画像・偽動画が、意図せず又は意図的に拡散し、他者の利益・権利の侵害や社会的混乱を引き起こしてしまうような負の側面も顕在化しつつあります。 例えば、次のようなものがあります。 2022年9月、日本でもプロンプト型画像生成AI「Stable Diffusion」を利用した静岡県の台風洪水デマ画像がSNS上に投稿され拡散し、社会的な問題となった 2023年1月、米・サンフランシスコで複数のアーティストが画像生成AI開発各社（Stability AI Ltd、Midjourney Inc及びDeviantArt Inc）を著作権侵害で訴えた 2022年8月、日本でもラディウス・ファイブ社が、元となるイラストを学習させることで、その特徴をとらえた画像を自動生成できるAI「mimic」をリリースした後、悪用を懸念する声が多く寄せられたことから1日で配信を停止したという事例がある AIサービスを提供した事業者側では利用にあたっての規約は定めているものの、その内容が利用者に着実に届くための努力や、これを踏まえた利用者自身の活用モラルの向上が必要な状況となっています。 生成AIの取扱い等については、各国や国際会議の場で検討・議論が始まっています。 日付 内容 2023年3月 2023年3月、イタリアのデータ保護当局は、データ主体に対して十分な情報提供がなされていないこと、機械学習のために個人データを大量に収集し処理することを正当化する法的根拠に疑義があること、ユーザーの年齢認証のメカニズムが欠如していることを踏まえ、ChatGPTを一時的に使用禁止とした 2023年4月 英国の情報コミッショナー事務局は、法的根拠を明確にする必要があること、データ管理者としての義務を持つこと、リスク評価をすることなど、個人データを処理する生成AIを開発したり、利用したりする際の8つの留意点を公表した 2023年4月 米国の国家電気通信情報管理庁（NTIA:National Telecommunications and Information Administration）が、AIの監査や評価、認証制度ついての意見募集を開始した 2023年5月 バイデン政権は、責任ある人工知能（AI）の研究開発への投資、民間企業が開発した生成AIの評価、連邦政府によるAI利用に関する指針の策定からなるAIに関する責任あるイノベーションの推進策を新たに発表し、企業がAI製品を展開・公開する前にその安全性を確認する責任がある旨を明確にした 2023年4月 EUでは、ChatGPTに関するプライバシー保護への懸念を検証するための作業部会を設定することを決定した 2023年4月 同年4月に群馬県高崎市で開催されたG7デジタル・技術大臣会合において「責任あるAIとAIガバナンスの推進」についても議論が行われ、本会合で採択された「G7デジタル・技術閣僚宣言」ではAIガバナンスのグローバルな相互運用性を促進等するためのアクションプラン、生成AIについて早急に議論の場を持つこと等が合意された 2023年5月 広島市で開催されたG7首脳会合でも、首脳レベルでAIガバナンスに関する国際的な議論とAIガバナンスの相互運用性の重要性等の認識が共有され、生成AIについて議論する広島AIプロセスを年内に創設すること等が合意された 情報通信白書令和5年版 生成AIを巡る議論 https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r05/html/nd131320.html これほどの議論が必要な理由が生成AIにはあります。 次のものは、利用者活用モラルに関連するものです。 学校（例：宿題や論文、テスト）でのChatGPT不正利用が懸念され、利用を禁止 ChatGPT生成の“存在しない判例”を使った米弁護士、約72万円の支払いを命じられる これらは、生成AIを提供した事業者側の意図を無視した利用といえます。 AIを利用することで技術の進化はあれど、技術の退化を招くべきではありません。 先ほど取り上げた”ソフトウェアテスト技術やソフトウェア開発に将来性があるかどうか”も同様の考えです。 AIの浸透は、技術を学ばなくてよい日が来るかもしれないというものでなく、AIを利用して技術を進化させていこう（生活を豊かにしていこう）という取り組みであるべきなのです。 インターネット、スマートフォンの普及に関しても、機械により生活が豊かになって労力が削られた部分はありますが、更なる発展のために技術を磨いたものでした。 近い未来でAIが完全に自律して何かを行うことが出来るようになったとしても、人は楽ができるというものでなく、その延長線上ないしは他の領域に時間を割けると考えるべきでしょう。今後も技術者は技術を学び、発展させていく必要があります。 AGESTAcademyでは、技術の発展や学びの一助となれば思い、Udemyコンテンツを公開しています。本章で取り上げたAIについてわかるコンテンツや、ソフトウェアテストの効果を上げるための考え方として、ソフトウェアテスト技法のブラックボックステストというもの解説しています。 一部動画の無料プレビューも可能ですので、アクセスいただければ幸いです。 ゼロから始めるAIテスティング/今からでも遅くない AIテスティングの全てを学ぼう！ 30年以上の経験を持つ世界的なソフトウェアテストのエキスパートであるスチュアート・リード博士が、実際の演習をもとに解説します 　詳細はこちら　 Udemy 関連情報 ゼロから始めるソフトウェアテスト技法～基本から実践へ　現場で使えるテスト技法を学ぼう！～ なんとなくテストしていたり、テストに漠然とした不安を感じていませんか？少ないコストでより多くのバグを見つけるために、「正しく理解」すれば「強力な武器」になるソフトウェアテスト技法をソフトウェアテスト専門会社のプロが教えます。 　詳細はこちら　 Udemy 関連情報 Udemyクーポン配布 「ゼロから始めるソフトウェアテスト技法～基本から実践へ　現場で使えるテスト技法を学ぼう！～」のUdemyコンテンツ公開に伴い、購入時に使用できるクーポンを配布します。 こちらは、定価19,800円の講座が1,980円になるクーポンです。 購入をお考えの方は、ぜひご利用ください。 なお、クーポンには有効期限がございます。 Udemy クーポン情報（19,800→1,980円） 割引クーポンの発行： 　　 https://www.udemy.com/course/agest-testing/?couponCode=F9EAB46C943A3071307C クーポンコード: F9EAB46C943A3071307C 有効期限: 2024/07/24～2024/08/23 The post 「ゼロから始めるソフトウェアテスト技法」を解説 first appeared on Sqripts .

この連載では、ITエンジニアにとって親和性が高く「スキルアップしたい」と思う方にとっては役に立つであろう知的生活について、いろいろなアクティビティやツール、仕事での活用方法などについてご紹介します。知的生産・知的生活の考え方や、「そもそも知的生活とはどうあるべきか」等の話ではなく、できるだけエンジニアの普段の生活や仕事に役立てられるテクニックよりの話をするつもりです。 前回 の記事では、技術書以外の本も積極的に読み、そこから得られた情報を知的生活の母艦に蓄積して活用すること等について解説しました。 【第3回】技術書以外の本を読み、仕事に活かすには この連載では、ITエンジニアにとって親和性が高く「スキルアップしたい」と思う方にとっては役に立つであろう知的生活について、いろいろなアクティビティやツール、仕事での活用方法などについてご紹介します。知的生産・知的生活の考え方や、「そもそも知的生活と... 　続きを読む　 Sqripts 関連記事｜Sqripts 今回は、仕事の中で得られる情報や作業の記録についてご説明します。 ＜ITエンジニアの仕事を楽しくする知的生活　記事一覧＞ ※クリックで開きます 【第1回】知的生活とはなにか？エンジニアにどう関係するのか ［全文公開中！］ 【第2回】知的生活の母艦としてのツールを選び、活用する 【第3回】技術書以外の本を読み、仕事に活かすには 【第4回】デイリーページを用いて日々の作業を記録する 仕事においても知的生活はできる 本連載のこれまでの記事は、どちらかといえばプライベートな時間における、読書やアイデアの蓄積などが中心でした。 しかし、知的生活はプライベートな時間だけのものではありません。平日日中の仕事をしている時間にも、知的生活は可能です。 むしろ 第一回 でご説明した知的生産、 アウトプットである「なにかあたらしい情報や価値」を出すために、いろいろなインプット＝情報をあつめて、自分の頭やいろいろな道具を使って処理＝思考をする これを生活の中に組み込むのが知的生活であるという考えに基づけば、生活の多くの割合を占める仕事中も知的生活の範囲に含まれるのは自然なことです。 【第1回】知的生活とはなにか？エンジニアにどう関係するのか みなさんは、知的生産や知的生活ということばを聞いたことはありますか？初めて聞いた、という方はもしかしたら「堅そう」とか「えらそう」といった印象を持つかもしれません。ところが、私はこの知的生産・知的生活は「ITエンジニア皆に知っておいてほしい」と考え... 　続きを読む　 Sqripts 関連記事｜Sqripts 仕事中に集める情報 とくにITエンジニアの皆さんは、プライベートな時間よりも仕事中のほうがたくさんの情報をインプットし、そして頭の中で処理をしているのではないでしょうか。 大量に流れてくる情報は何もしなければ失われてしまいますが、意識的に収集・整理することで自分の資産として活用できます。 私も昔 自分用の「仕事の教科書」をつくりながらはたらこう – テストウフ というブログ記事を書きましたが、ナレッジを残してあとから使えるようにする、というのはさまざまなことに共通する基本の考え方です。 こうした、情報の残し方に関してもいくつかのテクニックがあります。 たとえば、Today I Learned、略してTILと呼ばれる方法です。 Today I Learnedとは、その名の通り「今日学んだこと」を記録していくものです。 媒体は自由ですが、たとえばGitHubに「TIL」というリポジトリを作り、その中に「Python」や「Docker」「Git」など技術要素ごとのフォルダーを作ります。 そして、フォルダーの中に学んだことをMarkdown形式でメモしていく、という手法です。 単純に調べ物をして終わりではなく自分用にアウトプットすることで、記憶を定着されたり、また次以降「TILに書いていた」ということさえ覚えておけば検索をかけて素早く情報を引き出すこともできます。 TILは基本的に「自分用」で、かつ複雑な管理ルールもないため、気軽に始めるにはよいでしょう。 ただ、今回はこのTILのようなナレッジの蓄積とは少し異なる、日々を記録してふりかえりを行う「デイリーページによる作業ログ」についてもご紹介したいと思います。 デイリーページによる作業ログ TILなどにナレッジを残す場合には「残すべきものがあれば残す」という考え方になるでしょう。 一方ここでオススメしたいのは、「何を残すか」を考えるのではなく、とにかく記録を書きつけるという方法です。 大まかな流れは以下です。 朝仕事を始める際に、エディター等でその日の日付をタイトルにしたページ＝デイリーページを作成する デイリーページに、今日やることをリストアップする 仕事をしながら、デイリーページの中に行ったことや考えたこと、わからないことなどを時系列で書いていく 基本的にはこれだけ、です。もし職場のタスク管理ツールなどで「今日やること」を管理している場合は、デイリーページに転記してもいいですし、デイリーページには書かずにツール側で管理してもいいでしょう。とくに大事なのは「やったことや考えたことを時系列で記録する」という部分です。 なお、このやり方は知的生産に関連する「ユビキタス・キャプチャー」というもののエッセンスを取り入れたものです。 参考： 「全てを手帳に記録する」、ユビキタス・キャプチャーの実践 | Lifehacking.jp デイリーページのサンプル このあとデイリーページのメリットや作業ログの書き方を説明しますが、先にどのようなものかサンプルをお見せします。 普段使っているエディター（ここではvscode）で、日付を名前にもつファイルを作成します。私はMarkdownが好きなのですが、.txtや他の形式でも、慣れたものがあればそれでかまいません。 また、過去に所属していたチームの朝会で直近あった良いことを紹介しあうGood＆Newというコーナーがあったので、そのメモや今日やるタスクを列挙しています。このあたりのフォーマットや項目も、デイリーページを運用しながら少しずつカスタマイズしていくのが良いでしょう。 メインとなるのは、下部の「作業ログ」の項目です。 ここに、時刻とともにタスクのおおまかな見出し（例では「自動テストエラー対応」）を書き、そのしたにタスクを行う過程で考えたことや調べたこと、メモなどを並べていきます。 とくにエラー対応やトラブルシュートなどを行っている際には、独り言をつぶやくように書いていくと、頭の中を整理しながら思考することができるため便利です。 他にも、仕事中になにかを調べた場合はそこでヒントになったWebページのURLを記載したり、誰かからSlackやTeamsで質問された場合の内容や回答なども記録しておきます。 このように、仕事中の脳内をできるだけ余さず書きつけておくようなイメージで作業ログを書いていけるとベストです。 作業ログを書くメリット 上記の説明の中で、頭の中を整理できる、というメリットを挙げました。他にもいくつか考えられます。 たとえば、将来似たようなタスクや同じような問題に取り組む際のヒントになること、です。皆さんは仕事中に「あー、前似たような問題あって対処したなぁ・・・どうやったんだっけ・・・」と困ったことはないですか？私も数え切れないほどあります。 だいたいこのような場合は当時の記録が残っていなかったりして、記憶を頼りにGoogleや社内のファイルを検索して時間を溶かしていくことになります。 しかし、デイリーページに記録したということを覚えていれば、デイリーページの入ったフォルダーを検索すれば良いので目当ての情報にたどり着く手間が少なく済みます。 また、作業ログの形式で書くことによって、ナレッジの整理と実タスクの進行とを分離することができます。 仕事中の知見を社内のWikiやナレッジベースにまとめている方も多いでしょう。しかし、目の前のタスクを進めながらナレッジベースに情報を整理する、というのはなかなか大変です。私も経験があるのですが、なにかのタスクをしながら整理したナレッジというのは情報の順番が前後したり整理されていなかったりして、読みづらい状態になりがちです。 一方「あとでナレッジをまとめよう」と思って仕事に集中していると「あとで」が永遠に来なかったり、運良く時間が作れたとしても書くべき内容を忘れてしまっていたりと、こちらも効果的ではありません。 そこで作業ログの出番です。タスクをやっている最中は、構成や見栄えなどは考慮せずとにかく「記録・メモ」をする。そして、あとから記録・メモをもとにナレッジベースに整理する。 こうした二段構えで行うことで、業務効率と情報の内容を両立させることが可能です。 他にも細かなメリットとしては、日報や週報、ふりかえりの材料としても使える点などがあります。 作業ログを書く際のコツ これらのメリットを享受するためには、まずはとにかく作業ログを書くことが大事です。書き方やフォーマットなどは人によって好みがありますし、基本的にはどのような内容をどのように書くかは自由です。 しかし、自由な中でも一つだけ心がけるべき点があります。それは、 メモ・記録の手間をできるだけ少なくする ことです。 ここで言う手間とは、操作手順などのことだけではありません。頭で考えたり意思決定することも、手間に含まれます。たとえば、メモのルールや書く場所が複雑になって「ええと、この内容はどこに書こうかな・・・」とつど考える必要があるようではメモやログは続きません。 デイリーページに時系列で作業ログをとる一番のメリットは、この思考の手間を減らせることです。 今日日付のファイルの末尾に作業中のメモを追加していく、というシンプルなルールなので迷わずに済みます。 また、作業ログをとることを始めると必ずぶつかる壁が「何も書かない/書けない日がある」こと、です。会議が多い日であったり、作業に集中してログをとるのを忘れてしまった、などは起こり得ます。 この問題に対しては、 気にしない のが一番です。作業ログは毎日書くのが理想ですが、逆に毎日書かなければ意味がないもの、でもありません。 本記事冒頭の繰り返しになりますが、大切なのは アウトプットである「なにかあたらしい情報や価値」を出すために、いろいろなインプット＝情報をあつめて、自分の頭やいろいろな道具を使って処理＝思考をする という知的生産を、日常の中に組み込んでいくことです。 最初のうちは頻度が少なくても仕方がないですし、もし難しければ「エラー対応だけは作業ログをとる」や「朝9時から10時の集中タイムはログをとる」など、対象や時間を絞って始めるのも良いかもしれません。 少しずつでもよいので、インプット＝情報を集める習慣付けをしていくと、後々のアプトプットにつながっていきます。 まとめ 今回は主に仕事中の作業の記録についてご紹介しました。 学んだことや知見をトピックごとにまとめるのも良いですが、個人的にはデイリーページに作業中の考えや行ったことなどをメモすること＝作業ログをつけることがオススメです。情報を整理しながら蓄積するのは大変なので、作業ログとして蓄積することと、あとから作業ログを整理して情報として残すこととに分けて行うのが良いでしょう。 次回は蓄積した記録をもとにどのようにアウトプットし、仕事に活かしていくのかについて解説します。 ITエンジニアの仕事を楽しくする知的生活　連載一覧 【第1回】知的生活とはなにか？エンジニアにどう関係するのか ［全文公開中！］ 【第2回】知的生活の母艦としてのツールを選び、活用する 【第3回】技術書以外の本を読み、仕事に活かすには 【第4回】デイリーページを用いて日々の作業を記録する The post 【第4回】デイリーページを用いて日々の作業を記録する first appeared on Sqripts .

こんにちは、ツヨシーサーです。   「何から考えればよいか分からない。」 「考えが頭の中でぐるぐる回ってまとまらない。」 「表面的にしか考えられない。」 皆さんに思い当たる節はありませんか？お恥ずかしながら、最近もこんなことがありました。例えば、スマホ・アプリの新サービスを企画する際にアイデアを考えることが出来なかったり、課題の解決策を検討したものの網羅的に考えることが出来なかったりしたことがありました。そんな悩みを解決できるかもしれない書籍に出会いましたので、その本からエッセンスを抽出して皆さんにお伝えいたします。思考のメカニズムを深く理解することで、より効果的な判断や意思決定に役立てて頂ければ幸いです。 ［参考文献］ 『思考・論理・分析「正しく考え、正しく分かること」の理論と実践』 波頭 亮 著 思考のメカニズム 「思考」とは、『思考対象に関して何らかの意味合いを得るために、頭の中で”情報”（外から得られた情報）と”知識”（頭の中にすでに保有している情報）を加工すること』と定義されています。例えば、目の前に飛んできた小さな物体を観察した結果、身体の色は褐色で、大きな角があり、5cmほどの小さな生き物であるという”情報”から、自分の頭の中にある”知識”と照らし合わせてカブトムシであると判断することが「思考」ということになります。 その思考の核心は、『”情報”と”知識”を突き合わせて比べることであり、比べることにより、”同じ”部分と”違う”部分を認識し、その認識を基に判断や理解を得るプロセスが思考の本質』と整理されています。例えば、身体の色が褐色の昆虫がカブトムシであるかクワガタムシであるかを判断する際、角の有無といった情報を比べることで違いを見極めます。このように、『思考とは”情報”や”知識”を突き合わせて”同じ”か”違う”かを認識し、その認識を集積して理解や判断を得る行為』ということなのです。 思考ができない時は、理解や判断するために必要な”情報”や”知識”は足りているのか、”情報”と”知識”を突き合わせて比べて”同じ”と”違う”を認識できているのかということを疑ってみろということですよね。 思考のメカニズム（出典文書 ※1 （ P21）より筆者作成） 分かることは分けること 「思考」とは”同じ”と”違う”の認識作業になります。この認識の集積が思考のアウトプットとして、思考対象に関する理解や判断になるのです。この思考の仕組みとメカニズムは、『分かることとは分けること』とも表現されており、逆に言うと「分かっていないということは分けれていないこと」だと気付かされました。 例えば、身体の色は褐色で、大きな角があり、5cmほどの小さな生き物が目の前に現れた場合、その特徴を自分の持っているカブトムシの知識と照合します。これらの要素が一致した場合に、それはカブトムシであることが分かります。このように、『思考対象の”情報”と持っている”知識”を比べ、要素ごとに同じと違うに分けているのが思考作業』になります。そして、この思考作業を経て思考対象を構成する要素が”同じ”と”違う”に正しく分け尽くされた状態にたどり着くことが「分かる」ということなのですね。 分けるための3要件 それでは、思考対象の情報要素を正しく分け尽くすためには、どうすればよいのでしょうか？この本では以下の三つの要件を満たすことが必要であると書かれています。 ディメンジョンの統一 クライテリアの設定 MECEであること これらの3つの要件を満たして初めて、正しく分けることができ、正しく理解することが可能になるということですので、詳しく知りたいところですよね。 実体験として「ディメンジョンの統一」で困ったことはないのですが、「クライテリアの設定」では、スマホ・アプリの要件検討をしていた際に、機能面の切り口のみにフォーカスを当ててしまったため、体系的な検討が不足していたことがありました。また、「MECE」では、スマホ・アプリを利用するユーザの動線を検討していた際に、ユースケースの主要ケース以外の考慮漏れがあったため、設計の見直しを行ったという失敗談もありました。 ディメンジョンの統一 『ディメンジョンの統一とは、思考対象や要素を比較する際に、その抽象水準や次元を揃えること』を指します。これにより、適切かつ意味のある比較が可能になるということですね。 ディメンジョンが異なるもの同士を比べても適切な比較ではなく、正しく分けられたことにはならないので、注意しましょうね。 ディメンジョンの統一（出典文書 ※1 （P30）より筆者作成） クライテリアの設定 次に、『クライテリアとは、思考対象を分類する基準のこと』です。思考対象をどういう切り口で分けるのかを設定することは、その思考対象をどのように体系立てて分かるのかを決定付けることになるため、適切なクライテリアさえ設定できれば、思考対象を正しく理解し、判断することが可能になるということなのです。 前述のスマホ・アプリ要件検討の失敗時には、「クライテリアの設定」を活用して、機能面だけでなく、ユーザ目線での切り口も考慮して再検討を行ったところ、クライアントを説得することができました。 クライテリアの設定がしっくりこないときは、思考目的に合致したクライテリアになっているのかを確認してみてくださいね。 クライテリアの設定（出典文書 ※1 （P33）より筆者作成） MECEであること 最後に、『MECE（Mutually Exclusive Collectively Exhaustive）とは、モレがなくかつダブリがないこと』を指し、論理的な思考や分析において極めて有用なテクニックになります。MECEを用いることで、漏れや重複がない分類が可能になり、正確な分析や考察ができるというわけです。 前述のスマホ・アプリにおけるユーザ動線検討の失敗時には、「MECE」を活用し、ユースケースの90%を占める主要ケースだけでなく、レアケースの残りの10%も考慮しました。その結果、ユーザ動線の抜け・漏れがなくなり、設計レビューでレビューアからOKを頂くことにつなげることができました。 ただし、定性的な対象を分類する場合には数学的論理学的というより、MECE的な分類であれば十分みたいですよ。（MECEに分類するのが難しいケースって実際ありますよね…） MECE（出典文書 ※1 （P36）より筆者作成） さいごに 思考とは、情報と知識を突き合わせて比べ、”同じ”か”違う”かを識別するプロセスです。このプロセスを理解することで、より効果的な判断や理解が可能になります。また、「ディメンジョンの統一」や「クライテリアの設定」、「MECE」の活用により、思考の精度を高めることができます。ぜひ、日常生活やビジネスシーンでこれらの思考のテクニックを活用してみてください。 特に「クライテリアの設定」は私も普段から意識しているのですが、切り口のバリエーションをもっておかないと適切にクライテリアを設定できません。そのため、クライテリアの設定が上手な人、つまり、構造化思考で物事を考えるのが上手な人が皆さまの周りにもきっといらっしゃると思いますので、その人からノウハウを吸収するように心がけるのがお勧めです。 いかがでしたでしょうか？ すこしでも皆さまの気づきになれたのであれば幸いです。それではまた。 ※1　波頭 亮 (著),『思考・論理・分析「正しく考え、正しく分かること」の理論と実践』,産業能率大学出版，ISBN:978-4-382-05541-4 なお、本文中の『』は出展文書からの引用 The post 考えることを考える first appeared on Sqripts .