こんにちは。まーくー＆くまねこです。 ゆるっとシリーズ第8話です。 前回 から引き続き、まーくーの学び直し回です！ 書籍「基本から学ぶソフトウェアテスト」 を読んで、現在でも活かせる内容があるのか？、まーくー＆くまねこの会話形式でお話させていただきます。 最後まで楽しんで読んでいただければ幸いです！ ゆるっと♪Blogシリーズの記事一覧はこちら（クリックで開きます） 第1話 ゆるっと♪ファームウェアテストよもやま話 第2話 ゆるっと♪学び直し！アジャイルソフトウェア開発技術者検定試験 第3話 ゆるっと♪どうやってる？探索的テストの世界！ 第4話 ゆるっと♪学び直し！[書籍]基本から学ぶソフトウェアテスト！ 第5話 ゆるっと♪学び直し！[書籍] 基本から学ぶソフトウェアテスト！② 　　　 ～あきらめてしまわないでね 難しさ感じても～ 第6話 ゆるっと♪学び直し！[書籍] 基本から学ぶソフトウェアテスト！➂ 　　　 ～きっとそこに信じていた、バグ管理の姿があるはずさ♪～ 第7話 ゆるっと♪学び直し！[書籍] 基本から学ぶソフトウェアテスト！④ 　　　 ～君がおしえてくれたテストの名前は～ 第8話 ゆるっと♪学び直し！[書籍] 基本から学ぶソフトウェアテスト！⑤ 　　　 ～つかまえて デバイスたちの歌を～ 自己紹介 まーくー QA業界経験2x年のエンジニア。 年齢からくる（？）気力、体力の衰え、体重の増加を感じつつ、お気に入りアーティストのMCを完コピすることで奮い立たせる今日この頃。自宅から徒歩3分のところにあるチョ○○ップ入会すら躊躇ってしまう、一歩踏み出せない自分がいます・・・ くまねこ QA業界経験1x年のエンジニア。 最近のマイブームはペットボトルをどこまで縦にまっすぐ立てて飲めるかトライすること。 ノドに勢いよく流れ込む液体に身を任せ、テストの日々を泳いでいます。 イラストby くまねこ 今日も二人のやりとりをお楽しみください！ 2025年も！学び直しの旅は続く… （ズッタンズズタン♪ズズタタズッタン♪）Wow！ （あっ、まーくーさんだ。何やらリズムに乗ってゴキゲンだ…！ どうしよう。話しかけてみようかな…） まーくーさん！ おつねこです～！ おつねこ！ 私は最近こんな風に思っている。 ダイエットっていうのは数字にしばっ、しばられないことなんだ。そして、自分に与えられた全ての食物の中で、一体何が食べたくて、何が食べたくないのか、見分ける力を持つことが大事なんだって。 Oh…とにかく好きなものを食べようってことですか！ どんな体重でもそれがベスト！ 今がベスト！ （まーくーさん、ちょっと嚙んでたけど…かっこいい！ しびれるぅ～！） そう！ ベストが毎日続けばいつでもベスト！ Yeah～！ \ / オゥーライ！ では、今日も学びなおしていこうかぁ～ ？ Yeah～！ \ /（今日は書籍に関する前振りなしでいきなり始まった～！） 第8章 プリンタ(およびその他デバイス)のテスト を読んで① 前回 は7章まで進み、今回は8章ですね…。「プリンタ(およびその他デバイス)のテスト」ですって。プリンタって聞くとまーくーさんと同じ現場だった時のことを思い出します。 あっのっころっは～♪ Wow！…で、どんなことが書いてあるんだい？ （今日はテンション高い＆展開が早い～！）そうですね…ふむふむふむふむ。 大きく分類すると以下のような記載になっていますね。 　・デバイス構成テスト 　・プリンタのテスト 　・プリンタの内部処理 　・プリンタのテスト戦略 　・プリンタのテスト項目 　・テスト自動化のヒント なので、この中からプリンタにしばっ、しばられない項目から汎用的に学べそうな部分をピックアップしていくと良いと思います。（意図的に噛んでみたけど…気づくかなぁ？） そうだね。構成テストというくくりで言えば、私たちも行っている他端末検証とかにも応用できる知見が得られそうだね。「プリンタの内部処理」は分野が限定されすぎるから、今回は無しにしても良いかもね。ひとまず前半の２つをピックアップしてみよう。 「デバイス構成テスト」 と 「プリンタのテスト」 についてですね。Yeah～ッサー！ \ /（気づかなかった～！） まずは「デバイス構成テスト」について。 ここではテスト対象を動作させる環境面のことが書かれています。テスト対象と互換性のあるプリンタの用意をするかどうか、PCのハードウェアやOSのバージョンなども記載がありますね。 なるほど。テストの大前提ではあるけど、テストを行うための環境の洗い出しやバージョン情報などは最初にしっかりと確認し、ステークホルダーと合意して進めていけるようにしたいね。 本文にもあるけど構成の組み合わせは「ブラックホール」のように多様なデバイスを飲み込んでしまって複雑になりすぎたり、せっかくテストが順調に進んでいたのに、実はテスト対象プログラムのバージョンが違ってました…とかだと目も当てられないしね。 ですよね…そこまで大きなロスをしたことはないですが、プロジェクト終盤で判明してしまった時のことを考えるといろいろな意味で背筋が凍りますね。((( ))) 続きまして、「プリンタのテスト」について。本書発行当時はプリンタは1000種類以上あり、その中からプリンタと連携するPC(OS)のシェア、プリンタのシェアなどを考慮して動作保証範囲を検討する必要がある旨が書かれています。 当時はそれぐらいの種類だったんだね。現在はプリンタの種類もそうだけど機能も高度化しているから、その辺も考慮に入れてデバイス構成を検討すると良いと思う。もっとも当時よりデバイス間の互換性が保たれていることも多いだろうから、思ったよりうまく整理できるかもしれないね。 第8章 プリンタ(およびその他デバイス)のテスト を読んで② では８章の後半も進めていこう。「プリンタのテスト戦略」について。ここは私が… 「テスト戦略」として大切なことは一般的なところから特殊なところへ進めていく、というところが参考になると思う。色々な種類のプリンタがある中で、ひとつ目の機種ではプリンタに依存しない不具合を見つけ、次のプリンタではプリンタとして共通の不具合を見つけていく…というところ。これを行うことで同じテストをプリンタ種類毎に全て実施しなくても良くなるから良いよね。 そうですね。この考え方はプリンタやデバイスのテストだけでなく、アプリのテストでも活用できそうです。まーくーさんはテストを進めていく上でのアイデアって他にどのようなものがあると思いますか？ 戦略と言うほど大がかりなことではないけど…（目を細めながら遠くを見つめる）、 派生開発とかならテスト実行の順番を考えるとき、過去の傾向から不具合が多かった機能や、プログラムの修正に時間がかかった不具合を検出した機能から先にテストを進められるようにスケジュールするかな。そうすれば不具合が発生しても早めに対処することが可能となって、終盤に重大不具合が発生してアップアップするなんて事態を回避できるよね。 なるほど。テストチームだけでなく、開発チームの作業負荷も考慮して進めることができれば、より効率よく安心してプロジェクト終了へ進めていくことができますね！ 次は「テスト項目」についてだけど…現在では一般的になっている内容かと思うので今回は割愛させてもらおうかな。 了解しました ゞそしたら最後は「テスト自動化のヒント」ですね。自動化っていうと今でもテーマとしては重要かと思います。ふむふむふむふむ。やはり当時から以下のようなポイントで語られていますね。 （プリンタテストの自動化に関する四つのリスク※要約） 　・すべてを自動化しようとしないこと 　・合否判定が正しくできない項目は実施しないこと 　・印刷に関連するバグを見逃さないように注意すること 　・同じ自動テストだけを実施し続けないこと なるほど。ここでも自動化する前にどういった範囲を自動化していくのか、ツールの特性でできること/できないことも調査しながら適切に自動化ができるようにしていきたいところだよね。 はい。合否判定のところも、もし実際の印刷まで自動化するのであれば出力された紙の目視確認も必要になると思います。その際、どの自動化テストケースで印刷したのかわかるようなデータ作成をする必要もありますね。他にも紙出力ではなくファイル出力したデータと期待値ファイルと比較して合否判定するっていうのも良いですよね！ うん。あと4つ目の同じ自動テストを続けないこと、のところはまさに殺虫剤のパラドックスと同じだね。既存の動作に問題ないことを確認するのは良いけれど、テスト対象の成熟度に応じて自動テストの量や内容も臨機応変に対応していかないといけないよね。 変化を恐れず常に前を向いて前進する、まーくーさんのようにですね！ 最初はトライ＆エラーの時間が少なからず発生すると思うけど、「テスト自動化のヒント」で学べることを活かせば自動化の成功率向上と安定した運用ができそうだね。 トライ！ トライ！ トライ！ Yeah～！ We can do it！ \ / まとめ 第8章はこれぐらいかな。 次回のまーくー＆くまねこは、 まーくー： JSTQB ALTM試験、うっかり受かっちった！ 次はTA？ （仮） くまねこ： JSTQB ALTM試験、ではないものを受け、あと1問で x  2 （苦） の２本でーす！ 最後まで読んで頂き、ありがとうございました！ よろしければ、過去のゆるっと♪シリーズもお楽しみください！ 次回もまた見てねー ﾉｼ 三 ﾉｼ 三 ゆるっと♪シリーズ 第1話 ゆるっと♪ファームウェアテストよもやま話 第2話 ゆるっと♪学び直し！アジャイルソフトウェア開発技術者検定試験 第3話 ゆるっと♪どうやってる？探索的テストの世界！ 第4話 ゆるっと♪学び直し！ [書籍]基本から学ぶソフトウェアテスト！ 第5話 ゆるっと♪学び直し！[書籍] 基本から学ぶソフトウェアテスト！② 　　　 ～あきらめてしまわないでね 難しさ感じても～ 第6話 ゆるっと♪学び直し！[書籍] 基本から学ぶソフトウェアテスト！➂ 　　　 ～きっとそこに信じていた、バグ管理の姿があるはずさ♪～ 第7話 ゆるっと♪学び直し！[書籍] 基本から学ぶソフトウェアテスト！④ 　　　 ～君がおしえてくれたテストの名前は～ 第8話 ゆるっと♪学び直し！[書籍] 基本から学ぶソフトウェアテスト！⑤ 　　　 ～つかまえて デバイスたちの歌を～ The post ゆるっと♪学び直し！[書籍] 基本から学ぶソフトウェアテスト！⑤～つかまえて デバイスたちの歌を～ first appeared on Sqripts .

みなさんこんにちは。 「ソフトウェアレビューをエンジニアリングっぽく捉える会」の”きたのしろくま”です。 前回 に引き続き、「#5レビューの終わり方～レビュー評価・ふりかえり(2/2)」をお伝えします。 【第3回】［#5］レビューの終わり方～レビュー評価・ふりかえり（1/2）｜ソフトウェアレビューをエンジ... みなさんこんにちは。「ソフトウェアレビューをエンジニアリングっぽく捉える会」の”きたのしろくま”です。次の話題は「#5レビューの終わり方～レビュー評価・ふりかえり」です。前回うれっしーさんが書いてくれた「#1レビューとは？」の次に#5・・・かなり飛んだテ... 　続きを読む　 Sqripts ＜ソフトウェアレビューをエンジニアリングっぽく語ってみる　記事一覧＞ ※クリックで開きます 【第1回】［#0］イントロダクション 【第2回】［#1］レビューとは？ 【第3回】［#5］レビューの終わり方～レビュー評価・ふりかえり（1/2） 打開策2：レビュー指摘事項の分類／評価の実施 打開策1と同様、レビュー終了直後に、レビューにより検出された指摘事項をいくつかの視点で分類し、評価します。 分類／評価の方法にはいろいろありますが、ここでは2つの事例（視点）を紹介します。 1つ目の視点は、このフェーズで作り込まれた欠陥・不備なのか、他のフェーズで作り込まれたものなのかの分類です。理想的なのは、このフェーズで作り込まれた欠陥・不備を同じフェーズのレビューで見つけ出すことです。（図2の上）これが実現できなければ、プロジェクトが混乱する原因となってしまいます。（図2の下） よって、他のフェーズで作り込まれた欠陥・不備があれば、作り込まれたフェーズのレビューを見直す必要があることに気づきます。 図2：フェーズで作りこんだ欠陥・不備をどこで見つけるか？ 2つ目の視点は、レビュー目的の達成度と指摘事項の効果です。 レビューの“効果”を何で示すのかについてもいろいろ考えられますが、今回はその一例として「仮に今回のレビューでこの欠陥・不備を見逃した場合、あとでどの程度悪い影響が出るものかの度合い」をご紹介します。 あとになって発生する悪い影響を正確に把握することはできない場合も多いので、下記のように進めます。 少なくとも自分たちの開発の進め方から想定すると、この欠陥・不備はこの先どのフェーズで見つかる可能性が高いか、見つかった時の対処にどのくらい期間、工数を費やして対処することになるのかを（ザックリでもOK）見積もります。その際にプランニングポーカーを使うなどの工夫が可能です。 見積結果を活用して3つの枠：効果大、効果中、効果小に割り振ってマッピングします。 さらに、それぞれの指摘事項がどのような観点にあたるのか？を明らかにして、効果大中小の観点分布を把握します。（以上、図3） 図3：レビュー指摘事項の分類／評価の流れ（例） 以上の結果を見ながら、どの観点の指摘事項がどの程度見つかったのか？や、効果大・中・小の指摘数、観点の偏りはないか？、今回のレビュー目的は達成できたといえるのか？、レビューにおける費用対効果はいかほどか？、等を分析、評価します。（図4） 図4：レビュー指摘事項評価の観点例 最初は効果大、中、小をどのように分けたらよいのか、それぞれの指摘事項がどのような観点（意味がある）と言えるのか、などメンバーの認識が合わずに難航するかもしれませんが、議論を重ねて一度出来上がるとそれを再利用しながら短い時間で分類／評価を進められるようになります。 完成したレビュー指摘の効果分類図に表現された内容が、対象となるソフトウェアの品質に対するチームの価値観を表すことになります。これがマネジメント、開発メンバー、QAメンバーの共通の価値観になり、あらゆるタスクを進める上で注視して開発を進められるようになっていきます。それがさまざまな役割のメンバーが相互に協力して同じ目的達成を目指すうえで協調関係を築く土台になります。 ここで間違ってほしくないのは、完成した図が大事なだけではなく、それを創りあげる過程＝チームメンバーによる対話や議論がなにより重要である点です。そして、一度完成したら終わりではなく、さまざまなレビューやテストの結果を同様に分類／評価しながら何度も見直し、更新していくことが本質である点です。 なお、この打開策2は 打開策1：「レビューふりかえり」 の前に実施し、その結果を踏まえてふりかえることをおススメします。 この組合せにすることで、レビューの実施過程＋実施結果の両面を解像度高くふりかえることが可能になるため効果的です。 おわりに ～忙しくてそんなことしている時間はないよ、と言っていた当時の私に 以上の提案をすると「レビュー終了直後に指摘事項を分類/評価したり、ふりかえりを実施するなんて、、、忙しいからそんな時間はないよ。」という声をよく聞きます。 私も当時はそう思っていた一人なので、この先は当時の私に伝える／問いかける内容です。 当時のしろくまさんへ どうしてそんなに毎日忙しいのか、現状で自分が何にどのくらい時間を割かれているのかちゃんと把握しているかな？例えば、計画された作業を実施したものの、あとで仕損じていたことがわかり、作業をやり直したり、成果物を手直ししたりする工数って作業全体の中にどのくらいあるんだろう？ それを把握することも大事なふりかえりの一種なんだけど、それも忙しいからできないって言うかもしれないね。 自分（たち）の作業や成果物をふりかえって、仕事の仕方をもっとより良く変えない、良くないところを直さないから、いつまで経っても仕損じて手戻り（再作業や非効率状態）が減らず、その結果忙しさが解消されない、さらに忙しいのを言い訳に本当に必要な作業を端折ったりしてまた手戻りを増やしている、なんてことはないかな？ 実は、忙しいからふりかえりなんてできない、のではなく、ふりかえらないから忙しくなってしまう、ということなんじゃないのかな？ 「忙しい」が結局は現状維持・現状肯定のための言い訳にならないように、そして意図せず自らの成長を阻害することにならないように、しろくまさんの今後の健闘を祈ります。疑問点などあれば遠慮なく教えてね。他者のせいにしていても解決しないからさ。一緒によりよい世界を自ら創り上げていこう！ この記事を担当したメンバー きたのしろくま（安達 賢二／ @kitanosirokuma ） 自律・自己組織化を促進する価値共創プログラムSaPIDをベースに三方よしとなる新しい価値を一緒に考えて創る「共創ファシリテーター」として活動中。 https://www.softwarequasol.com/ 【連載】ソフトウェアレビューをエンジニアリングっぽく語ってみる｜記事一覧 【第1回】［#0］イントロダクション 【第2回】［#1］レビューとは？ 【第3回】［#5］レビューの終わり方～レビュー評価・ふりかえり（1/2） The post 【第4回】［#5］レビューの終わり方～レビュー評価・ふりかえり（2/2）｜ソフトウェアレビューをエンジニアリングっぽく語ってみる first appeared on Sqripts .

こんにちは。執筆者のおすしです。 ChatGPTが世にリリースされてから、私には続けてきた趣味があります。 変わった料理のレシピをAIに提案してもらい、作って食べてみること です。 数あるおかしなレシピの中からおいしかった3つを紹介します。 ルール 次のような単語を入れてAIにレシピ作成を依頼する。 「奇抜な」「前衛的な」「いまだかつてない」「狂った」 無難なレシピを提案してきたら、「より奇抜なものをお願いします」のように指示してやり直してもらう。 提案したレシピ名や材料の組み合わせを検索して、同じレシピがヒットしなかったらOK。ヒットしたら手順2を繰り返す。 食べても安全かチェックしてから作成に入る。 AIは食品以外を材料にしたり、危険な食べ方を提案してしまうことがあります。必ず安全を確かめてください。 残さず食べる。 レシピ①「かんぴょうと餃子のカルパッチョ」 AIとのやり取り まずは普通に依頼した場合の結果です。しけてきたかんぴょうの残りを使い切りたかったので、必ず使ってほしいと依頼します。 無難なレシピを提案されました。「前衛的な」を指示に入れてみます。 「かんぴょう　餃子　カルパッチョ」で検索しましたが、似たような料理はヒットしませんでした。 ※2025年現在は「餃子のカルパッチョ」というレシピがヒットします。 レシピ 【かんぴょうと餃子のカルパッチョ】 【材料】 餃子 6個 白菜 4枚 かんぴょう 20g ベーコン 2枚 スプラウト 適量 レモン 1/2個 オリーブオイル 大さじ2 塩、胡椒 適量 【作り方】 餃子を沸騰した湯で1分程茹でます。 冷水で餃子を冷やし、食べやすい大きさに切ります。 白菜を塩茹でし、水に取っておきます。 かんぴょうを水で戻して、茹でます。 ベーコンをフライパンでカリカリに焼きます。 レモンの汁、オリーブオイル、塩、胡椒を混ぜ合わせ、ドレッシングを作ります。 盛り付け皿に3と2を乗せ、5と4を添えます。 ドレッシングをかけ、スプラウトを散らして完成です。 和のかんぴょうと洋のカルパッチョが融合した、前衛的な一品となります。おしゃれなパーティーやディナーにもぴったりです。 作成 ゆでた餃子を冷水で冷やすのか…と驚きながら調理しました。 餃子は切らない方が見栄えが良いので作り方の手順2の後半は無視します。「おしゃれなパーティーやディナーにもぴったりです」とあるのでおしゃれに盛りつけます。しかし、白菜を下に敷くと餃子が転がって盛り付けが難しい。白菜はお浸しとして食べてしまいました。時にはレシピを無視するのも楽しく続けるコツです。 実食 とてもおしゃれな見た目です。確かにパーティにぴったりかもしれません。 おいしくいただきました。 冷やした餃子の皮のもちもち感、添えたかんぴょうの歯ごたえ、上に載ったベーコンのカリカリ感。面白い食感でした。上に散らかしたスプラウト（カイワレ大根）の辛味がアクセントになって、食べ続けても飽きません。レモンのおかげで後味もさわやかでした。お酒のつまみにぴったりだと思いました。 この料理がおいしかったとAIに伝えました。かんぴょうが好きだとインプットされたらしく、しばらく提案するレシピにかんぴょうが入るようになりました。 レシピ②「うどんティラミス」 AIとのやり取り 「うどん　ティラミス」で検索するとうどんのティラミス風がヒットしました。しかしながら、作り方や材料を比較すると全く違う料理のようです。やや驚きに欠ける気もしますが、同じものはないのでOKとします。 レシピ 「うどんティラミス」 うどんをデザートに大胆にアレンジし、ティラミス風に仕上げた一品です。もちもちのうどんが、意外とマスカルポーネとコーヒー風味に合います！ 【材料】 うどん（冷凍うどんを推奨）：1玉 マスカルポーネチーズ：100g 生クリーム：100ml 砂糖：大さじ2 インスタントコーヒー：小さじ1（湯大さじ2で溶かして冷ましておく） ココアパウダー：適量 【作り方】 冷凍うどんを茹でて冷水でしっかり締め、水気を切ります。1～2cmほどの長さに切り、ティラミスのスポンジ部分の代わりにします。 ボウルにマスカルポーネチーズと砂糖を入れて混ぜ、生クリームを加え、ふわっとするまで泡立ててクリームを作ります。 切ったうどんをコーヒー液にさっとくぐらせ、グラスや容器に敷き詰めます。 3の上にマスカルポーネクリームを重ね、再度コーヒーにくぐらせたうどんを敷き詰めて、もう一層クリームをのせます。 最後にココアパウダーをふりかけ、冷蔵庫で1時間ほど冷やして完成です。 うどんのもちもち食感がティラミスのクリーミーさと相まって、新しいスイーツの食感と風味が楽しめます。まさかうどんがデザートになるとは思わない驚きの一品です。ぜひ話のネタに試してみてください！ 作成 うどんという中身の詰まったものをスポンジ部分の代わりにするのですね。「ティラミスのクリーミーさ」とあるけどスポンジ部分も含めてティラミスなのでは？ティラミスってどういう意味なんでしょう。ちょうど開いていたGoogleのAI（Gemini）に聞いてみます。 【語源】Tira（引っ張る、mi（私、 su（上に。 「私を上に引っ張り上げて」が転じて「私を元気づけて」という意味になりました。 また、「私を天国に連れて行って」という意味もあります。 強烈な味で天に召されるのかもしれない。材料からそこまでおかしな味にならないとは思いますが…。 実食 上から見ると完全にティラミスです。 横から見るとうどんが…。クリームにうどん。複雑な気持ちになりますが、目を閉じて食べてみます。 意外にもおいしくいただきました。 うどんの弾力が大福などのモチ系のお菓子と似ています。食べ始めはうどんが甘いことに違和感がありましたが、慣れたらおいしく感じます。うどんって甘い味も合うんですね。 レシピ③「鹿胸肉のカーボン化ロースト ブラックダイヤモンド仕立て」 AIとのやり取り 鹿肉の塊が手に入りました。私の大好きな食材です。早速レシピを提案してもらいます。 鹿肉とチョコレート、ベリーソースを使ったものはすでにある料理でした。私も食べたことがあります。奇抜さが足りないのでやり直してもらいます。 いまだかつてなく危険なにおいのする料理名とサブタイトルです。念のため「鹿肉　ロースト　炭」「鹿肉　カーボン」「鹿肉　ブラックダイヤモンド」で検索しましたが同じ料理はヒットしませんでした。 プロンプトは胸肉と書いてしまいましたが、手元にあるのは鹿の肩肉でした。気にせず調理に入ります。 レシピ 「鹿胸肉のカーボン化ロースト 〜ブラックダイヤモンド仕立て〜」 （見た目は真っ黒、食べるとジューシー！炭と科学を駆使した革新的な一皿） コンセプト 鹿肉を「完全に黒焦げ」に見せつつ、中は驚くほどジューシーで旨味たっぷり。 活性炭や黒ニンニクを使い、炭化したような見た目ながら、旨味を凝縮させる新感覚の料理。 【材料】 （2人分） 鹿胸肉（ブロック）：300g 食用活性炭パウダー：大さじ1（※食品用を使用） 黒ニンニク（ペースト状にする）：3片 バルサミコ酢：大さじ2 黒蜜：大さじ1 カカオパウダー（無糖）：小さじ1 オリーブオイル：大さじ1 塩・黒胡椒：適量 【作り方】 漬け込み（ブラックマリネード） 黒ニンニク、バルサミコ酢、黒蜜、カカオパウダーを混ぜてペーストを作る。 鹿胸肉に塩・黒胡椒をふり、ペーストをたっぷり塗り込む。 1時間以上漬け込み、冷蔵庫で休ませる。 カーボンコーティング（完全黒化） 活性炭パウダーをふるい、マリネした鹿肉全体をまぶす。（しっかり真っ黒に！） 表面が乾燥しすぎないよう、オリーブオイルを軽く塗る。 低温調理（ジューシーに仕上げる） 120℃のオーブンでじっくり40分焼く。（中はピンクをキープ） 焼き上がったらホイルに包み、10分ほど休ませる。 仕上げ（カーボンローストの完成） 表面が完全に黒くなっているはず！だが、中はレアでジューシー。 薄くスライスし、岩塩を添えて提供。 驚きのポイント 見た目は「真っ黒の炭」、でも食べると柔らかくて旨い！ 活性炭の効果で胃腸に優しく、デトックス効果もあるヘルシー料理！ 黒ニンニク＆バルサミコの甘酸っぱさが鹿肉の旨味を爆発させる！ 作成 AIのモデルが変わったのでしょうか。以前よりも絵文字と「！」が多く「驚きのポイント」も炎で挟むというハイテンションぶりです。やや不安になりましたが、「食用活性炭パウダー：大さじ1（※食品用を使用）」と注意書きがあります。安全性を考える冷静さは残っているようです。 鹿肉の生食は危険な場合があります。温度計で中心温度を確認してしっかり低温調理をします。味はともかく、安全性には必ず配慮しましょう。危険なものは残さず食べることができません。 食べ物と思えない黒い塊ができました。期待と不安で胸が高鳴ります。 実食 切ってみました。程よく火が通った美しいお肉が見えます。 とてもおいしくいただきました。 しっとり柔らかいお肉に、黒ニンニクとバルサミコ酢の風味がしっかり染み込んでいます。赤ワインに合いそうな味です。 炭の味がするのかな、と心配でしたが外側の炭は特に味がしません。切る前の見た目と味のギャップがおもしろい料理でした。 まとめ 今まで複数のレシピを提案してもらいましたが、プロンプトに入れる形容詞や副詞によって傾向があるようです。 「驚くような」「奇抜な」：既存のレシピで、ちょっと変わっているなと感じるものが多いです。（例：お肉にチョコレートソースなど） 「前衛的な」：既存のレシピを食材の変更でアレンジする傾向があります。また、比較的おしゃれなレシピが多いです。 「いまだかつてない」：調理法から変わったものが多いです。 「激しい」「狂った」：調理法は普通ですが、量、色、味で狂気を表現するものが多いです。（例：大量の食材を積み上げる、真っ赤にする、大量の唐辛子で激辛にするなど。）また、レシピの説明で中二病のような表現を使うようになります。 毎日の献立に悩んだり、同じご飯が続いて飽きることがあると思います。上記のような言葉を入れて、ちょっと変わったレシピをAIに提案してもらうのはいかがでしょうか。 作成の際はレシピの安全確認を忘れないように気を付けてください！ The post AIに前衛的な料理のレシピを提案してもらった（写真と実食あり！） first appeared on Sqripts .

みなさんこんにちは。 「ソフトウェアレビューをエンジニアリングっぽく捉える会」 の”きたのしろくま”です。 次の話題は「#5レビューの終わり方～レビュー評価・ふりかえり」です。 前回うれっしーさんが書いてくれた「 #1レビューとは？ 」の次に#5・・・かなり飛んだテーマではありますが、 準備できた順に投稿していくと宣言 して始めた連載ですのでご容赦ください。 （すべてのテーマ投稿が出揃った際にこの連載の価値がわかるはず・・・です） 今回のテーマは少し長くなりますので2回に分けてお伝えします。 今回は「#5レビューの終わり方～レビュー評価・ふりかえり(1/2)」です。 レビューのよりよい終わり方を一緒に考える機会になるとうれしいです。ではスタートです！ ＜ソフトウェアレビューをエンジニアリングっぽく語ってみる　記事一覧＞ ※クリックで開きます 【第1回】［#0］イントロダクション 【第2回】［#1］レビューとは？ レビューってどうしたら終わる？ みなさんのレビューはどうなれば終了しますか？ 例えば、 ・予定していた時間が来たら終了～まだ途中だけど、残りの内容でこれまでの指摘と同様の箇所があれば同じように直しておいてね（ハート） ・レビューアから指摘事項が出揃ったら／それを作成者に伝えたら終了 ・声の大きな人が「終わり」と言ったら終了 ・正式なレビュー記録が承認されたら終了（QMS的） など、いろいろありそうです。 これは「レビューの終了基準」の話題ですが、（「開始基準」と同様）特に決まりがないまま、いや「慣習になっている暗黙のやり方」に従って運営している、という状態が意外と多い気がしています。 ”やりっぱなしレビュー”の影響 先ほど示した4例ですが、どれをとっても「レビュー計画」や「レビューの実施方法」「レビュー結果」の良し悪しをふりかえらず、集まった人たちでレビュー指摘さえ出せば、あるいはそれを申し渡したら終わり、という状態になっている可能性があります。 この状態を「やりっぱなしレビュー」と呼ぶことにします。 やりっぱなしレビューがもたらす主な影響は以下の通りです。 ・レビューに費やす工数や時間が最小限で済むので、実務に早めに戻ることができる。（これは良い影響） ・レビューで新たな経験や気づきを獲得した特定の個人にのみ、その分の学習効果が得られる。 　しかし、あくまでも個人の話であり、かつレビュー能力の向上は非常に小さく、組織としてのレビュー能力向上には長い年月が必要になる。 ※有識者がいないとレビュー結果が伴わない状態はこのように作られる ・（一度のレビューで各自が獲得するノウハウはそう多くはないため）次回以降のレビューでも同じような結果になることを繰り返す可能性が高い。 例1：検出すべき欠陥や不備を見逃しがちなレビューになっているチームは、以降も同様に見逃す結果になりやすい。 例2：集合レビュー時に話題が横道に逸れてもそのまま放置される（ムダな時間、工数が多くなる）運営になっているチームは、以降も同じ状態になりやすい。 以上のように、メリットよりもデメリットが目立つのが実態だと思います。 さらに、業務やプロジェクトのメンバーは、自分が割り当てられているタスクを遅延なく進めることでさえも簡単ではなく、多忙な中で依頼されたレビューを何とかして行っている場合も多いと推察します。 多忙な中、何とかやりくりしてレビューを実施しているのに、その効果が実感できないと、レビューに対するモチベーションが低下し、前向きにレビューが実施できなくなってしまいます。 このような「やりっぱなしレビューの悪影響や負の連鎖」はどのように打開すればよいでしょうか？ 打開策1：レビュー実施直後のふりかえり実践 レビューを実施した直後に今回のレビュー全般をふりかえり、次（今後）のレビューでどのように進めるとより良い結果が出せるのかを明確にするのが打開策の一つ目です。 ふりかえりを実施するときの大事なポイントの一つは「ふりかえりの対象活動を小さくする」そして「終了直後に実施する」ことです。 小さい活動の終了直後にふりかえりを実施することで、対象活動（今回はレビュー）で発生した「継続すべきよい事項」や「見直すべき事項」が記憶のかなたに消えてしまうリスクを軽減し、何が起きたのか、その結果どうなったのかを思い出すための余計な時間を最小化します。（図1-【B】） よく、プロジェクト終了後にプロジェクトふりかえりを実施しているケースを目にしますが、数か月～数年の期間で運営してきた内容を一度に一気に思い出すことを暗に求めることになります。1日経過すると7割程度の記憶がなくなる、数日前の食事の内容ですら思い出すのに苦労するのが人間ですから、数か月前、半年前の記憶はほんのささやかな断片でしかありません。必要なことをしっかり思い出して共有するには余計な時間と手間をかける必要がありますが、それでも実際には思い出せずに終わることのほうが多くなります。 この方法だと、時間も工数も大きくなる割に効果的な結果が得られる可能性はとても低くなってしまいます。（図1-【A】） レビュー実施直後にふりかえりを行うことで、短い時間と工数で次（以降）のレビューで実践すべき事項を確実に導出することができるわけです。 さらに慣れてくると、ふりかえり時に各自がふりかえって結果を書き出す（そのために時間をかける）のではなく、レビュー計画立案や準備、各自のレビュー実施、集合レビュー時などの各段階で気づいたことや見直すべき事項（ふりかえり結果）を共有場所に書きだしながら進めることができるようになります。その結果、ふりかえり時にはすでに書き出された各自の結果を確認・共有するところからスタートするため、ふりかえりにかかる時間・工数が小さくできます。これを、リアルタイムふりかえり、と呼んでいます。（図1-【C】） 図1：ふりかえり実施形態と費用対効果 個人的な経験則ですが、この形式で運営できるようになると、ふりかえりにかかる時間は最短で5分程度、長くても15分程度で済み、次のレビューで実践する具体的な内容を確定することができます。 ふりかえりを実施するときのもう一つの大事なポイントは「関係者で観点を共有して実施する」ことです。 ソフトウェアレビューは一般的に“成果物”に対するレビューですが、ふりかえりは“活動”を対象としたレビューです。 突然「何かあれば指摘してください」と言われると、何となくぼんやり実施することになり、必要な結果が得られる可能性が低くなってしまいます。 関係者が今回のレビュー計画～終了までに体験したことの中には、磨けば光る財宝級の情報が含まれていることがあります。それをしっかり抽出・言語化するために「観点」を活用します。 下記はレビューふりかえりの観点例です。 [全体共通] ナイスプレー（自薦他薦問わず）、個人的に獲得した気づき、あとから準備不足や仕損じが判明したこと、など [レビュープランと準備] レビュー目的、確認すべき観点は適切であったか レビュー目的、観点等に必要なレビューアを割り当てていたか レビュー対象成果物の難易度や重要性・規模、作業者のスキル等からふさわしいレビュータイプを選択できたか ・レビュー実施に必要なインフラ（各種様式、結果格納場所の確保と周知、集合レビュー時の会議室やオンライン会議の準備など）は遅滞なく準備できていたか [集合レビュー] 集中して建設的に議論し結論が導けたか 全員参画できたか／全員から発言・意見・コメントが提示されたか 司会のファシリテーションは適切であったか [レビュー結果] 特定の観点による確認の欠落、不足が危惧されることはないか 指摘件数や指摘内容から想定されるリスクや問題点はないか ふりかえり時に各自が観点に沿ってふりかえり結果を1件1葉で書きだし、全員で共有してまとめていきます。とある一人の気づきや考えを関係者の気づきや考えに変えられる、共有されるのがふりかえりの大事な期待効果です。ふりかえりを通じて次のレビュー時にチームとして継続して実践すること、見直して実践方法を変えることを具体化します。 なお、ふりかえり観点は固定化するモノではありません。 個別のレビューの目的やチームや関係者の習熟度、実践レベル等に応じて内容を見直す必要があります。 このように「やりっぱなしレビュー」によるいつも同じような結果しか得られない状態から、レビューを実施するたびに個々人の体験やノウハウをチームのノウハウに変えてレビューのパフォーマンスを段階的に変えていく基盤にすることができます。 ・・・ちょっと長くなりました。 まだ途中ではありますが以上で「#5レビューの終わり方～レビュー評価・ふりかえり(1/2)」は終了です。 この続きは次回「#5レビューの終わり方～レビュー評価・ふりかえり(2/2)」でお伝えします。 お楽しみに。 この記事を担当したメンバー きたのしろくま（安達 賢二／ @kitanosirokuma ） 自律・自己組織化を促進する価値共創プログラムSaPIDをベースに三方よしとなる新しい価値を一緒に考えて創る「共創ファシリテーター」として活動中。 https://www.softwarequasol.com/ 【連載】ソフトウェアレビューをエンジニアリングっぽく語ってみる｜記事一覧 【第1回】［#0］イントロダクション 【第2回】［#1］レビューとは？ The post 【第3回】[#5]レビューの終わり方～レビュー評価・ふりかえり（1/2）｜ソフトウェアレビューをエンジニアリングっぽく語ってみる first appeared on Sqripts .

はじめまして！クオリティマネージャーの”黒山羊さん”です。 どのような業種においても、複数のチームで仕事を進めることは常に発生します。 複数人で仕事を進めるにあたり、打ち合わせやミーティングを開催して認識合わせから始まり、情報の共有、方針・内容の決定、合意に至っているのではないでしょうか。 会議の参加者はお客様、他社様、上役、チームメンバーとそれぞれ異なりますが、いずれの場合でもどのようなことを決定したかを残すために議事録を作成します。 それとは別に、議事メモというものもあります。 社内の小さな会議体の時に議事録代わりに作るというところもあると思いますが、私は議事録とは別に、会議の振り返りに役立てるため、議事メモを作成しています。 今回は、議事メモ作成のポイントを共有させてください。 議事録と議事メモの違い 議事録は会議全体の概要や決定事項等を記録するものです。 議事メモは議論の内容や議題の要点が記載され、決定事項に行き着く流れがわかるものです。 チームメンバーとの会議であれば、会議中に議事メモを表示させ、加筆修正しながら議論を進めるといった使い方もします。 議事録の内容 概要 会議の議題や論点、アジェンダを記す 決定事項 議題に対して決定したことを記す 未決事項 議題に対して決まらなかったこと、次回持ち越したことを記す 確認事項・宿題事項 次回までにやるべきことTODOとして記す この時、対応する担当と期限も記載しておく 議事メモの内容 議事メモは定められたものではなく、それぞれの組織にあわせて記載すればよいと思います。 ただ、議事録と突き合わせて会議の振り返りに使用する場合、アジェンダ毎にどのような意見や議論、質疑応答があったかを記載し、どのタイミングで決定事項と確認事項・宿題事項が出たかわかるようにすると使用しやすいです。 今の議事録事情 昨今のテレワークの普及により、オンライン会議が増えました。 オンライン会議をする際に録画をしておくことで、その録画データをもとに、生成AIが議事録を作成してくれる世の中です。 音声から文字起こしを行い、それを要約することで完成するのですが出来上がったものは要点や決定事項がしっかりまとめられており、少し手直しして議事録のフォーマットに落とし込めばそのまま使えるものになります。 生成AIで作成しなくても、録画が残っていれば後から見直して議事録と突き合わせることもできます。 議事メモ作成のポイント 議事メモは自分やチーム内で会議を振り返ったり、議事録の内容を深堀りするために使います。 個人的に議事メモに残しているポイントを連携します。 確認事項、宿題事項の記録について 確認事項や宿題事項も話の流れで誰がやいつまでにが抜けることがあります。アクションが着実に進むよう、5W1Hがわかるように心掛けるとTODOが明確になります。 確認事項、宿題事項にマークを付けておく 議事録にもTODOとして記載される事項ではありますが、議事メモであれば前後の流れも含めて確認できるので、やることのズレを少なくすることが出来ます。 マークをつけておくことで、後でメモを確認する際に見つけやすくなります。 誰の発言か書いておく 質問やその回答、依頼事項や意見などが出た場合は誰の発言かわかるようにしておきましょう。それによって、発言の意図を確認することに役立ちます。 資料のページ数を書いておく 資料の説明中に質問が出た場合、ページ数も添えておきます。 振り返りの際、資料を突き合わせやすくするため、役立ちます。 時間をメモる これは録画データを確認するときに重宝します。基本議事メモは時系列に記載しているので、前から順に追っていけば該当箇所にたどり着けますが、意見が出たタイミングの時間を書いてあれば、直接アクセスすることが出来ます。 資料とは違う意見は残しておく 資料が間違っていて訂正しているのであれば、後で修正した資料を連携してもらえばいいのですが、報告最中に補足説明や懸念事項が挟まれた場合は残すようにしています。 やっかいなのが、例えば技術者から報告の最中に出てきた懸念事項。ちょっと気になっている・引っかかっている箇所がある。課題にはしたくないけど報告はしておきたい。そういった理由で会議の中の報告の最中に混ぜてくることはあります。（私自身も技術者だった頃、チーム内ミーティングでやりました） そういったものが会議でスルーされると議事録から外れてしまうこともあるので、議事メモには残しておきましょう。 おわりに テレワークや生成AIと我々を取り巻く環境は日々変化していっていますが、人と人が協力して仕事を進めることに変わりはありません。 お互いの意思疎通ができ、認識齟齬が発生しないよう、よりよい会議を開催し、スムーズな決定事項が出来るような資料作成を念頭に置いて頂ければと思います。 参考書籍 コンサル一年目が学ぶこと （大石哲之 著／Dicover） こちらの記事もおすすめです QAコンサルタントの私が、文章を書く時に気を付けている事(5W1H) こんにちは、そして初めまして、QAコンサルタントのsakkyです。  私達は日々、短いものから長いものまで、色々な文章を書いていますが、文章を書くのを苦手に感じたり、なんだかイマイチしゃっきりしないと感じたり、記載の過不足があるのではないかと思ったりする事... 　続きを読む　 Sqripts 段取り八分／仕事二分のマネジメント こんにちは。クオリティマネージャーのおすぎです。「段取り八分、仕事二分」という言葉があります。仕事の事前準備の大切さを表すもので、仕事に取り掛かる前にきちんと段取りを済ましておくことで仕事の8割は完了している、という格言です。段取りはプロジェクトマ... 　続きを読む　 Sqripts 環境構築ミスやヒューマンエラーをなくすためのノウハウ こんにちは、テスシです。私はソフトウェア開発で、システムテストに携わっています。この工程では、これまでに開発したプログラムを一つにまとめて、想定通りのものができているかどうかや本番環境でちゃんと動作するかどうかを確認しています。はじめに今回のお話... 　続きを読む　 Sqripts The post 議事メモのすすめ first appeared on Sqripts .

帰納的な推論 と 発見的な推論(アブダクション) は、 私たちがソフトウェア開発の現場/実務で（知らず知らずにでも）駆使している思考の形です（それどころか日々の暮らしでも使っています）。 それほど“自然な”思考の形ですが、どんな考え方で、どんなところに注意すると質の高い思考ができるのか、基本知識を押さえておくと実務のレベルアップにつながります。 ＜実務三年目からの発見力と仮説力　記事一覧＞ ※クリックで開きます 【第1回】見つけるための論理【連載初回、全文公開中】 【第2回】 “共通項”を見つけ出す 【第3回】発見はよい観察とよい方法から 【第4回】帰納の仲間と落とし穴 -前編- 【第5回】帰納の仲間と落とし穴 -後編- 【第6回】 なぜ・どのようにを説明したい 今回からは、“非演繹的”なもうひとつの推論、 アブダクション の考え方を見ていきます。 今回は「仮説(説明仮説)って何？」「アブダクションって何！？」という話です。 ところで仮説って何だろう？ “なぜ” “どのように”を解き明かしたい、説明したい・して欲しい 帰納的推論で一般的な傾向を見つけたり、原因と結果の関係を見つけるのに加えて、 「その条件(原因)から なぜ この事象が起こるか」「原因から結果まで、 どのようにして (どのような過程・機序で)起こるか」の説明ができれば、 推測の説得力は相当高まるでしょう。 アブダクションが考える仮説は、 このような「事象の原因を見つけたり、原因から結果に至る過程などを説明する」仮説( 説明仮説 )です。 よい仮説の性質 はじめに、当てずっぽうや思いつきの推測と一線を画す「よい仮説」が具えているべき性質を確認しておきましょう。 （参考：『論理学入門』） いくつか考えられますが、外せないのは次の4点です。 問題となっている事象や因果関係を説明できる。 直接的/間接的に 真偽を検証可能 (verifiable)である。 仮説自体でなくとも仮説がもたらす帰結などの真偽を、事実に照らして判断できる。 （ 反証可能性(偽であると検証できる) は、 誤った仮説を除外できるために重要な性質） 説明能力が同じなら、 より単純な仮説 が望ましい。 複数の仮説が考えられて、同じように不整合や破綻がなく、同じように説明できるなら、単純な仮説を採るのがよい。 少数の仮定から、整合的に説明できる仮説 が望ましい。 既に確立された知識・理解に基づいて、多くの仮定を足すことなく、系統的・体系的に説明できるのが理想的。 アブダクションとは 仮説を考える推論とその形式 19世紀から20世紀アメリカの哲学者・論理学者パースは、説明仮説の重要性と、よい仮説を考える推論( アブダクション )はどのようなものか（どうあるべきか）を研究しました。 パースによれば、アブダクションの典型的な形は次のように示されます。 （出典：『アブダクション　仮説と発見の論理』。太字は引用者による） ①驚くべき事実Cが観察される。 ②しかし もしHが真であれば、Cは当然の事柄 であろう。 ③よって、Hが真であると考えるべき理由がある。 「驚くべき事実C」とは、理由や原因を探りたくなるようなものごとや、解明が必要なものごとです。 （推理小説や推理ドラマの「不可解な事件」や、日常で「これは何だろう？」と不思議に思う出来事もそうです） このCに対して 「こう考えれば C は説明できる」と、“謎”の解消を図る のが仮説Hです(図6-1)。 図6-1 アブダクションの典型的な形・例 アブダクションの形式面での特徴 図6-1の推論の形を図式化すると図6-2のようになります。 図6-2 アブダクションの論理 図6-2の前提1と前提2の順序を入れ替えると、混合仮言三段論法の形をしています(図6-3)。 つまり、アブダクションによる推論は、見かけ上演繹的な推論っぽい形をまとっています。 図6-3 アブダクションの論理・変形 ただし、それは 後件肯定 という、演繹的な推論では誤りになる形です（図6-4。実践編「 “ならば”を使って推論する 」参照）。 図6-4 混合仮言三段論法・後件肯定の誤謬 このように、 （後件肯定という 演繹的には誤った形ではあるが ）後件(事実や結果)から、その後件を導く前件(前提や原因など)を“逆向きに”考え、 「 そう考えるのが理にかなっている、もっともらしい 」という説明仮説を発案する のが、アブダクションという推論形式の特徴です。 図6-5 アブダクションの論理の特徴 ポリアの「発見的三段論法」 仮説を考える推論の、もうひとつの見方 パースとは別に、20世紀アメリカの数学者ポリアが「発見的推論」というテーマの論考を著しました。 「発見的推論」とは「帰納や類推(類比的推論)から新たな知見を引き出す推論」に与えた名称で、 パースのアブダクションに言及したものではありませんが、内容はアブダクションに通じるものがあると思われるので、 アブダクションを“側面支援”するひとつの考えとしてその一部を紹介します。 発見的三段論法 ポリアはこの種類の推論の形と意味を考察し、 演繹的な三段論法に対応づけて「発見的三段論法」と呼びました。 発見的三段論法の典型は次の例で示されます。 （参考：『いかにして問題をとくか』、『数学における発見はいかになされるか』） ①Pが正しいならば、Qも正しい。 （例：外洋の航海から陸に近づくと鳥を見かける） ②Qが正しいことが判った。 （例：今、鳥の姿が見えた） ③Pが正しいということは確からしい。 （例：多分陸が近いだろう） 「①PならばQ。②Q。③従って、Pであろう」 という形で、Pがアブダクションでいう仮説Hに相当すると見ることができます。 やはり後件肯定の形(図6-4)ですが、発見的三段論法でもこれを誤りとせず、次のように考えます。 前提Pを裏づける帰結Qが正しい事例が増えると、Pに対する信頼が増す(図6-6 上)。 （「陸が近づくと鳥を見た」事例が増えれば、「鳥が見えた」から「陸が近い」確からしさは増す） 前提Pが正しくない事例が増えると、帰結Qに対する信頼は減る(図6-6 下)。 （「陸は近くないのに鳥を見かけた」“反例”が増えれば、この推測は怪しくなる） 図6-6 発見的な推論の形と意味 なお、この「信頼が増す/減る」は、PとQとの関係性の強弱に応じて“グラデーション”(度合の違い)があります。 PでないのにQである可能性が低い場合は、Qが真の時、Pの信頼はかなり増しますが、 PでなくてもQである可能性が高い場合は、Qが真の時、Pの信頼はわずかに増すにとどまります(図6-7)。 図6-7 発見的な推論の形と意味・グラデーション版 “犯人でないのに手の込んだトリックを仕組むだろうか？” 図6-1上の「V氏殺人事件」で具体化してみましょう(図6-8)。 （なお、図6-1から捜査が進んで、②で「V氏が犯行時刻に間に合うように戻ってきたことが判明している」時点であるとします） 図6-8 発見的な推論・例 レッツアブダクション アブダクションとは、形式や意味の面から見ると、どのようなものなのか？　今回はその概要を見ました。 アブダクションもまた蓋然的な推論であり、“間違い”の可能性をはらみますが、“間違えるリスク”以上の価値をもたらし得る推論です。 説明仮説の質を高めて、原因究明の効果と効率を高めましょう。 次回は、「仮説を考える」にはどう取り組むとよいのか、どんな進め方があるかを見ていきたいと思います。 参考文献 近藤洋逸, 好並英司 『論理学入門』 岩波書店 1979 米盛裕二 『アブダクション　仮説と発見の論理』 勁草書房 2007 パース(著), 伊藤邦武(訳) 『連続性の哲学』 岩波書店 2001 ポリア(著), 柿内賢信(訳) 『いかにして問題をとくか』 丸善 1954 （1997(日本語第11版30刷)) ポリア(著), 柴垣和三雄(訳) 『数学における発見はいかになされるか 2 (発見的推論　そのパターン)』 丸善 1959 図版に使用した画像の出典 Loose Drawing 人物画をお借りしています。 品質探偵コニャン：Produced by Sqripts . No Unauthorized Reproduction. 【連載】ソフトウェアエンジニアのための論理スキル［実務三年目からの発見力と仮説力］ 記事一覧 【第1回】見つけるための論理 【連載初回、全文公開中】 【第2回】 “共通項”を見つけ出す 【第3回】発見はよい観察とよい方法から 【第4回】帰納の仲間と落とし穴 -前編- 【第5回】帰納の仲間と落とし穴 -後編- 【第6回】 なぜ・どのようにを説明したい The post 【第6回】 なぜ・どのようにを説明したい｜実務三年目からの発見力と仮説力 first appeared on Sqripts .

こんにちは、テストエンジニアの ナカノ です。私は以前、とあるプロジェクトで「お金に関するシステム」に関するテスト設計・実施を行う機会がありました。 「課金 ＝ お金」 というわたしたちの日常生活に密接に関わるモノのシステムにおいて不具合が発生してしまった場合、ユーザーに対する損失は多大なる影響を与えることになります。そのため、一般的なシステムに加えて様々な状況やリスク等を考慮しながらテスト設計を行う必要があると感じました。そういった経験を基に、今回は「お金に関するシステム」においてテストで使用できるような観点を考えてみました。 ※今回ご紹介するケースはあくまで1つの事例・観点であり、全てのカバレッジを網羅するわけではありませんが、少しでも参考にしていただけたらと思います。 お金に関するシステムとは？ はじめに、今回のメインテーマである 「お金に関するシステム」 についてどのようなものがあるか、一例をご紹介したいと思います。 オンライン決済システム：Eコマースや店舗での支払い等、Webシステムやアプリで決済を行うシステム 金融機関システム　　　：金融機関（銀行・証券・保険）が利用する業務システム 資産運用システム　　　：AI等を利用して資産運用を取り扱うシステム 仮想通貨取引システム　：金融機関を介さずに仮想通貨の取引を行うためのシステム 上記で挙げたものの中では特に「オンライン決済システム」がもっとも身近に感じられるシステムなのではないでしょうか。最近はお店でのタッチ決済やネットショッピングなど、モノやサービスの購入をオンライン上で済ませることが当たり前の時代となり、またシステムの需要も増えてきました。本記事では、そういったオンライン決済システムの中でも「課金システム」や「決済」についてピックアップして、テストの観点をご紹介していきたいと思います。 汎用的なテスト観点について まずはじめに大前提として、他のシステムテストなどでも共通と言える汎用的なテスト観点を挙げてみます。 汎用的なテスト観点例） 表示　　　　：仕様通りの文言やアイテム等が適切に表示されているかを確認する レイアウト　：レイアウト崩れ等が発生せず適切に描画されているかを確認する 入力　　　　：テキストボックスやテキストエリア等に文字列が入力できることを確認する 画面遷移　　：仕様通りに各ページ等に画面遷移できるかを確認する 挙げればキリがないので他は割愛しますが、このような汎用的なテスト観点はどのようなシステムにおいても重要な確認項目となります。 数値のバリデーション観点について 次に数値のバリデーションについてご紹介します。課金システムや決済システムでは、「お金＝数値」を入出力する機能が想定されるため、「バリデーション（入力値が正しい形式や範囲に合致しているか）」もとても重要な観点となります。 「数字」に関するバリデーション観点例） 小数点あり　：100.1、0.1234　など 記号あり　　：+100、-1234　など 指数表記　　：1e2 (=100)、1e12 (=1,000,000,000,000)　など また、半角数字以外を入力したときの挙動を確認する観点も考慮する必要があります。 「文字」に関するバリデーション観点例） 全角数値　　　　　：１２３４５　など 数値以外の文字種　：ひらがな・カタカナ・漢字・アルファベット・記号　など 数値の入力が可能なシステムの場合、「境界値」に不具合が潜んでいる可能性が高いため、値の有効・無効の範囲を確かめる観点も重要なポイントとなります。 「境界値」に関するバリデーション観点例） 最小値の境界値　　：最小有効値の境界値、最小無効値の境界値　など 最大値の境界値　　：最大有効値の境界値、最大無効値の境界値　など 境界値分析については、こちらの『 「境界値分析」をテスト設計に取り入れる 』でも紹介しているので、ご興味がある方は是非読んでみてください！ 「境界値分析」をテスト設計に取り入れる こんにちは、はまたくです。前回の「同値分割法」を使ってみたに続いて、今回は「境界値分析」についてのお話をします。JSTQB FLを勉強したけど実際にテスト技法を使用したことが無い方や、現在JSTQBの勉強を進めている方々の参考になれば幸いです。境界値分析の定義... 　続きを読む　 Sqripts 以上が数値に関する観点の一例のご紹介となります。他にもシステムの仕様や条件によって様々な要素や観点の考慮が必要なため、実際の作業では仕様やテスト条件を見逃さないように、十分注意してテスト設計を行う必要があります。 課金システム特有のテスト観点について 続いて、「課金システム」特有のテスト観点について考えてみます。課金システムでは、テスト対象となるシステムの仕様によって課金に関する各機能の実装が異なるため、本記事ではいくつかの代表的な機能をピックアップしてテスト観点をご紹介します。 クレジットカード決済 Eコマースサイト等の課金システムの場合、ほとんどの機能仕様としてクレジットカード払い、コンビニ払い、口座振替といった「決済方法」が選択できるようになっているかと思います。本記事ではその中でも決済代行システムを利用した 「クレジットカード」 について、観点を検討してみました。 対象の課金システムが決済代行システム（ECサイト等の運営と決済機関との間で第三者が決済を仲介するシステム）を利用している場合、「テスト専用のカード」を使用して架空のデータで決済処理を行ってテストすることができる場合があります（実際に決済は行われません）。通常、テスト専用のカードのデータとしては、 ①正常に決済できるカード と ②決済処理を作為的に失敗させるカード の2種類あります。さらに、①正常に決済できるカードには、「カードブランド」の種別（基本的には国際的な5ブランドなど）や「カード属性」として「デビッドカード」や「プリペイドカード」などの種類があります。一方、②決済処理を作為的に失敗させるカードには、エラーの種別として「残高不足」や「限度額オーバー」といったデータが用意されていることがあります。 クレジットカードの因子例） 決済に成功するケース ： カード種別　　　　　：国際的な5ブランド、デビットカード、プリペイドカード、海外発行カード　など セキュリティコード　：4桁、3桁 名前の文字列長　　　：有効桁数最小、有効桁数中間、有効桁数最大　など 有効期限　　　　　　：最短期限、中間期限、最長期限　など 決済に失敗するケース ： エラー種別　　　　　：残高不足、限度額オーバー、取扱不可　など クレジットカードの条件の注記 例えば、上記記載の「決済に成功するケース」のようなパターンについては、システムの特徴やテストの規模感等を考慮したうえで、「全網羅」とするのか「水準網羅」とするのかといった、どのような条件でテストを行うのかをテスト設計段階でステークホルダーや開発側と協議して合意を形成したうえで決定する必要があります。 クレジットカードの因子例を基にした因子・水準リスト 因子・水準リストを基にした全網羅のパターン例 すべてのパターンをテストケース化する「全網羅」でテストしようとした場合、8 × 2 × 3 × 3 = 144パターンとなるため、テストケース数は大きく増加します。全パターンの組み合わせで確認できるため、ケースの抜け漏れなどは防ぐことができますが、その分テストに必要な工数が膨らむ傾向があります。 因子と水準を基にした水準網羅のパターン例 １つの水準に対して最低限１回は確認を行う「水準網羅」の場合は、「全網羅」ほどの複雑な組み合わせは確認できませんが、例えばシステムの特性として任意の組み合わせで確認できればよいといった条件の粒度感が提示されているのであれば、比較的有効となる確認方法となります。 課金方法種別と残高 課金方法種別について 課金システムにおける課金方法では、主に 「都度課金」 と 「継続課金」 が挙げられます。「都度課金」では商品やサービスの決済ごとにその都度課金する方法に対して、「継続課金」ではサブスクリプションシステムの月額使用料などに代表される設定された金額が毎月決められた日に課金される課金方法となります。各課金方法に関するテストについては、対象システムの仕様に即した各機能が動作するか（都度課金であれば決済時に毎回課金する方式となっているか、継続課金では決済時は課金せず決済日に引き落とされるか　など）といった単体的な機能の確認に関するテストが有効となるでしょう。 残高について 課金システムでは、事前にチャージされているお金やポイントを 「残高」 として取り扱い、そこから決済を行う機能仕様が備わっている場合があります。残高は決済前後の状態が重要なポイントとなるため、以下のような観点を抽出すると有効な確認となるでしょう。 都度課金時の決済金額と残高の関係に着目したバリデーション例） 決済金額 ＜ 残高（決済できるか／決済後の残高情報が適切か） 決済金額 ＝ 残高（決済できるか／決済後の残高情報が適切か） 決済金額 ＞ 残高 決済可能な額を追加で課金（決済できないか／決済後の残高情報が適切か） 決済のキャンセル（決済できるか／決済後の残高情報が適切か） 継続課金であっても同様に、設定された決済日に対して自動で課金額が引き落とされるシステムとなるため、決済日当日に上記観点を応用することができます。 年齢による課金額制限 システムによっては、使用するアカウントの年齢に対して課金できる金額の上限が定められている場合があるため、年齢や金額の境界値等の仕様を十分に確認し、テスト設計を行う必要があります。仕様を整理するためには、以下のようなデシジョンテーブルが有効となるでしょう。 課金額制限の仕様例） 15歳までは月額で課金できる上限金額を 5,000円 までとする 16歳から19歳までは月額で課金できる上限金額を 20,000円 までとする 20歳以上は上限金額なし とする 上記仕様を基にしたデシジョンテーブル例 デシジョンテーブルについては、『 いまさらデシジョンテーブルというものを考えてみた 』でも解説されています。こちらもご興味がある方は是非読んでいただければと思います！ いまさらデシジョンテーブルというものを考えてみた こんにちは、ゆーすけです。 「V&V」「シフトレフト」に続く、いまさらシリーズの第3回です。今回は、ブラックボックステスト技法の一つである「デシジョンテーブルテスト」について考えてみたいと思います。デシジョンテーブルとは一旦、JSTQB FLシラバスでどの... 　続きを読む　 Sqripts 決済タイミングとステータス 近年、市場はクレジットカードやスマホから決済を利用するようなシステムにおいて、 二重決済 （システム上の欠陥等により同じ金額が２回決済されてしまう現象）などのトラブルが発生する事例が増えてきました。原因としては、システム側で請求したはずの履歴がないために再請求が行われるケース（システム間の連携不備）や、注文時と商品発送時などで送信されるデータがそれぞれ2回分決済されてしまうといったケースがあるようです。そのため、課金システムにおいても決済を行うときのタイミングやそのときの各ステータスの変化に着目するような観点は重要なポイントとなります。例えば、決済時のアイテムやコンポーネント間での確認であれば「機能テスト」が、決済処理とそのステータスといった各処理の連携に関する確認であれば「状態遷移テスト（または画面遷移表や状態遷移図を用いたテスト設計）」がそれぞれ有効なテストとなるでしょう。 機能テストの観点例） 正常系： 決済処理を行ったとき、関連するステータスが適切に変化するか 決済処理を行ったとき、関連する履歴が適切に反映されるか フロントシステムから決済処理を行ったとき、バックエンドシステムや基幹システムなどに決済した情報が適切に受け渡されるか 異常・特殊操作系： 同時処理（複数ブラウザ等から同タイミングで決済したとき二重決済されないか） 割込処理（決済処理中などで別の決済情報が割り込みしたとき各決済が適切に処理されるか） 連続操作（決済を確定するボタンを連打したとき二重決済されないか） ※上記で記載している当該処理・操作時の期待結果はあくまで想定で記載しているため、実際のテスト設計時は対象システムの仕様を考慮する必要があります。 状態遷移テスト例） 決済に関する各ステータスの仕様例 仮売上： 決済が完了して注文が入った状態 処理中： 売上処理・キャンセル処理を行っている状態 決済完了： 実売上処理が正常に完了した状態 決済失敗： エラーが発生して決済処理が失敗した状態 キャンセル： ユーザーが注文のキャンセルを行った状態 上記仕様を基にした状態遷移図例 状態遷移図については、『 幅広いソフトウェアとテストレベルで適用可能な状態遷移テスト 』にて解説されているため、詳しい内容はこちらでご確認いただけます！ 幅広いソフトウェアとテストレベルで適用可能な状態遷移テスト 初めまして。テストエンジニアリング部のこまです。今回はテスト技法の1つ、「状態遷移」についてのお話です。実際の業務でお世話になることも多い技法であることに加えて、JSTQBの学習を進めている方で苦手意識がある方もいらっしゃるかと思い（私がそうでした）、... 　続きを読む　 Sqripts その他の機能 その他に、例えば 「ポイント」 を付与・利用できるような機能や、 「クーポン」 に対応しているような機能があれば、課金額への影響に関するテスト観点や今回ご紹介した「残高について」周りのテスト観点をかけ合わせてテスト設計を行うと有効となる場合があります。その他にもテスト対象となる課金システムによって様々な機能やサービスがあるため、各機能仕様やテスト条件、テスト環境やテストの規模感などに応じて、適切なテスト設計を行う必要があることを忘れてはいけません。 おわりに 冒頭の「お金に関するシステムとは？」でも述べた通り、近年ではオンライン決済等、お金を扱うシステムが増えてきました。一方で、そのようなお金に関するソフトウェアが正しく動作しないと、経済的な損失、時間の浪費、信用の失墜など企業やユーザーにとって生活レベルで重篤な問題が発生する可能性があります。そのため、テスト設計者は仕様通りに動作することはもちろんのこと、仕様通りの動きが妥当か、ユーザーの様々な利用シーンを考慮できているかなど、開発視点とユーザー視点の両方からテストを考えることが品質保証にとって重要なポイントとなります。仕様やリスクを深く理解し、様々な状況を想定してテストを設計していきたいと改めて感じました。今回の記事が少しでも参考になれば幸いです。 The post 課金システムのテスト設計に必要な観点を考えてみた first appeared on Sqripts .

この連載では、ソフトウェア開発のQAエンジニアとして働き始めた皆様に向けて、私の実体験をもとに「こんなことを知っておけばよかった」という、ちょっとした気づきを共有します。 一緒にソフトウェア開発のQAエンジニアとしての充実したエンジニアライフを築くためのヒントを探っていきましょう。 ＜QAエンジニアのスタートガイド 記事一覧＞ ※クリックで開きます 【第1回】充実したQAエンジニアとしてスタートするためのガイドライン 【第2回】「誰のためか」を意識しよう 【第3回】QAエンジニアの第一歩、「ソフトウェアテスト」を知ろう -前編- 【第4回】QAエンジニアの第一歩、「ソフトウェアテスト」を知ろう -後編- 【第5回】コミュニケーションが鍵を握る 【第6回】学ぶ姿勢を持ち続けよう 本記事ではエンジニアとして重要な課題である「学ぶこと」について解説します。 学ぶことは大切です。ITという分野は技術やトレンドの移り変わりが激しく、常に最新の知識をアップデートしていく姿勢が求められます。 また、ITエンジニアは、学ぶことでさらにキャリアを飛躍できる可能性が高いです。 私が過去に経験していた営業職では、「勉強してもなかなか結果につながらない」ということがありました。もしかしたら他の職種でも同じような状況があるかもしれません。 一方で、ITエンジニアは学んだ知識をすぐに試せる特徴があると実感しています。また、世の中で広く知られている知識の多くは、現実のプロダクト開発の貢献につながるような、実践的なものがたくさんあるとも思います。 なので、前向きに学び、それを普段の業務で実践することは充実したエンジニアライフに繋がると考えています。 学び方は、学校教育や受験勉強など、これまでの人生でたくさん経験してきたのではないでしょうか。 しかし、実際に働いていく中では、学生時代と同じように学べないことがあると思います。 本記事では、社会人として、学びを継続することの考え方やコツを伝えていきます。 さまざまな方法で学習する 学習の仕方を学ぶ 社会人になると、1日のほとんどを学びに使っていた学生時代と状況が異なります。 もしかしたら、仕事や家庭の事情で、以前と同じようには学習できないかもしれません。 これらは時間的な要因だけでなく、脳の成長や、経済的な環境の変化にも影響を受けているのだと考えています。 そのため、社会人、そしてエンジニアとしての学び方を身につける必要があります。 具体的な学習の方法は、様々な書籍で言及されていますので、ここでは個別の学習方法について言及しないでおきます。 学習の仕方を学ぶには、以下の本をおすすめします。 エンジニアの知的生産術 （西尾泰和 著／技術評論社） 一生頭がよくなり続ける すごい脳の使い方 （加藤俊徳 著／サンマーク出版） 独学大全 （読書猿 著／ダイヤモンド社） 学習方法には様々なものがあり、具体的にどうやって学ぶかは、自身で考える必要があります。 重要なのは、一人一人に合った学習方法があり、「これが最高」というベストプラクティスは存在しないということです。 アウトプットを通じて学ぶ 個人的にいい学習方法だと思っているのは、アウトプットを通して学ぶことです。 ご自身が使用するナレッジマネジメントツールへの記録、SNSやブログへの発信、イベントへの登壇、普段の仕事での実践などです。 しかし、SNSやブログを通してパブリックな場にアウトプットすると、批判を受けてしまう可能性もあります。外部に向けてのアウトプットはいい面もあれば悪い面もあります。 それでもアウトプットをおすすめする理由は、自分の記憶に頼らなくても、ネット上から自分で検索して思い出すことができるというメリットがあることです。 アウトプットを通じて、自分の力を自分の外に蓄えておくことが可能になるのです。 「テスト」を通じて学ぶ QAエンジニアとして、様々なソフトウェア開発の言語やフレームワークを学ぶことがあると思います。 そういった場合に私は「どうやったらテストできるかを考える」ことを通して学んでいます。 テストとは試験ではなく、ソフトウェアテストです。 ソフトウェアテストは、そのプログラムの呼び出し、処理、アウトプットなど、ソフトウェアの概観を理解するのに重要な要素が詰まっています。 プログラミングを苦手だと感じているQAエンジニアは少なくありません。 そんな人は一度、「この言語やフレームワークはどのようにすればテストできるのだろうか」から考えてみることをおすすめします。 習慣を味方につける 社会人になると、様々な年齢や経験を持った人と比較されます。 そのため、学生時代のような、「同じ世代が同じスタートを切って比べる」ような経験からマインドをチェンジする必要があります。 早く到達することより、むしろ長い時間をかけてでも高い能力に到達することで、メリットを享受できることを理解することです。 だからこそ、長期的な視点で学習に取り組むことは大切だと思います。 「習慣にできるかどうかはその人の性格による」と考えている人もいるかもしれません。実際に私もそう考えていました。 しかしながら、習慣化にもまた技術があり、習熟することが可能なのです。 小さな習慣から始める 私のおすすめは、小さな習慣を作ることです。 学習の具体的な習慣だと、「1行だけ本を読む」や「1問だけ解いてみる」といったことです。 こういった小さな習慣は、数秒から数分程度で実行できるので、習慣化しやすいです。 これらの習慣をアプリやカレンダーなどで簡単に記録します。 小さな習慣の実行と記録を一定期間、例えば1ヶ月続けたとき、これは成功体験となり、次の習慣化のモチベーションに繋げることができるのです。 小さな習慣は育つ 小さな習慣は小さな歩みですが、時間を味方につけることで、長期的には大きな飛躍につながります。 そして、ここで強調したいことは、「小さな習慣は進化する」ということです。 例えば、1日1行の読書を続けているうちに、「1行から１ページにしよう」といった、小さな習慣が大きな習慣に育っていくことがあります。 私のおすすめはこういった前向きなモチベーションには正直に従い、大きな習慣にしてしまうことです。 続けるのが難しくなればまた小さな習慣に戻せばいいのです。 習慣化に失敗しても、習慣化をする技術は失敗を通じて向上させることができると考えます。 習慣化の技術については以下の本が参考になります。 200万人の「挫折」と「成功」のデータからわかった 継続する技術 （戸田大介 著／ディスカバー） 仕事から学ぶ エンジニアとして、様々な学び方があります。 机に向かって勉強するだけでなく、普段の仕事から学ぶことも大切です。 ふりかえりから学ぶ 普段の仕事をしていて、学習よりもむしろ、業務に追われてしまうことは少なくないと思います。 そういった中で、「ふりかえり」や「内省」を通じて学ぶことも有効です。 失敗を繰り返さないことも大切ですが、「よかったことを習慣化する」という点でも、自分の普段の業務をふりかえり、自分自身の学びに繋げることができます。 たとえばKPTというフレームワークがあります。 これは自分が行ったことや感じたことなどを、 Keep/Problem/Try という3つの視点で分類して、次のアクションを考えるという手法です。 KPTの中ではProblemに気を取られる人は少なくないですが、むしろ私はKeepを習慣化することが大切だと考えています。 ふりかえりについては下記の書籍をおすすめします。 アジャイルなチームをつくる ふりかえりガイドブック 始め方・ふりかえりの型・手法・マインドセット （森 一樹 著／翔泳社） 失敗から学ぶ 失敗から学ぶことも大切です。 失敗には学びにつながる「良い失敗」と学びに繋がらない「悪い失敗」があります。 たとえば「失敗学」という分野では失敗の原因を分析し、レベルの低い判断ミスを防止しつつ、高度な判断ミスを形式知にして改善していくという考え方があります。 失敗学のすすめ （畑村洋太郎 著／講談社） 最後に 最後に、1つだけアドバイスしたいことがあります。 「さあ学んでみよう」と学んでみても、うまく記憶が定着しなかったり、アウトプットに繋がらないことがあります。 それによって「また、これを学ばなければいけない」とか「また、こんなこと忘れていて恥ずかしい」と思うことがあると思います。 私はよくあります。 そういった時に私が自分に言い聞かせていることがあります。 「繰り返しの中から、また学べばいい」と考えることです。 何かを学び、忘れてしまって、同じことを学んでしまうこともあります。 しかし、それを悔やむ必要はありません。 そうして悔やむのではなく、「また学ぶことができる」「同じことでも学べばいい」と前向きに考えて、好奇心を持ち続けることが大切だと考えています。 「どれだけ学べたか」は他者から見れば、大事かもしれません。 一方で、「学ぶ姿勢を持ち続けよう」は、自分自身が充実したエンジニアであると感じて過ごすために、重要だと思っています。 【連載】QAエンジニアのスタートガイド 記事一覧 【第1回】充実したQAエンジニアとしてスタートするためのガイドライン 【第2回】「誰のためか」を意識しよう 【第3回】QAエンジニアの第一歩、「ソフトウェアテスト」を知ろう -前編- 【第4回】QAエンジニアの第一歩、「ソフトウェアテスト」を知ろう -後編- 【第5回】コミュニケーションが鍵を握る 【第6回】学ぶ姿勢を持ち続けよう The post 【第6回】学ぶ姿勢を持ち続けよう｜QAエンジニアのスタートガイド first appeared on Sqripts .

こんにちは、K.Oです。 現代のソフトウェア開発では、新しい技術やプロセスの導入機会が増えています。特に、スピードと柔軟性が求められるスタートアップのアジャイル開発では、技術導入による生産性向上が大きな魅力です。しかし、現場の抵抗感やスキルギャップにより、導入が思うように進まないことも少なくありません。 そこで鍵となるのがチェンジマネジメントです。これを活用することで、組織や個人が変革に柔軟に適応し、スムーズに定着させるためのプロセスを可視化・管理できます。 本記事では、まずチェンジマネジメントの全体像を押さえ、以下の2つの事例をもとに、ADKARとKotterの2つのモデルを用いてチェンジマネジメントの実践方法を解説します。 スタートアップのアジャイル環境に品質管理の仕組みを導入 第三者検証企業のテスト工程にAIベースのテスト支援を導入 チェンジマネジメント とは？変革を定着させる基本原則 チェンジマネジメントとは、新しい技術やプロセスをスムーズに導入し、定着させるための手法です。単にツールを導入するだけでなく、組織や個人の行動変化を支援し、変革を持続させることが目的となります。 代表的なフレームワークとして、以下の2つがよく知られています。 ADKARモデル ジェフ・ハイアット（Jeff Hiatt）が提唱した、個人に焦点を当てた変革モデルです。 変革を受け入れる個人の心理プロセスを次の5つの要素で定義しています。 Awareness（認識） – 変革の必要性を理解していること Desire（欲求） – 変革に参加し支えたいという意欲があること Knowledge（知識） – 変革の方法に関する知識を持っていること Ability（能力） – 新しいやり方を実行するスキルが備わっていること Reinforcement（強化） – 定着させ変化を持続するための強化策があること ADKARモデルでは、個々人が「なぜ変わる必要があるのか」「変化が自分にどう影響するのか」を明確に理解し、自発的に変化を受け入れる状態を作ることを重視します。 個人レベルでこの5要素を順に満たす支援を行うことで、組織全体の変革成功率を高めることができます。 Kotterの8段階プロセス ジョン・コッター（John Kotter）が、多くの企業の変革事例を分析してまとめたフレームワークです。変革を成功させるために踏むべき8つのステップを提示しており、特に大規模な組織変革における人の動きに焦点を当てています。 8段階の概要は次の通りです。 危機意識を高める – 変革の必要性を周知し、現状のままでは問題であるという認識を共有する 強力な連帯を築く – 変革推進チームを結成し、信頼できるメンバーで連帯して取り組む 戦略的ビジョンを策定する – 目指す方向性（ビジョン）と実現する戦略を示す 全員の支持を得る – ビジョンを社内に浸透させ、できるだけ多くの支持と参画を得る 障壁を取り除いて行動を可能にする – 新しい取り組みを妨げる抵抗や障害を排除し、現場が行動しやすい環境を作る 短期的な成功を生み出す – 早い段階で小さな成功事例を作り出し、成果を実感させる 加速を持続する – 得られた成果を踏み台にさらなる変革を進め、勢いを維持する 変化を定着させる – 変革で導入した施策を組織文化や日常業務に組み込み、元の状態に戻らないよう定着させる このモデルのポイントは、抵抗感のある人々も巻き込みながら信頼関係と透明性を持って進めることで、受動的で抵抗感のある人を主体的な変革の担い手へと変えていく点です。 コッターのモデルはトップダウン視点の色合いが強いため、ADKARモデルで個人の理解と納得を促しつつ、コッターのステップで組織の環境を整えるという使い分けが効果的です。 以降の事例では、ADKARモデルとコッターの8段階プロセスを効果的に組み合わせながら、品質管理の導入やAIベースのテスト支援の導入を例に成功させるポイントを解説していきます。 ケース1：スタートアップのアジャイル環境に品質管理を導入 スタートアップのアジャイル開発に起こりがちな品質管理の課題 アジャイル開発を採用するスタートアップでは、以下のような課題が起こりやすい傾向があります。 スピード重視文化の弊害 「動くものを早く届ける」を優先し、テストや品質基準を軽視しやすい 属人的な判断・経験頼み KPIや品質基準がなければ、リリース前のチェックも各エンジニアの裁量に依存 リリース後のバグ増大と修正コストの上昇 初期不良が重なり、結果的に作業負荷や開発スピードが落ちる アジャイル開発はスピードと柔軟性が強みですが、品質面が甘いと長期的な成長を妨げる可能性があります。こうした状況を改善するためには、品質管理の仕組みを「無理なく」アジャイル開発に取り込むアプローチが効果的です。 ADKARモデルを活用した導入ステップの一例 A（Awareness） ：認識 まずは、品質管理の重要性を全員に認識してもらうことが出発点です。 過去の不具合件数や修正コストを可視化。チームが「長期的な開発速度低下」を実感するようなデータを共有 D（Desire） ：欲求 次に、品質管理導入がチームのメリットにつながることを共有します。 バグ修正頻度が下がれば、エンジニアはより新機能開発に専念できる 品質管理の導入は、開発者のストレス削減につながることを強調 K（Knowledge） ：知識 品質基準やKPI測定の方法など、具体的な知識を浸透させます。 軽量な品質基準の策定し、テストカバレッジ、コードレビュー実施率など、導入ハードルの低い指標からスタート プロジェクト管理ツールに「バグ起票ルール」や「優先度付け方法」をまとめ、誰でも確認できる状態を整える A（Ability） ：能力 実際の開発現場で運用できるよう、チームに必要な技術を身につけてもらいます。 デプロイ時に自動テストが実行されるようにするなど、開発フローを大幅に変えずに品質管理を自然に取り込める仕組みを整える コードレビューの基準化を進め、チェックリスト形式で「レビューすべきポイント」を定義するなど、担当者の迷いを軽減、レビュー工数が増えすぎるリスクを抑える R（Reinforcement） ：定着 最後に、成果を振り返り、チーム文化として定着させます。 バグ発生率の変化やテストカバレッジの推移を週次やスプリント末に確認し、チームで議論 良い変化があれば称賛し、継続的な振り返りと改善を重ねて開発文化として定着させる 成功のポイント 大きな変革は小さく始める いきなり品質基準を厳しくするのではなく、テストカバレッジやコードレビューの導入など、小さいステップから取り入れる 品質管理の形骸化を防ぐ 「テストカバレッジ100％」を目指すことが目的ではなく、「実際の品質向上」を重視するという意識づけを行う 成功事例をチーム全体で共有 不具合の減少や長期的な工数削減のデータを共有し、品質管理のメリットを実感してもらう ケース2：第三者検証のテスト工程にAIベースのテスト支援を導入 第三者検証へのAI導入も考えてみます。 AI導入時の典型的な課題 第三者検証企業におけるテスト工程にAIベースのテスト支援を導入する際は、技術的ハードルに加えて、顧客や現場の理解を得る必要があります。具体的には、以下のような点が課題となりがちです。 AIによるテストケース生成の妥当性 顧客が「本当に十分な品質が担保できるのか？」と懐疑的 不具合起票の一貫性 AIが自動で発見した不具合と、テストエンジニアが手動で発見した不具合の整合性をどう確保するか 現場エンジニアの抵抗感 「AIに仕事を奪われるのでは？」という誤解や、新ツール学習への負荷 ADKAR＋ Kotter で見る導入プロセスの一例 AI導入時は、個人の変革を促すADKARモデルに加え、組織全体の変革を推進するコッターの視点が役立ちます。 危機感を高める ：Kotter Stage 1 人手不足や工期短縮要請など、従来のやり方では対応が難しい現状を明示 Awareness（認識） ：ADKAR AI導入の必要性をデータで裏付ける（例えば、テストケース自動生成やテストの自動実行で〇％の工数削減見込み） 強力な連帯を築く ：Kotter Stage 2 開発チームに加え、営業やカスタマーサポートも含めた横断的なチームを編成し、導入をリードする Desire（欲求） ：ADKAR 「AIがルーティン作業を担うことで、テストエンジニアはより高度なテスト設計に集中できる」というメリットを明確に示す Knowledge（知識） ：ADKAR AIによるテストケース生成の仕組みや、誤評価・評価漏れリスクの対処方法を従来のテストと比較し、社内勉強会で共有 短期的な成功を生み出す ：Kotter Stage 6 一部プロジェクトでPoC（概念実証）を実施し、バグ検知率の向上や工数削減といった成功データを取得する Ability（能力） ：ADKAR PoCで得たノウハウを手順化し、マニュアルや動画チュートリアルを整備 Reinforcement（定着） ：ADKAR 成果を関係者全体で評価し、顧客への提案資料に活用する 組織全体でAIベースのテスト支援に対する理解を深め、現場での定着を図る 変化を定着させる ：Kotter Stage 8 組織として「AI活用」を当たり前の体制にし、人事評価やプロジェクト計画書にAI活用を織り込む リスク管理と成功のポイント 顧客とのコミュニケーションを強化 AIがどの範囲まで自動化し、どこから人が判断するのかを、契約時やテスト計画の段階で明確にし、関係者間で合意形成しておく PoC→段階的導入→水平展開 まずは限定的なプロジェクトで導入し、成功を確認。その後、他のプロジェクトへ段階的に展開する 透明性と説明責任 AIが生成したテストケースや不具合起票の根拠を説明できる仕組みがあると、顧客が安心しやすい まとめ 変革＝ツール導入だけではない 技術導入の成否は「ツールそのものの優秀さ」だけでなく、人や組織がどう変わるかにかかっている 小さな成功体験の積み重ねがカギ まずは限定的な範囲で導入し、成功体験を積み上げることで、チーム全体のモチベーションを高めながら定着を促す “なぜ今この変革が必要なのか”を共有する 関係者全員が納得できる理由を明確にし、データや事例を活用して効果を示すことで、チェンジマネジメントをスムーズに進められる チェンジマネジメントの本質は、「人の意識と行動をいかに変えるか」にあります。スタートアップの品質管理導入からAIベースのテスト支援の活用まで、ADKARモデルやKotterの8段階プロセスといった理論を適切に応用することで、変革の成功率を大きく高めることができます。 本記事が、チェンジマネジメントを進める際のヒントとなり、少しでもお役に立てれば幸いです。 #チェンジマネジメント #ADKAR #Kotter #アジャイル #品質管理 #AIテスト The post チェンジマネジメントで変革を加速！ADKAR×Kotterで実現するアジャイル品質管理とAIテスト導入 first appeared on Sqripts .

こんにちわ。GS です。 今回は、playwright-mcp を駆使して、AI を活用したソフトウェアテストの設計から実行、結果の出力に至るまでの様々な工程の自動化を試みていきます。 キーとなる技術は、 MCP Playwright Aria snapshots LLM の3つです。 前知識 まずは今回使用する技術や概念について説明します。 MCP（model context protocol）とは MCP は「Model Context Protocol」の略で、AI モデル（LLM）が外部のデータソースやツールと通信するための標準化されたプロトコルです。 MCP をわかりやすく説明すると MCP は、「AI のための USB-C」のようなものと考えてください。 例えば、あなたが持っている様々な家電（テレビ、スピーカー、照明、コーヒーマシンなど）を 1 つのリモコンで操作できるユニバーサルリモコンをイメージしてください。MCP は AI アシスタントにとってのそのユニバーサルリモコンです。 従来、AI モデル（ChatGPT、Claude、LLaMA など）が外部のシステム（データベース、API、社内文書など）と連携するには、それぞれのシステムごとに専用の接続方法を開発する必要がありました。これは、テレビ、エアコン、照明器具などにそれぞれ別のリモコンが必要なようなものです。 MCP はこの問題を解決し、AI モデルと外部ツールの間の「共通言語」を提供します。これにより： 開発者は各 AI モデルと外部ツールの組み合わせごとに独自の連携方法を作る必要がなくなります ユーザーは AI アシスタントに「今日のサンフランシスコの天気は？」と聞くだけで、AI が適切な外部ツールを使って最新情報を取得できます 新しいツールやデータソースを簡単に AI システムに追加できるようになります 2024 年末に Anthropic によって公開された MCP は、オープンスタンダードとして急速に普及し、多くの開発者がさまざまなツールやサービスと AI を連携させるためのサーバーを開発しています。 Playwright とは Playwright は、Microsoft が開発したブラウザ自動化ツールです。 簡単に言うと、人間がブラウザで行う操作（ウェブサイトを開く、ボタンをクリックする、テキストを入力するなど）をコンピュータが自動的に行えるようにするソフトウェアです。 例えば、オンラインショッピングサイトで商品を検索したり、フォームに情報を入力したり、ログインしたりといった作業を、人間が手動でやる代わりに自動的に実行できます。 これは特にウェブサイトのテストや、繰り返し行う作業の自動化に役立ちます。 playwright-mcp とは playwright-mcp は、Microsoft の Playwright チームが開発した MCP（Model Context Protocol）サーバーで、AI アシスタントがウェブブラウザを操作できるようにするツールです。このサーバーは、構造化されたアクセシビリティスナップショットを通じてウェブページとの対話を可能にし、スクリーンショットや視覚ベースのモデルを必要としない特徴があります。 playwright-mcp の主な機能 playwright-mcp の主な特徴は以下の通りです： 高速で軽量 ：Playwright のアクセシビリティツリーを使用し、ピクセルベースの入力に依存しません LLM フレンドリー ：視覚モデルを必要とせず、純粋に構造化データで動作します 決定論的なツール適用 ：スクリーンショットベースのアプローチでよくある曖昧さを回避します playwright-mcp を使用すると、AI アシスタント（Claude や GPT-4 など）は以下のようなウェブブラウザの操作を行うことができます： ウェブページの閲覧・ナビゲーション テキスト入力やボタンのクリック ページ内の要素の検索と情報取得 フォームの入力と送信 構造化されたコンテンツからのデータ抽出 Aria Snapshot とは Aria Snapshot は、Playwright が提供するウェブページのアクセシビリティ構造をテストするための機能です。この機能は、HTML の構造をアクセシビリティツリーの YAML 表現として提供し、ページの状態を検証するために使用されます。 特徴 アクセシビリティツリーの表現 ： Aria Snapshot は、DOM の構造ではなく、アクセシビリティツリーを基にしています。これには要素の役割、名前、状態などの情報が含まれます。 YAML 形式 ： スナップショットは YAML 形式で表現され、人間にも読みやすい形式で保存されます。 柔軟な比較 ： 部分的なマッチングや正規表現を使用した比較が可能で、動的なコンテンツにも対応できます。 強み リファクタリング耐性 ： DOM の内部構造が変更されても、アクセシビリティツリーは変わりにくいため、リファクタリングに強いテストが可能です。 アクセシビリティの検証 ： アクセシビリティの観点からページ構造を検証できるため、支援技術との互換性を確保しやすくなります。 視覚に依存しないテスト ： 見た目ではなく、構造的な変更を検出できるため、CSS の変更などに影響されにくいテストが可能です[1]。 弱み 詳細な視覚的テストには不向き ： レイアウトや色などの視覚的な要素のテストには適していません。 学習コスト ： アクセシビリティツリーの概念を理解する必要があり、初心者には難しい場合があります。 他の技術との違い 従来の DOM スナップショットとの違い ： DOM の構造ではなく、アクセシビリティツリーを比較するため、内部実装の変更に強いテストが可能です。 ビジュアルリグレッションテストとの違い ： 視覚的な差異ではなく、構造的な差異を検出するため、異なる目的で使用されます。 YAML 表現の例 以下は、シンプルな HTML とそれに対応する Aria Snapshot（YAML 表現）の例です： HTML: <nav> <ul> <li><a href="/">ホーム</a></li> <li><a href="/about">概要</a></li> <li><a href="/contact">お問い合わせ</a></li> </ul> </nav> Aria Snapshot（YAML 表現）: - navigation: - list: - listitem: - link "ホーム" - listitem: - link "概要" - listitem: - link "お問い合わせ" この例では、ナビゲーション構造がアクセシビリティツリーとして表現されており、各要素の役割と名前が明確に示されています。 playwright-mcp での活用 playwright-mcp では、この Aria snapshots を活用することで、AI アシスタントがウェブページの構造を理解し、適切な操作を行うことができます。視覚的な情報に依存せず、構造化されたデータのみを使用するため、軽量かつ高速な処理が可能になり、テキストベースの LLM でも効果的にウェブブラウザを操作できるという大きな利点があります。 使用例 playwright-mcp の典型的な使用例には以下のようなものがあります： ウェブナビゲーションとフォーム入力 構造化されたコンテンツからのデータ抽出 LLM による自動テスト エージェントのための汎用ブラウザ操作 バックグラウンドまたはバッチ操作（ヘッドレスモード） 導入方法 playwright-mcp は、npm 経由で簡単に導入できます。以下は基本的な設定例です： { "mcpServers": { "playwright": { "command": "npx", "args": ["@playwright/mcp@latest"] } } } ヘッドレスモード（GUI なしのブラウザ）で実行する場合は以下のように設定します： { "mcpServers": { "playwright": { "command": "npx", "args": ["@playwright/mcp@latest", "--headless"] } } } 実行前準備 MCP サーバーを起動する方法は色々ありますが、今回使用する playwright-mcp サーバーをローカルの Node.js を使用して起動してみます。 Node.js そのもののインストール方法についての詳しい説明は割愛します。ちなみに筆者は Windows も Mac も mise を使ってインストールしています。 mise use -g node@lts npx コマンドの確認 Node.js がインストールされていれば、以下のコマンドで npx コマンドが使用できるはずです。 npx --version npx コマンドのパス確認 npx コマンドのパスを確認します。 Mac の場合 which npx Windows の場合 where npx 操作ツール MCP サーバーを呼び出せるツールなら何でもいいのですが、今回は  Claude のデスクトップアプリ  を使ってみます。 Claude Desktop の設定画面より、構成を編集を押します。 claude_desktop_config.json をお好きなエディタで開きましょう。 開いたファイルに以下の内容を追記します。今回設定する MCP サーバーは、アクセシビリティスナップショットを用いて操作をおこなう MCP サーバーです。 { "mcpServers": { "playwright": { "command": "npx", "args": ["@playwright/mcp@latest"] } } } 設定が完了したら、Claude Desktop を再起動します。 正しく設定されていると、以下のように MCP サーバーが追加されているのが確認できるはずです。 設定がうまくいかない場合、command の部分をフルパスにすることで解消する可能性があります。 たとえば mise を使ってインストールした Node.js に付随する npx コマンドのパスは Mac の場合 "command": "/Users/{ユーザー名}/.local/share/mise/installs/node/22.14.0/bin/npx" Windows の場合 "command": "C:\Users\{ユーザー名}\scoop\apps\mise\current\mise\installs\node\22.14.0\npx.cmd" のようなパスになります。  ●ヒント MCP を使える MCP クライアントにはどんなものがある？ ・ Visual Studio Code ・ Cursor ・ Visual Studio Code や Cursor で使える拡張機能の一つである Cline ・ 自作した MCP クライアント など様々な選択肢があります。 playwright-mcp の実行 実際に実行して、様々な動作を確認しながら、テストに活用できる具体例を紹介します。 MCP サーバーに実行してほしい操作を伝えると、指示通りに実行されます。 実行時には、「この操作を本当に実行してもよいですか？」といった確認メッセージが表示されることがあります。 「このチャットで許可」を選択すると、同じ種類の操作については以降確認なしで自動的に実行されるようになります。 ウェブサイトの構造を確認してみよう まずは MCP サーバーにウェブサイトの構造を確認してもらい、正しく動作していることを確認してみましょう。 以降 Web サイトに対する操作は、弊社サイト「 Sqripts 」を対象とします。 以下の命令を与えると、サイトの構造を tree コマンド形式で出力してくれます。 https://sqripts.com このサイトの構造をtreeコマンド形式で出力してください。 このように、サイトの構造を tree コマンド形式で出力してくれます。 テストケースを生成してみよう サイトの構造を確認したところで、テストケースを生成してみましょう。 今回はトップページ だけ のテストケースを生成してみます。 https://sqripts.com このページの内容から、このページのためのテストケースを生成してください。 以下が実際に生成されたテストケースのマークダウンです。 # Sqripts.com のテストケース ## 1. ナビゲーションとリンクテスト |ID|テスト項目|前提条件|テスト手順|期待結果| |---|---|---|---|---| |1.1|ヘッダーナビゲーションリンクの動作確認|Sqripts.comのトップページにアクセスする|1. 各ナビゲーションリンク（テクノロジー、品質、エンジニアリング、スクリプター、特集、ニュース、資料ダウンロード、Sqriptsについて）をクリックする|各リンクをクリックすると対応するページに正しく遷移する| |1.2|「新規登録・ログイン」リンクの動作確認|Sqripts.comのトップページにアクセスする|1. 「新規登録・ログイン」リンクをクリックする|ログインページに正しく遷移する| |1.3|フッターリンクの動作確認|Sqripts.comのトップページにアクセスする|1. フッター内の全てのリンクを一つずつクリックする|各リンクが正しく対応するページに遷移する| |1.4|記事カテゴリタグリンクの動作確認|任意の記事ページを開く|1. 記事に付与されているカテゴリタグ（品質、エンジニアリング、ソフトウェアテストなど）をクリックする|対応するカテゴリページに正しく遷移する| ## 2. コンテンツ表示テスト |ID|テスト項目|前提条件|テスト手順|期待結果| |---|---|---|---|---| |2.1|おすすめ記事セクションの表示確認|Sqripts.comのトップページにアクセスする|1. 「RECOMMEND おすすめ記事」セクションを確認する|おすすめ記事が正しく表示され、タイトル、日付、カテゴリ、著者情報が表示されている| |2.2|最新記事セクションの表示確認|Sqripts.comのトップページにアクセスする|1. 「LATEST 最新記事」セクションを確認する<br>2. 複数の記事が表示されていることを確認する|複数の最新記事がサムネイル画像、タイトル、日付、カテゴリ、著者情報と共に表示されている| |2.3|ランキングセクションの表示確認|Sqripts.comのトップページにアクセスする|1. 「RANKING アクセスランキング」セクションを確認する|人気記事が順位付けされて表示されている| |2.4|著者情報の表示確認|任意の記事ページを開く|1. 記事内の著者情報（名前、画像）を確認する|著者の名前と画像が正しく表示されている| |2.5|記事本文の表示確認|任意の記事ページを開く|1. 記事のタイトル、日付、カテゴリ、本文を確認する|記事の全コンテンツが正しく表示されている| ## 3. 機能テスト |ID|テスト項目|前提条件|テスト手順|期待結果| |---|---|---|---|---| |3.1|「もっと見る」ボタンの動作確認|Sqripts.comのトップページにアクセスする|1. 最新記事セクション下部の「もっと見る」リンクをクリックする|記事一覧ページに正しく遷移し、より多くの記事が表示される| |3.2|タグによる記事絞り込み機能確認|Sqripts.comのトップページにアクセスする|1. 「#TAGS 人気のタグ」セクションから任意のタグ（例：「AI」「ソフトウェアテスト」）をクリックする|選択したタグに関連する記事のみが表示されるページに遷移する| |3.3|イベント・ニュースバナーの確認|Sqripts.comのトップページにアクセスする|1. 「EVENT・NEWS」セクションのバナーをクリックする|バナーに対応するイベントページやニュースページに正しく遷移する| ## 4. レスポンシブデザインテスト |ID|テスト項目|前提条件|テスト手順|期待結果| |---|---|---|---|---| |4.1|モバイル表示確認|モバイルデバイスまたはブラウザの開発者ツールでモバイル表示を有効にする|1. Sqripts.comのトップページを表示する<br>2. 画面をスクロールし、各セクションの表示を確認する|全てのコンテンツがモバイル画面に適切に表示され、レイアウトが崩れない| |4.2|タブレット表示確認|タブレットデバイスまたはブラウザの開発者ツールでタブレット表示を有効にする|1. Sqripts.comのトップページを表示する<br>2. 画面をスクロールし、各セクションの表示を確認する|全てのコンテンツがタブレット画面に適切に表示され、レイアウトが崩れない| |4.3|画面回転時の表示確認|モバイルデバイスまたはブラウザの開発者ツールでモバイル表示を有効にする|1. Sqripts.comのトップページを表示する<br>2. 画面を横向きに回転させる|横向き表示でもコンテンツが適切に表示される| ## 5. パフォーマンステスト |ID|テスト項目|前提条件|テスト手順|期待結果| |---|---|---|---|---| |5.1|トップページの読み込み速度確認|ブラウザの開発者ツールを開く|1. 開発者ツールのNetworkタブを有効にする<br>2. Sqripts.comのトップページをリロードする<br>3. 読み込み完了時間を確認する|ページの読み込み時間が3秒以内である| |5.2|画像の最適化確認|ブラウザの開発者ツールを開く|1. 開発者ツールのNetworkタブを有効にする<br>2. Sqripts.comのトップページをリロードする<br>3. 画像ファイルのサイズを確認する|画像が適切に最適化されており、大きなファイルサイズの画像がない| |5.3|記事ページの読み込み速度確認|ブラウザの開発者ツールを開く|1. 開発者ツールのNetworkタブを有効にする<br>2. 任意の記事ページを開く<br>3. 読み込み完了時間を確認する|記事ページの読み込み時間が3秒以内である| ## 6. 機能性テスト |ID|テスト項目|前提条件|テスト手順|期待結果| |---|---|---|---|---| |6.1|検索機能の動作確認|Sqripts.comのトップページにアクセスする|1. 検索ボックスにキーワード（例：「テスト自動化」）を入力する<br>2. 検索を実行する|入力したキーワードに関連する記事が検索結果に表示される| |6.2|新規登録機能の確認|「新規登録・ログイン」ページにアクセスする|1. 新規登録に必要な情報を入力する<br>2. 登録ボタンをクリックする|アカウントが正常に作成され、ログイン状態となる| |6.3|ログイン機能の確認|「新規登録・ログイン」ページにアクセスする|1. 既存アカウントの情報を入力する<br>2. ログインボタンをクリックする|正常にログインでき、ログイン状態となる| ## 7. アクセシビリティテスト |ID|テスト項目|前提条件|テスト手順|期待結果| |---|---|---|---|---| |7.1|画像の代替テキスト確認|ブラウザの開発者ツールを開く|1. トップページの画像要素を検査する<br>2. alt属性の値を確認する|全ての重要な画像に適切な代替テキストが設定されている| |7.2|キーボードナビゲーション確認|Sqripts.comのトップページにアクセスする|1. マウスを使用せず、Tabキーのみでページ内を移動する<br>2. Enterキーでリンクを開く|キーボードのみでページのすべての機能にアクセスできる| |7.3|フォントサイズの変更確認|Sqripts.comのトップページにアクセスする|1. ブラウザの設定でフォントサイズを大きくする（Ctrl + または Cmd +）|コンテンツが読みやすく表示され、レイアウトが崩れない| ## 8. セキュリティテスト |ID|テスト項目|前提条件|テスト手順|期待結果| |---|---|---|---|---| |8.1|HTTPSプロトコルの確認|ブラウザでSqripts.comにアクセスする|1. URLバーの鍵アイコンを確認する|サイトがHTTPSで保護されている| |8.2|パスワード強度の確認|「新規登録・ログイン」ページにアクセスする|1. 新規登録フォームで弱いパスワードを入力する|強度が不足しているパスワードを拒否または警告が表示される| ## 9. クロスブラウザテスト | ID | テスト項目 | 前提条件 | テスト手順 | 期待結果 | | --- | ------------ | ---------------------- | ------------------------------------------------------------------------- | ---------------------- | | 9.1 | Chrome互換性確認 | Google Chromeブラウザを起動する | 1. Sqripts.comのトップページにアクセスする<br>2. 各セクションの表示を確認する<br>3. リンクをクリックして動作を確認する | すべての機能とデザインが正常に表示・動作する | | 9.2 | Firefox互換性確認 | Firefoxブラウザを起動する | 1. Sqripts.comのトップページにアクセスする<br>2. 各セクションの表示を確認する<br>3. リンクをクリックして動作を確認する | すべての機能とデザインが正常に表示・動作する | | 9.3 | Safari互換性確認 | Safariブラウザを起動する | 1. Sqripts.comのトップページにアクセスする<br>2. 各セクションの表示を確認する<br>3. リンクをクリックして動作を確認する | すべての機能とデザインが正常に表示・動作する | このように、AI がテストケースを自動生成してくれました。 今回はあえて簡潔な指示だけで生成してみましたが、より具体的なテストケースが必要な場合は、テスト観点や重要なポイントを詳細に入力することで、それらの指示に沿ったテストケースを生成できます。 要件定義書や基本設計書、詳細設計書などを入力し、適切なプロンプトを与えれば、対象画面と設計書の仕様を照合したテストケースを生成することも可能です。 生成されたテストケースに修正や追加が必要な場合は、具体的な指示を入力するだけで、AI が修正や加筆を行ってくれます。 テストケースを実行してみよう 生成されたテストケースを元に、テストを実行していきます。しかし単純に実行するだけでは、テストの再利用性が確保できません。 そこで、テストを実行しながら、同時にそのテストを再利用可能な形式でアウトプットする方法を検討しました。 今回は、playwright-mcp で実施されているテストを、TypeScript + Playwright コードとして出力することにします。 以下は使用したプロンプトです。 「1.1ヘッダーナビゲーションリンクの動作確認」のテストをplaywrightで操作して実行し、その実行した手順をtypescript + playwrightコードとしてまとめ、最終レポートにテスト結果と、そのテストを再現できるまとめたコードをレポートとして出力してください。 今回の例では、元となるテストケースの抽象度が高く、そのままではテスト実行が困難でしたが、 実行過程でより具体的なテストケースが自動生成 され、同時にテスト実行も完了してレポートが作成されました。 この結果から、「テストケースを抽象から具象（ステップ）へと変換する」能力が明確に見て取れ、さらに実際の実行までを一貫して行える点が、このテストケース生成システムの大きな強みだと言えます。 もちろん、すべての状況でこれが最適解というわけではなく、ケースによっては適していない場合もあるでしょう。 しかし、このようなテストケース生成システムは、効率的かつ効果的なテスト設計において非常に価値のある強力なツールであることは間違いありません。 作成されたテストコードを実行してみよう 以下が作成されたテストコードです。 このテストコードでは、スクリーンショットを取得していますが、スクリーンショット名にユニーク性がないため、複数のブラウザで実行した場合、後から実行したブラウザのスクリーンショットで上書きされてしまう問題があります。 この問題を解決するため、スクリーンショット名にユニークな値を含めるように修正しました。 また、ファイル名がテストファイルの命名規則に沿っていなかったため、適切な名称に変更しました。 // navigation.spec.ts - Sqripts.comヘッダーナビゲーションリンクのテスト import { test, expect } from "@playwright/test"; test("1.1 ヘッダーナビゲーションリンクの動作確認", async ({ page }) => { // ナビゲーションリンクとその期待されるURLを定義 const navLinks = [ { name: "テクノロジー", url: "https://sqripts.com/category/technology/" }, { name: "品質", url: "https://sqripts.com/category/quality/" }, { name: "エンジニアリング", url: "https://sqripts.com/category/engineering/", }, { name: "スクリプター", url: "https://sqripts.com/writer/" }, { name: "特集", url: "https://sqripts.com/feature/" }, { name: "ニュース", url: "https://sqripts.com/news/" }, { name: "資料ダウンロード", url: "/document/" }, { name: "Sqriptsについて", url: "https://sqripts.com/about/" }, ]; // テスト結果を保存する配列 const results = []; // テスト開始時刻を記録 const startTime = new Date(); console.log(`テスト開始: ${startTime.toLocaleString()}`); try { // ホームページに移動 console.log("Sqripts.comに移動中..."); await page.goto("https://sqripts.com/"); await page.waitForLoadState("domcontentloaded"); console.log("ホームページのスクリーンショットを取得"); await page.screenshot({ path: "./screenshots/homepage.png" }); // 各ナビゲーションリンクをテスト for (const link of navLinks) { try { console.log(`ナビゲーションリンクをテスト中: ${link.name}`); // ナビゲーションリンクを見つけてクリック // ナビゲーションは通常、HTMLではnavタグに含まれているため、このセレクタを使用 const linkElement = await page .locator(`nav >> text="${link.name}"`) .first(); // クリック前にスクロールして要素を表示 await linkElement.scrollIntoViewIfNeeded(); // リンク要素がクリック可能かどうかを確認 await expect(linkElement).toBeVisible(); await expect(linkElement).toBeEnabled(); // リンク要素をクリック await linkElement.click(); // ページ遷移の完了を待機 await page.waitForLoadState("networkidle"); // 現在のURLを取得 const currentUrl = page.url(); // 遷移先ページのスクリーンショットを保存 await page.screenshot({ path: `./screenshots/${link.name}-page.png` }); // 期待されるURLに遷移したかどうかを確認 // 相対URLの場合はベースURLを考慮する const expectedUrl = link.url.startsWith("http") ? link.url : `https://sqripts.com${link.url}`; const passed = currentUrl === expectedUrl || currentUrl.includes(link.url); // テスト結果を保存 results.push({ link: link.name, expectedUrl: expectedUrl, actualUrl: currentUrl, passed, }); // コンソールにテスト結果を出力 if (passed) { console.log(`✅ ${currentUrl} に正常に遷移しました`); } else { console.log( `❌ 遷移に失敗しました。期待値: ${expectedUrl}, 実際: ${currentUrl}` ); } // 次のテストのためにホームページに戻る await page.goto("https://sqripts.com/"); await page.waitForLoadState("domcontentloaded"); } catch (error) { console.error(`エラー発生 ${link.name}のテスト中: ${error}`); results.push({ link: link.name, expectedUrl: link.url, actualUrl: "Error", passed: false, error: error.toString(), }); } } } catch (error) { console.error(`ホームページへの移動に失敗: ${error}`); } // テスト終了時刻を記録 const endTime = new Date(); const testDuration = (endTime.getTime() - startTime.getTime()) / 1000; console.log(`テスト終了: ${endTime.toLocaleString()}`); console.log(`テスト所要時間: ${testDuration}秒`); // テスト結果レポートを生成 let passCount = 0; let failCount = 0; console.log("\n========== テスト結果レポート =========="); console.log("ヘッダーナビゲーションリンクテスト結果:"); console.log("==================================="); for (const result of results) { if (result.passed) { passCount++; console.log(`✅ ${result.link}: 成功`); console.log(` 期待値: ${result.expectedUrl}`); console.log(` 実際: ${result.actualUrl}`); } else { failCount++; console.log(`❌ ${result.link}: 失敗`); console.log(` 期待値: ${result.expectedUrl}`); console.log(` 実際: ${result.actualUrl}`); if (result.error) { console.log(` エラー: ${result.error}`); } } console.log("-----------------------------------"); } console.log(`\n概要: ${passCount}成功, ${failCount}失敗`); console.log("==================================="); // すべてのナビゲーションリンクが正常に動作したことを検証 expect(failCount).toBe(0); }); テストコードを動かすための設定ファイルです。 こちらは自動出力されたものをそのまま使用しています。 この設定は Chromium、Firefox、Webkit の 3 つのブラウザ（エンジン）で実行するように最初から設定されていました。 // playwright.config.ts - Playwrightの設定ファイル import { PlaywrightTestConfig } from "@playwright/test"; const config: PlaywrightTestConfig = { testDir: "./tests", timeout: 60000, // タイムアウトを60秒に設定 reporter: [ ["html"], // HTMLレポートを生成 ["list"], // コンソールに結果リストを表示 ["json", { outputFile: "test-results.json" }], // JSON形式のレポートも生成 ], use: { // ブラウザの設定 headless: false, // テスト実行時にブラウザを表示（視覚的に確認するため） viewport: { width: 1280, height: 720 }, // ブラウザのビューポートサイズ ignoreHTTPSErrors: true, // HTTPS証明書エラーを無視 screenshot: "only-on-failure", // 失敗時のみスクリーンショットを撮影 video: "on-first-retry", // 最初の再試行時にビデオを記録 trace: "on-first-retry", // 最初の再試行時にトレースを記録 // アクションのタイムアウト設定 actionTimeout: 10000, // アクション（クリックなど）のタイムアウトを10秒に設定 navigationTimeout: 15000, // ナビゲーション（ページ遷移）のタイムアウトを15秒に設定 }, // 並列実行の設定 workers: 1, // シーケンシャルにテストを実行（ナビゲーションテストの場合は順序が重要） // プロジェクト固有の設定 projects: [ { name: "chromium", use: { browserName: "chromium" }, }, { name: "firefox", use: { browserName: "firefox" }, }, { name: "webkit", use: { browserName: "webkit" }, }, ], // フォルダ構造の設定 outputDir: "test-results/", // テスト結果の出力ディレクトリ }; export default config; 以下のコマンドを実行してテスト環境を構築しましょう。 macOS の場合 # 新しいディレクトリを作成 mkdir sqripts-test cd sqripts-test # npm プロジェクトを初期化 npm init -y # Playwright をインストール npm install -D @playwright/test # Playwright ブラウザをインストール npx playwright install # スクリーンショットを保存するディレクトリを作成 mkdir screenshots mkdir tests touch tests/navigation.spec.ts touch playwright.config.ts Windows の場合 # 新しいディレクトリを作成 mkdir sqripts-test cd sqripts-test # npm プロジェクトを初期化 npm init -y # Playwright をインストール npm install -D @playwright/test # Playwright ブラウザをインストール npx playwright install # スクリーンショットを保存するディレクトリを作成 mkdir screenshots # テストディレクトリとファイルを作成 mkdir tests New-Item -Path tests/navigation.spec.ts -ItemType File New-Item -Path playwright.config.ts -ItemType File tests/navigation.spec.ts と playwright.config.ts ファイルに、それぞれ上記のコードを記載しました。 最後にテストを実行してみます。 npx playwright test ブラウザごとにテストが正常に実行されていることが確認できます。 WebKit はヘッドレスモードで動作しているようです（他のウィンドウの背後に隠れている可能性もあります）が、その他のブラウザは問題なく動作しています。 すべてのブラウザのスクリーンショットは screenshots フォルダに正しく保存されています。 ちなみに今回のテスト動画をよく見ると、Firefox では途中からレイアウトが崩れている箇所があります。 今回のテストケースにはレイアウトのテストが含まれていないため問題なく成功していますが、レイアウトに関するテストケースを作成する場合は、視覚的な検証を行うことでこのような問題を検出できるでしょう。 視覚的な検証を行うには、単純に考えると playwright-mcp サーバーを ビジョンモード で動作させる必要があるでしょう。 ただし、今回のテストのように途中でスクリーンショットを撮影している場合は、これらのスクリーンショットを LLM に渡すことでもレイアウトの検証が可能かもしれません。 まとめ playwright-mcp を使って テストケースを生成 テストケースの具象化（ステップ化） テストケースを実行 テストケースを再利用可能な形式で出力 テストの再実行 結果レポートの生成 これらの機能を活用し、AI を用いたソフトウェアテストを実施しました。 さらに別の技術やMCP、ソフトウェアに関するドキュメントと組み合わせれば テスト結果から仕様書の記載漏れを検出 テスト結果と仕様書を突き合わせて想定外の仕様を検出 NGテストとGithub MCPを組み合わせて不具合箇所を特定 テスト結果に基づく改善点をGithub MCPと連携してリファクタリングを実施 などの様々な活用方法が考えられます。 実際、これらの機能を提供しているプロダクトやサービスはすでに登場しています。 人の手で行わなければならない作業は確実に減少しています。今回紹介した例は単体タスクの依頼であり、自律的なエージェントはまだ登場していません。 しかし、十分な精度を持つ自律型エージェントが登場すれば、人間が行うべき作業は限りなく0に近づいていくでしょう。 1年後にはどのようなソフトウェアテストが可能になっているでしょうか。 1年と言わずとも、わずか1〜2ヶ月で技術が劇的に進化する可能性もあります。 そのような変化が起きた際には、また新たな記事でご紹介したいと思います。  The post 【自動化】playwright-mcpを駆使し、ソフトウェアテストの設計から実行、テスト結果の出力までの自動化を試みる first appeared on Sqripts .

帰納的な推論 と 発見的な推論(アブダクション) は、 私たちがソフトウェア開発の現場/実務で（知らず知らずにでも）駆使している思考の形です（それどころか日々の暮らしでも使っています）。 それほど“自然な”思考の形ですが、どんな考え方で、どんなところに注意すると質の高い思考ができるのか、基本知識を押さえておくと実務のレベルアップにつながります。 ＜実務三年目からの発見力と仮説力　記事一覧＞ ※クリックで開きます 【第1回】見つけるための論理【連載初回、全文公開中】 【第2回】 “共通項”を見つけ出す 【第3回】発見はよい観察とよい方法から 【第4回】帰納の仲間と落とし穴 -前編- 前編では「帰納的推論で気をつけたい落とし穴」についてお伝えしました。 後編となる今回は「帰納的推論の仲間」（ 第2回 の続き）です。 帰納の仲間たち 帰納的な推論には 第2回 で紹介したものの他にも仲間がいます。 ここではふたつ、 類推(類比的推論) と 既知の因果関係を用いた推論 を紹介します。 （実は、どちらもこれまでの記事の中でさりげなく活躍しています……） 類推（類比的推論） 「あるものごとを他のものごとになぞらえて、共通項を見出す」「あるものごとと他のものごととの類似点を見つけ、一般化する」 といった思考の形は 類推 、 類比的推論 と呼ばれます。 有限の事例の列挙から共通項を見出し、対象全体に一般化する点で、これも帰納的な推論の仲間と言えます。 類推の形には2種類あります。 事例群αに見出された共通点を、別の事例群βの中に見出す(推論する)形 （本記事内独自の呼称として、“タイプA”と呼びます） 事例群αとβとの類似性を基に、新たな共通点を見出す(推論する)形 （本記事内独自の呼称として、“タイプB”と呼びます） 図4-4 類比的推論のふたつの形 “タイプA”では、 ①ある事例群αにおける共通項(属性/特徴/etc.)から、 ②同じ共通項を持つ別の事例群βでも同じことが言えるだろう、 と推論しています。 この形はこれまでも本連載の中でひそかに出てきています。 「ソフトウェアZがプリインストールされているスマートフォンで故障Fが起こる」では、「故障Fが起こるスマートフォンの特徴」「起こらないスマートフォンの特徴」を仕分ける際に、「同じ特徴を持っているなら、同じ故障が起こるのでは」という見方をしています。 “タイプB”はちょっと込み入っていますが、 ①ふたつの事例群α, βに共通項を見出し、 ②事例群αに新たに発見された属性/特徴に対して、 ③ 似ている 事例群βにも 同じ属性/特徴 が見られるだろう（共通項が増えるだろう）、 と推論しています。 図4-5 “タイプB”の推論の構造 類推をする上での 注意点 は、 ふたつの事例群間の共通項が多いほど、推論の蓋然性は高くなります。 既知の共通項と、新たに加わる共通項との関連が密接であるほど、蓋然性は高くなります。 図4-4の“タイプA”の例で、ソフトウェアYとZの共通項は、単に「同じようなサービスを提供する」だけよりは、「使用するリソース、必要とする権限設定、制御構造など」の類似点が多い方が、「ソフトウェアYでも同じ故障Fが起こる」見込みが高いでしょう。 （といっても、「同じようなサービスを提供する」のような目につく点に着目するのは悪手、ということではありません。調査初期の、手がかりが何もないような状況では、見えやすい類似点から手をつけることはよくあります） “タイプB”の例では、ソフトウェアZとYの共通項と故障Fとの関連が強そうで、故障Gもそれら共通項との関連が強そうなら、「Yでも故障Gが起こる」見込みは高いでしょう。 逆に故障GがZに固有の故障でありそうなら（Z独自の処理や、Zに特有のデータに関わる、etc.)、その見込みは低くなるでしょう。 なお、今回紹介した「帰納的推論の性質に関わる落とし穴」はそのまま類推でも気をつける必要があります。 既知の因果関係を用いた推論 既知の因果関係の知識を手がかりに、起こった事象から原因を（または、先行事象から起こり得る結果を）推論する、というのも一種の類推と言えるでしょう。 （たとえば、電子レンジの原理を知っていれば、実際にレンジ内で“爆発”が起こった時に何が原因か推測が働きやすいでしょうし、ある種の食品を電子レンジで温める際に注意深くなるでしょう） 図4-6 既知の因果関係を使って推論する 「ハードウェアやソフトウェアで起こりがちなトラブルの原因と事象の知識」は、問題発生時の原因の切り分けにも通じますし、エラー推測といったテスト技法とも関わります。仕入れておくに越したことはありません。 ネットワーク機器などのハードウェアで起こるトラブルと、ソフトウェアの実行に及ぼす影響 使用しているOS, ミドルウェア, サーバー等の典型的なトラブルと、それが引き起こす事象 プログラミング言語や処理系に関する知識 etc. なお、既知の因果関係の知識は推論を支えてくれはしますが、状況証拠からの推測である点、やはり蓋然的な推論になります。 事象の原因を説明する仮説 「因果関係の推定に関わる落とし穴」の「早急な特定は禁物」で触れているように、因果関係の推定は簡単にいかない場合も多々あります。 原因らしきものを挙げるにとどまらず、「それが原因だとして、どんな過程でこの結果に至ったのか」を説明する仮説( 説明仮説 )が考えられるとなおよいです。 （類推(類比推論)や既知の因果関係を用いた推論は仮説を考える助けになります） 原因から結果までの過程に矛盾がない、他の事象との整合もとれているような“よい” 説明仮説 は、原因の推定に対する確信を与えてくれますし、原因の特定作業も助けてくれます。 そこで、次回からはよい仮説を考えるためのもうひとつの推論の形である アブダクション を紹介していきます。 参考文献 近藤洋逸, 好並英司 『論理学入門』 岩波書店 1979 鈴木美佐子 『論理的思考の技法Ⅱ』 法学書院 2008 藤野登 『論理学　伝統的形式論理学』 内田老鶴圃 1968 J.S.ミル(著), 大関将一(訳) 『論理学体系 : 論証と帰納 5』 春秋社 1959 T・エドワード・デイマー(著), 小西卓三(監訳), 今村真由子(訳) 『誤謬論入門　優れた議論の実践ガイド』 九夏社 2023 図版に使用した画像の出典 Loose Drawing 人物画をお借りしています。 品質探偵コニャン：Produced by Sqripts . No Unauthorized Reproduction. The post 【第5回】帰納の仲間と落とし穴 -後編-｜実務三年目からの発見力と仮説力 first appeared on Sqripts .

帰納的な推論 と 発見的な推論(アブダクション) は、 私たちがソフトウェア開発の現場/実務で（知らず知らずにでも）駆使している思考の形です（それどころか日々の暮らしでも使っています）。 それほど“自然な”思考の形ですが、どんな考え方で、どんなところに注意すると質の高い思考ができるのか、基本知識を押さえておくと実務のレベルアップにつながります。 ＜実務三年目からの発見力と仮説力　記事一覧＞ ※クリックで開きます 【第1回】見つけるための論理【連載初回、全文公開中】 【第2回】 “共通項”を見つけ出す 【第3回】発見はよい観察とよい方法から 【第4回】帰納の仲間と落とし穴 -前編- 今回のトピックは2つ、前編では「帰納的推論で気をつけたい落とし穴」、そして後編では「帰納的推論の仲間」（ 第2回 の続き）です。 帰納的推論で気をつけたい落とし穴 帰納的な推論にも落とし穴(誤謬)はあります。 見つける共通項が因果関係である場合には、因果関係の推定に関わる落とし穴もあります。 第2回 , 第3回 で説明したことも併せ、改めて今回見ていきましょう。 なお、[ 実践編 ]と同様、以下の点に注意してください。 本記事で紹介しているものがすべてではありません 。 これらの分類は排他的なものではありません。複数の分類に該当する誤りもあります（視点によって分類が変わる）。 複数の誤謬が重複したり関連したりして間違った推論を形づくることもあります。 誤謬の名称は、人により文献によって名称が異なることもあります。 帰納的推論の性質に関わる落とし穴 一般化：標本(サンプル)にまつわる落とし穴 軽率な一般化 、または 不十分な標本 の誤謬。 母集団の規模に対して少な過ぎる事例を基に一般化をしてしまう誤りです。 偏った標本 の誤謬。 数は問題ないとしても、母集団の傾向(属性/特徴の在りよう)を適切に反映できていない事例を基に一般化をしてしまう誤りです。 事例の数が少ない場合は 軽率な一般化 だけでなく 偏った標本 になっていないか気をつける必要があります。 こうしたことは、統計的な推論でなく枚挙的な帰納をする場合でも気をつけたい事柄と言えます。 （参考： 第2回 の図2-1(B)） 図2-1 帰納的な推論(再掲) 帰納的な推論ができそうな場合は、まず、 「事例の数と傾向を把握した上で推測を立てる」ことを意識して、これらの点を確かめましょう。 事例の数は、一般化するには十分そうか？ （推測に合致しそうな事例だけ無意識に集めているということはないか） （数が少ない場合、推論の蓋然性が低い可能性を意識できているか） 事例は偏っていないか？ （推測に合致しそうな事例だけ無意識に注目しているということはないか） （偏りがありそうなら、事例を増やして多様性を増すことはできないか） なお、「事例の数が少ないならば、帰納的推論の蓋然性は低い」、というわけではありません。 母集団の均質性、類似性が高いなら（どれも同じ属性を持っている、どれもみな似通っている、etc.）、事例の数が少なくても結論の蓋然性は見込める場合があります。 一般化：結論の導き方にまつわる落とし穴 事例の数や偏りの点で問題がなくても、共通項から結論を引き出す際の考え方や態度にも落とし穴はあります。 いずれも、共通点/類似点に対して相違点への注目が相対的に弱まってしまうところからはまる落とし穴と言えます。 キャリアX社のAndroidスマートフォンA, B, C, D, Eがあるとして、 (1)共通点や類似点にばかり注意が向いて、 相違点を見落とす 。 「A, B, C, D, EはAndroidスマートフォンだから同じだ」と考える類です。 （ハードウェアスペックもUI回りも違っている、etc.） (2)共通点や類似点と結論する性質との 関連が薄い 。 A, B, C, Dで同じ故障が起こっていることから「Eでも同じ故障が起こるだろう」と考える類です。 （見かけの共通点/類似点に引っ張られて結論に飛びついてしまう、etc.） (3)結論の 蓋然性を過度に見積もる 。 A, B, C, D, Eすべてで試したことから「この故障はすべてのAndroidスマートフォンで起こる」と考える類です。 （事例の多さや傾向の偏りのなさなどから、結論が必ず正しいと考える、etc.） （実は権限設定に問題があり、使用したスマホで同じ権限設定のミスをしていたためだった……などの可能性もあります） 図4-1 枚挙的帰納の落とし穴 統計的帰納で気をつけたいこととしては、 的外れな一般化 といったものがあります。 よく起こりがちなものは、事例の数を割合と同一視してしまう（または置き換えてしまう）、というものです。 第2回 の「A子さんの学校でのいちごフォンユーザーの割合」でいうと、 いちごフォンユーザーの数が多いならば、いちごフォンのハードウェア故障の 件数 も多いのは自然でしょう。 対して、その他のスマートフォンユーザーのハードウェア故障件数は相対的に少ないでしょう。 ここで「いちごフォンはハードウェア故障が多い」と考えるのは、ユーザー数の規模の違いを見ずに、ハードウェア故障の件数を故障を起こす割合と同一視、ないし置き換えて考えてしまっています（「故障件数が多い＝故障の割合が高い」）。 より適切には、いちごフォンとその他のスマートフォンそれぞれのハードウェア故障の割合を比較するべきです。 図4-2 統計的帰納の落とし穴：的外れな一般化 因果関係の推定に関わる落とし穴 因果関係の取り違え 前後即因果 の誤謬。 時系列の前後関係を因果関係と思う 誤りです。 結果画面の表示が崩れた直後にフリーズしたことから、「表示の崩れがフリーズの原因」と考える類です。 この誤りは古くは「『この後に，だからこの故に (post hoc, ergo propter hoc)』の誤謬」と呼ばれていたそうで、昔からありがちな誤りだったのでしょうね。 原因と結果の混同 。 サブシステムAの処理の重さがサブシステムBのデータ転送遅延を引き起こしているのを、「Bの遅延がAの処理の重さの原因」と考える類です。 間違った原因探し   たまたま共存しているだけ の複数の事象の間に因果関係があると考える誤り。 サブシステムAの応答速度の低下とサブシステムBの転送遅延はたまたま同時に起こっていたただけ（互いに何の干渉もしていない）、といった類です。 相互作用の一面だけ見て 因果関係を考えてしまう誤り。 サブシステムAの応答速度の低下がサブシステムBのデータ転送遅延の原因と思ったが、それぞれの故障が互いに影響を与えていた、といった類です。 原因の見逃し 関連する原因の無視/見落とし 。 複数の原因が関連し合って生じている事象に対し(原因の多数性)、 ひとつの原因を特定するに留まり、他の原因を無視/見落としてしまう 誤りです。 取得するデータの間違えと、計算ロジックの誤りと、画面表示の処理の誤りが合併した故障を、計算ロジックの誤りにだけ注目して他を見落としてしまう類です。 共通する原因の無視/見落とし 。 複数の事象や状態が、共通する原因の結果として起こっている可能性を見落とす（そして、それら事象の間に因果関係を求めてしまう）誤りです。 モジュールAでのデータ加工の故障と、モジュールBでのデータ転送の故障は、実は中間ファイルのデータの破損が引き起こしているのに、個別の事象と判断する（場合によっては「Aの故障がBの故障を引き起こした」などと考える）類です。 早急な特定は禁物 ここまで挙げた誤りにもつながり得る落とし穴が、 因果関係の過剰な単純化 です。 「目につく」「最初に気づいた」「判りやすい」「いかにもそれらしい」といった理由から、見つかった“原因っぽいものごと”に飛びついてしまう（そこで因果関係の推定を止めてしまう）誤りです。 図4-3 因果関係推定の落とし穴 一般に、ある事象が起こった際、その要因と考えられる事柄や先行する事象は数多くあります。 複数の要因が（複雑に）関連してひとつの事象を起こすことも珍しくありません。 それらの中から原因を見つけるのは、時間や手間がかかるものです。 特に、ソフトウェアの故障や不具合発生時のような、起こった事象から遡って原因を考える場合、「事象を確認した段階で、原因の候補を洗い出して、原因らしきことを推定する」のは簡単なことではありません。 （同じようなことが、プロセス改善時の原因分析でも言えます） 因果関係を見つけようとする時には、まずこのことに気をつけましょう。 （ 第3回で紹介した「ミルの帰納法」 も参考になります） 事象や発生状況の詳細を十分調べたか？ 原因の候補(先行する事象や、故障の要因になり得る事項)を十分考えて挙げたか？ 見つけた（と思う）原因は、観察結果に即しているか？ 原因から結果に至る道筋を単純に考えていないか？ この章に挙がっている 因果関係の推定に関わる落とし穴 に落ちていないか？ 別の落とし穴にはまらないように 観察結果をまとめて共通項を見つけたり、因果関係を特定しようとする際には、演繹的な論理のスキルも働きます。 演繹的推論の落とし穴（ 形式面(前編) 、 非形式面(後編) ）にも併せて気をつけましょう。 ★ 長くなってしまいましたので、今回はここまで。帰納の仲間については後編でお伝えします。 参考文献 近藤洋逸, 好並英司 『論理学入門』 岩波書店 1979 鈴木美佐子 『論理的思考の技法Ⅱ』 法学書院 2008 藤野登 『論理学　伝統的形式論理学』 内田老鶴圃 1968 J.S.ミル(著), 大関将一(訳) 『論理学体系 : 論証と帰納 5』 春秋社 1959 T・エドワード・デイマー(著), 小西卓三(監訳), 今村真由子(訳) 『誤謬論入門　優れた議論の実践ガイド』 九夏社 2023 図版に使用した画像の出典 Loose Drawing 人物画をお借りしています。 品質探偵コニャン：Produced by Sqripts . No Unauthorized Reproduction. 【連載】ソフトウェアエンジニアのための論理スキル［実務三年目からの発見力と仮説力］ 記事一覧 【第1回】見つけるための論理 【連載初回、全文公開中】 【第2回】 “共通項”を見つけ出す 【第3回】発見はよい観察とよい方法から 【第4回】帰納の仲間と落とし穴 -前編- The post 【第4回】帰納の仲間と落とし穴 -前編-｜実務三年目からの発見力と仮説力 first appeared on Sqripts .

みなさん、こんにちは。 「ソフトウェアレビューをエンジニアリングっぽく捉える会」 の”うれっしー（うれしのあや）”です。 今回は「レビューとは？」がテーマです。 「〇〇レビューと名前がついていなくても、それはレビュー！って捉えて活動していきましょう」 と言いたい、少し視野を広めていただきたい記事になります。 ▼前回の記事はこちら ［#0］イントロダクション ｜ソフトウェアレビューをエンジニアリングっぽく語ってみる レビューとは何か？ さてさて、レビューとはいったい何でしょうか？ まずは気楽に、字面（じづら）として意味をとらえてみましょう。 「レビュー（Review）」は、「 re （再び）」+「 view （見る）」が合成した形になっています。 このままの意味「再び見る」のであれば、日常生活がレビューだらけです。 朝出かける時の「携帯持った、財布持った、鍵持った！」も、もう十分レビューなわけです。 次に言葉として、辞書的な意味合いを見ていきましょう。 Googleさんに聞いてみると、「Review（レビュー）には、「批評する」「復習する」「再考する」などの意味があります。 」と教えてくれました。 例えば今回のような記事を読んでいると この記事のここはいいけど、あの部分はもう少しよく書けたはず あのポイントは覚えておきたいから、もう一度チェックしておこう ちょっと引っかかった言葉があるので、別の記事も調べてみよう なんてことがあるでしょう。 たしかに、一目見ただけではなく、今一度記事を見たり頭の中で思い起こしたりして、批評も復習も再考もしています。 というわけで、これらが「レビュー」なわけです。 それは辞書ひっくり返しただけじゃないか、エンジニアリングではなく日常の話だよね、開発で役立つことが知りたいんだよ！というあなた、ここから開発っぽくなりますのでご安心ください。 開発現場における「狭義のレビュー」と「広義のレビュー」 多くの開発現場では、コードレビューや工程移行判定のレビュー、出荷判定のレビューなど、エンジニアリングとして開発プロセスの中で形が定義されていると思います。 指摘事項について合意ができるまでさらに議論したり、疑問については関係者に説明ができるような回答を用意したり、To-doリストを残して管理したりもしているでしょう。 つまり多くの方は「レビュー」と言えば、このような公式に規定されているレビューを思い浮かべるのではないでしょうか。 これらを我々は「狭義のレビュー」と捉えています。 一方、規定されているレビュー以外で、設計書やコードを読んだり、プロセスを策定したり改善したりする際も、気になったことを同じチームのエンジニアに相談に乗ってもらったり、上司に聞いてコメントをもらったりすることが多いと思います。 我々はこれらを「広義のレビュー」として捉えています。 つまり、開発やテスト、プロセスにまつわる相談も「レビュー」に入れているわけです。 「広義のレビュー」として捉えた方が、規定のレビューだけではカバーできない、今まで見えてなかったものが見えてくると思っているからです。 コードや設計書などの成果物を理解するために、 わからないことを聞いて、わかるようになる この部分は、そもそもどうなっていたのか？と確認する もっとこうした方が分かりやすいのではないか？と改善案を考える 公式レビューの準備のために、事前に合意をとっておく、有識者だけで仮の結論を出しておく このような行為を複数人で実施しているのであれば、ピアレビューと言えるのではないかと考えているわけです。 他にも、 エンジニアの頭の中にあるけど、うまく成果物に表現できていないことを引き出す 規定されたレビューの範囲内で多くの項目があり、網羅しているつもりだが、リリース後に問題が起こったので、確認項目を見直してみる 有識者が直接関係しない部分にも参加が必要になっていて時間がもったいないため、レビュー自体の手順やプロセスを効率化する これらもエンジニアリング行為であり、テクニックと同等のものを行使する必要がありますので、「レビュー」と捉えています。 にしさんがよく言っていた「テクい」話の方で、「会議術」（一般的な会議を回す技術）ではない方です。 レビューはテストとは違って動かないもの・ことも対象に入ってきますので、テストとは異なる技術が必要になることは明確でしょう。 必要な技術の中身については今後の連載の中に出てきますので、お楽しみに。 「広義のレビュー」の効果 「狭義のレビュー」の重要性は書くまでもありませんが、でき上がった後の成果物に頼ると現場の負担が大きくなりがちです。 特にレビューでお悩みの方は、公式レビューよりも前の気軽な相談や確認会を増やす＝レビューをシフトレフトすると、コストをあまりかけずに製品やサービスを一歩でも改善できると思います。 加えて、レビューの役割分担も普段とは少しずらしたり別の視点にしてみたりすると、みんなの知恵や日常とは異なる良いところも見えてきそうです。 いろんな人の知恵を集めてちゃんと使えるようになると、さらに進化した、強い組織になっていくことにも繋がるはずです。 まとめ 「〇〇レビューと名前がついていなくても、それはレビュー！って捉えて活動していきましょう」 レビューを「狭義のレビュー」で捉えるよりも、「広義のレビュー」として考えてみた方が、手戻りが少なくちょっと気楽になる未来が見えてくるのではと思います。 この連載で書くのはあくまで例にはなりますが、それぞれの現場でどのようにあてはめてみると良いかを、まずはゆる目に検討されてみてください。 「広義のレビュー」の検討が、少しでも皆さまの良い製品・サービスにつながることを願っております。 この記事を担当したメンバー うれっしー （うれしのあや／ @ureshino66 ） 大規模ソフトウェアの品質管理を22年ほど経て、最近の活動は、 ASTER のバグシェルジュとSReEE(スリー)「ソフトウェアレビューをエンジニアリングっぽく捉える会：Software Review Engineering Explorers」。 https://www.softwarequasol.com/ 【連載】ソフトウェアレビューをエンジニアリングっぽく語ってみる 記事一覧 ［#0］イントロダクション ［#1］レビューとは？ The post ［#1］レビューとは？｜ソフトウェアレビューをエンジニアリングっぽく語ってみる first appeared on Sqripts .

ソフトウェアクオリティマネージャーのアイネイドです。昨今、業界にはテスト自動化の波が来ており、顧客からのテスト自動化に関するご質問やご相談を受けることがあります。 そこでテスト自動化の知識をつけるために丁度よい資格試験はないものかと探していたところ「JSTQB Advanced Level テスト自動化エンジニア」という資格に辿り着きました。 本記事では「JSTQB Advanced Level テスト自動化エンジニア」試験自体についての説明および、合格に至った学習ポイントについてお話したいと思います。最後までお付き合いいただければ幸いです。 JSTQB AdvancedLevel テスト自動化エンジニア JSTQBとは何か？ まずJSTQBについて知らない読者もいらっしゃると思いますので簡単に説明をします。日本におけるソフトウェアテスト技術者資格認定の運営組織として2005年4月に認定されました。各国のテスト技術者認定組織が参加しているISTQB（International Software Testing Qualifications Board）の加盟組織の一つになります。 「JSTQB Advanced Level テスト自動化エンジニア」について 本資格名である「テスト自動化エンジニア」の定義は、 テストについて汎用的で幅広い知識を持ち、テスト自動化という特定の領域につい て深く理解している者を言う。深い理解とは、組織および／またはプロジェクトが機能テストのために自動化ソ リューションを設計、開発、保守する際に、方向付けとして使用できるテスト自動化理論とプラクティスについて、 十分な知識を持っていることと定義される。 後述のシラバスより抜粋 となります。テスト自動化レベルの考え方から、ソリューションとしての運用方法まで幅広く抑えている内容となっており、コンサルタントとしての提案・マネージャーとしての運用まで実務で使うことができる「 Specialist 」として役立つ資格になっています。 なお「テスト自動化エンジニア」はAdvanced Levelのため、受験するためには「JSTQB認定テスト技術者資格Foundation Level資格試験の合格者、又は JSTQB (日本) 以外の Foundation Level 資格試験の合格者」である必要があります。ちなみに受験料は22,000円(税込)でした。  また、今回の試験は「期間限定」「受験回数制限(1回)」だったため、2024年8月1日(木) から 2024年10月31日(木)(約3ヶ月間)の期間中に一回のみ受験可能となっていました。恒常化する可能性があることは言及されていましたが、次回も期間限定である可能性がありますので「テスト自動化エンジニア」資格の取得を希望する方はアンテナを高くしておいた方がいいでしょう。 学習対象のシラバスと最小学習時間目安 学習対象となるシラバスは下記URLで公開されております。 ■テスト技術者資格制度 Advanced Level シラバス テスト自動化エンジニア https://jstqb.jp/dl/JSTQB-Syllabus.Advanced_TAE_Version2016.J01.pdf ちなみにシラバスには章毎に学習最小時間の目安が設定されており、総合計で1170分(約20時間)となっております。これは例えば平日一日一時間の学習で約一ヶ月ということなので個人的には比較的着手しやすい資格といった印象です。 (あくまで個人的な)合格するための学習ポイント まず最初に。受験の際に秘密保持契約(NDA)を結ぶため、このコラムで試験問題や解答を示すことはありません。もし期待していた方がいましたら申し訳ございません。ただ、後述の学習ポイントを抑えることで解答しやすかったように感じましたので参考になれば幸いです。 Point1. まず頭文字の略語を把握しよう シラバスを読み始めて一番最初に思ったのがこれになります。シラバスの文章では複数の頭文字の略語が使われているのですが、似たような頭文字の略語が多いためきちんと把握してからシラバスを読み始めないと略語の意味を取り違えることが往々にあります。例えば頭文字が「TA」(Test Automation = テスト自動化)で始まる略語にはTAA、TAE、TAF、TAM、TAS等があり、略語の後に()付きで説明のように親切に記載されておらず、文章中に頻繁に登場するため時々混乱することになるでしょう。頭文字の略語を見ればすぐにイメージができる程度までしっかり覚えこんでからシラバスを読み始めるとよいでしょう。また、シラバス内の略語に関する説明はしっかり読み込んでおくことをおすすめします。 Point2. 先頭から順にシラバスを読んでいこう 他の資格であると「まずこの章から学習しよう」のような物があると思いますが、「テスト自動化エンジニア」のシラバスにおいては順番に読んでいくことをおすすめします。これはおそらくシラバスが認定コース用教材としての章立てを最初から意識して構成されており、順番に読んでいくことにより順次習得しやすく構成されているためになります。 Point3. 図をしっかり頭に入れよう シラバス内には少ないですが図がいくつか載っています。ただなんとなく図を見るのではなく、せっかく図になっているのですから、「矢印があればどこからどこにひかれている矢印なのか」や、「枠で括られている場所・中に何が記載してあるのか」を意識してはしっかり覚えておきましょう。単に文章を丸暗記するより断然効率的で頭に入っていれば問題に対して応用が効くことでしょう。 Point4. キーワードは表にまとめよう 人によるとは思いますが、私としてはシラバスで形式立てて記載（「3.2.2 テスト自動化へのアプローチ」のようなの主な概念・利点・短所など）をされている部分に関しては自分の言葉で表形式化することで理解しやすくなりました。長い文章を長いまま暗記するのはあまり現実的ではないので、一度試してみてはいかがでしょうか。 考察・まとめ いろいろと学習ポイントについて話させていただきました。 テスト自動化エンジニアは個人的にはとっつきやすく、仕事に役立ち、興味のある分野であったこともあり楽しく学習することができました。 Advanced Levelではありますが、難易度はそれほど高いわけではなくシラバスのボリュームも程々なので皆さんも一度取り組んでみてはいかがでしょうか。 本ブログを最後まで読んでいただいてありがとうございました。 The post JSTQB Advanced Level テスト自動化エンジニア試験合格体験記 first appeared on Sqripts .

こんにちは、エンジニアのタカです。 突然ですが、Google Apps Script（以下、GAS）を実装していて、もっと効率的に作業したいと思ったことはありませんか？ GASは手軽に業務効率化できる便利なツールですが、コード管理やデプロイの面で課題を感じている方もいるかもしれません。この記事では、GAS開発の課題を解決するツール「clasp」を既存のGASプロジェクトに導入する手順を解説します。 claspとは GitHub – google/clasp: Command Line Apps Script Projects claspは、Googleが提供するNode.jsのパッケージで、開発者がGASをより効率的に実装、バージョン管理、デプロイができるようにします。 claspを導入することで、具体的には以下のような利点があります。 ローカル開発環境の構築 claspを使用することで、ローカル環境で任意のエディタやIDEを利用して実装できます。GASはプロジェクトのページに専用のエディタが提供されていますが、このエディタでの開発と比べ、コード補完やリファタクリング機能などが強力になるメリットがあります。 TypeScriptの利用 claspは実装言語にTypeScriptを選択できます。TypeScriptで実装することで、型安全性の保証や、コードの可読性や保守性が期待できるため、直接GASを実装するよりもバグの発生を減少させることが期待できます。 バージョン管理の容易さ ローカル環境で実装したプログラムファイルや設定ファイルは、gitで管理することができます。GASのプロジェクトページでは手動でバージョン管理が必要ですが、gitでの管理のほうが、変更履歴を追跡したり、過去のバージョンに戻したりすることが簡単になります。 デプロイの簡素化 GASのプロジェクトページではデプロイは手動で行いますが、claspを使用すると、TypeScript等で実装したファイルをコマンドで本来のGASの実行環境にpushしデプロイします。コマンドラインでデプロイができるため、手動でのデプロイと比べて開発の効率が向上します。 既存の運用方法についての悩み 以前、私はGASでシステム仕様を管理する記事を書きましたが、この記事で紹介したGASを本格的にシステムの開発と運用で用いるようになりました。 スプレッドシート × Google Apps Scriptでシステム仕様をシンプルに管理！ こんにちは、エンジニアのタカです。普段はアジャイル開発におけるスクラムマスターや開発者としてプロダクトの開発に関わっています。今回は、プロダクト開発で起きたシステム課題に対して、導入の敷居が低いスプレッドシートを中心に解決を行った体験談を書きたい... 　続きを読む　 Sqripts 関連記事｜Sqripts また、この記事とは別のGASも開発と運用で使い始めており、以下の課題を解決するため、claspを導入することにしました。 clasp導入の背景 GASのバージョン管理が煩雑 GASのファイル変更履歴はブラウザ上の専用のエディタでのみ確認でき、かつ以前のバージョンへの復元がプロジェクト全体でしか行えない。 回避手段として、GASのファイルをコピー&ペーストしてGitHubにプッシュしているが、手順が煩雑。 解決策：webエディタは使わず、最初からローカルで実装と gitでのバージョン管理を行う GASのデプロイが手動 GASプロジェクトのデプロイボタン押下でデプロイを行っており、効率がやや悪い。 解決策： claspでコマンドラインからデプロイする ローカル開発環境がない 実装を専用のブラウザ上のエディタで行っており、コード補完やリファクタリング機能が不足している。 解決策： claspで任意のエディタを使用する claspで管理するGASについて 今回の記事で取り上げるGASですが、前回の記事のコードは若干長いため、簡略化した専用のGASを準備しました。 GASは2ファイルで、処理の内容としては、スプレッドシートから値を読み取り、JSON形式の値に変換のうえ、ドライブに値をテキストファイルとして保存するものです。 なお、テキストファイルを出力するドライブのパス（ID）は、GASのスクリプトプロパティとして登録しておきます。 サンプルのスプレッドシート // JSON生成処理 function generateJson() { // スプレッドシートのデータを取得する const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName("test_sheet"); const data = sheet.getDataRange().getValues(); // JSONを格納するオブジェクトを作成する const json = {}; // シートの各行を処理する for (let i = 0; i < data.length; i++) { json["app_PJ1_" + i] = { number: data[i][0], app: data[i][1] }; } return json; } // メイン関数 function main() { saveDrive(generateJson()); } // Google Driveにファイルを保存 function saveDrive(message) { // Google Driveの特定のフォルダにファイルを作成 const folderId = PropertiesService.getScriptProperties().getProperty( "DRIVE_FILE_PATH_PJ1" ); const folder = DriveApp.getFolderById(folderId); folder.createFile( "sample.json", JSON.stringify(message), MimeType.PLAIN_TEXT ); } clasp導入の流れとしては以下の手順で行います。 リポジトリに元のGASをpushしておく 当該リポジトリをcloneしてclaspをインストールし設定を行う GASをTypeScriptで書き換え、リポジトリにファイルをpushする claspでデプロイする なお、本来のGASのプロジェクトは2つ存在するため、前述のGASファイルをコピーし、それぞれ別のプロジェクトのGASと仮定して移行を進めます。 以下が、元のGASファイルをpushした状態のリポジトリのディレクトリ構成です。 . ├── README.md ├── project1 │ ├── drive.gs │ └── main.gs └── project2 ├── drive.gs └── main.gs claspのインストールと設定 Node.jsのインストール claspはNode.jsのパッケージなので、まずはNode.jsのインストールを行い、npmコマンドを使えるようにします。インストールは、下記の記事で解説しているasdfなどで行うのがおすすめです。 Windowsユーザーにささぐ、WSL2を利用した（ちょっと便利な）Linux開発環境作成 こんにちは。GSです。今の時代、開発から運用までLinuxを必要とするケースはとても多いです。WindowsユーザーがLinux環境が必要な開発を行うとき、WSL2を使うことで手軽に環境を作り利用することができます。「Windowsは使えるが、Linuxはよくわからない」といった人... 　続きを読む　 Sqripts 関連記事｜Sqripts claspのインストールと設定 次に、npmコマンドでclaspをインストールし、初期設定を行います。 # package.json作成 npm init -y # claspをインストール npm install @google/clasp # コーディング時に、GASの関数を表示してくれるようになるパッケージ npm install @types/google-apps-script # Googleアカウントでログインします (認証画面が表示されるので許可します) clasp login 続いてclaspのコマンドで設定ファイルを作成します。今回は既存のスプレッドシートを使用するため、IDを指定します。プロジェクト単位で npm initを実行していますが、これは、claspのデプロイ時にプロジェクト単位で package.json が必要なためです。 # それぞれのプロジェクトで、既存のidを使用してclaspプロジェクトを作成 cd project1 npm init -y clasp create --title "Project1" --rootDir ./ --parentId "<スプレッドシートのID>" cd ../ cd project2 npm init -y clasp create --title "Project2" --rootDir ./ --parentId "<スプレッドシートのID>" コマンドを実行するとclaspの設定ファイルが生成され、同時にGASのプロジェクトも新規作成されます。 なお、作成後にスプレッドシートからGASのプロジェクトを開こうとすると、スプレッドシートに紐付いているプロジェクトが複数あるため、プロジェクトの選択画面が表示されるようになります。 ここまでのディレクトリ構成 . ├── node_modules ├── README.md ├── package-lock.json ├── package.json ├── project1 │ ├── .clasp.json │ ├── appsscript.json │ ├── drive.gs │ ├── main.gs │ └── package.json └── project2 ├── .clasp.json ├── appsscript.json ├── drive.gs ├── main.gs └── package.json package.jsonの編集 それぞれのprojectディレクトリのpackage.jsonについては、デプロイ用のスクリプトとしてclasp pushコマンドを定義します。 "scripts": { "deploy": "clasp push" } また、ルートディレクトリにあるpackage.jsonには、プロジェクトごとのデプロイ開始スクリプトを定義します。また、GASプロジェクトの画面を開くためのスクリプトも定義しておくと便利です。 "scripts": { "deploy:project1": "cd project1 && npm run deploy", "deploy:project2": "cd project2 && npm run deploy", "open:project1": "cd project1 && clasp open", "open:project2": "cd project2 && clasp open" }, 設定ファイルの編集 それぞれのprojectディレクトリの設定ファイルについて、appsscript.json（マニュフェストファイル）を編集して、timeZoneを変更しておきます。 { - "timeZone": "America/New_York", + "timeZone": "Asia/Tokyo", "dependencies": { }, "exceptionLogging": "STACKDRIVER", "runtimeVersion": "V8" } (参考) 設定ファイルのドキュメント 各設定ファイルのパラメータについては、公式ドキュメントを参照してください。 マニフェストの構造  |  Apps Script  |  Google for Developers GitHub – google/clasp: Command Line Apps Script Projects TypeScriptへの書き換え 次は既存のGASファイルの書き換えです。GitHub Copilot Chat や Cursorなどを用いると、比較的楽にGASファイルをTypeScriptに変換できます。 なお、今回はCursorのComposer機能を使用したため、tsconfig.jsonや、必要なディレクトリなどが自動生成されて便利でした。 CursorエディタやComposer機能の基本的な使い方については、2024年10月に公開されたこちらの記事で詳しく解説していますので、併せてご覧ください。 CursorのComposer機能でAIに0からテストコードを作成してもらう こんにちは、AGESTのバックエンドエンジニアのまさです。今回は、CursorエディタのComposer機能を用いて、AIにテストコードを記述してもらう方法をご紹介します。テストコードはソフトウェアの品質を高めるために重要ですが、手作業で書くのは時間がかかるものです。... 　続きを読む　 Sqripts 関連記事｜Sqripts 変換後のファイル // main.ts declare const saveDrive: (message: JsonData) => void; export interface JsonData { [key: string]: { number: any; app: any; }; } // JSON生成処理 export function generateJson(): JsonData { // スプレッドシートのデータを取得する const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName("test_sheet"); if (!sheet) { throw new Error("Sheet not found"); } const data = sheet.getDataRange().getValues(); // JSONを格納するオブジェクトを作成する const json: JsonData = {}; // シートの各行を処理する for (let i = 0; i < data.length; i++) { json[`app_PJ1_${i}`] = { number: data[i][0], app: data[i][1] }; } return json; } // メイン関数 export function main(): void { saveDrive(generateJson()); } // drive.ts import { JsonData } from './main'; // Google Driveにファイルを保存 function saveDrive(message: JsonData): void { // Google Driveの特定のフォルダにファイルを作成 const folderId = PropertiesService.getScriptProperties().getProperty( "DRIVE_FILE_PATH_PJ1" ); if (!folderId) { throw new Error("Folder ID not found in script properties"); } const folder = DriveApp.getFolderById(folderId); folder.createFile( "sample.json", JSON.stringify(message), MimeType.PLAIN_TEXT ); } // グローバルスコープに公開（globalの代わりにthisを使用） // @ts-ignore this.saveDrive = saveDrive; 書き換え後のディレクトリ構成 変換後のディレクトリ構成は以下のようになります。元の.gsファイルはpushする必要がないため削除します。 . ├── node_modules ├── README.md ├── package-lock.json ├── package.json ├── project1 │ ├── .clasp.json │ ├── appsscript.json │ ├── functions │ │ ├── drive.ts │ │ └── main.ts │ └── package.json ├── project2 │ ├── .clasp.json │ ├── appsscript.json │ ├── functions │ │ ├── drive.ts │ │ └── main.ts │ └── package.json └── tsconfig.json プロジェクトへのデプロイ 定義したスクリプトを使用してデプロイを行います。 $ npm run deploy:project1 Debugger attached. > gas-management@1.0.0 deploy:project1 > cd project1 && npm run deploy Debugger attached. > gas-management-project1@1.0.0 deploy > clasp push Debugger attached. (node:45633) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead. (Use `node --trace-deprecation ...` to show where the warning was created) └─ appsscript.json └─ functions/drive.ts └─ functions/main.ts Pushed 3 files. Waiting for the debugger to disconnect... Waiting for the debugger to disconnect... Waiting for the debugger to disconnect... デプロイが完了したら、GASのプロジェクト画面を開き、main関数を手動で実行して動作確認を行います。GASのプロジェクト画面で「実行」ボタンを押し、関数を選択することで実行できます。 $ npm run open:project1 Debugger attached. > gas-management@1.0.0 open:project1 > cd project1 && clasp open Debugger attached. Opening script: <https://script.google.com/d/◯◯◯◯> Waiting for the debugger to disconnect... Waiting for the debugger to disconnect... 動作確認 初回実行時や権限を変更した場合など、データへのアクセス権限の承認が必要になる場合があります。 おわりに 今回は、GAS開発を効率化するためのツール「clasp」の導入から、実際のGASファイルのTypeScriptへの書き換え、そしてデプロイまでを解説しました。 この記事が、GAS開発をより快適に、そして効率的にする一助となれば幸いです。ぜひclaspを活用して、より良いGAS開発体験を実現してください。 The post clasp導入で既存のGAS開発を効率化！手順とメリットを徹底解説 first appeared on Sqripts .

この連載では、ソフトウェア開発のQAエンジニアとして働き始めた皆様に向けて、私の実体験をもとに「こんなことを知っておけばよかった」という、ちょっとした気づきを共有します。 一緒にソフトウェア開発のQAエンジニアとしての充実したエンジニアライフを築くためのヒントを探っていきましょう。 ＜QAエンジニアのスタートガイド 記事一覧＞ ※クリックで開きます 【第1回】充実したQAエンジニアとしてスタートするためのガイドライン 【第2回】「誰のためか」を意識しよう 【第3回】QAエンジニアの第一歩、「ソフトウェアテスト」を知ろう -前編- 【第4回】QAエンジニアの第一歩、「ソフトウェアテスト」を知ろう -後編- 【第5回】コミュニケーションが鍵を握る ソフトウェア開発は、一般的に、多くの専門家からなるチームによって行なわれます。 また、ソフトウェア開発は創造的であり、高度で知的な作業が伴うため、チームワークや人間性への配慮は、生産性や品質を含むさまざまな結果に影響を与えます。 チームワークや人間性への配慮に重要なファクターとなるのは「ソフトスキル」です。 ソフトスキルはQAエンジニアにとっても、より一層重要になります。 QAエンジニアの仕事で特に重要なのは「情報提供」であると考えます。そして、伝え方やマインド次第でチームを守ることもできますし、壊すこともできてしまいます。 本記事ではQAエンジニアにとって重要なソフトスキルについて解説します。 チームで働く チームの一員として働くということ QAは多くの場合、1人で価値を届けることはできません。テストを始めとして、誰かが作ったものに対してQAとして貢献することが一般的なありかたではないでしょうか。 つまり、QAはチームを必要としています。 ここで紹介したい品質モデルがあります。JIS X 25010:2013では、利用時の品質の他にも外部特徴・内部特徴・プロセス品質という考え方で整理しています。 利用時の品質にフォーカスするQAは多いと思いますが、プロセス品質もまた重要だと私は考えています。 プロセス品質を大事にしてこそ、良いプロダクトが作れるという考えを私は支持しています。 ソフトウェア開発において、「プロセス」は、ただ単に仕事の受け渡しだけではなく、人のモチベーションやコミュニケーションも含めて考えたほうがよいでしょう。 QAはタスクの受け渡しをするのでなく、チームの一員としてオーナーシップを持ち、プロセス品質にも着目して活動をすることが大切だと考えています。 チームでソフトウェア開発をすることに言及している記事は多くありますが、私は「チーム・ジャーニー」という本をおすすめします。 ■ チーム・ジャーニー：TEAM JOURNEY 〜ゼロの状態から最強のチームをつくりあげるまで〜 （市谷 聡啓 著／翔泳社） 弱さを抱擁できることがQAの強みである ソフトウェアテストでは、ソフトウェアの故障を見つけたり、欠陥を指摘するということがあると思います。 だからといって、QAは喜びすぎたり、ましてや開発者を非難するような振る舞いをしていてはいけないと思っています。 昔、「こんな悪いコードを書いたのは誰だ」や「なんでこんなバグを作るんだ」というような発言をするQAに出会ったことがあります。 私はそれを大変残念だと思いました。 QAは、プロダクトを通じてプロセスの課題や人の弱点を垣間見ることがあります。 だからこそ、QAは優しい存在になる必要があります。 QAは、礼儀正しく、接しやすく、そして何よりメンバーの弱さを受容するような態度が必要だと思っています。 もちろん、チーム開発にとってそういう行動が好ましいという側面があります。 それだけでなく、これらはQAの倫理として守るべきものではないでしょうか。 欠陥を探して故障を見つけるということは大事なことです。 一方で、そういった立場を使って優位に立とうとしたり、人を貶めるようなことは決してしてはいけません。 弱さを抱擁できることこそが、QAの強さであると私は考えています。 「弱さを抱擁する」というフレーズについては西康晴先生の以下の動画から引用しています。 この動画はQAエンジニアにとってあるべき姿について深い洞察が得られるので、ぜひご覧いただきたいです。 コミュニケーションの方法 コミュニケーションの方法としてさまざまありますが、QAのあるべき姿が試される場面として、3つ紹介します。 ミーティング ミーティングはチーム開発においては避けられない活動であり、とても重要です。 ミーティングの効果、生産性の議論はエンジニアリングの分野に限らず活発的です。 ここでは、QAの専門性を発揮できる参加の方法を提案したいです。 「俯瞰的に見る」ということ、「目的志向に立ち返る」ということです。 テスト設計をしていて、抽象と具体を行き来することは少なくないと思います。 QAはミーティングのなかで、「どういう議論をしているのか」「何を話しているのか」を俯瞰で見て、時に抽象でまとめ、時に具体によって前に進めることができます。 あるいは、ミーティングの中で目的を見失ってしまうことがあるかもしれません。 そのなかでもQAは、専門性である「目的志向」で、「目的は何なのか」という問いを立てることができます。 ミーティングを通して、チームのプロセス品質を良くしていくことも、QAとして重要な役割だと考えています。 バグチケット バグチケットを通して開発者にフィードバックすることがよくあると思います。 そのなかでも重要なことは、事実を正確に書く、そして礼儀正しく書くということです。 バグチケットは開発者を批難する手段ではありません。バグチケットはあくまで事実を提示して、チームにとってより良い意思決定を促すために使うものです。 レビュー レビューでもQAの専門性が発揮されると考えます。 レビューはソフトウェア開発でも重要な役割を持っています。一方、体系的に導入している組織は少ないのではないかと考えています。 レビューはリーディング技法などがある一方で、コミュニケーションもまた重要です。 たとえばJSTQB FLでは、レビューのミーティングについて、体系的な解説がされています。 レビューのプロフェッショナルとして、必要に応じて体系化された技術を実装していくことが、QAには求められていると考えます。 コミュニケーションで大切にしてほしいHRT コミュニケーションは会話や発信であると捉えている人は多いと思います。 一方で、私は自分自身のマインドもまた重要だと思います。 ここでは「Team Geek」という書籍で紹介されている、HRTという考え方を紹介します。 ■ Team Geek （Brian W. Fitzpatrick、Ben Collins-Sussman 著、角 征典 訳／O’Reilly Japan） HRTとは、Humility（謙虚さ）、Respect（尊敬）、Trust（信頼）の3つの単語の頭文字を取ったものです。ソーシャルスキルの三本柱であり、人間関係を円滑にするだけでなく、健全な対話とコラボレーションの基盤になると考えられています。 Humility（謙虚） 自分の考えは、絶対に正しいわけではなく、自分自身もまた欠点を抱えていることを理解することです。同時に常に自分を改善していくことも大切です。 他者に対して謙虚であることも重要ですが、一方で自分に対して謙虚であることも重要です。 例えば、「自分の成果物は完璧な状態で見せなければならない」と思っていれば、それは自分自身を完璧だと思いたいことの裏返しであり、謙虚さを失っていると言えます。 時には不完全な成果物を見せることも必要だと知ることが大切です。自分は完全無欠ではないということを理解して、自分の成果物もまた不完全であることを受容することが必要なのです。 Respect（尊敬） 一緒に働く人の人格や能力を尊重し、心から思いやることです。相手は「開発者さん」といった役割ではなく、人格のある人間であることを認識することでもあります。 特にQAは批判を行うことがあります。 そうした中で成果に対する建設的な批判と性格に対する攻撃的な批難を区別して理解する必要があります。 建設的な批判は、心から他人を思いやり、成果を改善してほしいと願っていないと生まれません。そして、そこに尊敬が含まれていることが重要なのです。 Trust（信頼） 自分以外の人は有能であり、正しいことをすると信頼することです。 チームのメンバーはそれぞれ何かしらの専門家であり、自分とチームに対して恩恵をもたらしてくれていると心から信頼しましょう。 これは批判を受ける際にも重要となります。 仕事の中で批判されているのは成果物であり、自分自身ではないということを理解することが大切です。 また、 批判する対象は作成者ではなく成果物であるべき ということを肝に銘じておく必要があると考えます。 おわりに 優れたQAエンジニアは、技術的なスキルだけでなく、コミュニケーション能力も高いものです。 チームの一員としての自覚を持ち、HRT（謙虚さ、尊敬、信頼）を念頭に置いて行動することで、QAエンジニアはチームに貢献し、プロジェクトを成功に導くことができます。 コミュニケーション能力は、一朝一夕で身につくものではありませんが、意識して継続的に努力することで、より良いチームとより良い製品を作ることができると信じています。 【連載】QAエンジニアのスタートガイド 記事一覧 【第1回】充実したQAエンジニアとしてスタートするためのガイドライン 【第2回】「誰のためか」を意識しよう 【第3回】QAエンジニアの第一歩、「ソフトウェアテスト」を知ろう -前編- 【第4回】QAエンジニアの第一歩、「ソフトウェアテスト」を知ろう -後編- 【第5回】コミュニケーションが鍵を握る The post 【第5回】コミュニケーションが鍵を握る｜QAエンジニアのスタートガイド first appeared on Sqripts .

こんにちは、QAのゆーすけです。 私は今でこそソフトウェアテスト会社の一員として日々努めていますが、元々はゲームテストがメインの会社のメンバーでした。 ゲームテストの会社自体はコンシューマーゲーム→PC→携帯（FP/スマホ）とテストを渡り歩いてきましたが、元々はガチガチのゲーム好きからゲームデバッグに応募した経歴になります。 今はゲームテストに関わることが全くないですが、元々のゲーム好きの興味として最近JSTQB ※1 のゲームテストシラバスを眺める時間を設けるようにしています。 ※1 JSTQB認定テスト技術者資格 日本におけるソフトウェアテスト技術認定資格運営組織。ISTQBの加盟組織でもあるので、その資格および教育は国際的にも有効 ゲームテストの思い出 私がゲームテストを主戦場としていたことは、ゲーム機がネットワークに繋がるといったことはほぼなく（PlayStation 2では別売のBBユニットが必要な時代……）、 ゲームの重篤な不具合＝回収、リマスターの販売 といったことが当たり前でした。 ※担当案件でリマスター版が出たことが一度だけあります（広い意味なら2回ですが） ※PlayStationの某大型RPGの進行不能不具合は新聞にまで載った最も？有名な不具合だと思います。 　直すためにはメモリーカード（PS）の発送、修復が必要 　この不具合は今の市場流通版（アーカイブス版）でも修正されていない また、発売日というものが明確に決められるので、その発売日何カ月前には開発・テストが収束し、製品を量産（カートリッジもしくはROM）し、出荷して、流通させる、というスケジュールが必須でした（これは多分今もそう）。 ※とあるメーカー、とあるゲームタイトルのキックオフで 「すでに発売日を決めて広告をxxxxx円かけて大体的に行っているので、 　くれぐれも発売遅延がないように品質管理を徹底してください」 と言われたのは今ではとてもいい思い出。ネタになってます（ちゃんと当初の予定日に発売しました）。 ゲーム特有の観点として 閑話休題、 JSTQBのゲームテストシラバスに以下のような文章が記載されています。 ブラックボックステスト技法（black-box test technique）を使ったテストでは、プラットフォームによる 違いはほとんどない。しかし、各ゲーム機メーカーは、ビデオゲームが公開される前に準拠しなければならない独自の要件を定めている場合がある。これらの要件は、秘密保持契約に基づいて開発者やパブリッシャーに提供される独自の文書である。各要件のチェックリストはいくつかのカテゴリーで構成されており、ゲーム機メーカーに拒否されないためには、ゲームソフトウェアはそれらに準拠しなければ ならない ゲームテストシラバスより抜粋 PC・webサービス系のテストを行っていると意識することがないですが、 ゲーム業界のような3rdパーティーがいるものでは、一般のテストと同様もしくはそれ以上に強く意識しなければならないのが上記のようないわゆる「作成基準」というものになります。 ※1stパーティーがプラットフォーマー（任天堂、ソニー、マイクロソフトなど）   2ndパーティーがユーザーとして、   3rdパーティーはゲーム開発企業と言われています。 つまり、ゲームとしての品質がどんなに高水準であっても、メーカー側の作成基準に抵触事項が1件でも存在した場合はリジェクトを受けてしまうわけです。 前述した広告費をかけた、とプレッシャーをかけていただいたプロジェクトでも、機能部分の重篤な不具合よりも、作成基準を通過できるか、という点の方が気になって胃がキリキリとしたものです。 この各種作成基準はひとつひとつを詳細に覚えておく必要まではありませんが、品質基準、観点、方針として心に留めておくと有益なものばかりなので、思い出話を含めて軽く紹介していきたいと思います。 作成基準例 正しい用語を使う 何を当たり前のことを、と思われるかもしれませんが、意識しないと正しい用語を使うことは結構難しかったりします。 「取り扱い説明書を見て、playstation2のコントローラーで十字ボタンのことを調べた」 昔の知識に偏っていて申し訳ないですが、 上記のような文章がゲーム中にあると、即再生基準でリジェクトを受けること間違いなしです。 正しくは 　・ 　・ 　・ 「解説書を見て、”PlayStation🄬2”のコントローラで方向キーのことを調べた」 となります。 複数のプラットフォームがある場合、それぞれで使用される用語は差別化されていることが多いので、自分の使っている言葉がその環境において本当に適切なものであるか、ということは非常に大事な要素です。 こういったことは作成基準など関係なく、普段の日常やビジネス上の会話や、論文、レポート作成でもかなり有効になる意識となります。 中断再開、復元を意識する とあるハードの作成基準では、 「ディスクトレイの開閉を行った後でも適切にゲームに復帰できること」 というものがあります（今もあるかもしれませんが）。 流石にPC・webサービス系のテストでは上記のような開閉を直接的に使うことはないかもしれませんが、携帯電話系のテストでは 携帯（フィーチャーフォン）の開閉を行っても正しく動作が復帰すること （いわゆるサスペンド／レジュームの観点） Androd端末において、端末デバイス側にバックキーが搭載されている場合、デバイス側からのインプットを受けて画面遷移を行った場合でも、適切な動作を保つこと などが派生観点としてあげられるかと思います。 画面端に重要な情報の表示、描画を行わない 重要情報の見逃しによる不利益防止のための観点になりますが、こういった内容もUI/UXなどの観点から意識できるとよりよい製品、品質構築に寄与できる観点だと思います。 このチェックを漏れなく行うために、液晶ディスプレイ上に透明テープを貼っている人をみたことは今でも忘れられない衝撃として記憶に残っています。 過剰の演出、画面描写を行わない これは1997年に某テレビ番組で起こった光過敏性発作が有名だと思いますが、いわゆる激しい画面の明滅を禁止する、という内容です。 こういったその時々に起こった事象なのが制約・規約として盛り込まれるということもあります。 また仮に明記された制約がなかったとしても、現在および過去の事象と照らし合わせて問題だと思われることを指摘していくことも、品質観点からは重要な活動になりますので、品管に携わる人達には幅広く、そして深い知識が求められることになります。 まとめ 今現在、元々ゲームデバッグからキャリアの始まった自分が、今こうしてソフトウェアテストに携わって少なからず活躍できている？ことを考えると、何のデバイスにどう関わってきたかはそこまで重要ではないのかもしれません。 品質的な考え方は別分野別デバイスでも有益だということが分かりますし、より大事なのは関わったものを柔軟に適用し、様々な知識を多角的に広く深く吸収し続ける、ということなのかもしれませんね。 The post ゲームテストから考える品質管理に大事なこと first appeared on Sqripts .

帰納的な推論 と 発見的な推論(アブダクション) は、 私たちがソフトウェア開発の現場/実務で（知らず知らずにでも）駆使している思考の形です（それどころか日々の暮らしでも使っています）。 それほど“自然な”思考の形ですが、どんな考え方で、どんなところに注意すると質の高い思考ができるのか、基本知識を押さえておくと実務のレベルアップにつながります。 ＜実務三年目からの発見力と仮説力　記事一覧＞ ※クリックで開きます 【第1回】見つけるための論理【連載初回、全文公開中】 【第2回】 “共通項”を見つけ出す 【第3回】発見はよい観察とよい方法から 今回は帰納的推論で「発見」をするために参考になる方法（見方考え方）を紹介します。 再現・枚挙的帰納 第2回で紹介した枚挙的帰納の例(A)、(B)（第2回の図2-3を図3-1として再掲）、それぞれでどんな風に推論しているか、コニャン君の脳内を覗いてみましょう。 図3-1 枚挙的帰納の例 【注意】 以下に再現する“推論の筋道”は、「こういう形/流れもある」を示すもので、誰でも・どんな場合でもこのような流れを辿る、と主張するものではありません。 (A)の形の場合 図3-1 (A)、コニャン君の思考の筋道は図3-2のようになるでしょう。 図3-1 コニャン君の脳内(A) こうした思考を支えるのが、前回解説した 自然の斉一性 や 因果性 という概念でした。 【第2回】 “共通項”を見つけ出す｜実務三年目からの発見力と仮説力 帰納的な推論 と 発見的な推論(アブダクション) は、私たちがソフトウェア開発の現場/実務で（知らず知らずにでも）駆使している思考の形です（それどころか日々の暮らしでも使っています）。それほど“自然な”思考の形ですが、どんな考え方で、どんなところに注意す... 　続きを読む　 Sqripts 関連記事｜Sqripts プログラム(ソースコード)に混入する欠陥は自然現象ではありませんが、筆者の経験によれば、斉一性に似たような状況が生じることがあります。 ある箇所のある処理で生じたエラー（誤り。勘違い、思い込み、考慮不足、仕様の誤読、etc.）は、他の似たような箇所での同じような処理でも生じがち。 ソースコードのコピペも欠陥を伝播しがち。 複数の箇所から呼び出されるモジュールに欠陥があると、特定の条件を満たしたら同じような故障が各地で発生することが起こりがち。 【訂正】この(A)、 第2回 では「共通項Pを見つける」例と述べましたが、「特殊文字を入力すると(共通項P)、フリーズする(共通項Q)」形と言えますね。間違えました。 (B)の形の場合 (B)は、共通項Pだけでなく共通項Qも見つけ、両者の関係性を見つけるのに、ちょっと“手数”がかかるでしょう。 （図3-3。図3-1との対応の参考として、吹き出し中に丸数字をつけています） 図3-3 コニャン君の脳内 (B) 発見＝観察＋推論の方法 「実験的探究の4方法」 図3-1 (A)(B)のような推論の方法は、何といっても 観察 ――起こっている事実を見落とさず、適切な詳しさで見る―― に支えられています。 （ 観察 については後ほど触れます） そして、よい 観察 に基づいて“共通項”（中でも 因果関係 ）を見つけるための方法を、19世紀イギリスのJ.S.ミルという哲学者が考えました。 自身の著作の中では「実験的探究の4方法」と題されていますが、「ミルの帰納法」「ミルの方法」などとして知られます。 （解説している方法は5つだが、ひとつは2方法の組合せ） 一致法 差異法 一致差異併用法 剰余法 共変法 本記事では、「ソフトウェアの動作確認やテストで、故障や不具合に遭遇した局面」や「デバッグ中に原因を探る局面」を想定して、結果から原因を探る場合に焦点を当てて説明します。 以降の解説では、 前件(先行する事象群)： 故障や不具合の発生に先立つ 環境・設定、データ、状態、コード中のロジック、入力・操作、など を指します。 後件(後続する事象群)： ソフトウェアの実行が引き起こす 出力・表示、状態(の変化)、データの変化、など（故障や不具合自身を含む） を指します。 (前件や後件の)要素： 前件や後件中の互いに識別可能なものごとを指します。 J.S.ミルの帰納法 一致法：多くの事例の「共通点」に着目する 着目する事象a（ソフトウェアの故障や不具合など）を生じる事例をふたつ以上集める。 ①前件の中に全事例で共通する要素がひとつだけある(要素Aとする)。 ②要素Aだけが全事例で一致している。 ③要素A以外の前件の要素が異なると、事象a以外の後件は異なる。 ①②③が共に満たされるなら、その要素Aが着目する事象aの原因（または、原因の不可欠の一部分）である、と考えることができます。 図3-4 一致法の概略 【特徴】 「ある要素がなくても着目する事象が生じるなら、その要素は原因から取り除いて考えてよい」という考え方に基づく( 消去法 )。 着目する事象を含む事例をいくつか集めれば適用できる。 「特定の要素を取り除いて結果を見る」といった実験ができない場合に適している。 後述の差異法の前段階として原因の候補を絞るのに適している。 【注意点】 事例は「前件では要素Aだけが共通、後件では事象aだけが共通している」こと。 他の要素や事象が共通していると、因果関係が絞り切れない。 （別の方法の適用などにより、さらに絞り込むことが必要） 事例は多いのが望ましい。 （少ないと、原因の絞り込みができなかったり、偶然の結果を原因と間違えたりするおそれが大きい） 前件の要素Aと事象aがともに、隠れた他の原因から生じている場合( 結果の共存 )を識別できない。 事象aが、前件の要素A ではない 原因による場合を識別できない。 事象aが多数の原因の複合により生じている場合、先行事象Aがどのように関与しているかは判らない。 図3-4a 一致法の例 差異法：異なる結果を生む「違い」に着目する 着目する事象aを生じる事例( 積極事例 )と、生じない事例( 消極事例 )を集める（最低、各ひとつずつ）。 ①前件に特定の要素Aがあると、事象aが生じる。 ②前件に特定の要素Aがないと、事象aは生じない。 ③それ以外は、前件と後件は全く同じ。 ①②③が共に満たされるなら、要素Aが事象aの原因（または、原因の不可欠の一部分）である、と考えることができます。 図3-5 差異法の概略 【特徴】 「ある特定の要素を除くと着目する事象が生じないなら、その要素は原因と考えてよい」という考え方に基づく(これも 消去法 )。 積極事例、消極事例それぞれひとつずつあれば適用できる。 別の方法で推定された因果関係を確認するのに適している。 （事象の発生原因がある程度推定できている状況で適用するのがよい） 一致法では識別できない「事象aが、前件の要素A ではない 原因による」場合を誤認しない。 【注意点】 条件を満たす事例を集める手間がかかる。困難な場合もある。 「特定の要素を取り除いて結果を見る」といった実験ができない場合には適さない。 原因の特定に適用する際には注意が必要。 （発生原因の推測がないと、ブルート・フォース的に手当り次第に試すことになる） 図3-5a 差異法の例 一致差異併用法：ふたつの方法の合わせ技 着目する事象aが生じる事例( 積極事例 )を2つ以上、 生じない事例( 消極事例 )を2つ以上、それぞれ集める。 ①積極事例では、先行する要素Aと後続の事象aが含まれて いることだけが共通 している。 ②消極事例では、先行する要素Aと後続の事象aがともに含まれて いないことだけが共通 している。 ①②が共に満たされるなら、要素Aが事象aの原因（または、原因の不可欠の一部）である、と考えることができます。 （消極事例の前件は、積極事例のそれと同じか類似していると対比が明確になる） 図3-6 一致差異併用法の概略 図3-1(B)、図3-3「ソフトウェアXはソフトウェアZがプリインストールされている機種で故障Fを起こす」は、この考え方を用いているわけですね。 図3-3 の②’で、「他の点で、起こる機種と起こらない機種に共通項はない」ところから、「故障Fが起こる場合と起こらない場合の違い」が絞り込まれます。 （他にも共通項がある場合は、さらに絞り込みを行なうことになるでしょう） 【特徴】 差異法だけでは「A : a」の組を見つけられないような場合でも使える。 事象が起こる場合(積極事例)、起こらない場合(消極事例)の共通点と相違点を広く見渡して検討できる。 【注意点】 積極事例と消極事例を集める手間がかかる。 図3-6a 一致差異併用法の例 剰余法：既知の関係との差分に着目する 着目する事象が生じる事例を取り上げる。 ①事例の一部の事象は、既に前件と後件の関係(因果関係)が判っているとする。 ②事例の前件・後件から、既知の前件・後件の組(①)を全て取り除く。 ②で残った前件・後件の組は、それぞれ前件(原因)と後件(結果)と考えることができます。 図3-7 剰余法の概略 【特徴】 差異法のバリエーションと言える。 既知の因果関係を用いて原因探求の省力化が期待できる。 この方法を適用すると、次のような事態に遭遇することがあります。 ある事例がある（例：A, B : a, b, c）。 このうち、A : a, B : b は既知の因果関係である。 そこでこれらを取り除いたら、「nil : c」になる！？ （注：nil＝空のこと、つまり前件が空） これは、a, b, cという後件に対して、候補として考えたA, Bの他に前件がある可能性を示唆しています。 こうした事態になったら、 前件の見落とし・見逃し がないか確かめるか、 隠れた前件 の存在を仮定して要素Cを探すか、といった方向に向かうことになるでしょう。 （この例は、決して「前件の要素と後件の要素は1対1対応でなければならない」ということ ではありません ） 【注意点】 この方法で残った前件の要素が後件で残った事象の原因かどうかは、別途確かめる必要がある （差異法ほど強い蓋然性を示してはいない）。 前件の要素が複数残った場合(例：BとC)、BとCのどちら(または両方とも)が原因なのかは、この方法だけでは判らない。 【特徴】で述べた「既知の前件:後件を取り除くと、“前件が空になる”事態が生じ得る」は、注意点でもある。 図3-7a 剰余法の例 共変法：特定要素の変化に着目する 着目する事象を生じる事例を取り上げる。 前件の特定の要素だけを変化させて(値、数量、設定、etc.)、後件の変化を見る。 着目する事象aの変化を引き起こす特定の要素Aがあったら、それが事象aの原因（または、事象aと何かしらの因果関係によるつながりがある）と考えられます。 図3-8 共変法の概略 【特徴】 前件の特定の要素の 有無 ではなく、要素の 変化 (値、数量、設定、etc.)に着目した方法。 一致法、差異法、剰余法といった、消去法に基づく方法が適用できない/しづらい場合に、特定の要素を変化させて原因と結果の関係を推定する役に立つ。 他の方法が使える場合でも、因果関係が推定された後に「原因と考えられる要素Aの変化が結果と考えられる事象aにどんな影響を与えるか」を調べる役に立つ。 【注意点】 この方法だけでは、要素と事象の因果関係が確かめられない場合がある。 （前件の要素Aの変化が別の要素や事象を通してaに影響を与えている場合など） 前件の要素Aを変化させた時に、後件に何の変化も見られないからといって、要素Aが結果にまったく影響を与えていないとは言えない。 図3-8a 共変法の例 気をつけたい点 筆者自身のデバッグ経験・テスト経験を振り返ると、一致差異併用法、剰余法、共変法が活躍した記憶があります。 特定の要素だけを変化させたり、特定の要素の有無だけ変えたりという実験的な操作は、ソフトウェアの場合は比較的行ないやすいからでしょうか。 ミルの方法は起こった事象からその原因を見つけようとする際のガイドとして大いに参考になるものと思いますが、適用に当たって気をつけたい点がいくつかあります。 5つ(4つ)の方法、どれかひとつで原因を突き止められるとは限りません。 いくつかの方法を組み合わせて使うことも考えましょう。 いずれの方法も結論を導いた段階では蓋然的に正しいと言えるにとどまります。 結論を基にさらに調べる、原因から結果への演繹的な説明を考える、 などの作業が必要です。 また、方法は推論を補強はしますが、保証はしません。 「○○法を使っているから正しい推論であり、結論も正しいんだ」といった考えに囚われないようにしましょう。 発見を支えるのは観察（と、仮説） ミルの方法を活かすには・観察が大切 冒頭で触れたように、帰納的推論による発見を支えるのは“ 観察 ”（と、その補助として 事実の収集、記録(記憶) ）です。 前件(先行する事象群)や後件(後続する事象等)として取り上げる事項の 焦点を絞る 。 （すべてを見ようとするのはかえって見落としを招きやすい） 故障や不具合の内容に応じて、操作や入力、ソフトウェアの環境やデータ、ハードウェア環境、etc.。 生じた故障は動作か、データの変化か、状態異常か、外部への出力か、etc.。 同じく、 粒度感 にも気をつける。 大まかな原因を把握するなら、故障は概要レベルで捉え、前件や後件は大づかみに区別する、 因果関係の詳細を突き止めようとするなら、故障を詳細に記述し、前件や後件は詳細に区別する、etc.。 調べて見込みがなかったら、「調べ方や調べるところを変えよう」という判断も必要。 ミルの方法を活かすには・もう一点 帰納的推論による発見を支えるものには、「着目した事象にまつわる因果関係を調べるに当たり、ある程度推測を立てる」という態度もあります。 一般に、起こった事象(故障や不具合) だけ から何が原因(の候補)か当たりをつけるのは困難で、 「こういうことが原因となっているのではないか」といった推測が必要になります。 これも誰しもやっていることでおかしなことではありません。 この推測（ 説明仮説 ）が原因探求の道標になります。 「なんとなく・当てもなく原因を探す」のではなくて、「ある仮定に基づいた推測に沿っている」ことを意識しましょう。 （ソフトウェアの場合、仕様や設計やソースコードに基づけば推測しやすいですが、「思いがけない遠く離れた箇所の仕様/設計/実装」が影響を及ぼす場合や、外部環境要因が干渉する場合もありますし、仕様や設計が当てにならないことも……） 説明仮説に関わる推論は、アブダクションの回で取り上げます。第5回以降をお楽しみに。 ★ 次回は帰納的推論にもある“落とし穴”を紹介する予定です！ 参考文献 近藤洋逸, 好並英司 『論理学入門』 岩波書店 1979 鈴木美佐子 『論理的思考の技法Ⅱ』 法学書院 2008 藤野登 『論理学　伝統的形式論理学』 内田老鶴圃 1968 J.S.ミル(著), 大関将一(訳) 『論理学体系 : 論証と帰納 3』 春秋社 1958 米盛裕二 『アブダクション　仮説と発見の論理』 勁草書房 2007 図版に使用した画像の出典 Loose Drawing 人物画をお借りしています。 品質探偵コニャン：Produced by Sqripts . No Unauthorized Reproduction. 【連載】ソフトウェアエンジニアのための論理スキル［実務三年目からの発見力と仮説力］ 記事一覧 【第1回】見つけるための論理 【連載初回、全文公開中】 【第2回】 “共通項”を見つけ出す 【第3回】発見はよい観察とよい方法から The post 【第3回】発見はよい観察とよい方法から｜実務三年目からの発見力と仮説力 first appeared on Sqripts .

こんにちは、バックエンドエンジニアのまさです。 AI技術の急速な進化に伴い、従来のキーワード検索では対応できない「意味的な類似性」に基づく検索ニーズが急増しています。本記事では、 オープンソースRDBMSであるPostgreSQLにpgvector拡張を組み込むだけで、簡単にベクトル検索システムを構築する方法 を解説します。 ベクトル検索 とは、文章を数値ベクトルに変換して抽象的な意味を検索する技術であり、キーワード依存型の検索では捉えきれない「ユーザーが本当に求めている意図」を、 高い精度 で汲み取れる検索手法です。 この記事では、ベクトル検索をPostgreSQLに組み込む方法を、ハンズオン形式で環境構築を進めながら説明していきます。 ベクトル検索とは 3分で分かるベクトル検索の仕組み 従来のキーワード検索は、文字通りキーワードが一致するかどうかで検索結果を返します。しかし、言葉の表現は多様であり、ユーザーの意図と完全に一致するキーワードが使われるとは限りません。そこで登場するのが ベクトル検索 です。 ベクトル検索は、テキストや画像などのデータを、数値の集まりである ベクトル に変換します。このベクトルは、元のデータの意味的な特徴を捉えており、類似した意味を持つデータは、ベクトル空間上で近い位置に配置されます。 具体的な仕組み: エンベディング:  テキスト（質問や文章）を、事前に学習済みのAIモデル（例：OpenAIのtext-embedding-ada-002）を用いて、数値ベクトルに変換します。この処理をエンベディングと呼びます。 ベクトルデータベース:  エンベディングされたベクトルをデータベース（この例ではPostgreSQL + pgvector）に格納します。 類似度計算:  検索クエリも同様にベクトルに変換し、データベース内のベクトルとの類似度を計算します。類似度の高いベクトルを持つデータが、検索結果として返されます。 例: 「猫が好きな人におすすめの映画は？」という質問をベクトル検索にかけると、「猫」というキーワードが含まれていなくても、「猫が登場する映画」「猫を飼っている人が主人公の映画」など、意味的に関連性の高い映画が検索結果として表示される可能性があります。 つまり、ベクトル検索は、キーワードに縛られず、意味に基づいた柔軟な検索を実現する技術なのです。 PostgreSQL採用の5大メリット ベクトル検索システムを構築する上で、PostgreSQLを採用するメリットは多岐にわたります。以下に主な5つのメリットを挙げます。 拡張性:  pgvector拡張により、PostgreSQLにベクトル検索機能を追加できます。既存のデータベース環境を大きく変更する必要はありません。 コスト効率:  オープンソースであるため、高額なライセンス費用は不要です。必要なハードウェアリソースのみで運用できます。 信頼性:  PostgreSQLは長年の実績を持つ堅牢なRDBMSであり、高い信頼性と安定性を誇ります。 標準SQL対応:  既存のSQLクエリと組み合わせて、複雑な検索処理を記述できます。 コミュニティサポート:  世界中に活発なコミュニティが存在し、豊富な情報やサポートが得られます。 従来検索とのパフォーマンス比較表 検索方式 検索精度 検索速度 (データ量依存) 柔軟性 備考 キーワード検索 キーワード一致に依存。曖昧な表現や同義語に弱い。 高速 低い。キーワードの厳密な一致が必要。 シンプルな検索には適している。 ベクトル検索 意味的な類似性に基づくため、キーワードに依存しない。高い精度を実現。 データ量に依存。インデックス構造で高速化可能。 高い。ユーザーの意図を汲み取った柔軟な検索が可能。 大量のデータに対しては、適切なインデックス設計が重要。 全文検索 キーワード検索より高度な検索が可能だが、意味理解は限定的。 データ量に依存。 中程度。 日本語の形態素解析など、言語依存の処理が必要な場合がある。 補足: パフォーマンスは、データ量、ハードウェア、インデックス設計などに大きく左右されます。 上記比較表はあくまで一般的な傾向を示すものであり、実際のパフォーマンスは環境によって異なります。 専用のベクトルデータベースとの比較 専用のベクトルデータベース（例: Chroma, FAISS, Pinecone）とPostgreSQLの拡張機能であるpgvectorは、それぞれ異なる強みを持っています。ここでは、pgvectorと専用ベクトルデータベースとの違いや、それぞれのメリット・デメリットを解説します。 pgvectorの特徴 pgvectorは、PostgreSQLにベクトル検索機能を追加する拡張機能です。以下が主な特徴です： リレーショナルデータとの統合 ：ベクトルデータと従来のリレーショナルデータを同じデータベースで管理可能。 低コスト導入 ：既存のPostgreSQL環境に拡張機能として追加するだけで利用可能。 ACID準拠 ：トランザクション管理やセキュリティ機能をそのまま利用可能。 専用ベクトルデータベースの特徴 専用ベクトルデータベース（例: Chroma, FAISS, Pinecone）は、ベクトル検索に特化した設計がされています。以下が主な特徴です： 高速検索 ：高次元ベクトルに最適化されたインデックス設計（例: HNSW, IVF）。 スケーラビリティ ：分散システムによる水平スケーリングが容易。 多様なデータ形式対応 ：画像、音声、動画などの非構造化データも効率的に処理可能。 比較表 項目 pgvector 専用ベクトルデータベース（例: Chroma, FAISS） 導入コスト 低い（既存PostgreSQL環境で利用可能） 高い（新規インフラ構築が必要） 速度（大規模データ） 中程度（PostgreSQL依存） 高速（専用設計による最適化） スケーラビリティ 垂直スケール（ハードウェア増強が必要） 水平スケール（分散システム対応） 統合性 高い（SQLクエリでリレーショナルデータと統合） 低い（別途APIやミドルウェアが必要） ユースケース 小〜中規模データ、既存RDBMSとの統合 大規模データ、高速検索が求められるAI/MLワークフロー 学習コスト 低い（PostgreSQLユーザーに馴染みやすい） 中〜高（新しいツールやAPIの習得が必要） pgvectorのメリットとデメリット メリット 簡単な導入手順 ：PostgreSQL環境に拡張機能としてインストールするだけで利用可能。 低コスト運用 ：既存インフラを活用できるため、新たなサーバー構築が不要。 SQL統合性 ：従来のSQLクエリと組み合わせてハイブリッド検索が可能。 デメリット パフォーマンス限界 ：大規模データセットや超高次元ベクトルでは専用VectorDBに劣る。 水平スケーリング非対応 ：PostgreSQL自体が分散システムに最適化されていないため、大量トラフィックには不向き。 機能制約 ：画像や音声など非構造化データへの対応は限定的。 専用ベクトルデータベースのメリットとデメリット メリット 高速な類似検索 ：HNSWやIVFなど、高度なインデックスアルゴリズムを採用。 大規模データ対応 ：分散システムによる水平スケーリングで数十億件以上のベクトル処理も可能。 柔軟性 ：画像、音声、動画など多様なデータ形式に対応。 デメリット 導入・運用コストが高い ：新たなインフラ構築や運用管理が必要。 学習コストが高い ：新しいツールやAPIの習得が求められる。 統合性が低い ：従来のRDBMSとの連携には追加開発が必要。 選択基準 pgvectorを選ぶべきケース 既存のPostgreSQL環境を活用したい場合 中小規模のプロジェクトでコスト効率を重視する場合 リレーショナルデータとの統合性が重要な場合 専用VectorDBを選ぶべきケース 数千万〜数億件以上の大規模ベクトル検索を行う場合 非構造化データ（例: 画像、音声）の処理が必要な場合 高速性とスケーラビリティを最優先する場合 pgvectorは、PostgreSQLユーザーにとって手軽かつコスト効率の良い選択肢であり、中小規模プロジェクトには最適です。一方、専用VectorDBは、大規模かつ複雑なAI/MLワークフローにおいて圧倒的なパフォーマンスを発揮します。用途や要件に応じて、それぞれの特性を活かした選択を行うことが重要です。 環境構築 本章ではハンズオン形式で PostgreSQLコンテナのセットアップ から、 Streamlitを用いたフロントエンドの構築 、そしてそれらを連携させる Docker環境の設定 まで、必要な手順をわかりやすく解説します。この章の手順に従うことで、pgvectorを用いた簡単なベクトル検索システムを構築できます。 環境構成 上記のように非常にシンプルな構成をdocker composeで構築します。 ディレクトリ構成は以下のようになります。 ├── .streamlit │ └── secrets.toml *# DB接続情報* ├── docker-compose.yml ├── postgres │ ├── Dockerfile *# PG拡張機能インストール* │ └── initdb │ └── init.sql *# テーブル定義* └── streamlit ├── Dockerfile *# Python環境構築* ├── app.py *# メインアプリ* ├── embeddings.py *# ベクトル生成ロジック* ├── requirements.txt └── seed.py *# テストデータ生成* PostgreSQLコンテナの環境構築 PostgreSQLのデータベースを起動するコンテナ上に初期設定用のSQLファイルを作成します。 CREATE EXTENSION IF NOT EXISTS vector; -- サンプルテーブル作成（必要に応じてカスタマイズ） CREATE TABLE documents ( id SERIAL PRIMARY KEY, title TEXT, content TEXT, embedding VECTOR(1024) ); CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops); Streamlitコンテナの環境構築 メイン処理となるpythonコードを記述したファイルを作成します。 import streamlit as st import pandas as pd import numpy as np from datetime import datetime import psycopg2 from psycopg2.extras import execute_values from sqlalchemy.sql import text from streamlit.logger import get_logger from embedding import Embedding logger = get_logger(__name__) embedding = Embedding() # ページ設定 st.set_page_config( page_title="Vector Database Demo", page_icon="🔍", layout="wide" ) def get_embedding(text): return embedding.get_embedding([text])[0] # データベース接続関数 def get_connection(): return st.connection('postgresql', type='sql') # メインアプリケーション def main(): st.title("📊 Vector Database Demo") # サイドバーでの操作選択 operation = st.sidebar.selectbox( "操作を選択", ["データ表示", "データ追加", "ベクトル検索"] ) if operation == "データ表示": show_data() elif operation == "データ追加": add_data() elif operation == "ベクトル検索": vector_search() def show_data(): st.header("📋 登録データ一覧") conn = get_connection() # データ取得 query = "SELECT id, title,content FROM documents LIMIT 100" df = conn.query(query, ttl=0) if not df.empty: st.dataframe(df) else: st.info("データが登録されていません") def add_data(): st.header("➕ データ追加") # 入力フォーム with st.form("data_form"): title = st.text_input("タイトルを入力") content = st.text_area("テキストを入力") submitted = st.form_submit_button("登録") if submitted and content: conn = get_connection() # サンプルとして、ランダムな1536次元ベクトルを生成 # 実際のアプリケーションでは、適切なエンベッディングモデルを使用する embedding = get_embedding(title + " " + content) # データ登録 query = text(""" INSERT INTO documents (title, content, embedding) VALUES (:title, :content, :embedding) """) params = {"title": title, "content": content, "embedding": embedding} try: with conn.session as session: session.execute(query, params) session.commit() st.success("データを登録しました") except Exception as e: st.error(f"エラーが発生しました: {str(e)}") def vector_search(): st.header("🔍 ベクトル検索") search_text = st.text_input("検索テキストを入力") k = st.slider("表示件数", min_value=1, max_value=10, value=5) if st.button("検索") and search_text: # サンプルとして、ランダムなクエリベクトルを生成 # 実際のアプリケーションでは、入力テキストを適切にエンベッディング query_vector = get_embedding(search_text) conn = get_connection() # コサイン類似度による検索 query = """ SELECT title,content, 1 - (embedding <-> :query_vector) as similarity FROM documents ORDER BY embedding <-> :query_vector LIMIT :k """ params = {"query_vector": str(query_vector), "k": k} try: df = conn.query(query, params=params, ttl=0) if not df.empty: # 結果表示 for _, row in df.iterrows(): with st.expander(f"{row['title']} 類似度: {row['similarity']:.4f}"): st.write(row['content']) else: st.info("検索結果が見つかりませんでした") except Exception as e: st.error(f"検索中にエラーが発生しました: {str(e)}") # アプリケーション実行 if __name__ == "__main__": main() テキストの埋め込み処理を行うpythonコードを記述したファイルを作成します。 今回の例ではデフォルトで埋め込み用のモデルにmultilingual-e5-largeを使用するように設定しています。このモデルを変更することで検索時の傾向等を変えることが可能です。 intfloat/multilingual-e5-large · Hugging Face import torch.nn.functional as F from torch import Tensor from transformers import AutoTokenizer, AutoModel class Embedding: def __init__(self, model_name: str = 'intfloat/multilingual-e5-large'): self.model_name = model_name self.load_model() def load_model(self): self.tokenizer = AutoTokenizer.from_pretrained(self.model_name) self.model = AutoModel.from_pretrained(self.model_name) def average_pool( self, last_hidden_states: Tensor, attention_mask: Tensor ) -> Tensor: last_hidden = last_hidden_states.masked_fill(~attention_mask[..., None].bool(), 0.0) return last_hidden.sum(dim=1) / attention_mask.sum(dim=1)[..., None] def get_embedding(self, input_texts: list[str]) -> list[float]: batch_dict = self.tokenizer(input_texts, max_length=512, padding=True, truncation=True, return_tensors='pt') outputs = self.model(**batch_dict) embeddings = self.average_pool(outputs.last_hidden_state, batch_dict['attention_mask']) return F.normalize(embeddings, p=2, dim=1).tolist() 初期データの投入を行うpythonコードを記述したファイルを作成します。 単純にタイトルと内容をならべ、それらをデータベースに埋め込み表現と共に保存しています。 import psycopg2 import numpy as np from psycopg2.extras import execute_values from embedding import Embedding test_data = [ { "title": "Dockerコンテナのベストプラクティス2025年版", "content": "Dockerコンテナを本番環境で効率的に運用するためのベストプラクティスを解説します。イメージサイズの最適化、セキュリティ対策、ネットワーク設定、ボリューム管理など、実践的なトピックを網羅的にカバーします。マルチステージビルドの活用方法や、環境変数の適切な管理方法についても詳しく説明します。" }, { "title": "PyTorchによる深層学習モデルの最適化手法", "content": "PyTorchを使用した深層学習モデルのパフォーマンス最適化について解説します。バッチサイズの調整、学習率スケジューリング、データローダーの最適化、GPUメモリの効率的な使用方法など、実践的な最適化テクニックを紹介します。" }, { "title": "マイクロサービスアーキテクチャの設計パターン", "content": "マイクロサービスアーキテクチャを採用する際の主要な設計パターンについて解説します。サービス間通信、データ一貫性の確保、障害対策、モニタリング戦略など、実装時の重要なポイントを詳しく説明します。" }, { "title": "Kubernetes運用管理の実践ガイド", "content": "Kubernetesクラスタの効率的な運用管理方法について解説します。リソース管理、オートスケーリング、モニタリング、セキュリティ対策など、実運用で必要となる知識を体系的に説明します。" }, { "title": "効率的なデータベースインデックス設計", "content": "リレーショナルデータベースにおけるインデックス設計のベストプラクティスを解説します。クエリパフォーマンスの最適化、インデックス選択の基準、メンテナンス戦略など、実践的なアプローチを紹介します。" }, { "title": "GraphQLによるモダンAPIの構築", "content": "GraphQLを使用したAPIの設計と実装について解説します。スキーマ設計、リゾルバの実装、N+1問題の解決、キャッシュ戦略など、実践的な開発手法を紹介します。" }, { "title": "CI/CDパイプラインの自動化戦略", "content": "継続的インテグレーション/デリバリーパイプラインの効率的な構築方法について解説します。テスト自動化、デプロイ戦略、品質管理、モニタリングなど、実践的な自動化手法を紹介します。" }, { "title": "セキュアなWebアプリケーション開発", "content": "Webアプリケーションのセキュリティ対策について包括的に解説します。XSS対策、CSRF対策、認証・認可の実装、セキュアなセッション管理など、重要なセキュリティ考慮事項を説明します。" }, { "title": "効率的なキャッシュ戦略の実装", "content": "Webアプリケーションにおけるキャッシュ戦略の設計と実装について解説します。CDN、ブラウザキャッシュ、アプリケーションキャッシュ、データベースキャッシュなど、多層的なキャッシュ戦略を紹介します。" }, { "title": "大規模データ処理のベストプラクティス", "content": "大規模データ処理システムの設計と実装について解説します。バッチ処理、ストリーム処理、データパイプライン、スケーラビリティ確保など、実践的なアプローチを紹介します。" }, { "title": "ReactとTypeScriptによるフロントエンド開発", "content": "ReactとTypeScriptを組み合わせた最新のフロントエンド開発手法について解説します。型安全な開発、コンポーネント設計、状態管理、パフォーマンス最適化など、実践的な開発テクニックを紹介します。" }, { "title": "AWSでのスケーラブルなインフラ構築", "content": "AWSを使用したスケーラブルなインフラストラクチャの構築方法について解説します。オートスケーリング、負荷分散、障害対策、コスト最適化など、クラウドインフラの設計ポイントを説明します。" }, { "title": "効率的なログ管理とモニタリング", "content": "分散システムにおけるログ管理とモニタリングの実践的アプローチについて解説します。ログ収集、分析、可視化、アラート設定など、効果的な運用監視の方法を紹介します。" }, { "title": "マイクロフロントエンドアーキテクチャの実装", "content": "マイクロフロントエンドアーキテクチャの設計と実装について解説します。モジュール分割、統合戦略、ルーティング、状態管理など、フロントエンド開発の新しいアプローチを紹介します。" }, { "title": "NoSQLデータベースの設計パターン", "content": "NoSQLデータベースを使用する際の効果的な設計パターンについて解説します。データモデリング、クエリ最適化、スケーリング戦略など、実践的な使用方法を紹介します。" }, { "title": "機械学習モデルの本番環境デプロイ", "content": "機械学習モデルを本番環境にデプロイする際の実践的アプローチについて解説します。モデルのバージョン管理、スケーリング、モニタリング、再学習戦略など、運用上の重要ポイントを説明します。" }, { "title": "Terraformによるインフラのコード化", "content": "Terraformを使用したインフラストラクチャのコード化について解説します。リソース管理、モジュール設計、状態管理、チーム開発など、IaCの実践的な適用方法を紹介します。" }, { "title": "効率的なAPIバージョニング戦略", "content": "WebAPIのバージョニング戦略について実践的な方法を解説します。バージョン管理手法、下位互換性の確保、マイグレーション戦略など、長期的な API 運用のポイントを説明します。" }, { "title": "セキュアなマイクロサービス間通信", "content": "マイクロサービス環境におけるセキュアな通信方法について解説します。認証、認可、暗号化、証明書管理など、サービス間通信のセキュリティ確保方法を説明します。" }, { "title": "効率的なデータベースマイグレーション", "content": "大規模データベースのマイグレーション戦略について解説します。ダウンタイム最小化、データ整合性確保、ロールバック計画など、安全なマイグレーションの実施方法を紹介します。" } ] def insert_test_data(): conn = psycopg2.connect( dbname="vectordb", user="postgres", password="postgres", host="postgres", port="5432" ) cur = conn.cursor() embedding = Embedding() for data in test_data: # サンプルとして1536次元のランダムベクトルを生成 emb = embedding.get_embedding([data["title"] + " " + data["content"]])[0] cur.execute( "INSERT INTO documents (title, content, embedding) VALUES (%s, %s, %s)", (data["title"], data["content"], emb) ) conn.commit() cur.close() conn.close() if __name__ == "__main__": insert_test_data() データベースとの接続定義を記述したファイルを作成します。 [connections.postgresql] dialect = "postgresql" host = "postgres" port = 5432 database = "vectordb" username = "postgres" password = "postgres" 依存ライブラリを記述したファイルを作成します。 SQLAlchemy==2.0.35 streamlit==1.32.0 pandas==2.2.0 numpy==1.26.0 psycopg2-binary==2.9.9 torch==2.6.0 transformers==4.48.2 Docker環境のセットアップ まずはpostgresのDockerfileから作成をしていきます。 postgresベースのイメージにpgvectorのインストール処理を追加します。 FROM postgres:16.3 # pgvectorインストール RUN apt-get update && \\ apt-get install -y \\ build-essential \\ git \\ postgresql-server-dev-16 RUN git clone <https://github.com/pgvector/pgvector.git> /tmp/pgvector && \\ cd /tmp/pgvector && \\ make && \\ make install && \\ rm -rf /tmp/pgvector 続けてStreamlitのDockerfileを作成します。 FROM python:3.11-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt CMD ["streamlit", "run", "./streamlit/app.py", "--server.port=8501"] 最後にこれらのコンテナを束ねて管理するdocker-compose.ymlを作成します。 version: "3.9" services: postgres: build: ./postgres environment: POSTGRES_USER: postgres POSTGRES_PASSWORD: postgres POSTGRES_DB: vectordb volumes: - postgres_data:/var/lib/postgresql/data - ./postgres/initdb:/docker-entrypoint-initdb.d ports: - "5432:5432" networks: - app-network streamlit: build: ./streamlit volumes: - .:/app environment: - STREAMLIT_SERVER_PORT=8501 ports: - "8501:8501" depends_on: - postgres networks: - app-network volumes: postgres_data: networks: app-network: driver: bridge 動作確認 起動確認 以下のコマンドでコンテナのビルドを行います。 docker compose build 以下のコマンドでコンテナの起動を行います。 docker compose up -d ブラウザで以下のアドレスにアクセスします。 http://localhost:8501/ 最初はモデルを読み込むためロード中となり、下記のような画面が表示されるかと思いますが その後このような表示になれば、サーバーの起動に成功しています。 初期データの投入 データベースに初期データを投入する為、コンテナ上でコマンドを実行します。 まずはコンテナの状態の確認を行います。 $ docker compose ps NAME IMAGE COMMAND SERVICE CREATED STATUS PORTS pgvector-postgres-1 pgvector-postgres "docker-entrypoint.s…" postgres 2 hours ago Up 2 hours 0.0.0.0:5432->5432/tcp, :::5432->5432/tcp pgvector-streamlit-1 pgvector-streamlit "streamlit run ./str…" streamlit 2 hours ago Up 2 hours 0.0.0.0:8501->8501/tcp, :::8501->8501/tcp 上記で出力されたコンテナの内、streamlitのコンテナ上で以下のようにしてコマンドを実行します。 $ docker exec -it pgvector-streamlit-1 python streamlit/seed.py コマンド実行後に再度ブラウザで以下のアドレスにアクセスします。 http://localhost:8501/ 投入したデータが一覧で表示されるようになりました。 Vector検索の確認 先ほどアクセスした画面の「操作を選択」から「ベクトル検索」を選択します。 上記のような画面が表示されるかと思います。 試しにこちらの検索テキストに「MySQL」と入力して検索してみます。 上記のように結果が表示されました。内容としては以下のようなものですが、もちろん本文に「MySQL」という文言はありません。 内容の指向性や意味などからもっとも類似度の高い内容順に並べることができていることが確認できます。 おわりに 本記事で実践したPostgreSQLベクトル検索システムの構築は、AI時代のデータ活用における重要な第一歩です。 従来のリレーショナルデータベースの枠組みを超え、意味理解を組み込んだ次世代検索技術 を、既存インフラで実現する手法を具体例と共に解説しました。 本格的な導入を検討される方は、まずは pgvector公式ドキュメント と E5モデルに関しての記事 の精読をお勧めします。実際のプロダクション環境では、 インデックス再構築戦略 と メモリ最適化 が成否を分ける鍵となります。 最後に、本記事が皆様のAI/MLプロジェクト推進の一助となれば幸いです。 The post PostgreSQLで実践するベクトル検索入門：AI時代のRDBMS活用術 first appeared on Sqripts .

こんにちは、QAコンサルタントの ヤマダ です。 私はこのたび、JSTQB® Advanced Level テストマネージャ試験に合格しました。   本記事では、試験合格のために活用した書籍「 科学的根拠に基づく最高の勉強法 」の内容を解説するとともに、JSTQB試験の概要、そして実践した勉強法を共有します。 書籍の紹介：「科学的根拠に基づく最高の勉強法」 この書籍は、医師であり学習法の専門家である著者が、最新の研究論文やデータを基に、科学的に効果が証明された学習法を紹介したものです。特に、次のようなポイントが大きな特徴です。 効果が低い学習法 日常的に行われがちな以下の方法は、実は非効率とされています： 繰り返し読む ：一見効果的に思えるが、記憶の定着にはほとんど寄与しない。 ノートに書き写す ：時間がかかる割に、記憶や理解が深まらない。 ハイライトや下線を引く ：重要箇所をマークする行為そのものに学習効果はない。 効果が高い学習法 1. アクティブリコール（能動的記憶再生） 学習した知識を記憶から引き出すことで、記憶が強化されます。たとえば問題を解く、クイズ形式で学ぶといった方法が該当します。 2. 分散学習 短時間で詰め込むのではなく、間隔を空けて繰り返し復習することで、記憶の定着率が向上します。たとえば、1日おきに復習する、週ごとに学び直すといった方法です。 3. 精緻的質問と自己説明 精緻的質問 ：学んだ内容に対して「なぜそうなるのか」と問いかけ、深掘りして理解を深めます。 自己説明 ：学習した内容を自分の言葉で説明することで、曖昧な理解を防ぎます。 これらの方法を組み合わせることで、学習効率を大幅に向上させることができます。 JSTQB®の試験とテストマネージャモジュールの紹介 JSTQB®の概要 JSTQB®（Japan Software Testing Qualifications Board）は、ソフトウェアテストの知識と技能を体系的に学び、その理解度を証明する資格試験を提供する団体です。ISTQB®（International Software Testing Qualifications Board）の国際基準に基づいており、ソフトウェアテストの標準資格として広く認知されています。 試験の構成 JSTQB®試験には以下の3つのレベルがあります。 1. Foundation Level 初心者向け。テストの基本概念、設計技法、テスト管理の基礎が試験範囲に含まれます。 2. Advanced Level 経験者向け。3つのモジュールに分かれています。 テストマネージャ ：テスト計画やプロジェクト管理に特化。 テストアナリスト ：要件分析やテスト設計技法に焦点。   テクニカルテストアナリスト ：テストツールや自動化の活用。 3. Expert Level   ソフトウェアテストの最上級資格。リーダーシップやプロセス改善に関する知識を問われます。 Advanced Level テストマネージャの試験内容 テストマネージャは、テストプロジェクトを計画・実行・管理するスキルを証明するためのモジュールです。以下が主な試験範囲です。 テストプロセス ：テスト戦略の作成、計画、モニタリング、評価。 リスクベーステスト ：リスクを特定し、優先順位を付けてテスト計画を策定。 テストチームの管理 ：チームビルディングやステークホルダーとのコミュニケーション。 品質保証 ：メトリクス分析やプロセス改善の実施。 ツールと自動化 ：適切なツールの選定と導入。 実践した勉強法 以下の3ステップを繰り返しながら学習を進めました。このプロセス全体に書籍で紹介されている学習法を取り入れています。 1. シラバスを読む 方法とポイント 流し読みからスタート ：まずはシラバス全体を流し読みし、試験範囲を大まかに把握。 不明点をメモ ：分からない箇所や重要そうな部分をメモに記録し、後のプロセスで補強。 関連情報を調査 ：シラバスに記載された内容について理解が曖昧な部分は、ChatGPTやWeb検索で調査。 活用した勉強法 分散学習 ：シラバスを一度に全部読むのではなく、複数回に分けて学習しました。1日目に全体を流し読み、2日目以降に重点的な箇所を再度読むことで記憶を強化しました。 精緻的質問 ：各セクションで「なぜこの方法が重要なのか」「どうしてこれが推奨されるのか」を自分に問いかけながら学習しました。 2. 問題を解く 方法とポイント 問題演習の徹底 ：非認定問題集を使いながら繰り返し問題を解き、シラバスの内容を応用する練習を行いました。 間違いの記録 ：間違えた問題について、問題番号、対応するシラバスの箇所と間違えた原因をメモ。 ChatGPTを活用 ：シラバスと問題集をChatGPTにインプットし、問題集に含まれていない新しい問題を生成してもらうことで、幅広い演習を実施しました。 活用した勉強法 アクティブリコール ：問題を解くことで、学習した知識を記憶から引き出し、記憶を強化しました。 自己説明 ：解いた問題について「なぜこの答えが正解なのか」「他の選択肢が不正解の理由」を自分に説明しました。これにより、選択肢の背景や理論を深く理解できました。 3. 振り返り 方法とポイント 振り返りは学習の各ステップで必ず行い、学習効率を高めました。振り返りでは、これまでに取った メモ を活用して原因分析を行います。 メモの活用 ：シラバスを読んだ際に書き留めた不明点や、問題を解いた際に記録した間違えた箇所やその理由を参照。 原因分析 ：「知識不足」「問題文の読み違い」「思い込み」などに分類し、それぞれの対策を実施。 弱点補強 ：特に苦手な分野については、再度シラバスを読み直したり、問題を解き直したりして克服を図りました。 進捗の可視化 ：日々記録を取っているため、これまで間違えていた問題が出来るようになっていることが分かり、自分の成長を確認しました。 活用した勉強法 分散学習 ：振り返りを何度も行い、時間を空けて同じ内容を復習することで、知識の定着を強化しました。新しい知識よりも復習を重視しました。 精緻的質問 ：「なぜ間違えたのか」「どのように考えれば正解にたどり着けたのか」を繰り返し問いかけ、理解を深めました。 スキマ時間を活用した学習 スキマ時間を積極的に活用することも、 分散学習 の効果を得るための重要な手段です。以下のように、短時間の学習を複数回に分けて行いました。 通勤時間 ：シラバスの読み込みや、理解が曖昧な箇所の復習。 昼休み ：問題集を1問でも解く。 夜の15分 ：振り返りや弱点補強。 まとめ 「科学的根拠に基づく最高の勉強法」を取り入れることで、学習効率を向上させることができたと思います。この方法は、資格試験だけでなく、日常の学びやスキルアップにも応用可能です。これから受験を目指す方は、科学的なアプローチを試してみてはいかがでしょうか？ The post JSTQB Advanced Level テストマネージャ勉強法　-科学的根拠に基づく最高の勉強法を参考にして- first appeared on Sqripts .