この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。 第13回目のテーマは、「かんばん」です。 この内容はUdemyで公開しているオンラインコース「 現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム 入門編 」の内容を元にしています。 かんばんの誕生 かんばんは、イギリス人のデイヴィッドさんが考え出した開発手法です。 かんばんはその名の通り日本語が元になった開発手法です。もともとはトヨタ生産方式で使われているかんばんがベースなのですが、トヨタのかんばんとこのかんばんは、思想は似ていてもまったく異なる手段です。 かんばんは、開発手法としてのかんばんと、ツールとしてのかんばんがあります。開発手法のかんばんは、XPやスクラムのようなもので、原則が手順書のようになっているのではじめやすく、誰にでも理解しやすくなっています。 ツールとしてのかんばんは、タスクをふせんではりつけたタスクボードをさしています。厳密に言うとタスクボードとかんばんはちょっと違うのですが、このあたりも後ほど解説します。 かんばんに関しては、自分が翻訳した書籍『 リーン開発の現場 』をベースに解説します。また、翻訳の際に、 かんばんの英語版Wikipediaページ も日本語に翻訳しました。こちらもかんばんの理解にとても役立つ内容なので、おりまぜて解説します。 かんばんの基本原則 まず、かんばんの基本原則を解説します。 解説と言っても、原則自体が文章になっているので、これまでの開発手法とちがってとてもわかりやすい内容になっています。 原則： 現在、何をしているかを理解することから始める ひとつめは「現在、何をしているかを理解することから始める」です。 まずは、現状、どういう流れで開発が行われているかを考えます。リーン思考で登場したバリューストリーム（価値の流れ）を意識します。かんばんではこれをワークフローと呼んだりします。 塹壕より、かんばんとリーン より たとえば、大抵の開発現場では、要件を聞く ＞ 設計する ＞ 開発する ＞ テストする ＞ リリースする・・・といったワークフローになっているはずです。こういったバリューストリームを構成する要素をホワイトボードなどに書き出していくとよいでしょう。 そして、洗い出したワークフローをかんばんに反映していきます。 かんばん Wikipedia より この写真は、実際に私が使っていたかんばんです。マスキングテープによって、タテのレーンにわかれていますが、それぞれのレーンが、要件をきく ＞ 設計する・・・といった構成要素をあらわしています。そこに仕事を表す付箋を貼ることで、仕事がどういう状態なのか、かんばんだとひとめでわかるようになります。 原則： インクリメンタルに進化させ、変化を追求していく 2つ目は「インクリメンタルに進化させ変化を追求していく」です。 シンプルなかんばん。タスクボードと呼ばれたりもする。 さきほど登場したかんばんは、様々な進化を遂げて写真のような形になりました。もともとのかんばんは、上記のようなシンプルなかんばんでした。このかんばんは、TODO、DOING、DONEといったタスクの状態を可視化したものです。おそらく、さまざまな現場でも使われているフォーマットだと思います。 しかし、開発を進めていく上で、この方法ではわかりにくい部分が出てきたので、インクリメンタルに進化させ、変化を追求していきました。 たとえば、Doingひとつをとっても、開発がDoingもあれば、テストがDoingもあります。開発をすすめる上で、この違いがわかりにくくなったのであれば、開発DoingやテストDoingを追加するとよいでしょう。 このように進化を続けた結果、たくさんのレーンのあるかんばんになりました。 これをはじめて見たひとはよく「複雑でわかりにくそう」と感じるみたいですが、開発チームにとって見れば、自分たちの仕事の流れと状況がひと目で分かる仕組みになっています。Wikiにすらまとめる必要はありません。よって、新しいメンバーがはいったときでも、このかんばんを使い、ひととおりタスクを流してもらうだけで、開発の流れの全体像を理解できるようになります。 原則： 現状のプロセス、役割、責務、職位を尊重する 3つ目は「現状のプロセス、役割、責務、職位を尊重する」です。 現状、さまざまなプロセス、役割や責務があるはずです。とくに役割を見てみると、現状の役割分担では、アジャイル開発がうまく進まないケースもありえます。よくあるのが「これは誰が担当するのか？」の議論です。縦割りの工程に慣れているひとにとっては、職能横断型のやりかたは急にはなじめないものです。 かんばんでは、まずは現状を尊重し、そこから少しずつ変化をうながしていきます。 原則： すべての地位でのリーダーシップを求める 最後は「すべての地位でのリーダーシップを求める」です。 いうまでもなく、リーダーシップは重要です。これはチームだけでなく、マネジメント層や経営層まで、はばひろく求められる要素です。 チーム開発ですから「誰かがやってくれる」ではなく、「自分たちがやる」という気持ちを持つのが重要です。 コアプラクティス： 可視化する 最後にかんばんのコアプラクティスを紹介します。コアプラクティスも、やることが順番になっているので、わかりやすいのがかんばんのいいところです。ひとつずつ見ていきましょう。 ひとつめは「可視化する」です。原則にもありましたが、ワークフローを中心に可視化し、改善していきます。かんばんのいいところは、見える化に特化したツールなのでわかりやすい点です。 コアプラクティス： WIPを制限する 2つ目は「WIPを制限する」です。 これは、かんばんの特徴的なプラクティスです。WIPは（ウィップ： Work in progress）という意味です。日本語に訳すとすれば、進行中、処理中という意味になります。かんばんでは、同時進行の仕事の個数を制限します。これがWIP制限です。 たとえば、開発中というステータスのWIPを5に設定した場合、チームメンバーは5つの仕事だけを開発中にできます。これがWIP5の意味です。5つが開発中であれば、どれかが次に進まない限り、次の仕事を開発中にはもってこれません。 5人のチームだった場合、WIP5だとすると「ひとりひとつの仕事を担当する」という意味になります。もし、だれかが仕事を終えた場合、開発中の数がひとつへります。そうすると、新しくもうひと仕事を開発中に移動できます。 せっかく同時進行で進められるのに、やれる仕事の数に制限するのは不思議に思うかもしれません。ただ、ひとりで作業することが、効率が良いとは限らない場合もあります。たとえば、誰かに相談したくても、まわりもひとり一つの仕事に集中しています。もし話しかけるならば、誰かの仕事を止めることになります。 かんばんでは、WIP制限によって、流れる仕事の数を調整し、全体最適を考えていきます。このあたりはリーン思考に近い考え方です。 コアプラクティス： 流れを管理する 3つ目は「流れを管理する」です。 WIPで仕事の量をコントロールできたら、その状況を見極めます。たとえば、リリース待ちのエリアにたくさんの仕事が貼り付けてある場合、リリースがボトルネックになっている可能性があります。開発中のWIPを減らすなどして、リリースに仕事がたまらないようにするのもいいかもしれません。 かんばんを活用すれば、どこがどういう状況か？ 開発の流れがよくわかるようになります。 コアプラクティス： 明確なポリシーを作る 4つ目は「明確なポリシーを作る」です。 アジャイル開発でよく言われる「完了の定義」を決めます。たとえば、開発完了という状態がある場合、その状態になるためには何をクリアしなければならないのかを決めます。これを決めることで、チームメンバーはまよいなく仕事の状態を選択できるようになりますし、どうすれば終わるのかが明確になります。 たとえば、開発完了にテストも含めるのであれば、開発は終わったけどテストが終わっていない・・・といった状態に気がつけます。気がつけると、終わらせるための対策も打てます。 連載一覧 第1回：アジャイル開発の過去、現在、未来を知ろう！ 第2回：声に出して読みたいアジャイルマニフェスト 第3回：従来型開発とアジャイル開発の違い　その１ 第4回：従来型開発とアジャイル開発の違い　その２ 第5回：アジャイル開発のよくある誤解を解いていこう！ 第6回：世界中で大人気の秘密に迫る！スクラムを使ったソフトウェア開発 第7回：わかるようでわかりにくいスクラムチームの責任 第8回：スクラムイベントの実践方法 第9回：エクストリーム・プログラミングとその価値 第10回：エクストリーム・プログラミングの原則と基礎プラクティス 第11回：エクストリーム・プログラミングの応用プラクティス 第12回：リーンソフトウェア開発 第13回：ソフトウェア開発における「かんばん」 The post 第13回 ソフトウェア開発における「かんばん」 first appeared on Sqripts .

こんにちは。小学２年生と年中の子を持つワーママ、ちーちゃんです。 育児の一番大変な時期は多分越えた？とは思いますが、まだまだ自分の時間は持てない中で最低限の勉強をしてAWS認定 クラウドプラクティショナーを受験＆合格しましたのでAWSについて、受験のことや試験について報告します！ AWSの概要 AWSとは AWSとは何か？公式Webサイトには以下のように説明されています。 Amazon Web Services (AWS) とは、世界で最も包括的で、幅広く採用されているクラウドコンピューティングサービスです。クラウドサービスを利用すると、インターネット経由でコンピューティング、データベース、ストレージ、アプリケーションをはじめとした、さまざまな IT リソースをオンデマンドで利用することができます。AWSでは、そういった 200 を超えるフル機能のサービスを世界中のデータセンターから提供しています。 AWS公式Webサイト「AWSとは？」 AWSが人気の理由 クラウドインフラ市場シェアは以下です。 1位：AWS　32% 2位：Azure　23% 3位：GCP　9% Canalys「Worldwide cloud infrastructure services expenditure grew 23% in 2023」 AWSはCIPS市場において、どのプロバイダーよりも幅広く高度な能力を発揮し続けている。AWSは、競合クラウドプロバイダーがそのまま模倣することも少なくない標準の設定、技術の開発、および手法の確立を通じて、市場全体の指導的な役割を担ってきた。 さらに、AWSは、合理的に見てクラウドに該当すると考えられるものの範囲から大きく逸脱したサービスの販売を基に顧客に対して業績を誇張することのない、この市場における数少ないベンダーの1つである。 gartnerのクラウド・インフラストラクチャ／プラットフォーム・サービスのマジック・クアドラント の分析ページより AWSは長らくシェア1位をキープしています。 AWSはクラウドサービスの先駆者であることだけではありません。上記のように指導的役割を果たしたり、技術を上げノウハウを蓄積したこと、また歴史も長いことから、ネットに情報が多いことも利用しやすい理由だと思います。 それだけでなく、AWSはよくユーザーファーストといわれます。クラウドから逸脱したサービスを行ったり、利益を得た分を還元するシステムで何十回も値下げをしています。先頭に立って他にはないサービスを提供しながらコスト面でもユーザーの期待に応えていたことがAWSが人気になった理由だと思います。（参考： 「AWSのクラウドが選ばれる10の理由」 ） 3大クラウドサービスの特徴 今度は先ほどのシェア率の図を見てみましょう。1位のAWS、2位のAzure、3位のGCPだけでシェアの60%以上を占めています。 これらは以下の特徴があります。 AWS セキュリティ AWSでは、セキュリティが最優先事項です。 AWSは、アプリケーションとワークロードを構築、移行、管理するための最も安全なグローバルクラウドインフラストラクチャとして設計されています。これは、300種類以上のクラウドセキュリティツールの豊富なセットと、政府、医療、金融サービスなどのセキュリティに最も敏感な組織を含む数百万のお客様からの信頼によって裏付けられています。（ 「AWSクラウドセキュリティ」 より） サービス数 （ 「AWSのクラウドが選ばれる10の理由」 より） 200以上のサービスを提供 リージョン、国と地域 (「 AWSグロ－バルインフラストラクチャ 」より) リージョン数： 32 利用できる国と地域：245 AWS グローバルインフラストラクチャマップ より Azure セキュリティ クラウドの保護に役立つサイバーセキュリティ関連のインテリジェンスが全世界からリアルタイムで供給されるので、新しい脅威を検出し、迅速に対応することができます。このような実用的な分析情報は、180 億件の Bing Web ページ、4,000 億件のメール、10 億件の Windows デバイスの更新、毎月 4,500 億件の認証など、幅広いソースを分析することによって得られます。Microsoft のデータ サイエンティストは機械学習、行動分析、アプリケーションベースのインテリジェンスを駆使して、Microsoft インテリジェント セキュリティ グラフにある大量のデータを分析しています。このようにして得られた分析情報が Azure のサービスに供給され、脅威の迅速な発見に役立てられているのです。（ 「Azureでセキュリティ体制を強化」 より） サービス数 200以上のサービスを提供 リージョン、国と地域 （「 Azure の施設、建物、および物理上のセキュリティ 」より） リージョン数： 60 以上 利用できる国と地域：140 GCP セキュリティ Google と同じ安全性を重視した設計のインフラストラクチャ、組み込みの保護機能、グローバル ネットワークを使用して、お客様の情報、ID、アプリケーション、デバイスを保護します。 Google の施設間で転送中または保存中のデータを暗号化し、暗号鍵への監査済みアクセス権が承認されているロールとサービスのみがアクセスできるようにしています。（「 Google Cloudトラストセンター 」より引用） サービス数 ※サービス数の具体的な数値は見つけられなかったがGCPがAWS,Azureとのサービスの比較表を提示しています。それを見るとサービス量に大きな差はないのではないかと思いました。（参考：「 AWS や Azure サービスと Google Cloud を比較する 」） リージョン、国と地域 （「 Cloudのロケーション 」より） リージョン数：39 利用できる国と地域：200以上 3大クラウドサービスすべてに言えること セキュリティについては公式の文面で優劣は私だとつけられないですが、自分たちが持てる最大のセキュリティで情報を守っているのだと分かりました。 リージョンや利用できる国、地域については数で多少差はありますが、日本は当然のことながら世界中で利用できることが分かりました。 サービス数においても、どのクラウドサービスも、利用する企業の希望に応えることのできる量のサービスを提供していると感じました。 AWS認定 クラウドプラクティショナー試験 2023/08にAWS認定クラウドプラクティショナー試験を受験しました！ 資格取得しようとした理由 AWS認定 クラウドプラクティショナーの資格取得しようと思ったきっかけは、以前お客様先でAWSを使用していたことを思い出して、AWSは様々な業種で使用しているので、この知識を多く知っておくことは有意義だと思ったからです。 この資格は広く浅くAWSやクラウドのサービスを知ることができる資格なので直接〇〇に役立つよ！！というものは多くはないです。しかし、AWSやクラウドのサービスを知ることでお客様先で利用しているときなどに役に立ったり、どの業界でもクラウドサービスを利用しているので自分自身を一段成長させたいと思った時、このシステムを把握すること自体意味があることだと感じました。 ここから次のレベル以降は直接的なAWS構築の業務に携わったり、さらには世界に通用する国際資格なので高みを目指すためのベースとなる資格です。そのため資格取得を目指して勉強することは意味があることだと思い資格を取得しました。 試験の概要 4択問題か、5択で2個選ぶ形式で出題 試験時間：90分 問題数：65問 （ 「AWS Certified Cloud Practitioner」 より引用） 合格ライン：非公開（7割正解で合格？難易度で前後するらしいとの噂も・・・） ピアソンVUEでの受験 受験の申し込みとamazonの公式勉強「Amazon Skill Builder」のアカウント取得までが英語だらけで、英語が苦手な私にはちょっと大変でした。。。 必要なアカウント 受験申込：Amazonアカウント 無料の勉強システム：Amazon Skill Builderアカウント Amazonアカウントは持っているものでも良いらしいですが私は試験用に新規作成しました。 またサブスクで追加の勉強もあるみたいでしたが今回は無料の範囲で挑戦することにしました。（勉強のサブスクがあることに驚きました！サブスクで収益を得る時代なのかなと思いました。） 申し込みの際に英語の難関さえ越えれば、受験勉強用に公式の無料勉強教材「Amazon Skill Builder」があることや、受験結果がすぐ出るなど受験しやすいと感じる試験でした。 試験の特徴 資格の有効期限がある →AWSの試験全てにおいて３年の有効期限がある。最初は驚きましたが、世の中の変化に合わせて知っておくべきサービスが変わるので個人的には納得しました。 ピアソンVUE試験会場（沢山ある）、または自宅で受験できる →自宅だとネットワークなどのトラブルが怖いので会場受験を選択しました。 ピアソンVUEの受験をしたことがある人はご存じの通り試験会場はカンニングできないような対策がばっちり。 →免許証等２枚身分証明書必要 →当日も受験者の写真を撮られる →ヘアピン禁止（ヘアゴムはOK） →もちろんカバンやスマホ、ポケットの中のものはロッカーへ →メモしたい時などペンさえも会場が用意したものを使用する 最初ちょっとドキドキしますが、会場には他の試験を受けている人も沢山いるのですぐ慣れます。 私の勉強方法 勉強に利用したサイト 「 Amazon Skill Builder 」 動画で勉強のほかに、無料の模擬テストもあり何度か利用。 「 AWS認定資格 無料WEB問題集＆徹底解説 」 　直前は（最後の１日くらい）は「AWS認定資格 無料WEB問題集＆徹底解説」のサイトも利用 受験勉強方法 「AWS Skill Builder」では覚えてほしいことを動画や文章でまとめてくれているのでそれを中心に２週間前から勉強。当然、日本語バージョンを使って勉強しました。 主にコーヒーショップを例にした動画を見ながらキーワードや、説明をメモして動画を一通り見ました。その後、時間もなかったのでメモを見返して特徴を覚えました。 直前は「AWS Skill Builder」の無料の試験の想定問題や、「AWS認定資格 無料WEB問題集＆徹底解説」のサイトを利用して問題に慣れるようにしました。 公式の想定問題だけでは問題慣れが不十分と感じ、「AWS認定資格 無料WEB問題集＆徹底解説」は前日から利用しました。しかし、このサイトに用意されている400問という問題数は前日からではとてもできないと思い網羅しやすいとことに絞って利用しました。 試験の出題範囲と出題率が以下です（C01ドメイン） クラウドのコンセプト： 26% セキュリティとコンプライアンス： 25% テクノロジー： 33% 請求と料金設定： 16% ( 2023/9/18 まで。 9/19 から変更あり) AWS Certified Cloud Practitioner(CLF-C02)試験ガイド より それに対して「AWS認定資格 無料WEB問題集＆徹底解説」の問題数が以下でした。 クラウドの概念： 45 問 セキュリティ： 57 問 テクノロジー： 254 問 請求と料金設定： 51 問 そのため約100問で51%のカバーができる「クラウドの概念」「セキュリティ」だけをこのサイトでは学習しました。 こちらの学習で用語の定着の確認や覚えていないところの覚えなおしができました。 この勉強方法でよかったことは、「動画でイメージが分かってから用語を覚える」そして「他サイトも含めて定着を確認する」という流れだったので最短で受験合格ができたことだと思います。 受験 受験中 試験では私は見直しを含めて時間は最後まで使いました。 （昔からギリギリまで粘るタイプ） 難しい！とは思わなかったですが、学習中に聞いたことない用語が消去法で消せなかったり、残り２つから絞れない問題や、まったく分からない問題もありました。 一方で、ITの常識の範囲で選択肢を消去できるような問題もあり（例：自社サーバーからクラウド移行するメリットを答える問題で、選択肢で「パッチの適用が不要になる」は明らかに不正解など）落ち着いて考えればある程度絞れる問題もいくつもありました。 今回の勉強に踏まえ、このような問題で確実に点を取っていたのかなと思います。 試験結果 試験結果が早く分かります。 試験が終わってアンケートを答えた後 ---------------- この画面を保存しないでください。 ----------------- と表示されて（そもそもスマホはロッカーだし、ピアソンVUEのPCだからスクショしても意味ないけど。と思いながら）読み進めると ----------------- 「合格」 ----------------- の二文字が！！ ここまで即時に合格が分かった試験は初めてです。笑 （2023/03に受験したJSTQB_FLを受験したときでさえメールで２日後に連絡がきました） 合格証 上長とも「時代？！」と話していたのですが、合格証は送られてくるものではなく自分でダウンロードして取得するものでした。笑 AWS認定 クラウドプラクティショナーを取得して AWSは効率的なサービスがたくさんあって、世界中どこでも利用することができてホント便利！と感じました。 例えば東京と、大阪という異なるリージョンにミラーを配置することができます。複数のリージョンを利用すれば、地震など一方に大きな災害があった時、もう一方が問題なくお客様の情報を守ったり、仕事が円滑にできるなど、クラウドの必要性を知ることができました。 ※ただし東京にあるが、大阪にはないサービスがあるなどリージョン毎に提供されるサービスが異なっていたり（「 AWSサービス（リージョン別） 」で、それぞれのリージョンで提供されるサービスの確認が可能です）、料金もリージョン毎に異なるので、利用の際は確認が必要です。 また、近年日本で普及した理由の一つは新型コロナウイルス感染拡大予防のため、テレワークが急速に進められたからです。オフィス以外の場所で仕事ができる環境を整えるためクラウドサービスを利用する企業が増えたことにも納得しました。 今回の勉強で、データ保管の方法や、世界各国に配信することができることや、料金システムなどクラウドコンピューティングができることや仕組みが分かるようになりました。AWSクラウドについて知識がふえることでイマドキの世の中のクラウドのことが少しは理解することができたと思えたので受験してよかったです。 ここまで読んでいただきましてありがとうございます。 参考資料 AWS(アマゾン ウェブ 【AWS公式】 クラウド コンピューティング サービス | Microsoft Azure 無料トライアルと無料枠  |  Google Cloud The post AWSをもっと知りたくなった！AWSクラウドプラクティショナー受験体験記 first appeared on Sqripts .

2023年11月15日、 VMware （現 Broadcom ）社主催のVMware Explore 2023 Tokyo内で脅威ハンティングのコンテスト「VMware Carbon Black Threat Hunter Challenge」が開催されました。 今回は、同コンテストで並みいる強豪を抑えて個人スコア１位を獲得した、株式会社AGESTのプリンシパルアナリスト（以降Aさん）にインタビューを行いました。 ■ 脅威ハンティングのコンテスト「CTF（Capture The Flag）」とは 情報セキュリティの腕を競い合うコンテストです。CTF（Capture The Flag -旗をつかめ-）とも呼ばれ、今や世界中で開催されています。 セキュリティ関連の課題がクイズ形式で提示され、制限時間内に解いたクイズによって獲得した得点が多い方が勝利です。個人でも団体でも参加でき、勝利を目指すためのWebサイトや書籍なども存在します。 関連記事 CTFとは。情報セキュリティの腕を競うコンテスト－Capture The Flag－ 　</Sqripts> 【注釈】この記事は一部2023年11月15日時点での製品名等の表記があります。 コンテスト概要 開催概要 開催日：2023年11月15日（水）14:00～17:30　（VMware Explore 2023 Tokyo Day2） 場所：ザ・プリンスパークタワー東京「きんもくせい」ルーム 公式サイト： VMware Carbon Black Threat Hunter Challenge 競技の概要 VMware Carbon Blackを用いた脅威ハンティングを3時間で体験するコンテスト。これまで海外で多数開催されており、日本では今回が初の開催となった。 サイバーセキュリティの知識を問う問題や、VMware Carbon Black Cloudを用いた脅威ハンティングに挑戦し、時間内での獲得点数を競い合う。 参加対象は、サイバーセキュリティに興味がある・脅威ハンティングを体験してみたいといった人から、業務でVMware Carbon Blackの運用に携わる人、VMware Carbon Blackの導入を検討している人など幅広い。団体での参加が可能だが、得点は個人単位となる。 サイバーセキュリティの知識を問う問題や、VMware Carbon Black Cloudを用いた脅威ハンティングに挑戦する問題をL100-L300（初級～中級）の複数のレベルで出題している。 優勝者インタビュー。職業はセキュリティアナリスト。 編集部 ：今回は優勝おめでとうございます。まずはAさんのプロフィールをお願いします。 Aさん ：現在は株式会社AGESTでセキュリティオペレーションセンター「DH-SOC」に所属し、セキュリティアナリストをしています。 これまでの職歴としては、セキュリティアナリストを3年、その前はデータセンターのオペレーターを6年ほどしていました。 編集部 ：今回参加された「VMware Carbon Black Threat Hunter Challenge」は、どのようなコンテストだったのでしょうか。 Aさん ：VMWareのCarbon Black EDRで検知されたインシデントの調査・分析を題材にしたCapture the Flag形式の競技大会です。海外での開催実績はあるそうですが、日本で開催するのは今回が初めてと聞いています。 当社からは私と同僚の2名で参加しました。 編集部 ：参加したきっかけはどのようなものでしたか？ Aさん ：今回のCTFはVMwareさんからお誘いいただき参加しました。 過去には2回ほど別のCTFに参加していますが、いずれもあまりいい成績ではなかったので、今回もそこそこの順位までいければいいな、というぐらいの見通しでした。 コンテスト開始から途中経過発表まで 当日のタイムテーブル 編集部 ：コンテストで優勝に至る経緯をうかがいます。当日のタイムテーブルを拝見しました。日本では初めての開催とのことで、会場の雰囲気などどのように感じられましたか？ Aさん ：実は私は当日遅刻をしてしまい、オープニングやゲームの説明には参加できませんでした。ですので、開会時の雰囲気などはわからず、初めて参加する大会なのに残念な思いをしました。 遅刻した私に対しても、VMwareの担当の方が丁寧に対応してくださったので、とても助かりました。 会場についた時にはもう競技が始まっており、みなさん真剣に取り組んでいたので、途中から入るのはかなり気まずかったです。 競技中に漏れ聞こえてきた周囲の話から、参加者はアナリストだけではなさそうだと感じましたので、あまり構えずに挑みました。 表彰時に他のSOCアナリストも多く参加していることを知り、むしろ驚いたぐらいです。 SOCアナリストとは 各種ネットワーク機器やセキュリティ機器などから取得したログを監視し、サイバー攻撃やインシデントの発生を把握する役割を担っています。監視は24時間365日行われます。 インシデントの対策の立案や、実際に発生したインシデントの対処を行うこともあります。 競技の様子 （VMware社提供。※モザイク加工をしています／Sqripts編集部） 編集部 ：競技の内容について教えてください。 Aさん ：一般的な知識を問うパートが1/3、Carbon Black上で模擬的なインシデントのシナリオに基づいてアラートや検知ログからフラッグを探すパートが2/3ほどの割合でした。 一般的にSOCだと、端末と端末上の挙動だけについて詳しくなりがちですが、今回はネットワークだけではなく、ログの外部連携やAPIなどについての質問もあり、かなり広範囲について質問されている印象を受けました。 編集部 ：競技開始から1時間ほどで途中経過発表がありました。ここまでの前半での手ごたえはどのようなものでしたか？ Aさん ：スタート時点ですでに出遅れていましたので、なるべく焦らず、着実に回答可能な問題を選んで解いていきました。今回のCTFは2回のミスで不正解の扱いになるルールでしたので、とにかく失点をしないことを一番に心掛けました。 私が従事しているようなSOCの現場では、短時間で確実に分析・判断することがいつも求められていますので、普段の業務のつもりで取り組みました。 とにかく遅れを挽回することに集中していたので、ここまでは順位などもあまり気にしていませんでした。途中経過の段階では5位に届かないぐらいでしたが、これぐらいのペースで解いていけばいいかなという感触でした。 途中経過を発表した司会の方から「追い上げが凄い」とコメントをいただいたのですが、私としては実感はなかったです。 優勝インタビューではありきたりなコメントをするのが精一杯でした 編集部 ：遅れてのスタートでしたが、順調に順位を上げていたのですね。競技後半での手ごたえはいかがでしたか？ Aさん ：前半のペースを落とさず、同じような調子で問題を解いていきました。インシデントのシナリオに沿って解いていくタイプの問題が前半と比べて増えたので、前半よりも比較的容易に解けたかなと思います。 出題ではAPIや外部ログ出力に関する問題もありました。私が現在所属しているDH-SOCでは、運用を担当するチームと連携して顧客対応をすることがあります。その際に運用チームから教えてもらった知識を活用することができ、とても嬉しかったです。 夢中で問題を解いていたところ、途中で同僚から1位になっていることを教えられて、自分としてはむしろ驚きました。景品も出るという話をチラッと聞いていたので、それならもうちょっと頑張ってみようかなと。 終了の30分前ぐらいに2位の人に500点（1～2問分）程度の点差に迫られていたので、正直焦りもありました。どうにか突き放そうとして頑張って点差を稼いだのですが、最後はそのまま逃げ切り、終了することができました。 当日のスコアボード。青い線がAさん （※名前を隠す加工をしています／Sqripts編集部） 編集部 ：最終の結果では、個人スコア1位を獲得されました。おめでとうございます！ 発表時のお気持ちはどのようなものだったでしょうか。 Aさん ：そこそこの順位のつもりで参加していたので、1位が取れるとは思っておらず、正直びっくりしました。 今ここに至っても1位を取ったという実感はないです。自分のことではないみたいで…… 優勝時のインタビューでも泡食ってありきたりなコメントをするので精一杯でした。 編集部 ：競技では冷静でしたが、優勝インタビューはテンパってしまったというところでしょうか。 本当におめでとうございます。 CTFで勝つために必要なこと 編集部 ：このようなコンテストや大会は普段の業務経験が活きるのだとは思いますが、大会に向けて、普段から準備やトレーニングしていることなどはありますか？ Aさん ：特にはありません。 しいて言うなら、業務を通して幅広く知識を得ようと心掛けているぐらいです。また、普段から、端末の挙動ではなくその背後にあるユーザーや攻撃者の意図を意識するようにしています。 編集部 ：今後もこのような大会があれば出場されますか？（他社CTF含む） Aさん ：ぜひ参加したいと思っています。 自身のセキュリティ知識やアナリストの腕試しという意味もありますが、純粋に自分の知識を使って問題を解いていくのは楽しいです。 編集部 ：これから出場を目指す方に、普段から取り組むとよい勉強・トレーニングなどがあればアドバイスをお願いします。 Aさん ：自分の業務外の知識も知ろうとすることが重要だと思います。 SOCだけだとついつい端末側の知識に偏りがちですが、CTFだとフォレンジックやネットワーク、製品でも運用構築に近い部分の知識が問われることも珍しくありません。 それから、実際に分析に必要な作業を行って操作に慣れておくことも重要だと思います。競技中も調べものをすることは可能ですが、「一度経験があることを思い出すために調べる」のと、「初めての作業を調べながら、その情報を元に作業する」のでは、速度も作業精度も各段に差が出ます。 普段から、自分の担当する部分だけではなく、周辺の知識を習得したり実際に作業を行ってみることで、予想外の問題が出ても解いていく力がつくと思います。 （了） The post CTF優勝者インタビュー｜VMWare社主催「VMware Carbon Black Threat Hunter Challenge」 first appeared on Sqripts .

こんにちは。QAエンジニアのTHです。 普段からGoogle Chromeをウェブブラウザとして使用されている方は多いと思います。 このGoogle Chromeにはデベロッパーツールと呼ばれる機能があります。 一般ユーザーとしてウェブサイトを閲覧するだけの人は使うことのない機能ですが、ウェブ開発や検証においてはとても便利なツールです。ウェブ開発や検証に携わったことのある方は一度は見聞きしたことがあるのではないでしょうか？ 本記事が下記のような方にとって Chromeデベロッパーツール 使い始めの第一歩として参考になればと思っています。 - Chromeデベロッパーツールはなんとなく知っているけど何ができるのか分からない - Chromeデベロッパーツールの使い方が分からないので敬遠している - ウェブデザイン・コーディング初心者 - 意図しないブラウザ表示の原因特定や微調整に苦労している 沢山あるChromeデベロッパーツールの機能の中でも、特に基本となる「要素(Elements)パネル」の機能について紹介していきます。要素(Elements)パネルは、Chromeデベロッパーツールの中でも特に重要な機能の一つで、ウェブページの要素やDOMツリーの視覚的な表示、スタイルの編集などに使用されます。 要素(Elements)パネルを活用すると、HTML構造や、CSSでどのようなスタイル指定がされているのかを確認しながら、ブラウザ上の表示や動作のシミュレーションを即時反映で確認することができます。要素の微妙な表示位置やサイズ、色合い調整のために、HTMLやCSSをエディター画面で少しいじっては、ブラウザ画面の表示を確認する、といった作業を繰り返しているような方は作業効率がぐんと上がるはずです。 その他、本記事を読んでいただくことで以下のようなことができるようになります。少しでも皆様のお役に立てばと思いますので、ぜひ最後までお付き合いください。 - HTMLやCSS編集によるブラウザ表示の変化を即時反映で確認しながらコードを決定 - 決定したコード（シミュレーションした内容）を手軽に実ファイルへ反映 - マウスオーバー時など、特別な状態の要素を即時反映でシミュレーション確認 - 様々なデバイス端末のブラウザ表示状態をシミュレーション確認 ※本記事の執筆時のGoogle Chromeのバージョンは 117.0.5938.92 です。 ※本記事内の画像はWindowsで起動したChromeデベロッパーツールのものになります。 まずは使ってみよう 起動 まずは以下手順でChromeデベロッパーツールを起動してみましょう。 Chromeブラウザを開きます。 ブラウザウィンドウの右上隅にあるメニューアイコン（3つの垂直な点）をクリックします。 メニューが表示されたら、「その他のツール」を選択します。 「デベロッパーツール」をクリックします。※または、以下のショートカットキーでも起動することができます。　Windows/Linux：F12　Windows：Ctrl + Shift + I　Mac：Option + Command + I デベロッパーツールが表示されます。 日本語化 Chromeデベロッパーツールはデフォルトでは英語表示となります。 英語がどうにも苦手という方もいらっしゃるかと思いますが、それで利用を敬遠してしまっては非常に勿体ないので以下手順で日本語化しましょう。 ・Chromeデベロッパーツールを起動します。 ・デベロッパーツール右上に表示されているSettingsアイコン（歯車のアイコン）をクリックして、Settingsメニューを表示します。 ・Settingsメニューの「Preferences」を選択して、「Language:」の項目で「Japanese – 日本語」を選択後、右上の×ボタンで閉じます。 ・設定変更を反映するためのリロードが必要である旨のメッセージが表示されますので、「Reload DevTools」をクリックします。 ・リロード後、デベロッパーツールが日本語表示になります。 画面配置の変更 Chromeデベロッパーツールは画面配置を変更することができます。 以下手順で検証対象のウェブページや自分の好みに合わせてデベロッパーツールの画面配置を変更して使ってください。 ・デベロッパーツールの右上にあるメニューアイコン（3つの垂直な点）をクリックします。 ・メニューが表示されたら、「固定サイド」のいずれかのアイコンを選択します。選択肢には次のものがあります： 固定を解除して別ウィンドウに表示：デベロッパーツールを独立したウィンドウとして表示します。 左に固定：デベロッパーツールをブラウザウィンドウの左側に固定表示します。 下部に固定：デベロッパーツールをブラウザウィンドウの下部に固定表示します。 右に固定：デベロッパーツールをブラウザウィンドウの右側に固定表示します。 要素(Elements)パネルの基本的な使い方 ここからは、本題の「要素(Elements)パネル」でできることについて記載していきます。 HTMLやCSSの表示を確認したり、加えた変更をシミュレーションしながら最終的なファイル更新を行う、といった活用の仕方の例を紹介していきます。 DOMツリー表示と要素選択 要素パネルでは、ウェブページのDOMツリーが表示されます。DOMツリーは、ウェブページの要素の階層構造を示しており、子要素と親要素の関係を視覚的に確認することができます。DOMツリーは展開/収納することもできます。 また、要素パネルの上部にあるポインターのアイコンをクリックすることで、ウェブページ上の要素を直接選択することもできます。 ［1］デベロッパーツール左上の「ページ内の要素を選択して検査」アイコンをクリックします。アイコンが青色になっている時は要素の選択モードになっている状態です。 ［2］そのままウェブページの表示画面のほうにカーソルを移動して要素上にかざすと、その要素がハイライト表示され、ポップアップ表示でタグの種類やクラス名、要素のサイズが確認できるようになっています。 ［3］さらに検証ツール画面のほうでも連動して該当要素のコードをハイライト表示してくれます。 ［4］DOMツリー上のハイライト表示箇所をクリックして選択すると検証ツールの画面でそのままその要素の詳細（CSSでどのようなスタイルが適用されているか等）を詳しく確認できます。 スタイルの編集 要素パネルの最も多い使い方としては、実際のブラウザ上での表示の変化を見てシミュレーションしながらCSSの指定の仕方を決めたり、CSSの記述が効いていない場合に何が原因で上手くいかないのかを検証ツールで確認したりするケースかと思います。 ［1］スタイルタブでは、選択中の要素に対して効いているCSSのスタイル指定が一覧で確認できます。プロパティ指定の一つ一つに対してチェックを付けたり外したりできるようになっており、この指定がなかった場合、または、あった場合、というようなシミュレーションができます。 ［2］プロパティに書いてないものを追加することもできます。プロパティ欄をクリックすることで新しいプロパティ指定を増やせるようなモードになります。この状態で何かプロパティを追加した場合どう変わるかといったシミュレーションをしながらコードを決めることができます。 例として「Google」表示の要素に対して「BACKGROUND-COLOR」のプロパティ指定を追加すると、実際の画面にその背景色が反映され、どのような表示になるかをシミュレーションすることができます。 ［3］また、element.style欄にプロパティ指定を追加することで、タグ名やクラス名等のセレクタ指定があるCSSでのスタイル指定ではなく、選択中の要素一つ一つに対して直接プロパティ指定をすることもできます。element.style欄で記載した内容は、個別にHTMLの要素の中に直接インライン指定でスタイル属性が追記されます。ある特定の個別要素に対して表示の検証がしたいような場合にはこちらが便利です。 ここで注意点です。 検証ツール上での変更は、あくまでシミュレーションなので実際のファイル内容が書き換わることはありません。ブラウザでのページ再読み込みやクローズで検証ツール上でのシミュレーション内容は全て消えてしまいます。 反映する場合には同じ内容を実際のファイルに書き写して更新する作業が必要になりますので忘れないようにしましょう。 inspector-stylesheet を利用したスタイル編集 上記の通り、実際にシミュレーションした内容を反映させるためには記載内容の実ファイルへの書き写しが必要となりますが、この作業を少し楽にしてくれる方法として、inspector-stylesheetを利用したプロパティ指定の方法があります。ここではその方法を紹介していきます。 この inspector-stylesheet とは、簡単に言うと検証用に一時的に読み込むためのCSSファイルになります。 ［1］スタイルタブ右上にある「新しいスタイルルール」アイコン（プラスマークアイコン）をクリックすると、選択中要素のタグ名やクラス名などのセレクタ指定で自動で inspector-stylesheet のブロックが生成されます。自動で生成されたセレクタの内容が意図したものではない場合には編集して修正も可能です。 ［2］この inspector-stylesheet のブロックにプロパティ指定を追記できます。この場合は、先程のelement.style欄でのプロパティ指定とは違い、HTMLの要素には直接インライン指定でのスタイル属性は追記されません。 ［3］続けて他の要素を選択して、同様にスタイルタブ右上にある「新しいスタイルルール」アイコン（プラスマークアイコン）をクリックして、inspector-stylesheet のブロックでプロパティ指定を追記します。 ［4］ここで、inspector-stylesheet のブロック右上にある「inspector-stylesheet：数字」の表示をクリックしてみます。各ブロック右上のこの欄には、そのブロックに表示されているスタイル指定が実際に記載されているCSSファイルの名前が表示されています。またファイル名の後のコロン記号に続く数字はCSSファイルの何行目にそのスタイル指定の記載があるかが表示されています。 ［5］表示が要素パネルからソースパネルへと変わり、inspector-stylesheet(検証用に一時的に読み込むためのCSSファイル)に記載されている内容を全て確認することができます。 今回は、上記の手順2と手順3で、inspector-stylesheet に追記した内容をまとめて確認することができ、その内容をまとめて選択してコピーすることが可能です。つまり、inspector-stylesheet を利用してシミュレーションをした場合には、全ての表示確認を終えてから実際のファイルに反映させる時にも、こちらのソースパネルから纏めてコピペができることになります。 hover要素のスタイル編集 ウェブサイトにはマウスオーバー時（hover時）に表示スタイルが変わる仕様のボタン等が数多く存在します。 例えば、Googleトップページでは下記キャプチャのように「Googleアプリ」アイコン（9つの点でできたブロックアイコン）は、hover時とそれ以外で表示が切り替わります。 ・通常時（9つの点でできたブロックアイコンのみ表示） ・hover時（円形のグレー背景が追加表示される） 当たり前ですが、ブラウザ上の表示はマウスオーバー時にはhover時表示に変わりますが、マウスを動かしてしまうと通常表示に戻ってしまいます。なので、このhover時のスタイル指定編集を実際のウェブページ上でシミュレーション確認しながら実施するには特別に表示設定を固定する必要があります。 この方法が少し分かりづらいのでここで説明しておきます。 ［1］確認したい要素を選択した状態で、スタイルタブの「:hov」をクリックして「要素の状態を強制」メニューを表示します。 ［2］「要素の状態を強制」メニューで「:hover」のチェックをオンにします。 チェックをオンにするとブラウザ上の表示がマウスオーバーしているいないに関わらずhover時の表示で固定されます。 また、該当要素のコードの左上にはhover表示固定であることを示すオレンジ丸のマークが表示されます。 そして、スタイルタブには、該当要素のhover時のプロパティ指定が表示されて編集が可能になります。 ［3］この状態であれば、hover時のスタイル指定を編集してブラウザ上での表示をシミュレーションすることができます。 また、「要素の状態を強制」メニューには、hover以外にも機能がありますので、ここでhoverも含めて簡単に説明しておきます。 それぞれ、hoverと同様の手順で各状態のスタイル編集をシミュレーションできます。 active：クリックされた状態 hover：マウスオーバー時の状態 focus：テキストエリアやテキストフィールドが選択された状態 visited：過去に訪問したことのあるリンク色の状態 focus-within：テキストエリアやテキストフィールドが選択された状態（focusとの違いは一つの入力欄だけでなくフォーム全体の状態であること） focus-visible：タブキー操作などのキー操作で選択している状態 target：アンカーリンクなどのリンク先に適用される状態 デバイスモードでの表示確認 デバイスモードはウェブぺージをさまざまなデバイスや画面サイズで表示するための機能になります。これにより、モバイルデバイスでの表示やレスポンシブデザインのシミュレーションが容易になります。また、実際のデバイスでの操作同様に画面のスクロールやタッチイベントのシミュレーションも可能です。 デバイスモードを使用する手順は以下の通りです。 ［1］デベロッパーツール左上の「デバイスのツールバーを切り替え」アイコンをクリックします。ウェブページ表示画面がデバイスモードの表示に切り替わり、上部にはデバイスツールバーが表示されます。 ［2］デバイスツールバーの中央にあるサイズ欄をクリックすると、利用可能なデバイスやプリセットが表示されます。確認したいデバイスを選択すると、ウェブページが自動的にリロードされ、選択したデバイスでの表示に切り替わります。その状態でデバイス固有の表示問題の特定などを行うことができます。 ［3］表示されたデバイスリスト一番上の「レスポンシブ」を選択した場合には、特定機種のサイズではなく自由に横幅と縦幅を設定して表示を確認することができます。 表示されたデバイスリストで「編集」を選択した場合には、エミュレート対象のデバイスリストが表示され、リストに表示または非表示にするデバイスを選択することができます。 さらに「カスタムデバイスを追加」ボタンをクリックすると、任意に画面サイズを設定したデバイスを追加することも可能です。 ただ、非常に便利なデバイスモード機能ではりますが、あくまでもシミュレーション用になります。この機能を使って確認をしながらデザイン実装を進めた後に、最後は必ず実機での検証確認をお勧めします。 おわりに 今回ご紹介した要素(Elements)パネルの機能は基本的なものばかりですが、ウェブページの表示や、各要素のスタイルを確認したり変更したりする際にとても役立ちます。 意図しないブラウザ表示の原因特定や微調整など、HTMLやCSSエディターでの編集作業とブラウザの表示確認で、繰り返しの画面切り替えが発生して時間をロスしているような方は、Chromeデベロッパーツールを使うことで画面表示を予めシミュレーションして作業を効率的に実施することができるようになりますので、ぜひご活用ください。 また、Chromeデベロッパーツールには、他にも多くの機能があります。この記事がデベロッパーツール利用の機会となれば嬉しいです。機会があれば今回ご紹介できなかった他パネルについてもご紹介していければと思います。 こちらの記事もおすすめ Webサイトテスト時の便利技・PCブラウザのデベロッパーツールをスマホで使おう The post Chromeデベロッパーツールを使ってみよう｜要素（Elements）パネル編 first appeared on Sqripts .

本連載では、ブロックチェーンの基本的な仕組みを解説しながら、オンチェーンデータを分析するための基本的な手法について、全8回で紹介します。 最終回となる今回は、過去の連載記事で紹介しきれなかったDune（分析ツール）のTips的な有用機能や、分析のための高度なSQL構文についてご紹介します。 Dune Tips DuneのようなSQLベースの分析ツールは、SQLで記述されたクエリを再利用するためのさまざまな有用機能が実装されていることが多くあります。その中でも、多くの分析ツールで頻繁に使用されるパラメタ化機能やビュー作成機能についてご紹介します。 Parameters SQLクエリ中の絞り込み条件に含まれる、時刻や特定の文字列などの値を、パラメタ化して実行時に指定できるようにしたり、パラメタだけを変えて同じクエリを何度も実行したりしたいことがよくあります。Duneの場合、パラメタ化したい箇所に名前をつけて {{ }} で囲うことで、簡単にパラメタの外部化を実現できます。コード1に、uniswapという分散取引場の取引履歴から、トークンペアの種類をパラメタで指定して集計を実行するクエリ例を示します。 コード1 . token_pairをパラメタ化したクエリ例 SELECT token_pair, COUNT(1) AS cnt, SUM(amount_usd) AS total_amount_usd FROM uniswap_v3_ethereum.trades WHERE block_time BETWEEN timestamp '2023-01-01 00:00:00' AND timestamp '2023-01-31 23:59:59' AND token_pair = '{{token_pair}}' GROUP BY token_pair LIMIT 100 パラメタ化した箇所のデータは、図1に示すような設定画面で、データ型を指定したり、選択肢を設定したり、他のクエリの出力結果をパラメタとして設定したり、といったカスタマイズが可能です。パラメタ化機能をうまく活用することで、ひとつの汎用的なクエリを用いて、さまざまな切り口からのデータ分析をおこなうこともできます。 図1. パラメタの詳細設定画面 Query Views 過去の記事でも解説した通り、関係演算の閉包性により、SQLクエリの出力結果は別のSQLクエリの入力（FROM句に指定するテーブル）になることができます。それは、WITH句を用いてひとつのクエリ内で名前付けしたテーブルを再利用するだけでなく、異なるクエリ間でも再利用が可能です。 SQL自体の機能にも、「CREATE VIEW」などの構文を用いて、クエリ結果をテーブルとして扱うことができるビューを定義する機能があります。Duneの場合は、クエリエディタで作成し保存したクエリには自動的にIDが振られるため、そのIDを用いてさらに簡単にクエリ結果の参照ができます。 例えば、 https://dune.com/queries/3238025 というURLでアクセスできるクエリの結果をSQLで利用するには、URLに含まれる queries/ 以下のクエリIDを用いて、「query_3238025」といったテーブル名で参照するだけです。 図2. ビューとして参照したいクエリ（ https://dune.com/queries/3238025 ）の実行例 コード2 . クエリID: 3238025のビューを参照するクエリ例 SELECT * FROM query_3238025 図3. コード2の実行結果（図2と同様の出力結果になる） 自身が作成したクエリだけでなく、他のユーザーが作成し公開しているクエリも簡単に参照できるので、オンラインコミュニティ全体で共創的なダッシュボード開発が実現できることも、Duneのサービスの魅力です。 分析のための高度なSQL 最後に、Window関数やCASEほど頻出ではないものの、SQLの表現力を拡大させる高度な構文として、ROLLUP（超集合）やWITH RECURSIVE（再帰クエリ）の使い方をご紹介します。 ROLLUP ダッシュボードやレポートを作成する際、カテゴリごとの集計と、それらを合算した小計、全体の合計などを一度に表示したい場合があります。SQLの場合、同じカラムを持ったテーブル同士をUNIONまたはUNION ALL句で連結することで、一つのテーブルにまとめることができるため、UNION句を用いて小計・合計を含むレポートを作成することができます。 コード3 . UNION ALL句を用いて、Ethereum Traceデータの種類ごとの件数と合計を同時に取得するクエリ WITH target_traces AS ( SELECT * FROM ethereum.traces WHERE block_time BETWEEN timestamp '2023-01-01 00:00:00' AND timestamp '2023-01-01 23:59:59' ) SELECT 'ALL' AS type, count(1) AS cnt FROM target_traces UNION ALL SELECT type, count(1) as cnt FROM target_traces GROUP BY type 図4. コード3の出力結果 しかし、同じテーブルに対して複数のSELECT文を実行し、UNIONで連結するのは、実行コストが高く、記述も冗長になりがちです。そこで、GROUP BY句にROLLUP句を指定することで、全体の合計と小計を同時に計算することができます。 コード4 . コード3と同様の内容をROLLUP句で実現したクエリ SELECT type, count(1) AS cnt FROM ethereum.traces WHERE block_time BETWEEN timestamp '2023-01-01 00:00:00' AND timestamp '2023-01-01 23:59:59' GROUP BY ROLLUP(type) 図5. コード4の出力結果 また、ROLLUP句には複数のカラムを指定することもできます。ROLLUP句に複数のカラムを指定した場合、指定した順に応じて小計のグループが細分化されます。例えば、コード5に示すとおり、ROLLUPにtypeとsuccessという2つのカラムを指定した場合、まず冒頭に指定したtypeをもとに小計と合計が計算され、さらにsuccessの中身に応じて細分化された小計が計算されます。2つ目に指定したsuccessのみに応じて細分化された小計（この場合はsuccess=trueのレコード全体とsuccess=falseのレコード全体の小計）は計算されないことに注意してください。 コード5 . ROLLUPに複数カラムを指定するクエリ例 SELECT type, success, count(1) AS cnt FROM ethereum.traces WHERE block_time BETWEEN timestamp '2023-01-01 00:00:00' AND timestamp '2023-01-01 23:59:59' GROUP BY ROLLUP(type, success) 図6. コード5の出力結果 もし、指定したカラムのすべての組み合わせに対する小計を計算したい場合は、ROLLUPではなくCUBE句が利用できます。コード6に示したCUBE句によるクエリ例では、図7に示すとおり、2番目に指定したsuccessカラムだけに基づく小計も計算されています。 コード6 . コード5のROLLUPをCUBEに書き換えたクエリ例 SELECT type, success, count(1) AS cnt FROM ethereum.traces WHERE block_time BETWEEN timestamp '2023-01-01 00:00:00' AND timestamp '2023-01-01 23:59:59' GROUP BY CUBE(type, success) 図7. コード6の出力結果 よりカスタマイズされた条件に基づく小計を計算したい場合、GROUPING SETS句を用いることもできます。GROUPING SETS句には、GROUP BYの対象としたいカラムの組み合わせを列挙して指定することができます。「ROLLUP(c1, c2)」という記述は「GROUPING SETS( (c1, c2), (c1), () )」に等しく、「CUBE(c1, c2)」という記述は「GROUPING SETS( (c1, c2), (c1), (c2), () )」に等しくなります。 コード7 . コード5のROLLUPをGROUPING SETSで書き換えたクエリ例 SELECT type, success, count(1) AS cnt FROM ethereum.traces WHERE block_time BETWEEN timestamp '2023-01-01 00:00:00' AND timestamp '2023-01-01 23:59:59' GROUP BY GROUPING SETS( (type, success), (type), () ) 図8. コード7の出力結果 WITH RECURSIVE SQLには、手続き型プログラミング言語のfor文のような繰り返し処理のための構文がないため、逐次処理が苦手と思われがちです。しかし、WITH句のなかで自分自身のテーブルを参照できるWITH RECURSIVE（再帰クエリ）を用いると、無限ループを含む繰り返し処理をSQLで実行することも可能です。 コード8に、WITH RECURSIVEを用いてフィボナッチ数列を計算するクエリ例を示します。WITH RECURSIVEの基本構文は、UNION ALL句を用いて2つのSELECT文を結合し、1つ目のSELECT文では繰り返しの起点となるレコードを指定し、2つ目のSELECT文で繰り返し中の計算処理と終了条件を指定します。 コード8 . WITH RECURSIVEを用いてフィボナッチ数列を計算するクエリ例 WITH RECURSIVE fib (x, a, b) AS ( SELECT 0, 0, 1 UNION ALL SELECT x + 1, b, a + b FROM fib WHERE x < 10 ) SELECT x, a FROM fib; 図9. コード8の出力結果 WITH RECURSIVEを用いた実用的なクエリ例として、暗号資産の取得価額を移動平均法によって計算するクエリをコード9に示します。暗号資産の取得価額の計算方法については、国税庁による「 暗号資産に関する税務上の取扱いについて（ＦＡＱ） 」（pp.15-16）の事例を参照します。 コード9 . WITH RECURSIVEを用いて、移動平均法による暗号資産の取得価額を計算するクエリ WITH RECURSIVE t (id, btc_balance, trade_time, trade_type, trade_amount, btc_amount, jpy_amount) AS ( SELECT ROW_NUMBER() OVER(ORDER BY trade_time) AS id , SUM(btc_amount) OVER(ORDER BY trade_time) AS btc_balance , * FROM query_3238025 ) , moving (id, trade_time, trade_type, btc_amount, jpy_amount, btc_balance, btc_moving_avg_price) AS ( (SELECT id, trade_time, trade_type, btc_amount, jpy_amount, btc_balance, 1.0 * abs(jpy_amount) / btc_amount AS btc_moving_avg_price FROM t WHERE id = 1) UNION ALL (SELECT t.id, t.trade_time, t.trade_type, t.btc_amount, t.jpy_amount, t.btc_balance, CASE WHEN t.trade_type = 'Sell' THEN moving.btc_moving_avg_price ここでのサンプルデータは、下記のような内訳でビットコインの購入と売却をおこなった場合を想定します。このサンプルデータは、図2に示したクエリ（ https://dune.com/queries/3238025 ）から参照できます。 3月1日 4 BTCを 1,845,000円で購入 保有数量 4 BTC 6月20日 2 BTCを 1,650,000円で購入 保有数量 6 BTC 7月10日 2 BTCを 2,400,000円で売却 保有数量 4 BTC 9月15日 0.5 BTCを 542,800円で購入 保有数量 4.5 BTC 11月30日 3 BTCを 2,895,000円で売却 保有数量 1.5 BTC コード9のクエリを細分化して解説します。まず、サンプルデータには取引時点での保有BTCの残高を示すカラムがないので、Window関数を用いて累計のBTC残高を計算します。また、取扱を簡単にするため、取引履歴順に連番のIDを付与します（コード10）。 コード10 . BTC取引履歴の前処理部分 SELECT ROW_NUMBER() OVER(ORDER BY trade_time) AS id , SUM(btc_amount) OVER(ORDER BY trade_time) AS btc_balance , * FROM query_3238025 移動平均法を用いた暗号資産の平均単価は、「取引時点で保有する暗号資産の簿価の総額 / 取引時点で保有する暗号資産の数量」で計算されます。 例えば、3月1日時点でのビットコインの平均単価は、ビットコインの簿価の総額が1,845,000円であり、保有するビットコインの数量が 4 BTCなので、1 BTCあたりの平均単価は 1,845,000 / 4 = 461,250円となります。コード11に示す再帰クエリのなかでは、UNION ALL句の前側のSELECT文で、この計算をおこなっています。 続いて、6月20日時点の場合を計算します。この時点でのビットコインの簿価の総額は、過去に保有しているビットコインの簿価＋新規購入額となります。すなわち、上記で計算した平均単価461,250円 × 保有ビットコイン 4 BTC + 新規購入額 1,650,000円 ＝ 3,495,000円です。また、この時点で保有するビットコインの数量は 6 BTCなので、1 BTCあたりの平均単価は 3,495,000 / 6 = 582,500円となります。この計算は、コード11においては「WHEN t.trade_type = ‘Buy’ THEN～」に続く箇所で計算しています。 7月10日の取引は、保有しているビットコインの売却なので、平均単価には影響せず、1 BTCあたりの平均単価は6月20日時点と同じ582,500円となります。コード11においては「WHEN t.trade_type = ‘Sell’ THEN」に続く箇所が、該当する計算箇所です。 9月15日の取引では、新たに 542,800円分のビットコインを購入し、合計4.5 BTCを保有していることになるので、平均単価は （582,500円 × 4 BTC + 542,580円）/ 4.5 BTC = 638,400円となります。 11月30日の取引では、ビットコインの売却のため平均単価には影響せず、同じく638,400円が1 BTCあたりの平均単価です。 コード11 . 移動平均法を計算する再帰クエリの中核部分 (SELECT id, trade_time, trade_type, btc_amount, jpy_amount, btc_balance, 1.0 * abs(jpy_amount) / btc_amount AS btc_moving_avg_price FROM t WHERE id = 1) UNION ALL (SELECT t.id, t.trade_time, t.trade_type, t.btc_amount, t.jpy_amount, t.btc_balance, CASE WHEN t.trade_type = 'Sell' THEN moving.btc_moving_avg_price WHEN t.trade_type = 'Buy' THEN (moving.btc_balance * moving.btc_moving_avg_price + abs(t.jpy_amount)) / t.btc_balance END AS btc_moving_avg_price FROM moving JOIN t ON moving.id = (t.id - 1) ) このように、前の計算結果を引き継いで次の計算をおこなう必要がある場合、WITH RECURSIVEによる再帰クエリが力を発揮します。上記の説明文で計算したビットコインの平均単価と、図10に示す計算結果が一致していることを確認してみてください。 図10. コード9の出力結果 まとめ 全8回の連載を通じて、ブロックチェーンの基本的な仕組みの解説と、代表的なブロックチェーンであるビットコインとイーサリアムのデータ構造の解説、および、SQLを用いたオンチェーンデータ分析の演習をおこないました。これからSQLを用いてデータ分析の技術を磨きたい人にとって、ブロックチェーンのオンチェーンデータは手軽にアクセスできるリアルなデータソースとしておすすめです。また、ブロックチェーンに関する知識を深めたい人にとっても、自分でSQLを記述しながら実データを分析するプロセスは非常に有益です。本連載を通じて、読者の皆様がSQLやブロックチェーン技術の魅力を発見する一助となれば幸いです。 連載一覧 【第1回】ブロックチェーンとは 【第2回】ビットコインの仕組み 【第3回】イーサリアムの仕組み 【第4回】ビッグデータ分析のためのSQL基礎 【第5回】Ethereumデータ分析演習1 【第6回】Ethereumデータ分析演習2 【第7回】Ethereumデータ分析演習3 The post 【第8回】Ethereumデータ分析演習4 first appeared on Sqripts .

こんにちは！　テストエンジニアのマツキョーです。 第三者検証会社のテストエンジニアは、様々なプロジェクトに途中から参画することが多くあります。プロジェクトに参画したテストエンジニアは、まず仕様把握という作業から着手していきます。 仕様把握では、テスト対象となるシステムの要件や仕様が記述されたテストベースが必要になります。すでに開発が進んでいるプロジェクトでは、当然ながらテストベースの量も膨大になっています。そのためテストエンジニアは、膨大なテストベースを確認・理解してテスト設計をする必要があります。 ですが、純粋にテストベースの確認と理解だけに使える時間は限られています。 プロジェクトの体制にもよりますが、多くの場合はキャッチアップ期間として1日～数日、それ以降はテスト分析・設計作業と並行して仕様把握を進めていきます。何も知らないところから、膨大なテストベースを短期間で読み解いて仕様を理解し、品質を担保するために最適なテスト設計を行うのです。 やりがいのある仕事ではありますが、テストエンジニアも人間なので当然プレッシャーが掛かります。むしろ、品質のプロだからこそ感じる不安がプレッシャーの原因と言えるかもしれませんね。 品質保証の業務に従事して10年以上経つ私でも、プロジェクトに参画して仕様把握を始める時は不安を感じます。 この記事では、仕様把握という作業について再認識するところから始め、テストエンジニアの正直な内心にフォーカスしたのち、それを克服して効果的な仕様把握を行うためのコツを紹介したいと思います。 日々品質の守護者として戦うテストエンジニアたちが、不安やプレッシャーに打ち勝ち、より良い品質のために行動する助けになれば幸いです。 仕様把握とは？ 仕様把握とは、言葉のとおり仕様を把握していく作業です。 テストプロセスにおける テスト分析 の作業の1つで、テスト設計の情報源であるテストベースを読み解いて理解していきます。 文字に起こすと簡単そうですが、重要なのは 「理解する」 の部分にあります。この 「理解する」 という作業は、ドキュメントに書かれた内容を覚えるだけの作業ではありません。 仕様として明記されていない情報がないか？ ユーザーの利用シーンはどのような状況か？ 他の機能や外部システムとの連携はあるか？ このような問いを自分の中に持ち、想像力を膨らませながらテストベースを読み解いていく必要があります。なぜなら、 テストベースに書かれていない部分に多くの欠陥が潜んでいる と考えられるからです。 そうして読み解いた内容からテスト設計に必要な情報を選別していき、テスト分析という工程を通じて「何をテストするか？」であるテスト条件を定義していきます。 品質を担保するために必要な情報を得るため、 適切な広さ・深さで仕様を熟知していく作業 がテストエンジニアにとっての仕様把握です。 テストエンジニアの内心 プロジェクトに参画したテストエンジニアが、最初に取り掛かる作業が仕様把握です。仕様把握は、膨大なテストベースを読み解いてテスト対象への理解を深めていく作業です。 私たちはプロなので、お客様のご都合に合わせた期間で必要な情報を集め、理解し、テスト設計に活用して品質に貢献します。だからこそ、テストエンジニアは仕様把握を行うときに以下のような不安を感じます。 効率の良い順番でテストベースに手をつけられるだろうか？ テストベースの内容をスムーズに理解できるだろうか？ テスト設計に必要な情報を期日までに収集できるだろうか？ この不安の裏には、品質のプロとして 「テスト対象を深く理解してテストを設計し、高品質の実現に貢献したい」 という想いがあります。その想いが自身にプレッシャーという形で降りかかってくるのです。 プレッシャーというとデメリットのように捉えがちですが、テストエンジニアにとってはデメリットだけではありません。このプレッシャーに打ち勝つために、知識を身につけ、技術を磨き、創意工夫することで、私たちは成長していくからです。 仕様把握のコツ５選 仕様把握のコツを紹介する前に、まず 仕様把握 という作業を分解してみます。 仕様把握は、 インプット、アウトプット、コミュニケーション という3つの要素に分けられると考えています。 インプット　　　　 …　テストベースから情報を集めること アウトプット　　　 …　インプットした情報を理解して整理し可視化すること コミュニケーション …　会話により情報への理解を深めたり共通認識を作ること この3つの要素を繰り返し行うことで、テスト対象の仕様理解が進み、テスト設計に必要な情報が明らかになっていきます。 これら3つの要素を前提に、私が仕様把握をするときに大事にしているコツを紹介します。 1. ステークホルダーと密にコミュニケーションをとる ステークホルダーとは「プロジェクトに関わる利害関係者」のことです。開発エンジニア、プロジェクトマネージャー、デザイナーなど、そのシステムの開発プロジェクトに関わる人たちを指します。私たちテストエンジニアもステークホルダーの1人です。 仕様把握を効果的に行うには、テストの目的、品質の目標、QA方針といったプロジェクト毎に存在する 決まり事 を知っておく必要があります。また、仕様把握やテスト設計を進める中で、疑問や不明点は必ず出てきます。 これらの 決まり事 を確認したり、疑問や不明点を解消するための、唯一の方法が 他のステークホルダーとのコミュニケーション です。私たちはコミュニケーションを通じて、情報の共有・質問・相談を重ねることで、仕様に対する理解を深め、曖昧さや抜け漏れを解消し、共通認識を作っていくことができます。 この後も仕様把握のコツを紹介していきますが、仕様把握において コミュニケーションを密にとる ということが最も重要なコツであることを、まずお伝えしておきます。 2. 主軸とするテストベースを決める 仕様把握はテストベースを読み解く作業ですが、手当たり次第にドキュメントを読み漁ればいいわけではありません。限られた時間の中で必要な情報を効率よく集めるためには、木の幹となるテストベースを決めておくことが重要です。 V字モデルを例に考えた場合、受入テストは「システムが要求を満たしているかを確認するテスト」なので 要求分析の結果 、システムテストは「システムが要件を満たしているかを確認するテスト」なので 要件定義 を主軸のテストベースとするのが一般的です。 このように、テストの目的に合わせて最適なテストベースを主軸に据えることで、確認するテストベースの優先順位を決めたり、どの程度の理解度が必要かの判断ができるようになります。 注意点として、受入テストやシステムテストといった用語は、組織やプロジェクトによって意味合いが異なる場合があります。なので、ここでもステークホルダーとのコミュニケーションで共通認識を作っておくことが重要になります。 3. 全体を俯瞰できるテストベースから着手する 主軸のテストベースが決まったら、早速そのテストベースから仕様把握を進めたくなりますよね。でも、焦ってはいけません。仕様を効率的に理解するには、どのようなテストベースから確認していくかも重要になります。 では何から着手するのが良いかというと、オススメは画面遷移図やDFD（データフローダイアグラム）といった システム全体を俯瞰して見ることができるテストベース です。 システムの全体像が見えていると、上から下、大から小といった流れでシステムの理解を進められます。このような流れで仕様把握することには、その画面や機能がシステム全体の中でどのような役割を持っているか、ユーザーがどのようにして利用するかといった部分の理解がしやすくなるというメリットがあります。 テストエンジニアは、テストベースに明記された仕様だけでなく 暗黙の仕様 にも配慮します。 暗黙の仕様 とは、ドキュメントに明記されていない隠れた仕様のことです。 システム全体を理解することは、その画面や機能が果たす役割やユーザー視点での理解を助け、要件や仕様の抜け漏れ、隠れたユースケースといった 暗黙の仕様 の発見に繋がります。 システム全体を頭の中でイメージして、テスト対象の振る舞いをシミュレーションできるようになれば仕様把握の上級者です。 4. ドキュメントを読むだけでなく、アウトプットして整理する 仕様把握は、概ねがドキュメントを読む作業です。しかしドキュメントを読むだけで仕様を理解したとするのは、私の経験上おすすめできません。 私たちは、品質保証を目的としたテスト設計をするために仕様把握をしています。前項でも書いたように、ドキュメントに明記された仕様だけでなく暗黙の仕様にも配慮する必要があります。暗黙の仕様を見つけるためには、システム全体を理解しながら仕様把握を行うことが重要ですが、システム全体を頭の中だけで理解していくのは無謀な行いです。 効果的に仕様把握を進めるためには、 理解したことをアウトプットして情報を整理していく ことが重要になります。アウトプットと言っても闇雲にメモすればいいわけではありません。ロジカルにアウトプットすることが仕様の理解を深める助けになります。 ロジカルシンキングという言葉を耳にしたことのある方は多いでしょう。ビジネススキルの定番とも言える思考法で、物事を論理的な繋がりで考えるスキルです。テストエンジニアにとっても優先的に身に着けたいスキルですね。 このロジカルシンキングには、基本的な概念とは別に、様々な思考を補助するツールや技術があります。詳しく書くと長くなってしまうので、ここでは概要と仕様把握におけるメリットに絞って、私がよく利用しているモノを紹介します。より詳しく知りたい方は、書籍やネットで調べてみてください。 ロジックツリー ロジックツリーは、情報を特定のロジックでツリー状に分類して整理するツールです。仕様把握におけるメリットは、画面や機能をツリー構造で整理できることです。画面や機能の関係性が視覚化されてわかりやすくなります。 ですが、ロジックツリーだけでは暗黙の仕様を見つけるには少し足りません。暗黙の仕様を見つけるためには、暗黙の仕様を見つけるための 問い が必要だからです。この 問い を考える時に活用できるのが、次に紹介する2つのスキルです。 フレームワーク思考 フレームワーク思考は、情報をフレームにあてはめて分解・深堀りするためのスキルです。仕様把握におけるメリットは、仕様の抜け漏れを発見しやすくなることです。特定の基準で作った枠組み（フレーム）に仕様をあてはめながら整理するので、仕様に抜け漏れがあると枠が埋まらないため、すぐに気づけます。 例えば、時間に関する機能があれば「過去」「現在」「未来」というフレームを作り、テストベースの情報をそのフレームにあてはめて情報を整理します。最後まで空欄の枠があれば、仕様の考慮漏れや記述漏れの可能性がありますので、ステークホルダーに確認してみましょう。 仮説思考 仮説思考は、現時点の情報から可能性の高い仮説を立てて検証していくスキルです。仕様把握におけるメリットは、隠れた要件やユースケースを発見しやすくなることです。現時点の仕様から導き出した仮説から、明記されていない仕様について検討することで、隠れた要件やユースケースに気づくことができます。 例えば、ユーザーを管理する機能があるとしましょう。管理者が管理するユーザー数をシステム上の最大ユーザー数であると仮定した場合、性能要件がどうなっているか、検索機能や一括処理機能などのユーザビリティに配慮しているかといった疑問が浮かびます。テストベースからその疑問の答えが見つからない時は、隠れた要件やユースケースである可能性がありますので、ステークホルダーに確認してみましょう。 このようにツールやスキルを利用してアウトプットしながら仕様把握を進めることで、テストベースに書かれたことを理解するだけでなく、システムが実現したい本来の姿を明らかにできます。 今回紹介した以外にも、思考を整理したり、情報を分析するためのスキルやツールはたくさんありますので、ぜひ色々試して自分にあった武器を身に着けてください。 5. 自分ひとりで考えない 最後のコツは、 誰かと一緒に考える ということです。 技術職の方には、自分ひとりで黙々と作業するのが好きな方が多いのではないでしょうか。集中して作業することはとても良いことですが、ひとりで考えていると壁に当たった時になかなか抜け出せないこともあります。 システム開発には多くの人が関わっていますので、チームの同僚やステークホルダーと積極的に話してください。 自分の考えたことや気づいたことを、誰かに伝えることで共通認識ができたり、別の角度からの意見が貰えることもあります。また考えがまとまらないときには、誰かに話すことでスルっと思考が整理されたり、新たな気づきを得られる場合もあります。 人と話すことは、最も手軽で効果的なアウトプット です。チームメンバーやステークホルダーに自ら話しかけ、協力関係を育んで、より良いプロダクト品質のために行動しましょう。 さいごに 仕様把握が効果的に行えると、それに比例してテスト設計の品質も高まります。 テスト設計の品質は、高度な仕様把握に基づいたテスト分析によって作りこまれるからです。 今日もどこかのテストエンジニアが、未知のシステムを前に勇気を出して仕様把握の一歩を踏み出していることでしょう。私のこれまでの些細な経験から得られたコツが、少しでも彼らの一歩の助けになり、世の中のプロダクト品質に貢献できれば幸いです。 The post 良い仕様把握は良い品質に繋がる ～仕様把握をする時のコツ ５選を紹介～ first appeared on Sqripts .

こんにちは。プロダクトチームで品質改善に取り組んでいる、QA Maestro K.O.と申します。 自社製品やサービスの売上げを伸ばす方法について悩み、日々奮闘している企業は多いのではないでしょうか。 競争が激化するビジネス環境において、ユーザーの期待を上回る品質は市場を制する鍵になり得ます。 自社が提供するサービスを自らが使用し、その品質を常に向上させることは、顧客満足度向上に繋がり、競争優位性を築く秘訣となるでしょう。 この記事では、サービスの品質向上のための有効な施策の一つである「ドッグフーディング」について詳しくご紹介します。 また、QAエンジニアが行うドッグフーディングについても記載しました。 売上にお悩みの方や、製品の価値を高めたいQAエンジニアの方のご参考になれば嬉しく思います。 ドッグフーディングとは ドッグフーディングとは、製品やサービスの開発者や内部関係者が、自らが開発した製品を実際に使用し、評価するプロセスです。つまり、開発者や関係者が、自分たち自身で一般のユーザーと同じように製品を利用し、その品質や性能を評価し、改善に役立てることを指します。 「ドッグフーディング」という名前の由来 由来は諸説あるようですが、ドッグフードの販売を手がける企業の社員が、自分が飼っていた犬にドッグフードを食べさせていたというエピソードが語源と言われています。 その後、Microsoftの従業員の一人が、自社の製品を自分たちで使うアイデアを説明する際に「Eating our own Dogfood」という比喩的な表現を用いたことから、「ドッグフーディング」という用語が社内で広まり、「ドッグフーディング」は内部での製品使用と評価を指す言葉として広く受け入れられるようになりました。 では、自社製品やサービスを自ら利用することにどのような意義があるのでしょうか。 ドッグフーディングのメリット ここでは、ドッグフーディングを実施するメリットとして広く知られているものをいくつかご紹介していきます。 製品品質と顧客満足度の向上 開発者や企業内のステークホルダーが日常的または正式リリース前に自社の製品を利用することで、ユーザーエクスペリエンスにおいて発生する潜在的な問題や改善点を直感的に把握できます。 これにより、不具合や改善点を事前に発見し、顧客がより満足するであろう製品品質に近づけることができます。 高い品質を備えた製品はユーザーに信頼感を与え、顧客満足度の向上も期待できるでしょう。 また、製品の品質や顧客満足度の向上は、競争の激しい市場で競合他社との差別化を図るための重要な要素となります。 競争優位性の確立 自社の製品を積極的に利用することで、他社製品との差別化ポイントや自社製品の優れたユーザーエクスペリエンスを見つけ出しやすくなります。 たとえば、競合他社の製品よりも高速で信頼性が高く、使いやすい新しいスマートフォンを開発した場合、この製品は競争優位性を持つこととなります。 また、競争力のある製品を提供することで、市場での価格競争を回避し、付加価値を提供することも可能となるのです。 このように、ドッグフーディングによる自社製品の品質や顧客満足度の向上は、製品の信頼性や競争力が向上するなど、ビジネスの長期的な成功へ大きく影響し、市場での成功を支える要因となります。 品質向上以外のドッグフーディングのメリット 品質向上以外にも、ドッグフーディングにはさまざまな利点が存在します。 従業員やステークホルダーが製品を自身で使用することにより、製品に関する理解が深まり、マーケティングやカスタマーサポートなどの役割においても、より効果的にユーザーに対応できるようになります。 また、実際に使い込むことで自社製品に対する愛着やコミットメントが高まり、各部門が一体となって製品の成功に貢献することも期待できるのではないでしょうか。 このように、ドッグフーディングは製品やサービスに多くのメリットをもたらす重要な取り組みであるといえます。 QAエンジニアが行うドッグフーディングについて考えてみた 品質管理の専門職であるQAエンジニアは、製品品質やユーザーエクスペリエンスの最適化を目指すドッグフーディングとの相性が良いと考えられます。 QAエンジニアがドッグフーディングを行う利点 テストや品質管理などを得意とするQAエンジニアがドッグフーディングを行うと、以下のような効果が期待できるでしょう。 バグと改善点の早期発見 QAエンジニアが製品を実際に使用することで、一般ユーザーが遭遇する可能性のあるバグや課題の早期発見がしやすくなるでしょう。 これにより、開発段階での修正が行いやすくなり、リリース後のトラブル減少に貢献することができます。 ユーザーエクスペリエンスの最適化 QAエンジニアはユーザーエクスペリエンスを向上させるための提案や改善点の提供を得意としています。 質の高いフィードバックにより、製品の使いやすさや顧客満足度の向上に寄与することが可能です。 テストケースの充実 QAエンジニアが実際に製品を探索的に使用することで、予め用意することが困難なテストケースやテストシナリオを作成し、テストカバレッジを増やすことができます。 このことは品質保証の精度向上につながり、製品の信頼性を高めることに貢献します。 将来のQAエンジニアリングとドッグフーディングの可能性 将来においてQAエンジニアとドッグフーディングの関係にはどのような可能性が考えられるでしょうか。 QAエンジニアリングの業界でも、今後、AIや自動化技術を活用したQAテストツールの進化が期待されていますが、これらのツールでユーザーエクスペリエンスを担保することは難しいのが現状です。 したがって、QAエンジニアがユーザー視点からソフトウェアを評価し、フィードバックを提供する役割は重要であり、QAエンジニアが新しいテクノロジーを活用した品質保証を行う未来においても、ドッグフーディングは不可欠な要素となることが予想されます。 また、ユーザーの多様なニーズに対応するために、QAエンジニアがソフトウェアやサービスを多角的に評価し、改善を推進する役割としての需要も将来的に増していくでしょう。 では、ドッグフーディングを効果的に実施するためにはどのような点に注意するとよいのでしょうか。 ドッグフーディングの実践に向けて これまでも紹介してきた通りですが、実際に製品を利用し、その使用体験からフィードバックを得ることはドッグフーディングの中核的な要素です。 ここでは、効果的なドッグフーディングを実施するための要素をいくつかご紹介します。 ユースケースシナリオの検討 ドッグフーディングを行う際には、製品やサービスの様々なユースケースやシナリオを検討することも重要な要素となります。 異なる利用状況での振る舞いや問題点を特定し、幅広いユーザー層の要求に適合するように改善を行うことが可能になるためです。 ユースケースの多様性を考慮することで、製品の汎用性を向上させることができます。 レアケースのテスト こちらは優先度は低くなることが多いですが、通常のユースケースシナリオだけでなく、稀なケースや特殊な状況に対するテストを意識的に行うのもよいと思います。 一般的でない問題やエッジケースでのバグを特定することは、製品の信頼性と安定性を高めるために必要なステップとなります。 たとえば、モバイルアプリケーションのドッグフーディングでは、通信状況が不安定な地域での利用などがこれにあたります。 チームへのドッグフーディングの普及 ドッグフーディングを個人で行うのもよいのですが、チーム全体で実施するとより大きな効果が期待できます。 チームでの実施により、より多くの視点と洞察を得ることができ、多角的な評価と改善を行いやすくなるためです。 ドッグフーディングの重要性をチームメンバーに伝え、定期的なドッグフーディングセッションの企画・ユーザーフィードバックの収集を行うなど、積極的な参加を促す工夫をすることが成功の鍵となります。 ドッグフーディングの継続と改善 ドッグフーディングは一度だけの実施ではなく、継続的に取り組むことが重要です。 フィードバックと改善のサイクルを確立することで、製品やサービスを継続的に進化させていくことが可能となるためです。 このサイクルを継続することで、ユーザーの期待に応じつつ、製品品質と競争力の継続的な維持に寄与できます。 これらの要素から自分のチームの状況に合ったものを取り入れ、実践的なドッグフーディングプロセスを構築することで、成功へ一歩近づくことができるはずです。 ドッグフーディングの課題点 ドッグフーディングを行うことで多くのメリットが得られる一方、注意すべき点も存在します。 製品やサービスの開発チームでドッグフーディングを行う場合、仕様を理解していたり、現在の仕様になるまでの経緯を知っていることで先入観が生まれ、初見のユーザー視点での改善点が挙げづらくなることがあります。 また、ステークホルダーなどの従業員から集まったフィードバックが、一般のユーザーや顧客の期待とは異なる可能性もあります。 このように、ドッグフーディングにはバイアスの問題が存在することには注意が必要です。 バイアスを軽減するためには、多様な従業員の選定や外部ユーザーのフィードバックを取り入れることが重要です。 開発チーム内で実施する際には、開発完了してから少し時間をおいたり、類似プロダクトを触るなどした後、改めて自社製品を触るとバイアスが軽減され、改善点を挙げやすくなるかもしれません。 ドッグフーディングの小ネタ 最後に個人的に効果があった、テスト業界の知識がなくても誰でも簡単にできるドッグフーディングの小ネタを紹介して、今回の記事を終わりにしたいと思います。 それは「 サービスを使った作業をタイムアタックで行う 」というものです。 たとえば、Webアプリケーションのドッグフーディングを行う場合を考えてみましょう。 Webアプリケーションは、基本的には業務などを効率的に行うために作られるサービスです。 ということは、手早く作業ができるWebアプリケーションは使い勝手がよいと評価されやすく、つまり、短時間で作業を完了させようとした際に、操作に迷ったり面倒な操作があれば、それは改善ポイントとなる可能性が高いというわけです。 対象のシステムにも依りますが、 ショートカット的な機能が欲しい ボタンの配置がこうなっていれば、もっと早く操作できるのに この機能は頻繁に使うから、もっとレスポンスを…！ というような改善点を挙げやすくなります。 とても簡単なことですが、意識するのとしないのでは改善点の気付き方も大きく変わってくると思います。気になる方は是非試してみてください。 おわりに ドッグフーディングは、自社製品やサービスの品質を改善する強力な手段の１つです。 競争が激化するビジネス環境において、ユーザーの期待を上回る品質は市場を制する鍵になり得ます。自社が提供するサービスを自らが使用し、その品質や顧客満足度向上に繋げるドッグフーディングは、このような状況下で非常に効果的なアプローチとなります。 ドッグフーディングは、製品やサービスの改善だけでなく、従業員が製品に関する理解を深め、各部門が協力して製品の成功に貢献する効果も期待できるでしょう。 この記事がドッグフーディング導入のきっかけとなったり、自社製品やサービスの開発に携わる方々の参考になれば幸いです。 The post 品質を制する者は市場を制す？サービス改善のためのドッグフーディング戦略 first appeared on Sqripts .

テストエンジニアが身につけておきたいスキルの一つに「論理スキル」があります。 この連載では、「プログラムのレベル」「文や文章のレベル」に分けて、論理スキルの基本である「論理の言葉」を徹底解説します。 第2回から第4回は、「論理の言葉」の基本でもあり、プログラムのレベルで働く論理の基本でもある 論理演算 を見ていきます。 連載第1回はこちら [第1回] なぜ、テストエンジニアに(も)論理のスキルは重要なのか ［連載初回全文公開中：Sqripts会員以外の方も全文お読みいただけます］ 筆者のnoteサイトで、「論理スキル[再]入門」を書こうと思った理由・経緯を綴っています。 ■ 論理スキル・“入門編”のこと　(T3:Pt1:Ch01) よろしかったらご覧ください。 論理演算はソフトウェアエンジニアの必修科目、だが…… プログラミング言語には実行の流れを制御するための条件分岐を司る仕組みが具わっています（簡単に言うとif文です）。 条件分岐の判定箇所にはひとつ以上の 条件式 を置く（「条件式」は本記事独自の呼称です） 典型的な条件式は、値の大小の比較や、等式/不等式。x > 10、y == 0、など 条件式は「 真 ( true 。成り立つ、満たす、当てはまる)」か「 偽 ( false 。成り立たない、満たさない、当てはまらない)」かどちらかの値を取る 条件式の取る値は 真か偽かいずれかのみ 。 また、「真であり、同時に偽でもある」ことはない（ 真でなければ偽。偽でなければ真 ）  この「真」と「偽」を 真理値(真偽値) と呼ぶ 判定の真偽で分岐先が決まる 判定箇所で複数の条件式の組合せを扱う場合や、真偽を反転して考えたい場合が(かなり頻繁に)あります。そこで活躍するのが 論理演算 です。 論理演算 とは、真理値を入力として、結果の真理値を出力する仕組みのこと（図2-1） 基本となる論理演算は 否定(NOT)、論理積(AND)、論理和(OR) の三つ（第3回で解説します） プログラミングには必須の要素なので、言語の学習には必ず含まれるほか、情報処理技術者試験のシラバスにも含まれています。 が、論理演算は憶えればそれで十分というものではありません(-ω-;)。 その後ずっと秘かにソフトウェアエンジニアについて回り、苦しめる存在です。というのは、論理演算はやりたいことに正しく合わせなければいけませんが、そこで起こるのが“ロジックミス”などと呼ばれるエラー(誤り)です。 （“ロジックミス”のすべてが論理演算の使い方によるものではありませんが、論理演算を誤ると“ロジックミス”に直結します） 論理演算がらみのエラーは、“修行”を積めば犯さなくなる……ということはなく、ベテランでもエラーを犯します(以下、いずれも当社比)。 仕様の記述を「条件を否定したif文にするとロジックをすっきり書ける」と思って、間違える 仕様の記述を“勘違い”したまま設計～実装に落とすこともある コードをデザイン/実装する時は「正しく解釈した」と思っていても、後でレビューで指摘、あるいはテストで故障が見つかって、愕然とすることもある まずいことに自分が考えたロジックに自信を持ってしまうと、自分のミスに自分で気づきにくくなる このエラーを根本的になくす方策はありません（と、筆者は思っていますが）。すなわち、 バグの種は尽きない ということになります(´・ω・｀) そのようなバグをできるだけ見つけるためにも論理演算の働きは理解しておきたいところです。 論理演算の言葉が重要である理由 ソフトウェアにとって“ロジックミス”が生じやすい、ということを除いても、 否定、論理積、論理和に相当する言葉は、ソフトウェアの仕様記述のレベルでもよく使われ、仕様を理解する場合やテストを考える際の手がかりになります。 一般的な文章や日常生活で使われる言葉にもあり、人の話や文章の筋道を辿ったり、自分の話や思考の筋道を組み立てたりする際に重要な役割を果たします。 具体例 論理演算が絡む「ロジックのミス」や、テストを考える際に論理演算の知識がどう関係するか、具体例で見てみましょう。 忍び寄る“ロジックミス”のごく単純な例 「利用者の年齢(入力値)が18以上の場合のみ、利用可能。18未満の場合、利用を拒否する(先には進まない)」といった仕様があるとします。 これをプログラム(疑似言語)で書くとこんな感じになりますが： if age >= 18 then 　　.... (利用可能な場合のコード) else 　　... (利用拒否) end if “>=”と書くところを”>”と書いてしまう、ということが起こります(以降、いずれも当社比)。タイプミスもあり得ますし、「仕様を勘違い」することもあります（もっとも、これは論理演算とは関係ありませんね）。 「利用拒否される場合(18歳以上でない)はそこで打ち切りにすればコードがすっきりする」と考えれば、「>=(等しいか大きい)」を否定してこう書くこともできるでしょう（第3回参照）： if age < 18 then 　　... (利用拒否。処理打ち切りで先に進まない) end if ... (利用可能な場合のコード) ここで、<と書くつもりでいて実際には>=のまま、ということが起こりますが、これを論理演算の誤りと呼ぶのも違うかも知れません。しかし、 「>=の否定」を間違えて<=とするということも起こります。 「利用可能でないなら」という表現を“活かそう”と”NOT(age >= 18)”と書くつもりでいて、”NOT”を書き忘れて”if (age >= 18) then …”としてしまう、ということも起こります。 もっと複雑な条件になると、よりいっそうエラーが紛れ込みやすくなります。 ISTQB Foundation Levelシラバス 4.0 の境界値分析(4.2.2)で「開発者はこれらの境界値に関してエラーを犯す可能性が高い」としている通り、ここに挙げた“エラー(誤り)”とその結果としてのバグ(欠陥)は、いずれも「利用可能な年齢」の境界に絡みます。境界値分析はこうしたバグを見つけるのに適したテスト技法です。 テストを考える時に働く論理演算 入力ファイルから1文字ずつ読み出して、出力ファイルに書き出すプログラム(ファイルのコピー)があるとします。 入力ファイルが開けない場合（ファイルが存在しないか、存在するが読み出しが許可されていない）は、何も書き出さずに終了する（空の出力ファイルを作らない）。 入力ファイルが空の場合は、何も書き出さずに終了する（空の出力ファイルを作らない）。 このプログラムをテストするには、どんな場合をテストするとよいでしょうか。 ………… 出力ファイルが作られるのは以下の場合です（太字部分が論理演算の言葉で、論理積(AND)や論理和(OR)というものになります。第3回参照）。 入力ファイルを開くことができ、 かつ 、ファイルの内容が空でない場合 出力ファイルが作られない場合には、次の2通りがあります。 入力ファイルが開けない（開けない場合には次の2通りがあります） ファイルが存在しないか、 または 、存在するが読み出しが許可されていない 入力ファイルを開くことができ、 かつ 、ファイルの内容が空である それぞれをテストすることになるでしょう。 （ 具体的にどんなファイル を用意するとよいか、考えてみてください！） むすび 論理演算の概要と、論理演算の言葉を知っておく意義をお話ししました。 次回第3回では否定(NOT)、論理積(AND)、論理和(OR)の意味と働き、続く第4回では、論理演算の組合せという話題を取り上げます。 参考文献 情報処理技術者試験　IT パスポート試験シラバス　Ver.6.2 （PDF） 情報処理技術者試験　基本情報技術者試験（レベル２）シラバス （PDF） 情報処理技術者試験　応用情報技術者試験（レベル３）シラバス （PDF） 『プログラミング言語C　第2版』(カーニハン, リッチー / 共立出版) 『プログラミング言語AWK』(エイホ, ワインバーガー, カーニハン / USP研究所) JavaScript リファレンス (Webページ) Python 言語リファレンス (Webページ) 『ソフトウェアの信頼性』(マイヤーズ / 近代科学社) 連載一覧 [第1回] なぜ、テストエンジニアに(も)論理のスキルは重要なのか 【連載初回、全文公開中】 [第2回] プログラムレベルのロジック (1)概要編 The post [第2回] プログラムレベルのロジック (1)概要編 first appeared on Sqripts .

こんにちは。性能テストグループのけんです。この記事では私が主に担当している性能テストについて、引き続き共有していきます。 前回の投稿 ではテストパターン（ロードプロファイル）の構成要素について説明しました。 今回は、構成要素の中で重要となる負荷量ついて説明していきたいと思います。 ＜ 性能テストのススメ 記事一覧 ＞ ※クリックで開きます #1 性能テストの目的と種類 #2 テスト計画 #3 対象シナリオ（運用プロファイル） #4 テストパターン（ロードプロファイル）第一章_構成要素 #5 テストパターン（ロードプロファイル）第二章_負荷量（入門編） スレッド数とスループット 性能テストにおいて適切な負荷量を設定するためには、スレッド数とスループットについて理解する必要があります。 ISTQBのシラバスでは、コンカレンシー（スレッド）とスループットについて以下の説明があります。 ワークロードの異なる側面であるスループットとコンカレンシーを理解することは重要である。 運用プロファイルとロードプロファイルを適切にモデル化するには、両方の側面を考慮すべきである。 参考文献： 「ISTQB テスト技術者資格制度 Foundation Level Specialist シラバス 性能テスト担当者 Version 2018.J01」 要約すると以下になります。 ・スレッドとスループットは別物なのできちんと理解しないといけないよ ・対象シナリオとテストパターンを決定するためには両方を考慮するべきだよ スレッドとスループットについては 前回の投稿 で説明しましたが、実際にはイメージしづらい部分もあるかと思いますので、今回は詳しく説明していきたいと思います。 握手会から学ぶスレッド数とスループットの関係 突然ですが、問題です。 【問題】 架空のアイドルグループAGT48 ※1 の握手会があります。 握手会には最大で300人の客が参加します。握手会の制限時間は60分です。 時間内に参加者全員が入退場するためには入場のための受付レーンを何列設置すればよいでしょうか。 【前提条件】 1. 入場から退場までにかかる想定時間は（受付を含め）1人あたり3分 2. 受付レーンから会場に入場できるのは1列あたり1人までで、1人が退場した直後に次の人が入場 ※1 AGT48は架空のアイドルグループですが、AGEST（当社）のアイドル「こころちゃん」（画像右上）はデジタルコンシェルジュとして社内で活躍しています。 こころちゃんについては「 Cloud FunctionsとSlack APIに踊らされたSlack Bot作成 」をご確認ください。 解けましたでしょうか？ここでヒントです。 【ヒント】 (1) 受付レーン1列で60分間あたり何人が入退場できるのか (2) 60分で300人を捌くためには、(1)を踏まえた上で受付レーンを何列用意すべきか ※注意※ 下の画像の後がすぐ答えになります。もう少しお考えになりたい方はスクロールしないようにしてください。 答えは以下の通りです。 （1）受付レーン1列で60分間あたり入退場できる人数は.. 　　　　↓ 　　60[分]（制限時間）/ 3[分]（1人あたりの入退場時間）＝ 20[人] （2）受付レーン1列で20人が入退場できるとして、300人を入退場させるためには.. 　　　　↓ 　　300[人]（客総数）/ 20[人]（1受付レーン60分あたりの入退場数）= 15[列] 正解は15列でした。 性能テストに置き換えると… 先ほどの例題は性能テストで負荷量を検討する際の基本となります。それでは例題の内容を性能テストに置き換えて解答していきたいと思います。 握手会場を対象システムに置き換え、握手会場に客が入場してから退場するまでにかかる時間を計測対象範囲とした場合、以下の様になります。 問題例 性能テストに置き換えると 握手会場 対象システム 握手会場に入場してから退場するまでの動線 トランザクション 握手会場に入場してから退場するまでの時間 トランザクションのレスポンスタイム 受付レーンの数 スレッド数 時間あたりの入退場者数 スループット これらを置き換えて図にすると以下の通りです。 例題の解き方も置き換えてみます。 (1) 1つの受付レーンで60分間あたり何人が入退場できるのか 　　　　↓ 　　1スレッドで60分間あたり何トランザクション実行できるか 　　　　↓ 　　60[分]（時間範囲）/ 3[分]（1トランザクションの処理時間）＝ 20[トランザクション] (2) 60分で300人を捌くためには、(1)を踏まえた上で受付レーンを何列用意すべきか 　　　　↓ 　　60分で300トランザクションを実行するためには、(1)を踏まえた上で何スレッド用意すべきか 　　　　↓ 　　300[トランザクション/60分] / 20[トランザクション/60分] = 15[スレッド] スレッドを算出するために、目標となるスループット（300[トランザクション/60分]）を確認した上で、1スレッドの時間あたりの実行可能な回数（時間範囲/ 1トランザクションの処理時間）を算出してから必要なスレッド数を算出する、という流れになります。 60分あたりのスループットで計算していますが、実際のスループット要件は分間、できれば秒間と、短い単位で算出することが好ましいです。なぜなら、例題では範囲時間が60分と決まっていましたが、範囲時間は今回の様に必ずしも定まっていないことが多いからです。1スレッドで1分あたりのスループットが算出できていれば、範囲時間（負荷継続時間）が変わったとしてもスレッド数の算出が容易となります。 以上を踏まえ、1分あたりのスループットを元に計算してみます。 目標スループット（300[トランザクション/60分]）を分間にすると... 　　　　↓ 300[トランザクション] / 60[分] = 5[トランザクション/分] 1スレッドで1分間あたりのトランザクション実行回数は... 　　　　↓ 1[分] / 3[分]（1トランザクションの処理時間）＝ 0.3333...[トランザクション/分] 目標トランザクションを達成するために必要なスレッド数は... 1分あたりの目標スループット / 1スレッドで1分あたりのスループット = 必要スレッド数 　　　　↓ 5[トランザクション/分] / 0.333...[トランザクション/分] = 15[スレッド] これが汎用的なスレッド数の計算方法となります。 もし上記から条件が変わり、範囲時間（負荷継続時間）が60分→100分に変更となった場合でも、1スレッドあたりの分間スループットが算出済みであれば以下の様に適用できます。 目標スループット（300[トランザクション/100分]）を分間にすると... 　　　　↓ 300[トランザクション] / 100[分] ＝ 3[トランザクション/分] 目標トランザクションに達するために必要なスレッド数は... 　　　　↓ 3[トランザクション/分] / 0.333...[トランザクション/分] = 9[スレッド] ポイント 今回は時間あたりの目標となるスループットを元にスレッドを算出するための方法をお伝えしました。 ※2 この方法では以下の３つが必要となります。 スループット（時間あたりのトランザクション処理数）の予測値 対象シナリオ1回あたりの所要時間予測（上記の例では「対象シナリオ1回 = 1トランザクション」として置き換えていました） 対象シナリオに含まれるトランザクション数（上記の例では1トランザクションのみでしたが、実際には複数のトランザクションが存在するのが一般的です） 注意点として、1と2は予測値であるということです。これらはリクエストの応答速度によって変動します。 変動要因としては、負荷をかけた影響によってシステム側のいずれかの処理で遅延が発生することです。 そのため正確な数値は計測するまでわかりません。どこまでの誤差が許容されるかで大きく違いはありますが、1回のテストで想定通りのスループットを出すことは難しいことをご理解いただけると幸いです。 ※2 負荷生成ツールによってはスループットを指定して実行する機能もあるので、それを利用することも選択肢の一つです。（考慮する観点が変わるため説明は割愛します） スレッド数の算出方法は今回紹介した方法以外にも存在します。以下は一例です。 ・同時アクセスユーザー数とスループットの両面で算出する場合（ユーザー数＝スレッド数とし、シナリオ内でスループットを調整） ・同時アクセスユーザー数のみで定義する場合（ユーザー数＝スレッド数とするが、実運用想定となる負荷量との乖離は大きい） ・システムが保持する同時セッション数で定義する場合（時間あたりのセッション数＝時間あたりのシナリオ実行回数） 性能テストで適切な負荷量を設定するためには、必要な情報をできる限り収集することが重要です。 さいごに 今回は負荷量について説明しましたが、まだまだ基礎的なお話となっているので引き続き連載していきたいと考えています。 次回記事もどうぞよろしくお願いいたします。 連載一覧 性能テストのススメ #1　性能テストの目的と種類 性能テストのススメ #2　テスト計画 性能テストのススメ #3　対象シナリオ（運用プロファイル） 性能テストのススメ #4　テストパターン（ロードプロファイル）第一章_構成要素 性能テストのススメ #5　テストパターン（ロードプロファイル）第二章 負荷量（入門編） The post 性能テストのススメ #5 テストパターン（ロードプロファイル）第二章 負荷量（入門編） first appeared on Sqripts .

AI が急速な進化を続ける中、各企業や私たちはその流れに遅れないようにする必要が出てきました。最先端の機械学習アルゴリズムから自然言語処理の進歩に至るまで、これらのトレンドは産業や私たちの日常生活を再構築する可能性を秘めています。 2023年以降も成熟する AI 市場に対して、私たちはAIをテストするという視点からAIに対してアプローチをしていきます。 AIテスティング(CT-AI)コースの紹介 今回紹介するのは、 ISTQB(テスト技術者資格制度) の　Foundation Level シラバス-AI テスティング (CT-AI)のトレーニングコースについてです。 一言で纏めてしまうとISTQBの資格取得用のトレーニングコースになるのですが、ソフトウェアテストの分野では世界的な権威でもある スチュアート・リード博士 がトレーナーを担当しており、博士の深い見識からもたらされるAIシステムにおけるテストの考え方を深く学ぶことができ、貴重な体験を得られます。 参考記事 【特集】AIのリスクベーステスト／スチュアート・リード博士 コース時間は12時間に及ぶコンテンツになっております。AI全般の技術や深い理解を醸成し、その実用化に向けて重要な洞察を提供してくれます。 内容は直接、ご覧いただきたいと思いますので、ここでは簡単な概要を紹介いたします。 セッション1：AIへの紹介 AIの基礎と導入に関する内容 AIの中核技術をお伝えし、GDPRのような法規制や特化型AI、従来の非AIとの違いなどを紹介。 キーワード ： 適応性、アルゴリズムバイアス、自律性、バイアス、進化、説明可能性、説明可能な AI（XAI）、柔軟性、不適切なバイアス、解釈可能性、ML システム、機械学習、報酬ハッキング、堅牢性、サンプリングバイアス、自己学習型システム、副作用、透明性 セッション2：AIベースのシステムの品質特性 AIシステムの特に重要な品質特性について学び、ユーザーがAIシステムをどのように信頼するかを紹介。 キーワード ： 適応性、アルゴリズムバイアス、自律性、バイアス、進化、説明可能性、説明可能な AI（XAI）、柔軟性、不適切なバイアス、解釈可能性、ML システム、機械学習、報酬ハッキング、堅牢性、サンプリングバイアス、自己学習型システム、副作用、透明性 セッション3：機械学習（ML） – 概要 機械学習の概要、モデルの評価やチューニングなどのワークフロー、機械学習モデルを利用した演習を通じて理解を深める。 キーワード ： アソシエーション分析、分類、クラスタリング、データ準備、ML アルゴリズム、ML フレームワーク、ML 機能性能基準、ML モデル、ML 訓練データ、ML ワークフロー、モデル評価、モデルチューニング、外れ値、オーバーフィッティング、回帰、強化学習、教師あり学習、アンダーフィッティング、教師なし学習 セッション4：ML – データ MLにおけるデータの取得、準備、前処理の重要なステップ。 キーワード ： アノテーション、データ拡張、分類モデル、データラベリング、データ準備、ML 訓練データ、教師あり学習、テストデータセット、検証データセット セッション5：ML機能パフォーマンスメトリクス 機械学習の評価指標に関する詳細な情報や算出方法の説明。 キーワード ： 正解率、AUC、混同行列、F1 スコア、クラスター間メトリクス、クラスター内メトリクス、平均二乗誤差（MSE）、ML ベンチマークスイート、ML 機能パフォーマンスメトリクス、適合率、再現率、ROC(受信者動作特性)曲線、回帰モデル、R2 乗、シルエット係数 セッション6：ML – ニューラルネットワークとテスト ディープニューラルネットワーク（DNN）などの基本的なキーワードを取り上げ、多層パーセプトロンやニューロンカバレッジのような高度なテクニックを紹介。 キーワード ： 活性値、ディープニューラルネットワーク（DNN）、ML の訓練データ、多層パーセプトロン、ニューラルネットワーク、ニューロンカバレッジ、パーセプトロン、符号変化カバレッジ、符号-符号カバレッジ、教師あり学習、閾値カバレッジ、訓練データ、値変化カバレッジ セッション7：AIベースのシステムのテスト概要 AIベースのシステムのテストに関する概要と課題について触れ、またコンセプトドリフトやデータパイプラインといったテストの際に考慮すべき事項について紹介。 キーワード ： AI コンポーネント、自動化バイアス、ビッグデータ、コンセプトドリフト、データパイプライン、ML 機能パフォーマンスメトリクス、訓練データ セッション8：AIに特化した品質特性のテスト AIの品質を評価するための特定のテスト技術と考え方を探求し、バイアスの検出、自律的なシステムの挙動、さらには解釈可能性や透明性を評価する方法など、AIの品質を確保するための多岐にわたるトピックを網羅。 キーワード ： アルゴリズムバイアス、自律型システム、自律性、エキスパートシステム、説明可能性、不適切なバイアス、解釈可能性、LIME 法、ML 学習データ、非決定論的システム、確率論的システム、サンプリングバイアス、自己学習型システム、透明性 セッション9：AIベースシステムのテストのための方法と技法 AIベースのシステムのテストに関するさまざまな方法と技術の紹介 AIで利用されるケースが多い、A/Bテストや敵対的テスト、メタモルフィックテストなども取り扱う。 キーワード ： A/B テスト、敵対的テスト、バックツーバックテスト、エラー推測、経験ベースのテスト、探索的テスト、メタモルフィック関係（MR）、メタモルフィックテスト（MT）、ペアワイズテスト、疑似オラクル、テストオラクル問題、ツアー,敵対的攻撃、敵対的サンプル、データポイズニング、ML システム、学習済みモデル セッション10：AIベースのシステムのテスト環境 テスト環境に関する詳細なガイド ここでは自動運転車を例に取り上げ、仮想テスト環境のメリットやデメリットについての紹介。 キーワード ： 仮想テスト環境、AI 専用プロセッサ、自律型システム、ビッグデータ、説明可能性、マルチエージェントシステム、自己学習型システム セッション11：テストにAIを使う テストプロセスにAIをどのように組み込むか、および実際の演習を通じての学び。 キーワード ： ビジュアルテスト、ベイジアン手法、分類、クラスタリングアルゴリズム、欠陥予測、グラフィカルユーザーインターフェース（GUI） 1. AI業界のこれから AIは現代のエンジニアリング分野において重要な役割を果たしており、その市場規模は急速に拡大しています。 特に生成AIの経済的ポテンシャルに関するマッキンゼーのレポートを要約すると生成AIの導入は、世界経済に年間約2.6兆ドルから4.4兆ドルの価値をもたらす可能性があり、現在使用されているソフトウェアに組み込まれることで、その価値はさらに2倍になる可能性があります。 生成AIはすべての産業構造に著しい影響を与えると予測されており、顧客サービス、マーケティング、販売、ソフトウェアエンジニアリング、研究開発などの分野で特に大きなビジネス価値を提供することが予想されています。 いくつかのユースケース分析を通じて、AIが様々なビジネス課題に対処し、測定可能な成果を出すことが示されています。 生成AIは労働市場にも影響を及ぼし、現在従業員が行う作業の60～70%を自動化する可能性があることから、仕事の構造を変化させることが予測されています。 この技術の自動化の可能性は、特に自然言語理解の能力が向上することにより加速しています。 この移行は労働者に新しいスキルの習得や職業の変更を要求し、それをサポートするための投資が必要と示しています。 このようにテクノロジーの絶え間ない進歩により、将来的にはさらに大きな進歩が期待でき、未来を形作る上でテクノロジーがますます重要な役割を果たすことは間違いありません。 参考： 2023年 国内AIシステム市場予測を発表 参考： The economic potential of generative AI: The next productivity frontier 生成型 AI の経済的可能性: 次の生産性フロンティア(マッキンゼーの見解) では将来に向けてどのように備えればよいでしょうか? 私たちは更に認識を広め、自分自身を教育していくことを継続していく必要があると思います。 AIは反復的なタスクを自動化し、人間の時間を節約するという驚異的な能力を備えてくれています。 これは私たちがより複雑で創造的な取り組みに集中するのに役立つツールだということです。 AI はさまざまな業界の多くのデータ分析に役立ち、あらゆるタスクを最適化し、効率とコスト効率を高めてくれると思います。 AIの未来は明るく、適切なアプローチをとれば、私たちは AI テクノロジーの進歩の恩恵を受けながら、その課題にも取り組むことができます。 AIテスティング(CT-AI)コースは、この急成長している分野でのキャリアを志向するエンジニアにとって、必要な知識と技術を習得する絶好の機会を提供します。 このコースでは、AIの基本原理から最先端の応用に至るまで幅広いトピックが網羅されており、特にAIベースのシステムの品質特性やテスト方法に重点を置いています。 参加者はAI技術の進歩に対応するための実践的なスキルと理解を深めることができます。 2. AIシステムのテストや評価の難しさについて コースにおいてもAIシステムのテストや評価の難しさを取り上げています。 これらの要因は、AIの複雑性、不透明さ、そして動的な性質から生じるものです。 以下に、これらの要素をいくつか紹介し、機械学習システムの失敗例とテストの重要性を示します。 【AIの複雑性とブラックボックス問題】 問題 説明 複雑性とブラックボックス問題 AIシステムは通常「ブラックボックス」と見なされ、システムがどのようにして特定の出力や決定に至ったかを外部から理解することは困難です。 ニューラルネットワークなどのモデルは数百万のパラメータを持ち、これらが最終出力にどう影響するかの理解は難しいです。 データ依存性 AIモデルは訓練データに大きく依存しており、データセットに偏りがある場合、不正確な結果を出す可能性があります。 訓練データと異なる新しいデータに対する反応を予測するのは難しいです。 動的な学習プロセス 多くのAIシステムは新しいデータから学習を続け、システムの振る舞いが時間と共に変化する可能性があります。 この動的な学習プロセスはテストや評価を継続的に行う必要があり、大量の資源を消費する可能性があります。 解釈可能性と透明性 AIシステムの決定を人間が理解し信頼するためには、その決定過程を説明できる必要があります。 解釈可能性と透明性の欠如はテストと評価を複雑にします。 エラーの特定と修正 AIシステムが誤った決定をした場合、その原因の特定と修正は難しく、AIモデルの規模が大きく複雑であればあるほど困難です。 不確実性とリスクの管理 AIシステムには確率的要素が含まれ、予測や決定に不確実性が伴います。 この不確実性を適切に管理し、リスクを最小限に抑えることはAIテストと評価の重要な課題です。 【機械学習(ML)システムの失敗例】 問題 説明 偏ったデータセット ある人種や性別に偏ったデータセットで訓練された顔認識システムは、特定のグループに対して誤った識別を行うことがあります。 これは偏見を持った意思決定につながり、社会的な不公平を生じる可能性があります。 オーバーフィッティング 訓練データに過度に適合したモデルは、新しいデータに対してうまく機能しない可能性があります。 これは、モデルがトレーニングデータのノイズやランダムな変動を学習してしまうためです。 リアルタイムデータへの適応の欠如 市場予測のモデルが過去のデータに基づいて構築され、市場の新たな動きに迅速に適応できない場合、不正確な予測を行うことがあります。 不十分なテストと検証 医療診断をサポートするために設計されたMLシステムが、十分な検証を経ずに臨床環境で使用されると、誤診や治療の遅れを引き起こす可能性があります。 【テストの重要性】 テストの重要性 説明 バイアスの低減 テストは、モデルの決定に偏りがないことを確認するために不可欠です。 これにより、公平で倫理的なAIシステムの構築が可能になります。 汎化能力の評価 モデルが新しい、未知のデータにうまく対応できるかどうかをテストすることで、その汎化能力を評価します。 パフォーマンスの検証 正確性、再現率、適合率などのメトリクスを用いて、モデルのパフォーマンスを検証します。 これにより、特定の用途に対してモデルが適切かどうかを判断できます。 安全性と信頼性の保証 特に医療、金融、自動運転車などの分野では、モデルの安全性と信頼性の確保が必要です。 継続的な改善 テストは、モデルの弱点を特定し、継続的な改善を行うための基盤を提供します。 機械学習システムのテストと評価は、これらのシステムが現実世界で効果的かつ倫理的に機能するために不可欠です。 これらの要因により、AIのテストや評価は伝統的なソフトウェアテストよりもはるかに複雑で挑戦的な作業である事が判ります。 ※参考までに機械学習の失敗事例を載せておきます。 キヤノンITS -なぜ上手くいかなかったのか 機械学習 WebBigData – 機械学習のトレーニングに失敗したしくじり事例 tjo.hatenablog.com – 機械学習プロジェクトが失敗する9つの理由 スタビジ -AIプロジェクトの失敗する原因3 ソフトバンク – なぜAI導入は失敗する？ 失敗事例から学ぶ傾向と対策 Aidemy Business – AI導入の失敗あるある、「PoC死」の罠とは？ 3. トレーニングコースで学べる事 各セッションの内容は多岐にわたり、AIベースのシステムの品質特性や機械学習の基本、訓練データの取り扱い、MLモデルの評価指標などに焦点を当てています。 さらに、AIベースのシステムのテスト方法、AI固有の品質特性とテスト問題、テスト環境の構築、そしてAIをテストプロセスに組み込む方法など、実践的なテスト技術に関する詳細な情報も提供しています。 このようにコンテンツ量が多く専門的な用語も豊富なため、全てをお伝えするのは難しいですが、いくつかの主要なトピックを紹介したいと思います。 機械学習(ML) コース概要からも判る通り、本講義では機械学習(ML)という用語が頻出します。 本コースでは、AIにおける最も人気のあるアプローチとして機械学習に重点が置かれています。 機械学習には、回帰/分類/クラスタリングがあり、講義でも取り扱っている内容です。 ●回帰 (Regression) 【用途】: 連続する値や量の予測 　・株価予測 　・不動産の価格予測 　・気温の予測など 【主なアルゴリズム】 　・線形回帰 (Linear Regression): 　連続値の予測に使用される 　・多項式回帰 (Polynomial Regression): 　非線形関係をモデル化する際に使用 ●分類 (Classification) 【用途】 データをクラス/カテゴリに分類 　・顔識別 　・スパム判定 　・病診断など 【主なアルゴリズム】 ・ロジスティック回帰: 2クラス分類用 ・決定木: 階層分割で分類 ・ランダムフォレスト: 　決定木のアンサンブル学習 ・SVM: 分類境界を最適化 ●クラスタリング (Clustering) 【用途】ラベルのないデータ(教師なし学習)を類似性に基づいてグループ化 ・顧客のセグメンテーション ・遺伝子クラスタリング ・SNS上のトレンドの識別など 【主なアルゴリズム】 ・K-平均法: データをK個のクラスタに分類 ・階層的クラスタリング: データをツリー構造のクラスタに分類 機械学習と一口に言っても、様々な手法があり、実際の使われ方にも多様な種類があります。ニューラルネットワークの仕組みを利用したディープラーニングは今のAIにおいて多大な貢献をもたらした技術です。 いくつか代表的な例を紹介しておきます。 使用技術: 畳み込みニューラルネットワーク（CNN） 顔認証 ロック解除、防犯、など… 画像の分類 写真の分類、 医療画像解析、など… 使用技術: 敵対的生成ネットワー ク（GAN） 画像・動画の生成 線画の着色、テキストから画像生成、ロゴデザイン、動画コンテンツの生成 など… ゲームの再現 名作ゲーム「パックマン」の完全再現、など… 使用技術: 再帰型ニューラルネットワーク（RNN） 文章の理解 商品レビューの分析、 音声アシスタント、 問題文の読解、スパムフィルタ、 など… 文章の生成 文章の要約、 チャットボット 、機械翻訳、 など… 一例ではありますが、ディープラーニングの種類は実に豊富で、多くの事業に活用できるテクノロジーであることが証明されています。 本コースでもニューラルネットワークについて取り上げており、シンプルなパーセプトロンを実装する演習などが用意されています。 機械学習モデルの評価指標 これら代表的なタスクのほかに、機械学習では、データの前処理やモデルの構築、モデルの評価と、さまざまな技術や手法が紹介されています。 特にテストや評価に密接に関わるであろう、モデルの評価指標について、いくつかの重要な概念とそれらの基本的な説明を紹介しておきます。 以下の表と図で混合行列のマトリクスを用いて紹介します。 混同行列（Confusion Matrix）は、主に機械学習において、分類モデルの性能を評価するために使用されるツールです。この行列は、分類問題の実際の結果と予測された結果を比較するために使われ、以下の四つの要素で構成されます 左上： True Positive (真陽性:TP): 正しい陽性の予測。 実際に陽性であり、モデルが陽性と正しく予測したケースの数。 左下： False Positive (偽陽性:FP): 誤った陽性の予測。 実際には陰性であり、モデルが誤って陽性と予測したケースの数。 右上： False Negative (偽陰性:FN): 誤った陰性の予測。 実際には陽性であり、モデルが誤って陰性と予測したケースの数。 右下： True Negative (真陰性:TN): 正しい陰性の予測。 実際に陰性であり、モデルが陰性と正しく予測したケースの数。 【この図は正解ラベル(横軸)に対してモデルが正解/不正解の予測(縦軸)を示す指標です】 これら4つの要素を使って、正解率、適合率、再現率、F1スコアなどを算出できます。 これらはモデルの特性やデータが不均衡な場合は誤解を招く可能性がありますので、1つの指標だけでなく複数の指標を用いて多面的に評価をしていく必要があります。 ここでは分類モデルの評価指標の一例を紹介しました。 さて、コースにおけるいくつかのコンテンツを紹介させて頂きましたが、ここですべてを説明することは割愛させて頂きます。今までの内容からAIテスティングに興味が湧いた方は、是非、お手に取って頂ければと思います。 今回紹介した内容以外にも AIに特化した品質特性 アルゴリズムやサンプルのバイアス、独自に進化する自己学習システムや自らを制御する自律型システムなどどのように予測精度や意思決定の品質を評価していくかを課題として取り扱っています。 AIのテスト環境 現実的に環境構築が難しいケースを構築できるメリットを上げており、危険なシナリオ、異常なシナリオ、極端なシナリオ、時間のかかるシナリオなどに対して、観測や制御が容易であるメリットを説明しています。 テストにAIを使うケース 欠陥の分析や予測、テストケースの生成やユーザーインターフェースのテストなどが取り上げられています。一例ではありますが、例えば今回紹介したような、SVMやk近傍法などを用いる事で、適切な欠陥カテゴリを特定し、類似した欠陥や重複した欠陥を分類したり、ファジー理論やベイズ理論等の応用で、事前確率と新たなデータを組み合わせて、事象の発生確率を更新し予測を行うなどに用いる事例が紹介されています。 多様にあるAIベースのシステムに対して、ソフトウェアの品質をどのように達成するか、そのヒントを提供してくれると思います。 4.最後に ChatGPTの動向 今回AIの題材を扱わせて頂きましたが、2022年にChatGPTとMidjourneyの登場により、生成AIの波が到来しました。特に、ChatGPTを中核とする大規模言語モデル（LLM）に関するニュースは日々飛び交い、その急速な進化には驚嘆させられます。 多くの企業がLLMをビジネスに導入し、新規サービスの開発、既存事業の拡張、効率化のために活用しています。そして2023年11月7日、OpenAIはChatGPTを大幅にアップデートし、その波はさらに加速しています。 このコースでは大規模言語モデル（LLM）の直接的な扱いはありませんが、LLMの使用を通して、その評価の複雑さを理解することができます。 現代のテクノロジーの中心にあるChatGPTのようなLLMが作り出すテキストの精度を測ることは、非常に困難な課題です。 この根幹にあるのは、特定の期待される出力に対して明確な基準を設定することの難しさと、同じ入力に対しても一貫性のある結果を得られるとは限らない、という特性にあります。これらの要素はLLMのテストと評価を複雑にしており、我々がこの分野で直面する主要な問題の一つとなっています。 LLMの評価指標は新しい研究分野ですので標準的な指標セットや、評価ツールも発展途上という状態です。 その中でいくつか参考となる内容を紹介しておきますので、興味がある方はご覧ください。 例えば、ChatGPTのAPIであるLangChainの評価機能の中で特に埋め込み距離（embedding distance）を扱う部分に焦点を当てています。 LangChainを使って自然言語処理タスクを実行し、その結果を評価するための機能やメソッドの説明がされています。 langchain.evaluation.embedding_distance.base.EmbeddingDistanceEvalChain — LangChain 0.0.336 またGitHubページに、OpenAIによる「 HumanEval 」という問題解決データセットの評価ハーネスに関するものがあります。 このデータセットは、コード上で訓練された大規模言語モデルの評価を目的としており、「Evaluating Large Language Models Trained on Code」という論文で詳細が述べられています。 https://github.com/openai/human-eval AI の時代はまだ始まったばかりです。しかし、この技術の利点を完全に実現するには時間がかかり、ビジネスや社会は依然として対処すべき大きな課題を抱えています。 これには、生成 AI に内在するリスクの管理、従業員に必要な新しいスキルや能力の決定 新しいスキルの再トレーニングや開発などの中核となるビジネスプロセスの再考などが含まれます。今後のAI時代に向けて、AIをテストするというアプローチから、AIに関する基本的な知識や理解を深め、今後の発展に役立ててくれると嬉しく思います。 Udemyクーポン配布 Udemyの割引クーポンの発行 (29%OFF) クーポンコード: 57749211103205F5B818 有効期限: 2023/11/24 0:00～2023/12/25 0:00 ぜひご活用ください。 The post 「ゼロから始めるAIテスティングトレーニングコース」を解説～AIベースシステムを「どうテストするのか？」～ first appeared on Sqripts .

こんにちは、エンジニアのタカです。 普段はスクラムマスターや開発者としてプロダクトの開発に関わっています。 今回は前回の Notionでプロダクトバックログを管理するビューを作成する の記事の続きで、Notionプロジェクトについて書きたいと思います。 関連記事 Notionでプロダクトバックログを管理するビューを作成する Notionプロジェクトについて Notionプロジェクトは、2023年6月に発表されたNotionの新機能で、主に開発におけるプロジェクト管理に役立つ機能群のことを指します。 今回紹介するのは、これらの機能を活用したテンプレートです。 テンプレートは、ページの新規作成時に テンプレート を使用し プロジェクト、タスク、スプリント のテンプレートを選択することで使用できます。 テンプレートを選択すると以下の4つのDBが作成されるので、それぞれのDBを更新し、プロジェクト管理を行っていきます。 なお、本テンプレートの注意点について先に記述します。 * 今回試すのはあくまでテンプレートのデフォルトの設定です。 実際の開発プロジェクトでは適宜プロパティなどを削除/追加してください。 * 記事執筆時点で本テンプレートはベータ版の表記がありました。 今後、テンプレート内容が変更される可能性があります。 Notionプロジェクトのテンプレート タスクDB 1つめはタスクのDBです。初期のビューとして、 プロジェクト別ビュー 、 タイムラインビュー などが存在します。 DBのページのプロパティは、一般的なBTSやタスク管理システムにあるような、連番のID、担当者、期限、ステータスなどが存在します。 この中で特殊なプロパティは以下です。 プロパティ名 説明 要約 Notion AIによる概要。プロパティ編集時に更新を押せば自動でテキストが生成される 親タスク 同一DBにある親となるタスクを指定。指定することで親タスクのサブアイテムとなります。 プロジェクト プロジェクトDBの値 スプリント スプリントDBの値 GitHubプルリクエスト 後述のGitHub連携機能を用いたプロパティ 個人的には、このDBを プロダクトバックログ として使うのが良いかと思いました。 完了のステータスでPOやステークホルダーに見せられる 成果物 が出てくるイメージで、その成果物をスプリントレビュー等でレビューしていくイメージです。 なお、GitHub連携についてはNotionの新機能のため次で解説します。 GitHub連携機能 GitHub連携機能は、NotionのpageとGitHubのプルリクエスト（PR）を紐付け、Notionのpage上にプルリクエストのリンクを表示する機能です。 この機能を使うことにより、タスクとPRを紐付け、Notion上では見えにくい改修の進捗を追うことができます。 連携は、NotionとGitHubのコネクトを行ったうえで、ページのIndexをGitHub側のPRのタイトルに追加するか、PRのURLをNotionのページのプロパティにコピー・ペーストするかのいずれかで行なえます。 プロパティの設定画面 使ってみた感触としては、PRのタイトルにindexを入れるチームルールを設けることで、PRを出す時にもプロダクトバックログを意識できるので、前者のIndexのタイトルへの追加が良いのではと思いました。 プロジェクトDB タスクのカテゴリ的なイメージで、ステータス、オーナー、期日、優先度などのプロパティを設定しページを作成します。 完了率のプロパティもあり、これはタスクのステータスと連動して自動計算されます。 初期のビューとしては、 アクティブビュー 、 タイムラインビュー などが存在します。 タスクDBも同様ですが、次のプロジェクトを指定することで、タイムラインビューにて依存関係が表示され、担当者のアサインや進捗状況のチェックに役立てることができます。 スプリントDB 1スプリントを 1ページとして扱うDBで、ステータスや日付を指定できます。タスクDB側にスプリントを指定することで、完了したタスク数などが反映されます。 自分たちはこのDBと同様のものを既にバックログの管理に組み込んでいましたが、 スプリントのステータス のプロパティは設定していませんでした。 今回のテンプレートではこのステータスが後述のスプリントボードDBの機能と連動して更新されていきます。 スプリントボード スプリント – Notion (ノーション)ヘルプセンター スプリントボードは、これまでの3つのDBを使ってスプリントを運用するボードです。 デフォルトで次の3つのビューが存在します。 現在ビュー スプリントのステータスプロパティが 現在 のタスクおよびプロジェクトを表示します。 特徴的な新機能として スプリントの完了 があります。 完了すると、未完了のタスクを次のスプリントに移動したり、スプリントのステータスプロパティが自動更新されるなど、これまでスプリントの完了時に手動で行っていた操作を自動で行ってくれます。 スプリントを完了ボタンを押下時のモーダル スプリントプランニング ビュー スプリントのステータスプロパティが 次 以降のスプリントごとにタスクが表示されます。タスクを追加したり、スプリントを移動したりできます。 また、 バックログ（スプリント未設定） のスプリントが自動で作られるので、こちらに一旦タスクを移動することができます。 バックログ（スプリント未設定）のスプリント バックログ ビュー 先ほどのバックログ（スプリント未設定）に存在するすべてのタスクを表示します。ここで担当者のアサインなどプロパティの設定も行えます。 おわりに テンプレートの紹介は以上となります。 今回のNotionプロジェクトのテンプレートを使うことで、 GitHubと連携してのタスク(バックログ)管理 や、 スプリント終了時の操作 が半自動になるので、スクラム開発の運営において、手動で管理していた部分が楽になった印象でした。 アジャイル開発・スクラム開発で既にNotionを活用している方も、今回のテンプレートを取り入れる価値はあるのではと考えています。 Notionは定期的に新機能がリリースされており、例えば Notion2.33では、データベース周りの新機能であるワークフローの自動化や、Excelのような列の固定化機能などがリリースされています。 様々な機能を用いることで自分達のチームに合う運用方法が見つかるはずなので、ぜひ一度試してみてください。 The post Notionプロジェクトのテンプレートでスクラム開発をよりスムーズに！ first appeared on Sqripts .

前回の記事 では、1人目QAとは何かや1人目QAに求められているもの、そして1人目QAとしてJoinした後の立ち回りなどについて説明しました。 連載｜1人目QAとしての立ち回り 【第1回】1人目QAの位置づけと、開発組織へのアプローチの仕方 今回は1人目QAが実際に組織の中で「品質保証」を浸透させる際のアプローチについて説明します。 1人目QAの役割である「品質文化の浸透」 一般に「QAエンジニア」と言った場合、求められるスキルや現場での役割などは組織によってさまざまです。この点を整理し、QA関連の各種スペシャリティをわかりやすくするために、ソフトウェア技術者協会の分科会の一つ、ソフトウェア品質保証分科会（SigSQA）が考案したのがQMファンネルです。 参考： 品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話（3D版） | PPT QMファンネルでは、3つのスペシャリティ – TE:テストエンジニア – PE:パイプラインエンジニア – QA:QAエンジニア が表現されているほか、それぞれのスペシャリティについて5つのロール – スプリット – インプロセス – コーチ – コンサルタント – プロモーター が定義されています。 今回、このQMファンネルの中で注目していただきたいのは、QAのスペシャリティにおける各ロールの説明にある「品質文化の浸透」です。 私は、1人目QAに求められる役割の多くは、この「品質文化の浸透」であると考えています。 なお、”品質文化とは何か”についても議論の対象になる点です。本記事においては「品質保証の重要性や手法等について、開発組織で考える習慣があり、品質保証のやり方を仕組み化できている状態」を指して「品質文化が浸透している」と考えることにします。その一部分である、品質保証の重要性や手法およびその仕組みをどうやって開発組織に浸透させるのかが本記事のテーマです。 品質文化について考えたい、という方は西康晴氏のプレゼン資料 What is quality culture? Is it something tasty? | PPT および講演動画 JaSST nano vol.12 #5「品質文化って何なの?」 – YouTube も参考にしてみてください。 本題に戻ります。1人目QAを募集している各社の求人や、1人目QAの方の業務内容を見ると – QA組織づくり（採用、QA組織のMVV策定など） – 開発者へのナレッジ共有 – 品質目標・標準やテストプロセスの整備 などが業務内容に含まれていることが多くあります。つまり、1人目QAは特定プロダクトのテストやQA業務だけを求められているのではありません。QA組織を作り、開発組織での品質保証のやり方や方向性を定める役割を期待されていることになります。 この役割が、まさに「品質保証を開発組織に浸透させること」を表している、と考えます。 品質保証を浸透させるための2つのアプローチ では、1人目QAが品質保証を開発組織に浸透させるために、どのような方法があるでしょうか。 ここでは2つのアプローチについて考えてみましょう。 1. トップダウン型のアプローチ 1つ目はトップダウン型のアプローチです。 こちらは、品質保証のやり方やプロセス、品質標準などをQAエンジニアや開発組織のトップがともに策定し、それを現場で実践してもらうやり方です。 このやり方のメリットとして、 – 決まった方法を取り入れてもらうので、実践までが早い – 複数の開発チームに対して共通のやり方や仕組みを導入できる – QAエンジニアが少人数でもある程度進められる などがあります。 一方デメリットとしては、 – 現場の納得を得づらくなる可能性がある – 現場の実態に合わないことがある などが考えられます。 2. ボトムアップ型のアプローチ 2つ目はボトムアップ型のアプローチです。 こちらは、個々の開発チームや部門において、その現場での課題を解決しながら改善を重ねていく方法です。複数の現場で同じような課題が出てきた場合に、共有の仕組み化やルール化を進めていきます。 このやり方のメリットとしては、 – 取り組みの意義や期待するメリットを現場が理解しやすく、納得を得やすい – 個々の開発チームに合った施策を行える などがあります。 一方デメリットとしては、 – 開発チームや部門ごとに取り組みの進度に差がでる – 局所最適な改善に陥りやすい – 組織全体で見たときに、品質保証のやり方の浸透が遅くなりやすい などが考えられます。 どちらのアプローチで行くのかを検討して取り組みましょう 上記2つのアプローチのうち、開発組織に品質保証を浸透させるにはどちらが適しているのでしょうか。 私個人の経験からは、上記2つのアプローチは「並行して両方やる」が正解だと考えています。 私も現在1人目QAとして、開発組織への品質保証の浸透をまさに行っているところです。その過程では、トップダウン型とボトムアップ型、どちらもやりながら試行錯誤をしています。いろいろと試した結果、ボトムアップとトップダウンの両輪を回すことで、双方のデメリットを補いつつ着実に進んでいる実感があります。 ただ、あえて順番を設定するのであれば、1人目QAとしてはボトムアップ型→トップダウン型→両方が良いでしょう。 理由は、1人目として開発組織にJoinしたQAエンジニアは、その時点では周囲からの信頼が貯まっていないからです。 よほどの業界の有名人でもなければ、外からやってきた1人目QAは謎の多い存在です。 そのような状態でいきなり「これからの品質保証はこのやり方でいきます」とか「標準を決めたのでこれを守ってください！」と言ったとしても、周りには響きません。 それよりは、まずは1つでも良いので開発チームの困りごとを解決し、信頼を得つつ他のチームへも横展開を行いましょう。そして、開発組織全体から少しずつ信頼してもらえたところで、いよいよトップダウンのアプローチに移る、という順番がスムーズです。 1人目QAとして活動する方や、1人目QAをこれから採用して品質向上に取り組んでいこうという組織の方は、これら2つのアプローチをぜひ意識してみてください。 連載一覧 【第1回】1人目QAの位置づけと、開発組織へのアプローチの仕方 The post 【第2回】組織に品質保証を浸透させるアプローチ first appeared on Sqripts .

みなさんはじめまして、QAコンサルタントのぐっちです。 私はこれまで制御系エンジニアとして様々な案件に携わってきました。今回のブログでは、制御系開発とはどのような開発かというお話から自身が経験して学んだ開発での課題や対策を紹介したいと思います。 制御系開発とはどんなものか 制御系開発と組込み開発は、よく混合されますが、違う開発の種類になります。 制御系開発は具体的なモノを作るのではなく、モノを制御するという考え方がわかりやすいと思います。 車を自動的に目的地に運ぶための仕組みを作り出すシステム開発を制御系開発と考えることがイメージしやすいと考えます。運転手がいない自動車や、ロボットが物を掴む動作をする場合など、人が操作することなく、動作を制御するシステムを作るのがシステム開発の概要になります。 例えば、自動車に乗って高速道路を走っているとします。制御系開発では、自動車が速度を一定に保つように制御するシステムを作成します。もしその速度が目標値よりも速くなったら、ブレーキを軽くかけて速度を下げるよう指示し、目標値よりも遅くなったらアクセルを踏んで速度を上げるよう指示します。これにより、自動車は目標の速度をキープできるのです。 制御系開発は、自動車の他にも、洗濯機の水量調整、エアコンの温度調整、電車の自動運転など、さまざまな場面で活用されています。システムが一定の目標を達成するように「指示」を出す仕組みなので、効率的かつ安全な動作を実現することが可能です。 制御系開発は、私たちの生活の中で自動化や効率化を実現するために欠かせない技術なのです。 開発現場で苦労したこと 次に、実際の開発にて苦労したことを記載していきます。Web開発やアプリ開発とも重複する内容もありますが、主に苦労したことをピックアップして記載します。 ソフトウェアだけでなく、ハードウェアの知識も必要 制御系開発ではソフトウェアの知識だけでなく、ハードウェアの知識も必要になります。もちろん専門家ほどの知見は不要ですが、開発では、デバックボードを使用して、プログラムを流し込んでプログラムの動作確認を行います。 検証では、オシロスコープ ※1 やPLC ※2 などハードウェアを使用してプログラムを制御するテストを行ったりします。普段使い慣れていないものなので、最初使うときには慣れるまで時間がかかりました。 想定する仕様の複雑さ 制御系開発では、様々な条件で起動したり停止したりするため、複雑な仕様になりやすいです。細かな制御が必要であるため、数学的な計算式を使って制御を行う場合もあります。 そういった場合、なぜこの処理になっているのか、どの仕様でこのプログラムが動作しているか等を調べるのが困難な場合も多いです。 また、動作する環境は、自動車やセンサーのようなモノであるため、実際の動作を見ることは中々できません。エミュレータ等を使用し、仮想環境でプログラムを作成したりテストを行ったりします。そのため、使用するツール等の理解や習得も必要になります。 納期の厳しさ 納期についてはWeb開発やアプリ開発も同様になりますが、制御系開発ではモノ（ハードウェア）も含めて完成になります。今ではPCやスマートフォンは容易に準備できるものになるため、準備にそこまで時間が必要にはなりません。 しかし、自動車やセンサーなど動作環境を含めてリリースするとなると様々な準備が必要になります。よって、ソフトウェアの開発だけでなく、ハードウェアの準備や進捗にも気を配る必要があります。 課題に対する対策 上述した課題に対しての対策について以下に記載します。 ハードウェアの知識もしっかりつける 先述でも記載した通り、制御系開発では色々なハードウェアを使用して開発を行うことが多いのでソフトウェアの勉強だけを行っていれば解決できるものではありません。よって、各開発に使用するハードウェアの理解を深める必要があります。 そうすることにより、ハードウェアを含めた動作を意識することができるようになり、ソフトウェアだけでなくモノとして全体を含めた視点で開発に着手できるようになります。 そうすることによってソフトウェアの動作という観点だけでなく、システム全体を俯瞰して意識していなかったことに気付くようになります。 複雑なロジックを理解できる訓練をする 制御系開発だけでなくその他の開発でも同じことが言えますが、複雑な仕組みや仕様を理解するのは容易ではありません。私も最初は苦労をしましたが、なぜそのような計算式を使うのか、なぜそのタイミングで制御を行うのかという視点で物事を考えるとだんだんと理解できるようになり、仕様書に書かれている内容に対しても、問題があるところに指摘できるようになっていきました。その際に役に立ったのはロジカルシンキングという考え方です。ロジカルシンキングとは、物事を結論と根拠に分け、その論理的なつながりを捉えながら物事を理解する思考法になります。今では書籍や研修など様々な訓練方法がありますので、興味がある方はぜひ勉強いただくことをお勧めします。 全体を見据えたスケジュール管理を意識する 先述も述べたように制御系開発ではソフトウェアだけなく、ハードウェアも含めた開発になります。よって、従来であればソフトウェアのリリーススケジュールを考慮しておけば問題ないですが、制御系開発ではハードウェアのリリースも含めたスケジュール管理が必要になります。その分、課題管理やリスク管理もハードウェアを含めた管理が必要になりますので意識してスケジュール管理を行うようにしてください。 まとめ 今回は制御系開発で気を付けるべき内容や対策について記載させていただきました。ここに書いてある内容については、他の様々な開発にも流用できる考え方だと思います。 現在はQAコンサルタントとして業務に携わっておりますが、制御系開発によって得た全体を俯瞰して開発を進めていく経験やロジカルシンキング思考を用いてプロジェクトの課題の解決することで、最終的な成果物の品質の向上に繋がっていることを身をもって実感しております。 今後もプロジェクトを成功に導けるように日々スキルアップを目指して業務を遂行していきたいと考えております。 APPENDIX:用語の説明 ※1： オシロスコープ（Wikipedia） オシロスコープ (英: oscilloscope) は、入力した信号の電圧の変化を時間の関数として視覚的に表示する電気計器。表示される波形から、振幅・周波数・立ち上がり時間（英語版）・時間間隔などの値を得ることができる。昔のオシロスコープでは、これらの値を得るには画面に組み込まれた目盛りを使って波形を手動で読み取って計算する必要があったが、現在のオシロスコープはこれらの値を自動で計算して表示する。 ※2： PLC（Wikipedia） プログラマブルロジックコントローラ（英: programmable logic controller、PLC）は、リレー回路の代替装置として開発された制御装置である。プログラマブルコントローラとも呼ばれ、一般的にシーケンサ（三菱電機の商品名であるが登録商標ではない）とも呼ばれる。 The post プロジェクトを成功させる制御系開発の進め方：学んだ教訓と対策 first appeared on Sqripts .

こんにちは。みぞぐちです。 アジャイル開発のQAとして日々業務を行っています。 11/2に開催された JaSST’23 Kyushu にオンライン参加してきました。今回は「E2Eテストの自動化導入」や「継続的テスト」をテーマにした 『 テスト自動化から、 開発を支える継続的テストへ 』 というセッションについて、要点と感じたことをレポートしたいと思います。 セミナー概要 『 テスト自動化から、 開発を支える継続的テストへ 』 今回のセッションは、ある開発チームがテスト自動化の導入を皮切りに、ソフトウェア開発サイクル全体に段階的にテストを導入していき「 継続的テスト 」を実現するまでの進化の道のりについてお話しされていました。 【登壇者】 末村 拓也（すえむら たくや）さん オーティファイ株式会社 シニアテクニカルサポートエンジニア／テスト自動化スペシャリスト ちなみに「笑わせないと生きていけないタイプの人間なんですよ」とご自身でおっしゃっていた通り、70分の講演は面白くてあっという間でした。 資料は公開されていますので、興味のある方は覗いてみてください。 継続的テストに進化するまでの道のり これは末村さんが6年前にQAやソフトウェア開発に携わったときの話だそうです。 明日リリースするというリリース日程が差し迫っている状況のときに… 開発者 ：「QAテストしてください！」 QA ：「はい！」 QA ：「バグ見つかりました！」 開発者 ：「バグ直りました！」←リリース当日3時間前 QA ：「（え？こっからテストするの～？）」 みたいなことがとてもストレスだったということで、開発者の実装とQAのテストの間に何か見えない壁があってウォーターフォールに近いものが残っていたそうです。この苦しみの源泉は何なのかいろいろ勉強していくうちにDevOpsというのを知りました。 DevOpsとは DevOpsとは、Development（開発）とOperation（運用）を分けて仕事していたのを一緒にしよう、というシステム開発の流れを良くする意味で使われる造語で、それを下支えする技術や概念として継続的インテグレーションや継続的デリバリーという考え方が出てきたそうです。 出典： テスト自動化から開発を支える継続的テストへ （P.9） では、今回の主役とも言える「継続的テスト」とは何なのか。 出典： テスト自動化から開発を支える継続的テストへ （P.10） 上記図のように、継続的テストはすべての場所でテストできると言われています。 開発とQAの間にあった壁が苦しみの源泉でしたが、確かにこの八の字なら壁を取っ払えそうです。ということで、「ある開発チームのテストが継続的テストに進化するまでの道のり」がスタートしました。 クライマックステスト 出典： テスト自動化から開発を支える継続的テストへ （P.15） ある開発チームのお話です。1スプリント2週間で開発／テスト／リリースという流れで仕事をしていて「 一度にリリースする量が多い 」、「 駆け込みマージが多い 」、「 手戻りが多い 」という課題があり、QAの手動テストがボトルネックになっていました。手動テストを自動化したらリリース頻度を増やせるのではないか！ということで、まずはクライマックステストのソリューションとして E2Eテストの自動化 を導入しました。 （ちなみに「クライマックステスト」の名前はChatGPTに考えてもらったそうです。最後の方にどっかーーんとテストするの、何かいい名前ない？と聞いたら「クライマックスはどうでしょう」ということで名付け親になってもらったそうです。いい仕事しますね！） テスト自動化 出典： テスト自動化から開発を支える継続的テストへ （P.22） テスト自動化したらテスト実行速度は1/4～1/2まで短縮し、4時間だったテストは1～2時間になりました。 しかしここにも課題があり… 出典： テスト自動化から開発を支える継続的テストへ （P.25） E2Eテストの自動テストコードが古かったり、新機能追加に対応できていなかったりと、実際に動かしてみて初めて問題に気が付きました。 問題に気付くのが遅かった のです。テスト時間はテストコードのメンテナンス作業が追加発生してむしろ増えてしまいました。 実装の後にテスト工程が集中しているのが悪くて、これを開発中にE2Eテストを回したら、そのサイクルの中で問題にすぐに気付けるのではないか。 出典： テスト自動化から開発を支える継続的テストへ （P.32） ということで次のチャレンジです！ シフトレフト 出典： テスト自動化から開発を支える継続的テストへ （P.35） 今まで開発の後に集中していたテストを開発の途中にもっていこう、という シフトレフト を取り入れました。 開発中に開発者によってテストコードの実装／メンテナンスがされるので、 問題に気付くタイミングが早く なり、CIサイクルの中にE2Eテストを組み込めば自動的に実行されてリリース直前のQAの負荷軽減、コードフリーズ期間の短縮、リリースサイクルの短縮が可能となり、結果、「2週間スプリントを1週間に」、「2週に1回リリースを1週に1回に」改善していきました。 ただし、ここにも課題があり… 開発者たちにフラストレーション がありました。 「CIの実行時間が長くなった」 「UNITテストで充分なのにE2Eテストを書かないとダメなの？」 これは どのようなバグをどのように見つけるか、ということをチーム内で充分共有されていないのが原因 ということがわかり、課題がわかったので次のチャレンジです。 テストリアーキテクティング リアーキテクティングはリファクタリングと類義語で使われますが、リアーキテクティングは直訳すると再設計。テストリアーキテクティングは、今までE2Eテストに寄りすぎていたテストをもっといろんなテストレベルに寄せていこうというものになります。 出典： テスト自動化から開発を支える継続的テストへ （P.41） 左の図のアイスクリームコーンというアンチパターンから、右の図の実行時間が短く実行コストが少ない順に充実させたテストピラミッドのバランスにもっていこう、というのを 開発チーム内で共有しまずは合意 を取りました。 次にテストのバランスを考えてE2Eテストを減らし、同時にテストを削ってもカバレッジは保っていることを裏付けるためのカバレッジ計測を1週間に1回やって、このチームにとって一番最適なテストピラミッドのバランスを確立しました。 これによって、リリース頻度が週1回だったのをテストリアーキテクティングで週4回に増やすことができました。 ただここでも課題が… 品質について議論できていない のではないか…。 次のチャレンジです！ 継続的テスト 「 継続的テスト 」は作る前からリリースの後までずっとテストし続けるということです。 出典： テスト自動化から開発を支える継続的テストへ （P.56） 「 開発前 」 仕様を理解し、仕様の抜け漏れを減らす。つまりは開発～デプロイまでの必要なテストをリファインメントで計画を立てて合意（QA承認済）するため、自動テストが通ったらQAの判断を待たずに（QAは開発者をブロックせずに）デプロイできるようになります。 「 リリース前 」 未知の不具合を探るために、探索的テストをします。 「 リリース時（段階的ロールアウト） 」 ユーザーの反応を見るために一度にリリースしないでちょっとずつリリースしていく、段階的ロールアウトをします。 「 リリース後（GA（General Availability）） 」 全ユーザーに使ってもらい、GA（General Availability）＝ 監視を一つのテスト手段として使い、ユーザーがどんなふうに使っているかというのをテストします。 作る前からリリースの後までずっとテストし続ける「継続的テスト」をしたことにより、デプロイ頻度は週4回から毎日数回になりました！ さらにはチームの課題感も変わり、最初は開発プロセスの中の話ばかりしていたのが、どんなテストが必要か、自分たちがどういう価値をユーザーに提供できるかなど、気付けばチーム全体で 品質について議論できるように なっていました。 最後に末村さんは、「この通りにやれというわけではありません。この話をたたき台にして自分たちのチームでも話してみてください。チームの状況に応じたアプローチが必要です。」とおっしゃっていました。 確かにおっしゃる通り、この「継続的テスト」の取り組みは一つの事例で、全ての開発チームにそのまま適応できるものではなく、開発チームごとの課題やそれぞれの議論の結果があって、解決していくためのプロセスやヒントについてをこの講演から学ぶととらえるのが良さそうだと思いました。 感想 今回のセッションを聴いて、『品質を伴う「継続的テスト」を続けること』が重要だと思いました。ただただ「継続的テスト」をするのではなく、PO／開発者／QAそれぞれが「品質」マインドを持ち続けることでその先のユーザーへの価値提供につなげられると解釈しました。さらに時代と共にユーザーの求める価値が変化し続ける今だからこそ『品質を伴う「継続的テスト」を続けること』がマッチしているのだと思います。（ちなみに、今携わっている自身の開発チームはまさにこれを体現しているので講演を聴いた後、にんまりと幸せを噛みしめていました。） また、セッション内容とは別の観点で着目していたのは、今回一貫して段階的に体系立てて検証する進め方でした。末村さんがやっている「〇〇したことでXXが起こって、そこから出た課題、次のチャレンジ、成果をその都度丁寧に明らかにしていくサイクル」は本当に圧巻でした。これは日々の業務で意識している部分ではあるものの輪郭がぼやけてしまいがちなところでもあったので、自身の課題を見つめなおす講演にもなりました。さっそく明日からの仕事にこの学びを役立てていきたいと思います。 最後まで読んでいただき、ありがとうございました。 The post テスト自動化から、開発を支える継続的テストへ JaSST’23 Kyushu 参加レポート first appeared on Sqripts .

この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。 第12回目のテーマは、「リーンソフトウェア開発」です。 この内容はUdemyで公開しているオンラインコース「 現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム 入門編 」の内容を元にしています。 リーンという思想 リーンソフトウェア開発は、リーン開発とも呼ばれています。 日本で生まれたトヨタ生産方式は、アメリカやヨーロッパのソフトウェア開発で活用・適用され、体系化されて日本に逆輸入された開発手法です。リーンの考えが、日本のソフトウェア産業に直結していかなかったのは、日本人として残念に思います。 リーンという言葉は、リーンスタートアップなど、現在、様々な書籍でも使われていますが、リーン開発自体はあまり話題にならないように感じています。どちらかというと不人気です。 その理由を考えてみると、リーン開発には、具体的なプラクティスが少なく、「22の思考ツール」と呼ばれるリーンの考え方（スクラムでも出てきたリーン思考）が、多く語られているからかもしれません。 リーン関係の書籍を読み解いていくと、リーン開発にはプラクティスがないのではなく、リーン思考をベースに現場に即したプラクティスを考えていきなさいというメッセージということが見えてきます。このあたりもスクラムととても似ています。 しかし、自分たちで考えるのは大切なことですが、読者を突き放したような言い方にも感じます。せっかくいい思想であっても、使われなければ意味がありません。せっかく、リーン思考、リーンの原則には、現在の開発でも通用するものがたくさんあるのに、このあたりはもったいないと思わざるを得ません。 リーン開発の本はこれまで3冊が日本語訳されています。もし、これからリーン開発を学ぶのであれば、廃盤になってしまいますが、『 リーン開発の本質 』がおすすめです。 この記事でも『リーン開発の本質』をベースに解説します。 リーンソフトウェアの7つの原則 リーンソフトウェアの7つの原則をみていきましょう。書籍『リーン開発の本質』を見ると、価値より原則が先に登場しています。 原則1： ムダをなくす ひとつめは「ムダをなくす」です。「ムダ」がカタカナなのは、リーンが海外からやってきた考え方だからでしょう。英語だと「Waste（無駄、浪費）」という言葉がありますが、トヨタの考えが尊重された結果、「無駄」が「ムダ」になり、その言葉自体が海外でも通じるようになりました。 トヨタ生産方式を源流とするリーン開発なので、ムダ取りは大切な原則でしょう。ムダを見つけ、ムダをなくすことで、顧客への価値提供を最短距離で行っていきます。また、ムダをなくすのは、さまざまなアジャイル開発手法でも取り入れられている考え方です。そう考えると、トヨタ生産方式はさまざまな開発手法に影響を与えたのだと言えます。 原則2： 品質を作り込む 2つ目は「品質を作り込む」です。 事後に欠陥を見つけるのではなく、最初から欠陥が入り込まないようにしていくこと。これを「作り込む」と表現しています。 ソフトウェアだと、作ったあとでも修正ができてしまうので、「作り込む」という意識を持ちにくい部分があるのかもしれません。しかし、トヨタ生産方式だと、生産物が車なので、欠陥を後で取り除けません。製品に欠陥が入り込むと、命の危険にもなります。 日本だと、ソフトウェアのテストは、作ったものをテストするのが主流です。しかもバグを出すと大騒ぎする文化なので、大量のテストを、手動で実行する現場も多いでしょう。トヨタ出身の人が言っていたこんな言葉があります。 すでにバグが埋め込まれているものをテストしてバグを取り除いても、品質がいいとは言えない。 バグを取り除くことに必死になるのではなく、バグそのものが埋め込まれない仕組みや方法を考える必要があります。そうしなければ、開発がバグを作り、テストで発見するという、非効率なもぐらたたきがずっと続いてしまいます。 「品質を作り込む」も、開発手法全般で大切にされている原則です。 原則3： 知識を作り出す 3つ目は「知識を作り出す」です。 ソフトウェア開発は知識創造のプロセスです。プロセスを運営しながら知識を生み出し、成果物だけでなくプロセス本体も改善していきます。 原則4： 決定を遅らせる 4つ目は「決定を遅らせる」です。 ソフトウェア開発において、最初にすべてを決めるのは不可能と言えます。なぜなら、未来を見通すのが難しいからです。 書籍には「ソフトウェアの詳細な設計は、コーディングの最中に行われるものである」とも書かれています。設計を詳細に書きすぎるとコードに近づいてしまいます。だから、あえて決定を遅らせて、コーディング中に設計していく・・・のもひとつの手かもしれません。 意思決定は素早く行うことも大切ですが、「決定を遅らせる」では、大切な意思決定を「あえて」先延ばしし、ぎりぎりまで情報やフィードバックを集めて、決定を行います。 原則5： 速く提供する 5つ目の原則は「速く提供する」です。ひとつめの「ムダをなくす」でもでてきた「速い価値提供」です。 スピードを強みとすることで、競合他社との競争に打ち勝ちます。これはリーンに限らず、アジャイル開発の本質とも言える内容です。 原則6： 人を尊重する 6つ目の原則は「人を尊重する」です。 書籍には「トヨタの製品開発システムの4つの基本理念のうち、3つまでが、製品開発プロセスに携わる人に関係している」とあります。ソフトウェア開発は人間中心の活動です。 さらに、トヨタ生産方式では、自動化を、ニンベンの付いた「自働化」という表現にします。人間を大切にしたトヨタ生産方式らしい表現だと思います。 原則7： 全体を最適化する 最後の原則は「全体を最適化する」です。 リーンではアイデアが生まれてリリースするまでの流れを「バリューストリーム」と捉えて改善していきます。バリューストリームは、日本語にすると価値の流れです。リーン開発ではバリューストリームの一部分ではなく、全体を最適化します。 全体を見ず、部分最適をしても、問題がどこかに移動してまた別の問題が生まれてしまいます。だから、全体を見ながら改善を行っていきます。これは制約理論という有名な理論でも語られています。 リーンソフトウェア開発の22の思考ツール 最後に、リーンソフトウェア開発の22の思考ツールを解説します。この思考ツールは、XPでいうプラクティスに似た立ち位置のものです。これらのツールは7つの原則に分類できます。 1. ムダをなくす ムダを認識する バリューストリームマッピング 価値の流れを図解し、流れる時間を計測して流れを短縮していく 2. 品質を作り込む 認知統一性 統一性を作り込む コンセプト統一性 統一性を作り込む リファクタリング テスティング 3. 知識を作り出す フィードバック イテレーション 同期 集合ベース開発 チーム開発 4. 決定を遅らせる オプション思考 最終責任時点 意思決定 5. 速く提供する プルシステム かんばんの考え方 待ち行列理論 リーンとは別の理論 遅れのコスト 6. 人を尊重する 自発的決定 モチベーション リーダーシップ 専門知識 7. 全体を最適化する 計測 契約 より詳細を知りたい場合は、書籍『 リーンソフトウエア開発 アジャイル開発を実践する22の方法 』をご確認ください。 連載一覧 第1回：アジャイル開発の過去、現在、未来を知ろう！ 第2回：声に出して読みたいアジャイルマニフェスト 第3回：従来型開発とアジャイル開発の違い　その１ 第4回：従来型開発とアジャイル開発の違い　その２ 第5回：アジャイル開発のよくある誤解を解いていこう！ 第6回：世界中で大人気の秘密に迫る！スクラムを使ったソフトウェア開発 第7回：わかるようでわかりにくいスクラムチームの責任 第8回：スクラムイベントの実践方法 第9回：エクストリーム・プログラミングとその価値 第10回：エクストリーム・プログラミングの原則と基礎プラクティス 第11回：エクストリーム・プログラミングの応用プラクティス 第12回：リーンソフトウェア開発 The post 第12回 リーンソフトウェア開発 first appeared on Sqripts .

はじめまして！テストエンジニアの「大の字」です。 私はゲーム業界でテスターを経て、エンタープライズ業界のテストエンジニアになりました。 今回は、エンタープライズ業界に転身したことで気付くことが出来た「デバッグ」と「テスト」の違いについてご紹介したいと思います。 気付き 前職のゲーム業界では、「デバッグ」や「デバッガー」という言葉が「テスト」「テスター」と同じ意味で扱われていることが多く、私自身も「デバッグ」と「テスト」は同じ言葉の意味だと思っていました。 しかし、エンタープライズ業界でテストの知識を学ぶうちに2つの言葉はまったく異なる言葉の意味だと知りました。 今回はJSTQB認定テスト技術者資格のシラバスを通して、「デバッグ」「テスト」の意味や他にもよく誤解されやすい言葉「エラー」「故障」「欠陥」の意味を再確認してみることにしました。 デバッグとは？ 私は以前まで「デバッグ」は開発者がプログラムのバグを見つける行為だと、ざっくりとしたイメージで認識していました。 では、実際にはどのような意味かをJSTQBのシラバスで確認してみましょう。 デバッグは、故障の基となる欠陥を見つけて、解析し、取り除く一連の開発の活動である。 JSTQB-SyllabusFoundation_Version2018.J03 JSTQB-FL 1.1.2 テストとデバッグ ふむふむ、なるほど！つまり、プログラム内に潜んでいる欠陥を見つけて、原因のプログラムコードをチェックして欠陥を取り除く行為自体が「デバッグ」という意味なんですね。 では、故障の原因である欠陥を取り除いた後、本当にその故障が無くなったかは確認しないのでしょうか？その答えは、これから紹介する「テスト」にありそうです。 テストとは？ 私は「テスト」といえば、テスト手順通りに実行して期待する結果と一致しているかどうかを確認する行為だと思っていました。では、正しい意味はどうでしょうか？JSTQBのシラバスを確認してみましょう。 テストは、実行することでソフトウェアに存在する欠陥に起因する故障を示すことができる JSTQB-SyllabusFoundation_Version2018.J03 JSTQB-FL 1.1.2 テストとデバッグ 「テスト」とは、欠陥が原因の故障が発生するかどうかを示すことができるんですね。また、故障の発生は確認できますが、その欠陥の原因が特定できないことも特徴と言えます。 では、その欠陥を「デバッグ」で取り除いた後、発生していた故障が修正されたことの確認は行わないのでしょうか？その問いには、再度シラバスの記載を見てみましょう。 テスト担当者が確認テストを実施し、修正により欠陥が解決したことを確認する。 JSTQB-SyllabusFoundation_Version2018.J03 JSTQB-FL 1.1.2 テストとデバッグ なるほど。「デバッグ」を行って修正後に「テスト」を行い、検出した欠陥が無くなったこともきちんと確認するんですね。 エラーとは？ 私は「エラー」といえば、プログラム内で誤った動作が発生することだと思っていました。 では、またまたJSTQBのシラバスで意味を確認してみましょう。 人間はエラー（誤り）を犯す。そのエラーがソースコードや他の関連する作業成果物の欠陥（フォールトまたはバグ）となる。 JSTQB-SyllabusFoundation_Version2018.J03 JSTQB-FL 1.2.3 エラー、欠陥、および故障 1 つの作業成果物で欠陥を発生させるエラーは、他の関連する作業成果物でも欠陥を発生させる可能性がある。 JSTQB-SyllabusFoundation_Version2018.J03 JSTQB-FL 1.2.3 エラー、欠陥、および故障 テスト業界での「エラー」の意味は、プログラム内だけではなく、ヒューマンエラーを含んだ意味なんですね。ソフトウェアのエラーに留まらず、テストを行う上で発生する人為的なミステイクを含む意味であることが分かりましたね。 次は「デバッグ」「テスト」「エラー」をより深く理解してもらうため、上記3つの中で使われている「故障」と「欠陥」という言葉の意味についてご紹介します！ 故障とは？ JSTQBのシラバスでは下記のような定義がされています。 コンポーネントやシステムが、期待した機能、サービス、結果から逸脱すること 「故障」とは、システムが期待する結果と異なる結果になることを意味するのですね。私の経験則上では1つの欠陥で複数の故障が発生することがある印象があります。「故障」を検出するための活動としてテストを行うので、イメージがしやすいですね。 欠陥とは？ JSTQBのシラバスでは下記のような定義がされています。 システムの要件や機能が実現できない原因になる不備や欠点 「欠陥」とは、要件や機能が満たせない「故障」の原因のことなんですね。また、テストによって「欠陥」が存在していることは示せますが、「欠陥」が存在しないことは証明できません。つまり、ソフトウェアに残存する未検出の欠陥数は減らせますが、「欠陥」が見つからないとしても残存する「欠陥」は無いとは言い切れないのが特徴です。 テストをもっと詳しく では、言葉の意味が分かったところで少しテストについて深掘りしていきたいと思います。 テストといえば、以前の私のようにソフトウェアの動作を確認して期待する結果が得られるかを確認するだけと認識されている方もいると思います。しかし、実はテストには下記のような様々な活動のプロセスが存在します。 「テスト計画」「テストのモニタリングとコントロール」「テスト分析」 「テスト設計」「テスト実装」「テスト実行」「テスト完了」 また、テストプロセスにはいくつかのメリットがあります。 プロセスを分けることで、各担当の作業範囲齟齬などのヒューマンエラーが予防できる プロセス毎にエキスパートな人員をアサインすることにより、作業の効率化を実現できる テストプロセスの中で問題点があった場合、どのプロセスに問題があったかを分析し、改善を続けることができる テストプロセスを段階的に行うことで、人為的なミスの防止や作業の効率化、各プロセスの改善等が可能になり、リスクの軽減にも繋がります。 まとめ 「デバッグ」と「テスト」の役割について、理解が深められたでしょうか。欠陥を取り除く「デバッグ」も大切ですが、「テスト」によって故障を検出することで欠陥があることが分かるため、「テスト」は必要不可欠な存在であり、ソフトウェア品質を保つための最後の砦であることがお分かりいただけたと思います。 また、エンタープライズ業界ではシステムの大規模化や複雑化、短納期化が日々進んできています。これらを実現するためにテストプロセスを上手く活用して、ヒューマンエラーの予防や作業の効率化、テストを改善していく仕組み作りが出来ることを今回学べました。 みなさんも今回を機会に各テストプロセスにどのような役割があるかを調べてみるのもいいかもしれませんね。 「/Sqripts」では、テストプロセスについても紹介しています。是非チェックしてみてください。 ・基本的なテストプロセス 基本的なテストプロセス ・テスト分析の重要性～テストを支える縁の下の力持ち～ テスト分析の重要性～テストを支える縁の下の力持ち～ ・テスト設計技法 テスト設計技法 The post テストとは何か？デバッグとは違うの？ first appeared on Sqripts .

本連載ではプロジェクトマネジメントの全体像とプロジェクトを成功させる上で最低限抑えるべき知識と技術はもちろん、プロジェクトを炎上させないための技術やコツをお伝えしたいと思っています。 みなさんのプロジェクトが今以上に充実し、笑顔でプロジェクト終結を迎えられるよう一緒に学んでいきましょう。 第2回となる今回は、プロジェクトマネージャーの役割や必要なスキル、心構えについてお伝えします。 連載第1回はこちら 【第1回】プロジェクトマネジメントとは何か？ ［連載初回全文公開中：Sqripts会員以外の方も全文お読みいただけます］ PM（プロジェクトマネージャー）とは プロジェクトマネージャーは「プロジェクト目標を達成することに責任をもつチームをリードするために、母体組織が任命する人物である」と定義されます。プロジェクトの成否に大きな影響を及ぼすものとして、PMの存在は第一に挙げられる要素であり、PMはあらゆる プロジェクトマネジメントの知識や技術、これまでの経験や個人の人間力を「総動員」させ、プロジェクトの目的・目標を期限までに達成し、プロジェクト完了の責任を持つ 存在です。 PMの主な役割 PMは プロジェクトの目的・目標を期限までに達成させる為に、プロジェクトマネジメントのプロセスを実行しマネジメント します。 プロジェクトマネジメントのプロセスは主に＜立上げ、計画、実行、監視・コントロール、終結＞の５つのプロセス群に分けられます。 「プロジェクトマネジメントのプロセス」が優れている点は「どの業種業態でも適用可能」である点にあります。ITでも製造業でもサービスでもあらゆる分野に適用できるのがプロジェクトマネジメントプロセスです。 一方でプロジェクト活動において生み出される「成果物自体を生み出すプロセス」は業種業態によって異なってきます。イベント企画のプロセスとダム建設のプロセスは明らかに違いますね。この成果物を生み出すプロセスを実行するのはチームメンバーであり、PMはこの「成果物を生み出すプロセスが（メンバーの活動により）円滑に進み、期日までに成果物が納品できるよう」に、 プロジェクトマネジメントのプロセスとアプローチを駆使してマネージメントする ことがその大きな役割です。 PMとしての役割に集中する 経験のあるみなさんは、この成果物自体を生み出すプロセス（＝現場・メンバーとしての活動）にとても精通されているのではないかと思います。また自らが手を出した方がスムーズに運ぶ場合もあるかもしれません。しかしプロジェクト成功に向ける上での定石という点では、先ずは 「このプロジェクトマネジメントのプロセス（＝PMとしての活動）」に集中してほしい と思います。 小規模プロジェクトや組織の状態によっては、プロジェクトマネージャーをしながら「メンバーの役割も兼任する」ことが少なく有りません。例えばシステム開発のPMとして活動しながら、同時にシステム開発自体にもエンジニアとしての役割を持つような場合です。もしもこのように兼務する場合には「自分の活動のどれがPMとしての役割で、どれがメンバーの役割なのかを意識」して活動することが大切です。どうしてもメンバーとしての活動に時間を割かれる、マネジメントに必要な活動や時間が充てられない、という事にならないよう注意しましょう。 PMの活動と影響範囲 以下はプロジェクトマネジメント専門職の価値と貢献を示すPM独自の活動とされます。 プロジェクト目標とステークホルダーの期待に応えられるよう、プロジェクトチームを導くこと 利用可能な資源と競合する制約条件とのバランスを維持すること スポンサー、チーム、メンバ、その他のステークホルダー間の子ミュウニケーションをはかること PMへの期待と責任の拡大 最近ではPMがビジネスアナリシス（BA）やビジネスケースの作成、プロジェクトのためのポートフォリオマネジメント作成などへの関与が求められるシーンがあります。ビジネスケースとはプロジェクトの「立ち上げ前」にプロジェクトスポンサーなどにより作成され、プロジェクトの立ち上げ理由や目標を設定します。これらの活動に早くからプロジェクトマネージャーが参加し、評価や分析、目標推進方法や提案に関与することで、プロジェクトの成功角度を高めてその後のプロジェクト活動を円滑にするといった期待が込められています。また同じようにプロジェクトベネフィットの実現に向けて、プロジェクト活動後の各種対応へも関与することがあります。プロジェクトマネージャーの役割、その期待は組織やプロジェクト毎に異なりその活動もテーラリング ※ されますが、上記のような 期待に臨機応変に応えること が求められています。 ※テーラリング（tailoring） ：直訳では「仕立て」、プロジェクトマネジメントにおいてはプロジェクトマネジメントの知識や技法等を「プロジェクトに合わせて適切に調整して適応する」ことを意味します。この対応を洋服の仕立てに見立てテーラリングと呼びます。 プロジェクトマネジメントの成功指標 プロジェクトマネジメントにおける成功判断は、伝統的にQCD（品質・コスト・納期）の達成が基準とされていましたが、昨今はそれだけではステークホルダーの満足を得られなくなっています。「QCDS目標を達成したのに、なぜプロジェクトが成功と言えないのか、評価されないのか」という状況に陥らないよう、事前にプロジェクト目標等に成功指標や達成事項を明確にして記録するなどして合意を得ておくこともPMとしての重要な活動となっています。（従来のQCD評価は全体の30％に過ぎないとも言われます） 記載しておくとよい達成事項例） 財務指標や非財務指標の達成 組織移行の完了 ステークホルダーの満足 顧客やエンドユーザーからの受け入れ 組織や現場への成果物の統合 ガバナンス基準の充足　など PMに必要とされるスキルとは？ 具体的にPMにはどのようなスキルが求められるのでしょうか。プロジェクト活動に必要な知識や経験の適用、チームを導くリーダーシップ…など、PMに求められるスキルは多様で切り口は数多く存在します。そこで今回はPMIが提唱する「PMIタレント・トライアングル」を紹介します。 タレント・トライアングルとは、効果的なプロジェクトマネジメントを実施する上で必要とされる３つのスキルセットです。これらのスキルを備え、トライアングルの名の通り「バランスよく発揮」することがプロジェクトの成功に効果的だとされています。 Ways of Working Business Acumen Power Skills Ways of Working（働き方、仕事の進め方） 「仕事（プロジェクトなど）を成し遂げるため」に さまざまな方法とアプローチ（予測型、アジャイル、デザイン思考、あるいはまだ開発されていない新しい手法）を駆使して成果を上げるスキル を指します。 その為PMは多様な働き方や仕事の進め方などを経験・習得すること、またそれらを適切なタイミングで活用させることが求められます。 Business Acumen（ビジネス洞察力） 組織や業界におけるマクロとミクロの影響力を理解し、適切な意思決定を行うための機能またはドメイン固有の知識を持つ ことを指します。効果的に意思決定を行い、自分たちのプロジェクトが組織全体の戦略やグローバルなトレンドなどの全体像とどのように「整合」しているかを理解できるスキルが求められます。 Power Skills（パワースキル）とは 協調的リーダーシップ、コミュニケーション、革新的マインドセット、目的志向、共感力などの対人関係スキル を指します。 プロジェクトやチームに対するリーダーシップはもちろんのこと、「協調的」や「共感力」といった対人関係スキルを発揮してステークホルダーへ関与し、彼らに影響力を維持が求められています。 いかがでしょうか？タレント・トライアングルに示される要求スキルからもPMへの期待、ビジネス戦略とその達成にとって大きな役割を持つことがわかりますね。このほかにもみなさんがプロジェクトに参加する中で、先輩PMの振る舞いなどを見て「自分だったらこうする」「次のプロジェクトならこうできる」という発想から自身のPM像とスキルセットのイメージを膨らませてみてください。 PMとして大切にしてほしいこと 人間性こそプロジェクトの推進力 いくら知識や技術、経験があっても人間性が適切でなければリーダシップを発揮しプロジェクトを円滑に進めることは困難です。 プロジェクトは多くの人と共に団結して目的・目標の達成を目指します。その為、メンバが「一緒にプロジェクトを進めたい」「この人にならプロジェクトを任せられる」と思われるような存在でなくてはなりません。技術と知識という基礎力に加え、その人間性でリーダーシップを発揮しプロジェクトを円滑に進めていきましょう。 management by walking around MBWA(Management By Walking Around)とは「歩きまわるマネジメント」つまり「マネージャーが現場を歩いてマネージメントする」ということです。「席に座って報告を待っているだけ」「定例ミーティングの場でだけ情報収集する」といったマネージメントではなく「自ら情報を取りに行く(pull)」スタイルです。対話をすること、対話の機会を増やすこと、自らその空気と場を醸成すること。メンバーはその行動や空気を汲み取り、自然と安心感やパフォーマンスの変化を呼び起こすはずです。ぜひ意識してみてください。 「自己流PM」に陥らない為に 「自己流のPM」は自分の強みを中心に、伸ばせる範囲に手を伸ばしていきます。それも決して悪くはありませんが「一流のPM」はどうかというと、プロダクトやプロジェクトの全体像を理解した上で、自分がやるべき仕事を担いながら、自分ひとりでは手の届かない仕事を適切にチームに委任するなどします。大切なのはバランスと意識です。 安易に自己流に走り「独走」しないよう、ご自身がもつ特性・要素と伸ばしていくべき方向を意識していくことからはじめましょう。 誰よりも目的・目標の達成にこだわりを持つ PMはプロジェクトの目的・目標を期限までに達成し、プロジェクト完了の責任を負う存在だとお話しました。しかし実際にプロジェクトを実行すると、おそらく計画通りに行かないことが多々発生するはずです。前提や制約条件、発生する困難に対処しながらプロジェクトを推進することは簡単ではありませんが、だからと言ってPMが簡単に諦めたり「このぐらいでいいか」と安易な妥協をしてはいけません。PMはできればチームで最も「目的や目標にこだわる思考」を持ってください。その思考が、どうすれば目的・目標が達成できるだろうか？という行動を呼び起こしチームを導きます。 さいごに プロジェクトの成功に大きく関わるPMとその活動。プロジェクトにおいて非常に重要な存在であるからこそ、その役割や仕事内容、求められるスキルや素養は多岐にわたります。PMはよく指揮者などにも例えられますが、様々な知識をフル活用し、方向性を示し、柔軟性を持って、繊細に、時に大胆にプロジェクトをまとめ上げていく様子は、心技体バランスを持った「総合格闘家」という方がピンとくる気がします。みなさんもぜひPMとしての「筋肉」をさらに鍛えて、プロジェクトを支えていきましょう！ 今回は、PMの役割や期待されるスキルセットなどについて考えてみました。 次回は、「苦手な活動、よくわからない」と言われることも多い「ステークホルダーマネジメント」を、具体的な手法も交えて学んでいきましょう。 連載一覧 【第1回】プロジェクトマネジメントとは何か？ The post 【第2回】プロジェクトマネージャーの役割とは？ first appeared on Sqripts .

こんにちは！エンジニアのぱやぴです！ 全国高等専門学校プログラミングコンテスト(以下、高専プロコン)の第34回福井大会が2023年10月14日〜10月15日に開催されました。今回は私の会社AGESTが協賛することとなり、私もメンバーとして参加してきました。 私自身、高専プロコンのことをよく知らなかったのですが、実際に参加してみて、学生の皆さんの技術力と熱い想いにとても刺激を受けましたので、その様子をお届けしたいと思います。 高専プロコンとは？ 全国の高等専門学校の学生がアイデアや技術力を競う大会です。 「課題」「自由」「競技」の3部門で開催されています。 以下公式HPです。 全国高専プログラミングコンテスト 公式サイト 第34回福井大会(2023) 課題部門 課題部門は2年に1度テーマが変わり、そのテーマに沿った作品を開発し最も優れたシステムを決める部門になります。今回は昨年に引き続き「オンラインで生み出す新しい楽しみ」というテーマでした。 将棋やカルタなどオンラインで楽しめるゲームを開発しているチームや、普段の活動や、ゲームなどをみんなでオンラインで楽しめるように考えられた作品、音楽などをオンラインでより楽しめるような工夫をしている作品などが多く出ていました。 自由部門 自由部門は課題部門とは違い自分たちが困っていることや、関心のあることなど自由なテーマで独創的な作品を開発し、最も優れたシステムを決める部門になります。 学生寮の洗濯管理についてや、アクリル廃材の再利用、高齢者の服薬管理など身近な問題から社会問題など幅広い問題に対処する作品から、音楽やアートなどのユニークな視点での作品が多く出されていました！ 競技部門 競技部門は与えられたルールに沿ってプログラムを作成し、そのプログラムを用いてゲームを行いチーム対抗戦を行う部門になります。 今回は「決戦！n乗谷城」というテーマで行われており、2チーム対戦型の陣取りゲームでした。静かに競技が進んでいくなか、出場している学生さん等の真剣な表情から緊張感が伝わり、熱い戦いが繰り広げられていました！ 会場の様子 今回の会場は福井県鯖江市の「サンドーム福井」という場所でした。 特徴的な外装の建物で、カッコよかったです！！ 内部では学生さん等が、自分のような企業の方や一般の参加者さん等に説明してくれました。 学生さん等はみんな自分たちの作品について熱く説明しており、聞いていると学生さん等のフレッシュさや熱量、作品に対しての自信が伝わってきてとても素晴らしかったです！ また、使っている技術やテーマを決めたきっかけ、デザインなど質問をするとそれぞれ担当の人が回答を返してくれて「なるほど…すごい…」となり続けながら説明を聞いていました！ 競技部門も熱い戦いが繰り広げられていました！次回参加するできたらもっとルールを最初から把握し、より熱く観戦をしたいと思いました！ 個人的に印象的だったもの 全部の作品を体験できたわけではなかったのですが、自分が体験した中で印象的だったものを2つ紹介したいと思います。 VibraSymphony -全ての人にリアルなVR体験を- こちらは石川県の石川高専の自由部門の作品です。 視覚・聴覚のみでしか体験できなかったVRライブに振動するデバイスを取り入れ、臨場感を向上させるという目的の作品でした。 胸部・腹部に振動するスマートフォンを入れたベスト、振動デバイスを入れた靴を着用し、VRライブを体験させていただきました。振動が本当にライブ会場の音の振動を感じているようで本当にその場でライブの音が鳴っているような感覚になりました。 作品の完成度も学生さん等の協力して説明をしてくれたところも非常に素晴らしいと思いました！ Learn Mate 学生の学生による学生のための連絡アプリ こちらは福岡県の有明高専の課題部門の作品です。 学生同士の掲示板、先生との匿名のチャット、ToDoリストや時間割など学生生活を送るにあたって欲しいものがたくさん入っている作品でした。実際に困っていることやこうあったらいいなという学生目線で作られており、自分も学生の時にこのような仕組みがあればな…と思いました！ 先生へ質問をする抵抗軽減のために匿名にしたり、匿名でも悪戯等ができないようにしていたりなど、使用時の想定が細かくされていて素晴らしかったです！ AGEST企業賞 AGEST企業賞を授与したのは福岡県の久留米高専の自由部門「SeQuick－気軽な学習ゲームで、セキュリティ人材を増やそう－」でした！おめでとうございます！ SeQuick－気軽な学習ゲームで、セキュリティ人材を増やそう－ セキュリティ人材の不足を課題としてゲーム形式で楽しく継続的にセキュリティの学習を行う目的の作品でした。非常にセキュリティを学ぶのに効果的であり、会社の研修等でこのようなシステムがあれば、効果的に楽しくセキュリティについて学ぶことができると思いました！ 感想 まず、チームでテーマを決めてみんなで協力して作成をやりとげたということ本当に尊敬します！ また、タイトルにもありますが「熱を浴びた！」と感じました。エンジニアとして、ものづくりをしているものとしてその熱に感動し、自分も頑張ろうと思えました！ また、今回参加している中で企業紹介等を行う機会もあり、弊社が専門としている品質の話題など今回の作品作りのなかで共感してもらえる部分や興味を持って聞いてくれる学生さんが多く、改めて弊社の領域について自信を持つことができました！ 最後に これからのITを引っ張っていくであろう学生さん等と交流できたこと、非常に貴重な体験をさせていただきました！ また、学生さん等のフレッシュさやものづくりへの熱量、チームメンバーと協力しているところをみて非常にエネルギーをもらえました！ 参加した皆さん、お疲れ様でした！ ここまで読んでいただきありがとうございます。 The post 第34回高専プロコンで感じた未来のエンジニアの熱量と創造力 first appeared on Sqripts .

こんにちは。 エンジニアの nobushi です。 RDBが必要な規模のデータを扱うWebアプリケーションを構築する場合、多少なりとも「検索」機能が求められるものだと思います。 しかし、この「検索」機能、要求事項の幅が非常に大きく、場合によっては実現がかなり難しいと思われることもよくあるんじゃ無いでしょうか。 「全文検索」はその代表とも思われるもので、機能自体はとてもメジャーなんですが、RDBだけでできることはそんなに多くありません。 そこで Elasticsearch のような全文検索エンジンを活用するケースも多いと思います。 ただその場合、データ更新をRDB、Elasticsearchの両方に対して行う必要があり、何かと煩雑になりがちです。 PGSync は PostgreSQL とElasticsearchの同期ツールで、PostgreSQLのデータ変更を即時にElasticsearchに反映してくれます。 そのため、アプリケーションではElasticsearchへのデータ更新を行う必要がなく、コードがスッキリします。 今回は簡単にPGSyncの導入をしてみたいと思います。 導入 docker-compose が使える環境で、任意のディレクトリに以下のファイルを配置して / db/ initdb.sh postgresql.conf pgsync/ Dockerfile entrypoint.sh schema.json docker-compose.yml 配置したディレクトリで起動してください。 docker compose up -d docker-compose.yml services: pgsync: build: context: ./pgsync environment: PG_HOST: db PG_USER: postgres PG_PASSWORD: hoge ELASTICSEARCH_HOST: elasticsearch depends_on: db: condition: service_healthy elasticsearch: condition: service_healthy db: image: postgres:16.0 environment: - POSTGRES_PASSWORD=hoge command: >- -c "config_file=/etc/postgresql/postgresql.conf" volumes: - ./db/postgresql.conf:/etc/postgresql/postgresql.conf - ./db/initdb.sh:/docker-entrypoint-initdb.d/initdb.sh healthcheck: test: ["CMD", "pg_isready", "-U", "postgres"] pgadmin: image: dpage/pgadmin4:7.7 environment: - PGADMIN_DEFAULT_EMAIL=johndoe@example.com - PGADMIN_DEFAULT_PASSWORD=hoge ports: - 50080:80 elasticsearch_prepare: image: bash privileged: true user: root command: ["sysctl", "-w", "vm.max_map_count=262144"] elasticsearch: image: docker.elastic.co/elasticsearch/elasticsearch:8.10.2 depends_on: elasticsearch_prepare: condition: service_completed_successfully environment: discovery.type: single-node xpack.security.enabled: "false" ES_JAVA_OPTS: -Xms1g -Xmx1g mem_limit: 2g healthcheck: test: ["CMD", "curl", "<http://localhost:9200>"] interval: 1s retries: 180 kibana: image: docker.elastic.co/kibana/kibana:8.10.2 environment: - ELASTICSEARCH_URL=http://elasticsearch:9200 depends_on: elasticsearch: condition: service_healthy healthcheck: test: ["CMD", "curl", "<http://localhost:5601>"] ports: - 55601:5601 PostgreSQL、Elasticsearchのインスタンスと、PGSyncのインスタンスを配置しています。 またPostgreSQL、ElasticsearchそれぞれのViewerとしてpgAdmin、Kibanaを配置しています。 db/initdb.sh #!/bin/bash -xeu set -o pipefail psql -v ON_ERROR_STOP=1 <<- _EOT_ CREATE TABLE IF NOT EXISTS public.sample (id integer PRIMARY KEY, value text); _EOT_ db/postgresql.conf include = '/var/lib/postgresql/data/postgresql.conf' wal_level = logical max_replication_slots = 10 pgsync/Dockerfile FROM python:3.11.5-alpine3.18 RUN apk update --no-cache &&\\ apk add --no-cache redis RUN pip install pgsync==2.5.0 COPY entrypoint.sh . COPY schema.json . ENTRYPOINT ["sh"] CMD ["./entrypoint.sh"] pgsync/entrypoint.sh #!/bin/sh -xeu set -o pipefail redis-server --daemonize yes bootstrap --config schema.json pgsync --config schema.json --daemon pgsync/schema.json [ { "database": "postgres", "nodes": { "table": "sample" } } ] PGSyncの設定 PGSyncはPythonのアプリケーションです。 上記 PGSyncサーバーの構築 ではPythonのコンテナイメージをベースにしています。 また、 Redis が必須なのでRedisも組み込んでます。 起動スクリプト ではRedisサーバーをバックグラウンド起動した後に以下のコマンドでPGSyncを起動しています。 bootstrap --config schema.json pgsync --config schema.json --daemon それぞれPGSyncの前準備、起動のコマンドです。 schema.json を引数として渡しています。 schema.jsonはPGSyncの対象テーブル等の設定を行います。 今回は最低限の設定として対象DBを postgres 、テーブルを sample としています。 この設定だと対象テーブルの全カラムをElasticsearchに同期することになります。 今回は割愛しますが、schema設定では対象のカラムを限定したり、スクリプトで値を加工したりと自由度は高いです。 動作検証 ではpgAdminとKibanaで確認してみます。 pgAdminへのアクセスは上記の docker-compose の通りであれば http://127.0.0.1:50080 で、 KibanaのDevToolへは http://127.0.0.1:55601/app/dev_tools#/console でアクセス可能なはずです。 pgAdminへのlogin http://127.0.0.1:50080 にアクセスするとログイン画面が表示されるので docker-compose の環境変数で設定した以下のメールアドレス、パスワードでログインします。 johndoe@example.com / hoge pgAdminからDBへの接続 ログインしたらDBサーバーへの接続を追加します。 General / Name Connection / Host name Connection / Username Connection / Password db db postgres hoge この段階では sample テーブルは空です。 KibanaでElasticsearchの確認 http://127.0.0.1:55601/app/dev_tools#/console にアクセスするとKibanaのDevToolコンソールが表示されるので GET /postgres/_search と入力して postgres インデックスの内容を表示します。 この時点では sample テーブルか空なのでElasticsearchのインデックスも空です。 PGSyncの動作確認 では、PGSyncが動作することを確認します。 pgAdminから sample テーブルにデータを追加します。 INSERT INTO public.sample VALUES (1, 'value1') 追加した後で、再度KibanaでElasticsearchを確認します。 無事、Elasticsearchにデータが同期されていることがわかります。 所感 PGSyncによってPostgreSQLとElasticsearchの両方をアトミックに更新する必要がなくなるという点で、 利点は非常に大きいと思います。 使い方も難しくなく、また、Pythonのスクリプトが設定できるので自由度もかなり高いです。 Elasticsearchを使用する際には検討してはいかがでしょう。 The post PostgreSQLとElasticsearchの同期ツールPGSyncを使ってみた first appeared on Sqripts .

TestArchitectは2023年夏にモバイル端末（iOS/Android）上で動作するアプリケーションを対象に機能テストが可能な「TestArchitect for Mobile」をリリースしました。モバイル端末を自動化することでWindowsアプリケーション、Webアプリケーションを1つの自動化ツールで制御することができるようになりました。 しかしTestArchitectはモバイル対応ができることだけが優れている点ではありません。TestArchitectは複数プラットホームの対応以外にもキーワード駆動型での簡単なスクリプトの作成、部分一致での画像比較、仕様変更への強さなど他の自動化ツールに無い特徴がいくつもあるため、実際に使ってみてどのようなものなのか検証してみました。 参考： TestArchitectの概要 TestArchitectの特徴 1. キーワード駆動型で複雑な処理もエクセルライクにスクリプト作成できる TestArchitectはキーワード駆動型でエクセルライクにスクリプト作成ができるため作りやすく読みやすいメリットがあります。他の自動化ツールでも簡単にスクリプトが作成できることを売りにしている自動化ツールがありますが、そういった自動化ツールでは簡単な処理だけ簡単に自動化できますが、複雑な処理になるとプログラム技術が必要になる場合が多いです。 　　　　　　　　　　　 TestArchitectは一貫して複雑な処理もキーワード駆動型で自動化できる点が他の自動化ツールと異なる点です。このようにキーワード駆動型を使って簡単に自動化できることで自動化習熟のハードルが下がる点がTestArchitectの良さです。自動テストの現場の問題としてテスト技術者で自動テストのアサインを検討している際にプログラム技術を持ち合わせたテスト技術者を揃えることが難しく、自動化担当者のアサインに困ることがあります。しかしキーワード駆動型を作ったTestArchitectではそういった問題の解消ができます。 TestArchitectはプログラム技術が無くてもスクリプト作成ができるため、数週間ツールを使えば現場で使えるレベルになることができます。私の考えですが自動テストは、テストを熟知しているテスト技術者が自動化担当者になることが良いと考えているため簡単に使えるTestArchitectはテスト技術者にとっても良いツールです。テスト技術者がスキルアップのため、自動テストの技術を身に着けてみたい方はTestArchitectを一度使ってみてはどうでしょうか？ 自動化経験のないテスト技術者にとってスキルアップのチャンスです。 2. 複数プラットホームで自動化ができる TestArchitectは今回対応されたモバイルの他、Windowsアプリ、ブラウザと異なるプラットホームを1つの自動化ツールで自動化することができます。そのためエクセルに登録された情報をブラウザで登録し、PCから送付したメールをスマホで確認するといった複数プラットホームを跨いだ操作も可能です。 初めて自動化ツールを選ぶ際にインターネットで良い評価の自動化ツールを選んでも、自分が自動化したい対象システムにとって必ずしも良い自動化ツールだと限りません。自動化の目的が明確でなければ、どの自動化ツールを選んでよいか分からなくなります。そういった自動化ツールに何が必要かを把握していない場合でも、TestArchitectの自動化できるプラットホームと充実したアクション数があれば、幅広い処理が自動化でき自動化することに困ることはないと言っても過言ではありません。 同じ会社でTestArchitectを使っているプロジェクトがあれば、一度借りて試してみてはどうでしょうか？自動化できることがわかるかもしれません。無料のTeam版もあるので気軽にダウンロードしてお試しください。 3. 仕様変更に強い構成 TestArchitectはスクリプト作成する際に座標指定を行わないため仕様変更に強いというメリットがあります。 座標指定を行う場合ではオブジェクトの位置変更があるとスクリプトの修正が必要になりますが、TestArchitectではインターフェース登録を行います。オブジェクトをTestArchitect内に登録し、その登録名を各スクリプトで呼出して使うためにオブジェクトのIDなどに変更があった場合にもインターフェースを取り直すことで、スクリプトに変更は発生しません。 　　　　　　　　　 オブジェクトのIDなどをスクリプトで設定して使う自動化ツールは、IDなどが変わってしまうとそのオブジェクトを使ったスクリプト全てに修正が発生することになります。こういったメンテナンス効率でTestArchitectは優れています。 インターフェースも簡単に登録することができるため、特に使いこなすことは特別な技術は必要ありません。 また共通関数も簡単に作成することができるため、複数のスクリプトで使用する同じ処理は１つの共通関数を呼出して使用できます。仕様変更があった場合にはその呼び出し元の関数を修正すれば仕様変更の対応が可能になります。 インターフェース登録と共通関数を使うことでメンテナンス効率を高めることができるため、TestArchitectは仕様変更に強い自動化ツールです。 4. ハーネス機能であらゆる対象を自動化できる Java、C#、Pythonで作ったプログラムを取り込み、TestArchitectで呼出して使うことができる機能があります。 この機能を使うことで通常TestArchitectで制御できない処理もハーネス機能を使うことで自動化することが可能になります。これまで諦めていた自動化もTestArchitectなら自動化できるかもしれません。 またハーネス機能を使えばRaspberry Piを使った組込み系製品の制御も可能になります。 組込み系製品の自動テストは組込み系製品を自動化するためのツールを作ることが技術的なハードルが高く自動化の実績が少ないですが、TestArchitectのハーネス機能を使うことでRaspberry Piを使い組込み系製品を自動化することが可能になります。Raspberry Piと連携できるハーネス機能と幅広いプラットホームを自動化できるTestArchitectを使えば、複数のシミュレータ機器を使ったIoT機器の自動化も可能になります。 他の自動化ツールでも工夫しシミュレータなど外部機能と連携することで、同様の幅広い機能で自動化ができますがこのやり方では大きな問題が発生します。1つの自動化ツールで複数の外部機能と連携する場合、構造が複雑になり実行エラーが発生した場合のエラー原因の特定が困難になります。運用担当者は必ずしもスクリプト作成者ではないため、自動化システムの構造を詳しく理解していない場合が多く、問題が発生した際に複雑な構造では原因特定が難しく実運用に問題が出ることが出てしまいます。 一方、TestArchitectは全ての機能を１つのツールで制御するため構造が複雑にならず、１つのツールのログからエラーを特定することが可能になります。自動化できる幅が広がるためのハーネス機能の特徴ですが、1つの自動化ツールで複数のシミュレータなどの外部機能と連携した自動化対象の構造を簡素化できるという特徴もあります。 5. スクリプトの構成が整理しやすい TestArchitectではテストモジュールには役割別に4つの区分が準備されています。 それぞれの区分で実行する処理を分けることで、可読性が高まり担当者が抜けたことでメンテナンスができなくなり自動テストの運用が止まってしまう可能性は低くなります。もともとキーワード駆動型で作りやすく理解しやすい自動化ツールのため、４つの区分があることでよりわかりやすく使いやすい自動化ツールになります。その区分に合わせてスクリプト作成するだけでコーディング規約に合わせたような一定の品質のコーディングができます。 6. 高度な画像判定ができる 一般的な自動化ツールでは画像一致の自動テストは実用面ではあまり使い勝手がよくありません。 その理由は画像判定をピクセル単位の一致で行っているため、誤判定が多いためです。 しかしTestArchitectはKey-Pointを用いて抽出した特異点と一致するものを画像内にあるか判定することができます。そのため完全一致ではなく部分一致での判定が可能です。デジタルカメラで取得した画像を使った画像判定を行うと少しの位置のずれ、画像ノイズが入ることから完全一致では判定は不可能です。 その点Key-Point技術を用いた画像判定を行うとデジタルカメラで取得した画像の一致も可能になります。デジタルカメラでの確認が可能になることから、組込み系製品でのテストにも使うことができます。 　　　　　　　　 画像チェックの自動化はこれまでオブジェクト認識ができなかったときの最後の手段として使っていましたが、部分一致が可能になると使い方が変わるため自動化の幅が広がります。 7. 自動化ツールのライセンス価格が非常に安い 自動化ツールの購入を検討する場合、重要視するポイントは自動化ツールの価格ではないでしょうか。 社内の予算を通すには価格の高い自動化ツールでは、苦労が予想されます。やっと予算を通してもそれが現場で使えなければ、大きな問題になります。 しかしTestArchitectは他に自動化ツールと比べても価格が安く、実行するだけの「Run Only」であれば年間9万3千円で使えます。スクリプト作成・編集可能な「Enterprise」でも年間44万9千円で使うことができます。 他の自動化ツールと比べても価格が低く、多機能な自動化ツールは他にありません。 お客様に中にも「TestArchitectはこれだけ多機能でなぜこれほど価格が安いのですか？」という声もよく聞きます。自動化ツールの購入の重要ポイントである価格が安いという点だけでも、ツール購入の選択肢に入れておく価値があると思います。このTestArchitectという十分な機能が揃った自動化ツールが実行だけなら年間９万から使えるというだけでも、作業者を雇うことを思えばかなりコスト面でのメリットは出てきます。かなりお買い得だと思います。 8. 自動化対象に合わせてカスタマイズ可能 どうしても他の自動化ツールで自動化できないこともTestArchitectであれば、カスタマイズを行うことで他の自動化ツールでできないことも自動化がすることができます。 Linux環境で充実した自動テストを行うことができる自動化ツールを探すとなるとなかなか良いものが見つからず、自動化断念となりかねません。 特殊な環境の合わせた自動化ツールを作成しようにも、新たに自動化ツールを作るために必要となる技術も高いものが求められるため、簡単に自動化ツールを作成しようと踏み切れるものではありません。 そういった問題があってもTestArchitectは環境に合わせたカスタマイズができるため、自動化対象に合わせた自動化ツールにすることができます。もし求める自動化ツールが探しても見つからない場合はTestArchitectのカスタマイズを選択肢に入れてみてはいかがでしょうか？ 纏め TestArchitectの優れた点ばかり説明してきましたが、1点他の自動化ツールに比べて劣っている点があります。 それはTestArchitectの知名度が無いことです。このような価格が安く実用的な自動化ツールが世間に知られていません。 日本以外の国で１０年以上の実績がありますが、日本での導入はごく最近の２０２０年頃からです。海外では実績もあり販売台数も多い自動化ツールですので、日本で知名度が無いことは問題ではありません。日本ではこれから実績を作っていく過程であるため現在は知名度が無いという状態です。 TestArchitectを検証したところ自動テストの現場の様々な問題を解決できる高い実用性を備えた自動化ツールであることがわかりました。他の自動化ツールに無い特徴を持った様々な機能を揃え、いろんな場面で活用することができ、しかも使いこなすことに高いスキルを必要としない自動化ツールは他に無いものだと思います。 気になった人はTeam版であれば無料で使えるため、TestArchitectを試してみてください。 参考： TestArchitectの概要 連載一覧 【第1回】自動テストはなぜ失敗するのか？ The post 【第2回】TestArchitect for Mobileの動作検証 first appeared on Sqripts .