生成AIで、作るスピードは上がりました。追いつかなくなったのは、何が出来上がったのかの確認です。Asklessは、マージされたPRから機能仕様を起こし、すべての記述にコードの該当行を添えます。PMやサポートは、コードを読まずに、出来上がったものが意図どおりかを確かめられます。コードから確定できないことは推測で埋めず、「開発チームに聞くこと」として分けて返します。
// checkout.ts - if (cart.total > 0) applyTax(); + if (cart.total > 0 && !cart.isGift) { + applyTax(); + } // #482 ギフト注文を非課税に
カート内の商品が「ギフト」指定の場合、税額計算をスキップする。
cart.isGift = true の注文開発と事業のあいだを、同じ確認が何度も行き来しています。
作るハードルが下がって、誰が先に仕様を考えるかは、案件ごとに変わるようになりました。
開発者が仕様を考えて、PRを出します。マージされると、変わった機能の仕様が届きます。PMやサポートは、それを読んで意図どおりかを確かめ、利用者への案内に使えます。
PMが考えた仕様で、開発が実装します。PRから起きた仕様を読めば、頼んだとおりに出来ているかを、コードを読まずに確かめられます。
出典のない記述を「書かないようお願い」しているのではありません。書けない構造になっています。
いまのコードから、ユーザーに見える機能ごとに仕様を書き起こします。解析対象のコードは書き換えません。
マージされたPRで変わった機能の仕様を更新します。すべての記述に、ソースの該当行が付きます。出典のない項目は、スキーマの段階で存在できません。
コードから確定できないことは推測せず、「開発チームに聞くこと」に回します。答えは仕様に書き戻せます。
| これまで | Asklessを使うと |
|---|---|
| 何が変わったかを、開発者に聞いて回る | 変わった機能の仕様が、マージのたびに届く |
| もっともらしい要約を、自分で裏取りする | 裏は最初から、該当行へのリンクで付いている |
| 確かめた答えが、チャットに埋もれる | 答えを仕様に書き戻し、確認済みにできる |
Asklessの基盤であるOSS版spec-bridgeは、作者が開発に関わっていない3つのOSSのPR履歴に対して動作検証を行っています。初めて読むコードベースで、出典付きの仕様が書けるかどうか。それをそのまま確かめた検証です。詳細はGitHubのREADMEをご覧ください。
作者が一行も書いていないdocumensoのコードから起こした仕様を、実物のまま読む →
登録は不要です。電子署名サービスの「署名依頼の自動リマインダー」機能について、全19件の記述すべてにGitHubの該当行へのリンクが付いています。生成したものに手を加えずに掲載しています。
作者が一行も書いていないgiteaのコードから、開発者に聞くべきことを洗い出した結果を見る →
7つの機能について、コードから確定できなかった点を種類ごとに分けています。人に確かめるしかない「聞くべきこと」は12件で、それぞれに答えを探して開いたファイルへのリンクが付いています。
正式リリースに先立って、案内をお送りします。導入のご相談も歓迎です。