第六回の連載では湯本が確立したテスト手法であるIDAU法のテストプロセスを、ソースコードレベルのテストに応用した、Code Based IDAU法(CB-IDAU)について説明しました。第七回では、第５回の記事の中で述べたもう一つの応用研究の仮説の一つである、数学的グラフ特徴量によるバグ予測(Mathematical G raph Feature M etrics T est)の研究について説明したいと思います。(以降、本研究で提案するバグ予測モデルをGMTと表記します。) GMTの仮説と目的 第五回の記事において記載した、湯本が確立したIDAU法をソースコードレベルのテストに応用したCB-IDAU法を実現するために必要になったデータや結果を応用した、GMTについて、再度、説明します。 IDAU法をソースコードレベルのテストに応用したCB-IDAU法を実現するために、テストのインプットデータとなるソースコードのデータを、一旦、Control Flow Graph (CFG)の数学的なグラフ構造に変換する必要がありました。そして、IDAU法に必要となるCRUDデータも、CFGのグラフノードに属性情報として付与することが必要でした。CB-IDAU法では、このCRUD情報が属性情報として付与された数学的グラフ構造であるCFGを、IDAU法のテスト抽出プロセスに従ってテストケースを抽出するために利用しましたが、他の用途として静的コードバグ予測のためのインプットデータとしての活用が仮説として考えられます。なぜなら、このCFGのデータ構造はソースコードの情報を数学的なグラフ構造としてモデル化されており、数学的グラフ特徴量やCRUD情報を静的コードのメトリクスとして、発生したバグとの相関性を計算することが出来ると考えられるからです。一般的によく知られている静的コードバグ予測のメトリクスとして、LOC、ネスト数、複雑度のようなメトリクスが知られていますが、数学的グラフ特徴量やIDAUで利用したCRUD情報をメトリクスとしてバグ予測が可能ではないかという仮説の元、実際に発生したバグ情報との相関性を計算し、バグ予測モデルを作成することが、GMTの目的なります。 図1にGMTのバグ予測モデル生成のためのプロセスのイメージを示します。 図1 GMTイメージ 仮説実現のための課題と対策 本研究では、既にCB-IDAU法を実装した時点で、ソースコードを中間コードに変換し、CRUD情報を属性情報として付与したCFGを網羅的に生成可能な状況ではあるものの、GMTの目的であるバグ予測モデルを作成するためには、以下の課題があります。 課題1 . モデル式の定義 バグ予測を行うためには、各メトリクスとバグ情報との相関関係をモデル式として表現する必要があるが、具体的にどのようなモデル式を作成するのか？ 課題2 . 数学的グラフ特徴量の計算 すでに大量のCFGを生成する基盤を確立しているものの、これらの情報から具体的にどのようなアプローチで数学的グラフ特徴量を計算して保持するのか？また、どのような特徴量をバグとの相関を計算するメトリクス候補として採用すべきか？ 課題3 . バグ情報の取得 CFG上の特徴量と実際に発生したバグ情報との相関を調べるために、過去の大量のバグ情報を取得し、相関を計算可能なデータ形式として保持する必要があるが、具体的にどこから、どのような手法でバグ情報を取得し、どのようにデータを表現するべきか？ GMTの研究においては、これらの課題を克服するために以下のような対策を行いました。 課題1 の対策： 重回帰 解析 と AIC の採用 バグ予測のモデル式としては、目的変数としてバグ情報、説明変数としてグラフ特徴量などの各メトリクス値として、離散型二項分布一般化線形モデル(Binomial General Liner Model)を採用しました。また、目的変数であるバグ情報との関連が最も深い説明変数を絞り込むための手法として、統計学の手法の一つである、AIC (Akaike Information Criterion)を用いました。重回帰分析の式は、目的変数Y、説明変数X i とし、各説明変数の係数をα i 、補正項をβとし、iを１からnまでの整数値でメトリクスの総数を表すとすると以下の式で表現出来ます。 Y = α 1 X 1 + α 2 X 2 +・・・＋α n X n +β　(式1) 本研究ではそれぞれの変数を以下のように定義し、バグ予測モデル式として用います。      Y : バグ情報      X : 既存の静的コードメトリクス値や数学的グラフ特徴量      α: 各メトリクスや特徴量がどれだけバグに相関しているかの重み係数 後述するバグ情報やメトリクス・特徴量の大量のデータから、代表的な統計解析ツールであるRのライブラリを利用して、重回帰解析とAICの計算を行うことで、最もバグYに相関のあるメトリクス・特徴量Xのセットを抽出し、その重み係数も付与します。 課題2の対策：igraphによる数学的グラフ特徴量の計算 CFGから数学的グラフ特徴量を計算するために、本研究ではRの代表的グラフ計算・可視化ライブラリであるigraphを利用しました。下図2にigraphを利用してBonachich Power 中心性の特徴量を計算し可視化したグラフを図示します。このグラフは、連載第五回にも掲載したグラフになります。 図2 igraphで計算したグラフ特徴量 Bonachich Power中心性の例 数学的グラフ特徴量の一つである中心性とは、グラフ全体の中でどれだけ多くのノードとの関係を持っているかの指標になります。Bonachich Power中心性は、特定のノードに対してより他ノードとの関連の多さをから強い影響力を持っているノードを示す、強者と弱者の関係を持つノードを表す指標になります。上記のグラフではNo8のノードとNo101のノードが特に大きな値を持っています。実際にどのような処理を担っているノードかを掘り下げて調べると、No8のノードは、パラメータのNullチェックを行う処理に関連するノードであり、No101は複数のメソッドを実行する処理に関連するノードになります。仮に、これらの処理に不具合があった場合、バグとして検出されていた可能性が考えられるため、Bonachich Power中心性の指標の高さはバグとの相関が高そうに見えます。しかし、これは、単に１例でしかなく、汎用的にこのような性質があるのかは、より多くのサンプルを検証して、その汎用性を検証する必要があります。そのため、本研究では以下に示す、3個の既存の静的コードメトリクスと、７個の数学的グラフ特徴量を説明変数の候補として採用しました。 表1 バグ予測モデル式の説明変数 既知の静的コードメトリクス X 1 Code Steps CFGに対応するソースのステップ数 X 2 Complexity CFGに体操するソースの複雑度 CB-IDAU法で抽出したCRUD情報 X 3 CRUD CB-IDAUで付与した各ステップ毎のCRUD情報 数学的グラフ特徴量 X 4 Edge Degree CFGに含まれるエッジの総数 X ５ Node Degree CFGに含まれるノードの総数 X ６ Eccentricity Centralization グラフを円とみなした時に中心からの距離を指標とした離心中心性 X 7 Eigenvector Centralization 高次のノードと繋がる程度を表す固有ベクトル中心性 X 8 PageRank 固有ベクトル中心性にリンク流入性の概念を取り入れた中心性であり、Googleの検索アルゴリズムとして利用された指標 X 9 Bonachich Power Centralization 強者と弱者の関係を表す中心性 X 10 Betweenness あるノードが他のノード間の最短経路上にある頻度を示す中心性の指標 表1のX6からX10までの説明変数に、数学的グラフ特徴量の値が入ります。実際にあるCFGに対して其々の数学的グラフ特徴量を掲載して、値の大きさを各ノードの円の大きさとして可視化した場合の例を以下に示します。 図3 Betweenness        図4 Bonachich Power 図5 Eigenvector Centralization 図6 Eccentricity Centrality 図7 Page Rank 課題3 の対策 : GitHub からのバグ情報の自動取得 上述した対策により説明変数の値については取得することが出来ますが、CFGに変換されたソースコードに対するバグ履歴の情報である目的変数Yをどのように取得するかが課題として残っています。本研究では各CFGに対応するバグ情報をGitHubのgit log情報をAPIから自動取得するスクリプトを実装することで、バグ情報を取得しました。また、１つのCFGはJavaであれば1メソッドの実装に対応するため、各メソッドのコードに対するバグ情報が存在していた場合にはY=1とし、存在しない場合にはY=0とする単純なBinominalの一般線形回帰モデルが適用出来るようにしました。 バグ予測モデル生成プロセス GMTにおいてソースコードからバグ予測モデルを生成するまでのプロセスについて説明します。下図3には全体の４つのプロセスを図示しています。プロセスの１と２は、既に前回連載のCB-IDAU法にて説明したプロセスと同一であるため、主にプロセス3と4について詳細に記載します。 図8 GMTのバグ予測モデル生成プロセス プロセス1.  中間言語への変換 前回連載のCB-IDAU法と同様のプロセスであるため、前回連載の記載を参照下さい。 プロセス2.  CG 作成 前回連載のCB-IDAU法と同様のプロセスであるため、前回連載の記載を参照下さい。 プロセス3.  静的コードメトリクス・数学的グラフ特徴量の付与 前述の(式1)として定義したモデル式の各変数に取得した其々のデータを代入して重み係数であるα n を計算します。本研究で説明変数候補としてデータ取得した項目と、目的変数であるバグ情報を其々(式1)に対応させると、本研究で生成するBinomialの一般線形解析の式は以下のようになります。 図9 Binomial 一般線形回帰モデル プロセス4. AIC によるバグ予測モデル式の生成 また、図４のモデル式は、候補となる説明変数を全て用いたモデル式になっていますが、この状態は仮説として候補となり得る説明変数で作成したモデル式になっているため、ここから、さらに精度を向上させるために、表1に示した10個説明変数の内、最もバグ予測の有無情報に相関が強い説明変数のセットを、AICを用いて絞り込みを行います。AICの詳細な説明は統計学の分野になるため省略しますが、本研究ではAICの計算にもRの関数を利用しました。図10にAICによる説明変数削減のイメージを図示します。 図10 AICによる説明変数削減イメージ 検証実験結果 本研究の検証用のテスト対象ソースコードは、代表的なオープンソースJavaアプリケーションサーバの一つであるTomcatのソースコードを利用しました。また、検証方法としては、GMTとして導出したバグ抽出モデル式と、既知の静的コードメトリクスのみを利用して導出したバグ抽出モデル式の２つのモデル式を導出し性能比較を行いました。こうすることで、GMTとして提案した新規のモデルが、既知のモデルよりどの程度の優劣があるか評価することが出来ます。性能指標としては、２値分類予測における一般的なモデル性能指標である、混合マトリックスを用いて、真陽性(TP)、偽陽性(FP)、真陰性(TN)、偽陰性(FN)、正確性(Accuracy)、精度・適合率(Precision)、再現率(Recall)を用いて評価を行いました。 GMT ：バグ予測モデル式の導出 下図11に実際のRを用いてGMTのバグ予測モデルを計算して導出した結果画面を図示します。図11では、表1に示した10個の説明変数を持つモデル式を作成した後に、AICを用いて、もっともバグの発生に相関がある5つの変数とされる、Edge-Degree, Node-Degree, Eccentricity-Centrality, Betweenness, Eigenvector-Centralization に絞り込みをおこなっています。 図11 GMTのAICによるモデル式導出結果 既存静的コードメトリクス：バグ予測モデル式の導出 下図12にGMTの比較モデルとして、既知の静的コードメトリクスである、表1に示した説明変数のX1(Step-Count)とX2(Complexity)のみを用いてバグを予測するモデル式をRのglm関数(一般化線形モデル)を利用して導出した結果を示します。 図12 既知の静的コードメトリクスを用いたバグ予測モデル式の導出 既存の静的コードメトリクスと数学的グラフ特徴量の比較結果 図11と図12の計算により、GMTのバグ予測モデル式と、既知の静的コードメトリクスを用いたバグ予測モデル式の２つの予測モデル式を得ることが出来ました。この２つのモデル式を利用して実際のソースコードからバグの有無を予測した場合、実際のバグ発生情報との乖離の具合を比較することで、GMTのバグ予測モデルが既存の静的コードメトリクスよりも、バグの存在有無を予測するのに有効性があるかを評価することが出来ます。評価の方法としては前述した通り、混合マトリクスの指標に従って性能評価をします。図13と図14にTP, FP, TN, FNの指標の違いを図示します。また、正確性(Accuracy)、精度・適合率(Precision)、再現率(Recall)も含めた各性能指標値の差異を表2に示します。 図13 GMTのバグ予測モデルの混合マトリックスイメージ 図14 既存の静的コードメトリクスによるバグ予測モデルの混合マトリクスイメージ 表2 混合マトリクスの各指標の差異 Item Our Model Traditional Model Difference (Our Model) – (Traditional Model) TP Ratio 0.64 0.66 -0.02 TN Ratio 0.16 0.03 +0.13 FP Ratio 0.13 0.25 -0.12 FN Ratio 0.08 0.06 +0.02 Precision 0.83 0.73 +0.10 Recall 0.89 0.92 -0.03 Specificity 0.56 0.12 +0.44 Accuracy 0.80 0.69 +0.21 評価結果 図14に示すように、既存の静的コードメトリクスでは大部分の予測結果が陽性と検出されており、どんなソースコードでもバグありと検出してしまう傾向があるのに対して、図13に示すとおりGMTのモデルでは、「真陰性(TN)」、つまりバグではないものをしっかりと検出しており、陽性・陰性の検出性能がバラついているためモデルとしての汎用性は高いと言えます。一方、陰性データも検出するトレードオフとして、「偽陰性(FN)」つまり間違ってバグ無しと判別する頻度が増えてしまっているため、改善の余地がまだあるのと、検証データのバリエーションを増やして検証する必要がありそうです。 まとめ 今回は、CB-IDAU法の研究において生成されたCFGのデータを流用して実施した派生研究であるGMTについて説明しました。既知の静的コードメトリクス値や、数学的グラフ特徴量データを付与した大量のCFGデータを用いて、実際のバグ発生データを教師データとして回帰分析を行うことで、GMTというバグ予測モデル式を生成しました。新規提案バグ予測モデルであるGMTの性能としては、既知の静的メトリクスよりもバグではない陰性コードの検出能力の向上が見られたものの、個々の性能指標を見ると、まだ改善が必要であることが分かりました。また、AICを用いてバグに相関の強い説明変数に絞り込みを行った結果としては、残った５つの説明変数全てが数学的なグラフ特徴量であったことから、さらにコミュニティ抽出などの異なる手法も合わせて用いることで、精度の向上も見込める可能性も考えらます。そして、大規模なデータと多くの特徴量によるモデル生成を試みることで、さらなる精度向上が見込めると思われます。次回は、湯本と武田で、これまでの連載の総括として、この研究の今後について対談を掲載します。 The post 【第7回】波及全使用法(IDAU)をバグ予測に応用したグラフ特徴量バグ予測モデル first appeared on Sqripts .

こんにちは。今回はエンジニアのアシスタント事務をしている”とく”が、非エンジニアの視点からNotion AIを使用して見えてきたものをレポートさせていただきます。エンジニアの皆さんには自然なことでも、非エンジニアの視点からでは違うものが見えているかもしれません。 Notion AIは無料アカウントでもトライアルで一定量使えるそうなので、私のような非エンジニアや将来エンジニアを目指す人にも気軽に試してみて欲しいです。 〈”とく”のスペック〉 ・エンジニア歴：なし ・義務教育期間のIT教育：ネット接続（ピーヒョロロ時代）、Yahoo検索、ペイントでマウスの使い方を習う（たしかWIN95時代） ・業務歴：コールセンター、映像制作（企画から取材・撮影・編集）、SNS運営、実写VR映像制作、事務など → まとめると表現することのプロ ・IT的なスキル：代表的な編集ソフトは大体使える。ここ十数年はMac、その前にちょっとだけWin。よくわからないけど新しい技術があると好奇心で情報は集めてみる。 ・クセ：機械でもソフトでもなんでも擬人化してしまう……ため、ここからはNotion AIさんと表現させていただきます。早速Notion AIさんと戯れてみる 素人から考えると文章を勝手に書いてくれるなんて、まるで魔法です！ 早速ブログ、まるまる書いてもらえるかな〜♪ とか夢見ながらどんな情報を集めればいいのかNotion AIさんに呪文を唱えて聞いてみました。 やっぱり記事を書くとなると多くの人に見てもらいたいので、検索ツールとして使用してみました。すると生まれた文章がこちらです。 見た目はなんかブログっぽい！ と思いきや、読むと大して中身がないのが残念。１.ターゲットオーディエンスを明確にするに関しては最初に「エンジニア向け」と指定していますからもうすでに明確ですよね。２.のキーワードの選定と、５.の見出しの使い方に関してはどちらも「キーワード」が大事っていうことですから、項目が分かれていなくても良いかと思いました。 もう少し、学びをくれないか まず、非エンジニアにとって「エンジニアのニーズ」ってなんなのよという話があります。１の項目に対して「具体例を教えてください」とNotion AIさんに追加質問してみました。すると…… ふむふむ！ なんかブログの方向性が見えてきた気がします。検索能力に関しては一度聞き出したものにさらに「具体例を」などより深く聞くスキルが必要とされる様です。検索サイトで個別に読んでいたものをまとめてくれているので、その点は時短ですね。 ロマンを求めてはいけない ３. 文章の構成を考えると、4. 文法の修正については実際に書いた文章をチェックしてもらわないとわからないなぁと、某サイトで公開している自筆の記事を校閲してもらいました。内容はVR映像で学ぶと、まるでそこにいるような臨場感があって、スキルをダウンロードしてインストールするくらいに学びの速度が早まるというようなことを2000文字くらいにしたものです。タイトルは『身につけたいスキルを「ダウンロード」する時代がやってきた』。一応プロが見て一般公開された文章です。 「この文書を校閲してください」っていう聞き方で、今回は編集者としてNotion AIさんにチェックしてもらいました。そしたら泣きたくなるチェックが帰ってきました。 確かにスキルはダウンロードできない。それは比喩です。表現の一つです。そして結論の「スキルの習得には、継続的な努力と実践が欠かせません」というのは真理です。でもちょっと厳しくないですか（涙） でもこのやり取りで、Notion AIさんが事実ベースでとても誠実なチェックをしてくれることがわかってきました。真面目なクラスの学級委員長的なイメージですね。（これもNotion AIさんからするとご指摘を受けそうな表現） こちらは最近、再度試したらこのような返しがなくなったので、Notion AIさんはもしかしたら比喩表現を理解するということを獲得したのかもしれません。 これから必要なスキルとは？ 今回Notion AIさんとあれやこれや色々と試していて気づいたことは、正しい指示が出せれば、少ない指示で多くの手間が省けるということです。今回は日本語での検証でしたが、細かいニュアンスを伝えて最大限の働きをしてもらうのがとにかく大変でした。日本語の勉強が足りないのかと思ったのですが、途中でもっと学ぶのに最適なものがあると気づきました。 それは、エンジニア脳です。 日常生活での会話では文法だったり単語だったりの正確さはあまり指摘されることはありません。その会話での流れだったり、ノンバーバル（非言語）コミニケーションで伝わるものが多くあるからです。海外に行ってカタコトの単語と手振り身振りで伝わるくらい、人は表現豊かだし、洞察力を持っていますよね。しかし、AIに関しては流れは理解してくれても言語化されない部分に関しては察してくれることはありません。だから、言語を駆使してプログラムを操るエンジニア脳が非エンジニアにも必要になるんだと気付かされました。Notion AIさんと対話してこれからの自分のリスキングの方向性が見えてきた気がします。自分の中にあるものを正確に言語化してアウトプットできるスキルをこれからはNotion AIさんとの対話でトレーニングしつつ高めていきたいです。 The post Notion AIさんから学ばせていただきました🙇‍♀️ first appeared on Sqripts .

探索的テストとは 探索的テストとはテスト担当者のスキルやテスト経験をもとにテストを行う経験ベースのテスト技法の一つです。 JSTQBの用語集 （Japan Software Testing Qualifications Board：ソフトウェアテスト技術者資格認定の運営組織）では「テスト担当者がテストアイテムや以前のテストの結果の知識や調査情報を使用して、テストを動的に設計、および実行するテストアプローチ」と定義されています。 探索的テストのやり方 探索的テストは、テストを行う中で、テスト対象のシステムを学習して次にどういったテストをすれば欠陥が見つかるかを考えたり、特定の利用者が特定の目的を達成しようとする上でどのようなテストが必要かを考え必要に応じてテストケースを追加していきます。探索的テストは一般的に以下の手順で実施します。 テスト目的の定義 探索的テストの目的を明確にしてテストチャーターなどに記載します。 テスト環境を準備する 目的を達成するために必要なテスト環境を準備します。 テスト実施 実際にテスト対象に触れながら理解を深めて、どういったデータを使って操作をするか検討しながらテストを実施します。想定外の動作やエラーが発生した場合、原因を調査して必要に応じてテストを追加します。 テスト結果記録 発見した欠陥、問題点、改善点を報告書などに記録します。この情報は管理者や開発者へのフィードバック時に役立ちます。 結果評価 テストマネージャー等が４のテスト結果記録をもとにテスト結果を評価し、今後の品質向上につながる施策などを検討します スクリプトテスト（記述式テスト）との違い スクリプトテストは「テスト計画→テスト設計→テスト実行」の順にテスト工程を進めていき、仕様書や設計書などのテストベースをもとに作成したテストケースに沿ってテストを実施します。 テスト開始前に仕様を理解し、テスト手順やテスト条件が具体的になっているテストケースを準備しておくことで、テスト実施時の属人性を軽減できたり、網羅的に仕様をテストできたりといったメリットがあります。しかし、テストケースを事前に準備してからのテストになるため、その分、工数がかかってしまったり、テストケースに沿ってテストを実施するため、テスト実施中の気づき事項をテストに反映しづらいといったデメリットもあります。 このようなスクリプトテストに対して、探索的テストは事前にテストケースを準備せず、動的に「テスト設計→テスト実行」の順にテスト実施し、そのテスト結果を確認しながら次のテストを考え、テストを繰り返していきます。、また、テスト実施中の気づき事項をテストに反映していきます。スクリプトテストと探索的テストにはこうした違いがあり、互いを補完し合う関係にあるため組み合わせて使用することが多くなっています。 モンキーテストとの違い モンキーテストは「仕様を全く理解していない猿にテストを実施させる」という意味で、テストの目的を定めずに場当たり的に実施するやみくもなテストと位置づけられています。テスト経験の浅い担当者でも実施可能で、効果的なテストができるかは不確定要素が大きいです。一方で、探索的テストはテストの目的や方針を決めた上でテスト担当者の知識や経験をもとに効率的に欠陥を検出するテストです。事前にテスト設計などの準備が不要という点では探索的テストと似ていますが、こうした違いがあります。 アドホックテストとの違い アドホックテストにはいくつか定義があるため、本記事では「一定の仕様理解のある技術者が狙いをもって実施するテスト」と定義します。狙いというのは、例えば「特定の問題に絞ってテストを行いその問題の修正方法や対処法を発見する」場合に活用されます。一方で、探索的テストはテスト担当者がシステムを学習していきながら、テスト観点を発見してテストを行う手法です。 よって、アドホックテストは、ある特定の狙った問題を解決する際に活用される一方で、探索的テストは、より広範囲にシステムを理解していきながら、システム全体の品質を向上させるために活用します。 参考： アドホックテストとは？モンキーテストや探索的テストとの違いや効果を紹介 アジャイル開発における探索的テスト 探索的テストは、事前にテストケースを準備する必要がないため、仕様書や設計書などのドキュメントが不十分な状況でも実施できます。テストケースの準備には、多くの工数を必要とするケースが多々あるため、テストケースの作成工数を削減できる点は工数的なメリットが大きいです。 このように、テストケースの作成工数を削減することでスピーディーにテストを開始できるため、開発速度が重視されるアジャイル開発に導入されるケースが増えてきています。 探索的テストのメリット・デメリット テスト技法のメリット・デメリットを理解した上で、どのテスト技法を採用するか検討することでより効果的なテストを実施できます。ここでは、探索的テストのメリットとデメリットを説明します。 探索的テストのメリット 効率よく欠陥を発見できる 探索的テストでは、テストを実施しながらテスト対象のシステムを学習していきます。次にどういったテストを実施すれば欠陥が見つかるかを考えたり、特定の利用者が特定の目的を達成しようとする上でどのようなテストが必要かを考え必要に応じてテストケースを追加していきます。このようにテスト実行中の気づきをその場でテストに反映できる点がメリットです。 テスト実行中に欠陥が潜んでいそうな箇所を集中的にテストをしたり、スクリプトテストなどでテストケースを準備するような段階では気づきにくいような機能の振る舞いをテストすることで、効率よく欠陥を発見することが可能です。 工数・コストを抑えやすい テストケースを作成するためには、仕様書を読解し、仕様を把握してどのようなテストを実施するか検討したうえでテスト設計をする必要があります。作成したテストケースはレビューをして、レビューで指摘があれば修正します。こうした工程を通してテストケースは作成されるため工数がかかります。 テストケース作成自体にかかる工数以外にも、各工程のなかでは、関係者間のコミュニケーションコストもかかってきます。例えば仕様を理解するなかで、仕様書に不備が見つかった場合にはテストケース作成ができないため、開発者への仕様の確認作業が必要になります。また、仕様に変更が生じた場合はテストケースを修正する必要があるため、メンテナンスコストもかかってきます。探索的テストではこうした工数・コストを抑えられる点がメリットです。工数が逼迫していてテストケースの準備が難しい場合に効果が大きいです。 仕様書や設計書などのドキュメントがなくても実施できる 探索的テストはテスト担当者がテスト対象を動作させながら、自身の知識や経験をもとにどのようなテストを実施するかを判断するため、仕様書や設計書などのドキュメントが不十分な場合でも適用できます。 JSTQB-FLシラバス(Version 2018V3.1.J03) にも「仕様がほとんどなかったり、不十分であったりする場合に最も効果が大きい」と記載されています。仕様書が完成するのを待たずに先行してテストを開始できたり、アジャイル開発のように仕様をドキュメントに十分に記載しないような場合でもテストを実施できる点は大きなメリットです。 柔軟性が高い スクリプトテストではテスト設計の段階であらかじめ決めたテスト技法にもとづきテストを進めていくため、テスト中によりよいテスト方法があることに気がついても、テストへの反映は時間的に難しいことが多いです。探索的テストでは、テスト実施中にテスト担当者の経験にもとづいて、状況に応じた最適なテスト技法を適用できます。このように柔軟性高く臨機応変にテストが行えるため、スクリプトテストでは検出できないような欠陥を検出できることもあります。 暗黙知を活用できる 暗黙知は個々の経験や学習で習得した、意識的に認識していない知識です。人が行動するなかで無意識に行う動作などを指します。テスト担当者に自由度を持たせ、知識や経験を活かす探索的テストでは、このような暗黙知を活用できます。 また、テスト内容が具体的に記載されたテストケースに沿ったテストでは、テスト中に疑問が生じることは少ないですが、仕様書が不十分な状態でもテストを実施する探索的テストでは、テスト中に疑問点や不明点が生じることがあります。そのため、設計者や他の担当者に質問をして次のテスト内容を考えることも多々あります。そのタイミングで互いの暗黙知が共有されてテストに活用できる点もメリットです。 探索的テストのデメリットとその対策 テスターのスキルや経験に依存する 　探索的テストはテスト担当者のスキルや経験をもとにテストを実施しますが、テスト担当者といっても「経験の浅い担当者」から「熟練のテスト担当者」までさまざまでテストの効果にバラツキが出る可能性があります。もし、テスト担当者の経験が不足していると、単なる思いつきのテストになってしまい期待した効果を得られないかもしれません。 こうした、経験のバラツキを軽減するためには、テストチャーターが有効です。テストチャーターはテストの目的や観点を記載します。作成したテストチャーターをテスト担当者間で共有して、テストを実施することで経験のバラツキを軽減することができます。 テストを資産化できない 探索的テストでは、基本的にはテスト仕様書やテストケースといったドキュメントを作成しないため、テストを資産化できません。ドキュメントを作成しておくと、以前テストしたシステムと似たシステムをテストする際に活用してテスト品質を高めるのに役立ちます。 探索的テストは過去のテストノウハウを共有しにくいため、探索的テストで実施したテストアイデアや発見した問題のなかで、他のテスト担当者や開発チームにも役立つ情報があれば会議やワークショップなどを開催して共有しておくといいでしょう。 網羅性が担保できない 探索的テストは事前に具体的なテスト内容を定義せずにテスト担当者に自由度を持たせてテストを実施するため、テストがどの程度の範囲を網羅して実施されたかどうかの判断が難しくなります。これは、探索的テストには公式なテストカバレ ッジ基準が存在しないため、カバレッジの計測が困難であったり、テスト対象の優先順位もテスト担当者によるため不明確であったりすることからきています。そのため、探索的テストはブラックボックステスト技法やホワイトボックステスト技法などカバレッジの計測が可能な他のテスト技法と組み合わせて適用することが多くなっています。 管理・コントロールが難しい 探索的テストでは詳細にテスト計画を立ててテストを実施しないため、テスト期間、対象範囲、テストの量などが管理・コントロールしづらくなります。 この対策としては、あらかじめテスト期間を一定期間に区切って探索的テストを実施するセッションベースドテスト（セッションは一定の時間の意味）といわれる方法が有効です。セッションが変わるタイミングでテスト担当者が管理者にテストの実施状況を共有することで、管理者はテストの実施状況を把握でき、管理・コントロールしやすくなり、テスト担当者も管理者からのフィードバックを受けられるようになります。 非機能テストに向かない 非機能テストはユーザビリティといった使いやすさやシステムがどれくらいの負荷に耐えられるかや十分なパフォーマンスを発揮しているかなど機能以外の部分をテストします。非機能テストには、テスト環境の構築に時間を要したり、一定の目標値が定められ、その値を満たしているかを検証するケースが多いため、テスト担当者の知識、経験で判断できるような観点が少なくなります。テスト担当者の経験からランダムにテスト対象を動作させて結果を確認する探索的テストでは、非機能要件を保証する方法としては適していないでしょう。非機能テストと探索的テストは別として、探索的テストは機能テストやユーザビリティテストに対して適用した方がよいでしょう。 まとめ 探索的テストはスクリプトテストのように事前にテストケースの準備をする必要がないため、開発スピードが重視されるアジャイル開発との相性がよいテスト手法です。テスト担当者の知識・経験を活かしてスクリプトテストでは検出しにくいような欠陥を効率的に検出できる可能性が高いです。しかし、テスト担当者の経験が浅いと単なるやみくもなテストであるモンキーテストになる恐れもあります。また、カバレッジ基準がないため網羅性を担保しづらくなるため、スクリプトテストと組み合わせて使うなどするとよいでしょう。このように、各テスト技法の特徴を抑えたうえで、組み合わせて適用することで効果的なテストを実施できます。 参考： AGEST式探索的テスト – 株式会社AGEST（アジェスト） The post 探索的テストとは？スクリプトテストなどの他のテストとの違いやメリット・デメリットについて解説 first appeared on Sqripts .

はじめに こんにちは、バックエンドエンジニアをしているまさです。 仕事でNotionを利用しており、便利に活用させていただいていますが、最近NotionにNotionAIなるものが導入されました。そこで、今回はこのNotionAIを活用してこのブログ記事を書いてみようと思いました。 最近では自然言語系のAIが多く台頭してきており、こうした技術の活用を色々と検討していく必要があると思っています。その一環として、まずは今回のブログをNotionAIに頼って書かせてみようと思います。 NotionAIについて NotionAIは、人工知能を利用して、簡単に文章を生成することができるツールです。利用者は、文章のジャンルやキーワードを入力するだけで、NotionAIが自動的に文章を生成してくれます。また、生成された文章は、利用者が修正・編集することもできます。 NotionAIは、今後ますます多くの人々に利用されるでしょう。一方で、自動生成された文章には修正が必要な場合もあり、修正を加えることで、より良い文章を作成することができます。 上記の「NotionAIについて」の説明文章はNotionAIが作成したものです。NotionAIは、このような自然な文章を作成することができます。 そのままブログを書かせてみる まずそのまま本記事のタイトルを元にAIに記事の作成を依頼してみます。ページの先頭でスペースキーを押すことでAIへの指示を選択できます。 ここではブログ記事を書いてもらいたいので「AIでドラフトを作成」の「ブログ投稿」を選択します。 するとどのような内容に関しての記事を書くかを確認されますので、今回の記事のタイトルを入力します。 すると 以下はAIが生成した記事内容です イントロダクション NotionAIは、人工知能を利用して文書を自動生成するツールです。このツールを使えば、手間をかけずに多くの文章を生成することができます。今回は、NotionAIを使ってブログ記事を書いてみることに挑戦しました。 NotionAIについて NotionAIは、人工知能を利用して、簡単に文章を生成することができるツールです。利用者は、文章のジャンルやキーワードを入力するだけで、NotionAIが自動的に文章を生成してくれます。また、生成された文章は、利用者が修正・編集することもできます。 NotionAIを使ってブログ記事を書いてみる NotionAIを使って、ブログ記事を書いてみました。最初に、タイトルとキーワードを設定し、NotionAIに文章を生成させました。NotionAIが生成した文章は、非常に自然な文章でしたが、文章の流れが少し変だったので、修正を加えました。修正後の文章は、非常に読みやすく、自然な文章になりました。 結論 NotionAIは、文章を自動生成することができる優れたツールです。ただし、自動生成された文章には、修正が必要な場合もあります。NotionAIを活用することで、短時間で多くの文章を作成することができるため、ブログライターにとっては非常に便利なツールと言えます。しかし、文章の質を維持するためにも、修正や編集は欠かせません。 このような感じでそこそこいい感じの文章を記載してくれます。簡潔かつ適切な内容にまとまった良い記事だと思います。ただもう少し記事としてボリュームが欲しいと思います。 そのようなときは記事全体を選択し「AIに依頼」を選択から「長くする」を選択し、もっと長めの文章にしてもらいます。 この結果作成された内容は 以下はAIが生成した記事内容です イントロダクション NotionAIは、人工知能を利用して文書を自動生成するツールです。このツールを使えば、手間をかけずに多くの文章を生成することができます。今回は、NotionAIを使ってブログ記事を書いてみることに挑戦しました。 NotionAIを使うことで、ブログライターは時間を短縮できます。また、書き手は生成された文章の質を向上させるために、修正や編集を加えることができます。 NotionAIについて NotionAIは、人工知能を利用して、簡単に文章を生成することができるツールです。利用者は、文章のジャンルやキーワードを入力するだけで、NotionAIが自動的に文章を生成してくれます。また、生成された文章は、利用者が修正・編集することもできます。 NotionAIは、今後ますます多くの人々に利用されるでしょう。一方で、自動生成された文章には修正が必要な場合もあり、修正を加えることで、より良い文章を作成することができます。 NotionAIを使ってブログ記事を書いてみる NotionAIを使って、ブログ記事を書いてみました。最初に、タイトルとキーワードを設定し、NotionAIに文章を生成させました。NotionAIが生成した文章は、非常に自然な文章でしたが、文章の流れが少し変だったため、修正を加えました。修正後の文章は、非常に読みやすく、自然な文章になりました。 NotionAIを使うことで、ブログライターはより多くの記事を生成できるようになります。また、自動生成された文章を修正することで、より良い文章を作成することもできます。 結論 NotionAIは、文章を自動生成することができる優れたツールです。ただし、自動生成された文章には、修正が必要な場合もあります。NotionAIを活用することで、短時間で多くの文章を作成することができるため、ブログライターにとっては非常に便利なツールと言えます。しかし、文章の質を維持するためにも、修正や編集は欠かせません。NotionAIを使いこなすことで、ブログライターはより多くの記事を素早く作成することができ、より多くの読者を魅了することができるでしょう。 だいぶいい感じになりましたね！ あとはもう少しくだけた感じの表現にしてみたいとおもいます。 再度記事の文章全体を選択し「AIに依頼」を選択後、「トーンの変更」から「カジュアル」を選択してみます。 トーン変更後の内容は 以下はAIが生成した記事内容です イントロダクション NotionAIっていうのは、人工知能で文章を勝手に作ってくれるツールだよ。このツールを使えば、めんどくさくなくてたくさんの文章を作ることができるんだ。今回は、NotionAIを使ってブログ記事を書いてみたんだ。 NotionAIを使うと、ブログライターは時間を節約できるし、文章も修正して編集できるから、もっと良い文章にすることができるんだ。 NotionAIについて NotionAIっていうのは、人工知能を使って、簡単に文章を作れるツールだよ。文章の種類やキーワードを入力するだけで、NotionAIが自動的に文章を作ってくれるんだ。作った文章は、修正や編集もできるよ。 NotionAIっていうのは、今後もっと多くの人に使われるようになると思うよ。でも、自動で作った文章には修正が必要な場合もあるから、修正して良い文章を作ることが大切だね。 NotionAIを使ってブログ記事を書いてみる NotionAIを使って、ブログ記事を書いてみたんだ。最初に、タイトルとキーワードを入力して、NotionAIに文章を作ってもらったんだ。NotionAIが作った文章は、自然な文章だったけど、文章の流れがちょっと変だったから、修正したんだ。修正した文章は、読みやすくて自然な文章になったよ。 NotionAIを使うと、ブログライターはもっとたくさんの記事を作れるようになるし、自動で作った文章を修正することで、もっと良い文章を作ることができるんだ。 結論 NotionAIっていうのは、文章を自動で作れるツールだよ。でも、自動で作った文章には修正が必要な場合もあるから、それを修正することが大切だね。NotionAIを使うと、ブログライターはたくさんの記事を簡単に作ることができるし、読者にもっと魅力的な記事を提供することができるんだ。 このような形に変更してくれました！ 今回は、このブログ記事のタイトルのまま作成しました。しかし、ブログ記事を執筆する際に、「こんなことを書きたい」「これを共有したい」というアイデアが浮かんだ場合は、NotionAIに書き出しを任せて、自身の知識や経験などで修正・加筆することで、より良い文章を作成できるかもしれませんね。 その他の機能を試してみる 今回の記事の主題はNotionAIにブログを書かせることでしたが、その他にもNotionAIを利用した便利な機能があります。その中からいくつか機能を試してみたいと思います。 文章の修正 自然言語系のAIではよくある機能ですが、校閲機能もあります。文法の誤りや誤字脱字を修正してくれます。例えば このようなへんな文章や日本語とせておかしな内容の文章をAIが正しくなおしてくあれます。 上記の文を選択し「スペルと文法を修正する」を選択すると このような変な文章や、日本語としておかしな内容の文章をAIが正しく直してくれます。 アクションアイテムの抽出 個人的にこれは便利そうだなと思う機能の一つが「アクションアイテムの抽出」です。これは文を元にチェックリストを生成してくれます。例えば下記のような文に対して「アクションアイテムの抽出」を行ってみます。 アクションアイテムの抽出も文を選択後に「AIに依頼する」から「アクションアイテムの抽出」を選択することで行うことができます。 今日中にNotionAIに関するブログを一つ執筆して、明日中に上長に提出する。レビューされた内容を確認し、最終修正後にブログ投稿を依頼する。 NotionAIに関するブログ記事を執筆する 上長にブログ記事を提出する レビューされた内容を確認する 最終修正を行い、ブログ投稿を依頼する 上記のように文から、行うべきアクションをチェックリストとして抽出してくれます。 おわりに 現在では、ChatGPTやBingのAIなど自然言語系のAIが革新を起こしています。これらを実際に利用してみると、非常に便利で作業の効率化や改善に役立てることができます。また使い慣れることで、より便利な活用方法を考えることもできます。もちろん、万能ではなく、改善が必要な部分もありますが、それでも非常に素晴らしい技術で、利用しない手はありませんね。 The post NotionAIを使ってブログ記事を書いてみる first appeared on Sqripts .

みなさん、こんにちは！ QA事業本部のゆーすけです。 10月26日～28日の3日間、幕張メッセで「Japan IT Week 秋」が開催されました。 というのは以前こちらブログもお伝えした通りです。 その中でミニセミナーというものを行わせていただいた、というのもブログに記載されていますが、今回はどのようなミニセミナーを行ったか、ということを書かせていただきたいと思います！ 第三者検証のプロが語るミニセミナー なぜ今第三者検証なのか？ なぜテストのアウトソースが少ないのか 実際にやってみて 第三者検証のプロが語るミニセミナー 今回AGESTとして3つのミニセミナーを実施させていただいています。 …

こんにちは！テストオペレーション部のしのののです。 普段、様々なシステムの総合テストを担当していますが、今回初めてWeb APIのテストを担当しました。 今回のAPIテストでは、「Postman」というツールを利用しました。超有名なツールなので既知の情報ばかりだとは思いますが、自身の勉強まとめも兼ねて初めて利用した際に調べたこと、感じたことを経験談として書き連ねていこうと思います。 なお今回書いた内容は、前提としてREST APIのテストを対象としています。 REST APIとは？ Postmanとは？ Web APIを使う前に把握すべき要素 いざ実践へ 事前準備（Githubのトークン発行）…

こんにちは、エンジニアをしているやまたろうです。 Notionはページやデータを管理する非常に便利なプロダクトですが、愚直にページやデータを追加していくと階層構造が深くなりすぎて必要な情報へのアクセシビリティが下がってしまったりと、最大限の恩恵を受けるためには情報を整理するための設計が必要です。 本記事はドキュメントを残すのが苦手な私が、所属するチームでWikiを導入する際に設計した事例を紹介します！ Notionページの管理方法 チームWikiを作るにあたり初めに考えたのがページ管理です。 直前に行なっていたプロジェクトで、何も考えず子ページ孫ページをスペースに追加する運用を行なった結果、プ…

こんにちは。エンジニアの nobushi です。 サーバーアプリケーションをデプロイする場合、絶対必要なのが SSL 証明書ですよね。しかしながらこの SSL 証明書、有料だったり更新が必要だったり何かと面倒です。 そんなエンジニアの強力な味方となってくれるのが Let’s Encrypt です。 開発中に一時的に必要な証明書はもちろん、本番環境のサーバーでも使用可能。 しかも無料。これでもう社内稟議に悩まされることはありません。 ただし。 もちろんいい話ばかりではありません。 この Let’s Encrypt の証明書、有効期限が一律90日と、とても短いです。現実的な運用を考えると2ヶ月程度…

はじめまして！2022年新卒でテストエンジニアリング部のたかぱぴです。 私を含めて2022年の新卒者6名で専門書の輪読を行ったので、その時の感想や学んだことについて、参加者へのアンケートを交えつつ書いていこうと思います。 輪読とは 使用した書籍 一番興味を持った章 (参加者アンケート結果) 一番理解が難しかった章(参加者アンケート結果) 輪読に参加して良かった点/学んだ点(参加者アンケート結果) 輪読に参加して大変だった点(参加者アンケート結果) まとめ 輪読とは 輪読は、参加者全員でディスカッションをしながら一冊の本を順番に読み進めていきます。 今回の輪読は週に1度、1回につき約1時間程度で…

こんにちは！新米技術広報のちゃっきーです。 10月26日～28日の3日間、幕張メッセで「Japan IT Week 秋」が開催されました。 AGESTも5月に開催された「Japan IT Week 春」ぶりに出展してまいりました。今回は会場の様子をお届けします♪ 「Japan IT Week 秋」って？ AGESTブースの様子 第三者検証のプロが語るミニセミナー ご来場いただいた皆さまへ 「Japan IT Week 秋」って？ 「Japan IT Week 秋」とはAI・業務自動化、IoT、WEBマーケティングなどDXを推進する企業が出展する日本最大のIT展示会です。同じ規模で毎年春ごろに「…

はじめまして、テストオペレーション部のJJです。 今回はインスペクション初心者の私が、業務を体験して学んだことについて書いていこうと思います。 既にインスペクションというものをご存じの方からすれば何を基本的なことをと思われるでしょうが、IT業界に長年身を置いている私でもはじめて聞いた言葉でもあったので知らない方も多いと思われます。ですので、そもそもインスペクションとはなんぞや？というところから説明させていただければと思います 1.インスペクションとは？ 2.インスペクションの目的とメリット 3.インスペクションのカギ 4.対象となる主なドキュメント 5.インスペクションの役割 6.インスペクシ…

こんにちは！新米技術広報のちゃっきーです。 今回は株式会社AGEST主催のオンラインセミナーについてご案内させてください。 テーマ 何が学べるの？ こんな方にオススメ オンラインセミナー概要 テーマ 中小企業の経営者様、一人情シス/ゼロ情シスの企業のご担当者様必見！ 低コストで導入簡単なセキュリティ対策を紹介 何が学べるの？ 当セミナーでは、以下3点をメインにお話をいたします。 低コストで、専任担当者がいなくても導入できるセキュリティ対策 EDR監視運用サービス「ミハルとマモル」の概要 デスクトップデータ仮想化「Shadow Desktop」の概要 今やサイバー攻撃のターゲットとなる企業は規模…

こんにちは。 テストオートメーショングループのおすしです。 ■前回記事 TestRailと自動テストの連携#1 Selenium/Python編 engineers-blog.agest.co.jp 今回はTestRailとmablの自動テストを連携したお話です。 連携方法やテストコードは下の方で全部公開しています。 ※今回はmablのJenkinsプラグイン以外を使用していません。mablには便利なCLIがあるので、一度目を通しておくことをお勧めします。 自分の環境に合ったより良い連携方法をひらめくかもしれません。 mabl CLIの概要 https://help.mabl.com/docs…

こんにちは！新米技術広報のちゃっきーです。 早いもので10月も後半に突入しましたね。2022年新卒入社社員も研修期間を終え、9月より本配属先で業務を開始しております。環境に慣れるには時間を要するかと思いますが、学ぶこと盛りだくさんな刺激のある日々を過ごしているのではないでしょうか。（あれ…私自身もいつまで”新米”と名乗って許されるだろう…。汗） そんな中9月末に開催した社内イベント、名付けて「新卒1～3年目大集合！AGESTワークショップ」の様子をお届けしたいと思います。 企画の背景 NASAゲームって？ ワークショップの様子 締めはピザパーティーで まとめ 企画の背景 新卒採用担当とCTO城…

こんにちは、テストエンジニアリング部のさっちゃんです。 前編の記事では、未経験者向けに行った研修内容と、未経験者のつまずきポイントを紹介させていただきました。 今回の後編では、実際に研修生が行ったテスト設計の紹介と、そこから気付かされたことについて紹介していきたいと思います。 演習の題材について メニュー 研修生の作成物（ドキュメント）から考えたこと 状態遷移テスト デシジョンテーブルテスト 組み合わせテスト（二因子間網羅） 最後に 演習の題材について 研修生が行ったテスト設計を紹介する前に、まずはどういったシステムを演習の題材としているか記載します。 題材：WEB上で動作する予約システムの総…

みなさん、はじめまして、テストオペレーション部のゆーきです。 テックブログを書くのはなかなか難しいですね…記載しては書き直しを繰り返しながら頑張って「自動運転」について書きましたので、ぜひ読んでみてください。 はじめに LiDAR（ライダー）とは 1.モビリティ 2.マッピング 3.防犯 etc. 自動運転のテストについて さいごに はじめに みなさんは自動運転の車やロボットって見たことありますか？近年では様々な会社が開発を行っており見かける頻度も増えてきたかと思いますが、課題などが多くありまだまだ一般的にはなっていないかと私は思っています。なので先に自動運転に関する説明をします。 簡単に説明…

こんにちは。 テストオートメーショングループのおすしです。 JaSST'22 Shikokuにオンライン参加してきました。 今回は学生の参加が多いこともあり、各講演内容は基本的な説明からはじまり、具体例も専門用語をあまり使わずにわかりやすく説明していました。 以下では、私が個人的に「なるほど！」と思ったところをピックアップしてレポートしていきます。 JaSSTとは 講演①「テストを学び成長する 2022 年度版 ～テストの全体観を持ち、テストに強みをもった技術者になるための学びと成長について～」 ソフトウェアテストの本質とは何か ソフトウェアテストについての全体像を俯瞰して整理できる軸を持つ …

こんにちは。CTO室のGSです。 みなさんは既存のPWA対応サイトをモバイルアプリとしてAppStoreにリリースしたいと考えたとき、どのような手段でそれを実現するでしょうか？ ぱっと思いうかぶのは ・ネイティブ開発（Objective-C、Swiftなど）でいわゆる「ガワアプリ」を作成 でしょうか。 Androidであれば「ガワアプリ」を作ることなくPWA対応サイト（厳密にはTWA）もGoogle Playストアからリリース可能ですが、iOSではPWA対応サイトをApp Storeからリリースすることはできません。 この「ガワアプリ」ですが、単純に作ると機能足らず（PWA読み込み中に真っ白に…

こんにちは。テストオペレーション部のぶれです。今回はCBT化されたJSTQB認定テストを早速受験してきましたので、受験レポートを記したいと思います。 JSTQB認定テストがCBT化されたよ JSTQB 申込完了まで 試験当日の流れ 入室～試験中 退室～合格発表 さいごに JSTQB認定テストがCBT化されたよ 2022年10月3日から、Foundation Level試験（CTFL）とAdvanced Level テストマネージャ試験（CTAL-TM）のCBT（コンピュータ・ベースト・テスティング）による試験受付が開始されました。 ※JSTQBからパートナー企業へ提供される情報によると、Adv…

こんにちは！新米技術広報のちゃっきーです。 今回は株式会社AGEST主催のオンラインセミナーについてご案内させてください。 テーマ 社内外のIT資産を攻撃者視点で継続モニタリング、ゼロトラストセキュリティを成功に導く！ ～革新的なゼロデイ対策「Synack／インフラストラクチャ モニタリング」を紹介～ セキュリティ脅威から身を守り、安心で安全なシステム運用を行うためには、IT資産の脆弱性モニタリングが必須です！ 何が学べるの？ こんな方におすすめ オンラインセミナー概要 何が学べるの？ 当セミナーでは、以下3点をメインにお話いたします。 ゼロデイ対策の重要性 ゼロトラストセキュリティの重要性 …