みなさんこんにちは。テストエンジニアのしば太郎、ひめりです。 ソフトウェアテストの勉強を日々行っていますが、参考書などに書かれた内容について、ほかの誰かに解説してほしいな、と思うことがあります。 同じ部署の先輩に相談したところ「生成AIを使ってみるのはどう？」というアドバイスがあり、初めて「生成AI」の存在を知りました。 生成AIとは AIという言葉は聞いたことがありましたが、生成AIという言葉は耳慣れない言葉でしたので、Webサイトで調べてみました。 生成AIとは、「ジェネレーティブAI（Generative AI）」とも呼ばれるAI（人工知能）の一種です。AIを用いてクリエイティブな成果物を生み出すことができるのが特徴的で、生成できるものは楽曲や画像、動画、プログラムのコード、文章など多岐にわたります。 生成AIはAIが自ら答えを探して学習する「ディープラーニング（深層学習）」を用いて構築された機械学習モデルであり、AIの中では比較的新しく生まれたモデルです。 「AIが人間のようにクリエイティブな成果物を生み出せる」点が従来のAIとは異なっており、画像生成AIの「Stable Diffusion」や、テキスト生成AIの「ChatGPT」などが一例として挙げられます。 AIsmiley「生成AI（ジェネレーティブAI）とは？使い方・種類・仕組み・活用事例を解説》」 そしてWebサイトを調べていくうちに、生成AIには画像生成、動画生成、音声生成、テキスト生成など、各分野に特化したAIがあり、各分野のAIも複数存在することが分かりました。 生成AIから文章だけではなく、画像や動画などが作り出せることに驚いたのと同時に、自分が利用したい目的を明確にし、適切な生成AIを選択する必要があることが分かりました。 続いては、実際に生成AIを使って勉強する前に、自分たちにはどの生成AIが適しているのかを決めていきたいと思います。 学習に使用する生成AIの決定 私たちは、画像や動画を作るのではなく、ソフトウェアテストを学ぶにあたって、生成AIに説明をしてもらいたいため、質問を入力するとAIが回答を生成してくれる「テキスト生成」の生成AIから選びたいと思います。 いくつかの生成AIを試し、理解しやすい言葉で説明してくれる「Gemini」に決めました。 学習開始 では、実際に生成AI「Gemini」を使って学習を進めてみます。 質問内容、使用してみての感想 1. 　質問をし、勉強のきっかけを作ってみる まずは「ソフトウェアテスト」という仕事について、イメージを掴めるような質問をしようと考えました。 回答はできるだけわかりやすくしてほしいことから、Geminiへの質問文に「わかりやすく」という文言を入れてみました。 質問：「ソフトウェアテストの目的と種類をわかりやすく教えてください。」 Geminiの回答はこちら。 「ソフトウェアテスト」という仕事の概要について要点を押さえ、すっきりとまとめてくれました。 多少情報の不足はありそうですが、概要を掴むには十分です。学習の入り口にちょうどよいと感じました。 2.　専門用語を使わずに解説してもらう 1.でだいぶわかりやすい回答をもらえたものの、初心者としては、「モジュール」や「コンポーネント」等、専門用語が多い点が気になります。 用語の意味は追々調べるとして、せっかく生成AI学習をしているので、Geminiを活用し、1.の回答をさらにわかりやすく、「専門用語を使わない」形で書き換えてもらうことにしました。 1.の質問に以下の追加質問をしてみます。 追加質問：「専門用語を使わないでもっとわかりやすくしてください。」 Geminiの回答はこちら。 質問文の「専門用語を使わないで」「もっとわかりやすく」を忠実に守り、「車」という誰でもイメージできる例を使って回答してくれました。 「モジュール」や「コンポーネント」という単語のイメージが着き難かったのですが、「エンジン」や「ブレーキ」を使った例えが非常にわかりやすく、ようやく「単体テスト」や「結合テスト」等テストの違いが理解できました。 難しい用語でつまずくことも、Webサイトで調べる時間を取られることもなく読み進められました。 3.　疑問点を質問してみる 初心者あるあるだと思うのですが、理解できない部分が増えて勉強が思うように進まなくなると、頭の中にどんどん疑問がたまっていきます。 「なんでこんなにたくさんのテスト技法があるのだろう？」 「たくさんのテスト技法があるけれど、自分でテスト設計するときが来たら、どうやって選べばいいのかな？」 疑問を解決したいのですが、Webサイトで調べても分かりやすく説明されている検索結果を見つけられないことが多くあります。誰かに教えてもらいたいと思っても、身の回りに気軽に質問できる人はなかなかいません。 そのような時、生成AIには遠慮する必要がないので、自分の聞きたいタイミングで質問することができます。 さっそくGeminiに聞いてみます。 質問1：「なぜこんなに多くのテスト技法があるのですか？」 Geminiの回答はこちら。 「ソフトウェアには様々な側面があり、それぞれの側面を効果的にテストするために、それぞれ異なる技法が必要だから」という端的にまとめられた回答を読み、テスト技法の1つ1つに異なる役割があるからこんなに多くのテスト技法があるのだな、と理解することができました。また、Geminiはまず結論を伝え、次に理由や具体例を提示してくれるので、とても理解しやすいと感じました。 続いて、もう1つ聞いてみます。 質問2：「何を基準にテスト技法を選べばいいのか分かりません。どのように選べばよいのでしょうか。」 Geminiの回答はこちら。 この回答から、テスト技法だけではなく、テスト対象の種類・規模・複雑性はどうなのか、テスト対象をどういった観点でテストしたいのか、そしてテストにかけられる時間・コスト・テストを実行する担当者のスキルはどのくらいあるのか、といったテスト対象の様子やテストを実行するリソースにも関係することが分かりました。そのため、テスト技法の学習段階では、それぞれのテスト技法の特徴をとらえておき、私たちがテスト設計できるようになったとき、今回学んだ内容を活かしたいと思います。 AI学習の利点と注意点 これまで試した内容から、生成AIを使って勉強するメリットを以下のようにまとめてみました。 【メリット】 生成AIを使うことで手軽に学習ができる。 生成AIを使うことで学習のハードルを下げることができる。 人に聞きづらいことも遠慮なく質問でき、納得いくまで再質問ができる。 メリットがある一方で、生成AIを利用する際、気を付けなければいけない点があります。 生成AIは事実とは異なる情報をもっともらしく回答することがあり、このような現象を「ハルシネーション」と言うそうです。 そのため、初心者には生成AIの回答が合っているかどうかという判断が難しく、生成AIだけでの学習は誤った理解につながる可能性があるため、やはり参考書などのテキストとの併用が必要と感じました。 最後に 「ほかの誰かに解説してほしいな」から始めた今回の試みでしたが、私たちの目的は達成できたと思います。 生成AIを使った学習方法は、手軽に利用できる点、情報が掲載されているサイトを自分で探す必要がない点、生成された回答では理解が不十分である場合、納得できるまで繰り返し質問できる点において、大きなメリットを感じました。 また、今まで理解が難しかったテストの種類や技法が理解できたことで、自信に繋がりました。 生成AIを使うことで、自分ひとりでは理解するまでに時間がかかっていた内容を今までより効率よく学習できることから、これからも日々努力をつづけて、一人前のソフトウェアテスト実施者を目指していきたいです。 The post ソフトウェアテスト初心者が生成AIを使って勉強してみた first appeared on Sqripts .

みなさんはブラウザのパスワード保管機能（ブラウザパスワードマネージャー）を使っていますか？ パスワードを記憶し、自動で入力してくれるのはとても便利ですし、入力の手間も省けるので使用している方も多いのではないでしょうか。 では、ブラウザのパスワード保管機能の危険性について考えたことはあるでしょうか？ 結論から言うと、ブラウザのパスワード保管機能は危険があると言えます。ブラウザは 利便性を追求するものであり、安全性は二の次であること が最大の理由なのですが、今回はより具体的にブラウザのパスワード保管機能の危険性を考えていきたいと思います。 ※今回の記事では「ブラウザパスワードマネージャー」を「ブラウザのパスワード保管機能」と表記しています。 ブラウザのパスワード保管機能が危険と言われる3つの理由 ここでは具体的に危険と言われるポイントについて紹介をしていきたいと思います。 1. 暗号化による保護が十分でない可能性 1つ目は暗号化による保護が十分でない可能性があることです。 一部のブラウザにおいてはエンドtoエンドでの暗号化がなされないため、パスワードが平文となる瞬間・場所が存在する可能性があります。（注：必ずしも常に発生するわけではない） 参考 エンドツーエンド暗号化 （ E2EE 、 E2E暗号化 ）は、通信経路の末端でメッセージの暗号化・復号を行うことで、通信経路上の第三者からのメッセージの盗聴・改ざんを防ぐ通信方式である。E2EEを用いた通信では、メッセージは意図した受信者だけが復号できるよう暗号化してから転送されるため、通信が傍受されたり、通信を中継するサーバが危殆化（きたいか）したりした場合でも、通信の機密性が確保される。 Wikipedia「エンドツーエンド暗号化」 より引用 また、ブラウザのアカウントログイン時はパスワードの復号が可能です。これ自体は悪いことではありませんが、ほとんどの人が常時ブラウザにログインしている状態であることを考えると、その間ブラウザに保存されているパスワードは暗号化による保護がされていないことになります。 この点は 前回 の記事でも解説していますのでご参照ください。 【第2回】パスワードマネージャーの選定時のポイント 第1回目の記事【パスワードの基礎と主な管理手法について】で、パスワード管理手法のうち、業務効率化の観点及び安全性向上の観点からパスワードマネージャーによる管理が有効な手段であることをご紹介しましたが、今回は具体的な選定のポイントについてご紹介をして... 　続きを読む　 Sqripts 関連記事｜Sqripts 2. ブラウザ自体の脆弱性 2つ目はブラウザ自体に脆弱性が存在する可能性があることです。 ブラウザが利便性を追求するものであるということは何度も言及していますが、便利であるが故にセキュリティ面では脆弱性を孕むことが多々あります。 例えば、 JVN iPedia で「Google Chrome」と検索すると、執筆時点（2024年5月）で 4,215件 の脆弱性情報を確認することができました。全てがパスワード管理に関係するものではありませんが、利便性を追求するブラウザを使用することで、日々多くの脆弱性と隣り合わせているということを考える上では参考になる数値です。 ブラウザのパスワード保管機能を使用するということは、このような脆弱性を抱えるツールでパスワードという機微情報を保管しているということです。 このことの危険性を知る必要があることは言うまでもありません。 3. ハッカーにとってブラウザは人気のターゲット 3つ目は、ブラウザがハッカーに人気のターゲットであることです。 ここではサイバー攻撃をする側の目線に立って考えてみたいと思います。 もし、あなたが「悪意あるハッカー」だったとして、 世界中のほとんどの人が利用している 多くの脆弱性が存在している 価値のある情報が沢山保存されている そんなものがあったら、真っ先に狙ってみたくなりませんか？ この「狙いたくなるターゲット」の1つがブラウザです。 パスワードをはじめクレジットカード等の機微情報も保管されているブラウザは、悪意あるハッカーにとっては情報の宝庫と言えます。実際に、サイバー攻撃でブラウザが標的となるケースは多数報告されています。 身近なところでは、マルウェアの「Emotet」は端末に感染後、ブラウザに保存されているパスワード等を奪取することが知られています。 Emotet対策｜警察庁Webサイト Emotetは、主にメールの添付ファイルを感染経路としたマルウェア（不正プログラム）です。過去にやり取りしたメールへの返信を装ったメールを送信し、添付ファイルの開封を促します。感染するとパソコンからメールアカウント、パスワード、メール本文等の情報を窃取... 　詳細はこちら　 警察庁 関連情報 ブラウザのパスワード保管機能に対する最新の動向 ブラウザのパスワード保管機能についてセキュリティ面での危険があることについて解説してきましたが、世界的な潮流はどうなっているのでしょうか。 ここでは著名なセキュリティ関連機関等の見解をご紹介したいと思います。 NIST（米国） NIST （National Institute of Standards and Technology）とは、日本語では「米国国立標準技術研究所」と呼ばれ、米国の科学技術分野における計測と標準に関する研究が行われている機関です。 世界的にセキュリティ対策の標準となることが多いNISTのドキュメントですが、パスワード関連では「Digital Identity Guidelines(SP 800-63)」が参考になります。 NIST SP 800-63 Digital Identity Guidelines NIST Special Publication 800-63 Digital Identity Guidelines 　詳細はこちら　 pages.nist.gov 関連情報 パスワード管理のベストプラクティスが記載されており、最近ではパスワードの定期変更は不要であると発表をしたことでも注目を集めたドキュメントですが、ブラウザのパスワード保管機能について利用の是非は明言されていません。 ただし、パスワードマネージャー（※ 第2回で解説している有償のパスワードマネージャーのこと ）を利用することの有効性はFAQ内で言及があり、パスワードマネージャー利用時のチェックポイントとして、主に以下のような点が挙げられています。 攻撃から保護するために十分な長さと複雑性のあるマスターパスワードを利用することができ、盗難されないよう保護する。 パスワードマネージャーで保管する各サービスに対して、一意で複雑なパスワードを生成できる。 マスターパスワードの復元が可能なツールは避ける。アカウント回復ツールによってマスターパスワードが漏洩すると、全てのパスワードが漏洩する可能性がある。 多要素認証による保護メカニズムがあるパスワードマネージャーである。 ※上記は日本語への翻訳を行った上での要約です。正確な情報は原文にてご確認ください。 （ https://pages.nist.gov/800-63-FAQ/#q-b12 ） NISC（日本） 内閣サイバーセキュリティセンター・ NISC （National center of Incident readiness and Strategy for Cybersecurity）とは、日本政府の情報セキュリティ政策を遂行する機関です。 内閣官房に設置されている日本のセキュリティ機関です。パスワード管理関連では、NISCから発行されている「インターネットの安全・安心ハンドブック Ver5.00」にブラウザのパスワード保管機能に関する言及があり、 利用は非推奨 となっています。 出典： インターネットの安全・安心ハンドブック Ver5.00 全体版（115ページ）より インターネットの安全・安心ハンドブック - NISC 内閣サイバーセキュリティセンター（NISC）が制作した「インターネットの安全・安心ハンドブック」様々なサイバー攻撃とその対応策を、イラスト入りで分かりやすく解説しています。無料で自由にダウンロードでき、学校やご家庭、会社内での情報セキュリティ研修の教... 　詳細はこちら　 security-portal.nisc.go.jp 関連情報 非推奨とする理由としては 「 パスワードなどの自動入力は便利ですが、仕事場などであなたがパソコンをロックしないまま席を離れると、他人が各種サービスにログインし放題になります ※ 」 という言及がなされていることから、上記の「 1. 暗号化による保護が十分でない可能性 」でも言及した点と似たものと言えるでしょう（＝ブラウザにログインしている間、パスワードは暗号化されていない） ※ インターネットの安全・安心ハンドブック Ver5.00 中小組織版（11ページ） セキュリティベンダーや専門家（各国） Webで「ブラウザパスワードマネージャー　危険性」などで検索すると、数多くのサイトや記事でブラウザのパスワード保管機能が非推奨として言及されております。 これらの多くが、「ブラウザのパスワード保管機能が危険と言われる理由」でご紹介した要素を理由に、ブラウザのパスワード保管機能の利用を非推奨としています。 それでもブラウザのパスワード保管機能を使う場合 ここまでブラウザのパスワード保管機能の危険性について解説してきましたが、決して「ブラウザパスワードマネージャー ＝ 悪」というわけではありません。 押さえるべきポイントを理解して利用すれば、ブラウザのパスワード保管機能はコストが発生しないというメリットを持つ有効なツールにもなり得ます。 ここでは、ブラウザのパスワード保管機能を使う場合のポイントを紹介します。 セキュリティリテラシーを持つこと ブラウザのパスワード保管機能の危険性を理解できること 。これはブラウザのパスワード保管機能を使う場合の必須事項であり、第一歩です。言い換えれば、「なんとなく便利だから」というだけの状態 ＝ これまで解説してきたような基本的な知識を持たない状態では、ブラウザのパスワード保管機能を利用すべきではありません。 ブラウザアカウントへのアクセス管理 ブラウザアカウントへのアクセス管理を適切に行うこと が重要です。特に二要素認証は必須と言えるでしょう。法人利用の場合には、グループポリシー等で二要素認証を一括で強制的に有効するなどの対策が考えられます。個人利用の場合も設定から二要素認証を有効にしておきましょう。 また、パスワード保管をする全てのブラウザアカウントで、例外なく二要素認証は有効にすべきです。 管理の責任は個人に依存することを理解する 「ブラウザのパスワード保管機能を利用する」＝「パスワード管理を個人に委ねる」ことを意味します。ここで注意が必要なのは、組織的にブラウザのパスワード保管機能を利用する場合です。 以下が考え方のポイントとなります。 個人でパスワードマネージャーを利用する場合 パスワード管理をする人＝個人 パスワード管理の責任＝個人 →管理する人と責任の所在が一致するため、自分の責任で管理するという極めて基本的な考え方となります。 組織でパスワードマネージャーを利用する場合 パスワード管理をする人＝個人 パスワード管理の責任＝組織 →管理する人と責任の所在が一致しません。そのため、パスワードを管理をする人のミスや不注意の責任を組織が負うことになり、リスクが発生します。 まとめ ブラウザのパスワード保管機能は便利ではありますが、セキュリティの観点からは危険が存在します。 具体的には、不十分な暗号化、多くの脆弱性といった危険が挙げられます。 セキュリティ関連機関等の見解では、ブラウザのパスワード保管機能の利用は非推奨の傾向があります。 政府、専門機関からブラウザのパスワード保管機能に対するいくつかの考え方、指針が出ているので参考にすることができます。 どうしてもブラウザのパスワード保管機能を利用する際は、危険があることを理解した上で、ポイントを押さえて利用しましょう。 ブラウザのパスワード保管機能を組織的に利用するにはリスクがあるため、リスクの理解が必要です。 シリーズ「組織におけるパスワード管理」記事一覧 【第1回】パスワードの基礎と主な管理手法について 【第2回】パスワードマネージャーの選定時のポイント 【第3回】ブラウザのパスワード保管機能を使う危険性 The post 【第3回】ブラウザのパスワード保管機能を使う危険性 first appeared on Sqripts .

この連載では、ITエンジニアにとって親和性が高く「スキルアップしたい」と思う方にとっては役に立つであろう知的生活について、いろいろなアクティビティやツール、仕事での活用方法などについてご紹介します。知的生産・知的生活の考え方や、「そもそも知的生活とはどうあるべきか」等の話ではなく、できるだけエンジニアの普段の生活や仕事に役立てられるテクニックよりの話をするつもりです。 前回 の記事では、知的生活の母艦となるツールの選び方や、新しい価値を生み出すための材料として情報を蓄積すること等について解説しました。 【第2回】知的生活の母艦としてのツールを選び、活用する この連載では、ITエンジニアにとって親和性が高く「スキルアップしたい」と思う方にとっては役に立つであろう知的生活について、いろいろなアクティビティやツール、仕事での活用方法などについてご紹介します。知的生産・知的生活の考え方や、「そもそも知的生活と... 　続きを読む　 Sqripts 関連記事｜Sqripts 今回は情報をインプットする代表的な手段である読書について、とくに技術書以外の書籍を読んで情報として蓄積する際のやり方や、読んだ本を活かす際の考え方についてご説明します。 ＜ITエンジニアの仕事を楽しくする知的生活　記事一覧＞ ※クリックで開きます 【第1回】知的生活とはなにか？エンジニアにどう関係するのか ［全文公開中！］ 【第2回】知的生活の母艦としてのツールを選び、活用する 技術書以外を積極的に読み、幅を広げる ITエンジニアとして仕事をしていると、プログラミングやソフトウェア開発、そして品質やテストなど、技術書を読む機会は多いです。日々の業務に直接関わるジャンルであり、結果として自分のスキルやキャリアに活かしやすいというメリットがあるでしょう。 しかし、技術書以外の書籍を読むことも、とくに知的生活という点ではとてもオススメです。 世の中で活躍するエンジニアの方は、もちろん技術書もたくさん読んでインプットしていますが、そのほかにも – ピープルマネジメント・プロジェクトマネジメント – 組織開発 – 教育心理学 – 資料作成 – 営業・マーケティング など多様なジャンルについて学んでいます。身の回りのエンジニアに対して「そのようなことまで詳しいんですか！」と驚いた経験はありませんか？ こうした、即効性はないかもしれないけれども自分の知識の幅を広げてくれるような本は、とくに若いうちに読み漁っておくとのちのち効果を発揮します。 以下のようなつぶやきをしたことがありますが、何人かの方から「わかる」「やってた」という反応をいただきました。みなさん優秀な方ばかりでしたので、実際に効果がある方法のように思います。 たまにおじさんらしいことでも言っておくと、 20代、月収の10%本買っておけば あとでブーストになると思います — Yoshiki Ito/伊藤由貴 (@yoshikiito) May 3, 2024 読書で得た情報を蓄積しておく 業務に直結する技術書以外を読んで知識を蓄えておくことが大事です、という主張に関しては、ほとんどの方が賛同してくださるでしょう。 では、その「蓄える」のは、どこにどうやって行うのか。頭で記憶しておくだけでは、せっかくのインプットが揮発してしまいます。 そこで、前回もご紹介した知的生活の母艦となるツールの出番です。 知的生活を楽しんでいる方には読書家も多く、ほぼ皆さんが読書メモの形で書籍からインプットした内容をまとめています。 たとえば、私がまとめている読書メモの例をご紹介します。 読書メモのポイントはいくつかありますが、主な内容としては以下を記録しておくとよいでしょう。 – 買おう、読もうと思ったきっかけ – いつ読み始めたか – 書籍の中の気になる・グッときたフレーズ – 書籍を読んでいて考えたこと、疑問、感じたことなど 必須ではありませんが、書影の画像なども添付しておくとツール上で探しやすくなりますし、「きれいなメモをしている感」も得られるのでオススメです。 また他にも、単純に書籍のなかから文章を抜き書きするだけではなく、自分の感じたことや疑問なども書いておきましょう。これは詳細に書ければベストですが、読書をしながらメモをたくさん書いているとリズムを損なう場合もあります。そういったときは「なるほど！」や「わかる！」などの簡単なものでもいいので感情を添えておくと、あとで思い出しやすくなります。 大切なのは、ツールにメモをすることによって適切に忘れることです。 「あの本のこのページにこんな文章が書いてあった」とすべて記憶しておくのは大変です。そうではなく、「たしかこの本に書いてあったはず」というレベルで記憶しておいて、実際に思い出すときにはツールに検索をかけられる状態にしておく。これがポイントです。 たとえば「心理的安全性が大事、とどこかの本で読んだ気がするぞ」と覚えていれば、検索をかけて上記の読書メモにたどり着くことができます。同時に、同じ心理的安全性という単語が出てくる他の情報も表示されるので、情報同士を組み合わせて新しい価値を生み出すことが行いやすくなります。 「利他的な読書」を仕事に活かす 技術書以外の本を、なるべく幅広く読み、そして知的生活の母艦に蓄積する。 「理屈はわかるけど大変そう」と感じられるかもしれません。そして、本連載は「ITエンジニアの仕事を楽しくする知的生活」です。単に苦しいだけの読書では継続できません。 読書はそれ自体ももちろん楽しいものですが、仕事に活かせたとき、役に立ったという実感を得られたときも楽しみを感じるポイントです。 自分が仕事をしていて困ったことやわからなかったことを解決するために、本を読み実践する。これも良いことですが、ここではあえて「利他的な読書」という楽しみ方を提案したいです。 利他的な読書というのは私の造語で、他人のために読書をする、という意味です。大きく二通りのやり方があります。 ひとつは、職場の同僚がなにか困っている際に、解決のヒントになりそうな情報を得るために本を読み共有する方法です。課題ありきで本を選ぶやり方です。 このやり方であれば、自分の興味の範囲を越えたジャンルの書籍を読むきっかけにもなるので、幅広い知識をインプットすることにもつながります。 もうひとつは、普段からさまざまな本を読んでおいて、同僚が困っているときに読書メモからサッと「こうするといいよ」「この本が参考になるよ」と取りだすやり方です。 こちらの方法も幅広いインプットにつながりますし、さらに「情報をサッと取り出せるようにしておく」ための努力に自然につながるというメリットがあります。 いずれの方法も、自分のためだけに読書をする場合と比べて幅が広がりますし、なによりひとの役に立てます。もちろん、手段や書籍の押し付けにならないよう注意が必要です。 しかし、適切な情報提供ができれば相手から感謝されますし、それによって次のインプットを行うモチベーションにつながっていきます。こうした良いサイクルを作って回していくことが、ITエンジニアの仕事を楽しむことにつながる、と考えます。 皆さんも、普段の読書で得た情報を蓄積し、それを自分や他人のために役立ててみてください。 ITエンジニアの仕事を楽しくする知的生活　連載一覧 【第1回】知的生活とはなにか？エンジニアにどう関係するのか ［全文公開中！］ 【第2回】知的生活の母艦としてのツールを選び、活用する The post 【第3回】技術書以外の本を読み、仕事に活かすには first appeared on Sqripts .

ソフトウェア品質の向上に向けた活動は終わりの無い、息の長い取り組みです。 活動の成果を出すためには開発現場任せにせず、計画的・組織的なプロセス改善を行う取り組みが王道です。 本書では、そのような取り組みに活用できるテストプロセス改善モデルの一つ、「TPI NEXT」の概要をご紹介します。 テストプロセス改善の課題 テストプロセス改善には下記に示すような課題があり、必要性は感じていながらもなかなか思うように進まないのが実情です。 コスト、リソース、スケジュールの制約のため、テスト実施が優先されてプロセス改善まで手が回らない ステークホルダーを巻き込んだ取り組みが必要であり、利害関係者の意見調整に労力と時間がかかる 現状の課題対応優先順位やプロセス成熟度レベルの把握が難しく、改善目標の設定が難しい テストプロセスの課題解決によって実現される品質向上効果が測定しにくい 又、品質向上にはテストプロセスだけではなく、開発プロセスと連携した取り組みも重要です。 プロジェクトの限られた期間と工数の中で、タスクの優先順位付けとそれに応じたリソース配分を適切に行うことは、熟練した経験者でも大変であり、テストプロセス改善のハードルを高くしています。 テストプロセス改善への取り組み これらの課題を解決していくためには、ソフトウェア開発・保守・運用をささえる三要素である「人」、「プロセス」、「技術」をバランス良く改善することが成功の秘訣です。 テストプロセス改善も一般的な業務プロセス改善と同じく、上記三要素に着目しながら次の順番で進めていきます。 現状の課題を整理・分析し、根本課題を把握する 根本課題を解決する施策案を検討する 最終目標を設定し、達成までのステップとマイルストーンを策定する ステップ毎の具体的な取り組み内容を決める リソースとスケジュールをアサインして実行する これら一連の取り組みを効率的に進めていくためには、実績に裏打ちされた方法論、進め方のガイドライン、改善状況を測定するための評価指標等があると、効率的に進めることができます。 TPI NEXT はこのようなニーズを満たすツールの一つとして活用することができます。 TPI NEXT とは TPI NEXT は Capgemini グループである Sogeti 社が、欧米 1,000 社近くのコンサルティング結果をまとめたテストプロセス改善のモデルです。 1998年に発表した TPI（Test Process Improvement） の実践事例に基づく改訂版として、2009 年に TPI NEXT が発表されました。 テストプロセスの成熟度を多角的な視点から可視化するためのツール、改善活動を達成するためのコツや提案が、実践を通じて蓄積されたノウハウを盛り込んで体系的にまとめられた改善モデルです。 ツールとしての TPI NEXT の概要 全体像と構成要素 TPI NEXT の全体像と構成要素を（図1）に示します。 図1：TPI NEXT 全体像と構成要素 テストプロセスの成熟度を測定、可視化する 「テスト成熟度マトリクス」を中心として、下記の各要素で構成されています。 テストプロセスを 16の切り口で分類した 「キーエリア」 各「キーエリア」毎に、下記の 4段階で定義された 「成熟度レベル」 -Level0：初期レベル ⇒ テスト活動の構成要素が充分に文書化されていないアドホックな活動 -Level1：コントロールレベル ⇒ 行うべきことに取り組み、テスト対象の品質を十分に把握できるレベル -Level2：効率化レベル ⇒ テスト活動を適切に実施するように方法を改善するレベル -Level3：最適化レベル ⇒ 刻々と変化する状況に絶えず順応するレベル 「成熟度レベル」を定義・測定するための「チェックポイント」 「チェックポイント」達成のためのヒントと提案を提示する、「改善提案」、及び 「キーエリア達成のコツ」 複数の「チェックポイント」をグループ化し、効率的な改善活動の順序を提案する 「クラスタ」 テスト成熟度マトリクスの見方 「テスト成熟度マトリクス」 のイメージを（図2）に示します。 図2：テスト成熟度マトリクスのイメージ 縦軸方向に SR（ S takeholder R elation）、TM（ T est M anagement）、TP（ T est P rofession）の3カテゴリに分類された 16 の「キーエリア」が配置されています。 横軸方向には「初期レベル」～「最適化レベル」の 4つの「成熟度レベル」が並び、各レベルはキーエリアに応じて更に 2～4 レベルの「チェックポイント」に細分化されています。 各「チェックポイント」の達成条件は別途チェックシート形式で提供されており、そのチェック項目に “Yes”、”No”、”N/A” で回答していくことによって、テスト成熟度マトリクスの各「チェックポイント」が “条件を満たす（グリーン）”／”条件を満たさない（オレンジ）” で色分けされます。 テスト成熟度マトリクスによる評価 チェックポイント達成状況の評価が一通り終わったら、キーエリア毎の成熟度が評価できます。 ある成熟度レベルの全チェックポイントが条件を満たしたとき、そのキーエリアが当該成熟度であると評価します。 図2の例であれば、「03：テスト戦略」、「05：コミュニケーション」、「06：報告」、「10：欠陥管理」、「12：手法の実践」～「15：テストツール」、の各キーエリアが「コントロールレベル」にあると評価します。 又、「16：テスト環境」のキーエリアは「効率化レベル」にあります。 評価結果に基づくアクション策定 この成熟度マトリクスは、現状テストプロセスの成熟度を可視化しているとともに、次に実行すべきアクションを提案しています。 基本的な改善のアプローチ方法として、キーエリア毎に成熟度の低い（マトリクスの左側にある）未達成のチェックポイントを達成するように対策を検討します。 TPI NEXT は対策検討のためのヒントとして、チェックポイント毎に「改善提案」、及び「キーエリア達成のコツ」を提供しており、これらの情報を参考にアクションプランを策定することができます。 又、成熟度マトリクスには「クラスタ」という概念が導入されており、各キーエリア間でバランス良く改善対策を検討できるようになっています。 図2の例では、各チェックポイントに “A” ～ “M” 迄のアルファベットが付番されており、同じアルファベットが付番されたチェックポイントを一つの「クラスタ」と呼びます。 クラスタ単位でアルファベットが若い順番（A ⇒ M の順番）にチェックポイントを達成していくことによって、キーエリア横断的な視点で優先順位を考慮したプロセス改善が図れるという考え方です。 図2 の場合であれば例えば、 「”A” のクラスタは全て条件を満足しているので、 “B” ～ “E” のクラスタにある未達成のチェックポイントを対策することで、テストプロセス全体の成熟度を “コントロールレベル” に底上げしよう」という目標設定が考えられます。 このクラスタは TPI NEXT のツールでデフォルトとして提案されている他、ビジネスニーズに合わせて優先度をカスタマイズすることができるので、テスト組織のニーズや戦略に合わせてテスト成熟度マトリクスを活用することができます。 テストプロセス改善への TPI NEXT の活用例 ここまで、TPI NEXT のツールとしての側面を中心にご紹介してきました。 TPI NEXT 自体はテストプロセス改善モデルですので、企業毎、組織毎の改善活動の中に組み込んで上手に活用することが品質向上のキーとなります。 本章では活用例として、ソフトウェア開発企業の 「品質管理組織」から委託を受けたTPI NEXT のコンサルタントが、同企業のステークホルダーを巻き込んで現状プロセスの成熟度診断を行うケースを紹介します。 尚、TPI NEXT のモデルに基づく改善は本来、現場主導のボトムアップ アプローチであり、コンサルタントによるアセスメントは必要ありませんが、プロセス改善のリソース不足対策や、第三者視点での現状評価・改善のアイディア導入等の目的で外部コンサルタントの支援を得ることもあります。 登場人物と役割分担は下記を想定しています。 コンサルタント：全体プロセスリード、TPI NEXT ツールの準備、及びワークショップのファシリテーション 品質管理組織：自社のテストプロセス改善をミッションとしたタスクフォースのリード ステークホルダー：同企業の開発組織や運用組織の責任者・リーダー 全体の流れを（図3）に示します。 図3：TPI NEXT を活用した成熟度診断例 (1) TPI NEXT 概要説明 コンサルタントは、品質管理組織に対して全体の進め方とTPI NEXT 概要を説明します。 品質管理組織は、TPI NEXT のチェックシートを用いて自己診断を行います。 TPI NEXT コンサルタントはチェックシートの質問内容の趣旨、判断基準の考え方、用語の意味等について、品質管理組織の自己診断をサポートします。 自己診断は各チェックポイントの Y/N 判定だけでなく、判定理由を記入するとともに、課題の現状を示すエビデンス資料（テスト計画書、進捗管理表、欠陥管理表、課題管理表、品質分析資料等）を入手して現状を客観的、定量的に把握できるようにします。 (2) ステークホルダーへのヒアリング コンサルタントは品質管理組織と協力して、各ステークホルダーに個別にヒアリングを行います。 品質管理組織が自己診断で判断できなかった項目の他、各ステークホルダー間での認識の齟齬、組織間の利害関係、品質戦略の理解浸透状況 等の課題についてもヒアリングを行います。 ヒアリングはTPI NEXT のチェックシート 1問1答形式ではなく、各チェックポイントの趣旨を現状課題に置き換えて、ステークホルダーに身近な課題として回答を引き出せるように準備します。 必要に応じて開発委託先や運用委託先企業のリーダーにもヒアリングを行います。 コンサルタントは品質管理組織と協力して、ヒアリング結果を基に「TPI NEXT チェックシート」に記入します。 (3) 改善施策検討ワークショップ 事前準備として、コンサルタントは「TPI NEXT チェックシート」、「テスト成熟度マトリクス」を中心に、ヒアリング結果や課題のエビデンス資料を分析し、ワークショップの論点整理を行います。 品質管理組織とステークホルダーによるワークショップを開催し、コンサルタントのファシリテーションで主要課題の認識合わせと論点の検討を行います。 ワークショップ参加者は、「テスト成熟度マトリクス」、「改善提案」、「キーエリア達成のコツ」 等を参考に、実施するべき施策を議論し、合意します。 品質管理組織はステークホルダーと協力して、合意した施策のスケジュールとリソースを決定し、アクションプランとして取りまとめます。 取りまとめたアクションプランについて、品質管理責任者の承認を得ます。 おわりに テストプロセス改善モデルの一つである、TPI NEXT の概要と活用例をご紹介しました。 TPI NEXT は日本語化された excel ツールや、活用のための分かり易い手引書等も出ているので、比較的容易に始められるのではないでしょうか。 又、手法自体のカスタマイズ性も高く、必要な箇所だけをセレクトする等の使い方も柔軟にできるので、部分的なテストプロセス改善等に適用して試してみて頂ければと思います。 Appendix：参考となるサイト、書籍 など TPI Next ツール Test Process Improvement (TPI) Sogeti’s Test Process Improvement model – TPI NEXT® – reflects the changes in today’s business dynamics and technology developments. The model still provides a step-by-step guide to developing an insight into the relative maturity of an organizati... 　詳細はこちら　 TMap 関連情報 TPI NEXT テスト成熟度マトリクス ツール（日本語版 ver 2.1.2） TPI NEXT テスト成熟度マトリクス ツール ユーザーマニュアル（日本語版 ver 1.2.1） TPI Next 関連参考資料 「TPI NEXT ビジネス主導のテストプロセス改善」 （トリフォリオ：日本語翻訳版） 「はじめてのテストプロセス改善」 （翔泳社：電子書籍） 「テストチームの健康診断」 （JaSST東海実行委員：JaSST ‘17 Shikoku 講演資料） The post TPI NEXT®を活用したテストプロセス改善 first appeared on Sqripts .

はじめまして。テストエンジニアの藤江です。2023年9月に現在の勤務先にJOINし、テスト実施管理者として顧客の課題やお困りごとに最前線で対応しています。今回は、テスト実行プロセスにおけるモニタリングとコントロールについてご紹介したいと思います。 テスト実行プロセスにおけるマネジメントのための事前準備 事前準備として重要なのは、マネジメントを行うための基準を決めることです。モニタリング及びコントロールのプロセスを最適化し、調整するための基準をテスト計画の段階で策定します。具体的には以下のような基準の調整を行います。 テスト対象、テスト範囲、テストスケジュールの把握 テスト実行プロセスにおけるモニタリングを行う際には、現時点の状態を正しく把握し、問題を検出することが重要です。テスト計画の時点でテスト対象、テスト範囲、テストスケジュールについて合意を取り、計画と実績の差分を取れるようにします。 モニタリング対象の選定とQCDバランスの合意 計画と実績の差分が取れるような基準を決めた後、テストの進行状況に合わせてモニタリングの対象を決めます。計画時には、上手く行かなかった場合の対応策を事前に決めておくことも重要です。QCD(品質(Quality)、コスト(Cost)、納期(Delivery))のうちどれを重視し、 計画との乖離がどれくらい出たら実行に移すのかを予め決めておくことが必要です。 テストと開発が並行で実施される場合の留意点 テストと開発が並行している場合、開発側のスケジュールに影響してテスト計画を変更することもあるため、特にスケジュールに留意し、テスト実施のスケジュールだけでなく、実施の前提となっているシステム実装側のスケジュールも確認する必要があります。 モニタリングとコントロールとは モニタリング 対象の状態を連続または定期的に観測・記録し、監視し続けること。ソフトウェアテストにおいては、問題やエラーを早期に検知するためにテストの進捗状況や結果をリアルタイムで把握し、テストプロセスを最適化するためのデータを収集します。 コントロール 対象を目的の状態にするために操作すること。ソフトウェアテストにおいては、テスト実行中に発生する問題への対処や修正を迅速に行い、テスト実行の流れを管理し、リソースやテスト実行プロセスに対する行動を調整します。 テスト実行プロセスのマネジメントで行うモニタリングとコントロール テストのモニタリングとコントロールに関して、JSTQB テストマネージャーのシラバス「2.3.4 テストプロセスにおけるテストの優先度付けと工数の割り当て」から一部抜粋します。 テスト実行では、テスト計画作業で決定した優先度に従ってテストを実行すべきである。 ただし、計画を作成した後で得られた情報に基づいて、定期的に優先度付けを更新することも重要である。 テスト結果と終了基準ステータスを評価しレポートする場合、テストマネージャは、リスク、要件、利用方法プロファイル、およびチェックリストに関して、評価し、レポートする必要がある。 さらに、テストを選択し優先度付けするために使用するそれ以外のガイドについても、評価し、レポートする必要がある。 必要に応じて、テストの優先度付け方式に基づいて、テストのトリアージ（実行順序判定）を行う必要がある。 ソフトウェア開発において、問題を迅速に検出し解決するためのモニタリングは、早期に問題を発見し修正するうえで非常に有益です。以下にいくつかのモニタリングの例を紹介します。 不具合箇所の早期発見 特定の不具合により実行できない箇所がないかを厳密にモニタリングします。これにより、開発プロセス全体において生じる影響を最小限に抑えることが可能です。 不具合によって実行できていない箇所をモニタリングするためには、試験項目のバックログ（BK）を不具合のチケット番号と紐付けし、各チケットごとに関連する試験項目数を一覧化することが有効です。これにより、不具合チケットによって何件のテストケースが実行できないかを把握し、効果的にモニタリングすることができます。 品質向上によるテスト効率改善 品質が低い場合、テスト効率を損なう原因となります。モニタリングを行い、品質が悪い箇所を特定し改善することでテストプロセス全体の効率を向上させます。 品質が悪い箇所をモニタリングするためには、不具合報告の際に予めさまざまな属性をタグ付けし、タグごとに集計したデータを確認する手法が有効です。これにより、特定の機能ブロックに不具合が集中している場合、その部分の改修を行うことで全体の効率を向上させることができます。 進捗状況の把握 テストの現状と目指しているゴールとの差分を常に確認し、周知することが重要です。全体の進捗状況を把握することで、チーム全体が同じゴールに向かって進むことができます。 計画との乖離を確認する方法としては、WBS（Work Breakdown Structure）による各機能のテスト進捗確認に加えて、EVM（Earned Value Management：実績と計画をコストの面から状況を把握する手法）を使用して、項目の消化状況と使用したコストが計画通りに進行しているかを確認することが有効です。この数値を日々確認することで、計画からの乖離が起きていないかをモニタリングすることができます。 これらのモニタリング手法を実践することで、ソフトウェアテストの実行状況を把握し、問題の早期発見とそれによる迅速な対応ができるようになります。 また、同様に問題を修正するためのコントロールも重要です。以下にいくつかのコントロールの例を紹介します。 実装スケジュールに併せての実施テストの入れ替え 開発の進捗に合わせてテストを調整し、特定の機能やコンポーネントのテストを実行する順番を変更することが重要です。リソースや時間の制約下で柔軟に対応することが必要です。具体的には、実装が遅れている機能のテストを後回しにして他のテスト実施を優先的に実施するといった対応を行います。 不具合にて実施できないテストスイートとの順番入れ替え 不具合の発生により特定のテストが実行できない場合、他のテストスイート(テストの目的や条件が似ている複数のテストケース)と順番を入れ替えて進行することで、効率的なテストの実施を維持します。 予め乖離が出た際に決めておいた合意に従っての変更 プロジェクトの進行において、予め設定された計画からの乖離が生じる可能性があります。その際には、事前に合意された方針や変更手順に従って適切に調整を行います。 例えば、テスト実施時に計画から3割以上の乖離を確認したら重要な機能テストにのみテスト実施者を集中させる、開発チーム側としてデバッグや修正を迅速に行うための専任の担当者を配置するといったことを実行します。 システム開発において、テストフェーズと実装フェーズが同時進行する際には以下の留意点が重要です。 開発側の実装スケジュールとの調整 開発チームの実装スケジュールとテストの実行を調整し、スムーズな進行を図る必要があります。 不具合の追跡と修正処理 開発者が修正を行うため、不具合の特定から修正までの速度を明確にし、リスクを管理することが欠かせません。 デグレード等の検証 実装とテストが重なることから生じるデグレードなどのリスクに適切に対処し、品質を維持する必要があります。 テスト結果に基づく意思決定 テスト中止やスケジュールの見直しの基準を適切に設定し、進捗状況をモニタリングして、プロジェクト全体の進行状況を把握します。 これらの留意点を踏まえ、開発とテストが同時進行する場合には適切な調整やコミュニケーションが不可欠です。異なるフェーズが連携して効果的な結果を生み出すためには、定期的なリポートやミーティングを通じて全体像を把握し、適切な対応を行うことが重要です。 イレギュラーケースの対応事例 様々な面からテストに関する要望が寄せられることが増えてきました。特にイレギュラーかつ重要な対応が求められる場面も多く、以下のような要望を頂くことがあります。 消化スケジュールに対する要望 要望内容: 人員を増やしてでも項目を早く消化してほしい。 検討事項: スケジュールの短縮はプロジェクトにとって重要です。迅速な対応のため、追加スタッフの配置や最適化を実施し、進捗を優先的に考える必要があります。 作業追加に対する要望 要望内容: 検出された不具合に関する優先度の高いものを精査してほしい。 検討事項: 高い優先度の不具合については適切な対応を行うため、検証プロセスを改善し、緊急性を優先的に考慮する必要があります。 これらの要望に対しては、以下の手順で支援を行っています。 品質保証の芯についての確認 テスト品質の中心部位を確実に把握し、対応を行うための基礎となる情報を整理します。具体的には優先順位の再整理として、絶対に落としたくない機能や超えてはいけない期日等を明確にしていきます。 後ろに控えている作業や要望の背景の確認 現在の要望の他に、背景に潜む問題や要求事項なども含めて把握します。何を求めているのか、要望を言葉通り捉えて良いのかといった点を特に確認します。 例えばですが、試験項目をもっと消化してほしいという要望があるとします。詳細なヒアリングを行ってみると、複雑な手順については開発チームでのツール導入を検討している。軽微な手順の箇所を先に終わらせてほしい。複雑な手順の項目に対して各テスターが仕様書を見て時間をかけないようが良いといった試験実施順序の入れ替えの要望だったりすることがあります。 QCDのうち何をトレードオフとするのか QCDに関して、何を優先し、何を譲歩するかを明確にします。例えば、単純にコストと納期の優先を要望されたので、品質を落とします。といったトレードオフは出来ず、トレードオフを行うにも納得してもらう必要があります。 具体的に納期の優先を要望された場合に、品質を落とすのであれば、試験実施のエビデンス取得手順及びエビデンス確認によるクロスチェックを止めます。これによって試験実施を行ったことに関する証左や後から実施内容のトレースが出来なくなってしまうことを了承してもらうといったトレードオフが必要になります。主なトレードオフとなりやすいのは以下となります。 　・作業手順を減らす 　・テスト環境を減らす 　・テスト項目を減らす どの場合もトレードオフのリスクについて同意を得る必要があります。 要望に対する具体的な対応案の作成 施策や改善策を具体的にまとめ、実行可能な提案を作成します。手順としてはトレードオフとなったことで、確保することができたリソースをどう分配するかを検討します。先ほどの納期優先のためにテストの手順を一部削減する例であれば、手順を削減することでどのくらい試験実施が進むのかを見積もり新しいスケジュールを作成、お客様と相談の上計画に問題ないかを確認します。 変更の経緯及び作業影響に関するテスト実施メンバーへの説明 変更の経緯や予定の変更箇所についてテスト実施メンバーに的確に説明し、スムーズな実行を促します。要望対応についてテスターとしてどのような対応が必要か、新しいスケジュールに関して何に意識を向ければ良いかを説明します。 こちらに関しても、先ほどの手順を削減する例であれば、削減した手順に関する説明とそれによって変更になった1日当たりの消化目標数等具体的な日々の作業がイメージできるように説明する必要があります。 まとめ テスト実行時のモニタリングやコントロールの目的は、問題の早期発見と早期解決です。問題に対する解決が不十分であると顧客から判断されると様々な要望を頂くことがあります。要望を頂くということは、既に問題の発見と対応に失敗しかけている状況であり、そのような事態でもトレードオフや要望の背景を確認しながら進めることが重要です。 テストエンジニアとして、これらのポイントを意識しながら、顧客の期待に応えるために最善のテストプロセスを提供していきたいと考えています。 The post テスト実行プロセスのモニタリングとコントロールについて first appeared on Sqripts .

ソフトウェア開発の世界では、アジャイル開発やスクラムが一般的になってきました。そのアジャイル開発のコアとも言えるのが、対話や協調です。この連載では、アジャイル開発におけるコミュニケーション・コラボレーションスキルを解説しながら、ファシリテーションスキルのレベルアップを目指します。 第5回目のテーマは前回解説した「ファシリテーション」と合わせて学びたい「コーチング」です。 ＜スクラムマスターのためのコミュニケーション講座　連載一覧＞ ※クリックで開きます ・ #イントロダクション：優れたスクラムマスターが絶対に言わないこと 【連載初回、全文公開中】 ・ あなたの提案はなぜ受け入れられないのか？｜ファシリテーション技術-1- ・ よりよい場を作るための9つのルール［前編］｜ファシリテーション技術 -2- ・ よりよい場を作るための9つのルール［後編］｜ファシリテーション技術 -3- 前回のおさらい 前回 はファシリテーション技術について解説しました。今回はコーチング技術の解説になりますが、ファシリテーションもコーチングも、トレーニングなどに参加してみるとよくわかるのですが、共通して学べる部分が多くあります。 ここでは、コーチングの中でも、スクラムイベントなどアジャイル開発におけるコミュニケーションで使えるポイントを中心に解説していきます。 よりよい場を作るための9つのルール［後編］｜ファシリテーション技術 -3- ソフトウェア開発の世界では、アジャイル開発やスクラムが一般的になってきました。そのアジャイル開発のコアとも言えるのが、対話や協調です。この連載では、アジャイル開発におけるコミュニケーション・コラボレーションスキルを解説しながら、ファシリテーション... 　続きを読む　 Sqripts 関連記事｜Sqripts コーチングの代表技術 昔、熟練のコーチに「コーチとは何か？」を質問したときに、その方は「コミュニケーションのプロフェッショナル」と答えていました。コーチングを学んでみるとそう答えた理由がよくわかるのですが、コーチングの本質は相手（クライアント）とパートナーシップを結び、共通のゴールの達成へと進んでいく方法です。よって、チームメンバーのような「相手」との会話の質を高められるヒントがたくさんあります。 コーチングの代表技術 コーチングの主たる技術は「傾聴」、「質問」、「承認」、「フィードバック」です。それぞれの技術をみていきましょう。 傾聴 傾聴（けいちょう）は、しっかり聞くことです。漢字が表しているように、相手に傾きながら聴きます。「聞く」ではなく「聴く」です。コーチの頭の中を覗いてみると、相手が発する言葉を聴くだけでなく、その背景まで読み取ろうとします。 たとえば、コーチングの練習でよく聞くテーマが「片付けができない」や「ダイエットが続かない」です。ずばり「片付けましょう」や「おかしを食べるのを止めましょう」と言いたくなりますが、 プロのコーチは問題そのものではなく、その言葉の裏側を考えます 。 コーチ ： 「今日、何か話したいことはありますか？」 クライアント ： 「そうですね。片付けができなくて困っています」 コーチの心の中： （この人は片付けができないことで悩んでいるのか。すぐ片付ければいい気もするけど、なぜこの人は「片付けができない」と考えているのだろうか？ そうしてしまう状況や環境があるのだろうか？ できないと思いこんでしまうなにかがあるのだろうか？） 聴くことの難しさを学ぶなら、相手と二人一組になって、5分間聴き続けるトレーニングを試してみるといいでしょう。思った以上に聴くことが難しいと感じるはずです。ついつい話をしてしまいがちですが、コーチングの8割は聴く時間と言われたりします。 アジャイル開発の現場に置き換えて、傾聴について考えてみましょう。 スクラムマスターもアジャイルコーチも、教えるケースはもちろんありますが（ティーチングやトレーニング）、チームの自律性を考えると、チームで主体的に考えられるようなコミュニケーションを取っていく必要に迫られます。 よって、当初は経験やアイデア、基本や応用を語る時間が多くなるでしょうが、徐々にコーチング的な関わり方を増やし、「よく聴く」時間が増えてくるはずです。積極的に聴くことで、状況を理解し、選択肢の整理ができます。積極的に聴くことで、チームメンバーが自律的に話すように変わっていきます。 もし、スクラムマスターやアジャイルコーチがいる現場において、1年ぐらい経ったのに、彼らがとうとうと知識や経験を語っていれば注意が必要です。なぜなら、スクラムマスターやアジャイルコーチが、チームの自律性をうばっている可能性があるからです。 質問 質問例 質問によって相手は内省をはじめます。良い質問は相手を深く考え込ませ、彼らの中にあるポテンシャルを引き出していきます。ここでは、質問やその例の概要をまとめておきます。 視点を変える質問 ： 自分たちの視点に凝り固まってしまったときは、視点を変える質問によって、より大きな視点や、違った視点に切り替えることで、議論の幅を広げていきます。 時間を変える質問 ： 自分たちのいる時間軸にしばられてしまったときは、時間を変える質問で、過去や未来にタイムトラベルを行い、それぞれの時間軸で問題を考え、新しい発見を得ようと試みます。 リソースを確認する質問 ： 自分たちの力量に限界を感じたら、リソースの確認によって、自分たちに使えるリソースを考えます。リソースとは、詳しい方とのつながり、お金、時間、環境など、チームが使えるものすべてを指します。 オープンな質問とクローズドな質問 ： 広くアイデアを集めるならオープンな質問が良いでしょう。オープンな質問は答えが複数になる質問です。逆に、議論が発散した場合は、選択肢の中から選ぶようなクローズドな質問も使えます。 チャンクダウンとチャンクアップな質問 ： 大きな問題は小さく分割すると物事を進めやすくなります。逆に小さすぎる問題は、すこし大きく組み立ててから考えると扱いやすくなるかもしれません。 アジャイル開発の現場では、良質な質問が飛び交います。発想やアイデアを広げたり、より最適な解決策を見つけたり、行動の源泉に結びつけるために質問を活用するのです。 承認 承認とは認めることです。コミュニケーションにおける承認とは、相手の話を受け入れ、認める行為を指します。承認にはいろんな方法があります。 「おはようございます。◯◯さん」 「ふんふん。なるほど」 「◯◯さんは、そう思ったんですね」 「目標を達成しましたね」 「つまり、〜〜だったんですね」 あいさつはわかりやすい承認方法です。あいさつするだけでなく「◯◯さん」と相手の名前を呼びかけるのも承認につながります。あいづちも承認です。「〜だったんですね」、「〜をしましたね」と相手の話を復唱したりする行為や、「つまり〜なんですね」といった要約する行為も、承認になります。 承認がない会話は、一方通行になりがちです。話している相手も「この人、私の話を聞いてくれているのかな？」と不安になってきます。コーチは傾聴とあわせて承認を加えることで、相手に「ちゃんと聴いてますよ〜」という反応を送り続けます。 承認は共感を生み出します。コーチングはあくまでクライアントとのパートナーシップ（1on1のような上下関係がない）なので、共感が生まれないと信頼関係に繋がりません。 アジャイル開発の現場における承認はどういったものになるでしょうか？ まず、スクラムを利用していれば多種多様なイベント（MTG）が開催されます。ソフトウェア開発の仕事ではチーム力が求められるため、コミュニケーションは避けて通れないイベントと言えます。イベントの中で気軽にアイデアを話しても、反応がなければモチベーションは下がります。次、また意見しようと思う人は少ないはずですよって、可能な限り、お互いに承認を繰り返していく必要があります。 承認はコミュニケーションが主体になるソフトウェア開発において、重要なスキルなのです。 フィードバック 最後はフィードバックです。承認とセットで語られるケースもありますが、ただ受け入れる承認とは違い、相手に何かを伝えるフィードバックとして、ここではわけて解説します。フィードバックは、いわゆる承認を超えた反応になります。ふんふんと受け入れるだけでなく、相手に言葉を渡します。 「今の話を聞いて、感じたことを話してもいいですか？ 私は〜〜と思いました」 ファシリテーションでも解説した「提案と質問を組み合わせる」形に似ています。コーチングにおいて、フィードバックを受け入れるかどうかは相手が選びます。よって、伝え方にも注意が必要になり、伝え方を間違えると「コーチのアドバイス」になってしまい、コーチングの効果が期待できなくなり、相手も自分事として考えてくれなくなります。 承認で出てきた、「◯◯さんは、そう思ったんですね」や「目標を達成しましたね」もフィードバックの一種と言えます。「そう思ったんですね」という一言によって、今ここにある感情を確認できます。「目標を達成しましたね」という一言によって、相手の前進が明確になります。 ちなみに「目標を達成してすばらしいですね！」はコーチング観点だとあまりおすすめされないコミュニケーションになります。すばらしいかどうかはクライアントが決めることで、コーチが決めることではないからです。ただし、1on1など、部下の育成の場においては、「がんばろうね」といった一言が相手の背中を押すケースもあります。 ＊ 今回は、コーチングの主要技術について解説しました。ファシリテーション技術とあわせて使うと、アジャイル開発やスクラムの現場が活性化されていきます。ただ、ファシリテーションもコーチングも、それぞれが独立したスキルになるため、アジャイル開発の全てに適応できるわけではありません。 あくまで「活用できる部分が多い」ことを理解しておかないと、コーチングの基礎的な部分を自分の都合よく間違えて解釈してしまい、期待した効果が得られなくなる問題が発生してしまいます。いわゆる「自分に都合の良いコーチング」です。 次回はコーチングの中で、もっとも難しく奥が深い「質問」について深掘りしていきます。 連載一覧 ・ #イントロダクション：優れたスクラムマスターが絶対に言わないこと 【連載初回、全文公開中】 ・ あなたの提案はなぜ受け入れられないのか？｜ファシリテーション技術-1- ・ よりよい場を作るための9つのルール［前編］｜ファシリテーション技術 -2- ・ よりよい場を作るための9つのルール［後編］｜ファシリテーション技術 -3- The post コーチング技術 〜 基本技術を学ぼう｜コーチング技術 -1- first appeared on Sqripts .

みなさん、はじめまして。たけちゃんです。 私はこれまで2回のジョブチェンジを経験しており、現在は第三者検証会社にてテスト業務を中心に様々な案件に携わっています。本ブログではジョブチェンジを実施してきた経緯とメリットについてお伝えできればと思います。 これまでの経歴について 私はこれまで以下のジョブチェンジを行ってきました。 勤務先 勤務年月 業務内容 システムエンジニア (以下SE)時代 2011/4～2019/9 某地方銀行傘下のシステムを運用・保守を実施 システムインテグレーター(以下SIer)時代 2019/10～2023/3 様々な地方銀行の案件に携わり、要件定義・基本設計書などの上流工程を実施 第三者検証会社時代 (現在) 2023/4～ テスト設計・テスト実施などのテスト業務を中心に実施 SE時代について お客様と協力しながら某銀行のシステム改善を目的とした案件を実施することにより、以下のスキルを習得することが出来ました。 特定の作業のみ実施するのではなく、プログラミングから本番反映までの作業を経験することが出来た。 銀行業務に関する知識を身に着けることが出来た。 一方で、以下の理由から、世間に通じるようなスキルが身についていないのではないかと、幾ばくかの不安を覚えていました。 携わったシステムはレガシー化が進んでおり、一般的ではないプログラミング言語を扱っていること。 お客様は某銀行のシステム担当者のみであるため、お客様が一緒に働く仲間であるという意識が強く、不特定多数のお客様と会話する機会は多くなかった。 SIer時代について SE時代と比べ、様々な銀行の案件に携わるようになりました。また、より一層、要件定義や基本設計書などの上流工程の作業を中心に行うようになり、以下のスキルを身に着けることができたと感じています。 案件の見積もりの経験を通じて、お客様との折衝スキルを身に着けることができた。 他の銀行のシステム担当者と会話する機会が増えたことにより、コミュニケーション能力が以前よりも向上した。 上流工程を経験することにより、要件定義および基本設計書を作成するスキルが向上した。 下流工程のリーダーとして、下流工程担当の方に指示を行う経験を積むことで、マネジメントスキルが向上した。 一方で、SIerとして仕事を行うことにより、以下の気づきを得ました。 上流工程に携わる機会が増えたことで、自分は下流工程のほうが向いていることに気づいた。 新しい環境においても扱うプログラミング言語はレガシー資産のままであり、新しい技術に触れる機会が少なく、SE時代と変わらず、世間に通じるようなスキルが身についていないと感じた。 休日勤務および残業が増加したことで、自分の使える時間が減少し、仕事に対するモチベーションが低下した。 上記の気づきを受けて、自分に適した働き方が明確になったため、転職エージェントを通じて転職活動を開始しました。これまでの上流工程の経験を活かして、下流工程を含めた全体の品質管理に関わることができ、さまざまな業種でのレガシーではない資産に携わることで、一般的に価値のあるスキルを身につけられる職場を模索しました。多くの人事担当者との面談を経て、最終的には現在の第三者検証会社での勤務が決まりました。 第三者検証会社時代(現在)について 第三者検証会社にジョブチェンジしたことによる気づき 第三者検証会社で案件をこなすことで、以下の気づきを得ることができました。 これまで勤めていた会社では経験則によるテストを実施していましたが、第三者検証会社では様々なテスト技法を用いた論理的なテストを実施しており、これまでのテストは品質が担保されていなかったことに気づきました。 以前は残業することが当たり前の環境でしたが、第三者検証会社では、しっかりと計画を立ててプロジェクトを受託し、進行することで、ワークライフバランスが取れていることに気づきました。 第三者検証会社で身についたスキル 第三者検証会社で案件をこなしながら、以下のスキルを身に着けることができたと自負しています。 自分もテスト技法を学び、案件を通じて実践することで、これまで以上に質の高いテストを実施できました。また、経験則による資料作成から脱却し、テスト技法を用いた体系的な資料作成を心掛けることで、プロジェクト経験の浅いテスターでもテストを実施できるようになり、属人化を防止できるようになりました。 前職ではお客様がほぼ固定だったため、雑なコミュニケーションでも通じていましたが、第三者検証会社入社後は案件ごとにお客様が異なるため、丁寧なコミュニケーションが必要になりました。そこで、テスト技法を用いた資料を作成し、それを基にお客様へ説明を行いました。その結果、説明責任が果たしやすくなり、コミュニケーション能力が向上しました。 効率的に作業するために、お客様との打ち合わせを頻繁に行い、作業の優先順位を付けました。優先順位の高い作業を重点的に行い、優先順位の低い作業はお客様の了承を得て実施しないことで、効率的な作業を実現し、作業効率を向上させるスキルを身に着けました。また、効率的な作業により残業時間を減らし、ワークライフバランスを向上させることができました。 まとめ これまで働く環境を変えてきたことで、ジョブチェンジには以下のメリットがあると気づきました。 新しい環境に慣れるのは大変ですが、未経験の仕事に携わることで新しいスキルを身につけることができる。 新しいスキルを身につけることで、自分の適性を知ることができる。 自分の適性を把握することで、自分の強みを活かしたジョブチェンジが可能になる。 これまで当たり前だった常識を新常識にアップデートできる。 ワークライフバランスを向上させることができる。 ジョブチェンジを行うことで新しいスキルを身につけ、そのスキルを通じて自分の適性を理解することができました。ジョブチェンジは新しい環境への適応が必要となるため勇気がいりますが、更なる成長を望む方や現在の環境を改善したい方にはぜひ挑戦をお勧めします。 今回の記事がジョブチェンジを検討する際の参考になれば幸いです。 The post ジョブチェンジを行うことによるメリットの紹介 first appeared on Sqripts .

こんにちは。バックエンドエンジニアのカズです。 今日はExcelのベータ版に提供されているPython in Excelを紹介します。 Python in Excelとは? Python in Excelとは、その名前の通り、Excel内でPythonコードを実行できる機能です。 PythonコードはMicrosoft Cloud上のAnacondaで実行されます。 セルに直接Pythonコードを入力することで、Pythonコードがクラウド上で実行され、データの加工などを行うことができます。 Python in Excelの利用方法 現在はプレビュー版であり、Microsoft 365 Insider Programのベータチャネルでしか提供されておらず、Windows版でのみ利用することができます。詳しくは こちら を確認してください。 Microsoft 365 Insider プログラムに参加する - Microsoft サポート Microsoft 365 Insider プログラムに参加する 　詳細はこちら　 support.microsoft.com 関連情報 Python in Excelの使い方 セルに =py( と入力するか、数式リボンから Pythonの挿入 を選択してください。 選択すると、セルと数式バーにPYという表示が表れて、コードを受け付けられる状態になります。 その上で、セルもしくは数式バーにコードを記述しCtrl+Enterを押下することでコードが実行されます。 Python in Excelの基本機能 記述したコードの実行結果はセルに出力されます。 また、 ["A", "B"] などの型を持つコードの場合、 Pythonオブジェクト を選択すると、Pythonオブジェクトの型が表示されます。 リストなどの多次元配列に対応している場合、そのセルだけではなくデータの形状によって他のセルにも展開されて表示されます。 以下の図は、A1セルに x = 1 を入力し、そのほかのセルに x += 1 を入力した状態です。 基本的に、Python in Excelにおいての計算は、列順で計算が行われた後、行が移動し再度列順で計算が行われます。ただし、計算方法の設定において手動を選択した場合は、その法則に従わず計算が行われます。 上の例では、A1→B1→C1→A2→…の例で計算が行われています。 下の例では、上の表を作成した後にE1に式を設定しています。 本来であればE1に式を設定した場合はC1の後に計算が行われるため結果は 4 となりますが、計算方法を手動に設定しているため、A6の 13 となる計算結果の後に演算を行っているため、結果は 14 と出力されています。 Pythonコード内でのセルの指定 Pythonコード内でセルにあるデータを利用する際は、 xl() 関数を用いて指定します。 利用できるPythonライブラリ Python in Excelの実行環境は、前述のとおりAnacondaを利用しているため、基本的にはAnacondaに搭載されているライブラリを利用できます。また、予めインポートされているライブラリもあり、初期化ボタンを選択すると、そのライブラリを確認することができます。 その他の利用できるライブラリに関しては、 こちら を確認してください。 Open-source libraries and Python in Excel - Microsoft Support This article describes the open-source python core libraries and how to import them 　詳細はこちら　 support.microsoft.com 関連情報 コンソール出力 print() やエラーコードなどは診断画面に出力されます。また、エラーのため実行できなかったセルには、 #PYTHON! が表示されます。 関数の利用 セル内で関数を定義し、その他のセルでその関数を利用することも可能です。 以下の例は、引数を2つ与え、その引数を足し合わせて返却する関数を作成し、その関数に対して2つの引数を与えた結果です。 他にできること グラフ描画を行うことのできるmatplotlibを利用して線形回帰や散布図を生成したり 線形回帰サンプルから引用 散布図サンプルから引用 データ分析やデータの前処理を行うことのできるscikit-learnなどのライブラリを活用することで一般的な機械学習をすることもできます。 また、Excel関数で出力させた値に対して、Pythonコードで処理を行うことも可能です。 Python in Excelでできないこと Pythonをローカルで実行する Pythonはクラウド実行のみの環境となっているため、今後ローカルで実行する予定も無いとの発表があります。( 公式ブログ ) Pythonから外部ファイルへアクセスする Python in Excelはクラウド実行となっているため、そのままの状態ではローカルファイルへのアクセスはできません。Power Queryを使用することで外部データを使用することができます。( 公式 ) また、requestsなどのライブラリを使用したインターネットへのアクセスも不可能です。 まとめ 今まではExcelファイルを使って分析をするためにPythonからExcelを読み込んで行っていたものが、一部だけですが、Excel単体で行えるようになったことは大きいのではないかと思います。 今後、Windows版だけではなく、Mac版などにも実装されることを期待したい機能の一つだと考えています。 The post Python in Excelを使ってみた first appeared on Sqripts .

本連載ではプロジェクトマネジメントの全体像と、プロジェクトを成功させる上で最低限抑えるべき知識と技術はもちろん、プロジェクトを炎上させないための技術やコツをお伝えしたいと思っています。 みなさんのプロジェクトが今以上に充実し、笑顔でプロジェクト終結を迎えられるよう一緒に学んでいきましょう。 第11回となる今回は「リスクマネジメント後編」です。 前回と今回の2回に分けて、プロジェクトマネジメントにおけるリスクの考え方と具体的なリスク分析方法、対応策の立て方について一緒に学んでいきましょう。 ＜ プロジェクトマネジメント成功の技術 連載一覧＞ ※クリックで開きます 【第1回】プロジェクトマネジメントとは何か？ 　［連載初回全文公開中：Sqripts会員以外の方も全文お読みいただけます］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ 【第8回】コストをプロジェクトの武器にする！ 【第9回】目に見えにくいプロセス管理こそ品質達成の鍵 【第10回】プロジェクトのリスクマネジメント［前編］リスクを徹底的に洗い出す 前回のおさらい 前回 はリスクの概要、リスクマネジメントのステップ、リスクの洗い出しについて解説しました。 【第10回】プロジェクトのリスクマネジメント［前編］リスクを徹底的に洗い出す 本連載ではプロジェクトマネジメントの全体像と、プロジェクトを成功させる上で最低限抑えるべき知識と技術はもちろん、プロジェクトを炎上させないための技術やコツをお伝えしたいと思っています。みなさんのプロジェクトが今以上に充実し、笑顔でプロジェクト終結... 　続きを読む　 Sqripts 関連記事｜Sqripts リスクがプロジェクトに及ぼす影響を分析する 洗い出されたリスクは、プロジェクトへどのような影響を及ぼすかを分析して、管理可能な状態に落とし込んでいきます。分析にはリスクの優先順位を付けるための定性的分析と複合的な影響を分析する定量的分析とがありますが、定量分析は全てのプロジェクトに必須ではなく且つ分析に必要なデータが入手できる場合に行います。 ※以下では単純化した定量リスク分析のイメージを記載しています リスク定性的分析：多くのプロジェクトで実施する分析手法で、リスクの発生度や影響度などから優先順位を付ける リスク定量的分析：大規模または複雑なプロジェクトで使用されることが多く、リスク影響を数量的に分析する 1) 定性的分析で優先順位を決める リスクの優先順位付けとは ＜先に手を打つべきリスクを決める＞ ことです。 リスクの発生頻度と影響度、その他の特性を査定して、その後の分析や処置のために個々のプロジェクトリスクにおける優先順位付けを行います。優先順位の高いリスクに集中することで、プロジェクトのパフォーマンスを向上させることができます。 具体的には、以下のように個々のリスクを配置していくことからはじめましょう。マトリックスの縦軸は「発生頻度」として、そのリスクが発生（リスク発動）してしまう可能性の高低を設定します。横軸はリスクがプロジェクト目標達成にに与える「影響度」を設定します。 発生頻度：リスクが起こるのはどれくらいの頻度と考えられるか 影響度　：リスクが発動した場合、どのような結果がもたらされるか この発生頻度と影響度に対しての閾値は、実は人やその人の経験などによって感じ方が大きく異なります。またプロジェクトの性質によっても異なります。その閾値の違いがリスク分析に影響を及ぼさないように、それぞれの指標を必ず決めておきましょう。 2) 定量的分析で対応範囲を決定する 大前提としてリスクを管理することはお金がかかります。リスクを洗い出してみると、多くのリスクが出てくることに驚くことも少なくありませんが、全てに対応して備えることはコストの面でも時間の面でも限りがあり困難です。ですから「このプロジェクトではどのリスクにフォーカスしていくべきか」ということを明確にして、対応範囲を決めておくことが重要になります。 先ほどの発生頻度×影響度のマトリックスに配置したリスクに対してポイントを割り当てていきます。例えば、各軸の高は3PT、中は2PT、低は1PTとしましょう。縦軸の数値×横軸の数値が各ますのポイント＝リスクポイントとなります。 リスク対応の大原則はこのリスクポイントが高い順に実施します。場合によっては6PTと4PTの中間あたりというように迷う場合や個別の判断が伴うリスクもあると思いますが、リスクの数値化により例えば「6PT以上のリスクに対応する」と意思決定し、集中してリスク対応予算や対応工数を充当することができるでしょう。 筆者の経験から、概ねリスク対応対象となる（上記の例で言えば6PT以上）リスクは全体の20％程度、受容するリスク（6PT以下）が80％程度になる印象です。注意したいのは「リスクには全て対応策を考えなければならない症候群」です。これは間違いであり且つ間違いなくコストがかかりすぎます。リスクアイデアに上がったリスクは網羅的に対応しよう！とするのは聞こえはいいですが、そんなシーンには注意が必要です。 リスク対応策を考えておく プロジェクトマネジメントにおけるリスク対応策には「5つの分類」があります。洗い出したリスクがどの対応分類で対処できそうか検討します。 リスク対応策はその後の対応実現可能性や難易度、コストなども踏まえて決定する必要があります。例えば「Aというリスクを回避する方法はあるが、それには莫大な対応コストがかかる為、発生頻度も鑑みて一旦は受容することにする」ということもあるでしょう。リスク対応策はバランスが大切です。 リスク対応策検討の材料（評価軸）例： 残存リスク（リスク対応策実施後に残るリスクはどうか） 二次リスク（リスク対応策を実施した直接の結果として生ずるリスクはどうか） 対応難易度 対応工数 対応コスト 対応にかかる特別なリソースが必要とされるか コンティンジェンシープランを作ろう リスク対策とセットでコンティンジェンシープランを立てておきましょう。コンティンジェンシープランがあることで、より迅速・的確にリスク対応を進めることができます。またコンティンジェンシープランを実施するための費用などのリソースをコンティンジェンシー予備と呼びます。リスク対策をすると感じると思いますが、リスク対策をいくらしてもリスクが残ることが多く、リスクが発生する可能性をゼロにすることは難しいです。リスク発動時にすぐに対応を開始できるようにすること、準備がなによりも大切です。 コンティンジェンシープラン： リスク発動時の耐性や手順、意思決定手段などを文書などで明らかにしておく（起こってもすぐ対応できる） コンティンジェンシー予備： コンティンジェンシープランに対応できる人やもの、コストを準備（見積りと確保）しておく 実行計画を策定していない時点の見積もり→プロジェクト原価の「 X％ 」 実行計画策定後→各受容できるリスクの Σ{(対策時間または費用)X(発生確率)} 1) リスクトリガーを決めておこう タイムリーに対策を発動するため「リスクトリガー」を決めておきましょう。このリスクが発動しそうだ、発動したようだ、という兆候またはメトリクス、閾値を決めておくことです。そのために、リスク毎にリスク監視担当者を決めておくことをおすすめします。リスクが発動しても、トリガーに達しているか判定する人がおらず見過ごされることが実はよくあります。 例）地震の緊急速報（震度XX以上、津波の計画があるとアラームがなるという閾値） リスクを管理する リスク管理表またはプロジェクト管理ツール等の機能を活用して、リスクをマネジメントする管理表を作成するようにしましょう。最低限必要な項目は、リスクの洗い出しで特定したリスク内容、リスク分類、リスク対策、リスクポイント、対応コスト、リスク対応開始日、伴う終了日、リスク担当者です。 「リスク管理表はPMが管理していて（だろうから）見たことがない」と聞くことがありますが、リスク管理表はPMだけが管理するものではありません。リスク特定方法や経緯、なにより監視に力点があります。そのためリスク管理表はプロジェクトの中で目につきやすい、管理しやすい場所（ディレクトリなど）に格納するなどして、誰でも閲覧・確認・更新できるようにしておきましょう。また、リスク管理表作成後は最低月１回程度棚卸し（状態の確認）を定例化するなどしましょう。 棚卸しでのチェック例：リスク監視 （検討済みの）リスク対応策は効果的に実行されているか リスク対応策実施によりリスクレベルは下がっているか（効果があるか） リスク状況は変化したか 新たなリスクは生じていないか、新たな脅威はないか 見逃しているリスクトリガーの発現はないか リスクマネジメントの方針と手順は守られているか さいごに 完璧な計画がないように、リスク（不確実性）のないプロジェクトも存在しません。プロジェクトの目標達成の為に、リスクと適切に向き合って、その影響を自らコントロールできるようになればリスクは決して「ただ恐る」ものではなくなるはずです。 次回のテーマは「プロジェクト資源マネジメント」です。 連載一覧 【第1回】プロジェクトマネジメントとは何か？ ［連載初回全文公開中］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ 【第8回】コストをプロジェクトの武器にする！ 【第9回】目に見えにくいプロセス管理こそ品質達成の鍵 【第10回】プロジェクトのリスクマネジメント［前編］リスクを徹底的に洗い出す The post 【第11回】プロジェクトのリスクマネジメント［後編］リスク分析とコンティンジェンシープラン first appeared on Sqripts .

テストエンジニアのマッツーです。 前回 の記事ではmablの変数について操作方法や所感をお伝えしました。 今回はテスト自動化における「アサーション」の機能や活用方法について書いていきます。 機能の内容だけでなく実際の自動テスト実装で感じたことを書いていくので最後まで読んでいただければと思います。 ■過去記事はこちら ローコード自動化ツール「mabl」 #1 mablの基本操作 はじめまして。マッツーです。僕はもともとマニュアルテストでのQAを担当していましたが、テストの自動化に興味を持っていたため、昨年途中から自動化のチームにてチャレンジすることになりました。コードを書いた経験は社内のプログラミング研修の時くらいしかなか... 　続きを読む　 Sqripts 関連記事｜Sqripts ローコード自動化ツール「mabl」 #2 変数の使い方 こんにちは、マッツーです。前回の記事ではmablについての概要と基本的な操作方法についてお伝えしました。今回はテスト自動化において必要な要素である変数について、操作方法や実際に使った所感を書いていきたいと思います。変数についてテスト自動化では同じテス... 　続きを読む　 Sqripts 関連記事｜Sqripts アサーションについて アサーションとは、一般にはアプリケーションやWebサイトが正しく動作しているかを確認する仕組みのことをいいます。 特にmablにおいては、アサーションは特定の要素に対して正しいかどうか判定し、正しければ「成功」となり、期待値と異なる結果や動作の異常があった場合に「失敗」となるものを指しています。 アサーションには種類が数多くあり、これらを使用することによって複雑なコードを書くことなく自動化ができる仕様となっています。 まずは、mablでのアサーションの作成方法についてお伝えします。 アサーションの作成 今回はサンドボックス内のログイン動作が確認できる「SIMULATED LOGIN」を使用します。 ここでは#2の記事( ローコード自動化ツール「mabl」 #2 変数の使い方 | Sqripts )で用いた「5文字のアルファベット+@test.com」という変数のメールアドレスでログインした後の画面に遷移できたことを確認するアサーションを作成していきます。 始めに、最も基本的な確認方法について説明します。 ▲この画像はサンドボックスを開き、「SIMULATED LOGIN」でメールアドレス・パスワードを 入力してログインまで完了した状態のものとなっています。 トレーナーを確認するとステップ数が9個あることがわかります。 ここからアサーションの作成に入っていきます。 まず、トレーナーの✓ボタン（画像の赤丸で囲われたボタン）をクリックします。 するとページ上に要素選択の画面が表示されます。 この画面ではカーソルを文字に合わせると該当部分が四角で囲まれHTMLタグが表示されるようになります。 以下の画像は「simulated login examples」にカーソルを合わせている状態です。 確認したい箇所であればこれをクリックします。 クリックするとトレーナーの表示が変わりアサーションの設定ができるようになります。 ここでは「属性/プロパティ」と「アサーションの種類」を選択することができます。 「属性/プロパティ」のデフォルトはinnerTextとなっており、要素の文字列を判定内容として使用します。mablの自動テスト実装ではこの「属性/プロパティ」を変更することはあまり多くありませんが、変更することでHTMLのタグ名、クラス名、要素の位置による判定もできるようになります。 「アサーションの種類」のデフォルトはequalsとなっており、期待する値に表示されている文字列と完全一致している場合にアサーションのステップを成功と判定します。 この「アサーションの種類」は確認したい内容によって変更することが多く、equals以外にも使いやすいものがあるため後程紹介します。 「属性/プロパティ」と「アサーションの種類」を選択したらOKボタンをクリックします。 するとトレーナーの10ステップ目に「Assert～」で始まるステップが作成されました。 これによって「simulated login examples」という文字列が表示されていることを確認することができるようになりました。 基本的なアサーションの作成方法としてはこれだけであり、複雑なコードを書かなくても自動テストを行うことができるようになっています。 アサーションの種類と活用方法 ここではアサーションの種類と、どういった場面で使用するのがよいかについて実践経験をもとに書いていきます。 contains containsは期待する値に表示されている文字列を要素が含んでいれば成功と判定します。 赤枠内の要素の確認において「メールアドレスに関係なく「logged in as:」と表示されていることを確認したい」といった場合にcontainsを使用することでメールアドレスが変更になった場合でも「logged in as:」が表示されていればステップは成功となります。 このように、要素内の一部が変更されるような画面であってもアサーションを作成できるため使用頻度は多いです。 ※このケースについては「logged in as:」で始まっているためアサーションの種類をstart withとすることもできます。start withは、期待する値から文字列が始まっている場合に成功となります。 また、変数を使用している場合には比較対象を変数にすることで赤枠内の要素に「5文字のアルファベット+@test.com」というメールアドレスが含まれることも確認できるようになります。 トレーナー内の「期待する値」に「kvbkA@test.com」とありますが、変数による確認の場合には「kvbkA」の部分が別のアルファベットに変わっても、文字数と「@test.com」の部分が正しければ成功となります。 ※このケースについては「5文字のアルファベット+@test.com」で終わっているためアサーションの種類をend withとすることもできます。end withは、期待する値で文字列が終わる場合に成功となります。 ただし、注意点もあります。 mablでは要素選択の際にHTMLの要素によって選択することになるので、特定の文字列のみ取得して確認したい場合に困るケースが出てきます。 上のケースにおける「ioggined in as: 5文字のアルファベット+@test.com」のように「特定の文字列+変数」のような変数が絡むテスト項目については比較対象が前半は属性、後半は変数となっており一度に確認することはできません。 この場合は「logged in as:」と「 5文字のアルファベット+@test.com」をそれぞれcontainsでアサートすることになります。 greater than, less than, greater than or equals, less than or equals 数値を比較する際に使用できるアサーションの種類は4つあります。それぞれ以下の場合に成功となります。 greater than: 期待値より大きいこと less than: 期待値より小さいこと greater than or equals: 期待値以上 less than or equals: 期待値以下 数値比較についてはサンドボックス内の「LOOPING」を使用します。 使用方法は要素選択で数値を選択した後、確認にあったアサーションの種類を選択します。画像では数値として20を選択しているため、greater thanの場合は20より小さい数字が比較値であれば成功となるため、比較値が10の場合は成功、30の場合は失敗となります。 この比較値については負の数や小数点が含まれる数であっても数値の大小比較は問題なく行われるため、今回の場合であれば-10や19.5であっても成功となります。 ちなみに、文字列+数値のような場合でも比較可能です。 「count: 20」という要素における数値の部分を比較したいという場合、比較値を「count: (数値)」とすることで比較することができます。文字列が含まれている場合でも数値を比較して判定可能なため数値データが並んでいるような表の内容を確認する際に便利です。 注意点としてはgreater thanとless thanは比較値と要素の値が同じ場合は失敗となることです。mablの仕様上要素を選択するとその値がそのまま期待する値となるため、アサーションの種類をgreater thanまたはless thanに変更して比較値を変更しないでいると必ず失敗となります。比較値を変更しない場合にはgreater than or equalsやless than or equalsを用いるのがおすすめです。 また、数値以外を比較することもできますが、こちらは個人的にはあまりおすすめできません。数値以外の比較についてはトレーナー上で以下のように説明されています。 アルファベットのみで構成されている文字列であれば比較しやすいのですが、日本語のWebサイトやアプリケーションの場合その文字のUnicodeの大小比較が難しく、テストが失敗した場合にその原因を確認するのに時間がかかってしまうことがあります。 どうしても文字列の判定を大小比較によって判定したいということでなければ、別のアサーション選択が良いと思います。 日本語の大小比較を行いたい場合、漢字表記をひらがなやカタカナのみの表記に変更可能であれば五十音に沿った直感的な大小比較が可能になるためgreater thanやless thanによる確認をしやすくなります。 漢字自体の大小比較を行う場合、比較対象になり得る漢字の種類が限定されているのであればUnicodeの文字コード番号を事前に記録しておき、テストが失敗した場合にどの文字コード番号だったかを参照できれば現実的に運用可能にはなると思います。 まとめ アサーション作成の際に確認したい内容に適したアサーションの種類を選択することで、より柔軟な自動テストの実装が可能になります。 アサーションの種類としては以下のようなものがあります。 アサーションの種類 確認できること 使用可能なケース equals 文字列完全一致 文字列が変化しておらず完全一致していることの確認 contains 文字列部分一致 文章や表が変化する場合に、特定の単語が含まれていることの確認 greater than 期待値より大きいこと 数値が変化する場合に期待値より大きいことの確認 greater than or equal 期待値以上 数値が変化する場合に期待値と同じかより大きいことの確認 less than 期待値より小さいこと 数値が変化する場合に期待値より小さいことの確認 less than or equal 期待値以下 数値が変化する場合に期待値と同じかより小さいことの確認 自動テストの実装においてmablのアサーションは操作の分かりやすさと利便性のバランスが取れているように思いました。 一方で要素取得や大小比較については改善してほしい点もあるように感じています。 要素取得はHTMLタグをもとに行われるので、文章中の特定の単語や数字中の特定の桁のみを確認したい場合containsを使用ことになります。しかし、例として「10101」のような5桁の数字のうち百の位が1であることを確認するようなケースではcontainsで「1」を指定しても百の位以外の1に引っかかり、大小比較で「10100～10199の場合OK」のようにしても「11101」ではOKとなりません。こういった場合の対策として、特定の文字数目だけを確認するようなアサートが可能になればさらに使いやすくなると感じました。 mablはアップデートが高頻度で行われており、前回の記事作成時と比べてもトレーナーが日本語対応していたり利便性が向上していることも多いので今後のアップデートにも期待しています。 ある程度慣れが必要な部分はありますがコード不要でここまで実装できる点はやはり魅力だといえます。 今後も様々な機能や特徴についてお伝えしていこうと思います。 mabl関連記事 ローコードでテスト自動化を実現したいなら「mabl」（メイブル） ローコード自動化ツール「mabl」 #1 mablの基本操作 ローコード自動化ツール「mabl」 #2 変数の使い方 ｍablとGithub Actionsの連携してE2Eテストを自動化する mablで一連のステップを共通部品にして再利用できる「flow機能」について TestRailと自動テストの連携#2　mabl編 mabl APIテストでJavaScriptを用いて変数を扱う方法 The post ローコード自動化ツール「mabl」#3 ～使ってみた所感～ first appeared on Sqripts .

新卒でフロントエンド開発者をしています、イソダです。 約半年前、業務経験３か月目のとき、ついに私も GitHub Copilot を使用できるようになりました。これで開発速度爆上がりだと意気込んでいたのですが、思ったより速度が上がらない。。。 GitHub Copilotが提案してくれるコードが間違っていたり、あまりきれいでなかったりするので、結局は自分で書き直したり、間違いがないか入念にチェックしたりという作業が起きました。 理想とはほど遠いなと思いながら日々を過ごしていると、ある時気づいたことがありました。それは、間違いばかり提案してくるのは、自分のコードが汚いからでは？ということです。 GitHub Copilotは既存のコードを読み取って、文脈に合わせたコードを提案してくれます。公式ドキュメントには次の記載があります。 GitHub Copilot は、編集中のファイルや関連ファイルのコンテキストを分析し、テキスト エディター内から候補の提示を行います。 GitHub Docs, “ GitHub Copilot Individuals について” ,2024/06/03 よって、既存のコードが汚いから、文脈を正しく理解できず、間違った提案をするのだと考えました。 そのため、GitHub Copilotにバリバリコードを書いてもらうということは諦めて、もっと違う形で有効的に使うために工夫していこうと方向転換しました。その結果、自身の成長を加速させるような使い方ができてきたと感じています。 開発初心者向けにはなると思いますが、今回はその使い方を紹介します。 1. 間違いを提案されたら既存のコードをきれいにする GitHub Copilotの提案に間違いが多く含まれているときは、だいたい既存のコードが汚いため文脈が把握しずらく、次のコードの流れが推測しずらいときです。そのため理解しやすいように既存のコードをきれいにしてあげます。ルンバが掃除しやすいように部屋を片付けるのと同じです。 この方法のメリットは次が考えられます。 GitHub Copilotの提案が正確になり、以降の開発速度が上がる。 きれいなコードを書く意識が身についたり、きっかけになる。 自分がコードを読み返したり、コードレビュアーがコードを読む負担を減らせる。 コードをきれいにする方法はいろいろあります。私はよく次に挙げるものを行っています。 ロジックを短く簡潔に書き換える。 使わないコードは削除する（コメントアウトで残さない）。 ロジックを説明変数に代入したり関数に切り出したりで名前を付ける。 変数や関数の順番を入れ替えて、コードの流れをきれいにする。 基本リーダブルコードという書籍を参考にしています。 最初の提案 では、実際のコードをきれいにする前後でGitHub Copilotの提案が変わる例を示したいと思います。ユーザーのロールを設定する機能を実装していた時のことです。この時ロールが変更されているかを判定する変数 isDirty を追加しようとしました。実際にGitHub Copilotが提案してくれたコードが次のスクリーンショットになります。 コードをきれいにする前のGitHub Copilotの提案 この提案は間違っています。ロールが変更されているかを確認するには、変更後のロールを持つ変数 projectUserRoleValue の値と、変更前のDBから取得したロール情報 projectUsers[0].roles.find((role) ⇒ role.type === 'general').role_id とが異なるかを確認する必要があります。そして、これらの変数は isDirty の宣言前には既に揃っていました。しかしGitHub Copilotの提案では、変更後のロールを持つ変数 projectUserRoleValue が何かしらの値を持っていれば、ロールが変更されているという判断を下しています。 このように間違いを提案されるときは、既存のコードが汚くなってきているという目印です。実際前述した変更前のDBから取得したロール情報 projectUsers[0].roles.find((role) ⇒ role.type === 'general') は、ぱっと見では何を表現しているのかわかりません。 改善後の提案 それでは、コードをきれいにするとどうなるでしょうか。先ほどの変更前のロール情報を変数 initGeneralUserRole に代入して、何を表現しているかをわかりやすくします。 const initGeneralUserRole = projectUsers[0].roles.find((role) ⇒ role.type === 'general'); 他にもコードを短く簡潔にしたり、わかりにくいロジックを分かりやすい名前の変数に代入したりとしていきます。その後、再び変数 isDirty を追加しようとすると、GitHub Copilotの提案は次のようになります。 コードをきれいにした後のGitHub Copilotの提案 この提案は合っています。変更前のロール initGeneralUserRole と変更後のロール generalUserRoleIdInProject とが異なっているか比較できてします。 このように既存のコードをきれいにするだけで、GitHub Copilotの提案精度は向上してくれます。 2. 想定と違う提案をされたら英単語の意味を詳細に調べなおす あたりまえではありますが、実装したいロジックとそれに付ける名前とが一致していないときは、GitHub Copilotの提案も実装したいロジックとは異なるものになります。 筆者の英語力では、こういったことがちょくちょくおきます。英単語の正確な意味を誤解してたり、ニュアンスまで知らなかったりして、名前付けを間違えます。そのため想定していたロジックと異なる提案をされたら、名前付けを見直します。特に英単語の意味をきちんと調べるようにしています。 この方法のメリットは次があげられます。 GitHub Copilotの提案が正確になり、以降の開発速度が上がる 名前付けのスキルが向上する 英語の勉強になる 最初の提案 例を挙げます。プロジェクト情報の配列のある要素を移動する関数を実装しているときのことです。このとき移動後の配列要素のインデックス newIndex の１つ前方の要素のプロジェクトを参照する必要がありました。このプロジェクトを持つ変数を formerProjectOfNewIndex として定義しようとすると、GitHub Copilotは次のスクリーンショットのように提案してくれました。 変数formerProjectOfNewIndexの定義に対するGitHub Copilotの提案 この提案は実装したいものと異なります。しかし、これはGitHub Copilotが間違っているのではく、変数の名前が少し不適切です。 辞書で英単語の意味を調べると次のような記述が出てきます。 「former」が形容詞として使われる場合、過去の地位や状態、あるいは以前の時点での事柄を指す。 weblio 実用英語辞典 , 2024/05/28 つまり、 formerProjectOfNewIndex は配列要素を移動させる以前の newIndex の位置にあるプロジェクトという意味になります。formerの意味を軽く検索しただけだと、「前の」という意味が引っかかるので、英単語の正確な意味を誤解していました。 改善後の提案 変数名を見直して、変更した後のGitHub Copilotの提案が次のスクリーンショットになります。 変数名をpreviousProjectOfNewIndexに変更したときのGitHub Copilotの提案 こちらは想定通り newIndex のひとつ前の位置のプロジェクトを変数に代入してくれています。 3. 知らないコードを提案されたら理解して糧とする コードを書いていると、筆者がまだ知らない文法や組み込み関数を使った実装方法をGitHub Copilotが提案してくれる時があります。 こういったとき、時間がない、調べるのが面倒などの理由で提案を無視して、自分の知っている方法で実装したくなります。しかし、できるだけ提案された方法を調べて使ってみるようにしています。 これのメリットは次が挙げられます。 言語への知識が増える その言語の慣習に沿った実装方法が身につく (提案されたものが良ければ)ロジックをより簡潔に記述できる このメリットの中で１番大きいのが「その言語の慣習に沿った実装方法が身につく」だと思います。それぞれの言語にはコードの品質を良くするための慣習があります。 JavaScriptだと配列をfor文で回すのでなく、map関数やreduce関数を使って副作用が起きない純粋な関数として実装するなどです。 GitHub Copilotの提案はこういった慣習に沿った提案してくれることが多いです。そのため、提案してくれたコードを、きちんと理解して使えるようになると自然とコードの品質も良くなっていきます。理解するためには言語リファレンスを調べるなどの労力がかかりますが、1度理解してしまえば自分の血肉となり、以降ずっと使える資産になります。 まとめ 今回紹介したような使い方でGitHub Copilotを使用すると、既存のコードを見直したり、新しい文法や組み込み関数を知るきっかけになります。この習慣を継続して学習を進めることで、言語の習熟が促進されたり、開発スキルの成長が加速していると、筆者は感じています。 GitHub Copilotを使ってみたら開発効率が劇的に向上した話 こんにちは、バックエンドエンジニアのまさです。最近、開発プロセスを効率化するための取り組みの一つとして、Github Copilotを利用しています。この記事では、Github Copilotを使ってみた結果、開発効率が劇的に向上した経験について共有したいと思います。Github ... 　続きを読む　 Sqripts 関連記事｜Sqripts Visual Studio CodeとGitHub Copilotでコーディング効率を革新！AIを駆使した開発ガイド こんにちは。GSです。Visual Studio CodeとGitHub Copilotの組み合わせは非常に強力です。多くの人が「GitHub Copilotを使う＝コード自動補完を使う」と考えているかもしれませんが、Visual Studio Codeのアップデートにより、さらに便利な機能が使えるようになって... 　続きを読む　 Sqripts 関連記事｜Sqripts The post 初心者がGitHub Copilotに振り回されないために first appeared on Sqripts .

テストエンジニアが身につけておきたいスキルの一つ「論理のスキル」。 「論理の言葉」の意味や働きに注意が向くようになったら、文や文章の読み書きで実践していきましょう。 この連載では、「論理スキル“実践編”」と題して、「文章の筋道を把握する、主張を理解する」「文や文章の筋道を組み立てる」ことに役立つ 推論の形 を見ていきます。 ＜テストエンジニアのための論理スキル[実践編]　記事一覧＞ ※クリックで開きます 論理のかたち。推論とは ［全文公開中！］ 基本的な推論形式 今回のテーマは、論理の言葉のうち“または”を用いる推論の形式です。 前回のクイズ解答 問題(再掲) （図2-7 前回の最後に出題したクイズです ） 解答 bの条件は「aに該当せず、かつ、b独自の条件に該当する」＝「aの否定、かつ、b」ですから(図3-1の上)： aの条件の否定(③)：　 NOT (S1 >= 85 AND S2 >= 70) ⇒ (S1 < 85 OR S2 < 70) 　(ド・モルガンの法則) b独自の条件(⑥)と“かつ”で結ばれ： (S1 < 85 OR S2 < 70) AND (S1 >= 85 OR S2 >= 70) (⑦) cの条件は「a, bいずれにも該当しない」＝「aの否定、かつ、b独自の条件の否定」ですから(図3-1の下)： aの条件の否定(③)：　 (S1 < 85 OR S2 < 70) b独自の条件の否定(⑥)：　 NOT (S1 >= 85 OR S2 >= 70) ⇒ (S1 < 85 AND S2 < 70) 　（ド・モルガンの法則） ③と⑥が“かつ”で結ばれ： (S1 < 85 OR S2 < 70) AND (S1 < 85 AND S2 < 70) (⑦) 図3-1 LED点灯条件b, cの真理値表 「該当しない場合」や「そうでなければ」は、プログラムならelseの一言で済みますが、このように敢えて詳細な条件を展開してみることも論理のスキルの向上につながります。 「S1の値が85未満」と「S1の値が85以上」とが同居していて両立するの？　何か間違ったかな？　と思う人は、図3-1で“両立”することを確認してください。 “または”の意味/働きと推論 前提の“または”から結論を導く 論理の言葉“または”の意味・働きをそのまま活かして、 「Aであるか、またはBである」という前提から結論を導く推論の形があります。 図3-2 選言三段論法のイメージ 前提1が選言文（“または”を用いた主張）である三段論法を「 選言三段論法 」といいます。前提2には、前提1から結論を導くための断言文を置きます。 選言三段論法の形式 “タイプA” 選言三段論法の基本的な形は次の通りです（本記事独自の呼称として、 “タイプA” と呼びます）(図3-3)。 ①Pであるか、または、Qである。 ②Pではない。 ③従って、Qである。 図3-3 選言三段論法・妥当な形 “または”(選言)がつなぐ文や語句のことを「選言肢」といいますが、 ふたつの選言肢のうちひとつが否定されれば、残る選言肢が結論になります。 （なお、PとQのどちらを否定しても同じです） 例： ①このエラーコードが出るのは、アクセス制御に問題がある場合か、データに不整合がある場合だ。 ②データには不整合が発見されなかった。 だから、③アクセス制御に問題があると見てよさそうだ。 “タイプB” 次の形は、基本的に妥当ではありません（本記事独自の呼称として、 “タイプB” と呼びます）(図3-4)。 ①Pであるか、または、Qである。 ②Pである。 ③従って、Qではない。 図3-4 選言三段論法・非妥当な形 論理の言葉としての“または”は 包含的 であることに注意してください（P、Qがともに真の場合もあり得る）。 選言肢の一方が真だからといって、他方が偽であることにはなりません。 （PとQのどちらを肯定しても同じです） 例： ①このエラーコードが出るのは、アクセス制御に問題がある場合か、データに不整合がある場合だ。 ②データに不整合が見つかった。 ということは、③アクセス制御には問題はないだろう。 アクセス制御の欠陥とデータの不整合は同時に起こり得るでしょうから、これは妥当な推論ではありません。 「 論理のかたち。推論とは 」の「ネコにはしっぽがあるか、にゃあと鳴く」の例も同じ形になっています。 論理のかたち。推論とは｜テストエンジニアのための論理スキル［実践編］ テストエンジニアが身につけておきたいスキルの一つ「論理のスキル」。「論理の言葉」の意味や働きに注意が向くようになったら、文や文章の読み書きで実践していきましょう。この連載では、「論理スキル“実践編”」と題して、「文章の筋道を把握する、主張を理解する... 　続きを読む　 Sqripts 関連記事｜Sqripts 選言三段論法　補足 排他的選言の場合 ただし、“または”は排他的な意味で使われることがあります（「 “入門編”第5回 文レベルのロジック (1) 」）。 排他的な“または”の場合には、“タイプB”も妥当 になります(図3-5)。 どちらの“または”なのか、主張の内容から判別する必要があります。 （なお、 “タイプA”はどちらの“または”でも妥当 です） 図3-5 排他的な“または”の場合 例： ①この現象が起こるのは、データがゼロ件の場合か、データ件数が上限に達している場合ですね。 ②調べたらデータ件数が上限いっぱいでした。 だから、このトラブルは③データがゼロ件の場合の処理は関係ないと見てよいでしょう。 [第5回] 文レベルのロジック (1)文レベルのAND/OR/NOT テストエンジニアが身につけておきたいスキルの一つに「論理スキル」があります。この連載では、「プログラムのレベル」「文や文章のレベル」に分けて、論理スキルの基本である「論理の言葉」を徹底解説します。今回の第5回から、「文レベルの論理の言葉」に焦点を当... 　続きを読む　 Sqripts 関連記事｜Sqripts 選言肢が三つ以上でも成り立つ 選言三段論法は前提1が三つ以上の選言でも成り立ちます。 その場合、結論は「前提1から、前提2で否定されたものを除いた選言判断」になります(図3-6)。 図3-6 選言肢が3つ以上の場合 選言三段論法 featuring ド・モルガンの法則 連言の否定（「PかつQ、ではない」）から結論を導く、選言三段論法の変形のような形もあります。 ①「Pであり、かつ、Qである」ということはない。 ②Pである。 従って、③Qではない。 「連言の否定は、否定の選言」ですから、ド・モルガンの法則を適用して①を①’に置き換えると、 ①’Pではないか、または、Qではない。 ②Pである。 従って、③Qではない。 となります(図3-7)。 図3-7 ド・モルガンの法則と選言三段論法 この場合、②が一見非妥当な形（“タイプB”）のように見えますが、これは前提1が否定であり、その否定（＝二重否定）だから「Pである」という形になっているものです。 （「①Pではないか、または、Qではない。②Pではない。従って、③Q」は、妥当ではありません） 選言三段論法・気をつけたい落とし穴(誤謬) “タイプB”の形になっているが、前提1が「排他的な選言」でない 繰り返しになりますが、“タイプB”は排他的な“または”でなければ妥当な形ではありません。 “タイプB”の形の論理に出会った場合は、使われている“または”が排他的な意味で使われているのかどうか注意を向けてみましょう。 選言肢不完全の誤謬 「AかBかどちらか」から結論を導くわけですから、前提1で提示される選言肢が主張したい事柄の範囲をカバーできていないと、誤った結論を導いてしまう惧れがあります。 これを「 選言肢不完全の誤謬 」といいます(図3-8)。 図3-8 誤謬・選言肢不完全の誤謬 そもそも、選言肢が不適切 選言肢不完全の誤謬に通じますが、“または”でつなぐのが適当ではないものを選言肢に掲げるのも、前提の正しさを損ねる惧れがあります。 極端な場合を取り上げている（詳細を無視するなど） 関連が薄いか、ないものを選言肢にしている ありうる様々な場合を見落としている etc. 図3-9 選言肢が不適切 クイズ （解答は次回に） 次回 「 基本的な推論形式 」で挙げたうち、「“ならば”を使う推論の形（仮言三段論法）」を取り上げます。 基本的な推論形式｜テストエンジニアのための論理スキル［実践編］ テストエンジニアが身につけておきたいスキルの一つ「論理のスキル」。「論理の言葉」の意味や働きに注意が向くようになったら、文や文章の読み書きで実践していきましょう。この連載では、「論理スキル“実践編”」と題して、「文章の筋道を把握する、主張を理解する... 　続きを読む　 Sqripts 関連記事｜Sqripts 参考文献 近藤洋逸, 好並英司 『論理学入門』 岩波書店 1979 藤野登 『論理学　伝統的形式論理学』 内田老鶴圃 1968 John Nolt, Dennis Rohatyn(著), 加地大介(訳) 『現代論理学 (Ⅰ)』 オーム社 1995 レイモンド・スマリヤン(著), 高橋昌一郎(監訳), 川辺治之(訳) 『記号論理学　一般化と記号化』 丸善出版 2013 図版に使用した画像の出典 Loose Drawing 人物画をお借りしています。 テストエンジニアのための論理スキル[実践編]  連載一覧 論理のかたち。推論とは  【連載初回、全文公開中】 基本的な推論形式 The post “または”を使って推論する｜テストエンジニアのための論理スキル［実践編］ first appeared on Sqripts .

こんにちは！　テストエンジニアのマツキョーです。みなさん読書はお好きですか？ 最近はもっぱら実用書ばかり読んでいますが、たまに小説を読むと文章の楽しさを再確認します。小説の楽しさは様々ですが、私は文章の行間に隠された登場人物の行動や感情を読み解くことに楽しさを感じます。なぜなら、文章の行間には著者が読者に気づいてもらいたいことがあると思うからです。それに、もしかしたら著者も意図していない気づきだってあるかもしれません。 人間が書く文章には、意図している、していないにかかわらず、行間が生まれてしまうものだと思います。私たちテストエンジニアにもなじみ深い開発ドキュメントも例外ではありません。そして開発ドキュメントの行間には、隠された仕様……「暗黙の仕様」が眠っている可能性があります。 「暗黙の仕様」とは、開発ドキュメントに記述されていない仕様のことです。この「暗黙の仕様」は、仕様に書かれていないため開発段階で考慮されないリスクがあります。考慮されていなければ当然ながら実装から漏れることになり欠陥が混入することになります。 QAでは、このようなドキュメント上の欠陥を検出するプロセスとしてレビューなどの静的テストを行います。 JSTQB FoundationLevel シラバス でも、シフトレフトアプローチとして以下のように記述されています。 テストをする観点から仕様書をレビューする。このような仕様書のレビュー活動では、曖昧さ、不完全さ、矛盾など、潜在的な欠陥を発見することが多い。 JSTQB-SyllabusFoundation_VersionV40.J01 > 2.1.5 シフトレフトアプローチ この記事ではドキュメントの行間を読み解いて「暗黙の仕様」を明らかにするためのアプローチを5つ紹介します。 ドキュメントの行間を読み解くとは？ ドキュメントの行間とは？ テスト設計をするとき、仕様ドキュメントに書いてあることをコピペすればテスト項目書が完成するわけではありません。なぜなら、ドキュメントに書かれていることが仕様のすべてではないからです。ドキュメントに書かれていなくても、存在するはずの状況や条件があります。たとえば、「～になると活性する」という仕様記述があれば、当然「非活性」の状態も存在するはずですよね。このような明記されていないけれども存在する仕様が開発ドキュメントの行間です。 行間を読み解くとは？ ドキュメントの行間には様々なパターンが存在します。以下はドキュメントの行間の一例です。 ・仕様記述にない条件・状況・パターン ・複数のドキュメントの隙間にある観点 ・テスト対象のシステムとその動作環境との相互作用 このようなドキュメントに明記されていない情報を見つけだしていくことが行間を読み解くということです。 ドキュメントの行間を読み解くにはどうするか？ 行間を読み解くのに必要不可欠な能力として想像力があります。想像力により文字から実際の動作をイメージすることで隠れた仕様である「暗黙の仕様」を見つけ出します。しかし文字から動作をイメージするというのは意外と難しいものです。想像力を補って動作のイメージを助けたりヒラメキを得やすくして「暗黙の仕様」を見つけだす可能性を高めるためには工夫が必要です。 ここからは、実際に私も使用している行間を読み解くためのアプローチを紹介します。 ドキュメントの行間を読み解くアプローチ５選 図表を作って可視化する ドキュメントの行間を探すには、頭の中ではなく目で見える状態にするのが効果的です。情報を目に見えるかたちで表現することで、曖昧さや抜け漏れが見つけやすくなります。ロジックツリー、マインドマップ、ダイアグラムなどの手法を使うと、情報が整理されてより行間を見つけやすくなると思います。それぞれの手法については、詳しく紹介しているWebサイトなどを参照してください。 思考法を活用する フレームワーク思考、仮説思考などの思考法はビジネスパーソンにとって必修科目となりつつあります。もちろんドキュメントを読み解く行為においても、思考を補助して素早い理解と疑問の洗い出しを可能とする思考法は効果的です。情報を可視化する手法と組み合わせることで、さらに大きな効果が期待できます。それぞれの思考法についても、詳しく紹介しているWebサイトなどを参照してください。 他者と会話する テスト設計などでドキュメントを読み込むとき、1人で読む人が多いのではないでしょうか。1人で読んで完全に理解したと思った時でも、一度他者と会話してみることをオススメします。人間には主観や認知バイアスといった思考を縛る特性があります。完全に理解したと思ったドキュメントでも、他者と話したり質問されることで理解不足や新たな視点に気づくキッカケになることは多くあります。また、会話は最も手軽なアウトプット手段でもあります。チームメンバーと積極的にコミュニケーションすることでより深く正確にドキュメントを読み解くことができると思います。 実際に動かす すでに動作するモックや類似システムがある場合は、実際に動かしてみることで理解が深まることがあります。感覚的にシステムを触ったあとで、ドキュメントを読み直すことで曖昧だった部分が鮮明に理解できたり、新しい発見を得られることも多くあります。 私がまだ駆け出しのころ、仕様ドキュメントからの情報のみでテスト設計をするべきだと思っていた時期がありました。もちろん仕様ドキュメントをベースとすることは重要ですが、理解するための補助という点では実際に動かす方が圧倒的に早く理解を深められます。ただし実際の動作を想定された仕様だと錯覚しないように注意が必要です。 時間を空ける ドキュメントを長時間読み続けている時、一度ドキュメントを読むという行為から離れて少し時間を空けることも効果的です。見たり読んだりした情報は脳で処理されて理解に至りますが、情報によってはすぐに理解まで至らない場合があります。そんな時、さらに情報を詰め込んでいくのもいいですが、一度頭をクールダウンすることでいつのまにか頭の中の情報が整理できていたり、ふっと新鮮な発見が思い浮かんだりすることがあります。 さいごに これらのドキュメントの行間を読み解くアプローチを活用すれば、様々な工程で課題を早期発見できる可能性が高まります。ドキュメントの行間に隠れた「暗黙の仕様」には、明記されていないという性質から欠陥が潜んでいる可能性が高いからです。そのためドキュメントの行間から「暗黙の仕様」を見つけ出すことは、QAエンジニアに求められるスキルの1つであると私は考えます。「暗黙の仕様」は多くの場合、予定している工数に含まれないため、読み解いた「暗黙の仕様」からテストを設計する時はステークホルダと相談して効果的に取り入れていきたいですね。また、要件や仕様レビューなどの上流工程であれば、ドキュメントの行間を読み解くことで課題の早期発見となり、大幅なリスク軽減とコスト削減が期待できます。今回紹介したアプローチを活用し、想像力を働かせて開発ドキュメントを読み解き、品質向上に貢献していただければと思います。 The post 開発ドキュメントの行間を読むためのアプローチ5選 first appeared on Sqripts .

はじめまして、KMです。 昨今はモバイルWi-Fiやキャリア回線でのテザリング等で、自宅でも外出先でもPCをネットワークに接続できる便利な時代になりました。 一方、環境要因や接続機器要因等で、サイトの読み込みや保存に時間がかかってしまうといった事象に遭遇してストレスに感じてしまう方も多いのではないかと思います。読み込みに時間がかかっても正常に動作するのであれば特に問題があるというわけではありませんが、中には通信速度の低下が原因で重篤な不具合が発生するケースもあります。 私が対応している業務でWebサイトのテストに関わることが多いのですが、過去にPCとスマートフォン（以下スマホ）のWebテストを実施中にスマホの通信状況が悪いタイミングで画面の表示崩れが発生したことがあります。 その際、クライアントからPCも含めて同様の現象が他の画面でも発生していないか確認して欲しいと依頼があり、通信速度低下のテスト方法を調査しました。 スマホの場合は、通信速度の制限やアクセス集中によって速度低下状態となる事があるため容易に再現する事が可能だったので、PCでも再現できないか調査したところ意図的に速度低下状態にする方法が見つかり、テストを実施した結果重篤な不具合も検出することが出来ました。 今回は、通信速度低下による重篤な不具合発生のリスクをテスト段階で可能な限り取り除けるように、意図的に通信速度低下状態にする方法と、テストによって実際に検出できた不具合を紹介したいと思います。 過去に発生した不具合紹介 まずは、実際に通信速度低下状態でのテストを行った際に検出できた不具合を紹介させていただきます。 事例1：通信速度低下状態で登録完了画面に遷移すると入力データの一部が欠損 Webサイトで個人情報を入力して会員情報の登録をする画面で、通信速度低下状態で登録完了画面への遷移を行い、読み込み中に通信速度を通常に戻して読み込みを完了させると、入力データの一部が欠損する不具合が発生していました。 こちらは通信速度低下状態で遷移を行ってから通常の速度に戻って登録完了になった場合、低速で読み込んでいたデータ部分しか保存されなかったというのが原因でした。 事例2：通信速度低下状態で登録完了を行うと完了メールが送信されない 登録完了画面に遷移した際に完了メールが送信されるという機能があるサイトにおいて、通信速度低下状態で登録完了画面に遷移すると、完了メールが送信されない不具合が発生していました。 こちらは通信速度低下状態で登録完了に遷移すると完了失敗の判定になっていたことが原因でした。 このように、実際に通信速度低下のテストを行うことで、データの欠損や完了失敗の判定となる等の重篤な不具合が検出される場合があることから、表示確認以外にもデータの読み込み、入力等の特定の画面に対しては通信速度低下状態でのテストを行う必要性を感じることができたのではないかと思います。 では次に実際に通信速度を低下させる方法を紹介します。 デベロッパーツールの設定手順 今回紹介する方法はブラウザの機能となるため、Chrome、Edge、Firefoxがインストールされている全てのPCで使用可能となります。 ※Safariに関してもデベロッパーツールと同様の機能「Webインスペクタ」がありますが、通信速度の変更を行うためには無料ツールの「Xcode」と「Additional Tools for Xcode」のインストールが必要となりますので今回は割愛します。 ChromeとEdgeの設定手順 1　Chrome(Edge)を起動する 2　その他のツールからデベロッパーツール(開発者ツール)を起動する 3　「Network」を選択する 4　扇形の通信アイコンを選択する 5　画面下に「Network conditions」が表示されることを確認する 6　「Network throttling」のプルダウンリストから「Fast 3G(Slow 3G)」を選択する 7　確認したいWebページに遷移すると通信速度が制限された状態になる 8　元の速度に戻したい場合はプルダウンリストの「No throttling」を選択する ※デベロッパーツールが起動しているタブのページのみ通信速度の影響を受けます。 ※一例として「Slow 3G」を選択して画面遷移→画面読み込み中に「No throttling」を選択すると一時的に地下鉄でスマホを使用しているような通信速度低下状態を再現できます。 また6の「Network throttling」のプルダウンリストから「Add…」を選択し、設定を行うことで任意の速度にすることも可能となります。 9　「Add custom profile…」を選択する 10 　下記入力欄に任意の値を入力する Profile Name：任意の名前 Download(下り速度)：インターネット上にあるデータをダウンロードする速さ Upload(上り速度)：手元のデータをインターネット上にアップロードする速さ Latency(遅延速度)：疎通確認と同時にデータを送信してから返ってくるまでの応答速度 ※Latencyの時間が長いほど、下り速度および上り速度が速くても表示に時間がかかります。 11　入力が完了したら「Add」を選択する 12　追加が完了したら画面右の「×」を選択する 13　「Network throttling」のプルダウンリストから作成したCustomを選択する 以上で設定通りの通信速度でブラウザ操作が可能になります。 Firefoxの設定手順 1　Firefoxを起動する 2　その他のツールからウェブ開発者ツールを起動する 3　「ネットワーク」を選択する 4　「帯域制限なし」のプルダウンリストから任意の制限を選択する ※以下がFirefoxのプルダウンリストにある大まかな速度表記になり、Chrome、Edgeと異なり、カスタム設定は出来ません。 デベロッパーツールで設定した速度表示の確認 速度表示の確認ができるサイトで実際に通信速度が制限されているかを確認してみました。 ・デベロッパーツールで速度制限を設定していない画面 ・デベロッパーツールで「Slow 3G」を選択して速度制限を設定した画面 このように、デベロッパーツールのプルダウンリストを切り替えるだけで速度制限の状態を簡単に再現することが可能です。 通信速度低下状態に設定する際の注意点 低速にすることによりWebページの読み込みに時間がかかり、表示されるまで操作できない状態になるため通常のテスト実施を行うよりテスト工数がかかります。 そのため全ての画面で通信速度低下状態でのテストを行うことは現実的ではないので、「過去に発生した不具合紹介」でも記載したような、データの読み込み、入力等の特定画面のみの限定的な使用にする必要があります。 またデベロッパーツールで容易に速度変更を行えますが、Webページの作りによっては使用を想定していない場合もあるので、クライアントとの事前確認を行ってから使用する必要があります。 まとめ PCのブラウザ機能となるため、Safari以外のブラウザ（Chrome、Edge、Firefox）ではインストール等必要なく使用が可能で、通信速度が低下する現象も容易に再現が可能となります。 テスト工数がかかるデメリットもありますが、紹介した不具合のように重篤な不具合を発見することができる可能性がありますので、データの読み込み、入力等の画面では通信速度低下状態でのテストも、品質を担保するために効果的なのではないかと思います。 本記事が皆さんのお役に立てれば幸いです。 The post デベロッパーツールで通信速度を低下させる方法について first appeared on Sqripts .

この連載では、ITエンジニアにとって親和性が高く「スキルアップしたい」と思う方にとっては役に立つであろう知的生活について、いろいろなアクティビティやツール、仕事での活用方法などについてご紹介します。知的生産・知的生活の考え方や、「そもそも知的生活とはどうあるべきか」等の話ではなく、できるだけエンジニアの普段の生活や仕事に役立てられるテクニックよりの話をするつもりです。 前回 の記事では、知的生産・知的生活とは何かや、エンジニアにとってなぜ必要なのか等について触れました。 その中で、知的生産を単純化したモデルとしての インプット→処理→アウトプット という形が登場しました。 今回は、とくにインプットとその後の処理に重要となる、知的生活の母艦としてのツールについて紹介します。 【第1回】知的生活とはなにか？エンジニアにどう関係するのか みなさんは、知的生産や知的生活ということばを聞いたことはありますか？初めて聞いた、という方はもしかしたら「堅そう」とか「えらそう」といった印象を持つかもしれません。ところが、私はこの知的生産・知的生活は「ITエンジニア皆に知っておいてほしい」と考え... 　続きを読む　 Sqripts 関連記事｜Sqripts 知的生活の母艦とは 前回の記事で、私は”知的生産”を アウトプットである「なにかあたらしい情報や価値」を出すために、いろいろなインプット＝情報をあつめて、自分の頭やいろいろな道具を使って処理＝思考をすること とし、この知的生産を日常生活の中に取り入れ、ひとつの楽しみとして行うことが”知的生活”であると考えていると書きました。 なんらかのインプット、たとえば読書やインターネットでの調べ物などを行って得た情報を元にしてあたらしいことがらを生み出す処理をする。 この過程では、インプットした情報をためておくところ、それも、できるだけ処理の都合がいいようにためておくところが必要になります。 人間は、一度見聞きしたものをすべて記憶しておくことはできません。なにか情報をインプットしたとしても、頭で記憶しておくだけではいずれ忘れてしまいます。それでは、何か新しいことを生み出すための材料として使えません。 そのため、知的生活と、情報をためておく行為およびその道具とは不可分な関係にあります。 情報を記録し、あとで処理しやすいようにためておく。 コンピューターが普及する以前には紙を中心に記録と整理を行う手法もありましたが、現在ではさまざまなデジタルツールがあるため、PCやスマートフォンのアプリケーションを用いるのが一般的となっています。 この、情報をためておきつど見返すためのツールを、ここでは知的生活の母艦と表現しています。思考のホーム、などと表現をする方もいますが、「自分がインプットした情報は基本的にここにある」という場のことを意味しています。 読書メモや仕事中に同僚からもらったアドバイス、Googleで検索をしてなにかのエラーを解決した際の記録などがいろいろなツール・場所に散らばっていると、「前にメモしたアレどこだっけ・・・」となるのは明らかです。 また最終的に何かあたらしいことがらをアウトプットするには、インプットした情報Aと別のところからインプットした情報Bを組み合わせて発想する、ということもよく行われます。 このように、情報が母艦という一箇所にまとまっていることで 探す場所に迷わずに済む 情報どうしのつながりによって発想が得られる という、情報を「貯める」ことと「生み出す」ことの両面にメリットがあるのです。 ツールの種類と選び方 そのような知的生活の母艦、すなわちインプットした情報をためておくための場所・ツールは、個人の好みや使い勝手に応じていろいろな選択肢があります。 極論としては「お好きなものを使いましょう」になるのですが、それでは迷ってしまうので、ここではいくつか選び方・具体例について紹介します 選ぶポイント1：クラウドサービス、もしくはクラウド同期があるか クラウドサービス、もしくはクラウド同期が可能なツールはPC・スマートフォン・タブレットなどさまざまな環境から同じデータにアクセスでき、知的生活の大きな支えになります。 発想やアイデアは、いつでもどこでもメモできる状態にあることが重要です。「何探してたんだっけ」「何ググろうと思ってたんだっけ」という経験、ありますよね。 特定の道具、特定の環境でしかメモできない状態では、アイデアが飛んでしまいます。紙にメモしておいてあとでツールに転記することもできますが、多くの場合面倒になってメモしなくなります。 クラウドサービスもしくは同期機能のあるツールを使うことで、メモをスマートフォンでとっておいてあとからPCで整理や追記をする、といった使い方が可能です。 昨今の代表的なツールとしては、 Notion Cosense（旧Scrapbox） Obsidian Logseq Dynalist などが挙げられます。 逆に、クラウドサービスでないローカルアプリケーションで、クラウド同期をしないで使えるツールが必要な場面もあります。 たとえば職場では、個人のクラウドサービスをそのまま使うことはNG、という場合も多いでしょう。仕事上のナレッジをためておきたいけれども、会社標準のクラウドツール以外は申請が面倒・・・という場合は、ローカルでのみ動作するツールを選択するのも手です。 選ぶポイント2：蓄積する情報や形式 ポイント1で挙げたツールには、それぞれ蓄積する情報や形式によっての得手不得手があります。 たとえばNotionなどは、ツール内部でデータベースを作ってかなり自由度の高い表示ができます。Cosenseは情報＝ページ間のつながりを簡単に作成できるのが特徴で、蓄積した情報間の思いがけないつながりが見えるなど、情報同士を組み合わせて新しい価値を生み出すのに向いています。 Cosenseの例として、私が（最近は編集していませんが）公開しているCosenseのページをご覧いただくと、少しイメージがつかめるかもしれません。 ■ いとうよ式.out デフォルトでは上の画像のように情報＝ページがカードのように並んでいて、たとえば読書メモをとったり、思いついたことをメモしたり。人によってはこれをブログとして使っている方もいます。 他にも、情報を文章や画像、リンクなどを中心にまとめられる「デジタルノート」としてのツールや、箇条書き形式のテキストやデータを作成・編集できる「アウトライナー」などさまざまなツールがあります。 代表的なアウトライナーとしては、WorkflowyやDynalistなどのツールがあります。 私はDynalistをよく利用していて、このSqriptsの原稿もアウトライナーを利用して構成を作成しています。 母艦として利用するうえでアウトライナーは若干のクセがあるため、個人的にはデジタルノートとして使えるObsidianやCosenseがオススメです。 Notionも非常に強力なツールではありますが、そのぶん「どう使っていいかわからない」になりやすいと感じています。 母艦の私なりの使い方 ここでは、知的生活の母艦をどのように使っているのか、私の実例をお見せします。 私は主にObsidianを母艦として使い、補助的なツールとして先に触れたDynalistを使っています。 Obsidianは「ノートアプリ」等と呼ばれることもあるツールで、Markdownファイルを管理・編集できるものだと考えてください。プラグイン等を用いてさまざまなことが出来ますが、基本はvscodeのようなエディターでMarkdownファイルを作成・更新するのとかわりありません。 ここで書いている使い方はObsidianに特化したものではなく、他のツールでも同じようなことができます。 さて、そのような母艦としてのObsidianの使い方ですが、まず私は 毎日の記録 読書をしたメモ 仕事中、もしくは日常生活で感じた疑問 その他「思いついたこと」 などの情報は基本的にすべてObsidianに記録しています。 私のObsidianのフォルダー内の一部はこんな状態になっています。 キーワードだけを書いたメモもあれば、中身をたくさん書いているページもあったりと、わりとバラバラです。 誰かと会話をしていて得られたアイデアや、ひとり黙々と仕事をしているときに浮かんできたアイデアや疑問などをObsidianに書き留めるようにしています。 このObsidianを毎晩眺めて、気が向いたページに内容を書き足して、少しずつ中身を育てています。 そして、Webメディアに記事を書く際などはこのObsidianの中で気になったページを見返したり、複数のメモ・ページの組み合わせで一つの記事の案を考えたりするのが主な使い方です。 活用のコツ 母艦を活用する際は、「＊＊＊の活用方法」などの記事をあまり真に受けすぎないことです。 世の中には（私も含めて）ツールを活用することそのものが大好きな人がいて、たくさんのすばらしい使い方が日々発信されています。 ただ、だからといって全員が全員ツールを使い倒す必要はなく、100%使いこなせなければだめということはありません。 ツールの使い方は基本的に自由なので、まずは複雑なことをするのではなく触ってみるというスタンスが大事です。 とくに知的生活において、大切なのはツールを使い倒すことではなく、 せっかく集めた情報や発想を失わずに蓄積しておく 集めた情報や発想をもとに、アウトプットする ことです。これらが実現できるのであれば、紙とペンでも、ルートフォルダーとテキストファイルをただ突っ込むだけでも、手段はなんでもよいのです。 細かい使い方はさておき、まずはインプットを一か所にまとめてみよう 今回は知的生活のポイントとなる、インプットした情報やアイデアをためておく母艦としてのツールについて紹介しました。 私が普段使っているから、という理由でObsidianをベースにご紹介しましたが、もちろん他のツールでもかまいません。最近は多数のツールがあるため、しっくりくるものを探していろいろと試してみるのもよいでしょう。 その際は1点「とりあえずそのツールにメモやノートなどをまとめる」という点を実践できればOK、と私は考えています。つい目に入ってくる、誰かのテクニカルな使い方、などは気にしすぎる必要はありません。ここを気にしすぎると、ツールを使いこなさねばという義務感に駆られてしまい、知的生活自体を楽しめなくなってしまいます。 よりシンプルに「前にメモしておいた内容が役に立った！」とか「ページが増えてきてなんとなくうれしい」とか、ちょっとした効果が得られたらOKです。これを繰り返すことで、最終的には仕事が捗るようになったり、プライベートでのアウトプットにつながったりします。 まずは気軽に、知的生活の母艦となるツールを決めてそこに情報を集約するところから始めてみてください。 【第1回】知的生活とはなにか？エンジニアにどう関係するのか みなさんは、知的生産や知的生活ということばを聞いたことはありますか？初めて聞いた、という方はもしかしたら「堅そう」とか「えらそう」といった印象を持つかもしれません。ところが、私はこの知的生産・知的生活は「ITエンジニア皆に知っておいてほしい」と考え... 　続きを読む　 Sqripts 関連記事｜Sqripts The post 【第2回】知的生活の母艦としてのツールを選び、活用する first appeared on Sqripts .

こんにちは、QAコンサルタントのツマミです。 皆さま、先日JIS ※1 スキーのツマミが報告しましたコラム、 JIS Z 8520:2022「人間工学－人とシステムとのインタラクション－インタラクションの原則」 はご覧いただけましたでしょうか。「インタラクションの原則」を知ってくださった方に是非お勧めしたいJISがありまして、またしても出張ってまいりました。 JISさんぽ (01) JIS Z 8520:2022「人間工学－人とシステムとのインタラクション－インタラクションの原則」 こんにちは、QAコンサルタントのツマミです。唐突過ぎますが私ツマミ、JIS（日本産業規格：Japanese Industrial Standards）が大好きです。お客様のプロダクト品質やプロセス品質の課題に対して何か基準は無いか、定義や分類法は無いかと探ると何かしらのJISに行き当... 　続きを読む　 Sqripts 関連記事｜Sqripts という訳で、次なるさんぽはJIS Z 8522:2022「人間工学－人とシステムとのインタラクション－情報提示の原則」。今日もまた、ゆるゆると楽しんでまいりたいと思います。 どうぞ皆さま、ちょっとした気分転換としてこのJISさんぽにお気楽にお付き合いの程、よしなに願い奉ります。  ※1 　JIS：日本産業規格（Japanese Industrial Standards） 今回のJIS JIS Z 8522:2022「人間工学－人とシステムとのインタラクション－情報提示の原則」とは この規格は前回ツマミがご紹介した JIS Z 8520:2022「人間工学－人とシステムとのインタラクション ※2 －インタラクションの原則」と同じく「人とシステムとのインタラクション」に関係するJISです。人とシステム（サービスであったり、プロダクトであったり）との間でのやりとり(インタラクション)について、システム側はどの様に情報を提示するべきかという原則がまとめられています。 残念ながら JIS Z 8520 と異なり例は少なく、 JIS Z 8520 が７つの原則に関して141例あったのに対し JIS Z 8522 は6つの原則に関して57例と約1/3の量に留まっています。これは例にあがっていることをそのまま製品やサービスの一部に当てはめても使いやすくならないからかもしれません。あるいは、もっと優れた設計解を考えて欲しいということかもしれません。 ※2　インタラクション(Interaction)：相互作用，相互の影響　Weblio英和辞典 なぜ、このJISを選んだのか 例が少ないにもかかわらず今回 JIS Z 8522 を選んだのは、前回の「JISさんぽ」で JIS Z 8520 を知って、ご自身が担当する製品やサービスを「もっと、もっと良くしたい！」と思ってくださった読者の方に改善の手掛かりがあることをお知らせしたかったからに他なりません。 JIS Z 8520 に添付されたチェックリストで問題を検出した時、ユーザーテストで被験者がどうしても先に進めない様子を目の当たりにした時など、問題があることは分かっても「何が、あるいはどこが問題なのか」は分からないことがしばしばあると思われます。ユーザーや被験者がどうして躓いて(つまづいて)いるのか、どこで躓いているのかについてこの JIS Z 8522 が「情報提示」という切り口で手掛かりを与えてくれることでしょう。 道行 まえがき、序文 まえがきは8行。前半で「一般社団法人人間工学会」と「一般財団法人日本規格協会」が原案を出したと記載されています。それとJIS Z 8522:2006からの改訂であること。 JIS Z 8522 とJIS番号と前版の年度が異なるだけで他は一字一句同じです。後半4行で示されている「この規格が著作権法で保護対象になっている云々」も全く同じです。「一般社団法人人間工学会」が関わっている点、改訂年度が2022年と揃っている点に、 JIS Z 8520：2022 と JIS Z 8522：2022のセット感を否応なく感じるツマミです。 序文も JIS Z 8520 とほぼお揃い。JIS Z 8522 には技術的変更に「一部の用語及び定義を削除」されている点と文章に側線が施された箇所がある点が JIS Z 8520 との様式的な違いのようです。 1章　適用範囲 この適用範囲で「モダリティ」という重要な言葉が登場します。「モダリティ」は3章の「用語及び定義」で「人間の感覚に基づくインタラクションの方法」であり情報通信技術で最も使われるのは「視覚、聴覚、触力覚」の３つであると補則が入っています。そしてこの章では「視覚、聴覚、触力覚の３つのモダリティ」を通じて「提示情報を（ユーザーが）知覚及び理解することに適用する」と述べられています。 つまり、システムが「見せたり、聞かせたり、触れさせたり（または押したり引いたり）」していることをユーザーが気付けるか、理解できるかについて述べられているのです。 ユーザーテストでユーザーや被験者が戸惑っているのを見て「えっ、マウスカーソルのすぐ横にボタンがあるやん」とか「なんで正しいボタンを押す直前に全く関係ないボタンとの間で迷うかな」とか思ってショックを受けた方、是非 JIS Z 8522 の4章～6章を読んでください。多分原因に気付けます。 2章　引用規格 JIS Z 8341-6：2013　高齢者・障害者等配慮設計指針－情報通信における機器、ソフトウェア及びサービス－第６部：対話ソフトウェア」の一部又は全部が本JISの要求事項だと述べられています。因みにJIS Z 8341 に記載されていることは具体的で最大公約数的な配慮事項です。プロ向けや専任者向けなどユーザー層を絞ったり、「県外から○○市に引っ越してきた方」など状況を絞ったりした際の製品やサービスとしての使いやすさを考えた場合、考え方を示している JIS Z 8522 の方が応用できるのではないかとツマミは考えています。 3章　用語及び定義 ここでは17の用語が定義されています。ですが（17の用語の内）5つの用語は「対応する国際規格で定義しているけれど JIS Z 8522 では使われている意味が違うため不採用」とされているのです。どういった用語なのか興味がある方は是非本JISを確認してみてください。  ここで寄り道。16個目の用語「ユーザビリティ」、17個目の用語「ユーザエクスペリエンス」には側線が引かれているのですが、側線にはどういった意味があるかご存知でしょうか？実は側線や下点線は、国際規格を基にして JIS を作成した時に、基の国際規格から編集上の変更や技術的差異が発生した時に使う記号になっています。  JIS Z 8522 にも色々な所に側線や下点線が引かれていますが、では側線と下点線の違いは何かご存知ですか？ これは線を引く文章の量にあるようです。JISを作成する際のきまり（JIS Z 8301 ※3 ）がJISにはあります（この JIS Z 8301 や関連JISがまた面白いのですが、それはまたいつか取り上げてみたいと思います）。併せて作成の手引き ※4 が用意されていますが、その8.3項に「編集上の変更及び／又は技術的 差異に該当する箇所が続けて 1 ページ近くにわたるときには，読みやすさという観点から，点線の下線ではなく，通常，側線を用いるのが望ましい」とあるのです。誰得なトリビアかもしれませんが、ツマミは本JISで違いに気付き、初めて興味をもって調べたところ使い分けがあることを知りました。 ※3　JIS Z 8301 「規格票の様式及び作成方法」10.3 引用又は参照する場合の表し方 ※4　 JIS原案作成のための手引き（第21版） 4章　情報提示の概要 4章は4.2項「モダリティとメディア」に記載されている次の言葉さえ押さえておけばいいんじゃないかと思っています。 「ユーザーは、情報を理解（その意味を特定）する前に、提示情報を知覚（感知）しなければならない。」 ですが折角のさんぽ。ゆるゆると各項目を眺めていきましょう。 4.1　情報提示に関するISO 9241-100 規格群の出典及びその関係 4章では最初に他のISOやJISの他、企業が定めているガイドラインとの関係について言及されています。 JIS Z 8520が示す一般的推奨事項の内、情報を提示する際の原則や一般的推奨事項が JIS Z 8522で示されていること。更にISO9241-125など他の規格では特定領域における推奨事項や要求事項が示されていること。 企業や業界でのガイドラインにおける具体的な個々の作法に対して確立したり評価したりするときに本JISや関連するISO規格を使って欲しいと記載されています。いや、使って欲しいとまでは記載されていませんでした。「ISO規格における情報提示に関する規格群は、上記の”標準化された規約（ガイドラインに書かれている個々の作法などですね）”を確立又は評価する際に適用する。」と記載されています。 例えばガイドラインに「アクティブなウィンドウのタイトルバーは青にする」と記載されていたら、絶対に青にする必要があるのか、どうして青にする必要があるのかなどを裏付けたり、青色が適切であるか判断したりするために本JISや関連するISO規格を使うということですね。 4.2　モダリティ及びメディア モダリティとは「人間の感覚に基づくインタラクションの方法」だと3章の「用語及び定義」に記載がありました。ここでは更に具体的に人間の「見る、聴く、触れる、嗅ぐ、味わう」の五感に基づいていると記載されています。情報通信システムでは「見る、聴く、触れる」が主に利用される感覚なので本JISでの推奨事項はこの３つの感覚（三感？）を代表にするというお断りが述べられています。 また、メディアとは1つ以上のモダリティに対して情報を提示するための手段であると定義されていて、メディアにおいてテキストは複数のモダリティが扱えるよう（音にしたり図にしたりと）形を変えやすいけれど非テキストは（インパクトが出せるけど）形は変えづらいということが述べられています。 そして「ユーザーは、情報を理解（その意味を特定）する前に、提示情報を知覚（感知）しなければならない。」から、情報提示に気付けなかったり、提供されたモダリティが利用できないと提示された情報をスルーしてしまったりすることがあると記載されています。 4.3　アクセシビリティ ここでは、プラットフォームが提供するアクセシビリティサービスを使って支援技術と連携することを定めています。 4.4　ユーザーに対する行動のガイド 情報の提示の仕方として、あれこれ指示をするのではなくユーザーの行動をサポートするように勧めています。 4.5　提示情報の審美性 審美的な効果（フラッシュや音、振動など）はユーザエクスペリエンスを向上することもあるけどユーザビリティを低下させることもあるから気を付ける必要があると記載されています。 審美的な効果は、情報の受け手側の文化だけでなくその時の周りの環境や受け手側の気分や体調によってプラスに働いたりマイナスに働いたりすることがあります。適切な情報提供ができるよう、是非早い段階からユーザビリティチェックやユーザーテストを行うことをお勧めします。 5章　原則の概要 さて、いよいよ本JISの本題に入っていきます。 ここでは次の6つの原則が示されています。 ①気付きやすくする、②注意を逸らさないようにする、③区別しやすくする、 ④解釈しやすくする、⑤簡潔にする、⑥内部一貫性及び外部一貫性を保つ この6つの原則は 5.3項「個々の原則間の関係」 で述べられているように、一方の対策を強化すると他方が悪化したりとトレードオフの関係になることもままあります。 このため、エンドユーザーや環境などを考慮して優先事項を決めていくことが推奨されています。 6章　原則及び推奨事項 ここは是非、本JISを読み込んで欲しい所です。p.9後半からｐ.20に亘って記載されており、1つの原則に対して数個の推奨事項が挙げられています。具体例は、あったり無かったりします。良くある対策として他の対策と競合しづらい例が挙げられている印象をツマミは抱きました。 皆さんに目を通していただくきっかけになるよう原則と推奨事項をまとめておきます。 6.1　気付きやすくする a)目立たせること、b)タイムリーに提示すること、c)コントロール部品を気付きやすく設計すること、d)（続きがあるなら）続いていることがわかるようにすること 「（続きがあるのに）続いていることがわからない」のはWebカタログなどのユーザー評価で良く見つかる指摘事項です。画面内にアイテムが綺麗に収まっていて続きがあることに気付けない。更におしゃれな細いスクロールバーはマウスオーバーしないと目立たないため「コントロール部品が気付きづらい」という合わせ技が発動。配慮を忘れると「ユーザーテストの被験者がことごとく目当ての商品を見つけることができずページを離脱する」といった悲劇が起こりがちな原則です。 6.2　注意を逸らさないようにする a)注意を逸らすことを回避する、b)注意を逸らすことを最小限に抑える 少し禅問答のような原則と推奨事項ですが、メインの情報より広告が目立つようなつくりを避けたり、音声で情報を提示する際は背景音を予め絞ったり、消音できるようにしたりすることが具体的な対策例となります。 6.3　区別しやすくする a)情報を構造化する、b)情報に応じた属性を付与する、c)近接の法則を利用してグループ化する、d)類同の法則を利用してグループ化する 「情報の構造化」は設計者の腕の振るいどころ、将来的に情報や導線が増えたり減ったりすることも視野に入れて構造化を図ってください。 6.4　解釈しやすくする a)意味を理解しやすくする、b)意味を明瞭にする、c)（ゲシュタルトの）閉合の法則の利用、d)文章に統一性がある、e)メディア及びモダリティの適切な選択及び利用、f)ユーザーの能力への配慮 「解釈しやすくする」と言っている端から「閉合の法則」とか意味の分からない単語が出てくるのは何だろうと思ってしまうのですが、情報に欠けがあると欠けた部分を補って完全なものとして認識しようとする情報の受け取り方の傾向だそうです。そのような傾向がなぜ「解釈しやすくする」ことに使えるのかは是非、本JISに当たってくださいね。 6.5　簡潔にする a)内容の簡潔さ、b)手段（操作法）の簡潔さ ここは、推奨事項通り簡潔で分かりやすい原則ですね。全くその通りだと思います。 6.6　内部一貫性及び外部一貫性を保つ この項だけ”a)”といった書き方と異なるので、記載ルールの一貫性が保たれていません。態と一貫性を崩すことで一貫性の重要さを伝えようとしているのでしょうか？ システム内で使う用語が一意に定まっていることやHELPボタンをクリックすると必ずHELPが表示されるといったシステムと利用者間におけるお約束がしっかりと守られている方が分かりやすいということです。 画面の一部を改修する時にUIの一部だけを修正すると使いづらくなってしまう事もありますので、ユーザビリティを改善しようとする場合は従来のユーザビリティが今一つなシステムの一貫性を破綻させずに使いやすいＵＩを設計するといった神業を求められることもままあります。 参考文献 本JISを策定するための参考文献となった18点の資料が並んでいます(1点は削除されているため実質17点)。もし、本JISに触れて更に色々と知りたいとなったならこれらの資料にも是非あたってみてください。 懐かしい（懐かしいのはツマミだけかも）JIS Z 8524「人間工学－視覚表示装置を用いるオフィス作業－メニュー対話」が挙がっていますし、JISさんぽ(1)で取り上げたJIS Z 8520「人間工学－人とシステムとのインタラクション－インタラクションの原則」も挙がっています。 附属書JA(参考)　JISと対応国際規格との対比表 本JISとISO9241-112:2017との対比が一覧表となっています。説明が追加されている箇所が多く、国際規格と一致させるための苦労があるのだなぁなどと勝手に思ってしみじみとします。 削除された6.4.2.4項の記載例は文章の時制に関わる例のようで、思わず半世紀近く前にお世話になった英語の先生のご尊顔が頭をよぎりました。 以上がJIS Z 8522:2022「人間工学－人とシステムとのインタラクション－情報提示の原則」となります。 今日見つけた宝物 「ユーザーにとって違和感のない慣習との一貫性」 この宝物はJISの最終項6.4.2.4項なのですが、既存のユーザーを思いやった素晴らしい原則だと思います。UI設計に携わる方は、従来の操作に慣れたユーザーのことも置き去りにしないように是非工夫してください。場合によってはちょっとした配置換えが大きな事故につながることさえありますので。 さてさて今日も最後までお付き合いくださりありがとうございます。本日の道行きはいかがでしたでしょうか。次のさんぽはJIS S 0137「消費生活用製品の取扱説明書に関する指針」などいかがでしょうか。JIS C 0448「表示装置（表示部）及び操作機器（操作部）のための色及び補助手段に関する規準」も捨てがたいんですよね。全く別のJISになるかもしれませんが、次回またご一緒できますことを楽しみにしております。 参照： JIS Z 8522 情報提示の原則 参照： U-site ビジュアルデザインにおける閉合の法則 The post JISさんぽ (02)　 JIS Z 8522:2022「人間工学－人とシステムとのインタラクション－情報提示の原則」 first appeared on Sqripts .

ソフトウェア開発の世界では、アジャイル開発やスクラムが一般的になってきました。そのアジャイル開発のコアとも言えるのが、対話や協調です。この連載では、アジャイル開発におけるコミュニケーション・コラボレーションスキルを解説しながら、ファシリテーションスキルのレベルアップを目指します。 ＜スクラムマスターのためのコミュニケーション講座　連載一覧＞ ※クリックで開きます ・ #イントロダクション：優れたスクラムマスターが絶対に言わないこと 【連載初回、全文公開中】 ・ あなたの提案はなぜ受け入れられないのか？｜ファシリテーション技術-1- ・ よりよい場を作るための9つのルール［前編］｜ファシリテーション技術 -2- ・ よりよい場を作るための9つのルール［後編］｜ファシリテーション技術 -3- 第4回目のテーマは前回と同じく「ファシリテーション」でよりよい場を作る9つのルールの後半部分を見ていきます。 前回のおさらい 相互学習する現場のための基礎ルール 前回 は、 想定や推察を確認する 曖昧な言葉を確認する タブーを話し合う すべての情報を共有する と、会話の解像度を上げていくためのルールを解説していきました。今回は、ファシリテータのふるまいに注目したルールを解説していきます。 よりよい場を作るための9つのルール［前編］｜ファシリテーション技術 -2- ソフトウェア開発の世界では、アジャイル開発やスクラムが一般的になってきました。そのアジャイル開発のコアとも言えるのが、対話や協調です。この連載では、アジャイル開発におけるコミュニケーション・コラボレーションスキルを解説しながら、ファシリテーション... 　続きを読む　 Sqripts 関連記事｜Sqripts 相互学習する現場のための9つの基礎ルール 5. 理由と意図を説明する あなたは、以下の会話から何を感じるでしょうか？ 「◯◯さん、あなた、あの時間何をしていましたか？」 「刑事さん・・・私を疑っているんですか！？」 「いえ、そんなことはないです。繰り返しますがあの時間何をしていたんですか？」 ミステリーでありがちな会話ですが、ファシリテーションの観点からみると、刑事さんや探偵さんの質問方法は最悪です。まず、質問の答えを得たいはずなのに、相手は警戒しています。これだと相手は信頼して話をしてくれないかもしれません。 ファシリテーターは、質問の理由や意図を明確に伝えます。相手が不必要な警戒をしなくていいように、相手が質問に回答しやすいように質問します。会話をしているときに、もしあなたが、 「なんでこんな話をしたかと言うと」や「何を言いたいかと言うと」と発言したなら、理由と意図を事前にうまく説明できていないかもしれません 。 それでは、上記の会話を理由と意図を明確にした質問に書き換えてみましょう。 「私はここにいる全員が犯人の可能性があるので、ひとりひとりにアリバイを確認していきたいと考えています。◯◯さんは、あの時間何をしていましたか？」 ミステリー小説だとありえない台詞回しですが（笑）、ファシリテーターが何をしたいか？ 何を期待しているか？は伝わるはずです。 ファシリテーターは「犯人はあなただ！」と驚かせたいわけではありません。自由に適切な会話ができるように支援をしたいのです。理由と意図を説明することで、コミュニケーションがシンプルでわかりやすくなるはずです。 6. 自分の「関心」を伝える 繰り返しになりますが、ファシリテーションとは、チームの能力を高める技術です。さまざまな「違い」がある中で、適切に対立し、オープンかつ建設的に話し合い、物事を進めるための方法と言えます。 ファシリテーションが求める方向性について、異論のある方はほとんどいないと思います。ファシリテーターは、この方向性を会話の中でなんども繰り返し伝えていきます。 「自分の関心を伝える」は、ファシリテーションやチームの方向性を再確認するのに適した方法です。たとえば、議論がヒートアップした場合に、自分の今の関心事を伝えるだけで、一気に場が締まります。 「みなさんがいろいろな意見をお持ちなのはよくわかりました。白熱した議論になっているのも理解しています。ですが、 我々はこの1時間で意思決定を行い、アクションまで決める必要があります。私はそのための支援を全力で行いたいと思っています。 さて、残りの時間をどう使いましょうか？」 場合によっては自由な発言、建設的な議論が必要です。しかし、時間は有限なので、その時間をどう効率的に使うかは、参加者全員が頭の隅に入れておくべきテーマと言えます。そのため、ファシリテーターは定期的に「自分たちはこの時間を有効活用できているか？」「ちゃんと当初のゴールに向かっているか？」を確認しながらすすめるとよいでしょう。 ファシリテーターや参加者の関心といえば、「時間内で結果を出す」のはず。それをどんどん伝えていくだけで、チームは自分で考えて行動してくれるはずです。 7. 提案と質問を組み合わせる 提案を受け入れやすくするための流れ 提案やアドバイスはとてもありがたいことですが、なかなか自分ごとにならないのが課題としてあります。アジャイルコーチとしてさまざまなMTGに参加してきましたが、 提案やアドバイスのほとんどは実行されません。 たとえば、提案やアドバイスは、相手に対して一方通行になりがちです（上図左）。一方的な言葉の流れを変えるために、提案と質問を組み合わせます。提案と質問を組み合わせた会話は以下のようになります（上図右）。 もしよければですが、私の過去の経験を元にアドバイスしてもよいでしょうか？（確認） 相手は受け入れるかどうかを選べる（受け入れる場合は次に進む） 過去に似たようなことがあったときに〜〜をしたら解決に進んだことがあります（提案）。今の話を聞いてどう思いましたか？（質問） 相手は自分が受け止めたことを感想として話す この方法では、一方的な提案やアドバイスではなく、最初に受け入れるかどうかの確認を相手に委ねています。さらに、最後に提案したアイデアの感想を質問することで、どう受け止められたのかを確認しています。上の図を見るとわかるように、コミュニケーションのやり取りの量が大きく違うのがわかります。 アイデアがアクションの選択肢に加われば幸いですが、そうでなくとも「何が違ったのか？」を確認できます。確認できたら軌道修正して、相手の求めるものに近づいていきます。このあたりはアジャイル開発の本質とも言える、フィードバックサイクルの構築に近い流れです。 また、提案するときに以下のように聞いてもいいでしょう。 「この提案をあなたは受け入れても、拒否しても、ちょっと取り入れてもOKです」 提案を拒否されてもがっかりしないことをきちんと伝えておきましょう。外部からの意見は、あくまで選択肢でしかないのです。 8・9. 次のステップを一緒に作る、アクションを自分ごとにする 「8. 次のステップを一緒に作る」と「9. アクションを自分ごとにする」は、MTGで決まったことやアクションを整理するプロセスです。ふりかえりなどでよくあるケースなので、問題を深掘りし、アクションを作っていく過程を見ていきましょう。 問題を深掘りする例 ここでは「スプリント内で仕事が終わらない」という問題があるとします。今回は以下の流れで問題を深掘りしていきます。 今、何が起きているのか？ 将来、その結果どうなるのか？ 理想はなにか？ 何にチャレンジ・アクションするのか？ ステップ1 何が起きているかを明確にする まず、今何が起きているかを上方向に整理していきます。スプリント内で仕事が終わらないため、PRが溜まって仕事が進まなかったり、テストが終わらなかったり、さまざまな問題が発生していることがわかりました。 問題は、見る人によって違う形に変化します。ここでは、チームメンバーの様々な視点で問題を眺めてみましょう。私の場合「 問題を誰かに持たせず、テーブルの上に問題を置いて、みんなで眺めてみましょう 」と声掛けしたりします。問題を誰かが持ってしまうと、その人自身が問題になってしまいがちだからです。 ステップ2 その結果どうなるか？ 次に、問題がこのまま起こり続けたらどうなるかを想像します。ユーザに価値が届かない、予定が狂うなど、かなり影響が大きい問題のようです。もし、将来起こり得る問題が小さいのであれば、この問題は捨てて、違う問題や課題を扱っても良いでしょう。 将来の問題が大きければ大きいほど、チームは危機感を持って取り組めるようになります。開発に大きな影響を与えるのであれば、他人事ではなくなるからです。 ステップ3 理想はなにか？ そして、理想の状態をイメージして少し下側に置きます。なぜなぜと根本原因をさぐることもできますが、その方法はほろ苦い過去を探るつらい旅になりがちです。未来に進む推進力をつけるため、ここでは過去ではなく将来を考えています。 ステップ4 何をチャレンジするか？ 理想の状態がイメージできれば、現在と理想の間にあるギャップを洗い出します。そのギャップを埋めるものが、アクションやチャレンジになります。今回の例だとベロシティを考慮したり、見積もりを改善したり、完了の定義を見直しています。 全体図 これまで深掘りしてきた内容の全体像を見ると上記のようになります。 課題の深掘りボードサンプル（ こちら からサンプルを確認できます） ここまでの問題解決の流れをMiroに落とし込むと、上記のようなボードになります。ふりかえりなどでまずはこの形で進めていき、慣れてきたら自分たちに合わせてカスタマイズしていくこともできます。 今回の例では現状を掘り下げ、理想の状態を考え、現状とのギャップをアクションとして埋めました。注意したいのは、誰がやっても同じ結論になるとは限らないということです。つまり、その場の状況や会話、質問によっては違う結論に行く場合もあります。複数の結論が出てきて選択を迫られる（あるいはどちらもやる）場合もあるでしょう。 また、結論が同じでも、そこに行き着くまでの過程が変わる可能性もあります。効率的に結論にたどり着く場合もありますが、非効率であっても議論が深まる場合もあります。 ファシリテーターはその現場の会話の流れを汲み取りながら、最適な方法を模索し、良い方向にチームをいざなっていきます。 ＊ 今回は、相互学習する現場のための基礎ルールの5〜9までを解説しました。実際の会話例をもとにひとつずつみていきましたが、ファシリテーターの言葉の使い方やふるまい方のイメージが持てたのではないかと思います。 次回はファシリテーションと双璧をなす重要技術「コーチング」について解説します。 連載一覧 ・ #イントロダクション：優れたスクラムマスターが絶対に言わないこと 【連載初回、全文公開中】 ・ あなたの提案はなぜ受け入れられないのか？｜ファシリテーション技術-1- ・ よりよい場を作るための9つのルール［前編］｜ファシリテーション技術 -2- ・ よりよい場を作るための9つのルール［後編］｜ファシリテーション技術 -3- The post よりよい場を作るための9つのルール［後編］｜ファシリテーション技術 -3- first appeared on Sqripts .

本連載ではプロジェクトマネジメントの全体像と、プロジェクトを成功させる上で最低限抑えるべき知識と技術はもちろん、プロジェクトを炎上させないための技術やコツをお伝えしたいと思っています。 みなさんのプロジェクトが今以上に充実し、笑顔でプロジェクト終結を迎えられるよう一緒に学んでいきましょう。 第10回となる今回は「リスクマネジメント前編」です。 前編と後編の二回に分けて、プロジェクトマネジメントにおけるリスクの考え方と具体的なリスク分析方法、対応策の立て方について一緒に学んでいきましょう。 ＜ プロジェクトマネジメント成功の技術 連載一覧＞ ※クリックで開きます 【第1回】プロジェクトマネジメントとは何か？ 　［連載初回全文公開中：Sqripts会員以外の方も全文お読みいただけます］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ 【第8回】コストをプロジェクトの武器にする！ 【第9回】目に見えにくいプロセス管理こそ品質達成の鍵 【第10回】プロジェクトのリスクマネジメント［前編］リスクを徹底的に洗い出す リスクとは「挑戦すること」 1) リスクの語源 リスク（risk）の語源は諸説ありますがラテン語のrisicare（リズカーレ）とされています。risicareはもともとイタリアの東方貿易で危険を顧みず一攫千金を狙う船乗り達を指していた言葉が転じて「悪い事象が起こる可能性を覚悟の上で、勇気をもって試みる」という意味で使われ始めたようです。単純に「危険・危ない」のではなく、危険を承知で挑戦することで ＜得られるもの＞ があると捉えると、リスクは「避けるのではなく挑むべきもの」だと感じますね。 2) プロジェクトにおけるリスクは？ 日本語のニュアンスではやはり「危険」「悪い事」といったネガティブなイメージを持つリスクという言葉ですが、プロジェクトマネジメントはこのネガティブなリスクと共に「ポジティブなリスク」が存在します。この2種類のリスクをしっかりマネジメントして 「目標設定への影響をコントロール」 していくことがリスクマネジメントの極意です。 3) 2種類のリスク プロジェクト目標は未来にあるため、常に「不確実性」が存在します。まさにリスクがこの「不確実性」にあたります。 まずみなさんが思い浮かべるリスクには「悪いことが起こる」「起こってほしくないことが起こる」といったリスク、つまりネガティブリスクがあるでしょう。そして同じように「良いことが起こる」「思いの外良い結果がでた」といったリスク、つまりポジティブリスクも存在します。 計画を基準として考えたとき、計画から「悪い方」に外れたものをネガティブ、計画から「良い方」に外れたものをポジティブと捉えます。プロジェクトや環境によって悪い/良い事象は異なりますが、どのようなプロジェクトでも必ず ＜リスクは目標達成に影響を与え＞ ます。ですからプロジェクト成功に向けて人材が揃わない、顧客とのトラブルや法令の変更、為替変動や急激な原価高騰といった未来に起こりうる様々な「事象・リスク」を想像して適切にマネジメントしなければなりません。 4) ポジティブリスクへの接し方 とはいえ筆者の経験からも、大規模なプロジェクトを除いてはネガティブリスクにフォーカスしてマネジメントすることがほとんどです。また限られたリスク検討時間の中では、ポジティブリスクの洗い出しに思いや時間が及ばないことも想像されます。 しかし、そのような場合でもPMの立場では「別プロジェクトの熟練人材が獲得できればXXアクティビティの納期を短縮できる可能性がある」といった期待やポジティブ事象の発現シーンを想定しておくことで、そのプラスのベネフィットをしっかり活用する判断ができるように準備しておきましょう。 リスクマネジメントのステップ リスクマネジメントは以下7つのステップで行います。計画（準備）するプロセスが多いことからもわかるように、基本的にプロジェクト計画時にリスク対策を策定して、その後プロジェクト内で発現しつづけるだろうリスクに対してマネジメントを適用していきます。 リスクを徹底的に洗い出す、まずはそこから プロジェクトマネジメントの講義などで「リスク分析の仕方」「正しいリスク管理の方法」などについて質問を受けます。それはこの後触れていきますが、大切なのは「十分にリスクを洗い出してはじめて、リスク分析や管理ができる」ということです。 「ねえ、このプロジェクトのリスクってなにがあるかな？」 「まだ計画段階なので、具体的にリスクって言われても、スケジュール遅延ぐらいしか思い浮かばないな」 というように、リスクを洗い出そうとしても悶々とした時間になったり、せっかく出たリスクをおざなりにしてはいませんか？ 1) プロジェクトのイベントとしてリスク検討をしてみる 確かに「XXというプロジェクトをはじめます」という情報だけでは未来に起こる事象・リスクを思い浮かべることは難しいですね。そんなときは、例えばこれまでに作成してきたWBSやガントチャート、計画書、見積書などの情報を元ネタにして洗い出しを進めてみましょう。プロジェクトメンバが決まっていればキックオフやMTGのテーマとしてリスク検討をしてみてもいいでしょう。またリスクという言葉自体に慣れていない場合もありますので「プロジェクトの目標達成に影響を与えそうなモノやコトはなんだろう」「起こってほしくない出来事はなんだろう」「過去の経験から似たような事象が起こりそうなコトってあるかな」というように、難しく考えずにいろんな ＜リスクアイデア＞ が出るように導いていきましょう。 2) プロンプト・リストを活用する プロンプト・リスト（Prompt List）を使ったことはありますか？ プロンプトは即興のといった意味がありますが、プロンプト・リストというリスク区分が整理されたリストをあらかじめ準備することで、リスクアイデアを引き出したりリスクの漏れのない特定を助けたりすることができるという訳です。しかしながら、プロジェクトのリスクは固有のものですから、プロンプト・リストはそのアイデア出しの「呼水」として活用するという意識を忘れないようにしましょう。 ＜プロンプト・リストのフレームワーク＞ PESTLE（政治、経済、社会、技術、法律、環境） TECOP （技術、環境、商業、運用、政治） VUCA （揮発性、不確実性、複雑さ、あいまいさ） 3) リスクの基本的な書き方 リスクを検討する大きな理由は、不安なままではプロジェクトが進み出せないこと、プロジェクトのリスクは後にQCDの複合的な問題を起こすことが挙げられます。そのため、まずは「不安を起点」に考えはじめ、「リスクとして正しく記載・管理」することが重要です。 リスクマネジメント残念例： リスクアイデアを出したが、文書化されず、その後も管理されない リスクの特徴が掴めず、リスクの持つ問題やリスク発生時の影響が考慮しにくい 書き方の良い例・悪い例： 悪い例） コンパイル処理のパフォーマンスが足りない　→ リスク条件（原因）が不明 良い例） 要件定義フェーズでパフォーマンスに関する非機能要件合意ができていないので、コンパイル処理のパフォーマンスが不足 悪い例） 計画不備によりスケジュール遅延が発生する　→　スケジュール遅延が結果となっている 良い例） 計画リーダーが計画策定に関する知識に乏しく、必要となる工数を正しく見積もれない可能性がある さいごに リスクマネジメントは苦手意識を持たれがちですが、リスクを洗い出す段取りや分析方法を理解しておけば難しくはありません。 必要な準備をすることでその後のプロジェクト成功を助けるリスクマネジメント、後編では具体的な分析方法やリスク管理表の作り方に触れていきます。 次回は「リスクマネジメント後編」です。 連載一覧 【第1回】プロジェクトマネジメントとは何か？ ［連載初回全文公開中］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ 【第8回】コストをプロジェクトの武器にする！ 【第9回】目に見えにくいプロセス管理こそ品質達成の鍵 【第10回】プロジェクトのリスクマネジメント［前編］リスクを徹底的に洗い出す The post 【第10回】プロジェクトのリスクマネジメント［前編］リスクを徹底的に洗い出す first appeared on Sqripts .

皆さんこんにちは。今回が初投稿となります ばーちー です。 先日 IVIA で開催されたWebセミナー『テスト自動化の8原則と失敗事例から学ぶ成功のポイント！』に参加してきました。（講師：トーテックアメニティ株式会社　高橋友之様） 私は10数年前の案件で「テスト自動化」を導入したものの理想的な運用を行うことができなかった経験があります。現在では約6割のエンジニアが何らかの形でテスト自動化に関わっている ※1 という調査結果もあるとのことですので、今回のセミナーで得た知見を紹介するとともに、当時の反省点を振り返って行きたいと思います。 ※1　トーテックアメニティ社の独自アンケートにより、約3割がテスト自動化に直接携わっている、約3割がチーム内でテスト自動化が導入されているという報告があったとのことです。 セミナー概要 それではタイトル毎にセミナーでの講義内容を紹介します。 テスト自動化を実現するには、分析・選定 → 導入 → 運用・測定 の流れで行われます。 分析・選定： 自動化可能な部分や作業期間、予算、体制を考慮し、自動化すべき部分を検討します。 導入： 適切な自動化ツールを選定し、予算や技術レベルを考慮して導入し、テストケースを実装します。 運用・測定： 自動テストを実行し続けながら結果を分析し、テストケースのメンテナンスを行い、効果を評価して改善(PDCA)します。 この冒頭の話でいきなり当時の反省点が見えました。 当時は「自動化すればコストが削減できて品質も向上する」といった夢のような考えを持って“自動化ありき”で話を進めていました。その結果、大した分析も行われないまま導入したことにより、コストや品質への効果を想定通りに出すことができませんでした。 次に自動化を導入する機会があったら充分な分析と計画を行っていきたいと思います。 ＝メリット＝ コスト削減： 自動化により人員削減やテスト工数の削減による金銭的・時間的コストの削減が可能です。 品質向上： 自動化により網羅性向上と工数削減により確保できた時間で品質向上のための取り組みを行えます。 問題の早期発見： テストが24時間実行可能になることでバグや問題点を早期発見できます。 ヒューマンエラーの防止： テストのばらつきを防ぐと共に、妥当性が向上します。 ＝デメリット＝ アドホックやユーザビリティなどのテストは自動化に向いておらず、全てのテストを自動化することはできません。また、初期コストが高く、導入時にはテストコード作成やツール習熟に関連するコストが発生します。 当時はテスト自動化やプログラミングの有識者がおらず手探りで着手していました。その為、テスト設計まで済んでいるのにテストコードを作成する作業に苦戦して余計な工数が発生してしまうことがありました。これにより、自動化で期待される工数削減効果を減少させてしまったことが反省点です。 チーム体制も加味して初期コストを想定するとともに、テスト自動化により何を目指すのかといった目的を明確にすることが重要なのだと考えます。 テスト自動化研究会では「テスト自動化に取り組む前に留意しておくべきこと」として以下の８原則を提唱しています。 テスト自動化を成功させるためにはこれらを意識することが大切です。 手動テストはなくならない ユーザビリティテストなど、自動化できないテストタイプが存在します。 手動で行って効果のないテストを自動化しても無駄である テストプロセス(特にテストの分析、設計)が適切に行われていないテストは、期待される動作の保証やバグの検出といった効果を発揮しないという点は自動テストにおいても同様です。 自動テストは書いたことしかテストしない 自動テストには、操作、合否判定を厳密に記述する必要があるため、テスト内容は「記述された部分のみ」に限定されます。 テスト自動化の効用はコスト削減だけではない テスト自動化によってコスト削減が期待できる主なケースは「テスト実行」のコストです。これ以外には繰り返し型開発におけるセーフティネットとしての役割や、バグ修正日数の低減、影響範囲レビュープロセスの代替といった開発アクティビティへの効用も存在します。 自動テストシステムの開発は継続的に行うものである テスト自動化に関わる作業全体を１０割とした場合、自動テストシステムが完成するまでが３割、残りの７割は運用に関する作業となります。各種メンテナンスや自動テストのターンアラウンドタイム(TAT)の向上、信頼性の向上といったシステムの価値を向上させていく活動を行う必要があります。 自動化検討はプロジェクト初期から 繰り返し実行されるテストが予めわかっているなら、自動化を前提として、テスト計画を策定すれば効果的です。 自動テストで新種のバグが見つかることは稀である 運用されている自動テストの意義は「一度動いたはずの機能がうっかり壊れる」ことを最速で発見することにあります。 テスト結果分析という新たなタスクが生まれる 自動テストが”FAILED”を出してきた場合は何が起きたのかを改めて人間が確認することになります。ある程度自動的に”FAILED”を仕分ける機構など、コストを軽減させる施策を検討する必要があります。 ここに全てが詰まっているといった感じですね。 テスト自動化において大切なこと、注意すべきことが分かりやすくまとめられています。 記載の内容は要約してあるので、より詳細を知りたい方は下記サイトを参照してください。 ● テスト自動化研究会 　 テスト自動化の８原則 テスト自動化研究会 - テスト自動化の8原則 1. 手動テストはなくならない2. 手動でおこなって効果のないテストを自動化しても無駄である3. 自動テストは書いたことしかテストしない4. テスト自動化の効用はコスト削減だけではない5. 自動テストシステムの開発は継続的におこなうものである6. 自動化検討はプロ... 　詳細はこちら　 sites.google.com 関連情報 【事例１】 失敗の状況・原因： テストケースのドキュメントレビューが十分に行われておらず、テストケース手順書に不備や曖昧な点があった状態で自動化を行ったことによりテストできる品質になりませんでした。 成功ポイント： 自動化実装開始の基準を明確に定めた上で、ドキュメントレビューを十分に行う必要があります。 また、手動テストケースを自動化する際には、より客観的・定量的に細かく指定する必要がある点に注意してください。 【事例２】 失敗の状況・原因： 実装のスケジュールやルールが定まっていない状態にも係らず、顧客要望もありスピード重視で進めたことでメンテナンスしにくい自動化テストが大量に作られてしまいました。 成功ポイント： 事前調査や準備を怠らずにきちんと作業計画を立てる必要があります。命名規則やコーディング、レビューなどのルールを設け、属人化しないようにすることも大切です。 【事例３】 失敗の状況・原因： 顧客要求によりコストダウンを目的にテスト自動化を導入することになりましたが、体制として有識者をアサインすることができず、また他の作業もあり自動化に向けた準備工数を十分に確保することができませんでした。 成功ポイント： 自動化ツールの習熟度により必要となる工数は大きく異なります。有識者をアサインすることが理想的ですが、それができないのであればきちんと工数を確保できるように計画を立てることが必要です。 事例３は私の経験そのままと言っていいほどの内容でした。そもそも有識者がいるのか、いたとしてアサインできるのかなど、簡単に解決できない状況もあるでしょうが、有識者をアサインできていたら心強かったと思います。 IVIA Webセミナー『テスト自動化の8原則と失敗事例から学ぶ成功のポイント！』の講義内容は以上となります。 まとめ 「自動化」という言葉に夢を追いがちになりますが、その導入には初期コストを考慮した充分な計画が必要になります。また、自動化の目的としてコスト削減が挙げられますが、これは短期間に効果を得られるものではありません。自動テストを繰り返し実行していくことで次第に費用対効果が高まることになります。これらのことだけでも10数年前の私が理解できていれば、より良い結果になっていたはずです。 最近ではノーコードでテスト自動化を行えるツールも増えていますが、複雑なテストケースを自動化させるためにPython、JavaScript、C#等のプログラム言語を使用することがあります。プログラミングを行えるメンバーがチームにいることで、より効率的、効果的にテスト自動化を行うことができます。 また「テスト自動化エンジニア」を目指すのならばプログラミングは必須スキルとなるでしょう。 テスト自動化は今後も普及を続けると考えています。これから導入を考えている皆さんにとって有益な情報になれば幸いです。 レポートは以上となります。最後までお読みいただき、ありがとうございました！ テスト自動化ツールの選定【前編】～ツールの比較表をどう活用するか テストの自動化、特にE2Eテストの自動化を行ううえで、ツールの選定はとても悩ましい問題ではないでしょうか。特に有償のツールを用いる場合、会社でお金を払ってライセンスの購入や契約をするわけなので、「なんとなく」や「有名だから」「他社が使っているから」で... 　続きを読む　 Sqripts 関連記事｜Sqripts 【第1回】自動テストはなぜ失敗するのか？ この連載では、自動テストにスポットを当て、失敗事例の解説や自動化ツールの検証、自動テストを成功させるための手法を解説していきます。自動テストは自動化したからと言って必ずしも効率化できるわけではありません。自動テストの理解が不十分であると効果のある... 　続きを読む　 Sqripts 関連記事｜Sqripts The post IVIA Webセミナー『テスト自動化の8原則と失敗事例から学ぶ成功のポイント！』参加レポート first appeared on Sqripts .

ソフトウェア開発の世界では、アジャイル開発やスクラムが一般的になってきました。そのアジャイル開発のコアとも言えるのが、対話や協調です。この連載では、アジャイル開発におけるコミュニケーション・コラボレーションスキルを解説しながら、ファシリテーションスキルのレベルアップを目指します。 ＜スクラムマスターのためのコミュニケーション講座　連載一覧＞ ※クリックで開きます ・ #イントロダクション：優れたスクラムマスターが絶対に言わないこと 【連載初回、全文公開中】 ・ あなたの提案はなぜ受け入れられないのか？｜ファシリテーション技術-1- ・ よりよい場を作るための9つのルール［前編］｜ファシリテーション技術 -2- 第3回目のテーマは前回と同じく「ファシリテーション」です。よりよい場作りをするためにつかえる9つのルールを見ていきます。 前回のおさらい 前回 は、ファシリテーションが機能する現場を解説しました。ファシリテーションが機能している理想の現場をイメージすることで、進むべき方向性が定まるはずです。 また、MTGでありがちな、誰かの提案がチームの自分ごとになりにくい理由も解説しました。そのため、ファシリテーション技術などを使って、改善活動のアクションが自分ごとになり、チーム一丸で突き進める状態を目指す必要があります。 今回は理想の場や、アイデアが自分ごとになるために、ファシリテーションでどういった支援ができるかを具体例を元に考えていきます。 あなたの提案はなぜ受け入れられないのか？｜ファシリテーション技術 -1- 相互学習する現場のための9つの基礎ルール 相互学習する現場のための基礎ルール 相互学習する現場のための基礎ルールは以下の9つになります。 想定や推察を確認する 曖昧な言葉を確認する タブーを話し合う すべての情報を共有する 理由と意図を説明する 自分の「関心」を伝える 提案と質問を組み合わせる 次のステップを一緒に作る アクションを自分ごとにする 「相互学習する現場」は、参加者がお互い学び合うファシリテーションが機能している現場です。これらを実現するためのルールが上記になります。これらのルールは書籍『 ファシリテーター完全教本 』でまとめられていたものを、トレーニング用に筆者が整理したものになります。それぞれ見ていきましょう。 1. 想定や推察を確認する ファシリテーターは以下のような発言に注意をはらう必要があります。 「◯◯さんが〜〜と言っていたらしいよ」 「部長なら絶対〜〜って言うと思うよ」 「お客さんはかなり嫌がっているように感じる」 これらの発言は、想定や推察が混ざっており、事実確認ができていない情報です。このあいまいな情報をもとに、大切な意思決定をするのはとても難易度が高い行為です。 よって、こういった発言が出てきたら、ファシリテーターはすぐに内容を確認する必要があります。 「◯◯さんが言っていたということですが、それは確かですか？ 」 「お客さんが嫌がっているというのは、どういった状況を通してそう思ったのですか？」 その場にいない人の話が出てきたときは、その内容の事実確認が必要です。 我々はエスパーではないので、相手の考えていることを100％理解することはできません。 理解しようとする努力は必要でしょうが、すべてを理解するには限界があります。お客さんが嫌がっているという意見があれば、状況を確認するのと同時に、本当に嫌がっているのだろうか？ 疑う必要があります。必要であれば、お客さんに直接会いに行って真意を確かめるのも手です。 このようにして、ファシリテーターは想定や推察を確かな情報に変えていきます。 2. 曖昧な言葉を確認する MTGに参加したメンバーの次の発言を見てみましょう。 「前回のトラブルはすごく大きな問題です」 「めちゃくちゃ忙しいので、なかなか難しそうです」 「このタスクは時間がかかります」 我々は自分でも知らない間に、曖昧な言葉を使ってしまいがちです。 本人は内容を正確に理解できているかもしれませんが、我々はエスパーではないので、同じ理解をすぐに持つのは難しいものです。 「大きな問題」はどれぐらい大きな問題なのでしょうか？ 「めちゃくちゃ忙しい」というのはどれぐらい忙しいのでしょう？ 「なかなか難しい」というのはどれぐらい難しいのでしょう？ 「時間がかかる」というのはどれぐらいかかりそうなのでしょうか？ ファシリテーターは曖昧な言葉が出てきたらすぐに確認し、明確な情報に変えていきます。 3. タブーを話し合う 例となる会話を元に解説していきます。 「またトラブルが起きましたね。前回と同じく◯◯さんとの連携がうまくいかず、トラブルになってしまったようです」 「前にふりかえりもしたのに、同じ問題が起きてしまいましたね。こちらでやれることは限界があるので、◯◯さん側の部署でもう少し対策を考えてほしいものですが・・・」 「トラブルは現在も継続中みたいですよ」 この会話を見る限り、ここにいない人や部署の話をしているのが印象的です。そもそも、場に影響を与える人がこの場にいないのは不自然です。そこで、タブーかもしれないですが、以下のように話してもいいかもしれません。 「さっきから◯◯さんの話をしていますが、この場にいない人の話をする必要はありますか？ あるなら◯◯さんをここに呼びませんか？」 相談しにくい人や部署、相性の悪い人たち、誰もが知っている昔からある会社の問題などなど、タブーとなっている情報で身動きが取れなくなるケースも多いです。 タブーに囲まれる当人たちの場合、気が付かないうちにタブーを避けて会話を進めたり、見て見ぬふりをしたりする傾向があるからです。 私の仕事はアジャイルコーチであり、外部からやってきた存在です。よって、タブーがわかりません。お客さまとの関係性、チーム間の心理的安全性、時と場合など、タブーに踏み込むタイミングを見計らう必要はありますが、ファシリテーターはどこかのタイミングでタブーが話し合える場にいざなっていきます。 なぜなら、制約や制限のなかで最大限の効果を考えるより、制約や制限を取り払って議論するほうが、劇的に状況がよくなるからです。 4. すべての情報を共有する 想定や推察を確認する、曖昧な言葉を確認する、タブーを話し合うことで、現場にある隠れた情報の輪郭が現れるはずです。これらのルールを適用しながら、今ある情報を洗い出し、オープンに共有していきます。そうすることで、的確な判断や議論ができるようになります。 情報共有なんて当たり前・・・といえるかもしれませんが、チームで議論をするときになかなか意見が出てこない場合も多いでしょう。特に、まだ立ち上がったばかりのチームだと、心理的安全性も構築できておらず、ディスカッションが盛り上がらないといったケースもあるはずです。 そういう場合に使えるテクニックをいくつか紹介します。 順番に話す オンラインMTGは便利ですが、オフラインで対面で話すのと比べると間を取るのが難しくなります。この原因のひとつは、雰囲気やふるまい、しぐさなどがオンラインではわかりにくいためです。そういうときは、参加者に順番に話してもらうのも手です。 まず、考える時間を与えます。時間で言うなら1分ぐらいで十分でしょう。「1分じゃ考えられない」という人もいますが、今後のMTG効率を高めるために、短い時間で考える癖をつけるといいと思います。時間がないなら事前に準備をすればいいはずです。完璧な意見ではなく、たくさんの意見が集まる方法を身につけましょう。オフラインなら付箋に書いてもらったり、オンラインなら Miro のようなオンラインホワイトボードツールを使うのもよいでしょう。 次に、画面に写っている順番でもなんでもいいので、ひとりひとりに自分が考えたことを話してもらいます。ファシリテーターは「一人1分で話してください」というように、誰か特定の人が話しすぎないように配慮するとよいでしょう。話しすぎる人がいれば、指摘するのではなく「2分話してますね」と事実だけを伝えます。事実を伝えるだけで相手は自分のふるまいに気がつくはずです。 この方法のデメリットは、時間がかかることです。全員に均等に時間配分するのは平等と言えますが、そのぶん時間がかかります。 発言者が次の発言者を指名する 最初に発言者を指名したあと、その人に次の人を指名してもらう作戦です。お互いがお互いを意識し合うようになるので、チームのメンバー同士のコミュニケーション活性化に使える方法と言えます。 次のように、発言者が感想を他の人に求めるのも手です。こうすれば、よりコミュニケーションが活性化され、相手の意見を聞きやすくなるはずです。 「Aさんから〜〜という意見が出ましたが、Bさんはどう思いますか？」 ファシリテーターがチームを触発する ファシリテーターが発言者に集中してしまうと、ファシリテーターと発言者の1on1コミュニケーションになってしまいます（上図左）。ファシリテーターは、あくまでコミュニケーション活性化の媒体でしかないため、ファシリテーターの言葉に触発され、参加者間でコミュニケーションが活性化される形を意識します（上図右）。 ＊ 今回は、相互学習する現場のための基礎ルールの1〜4までを解説しました。 次回も、この続きを解説していきます。 連載一覧 ・ #イントロダクション：優れたスクラムマスターが絶対に言わないこと 【連載初回、全文公開中】 ・ あなたの提案はなぜ受け入れられないのか？｜ファシリテーション技術-1- ・ よりよい場を作るための9つのルール［前編］｜ファシリテーション技術 -2- The post よりよい場を作るための9つのルール［前編］｜ファシリテーション技術 -2- first appeared on Sqripts .