はじめに

こんにちは。カミナシでソフトウェアエンジニアをしているShimmy(@naoya7076) です。

皆さんは、仕様検討の段階で「本当に想定通り実装できるだろうか？」と不安になったことはありませんか？実際に実装してみたら想定外の技術的制約にぶつかり、手戻りが発生した経験はないでしょうか？

本記事では、AIに仮実装をさせることで実装の難所を事前に発見し、より良い仕様へ素早く変更した実例をお話します。

背景

承認一覧画面のパフォーマンス問題

「カミナシレポート」は現場で使う帳票をペーパーレス化し、従業員と管理者の生産性を高めるクラウドサービスです。従業員が記録した内容を、管理者が承認するための「承認一覧画面」というページがあります。

承認一覧画面では、歴史的経緯により初期表示時に「全件」取得していました。データ量の増加に伴い、初期表示に数分かかるケースが発生し、根本的な仕様見直しが必要となりました。技術的な改善（SQLチューニングやインデックス最適化）では限界があり、「全件取得」から「期間指定取得」への仕様変更を検討することになりました。

仕様を変える

Before

承認対象レポートをすべて取得
絞り込みはユーザー操作に依存

After

初期表示は直近1ヶ月分のみ取得（デフォルト設定）
ユーザーが期間を変更可能（上限3ヶ月まで）

この変更により、画面の初期表示時間が短くなり、将来データが増えても処理速度が落ちにくい仕様になりました。

初期の仕様

仕様変更において考慮すべきはUI/UXです。顧客ごとに少しずつ使い方は違いますが、個別最適を積み上げるとUIは複雑化しがちです。当初検討していたUIは次のような多段構造でした：

セレクトボックスで「直近2週間」「直近4週間」「任意の期間」のいずれかを選ぶ
「任意の期間」を選ぶとカレンダー展開
カレンダーで選択した結果をセレクトボックスに反映

この仕様に潜在的なリスクや実装上の障壁はないのか？チーム内で少し話題に上がったものの、具体的な問題点は明確になっていませんでした。

AIでの仮実装

そこで、AIに実際にコンポーネントの仮実装をしてもらいました。生成結果では次の事がわかりました。

親コンポーネント（期間表示）、子コンポーネント（選択ボックス）、孫コンポーネント（カレンダー）の3層間でstateの受け渡しが必要
Ant DesignのRangePickerは入力ボックスとカレンダーパネルが一体化しており、パネルだけを独立して表示するAPIが存在しない
- この制約により、当初の仕様を実現するには独自実装が必要