新卒でフロントエンド開発者をしています、イソダです。 約半年前、業務経験３か月目のとき、ついに私も 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 .

こんにちは！　テストエンジニアのマツキョーです！ 「トレーサビリティ」という言葉をご存知でしょうか？　トレーサビリティは英語の「trace」と「ability」を繋げた造語で、日本語では「追跡可能性」のように翻訳されます。元々は製造業の品質管理の概念として生まれたもので、部品から製品までの各製造工程で品質を管理するための手法です。近年では、IT業界においてもトレーサビリティの重要性に注目が集まっています。 もちろん品質保証（QA）においても、トレーサビリティを確保することは重要です。なぜならトレーサビリティを確保していないと、私たちが行ったテスト活動が、ソフトウェアやシステムの要件・仕様に対してどのくらいの品質を担保できているかが追跡できなくなるからです。 では、QAだけがトレーサビリティを意識していればいいかというとそうではありません。QAの責務は品質を保証することであり、品質を作り込んでいくのは、QAや開発を含めソフトウェアやシステムに関わるすべての人間だからです。組織やチーム全体でトレーサビリティを確保するための取り組みを行っていくことで品質の追跡可能性や明確性などの確立を促進することができます。 しかしながら、トレーサビリティを確保して活用していくためには、相応にコストが掛かります。私自身、業務を通して多くのプロジェクトに携わる中で、トレーサビリティの活用に取り組みながらも苦戦するチームを数多く見てきました。トレーサビリティを導入してもすぐに期待通りの効果を得ることは難しいでしょう。それでもトレーサビリティを組織やプロジェクトに導入することは、大変価値のある作業なのです。 この記事では、これからトレーサビリティを導入・運用していくにあたり、トレーサビリティとは何か、そのメリットおよび運用方法と注意点、そしてQAとしてどう関わっていくかについてご紹介していきます。トレーサビリティについて知識を深め、組織やプロジェクトの品質改善にお役立ていただければ幸いです。 トレーサビリティとは？ トレーサビリティという言葉は、元は製造業で使用されていた品質管理の概念です。ソフトウェア開発でも品質管理のための手法として一般的に利用されています。ソフトウェアの品質保証においても重要な概念であることは言うまでもありません。 ISTQB glossary では、トレーサビリティに関する用語として以下のように掲載されています。 関連する作業成果物、または作業成果物内のアイテムを明示的に関連付ける能力。 ISTQB glossary「トレーサビリティ」 たとえばシステム開発であれば、最初に「要求」を定義し、「要求」をもとに様々な「要件」を洗い出し、「要件」を満たすための「仕様」を設計し、「仕様」をもとに「コード」を作成して実装したり、QAが「テスト」を設計したりします。トレーサビリティはこれらの繋がりを明示的に管理することで、「要求」を満たせているか、つまり意図した価値・品質を作り込めているかを測定できるようにしてくれます。トレーサビリティに関するQAの役割としては、様々な種類のテストを通してトレーサビリティの破綻や抜け漏れがないか、その繋がりに妥当性があるかを検証して保証していくことが挙げられます。 トレーサビリティのイメージ トレーサビリティを確保するメリット トレーサビリティのイメージが少し掴めたところで、次に具体的なメリットをご紹介します。 製品の品質について追跡可能性・透明性・明確性を提供してくれる 製品が要求を満たしていることを担保するためには、まず要求をどのようにブレイクダウンして仕様やデザインに落とし込んだか、その仕様がどのコードにより実装されたかが追跡できる必要があります。そしてQAが、仕様をもとにテスト条件を抽出してテストケースを作成し検証することで、要求からテストまでの一貫したトレーサビリティが確保されます。これらを可視化して管理することで「追跡可能性」や「透明性」が生まれ、品質という目に見えない指標を計測できるようになります。また、情報を一意化することにより「明確性」も生まれ、欠陥の混入や不具合の作り込みを防ぐことができるようになります。 他にも、トレーサビリティが適切に確保されていれば、不具合が偏在している機能や、他の機能・システムとの依存関係が集中している部分が明確になります。不具合が集中している部分をリファクタリングしたり、他の機能・システムとの依存関係を緩和したりするなど、プロダクトをより管理しやすく品質を保ちやすい構造に改善していくための判断材料にすることもできます。 変更要求が発生した際に迅速な対処が可能になる あるプロジェクトに途中から参画した時の話です。既存機能の機能変更が計画されておりテスト設計をすることになりました。その際、「以前に実施したテストケースが流用できるので使って欲しい」という指示を受けたのですが、テストケースを確認したところどのテストベースや仕様記述を基に設計されたのかがわからず、流用可能な部分と機能変更により新たに設計しなければいけない部分の調査に時間が掛かったことがありました。何とか期日までに仕上げましたが、人の入れ替わりが激しいIT業界においてトレーサビリティの重要性を再認識した出来事でした。 機能の変更発生時やインシデント発生時など、その機能変更や不具合が現在のシステムのどこに影響するのかを正しく理解していないと、予期せぬ別の不具合に繋がってしまう可能性があります。この時、トレーサビリティが適切に確保・管理されていれば、影響範囲の理解を助けて素早い対応が可能になります。たとえば既存システムに新たな要件にもとづく機能を追加することになった場合、QA視点では以下の活動が容易になります。 既存のテストケースでカバーできる範囲がわかり工数を節約できる 新たに作成する必要があるテストケースが特定でき、素早くテスト設計を行える 新たな要件／機能の追加により既存機能のどこに影響するかを特定でき、優先度をつけて適切なリソース投入ができる トレーサビリティを確保して適切に活用できれば、機能変更やインシデント発生時に影響範囲の調査などにかかる工数を削減することができます。浮いた工数をより品質を高める活動に使用できるため、高品質なプロダクトの継続的な提供が可能になります。またユーザーからの問い合わせに対する調査も迅速に行えるため、お客様の要望に素早く応えることができ、顧客満足度の向上も期待できます。そして影響範囲が明確であれば、不測の事態に遭遇するリスクを大きく減少できます。開発工程では影響範囲を考慮した実装により潜在的な欠陥を減少でき、テスト工程では影響範囲が明確なため効率的なテストが可能となります。結果として不具合の減少や各種リスクの軽減が期待できます。 トレーサビリティには、プロダクト開発の生産性を高め、お客様により高品質なプロダクトを提供するためのメリットがあります。では、実際にトレーサビリティを確保して適切に管理・運用していくには、どのような方法があるでしょうか。 トレーサビリティを確保して運用していくには トレーサビリティを管理する方法には様々ありますが、その中から一般的な方法を３つ紹介します。 ツールを導入して管理する 要件管理ツールは、要求・要件／仕様をチケットとして管理し、依存関係や関連付けをシステム上で簡単に設定できます。適切に導入・運用することで要求から仕様設計までのトレーサビリティの確保を支援してくれます。また構成管理ツールと連動させることで仕様とコードを関連付けることができるので、開発サイド全体のトレーサビリティを確保できます。さらに仕様とテスト条件・テストケース、及び、テスト結果を関連付けできるテスト管理ツールを併用することで、仕様からテスト結果までのQAサイドのトレーサビリティを確保できます。 これらのツールを連携して使用することで開発からQAまでの一貫したトレーサビリティを確保できます。 ドキュメンテーションで管理する トレーサビリティの管理には、ツールを導入することが最も効果的でしょう。しかし組織にツールを導入するには手続きやツールの習熟にかかるコストなどが相応に必要になります。大規模な開発でなければ、Excel等でトレーサビリティマトリクス ※1 を作成することでもトレーサビリティを管理できます。手作業による管理になるため、プロセスをしっかり定めて実施する必要がありますが、手軽に導入できる方法としては最も効果的な方法の１つです。 ※1 トレーサビリティマトリクスとは、要件（行）に対して、仕様・設計・テスト（列）がどのように対応しているかをマトリクスで表現したものです。以下にトレーサビリティマトリクスの例を示します。 トレーサビリティマトリクスの例 レビュープロセスで担保する ツール導入もドキュメンテーションもハードルが高いという人は、まずレビュープロセスにトレーサビリティチェックの項目を追加してみてはいかがでしょうか。 各工程のレビューにおいて、要求と要件／仕様、要件／仕様とテストといった双方向のトレーサビリティが確保されているかをチェックし、議事録やチェックシートに記録してトレーサビリティを担保する方法となります。ただし、この方法では製品全体の情報としてまとめられていないため、トレーサビリティを十分に管理できているとは言えず、効果を十分に得られません。トレーサビリティの効果を実感できたら、ツールやドキュメンテーションによるトレーサビリティ管理を導入することをオススメします。すでにツールやドキュメンテーションを導入している場合は、適切な運用を実現するためのプロセスの1つとして利用すると効果的でしょう。 以上がトレーサビリティを確保・管理する方法の一例ですが、これらの方法を導入すればトレーサビリティの恩恵を受けられるわけではありません。 たとえば、ツールを導入した場合を考えてみてみましょう。まずツールの使い方がわからなければ利用できないので、ツールを習熟するための教育方法を考える必要がありますね。次にプロセスやフォーマットが定まっていなければ活用できる情報として蓄積できないので、運用プロセスやフォーマットを策定する必要があります。プロセスやフォーマットが定まっていても利用者が認知していなければ利用されないため、組織に浸透するまで継続的に周知していくことが求められるでしょう。ただし、これらをすべてクリアしても利用時のプロセスやルールが複雑だったり冗長だったりすると、利用者に負担が掛かり継続が困難になる場合もあるため注意が必要です。 いずれの方法を採用するにしても、導入するだけでなく適切に運用できなくては効果は得られません。トレーサビリティを適切に運用して十分な効果を得るためには、学習・運用・改善のプロセスやルールを設定したり、定期的なチームミーティングの開催などでコミュニケーションを活発にするなど、チーム全員で様々な取り組みに挑戦する必要があることが分かりますね。 QAがトレーサビリティを推進する トレーサビリティを導入して活用していくためには、プロジェクトに関わるすべての人が継続して適切に運用していかなければいけません。その中でも品質に責務を持つQAが主導権を握ってトレーサビリティを推進していくべきかと思います。なぜならQAはテスト活動を通してソフトウェアやシステム全体の仕様に精通していくため、その過程でトレーサビリティが適切に確保され管理されているかを確認できるからです。その際、不適切な運用があった場合はチームへフィードバックしたり運用を改善したりできます。 とはいえ、QAはあくまでトレーサビリティを推進する旗持ちでしかありません。最も重要なのは、全員が 「品質向上のためにトレーサビリティを管理する」 という共通の目標を持つということです。トレーサビリティを確保して品質向上のために活用していくためには、チーム全員がトレーサビリティの重要性を理解し、継続してトレーサビリティの確保・管理・運用に取り組んでいくことが大切ですね。 さいごに トレーサビリティを組織やチームに適用してメリットを享受するには、チームメンバー1人1人が自分事として行動することが重要になります。トレーサビリティを適切に導入・運用して、プロダクトの品質向上に役立てていただければ幸いです！ The post トレーサビリティを制する者は品質を制する！～IT業界におけるトレーサビリティを解説～ first appeared on Sqripts .

こんにちは。RSです 私はAI技術に不可欠なアノテーション業務を行っています。 ここ数年で、AI技術は「開発途上の最先端技術」というよりは「実際に日常に活用されている最先端技術」になってきたと感じています。車の自動運転技術・自動で障害物を避けるお掃除ロボットなど、AI（人工知能）を使った様々な製品・サービスがあることを見聞きしたり仕事やプライベートでChatGPTを使っている方もいらっしゃることでしょう。 また、AI技術が発展してきていることでアノテーション業務を行う様々な業者が増えてきたり、アノテーションを行う求人を見かけるようになったりと、アノテーション業務自体も増えてきている事を感じています。 今回はAI技術に不可欠な「アノテーション」とはどんな事をする作業なのか、無料アノテーションツールを紹介しながらアノテーションの世界を紹介したいと思います。最後に複数のアノテーションツールを実際に使用して、アノテーション作業のタイムアタックを行いました。タイムアタックを通して分かった事もシェアします。 アノテーションってなんだろう？ ここまで、散々じらしてしまいましたが… そもそも、アノテーションってなんでしょう？アノテーションとは　 annotation＝注釈 　という意味です。AIの機械学習には様々な手法がありますが、その中の一つに「教師あり学習」という方法があります。テキストや音声・画像といったさまざまな種類のデータにタグやメタデータを付けたデータを使ってAIに学習させます。その学習用データを作る事をアノテーションと言います。もっとカンタンに言うと「教師あり学習」で機械学習をする際の正解データを作る作業がアノテーションです。 例えばAIに「花」を学習させたい場合、様々な花の画像を用意します。その画像全てに「花」というタグを付けてあげて正解を認識させます。このように認識させたいものと解答を用意して認識させます。 ただ、「鼻」とか間違えたタグをつけてしまうと、花の画像を「鼻」と認識してしまいます。なので正確な「正解データ」がたくさん必要になります。アノテーション業務では基準に沿って正確に作業し、たくさんのデータを完成させることが求められます。 アノテーションの種類 アノテーションの種類を説明する前に、対象データについて少しお話しさせていただきます。機械学習では教えたい内容に応じてアノテーション対象となるデータに様々な種類あります。代表的なものは以下の通りです。 画像・動画データ 音声データ テキストデータ 今回は画像データに対するアノテーションの種類を説明したいと思います。 A．画像分類 1枚の画像に写っているものがなにかタグをつける作業。 B．物体検出 画像・動画の中に映っている物体等を四角で囲み、タグを付ける作業。 画像内のどの位置にその物体があるのか情報を得ることができます。 C：領域検出 画像・動画の中に映っている物体等の領域を囲みタグをつける作業。 四角ではなく、対象物をその形のままに囲み、被写体を識別することができます。 D：座標検出 主に人体に対して使われることが多く、顔や身体等の部位に印をつける作業。 顔認識や姿勢推定などに使われます。 アノテーション作業の課題 色々なアノテーションの種類を見てきましたが、教師ありの機械学習では大量の「正解データ」が必要になります。そのため作業の効率化はとても大事になってきます。私が行ってきたアノテーション作業では、ほとんどのケースで専用のアノテーションツールを使って作業していました。ただ、専用のツールだとしても使い方が煩雑であれば、作業効率はそれほど上がらない可能性もあります。また、アノテーションツールは探してみると色々とリリースされています。各ツールそれぞれに特徴があり、作業工程・操作のしやすさ・使用感はどうなのか？気になるところです。 使用感の指標の1つに…タイムアタックをやってみた！ アノテーション作業では大量のデータを効率よく作業する必要があります。精度も重要ですが、それと同じくらいスピードが求められます。そこで実際の作業の流れを紹介しつつ同一条件でアノテーション作業のタイムアタックを行って、ツールの違いがどれくらい作業スピードに影響するか検証します！ さてさて、どんな結果が出てくるか…計っていくぅ～！ 使用するツール 今回はネットで調べて「無料で使う事ができる」「様々なデータにアノテーションできる」「進捗管理ができる」「ウェブ上で動作するので気軽に試せる」等の特徴が類似している3つのツールを使います。 Labelbox ANNOFAB CVAT アノテーション対象 通常の業務では、お客様の意図した「正解データ」を作るために、お客様からいただく基準書や質問を通してお客様とコミュニケーションを取りながら基準を明確にして作業を行います。今回は花の画像を用意して「物体検出」で「花」や「つぼみ」が写っている以下の画像10枚に対して、アノテーション作業のタイムアタックを行います。 アノテーションの作業内容とタイム計測方法 通常の業務ではアノテーション作業前に事前準備、作業後に見直し作業を行っています。事前準備では実施時に困らないように基準の確認・データ内容の確認等を行います。見直し作業では作業したデータが基準と相違がない事を確認します。「正確性が命」のアノテーションには無くてはならない作業です。自身（もしくは他者）が見直しを行う事で、基準と異なるデータが混入してしまうのを防止することができます。今回のタイムアタックも通常の業務と同じ手順で行いました。 タイム計測方法は、それぞれのツールで作業手順・設定項目等が異なる事から、どの作業にどれくらいの時間がかかるか分かりやすくするために下記3つに分けてタイムを計りました。 ＜作業準備＞ 画像アップロード〜アノテーション作業準備完了までを計りました。 作業画像のアップロード・ラベル名の作成・担当者の指定等ツールごとに最低限必要な設定を行い、アノテーション作業できる状態にしました。 ＜作業実施＞ アノテーション作業実施のタイムを計りました。今回は「物体検出」を行いました。 ＜データ見直し＞ アノテーション作業実施終了後の見直し開始〜終了までタイムを計りました。アノテーション作業が終わったら必ずミスをしていないか確認をします。実際の作業でも重要な工程です。 結果発表とツールの操作感 一番合計タイムが早かったのはCVATでした。 ＜作業準備＞ では他の2ツールと比べると設定項目が多いANNOFABが一番時間がかかりました。 ＜作業実施＞ ではCVATが一番早く終わりました。操作がシンプルで分かりやすい事が要因だと感じました。ANNOFABでは手順1つ多くて且つそれ抜かすとアノテーション出来ない仕様になっていました。そこを抜かすミスを多くしてしまったため時間がかかってしまいまいた。 ＜データ見直し＞ ではANNOFABで上記ミスにより焦りが生じたためか他のツールに比べて作業ミスが多く発生してしまいました。その結果、見直しに時間がかかってしまいました。同じデータをアノテーション作業するとはいえ、人の作業なのでタイミングによって精度にブレが出てしまいました。。。 では、ここからは各ツールごとに操作感をお伝えしたいと思います。 Labelbox 画像アップロード時に一部の縦画像が横で表示されてしまいました。ツール上で修正ができるか調べてみましたが、私の調べた限りでは見つけることができませんでした。そのため修正は行いませんでしたが、使用するデータや状況によっては縦横の修正が必要になるかもしれません。そのような場合どう対応すればよいのか悩ましいところではあります。 それ以外は直観的に作業ができて、ショートカットがある機能はメニュー操作時に表示されていました。はじめて作業を開始してから操作手順を覚えるまでは作業ペースが上がりづらいので、何度も目に入って覚えられるのは良いと思います。 ANNOFAB 進捗管理の機能・アノテーション作業の機能共に色々な機能が付いています。作業時間を細かくモニタリングして統計を取ることもできます。一見便利そうに見えましたが、便利機能があるがために設定項目が多くなったり、必要としている機能がどこにあるのか分かりづらく感じました。使いこなせればとても便利だとは思います。ただ、私は悲しいことにシンプル脳なので笑、私には使いこなすのは難しいなぁ…と感じました。 CVAT 他の2つのツールに比べるとアノテーション作業準備やアノテーション作業の手順がシンプルに感じました。それもあってかタイムアタックでも一番作業が早かったです。 3つのツールの印象 3つのツールの印象を私が一言で表すならば下記のようになります。 詳細な進捗管理をしたい、作業者をモニタリングして作業スピードを向上させるヒントを得たい →ANNOFAB シンプルな操作方法・管理方法でアノテーション作業したい →CVAT ANNOFABとCVATの間 →LabelBox どのツールも作業効率を上げるために色々な工夫をしていたのが印象的でした。 例えば 矩形を作る際には縦横の補助線を表示して1回の作業で矩形の中に対象物が入るような点を打つ手助けする（3ツール全て） 矩形をコピー＆ペーストしたら少しずれた位置にコピーした矩形が表示される事で1つの対象物に複数個の矩形が重なって付く事を防ぐ（Labelbox・CVAT） ショートカットをメニューに表示する（3ツール全て） 等です。 そんな小さなことで〜？！と思われる方も多いでしょう。ただ、アノテーション作業は基本的に単調な作業です。例えば今回の「物体検出」も、「画像から対象物を探す→矩形を作る（コピーする）→対象物にサイズを合わせる」　という、慣れれば数秒で完了するこの工程を1日中繰り返すのです。処理数が多くなるので、ちょっとしたツールの使い勝手の良し悪しが数秒のロスと微細なストレスを生み、積み重なって進捗に影響を与えます。なので、このような小さな工夫が役に立つのです。 更なる効率アップ～自動アノテーション ここからさらに効率を上げていくには人がイチからアノテーション作業を行うのではなくツールの「自動でアノテーションする機能」を使う方法があります。これはツールが自動でアノテーションした結果を作業者が確認、修正が必要であれば修正する方法です。自動アノテーションの精度が上がれば上がるほど、作業者が修正する時間が減っていき、その分作業者が1日で処理できる作業量も増えていきます。 今回上げた3ツールに自動でアノテーションする機能が付いていましたが、有償版の機能だったものもあったため検証は行いませんでした。ご興味がありましたら、ぜひお試しいただければと思います。 各ツールでの無料版・有料版で使える機能をまとめました。よろしければ参考になさってください。 （参考： Labelbox 、 ANNOFAB 、 CVAT ） 終わりに アノテーション作業について説明しましたが、少しはイメージできましたでしょうか？これまで見てきたように、アノテーションとはAIに覚えさせたいデータにタグやメタデータを付ける作業です。必要なデータに合わせて色々な種類に対してアノテーション作業を行い、画像の場合は4種類のアノテーション作業がある事をお伝えしました。少しでもアノテーションに興味を持っていただけたら嬉しいです。 また、アノテーション作業を行う際のツールが色々あり、使用感などを参考にしてもらうためタイムアタックを行いました。今回の検証では3ツールで物体検出を行うための必要最低限の操作方法・ショートカットキーを覚えてタイムアタックに挑みました。なので、今回はこのようなタイムアタックの結果になりましたが、各ツールの習熟度によってはタイムも変わってくるとは思います。 ただ、ツールによって作業時間に差が出ることは新たな発見でした。やる事は同じでもちょっとした工程が変わるだけで作業効率に差が出る事が分かりました。また、ツールの使い勝手も進捗に影響を与えるのだと改めて感じました。この検証を参考にしていただき、ご自分に合ったアノテーションツールを選択していただければと思います！ 最後まで読んでいただき、ありがとうございました The post AIの先生?! アノテーションってなにするの？を解説します first appeared on Sqripts .

はじめまして、QAエンジニアのT.Tです。 今回は流行りのAIを使って問題発生のログ情報とソースコードを基にデバッグを実施してみました。 その結果についてお伝えします。 AIについて まず初めに、AIについてご説明します。AIとは、Artificial Intelligence（人工知能）の略で、人間の知能を模倣するコンピュータープログラムを指します。これにより、機械が推論、認識、判断などの人間と同じ知的な処理機能を実行することが可能になります。特に、近年のChatGPTなどでお馴染みの大規模言語モデルは驚異的な進化を遂げており、本日ご紹介するAIによるデバッグもその力を活用しています。 AIによるデバッグの可能性と課題 AIでデバッグをする理由 デバッグは、コード内のバグを特定・除去し、ソフトウェアの品質を向上させ、ユーザーの信頼性や満足度を高める重要なプロセスです。しかし、デバッグ作業は時間やリソースを多く必要とし、開発者にとってストレスの原因となることがあります。 そこで、AIによる効率的かつ品質向上につながるデバッグの可能性を探ることにしました。 AIを利用したデバッグの方法 まずは、デバッグの実施環境について説明します。今回は、OpenAI社が提供する「OpenAI API」を用いてデバッグを行いました。また、「Langchain ※1 」のAgents機能を使用しました。「Langchain」のAgentsは、目的を遂行するために言語モデルと渡されたツールを適宜呼び出し、その結果をまた言語モデルやツールにインプットします。これを目的を達するまで自律的に行います。今回はこの機能を利用し、問題が発生した際のログ情報、関連ソースコード、そして問題事象の情報を入力できるツールを用意し、AIがこれらを利用してデバッグが可能かどうかを実際に検証しました。 AIを利用したデバッグの課題と解決策 課題：問題発生時の情報の収集 AIを用いたデバッグを実施した際に、AIにインプットするログの収集に課題があることが分かりました。テストを実施し、問題が見つかった場合、その状況を取得するためにログを収集する必要があります。当初、テストケースを実施して問題が発生した際、実施日時を基に必要なログを収集し、AIへインプットしていました。しかし、複数名が同一環境でテストケースを実施する場合、実施日時によるログ抽出だけでは、情報が混在してしまいます。その結果、問題が発生したテストケースとは無関係なログ情報が紛れ込み、正常にデバッグが行えないことが判明しました。 解決策：APMと専用ツール そこで、問題発生時のテストケースのログ情報の的確に収集できるように、下記の工夫を行いました。 APMを活用したトレース情報・ログの取得 トレースとは任意の処理単位（APIへのリクエストや関数呼び出し）の処理時間や呼び出し順序などを記録するものです。マイクロサービスなどでAPI間の複雑な呼び出し階層を持つものでも、トレースを記録することで「どこからどこにどの順序で呼び出されているのか」を処理時間とともに可視化できます。下図のようなイメージです。 参照元 (JAEGER公式サイトより) 今回はテスト時のトレース情報やログ情報を収集するために、APM ※2 を使用しました。その中でもトレースの共通規格であり、OSSで利用できるOpentelemetryを使用しました。Opentelemetryではトレースに合わせて関連するログ情報も取得でき、取得されたトレース情報を参照すると、特定テストケースに関連するログ情報のみ、収集できていました。Opentelemetryでは、トレースID毎にトレース情報・ログ情報を管理しており、テストケースとトレースIDを紐づけることができれば、個別のテストケースのトレース情報・ログ情報を取得できそうです。 関連記事： 分散トレーシングの活用による次世代のテストを考える テスト開始／終了とトレース開始／終了の連携 次に、テストケースとトレース情報・ログを紐づけるために、テストの開始と終了のタイミングでAPMのトレースを開始・終了する必要があります。そのため、私たちは手軽にトレースを開始・終了できるツールを開発しました。このツールでは、テストを開始する際に、任意のトレースIDが発行され、そのテストで行われた操作・処理のトレースが発行されたIDで記録されるようにします。これによりテストケースとトレースIDを紐づけることが可能となり、テストケースに紐づくトレース情報・ログを確実に取得することができるようになりました。 最終的に、今回AIでデバッグを行う際に用意したデバッグ環境は以下のようになります。 AIによるデバッグ それでは実際にAIを用いてデバッグを実施してみましょう。 今回デバッグの対象としたのは、Webアプリです。ユーザー登録機能やログイン機能などがあります。 今回調査する問題は、「ユーザー情報の更新失敗」という事象で、AIにこの事象を調査してもらうことにしました。 指示と入力データ 今回は、AIに対して以下のような指示を与えました。実際のプロンプトには利用するツールや調査手順などが含まれますが、わかりにくくなるためここでは省略しています。 エラーが発生したトレースのIDと、調査したい内容が与えられます。この内容を基に、問題が発生しているコードを確認し、原因を調査してください。 トレースID:{trace_id} 調査内容:更新ボタンを押下したところ「更新に失敗しました」と表示されました。理由を調査してください。 また、Agentsに与えるツールとしてPythonで下記の関数を作成しています。Agentsはこのツールを利用してデバッグを進めていきます。 get_trace_list 対象のトレースIDを与えられると、トレース情報を保持しているDBから該当するトレース情報を取得する。テスト実施時のトレース情報を取得するためのツール。 read_file 指定されたファイルを読み込む。調査対象のソースコードを読み込むためのツール。 今回インプットとなる問題発生時のトレース情報には調査対象のテスト開始から終了までのエンドポイントや関数呼び出しの順序情報、関数のパラメータ・戻り値、各所で出力されるログなどが含まれます。事象発生時には例外も発生しており、そのスタックトレースも含まれています。 結果 AIにデバッグを依頼した結果、以下のような回答が返ってきました。具体的なクラス名や関数名、ソースコード等についてはセキュリティ観点から変更しています。 エラーの内容を確認したところ、`SampleController` の `sample` メソッドで例外が発生していることがわかりました。具体的には、メールを送信する際に「An email must have a "To", "Cc", or "Bcc" header.」というエラーが発生しています。これは、メールを送信する際に宛先（To, Cc, Bcc）が指定されていないことを意味します。 エラーが発生しているコードは以下の部分です： if ($status === 'sample_status') { Mail::to($sample->email)->send(new SampleMail($sample->login_id, $sample->name, $sample->email)); // ... } このコードは、対象のステータスが「sample_status」に変更された場合に、変更されたことを通知するメールを送信しようとしています。しかし、`$sample->email` が空であるか、正しいメールアドレス形式でない場合、上記のエラーが発生します。 解決策としては、メールを送信する前に `$sample->email` が有効なメールアドレスであることを確認する必要があります。以下のようにコードを修正することを提案します： if ($status === 'sample_status') { if (filter_var($sample->email, FILTER_VALIDATE_EMAIL)) { Mail::to($sample->email)->send(new SampleMail($sample->login_id, $sample->name, $sample->email)); } else { Log::error("Invalid email address: " . $sample->email); // ここで適切なエラーハンドリングを行う } // ... } この修正により、メールアドレスが無効な場合はエラーログに記録され、メールの送信はスキップされます。また、適切なエラーハンドリングを追加して、ユーザーにエラーを通知することも考慮する必要があります。 この結果を出力するためにAgentsはおおまかに下記のような動作をしているイメージです。 プロンプトをllmに渡し必要なアクションを決定⇒トレース情報の取得（get_trace_listの呼び出し） get_trace_list(指定されたトレースID)の結果をllmに渡し、次のアクションを決定⇒エラーと関連するソースファイルの読み込み（read_fileの呼び出し） a. 読み込んだソースコードとトレース情報をllmに渡し、llmが調査完了と判断（原因が判明）するまでアクションを繰り返す 最終回答を出力 目的を達するまで利用可能なツールを用いて自律的に調査を進めてくれる有能なアシスタントという感じですね。 さて、そんなAIの出力結果をまとめると下記のようなことがわかります。 エラーの発生箇所 SampleControllerのsampleメソッドのメール送信部分 エラーの発生理由（直接原因） $sample->emailの値が空かメールアドレスの形式として正しくない エラーの回避策 メール送信前にアドレスチェックを行う 考慮点 エラー発生時にユーザーにエラーを通知する この結果から$sample->emailの値がおかしいということになり、その取得元であるDBのテーブルを確認したところ、正しくメールアドレスが格納されていないということが判明し、そのデータを修正することでエラーが解消しました。今回はテスト環境での事象だったのですが、その環境を構築する際に正しくデータが作成されていなかったようです。 このように、AIがトレース情報とソースコードを読み取り、トレース情報中のエラーログやパラメータ情報などから、例外発生の要因を解析し、ソースコードの問題発生箇所まで特定してくれました。従来のデバッグであればローカル開発環境で事象を再現しながらステップ実行したり、大量に出ているログから問題のログを見つけ出したりするなどの手間がかかっていたところですが、AIとAPMを利用することでその手間を削減することができました。 まとめ 時間やリソースを多く必要とするデバッグ作業について、AIが例外発生の要因を的確に解析し、ソースコードの問題発生箇所まで特定してくれることが分かりました。また、テストケースごとのトレース情報やログの収集は、APMやツールを活用することで比較的容易になり、テストケースが実行されて問題が発生した際には、迅速に情報を収集し、AIにデバッグを依頼する環境を整備することができました。 正直なところ、AIデバッグがどこまで問題を詳細に分析できるのか不安でしたが、私が想定していた以上に、細部まで分析し、問題点を指摘してくれました。AIに対する命令は比較的シンプルで汎用性があり、他のプログラムのデバッグにも流用可能だと思います。 近年、AIを利用した革新的なサービスが急速に増えています。その中で、AIによるデバッグは開発者たちを支援し、品質の向上に寄与すると感じています。適切な場面でAIを利用することが、より良いデバッグにつながると考えています。 株式会社AGESTでは、ソフトウェアテストのオプションとして「AIデバッグ」というデバッグのサービスを提供しています。本サービスは、AGESTの次世代QAエンジニアがAIを活用したデバッグを実施しており、次世代QAエンジニアとAIの力と、APMによるデータ収集を活用し、結合テスト・総合テストにおける開発者の不具合対応の負荷を大幅に削減します。お困りごとがありましたら、当社にお気軽にご相談ください。 ※1 Langchain：大規模言語モデル（LLM）を効率的に実装するためのフレームワーク。開発者がLLMを使用したアプリケーションを簡単に作成できるように設計されており、特にGoogle CloudのLLMであるPaLM 2を操作する基本的な方法を提供している。 ※2 APM：「Application Performance Management」の略で、アプリケーション性能管理を意味します。これは、アプリケーションやシステムの性能を監視し、管理するプロセスです。APMツールは、アプリケーションの応答時間や、構成要素のパフォーマンスを調査し、アプリケーション全体の稼働状況を把握するために使用されます。 The post AIの目で見るバグの世界：デバッグの未来形 first appeared on Sqripts .

テストエンジニアが身につけておきたいスキルの一つ「論理のスキル」。 「論理の言葉」の意味や働きに注意が向くようになったら、文や文章の読み書きで実践していきましょう。 この連載では、「論理スキル“実践編”」と題して、「文章の筋道を把握する、主張を理解する」「文や文章の筋道を組み立てる」ことに役立つ 推論の形 を見ていきます。 ＜テストエンジニアのための論理スキル[実践編]　連載一覧＞ ※クリックで開きます ・ 論理のかたち。推論とは 【連載初回、全文公開中】 今回のテーマは「基本的な推論形式」です。 「推論」と言われると難しそうに感じるかも知れませんが、“入門編”で見た「論理の言葉」が基本になります。 「論理の言葉」を復習してから、推論を支えてくれる基本的な形を見ていきましょう。 前回のクイズ解答 前回、「 論理のかたち。推論とは 」で出題したクイズの解答です。 （問1, 2とも、今回の内容でおさらいしています） 問1 Aさんの性格を考えると、①Aさんはギャンブルに手を出すと破産する。 しかし、②Aさんはギャンブルには手を出さない。 従って、③Aさんは破産しない。 ①は「PならばQ」という 条件法 の形をしています。 ②③は①に対し「PでないならばQではない」という、“裏”の形をしていますが、これはよい形ではありません。 問2 その時代、①家柄がよくて、裕福ならば、誰でも結婚できた。 ②彼の家柄はよかった。 しかし、③結婚できなかった。 従って、④彼は裕福ではなかった。 ①は「(PかつQ)ならば、R」という形をしています。③の「Rではない」から、「Rでないならば、(PかつQ)ではない」という 対偶 の形が考えられます。「(PかつQ)ではない」ということは、「Pでないか、またはQでない」ということです（ ド・モルガンの法則 ）。 ②でPであることが言われているので、「Pでない」可能性は消え、残る「Qでない」が結論として④で述べられています。この主張はよい形をしています。 推論を形づくる“道具” 推論で大切なのは、前提から結論まで筋道を立ててつなげていくことでした。その筋道は、「論理の言葉」をいわば“道具”として作ります。 この“道具”の使い方をよく理解しましょう。 文と文を繋げる道具　――論理の言葉おさらい 基本の論理演算：AND/OR/NOT 論理の言葉の基本のうち、論理演算、AND(論理積)、OR(論理和)、NOT(論理否定)の真理値表を図2-1に示します。（ “入門編”第3回 基本の論理演算 ） 図2-1 基本の論理演算・真理値表 “ならば”と、等値(同値)の“ならば” 条件・場合を表す言葉“ならば”(条件法)と、等値の“ならば”(双条件法)も、論理の言葉の基本でした。（ “入門編”第6回 条件・場合を表す言葉 ） これらにも真偽があり、真理値表で表すことができます。 「“ならば”という言葉の働きが成り立つ場合(真)と成り立たない場合(偽)がある」と考えてください(図2-2)。 図2-2 条件法と双条件法 条件法の真理値表(図2-2 左)で「おや？」と思うところがありませんか？ 2行目・4行目。 Pが偽の時、Qが真でも偽でも“ならば”は真 となっています。 これは条件法の 「Pが真でない時」のことは何も言っていない という性質に由来します。何も言っていないのだから、Qが真でも偽でも“ならば”自体は成り立つ、「あり」とする、という 約束、取り決め と考えてください。（なお、この性質を悪用すると、とんでもないことも「妥当な推論」として言えてしまいます） 3行目。「PならばQ」は、「Pが真なのにQが偽であることはない」という意味です。そこで、 Pが真でQが偽の場合は、条件法は偽(成り立たない) と考えます。 “実践編”での呼び方：選言、連言、仮言、定言 論理積/論理和といった用語に代えて、“実践編”では、堅い響きですが短い呼び方を用います。 論理積(“かつ”)を 連言 とも呼びます。ふたつの主張/判断が連なっているイメージですね。 論理和(“または”)を 選言 とも呼びます。ふたつの主張/判断のいずれかを選び取るイメージですね。 条件法(“ならば”)は 仮言 とも呼びます。“ならば”を用いた主張/判断を 仮言文(仮言判断) と呼びます。 仮言文に対し、「ネコは哺乳類である」「ネコは鳥類ではない」といった断言形式の主張を、 定言文(定言判断) とか 断言文(断言判断) と呼びます。 基本的な推論形式 (1) “入門編”で見たことのあるもの 論理の言葉はそのまま使える 前章でおさらいした基本的な論理の言葉の性質や働きと、次に挙げる論理の言葉の働きは、そのまま推論に用いることができます。 図2-3で、 ⇔の左辺の形は右辺の形に、右辺の形は左辺の形に言い換えることができます ( 前回のクイズ 参照)。 図2-3 基本的な推論形式 (1) 二重否定は “入門編”第3回 基本の論理演算 参照 ド・モルガンの法則は “入門編”第4回 論理演算の組合せ 参照 3・条件法と対偶に関して、逆（QならばP）と裏（PでないならばQでない）は一般には正しくないことも思い出しましょう。 4・条件法の言い換えについて。Pの否定・NOT(P)とQとのORをとると（ NOT(P) OR Q ）、“ならば”と同じ真理値の表が得られます(図2-4)。 この関係から、「PならばQ」は「Pでないか、またはQである」と言い換えて考えることもあります（このように同じ真理値を持つ論理演算どうしの関係も“同値”と呼びます）。 図2-4 “ならば”と「Pでないか、またはQ」 基本的な推論形式 (2) ちょっと複雑な形 推論を形づくる論理の言葉 論理の言葉を組み合わせて、複雑な推論の形を組み立てることができます。その中でも基本的な形とされているものをいくつか図2-5に示します。 図2-5 基本的な推論形式 (2) 6は“または”の意味/働きを使った推論で、 選言三段論法 と呼ばれます。 7, 8, 9は、“ならば”の意味/働きからこのような推論ができます。 7は 前件肯定 、8は 後件否定 というもので、9は“ならば”を重ねています。 併せて 仮言三段論法 と呼ばれます。 10, 11は複雑さが増して感じられますが、「AかBかどちらか」ということを言い表すのに使います。これらは 両刀論法(ディレンマ, ジレンマ) と呼ばれる形です。 次回以降、これらの推論形式を詳しく見ていく予定です。 「当たり前」には裏づけがある 図2-5、（10, 11は別としても）どれも「当たり前では？」と思う人も多いでしょう。実際、これらは私たちの日ごろの思考に通じているものがあります（というか、「私たちの思考」を吟味して論理の言葉や推論の形式ができているのですが）。 この「当たり前」は論理の言葉が保証してくれている、裏づけがある、と知っておくのは大切なこと です。 「よい形」であるのは、当たり前だからなのではなくて、「論理の言葉の使い方として正しいからよい形（妥当）」ということです。 三段論法 2,000年以上の歴史を持つ推論の形 前章で三段論法という言葉が出てきました。 前提2個に結論1個で構成されるから「三段論法(syllogism)」と呼ばれます（前提の数は3個以上でもよい）。 「大前提、小前提、結論」という用語の組を聞いたことのある人も多いでしょう。 ふたつの前提に論理の言葉の働きを作用させたり、主張している事柄の関係性を考慮したりして、結論を引き出すようになっています。 図2-6 三段論法 “定番”の三段論法 「三段論法」と言われたら、多くの人は次の形のものを思い浮かべるのではないでしょうか（“または”も、“ならば”も、使われていません）。 人間は誰しも死ぬ。 ソクラテスは人間である。 ゆえに、ソクラテスは死ぬ。 これを見て「当たり前のことを言っているなあ」と思う人も多いと思いますが（筆者もそうです）、この形はこの形で私たちのものの考え方に根ざしており、知っておく意義はあります。 この形の三段論法は連載後半で取り上げる予定です。 クイズ （解答は次回に） 次回予告 先の「基本的な推論形式 (2)」で出てきた「“または”を使う推論の形（選言三段論法）」を詳しく見ていきます。 参考文献 近藤洋逸, 好並英司 『論理学入門』 岩波書店 1979 John Nolt, Dennis Rohatyn(著), 加地大介(訳) 『現代論理学 (Ⅰ)』 オーム社 1995 鈴木美佐子 『論理的思考の技法Ⅱ』 法学書院 2008 レイモンド・スマリヤン(著), 高橋昌一郎(監訳), 川辺治之(訳) 『記号論理学　一般化と記号化』 丸善出版 2013 図版に使用した画像の出典　 TopeconHeroesダーヤマ, 『分かりやすいプレゼン資料 1秒で伝わるビジネスイラスト集』 インプレス 2016 クイズの画像に使用しています。 テストエンジニアのための論理スキル[実践編] 連載一覧 論理のかたち。推論とは 【連載初回、全文公開中】 The post 基本的な推論形式｜テストエンジニアのための論理スキル［実践編］ first appeared on Sqripts .

本連載ではプロジェクトマネジメントの全体像と、プロジェクトを成功させる上で最低限抑えるべき知識と技術はもちろん、プロジェクトを炎上させないための技術やコツをお伝えしたいと思っています。 みなさんのプロジェクトが今以上に充実し、笑顔でプロジェクト終結を迎えられるよう一緒に学んでいきましょう。 第9回となる今回のテーマは「プロジェクトの品質マネジメント」です。 ＜ プロジェクトマネジメント成功の技術 連載一覧＞ ※クリックで開きます 【第1回】プロジェクトマネジメントとは何か？ 　［連載初回全文公開中：Sqripts会員以外の方も全文お読みいただけます］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ 【第8回】コストをプロジェクトの武器にする！ 【第9回】目に見えにくいプロセス管理こそ品質達成の鍵 品質をマネジメントする、とは プロジェクトマネジメントにおける品質のマネジメントとは、ステークホルダーの目的に合致させるためにプロジェクトとプロダクトの品質要求事項を計画し、組織の品質方針等を取り入れた形でマネジメントしていく活動です。マネジメントの対象は「プロジェクトの品質」と「成果物の品質」の主に2つです。 品質のマネジメントと聞くと、不具合やバグが出ないようにするといったイメージになるかも知れませんが、たしかにそれは品質の1つではありますが全てではありません。成果物だけではなく、プロジェクト、つまり進め方自体の品質管理にフォーカスしていることが重要です。例えば、プロジェクトのスケジュールが計画に対して維持されているか、予算内で実行できているか、これらのスケジュールマネジメントやコストマネジメントにかかる部分もプロジェクトの品質マネジメントにおける品質対象です。 品質マネジメントは以下3つのステップ（プロセス）で行います。 品質のマネジメントを計画する ステークホルダーの真のニーズを確認して「品質要求事項」を特定することから計画ははじまります。またCOQ（Cost Of Quality）、つまり品質を担保するために必要なコストを考慮し獲得しておくことが大切です。 1) 病気もプロジェクトも予防が大切 品質にかかるコストは以下の4種類に分類されます。 大切なのは適合コストと不適合コストのバランスです。適切に適合コストを使わないと不適合コストの発生確率を高めることになりますが、適合コストばかりかけすぎると利益を圧迫してしまうことになります。コスト効果としては一般的に適合コスト＞不適合コストをかけた方がよいです。 2) 「よい品質」にはばらつきがある 一言で「よい品質」「品質が保たれている」といっても、多くの場合同じ品質が指されていることはありません。Aさんは「 XX まで担保されればよい品質だといえる」と思っていても、Bさんは「それでは不十分で XXX でなければ担保されているとは到底言えない」といった感じです。また顧客とのやりとりで「高いクオリティで」という曖昧な要求を受け取る経験も少なくないはずです。 近代的品質マネジメントの提唱者は以下のように言っています。 「品質とは要求条件の一致である」 「無欠陥（Zero Defect）、検査より予防」 フィリップ B.クロスビー 「品質は誰かにとっての価値である」 G.M.ワインバーグ つまり、「品質がよい状態」とは、ステークホルダーの要求を満たし、ステークホルダーにとって価値あるものを提供することと言えますが、見ての通り「よい品質」という定義の曖昧さや捉え方によるばらつきがある（起こる）ことも同じように示していますね。 だからこそ、プロジェクトが考え目指す品質や組織で定義されている品質方針を踏まえて「どうすれば実現できるか」を品質マネジメント計画書などのドキュメントで明らかにし、みんなで品質視座をあわせて目指していけるように準備しましょう。 ＜品質マネジメント計画書に記載される基本的事項＞ プロジェクトの品質基準 品質に関する役割と責任 品質レビュー対象やレビュープロセス 品質マネジメント活動や方法 品質ツール 不適合や是正措置プロセスなどの手続き規定 3) 品質を測定する尺度を決めておく 品質尺度とは、品質の適合を「どのように検証するか」を具体的に規定したものです。クオリティメトリクス（QM）と呼ばれることもあります。例えば、時間通りに完了したタスクの割合、突き当たりの合計ダウンタイム、コード行あたりのエラー、顧客満足度、テスト網羅率の基準としてテスト計画がカバーする要求事項の割合などがあります。品質そのものへの考え方やばらつきがある、とお伝えしたように、品質を何かしら測定する尺度を持っておくことで「こんなはずじゃなかった、これは違う」というトラブルや認識齟齬を予防しましょう。 4) 品質指標 上記の品質尺度に対して、品質指標は「品質を満たしているということはどういう状態か」を定義しておきます。品質指標が顧客の要求を満たした状態か、できる限り具体的な状態を定義しておくことが品質尺度と同様に大切です。 品質のマネジメント 品質のマネジメントでは、組織の品質方針をプロジェクトに組み入れて、品質マネジメント計画を実行します。品質のマネジメントは場合によって「品質保証」とも呼ばれます。プロジェクトマネジメントの観点では、品質保証の焦点はプロジェクトの「プロセス」にあるとともに「検査より予防」の考え方と密接に関連しています。その為、計画した品質を担保する仕掛けや仕組み（規約・ガイド）が正しく機能しているかを＜確認＞することがが重要です。 1) どうやって品質確認する？QC７つ道具を押さえておこう！ 品質標準と運用基準を満たすために、プロジェクトでは常に品質改善活動を行っていかなければなりません。継続した活動の中で、無駄なくプロセスを実行できるようパフォーマンスの測定結果を確認し、問題点を改善していきましょう。改善点を洗い出すためには、まず品質コントロール測定結果を分析します。分析には「QC7つ道具（7つの手法）」や「品質監査」を用いて問題点や改善につながるヒントを抽出し、必要なプロセスの改善点をまとめて必要に応じ変更（変更要求）を行いましょう。 また「QC7つ道具」を使った数値分析は主に製造現場で活用されてきましたが、「新QC7つ道具（N7）」は実測や数値化が難しい場合や言語データも併せて分析することで設計や営業など幅広い改善活動に活用される手法です。QC7つ道具と新QC7つ道具がどのようなもので、どのように活用することができるのかを簡単にでもいいので把握し、ぜひ品質マネジメントに取り入れてみてください。 ＜QC7つ道具：データ整理や関係性分析手法＞ パレート図 特性要因図（フィッシュボーン図・フィッシュボーン分析） グラフ ヒストグラム 散布図 管理図 チェックシート ・QC7つ道具は「Q7」と略称されます。 ・QC7つ道具及び新QC7つ道具の作成手順は「JIS Q 9024:2003 マネジメントシステムのパフォーマンス改善－継続的改善の手順及び技法の指針」でJIS化。 ・新QC7つ道具は「New seven tools for QC」あるいは「New 7 QC Tools」と呼ばれ、「N7」と略称されることもあります。 3) プロジェクトの品質保証活動に組織の品質保証活動を活かす 組織内に品質保証部門などを有する場合、プロジェクト活動でそれらの部門との連携やプロジェクトチームに組み入れるなどして、故障解析や実験計画、品質改善などのマネジメント活動を実行しましょう。豊富な品質ツールと技法を持った専門部門はプロジェクトにとって優れた資源です。 4) 製品は80％が設計で決まる、デザイン・フォー・エックス（DfX）という考え方 1990年代に米国で提唱、実践されたデザイン・フォー・エックス（DfX：Design for X）は、設計（デザイン）における個々の側面を最適化するためにプロダクト設計に取り入れる技術的なガイドラインのことを言います。DfXのXは信頼性、展開、組み立て、製造、コスト、サービス、使い勝手、安全性、および品質といったプロダクトの開発におけるさまざまな側面を指します。こうして多面的な設計思想を持つことで、コスト削減や品質改善、パフォーマンス向上や顧客満足の達成を目指しましょう。 品質のコントロール 成果物（アウトプット）が品質要求事項を満たしているかを検査し、その結果適合・不適合とを判定します。適合とされた上で、ステークホルダに受け入れられてはじめて「受け入れ済み成果物」と呼ぶことができます。 1) 品質マネジメント７原則 「品質マネジメント7原則」とは、品質マネジメントシステムの規格のISO9001で、適合性と有効性を維持した品質マネジメントシステムを構築する為の大枠を7つの原則として示したものです。 原則1：顧客重視 原則2：リーダーシップ 原則3：人々の積極的参加 原則4：プロセスアプローチ 原則5：改善 原則6：客観的事実に基づく意思決定 原則7：関係性管理 ISO9000:2015 品質マネジメントシステム－基本及び用語 さいごに プロジェクトマネジメントにおける「品質のマネジメント」はテストやプロダクト、サービスだけでなく、それらを生み出すまでのプロセスが重要になっていきます。開発中に多くの品質問題がでる、それらの対応などで計画していた開発期間を大幅に超過する、プロダクトは完成したけれども不具合が多発してしまう。もしそんなことが起こっていれば、これは品質のマネジメント自体に課題がないか目を向けてみてください。 次回のテーマは「リスクマネジメント」です。 連載一覧 【第1回】プロジェクトマネジメントとは何か？ ［連載初回全文公開中］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ 【第8回】コストをプロジェクトの武器にする！ 【第9回】目に見えにくいプロセス管理こそ品質達成の鍵 The post 【第9回】目に見えにくいプロセス管理こそ品質達成の鍵 first appeared on Sqripts .

こんにちは。QAエンジニアをしているポポラスです。私はコールセンター等でサービス受付をするシステムの受入テストを担当しております。 私の現場では、ユーザーの実際のオペレーションの情報が少なく、テストベースは要件定義書のみでテスト設計を行っております。そのような状況において、ユーザー観点を出し、実際のオペレーションに沿ったシナリオを設計するために私が工夫した3つのことを、経験事例を交えてご紹介させていただければと思います。参考になりましたら幸いです。 前提 私が経験していた現場は、システムの操作方法に関する情報が乏しく、また実際の利用者からのヒアリングが出来ない状態でした。そのような中で第三者検証として受入テストを担当させて頂いた際の経験です。 工夫したこと 以下の内容は、実際に私が現場で工夫したことになります。もし実際のオペレーションの情報が無く、設計にお困りの場合、観点出しのお役に立てることがあるかもしれません。ぜひご覧ください。 その１：機能の目的を考える 機能の目的を考えることで、実際のオペレーションに近いシナリオを導き出せることがあります。 以下は実際に私がテスト設計を担当した機能での経験事例になります。 <経験事例> ■機能 サービス対象端末の特殊在庫の表示 ■機能の目的を考えなかった場合のシナリオ まず、機能の目的を考えなかった場合のシナリオは以下になります。 前提条件： なし シナリオの流れ： ①端末Aの画面に遷移し、特殊在庫を表示する ②特殊在庫を選択し、オーダーを完了させる ■機能の目的を考えた場合のシナリオ 特殊在庫機能の目的は、通常在庫が切れた場合かつサービス利用者がどうしてもその端末を希望する場合に、予備の在庫を臨時的にサービス利用者に提示すること、と考えられます。 上記の目的から、以下のシナリオが導き出せます。 前提条件： 端末Aの通常在庫なし シナリオの流れ： ①端末Aの画面に遷移し、通常在庫切れ表示となることを確認 ②特殊在庫を表示する ③特殊在庫を選択し、オーダーを完了させる 機能の目的を考えたことで、「前提条件」と「シナリオの流れ①」がより実際のオペレーションに近い条件として導き出すことができました。 その２：3w1h 機能の目的を考えることで実際のオペレーションに近いシナリオを導き出せましたが、この「3w1h」では、そのシナリオに対して観点のバリエーションを持たせることができます。 今回ご紹介する「3w1h」は以下の要素となります。 Who（だれが） When（いつ） Where（どこで） How（どのように） 実際に私の現場で実践した3w1hは以下になります。 <経験事例> ■機能 サービス対象端末の特殊在庫の表示 ■「Who（だれが）」の考察 これは「システムを使用するユーザー」という理解で考察します。実際にサービス受付システムを使用するユーザーは以下3つのタイプが存在しますので、観点のバリエーションに加えることができます。 コールセンターのオペレーター 店舗の担当者 サービス利用者 ■「When（いつ）」の考察 これは機能が使われる「状況」という理解で考察します。状況として以下4つのパターンが考えられます。 通常在庫が切れた時 通常在庫が補充された時 特殊在庫が切れた時 特殊在庫が補充された時 ■「Where（どこで）」の考察 これは場所ではなく、私の現場の場合は機能を使用するプラットフォームという理解で考察します。プラットフォームは以下3つのパターンが考えられます。 コールセンターのオペレーターが使う受付システム 店舗の担当者が使う受付システム サービス利用者が直接Webサイトからオーダーする受付システム ■「How（どのように）」の考察 これは「どのように機能を実行するか」という理解で考察します。以下4つのパターンが考えられます。 デスクトップPCから特殊在庫を確認する ノートPCから特殊在庫を確認する スマートフォンから特殊在庫を確認する タブレットから特殊在庫を確認する その３：UMLを使ったアプローチ 工夫その１と２は、ユースケース図やアクティビティ図といったUMLを、テスト視点で活用することで導き出すアプローチもあります。UMLを使うことで、機能の目的や3w1hの観点を整理することができ、整理した観点を俯瞰的に見ることで、観点の抜け漏れや新しい観点の気付きにも繋がります。 ユースケース図 アクティビティ図 その４：顧客から情報を引き出す 顧客から市場での実際のオペレーションの情報を引き出すことで、シナリオの設計に活用できます。これは最もシンプルな方法ですが、最も実際のオペレーションに近い情報となりえます。 その５：観点のフォーマット化 工夫その１～４で導き出した観点をフォーマット化することで、他要件の観点出しにも流用が可能となります。更にフォーマットをチーム内で共有し、ユーザー観点を蓄積していければ、フォーマットのブラッシュアップを行っていけます。 結果 上記の工夫を行うことで、受入テストのユーザー観点不足を緩和することができ、より実際のオペレーションに近いシナリオを充実させた受入テストを行うことができます。 まとめ 実際のオペレーションの情報がほとんど無い現場でも、機能の目的や3w1hを考え、UMLを活用することで、ユーザー観点を導き出していけます。更に、導き出した観点をフォーマット化してチーム内で資産化することで、今後の他要件への流用やユーザー観点のブラッシュアップなどの付加価値を生むことができると思います。 本記事の内容は、受入テストのテスト設計としては当たり前の内容かもしれませんが、私の経験事例が皆様の参考になれば幸いです。 最後まで読んでいただき、ありがとうございました。 The post ユーザー観点を追加したい！そんな時に。受入テストにおけるユーザー観点の考え方 first appeared on Sqripts .

第1回目の記事【 パスワードの基礎と主な管理手法について 】で、パスワード管理手法のうち、業務効率化の観点及び安全性向上の観点からパスワードマネージャーによる管理が有効な手段であることをご紹介しましたが、今回は具体的な選定のポイントについてご紹介をしていきたいと思います。 【第1回】パスワードの基礎と主な管理手法について パスワードマネージャーの選定ポイント 無償ツールと有償ツール パスワードマネージャーは主に無償・有償の観点でツールを大別することができます。 無償ツール：主にブラウザベンダーがブラウザに標準搭載しているパスワードマネージャー機能のこと 有償ツール：専門のサイバーセキュリティベンダーから提供されているもの ※無償ツールの中には有償ツールを提供するベンダーが提供する無償版も存在しますが、今回はスコープ外とします。 無償ツールの特徴（メリット、デメリット） 以下に、無償ツールの特徴をご紹介します。 [代表的な提供ベンダー] Apple（Safari）、Google（Chrome）、Mozilla（Firefox）、Microsoft（Edge,IE） [メリット] ランニングコストがかからない ： 文字通りですが、無償であることが最大の魅力です。 利用・導入の容易さ ： ブラウザの機能となるため、導入作業無しに即時利用が可能です。 [デメリット] 安全面の不安 ： ブラウザはパスワード管理をするための物ではないため、安全面よりも利便性を追求しています。その上で、追加的に付与された機能であるブラウザパスワードマネージャーには安全面で以下の危険があることを認識しておく必要があります。 パスワードの保存/利用と暗号化 一部のブラウザでは一貫した暗号化がなされない（若しくは、なされていなかった）ことが専門家により指摘されております。具体的には、本来、機微情報であるパスワードを暗号化して保管し、復号して利用する場合、そのパスワードを復号できる人は唯一、利用者本人であり、利用者本人がパスワードを利用しないときは完全に暗号化されている必要があります。（＝ゼロナレッジアーキテクチャ ※1 ） しかし、一部のブラウザにおいて、部分的に暗号化がなされておらず平文で保管される瞬間や場所がある（若しくは、あった）ことが指摘されております。 アクセス制御 皆様は普段どれくらいの頻度でブラウザにログインを行っているでしょうか。多くの方は、ほぼ常時ブラウザにログインした状態で作業をし、頻繁にブラウザからログアウト→ログインをするというのは稀なのではないでしょうか。これ自体が悪いわけではありませんが、パスワード管理の観点では危険と隣り合わせの行為と言えます。 ブラウザでパスワードを保管している場合、ブラウザにログインしている間、パスワードは平文で確認することができる状態となっているため、上記のようなブラウザの使い方をされている方は、ほぼ常時パスワードが暗号化されていない状態に晒されていることになります。この状態で端末を紛失したり、他人が端末を操作できてしまえば保管されているパスワードが全て漏洩する危険があると言えます。 マルチデバイス対応とアタックサーフェイス ブラウザでパスワードを保管する場合、その情報は他のブラウザとは共有されません。つまり、複数のブラウザを利用する場合、それぞれのブラウザでパスワードを保管する必要があります。利用方法にもよりますが、一般的に複数回パスワード生成や保管の作業をする必要があるという利便性の低さと、機微情報であるパスワードを多くの箇所に置くことにより、アタックサーフェイス（＝サイバー攻撃を受ける可能性があるポイント）が増えるという安全面での懸念があると言えます。 有償ツールの特徴（メリット、デメリット） 以下に、有償ツールの特徴をご紹介します。 [代表的な提供ベンダー] Dashlane、Keeper Security、LastPass、1Password [メリット] 高い安全性 ： 有償ツールはパスワード管理専用ツールであり、安全面を最重視した設計となっているため、無償ツールがかかえる「安全面の不安」を以下のように解消することができます。 パスワードの保存/利用と暗号化 有償ツールの中でも採用している暗号化アルゴリズム、暗号化の単位は異なりますが、基本的に ゼロナレッジアーキテクチャ ※1 に基づいた暗号化メカニズムが採用されており、パスワードが平文で晒されるようなことがない設計となっています。 アクセス制御 有償ツールのほとんどがログインタイマー等の設定がデフォルトで有効化されており、パスワード利用後は自動的にログアウトする設計となっています。 利便性が下がるように思われるかもしれませんが、有償ツールのログインに指紋認証や顔認証を用いることで、利便性が大幅に下がることを防ぐこと可能です。 痒い所に手が届く ： 一部後述する「パスワード利用状況の可視化」、「適切なパスワード共有管理」等のパスワード管理専用ツールとしての機能を利用することができ、包括的なパスワード管理が可能です。 [デメリット] ランニングコストがかかる： 当たり前ですがコスト発生はデメリットであり、メリットとの比較が必要になります。 ※1 ゼロナレッジアーキテクチャ（ゼロ知識アーキテクチャ） ゼロ知識アーキテクチャとは、顧客データの平文（暗号化されていないデータ）をベンダーのクラウドに送信することなく、ユーザーのデバイス上でのみ暗号化と復号を行う仕組みです。 アプリケーションが平文を保管することはありませんし、ベンダーのクラウドが平文でデータを受信することもありません。 データが他のデバイスに同期される場合には、他のデバイスで復号（デコード／暗号化データの解読）されるまで、データは暗号化されたままとなります。 無償ツールと有償ツール、選定のポイントは？ GoogleChromeのパスワードマネージャー では、無償ツールと有償ツール、どちらのパスワードマネージャーを利用すべきなのか。 ここからは、選定時のポイントについて解説をしていきます。 無償ツール　→　有償ツールの順序で考える 最初にお勧めしたい大切な考え方は「無償ツールで運用できないか？」からスタートすることです。この考え方でスタートし、どうしても有償ツールが必要な場合には有償ツールを検討する、という順序が重要となります。 その上で、無償・有償の判断が分かれるポイントして以下の要素が参考になります。 個人利用か法人利用か？ この観点でいうと、個人利用＝「無償ツール」、法人利用＝「有償ツール」と考えるのが一般的です。 個人利用の場合、パスワードの管理責任は各個人にありますが、法人利用の場合、その管理責任は法人に帰属する点がポイントです。一般的に有償ツールには、組織全体のパスワード管理状況を可視化し、管理者は各従業員の「 パスワード使い回しの有無 」や「 弱いパスワードの利用 」をチェックする仕組みが搭載されています。しかし、無償ツールにはそのような仕組みは存在しません。（もちろん、スプレッドシートやメモにも存在しません） そのため、法人利用に無償ツールを選定してしまうと、適切なパスワード管理が組織的になされているか分からず、サイバー攻撃後のインシデント調査ではじめて管理体制の不備を指摘されるという結末になりかねません。こういったことから、基本的には法人利用＝ 有償ツールが適している という結論になります。 ※但し、小規模な組織等で、何らかの手段で適切なパスワード管理を組織として担保できる場合には、法人利用でも無償ツールは有効な手段となり得ます。 例：セキュリティ知識のある数名で設立したベンチャー企業など。 共有アカウント（＝ID/PW）はあるか？ そもそも、「パスワード共有」自体、行わないことがベストなのは言うまでもありませんが、業務上、やむを得ないケースも存在致します。 よくあるのが、SNSアカウントの運用を複数人で行うケースや、外部から付与・貸与されているアカウントを複数人で行うケースです。 このようなケースでは、必然的に1つのアカウントを複数人で共有しながら運用していくことになるため、ID・パスワードの管理を安全かつ効率的に行うことが業務上でとても重要となります。 そして、ほとんどの有償ツールにはこのような課題を解決するためのパスワード共有機能が搭載されています。詳細な機能説明は各ツールごとに異なるため省きますが、この機能を用いることで、メールやスプレッドシートで平文もしくはそれに近い低強度な保護でID・パスワードを共有するのではなく、有償ツール上で、必要な時に、必要な人にだけ（＝Need to KnowやLeast Privilegeの原則に沿った）、高強度の保護と共にID・パスワードを簡単に共有することが可能となります。 まとめ パスワードマネージャーは無償ツールと有償ツールで大別されます。 無償ツールは安全性よりも利便性を重視しており、有償ツールはその逆と言えます。 無償/有償をどちらかにするか考える時は「無償ツールでいけないか？」から考え、ダメなら有償ツールを考えるのがオススメです。 個人利用＝「無償ツール」、法人利用＝「有償ツール」が基本的な考え方となります。 法人利用の場合、従業員の「パスワード使い回しの有無」や「弱いパスワードの利用」をチェックする仕組みが必要となります。 次回はMITREフレームワークに見るパスワード管理について解説します。 シリーズ「組織におけるパスワード管理」記事一覧 【第1回】パスワードの基礎と主な管理手法について The post 【第2回】パスワードマネージャーの選定時のポイント first appeared on Sqripts .

みなさんは、知的生産や知的生活ということばを聞いたことはありますか？ 初めて聞いた、という方はもしかしたら「堅そう」とか「えらそう」といった印象を持つかもしれません。 ところが、私はこの知的生産・知的生活は「ITエンジニア皆に知っておいてほしい」と考えています。もちろん、好き・嫌い、合う・合わないはあるでしょう。 そのため「全員に身につけておいてほしい」ではなく「そういった考え方があると知ってほしい」と、一段階トーンを下げた言い方をしています。 この連載では、ITエンジニアにとって親和性が高く「スキルアップしたい」と思う方にとっては役に立つであろう知的生活について、いろいろなアクティビティやツール、仕事での活用方法などについてご紹介します。知的生産・知的生活の考え方や、「そもそも知的生活とはどうあるべきか」等の話ではなく、できるだけエンジニアの普段の生活や仕事に役立てられるテクニックよりの話をするつもりです。 知的生産・知的生活とは テクニックの話をします、とは言ったものの、知的生産・知的生活について事前情報なしに話を進めてもわかりづらくなってしまいます。 まずは知的生産・生活をこの連載においてどのような意味で扱うかや、それがエンジニアにとってどう関係するのかからスタートしましょう。 知的生産界隈における有名な書籍のひとつに、『知的生産の技術』があります。 この本によると、知的生産は 知的生産というのは、頭をはたらかせて、なにかあたらしいことがら――情報――を、ひとにわかるかたちで提出すること 「知的生産の技術」（岩波新書） くらいに考えておけばよい、とされています。 これを元に、私は知的生産というものを、 インプット 処理 アウトプット の3要素で考えています。 つまり、アウトプットである「なにかあたらしい情報や価値」を出すために、いろいろなインプット＝情報をあつめて、自分の頭やいろいろな道具を使って処理＝思考をする。これが知的生産です。 そして、知的生産を日常生活の中に組み込み、ひとつの楽しみとして行うことが「知的生活」であると考えています。 ちなみにこの『知的生産の技術』は1969年に初版が発行されたもので、知的生産という概念はこれだけ昔から存在していました。 ITエンジニアと知的生活 前述の知的生産の要素に照らすと、多くのITエンジニアが行っているような 技術書を読む 技術的な情報を集める、調べる 勉強する テックブログを書く 勉強会などで発表する 技術書や技術系同人誌を書く なども、ひろく知的生活の一部と言っていいでしょう。 一部、というのは、たとえば技術書について「読みっぱなし」では知的生産とは言えません。そこからアウトプットまで行って初めて知的生産といえます。もちろんこれは感想ブログを書く等に限らず、本で得た知識を普段の仕事に活かすことも立派なアウトプットでしょう。 我々ITエンジニアは知識労働者（ナレッジワーカー）と表現されることがあります。知識や経験を使って価値を生み出すことが求められます。これは、まさに知的生産といえます。 ITエンジニアの周辺では、たびたび「自己研鑽」が話題になります。気合いを入れて毎日勉強するのも良いですが、そうではなく日々の知的生活を楽しんでいたらいつのまにかスキルアップしていた、そういった形もアリだと考えています。皆さんの周りにもそのようなタイプのエンジニアが居るのではないでしょうか。もしくは、あなた自身がそうかもしれません。 楽しみながらスキルアップしたいという方にとって、知的生活をより楽しく実りあるものにするためのテクニックや考え方を学ぶことは、エンジニアとしての成長に直結するのです。 知的生活をよりよくするためのツールや考え方 先に、ITエンジニアにとっての知的生活の要素として インプット 処理 アウトプット の3つが考えられる、と述べました。 それぞれの要素について、よりやりやすくしたり、効果的に行うためのツールや考え方があります。 本連載では次回以降これらのツールや考え方、実際の活用方法などをご紹介します。本記事でも、それぞれ簡単に触れておきましょう。 インプット 知的生活では日常的なインプットが大切です。我々ITエンジニアは日ごろからさまざまな情報が勝手に流れてくる環境にあるため、あえて「大切です」という必要はないかもしれません。 SNSではソフトウェア開発にまつわるプラクティスや言語・フレームワークなどの情報も日々流れてきます。もちろん、読書や日々の業務中の調べ物もインプットにあたります。 「どうやって情報を集めるか」に苦労する方も居るかもしれませんし、一部には「大量に流れてくる情報をどう拾いあげ、自分のものにするか」で困っている方もいるかもしれません。 個人のナレッジを蓄積・管理する概念として「PKM：Personal Knowledge Management」があります。主にデジタルなツールを用いて、インプットした情報を管理しその後の処理→アウトプットにつなげる方法論で、蓄積した複数のメモやノートの類似性やつながりから新たに着想を得たりします。 こうしたデジタルツールを用いた情報蓄積は、ふだんからPCやデジタルデバイスに向かって仕事をしているITエンジニアにとって好相性です。皆さんの中にも、言葉自体は初めて聞いたけれども前からやっていたことに近いな、と感じる方がいらっしゃるでしょう。 処理 前段のインプットにて得た情報を蓄積することで、先のアウトプットに至るためのさまざまな処理を行います。処理といっても、ここでは機械的にできることだけではありません。 会社のテックブログの執筆当番が回ってきて、「何を書こうかな・・・」と過去のメモを見返してうんうんとうなるようなことも、この処理に該当しています。 ここでは主に、蓄積した情報をもとにどう発想するかや、発想を得るための道具について扱います。 ソフトウェアテストを仕事にしている方は、「マインドマップでソフトウェアテスト」という手法を聞いたことがあるかもしれません。この例ではマインドマップはまさに発想を得るための道具ですし、テストのためにマインドマップを使う際の考え方・使い方が発想法に該当します。 アウトプット アウトプットに関しては、ツールというよりも習慣化・仕組み化や、どのような場にアウトプットするかが重要になるでしょう。 現在はSNSやブログサービスなど無料でアウトプットを公開できる場がいくつもあります。また、エンジニアのアウトプットという点では、勉強会で登壇したり同人誌や一般書籍としてまとめることもできます。 ただ、いきなり「アウトプットしましょう」と言われても難しいという方も多いと思います。今後の連載の中では、小さいアウトプットから大きなアウトプットにつなげていく流れについても解説します。 効率だけでなく、楽しく知的生活を送ろう 本記事では知的生産や知的生活について、そしてそれらがエンジニアにとってどう関係するのか、またエンジニアの知的生活の要素についても簡単に触れました。 エンジニアにとっての知的生活は、もちろん成長につながることを目指して行う面もあります。ただ、成長速度や効率ばかりを追い求めてしまうと、苦しくなってしまいます。 この連載では効率もですが、より「楽しく継続できる」ことを大事にしたいと考えています。 仕事のためにとプログラミング言語を習得するよりも、便利ツールや作りたいアプリケーションのために身につけるほうがいい、という考え方と似ています。 知的生活やその要素自体を楽しんでいった先で、気がついたらエンジニアとして成長・スキルアップしていた、という状態を目指していきましょう。 The post 知的生活とはなにか？エンジニアにどう関係するのか first appeared on Sqripts .

こんにちは。クオリティマネージャーのおすぎです。 「段取り八分、仕事二分」という言葉があります。 仕事の事前準備の大切さを表すもので、仕事に取り掛かる前にきちんと段取りを済ましておくことで仕事の8割は完了している、という格言です。 段取りはプロジェクトマネジメントにおいても非常に重要になります。 蛇足ですが「段取り」の語源をネットで調べると 作業の順序や方法を定めたり必要に応じて手配をしたりすることで、歌舞伎の楽屋用語からきているとされています。「段」とは一区切りや一幕のことで、芝居の筋や構成の運びを段取りと言う。  だそうです。 プロジェクトの成功率 一般的に「プロジェクトの成功率は30％」と言われています。 成功の基準は一旦脇に置きますが、例えばJUASが発行している ※1 「 企業IT動向調査報告書 2023 」を見てみると、予定工期を守れたプロジェクトは、100人月未満のプロジェクトの場合で全体の3割程度になっています。 プロジェクトの規模が大きくなればその割合はさらに減る傾向にあるようです。 一昔前のプロ野球なら3割打てれば一流打者と言われたものですが、プロジェクトマネジメントも3割の確率で成功させれば一流の証になるのでしょうか？？？ どうせやるなら3割と言わず10割を目指したいですが、自分の担当するプロジェクトがその3割の成功プロジェクトに仲間入りできるのかどうかは、この「段取り」にかかっていると言っても過言ではありません。 今回はプロジェクトを進める上で「段取り」がもたらすメリットと、私が「段取り八分」を実現するために実際に意識していることをご紹介します。 「段取り」に期待するメリット プロジェクトを段取り良く進めることで様々なメリットがあると思いますが、私は主に２つのメリットがあると考えています。 生産性の向上 業務の効率化 働き方改革が叫ばれる中、生産性を落とさずに就業時間内で作業を完了できるかを求められることが多くなってきました。 働き方改革を実現するためにも生産性の向上や業務の効率化は避けて通れない道だと思いますが、段取りを上手く進めることは、その実現に大きく寄与します。 生産性の向上 何をするのかはっきりしない状態で作業を開始しても、何から手を付けて良いかわからなければ、作業はすぐに停滞してしまいます。 作業のスコープや優先度を明確にすることで、作業を停滞させることなくスムーズに進めることができます。また、スコープがはっきりしていることで作業の手戻りを減らすことにも繋がるため、リソースを無駄なく最大限に活用することができます。 プロジェクトを進める中で発生するであろうリスクを事前に洗い出しておくことで、実際に問題が発生した場合でも速やかに対応することができ、作業の停滞を最小限に留めることができます。 業務の効率化 作業を進めていると様々なことが起こりますが、何かあるたびに手を止めて確認していては、作業も思うように進みません。 大きなプロジェクトになればなるほど対応する人数も増えますが、それぞれが何かあるたびに手を止めていては、結果として膨大な工数を無駄に消費することになります。 作業の手順やフローを明確にしておくことや、プロジェクトの中で使用する定義を明確にしておけば、何か事が起こっても速やかに対応することができるため、作業を効率的に進めることができます。 段取りする上で意識していること 私はクオリティマネージャーとしてテスト工程をマネジメントしており、プロジェクト計画書やテスト計画書を作成しています。 その活動こそが「段取り」に当たりますが、私がプロジェクトの「段取り八分」を目指すために意識している観点がありますのでご紹介します。 ステークホルダーとスコープを整合する プロジェクト計画書やテスト計画書を作成している方は必ず意識していますが、私は特にテストのスコープについてステークホルダーと整合するようにしています。 ソフトウェアテストの７原則に「全数テストは不可能」という原則があります。 その原則通り全てをテストするのではなく、影響範囲やスケジュールなどを考慮してテストのスコープを決めるのですが、「すること」よりも「しないこと」を整合できるように努めています。 何をどのようなテストをするのか決めることは、テストをスムーズに進める上で重要なのは間違いないです。 しかし我々がテストのスコープではないと考えていることを、ステークホルダーがテストのスコープだと考えているケースは少なくありません。 ステークホルダーとの認識齟齬は、追加のテストや作業の手戻りが発生するなど、納期遅れの原因になることがあります。 そのため「テストしないこと」を事前にステークホルダーと整合しておくことが重要だと考えます。 プロジェクトメンバーと手順を共有する プロジェクト計画書やテスト計画書でWBSを作成し、メンバーが何をすべきなのか明確になっていたとしても、その1つ1つを具体的にどう進めれば良いのか決めていなければメンバーの手が止まります。 メンバーの手が止まるだけでなく、プロジェクトマネージャーやプロジェクトリーダーも、その都度メンバーに指示したり、メンバーからの質問に対応しないといけなくなり、思うように進捗が上がらなくなります。 そのためメンバーが作業の手を止めることがないように、WBSで細分化したアクティビティやタスク単位で、作業方針や作業フロー、ルールを定義するようにしています。 その際に注意しているのが、それぞれの目的や意図を合わせて明示しておくことです。 プロジェクトが進むと想定していない様々なことが起こりますが、目的や意図を明確にすることで、メンバー１人１人が応用を利かせた対応がとれるようになります。 プロジェクトマネージャーやプロジェクトリーダーの指示がなくても、メンバーだけで自走してプロジェクトを進めることができるようになっていきます。 腹八分で割り切る プロジェクトは生き物に例えられるように、動き出すと何が起こるかわかりません。 「段取り」が重要なのは間違いありません。 しかし事前に完璧な「段取り」を済ますことは困難ですし、あまりに色々なことを決めすぎても、実際の想定と違う状況になり労力が無駄になることがあります。 そのため「仕事二分」を実現するために「段取り」に拘るものの、その「段取り」も目一杯やるのではなく「腹八分」に抑えるようにしています。 具体的には成果物についてと、目に見える範囲や直前のアクティビティやタスクに対して目一杯段取りを進め、以降のタスクについてはザックリした方針だけ決めておき深追いしません。 それらはプロジェクトが動き出してから段階的に詳細化することで、段取りにかかる労力を分散できるようにしています。 さいごに 昨今はウォーターフォールだけでなくアジャイルの開発プロセスを採用するプロジェクトも多くなっており、状況の変化に対するスピード感が必要になります。 プロジェクトが動き出すと何が起こるかわからないため、想定外の事態が発生したときに、あれもこれも手を出していると、その変化に対応しきれません。 想定外の事態に「仕事二分」の労力の全てを注げることができれば、プロジェクトを成功に導くことができるのではないでしょうか。 私もクオリティマネージャーとして「段取り八分」を徹底し、３割の成功を手にできるようにこれからも邁進したいと思います。 ※1 一般社団法人　日本情報システム・ユーザー協会（JUAS） 企業IT動向調査報告書 2023 https://juas.or.jp/cms/media/2023/04/JUAS_IT2023.pdf The post 段取り八分／仕事二分のマネジメント first appeared on Sqripts .

こんにちは。Sqripts編集部です。 この記事では脆弱性の基本や「脆弱性をなくすことはできないのか」に焦点を当てて解説します。 脆弱性の本質、その存在理由、そしてリスクを最小化するアプローチを解き明かしますので、ぜひセキュリティ対策の参考にしてください。 脆弱性とは？ 用語の定義を理解する 脆弱性とは、システム全体のセキュリティを損なう可能性をもつ「弱点」です。一般的にはソフトウェアのバグ、設計ミスによる欠陥、不適切なセキュリティポリシーや管理体制（による防御の穴）などが含まれます。 総務省の定義によれば、 コンピュータのOSやソフトウェアにおいて、プログラムの不具合や設計上のミスが原因となって発生したサイバーセキュリティ上の欠陥 出典： 総務省『国民のためのサイバーセキュリティサイト』 とされています。 セキュリティ上のリスクを理解する 上記の「弱点」を通じて、攻撃者は不正アクセスを試み、データを盗む、サービスを妨害する、その他の悪意ある攻撃をしかけます。脆弱性に脅威が迫ったときに、システム損害のリスクあるいは、事業継続のリスクなどが生じます。 詳しくは「脆弱性のリスク」の章にて後述します。 なぜ脆弱性が生まれるのかを理解する 攻撃の対象となってしまう脆弱性は、私たちエンジニアが生み出しているという観点を持つことは重要です。脆弱性はシステムを設計する者、システムを利用する者が生み出しており、生み出された脆弱性に脅威が迫ったときに初めてセキュリティリスクが生まれます。 エンジニアから脆弱性が生まれる要因としては、スキル不足、ミスコミュニケーション、要件の急な変更、不十分な品質テストなどさまざまなことが考えられます。人間が関与する限り、完璧なシステムを構築することは現実的には不可能であり、「脆弱性は存在するもの」と認識しておくことが大切です。 利用者から脆弱性が生まれる要因としては、セキュリティアップデートやパッチを適用しないことが挙げられます。アップデートやパッチを適用しない環境下では、既知の脆弱性が存在し続けることになります。 また、パスワードの強度が弱い、パスワードの管理が不適切である（例えば、同じパスワードを複数のアカウントで使用するなど）といった環境も一種の脆弱性と考えられます。 【用語】 脆弱性とセキュリティホールの違いと関係性 脆弱性はシステムの弱点を広く指しますが、セキュリティホールは特定の脆弱性を指します。 セキュリティホールとはつまり、攻撃者がシステムに侵入するための具体的な「窓口」です。 セキュリティホールは脆弱性に内包されており、広義的な弱点を指す「脆弱性」という言葉と、狭義的な弱点を指す「セキュリティホール」という言葉が存在します。 脆弱性のリスク マルウェアへの感染リスク システムの弱点を許容し続けることは、さまざまなリスクを許容するのと同じです。 まず挙げられるのが、マルウェアへの感染リスクです。マルウェアに感染すると、データ漏えいや改ざん・削除といった被害が生じます。 特に近年では、マルウェアの一種であるランサムウェアの被害が世界的に注目されており、データを人質に身代金を要求するといった犯罪行為が後を絶ちません。ランサムウェアによる攻撃も高度化しており、組織化した犯罪集団が「ビジネス」としてランサムウェアを仕掛けてくるケースも目立ちます。 マルウェア感染は、直接的なデータ損失被害だけの話ではありません。顧客の信頼喪失に始まり、金銭賠償、法的責任による事業継続の危機にまで影響を及ぼします。一度評判が損なわれると即座の回復は困難であり、ダメージコントロールには莫大なコストを要します。 ひとたびマルウェアに感染すれば、自分たちが感染源となり、取引先企業への不正アクセスの踏み台になってしまう可能性もあります。あるいは、たとえば某大手動画共有サイトでは、コメント投稿に関するシステムの脆弱性から攻撃を受け、デマコメントが乱立するなど「社会的混乱」を招いた事例もあります。 マルウェアへの感染の要因 マルウェアへの感染の主な要因は、「ソフトウェアのバグ」や「設計ミスによる欠陥」と考えられます。マルウェアやランサムウェアがシステムに感染する際には、システムのバグや設計上の欠陥を突かれる事例が多くなっています。これらの欠陥（脆弱性）を悪用し、不正なアクセスを行ったり、データを盗んだり、システムを遮断したりします。 重要なのは、脆弱性を放置するリスクは派生的に広がっていくことを理解することです。適切にリスク管理と脆弱性対策を実施しないと、放置した分だけ危険度は増していきます。 脆弱性を完全になくすことはできるのか？ 「脆弱性をなくすことはできますか？」 答えはNoです。よく「開発・構築段階で十分なテストをすれば脆弱性はなくなる」と考えてしまうことがありますが、それは誤りです。 技術の進歩、攻撃手法の進化、意図しない操作などとともに新たな脆弱性は常に発見されるため、脆弱性を完全になくすことはできません。 ただし、リスクを管理し、影響を最小限に抑えることはできます。 脆弱性への対策 脆弱性対策の基本：情報収集と適切な管理 ひとことで情報収集といっても、脆弱性の情報は膨大であり、常に新たな脆弱性が発見されるため、すべてを完全に把握することはできません。 IPA（情報処理推進機構）によれば、脆弱性対策情報データベース「JVN iPedia」に登録された累計脆弱性情報は2024年3月時点で206,571件に上り、毎年右肩上がりで件数を伸ばしています。各メーカーや開発元からひとつひとつ脆弱性情報を集めるのは実質的に不可能であり、急速に脆弱性の数が増加する昨今においては、効率的ではありません。 網羅的に情報収集をしつつ、迅速な脆弱性の対策を実現するためには、データベースの活用が有効です。代表的なデータベースとしては以下の3つが挙げられます。 JVN（Japan Vulnerability Notes） 日本国内で使用されているソフトウェアの脆弱性情報を入手するのに適しているデータベースです。 NVD（National Vulnerability Database） 世界全域の脆弱性情報を入手するなら、米国国立標準技術研究所（通称NIST）が運営するNVDを活用するとよいでしょう。（英語表記サイトです） JVN iPedia JVNやNVDなどを一次ソースとして集約するデータベースです。 具体的にどんな情報を得るべきかは、対策に必要な項目から逆算しましょう。脆弱性対策には、具体的な対策手法だけでなく、対策の必要性の有無、対策の優先度を把握しなければなりません。対策の必要性の有無を把握するには、脆弱性が検出されたソフトウェアやバージョン情報を確認します。対策の優先度を判断するには、脆弱性の影響範囲を抑える必要があります。 上記を把握したうえで、定期的なセキュリティチェック、脆弱性スキャニング、ソフトウェアの更新、従業員教育といった具体的な対策に移ります。 脆弱性診断：定期的なセキュリティチェックの重要性 技術の進歩とともに、残念ながらサイバー攻撃も進化しています。一度脆弱性対策を実施したからといって、安全だとはいえなくなってしまったのが現状です。定期的なセキュリティチェックを施すことで、新たな脆弱性にも迅速に対応し、被害を最小限に抑えることができます。 セキュリティチェックには、大きく2つの種類があります。ひとつはプラットフォーム診断、もうひとつはアプリケーション診断です。プラットフォーム診断はネットワーク内のサーバやネットワーク機器、また昨今ではIoT機器なども含む環境の脆弱性有無を調査します。アプリケーション診断では、WebアプリケーションおよびWebサイト、スマホアプリなどを対象に脆弱性を診断します。 どちらの診断も、インターネット経由のリモート診断と内部ネットワークからのオンサイト診断の2つに細分化されます。 2つの脆弱性診断において、自社に必要なリソースがあればその範囲で診断活動を実施するのが最適でしょう。しかし、脆弱性に適切に対応するためには、豊富な知見や経験による「判断力」が必要です。今自分たちが対策していることが、自社にとって正解か否かを判断できなければ、それが企業にとって致命傷となってしまう可能性もあるからです。 自社に十分なリソースがない場合は、脆弱性診断ツールや専門のセキュリティチームを活用することも検討しましょう。 まとめ 脆弱性は常に新たなものが発見されるため、完全になくすことはできません。しかし、放置すればその分セキュリティリスクは高まり、事業継続の危機はもちろん、社会的混乱やパートナー企業へも影響を及ぼす可能性があります。 脆弱性の本質を理解しながら適切な情報収集と対策を施していくことが大切です。そうすれば、万が一脆弱性からの脅威が迫ってきても、被害を最小限に食い止めることができます。 Sqriptsを通じて、読者の皆さんが「自社はどのように脆弱性と向き合っていくべきか」の最適解を見つけられることを願っています。 【参考】 総務省： 国民のためのサイバーセキュリティサイト IPA： 脆弱性対策情報データベースJVN iPediaの登録状況 AGESTのセキュリティ関連ソリューション ● サイバーセキュリティ診断 脆弱性診断サービス ● ULTRA RED セキュリティフレームワークCTEMに則ったSaaS型ソリューション ● クラウドソースセキュリティテストプラットフォーム（Synack） 世界最高峰のエシカルハッカーチームと独自のAIスキャナーを活用したセキュリティテストプラットフォーム など、さまざまなソリューションを展開しています。「必要かどうかがそもそもわからない」段階でもご相談を受けていますので、お気軽にご活用ください。 The post 脆弱性とは？脆弱性をなくすことはできないのか first appeared on Sqripts .