三つの領域を設計の依存関係として扱う
見出しに並ぶユーザー体験、フロントエンド、バックエンドは、同じ作業の別名ではない。確認できるのは、三つの領域を横断して設計する必要があるということまでである。接続順や担当範囲については、資料から判断できない。
このため、実装の最初に各領域の境界を固定する必要がある。ユーザーにはどの状態を伝えるのか、その状態をフロントエンドがどう扱うのか、バックエンドがどの処理を担当するのかを、同じ単位で整理する。境界を先に決めなければ、表示と処理のどちらを変更すべきか判断できない。
確認項目は、三つで十分である。
- ユーザー体験：利用者が結果をどのように受け取るか
- フロントエンド：画面上でどの状態を扱うか
- バックエンド：どの処理結果と責任を返すか
ここでは、三つの領域を独立した工程として扱うべきではない。どれか一つが欠けても、エージェント型UIの信頼性を一貫して説明できないと見るのが自然である。ただし、記事にはその欠落がどのような障害として現れるかが書かれていない。具体的な障害名を補ってはいけない。
また、「フロントエンドで完結する処理」と「バックエンドに委ねる処理」を混同しないことが重要である。画面の表示だけで完了したように見えても、実際の処理結果とは別の状態として残る可能性がある。この場合も、記事から具体的な処理方式を推測するのではなく、表示と処理を別々に記録する。
個人開発では境界表を先に作る
Laravel、Docker、WordPressを使う個人開発では、フレームワークの有無だけで領域を区切ってはならない。重要なのは、ツールがどこで動くかではなく、各画面状態に対して責任が一つに定まるかである。
実装前に、次の項目を一行にまとめてみる。
- 画面上で利用者が目にする状態
- フロントエンドが受け持つ処理
- バックエンドが返す結果
- 状態が変わったときの表示と記録
この表を作る目的は、三つの領域の作業を整理することだけではない。実装後に不整合が起きたとき、変更箇所を限定するためでもある。境界表がなければ、修正箇所を推測で広げることになる。
特に個人開発では、フロントエンドとバックエンドを同じ開発者が担当することが多い。この場合、一つの処理を変更しても、表示、通信、記録のすべてを同時に変更してしまいがちである。処理を分割し、各領域が保持する状態を明記すれば、変更の影響範囲を確認しやすくなる。
ただし、接続方式やAPIの構成を自由に想像してはならない。紹介文には、具体的な技術構成、通信手順、保存方法、エラー処理の実装がない。したがって、境界表は実装仕様ではなく、確認すべき論点を置く設計資料として扱う。
現時点で確認できることと、確認できないこと
今回の資料で直接確認できるのは、devmioがエージェント型UIの信頼性をUX、フロントエンド、バックエンドの三領域にまたがる問題として提示したことである。確認できないのは、次の情報である。
- 実際の画面設計
- 具体的な実装コード
- 使用しているフレームワークやサービス
- 性能計測の結果
- 信頼性を判断する条件
- 障害や失敗の具体例
したがって、改善率、処理速度、計算量などを数値で示すべきではない。紹介文にない数値を補うと、設計上の提案を実績のように見せかねない。現時点でできるのは、三つの領域を実装前に接続し、責任を文書化することまでである。
個人開発者にとっての実務上の次の一手は、画面の機能追加を始める前に、三領域の対応表を一行でも作ることである。実装が進んだ後では、既存の表示や処理のどちらを修正すべきか判断するコストが増える。まず境界を固定し、その後にコードと計測結果を増やす。この順序なら、推測を実績として扱うことなく、UX、フロントエンド、バックエンドの依存関係を検証できる。
関連記事: AI時代のエンジニアの役割：コードを書くことから「境界線」を設計することへ 、 ヘッドレスUIと装飾済みコンポーネント：個人開発におけるUI設計の二つの選択肢.