こんにちは、見習いフロントエンドエンジニアのぱやぴです。 新卒として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を作るにあたり初めに考えたのがページ管理です。 直前に行なっていたプロジェクトで、何も考えず子ページ孫ページをスペースに追加する運用を行なった結果、プ…

こんにちは。エンジニアの 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. 自動運転のテストについて さいごに はじめに みなさんは自動運転の車やロボットって見たことありますか？近年では様々な会社が開発を行っており見かける頻度も増えてきたかと思いますが、課題などが多くありまだまだ一般的にはなっていないかと私は思っています。なので先に自動運転に関する説明をします。 簡単に説明…