テストエンジニアが身につけておきたいスキルの一つに「論理スキル」があります。 この連載では、「プログラムのレベル」「文や文章のレベル」に分けて、論理スキルの基本である「論理の言葉」を徹底解説します。 第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 .

みなさん、こんにちは！　QAエンジニアのゆーすけです。 11/2に JaSST九州 が開催されました。（新潟と同じ書き出し方…） 自分の今期のJaSST参加としては6月東北、9月新潟の2箇所は現地参加としていましたが、今回は九州の中でも福岡開催ということで何やら行けそうな気がしたので、こちらも現地参加をしてきました。 テストの基本に立ち返る 毎年九州内で開催地域を変えてきて、数年ぶりに初期開催拠点の福岡にもどってきたことから 「いまだからテストの基本に立ち返る」 ということをテーマに抱えたシンポジウムでした。 またJaSST実行委員の中に学生の方が参画された、ということもあり、基調講演のターゲットも、 学生向け 開発をやっているけどテストは初心者 という方が対象とした講演とした、とのことでした。 今回のブログでは主に基調講演の内容を拝聴しながら考えた内容をまとめていきたいと思います。 「わからない？をわかる！に変えよう！- QAエンジニアが実践している基本的な考え方と方法」 ということで、上記が基調講演のタイトルとなります。とりあえずどうしても書きたいことだけを先に書くと、 用語はISTQB グロッサリーを活用するのがよい（無料だし！） QAの用語統一はプロダクトや会社によって大きく異なる。 例えば単体テストという言葉をとっても全然違う 単体テスト＝Unit Testのことを考える人もいれば、画面上のかたまりや単機能のことを単体テストという会社もある でたっ！！！ 自分的QAあるあるの１個目にあげてる内容ですね（2個目以降は未設定） これを聞いて、「あー、やっぱこれは広く一般的？なQAあるあるなんだな」と強く思いました。 その証拠に、この話が出たときの会場の笑い＋苦笑い＋強くうなずくなど、参加者の反応が本シンポジウムで最も強くあらわれた部分なのではないのかな、と。 この話は自社内の個人の認識相違であれば笑い話ですむかもしれませんが、受発注関係で出た場合は大きなトラブルになるリスクを孕んでいます。 （とある日の光景）　※昔話を事実を元に誇張しています 営業 「クライアント様から見積と人員提案の依頼が来ましたー！”単体テスト”からやってほしいそうです」 自分 「単体テストから？？そうすると開発知見がないと難しいと思うんだけど、それって本当に『単体テスト』の話？？」 営業 「はい、”単体テスト”って言ってました！」 自分 「（ほんまかいな…）」 もちろんこの話のオチは『単体テスト』の話ではなく、単機能テスト＝結合テストだった、ということになります。 この話もまだ笑い話ですみますが、もし単機能テストだと思っていたら単体テストだった、という逆の場合では必要なスキルレベルが変わってくるので、会社間であれば大きなトラブルになる可能性が高いです。 今回の講演の話では「共通用語を定義できる」というインプットでしたが、「共通用語がある」ということが分かってくると、いろんな用語を聞いたときに「 それって本当に正しい意味で使われているのか、どういう意図で使われているのか 」といろんな部分にひっかかりができ、その「ひっかかる」ということがテストエンジニアとしての血肉になっていくのではないかな、と自分は考えています。 アウトプットする、ということ 講演案内に「紙とペンを使うよ」ということが記載されていたので、「はて？ワークショップ形式で行うのかな？」と思っていた部分があったのですが、実際は、エクササイズとして考えていることの文字でのアウトプットの時間が要所要所で設けられていました。 本シンポジウム中でも複数回に渡って 「レポートを書くところまでがJaSSTの参加です」 という言葉が出ていましたが、これはインプットとアウトプットの関係性的にもとても重要なことだと思っています。 「講義を受ける」といったような知識のインプット工程と、「得た知識を他で活用する」「人に話してみる」「レポートとして作成してみる」というアウトプット工程は、 インプット3割、アウトプット7割 が理想的だと言われています（比率に関しては所説あると思います） このブログ化も、言ってみればアウトプットの一つとして活用している部分になりますが、実際インプットしたものをアウトプットすることは、人によっては中々ハードルが高い場合もあります。 そういった人はインプットとアウトプットを同時かつ、理想的な比率で行えるワークショップに参加してみる、というのもよい機会だと思いますが、ワークショップに参加すること自体がハードルが高い、ということも往々にしてあります。 今回エクササイズとして、できるテストエンジニアとはどういうことができる人か書き出してみよう、といったような実際にペンを走らせる工程が複数ありました。 こういった講演の流れとしてアウトプットの機会があり、なおかつアウトプットしたものを他に公開しない、という心理的安全が保たれたかたちでの講演は中々に効果的かつ効率的だな、と思いながら参加をしていました。 中には持参したPCで書いた人もいたかもしれませんが、やはりペンを使って紙に書く、とテキストで打ち込む、は効果は違う、と思っているので、個人的にはアウトプットは紙とペンで行うのをおススメしたいところです。 余談ですが、20年くらいまえは不具合レポートを手書き＋FAX＆Excel送付で行っていたころもありますが、いかに最小限の労力でレポートを書くか、ということを求めるために、かなりの早さでレポート作成精度が一定値以上までいった、と思っています。 ※文章の一か所直すために全書き直し、とかあったので テクニカルスキル以外も学ぶ 役に立つテストとして、デシジョンテーブル、境界値という話にも触れられていましたが、境界値の例として 未成年・学生無料のイベントがある 未成年の定義としては、開催年度内で17歳であること 年齢判定としては、生年月日の4月1日と4月2日を境界値として考える という内容をあげられていました。 ご存じの方も多いと思いますが、学年というのは4/2～翌年4/1生まれで考えられています。 SEの方がそのルールを知らない場合、その判定で不具合が検出される、という話をしていましたが、テストする側もそのルールを知らなかった場合は普通に市場不具合として出るかたちになります（それもかなり恥ずかしいやつ）。 できるテストエンジニアとはどういうことができる人か書き出してみよう、のサンプルとして 「どのドメインでもテストできる」 という項目があげられていました。 言ってみると前項の事例も教育ドメインと言われれば教育ドメインですが、年齢、学年判定は教育系以外でも多く使われる内容です。 つまり極論的にいうと、 「全ての物事の理は、出し分け、分岐の指標になりうる」 だと思いますので、インプットの感度を強く日々過ごされるのがよりよいテストエンジニアへの道に繋がるのではないのかな、と思っています。 まとめ 今回は予めテックブログに書こう、と思って講演に臨みましたが、最初からアウトプットしよう、という気持ちで物事にあたると、 これをどうアウトプットしようか 自分に必要な情報は何なのか などというインプットしながら同時に脳内でアウトプットする、という状況になると思います。 また今こうして書いていること自体が自分の振り返りや新しい視点の創造になっているので、みなさんもいかにアウトプットをするか、ということに重きをおきながら学習に努めてみてはいかがでしょう。 「レポートを書くところまでがJaSSTの参加です」 書いたので、自分の中でのJaSST九州はこれで終わりになります！ お疲れ様でした！！ The post 初心者向けのQA講演を別の観点からいろいろ考えてみた －JaSST九州レポートにかえて－ first appeared on Sqripts .

こんにちは。RYUです。 現在、私はシステム保守運用のサポート業務を担当しております。業務経験としてはQAの方が多いのですが、今はインフラ系の業務を担当しております。 システム運用業務はミスが絶対許されない厳しい世界です。運用しているサービスの規模や種類にもよりますが、多くのユーザが利用しているWebサービスが停止したり、データが損失するような事態が発生した場合には、恐ろしい損害や事故等が発生する原因にもなってしまいます。それだけに、本番環境などを操作するような作業では、より慎重に取り組まないといけません。 とはいえ、私の性格的にボタンがあったら押すタイプなので、苦労しながらもミス防止を意識しながら、日々の業務に取り組んでおります。 システム運用業務ってこんな感じです 私が担当しているのはWebサービスで、日常的には、アラート発生時の対応やディスク容量の調整等を行います。また、定期的なアプリケーションのリリース作業や、不定期ですがファイヤウォールやロードバランサの設定変更、OSのバージョンアップ、仮想サーバの構築等も行っております。 いずれの作業においても、設定ミスやデータ削除等を行ってしまうと、サービス運営に影響を与えてしまいますので、作業中は気が抜けません。ただし、私の経験から強く思うのですが、人間はどうしてもミスをする生き物なんだなぁと感じる場面が多々あります。 そのため、システム運用の現場では運用業務におけるミスを防ぐ取り組みが色々と組み込まれており、今回はそのような取り組みの一部をご紹介させていただければと思います。 ここで紹介させていただく取り組みは、仕事や日常に取り入れることで、多少なりとも、単純なミスを防ぐことができるようになる可能性がありますので、できそうだなと思ったものは、ぜひお試しいただけると嬉しい限りです。 実際の取り組み 以下の内容は、いずれも目新しいものではなく、皆様もご存知のものだと思います。それでも、改めて見直していただくと、案外に役に立つものがあるかもしれませんので、ぜひぜひご覧ください。 その１：見直し 資料や手順書を作成した際、どうしても 誤字脱字や認識違い 等が発生するものです。本人の自覚や認識の無いところで、想定外の記載をしたり、必要な情報が抜けてしまうことは頻繁に起こります。自分ではそのようなミスは気が付かないことが多いので、作業完了後に見直しを行うべきなのですが、自分の行った作業については疑いを持ちにくいものですし、完成した際の満足感や疲労感から、作業完了直後に見直しを行ってもミスに気付きにくい状態になっております。 そのため、作業完了直後ではなく、少し違う作業を挟んだり、ちょっと休憩するなど、脳に違う刺激や休息を与えてから見直すだけで、自分のミスに気づきやすくなります。 ◆実際の取り組み ・ 手順書の作成や修正が完了したら最低30分は別作業を挟んでから再確認 　過去資料流用時はサーバ名表記等に修正漏れが多いので検索機能で再確認すると効果的 この見直すという行為は、日常生活ですと手続き用の書類記入や手紙など、色々な場面で実践できそうです。 その２：他者レビュー 作業手順書や設定用ドキュメントを作成、修正する際には他者レビューを実施します。 思い込みや認識違いや記載漏れ 等をかなり減らすことができますので、なかなか有効な手段です。 とくに、お客様に提出するドキュメントや本番環境に関する手順や設定に使用するパラメータシート等は重要なので、他者レビューの実施が不可欠です。 先の「見直し」も有効な手段ではありますが、やはり当事者による再確認なので、どうしても 思い込みや願望というフィルター が存在してしまいます。また、人によっても注意が向くベクトルが異なりますので、自分とは違う相手からのチェックというものは、非常に有効です。 ◆実際の取り組み ・ 必ず他者レビューを実施して完了するまで次に進めないというルールを運用 　手順書を２人で分割作成したときに作成者の認識違いで抜けた作業を他者レビューで指摘できました 日常生活ですと、重要書類の記入時に奥さまや旦那さま、ご両親、ご友人、などなど、身近な方に確認してもらうと良いかもしれませんね。 その３：ダブルチェック システム全般に致命的な影響を与えるような作業は必ず２人で操作内容の確認を行います。時間に余裕が無く手順書を作成することができない時や、過去に実施した実績のある手順などの場合にも、ダブルチェックで作業をすることも多くあります。 ダブルチェックは、作業を行う際に２名体制でお互いに作業内容を確認しつつ実施していくというものです。先の「他者レビュー」と同じように、 １人の不注意や思い込みフィルター などのミスにつながる要因を減少させることが可能です。とくに、時間が無い時などは、すぐにでも着手できますので、緊急時にも有効な手段となります。 ◆実際の取り組み ・ 簡単な作業でも影響が大きいものはダブルチェック 　サイトのメンテナンス作業でユーザーアクセスをブロックした場合、作業終了後のブロック解除時刻指定はダブルチェックで行い、必ず予定時間にアクセス再開できるようにしています 日常生活ではお出かけ前に、窓やドアの鍵閉め、水道やガスの元栓の状態確認など、ご家族やご友人とダブルチェックすることができれば閉め忘れや止め忘れなどを確実に防止することができます。とくに長期旅行などで長く自宅を離れる場合などでも、安心して出かけることができますね。 その４：無理しない 夜間作業などを実施している時、やはり人間ですのでどうしても睡魔に襲われる時があります。そのような場合には、我慢して作業を進めても、集中力の欠如による誤認識や不注意による誤操作などによるミスが発生しやすいです。そのため、作業で重要なデータ等を誤って削除してしまい、取り返しのつかない事態に発展する可能性があります 。ですので、そのような時は無理をせず１０分～３０分の仮眠をとるようにしています。※お客様の許可の上で仮眠しています。通常業務時に仮眠しちゃダメです(笑) おトイレや空腹感などもそうなのですが、人間ですので生理的欲求というものが必ず存在します。そして、それらは生きるために必要な機能となりますので、自分で制御することはなかなか難しいです。根性でなんとかしたり、精神力でどうにかしようとするのは難しいです。 ましてや、睡魔に襲われた時などのように、生体リズムに基づいた機能低下状態で作業を続けることは、自分の健康にも良くないですし、作業効率的な面からも有効ではありません。 ですので、眠い時は素直に仮眠する、がベストな対策になると私も考えております。結果的には、その方が効率が上がり、ミスの発生も防げます。 ◆実際の取り組み ・ 深夜作業でどうしても眠いときはメンバー交代と15分の仮眠取得 睡魔を我慢して作業することが無くなり、睡魔による重大ミス（ストレージの初期化など）を防いでいます 日常生活では、資格の勉強をしているような場面で効果があると思います。集中力が途切れ、睡魔に襲われるような時は、時間を決めて休憩したり、仮眠をとるというのは有効な手段ではないでしょうか。 その５：再発防止を考える ここまで色々と書いてきました。有効な手段があるとはいえ、やっぱりミスしちゃう時は必ずあります。 そのような時には、なぜミスが起こったのか原因を考え、再発しないような対策を作り、実践することで、同じようなミスを防ぐことができるようになります。 ただ、再発防止に力を入れすぎると、結果的に作業負荷ばかりが増えることにもなりますので、バランスが重要になります。世間でも時々話題になりますが、不祥事や事故が起きた際、一生懸命に原因追求と再発防止策を検討します。でも、そのせいで手順が煩雑になったり、審査が厳しくなったり、不便になることも少なからずあります。 再発防止の目的は、あくまでミスを防ぐことにありますので、仕組みやルールはできるだけシンプルな方が良いかなと思う次第です。 ◆実際の取り組み ・ 本番作業のミスは原因分析と再発防止策を策定して同じミスは起こさない 　間違って違うコマンドを入力した事例から、その作業は完全自動化バッチを作成することでミスの発生を防いでいます なお、日常生活で発生したミスについては、何故ミスしたのか？どうすれば防げるか？を常に模索することが重要になります。それを踏まえたうえで、実践可能な対策を実現できれば、もう同じミスは発生しにくくなります。 おわりに 以上、取り組みとして５つの実例を紹介させていただきましたが、いずれも使い古された手法であり、全て当たり前だと思うような基本的な事柄です。とはいえ、基本的な事柄を徹底して行い、習慣化することで、ミスを減らすことは必ず可能となります。私の経験からも、上記手法は効果があると考えております。 人間は生き物ですので、もともとミスをしやすい側面があります。勘違い・思い込み・錯覚・物忘れ・不注意・願望などが要因となることも多いです。そのため、そのような側面があることを理解したうえで、作業に取り組むことが有効ではないかと考えております。ただ、どうしても対策のための工数が発生しますので、バランスを考慮して取り入れていくことが重要かと思います。 ミスを減らすという取り組みは、システム運用では安全工学や信頼設計によるアプローチがありますが、今回紹介させていただいた内容は、どちらかというと認知心理学等の範疇となる認識や行動に着目したアプローチになると考えております。ミスを防止するために人間としての特性を意識した対策を考えていくことも有効ではないでしょうか。 最後まで読んで頂き、ありがとうございました。 The post 人間はミスをする生き物なんです ～システム保守運用業務で取り組んでいる5つのこと～ first appeared on Sqripts .

こんにちは。インフラエンジニアのTYです。普段はAWSやAzureなどのクラウドサービスを扱ったサービスの構築及び、検証などの業務を行っています。 システム導入時の検証でAsteriskを使用したPBX環境を構築しました。今回はAsteriskについてご紹介致します。 1.Asterisk概要 AsteriskはオープンソースのPBX（Private Branch eXchange）です。PBXはオフィスやコールセンターなどのように1つの親番号に着信しそこから適切な内線電話機やオペレーターに通話を転送する必要がある際に使用されます。 AsteriskはPSTNやSIPプロトコルによる通信はもちろんのこと、ACDシステムにWebRTCの機能を持たせて、利用することが可能です。   ＊ACD (Automatic Call Distribution)：着信呼自動分配装置   ＊WebRTC (Web Real-Time Communication)：ブラウザから発信される映像や音声・その他ファイルといったデータを優れた処理能力で通信する技術 Asteriskの一部機能となりますが、次項からAsteriskをSIPサーバーとして構築し、SIPによる内線通話を実現する環境を構築したいと思います。 2.構築 AWS EC2インスタンスにUbuntuをインストールし、そこにAsteriskをインストールしてSIPサーバーを構築していきたいと思います。 簡単な構成は以下の図のようになります。   では、構築していきましょう。 2.1 AWS 今回はAWS EC2インスタンスを利用します。もちろんローカル環境で行っても問題ありません。 2.1.1 EC2インスタンスの起動 Ubuntuを選択してセットアップを進めます。インスタンスタイプは小さいもので大丈夫です。 2.1.2 セキュリティグループ 以下のように設定します。 ※ SIPで使うUDPポートはデフォルトでは5060ですが、外部にAseteriskを構築する場合は、5060で空けないようにします。SIPのデフォルトポートを変更することでSIPを利用した攻撃の可能性を低減することができます。 2.2 Asteriskの導入 2.2.1 Asteriskのインストール 作成したEC2インスタンスにSSHでログインします。システムが更新されているか確認してください。 $ sudo apt-get update 今回aptでのインストールではAsteriskで使用を予定している機能が含まれていなかったため、今回はソースをダウンロードし、コンパイル時に使用する機能を含める状態にして ビルドします。 $ cd ~ $ wget　http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-18-current.tar.gz $ tar -xvf asterisk-18[tab] $ cd asterisk-18.[tab] $ sudo su # contrib/scripts/install_prereq install # ./configure --with-pjproject-bundled # make menuselect # make && make install && make config # exit $ cd ~ $ make menuselect はデフォルトのままsave&exitで大丈夫です。 最後に以下コマンドを実行しAsteriskのサンプル設定ファイルをインストールします。 ~/asterisk-18.19.0$ make sample 2.2.2 Asteriskの設定 内線電話番号を2つ設定し、お互いに通話がつながるようにします。この際に設定する必要のあるファイルは”pjsip.conf”と”extensions.conf”の2つです。 /etc/asteriskに移動すると以下のようにたくさんのファイルがあると思いますので、一旦”pjsip.conf”と”extensions.conf”のファイル名を変更します。 $ mv pjsip.conf pjsip_conf_bak $ mv extensions.conf extensions_conf_bak それでは設定していきましょう。 まずはpjsip.confです。SIPサーバーに関する設定や内線電話（SIPクライアント）からの認証情報を設定します。 /etc/asterisk/pjsip.conf を以下のように設定します。 [transport-udp] type=transport protocol=udp bind=0.0.0.0:5070 #デフォルトでは5060 [6001] type=endpoint context=from-internal disallow=all allow=ulaw auth=6001 aors=6001 rewrite_contact = yes # 6001がNAT環境下の場合、必要。 [6001] type=auth auth_type=userpass password=userpassword username=6001 [6001] type=aor max_contacts=10 [6002] type=endpoint context=from-internal disallow=all allow=ulaw auth=6002 aors=6002 rewrite_contact = yes # 6002がNAT環境下の場合、必要。 [6002] type=auth auth_type=userpass password=userpassword username=6002 [6002] type=aor max_contacts=10 “6001”,”6002”の type=auth にある”userpassword” は自由に設定してください 続いてextensions.confです。内線電話（SIPクライアント）からの発着信時のルールをここに記述します。 /etc/asterisk/extensions.confを以下のように設定します。 [from-internal] exten = 100,1,Answer() same = n,Wait(1) same = n,Playback(hello-world) same = n,Hangup() # 6001がコールされたらSIPの6001を呼び出す exten = 6001,1,Dial(PJSIP/6001,30,r) same = n.Hangup() # 6002がコールされたらSIPの6001を呼び出す exten = 6002,1,Dial(PJSIP/6002,30,r) same = n.Hangup() ここまで設定出来たら以下のコマンドでAsteriskを再起動します。 $ systemctl status saterisk ここまででAsteriskの設定は完了です。実際にSIPクライアントを接続し通話を行ってみましょう。 3.実機テスト 3.1 SIPクライアント設定 前章までの設定でAsteriskはSIPサーバーとしての機能を持つことができています。実際に通話ができるか確認する際には設定したAsteriskにSIPクライアントを登録(レジスト)して利用します。SIPクライアントはなんでも大丈夫ですが、今回はSIPクライアントとしてZoiperを利用します。 手元の端末2台にzoiperをインストールしたら起動し右下の歯車マークからAccountsを選択します。次にSIPAccountsを以下のように設定します。 設置画面には以下のように設定します。青枠のDomainの部分にはご自身のAsteriskサーバーのIPアドレスorドメインを入力、Passwordにはpjsip.confで設定したパスワードを入力してください。入力できたらregisterを選択し以下の画像のようにStatusがOKになればAsteriskにSipクライアントがレジストされています。 もう片方のSipクライアントも上記と同様にpjsip.confで設定したSipアカウントの情報を入力してください。本記事の内容通りだと6002のSIPアカウントがあると思います。 3.2 内線番号6001から内線番号6002に発信 ここまで設定ができたらZoiperの左下にあるDialPadから6001のアカウントなら6002にダイヤルし発信してみてください。うまく設定ができていれば6002のクライアントに着信するはずです。 4.まとめ これでAsteriskを簡単なSIPサーバーとして構築し内線環境を構築することができました。この程度の設定で内線通話ができることは始めて構築した際は結構感動しました。 今回は内線の環境ですがTwilioやひかり電話などをAsteriskにレジストすることで、PSTN回線を用いてSIPクライアントと通話することなどもできますし、Asteriskはhttpサーバーの機能もあるため、Websocketサーバーとして運用することでWebRTC-Sipクライアントの通話も構築次第で可能になります。 私もまだまだ勉強中ですが、そのあたりの設定も機会があればまたお話ししたいと思います。 ありがとうございました。 The post Asterisk入門　～SIPフォンで通話してみる～ first appeared on Sqripts .

本連載では、ブロックチェーンの基本的な仕組みを解説しながら、オンチェーンデータを分析するための基本的な手法について、全8回で紹介します。 第7回の今回は、Ethereumのトランザクションに紐づくデータ構造の深掘りや、データ分析でよく用いられる発展的なSQLの構文についての解説をおこないます。 Ethereumのトランザクション詳解 Bitcoinの場合、各アカウントが保持する状態は基本的にビットコインの残高であり、その変更は送金やマイニングといった１つのトランザクションを最小単位として行われます。一方、Ethereumの場合は、各アカウントのイーサ残高のほかに、スマートコントラクト上のさまざまなデータを状態として保持しており、状態変化のアクションはBitcoinほど単純ではありません。また、１つのトランザクションの中に複数のアクションが含まれることがあります。あるトランザクションを起点として、複数のスマートコントラクトの関数を呼び出すといったことも可能です。こういった複雑なアクションを分析するために、TracesやLogsといったデータ構造が存在します。 TransactionsとTraces EthereumにおけるTracesとは、トランザクションを起点としておこなわれるさまざまな状態変化のアクションの最小単位を記録したものです。Etherscan( https://etherscan.io/ )などのエクスプローラーでは、「internal transactions」といった形で表現されることもあります。コード1は、Dune( https://dune.com/ )上で過去24時間以内のTracesデータを100件取得するクエリです。 コード1 . 最新24時間以内のEthereumのTracesデータを100件取得するクエリ SELECT * FROM ethereum.traces WHERE block_time >= CURRENT_TIMESTAMP - INTERVAL '24' hour LIMIT 100 図1. コード1.の出力結果例：ethereum.tracesテーブルのサンプルデータ コード2は、Tracesの種類の一覧とアクション数を取得するためのクエリです。計算量の削減と計算結果の固定のため、対象期間を2023年1月1日から31日までの間に絞り込んでいます。 コード2 . traces.typeの種類ごとにカウントして多い順に並べ替えるクエリ SELECT type, count(1) as cnt FROM ethereum.traces WHERE block_time BETWEEN timestamp '2023-01-01 00:00:00' AND timestamp '2023-01-31 23:59:59' GROUP BY type ORDER BY cnt desc LIMIT 100 図2. コード2.の出力結果例 図2に示されるとおり、Tracesの種類には、callやcreate、reward、suicideなどがあります。最も件数の多いcallは、Etherの送金やスマートコントラクトの関数を呼び出す場合に用いられます。createは、スマートコントラクトを新規作成する場合に用いられます。rewardは、ブロック生成時の報酬に関するログに用いられますが、Ethereumの報酬に関する仕様は頻繁に変更されており、現在では使用されていません。suicideは、スマートコントラクトの削除に関するアクションに用いられます。 図3で示すとおり、Etherscan上では、Tracesの内容はInternal Txnsというタブで確認することができます。 図3. Etherscanで特定のトランザクションに関するInternal Transactionsを確認するサンプル画面 （ etherscan.ioの実際の画面はこちら ） 同様の内容を、Dune上でも参照してみましょう。コード3.を用いて、特定のトランザクションに紐づくTracesの情報を取得できます。トランザクションハッシュのみの指定でもデータは取得できますが、データの探索範囲を絞り込むためにWHERE句で期間も指定しています。 コード3 . 指定したトランザクションのTracesを取得するクエリ SELECT trace_address, call_type, "from", to, value, gas FROM ethereum.traces WHERE block_time >= timestamp '2023-10-20 00:00:00' AND tx_hash = 0x7900ef4293837b14cdf8814396e45b9380636cdfb7c55fe05a7343628b8b1ae0 LIMIT 100 図3および図4を見比べて、表記の違いはあるものの、同様のデータが取得できていることを確認してみてください。 図4. コード3. の出力結果例 TransactionsとLogs TracesがEVMの仕様によってほぼ自動的に出力されるログである一方、Logs（Event Logs）はスマートコントラクトの実装者が明示的に定義できるログの種類です。Logsは関数のデバッグ用途や、トランザクション内のイベントをブロックチェーン外のシステムから検知するためなどに用いられます。 コード3のテーブルをLogs用に変更して、さきほど見たトランザクションに関するLogsを取得するクエリがコード4です。 コード4 . あるトランザクションのLogsを取得するクエリ SELECT * FROM ethereum.logs WHERE block_time >= timestamp '2023-10-20 00:00:00' AND tx_hash = 0x7900ef4293837b14cdf8814396e45b9380636cdfb7c55fe05a7343628b8b1ae0 LIMIT 100 図5.コード4.の出力結果例 図6. Etherscanで特定のトランザクションに関するLogsを確認するサンプル画面 （ etherscan.ioの実際の画面はこちら ） 図6に示すとおり、Etherscanなどのエクスプローラーでは、著名なコントラクトについてはLogsのデータもデコードされた状態で表示されます。一方、Ethereumブロックチェーン上の生データやDuneのLogsテーブル上では、データはバイナリ形式でエンコードされた状態であり、そのままでは理解が困難です。また、さまざまなフォーマットのログをデコードするには、そのログがどのようなフォーマットであるかという定義情報が必要です。 Dune上では、それぞれのコントラクトの定義情報を用いてデータをデコードしたテーブルを提供してくれています。さきほどまで参照していたトランザクションであれば、uniswap_v3というDEX（オンチェーン上の分散型取引所）のトランザクションとしてデコードされています。 コード5 . uniswap_v3のトレードデータとしてデコードされたトランザクションを取得するクエリ SELECT * FROM uniswap_v3_ethereum.trades WHERE block_time >= timestamp '2023-10-20 00:00:00' AND tx_hash = 0x7900ef4293837b14cdf8814396e45b9380636cdfb7c55fe05a7343628b8b1ae0 LIMIT 100 図7. コード5の出力結果例 Duneでは、デフォルトでデコードされていないデータであっても、利用者がスマートコントラクトの情報などを登録してデコードの申請をすることも可能となっているので、自身の作成したコントラクトや、比較的新しいコントラクトのデータを分析する場合に活用してください。 データ分析のためのSQL 前半でご紹介したTracesやLogsデータを対象として、データ分析でよく用いられるSQL構文のうち、使用頻度も高いCASE式とWindow関数についてご紹介します。 CASE式と集約関数 CASE式は、条件式にしたがって値の場合分けをおこなうための式です。「CASE WHEN 【条件式】THEN【真の場合の値】ELSE【偽の場合の値】END」という構文を用います。コード6. に、Logsテーブルのtopicカラムの値が存在しているかどうかで0または1を出し分けるサンプルクエリを示します。SQLにおいて、値が存在していないフラグとして「NULL」を用い、NULLであるかどうかは「IS (NOT) NULL」を用います。 コード6 . CASE式で値の場合分けをおこなうサンプルクエリ SELECT topic0, topic3, CASE WHEN topic0 IS NOT NULL THEN 1 ELSE 0 END AS have_topic0, CASE WHEN topic3 IS NOT NULL THEN 1 ELSE 0 END AS have_topic3 FROM ethereum.logs WHERE block_time BETWEEN timestamp '2023-01-01 00:00:00' AND timestamp '2023-01-31 23:59:59' LIMIT 100 図8. コード6. の出力結果例 このCASE式と集約関数を組み合わせてデータ分析を用いるテクニックがいくつかあります。例えば、Logsテーブルにおいて、topic0～3の値がレコード全体のうちどれくらいの割合で存在しているかを集計したい場合を考えます。直感的には、「topicの値が存在しているレコードの数」を「レコード全体の数」で割ることで割合を計算できます。これは、CASE式を用いて「topicの値が存在している場合は1、存在していない場合は0」という変換をおこない、それをAVG関数で平均してあげることでも計算できます。コード7.に、CASE式とAVG関数を用いて割合を計算するサンプルクエリを示します。 コード7 .CASE式とAVG関数を組み合わせて割合を計算するサンプルクエリ SELECT COUNT(1) AS cnt, AVG(CASE WHEN topic0 IS NOT NULL THEN 1 ELSE 0 END) AS have_topic0, AVG(CASE WHEN topic1 IS NOT NULL THEN 1 ELSE 0 END) AS have_topic1, AVG(CASE WHEN topic2 IS NOT NULL THEN 1 ELSE 0 END) AS have_topic2, AVG(CASE WHEN topic3 IS NOT NULL THEN 1 ELSE 0 END) AS have_topic3 FROM ethereum.logs WHERE block_time BETWEEN timestamp '2023-01-01 00:00:00' AND timestamp '2023-01-31 23:59:59' LIMIT 100 図9. コード7. の出力結果例 また、CASE式と集約関数を組み合わせることで、レコードごとに保持していたデータをカラムごとに保持するフォーマットに変換することもできます。 コード8は、uniswap_v3のtradesテーブルから、USDT-WETHとUSDC-WETHという通貨ペアの取引に絞り込み、取引数や取引総額を集計するクエリです。 コード8 . 通貨ペアの取引数・取引総額を集計するクエリ 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 IN ('USDT-WETH', 'USDC-WETH') GROUP BY token_pair LIMIT 100 図10. コード8. の出力結果例 コード8の集計結果を、日次の取引数や取引総額に細分化して分析することを考えます。このとき、GROUP BY句にblock_dateを加えることで求める結果は計算できますが、すべての計算結果が別々のレコードとして表示されるため、異なる通貨ペアの同じ日付での取引の比較などが少し難しくなります。そこで、CASE式とSUM関数を用いて、レコードは日付ごとに集約し、カラムで通貨ペアの場合分けをおこなうことで、同じ日付の取引を比較分析しやすいフォーマットに変換できます。 コード9 .CASE式とSUM関数を用いて、異なる分類のデータをひとつのレコードに集約するクエリ SELECT block_date, SUM(CASE WHEN token_pair = 'USDT-WETH' THEN 1 ELSE 0 END) AS usdt_weth_cnt, SUM(CASE WHEN token_pair = 'USDC-WETH' THEN 1 ELSE 0 END) AS usdc_weth_cnt, SUM(CASE WHEN token_pair = 'USDT-WETH' THEN amount_usd ELSE 0 END) AS usdt_total_amount_usd, SUM(CASE WHEN token_pair = 'USDC-WETH' THEN amount_usd ELSE 0 END) AS usdc_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 IN ('USDT-WETH', 'USDC-WETH') GROUP BY block_date ORDER BY block_date LIMIT 100 図11. コード9. の出力結果例 Window関数 SQLのベースとなっている関係代数や集合論では、データの順序を扱うために特殊な手順が必要でした。しかし、SQLが時系列データやその他の順序付きデータの分析用途にも用いられるようになり、データ分析に特化した構文の需要が高まりました。そこで導入されたのが、Window関数と呼ばれる関数群です。 コード10は、コード9で計算したuniswap_v3の日次取引データに対して、Window関数を用いたサンプルクエリです。Window関数の多くは、集約関数に続いてOVER句を用いる形で記述できます。 例えば、SUM() OVER()関数を用いると、GROUP BYによるレコードの集約をおこなうことなく、各レコードに対して全体のデータの合計値を付加することができます。また、OVER句の中にORDER BY句で順序を指定することで、先頭からそのレコードまでの累計値を計算して各レコードに付加することができます。LAGやLEAD関数は、現在のレコードの前後のレコードの値を参照するために用いられます。例えば、１月２日の取引数を保有しているレコードに対して、１月１日や１月３日など、他の日付のレコードを参照することが可能です。 コード10 . Window関数でデータの累計や総計を計算するサンプルクエリ WITH daily_trades AS ( SELECT block_date, SUM(CASE WHEN token_pair = 'USDT-WETH' THEN 1 ELSE 0 END) AS usdt_weth_cnt, SUM(CASE WHEN token_pair = 'USDC-WETH' THEN 1 ELSE 0 END) AS usdc_weth_cnt, SUM(CASE WHEN token_pair = 'USDT-WETH' THEN amount_usd ELSE 0 END) AS usdt_total_amount_usd, SUM(CASE WHEN token_pair = 'USDC-WETH' THEN amount_usd ELSE 0 END) AS usdc_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 IN ('USDT-WETH', 'USDC-WETH') GROUP BY block_date ) SELECT block_date, usdt_weth_cnt AS daily_cnt, SUM(usdt_weth_cnt) OVER(ORDER BY block_date) AS accum_cnt, SUM(usdt_weth_cnt) OVER() AS total_cnt, LAG(usdt_weth_cnt) OVER(ORDER BY block_date) AS prev_daily_count, LEAD(usdt_weth_cnt) OVER(ORDER BY block_date) AS next_daily_count FROM daily_trades ORDER BY block_date LIMIT 100 図12. コード10. の出力結果例 Window関数では、OVER句の中にPARTITION BY句を用いて、集約範囲のグルーピングをおこなうこともできます。コード11では、Tracesテーブルの各レコードに対して、同じトランザクションIDを持つレコードの総数や、同じトランザクションIDを持つレコード内でtrace_address順に並べ替えたときのインデックス番号を付与する例を示します。 コード11 . PARTITION BY句によるWindow関数のグルーピング例 SELECT tx_hash, trace_address, COUNT(1) OVER(PARTITION BY tx_hash) AS trace_cnt, ROW_NUMBER() OVER(PARTITION BY tx_hash ORDER BY trace_address) AS trace_idx FROM ethereum.traces WHERE block_time BETWEEN timestamp '2023-01-01 00:00:00' AND timestamp '2023-01-01 23:59:59' ORDER BY tx_hash, trace_address LIMIT 100 図13. コード11. の出力結果例 CASE式やWindow関数を用いることで、SQLを単なるデータ抽出だけでなく、高度なデータ分析のツールとして活用できます。SQLを用いて計算した結果は、別のSQLクエリの入力に使うこともできるため、分析結果の共有や再利用性も高く、複数人のチームやプロジェクトによる大規模なデータ分析にも有用です。 次回予告 今回の記事では、TracesやLogsといったEVMのデータ構造の深掘り、および、CASE式やWindow関数といった分析用途で頻出するSQL構文について解説しました。次回記事では、本連載の最終回として、より発展的なオンチェーンデータ分析の事例についてご紹介します。 連載一覧 【第1回】ブロックチェーンとは 【第2回】ビットコインの仕組み 【第3回】イーサリアムの仕組み 【第4回】ビッグデータ分析のためのSQL基礎 【第5回】Ethereumデータ分析演習1 【第6回】Ethereumデータ分析演習2 【第7回】Ethereumデータ分析演習3 The post 【第7回】Ethereumデータ分析演習3 first appeared on Sqripts .

はじめまして、QAエンジニアの田中です。今回はアジャイル開発手法の一つのBDDについてご紹介したいと思います。 BDDとは何か？ BDD（Behavior-Driven Development）は、ビヘイビア駆動開発や振る舞い駆動開発とも呼ばれ、テスト駆動開発から派生したものです。ソフトウェアの振る舞いや機能を重視して、品質と要件の向上をめざします。具体的には、ソフトウェアの振る舞いを明確に定義することで、プログラム開発とテストを効率化することができます。 まず初めに、自動販売機の例を通して、BDDを説明していきます。自動販売機では、お客さんがお金を投入し飲み物を購入できます。BDDの視点から、具体的な振る舞いのシナリオを考えてみましょう。 シナリオ1: お客さんがお金を投入して自動販売機で飲み物を購入しようとする もし、お客さんが自動販売機にお金を投入し、飲み物の選択ボタンをクリックしたら、選択ボタンに応じた飲み物が出てくるべきです。 そして、おつりが必要な場合、自動販売機は、必要な金額をおつりとして、お客さんに出すべきです。 シナリオ2: お客さんがお金を投入しないで自動販売機で飲み物を購入しようとする もし、お客さんが自動販売機にお金を投入せずに、飲み物の選択ボタンをクリックしたら、飲み物が出てくるべきではないです。 このシナリオは、ビジネスの視点からソフトウェアの振る舞いを記述したものであり、BDDはこのようなシナリオを通じてソフトウェアの開発とテストを導く手法です。鍵となるポイントは、ビジネス要件とソフトウェアの振る舞いを結びつけ、それに基づいてテストを設計し、ソフトウェアを開発することです。 この自動販売機の例から、BDDが開発プロセスを明確にし、チームが顧客の要件を正確に理解するのに役立つことがわかります。これにより、顧客の期待に応える高品質なソフトウェアを迅速に提供することが可能になります。 BDDについて更に詳しく知りたい方は、本サイトでスクリプターのブロッコリーさんが詳しい記事を書いておりますので、そちらを参照願います。 ■ 【連載】TDDの派生形！BDDやATDDとは何か? 概念からプロセスまで徹底解説！ スクリプター：風間裕也（ブロッコリー） BDDの特徴・メリット BDDの特徴やメリットには、下記のようなものがあります。 振る舞いに焦点を当てる 開発者、テスター、ビジネスステークホルダーが共通の理解を持つために、振る舞いに対する要件や期待値を明確に定義します。非開発者と開発者間の認識齟齬の低減が期待でき、プロジェクトの効率を向上させます。 自然言語で記述 テストのシナリオ（テストケース）において振る舞いや要件を自然言語で記述します。シナリオは様々なフェーズのテストで柔軟に活用でき、開発者が書く自動テスト（ユニットテスト、インテグレーションテストなど）などの開発者テストでも適用可能です。非技術者も理解しやすく、コミュニケーションの質を向上させます。日本語で書かれたテストシナリオがそのまま実行でき、異なるパラメータの入力も日本語で記述されたシナリオ内で表現できます。一般的な文法は「Given-When-Then」で表現され、前提条件（Given）、アクション（When）、結果（Then）を記述します。非開発者による振る舞いや要件の記述(シナリオ作成)が期待できます。後ほど、例を用いて説明します。 テストケースとしてのBDD BDDはテストケース(シナリオ)を自動化するための方法としても使用されます。BDDフレームワークを使用して自動テストケースを記述し、実行することで、振る舞いに関する問題を特定し、外部品質を確保します。また、リファクタリングなどの内部実装変更に対して、テストケースが影響を受けないため、テストケースのメンテナンスが減ります。 テストファースト・シフトレフト BDDは、テストファースト・シフトレフトの原則に基づいています。コードを書く前に振る舞いや要件を明確にし、それに基づいてシナリオを記述します。その後、それに合格するプロダクトコードを書いていきます。これにより、テスタビリティの高い、かつ疎結合なコードが作成されることにより、各部分が独立してテストでき、特定の変更が他の部分に影響を与えにくくなるため、コードの品質向上とバグの早期発見を実現できます。早い段階で問題点をフィードバックすることで、大きな手戻りや未然にバグを防ぐことが可能で、全体のテスト時間を短縮し、コスト低減も期待できます。 QAエンジニアからみたBDDのメリット では、QAエンジニアからみたBDDのメリットには、どのようなものがあるでしょう？BDDを導入することで、QA(品質保証)の観点からは、次のようなメリットがあります。 開発者とQAエンジニアの共通理解の促進 開発者とQAエンジニアの連携が強化されます。開発者とQAエンジニアが共通のBDDの仕様や振る舞い定義に基づいて作業を行うため、コミュニケーションや理解が容易になります。 QAエンジニアによるテストのレビュー・作成が可能 QAエンジニアは開発者テスト段階からテストのレビュー・作成を行えるようになります。BDDの仕様に基づいてシナリオを作成し、テストの品質を向上させることができます。 つまり、BDDを導入することで、品質保証プロセスにおいて開発者とQAエンジニアの連携が強化され、テストの品質向上を実現することができます。 BDDの進め方 では、BDDの進め方について、 ブロッコリーさんの記事 の例を参考に、見てみましょう。 TDDとBDD/ATDD(5)　BDDのプロセスその1「発見(Discovery)」と実例マッピング より まず、「#1 ユーザーストーリーを選ぶ」では、システムにおいて実装すべき機能を引き出し、優先順位を付けて行きます。 次に「#2 要件ワークショップ」では、優先順位を付けられた機能に対して、振る舞いの実例を基に詳細な要件を探索し、明確になっていなかった要件を発見していきます。 TDDとBDD/ATDD(5)　BDDのプロセスその1「発見(Discovery)」と実例マッピング より 次に、実例をシナリオに変換する「#3 定式化」を行います。ここでは、振る舞い定義に基づいたシナリオが自然言語(Gherkin ※1 記法など)で記載されているため、開発者はもちろんQAエンジニアにもシナリオの理解が深まり、開発者テスト段階からテストのレビュー・作成を行うことが可能です。これにより、開発の早い段階からQAエンジニアが参画してテストを行うことができるため、テストの品質向上につながります。 Feature: 自動販売機 Scenario: 飲み物を買うと、飲み物代を引いた金額のお釣りが出る Given 自動販売機がある When 550 円を入れる And 120 円の "コーラ" を選択する Then "コーラ" が出てくる And 430 円が出てくる 「#4 レビュー」では、他のチームメンバーからの視点を取り入れることで、潜在的な問題を特定し、誤解や不足を解消し、ソフトウェアの品質を高めます。「#5 自動化」では、BDDのフレームワークを導入により自動テストのコードを書きます。自動化についての詳細については、下記を参考にしてください。 参考： TDDとBDD/ATDD(7)　BDDのプロセスその3「自動化(Automation)」 スクリプター：風間裕也（ブロッコリー） TDDとBDD/ATDD(7)　BDDのプロセスその3「自動化(Automation)」 より 次に下記の３つのサイクルを回し、コードを「#6 実装」していきます。 Red：プログラマーがテストを書く Green：テストが成功するのに十分なコードを書く Refactor：コードを整理する テストコードをシナリオに合わせて作成し、それをパスするコードを実装、このプロセスを繰り返します。「#7 補足的なテスト」では、自動テストを補う形で、探索的テスト、侵入テストや負荷テストを行い、ソフトの品質を高めていきます。最後に、出荷可能なインクリメントを生成「#8 リリース」して、次の開発につなげます。 事例(PoCをやってみた) BDDを導入することで、QAプロセスにおいて開発者とQAエンジニアの連携が強化され、テストの品質向上を実現できることが明らかです。しかし、理論的なメリットを持つ取り組みが実際の現場でどのように機能するかは、常に疑問が残ります。 そのため、想定しているQA目線でのメリットが実際に享受できるかをPoCで確認してみることにしました。 PoC事例詳細 プロジェクトの品質向上を目指し、テストに関する課題を解決するために、BDDの導入による品質向上の具体的な効果を実証し、その実現可能性を探ってみました。 難しい要件があるプロジェクトで、下記のようないくつかの課題を抱えており、品質を十分に担保できるかに懸念を抱いていました。 開発者によるテストに十分な時間が確保されていない 開発者だけでテストケースを作成しているため、テストケースを過不足なく洗い出せるか不安 開発者によるアサーション（テストの条件や期待結果）の設定が難しい そこで、BDDを取り入れて、上記の改善を図ることを目指すPoCを実施しました。実際に行った手順は、下記の通りです。（今回のPoCでは、BDDの進め方の「#2 要件ワークショップ」から「#6 実装」のプロセスを実施しています。） 実例を基にした要件整理とテストケース作成 開発者とQAエンジニアは、実際の実例を基に詳細な要件を整理し、ビジネス要件を明確にしました。その後、QAエンジニアはGherkin記法を用いて、テストケースを記述しました。これは、BDDの進め方の「#2 要件ワークショップ」「#3 定式化」に該当します。 テストケースの合同レビュー 開発者とQAエンジニアはテストケースについて「#4 レビュー」を行い、テストケースを明確化しました。 テストコード実装 開発者は、テストケースを基にテストコードを実装していきます。これは、BDDの進め方の「#5 自動化」に該当します。 今回のテスト自動化環境では、テストのフレームワークでは、pytest-bddを使用しました。これは、開発言語としてはPythonが用いられていたこと、元々ユニットテストがpytestで書かれておりユニットテストの資産流用を考慮したためです。pytest-bddは、pytest ※2 で振る舞い駆動を実現するために、Gherkinで記載したテストケースとPythonのコードを紐づけてくれる役割を持っています。 コードの実装 開発者は、pytest-bddで自動化テストを行い、パスするコードを作成しシステムに実装していきました。このステップは、BDDの進め方の「#6 実装」に該当します。 PoCで見えてきた課題と、解決に向けた取り組み 最初は順調に見えたPoCですが、進めていく中で次のような課題が出てきました。 多数のテストケースとテストコードが作成されたため、対応関係を理解しにくく、管理が煩雑 新機能の実装に専念するため、開発者によるテストコードの作成のための時間が不足 開発中に、多くのテストケースを通過させながらコードを実装する際、テスト・実装進捗の管理が難しい そこで、課題の解決のために、次のような対策を立てました。 テストケースとテストコードの関連性を明確に管理するための管理ツールを作成する 高品質のテストを開発と同時に進めるため、QAエンジニアがテストケースだけではなくテストコードも作成する。 コード実装の進捗状況をテストのパス数で可視化するための、試験結果・コード実装進捗の表示ツールを作成する。 BDDの開発プロセスにおいて、QAエンジニアが開発の初期段階で、管理ツールや試験結果表示ツールの対応、そしてテストコード作成をサポートしたことにより、開発者の品質向上に対する負荷を軽減し、ソフトウエアの品質を向上させることができました。 まとめ BDDは、ソフトウェア開発プロセスの品質と効率性を向上させる強力な手法です。現代のビジネス環境は変化し続けており、ソフトウェア開発においては柔軟で迅速な対応が求められます。BDDは自然言語で要件を記述し、シナリオを作成し、迅速なフィードバックを通じて顧客の要求に柔軟に対応するのに非常に効果的です。さらに、開発チームとテストチームが協力し、BDDフレームワークを使用して自動テストを実施することで、生産性の向上、品質の向上、および顧客満足度の向上を期待できます。この記事がBDDを導入のきっかけとなったり、チーム全体で実践を通してソフトウェア開発プロセスの品質向上と効率化を図る参考になれば幸いです。 APPENDIX:用語の説明 ※1 Gherkin： Cucumberなどのテストフレームワークがテストケースを定義するために使用する言語。この言語の目的は、ビジネスアナリストやマネージャを含む開発チーム全体にわたって、BDDの実践を促進することにある。これは、ビジネスマネジメントによる要件定義の初期段階や、開発ライフサイクルの他の段階において、強固で曖昧さのない要件を強制しようとしている。自動テストのためのスクリプトを提供することに加えて、Gherkinの自然言語構文は、テスト対象のコードの簡単な文書化を提供するように設計されている。 ※2 pytest：PyPyプロジェクトから生まれたPythonのテストフレームワーク。ユニットテスト、統合テスト、エンドツーエンドテスト、機能テストなど、様々な種類のソフトウェアテストを書くために使うことができる。その機能には、パラメトリックテスト、フィクスチャ、アサート書き換えなどがある。 The post BDDについて ～ ソフトウェアの振る舞いに焦点を当て、要件を明確にし、コミュニケーションを改善 ～ first appeared on Sqripts .

こんにちは、バックエンドエンジニアのまさです。 最近、開発プロセスを効率化するための取り組みの一つとして、Github Copilotを利用しています。この記事では、Github Copilotを使ってみた結果、開発効率が劇的に向上した経験について共有したいと思います。 Github Copilotとは Github Copilotは、AI（人工知能）を利用してコーディングの補完や提案を行う開発ツールです。このツールは、コードを書く際に、自動的にコードの断片や関数を提案してくれます。また、コードの文脈に基づいて、適切なコードスニペットを生成することもできます。Github Copilotは、プログラミング言語やフレームワークに関係なく使用することができます。 まずは試してみる｜GitHub Copilotの使い方 普段は開発用のIDEとしてVSCodeを利用しています。VSCodeには こちら のGitHub Copilot用の拡張プラグインがありますので、こちらをインストールして使用します。 プラグインをインストールした後、新規にファイルを作成してCopilotを試してみます。今回はGo言語で試してみるため、 main.go というファイルを作成します。 試しにクエリパラメータを受け取り、それをレスポンスとして返却するHTTPサーバーを実装してみたいと思います。 まずは、 main.go に以下のようにコメントで記述します。 // httpサーバーでユーザーからのリクエストをqパラメタで受け取り、それをレスポンスとして返す処理の実装 そして改行すると このようにcopilotが続けてコメント候補を提案してくれます。 今回はそのまま記述を行いたいのでパッケージ文 package main を記述しようと思います。 そのため一文字目のpという文字を打ち込むと 打ち込もうとした package main を候補として提案してくれました。 これはそのまま利用したいためtabキーを押下し、提案を承諾します。 続けて2行改行すると次は import文の提案をしてくれます。以降は改行→提案承諾という形でしばらく進めてみます。 すると最終的には下記のような動作するコードを生成してくれます。 動作を確認するため、以下のようにしてこのプログラムを実行します。 go run main.go コマンドを実行するとサーバー処理が起動し、リクエスト受付状態となります。 別のターミナルから下記のようにコマンドを実行してみます。 curl localhost:8080?q=test 「hello test」のように出力がされると思います。 最初のコメントに記載したとおり「httpサーバーでユーザーからのリクエストをqパラメタで受け取り、それをレスポンスとして返す処理の実装」を達成できました！ テストでの活用 Github Copilotはテストコードの作成にも役立ちます。テストケースやアサーションの生成、モックオブジェクトの作成など、テストに関連するコードの自動生成が行われます。これにより、手作業でのテストコードの作成時間やミスの可能性を減らすことができます。 実際に例を以下に記載したいと思います。 まずテスト対象のコードです。 ファイルは src/common/utils.go として作成してあります。 package common type ItemList struct { IdList []int ItemMap map[int]Item NameConcat string TotalPrice int } type Item struct { ID int Name string Price int } // Item配列を受け取り、ItemListを返す関数 func NewItemList(items []Item) *ItemList { // ItemListを初期化 itemList := &ItemList{ // IdListを初期化 IdList: []int{}, // ItemMapを初期化 ItemMap: map[int]Item{}, // TotalPriceを初期化 TotalPrice: 0, } // itemsを回す for _, item := range items { // IdListにitem.IDを追加 itemList.IdList = append(itemList.IdList, item.ID) // ItemMapにitem.IDをキーとしてitemを追加 itemList.ItemMap[item.ID] = item // NameConcatにitem.Nameを追加 itemList.NameConcat += item.Name // TotalPriceにitem.Priceを加算 itemList.TotalPrice += item.Price } // ItemListを返す return itemList } こちらは、Itemという構造体の配列から集計などを行い、ItemList構造体を返却する関数です。 具体的には、Item配列のIDのリストをIdListに、Idと実体を紐づけた連想配列をItemMapに、Nameを連結したものをNameConcatに、そして金額を合計したものをTotalPriceに格納したItemListを生成する処理となっています。 この関数のテストコードを作成するため、テスト用のソース src/common/utils_test.go を新たに作成しVSCodeで開きます。 まずは冒頭で下記のように入力します。 package common するとimport文の提案をしてくれますので了承します。 package common import ( "testing" ) 続けて以下のようにテストの生成の為のコメントが提案されます。 package common import ( "testing" ) // NewItemListのテスト その後は関数名からテストの実装まで全て提案してくれました。 package common import ( "testing" ) // NewItemListのテスト func TestNewItemList(t *testing.T) { // Itemを複数作成 items := []Item{ {ID: 1, Name: "item1", Price: 100}, {ID: 2, Name: "item2", Price: 200}, {ID: 3, Name: "item3", Price: 300}, } // NewItemListの実行結果を取得 itemList := NewItemList(items) // NewItemListの実行結果のIdListの長さが3でない場合 if len(itemList.IdList) != 3 { // テスト失敗 t.Errorf("len(itemList.IdList) = %v, want %v", len(itemList.IdList), 3) } // NewItemListの実行結果のIdListの要素が1でない場合 if itemList.IdList[0] != 1 { // テスト失敗 t.Errorf("itemList.IdList[0] = %v, want %v", itemList.IdList[0], 1) } // NewItemListの実行結果のIdListの要素が2でない場合 if itemList.IdList[1] != 2 { // テスト失敗 t.Errorf("itemList.IdList[1] = %v, want %v", itemList.IdList[1], 2) } // NewItemListの実行結果のIdListの要素が3でない場合 if itemList.IdList[2] != 3 { // テスト失敗 t.Errorf("itemList.IdList[2] = %v, want %v", itemList.IdList[2], 3) } // NewItemListの実行結果のItemMapの長さが3でない場合 if len(itemList.ItemMap) != 3 { // テスト失敗 t.Errorf("len(itemList.ItemMap) = %v, want %v", len(itemList.ItemMap), 3) } // NewItemListの実行結果のItemMapの要素が1でない場合 if itemList.ItemMap[1] != items[0] { // テスト失敗 t.Errorf("itemList.ItemMap[1] = %v, want %v", itemList.ItemMap[1], items[0]) } // NewItemListの実行結果のItemMapの要素が2でない場合 if itemList.ItemMap[2] != items[1] { // テスト失敗 t.Errorf("itemList.ItemMap[2] = %v, want %v", itemList.ItemMap[2], items[1]) } // NewItemListの実行結果のItemMapの要素が3でない場合 if itemList.ItemMap[3] != items[2] { // テスト失敗 t.Errorf("itemList.ItemMap[3] = %v, want %v", itemList.ItemMap[3], items[2]) } // NewItemListの実行結果のNameConcatがitem1item2item3でない場合 if itemList.NameConcat != "item1item2item3" { // テスト失敗 t.Errorf("itemList.NameConcat = %v, want %v", itemList.NameConcat, "item1item2item3") } // NewItemListの実行結果のTotalPriceが600でない場合 if itemList.TotalPrice != 600 { // テスト失敗 t.Errorf("itemList.TotalPrice = %v, want %v", itemList.TotalPrice, 600) } } このテストは実際にそのまま利用して関数のテストを行うことが可能です。 go test -v ./ === RUN TestNewItemList --- PASS: TestNewItemList (0.00s) PASS ok github.com/agest-inc/example/src/common 0.003s このように、実装に対するテストコードの提案をしてもらえることで、開発の補助ツールとして非常に有用であり、工数の削減に大いに役立っていると考えています。ただし、提案されたコードが100%正しいという保証はありませんので、内容の確認は自己責任で行う必要があります。 それでも、テストデータのコーディングの手間を省くことや、似たようなコードの繰り返しで一部変更を行う必要がある場合には、一定の効果があるのではないかと思います。 開発効率の向上 Github Copilotを使ってみると、開発効率が以前に比べて大幅に向上している実感があります。以前は、コードの一部を手動で入力する必要がありましたが、Copilotを使うと、コードの提案を受けることができます。これにより、時間を節約できるだけでなく、開発のスピードも大幅に向上しました。 また、Copilotは私のコーディングスタイルに合わせて学習していくため、提案されるコードは私の好みや習慣に合ったものが多くなりました。これにより、コードの書き方に一貫性が生まれ、保守性も向上しました。 さらに、Copilotは私の知識の不足を補ってくれる頼もしい存在です。新しいライブラリやフレームワークに挑戦する際、Copilotが適切なコードの提案をしてくれるため、学習の助けになりました。これにより、新しい技術への取り組みもスムーズになりました。 この中でも最もおすすめな活用方法は、テストコードの実装です。効率的に実装できるだけでなく、想定していないテストパターンなども提案してくれる可能性があるという点もメリットだと思います。 一つ気をつけるべきなのはGithub Copilotがコードを作成してくれるのではなく、補助してくれるという意識で利用する必要があるという部分です。あくまでAIによる提案であり、確実に意図しているような実装を提案してくれるわけではないため、最終的な実装は自身の目で確認しながら利用していくということを意識していないと誤った実装をそのまま適用してしまいかねません。 それさえ意識していればとても便利に利用することができると思います。 結論 Github Copilotは、開発効率を劇的に向上させることができる素晴らしいツールです。コーディングの補完や提案により、時間の節約や一貫性の確保、知識の補完といった恩恵を受けることができます。私のように開発プロセスを効率化したい方には、ぜひGithub Copilotを試してみていただきたいです。 The post GitHub Copilotを使ってみたら開発効率が劇的に向上した話 first appeared on Sqripts .

この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。 第11回目のテーマは、「エクストリーム・プログラミング（XP）」です。前回は原則と基礎プラクティスを解説をしたので、今回は応用プラクティスを解説します。 この内容はUdemyで公開しているオンラインコース「 現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム 入門編 」の内容を元にしています。 XPの応用プラクティス：実顧客の参加 ひとつめは「実顧客の参加」です。第1版では「オンサイトユーザー」でした。 ユーザー VS チームという構図をなくすためには、ユーザーを巻き込んだ開発が必要です。可能であれば、ユーザにもチームの一員として入ってもらうのも手です。 顧客の参加方法もいくつか選択肢があるはずです。たとえば、定期的に開発現場に来ていただくこともできますし、客先にスペースを作ってもらってそこで作業することもできます。 どちらにせよ、顧客と開発を切り離してはなりません。 XPの応用プラクティス： インクリメンタル配置 2つ目が「インクリメンタル配置」です。 配置というのは成果物を環境に配置する「デプロイ」を指しています。当時はデプロイという言葉が一般的ではなかったのだと思います。XPではイテレーションごとに成果物をインクリメンタルにデプロイを繰り返します。 正確に訳すなら継続的デプロイメントですが、今風な言い方にするなら継続的デリバリー（CD： Continuous Delivery）が近い言葉でしょう。つまり、デプロイやリリースの自動化です。 XPの応用プラクティス： チームの継続 3つ目は「チームの継続」です。 XPを続けるチームは、成熟度が高まっていきます。これをリリースごとに解散するのはもったいない話です。可能な限りチームを固定し、継続的に意欲的に開発に取り組んでもらえる体制を作ります。 従来型だとプロジェクトが終わるとチームが解散しますが、アジャイル開発はチームを中心にメンバーが構成され、メンバーをできるだけ固定しながら開発を進めていき、チームの成熟度を高めていきます。 XPの応用プラクティス： チームの縮小 4つ目は「チームの縮小」です。 これはチームをスケールさせる、もともとはトヨタ生産方式のプラクティスだそうです。たとえば、まずアジャイルチームをひとつつくり、生産性や効率性を高めていきます。そして、そのなかの1名をチームからはずし、新しいアジャイルチームの立ち上げで活躍してもらう・・・。このようなやりかたで、チームをスケールさせていきます。 この方法は、今ではアジャイル開発を横展開するときの王道の方法でもあります。 XPの応用プラクティス： 根本原因の分析 5つ目は「根本原因の分析」です。 トヨタがやっていることで有名な「なぜなぜ5回」という方法があります。なぜを5回繰り返すことで、根本原因に辿り着こうとする手法です。なぜなぜ5回と同じように、問題の原因を深堀りしていきます。そうしなければ、上辺だけの解決方法になってしまい、問題がまた再発してしまうからです。 ただ、根本原因にすぐとりかかるのが難しい場合もあります。そういう場合は、まずは短期的な対策を考えて進め、それと同時に長期的な対策をセットで考えるのも手です。 XPの応用プラクティス： コードの共有 6つ目は「コードの共有」です。第1版だと共同所有というプラクティスでした。 現在は、GitHubやGitLabなどのコード管理サービスが広く使われているので、コードの共有はあたりまえのプラクティスと言えます。しかし、XPの書籍がでてきた当時は、共有ファイルサーバにコードを置くなどの運用でカバーしていました（本当に辛かった）。 コードの扱い方については、ブランチ戦略や、プルリクエスト、コミットしたものをわすれずにPushしておく・・・などといったプラクティスへと広がってきています。 XPの応用プラクティス： コードとテスト 7つ目は「コードとテスト」です。当たり前のことですが、コードとテストはもっとも重要な成果物です。 XPでは、これらを使って別に必要なドキュメントを作ることも推奨しています。Javaの世界だと、ビルドツールでJavadocなどさまざまなドキュメントをアーティファクトとして自動生成したりします。 XPの応用プラクティス： 単一のコードベース 8つ目は「単一のコードベース」です。 現在だと、Git flowのように、さまざまなブランチ戦略が使われていますが、XPでは、コードベースを単一にするのを推奨しています。 Googleでも単一コードベースのほうが効率がいいとされています。 単一コードベースだと管理がシンプルになり、マージコストも下がります。ただし、単一のコードベースは複数チームでの開発のように、開発者の人数が増えると運用が大変にもなってきます。それぞれの現場にあわせて選択すると良いでしょう。 XPの応用プラクティス： 日次配置 9つ目は「日次配置」です。第1版では短期リリースと呼ばれていたものです。最近だとデプロイ回数を指標として計測するチームも増えています。 日次配置は、いわゆる日次デプロイです。ただ、これを実現するには「コードとテスト」や「インクリメンタル配置」といったプラクティスが必要になります。 このように、XPのプラクティスはそれぞれがゆるく連携しているので、どれか一つを導入してみて、関係するプラクティスの導入を進めていくといいでしょう。 XPの応用プラクティス： 協議によるスコープ契約 10番目は「協議によるスコープ契約」です。 開発を請け負う場合、契約が重要になります。ただ、従来型のように長いプロジェクトとなると、スコープが大きくなり、契約も長くなり、柔軟性が低くなってしまいます。 よって、契約も短く区切り、スコープを調整していきます。スコープには、スケジュール、費用、品質が含まれるので、それぞれを議論してスコープを決定していきます。 XPの応用プラクティス： 利用分払い 11番目は「利用分払い」です。 ユーザは利用した分だけシステム利用料を払う形の課金方法です。従来型だと見積もりをベースに納品後一括支払いが多いでしょう。しかし、XPではお金じたいもフィードバックの一つとして考えているようで、使った分、いただく・・・という形を提唱しています。 この方法は、現在だとSaaS型のサービスに似ています。SaaS型のサービスは、サブスク型の課金が多いので、毎月や毎年の単位で、特定の額を支払います。そう考えると、20年近く前にでてきたXPが、SaaSのサブスク型支払いをプラクティスとしているなんて、XPの先見性にびっくりしてしまいます。 以上が応用プラクティスです。 特にXPのプラクティスは、現在でも利用できる物が多く、あとで説明するスクラムと組み合わせることで、有効性を高められます。たくさんあるので、まずは概要だけでも覚えていただき、アジャイル開発を実践するときに、思い出しながら導入していただければと思います。 連載一覧 第1回：アジャイル開発の過去、現在、未来を知ろう！ 第2回：声に出して読みたいアジャイルマニフェスト 第3回：従来型開発とアジャイル開発の違い　その１ 第4回：従来型開発とアジャイル開発の違い　その２ 第5回：アジャイル開発のよくある誤解を解いていこう！ 第6回：世界中で大人気の秘密に迫る！スクラムを使ったソフトウェア開発 第7回：わかるようでわかりにくいスクラムチームの責任 第8回：スクラムイベントの実践方法 第9回：エクストリーム・プログラミングとその価値 第10回：エクストリーム・プログラミングの原則と基礎プラクティス 第11回：エクストリーム・プログラミングの応用プラクティス The post 第11回 エクストリーム・プログラミングの応用プラクティス first appeared on Sqripts .