みなさん、こんにちは！　QA事業本部のゆーすけです。 JSTQB CBT試験みなさん受けてますかっ！？（前回と同じ入り方） ついに、テストアナリストのCBT開始の連絡もありましたね、しかもテストアナリストはPBTやテストマネージャーCBTとは異なり、「3年間の業務経験」という条件がなくなっていますので、より現場に近い資格になったんじゃないかな、と思います。 また、年内には ・アジャイルテスト担当者 ・自動車ソフトウェアテストテスト担当者 ・テスト自動化エンジニア も開始予定とのことなので、自分もそろそろアジャイルテストと自動化エンジニアの勉強を再開しようかと思っているところです！（自動車はPBTで取得済み） ということで、JSTQBの学習のススメ連載の6回目となります！ ▼1～4回のおさらいです！ 1回目 JSTQBってなんだろう？→Foundation Levelから始めよう 2回目 Foundation Levelの構成ってどうなっているんだろう？ 3回目 テスト基礎について 4回目 テストのライフサイクルについて 5回目 静的テスト 　 JSTQB Foundation Levelの構成は以下のようになっていて、6回目の今回はみんな大好きテスト技法について触れていきたいと思います。 １：テストの基礎 ２：ソフトウェア開発ライフサイクル全体を通してのテスト ３：静的テスト　 ４：テスト技法　　　←今回はココ ５：テストマネジメント ６：テスト支援ツール テスト技法って？ テストを効率的かつ効果的に進めるための考え方、アプローチ方法ととらえると分かりやすいかもしれません。シラバスにも記載されていますが、テス技法ありきでテストを考えるのではなく様々な要因のもと正しくテスト技法の取捨選択、適用範囲を決めていることが大事になります。 プロダクトの性質上、適用できない/適用しても効果的ではない、というテスト技法もあるので、技法の特性特色はここで適切に把握するようにしていきましょう。 FLシラバスでは、動的テストの「ブラックボックス」「ホワイトボックス」「経験ベース」の3つに分類しています。以前の記事にも使ったテスト図に付け加えると以下のようなかたちになります。 ブラックボックスのテスト技法 上の図とは順番が異なりますが、シラバス記載の順序通りにブラックボックステストの技法から簡単に触れていきましょう。 同値分割 同値はデータの処理からグループ分け（同値クラス化）をする考え方です。 例えば、数字入力のフォームにて、 ・0～50 ・51～100 ・101～ の入力結果において異なる処理が行われる場合、上記の3つカテゴリが有効同値クラスとなります。 テストを行う際は、同値内の中央値を使用くするのが一般的と言われています。 境界値分析 境界値分析はIPAなどでは限界値分析とも呼ばれます。 コーディングにおいて、”＞”（大なり）、”＜”（小なり）と、“≧”（大なりイコール）、”≦”（小なりイコール）を取り間違える、というのはありそうでなさそうだけど、実際はありえる分かりやすいコーディングミスの一つです。想像することのできるコーディングミスで、最も単純でその割に影響度が果てしなく大きいので、出来れば重要な数値周りは境界値の観点でテストを行い、「問題ない」というお墨付きをもらっておきたいところですよね。 ※設計書上で数字の分岐定義、統一がされていない、「以上以下」と「より未満」が入り混じるようなものは要注意です。 先ほどの同値分割と同じ数字でいうと、 ・0～50 ・51～100 ・101～ 0、50、51、100、101が境界値分析として取り扱うべきテスト対象となります。 ※境界値として2値をとる、という方針になった場合。3値の場合は0、49、50、51、99、100、101が対象となります。 同値と境界値の関係を簡単な図にすると以下のようになります。 デシジョンテーブル 決定表とも呼ばれるテスト手法で、デシジョンテーブルのことを取り上げた記事もあります。 いまさらデシジョンテーブルというものを考えてみた | Sqripts 上の記事にも記載していますが、テストケースを省略できるパターン、省略できないパターン、デシジョンテーブルではなく原因結果グラフが適切な場合などいろいろ考えられますが、Foundation Levelではまずは簡単なテスト条件からテーブルを作成できれば問題ないと思います。 デシジョンテーブル記事の再掲となりますが、 　想定： 　　映画館のチケット割引サービス 　 　仕様： 　　通常金額1900円 　 　割引システム： 　　ファーストデイ：毎月1日はだれでも1200円 　　レディースデイ：毎週水曜日は女性なら1200円 という条件があった場合、以下のようなテーブルが作られます。 条件からデシジョンテーブルを作ってみる、という内容はJSTQB ALテストアナリストや、IVEC（IT検証技術者認定試験）でも頻出しているので、自分で条件を考えて実際に数回テーブルを作ってみる、というのがいいと思います。 状態遷移テスト これまた別ブログ記事参照で申し訳ないですが、状態遷移を取り上げた記事がありますので、より深く知りたい方はこちらを参考にしてみるといいかもしれません。 幅広いソフトウェアとテストレベルで適用可能な状態遷移テスト | Sqripts 状態遷移テストは、「状態遷移図」または「状態遷移表」を作って考えます。 それぞれの特色としては、 　状態遷移表：無効値も含めて考えるため、仕様の抜け漏れに気づきやすい 　状態遷移図：フロー図で表すため、遷移が視覚的に分かりやすい ということがあります。 状態遷移テストはJSTQB ALテストアナリストでも引き続き掘り下げられていく手法のため、FLの段階でしっかりと状態遷移図、状態遷移表のどちらも作れるようにしていきましょう。 ※JSTQBテストアナリスト試験では、状態遷移図を作ってNスイッチカバレッジを求めよ、というのが頻出傾向でしたが、最新PBTではなくなった、という嘆きの声もあるようです。 ※嘆きの声が書かれた記事がこちら シラバス改定後初のJSTQB ALTA試験受けてきた #1 | Sqripts ユースケーステスト まずはシラバスから抜粋すると ソフトウェアアイテムとの相互作用の設計方法であり、テストケースは、ユースケースから導出可能である。 ユースケースには、ソフトウェア機能の要件が盛り込まれている。 （省略） 各ユースケースは、1 つのサブジェクトと 1 つ以上のアクターとの相互作用による振る舞いを明確にす る（UML 2.5.1 2017） と記載されています。 つまりユースケースは、ソフトウェア機能要件（要件定義～詳細設計）で定義されたものがテストベースとなります。 ただし、ユースケーステストをISTQB GLOSSARYで調べると ブラックボックステスト技法の一つ。ユースケースの動作を実行するようにテストケースを設計する。 同義語：ユーザシナリオテスト、シナリオテスト と記載されているので、ユースケース図をテストベースとしたテストだけではなく、ユーザーを想定した一連のテストを丸めて呼んでいる、代表的な例としてユースケース図をベースに作成する、とざっくりとした理解でもFLの段階ではいいと思います。 このあたりはSWEBOK-SQuBOKや、ISO/IEC/IEEE 29119など、他の学習を取り入れ、そのうえで自分の中でのユースケース定義、シナリオテスト定義などをしっかりと定め、認識齟齬なくテスト活動を行っていく、ということが重要なところとなります。 ちなみにシラバスにも記載されているユースケースにおける、サブジェクトとアクターはこのように表せます。 なんと次回に続く…… 今回テスト技法を「ブラックボックス」「ホワイトボックス」「経験ベース」の3つを取り上げる予定でしたが、3つ全て取り上げるとかなりのボリュームになりそうなので、今回はブラックボックスだけの内容として、残りの2つは次回にまわしたいと思います。 次回はなるべく早めに掲載できるよう頑張りますので引き続きお付き合いいただけますよう何卒宜しくお願いいたします！！ The post JSTQB学習のススメ #6 〜Foundation〜 first appeared on Sqripts .

はじめまして、AGESTクオリティマネージメント部の坂本です。 今回は弊社が新たに開始するコード解析サービスについてご紹介したいと思います。 QA for Development QA for Developmentとは「開発のための品質保証」を実現するAGESTの新しいソリューションです。「不確実性が高い時代のモノづくり」の品質課題にオールインワンで向き合うため、AGESTは開発×テストの二刀流のノウハウを持った”次世代QAエンジニア”による新しい価値提供を行います。 今回ご紹介するコード解析サービスは、こちらの新ソリューション「QA for Development」のサービスのひとつです。どのようなものか、どのようなメリットがあるのか、また具体的な進め方や成果物についてご紹介します。QA for Developmentについての詳細は下記のページをご覧ください。 QA for Development コード解析サービス サービス概要 コード解析サービスとは、コード品質にお悩みのお客さまのソースコードを様々な観点から解析、品質を計測し、改善点を検出・作成するサービスです。 当サービスにより問題（指摘事項）やコード量の傾向等が可視化され、コードの問題箇所が見えてきます。また、問題箇所への最適な対応もご提案するため、結果として問題が減少し、クリーンなコードになることが期待できます。また継続的なコード品質の維持についても考えますので、一度受けて終わり、ではなく受けたあともコード品質をあげる仕組みができます。 ( ※1 ) コード品質とは 一言にコード品質といっても様々な観点が存在します。 たとえば下記の観点があります。 1.保守性 コードのメンテナンスのしやすさを表します。 　a.可読性 　変数やメソッド、クラス等への適切な命名、シンプルなロジックを作成する等で向上します。 　b.テスト容易性 　クラス、メソッドへの適切な責務の割り当てをする等で向上します。 　c.変更しやすさ 　定数を利用する、コードを重複させない、グローバル変数を使わない等で向上します。 2.再利用性 コード（モジュール、クラス）の再利用のしやすさを表します。適切な責務の割り当て、モジュール分割によって向上します。適当にクラスやメソッドを作成しているといらない機能が入っていたり、変に特化している部分があったりして再利用できないことがよくあります。 3.効率性 CPU利用やメモリ消費の多寡を表します。無駄なファイル入出力、メモリ確保をなくしたり、DBであればインデックスが効くようにクエリを発行する等で向上します。多くの場合プログラム実行速度に直結します。 4.移植性 プログラムを異なる環境に移植した際に動作させる容易さを表します。CPUやOS、ミドルウェア等に依存したコード（改行コードのべた書き、特定のDBにしか存在しない命令等）を減らすことで向上します。 5.信頼性 エラーへの強さを表します。具体的には例外的な入力があってもデータが壊れない、エラーが発生した場合フェイルセーフな動作をする等があります。例外的な場面に備えた処理を実装することで向上します。このようにコード品質には様々な面があり、プロジェクトによって注力するべきところも変わってきます。 低品質コードのリスク 前項で記載したなかでプロジェクトに必要な観点を満たしている割合が低いものを品質の低いコードということができます。それではそもそもコードの品質が低いと、誰がどう困るのでしょうか。 例えば下図のような、作業への影響、その結果として起こりうるリスクがあげられます。 テスタビリティの低下 テストがしにくくなることで、コードカバレッジやテストケースの漏れが発生し、欠陥検出率が低下します。その結果、市場不具合が発生し、顧客に損害が発生する、自社の信頼を失う等の影響が発生します。またプロジェクトもテストがスムーズに実施できないことで進捗遅れが発生します。 メンテナンス性の低下 メンテナンスがしにくくなることで、不具合修正の難易度が上がり、デグレードの発生確率が上がります。また機能追加・変更をする際にも影響範囲の広さや再利用性の低さからコストが増えます。 移植性の低下 移植性が低下すると異なる環境でソフトウェアを利用したいとなった際、修正が必要な箇所が増え、コストが増大します。 可読性の低下 可読性が低下するとコード解析の難易度が上がります。結果として不具合修正や改修時のコストが増えます。また意図を理解できずにロジックを修正した結果、欠陥を埋め込んでしまうリスクもあります。 対策 低品質コードは様々な工程で問題を引き起こします。そのため低品質コードを生み出さないことが大切です。対策も様々ですがたとえば下記のようなものが考えられます。 コードレビューを実施する 有識者によるコードレビューを行うことで、問題のあるコードを検知し、修正することが可能です。ただしすべてを見るにはコストが高く、プロジェクトの状況によっては難しいことも多々あります。またレビューアのスキルに依存するため、効果はその時々で大きく変わってきます。 静的コード解析を実施する Linterといわれる静的コード解析ツールやSonarQubeを利用した解析を行い、コードの問題箇所をリストアップできます。リストアップされた指摘を精査していき、問題箇所を修正することでコードの品質を向上させることが可能です。ただし環境・言語によっては導入が難しいことがあります。また警告の量が多く、些細な指摘に埋もれてクリティカルなものに気づかないことも起きえます。 コードメトリクスを計測する コードメトリクスを計測し、その結果をもとにレビューを実施したり、クオリティゲートを設定したりすることで、効率よくコード品質の低下を防ぐことができます。メトリクスにはステップ数、循環的複雑度（Cyclomatic Complexity）、継承の深さ、クラス結合度等、様々なものが存在します。プロジェクトの特性や言語によって利用するものを選定します。 静的コード解析とは 静的コード解析 (せいてきコードかいせき、static code analysis) または静的プログラム解析 (static program analysis)とは、コンピュータのソフトウェアの解析手法の一種であり、実行ファイルを実行することなく解析を行うこと。   静的コード解析 – Wikipedia コーディング規約違反やリソースの解放忘れ、到達不能コード等数多くの問題を指摘してくれるものです。CIに組み込んで違反コードをマージさせないような仕組みにすることもあります。 コードメトリクスとは コード メトリックスとは、開発者が開発中のコードをより理解できるようにする、ソフトウェアの一連の基準です。   コード メトリックを計算する – Visual Studio (Windows) | Microsoft Learn LOC(コード行数)、循環的複雑度(Cyclomatic Complexity)、CKメトリクス(オブジェクト指向言語用のメトリクス群)等、数多くのメトリクスが存在します。 コード上の複雑な箇所を見つけたり、多くの箇所から利用されているものを見つけたりするようなことが可能です。 コード解析サービスを利用するメリット 低品質コードの対策としては前項であげたものがありますが、それまでやっていなかった場合は実際にやるとなるとどうすればいいのかわからず、とりあえずやってみたけど特に得るものもなく徒労に終わるといったこともあります。 そういった場合にはノウハウを持った専門家に依頼することが有効です。 弊社のコード解析サービスはまさにこの対策を提供するものです。 サービスを利用するメリットとしては下記があげられます。 専門家がコード解析、それを受けた改善点のご提案するため、効果をあげやすい 外部の目が入ることで、新しい観点のレビューが実施される 自社で実施した場合にかかる工数が大幅に削減される 静的解析の結果は些細なものがフィルタリングされるため、重要なものにのみ集中できる メトリクスの閾値に適切なものが設定できる プロジェクトにマッチしたCI/CDへの導入方法がわかる(※1) 一度サービスを受けた後は実施した作業・メトリクス計測・閾値設定を継続、改良するだけでコード品質維持が可能になる。他のプロジェクトにも適用しやすくなる。 特に下記のようなことにお悩みのお客さまにおすすめです。 上流工程で品質を担保していきたい 静的コード解析を導入したいが方針が決まらない、導入したが成果が見えない コードメトリクスによるクオリティゲートを設定したいが何をどんな基準で設定すればいいかわからない 不具合が大量に発生してしまっていて手を打つ必要がある 今後もコード品質を向上させていきたい 下図は改善後イメージです。 コード解析サービスの進め方 それでは実際にコード解析サービスがどのように進められていくのかご紹介します。 おおまかなフローとしては下図のようになります。 1.事前準備 まずは対象プロジェクトの状況、課題のヒアリング、目標ヒアリング・設定をします。その後プロジェクト環境に適用可能な商用ソフトウェア、OSS等の調査、インストールを実施していきます。実はここが一番大変だったりします。OSSも玉石混交で、思うように動作しないものも多くあり、利用するソフトの調査に時間と手間がかかります。またお客さまのビルド環境が特殊だったりすると急激に適用できる商用ソフトウェア、OSSが減り、どうしようもないときはOSSをカスタマイズしたりちょっとした補助ツールを作成したりといったこともあります。 2.ソースコードの受領 git等のリポジトリからcloneしたり、プロジェクトフォルダをコピーいただいたり、基本的にはビルド可能なプロジェクトの全ソースをご連携いただきます。解析の中にはビルドしないと解析できないものも存在するためです。 ここでまずはビルド、テストが通るかの確認をします。 3.各解析の実施 下記を実施します。 　a.コードリーディング 　メトリクス計測の結果や、ヒアリング結果から要注意の箇所を確認していきます。コーディングルールがどうなっているか、重複コードがないか、バッドプラクティスのコードがないか等を確認します。 　b.静的コード解析 　SonarQubeやlinter等を利用し静的コード解析を実施します。独自環境であればそれに組み入れられるよう手順を構築します。 　c.メトリクス計測 　各言語ごとに利用可能なOSSや弊社ツールを利用し、必要なメトリクスを計測します。こちらも環境にあわせて手順を構築します。 4.解析結果の分析 解析結果を分析し、重要な指摘をリストアップ、整理していきます。指摘の傾向からどのようなところに注意が必要かを判断します。メトリクス計測した結果からはコードの状態をレポートします。複雑度等が事前に設定した閾値を超えている場合は何が問題なのかを分析します。また各メトリクスから不具合の発生しやすい要注意スポットを割り出します。ここもナレッジがないと難しいポイントとなります。 5.改善点、対応案の作成 指摘や具体的なコードの問題、メトリクスから改善点、対応案を作成し、レポートします。いま存在する問題点の解消と今後コード品質を維持するための施策を含めてご提案します。 6.CI/CDへの導入提案・支援( ※1 ) CIにツールを導入する必要があると考えられる場合にはそこへの導入提案・支援を実施します。継続的にコード品質を上げていく仕組みづくりを考えます。 レポート例 プロジェクトごとに内容は変わりますが、一例として下図のようなレポートを出します。 対象プロジェクトに合わせて設定したメトリクスと閾値にしたがって閾値を超えている箇所を可視化 プロジェクトのコード品質を可視化、またコード内の具体的な問題箇所についても整理し、改善案作成 まとめ 低品質コードは様々なリスクを発生させます。もしリスクが顕在化した際のダメージは甚大になりうるものです。それを避けるためには低品質コードを生み出さないことが重要です。コードレビューや静的コード解析、メトリクス計測等を実施し、コード品質を向上させていきましょう。上流工程の品質向上は後工程のコスト削減や市場不具合の減少につながっていきます。 もしコード品質が低く困っているがノウハウがなくどうすればよいかわからないというようなことがありましたら、ぜひ弊社へご相談ください。エキスパートがお客さまに最適な改善案をご提案します。 ※1 既存のCI/CDへの組み込み対応のみとなります。新規のCI/CD構築支援につきましては別途サービス開始予定となっております。 参考： コード解析 – 株式会社AGEST（アジェスト） The post コード解析サービスのご紹介 first appeared on Sqripts .

こんにちは、AGESTでエンジニアをしているやまたろうです。 皆さんは、FigmaやAdobeXDといったデザインツールをご存知でしょうか。Webシステム開発に携わっている方であれば、聞いたことがあったり、使っている方が多いと思います。 デザインツールという名前を聞くと「デザイナーのためのツール」という印象を持たれるかもしれません。（私も最初はそう思っていました）しかし、実際にエンジニアとしてデザインツールを使って得られたものは想像以上に大きかったので紹介させていただきます。 本記事は、筆者がメインで利用しているFigmaをベースにお話しします。 超高速なプロトタイピング 私はフロントエンド領域を得意とするエンジニアで、2日もあればTwitterのクローンアプリを作れる程度には自信があります。なので、実務でプロトタイプを作成する際はFirebaseやSPAフレームワークを駆使していました。また、デザインツールを活用したプロトタイプは、インタラクションの表現に乏しい「紙芝居」に近いものしか表現できないと思っていたため、実際にアプリケーションの利用イメージを伝えるためには、アプリケーションを開発してしまうことが確実であると考えていました。しかし、それは大きな誤りでした。 以下は、この記事のために作成したサンプルのログインページのイメージです。非常にシンプルな画面ですが、プログラム開発の場合、画面を作る時間に加えて、開発環境の構築やユーザーに触れてもらうためのホスティングなどの設定を行う必要があるため、短く見積もっても30分はかかります。しかし、Figmaを使用する場合は、それらの工程は必要ないため、5分もあれば作成することができます。 また、Figmaのコンポーネント機能を使用することで、状態や振る舞いを持ったUIパーツを定義することができます。そのため、懸念していた紙芝居のような印象を与えることはありません。むしろ、「もうアプリケーションを開発したの？」と勘違いされることのほうが多いです。 よくあるトグルスイッチ プログラムを書かずにコンテキストメニューを表示まで再現可能 その他、豊富なプラグインや無料で公開されているUI Kitを利用することで更に効率よくプロトタイプ/デザインを作成することができます。こちらはオススメが数多く存在するので実際に見たり触ったりして頂くのがよいと思います。 Figma Community 円滑なコミュニケーションの実現 今まではプロトタイプ修正後、デプロイしてからチャットやメールで変更した旨を共有していたのですが、Figmaであればリアルタイムでデザインやプロトタイプが変更されるのでコミュニケーションコストが大きく削減されました。 また、Figmaのコメント機能で修正すべき箇所に直接フィードバックが貰えるので、メンバー間で認識の齟齬が減ったように思います。 UIに直接フィードバックを受けることができるので、どこかを伝える必要がない ドキュメント作成の選択肢が増える 設計資料の中で言葉だけでは伝わりにくい箇所に図面を活用するのですが、Figmaで作成することが増えています。 以下は、Mermaidで作成した構成図を具体的にイメージを持ってもらうために簡略化やアイコンを追加してFigmaで作り直した例です。 Mermaidで作成したエンジニア向け資料 Biz向けFigma製の資料 一般的に、PowerPointを使って図面を作られている方が多いと思いますが、見た目に特化したツールではありませんし、Illustratorは学習コストや料金面で手が出しにくいため、私はFigmaやAdobeXDなどのツールを活用することをおすすめします。 見た目や資料の品質は別のスキルが必要になりますが、自由にデザイン・レイアウトを作れるのはデザインツールならではの長所だと思います。 さいごに 元々はデザイナーさんとのコミュニケーションのために触り始めたFigmaですが、使えば使うほどこのツールの汎用性の高さと洗練された機能に驚かされます。特に資料を作るのが苦手なエンジニアの方であれば十分な恩恵を得られると思うので、利用していない方は是非試してみてください！ それでは、よいFigmaライフを The post エンジニアでも使える！デザインツールFigmaがもたらす効果とは？ first appeared on Sqripts .

この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。 第1回目のテーマは、「アジャイル開発の過去、現在、未来を知ろう！」です。 この内容はUdemyで公開しているオンラインコース「 現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム 入門編 」の内容を元にしています。 アジャイルの現在位置 アジャイル開発の現在・過去・未来～今を知り、源流を訪ね、先を見据える～ 上記の図は、平鍋健児さんという方が2010年に発表した『 アジャイル開発の現在・過去・未来～今を知り、源流を訪ね、先を見据える 』から引用した図です。アジャイル開発が生まれるまで、生まれてからの流れがとても良くわかるすばらしい資料なので、読み解いてみましょう。 アジャイル開発は2001年頃に生まれました。ただ、その前から様々な方法論がありました。たとえば、図の左上にある「EVO」、「FDD」、「Crystal」は、アジャイル開発が登場する前に生まれた開発手法です。 その下には「Patterns」や「TPS」が並んでおり、そこから「XP」につながっています。Patternsは、建築家クリストファー・アレグザンダーが考えたパターンランゲージが元になっています。パターン・ランゲージとは、「こういった場合だと、この方法がいい」といったパターンを解説したものです。この考え方をソフトウェア開発に取り入れたのがXP（エクストリーム・プログラミング）です。TPSはトヨタ生産方式（Toyota production system）です。TPSは日本企業であるトヨタが考えた手法で、もともとは自動車の生産に関係する方法論でしたが、XPだけでなくLean（リーン）やScrum（スクラム）など、様々なソフトウェア開発手法にも影響を与えています。 さまざまな流れは、現在主流になっているスクラムなどを巻き込みながら、「アジャイル開発」へとつながっていきます。 アジャイル開発が誕生した後にもさまざまな方法論や手法が登場しています。たとえばリーンスタートアップがきっかけになってリーンUXなど、リーンの考えをベースとした手法がいろいろ出てきました。また、さすがにXPやスクラムといった有名な手法を超えるものは少ないですが、DevOpsのような考え方も今では当たり前になってきています。 さらに、ソフトウェアの開発方法だけでなく、ソフトウェア開発における組織論、大規模開発などにもアジャイル開発の思想は広がっています。 アジャイルマニフェストの誕生 アジャイル開発は2001年に生まれたと書きましたが、その誕生には面白いストーリーがあります。 2001年、アメリカのソルトレイクシティに、開発手法に詳しい17人が集まり議論を行いました。当時は会議室が見つからず、しかたなく空いていたスキーリゾートを予約して集まったそうです。 その議論の結果、「アジャイルソフトウェア開発宣言（通称：アジャイルマニフェスト」が誕生しました。このアジャイルマニフェストの誕生が、アジャイル開発の誕生となっています。アジャイルマニフェストは、以下のような1枚のWebページで公開されています。 アジャイルソフトウェア開発宣言 この時の様子は、アジャイルマニフェストの背景にも描かれています。背景をみると、ホワイトボードのようなものの前に、幾人かの男性が集まって話し合っている姿があります。ひとりはこちらを向いて、ホワイトボードのどこかを指差しているように見えます。おそらく、こちらを向いている人は、書籍『リファクタリング』などで有名なマーティン・ファウラー氏です。それ以外の背を向けているメンバーも、スノーバードに集まった17人の方法論者です。 また、アジャイルマニフェストの下側には、集まった17人の署名があります。名前を見てみると、世界初のWikiを開発したワード・カニンガム氏や、エクストリーム・プログラミングの生みの親であるケント・ベック氏、スクラムの生みの親であるジェフサザーランド氏なども名を連ねています。 様々な言語に翻訳されたアジャイルマニフェスト アジャイルマニフェストは、わずか10行の文章でしかありません。しかし、このわずか10行のテキストが世界中へと広がり、今では一般的に使われる手法へとなりました。その証拠に、アジャイルマニフェストのページを下にスライドさせていくと、他の言語に翻訳されたページへのリンクが並んでいるのがわかります。この記事を書いている時点では、68の言語に翻訳されているようです。 当時のスノーバードの様子。おそらく世界で一番有名なホワイトボードではないでしょうか？ アジャイル開発の10年、20年 毎年アメリカで開催されるアジャイルカンファレンスは、世界最大のアジャイル開発に関するカンファレンスです。 アジャイルマニフェスト誕生10年を祝うイベント。マイクを持っているのは書籍『アジャイルプロジェクトマネジメント』の著者ジム・ハイスミス氏 2011年は、アジャイルマニフェストが誕生して10年たった記念すべき年でした。その誕生を祝して、アジャイルカンファレンスにおいて、特別なイベントが開催されました。 イベントのテーマは「Back to where it all began. Back to the future」です。日本語に訳すと「すべてのはじまりの場所に帰ろう。そして未来へと進もう」という内容で、ケント・ベック氏を除く16人の署名者が集まり、当時を振り返りました。このときのレポートは、 アジャイルマニフェスト署名者たちが再会する「The Big Park Bench」～Agile 2011 Conference に書いたので、当時の熱気を感じたい方はぜひ一読ください。 現在では、アメリカだけでなく、ヨーロッパでも1000人規模のイベントが行われています。もちろん国内でもたくさんのイベントや勉強会、コミュニティが生まれています。日本語に訳された書籍だけでなく、日本語の書籍もたくさん登場しました。アジャイルマニフェストは、現在も広がり続けているのです。 アジャイルマニフェスト20周年となる2021年にも、誕生を祝うイベントがありました。残念ながら、コロナ禍だったのでオンラインイベントとなりましたが、数人の署名者がスノーバードのホワイトボード前に集まるイベントでした。こちらも 動画が公開されている ので、ご興味があればぜひご確認ください。 アジャイル開発の現在と未来 アジャイル開発の現在から未来を見ていきましょう。この数年のニュースを調べてみると、現在に至るまで、アジャイルの広がりがよくわかります。海外に目を向けてみると、 80％以上の企業がアジャイル開発を取り入れている というデータもあります。 ただ、アジャイル開発はその国の文化にも影響を受けており、日本や香港の場合、ウォーターフォールのような従来型の手法が根強いため、なかなかアジャイル開発の導入が進まないケースもあるようです。 では、なぜ、ここまでアジャイル開発がメインストリームとなったのでしょうか？ その理由はいくつかありますが、まず、変化の激しい時代になったからでしょう。作れば作るほど売れる時代から、消費者ですら何がほしいかわかっていない時代になっているため、消費者のニーズを掘り当てながら進んでいく開発が必要になりました。 また、技術の進化もアジャイル開発に影響を与えています。たとえば、クラウド・仮想化・コンテナといった技術は、開発にスピードや柔軟性といった恩恵を開発者に与えました。手軽に使えるサービスや技術を活用しながら、よりアジャイルに開発ができるようになってきています。 最後に、アジャイル開発が成熟したこともあげられます。アジャイル開発はその名の通り、ソフトウェア開発が中心の理論でしたが、プロダクトマネジメントやビジネス、あらゆる仕事にその考え方が浸透し、広がっています。もうアジャイル開発はソフトウェア開発だけのものではなくなってきています。 これらの状況をふまえて、アジャイル開発の未来をちょっとだけ考えてみると、アジャイル開発はプロダクトマネジメント、テストや品質などを中心に議論が進んできています。この10年でアジャイル開発は当たり前になりました。ニューノーマル（新たな常識）と言えるかもしれません。さらに10年でプロダクトマネジメントやテストや品質分野が成熟していく可能性を秘めています。 さらに、アジャイル開発の拡大を元に、組織やスケールが課題になりつつあります。よって、アジャイル開発に対応するために、企業レベルの変化が求められていく可能性もあります。 The post 第1回 アジャイル開発の過去、現在、未来を知ろう！ first appeared on Sqripts .

はじめまして、QAコンサルタントのヤスゴロウです。今回は私の経験に基づくテストのアプローチ方法をご紹介させていただきます。 テストベースがないシステム テストベース ( ※1 ) 昨今のシステム開発事情 デジタル化が進んだ昨今では新規システム構築は稀で、既存システムのマイグレーションや既存システムの改修・保守開発( ※2 ）が多いと感じております。例えば、システム利用者のフィードバックを受け、改善のための改修・保守開発を繰り返してサービス向上やユーザビリティ向上等をおこなっているようなケースです。 こういった背景の中、弊社へいただくQAコンサルタントやテスト実施のご相談は、既存システムの不具合に悩まされている場合が多い気がしております。 しかもその既存システムに対して改修・保守開発を繰り返しているうちに、サブシステムが増えたり機能間の関係や仕様が複雑になったりする等の理由で、現在の開発担当者が全仕様を把握できていない状況をお見かけすることがあります。 とはいえ、競争の激しい現代においてビジネスを成功するためには、改修・保守開発をスピーディかつ不具合なく実施しなければいけないという使命があるため、大変な世の中だなと改めて思ってしまいます。 私も前職で15年程SE/PGや開発PMに従事しておりましたので、システム開発に携わっている方々の痛みに共感しております。 また、改修・保守開発は長期に渡っている場合があるため、ずっと同じ担当者が開発しているとは限らず、有識者の退職により全仕様を把握している方がいないというようなことはよくあることです。 このような事情から ・改修箇所の影響範囲の特定がうまくできない。 ・隠れ仕様に気づかず、設計、実装、テストの考慮漏れが発生する。 等の原因で本番障害が発生し、既存システムの品質改善や品質向上に悩みを抱えている企業様もいらっしゃいます。現代は避けたくても避けられない道なのかもしれません。 なぜテストベースがない場合があるのか 前述のような昨今のシステム開発事情より、テストベースとなるシステムの最新ドキュメントがない理由は大きく2つあると私は解釈しております。 1.引継ぎ情報不足 長期に渡り改修・保守開発を繰り返していると、開発担当者の入れ替えがあり、引継ぎがうまくできないケースがあると思います。 システムが大きくなればなるほど全仕様を理解することが難しいため、既存ドキュメントを改修する知識が不足し、また正しく更新する自信がないことにより、その時の改修箇所（差分）のみしかドキュメントを書かなくなってしまうのではないかと思います。 2.時間 ビジネスの機会損失を避けるためにシステムリリースのスピードを優先することがあります。動くもの（プログラム）は必須で新しくなっていきますが、そのベースとなる要件定義書や設計書等のドキュメント修正は「時間がないため後回し」にしてしまう場合があります。後で修正しようと思っていても、次のリリースの開発に追われ、ずっと修正できなくなってしまうケースもあると考えます。 また、ちょっとした改修の場合は、簡単なメモ程度で仕様を決めて済ましてしまう場合もあるかもしれません。理想は既存システムのドキュメントを更新して常時最新仕様を理解できるドキュメントを保持することですが、上記のような理由によりドキュメントを最新化できなくなっているのではないでしょうか。 テストベースが無いとどう困るのか 改修・保守開発を繰り返しているシステムにはテストベースとなる最新ドキュメントがない場合があることをお話してきました。では、なぜQA担当者はテストベースが無いと困るのでしょうか。 テストを実行するためには、まずシステムの正しい仕様を理解する必要があります。そして仕様に沿ってテストケースを作成し、「何を以って合格とするか」の基準となる「期待する結果」を定義する必要があるため、そのよりどころとなる情報が無いということになってしまいます。 特に、第三者検証の会社にテストを依頼する場合は、仕様を把握するためのテストベースとなる最新ドキュメントが原則必要となります。 必要なテストベースは実施するテストレベル( ※3 )にもよりますが、例えば利用者目線で業務の流れを一通りテストしてほしいというご依頼であれば、業務フローや業務ルール（処理の分岐条件等）を理解できるドキュメントをご提供いただきたいです。ですが「テストを実施してほしいが、最新仕様を理解できるドキュメントは無いです」と言われてしまった場合、どうすればよいでしょうか？ どういうアプローチがあるか アプローチのアイディア 私が担当したWebサイトのプロジェクトでテストベースがなかった時のアプローチをご紹介します。 私はJSTQBで学んだ「テストオラクル( ※4 )」が使えるのではないかと考え、探してみることにしました。テストオラクルになりそうなものはないか調べた結果、以下3つのものを使用しました。 (1) Webサイト上に公開されている説明やFAQ (2) 運用担当者やシステム管理者向けの業務マニュアル (3) 過去の障害事例 テストオラクルを使ってみる まずは、「利用者に公開している(1)Webサイト上に公開されている説明やFAQの通りに動作しなければ不具合である」とする作戦が良いと考えました。幸いお客様にも良いアイディアだと言っていただけたので、早速テストエンジニアに実践してもらいました。残念ながら(2)は最新なのか分からないものが多かったのですが、Webサイト上に書いていない条件分岐になる業務ルールは正解と見立てて参考にしました。(3)からはテストしたい業務に関係する実際にあった障害をピックアップし、障害が発生した画面操作手順や業務の流れを理解して、テスト条件や期待する結果を検討するための参考にしました。 設計書等のドキュメントに書かれた仕様通りに開発されていることだけが正解ではなく、Webサイト上で利用者向けに告知していることが期待通りにできなければNGにしようと考えたら、あとは意外とスムーズに進みました。 テスト設計の具体例 では、どのようなテスト設計の考え方があるのか一例としてECサイトを例にご紹介させていただきます。皆さんもECサイトで買い物をすることがあるかと思いますが、注意して読んでみると以下のような「業務ルール」と思われることが書かれている場合が多いです。 ・XXXX円以上購入すると送料無料 ・当月XXXXX円以上購入すると翌月顧客ランクアップ ・離島など地域によって特別送料を課金 ・配送方法（種類）を選択 ・決済方法（種類）を選択 ・在庫切れの場合 ・到着前にキャンセルする場合 ・返品する場合 等です。 前述の「(1)Webサイト上に公開されている説明やFAQ」を読み込むと、たくさんの業務ルールがあることに気が付きます。業務ルールを デシジョンテーブル のようなマトリクス表に整理するとテストケースを作成できるようになります。 具体的なイメージをもっていただくために以下に簡単な例を挙げさせていただきます。 例）ECサイトで送料無料になる条件 ・顧客ランクがプラチナの場合 ・顧客ランクがゴールドの場合、かつ１注文あたりの購入金額が5000円以上の場合 ・顧客ランクがシルバーの場合、かつ１注文あたりの購入金額が10000円以上の場合 得られるテスト結果の例（メリット） 私もプロジェクトにおいて、前述のような考え方でテストオラクルから業務ルールを洗い出してテストケースを作成し、テストを実行したら、それなりに不具合を挙げることができました。不具合を一覧にしてシステムの有識者に確認していただいた結果、「サイト上に公開されている説明やFAQ」の方が誤っている場合もあり、サイト上の表記を修正することで、品質向上につながりました。。 その他、長期に渡り立ち止まることなく改修・保守開発を繰り返しているシステムの品質を認識できる良い機会にもなりました。「思っていた以上に潜在不具合があったのだね・・・」というような感想をいただくこともありました。また、最新のテスト設計書ができあがったことにより、システムの有識者以外の方が仕様理解に活用できるようになりました。 まとめ ・長期に渡り改修・保守開発を続けている既存システムのテストはテストベースとなる最新ドキュメントがない場合が多く難易度が高いが、工夫すれば品質向上のための強化テストを実施することができる。 ・テストベースが無い場合は、いかに適切なテストオラクルを見つけ出して妥当な「期待する結果」を導出するかが重要である。 ・場合によっては仕様理解用のドキュメントとしてテスト設計書が利用できることもある。 今回ご紹介したWebサイトのようなフロントシステムの場合はテストオラクルが探しやすいと思いますが、目に見え辛いバックエンドシステムの場合にはどのようなテストオラクルを見つけ出せるのか、今後の課題として取り組んでいこうと考えております。 APPENDIX:用語の説明 ※1 テストベース 「テスト分析と設計のベースとして使用するあらゆる情報」（ ISTQB Glossary より引用）具体的には、以下のようなものである。 ・要件仕様。ビジネス要件、機能要件、システム要件、ユーザーストーリー、エピック、ユースケースの他、コンポーネントやシステムに期待される機能および非機能の動作を指定する類似の作業成果物などがある。 ・設計および実装情報。システムやソフトウェアに関するアーキテクチャー図もしくはドキュメント、設計仕様、コールフローグラフ、モデル図（UMLやER図など）、インターフェース仕様、コンポーネントもしくはシステムの構造を指定する類似の作業成果物などがある。 ・コンポーネントまたはシステム実装そのもの。コード、データベースのメタデータやクエリー、インターフェースなどがある。 ・リスク分析レポート。コンポーネントやシステムの機能、非機能、構造の各側面を考慮する。 出典： ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J03 「1.4.2 テストの活動とタスク」 ※2 改修・保守開発 IPAのソフトウェアデータ白書 「表　開発プロジェクトの種別の選択基準」中段「スクラッチ開発」の「b:改修・保守」に該当する開発プロジェクト 出典： 独立行政法人情報処理推進機構 (IPA) 「ソフトウェア開発分析データ集2022」 2022年9月26日 発行 P.197 この表の通り、母体となる既存システムの規模に対して、どの程度「機能仕様の追加・変更があるか」により、開発プロジェクトの種別を判断してステークホルダー間で共通認識を持つことができる。 ※3 テストレベル 「具体的にインスタンス化したテストプロセス」（ ISTQB Glossary より引用）具体例としては、単体テスト、結合テスト、総合テストのようなテストプロセスの段階。 ※4 テストオラクル 「テスト対象のシステムの実行結果と比較する期待結果のソース」（ ISTQB Glossary より引用）　具体例としては、実在するベンチマーク用のシステム、他のソフトウェア、ユーザーマニュアル、個人の専門知識等など。コードであってはならないと言われている。 The post テストベースがないシステムの不具合を見つけるアプローチ first appeared on Sqripts .

はじめに 旅が大好きな、いしだぁぁです！ 私は、現在ソフトウェアテストとはかけ離れたアノテーション（詳細は後述）に関わるプロジェクトに従事しており、ソフトウェアテストの経験は浅いですが、JSTQBのFL取得に向けた学習を行っています。 ソフトウェアテストを勉強していくうちに、アノテーションの作業プロセスは、ソフトウェアテストプロセスと類似していることが分かりました。 アノテーションの作業プロセスに、ソフトウェアテストプロセスを応用すれば、よりよいプロジェクトになれるのでは、とそう考えました。 まずは、ソフトウェアテストプロセスの良いところをどのように取り入れていけばよいのかと考えたとき、最初に頭に浮かんだのは「学ぶことは、模倣から始める」です。 「模倣」は、否定的に見られがちですが、個人的には、ただ真似るだけではなく、その中から工夫も改善も自然と生まれ、重要な要素であると考えています。 このテックブログを通して、アノテーションのようなソフトウェアテスト以外のプロジェクトでも、ソフトウェアテストの様々な仕組みや技法を知ることによって、プロジェクト成功への近道となるヒントがもらえるのではないか、と感じていただければ幸いです。 アノテーションとは！？ 「アノテーション」と聞くと、あまりなじみがなく、遠い存在だと感じる方が多数いらっしゃるかもしれません。 私もその中の一人でした。 アノテーションとは、英語で「注記・注釈」という意味であり、ITの分野では、対象となるデータの一つひとつに、タグやメタデータと呼ばれる情報の付与を行う作業です。 アノテーションの対象となるデータには、以下の３種類があります。 画像＆動画データ 音声データ テキストデータ より詳しく言うと・・・アノテーションとは、AI開発のプロセスにおける必須の通過点であり、機械学習に使われる教師データを作成する工程を指しています。 教師データって！？ 例えば、みかんの画像があったとします。 この画像を「みかん」とAIに認識させるためには、みかんの画像に「これはみかん！！」という情報を付与してAIに学習させる必要があります。学習用の画像それが教師データです！！この教師データをたくさん作り学習させることで、AIがみかんを認識できるようになります。 しかしながら…AIにみかんの画像だけを学習させればいいというわけではなく、同時に例えば「りんご」との違いも認識する必要があります。AIにみかんだけの画像ばかり学習させてしまったら・・・りんごの画像を見せたときに、りんごをみかんと認識してしまう可能性があります。そのため、りんごのデータも学習させる必要があります。そうすることで、AIはみかんとりんごの特徴の違いを認識できるようになります。 このように教師データを使った機械学習によって形作られたAIは・・・実は、ビジネスや日常生活等のあらゆる場面に潜んでいます。 「これは便利だ！」、「すごい・・・技術が進歩している！！」と思っていたそこのあなた。 それらのモノにはアノテーションを使った学習済みAIが組み込まれている可能性があり、ビジネスや日常生活などで直面する問題を解決する手助けとなっているかもしれません！ アノテーション作業自体はとてもシンプルですが、AIの教師データとなり、その品質がAIの動作に大きく影響を与えます。AIが正しく動作するように、一枚一枚丁寧に作業してあげる必要があります。ですので、 日々我々は「重要な役割を担っているんだ！」という使命感を持って 作業しています。 ソフトウェアテストとアノテーションの作業プロセスについて 書籍『ソフトウェアテスト教科書 JSTQB Foundation 第4版 シラバス2018対応』（以下「ソフトウェアテスト教科書」と称する）に出会う前までは、アノテーションの作業プロセスについて深く考える機会がありませんでした。 ソフトウェアテストを勉強していくうちに、アノテーションの作業プロセスは「実行前作業」「実行時の作業」「完了作業」「全体を通して行われる作業」の4つに分類され明確になるのでは・・・と気付きました。さらに、アノテーションの作業プロセスには、ソフトウェアテストプロセスとの類似点があることにも気付きました。 何を隠そう、私はソフトウェアテスト教科書に出会う前までは・・・事前準備や納品等の事後作業もすべて「作業実行」に含まれると思っていました。つまり、アノテーションの作業プロセスは、「作業実行」1つのみであるというのが、私の最初の考えでした。お恥ずかしい限りです・・・ それでは、両方のプロセスの全体像を見ていきましょう。 ご覧の通り、両方とも「実行前作業」「実行時の作業」「完了作業」「全体を通して行われる作業」の4つに分類することが可能です。 私が現在担当しているプロジェクトについて、ソフトウェアテストプロセスと同じように整理することができました。 ソフトウェアテストとアノテーションのプロセスの類似点について つぎに両方の類似点に着目していきましょう。 プロセス/作業内容 ソフトウェアテスト アノテーション 実行前作業 テスト計画（開始基準の設定） ・テスト目的の決定＆共有 ・テスト範囲の決定　等々 作業前準備（開始基準の設定） ・作業目的の決定＆共有 ・作業範囲の決定　等々 実行時の作業 ・実行レポートへの反映 ・欠陥レポート作成、反映　等々 ・実行レポートへの反映 ・欠陥レポート作成、反映　等々 完了作業 ・テスト結果の報告　 　> 実行レポート提出 　> 欠陥レポート提出 ・テストウェアの整理 ・作業結果の報告 　> 実行レポート提出 　> 欠陥レポート提出 ・改善活動 　> 各レポートの整理整頓　等々 全体を通して行われる作業 ・進捗管理 ・終了基準等の達成状況の確認 ・進捗レポート作成＆提出　等々 ・進捗管理 ・各メンバーの目標値の達成状況の確認 ・進捗レポート作成＆提出　等々 ご覧の通り、プロセス内の作業内容にも多くの類似点があることがわかりました。 多くの類似点の存在を知ったことで、今ではプロジェクトでうまくいかないことがあったら、ソフトウェアテストプロセスや作業のやり方・良いところを模倣して参考にすればよいのだ！という安心感を持って進めることができています。 応用事例の紹介 それでは、実際にソフトウェアテストプロセスを、アノテーション作業プロセスに応用してみると、どのような効果が得られたか、いくつか応用事例を紹介します。 応用事例１「開始基準」の応用 ソフトウェアテスト教科書には、このように記載されています。 開始基準 「開始基準が満たされないままにテスト活動を開始すると、難易度が上がり、テスト時間が増え、コストも増え、リスクが高まります。」 アノテーションは、画像が驚くほど大量にあります。画像が何万枚もある中で、どこから作業を始めればよいか、どこまで作業をすればよいか、といったような迷いが出ないように事前に入念な準備が必要となります。 特に初めて作業するデータに着手する時は、開始基準の設定に多くの時間を費やすようにしています。例えば、トレーニングに要する時間や相互チェックの実施方法、頻度を事前にお客様と相談して決めておく必要があります。 トレーニングに要する時間 どれくらいできればよいか どこまでやるか 相互チェックの実施方法 全量チェックか、サンプリングチェックか どのくらいの頻度でやるか これらを考慮せずに作業を進めてしまうと、予想以上に工数がかかったり、手戻りが発生したりしてしまうという大変な思いをしたことがありました。 作業を円滑に進めるためには、開始基準を明確化し、お客様としっかり連携を行いながら、チーム内の情報共有を行うことがとても重要であると、毎回実感しています。 応用事例２「工数に影響する要因（人の特性）」の応用 ソフトウェアテスト教科書には、このように記載されています。 テスト工数に影響する要因（人の特性） テスト工数を見積もるためには、テスト工数の見積りに影響を与える要因を知っておく必要があります。考慮もれによるテスト工数の見積り誤りを防ぐためです。 見積りに影響を与えるものとして、テスト対象であるプロダクトの特性、開発プロセスの特性、人の特性、テスト結果などが挙げられます。 人には得意分野や不得意分野があり、それぞれの能力や実力には個人差があります。そのため、実際の作業に入る前に、各メンバーが十分にトレーニング期間を設けて、各メンバーの能力と実力を正確に把握することが必要となります。 各メンバー同士も作業に必要なスキルや知識を共有できますし、作業管理者も各メンバーの能力と実力に合わせた作業分担やスケジュールを立てられるようになります。 以上のように、工数に影響する要因として人の特性を把握することが、工数見積りの精度向上につながる重要な要素であると、毎回実感しています。 応用事例３「欠陥マネジメント」の応用 ソフトウェアテスト教科書には、このように記載されています。 欠陥マネジメント 欠陥は、検出時点から分類、修正、最終確認まで、きちんと追跡しなければなりません。その対策が終了するまでマネジメントできなければなりません。 欠陥をマネジメントするためには、発生したすべての欠陥を記録しなければなりません。 アノテーションミスを見つけることは重要ですが、それらをきちんと管理していかなければなりません。以前は適切に管理できておらず、記録が見つからない、同じ失敗を繰り返すなんてことがありました。今は記録を取り比較することで、優先順位を付けられますし、ミスの記録を参照することによって、将来的なミスの予防につなげられるようになっています。アノテーションミスの記録を残し活用することがとても重要であると、毎回実感しております。 以上、応用事例を３つ紹介しましたが、ソフトウェアテストプロセスを応用することで、 作業の効率が上がり、他の作業に割ける時間が増えるなど、様々な効果が生まれました！ 同時に、「学ぶことは模倣から始める」ということが大切であるとひしひしと感じました。 おわりに 最後になりましたが・・・ 今のプロジェクトをよりよいものにしていきたいという思いから始まった挑戦 　 ソフトウェアテストプロセスの他分野への応用 「学ぶことは、模倣から始める」 　「物事の上達は、模倣にあり」 うんうん、模倣だっていいさ。 まずは、模倣してみることから始めて改善に役立てたいと考え、ソフトウェアテスト教科書を読み込んで、とことん模倣してやろう！という気持ちで改善活動をスタートしました。 この改善活動によって、ソフトウェアテストプロセスとの類似点があるという新たな気付きや、模倣から始まり改善に役立てたという新発見をもたらしました。そして、応用事例で紹介したように様々な効果が得られ、業務改善に役立てることができました。 今回の学びは、ソフトウェアテストプロセスの中から、模範となるものを見つけて、そこから模倣して、改善に役立てるのが、私にとってプロジェクト成功への近道であるとわかったことでした。 教科書は読んで終わりではもったいないです！！ ソフトウェアテストプロセスの良いところを模倣して、改善活動してみませんか？ ひょっとしたら、ビジネスだけではなく日常生活シーンでも改善に役立って、心豊かな生活のヒントをもらえることがあるかもしれませんよ！？ 今回の活動を通して、「他分野へのソフトウェアテストのプロセスの応用」が利くということがわかりましたので、今後も試行錯誤を繰り返しながら改善活動を継続していきたいと思います。 皆さんもぜひ、模倣から始めて、新しいことに挑戦してみてはいかがでしょうか。 追伸 2月末、JSTQB認定テスト技術者資格 Foundation Level試験を受けてきました～さて、結果はいかに！？ 次回、試験結果・・・それとソフトウェアテスト経験が浅い私の勉強の進め方も紹介するので、お楽しみに♪ The post 模倣だっていいさ　挑戦してみた　ソフトウェアテストプロセスの他分野への応用 first appeared on Sqripts .

デバッグとは デバッグの語源や由来 デバッグという言葉は、不具合を表す「バグ（bug）」という言葉に由来するとされています。 実際にコンピュータに虫がはまり込んで故障を起こし、虫を取り除いたことにちなんで名付けられたと言われています。 デバッグの重要性 デバッグは、ソフトウェア開発の重要なプロセスの１つであり、プログラムが期待通りに動作しない場合に、その原因を特定し修正することです。デバッグが重要な理由は、ソフトウェアにバグがあると、それが原因でソフトウェアが正しく動作しなくなる（バグ）ことがあるためです。 例えば、予期せぬ動作が発生したり、データの損失、セキュリティ上の問題など、様々な問題が発生する可能性があります。そのような問題は、顧客やユーザーから不満やクレームが出ることがあり、企業の信頼性や評判に悪影響を与える可能性があります。そのため、デバッグはソフトウェア開発において欠かせない作業であり、十分な時間とリソースを費やすことが重要です。 デバッグとテストの違い デバッグとテストは関連性がありますが、異なるプロセスです。具体的に言うと、テストはソフトウェアの品質を評価するために、入力値や条件を変えながら繰り返し実行し、正常動作やエラーが発生しないことを確認するプロセスです。 一方、デバッグはテスト中に検出されたエラーを修正するために、エラーの原因を特定して、修正するプロセスです。つまり、テストとデバッグは密接に関連していますが、テストはソフトウェアの品質を確保するためのプロセスであり、デバッグはテスト中に検出されたエラーを修正するためのプロセスであると言えます。 デバッグのプロセス バグの発見 プログラムのバグは、さまざまな方法で発見できます。テスト段階、ユーザーからのフィードバック、エラーメッセージ、クラッシュやフリーズなどの動作異常などがそれに当たります。開発者自身がコードをレビューして問題を見つけることもできます。 さらに、自動テストツールを使ってバグを検出することもできます。自動テストツールは、テストスクリプトを作成して自動的にテストを実行し、ソフトウェアの動作を評価します。 また、静的解析ツールを使って、ソースコードの構文やロジックを解析し、潜在的なバグを検出することもできます。バグを発見するためには、多様な手法を駆使し、徹底的にテストを行うことが重要です。 バグの原因の特定と分析 バグが発見されたら、それを修正するためにバグの原因を特定し原因を分析する必要があります。バグの原因を特定するために、開発者はデバッグ技術を使用して問題を特定します。これには、デバッガーの使用、ログファイルの分析、コードのレビューなどが含まれます。 バグの原因を特定したら、原因を分析し、修正するための対策を検討する必要があります。バグが発生した環境を再現し、修正されたコードが望ましい結果を生成することを確認するために、テストを実行する必要があります。 バグの修正と検証 バグの修正には、バグが含まれるコードの変更が必要です。修正後には、テストを実行して、修正が正しく機能していることを確認する必要があります。テストは、単体テスト、結合テスト、システムテスト、受け入れテストなど、さまざまなレベルで行われます。また、コードの修正が予期せぬ影響を及ぼしていないかをテストするレグレッションテストもあります。 デバッグプロセスの成功には、開発者が良好なデバッグ技術を持っていることが不可欠です。また、デバッグ過程で生成される情報を分析し、問題の特定と解決策の検討を行うことが重要です。最終的に、バグの修正とテストが行われ、問題が解決されたことが確認されるまで、デバッグプロセスは続きます。 デバッグの手法 机上デバッグ 机上デバッグとは、プログラムのコードを読み込み、問題を予測し、推論する手法です。コードを熟知していることが前提となります。机上デバッグでは、コードのシミュレーションや手計算によって、プログラムの実行過程を想定し、問題を特定することができます。具体的には、変数の値の変化や制御フローの動きを手計算で追いながら、どこで問題が発生しているかを推論することができます。 机上デバッグは、デバッグの初期段階でよく使われますが、複雑なプログラムになるほど限界があるため、実際にプログラムを実行しながらデバッグする必要があります。 デバッガを使う デバッガを使うことで、実行中のプログラムの状態を見ることができます。デバッガを使って実行中のプログラムにブレークポイントを設定することで、特定の箇所で実行を止めることができます。ブレークポイントで実行を止めた後は、その時点での変数の値を確認したり、ステップ実行という機能を使って、1行ずつプログラムを実行しながら問題を特定することもできます。デバッガは、複雑なプログラムのデバッグに非常に有効であり、開発者にとって欠かせないツールの1つです。 デバッグを効率的に行う方法 設計書を確認し、仕様を把握する ソフトウェア開発においては、設計書に基づいてプログラムを作成します。プログラムに不備がある場合、設計書に不備がある可能性があります。そのため、設計書を確認し、仕様を把握することが重要です。 設計書は、ソフトウェアの全体像や各機能の詳細な仕様、ユーザーインターフェースの設計などが記載されているため、設計書を確認することで、プログラムがどのように動作するかを把握することができます。プログラムに問題がある場合、設計書を再度確認し、仕様が適切に反映されているかを確認することが重要です。 設計書の内容が不明確であったり、不備がある場合は、開発チーム内で議論を行い、問題を解決する必要があります。 わかりやすいプログラムを書く わかりやすく、コンパクトにまとめられたプログラムを書くことで、デバッグの効率が上がります。変数の名前を適切につけたり、処理をわかりやすく分割することで、デバッグがしやすくなります。 また、コメントを付けることで、プログラムの処理内容や意図が明確になり、デバッグがよりスムーズに進むでしょう。さらに、コーディング規約に従ってコードを書くことで、複数人での開発においてもコードの可読性が向上し、デバッグ作業が効率的に行えます。 ログを出力し確認できるようにしておく プログラムが実行される際に、ログを出力することで、プログラムの動きを確認することができます。ログを出力することで、特定の箇所でプログラムが異常終了したり、想定外の値が返されたりすることがわかります。 また、ログを出力することで、プログラムの動作を再現することができます。バグを再現することができれば、その原因を特定しやすくなります。ログを出力する際には、必要な情報だけを出力するように設定することが大切です。大量のログが出力されると、逆にデバッグの効率を下げてしまいます。 分割統治法 分割統治法は、問題を小さな部分の問題に分割し、それらを再帰的に解決していく手法です。大きな問題を小さな問題に分割することで、それぞれをより単純な問題として解決することができます。 例えば、ある関数において発生しているバグの原因を探したいが、処理が大きく複雑になってしまった場合、問題のある箇所とない箇所を分けることで問題箇所を絞り込んでいきます。 分割統治法は、アルゴリズムやデータ構造の設計にもよく用いられる手法です。 デバッグツール デバッグツールを利用するメリット・デメリット デバッグツールのメリット デバッグツールを利用すると、以下のようなメリットがあります。 プログラムの実行中にデータの値を確認できるため、プログラムの振る舞いをリアルタイムで確認できます。 デバッグツールは、プログラムの構造を理解するのに役立ちます。コードの一部分だけでなく、プログラム全体を俯瞰することができます。 デバッグツールは、コードの実行速度を計測することができます。これにより、プログラムのボトルネックを見つけることができます。 デバッグツールのデメリット デバッグツールを利用すると、以下のようなデメリットがあります。 デバッグツールは、プログラム実行時にリソースを消費するため、プログラムの速度が低下する可能性があります。 デバッグツールの操作方法を理解するまでに時間がかかる場合があります。 デバッグツールは、プログラムが動作している環境に依存するため、特定のプログラミング言語やプログラム実行環境に限定される場合があります。 代表的なデバッグツール 代表的なデバッグツールには、以下のようなものがあります。 Visual Studio Debugger：Microsoft Visual Studioに含まれるデバッグツール。C/C++やC#、Visual Basic.NETなどで書かれたプログラムのデバッグに使用されます。 Xdebug：PHPのデバッグツール。PHPスクリプトのデバッグやプロファイリングに使用されます。 WinDbg：Microsoft Windows上で動作するデバッグツール。Windowsのカーネルやドライバ、アプリケーションのデバッグに使用されます。 gdb（GNU Debugger）：UNIX系OS上で動作するデバッグツール。C言語やC++言語で書かれたプログラムのデバッグに使用されます。 Valgrind：Linux環境で動作するプロファイリングツール。メモリリークやプログラムの最適化に使用されます。 まとめ デバッグは、ソフトウェアの品質を維持するための重要なプロセスです。バグの発見方法には多様な手法があり、自動テストツールや静的解析ツールも使用できます。 デバッグの目的は、テストとは異なるプロセスで、テスト中に発見されたエラーを修正することです。バグを修正するためには、バグの原因を特定し、原因を分析する必要があります。プログラムの問題がある場合、まず設計書に不備があるかどうかを確認することが重要です。また、コードの品質を上げることでデバッグをしやすくすることが大切です。 デバッグをうまく活用してプログラム開発を行いましょう。 The post ソフトウェアプログラミングにおけるデバッグとは？ first appeared on Sqripts .

テスト駆動開発のスタイルを取り入れているもののテストのことはあまりよくわかっていないプログラマーと、テストへの熱い情熱をもちつつプログラマーの事情はわかっていないテスターとが、小さな障害の発見をきっかけとして出会い、役割の壁を崩しながら少しずつ協調するようになっていく、小さなお話です。 登場人物 プロ之 … プログラマー テス緒 … テスター 前回、テス緒さんとプロ之さんはそれぞれのリーダーから指摘を受け、プロダクトにとって大事なこと、チームにとって大事なことが何なのか考え直しました。そしていま調べている問題も大事なことだから、継続して調べようと2人で決意しました。 プログラマーが切り込む話 テス緒さんはテストチームリーダーと、プロ之さんは開発チームリーダーとそれぞれ交渉し、もうしばらくこの問題を追及していいことになりました。2人はそれぞれ自分の時間を使って調査を進め、これからお互いの発見を持ち寄って話し合うところです。 プロ之(以下、P)「total_hoursを更新する可能性がある箇所を、コールグラフを使って探したらAPIと画面合わせて4箇所ありました。APIはその先にUIがあるので、画面的には9箇所になります」 テス緒(以下、T)「えっそんなに？」 P「でも画面によっては他の項目を更新するだけなので、実際にtotal_hoursを変えられるのは4画面です」 T「あ、それならわかる」 P「4画面のどのパスもテストでカバーしているし、とりあえずおかしくは見えませんでした。ところがですね、念のためgrepしたら…」 T「ぐれーぷ？」 P「…リポジトリ横断して全検索したら、まったく別のアプリでtotal_hoursがヒットしました。更新していないバージョンで、どうやらIE対応のもののようです。現状稼働しているのか、よくわかりません」 プロ之さんはツールを駆使して、関係ありそうな箇所を絞り込みました。こうしたツールは開発中や、特にデバッグ時によく使うものです。 T「すごい！ よくそんな詳しく調べられたね」 P「基本的なことですよ」 T「ホームズみたい！」 P「カンバーバッチみたいですか？」プロ之さんの顔がちょっと嬉しそうになりました。 テス緒さんが「あ、ロバート・ダウニー・Jr.だと…」と言いかけるとプロ之さんの顔が曇ったので、あわてて話題を変えました。※1 ポイント: 問題の原因となり得る箇所を特定するために深く掘り下げるアプローチがある 開発者が原因追求に利用するツールはテストや調査でも利用価値がある ※1 著者はジェレミー・ブレット派です。 テスターが見逃さない話 テス緒さんはログを画面共有で表示しながら説明しました。「テストケースを増やすのはやめにして、表示がおかしいあたりのデータが登録されたときのログを500行くらい絞り込んで眺めたのね」 P「ただ眺めるんですか？」 T「他の仕事もあるからずっと眺めてたわけじゃないけど、ときどき引っ張り出してね。何度も見てると、だんだん“引っかかるな”って感じがしてきて、そうしたら！ 気がついたのよ」 P「ただ眺めるだけで？」 T「っていうか、絞り込んだログだけ眺めても何もわからなかったんだけど、別の条件にしたらログの出方が違っているのに気がついて。ほとんど同じなんだけど、あっちは”recorded”なのに、こっちは”record”になってて、スペルが違うでしょ。表示がおかしくなるのは、”record”って出ているときだけみたいで」 P「すごいですね。執念というか」 T「気になったから気にしてただけだけどね。これ、なんでだかわかる？」 ポイント: ログやデータなどを広範に調べ、問題の起きる条件を追求するアプローチもある 意味がわからなくても些細な違いや違和感を拾い上げると、突破口になることもある ついに問題を突き止めた！ プロ之さんは少し考えて答えました。「わかりませんが、調べればわかると思います。その部分はログの固定文言だと思われるので、検索すればすぐ見つかると思います」 プロ之さんはそう言いながらもうキーボードを叩いています。テス緒さんはプロ之さんがどう作業を進めるのか知りたくなって、画面共有してもらうように頼みました。 T「タイピングすごい速いんだね。あ、検索ってコマンドで実行するの？ いつも検索ツールを使ってるけど、そっちの方が早いね」 P「ログを検索するのとコードを検索するのは違いますよ。でも良かったらあとで教えます。それはともかく、ログに”recorded”ではなく”record”と出力する箇所が見つかりました。total_hours更新で絞り込むと…やった、1箇所だけです。それに…先ほどのIE用サービスの中です。これはビンゴですよ」 T「じゃあそのサービスを使っている画面を使えば、現象を再現できるかも！」 プロ之さんはIE用のサービスを手元の開発環境で立ち上げて、テス緒さんは以前に作ったテストケースを実行しました。数件実行したところで、テス緒さんが声を上げました。 「出た！ できた！ こっちの画面で入力して、あっちの画面だと9.9だけど、この画面は10.0になってる。やったよプロ之さん！ 突き止めたよ！」 「やりましたね。古いモジュールが原因だったんですね。おめでとうございます」プロ之さんは表情はあまり変えず、しかしいつもより早口で言いました。 テス緒さんはくちびるを尖らせて言いました。「何言ってるの、おめでとうなんてひとごとみたいに。プロ之さんと私で一緒にやりとげたんだから、もっと喜んで！ ほら、やったーって言って！ やったーって」 「確かにそうですね。私も嬉しいです。でもやったーと言う必要は…言わないといけないんですか？…はい、では、や、や、ヤッター」 こうして、テス緒さんがテスト中に発見した不思議な挙動の原因が判明しました。まだ開発環境で確認しただけなので、本番環境でも同じ結果になるか追加の確認が必要です。また原因がわかったら、修正して正しく動くようにすることになります。問題の性質によっては、修正が難しいことがあったり、影響が軽微なら修正不要と判断する場合もあります。プロ之さんは既に、どう修正を進めるのが良さそうか考え始めています。 2人はここでいったん作業を終えることにしました。1週間後にまた集まることにして、それまでに本番環境での確認を進めたり、IE対応サービスがなぜ最近修正されていないのか調べたりしてくることにしました。テス緒さんもプロ之さんも、大きな壁を乗り越えた充実感と自信に満ちあふれて、明るくセッションを終了しました。 ポイント: 開発者にもテスターにもそれぞれの直感があり、両方を組み合わせて使う おたがいのスキルや経験、人間性を尊重しあうと能力を発揮できる 真の問題とは？(次回に続く) テス緒さんはIE対応サービスを使うために、過去のテスト資料を調べていました。そこで見つけたテストケースには、なんと「IE対応終了のテスト」として、画面がすべて使えないと確認するテストケースが書いてありました。実際に試しても、本番環境ではIE対応サービスにアクセスできません。 テス緒さんは考えました。「(問題がある箇所を見つけたのに、アクセスできないんだったら実際には問題が起きるわけがない！ まったく違うところに問題があるのかなあ？ それじゃあ調べたのが全部ムダになってしまう。どうしよう…)」 同じ頃プロ之さんは先輩の開発メンバーから、IE対応は1年以上前に終了しており、サービスも停止していると教わっていました。それを聞いてプロ之さんも考えます。「(終了しているサービスなら問題は起き得ないし、修正しても意味はない。修正の検討は時間の無駄になった。ここまでの調査も無駄と言える。これ以上、時間を使う意味はない)」 本連載の次回では、2人がついに真の問題に到達し、連載も最終回となります。 The post 【テスターと開発者が上手に協力するには】第4回：立場を越えて問題を追及しよう first appeared on Sqripts .

こんにちは、エンジニアをしているタカです。 今回は 私が受けた アジャイルソフトウェア開発技術者試験の 受験レポートを記したいと思います。 アジャイルソフトウェア開発技術者検定試験とは アジャイルソフトウェア開発技術者検定試験 アジャイルソフトウェア開発技術者検定試験は、アジャイルソフトウェア開発に関する知識やスキルを認定するための検定試験です。 Lv1, Lv2がありますが、Lv1は受験するための条件は無く、アジャイル開発の基礎知識に関する問題が出題される入門的な位置づけです。 なお、検定試験は指定された全国の試験会場と日時での受験が可能です。 受けようと思ったきっかけ 直近のプロジェクトでスクラムマスターの役割で開発に携わっており、体系的な知識の整理に役立ちそうと感じたことや、現時点で会社の推奨資格に上げられていることもあり、受けてみようと考えました。 申込完了まで 受験申し込みは、公式サイトからリンクされているプロメトリックのサイトでプロメトリックIDを取得のうえ、試験日の3営業日前までに会場と時間を指定して申し込みを行います。 Lv1の場合、受験料金は11,000円（税込）でした。 申し込みが完了するとメールで確認証が送られてきますが、念の為、画面に表示された確認証を印刷しておきましょう。 学習 アジャイル検定公式テキスト が販売されており、体系的な知識を整理するためにも、こちらを購入して学習することをおすすめします。 プロジェクトでアジャイル開発に携わっている場合は、このテキスト以外に学習は特別必要ない印象でした。 ただし、本番試験は60問で合格条件が80%のため、単純計算で48問以上の正答が必要となります。 ミスを極力減らす必要があるため、XP、スクラムなどの様々なアジャイルのフレームワークの用語や考え方を知っておくと良いので、必要に応じて、アジャイルサムライなどの関連書籍も一読しておくと安心かと思います。 なお、試験内容については守秘義務があり、過去問題も出回っていませんが、公式テキストに演習問題が付いています。 試験当日の流れ 当日は、試験開始時間より前に集合時間が設けられており、その時間まで会場に向かい、確認証と、確認証記載の本人確認書類を提示して受付を済ませます。 私は会社近くの受験会場に申込み、徒歩で会場に向かったのですが、初めて行く場所だったので入り口を探すのに5分ほど迷い…結果的にギリギリの到着になりました。 どのような試験にも言えることですが、初めて行く場所には早め早めに付くように心がけていきましょう。 なお、集合時間に遅れた場合は受験ができないと明記されているので要注意です。 入室～試験中 時間になったら、指定される最低限の持ち物だけを持って入室します。 なお、ティッシュは持ち込みが許されており、鼻炎持ちの私には大変助かりました。 他の荷物はロッカーが準備されているので、そこにしまっておきます。 試験時間は60分で全て選択式となります。 時間は余る印象なので、問題と回答をよく読み、全て回答したらもう1周最初から読み込んで、ケアレスミスを無くすことを心がけていきましょう。 前述の通り問題内容はここでは掲載できませんが、私の結果は97点で合格でした。 試験が終了するとその場で結果が出るので、事前に指示された通りに退出し、受付の方に報告後に荷物を持って退出となります。 結果レポートはメールで受け取れ、後日合格証明書が送られます。 おわりに 今回の内容は以上となります。 Lv1試験はいつでも受けれる試験かつ難易度はそこまで高くないため、比較的受けやすい試験になります。 興味をお持ちの方の参考になれば幸いです。 The post アジャイルソフトウェア開発技術者検定Lv1 受験レポート first appeared on Sqripts .

こんにちは、見習いフロントエンドエンジニアのぱやぴです。 新卒として2022年4月に入社、9月に配属されもう早一年がたとうとしていることに驚きを隠せません。何より後輩が入ってくるということが最大の驚きです。 そこで今回は入社から執筆現在(4月)までの約1年間に何を行い、何ができるようになったのかを紹介したいと思います。 AGESTの新卒エンジニアはこういう感じなんだなと一つの例として見ていただければ幸いです。 はじめに まずは簡単に自分のプログラミング歴を紹介します。 情報系の大学を出ており、プログラミングはC言語を簡単に一通り学びました。 C言語を学ぶ中で再帰とポインタにトラウマを植え付けられ、在学中は正直プログラミングに苦手意識を持っていました。 新卒研修(4月 ～ 8月) AGESTは4月から8月末まで研修を行います。 インフラから開発、テストまで一通りを時間をかけて教えていただきました。 開発の研修ではHTML、PHP、JavaScriptを学びました。 Progateから始まり、いくつかの課題を通してコードの書き方や、コードを書く楽しさなどを学ぶことができました。 また、同期とお互いに教えあったりすることもあり、同期仲を深めると同時に技術について自信を持ちながら研修を進めることができました。 この研修で大学在学中に抱いていたプログラミングへの苦手意識を払拭することができ、9月の配属を迎えることができました。 配属(9月 ～ ) いざ、配属です。 ここから配属後研修でさらに深く技術について学ぶ機会をいただけました。 学んだ技術 配属後研修では主に以下二つの技術について学びました。 TypeScript 現在書いているコードの9割9分はTypeScriptを用いており、現在の自分の開発業務には欠かせないものです。研修ではJavaScriptは学びましたがTypeScriptは配属後から学び始めました。 型を考える大変さはありますが、そのおかげで得られる恩恵が大きく、日々TypeScriptとは喧嘩をしながら仲良く業務をしています。 React フロントエンジニアとしての第一歩を踏み出しました。 学べば学ぶほど奥の深さを実感し、Notion等今まで何も考えずに使っていたサービス等のコンポーネントに対して「すごいなこのコンポーネント…」となることが増えました。 まだまだ未熟ではありますが、少しずつ作れるものも増えてきており日々学びながら業務に向かっています。 それではそれぞれ詳しく何を行ったのか紹介していきます。 TypeScriptの学習(9月 ～ 11月) 行った内容は以下の3つでした。 APIの呼び出し Playwrightを用いたスクレイピング Slackbotの作成 それぞれ簡単に説明します。 APIの呼び出し TypeScriptとのファーストコンタクトでした。 ここでTypeScriptの基本的な書き方や実行方法、JavaScriptの違いを学びました。 実際にはAxiosを用いてRESAS APIの呼び出しを行うコードを書きました。 ここからAPI呼び出しの際の型との戦いの火ぶたが切られました。 RESAS APIとはRESASという地域経済分析システムのデータを取得することができるAPIです。 詳しくは以下のURLを確認してみてください。 RESAS-API – 地域経済分析システム（RESAS）のAPI提供情報 Playwrightを用いたスクレイピング 弊社はテストの会社ということもありPlaywrightの使い方について学びました。 TypeScriptの書き方に慣れつつ、DOMツリーの学習を踏まえてスクレイピングを行いました。 実際にはO’REILLYの書籍一覧から各書籍のURL、書籍名、表紙の画像URL、発行年月日、ページ数をローカルに保存するコードを書きました。 スクレイピングをする際はrobots.txtや利用規約などを確認し、サーバーに負荷をかけない程度に行いましょう。 Slackbotの作成 一通りTypeScriptを学ぶことができたため、社内用のSlackBot「デジタルコンシェルジュ こころちゃん」の開発を行いました。 以前出した記事 で当時に起きた問題とその解決について紹介をしているので良ければぜひ見てみて下さい。 ここではどちらかというとバックエンド寄りの実装をTypeScriptで行っていました。 GCPやGoogle APIのOAuth認証についても学ぶことができ、非常に勉強になりました。 (GitHubの利用) このSlackBotの開発からGitHubを用いた開発を行っており、同時にGitHubを用いた開発方法についても学ぶことができました。 Gitは取り返しのつかないことをしてしまいそうで怖いと感じていたのですが、今回のような一人のプロダクトで実際に触り動作を理解することで少しずつGitHubの使い方を知ることができ、便利さを改めて実感しました。これからもGitHubとはもっと仲良くしていきたいです。 この三か月の経験でTypeScript、GitHubの知識や開発経験を得ることができ、コードを書くことに自信が持てるようになりました。 Reactの学習(12月 ～ 現在) Reactの学習では主に以下の2つのことを行いました。 O’REILLYの「Reactハンズオンラーニング 第2版」 コンポーネントの作成 O’REILLYの「 Reactハンズオンラーニング 第2版 」 O’REILLYの書籍を一通り学習し、Reactの基礎を学びました。用いた書籍は以下のものです。 Reactハンズオンラーニング 第2版 この書籍はクラスコンポーネントではなく、最近の主流である関数コンポーネントの記述方法で書かれており、関数コンポーネントを用いたReactの書き方の基礎を学ぶことができました。 コンポーネントの作成 書籍で一通りReactを学ぶことができたのでいざ実践です。 他のコンポーネントライブラリも参考にしながらコンポーネントの作成について学び、主業務で開発しているサービスに使用するコンポーネントの作成を行いました。 仕様書をもとに、必要な機能を考え実装を行い、デザインを反映する形でコンポーネント開発を行い、自社のコンポーネントライブラリを充実させていきました。 また、ここでUI/UXやパフォーマンス、セキュリティ等フロントエンジニアとして必要な知識や技術を教えていただきフロントエンジニアとして第一歩を踏み出しました。 現在 現在は引き続きコンポーネント作成を通してReactについて学んでいます。 カレンダーや検索可能なマルチセレクトなど、ある程度複雑なコンポーネントの作成までできるようになりました。作れるものが増えてきていることを実感することで、楽しくフロントエンジニアとして学ぶことができています。 以下作ったコンポーネントの一部になります。 カレンダーコンポーネント マルチセレクトコンポーネント また、コンポーネントの作成の延長で、作成したコンポーネントを用いる機能の開発部分を任されることもあり、徐々にチームの一員として業務に参加することができています！ 終わりに 配属からの約一年間をさらっと振り返ってみました。思い返せばいろいろなことをやらせていただいており、非常に充実した半年間でした。 また、実装にあたって相談させていただけることが多く、先輩、上司の方には感謝の念に堪えません。 少し苦手意識を持っていたプログラミングも入社してからの一年で自信を持つことができ、自分自身の成長を感じました。四月から社会人初の後輩が入社してきますが、負けないようにこれからも成長し続けれればと思います。 これからも、かっこいいエンジニアになれるよう日々努力を続けていきます。 この記事が何かの参考になったら幸いです。 The post 新卒がエンジニアとしての一歩を踏み出すまで first appeared on Sqripts .

テストの自動化、特にE2Eテストの自動化を行ううえで、ツールの選定はとても悩ましい問題ではないでしょうか。 特に有償のツールを用いる場合、会社でお金を払ってライセンスの購入や契約をするわけなので、「なんとなく」や「有名だから」「他社が使っているから」では通りません。 OSS等の無料のツールを用いる場合は一見そうした説明責任からは無縁に見えますが、導入後にトラブルが起こった際には「選定の責任者」としての対応を迫られることになります。 いずれの場合も、ツール選定のプロセスを明示して組織内で合意をとる必要があります。そんなときによく用いられるのが、ツールの比較表です。筆者も過去テスト自動化のコンサルテーションを行っていた際には何度も作成しました。比較表があることで、他にも候補がある中でこんな項目を比較して選びました、という証拠にもなります。 そんなツール比較表ですが、使い方・結果の捉え方次第では、ツール選択に悪い影響を及ぼすこともあるのです。 本記事では、そんな比較表を用いたツール選定で失敗しないよう、活用方法や注意すべきポイントについて見ていきます。少しニッチな内容ですが、参考になれば嬉しいです。 なお、E2Eテストの定義については玉川さんの記事 E2Eテストの自動化を最速で成功させる秘訣 | Sqripts と同じとします。 ツール比較表とはどんなものか 本記事で扱う「ツール比較表」とはどういったものでしょうか？ 細かいフォーマットは作成者によって異なりますが、一般的には以下のようなものを指します。 一方の軸にツールの名称、もう一方の軸に比較したい項目を書き、交差するマスに○△✕や、直接情報を記載して作成します。 この表を埋めて、自分たちのニーズに最も合うツールを選ぶ、という使い方が一般的です。 比較表を用いて選定することの注意点 このツール比較表を作成すれば自分たちにあったツールが選択できると思われがちですが、いくつか気をつけなければいけないポイントがあります。 注意点１：比較表の陳腐化 昨今は「変化が早い時代」「開発サイクルの高速化」などとよく言われますが、これはテスト自動化ツールについても同様です。ツールを開発している各社は、自分たちのツールをよりよいものにすべく、日々機能追加や改善を行っています。 結果、ツール比較表を作成しても１週間後、１ヶ月後には内容が古くなっている可能性があります。しかし、各ツールの更新情報を常にチェックして比較表を最新に保つ、というのは現実的ではありません。そのため、ツール比較表の情報はどうしても古くなってしまいがちです。 まずこの点に注意が必要です。 注意点2：比較表には現れないポイントがある ツールの比較表の項目は、ツールの機能・スペックの比較になりがちです。これらももちろん大事ですが、一方で比較表には現れづらいけれども選定の材料になるポイントがいくつかあります。例えば以下が挙げられます。 使い勝手 サポートの質 開発・ユーザコミュニティの活発さ 使い勝手については主観も多分に含むため、単純な比較は困難です。これは後の項目でも触れますが、実際にトライアルをしてチーム内で意見を募ることで一定の判断ができます。 一方、サポートの質は短期のトライアルでは判断しづらい部分もあるかもしれません。トライアル前後のツール会社とのやりとりの際に、レスポンスの早さなどから間接的に推測することになります。最低限、何営業日以内に返事がくるか、サポートセンターがあれば国内か海外か、日本語でのやりとりがどの程度可能かなどは調べておきましょう。 また、特にOSSの場合は、開発の活発さやコミュニティの盛り上がり具合なども注意すべきです。具体的な線引きは難しいですが、GitHub等でツールのリポジトリを確認し、最終更新が “4 Years Ago”など古いものは注意が必要です。OSやブラウザ、使用している言語のバージョンアップに対応されない可能性が高いです。 注意点3:比較項目を挙げること自体にスキルが要る これが最も見逃されがちな点かもしれません。そもそも、 多種多様なテスト自動化ツールについての比較項目を挙げること自体に、一定のスキルが必要 です。 システムテスト自動化の知識や経験がない状態で比較表を作成すると、例えば「データ駆動テストが可能か」「オブジェクト管理の機能があるか」などを挙げるのは困難でしょう。これらの項目について調べるには、システムテスト自動化においてテストスクリプトのメンテナンス性が大事であること、メンテナンス性を高めるためのデザインパターンや機能があること、を知っていなければなりません。 もちろん、スキルが必要だからといって、すぐに身につくものではありません。大切なのは、テスト自動化についての知見が無い状態で作った比較表の信頼度はそれほど高くない、と理解をすることです。必要であれば、中立的な立場のテストベンダーやコンサルタントなど、テスト自動化の専門家にツール選定のアドバイスをもらうことも検討してみましょう。 ツール選定の基本的な考え方と比較表の活用方法 ここまでに述べた注意点に気をつけながら、実際のツール選定はどのように行なえばよいでしょうか。 大きくは以下の流れで進めましょう。 必須条件を満たすツールをリストアップする 比較表を作成しながら、2, 3のツールに絞る トライアルを行う それぞれ詳しく見ていきます。 1. 必須条件を満たすツールをリストアップする 最初から比較表を作って比べようとすると、手間がかかることがあります。そこで、まずは 選定対象を選定 する、ところからスタートしましょう。 この段階における「必須条件」とは、以下を指します。 テスト対象の操作・確認にツールが対応しているか 例：ツールからDBへのアクセスができるか、Edgeが操作できるか、Flutter製のモバイルアプリが操作できるか、など 社内のルールに対応できるか 例：SaaS使用不可、LDAP連携必須、など 上記の条件は、テスト対象やチームによらず必ずチェックすべきポイントです。ツールの対応については、これが満たされなければそもそもテスト自動化はできないため、機能や使い勝手の比較を行う必要がありません。また社内ルールへの対応についても、初期段階で調べておくべき重要なポイントになります。会社によってセキュリティチェックシートやツール・サービス利用時の導入条件などが設定されている場合があるので、確認をしておきましょう。 2. 比較表を作成しながら、2, 3のツールに絞る ツール候補をリストアップできたら、次は実際に比較表を作成しながら最終的には2つか3つ程度のツールに絞っていきます。 ここでいきなり比較項目を挙げていくのではなく、まずはテスト自動化の目的・ゴールから考えていきましょう。 テスト自動化の目的やゴールはさまざまで、チームによって異なると思います。 E2Eテストの自動化を最速で成功させる秘訣 | Sqripts などを参考に、チームの中で話し合ってみてください。 目的が見えてきたら、次はその目的が達成された際の、開発・テストの流れを想像してみてください。そこではシステムテストの自動化が行われているはずですが、誰がどのタイミングで自動テストを実行しているでしょうか。開発者か、QAエンジニアか。それともCIツールから自動実行しているでしょうか。自動テストの結果は誰が確認をして、テストが失敗（NG/Fail）していた場合は誰が原因の調査をしているでしょうか。 あえて回りくどい言い方をしましたが、大事なポイントは テストを自動化して運用している姿をイメージしてみましょう ということです。 そして、ツール比較表で比較すべきは、 自動テストの運用に必要な要素 です。 自動テストを作って動かすのが開発者なのかテストエンジニアなのかによって、ツールに求める要件は異なります。前者の場合は、プログラムを書いて自動化するタイプのツールが良いかもしれませんし、後者の場合はノーコードで自動化できるツールのほうが良いかもしれません。 自動テストの結果をチームのSlackで確認する運用がしたい、という場合は、Slackとの連携機能やWebhook対応などが比較項目になるでしょう。 このように、単純にツール間の機能有無を比較して「なんでもできそうな（○がいっぱいついている）ほうが良い」といってツールを選ぶのではなく、自分たちがテストを自動化して日々運用するのに必要な機能を持っているツールを選ぶことが大切です。 この点を意識して、意味のある比較項目を出すことができれば、そのツール比較表は有効なものになるでしょう。 3. トライアルを行う 前の段階で、ツールはほぼ絞られると思います。最後に必ず行っていただきたいのが、トライアルです。有償のツールでも、OSSのような無料のツールでも、必ず使い比べたうえで検討を行いましょう。 トライアルで確認するべき点はツールを絞る際と同じで、想定通りに運用ができるかどうか、が主になります。ツールの仕様上「可能」となっていることが、テスト対象との相性などで難しい、ということも稀にあるため、注意しておきましょう。 まとめ：比較表だけで選定するのではなく、あくまでも材料としての活用を心がけよう 本記事では、テスト自動化ツールの選定時によく用いられるツール比較表について、注意すべき点と活用方法についてご説明しました。 一番お伝えしたかったポイントはツール選定の流れにおける2番め、テスト自動化とその運用のイメージをもとに比較項目を考えましょう、という点です。この順番を意識していただければ、テスト自動化ツールの選定で大きく失敗することは無くなります。 今回はテスト自動化ツール全般に関わる選定方法でしたが、次回はここ数年導入事例が増えてきている「AI自動テストツール選定時の考え方」についてご紹介します。 The post テスト自動化ツールの選定【前編】～ツールの比較表をどう活用するか first appeared on Sqripts .

こんにちは。名古屋グループのとりです。 昨年まではリモートワークにする日が多く、静かな環境で集中できるかと思いきや、安物の椅子で座り心地が悪かったり、移動する事が無いので運動不足がストレスになったりと、やっぱり職場の方が仕事に集中できるなと思う今日この頃です。 私はWebやアプリの入力フォームに対して探索的テストを行う時、開発現場に居た時の経験から何か悪さできないかなとプログラム上誤動作を起こしそうな入力を試す事が多いのですが、同様の手段でデータベースを意図的に不正操作する方法をSQLインジェクションと呼びます。 システムの脆弱性診断を行っている現場寄りの内容ですが、仕様の穴になりやすい内容で機能テストを実施する現場でも理解しておいて損はないと思いますので、紹介します。 セキュリティ領域は非機能要件になるため、機能テストではカバーされない事がありますが、探索的テスト等の観点の1つとして取り入れると機能要件側でもリスクヘッジができて良い内容だと思います。 SQLインジェクションとは SQLインジェクションの説明ですが、まず名称に入ってるSQLから軽く説明します。 SQLというのは、データベースに対して命令を投げる際の問い合わせ言語の事です。 アプリケーションやWebシステムのサーバで動くプログラム上からデータベースにアクセスし処理を行う場合、SQL言語で組まれた命令を投げて目的のデータを取り出したり、書き換えを行ないます。 SQL例 SELECT * FROM 顧客マスタ WHERE ID = '01234567';  UPDATE 顧客マスタ SET パスワード = 'abcdefgh' WHERE ID = '01234567'; 上記例は基本的な構文となりますが、1つ目が顧客マスタからIDが「01234567」に該当するデータを返させる内容で、2つ目が顧客マスタ上でIDが「01234567」に該当するデータに対して、パスワードの情報を「abcdefgh」に書き換える内容になります。 Webサービスなどでユーザーが自身情報を画面に表示して参照する時、そしてパスワード変更を行う時を想定すればイメージしやすいと思います。 さて、次にSQLインジェクションの説明です。 WHERE ID = '〇〇〇〇' の「〇〇〇〇」は、処理を行う上で対象となるデータを特定する条件となりますが、この値は入力フォームに入力した値を、プログラム上そのまま当てはめている場合があります。 では、例えばその入力値がこんな値だったらどうなるでしょう。 例１ ■入力値 01234567' OR 'A' = 'A ■SQL SELECT * FROM 顧客マスタ WHERE ID = '01234567' OR 'A' = 'A'; フォームに入力する値としてはとてもおかしな値ですが、入力値に「’」を含めることによって生成されるSQL文では前後にシングルクォーテーション「’」がついてSQLの構文として成り立ってしまいます。SQLの内容としては、IDが「01234567」であるまたは「A」が「A」である条件に該当するデータを全て返せになります。「A」が「A」である事って、当たり前で意味のない指定の様ですが、こうする事により常に条件が真となり顧客マスタ上のすべてのデータが返されてしまいます。 例２ ■入力値 01234567'; UPDATE 顧客マスタ SET パスワード = 'abcdefgh' WHERE ID = ‘01234567 ■SQL SELECT * FROM 顧客マスタ WHERE ID = '01234567'; UPDATE 顧客マスタ SET パスワード = 'abcdefgh' WHERE ID = '01234567'; 上記の例では終了記号「;」を入力値に含ませ、続けてDBを操作する構文を入れることによって自由にDBのデータ書き換えなどが出来てしまう可能性があります。 こういったSQLの命令を悪用して不正動作を発生させる手法をSQLインジェクションと呼びます。 （入力フォームなどでSQLの構文の一部を注入（インジェクション）するという意味です） 実際にこの仕組みが使われて顧客情報が漏洩したなどの過去の事例は多いです。 テスト実施時に考慮すべき点 では、SQLインジェクションを防ぐ為、テストの実施者として考慮する点を2点挙げます。 （開発観点では他にも色々ありますが、テストの実施観点として絞っています） 入力値のバリデーション処理は行なわれているか ここで言うバリデーション処理とは、フォーム上で入力された値が仕様に沿った形式（文字数、文字のタイプ、文字列の形式など）となっているかプログラム側で確認し、外れている場合はエラーとして返す処理の事です。 （バリデーションテスト／妥当性確認試験とは、また言葉として別物なので注意） SQLで使用される「’」といった記号は、SQLインジェクションの様な問題が発生しない様に入力フォーム上にて入力不可の文字として設計される事が多いです。機能テストとして、その設計内容通りに入力がエラーとなる事を確認する事はとても重要です。 特に検索キーとなるIDといった入力は、入力制限は多いと思います。 記号に対してエスケープ処理は行なわれているか 入力値としてSQL構文で特殊な意味を持つ「’」といった記号を許可していても、エスケープ処理を施していれば問題ありません。エスケープ処理とは、エスケープ文字を組み合わせる事によってプログラム構文上で使われる記号であっても、文字データとして扱われる処理の事です。 エスケープ文字は使用されているDBシステムによって違い、例えばMySQLであれば「\」がエスケープ文字になります。 SQL例 UPDATE 顧客マスタ SET 備考 = ' 使用端末 'iPhone 14' ' WHERE ID = '01234567'; という様な「iPhone 14」を「’」で囲んだ情報で更新したい場合、このままでは「iPhone 14」が「’」の囲みから外れてSQL構文の一部と見做され構文エラーとなってしまいますが、 UPDATE 顧客マスタ SET 備考 = ' 使用端末 \'iPhone 14\' ' WHERE ID = '01234567'; 上記の様に「iPhone 14」前後の「’」の前に「\」を付けることによって、「 使用端末 ‘iPhone 14’ 」という文字列データとして扱われ更新されます。 エスケープ処理が施されていれば、「’」の様な記号が悪さしてSQLインジェクションに繋がる事はありません。ただこのあたりの確認はブラックボックステストにおいては入力を試して挙動を確認するしかないので、探索的テストでこういった構文を想像しながら怪しい入力を試してみると良いと思います。 私の経験則では、この辺りの対策がされているシステムは、設計時点からしっかりされてそもそも入力ではじかれます。1画面ピックアップして対策されていないシステムは、どの画面もされていない事が多いので探索的にどこか主要の1画面を確認するだけでも十分効果はあるんじゃないかと思います。 最後に 学生の頃はコミュニティサイト内のチャットでの発言にHTMLタグを組み込んでみたり、相手のCDROMドライブが勝手に開くみたいな悪戯を仕込んだりといった事が流行った記憶がありますが、昔はユーザーの入力に対して本当にどのWebサイトも無警戒だったと思います。 今回の様なSQLインジェクションに関わるような入力を探索的テストで確認していた時も、それでとんでもない挙動を起こさないかと半ば好奇心で試していましたが、情報漏洩やデータ改ざんに繋がるって怖いなと改めて思いました。 ただ、テストを行う上で好奇心を持つことは大事で、普段何気なくテストで確認している入力制限文字の確認なども、システム中のプログラムの仕組みを知るとなぜこういう仕様になっているのか？と理解が進み楽しくなるんじゃないでしょうか。 本記事を読んで頂き、少しでもテスト観点の幅が広がれば幸いです。ではまた。 The post テスト実施で知っておきたいSQLインジェクション first appeared on Sqripts .

PMとPMOの違い PMとPMOは、プロジェクトマネジメントにおいて異なる役割を担います。PMは「プロジェクトマネージャ（Project Manager）」の略で、プロジェクトの計画・管理・運営に関する責任者です。一方、PMOは「プロジェクトマネジメントオフィス（Project Management Office）」の略で、PMによるプロジェクトマネジメントを支援するポジションを担います。PMがプロジェクトの具体的な運営を担当するのに対し、PMOはプロジェクト管理に専念します。 [Tips]PMとPMOとコンサルタントは何が違う？ コンサルタントも、PMやPMOに似ているイメージですが、どこが違うのでしょうか。コンサルタントは、組織や企業に対して、ビジネス戦略やプロセスの改善、コスト削減などのアドバイスや支援を提供します。その中には、PMに関するコンサルティングや、PMOの設計や構築、PMの育成やPMプロセスの改善などが含まれます。 PM、PMO、コンサルタントは、それぞれ異なる役割を担いますが、プロジェクトマネジメントに関する知識やノウハウを共有することで、組織や企業のプロジェクトの成功に貢献できるのです。 PMの役割、業務、必要なスキル PMの役割、業務、必要なスキルについて詳しく解説します。 PMの役割 PMの主な役割には以下のようなものがあります。 プロジェクトの計画と立ち上げ プロジェクトの目的やスコープ、タイムライン、予算などの計画を策定し、スタッフを選定してプロジェクトを開始する。 スケジュール管理 プロジェクトのスケジュールを策定し、進捗を監視して調整し、遅れが生じた場合はスケジュールの変更や再調整を行う。 リスク管理 プロジェクトのリスクを特定し、それらに対処するための計画を策定する。また、リスクの発生に備えて対策を講じる。 コミュニケーション ステークホルダーとのコミュニケーションを円滑に行うことで、プロジェクトを成功に導く。 資源管理 プロジェクトに必要な人員、設備、財源などの資源を適切に割り当てて管理する。 品質管理 プロジェクトの成果物が品質基準を満たしているかどうかを監視し、必要に応じて改善を行う。 問題解決 プロジェクトの進行上の問題を特定し、解決するための方法を提供する。 PMの役割は、プロジェクトの成功に直接影響するため、多くの企業で重要視されています。 PMの業務 PMの主な業務には以下のようなものがあります。 プロジェクト計画 プロジェクト目標、スコープ、タイムライン、予算、リスク管理などを策定します。これには、必要なリソースを特定し、プロジェクトチームを構築することも含まれます。 プロジェクト実行 プロジェクトチームを指導し、計画に基づいてプロジェクトを実行します。これには、タスクの割り当て、進捗の監視、品質管理、コミュニケーションなどが含まれます。 プロジェクト監視 進捗状況を監視し、スケジュールや予算の変更、品質管理の改善などが必要かどうかを判断します。 プロジェクト制御 問題が発生した場合は、適切な対応を講じます。これには、予算、スケジュール、品質、リスク管理などを調整することが含まれます。 ステークホルダー管理 プロジェクトに関係するステークホルダーとのコミュニケーションを円滑に行い、プロジェクトがステークホルダーの期待に応えることができるようにします。 プロジェクト報告書作成 プロジェクトの進捗状況や成果物をステークホルダーに報告するための報告書を作成します。 これらの業務は、プロジェクトの成功に不可欠です。PMは、これらの業務を適切に遂行することで、プロジェクトを成功に導きます。 PMに必要なスキル PMには多くのスキルが必要です。以下に挙げるのは一般的に重要視されるスキルです。 リーダーシップスキル プロジェクトチームを率い、目標に向けて指導できる能力。 コミュニケーションスキル ステークホルダーとのコミュニケーションを円滑に行うことができる能力。 問題解決スキル 問題を特定し、解決するための方法を提供する能力。 プロジェクトマネジメントスキル スケジュールや予算の管理、品質管理、リスク管理などのプロジェクトマネジメント技術を使いこなす能力。 技術スキル プロジェクトに必要な技術を理解し、プロジェクトチームと協力してプロジェクトの成功に導く能力。 ビジネススキル プロジェクトの目的と企業のビジネス目標を理解し、プロジェクトがビジネス上の目標を達成するために必要な計画を策定する能力。 チームビルディングスキル プロジェクトチームを結束させ、チームメンバーのモチベーションを維持するための能力。 プレゼンテーションスキル プロジェクトの成果物や報告書をステークホルダーに説明し、プレゼンテーションスキルを持つことが重要です。 これらのスキルを持ったPMは、プロジェクトの成功に貢献するでしょう。 PMOの役割、業務、必要なスキル 続いて、PMOの役割、業務、必要なスキルについて詳しく解説します。 PMOの役割 PMOの主な役割には以下のようなものがあります。 プロジェクトマネジメントの標準化 PMOは、プロジェクトマネジメントの手法やツール、文書の作成方法などを標準化することにより、プロジェクト管理の品質を向上させます。 プロジェクトポートフォリオの管理 PMOは、企業が抱えるプロジェクトの全体像を把握し、プロジェクトポートフォリオとして管理することにより、プロジェクトの優先順位付けや予算配分などを行います。 プロジェクトの進捗管理 PMOは、プロジェクトの進捗状況を把握し、問題や課題を早期に発見し、解決することにより、プロジェクトのリスク管理を行います。 プロジェクトマネジャーの支援 PMOは、プロジェクトマネジャーに対して、プロジェクトの遂行に必要なツールや情報を提供することにより、プロジェクトマネジャーの業務を支援します。 企業によっては、より多くの役割を担っている場合もあります。 PMOの業務 PMOの主な業務には以下のようなものがあります。 プロジェクト管理のフレームワークやプロセスの策定・改善 PMOは、プロジェクトの進捗管理や品質管理などのフレームワークを策定し、プロセスの改善に取り組んでいます。また、プロジェクトマネジャーの指導や支援も行います。 プロジェクトの進捗管理・報告 PMOは、プロジェクトの進捗状況を管理し、定期的に報告書を作成して上層部やスポンサーに提出します。進捗状況に基づいて、プロジェクトのリスク分析や問題解決に取り組みます。 リソース管理 PMOは、プロジェクトに必要なリソース（人材、予算、設備など）の管理を行います。また、必要なリソースを供給するために、組織内の他部署や外部パートナーとの連携を図ります。 コミュニケーション管理 PMOは、プロジェクトに関わるステークホルダーとのコミュニケーションを担当します。プロジェクトに関する情報の共有や調整、または関連する問題の解決など、コミュニケーションに関するあらゆる業務を行います。 プロジェクトの成功に向けて、多岐に渡る業務を担当しています。 PMOに必要なスキル PMOに必要な主なスキルには以下のようなものがあります。 プロジェクト管理に関する知識と経験 PMOは、プロジェクトの計画、実行、監視、制御、クロージングなどのフェーズで活動するため、プロジェクト管理に関する知識と経験が必要です。例えば、プロジェクト管理のフレームワークやツール、プロジェクト計画や進捗管理、リスク管理などについて理解している必要があります。 コミュニケーションスキル PMOは、プロジェクトに関わるステークホルダーとのコミュニケーションを担当するため、優れたコミュニケーションスキルが必要です。これには、報告書の作成やプレゼンテーション能力、問題解決能力、関係構築能力、交渉力などが含まれます。 リーダーシップスキル PMOは、プロジェクトチームや関係者を統率し、プロジェクト目標の達成を支援するリーダーシップスキルが必要です。これには、チームの指導や指示、モチベーション管理、問題解決能力、優先順位の設定などが含まれます。 データ分析スキル PMOは、プロジェクトの進捗状況やリスクに関するデータを収集・分析し、適切な意思決定をする必要があります。そのため、データ分析スキルやエクセルやプロジェクト管理ツールの利用スキルが必要です。 プロジェクト全体のビジョンを把握する能力 PMOは、プロジェクト全体のビジョンや戦略を把握し、プロジェクトの目標に沿ったサポートをする必要があります。プロジェクトに関する知識を深めることで、プロジェクト全体のビジョンを理解する能力が必要です。 ただし、業務内容によって必要なスキルが異なるため、詳細な業務内容に応じて必要なスキルを身につける必要があります。 PMOを導入するメリットと注意事項 PMOを導入するメリットと注意事項について解説します。 PMOを導入するメリット PMOを導入することによって、以下のようなメリットが得られる可能性があります。 プロジェクト管理の統一化 プロジェクトの進捗管理や品質管理など、プロジェクト管理の方針や手順を統一化できます。 プロジェクト管理の改善 PMOはプロジェクト管理のベストプラクティスを提供することができ、これを各プロジェクトに適用できます。これにより、プロジェクトの効率性や成果品質が向上します。 リスク管理の強化 PMOは組織全体でリスク管理を行うことができ、リスクの早期発見や回避が可能です。 組織の透明性の向上 PMOによってプロジェクトの進捗状況や成果物の可視化ができるため、組織の透明性が向上し、組織全体でのコミュニケーションの改善につながります。 PMO導入のメリットとして、システムの進捗を徹底的に管理できることが挙げられます。小規模プロジェクトではPMが全ての業務を管理できますが、人数が増えると状況把握や書類の質などの問題が出てきます。PMOを導入することで、肥大化したマネジメント業務に対応できるのです。 また、PMOはプロジェクトマネジメントの強化につながり、開発チーム全体の連携を高めることができます。複数のプロジェクトが並行して動いている規模の企業では、PMO部門を社内に持つことで全プロジェクトの状況を把握できます。PMOスキルを持つメンバーがいない場合は、外部のPMOに入ってもらったり、コンサルタントと連携したり、社外の戦力を検討すると良いでしょう。技術の複雑化や働き方の多様化により、協力会社やフリーランスなどの人員管理の手間も増えていますが、PMOの導入によってこれらの課題にも対応できます。 PMOを導入する際の注意事項 併せて、PMOを導入する際には、以下のような事項に注意する必要があります。 コスト PMOの設置や運営には費用がかかります。組織にとってその負担が大きい場合があります。 組織への影響 PMOは組織全体に影響を与えることがあります。組織文化やプロジェクトマネジメントの方針に合わない場合、導入が困難である可能性があります。 プロジェクトマネージャーの負担増 PMOの導入によって、プロジェクトマネージャーの負担が増加することがあります。PMOからのレポーティングやプロセスの遵守、文書の作成などが増えるため、プロジェクトマネージャーの時間やリソースが削られる可能性があります。 PMOを導入する場合には、進捗管理に重きを置きすぎて、コミュニケーション不全や他部署への無関心を引き起こすことがあります。PMOは各部署の中継役として、プロジェクト全体の成功を目指すために機能する必要がありますが、進捗管理に過度に力を注ぎ、現場の粗探しに走ることで各部署が保身に走り、プロジェクトの炎上につながるかもしれません。 PMOは、進捗管理と同様に、各部署との円滑なコミュニケーションを築くことが必要です。機械的にプロジェクトを管理するだけではなく、メンバーと人間関係を構築し、チーム全体の能力を向上させることが重要です。PMOは、各部署の調整役として、高いコミュニケーション能力が必要な部門であることを覚えておきましょう。 PMOの導入を検討 PMOを導入するかどうかは、組織の状況やニーズによって異なります。以下は、PMOを導入する方が適切な場合と、導入しない方が適切な場合の例です。 PMOを導入する方が適切なケース 組織内に複数のプロジェクトがあり、それらの管理が分散している場合。 プロジェクト管理に関するノウハウやベストプラクティスが統一されておらず、プロジェクト成功率が低い場合。 リスク管理や品質管理など、プロジェクト管理における課題がある場合。 組織内に複数の部門があり、それらの間でプロジェクトが進行している場合。 組織が急速に成長しており、プロジェクトマネジメントをより効果的に行いたい場合。 大規模プロジェクトの開発において、PMOの導入は強く推奨されます。プロジェクト規模が大きく、複数の部署が関わる場合、PMOはプロジェクト全体を統括する役割を果たし、進捗管理やプロジェクトマネジメントを行います。PMOによって、プロジェクトの目標を達成するために必要な情報の収集、共有、報告、分析などが行われ、組織全体でのプロジェクトの進捗状況や課題が把握できます。また、PMOはリスクマネジメントや品質管理などにも貢献し、プロジェクトの成功に不可欠な役割を果たします。 PMOを導入しない方が適切なケース 組織が小規模で、プロジェクト数が少なく、プロジェクトマネジメントの管理が容易である場合。 組織内のプロジェクトが単純で、プロジェクト管理の手順が明確である場合。 組織内の文化やプロセスがPMOに適さない場合。 PMOの導入に伴い、組織に対する費用や時間の負担が大きくなる場合。 小規模なプロジェクトや部門の場合、PMOを導入する必要性は低いと言えます。PMOを導入することによって、プロジェクトの進捗状況や課題を共有することが難しくなり、コミュニケーションのコストがかかる可能性があります。また、PMOに必要なリソースや費用がかかるため、コストパフォーマンスが低くなるでしょう。 一方、小規模プロジェクトでは、プロジェクトのリーダーが中心となって進捗管理や課題解決を行うことができ、柔軟な対応が可能です。そのため、PMOを導入することが適切であるかどうかは、プロジェクトの規模や目的に応じて慎重に判断する必要があります。 PM、PMO関連の資格 代表的なPM、PMOの資格には、以下の3つがあります。 PMP プロジェクトマネージャ試験 NPMO認定資格 1. PMP（Project Management Professional） PMPは、米国プロジェクトマネジメント協会（PMI）が認定するプロジェクトマネジメントの資格です。PMP認定者は、PMに関する幅広い知識、スキル、経験を持ち、プロジェクトを成功に導くためのベストプラクティスを熟知しています。 PMP認定には、PMP試験に合格することが必要であり、PMP試験はPMの5つのプロセスグループと10の知識領域に関する問題が出題されます。PMP認定者は、PMだけでなく、プロジェクトチームメンバーやステークホルダーとしても重要な役割を果たします。 PMPは、世界的に認められたPMのスタンダードとなっており、PMP認定者の需要は高く、キャリアアップにもつながることが期待されます。 2. プロジェクトマネージャ試験 プロジェクトマネージャ試験は、一般財団法人日本能率協会が実施するプロジェクトマネジメントの資格です。PMIが提供するPMPに比べて、日本国内での認知度は低いですが、日本企業においては、この試験を求める求人も多くあります。プロジェクトマネージャ試験は、プロジェクトマネジメントの知識やスキル、実践経験を証明するものであり、合格者は、PMとしての資格を取得することができます。 試験は、プロジェクトマネジメントの基本的な知識や技能に加えて、プロジェクト計画、プロジェクト推進、プロジェクトコントロール、リスクマネジメント、チームマネジメント、コミュニケーションマネジメントなどのスキルや知識が問われます。プロジェクトマネージャ試験の合格者は、プロジェクトマネジメントにおいて、日本企業におけるキャリアアップの可能性を高めることができます。 3. NPMO認定資格 PMOに関する資格として、日本PMO協会が認定する「NPMO認定資格」が存在します。NPMO認定資格には、プロジェクトマネジメント・アソシエイト（PJM-A）、PMOスペシャリスト（PMO-S）、PMOスペシャリスト（PMO-S）の3つの総合的な資格があります。 プロジェクトマネジメント・アソシエイト（PJM-A） PJM-Aは、プロジェクトマネジメントに関する基礎的な知識や技能を証明する資格です。NPMO認定資格の最初のステップとして位置づけられています。PJM-Aの取得には、PMOの概要、プロジェクトマネジメントの基本的な知識、プロジェクトの計画や実行、チームマネジメント、コミュニケーションマネジメントなど、幅広い領域の知識が必要です。 PMOスペシャリスト(★)【PMO-S(★)】 PMO-S(★)は、PMO運営に関する知識や技能を証明する資格です。PMOの立ち上げや改善に関するプロジェクトマネジメント、戦略的なプロジェクト選択やプロジェクトポートフォリオマネジメント、PMO運営に必要なマネジメントスキルやコミュニケーションスキルなどが問われます。PMOの運営に必要な基礎的な知識を身につけたPJM-Aの取得が前提となります。 PMOスペシャリスト(★★)【PMO-S(★★)】 PMO-S(★★)は、PMOのプロセス改善や戦略的なPMO運営に関する高度な知識や技能を証明する資格です。PMO-S(★)の取得が前提となり、PMOの戦略的位置づけやビジネス価値、PMOの運営における課題解決や改善、PMO運営における成果や評価、PMOのグローバル展開など、より高度な知識やスキルが問われます。PMOのプロフェッショナルとしての知識とスキルを証明することができます。 まとめ PMOは、プロジェクトを円滑かつ迅速に進めるためのスキルを備えています。業界や組織にかかわらず、その能力を最大限に発揮するでしょう。PMやPMOの資格を取得することで、自分自身が大規模なプロジェクトに適した人材であることがアピールできます。知識の習得だけでなく、資格取得もスキルアップの一つとして検討することが重要です。大規模なプロジェクトでは、リソースを最大限に活用して万全を期したいものです。「プロジェクトの進捗が遅れている」「次のプロジェクトは確実に進めたい」といった場合には、PMOを活用してみることを検討してみましょう。 　 PM PMO 役割 プロジェクトの計画と立ち上げ スケジュール管理 リスク管理コミュニケーション 資源管理 品質管理 問題解決 プロジェクトマネジメントの標準化 プロジェクトポートフォリオの管理 プロジェクトの進捗管理 プロジェクトマネジャーの支援 業務 プロジェクト計画 プロジェクト実行 プロジェクト監視 プロジェクト制御 ステークホルダー管理 プロジェクト報告書作成 プロジェクト管理のフレームワークやプロセスの策定・改善 プロジェクトの進捗管理・報告 リソース管理 コミュニケーション管理 必要なスキル リーダーシップスキル コミュニケーションスキル 問題解決スキル プロジェクトマネジメントスキル 技術スキル ビジネススキル チームビルディングスキル プレゼンテーションスキル プロジェクト管理に関する知識と経験 コミュニケーションスキル リーダーシップスキル データ分析スキル プロジェクト全体のビジョンを把握する能力 ＜PMとPMOの役割、業務、必要なスキル＞ The post PMOとは？PMとの役割や業務の違いについて解説 first appeared on Sqripts .

第六回の連載では湯本が確立したテスト手法である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を作るにあたり初めに考えたのがページ管理です。 直前に行なっていたプロジェクトで、何も考えず子ページ孫ページをスペースに追加する運用を行なった結果、プ…