結論：やめなくてよい

以上・・・というわけにはいかない
仕様駆動開発自体、まだまだ概念が生まれて間もないため、試行錯誤の段階
一概に良い悪いはまだつけがたいため、使いながら良い方法を模索していきましょうという感じです

そもそも仕様駆動開発とは

SDD(Specification Driven Development)
Vive Cordingと対案となる手法
AIにコードを描かせる前に、きちんと仕様を決めて、その仕様書をもとにコーディングを行わせましょうという考え方
利点として：
　仕様書が残る(継続してメンテが必要になるが)
　他AIエージェントに引き継ぐ際も、ドキュメント(コンテキスト)が引き継ぎやすい
　コーディング前のレビューで間違いを発見できる

SDDを支えるツール

AmazonのKiroが有名
IDEレベルで仕様書の作成を矯正する仕組み

GitHubのSpecKitもSDDを実現するためのツール
今回のデモでは、CodexアプリからSpecKitのコマンドを呼び出し、VSCode上で変更点を確認するようなフローをとっていた

自分のプロジェクトにどう適用するか

自分はGoogle AntiGravityを利用しているので、よい方法がないかClaudeに相談してみました
結果として、いきなりツールを入れるのではなく、まずはフォルダ分けから初めてみるのが良いとのことだったので、そこから初めて見ようと思います(/specs, /tasks など　どの中に使用やタスクが記載された.mdファイルを置く )

SDDはあくまで開発手法であり、KiroやSpecKitを利用しないと実現できない、というわけではないので・・・

以上

ということで、勉強会に参加してきましたという報告でした
報告だけだと意味がないので、次に開発する機能からSDDを取り入れてみたいと思いました

仕様駆動開発 実践入門 ／ 日経BP社

created by Rinker

¥3,850 (2026/06/13 23:47:56時点 楽天市場調べ-詳細)

• Amazon
• 楽天市場
• Yahooショッピング

Visual Studio Codeで学ぶ！GitHub Copilot入門 [ 山田 裕進 ]

created by Rinker

¥3,080 (2026/06/13 23:47:56時点 楽天市場調べ-詳細)

• Amazon
• 楽天市場
• Yahooショッピング

投稿 仕様駆動開発はやめたほうがいいのか は Sheltie Garage Tech に最初に表示されました。

まとめ

タイトルの通り、基本的なテストの手法や計測すべき事項、AIテストなどの最近の話題に触れられていて、テストの基本を押さえることが出居ました。
ただ、知識0といいつつ何の説明もなく専門用語がちりばめられていたり、語り口調(○○みたいな・・・)の記載が随所に見られるので、本当に知識ゼロで読み進めるのは少し難しい印象を感じました。

章別、覚えておきたいところ

1章：はじめに

完全無欠のテストを実施することはテストパターンが増えすぎるため不可能！
また、よくテストは新人にやらせる見たな風潮があるが、テストこそ経験豊富なベテランが行うべき(不具合が残ったまま出荷すると大きな損害となるため)

2章：ソフトウェアテストの基本

ブラックボックステスト：入力と出力だけに注目する
ホワイトボックステスト：プログラムの内部構造に注目する

制御パステストの種類
ステートメントカバレッジ：制御文(if文など)を最低1回は実行する
ブランチカバレッジ：制御文の全パターンを実行する

カバレッジは75%以上が推奨

カバレッジでは検出されないバグがあることを覚えておく（外部から受け取るデータの不正など）

3章：エンジニアが最もよく使う手法

テストは「入力」「出力」「データ保存」「計算」の4種類のテストが行えれば良い

境界値テストは境界となる値を使用する
if(a < 5)のようなプログラムをテストするときは4,5といった値を使用する

複雑な入出力テストはディシジョンテーブルを利用する
GUIは状態遷移マトリックスを利用するとよい

ブラックボックステストのまとめ
入力エリアがある：境界値テスト
入力エリアが複数あり、相互に影響している：ディシジョンテーブル
GUI自体の遷移がある：状態遷移テスト

4章：探索的テスト

探索的テストはテスト設計とテスト実行を同時に行うこと
製品を学習しつつテストを設計、実行し結果を報告、そのサイクルで成熟していく　という流れを同時並行で行う

要はテスト対象の製品を理解し、仕様の穴（メニューからは操作できないが、同等の機能を実行するショートカットからだと実行できるなど）を見つけるのが大切という理解

探索的テストはクリテリア（テスト成功、テスト失敗とする条件）を決める

探索的テストはユーザービリティに関する検出に特に有効

5章：要求仕様のテスト

要求を書き出すときは「テスト可能な要求」である必要がある
例：多くのファイルを処理したい→多く、ではテストできない
　　同時に20ファイルまで開けるようにしたい→テスト可能

ユーザーストーリーも作成する
ユーザーストーリーはプロダクトオーナーと開発チームの約束事として機能する

TDDについても、この章で触れられていた(テスト駆動開発)
筆者としてTDDは推していたが日本国内での導入事例が少ないことを嘆いていた

6章：非機能要求のテスト

非機能要求とは
・パフォーマンス
・セキュリティ
・データ容量
などのこと

ファジングツールや静的解析ツールなどを利用してテストを行う

信頼度成長曲線という用語についても触れられていた(時間の経過とともにバグ数も減っていく曲線)

7章：テストの自動化という悪魔

テスト自動化の失敗についての章
要は「自動化すべきところと、しないほうが良いところを見極めましょう」という内容

単体テストレベルは自動化したほうが良い
逆にUIテストなどの場合は自動化しないほうが良い(変化が多いため、テストコードのメンテナンスにコストがかかるため)

8章：ソフトウェアテスト運用の基本

テストプランの書き方：IEEE829というテストプランの書式が用意されており、これに沿って作るのが良いとのこと
(多少のカスタマイズは可能)

テスト計画について、終盤に人員を投入して早く終わらせようとするのは悪手(デスマプロジェクトに見られる)
製品への知識が乏しい人員が増えたところで、教育にコストがかかったり、理解不足のままテストを行うことで品質が低下する可能性がある

テストケースの書き方として、「誰がテストしても同じ状況が再現できる」ように記載する必要がある
例：メモ帳のテストの場合
ダメなパターン：ファイルを保存する
良いパターン：メニューの保存ボタンからファイルを保存し、名称をtest.txtとしてC:\に保存する

9章：ソフトウェア品質管理の基本

品質を目に見えるものにするため、メトリクスを計測する必要がある
計測可能なものとして
・バグ数
・バグ修正にかかった時間
・コードの複雑度(と複雑度に応じたバグ数)
など

メトリクスは品質を図るもので、人に適用してはいけない
例：バグをたくさん見つけた人に報奨金→プログラマとテスターが組んで、わざとバグを仕込む不正が発生した

10章：新しいテスト技術

AIのようなアプリケーションは、従来のようなテスト手法が利用できない
(入力パラメータに対して、出力パラメータが一定ではないため)

その場合メタモルフィックテストといった新しい手法を用いる
メタモルフィックテスト：似たような入力を行い、似たような出力になるのか確認するテスト
例：パンダの画像をAIに入力→AIがパンダと答える→OK
　　パンダの画像を反転してAIに入力→AIがクマと答える→NG

カオスエンジニアリングについても触れられていた
カオスエンジニアリングはシステムの一部に障害が発生したときに、ほかシステムに影響が出ないか確認するテスト
AWSにはカオスエンジニアリングを実行するためのツールが準備されているとのこと

以上

個人的なまとめでした
今後AIにテストコード作成の指示を出すときは、それぞれの関数の仕様を把握したうえで境界チェックやカバレッジ、特に重要な処理を意識して支持を出したいところです

知識ゼロから学ぶソフトウェアテスト 第3版 アジャイル・AI時代の必携教科書 [ 高橋 寿一 ]

created by Rinker

¥2,750 (2026/06/13 23:47:56時点 楽天市場調べ-詳細)

• Amazon
• 楽天市場
• Yahooショッピング

投稿 個人的まとめ：知識ゼロから学ぶソフトウェアテスト は Sheltie Garage Tech に最初に表示されました。

このはぴば！2025とは

GMOインターネットグループが提供しているVPSサービス「GMO ConoHa」の応援団長「美雲このは」ちゃんの誕生日を祝うイベントです
オンライン、オフラインどちらでも参加OKで、オフラインではオンラインで配信されない技術者のテックトークに参加することができました

会場の様子

会場は、なんと写真撮影OK　ということで、数枚写真を取ってきました

正直、結構気合が入ったイベントで、展示物、新サービスの体験エリア、謎の二足歩行ロボが闊歩していたりとなかなかに楽しめる会場になっていました

今回はLT登壇として参加したので、席は登壇者専用の席に案内されました
そこで他の登壇者の方と挨拶

GMO社員の方のテックトーク終了後、一般LT枠での発表でした
その後はこのはちゃんのコンテンツを楽しむという内容です

このはちゃんのコンテンツは、Youtubeのアンケート機能を利用して物語が変化するという内容
なかなか凝った作りで、おそらくリアルタイムで対応していたのではないかと予想しています
コンテンツの最後にはYoutubeコメントに対してこのはちゃんがきちんと返事をするというサプライズ付き！

ノベリティも結構豪華で、ミネラルウォーター、綿菓子(!)、ペットボトルケース、ステッカーが入っていました
綿あめは見た目が青色ということでなかなかすごい色でしたが、結構美味しかったです

全編通してキャラクターへの愛を感じる内容になっており、よくできたイベントだなぁと感心しました
これで参加料は無料なので、また来年参加したいなと思いました

LT登壇の反省会

LT登壇は1人5分の持ち時間で、ConoHaに関連する内容を発表すると言うものでした
自分は個人開発したWebサービスのインフラにConoHaを利用しているため、その内容を発表しました

反省点としては、発表した後に考えると伝わりにくかったなと主部分がいくつかあり、ああすればよかったなと発表後に思うところがいくつかありました
一人でスライドを作っているので、やっぱり第三者に見てもらうということは大事だなと痛感しました

終わりに

このはぴば！2025に参加してきました、というメモ書きでした
このブログの内容よりも、「こういうイベントあるんだ！」ということを知ってもらえることが大事かなと思います
気になったら、ぜひ来年会場に足を運んでみてください

個人的には、知り合いとか友達が参加している方がもっと楽しめると思いますよ

Linux教科書 LPICレベル1 Version5.0対応 （EXAMPRESS） [ 中島 能和 ]

created by Rinker

• Amazon
• 楽天市場
• Yahooショッピング

AWSで実現するモダンアプリケーション入門 〜サーバーレス、コンテナ、マイクロサービスで何ができるのか【電子書籍】[ 落水恭介 ]

created by Rinker

• Amazon
• 楽天市場
• Yahooショッピング

投稿 このはぴば！2025に参加してきました は Sheltie Garage Tech に最初に表示されました。

kotlinといえばAndroidアプリに利用されるというイメージが強くて、あまりサーバサイド開発に用いられることは少ない印象ですが、実際に自分が今働いている会社でもサーバサイド開発に利用されています。

セッションごとの一言感想

Java開発者向けのKotlin Gradleビルドスクリプト入門

KotlinDSLに関する話題。Kotlin特有の文法ルールについての解説。関数の最後にラムダ式を取る場合、カッコの外に書けるなどKotlin特有の文法にも触れている。
KotlinDSLはパット見意味不明な記述に見えるので、このセッションは時間を取ってみなして見たいところです。

Kotlin と Java 徹底比較 (バイトコード編)

これは仕事に集中していたためきちんと見れず・・・ 見直し予定

Kotlin初心者がKotlinライブラリをJavaコードに読み替えて理解してみた

これは仕事に集中していたためきちんと見れず・・・ 見直し予定

KotlinのUnit Testの事例

kotestに関しての話題。テストについてはJUnitが現役で利用されているので、モダンな環境に移行するときにテストフレームワークも切り替えても良いかもと思った。時間を取って触りの部分は試してみたいところ。

5分LT: 『JavaのBuilderPatternはKotlinでいうと？』

kotlin自体にBuilderPatternの思想が組み込まれているという話（確か・・・）
こちらも仕事に集中していてほぼ聞けず、見直し予定。

状態管理で理解するKotlinのsealed classおよび周辺機能

こちらの仕事でほぼ聞けず・・・

結果

こうやって見直して見ると、8割ほどきちんと聞けてなかった・・・
それがわかっただけでも、アウトプットした意味はあったのかな・・・

投稿 Server-Side Kotlin Meetup は Sheltie Garage Tech に最初に表示されました。

勉強会に参加しても、聞くだけだとふーんで終わってしまうので、簡単にブログにアウトプットすることにしました。

大きく2つのテーマで講演がアリました

「フレームワークで脆弱性対策されているのに現実のアプリケーションに脆弱性が減らないワケ」

セキュリティの第一人者である徳丸氏の講演
ウェブフレームワークが数多く登場しているにも関わらず脆弱なアプリケーションが亡くならない理由を解説していた。
ざっくりまとめると以下の通り。

PHP参考書の惨状

過去発行されたPHP入門書は脆弱性を含んだ例を解説していることがあるため、そのままのコードを利用するのは危険な場合がある

SQLインジェクション

フレームワーク提供のO/Rマッパーを利用していればフレゲルことがほとんどである
フレームワーク提供のO/Rマッパーでは実現できないSQLが存在しており、そのSQLを実行するためにRaw(SQLをそのまま記述できるメソッド)を利用したときに脆弱性が発生することがある
SQLインジェクションを防ぐにはプレースホルダを利用するのが良い

XSS

テンプレートエンジンを利用していればHTMLエスケープが行われる・・・わけではなく、サニタイズを行うため別途ヘルパー関数を利用する必要がある
<img src=”/” onerror=”alert(1)” /> このような記述でXSSが実現できる
Laravelの場合であれば「Js::from()」のようなメソッドを利用する必要あり

認可不備

これは本来見れては行けない情報が見れてしまうということ
認可不備があると、URLパラメータとしてユーザーIDを利用している場合、ユーザーIDを変更することで他の人の情報が見れてしまう
そんな雑な作りにはなっていないだろうと考えがちだが、意外と多い

CSRF

これもフレームワークの機能を利用していれば防げる脆弱性である
が、まれにGETメソッドで更新処理を行っている場合があり、そのような場合にCSRFが成立する場合がある

まとめ

フレームワークを導入したからといって、すべての脆弱性に自動で対応されるわけではない
フレームワークの特性を理解し、脆弱性を作り込まないように開発者が意識することが大事である
逆にフレームワークのような便利なものが出てきたから、セキュリティに対する学習がおろそかになっているかもしれない

アジャイル開発に求められるセキュリティ

アプリケーションの開発サイクルは日に日に短くなっている
アマゾンでは１時間で1000デプロイしてやる　みたいな勢いらしい

アプリケーションの開発サイクルは短くなる一方、セキュリティのチェック感覚は長いまま
セキュリティチェックもアジャイルのように短い間隔で回していく必要がある。どうするか？

自動化できるところは自動化する。脆弱性チェックを自動化するツールは存在しているため、そのようなツールを利用して脆弱性チェックを自動化する

BugBountyという仕組みがある。ホワイトハッカーに自社の脆弱性やバグを発見してもらい、報酬を払う仕組み。日本ではあまり普及していないが、任天堂にも導入事例があるそうだ。

以上

せっかく勉強会に参加したので、ひとまずアウトプットしてみました
資料がないとなかなか分かりづらい（自分も多分、後で読んでもわからない）と思うが、聞くだけで終わらず、今後は何かしらアウトプットしていきたい。

投稿 勉強会参加　Security Study #1 「Webアプリケーションセキュリティ」 は Sheltie Garage Tech に最初に表示されました。