- 画面仕様書と呼んでいる
- リアーキテクチャをするとき「振る舞いは、原則現行通り」となるが、現行通りとはなにかがわからない
- 自分の場合、とにかくコードを読んで理解するために頑張るわけだが大変。QAEはコードを読めないので、ドキュメントや実際に動作させて調べているらしい
- 今はClaude Codeがあるし、レガシーの実装から振る舞いを書き出してみるのがいいのではないかとやり始めた
- Claude Codeで一発で書き出して終わりというわけではなく、1,2時間くらいかけて修正している。人間が1から書くよりは早いかなという印象。あと人間が書いてもAIが書いても100点は取れないなと思っており、間違うことはあるなという前提でいる
- 実装がそう振る舞っているだけで、意思を持って決めた仕様ではないため仕様と言いたくないという気持ちにはなるが、ユーザーにとってはそんなの知らんがなという話なので、仕様とする！！！とした
- また、そう振る舞っていることを言語化しただけなので、意図はまったくわからないことが多い。「なぜそういう実装/仕様に？」は全くわからないので、意図負債は残り続けている
- 最初はレガシーの画面仕様書だけ書いていたが、リアーキテクチャ時にバグを直したり「これはやめよう」と振る舞いを変えたいことがあることに気づいた
- レガシーの画面仕様書は、as-isだが、to-be も必要になってきたということ
- ほな、作りましょうということで、レガシーの画面仕様書を元にリアーキテクチャ後の画面仕様書を書き出すようにした
- レガシーの画面仕様書には元々バグっぽい挙動や変な仕様を書き出す章があり、そこに「リアーキテクチャ時に直す」とかを記載していたので、それを元にto-beな画面仕様書を書き出すようにした
- to-beの画面仕様書は、リアーキテクチャを行う前に書き出している
- リアーキテクチャの前に書き出すことで、実装のタイミングで画面仕様書を更新できる。例えば、Golden テストを書いたら画像を貼ったり、リンクを貼れたりするわけですね。
- このあたりは、すべてスキル化されている。あとはto-beの仕様書と実装を比較するスキルとかも用意した。
- それぞれレビューややり取りをかなり細かくして、自分が説明可能な成果物が出てくるという感じ。
- まあ、実装と同じですね
- これはCritにかなり助けられている
