新しい画面を作らない。MR、Issue、Slack、Teams、メール——受賞作は既存の器に結果を返している。
DocSyncは修正をマージリクエストとIssueというGitLab標準の単位で返す。Gitdefenderもコードレビューの中で完結する。SprintForgeはメールを転送するだけで起動し、結果はJira Cloudの課題になる。VendorGuardはメール受信からレポートまで2分以内。Performance Development AssistantはSharePointから情報を取り、承認はPower Automateで流す。電通デジタルの受賞作はSlack上でエージェントが分業し、TEAM HEART LINKの見守りソリューションは日報を家族のSlackに届ける。
この設計が効く理由は2つある。第一に、審査員が「これは明日から使える」と判断しやすい。新しいツールの導入は組織の合意が要るが、既にあるMRやSlackに乗るなら導入コストの話が消える。第二に、デモが短く済む。画面遷移を説明する時間が要らず、「メールを送ると、Jiraに課題が立つ」で終わる。
実践への示唆: UIを作り込みたくなったら、その分を「どこに結果を返すか」の設計に回す。対象ユーザーが1日で最も長く開いているアプリは何か、を先に決める。作品の価値が同じでも、既存の器に返せるかどうかで審査員の受け取り方が変わる。