こんにちは。エンジニアの maimai です。
このブログはギークフィードアドベントカレンダー2025の11日目の記事です。
他の記事もぜひチェックしてみてください！
目次
自己紹介
クラウド開発事業部所属の maimai です。
普段は 既存システムの保守・開発・テストを行いながら開発チームをリードする役割しています。エンジニア歴は 25年で、今は主に PHP を使った開発をしています。とはいえ、最近はコーディングより説明資料を書いている時間のほうが長かったりします。
趣味は音楽で、歌を歌ったりフルートを吹いたりしています。これから春までは発表会やステージが続いていて、練習と体調管理に気をつけています！
最近「鼻うがい」をはじめました。鼻やのどの乾燥が気になるときにやると、すっきりしますよ。風邪をひきかけても悪化しにくいような気がします（個人の感想です）。
普段使ってるAIツール
日常的に以下のAIツールを活用しています。といっても他のメンバーよりは使ってないかも。
- GitHub Copilot: VSCodeと連動していて使いやすいので。コードを書くときの確認とかに使ってます。今回のルールみたいな使い方ではなくて、コードの書き方に迷った時のサポートとかコードレビューとかに使ってます。
- Amazon Q Developer CLI: コードに関係なくてもちょっと相談したいこととか調べたいことがあるときに使ってます。スケジュール感の参考にしたりするときも。（最近Kiro CLIになりました）
企画概要とゴール
今回、「フルAI開発バトル」という企画に参加しました。
ルールはシンプルかつ過酷です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
# 禁止事項：エディタで直接コードを書く・修正すること - 許されるのは「AIへの指示」のみ。人間の役割は「Architect/Reviewer」、つまりAIをマネジメントして成果物を判断することです。 # お題 社員の生産性を上げる日々の業務管理ツールを作ってください。 ## 必須要件： - KiroとPlaywright MCPを使うこと - スペック駆動開発を行うこと（vibe codingはNG） - Todoを追加・編集・削除できること - 追加は画面上部のフォームから可能 - 編集・削除は各行の操作ボタンで行う - 一覧でTodoを確認できること - 一覧にはタイトル、担当者、期限を表示 - サクサク軽く操作できること - 画面は1ページで完結 - PlaywrightでCRUD周りのテストをすること |
詳しいルールや目的はアドベントカレンダー1日目の記事で紹介しております。
作業プロセス
要件の理解と整理
- AWSにデプロイするWebアプリケーション
- タスクの追加、編集、削除、一覧表示ができる
- ログイン機能は不要
- 1ページで完結する
などなど書かれていることは満たす必要があります。ただ、文章の行間の解釈はさまざまなので、確認は必要そうです。
「ログイン機能は不要」とあるので、第一印象ではあくまで個人で使う想定なのかな？と考えました。であれば、URLで識別して複数ユーザーで使い分けることもできそうです。
でも業務の一環として使うなら（ふつうは）複数ユーザーで管理したいよな…。佐藤さんの要求がとにかくフワッとしているので、この辺は確認していく必要がありそうです。
運営への質問事項
「ログイン機能は不要」というところが気になり、いくつか質問しました。
- 個人で利用する前提？ → No.（複数の社員で使いたい）
- URLで個人を振り分けるのはあり？ →なし（タスクの一覧を社員で共有したい）→この時点で、当初の私の想定と違っていたことがわかりました。質問してよかった。
- タスクを入力した人以外が「完了」してもいいの？→ほんとはよくないけど、ID/PWを管理したくないからログインが面倒。→ログイン以外の方法で、手間を取らせずにユーザーを識別できればより良いものができそう？と思いました。
ここまでを踏まえて、Kiroとやりとりして対策を考えました。こんな感じで聞いてみます。
|
1 2 3 |
要件に追加する前の検討として一緒に検討してほしい。 ユーザー認証不要という要件ではあるが、複数ユーザーで操作する前提のためセキュリティ上は認証があったほうがよいと考えている。 エンドユーザーは「ID・パスワードを忘れてしまうし、ログインが面倒」と言っている。 |
複数案が出されたのですが、使い勝手やセキュリティ面を考慮して、
|
1 2 3 4 5 |
「ブラウザ識別子 + ニックネーム表示」の組み合わせが良いかもしれません： ブラウザIDで所有権を判定 でも画面上はニックネームを表示 データが消えたら再度ニックネームを入力（新しいIDが発行される） |
こんな方向性はどうかなと結論を出しました。
それを踏まえて、運営にもうちょっと聞こうかなと思ったら…、佐藤さんが退勤してしまいました。（あるある！）
ということなので、最終確認はあきらめて、ログインなしで個人が特定できる方向で要件追加していくことにしました。
Specs定義
要件を整理した上で、スペック駆動開発の第一歩として、Kiroに要件定義を依頼しました。
指示に至るまでの思考プロセス
最初は自分で整理した仕様をKiroに入力しようとしましたが、収集つかなくなりそうに。途中で軌道修正しました。
まず佐藤さんの提示要件をそのままインプットして、補足が必要なものを追加していくことにしました。
Kiroへの指示
requirements.md の完成までには以下の入力をしました。何度か方針を修正しました。まずは最初に提示された要件をそのまま。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
以下の要件でタスク管理ツールを構築したい。足りない部分はこの後補足していく。 機能要件 タスクの追加(画面上部のフォームからテキスト入力)、編集、削除、一覧表示(タイトル、担当者、期限を表示) ログイン機能は不要 操作性 画面は1ページで完結。サクサク軽く動いて、直感的に操作できること 編集・削除は各行のボタンで可能 データ保持 ブラウザを閉じてもデータが消えないこと 品質保証 Playwright MCPを活用し、E2Eテストが通っていること |
運営側と調整した内容を追加しました。
|
1 2 3 |
ユーザー認証は不要だが、複数のユーザーで使用することを想定している。タスクの一覧は全ユーザーで共有する。 デプロイ先はAWSにしたい。 完了したタスクを元に戻す機能も追加したい。 |
「完了したタスクを元に戻す機能も追加したい。」というのは後出しの要件でした。要件の追加、よくありますね。
|
1 |
AWSへのデプロイをIaCで管理できるようにしたい。E2Eテストが完了していなければデプロイ不可にしてほしい。 |
これは明示的な要件ではないですが、今後の運用を楽にするためにはやっておきたいので追加しておきました。（本来は非機能要件として確認の上で追加すべきでしょうね）のちにこれに苦しめられるとは…。（AWSへのデプロイにすごい時間がかかってしまった）
最後に、ずっと引っかかっていた「ログイン機能は不要」について。
|
1 2 3 4 |
ブラウザIDで所有権を判定 でも画面上はニックネームを表示 データが消えたら再度ニックネームを入力（新しいIDが発行される） の方向で要件追加します。 |
としました。（運営側と合意までいかなかったですが。こちらも本来は合意してから追加すべきですよね。あとからひと悶着ありそう）
Kiroの出力
- requirements.md
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 |
# 要件定義書 ## はじめに このドキュメントは、AWS環境にデプロイされる軽量なタスク管理Webアプリケーションの要件を定義します。ユーザーはタスクの作成、編集、削除、完了マーク、一覧表示を行うことができます。シンプルで直観的な単一画面のインターフェースを通じて、日々のタスクを効率的に管理できます。すべての操作は1つの画面で完結し、ページ遷移は発生しません。ログイン機能は不要ですが、ブラウザ識別子とニックネームによる簡易的なユーザー識別を行い、各タスクは作成者のみが編集・削除できます。複数のユーザーが同じタスクリストを共有して閲覧できます。データはサーバー側に保存され、ブラウザを閉じても失われません。 ## 用語集 - **System**: タスク管理アプリケーション全体 - **User**: アプリケーションを使用してタスクを管理する人（認証不要） - **Browser ID**: ブラウザのLocal Storageに保存される一意の識別子（自動生成） - **Nickname**: ユーザーが設定する表示名 - **Task Owner**: タスクを作成したユーザー（Browser IDで識別） - **Task**: ユーザーが完了する必要がある作業項目（タイトル、担当者、期限、完了ステータス、作成者IDを含む） - **Task List**: すべてのタスクのコレクション（全ユーザーで共有） - **Task Status**: タスクの完了状態（未完了または完了） - **Backend**: サーバーサイドロジックとデータ管理（AWS Lambda、API Gateway） - **Database**: タスクデータを永続化するストレージ（DynamoDB） - **Task Form**: タスクを追加または編集するための入力フォーム ## 要件 ### 要件 1 **ユーザーストーリー:** ユーザーとして、初回アクセス時にニックネームを設定したい。そうすることで、ログイン操作なしで自分を識別できる。 #### 受入基準 1. WHEN ユーザーが初めてアプリケーションにアクセスする THEN THE System SHALL ニックネーム入力ダイアログを表示する 2. WHEN ユーザーがニックネームを入力して確定する THEN THE System SHALL 一意のBrowser IDを生成してLocal Storageに保存する 3. WHEN Browser IDとNicknameが保存される THEN THE System SHALL ニックネームをDatabase に保存する 4. WHEN ユーザーが2回目以降にアクセスする THEN THE System SHALL Local StorageからBrowser IDを読み込んでニックネーム入力をスキップする 5. WHEN Local StorageのBrowser IDが削除されている THEN THE System SHALL 再度ニックネーム入力ダイアログを表示する ### 要件 2 **ユーザーストーリー:** ユーザーとして、新しいタスクをタスクリストに追加したい。そうすることで、完了する必要があることを記録し整理できる。 #### 受入基準 1. WHEN ユーザーが画面上部のフォームにタイトル、担当者、期限を入力して追加ボタンをクリックする THEN THE System SHALL 新しいタスクを作成してリストに追加する 2. WHEN ユーザーが空のタイトルでタスクを追加しようとする THEN THE System SHALL 追加を防止してエラーメッセージを表示する 3. WHEN 新しいタスクが作成される THEN THE System SHALL タスクに一意の識別子を割り当てる 4. WHEN タスクが追加される THEN THE System SHALL タスクを Database に即座に保存する 5. WHEN タスクが正常に追加される THEN THE System SHALL 入力フィールドをクリアする 6. WHEN 新しいタスクが作成される THEN THE System SHALL タスクのステータスを未完了に設定する 7. WHEN 新しいタスクが作成される THEN THE System SHALL 現在のユーザーのBrowser IDを作成者IDとして記録する ### 要件 3 **ユーザーストーリー:** ユーザーとして、既存のタスクを一覧表示したい。そうすることで、何をする必要があるかを確認できる。 #### 受入基準 1. WHEN ユーザーがアプリケーションを開く THEN THE System SHALL Database からすべてのタスクを取得して表示する 2. WHEN タスクが表示される THEN THE System SHALL 各タスクのタイトル、担当者、期限、完了ステータスを表示する 3. WHEN タスクリストが空である THEN THE System SHALL 空の状態メッセージを表示する 4. WHEN タスクが表示される THEN THE System SHALL 現在のユーザーが作成したタスクの行にのみ編集ボタン、削除ボタン、完了ボタンを表示する 5. WHEN 他のユーザーが作成したタスクが表示される THEN THE System SHALL 編集ボタン、削除ボタン、完了ボタンを非表示にする 6. WHEN 複数のユーザーが同時にアクセスする THEN THE System SHALL すべてのユーザーに同じタスクリストを表示する ### 要件 4 **ユーザーストーリー:** ユーザーとして、自分が作成したタスクを完了としてマークしたい。そうすることで、進捗を追跡できる。 #### 受入基準 1. WHEN ユーザーが自分が作成した未完了のタスクの完了ボタンをクリックする THEN THE System SHALL タスクのステータスを完了に更新する 2. WHEN タスクが完了としてマークされる THEN THE System SHALL 視覚的にタスクを区別する（取り消し線または異なる色） 3. WHEN ユーザーが自分が作成した完了したタスクの未完了ボタンをクリックする THEN THE System SHALL タスクのステータスを未完了に戻す 4. WHEN タスクのステータスが変更される THEN THE System SHALL 更新を Database に即座に保存する 5. WHEN ユーザーが他のユーザーが作成したタスクを表示する THEN THE System SHALL 完了ボタンを非表示にする ### 要件 5 **ユーザーストーリー:** ユーザーとして、自分が作成したタスクを削除したい。そうすることで、不要になったタスクを削除できる。 #### 受入基準 1. WHEN ユーザーが自分が作成したタスクの行にある削除ボタンをクリックする THEN THE System SHALL 確認ダイアログを表示する 2. WHEN ユーザーが削除を確認する THEN THE System SHALL タスクをリストから削除する 3. WHEN タスクが削除される THEN THE System SHALL Database から即座にタスクを削除する 4. WHEN タスクが削除される THEN THE System SHALL タスクリストを更新して削除されたタスクを非表示にする 5. WHEN ユーザーが他のユーザーが作成したタスクを削除しようとする THEN THE System SHALL 削除ボタンを表示しない ### 要件 6 **ユーザーストーリー:** ユーザーとして、自分が作成したタスクの詳細を編集したい。そうすることで、タスク情報を更新できる。 #### 受入基準 1. WHEN ユーザーが自分が作成したタスクの行にある編集ボタンをクリックする THEN THE System SHALL タスクを編集モードに切り替える 2. WHEN タスクが編集モードである THEN THE System SHALL タイトル、担当者、期限の編集を許可する 3. WHEN ユーザーが編集を保存する THEN THE System SHALL タスクの詳細を更新して Database に保存する 4. WHEN ユーザーが空のタイトルで保存しようとする THEN THE System SHALL 更新を防止してエラーメッセージを表示する 5. WHEN ユーザーが編集をキャンセルする THEN THE System SHALL 変更を破棄して元の値を復元する 6. WHEN ユーザーが他のユーザーが作成したタスクを編集しようとする THEN THE System SHALL 編集ボタンを表示しない ### 要件 7 **ユーザーストーリー:** ユーザーとして、データが永続化されることを期待する。そうすることで、ブラウザを閉じた後もタスクが失われない。 #### 受入基準 1. WHEN タスクが作成、更新、または削除される THEN THE System SHALL 変更を Database に即座に保存する 2. WHEN ユーザーがブラウザを閉じて再度開く THEN THE System SHALL 以前に保存されたすべてのタスクを読み込む 3. WHEN Database が利用できない THEN THE System SHALL エラーメッセージを表示してユーザーに通知する 4. WHEN データの保存に失敗する THEN THE System SHALL エラーメッセージを表示してユーザーに通知する ### 要件 8 **ユーザーストーリー:** ユーザーとして、単一画面で直観的なユーザーインターフェースを使用したい。そうすることで、ページ遷移なしにタスク管理のすべての操作を簡単に実行できる。 #### 受入基準 1. WHEN ユーザーがブラウザでアプリケーションにアクセスする THEN THE System SHALL タスク入力、一覧表示、編集、削除、完了マークのすべての機能を単一画面に表示する 2. WHEN ユーザーがUIを操作する THEN THE System SHALL 説明なしで操作方法が理解できる直観的なインターフェースを提供する 3. WHEN ユーザーが任意の操作を実行する THEN THE System SHALL ページをリロードまたは遷移せずに画面を更新する 4. WHEN ユーザーがUIを操作する THEN THE System SHALL サクサク軽く動作する ### 要件 9 **ユーザーストーリー:** ユーザーとして、エラーが発生したときに明確なフィードバックを受け取りたい。そうすることで、何が問題なのかを理解できる。 #### 受入基準 1. WHEN 検証エラーが発生する THEN THE System SHALL 問題を説明する明確なエラーメッセージを表示する 2. WHEN データの保存に失敗する THEN THE System SHALL エラーメッセージを表示してユーザーに通知する 3. WHEN エラーメッセージが表示される THEN THE System SHALL ユーザーが閉じるまでメッセージを表示する ### 要件 10 **ユーザーストーリー:** 開発者として、アプリケーションをAWSにデプロイしたい。そうすることで、ユーザーがインターネット経由でアクセスできる。 #### 受入基準 1. WHEN アプリケーションがデプロイされる THEN THE System SHALL AWS環境で実行される 2. WHEN フロントエンドがデプロイされる THEN THE System SHALL 静的ファイルをS3またはCloudFrontから提供する 3. WHEN バックエンドがデプロイされる THEN THE System SHALL API GatewayとLambda関数を使用する 4. WHEN データが保存される THEN THE System SHALL DynamoDBを使用してタスクを保存する 5. WHEN アプリケーションがデプロイされる THEN THE System SHALL HTTPSを使用してすべての通信を保護する 6. WHEN インフラストラクチャが管理される THEN THE System SHALL Infrastructure as Code（AWS CDKまたはCloudFormation）を使用する 7. WHEN デプロイが試行される THEN THE System SHALL すべてのE2Eテストが成功していることを確認する 8. WHEN E2Eテストが失敗している THEN THE System SHALL デプロイを中止してエラーを報告する ### 要件 11 **ユーザーストーリー:** 開発者として、E2Eテストを実装したい。そうすることで、アプリケーションの品質を保証できる。 #### 受入基準 1. WHEN E2Eテストが実行される THEN THE System SHALL Playwright MCPを使用してテストを実行する 2. WHEN ニックネーム設定フローがテストされる THEN THE System SHALL ニックネームが正常に設定されることを検証する 3. WHEN タスクの追加フローがテストされる THEN THE System SHALL タスクが正常に追加されることを検証する 4. WHEN タスクの編集フローがテストされる THEN THE System SHALL 自分が作成したタスクが正常に更新されることを検証する 5. WHEN タスクの削除フローがテストされる THEN THE System SHALL 自分が作成したタスクが正常に削除されることを検証する 6. WHEN タスクの完了マークフローがテストされる THEN THE System SHALL タスクのステータスが正常に切り替わることを検証する 7. WHEN タスク所有権がテストされる THEN THE System SHALL 他のユーザーが作成したタスクの編集・削除ボタンが表示されないことを検証する 8. WHEN データ永続化がテストされる THEN THE System SHALL ページをリロードした後もタスクが保持されることを検証する 9. WHEN すべてのE2Eテストが実行される THEN THE System SHALL すべてのテストが成功することを保証する |
- design.md
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 |
# 設計書 ## 概要 タスク管理アプリケーションは、AWS環境にデプロイされる軽量なWebアプリケーションです。ユーザーはログイン操作なしで、ブラウザ識別子とニックネームによる簡易的な識別機能を使用してタスクを管理できます。フロントエンドはTypeScriptで実装され、バックエンドはAWS Lambda（TypeScript）で構築されます。データはDynamoDBに保存され、すべてのユーザーが同じタスクリストを共有しますが、各タスクは作成者のみが編集・削除・完了マークを変更できます。 ## アーキテクチャ ### システム構成 ``` ┌─────────────────┐ │ CloudFront │ ← HTTPSでアクセス └────────┬────────┘ │ ┌────────▼────────┐ │ S3 Bucket │ ← 静的ファイル（HTML, CSS, JS） └─────────────────┘ ┌─────────────────┐ │ Web Browser │ │ (Frontend) │ └────────┬────────┘ │ HTTPS ┌────────▼────────┐ │ API Gateway │ └────────┬────────┘ │ ┌────────▼────────┐ │ Lambda │ ← TypeScript │ (Backend) │ └────────┬────────┘ │ ┌────────▼────────┐ │ DynamoDB │ ← タスクデータ └─────────────────┘ ``` ### レイヤー構成 1. **プレゼンテーション層（Frontend）** - HTML/CSS/TypeScript - ブラウザのLocal Storageを使用してBrowser IDとNicknameを保存 - API Gatewayを通じてバックエンドと通信 2. **アプリケーション層（Backend）** - AWS Lambda関数（TypeScript） - API Gatewayでエンドポイントを公開 - ビジネスロジックとデータ検証 3. **データ層** - DynamoDB - タスクデータとユーザーニックネームを保存 ## コンポーネントとインターフェース ### フロントエンドコンポーネント #### 1. UserIdentityManager ユーザー識別を管理するコンポーネント **責務**: - Browser IDの生成と保存 - Nicknameの管理 - Local Storageへのアクセス **インターフェース**: ```typescript interface UserIdentityManager { getBrowserId(): string | null; generateBrowserId(): string; saveBrowserId(browserId: string): void; getNickname(): string | null; saveNickname(nickname: string): void; clearIdentity(): void; } ``` #### 2. TaskManager タスクの管理を行うコンポーネント **責務**: - タスクのCRUD操作 - バックエンドAPIとの通信 - タスクリストの状態管理 **インターフェース**: ```typescript interface TaskManager { fetchTasks(): Promise<Task[]>; createTask(task: CreateTaskRequest): Promise<Task>; updateTask(taskId: string, updates: UpdateTaskRequest): Promise<Task>; deleteTask(taskId: string): Promise<void>; toggleTaskStatus(taskId: string): Promise<Task>; } ``` #### 3. UIController ユーザーインターフェースを制御するコンポーネント **責務**: - DOM操作 - イベントハンドリング - 画面の更新 **インターフェース**: ```typescript interface UIController { initialize(): void; renderTasks(tasks: Task[]): void; showNicknameDialog(): Promise<string>; showError(message: string): void; showConfirmDialog(message: string): Promise<boolean>; } ``` ### バックエンドコンポーネント #### 1. TaskService タスクのビジネスロジックを処理 **責務**: - タスクの検証 - タスクの作成・更新・削除ロジック - 所有権の確認 **インターフェース**: ```typescript interface TaskService { getAllTasks(): Promise<Task[]>; createTask(task: CreateTaskRequest, ownerId: string): Promise<Task>; updateTask(taskId: string, updates: UpdateTaskRequest, ownerId: string): Promise<Task>; deleteTask(taskId: string, ownerId: string): Promise<void>; toggleTaskStatus(taskId: string, ownerId: string): Promise<Task>; } ``` #### 2. TaskRepository DynamoDBへのアクセスを抽象化 **責務**: - DynamoDBへのCRUD操作 - データの永続化 **インターフェース**: ```typescript interface TaskRepository { findAll(): Promise<Task[]>; findById(taskId: string): Promise<Task | null>; save(task: Task): Promise<Task>; update(taskId: string, updates: Partial<Task>): Promise<Task>; delete(taskId: string): Promise<void>; } ``` #### 3. UserRepository ユーザーニックネームの管理 **責務**: - ニックネームの保存と取得 **インターフェース**: ```typescript interface UserRepository { saveNickname(browserId: string, nickname: string): Promise<void>; getNickname(browserId: string): Promise<string | null>; } ``` ## データモデル ### Task ```typescript interface Task { taskId: string; // 一意の識別子（UUID） title: string; // タスクのタイトル assignee: string; // 担当者 dueDate: string; // 期限（ISO 8601形式） status: TaskStatus; // 完了ステータス ownerId: string; // 作成者のBrowser ID createdAt: string; // 作成日時（ISO 8601形式） updatedAt: string; // 更新日時（ISO 8601形式） } enum TaskStatus { TODO = 'TODO', DONE = 'DONE' } ``` ### CreateTaskRequest ```typescript interface CreateTaskRequest { title: string; assignee: string; dueDate: string; } ``` ### UpdateTaskRequest ```typescript interface UpdateTaskRequest { title?: string; assignee?: string; dueDate?: string; } ``` ### User ```typescript interface User { browserId: string; // Browser ID（主キー） nickname: string; // ニックネーム createdAt: string; // 作成日時（ISO 8601形式） } ``` ### DynamoDBテーブル設計 #### Tasksテーブル - **主キー**: `taskId` (String) - **属性**: - `title` (String) - `assignee` (String) - `dueDate` (String) - `status` (String) - `ownerId` (String) - `createdAt` (String) - `updatedAt` (String) #### Usersテーブル - **主キー**: `browserId` (String) - **属性**: - `nickname` (String) - `createdAt` (String) ## API設計 ### エンドポイント #### 1. GET /tasks すべてのタスクを取得 **リクエスト**: ``` GET /tasks Headers: x-browser-id: <browser-id> ``` **レスポンス**: ```json { "tasks": [ { "taskId": "uuid", "title": "タスク1", "assignee": "山田太郎", "dueDate": "2025-12-31", "status": "TODO", "ownerId": "browser-id-123", "createdAt": "2025-11-27T10:00:00Z", "updatedAt": "2025-11-27T10:00:00Z" } ] } ``` #### 2. POST /tasks 新しいタスクを作成 **リクエスト**: ```json POST /tasks Headers: x-browser-id: <browser-id> Body: { "title": "タスク1", "assignee": "山田太郎", "dueDate": "2025-12-31" } ``` **レスポンス**: ```json { "task": { "taskId": "uuid", "title": "タスク1", "assignee": "山田太郎", "dueDate": "2025-12-31", "status": "TODO", "ownerId": "browser-id-123", "createdAt": "2025-11-27T10:00:00Z", "updatedAt": "2025-11-27T10:00:00Z" } } ``` #### 3. PUT /tasks/{taskId} タスクを更新 **リクエスト**: ```json PUT /tasks/{taskId} Headers: x-browser-id: <browser-id> Body: { "title": "更新されたタスク", "assignee": "鈴木花子", "dueDate": "2025-12-31" } ``` **レスポンス**: ```json { "task": { "taskId": "uuid", "title": "更新されたタスク", "assignee": "鈴木花子", "dueDate": "2025-12-31", "status": "TODO", "ownerId": "browser-id-123", "createdAt": "2025-11-27T10:00:00Z", "updatedAt": "2025-11-27T11:00:00Z" } } ``` #### 4. DELETE /tasks/{taskId} タスクを削除 **リクエスト**: ``` DELETE /tasks/{taskId} Headers: x-browser-id: <browser-id> ``` **レスポンス**: ```json { "message": "Task deleted successfully" } ``` #### 5. PATCH /tasks/{taskId}/status タスクのステータスを切り替え **リクエスト**: ``` PATCH /tasks/{taskId}/status Headers: x-browser-id: <browser-id> ``` **レスポンス**: ```json { "task": { "taskId": "uuid", "title": "タスク1", "assignee": "山田太郎", "dueDate": "2025-12-31", "status": "DONE", "ownerId": "browser-id-123", "createdAt": "2025-11-27T10:00:00Z", "updatedAt": "2025-11-27T12:00:00Z" } } ``` #### 6. POST /users ユーザーのニックネームを登録 **リクエスト**: ```json POST /users Body: { "browserId": "browser-id-123", "nickname": "山田太郎" } ``` **レスポンス**: ```json { "user": { "browserId": "browser-id-123", "nickname": "山田太郎", "createdAt": "2025-11-27T10:00:00Z" } } ``` ### エラーレスポンス ```json { "error": { "code": "ERROR_CODE", "message": "エラーメッセージ" } } ``` **エラーコード**: - `VALIDATION_ERROR`: 入力検証エラー - `UNAUTHORIZED`: 権限なし（他人のタスクを編集・削除しようとした） - `NOT_FOUND`: タスクが見つからない - `INTERNAL_ERROR`: サーバー内部エラー ## 正確性プロパティ *プロパティとは、システムのすべての有効な実行において真であるべき特性または動作です。本質的には、システムが何をすべきかについての形式的な記述です。プロパティは、人間が読める仕様と機械で検証可能な正確性保証との橋渡しとなります。* ### Property 1: Browser ID生成と保存の一貫性 *任意の*ニックネームに対して、Browser IDを生成して保存した後、Local Storageから読み込んだBrowser IDは生成したものと同じであるべき **Validates: Requirements 1.2** ### Property 2: ニックネームのデータベース保存 *任意の*Browser IDとNicknameに対して、データベースに保存した後、同じBrowser IDで取得したNicknameは保存したものと同じであるべき **Validates: Requirements 1.3** ### Property 3: タスク作成時のリスト追加 *任意の*有効なタスクデータ（タイトル、担当者、期限）に対して、タスクを作成した後、タスクリストの長さは1増加し、新しいタスクがリストに含まれるべき **Validates: Requirements 2.1** ### Property 4: 空タイトルの拒否 *任意の*空文字列または空白文字列のタイトルに対して、タスクの作成または更新は拒否され、エラーメッセージが返されるべき **Validates: Requirements 2.2, 6.4** ### Property 5: タスクIDの一意性 *任意の*複数のタスクに対して、各タスクに割り当てられたIDはすべて異なるべき **Validates: Requirements 2.3** ### Property 6: タスクのラウンドトリップ保存 *任意の*タスクに対して、データベースに保存した後、同じIDで取得したタスクは保存したものと同じ内容であるべき **Validates: Requirements 2.4, 7.1, 7.2** ### Property 7: タスク初期ステータス *任意の*新しいタスクに対して、作成時のステータスはTODOであるべき **Validates: Requirements 2.6** ### Property 8: タスク作成者IDの記録 *任意の*タスクに対して、作成時に現在のユーザーのBrowser IDが作成者IDとして記録されるべき **Validates: Requirements 2.7** ### Property 9: タスク表示の完全性 *任意の*タスクに対して、表示される情報にはタイトル、担当者、期限、完了ステータスが含まれるべき **Validates: Requirements 3.2** ### Property 10: タスク所有権に基づくボタン表示 *任意の*タスクに対して、現在のユーザーのBrowser IDがタスクの作成者IDと一致する場合のみ、編集ボタン、削除ボタン、完了ボタンが表示されるべき **Validates: Requirements 3.4, 3.5, 4.5, 5.5, 6.6** ### Property 11: タスクステータスのトグル *任意の*タスクに対して、ステータスをTODOからDONEに変更し、再度変更すると元のTODOに戻るべき **Validates: Requirements 4.1, 4.3** ### Property 12: ステータス変更の永続化 *任意の*タスクに対して、ステータスを変更してデータベースに保存した後、同じIDで取得したタスクのステータスは変更後のものであるべき **Validates: Requirements 4.4** ### Property 13: タスク削除の完全性 *任意の*タスクに対して、削除した後、タスクリストにそのタスクが含まれず、データベースからも取得できないべき **Validates: Requirements 5.2, 5.3, 5.4** ### Property 14: タスク更新の正確性 *任意の*タスクと更新内容（タイトル、担当者、期限）に対して、更新した後、データベースから取得したタスクは更新後の内容を反映しているべき **Validates: Requirements 6.3** ### Property 15: 検証エラーメッセージの存在 *任意の*検証エラー（空タイトル、無効な日付など）に対して、エラーメッセージが返され、メッセージには問題の説明が含まれるべき **Validates: Requirements 9.1** ## エラーハンドリング ### フロントエンドエラー 1. **入力検証エラー** - 空のタイトル - 無効な日付形式 - エラーメッセージをUIに表示 2. **ネットワークエラー** - API呼び出しの失敗 - タイムアウト - ユーザーに再試行を促すメッセージを表示 3. **認証エラー** - Browser IDが見つからない - ニックネーム入力ダイアログを表示 ### バックエンドエラー 1. **検証エラー (400 Bad Request)** - 空のタイトル - 無効な日付形式 - 必須フィールドの欠落 - エラーコード: `VALIDATION_ERROR` 2. **権限エラー (403 Forbidden)** - 他人のタスクを編集・削除しようとした - エラーコード: `UNAUTHORIZED` 3. **リソース未検出 (404 Not Found)** - 存在しないタスクIDを指定 - エラーコード: `NOT_FOUND` 4. **サーバーエラー (500 Internal Server Error)** - DynamoDBへのアクセス失敗 - 予期しないエラー - エラーコード: `INTERNAL_ERROR` ### エラーハンドリング戦略 - すべてのAPI呼び出しはtry-catchでラップ - エラーはログに記録（CloudWatch Logs） - ユーザーフレンドリーなエラーメッセージを表示 - リトライ可能なエラーは自動リトライ（最大3回） ## テスト戦略 ### ユニットテスト **フロントエンド**: - `UserIdentityManager`のBrowser ID生成と保存 - `TaskManager`のタスクCRUD操作 - `UIController`のDOM操作 **バックエンド**: - `TaskService`のビジネスロジック - `TaskRepository`のDynamoDB操作 - `UserRepository`のユーザー管理 - 入力検証ロジック - 所有権確認ロジック **テストフレームワーク**: Jest ### プロパティベーステスト プロパティベーステストは、設計書で定義された正確性プロパティを検証します。各プロパティは、ランダムに生成された入力データに対して100回以上実行され、プロパティが常に成立することを確認します。 **テストフレームワーク**: fast-check **テスト対象**: - Property 1: Browser ID生成と保存の一貫性 - Property 2: ニックネームのデータベース保存 - Property 3: タスク作成時のリスト追加 - Property 4: 空タイトルの拒否 - Property 5: タスクIDの一意性 - Property 6: タスクのラウンドトリップ保存 - Property 7: タスク初期ステータス - Property 8: タスク作成者IDの記録 - Property 9: タスク表示の完全性 - Property 10: タスク所有権に基づくボタン表示 - Property 11: タスクステータスのトグル - Property 12: ステータス変更の永続化 - Property 13: タスク削除の完全性 - Property 14: タスク更新の正確性 - Property 15: 検証エラーメッセージの存在 **プロパティテストの要件**: - 各プロパティテストは最低100回の反復を実行 - 各テストには設計書のプロパティ番号を明示的に参照するコメントを含める - コメント形式: `// Feature: task-manager, Property X: <property_text>` - 各正確性プロパティは1つのプロパティベーステストで実装 ### E2Eテスト **テストフレームワーク**: Playwright MCP **テストシナリオ**: 1. ニックネーム設定フロー - 初回アクセス時にニックネーム入力ダイアログが表示される - ニックネームを入力して確定できる - 2回目以降はニックネーム入力がスキップされる 2. タスク追加フロー - タスクフォームにタイトル、担当者、期限を入力 - 追加ボタンをクリック - タスクがリストに表示される - 入力フィールドがクリアされる 3. タスク編集フロー - 自分が作成したタスクの編集ボタンをクリック - タスクが編集モードに切り替わる - タイトル、担当者、期限を変更 - 保存ボタンをクリック - 変更が反映される 4. タスク削除フロー - 自分が作成したタスクの削除ボタンをクリック - 確認ダイアログが表示される - 削除を確認 - タスクがリストから消える 5. タスク完了マークフロー - 自分が作成したタスクの完了ボタンをクリック - タスクが完了状態になる（視覚的に区別される） - 再度クリックすると未完了に戻る 6. タスク所有権フロー - 別のBrowser IDでアクセス - 他人が作成したタスクには編集・削除・完了ボタンが表示されない - 自分が作成したタスクにはボタンが表示される 7. データ永続化フロー - タスクを追加 - ページをリロード - タスクが保持されている 8. 複数ユーザー共有フロー - 複数のブラウザ（異なるBrowser ID）でアクセス - すべてのユーザーに同じタスクリストが表示される **E2Eテストの実行**: - すべてのE2Eテストが成功していることをデプロイ前に確認 - テストが失敗した場合はデプロイを中止 ### テストカバレッジ目標 - ユニットテスト: 80%以上 - プロパティベーステスト: すべての正確性プロパティをカバー - E2Eテスト: すべての主要なユーザーフローをカバー ## セキュリティ考慮事項 1. **HTTPS通信** - すべての通信はHTTPSで暗号化 2. **入力検証** - フロントエンドとバックエンドの両方で入力を検証 - SQLインジェクション、XSS攻撃を防止 3. **所有権確認** - タスクの編集・削除・ステータス変更時に所有権を確認 - Browser IDの改ざんを検出 4. **レート制限** - API Gatewayでレート制限を設定 - DDoS攻撃を防止 5. **エラーメッセージ** - 内部実装の詳細を漏らさない - ユーザーフレンドリーなメッセージのみ表示 ## パフォーマンス考慮事項 1. **フロントエンド** - タスクリストの仮想スクロール（タスクが多い場合） - デバウンス処理（検索、フィルタリング） - 楽観的UI更新（即座にUIを更新し、バックグラウンドでAPIを呼び出す） 2. **バックエンド** - DynamoDBのクエリ最適化 - Lambda関数のコールドスタート対策（Provisioned Concurrency） - API Gatewayのキャッシング 3. **目標** - ページロード時間: 2秒以内 - API応答時間: 500ms以内 - タスク追加・更新・削除: 1秒以内 ## デプロイ戦略 ### Infrastructure as Code **ツール**: AWS CDK (TypeScript) **リソース**: - S3 Bucket (静的ファイルホスティング) - CloudFront Distribution (CDN) - API Gateway (REST API) - Lambda Functions (バックエンドロジック) - DynamoDB Tables (Tasks, Users) - IAM Roles and Policies - CloudWatch Logs ### CI/CDパイプライン 1. **ビルド** - TypeScriptのコンパイル - 静的ファイルのバンドル 2. **テスト** - ユニットテストの実行 - プロパティベーステストの実行 - E2Eテストの実行 3. **デプロイ前チェック** - すべてのテストが成功していることを確認 - テストが失敗している場合はデプロイを中止 4. **デプロイ** - AWS CDKでインフラストラクチャをデプロイ - Lambda関数のデプロイ - 静的ファイルをS3にアップロード - CloudFrontのキャッシュをクリア 5. **デプロイ後検証** - ヘルスチェック - スモークテスト ### 環境 - **開発環境**: ローカル開発 - **ステージング環境**: AWS（テスト用） - **本番環境**: AWS（本番用） ## 今後の拡張性 1. **ユーザー認証** - メールアドレスとパスワードによる認証 - マジックリンク認証（パスワードレス） - ソーシャルログイン（Google、GitHub等） - Amazon Cognito を使用した認証基盤 - Browser IDからユーザーアカウントへの移行機能 2. **タスクのフィルタリング** - ステータス別（未完了、完了） - 担当者別 - 期限別 3. **タスクの検索** - タイトルでの検索 - 担当者での検索 4. **タスクの並び替え** - 作成日時順 - 期限順 - タイトル順 5. **タスクの優先度** - 高、中、低の優先度設定 6. **タスクのカテゴリ** - カテゴリ別の分類 7. **通知機能** - 期限が近いタスクの通知 - タスクの更新通知 8. **リアルタイム同期** - WebSocketを使用したリアルタイム更新 - 複数ユーザーでの同時編集 |
- tasks.md
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 |
# 実装計画 - [x] 1. プロジェクト構造とコア型定義のセットアップ - TypeScriptプロジェクトの初期化（package.json、tsconfig.json） - フロントエンドとバックエンドのディレクトリ構造を作成 - コア型定義（Task、User、API Request/Response）を実装 - _Requirements: 1.1, 2.1, 3.2_ - [x] 1.1 Property 1のプロパティベーステストを実装 - **Property 1: Browser ID生成と保存の一貫性** - **Validates: Requirements 1.2** - [x] 1.2 Property 2のプロパティベーステストを実装 - **Property 2: ニックネームのデータベース保存** - **Validates: Requirements 1.3** - [x] 2. フロントエンド: UserIdentityManagerの実装 - Browser IDの生成ロジックを実装（UUID v4） - Local Storageへの保存・読み込み機能を実装 - Nicknameの管理機能を実装 - _Requirements: 1.2, 1.3, 1.4, 1.5_ - [x] 3. バックエンド: TaskRepositoryの実装 - DynamoDB DocumentClientを使用したCRUD操作を実装 - findAll、findById、save、update、deleteメソッドを実装 - エラーハンドリングを実装 - _Requirements: 2.4, 3.1, 5.3, 6.3, 7.1_ - [x] 3.1 Property 5のプロパティベーステストを実装 - **Property 5: タスクIDの一意性** - **Validates: Requirements 2.3** - [x] 3.2 Property 6のプロパティベーステストを実装 - **Property 6: タスクのラウンドトリップ保存** - **Validates: Requirements 2.4, 7.1, 7.2** - [x] 4. バックエンド: UserRepositoryの実装 - ニックネームの保存・取得機能を実装 - DynamoDB DocumentClientを使用 - _Requirements: 1.3_ - [x] 5. バックエンド: TaskServiceの実装 - タスクのビジネスロジックを実装 - 入力検証（空タイトル、無効な日付）を実装 - 所有権確認ロジックを実装 - getAllTasks、createTask、updateTask、deleteTask、toggleTaskStatusメソッドを実装 - _Requirements: 2.1, 2.2, 3.4, 4.1, 5.2, 6.3, 6.4_ - [x] 5.1 Property 4のプロパティベーステストを実装 - **Property 4: 空タイトルの拒否** - **Validates: Requirements 2.2, 6.4** - [x] 5.2 Property 7のプロパティベーステストを実装 - **Property 7: タスク初期ステータス** - **Validates: Requirements 2.6** - [x] 5.3 Property 8のプロパティベーステストを実装 - **Property 8: タスク作成者IDの記録** - **Validates: Requirements 2.7** - [x] 5.4 Property 11のプロパティベーステストを実装 - **Property 11: タスクステータスのトグル** - **Validates: Requirements 4.1, 4.3** - [x] 5.5 Property 12のプロパティベーステストを実装 - **Property 12: ステータス変更の永続化** - **Validates: Requirements 4.4** - [x] 5.6 Property 13のプロパティベーステストを実装 - **Property 13: タスク削除の完全性** - **Validates: Requirements 5.2, 5.3, 5.4** - [x] 5.7 Property 14のプロパティベーステストを実装 - **Property 14: タスク更新の正確性** - **Validates: Requirements 6.3** - [x] 5.8 Property 15のプロパティベーステストを実装 - **Property 15: 検証エラーメッセージの存在** - **Validates: Requirements 9.1** - [x] 6. Checkpoint - バックエンドテストが通ることを確認 - すべてのバックエンドテストを実行し、問題があれば修正する - [x] 7. フロントエンド: TaskManagerの実装 - API通信用のHTTPクライアントを実装 - タスクのCRUD操作メソッドを実装 - エラーハンドリングとリトライロジックを実装 - _Requirements: 2.1, 2.4, 5.2, 6.3_ - [x] 7.1 Property 3のプロパティベーステストを実装 - **Property 3: タスク作成時のリスト追加** - **Validates: Requirements 2.1** - [x] 8. フロントエンド: UIControllerの実装 - HTML構造を作成（タスクフォーム、タスクリスト） - CSSスタイリングを実装（レスポンシブデザイン） - DOM操作とイベントハンドリングを実装 - ニックネーム入力ダイアログを実装 - エラーメッセージ表示機能を実装 - _Requirements: 1.1, 2.5, 3.1, 7.1, 8.1, 8.3, 9.1_ - [x] 8.1 Property 9のプロパティベーステストを実装 - **Property 9: タスク表示の完全性** - **Validates: Requirements 3.2** - [x] 8.2 Property 10のプロパティベーステストを実装 - **Property 10: タスク所有権に基づくボタン表示** - **Validates: Requirements 3.4, 3.5, 4.5, 5.5, 6.6** - [x] 9. フロントエンド: メインアプリケーションの統合 - index.htmlを作成 - アプリケーションエントリーポイント（main.ts）を実装 - UserIdentityManager、TaskManager、UIControllerを統合 - 初期化フローを実装 - _Requirements: 1.1, 8.1, 8.2, 8.3_ - [x] 10. バックエンド: Lambda関数ハンドラーの実装 - API Gatewayイベントのパース - ルーティングロジック（GET /tasks、POST /tasks等） - TaskServiceとUserRepositoryの呼び出し - レスポンスの生成（成功、エラー） - CORS設定 - _Requirements: 2.1, 3.1, 4.1, 5.2, 6.3_ - [x] 11. AWS CDK: インフラストラクチャコードの実装 - CDKプロジェクトの初期化 - DynamoDBテーブルの定義（Tasks、Users） - Lambda関数の定義とデプロイ設定 - API Gatewayの定義（REST API） - S3 Bucketの定義（静的ファイルホスティング） - CloudFront Distributionの定義 - IAM RolesとPoliciesの設定 - _Requirements: 10.1, 10.2, 10.3, 10.4, 10.5, 10.6_ - [x] 12. ローカル統合テストとデバッグ - フロントエンドとバックエンドをローカルで統合 - CORS設定を確認 - エラーハンドリングを確認 - すべての機能が動作することを確認 - _Requirements: 2.1, 3.1, 4.1, 5.2, 6.3_ - [x] 13. Checkpoint - すべてのユニット・プロパティテストが通ることを確認 - すべてのテストを実行し、問題があれば修正する - [x] 14. E2Eテスト: ニックネーム設定フローの実装 - Playwright MCPを使用してテストを実装 - 初回アクセス時のニックネーム入力を検証 - 2回目以降のアクセスでスキップされることを検証 - _Requirements: 11.2_ - [x] 15. E2Eテスト: タスク追加フローの実装 - タスクフォームへの入力を検証 - タスクがリストに追加されることを検証 - 入力フィールドがクリアされることを検証 - _Requirements: 11.3_ - [x] 16. E2Eテスト: タスク編集フローの実装 - 編集ボタンのクリックを検証 - 編集モードへの切り替えを検証 - タスクの更新を検証 - _Requirements: 11.4_ - [x] 17. E2Eテスト: タスク削除フローの実装 - 削除ボタンのクリックを検証 - 確認ダイアログを検証 - タスクが削除されることを検証 - _Requirements: 11.5_ - [x] 18. E2Eテスト: タスク完了マークフローの実装 - 完了ボタンのクリックを検証 - ステータスの切り替えを検証 - 視覚的な区別を検証 - _Requirements: 11.6_ - [x] 19. E2Eテスト: タスク所有権フローの実装 - 別のBrowser IDでアクセスを検証 - 他人のタスクにボタンが表示されないことを検証 - 自分のタスクにボタンが表示されることを検証 - _Requirements: 11.7_ - [x] 20. E2Eテスト: データ永続化フローの実装 - タスクを追加してページをリロード - タスクが保持されていることを検証 - _Requirements: 11.8_ - [x] 21. デプロイパイプラインの構築 - ビルドスクリプトを作成 - テスト実行スクリプトを作成 - デプロイ前チェック（E2Eテスト成功確認）を実装 - デプロイスクリプトを作成（AWS CDK deploy） - _Requirements: 10.7, 10.8_ - [x] 22. 最終Checkpoint - すべてのテストが通ることを確認 - すべてのユニットテスト、プロパティベーステスト、E2Eテストを実行 - 問題があれば修正する |
出力の判定と修正
Kiroの出力を確認し、期待通りか、修正が必要かを判断しました。
判定結果
今回は問題なしとしました。
良かった点
非機能的なところや、品質面も考慮して仕様を組み立てていくところは、キャリアの有無にかかわらず一定の品質を保てるのかもしれないと思います。
問題点
tasks.mdのチェックは大変ですね。今回はざっくり見るだけにしてしまいました。
本来はじっくりレビューすべきなのでしょうが、この辺も容易にできるのか。他のメンバーがどうやっているのか気になります。
Kiroとの対話
前述のとおり、requirements.md の完成まではなんどかやり取りをしました。
design.md の「今後の拡張性」については、以下の観点を追加しました。
|
1 |
今後の拡張性のところで、将来的にユーザー認証を実装することを追加してほしい。 |
運営との確認で「将来的には認証も考えている」と言っていたのでそれを踏まえて追加してます。
tasks.md については、最初の出力のままです。
テスト実装
KiroにPlaywright で実施したテスト内容を出力させました。ファイル出力させておくと後から参照もできるので便利でした。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 |
# Playwright E2Eテスト実施内容まとめ ## 概要 タスク管理アプリケーションに対して、Playwright MCPを使用した7つのE2Eテストシナリオを実装しました。 すべてのテストは手動実行用に設計されており、Playwright MCPのブラウザツールを使用して実行します。 ## テスト環境 - **テストフレームワーク**: Playwright MCP - **テスト対象**: タスク管理Webアプリケーション - **デプロイ先**: AWS (CloudFront + S3 + API Gateway + Lambda + DynamoDB) - **テスト言語**: TypeScript - **テストファイル数**: 7ファイル ## E2Eテスト一覧 ### 1. ニックネーム設定フロー (nickname-setup.e2e.test.ts) **検証要件**: Requirements 11.2, 1.1-1.5 **テストシナリオ**: - 初回アクセス時のニックネーム入力ダイアログ表示 - ニックネーム入力と確定 - Browser IDの生成とLocal Storageへの保存 - 2回目以降のアクセスでニックネーム入力のスキップ - Local Storage削除時の再表示 - ニックネームの検証（空文字、日本語文字） **主要な検証ポイント**: - ニックネームダイアログが初回のみ表示される - Browser IDが一意に生成される（UUID v4形式） - ニックネームとBrowser IDがLocal Storageに保存される - 2回目以降はダイアログがスキップされる - Local Storageが削除されると再度ダイアログが表示される **使用するPlaywright MCPツール**: - `mcp_playwright_browser_navigate`: URLへの遷移 - `mcp_playwright_browser_snapshot`: ページ状態のキャプチャ - `mcp_playwright_browser_type`: テキスト入力 - `mcp_playwright_browser_click`: ボタンクリック - `mcp_playwright_browser_evaluate`: JavaScriptの実行（localStorage操作） ### 2. タスク追加フロー (task-addition.e2e.test.ts) **検証要件**: Requirements 11.3, 2.1-2.7 **テストシナリオ**: - タスクフォームの表示と入力フィールドの確認 - タスクの追加とリストへの表示 - 入力フィールドのクリア - データベースへの即座の保存 - 空タイトルの拒否 - 空白文字のみのタイトルの拒否 - 複数タスクの連続追加 - タスクIDの一意性 - タスク所有権の記録 - UIフィードバックとエラーハンドリング **主要な検証ポイント**: - タスクフォームに必要なフィールドが表示される（タイトル、担当者、期限） - タスクが正常に追加されリストに表示される - 追加後に入力フィールドがクリアされる - タスクがデータベースに即座に保存される - 空タイトルでの追加が防止される - 各タスクに一意のIDが割り当てられる - 作成者のBrowser IDが記録される - 自分のタスクには編集・削除・完了ボタンが表示される ### 3. タスク編集フロー (task-edit.e2e.test.ts) **検証要件**: Requirements 11.4, 6.1-6.6 **テストシナリオ**: - 編集ボタンの表示とクリック - 編集モードへの切り替え - タスクフィールドの編集（タイトル、担当者、期限） - 編集内容の保存とデータベースへの永続化 - 編集のキャンセルと元の値の復元 - 空タイトルでの保存の防止 - 他ユーザーのタスクの編集ボタン非表示 - 複数回の編集 - 編集中の他タスクの状態維持 - 完了ステータスの保持 **主要な検証ポイント**: - 自分が作成したタスクのみ編集ボタンが表示される - 編集ボタンクリックでタスクが編集モードに切り替わる - すべてのフィールド（タイトル、担当者、期限）が編集可能 - 保存ボタンで変更が保存される - キャンセルボタンで変更が破棄される - 空タイトルでの保存が防止される - 他ユーザーのタスクは編集できない - 編集後もタスクのステータスが保持される **使用するPlaywright MCPツール**: - `mcp_playwright_browser_click`: 編集ボタン、保存ボタン、キャンセルボタンのクリック - `mcp_playwright_browser_type`: フィールドへのテキスト入力 - `mcp_playwright_browser_snapshot`: 編集モードの確認 - `mcp_playwright_browser_evaluate`: タスクデータの取得 - `mcp_playwright_browser_wait_for`: 更新完了の待機 ### 4. タスク削除フロー (task-delete.e2e.test.ts) **検証要件**: Requirements 11.5, 5.1-5.5 **テストシナリオ**: - 削除ボタンの表示とクリック - 確認ダイアログの表示 - 削除の確認と実行 - タスクのリストからの削除 - データベースからの即座の削除 - 削除のキャンセル - 他ユーザーのタスクの削除ボタン非表示 - 複数タスクの連続削除 - 完了済みタスクの削除 - タスク順序の維持 **主要な検証ポイント**: - 自分が作成したタスクのみ削除ボタンが表示される - 削除ボタンクリックで確認ダイアログが表示される - 確認後にタスクがリストから削除される - タスクがデータベースから即座に削除される - キャンセルするとタスクが削除されない - 他ユーザーのタスクは削除できない - 削除後にページをリロードしてもタスクは表示されない - 複数のタスクを連続して削除できる **使用するPlaywright MCPツール**: - `mcp_playwright_browser_click`: 削除ボタンのクリック - `mcp_playwright_browser_handle_dialog`: 確認ダイアログの処理 - `mcp_playwright_browser_snapshot`: 削除後の状態確認 - `mcp_playwright_browser_wait_for`: 削除完了の待機 - `mcp_playwright_browser_navigate`: ページリロード ### 5. タスク完了マークフロー (task-completion.e2e.test.ts) **検証要件**: Requirements 11.6, 4.1-4.5 **テストシナリオ**: - 完了ボタンの表示とクリック - タスクステータスのTODOからDONEへの変更 - 視覚的な区別の適用（取り消し線、色変更） - ステータスのトグル（DONE→TODO） - ステータス変更のデータベースへの永続化 - 他ユーザーのタスクの完了ボタン非表示 - 複数タスクのステータス管理 - 編集時のステータス保持 - 複数回のトグル **主要な検証ポイント**: - 自分が作成したタスクのみ完了ボタンが表示される - 完了ボタンクリックでステータスがDONEに変更される - 完了タスクに視覚的な区別が適用される（取り消し線または色変更） - 再度クリックするとステータスがTODOに戻る - ステータス変更がデータベースに即座に保存される - 他ユーザーのタスクのステータスは変更できない - 各タスクのステータスが独立して管理される - 編集してもステータスが保持される **使用するPlaywright MCPツール**: - `mcp_playwright_browser_click`: 完了ボタンのクリック - `mcp_playwright_browser_snapshot`: 視覚的な区別の確認 - `mcp_playwright_browser_evaluate`: CSSスタイルの確認 - `mcp_playwright_browser_wait_for`: ステータス更新の待機 - `mcp_playwright_browser_navigate`: ページリロード ### 6. タスク所有権フロー (task-ownership.e2e.test.ts) **検証要件**: Requirements 11.7, 3.4, 3.5, 4.5, 5.5, 6.6 **テストシナリオ**: - 自分のタスクへのアクションボタン表示 - 他ユーザーのタスクへのアクションボタン非表示 - 混在タスクリストでの正しいボタン表示 - ページリロード後の所有権維持 - API レベルでの所有権強制 - 他ユーザーのタスクの編集・削除・完了マークの防止 **主要な検証ポイント**: - 自分が作成したタスクには編集・削除・完了ボタンが表示される - 他ユーザーが作成したタスクにはボタンが表示されない - 他ユーザーのタスクは閲覧のみ可能 - 混在タスクリストで各タスクに正しいボタンが表示される - ページリロード後も所有権が維持される - API経由での他ユーザーのタスク操作が拒否される（403 Forbidden） - 複数ユーザーが同じタスクリストを共有できる **使用するPlaywright MCPツール**: - `mcp_playwright_browser_evaluate`: localStorage操作（Browser ID切り替え） - `mcp_playwright_browser_snapshot`: ボタン表示の確認 - `mcp_playwright_browser_navigate`: ページリロード - `mcp_playwright_browser_click`: ボタンクリック試行 - `mcp_playwright_browser_wait_for`: ページロードの待機 **テスト手順の特徴**: - 2つの異なるBrowser IDでセッションを切り替える - 各ユーザーでタスクを作成し、相互に閲覧する - ボタンの表示/非表示を確認する - API経由での不正操作を試みる ### 7. データ永続化フロー (data-persistence.e2e.test.ts) **検証要件**: Requirements 11.8, 7.1, 7.2 **テストシナリオ**: - 単一タスクのページリロード後の永続化 - タスクステータスの永続化 - 複数タスクの永続化 - 混在ステータスの永続化 - タスク編集の永続化 - 削除タスクの非表示の永続化 - Browser IDの永続化 - タスク所有権の永続化 - 空状態の永続化 - ブラウザセッション間の永続化 **主要な検証ポイント**: - タスクがページリロード後も表示される - タスクデータ（タイトル、担当者、期限）が変更されない - タスクステータス（TODO/DONE）が保持される - 複数タスクがすべて永続化される - 編集したタスクが更新された状態で永続化される - 削除したタスクがリロード後も表示されない - Browser IDがLocal Storageに保持される - タスク所有権が維持される（アクションボタンが表示される） - 空状態が正しく処理される - ブラウザを閉じて再度開いてもデータが保持される **使用するPlaywright MCPツール**: - `mcp_playwright_browser_navigate`: ページリロード - `mcp_playwright_browser_snapshot`: データ永続化の確認 - `mcp_playwright_browser_evaluate`: localStorage確認 - `mcp_playwright_browser_wait_for`: ページロードの待機 - `mcp_playwright_browser_close`: ブラウザセッションのクローズ **テスト手順の特徴**: - タスク追加→リロード→確認のサイクルを繰り返す - 各種操作（追加、編集、削除、完了マーク）後にリロードして確認 - Browser IDの永続性を確認 - 複数回のリロードでデータが保持されることを確認 ## テスト実行方法 ### 前提条件 1. アプリケーションがデプロイまたはローカルで実行されている 2. 各テストファイルの`TEST_CONFIG.APP_URL`を正しいURLに更新 3. Playwright MCPツールが利用可能 ### 実行手順 1. テストファイルを開く 2. 各テストシナリオの手動テスト手順に従う 3. Playwright MCPブラウザツールを使用して操作を実行 4. 期待される結果と実際の動作を比較 5. すべてのテストシナリオを実行 ### 主要なPlaywright MCPツール | ツール名 | 用途 | |---------|------| | `mcp_playwright_browser_navigate` | URLへの遷移、ページリロード | | `mcp_playwright_browser_snapshot` | ページ状態のキャプチャと要素の確認 | | `mcp_playwright_browser_type` | 入力フィールドへのテキスト入力 | | `mcp_playwright_browser_click` | ボタンや要素のクリック | | `mcp_playwright_browser_evaluate` | ブラウザコンテキストでのJavaScript実行 | | `mcp_playwright_browser_wait_for` | 要素や条件の待機 | | `mcp_playwright_browser_handle_dialog` | 確認ダイアログの処理 | | `mcp_playwright_browser_close` | ブラウザのクローズ | ## テストカバレッジ ### 機能カバレッジ | 機能 | テストファイル | カバー率 | |------|--------------|---------| | ニックネーム設定 | nickname-setup.e2e.test.ts | 100% | | タスク追加 | task-addition.e2e.test.ts | 100% | | タスク編集 | task-edit.e2e.test.ts | 100% | | タスク削除 | task-delete.e2e.test.ts | 100% | | タスク完了マーク | task-completion.e2e.test.ts | 100% | | タスク所有権 | task-ownership.e2e.test.ts | 100% | | データ永続化 | data-persistence.e2e.test.ts | 100% | ### 要件カバレッジ | 要件番号 | 要件内容 | テストファイル | 状態 | |---------|---------|--------------|------| | 1.1-1.5 | ニックネーム設定 | nickname-setup.e2e.test.ts | ✅ | | 2.1-2.7 | タスク追加 | task-addition.e2e.test.ts | ✅ | | 3.1-3.6 | タスク一覧表示 | 複数ファイル | ✅ | | 4.1-4.5 | タスク完了マーク | task-completion.e2e.test.ts | ✅ | | 5.1-5.5 | タスク削除 | task-delete.e2e.test.ts | ✅ | | 6.1-6.6 | タスク編集 | task-edit.e2e.test.ts | ✅ | | 7.1-7.4 | データ永続化 | data-persistence.e2e.test.ts | ✅ | | 8.1-8.4 | UI操作性 | 全テスト | ✅ | | 9.1-9.3 | エラーハンドリング | 複数ファイル | ✅ | | 11.2-11.8 | E2Eテスト要件 | 全テスト | ✅ | ## テスト結果の検証ポイント ### 1. ユーザー識別 - ✅ Browser IDが一意に生成される - ✅ ニックネームがLocal Storageに保存される - ✅ 2回目以降はニックネーム入力がスキップされる - ✅ Local Storage削除時に再度入力が求められる ### 2. タスク管理 - ✅ タスクの追加、編集、削除、完了マークが正常に動作する - ✅ 各操作がデータベースに即座に保存される - ✅ 入力検証が正しく機能する（空タイトルの拒否） - ✅ タスクに一意のIDが割り当てられる ### 3. タスク所有権 - ✅ 自分が作成したタスクのみ編集・削除・完了マークが可能 - ✅ 他ユーザーのタスクは閲覧のみ可能 - ✅ アクションボタンが適切に表示/非表示される - ✅ API レベルで所有権が強制される ### 4. データ永続化 - ✅ タスクがページリロード後も保持される - ✅ タスクステータスが永続化される - ✅ 編集内容が永続化される - ✅ 削除したタスクが再表示されない - ✅ Browser IDとタスク所有権が維持される ### 5. UI/UX - ✅ 単一画面ですべての操作が完結する - ✅ ページ遷移なしで画面が更新される - ✅ 直感的なインターフェース - ✅ 適切なエラーメッセージの表示 ### 6. 複数ユーザー対応 - ✅ 複数ユーザーが同じタスクリストを共有できる - ✅ 各ユーザーが自分のタスクのみ操作できる - ✅ 他ユーザーのタスクを閲覧できる - ✅ タスク所有権が正しく管理される ## テスト実施時の注意事項 ### 1. Browser IDの管理 - テスト間でBrowser IDをクリアする必要がある場合は`localStorage.clear()`を実行 - 異なるユーザーをシミュレートする場合は、Browser IDを切り替える - Browser IDの形式はUUID v4（例: `xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx`） ### 2. データのクリーンアップ - テスト前にデータベースをクリーンアップすることを推奨 - テスト後に作成したタスクを削除することを推奨 - 本番環境でのテストは避ける ### 3. ネットワーク状態 - ネットワークエラーのテストでは、ブラウザの開発者ツールでネットワークをブロック - タイムアウトのテストでは、適切な待機時間を設定 - API応答の遅延をシミュレートする場合は、ネットワークスロットリングを使用 ### 4. 視覚的な確認 - 完了タスクの視覚的な区別（取り消し線、色変更）を目視で確認 - UIの直感性を実際に操作して確認 - レスポンシブデザインは異なる画面サイズで確認 ### 5. エラーハンドリング - エラーメッセージが日本語で表示されることを確認 - エラーメッセージが明確で理解しやすいことを確認 - エラー発生時にアプリケーションが安定していることを確認 ## テスト実施結果の記録 各テストシナリオの実施結果は以下の形式で記録することを推奨： ``` テストシナリオ: [シナリオ名] 実施日時: [日時] 実施者: [名前] 結果: [成功/失敗] 備考: [特記事項] ``` ## まとめ Playwright MCPを使用した7つのE2Eテストシナリオにより、タスク管理アプリケーションの主要機能を包括的にテストしています。 **テストの特徴**: - 手動実行用に詳細な手順を記載 - Playwright MCPツールの使用方法を明示 - 各テストシナリオで期待される結果を明確化 - 要件定義書の受入基準と紐付け **カバレッジ**: - 全11要件のうち、E2Eテスト対象の要件をすべてカバー - 7つの主要機能フローをテスト - ユーザー識別、タスク管理、所有権、永続化を検証 **品質保証**: - すべてのE2Eテストが成功することがデプロイの前提条件 - テスト失敗時はデプロイを中止 - 継続的な品質保証を実現 |
成果物
最初にURLにアクセスすると、ユーザー名を求められます。
タスクの入力、一覧ができます。
佐藤さん（タスクを入力していない人）からはこんな感じに見えます。
WebUIを見たのはここが初です。実際の開発ではこんな経験はないです…。
入力画面が左ペインになっているなあ。最初提示された要件では上ペインじゃなかったっけ？
あと動作もちょっと微妙なところがありました。やっぱり要件が指定しきれていなかったか。担当者は最初に入れた名前と当然連動すべきでしたよね。（今回は時間切れです）
所要時間
すごく時間かかりました。自分でもびっくり。他のメンバーよりかなり長いんじゃないかな。
- tasks.mdが完成するまでに2.5時間
- taskの実行に3時間くらい。（これはクライアントPCの性能か？）
- KiroにAWSへのデプロイを依頼して、デプロイして正常動作を確認できるまですごい時間がかかりました。4時間くらい。（問題がループしている状態に陥っていた）
主な機能
Kiroに整理してもらいました。
- ログイン不要: Browser IDとニックネームで簡単にアクセス
- 共有タスクリスト: 複数ユーザーで同じリストを閲覧
- 所有権ベースの編集: 自分が作成したタスクのみ編集可能
- 完全サーバーレス: AWS Lambda、DynamoDB、CloudFrontで構築
- 包括的なテスト: ユニット、プロパティベース、E2Eテスト
- 自動デプロイ: テスト失敗時はデプロイ中止
工夫点など
Kiroに整理してもらいました。私が指示したものとしていないものが混在しています。具体的には認証なしのユーザー識別システム、Infrastructure as Code は明示的に指示した内容です。
- サーバーレスアーキテクチャの採用
- インフラ管理不要、自動スケーリング、コスト効率UP
- 認証なしのユーザー識別システム（Browser ID）
- ユーザー認証はしないけど、他の人にタスク操作させないようにした
- 将来的にはユーザー認証を追加するかも
- パフォーマンス最適化（楽観的UI更新、HTTPリトライ、CDN配信）
- エラーハンドリングの多層化
- プロパティベーステスト（fast-check）の活用
- Infrastructure as Code（AWS CDK）
- 技術的なチャレンジと解決策
- Lambda関数のコールドスタート
- DynamoDBのデータモデリング
- CORS設定
- ローカル開発環境の整備
- コード品質の工夫
- TypeScriptの型安全性
- コメントとドキュメントの整備
発見と学び
つらつらと書きました。
- 詳細を理解しないままだと、単にCreditを超消費するだけな気がする。Creditの有効活用ってどうやるのがいいのか？（お金は大事ですよね）
- よくわからない技術要素でも実装できちゃう。これは新しい技術要素を取り入れるチャレンジできるという反面、操作している人間がよくわからないことが実装できちゃう怖さもありますね。
- フロントエンドのUIデザインについてはほとんどやり取りしていないけど、これでいいのか？見た目を変更したいときはどの段階でチェックして修正していくのがいいんだろうか？（実際顧客とやり取りすると、見た目のUIデザインに対する指摘って結構あると思うのですが…日本的すぎる？）
- AWSにデプロイして正常動作を確認できるまですごい時間がかかってしまった。同じような問題を繰り返している状態だったので、なんか根本的にやり方が間違っていたような気がします。自分でコード書けないのつらい。
- Kiroが修正しようとしていることを適宜理解して適切にフィードバックする能力が必要ですね。人間相手と同じだなあという印象。苦労することには変わらない。
感想
良かった点
Spec駆動というワードは聞いたことがあったので、実際試せたのはよかったです。requirements.mdとdesign.mdについては短時間でこれだけのものが作れるというのは効率UPだと感じました。
苦労した点
一方で、Kiroの出力が妥当かどうかを判定するためのスキル（アウトプットを読み解く能力、矛盾などがないかなど）が必要と感じました。特にtasks.mdについては、内容の妥当性をどうやって判定するのがいいのか正解が見つかりませんでした。
今回は時間の都合上ほとんどチェックできていないですが、実務上で使うとなるとAIに丸投げすることになるのでAIとの付き合い方としてそれはよくないですよね。あくまで人間がコントロールしないと…。「AIが間違えました。すみません」は通用しないですよね。
今後に活かせること
今回やったことをすべて今の業務に割り当てていく、というのは難しくても、要件を整理するときとかのサポートとしてこれらのステップを利用していくのはアリだなと思います。特に要件が曖昧なときとか。
この記事が、少しでもみなさんのにお役に立てば幸いです。
ここまでお読みいただき、ありがとうございました！
The following two tabs change content below.
エンジニア
エンジニア歴は約20年。
主な開発（言語）遍歴：
Cのサーバ系アプリ開発を少々
→Javaサーバ系アプリ開発をがっつり
→C#のWindowsアプリをがっつり
→ここ数年はいろんな言語、いろんな環境をちょこちょこと。
最近はコードを書かないお仕事もいろいろ。
- 【Kiro・Playwright】社内でフルAI開発バトル！！「1行も書かずに」Todoアプリを完成させた話〜 maimai の場合〜 - 2025-12-11
- いよいよ IE (Internet Explorer) のサポートが終了します - 2022-02-02
- OWASP ZAPを使って脆弱性検査をしてみる - 2021-08-12
- カレンダーの祝日、違うかも？2021年の祝日にご注意 - 2021-02-10
- Porting Assistant for .NET を使ってみた - 2020-09-04
【採用情報】一緒に働く仲間を募集しています
