ベストプラクティス
Jeliqでアプリを作成する際のベストプラクティスをまとめました。これらのヒントを活用して、より効率的に、より良いアプリを作成しましょう。開発の進め方
1. 小さく始めて段階的に拡張
推奨アプローチ:-
Phase 1:基本機能
- データの登録・編集・削除
- 一覧表示
- 基本的な検索
-
Phase 2:便利機能
- 詳細な検索・フィルター
- ダッシュボード
- 集計・レポート
-
Phase 3:高度な機能
- 通知機能
- 外部連携
- 権限管理
2. こまめに確認・保存
プレビューで確認
ビルド後は必ずプレビューで動作確認を行いましょう。
変更履歴で保存
良い状態ができたら、すぐに保存しましょう。
3. リンク切れチェックを習慣化
仕様書作成後、ビルド前に必ず以下のコマンドを入力しましょう。プロンプトのコツ
具体的に伝える
- 悪い例
- 良い例
- 何を管理するのか不明
- 誰が使うのか不明
- 必要な機能が分からない
業務フローを説明する
単に「〇〇を管理したい」だけでなく、実際の業務フローを説明すると、より適切な設計になります。例外ケースも伝える
通常のケースだけでなく、例外ケースも伝えておくと、より堅牢なアプリになります。データモデルのポイント
必須/任意を明確に
データ項目を伝える際は、必須か任意かを明示しましょう。選択肢は具体的に
ステータスやカテゴリなど、選択肢がある項目は具体的に伝えましょう。データ間の関係を説明
複数のデータを管理する場合は、それらの関係を説明しましょう。画面設計のポイント
必要な画面を列挙
作りたい画面を具体的に列挙しましょう。ユーザーの動線を考える
ユーザーがどのような順序で画面を見るか、動線を考えましょう。トラブル対処
ビルドが失敗した場合
- エラーメッセージを確認
- AIにエラーメッセージを伝える
- 仕様書が修正されたら再ビルド
意図と異なる動作の場合
- プレビューで問題を特定
- 具体的に問題を伝える
- 仕様書が修正されたら再ビルド
仕様書が複雑になりすぎた場合
仕様書が複雑になりすぎて修正が難しい場合は、新しいアプリを作成して最初からやり直すことも選択肢の一つです。よくある失敗と対策
一度にすべてを作ろうとする
一度にすべてを作ろうとする
問題: 複雑な要件を一気に伝えると、AIが混乱したり、意図と異なる設計になることがあります。対策: 小さく始めて、動作確認しながら段階的に機能を追加しましょう。
曖昧な表現を使う
曖昧な表現を使う
問題: 「いい感じに」「適当に」などの曖昧な表現は、意図と異なる結果になりやすいです。対策: 具体的な要件を、箇条書きで明確に伝えましょう。
確認せずにビルドを繰り返す
確認せずにビルドを繰り返す
問題: 仕様書を確認せずにビルドすると、意図と異なるアプリが生成され、修正の手間が増えます。対策: ビルド前に仕様書を確認し、リンク切れチェックを実行しましょう。
保存を忘れる
保存を忘れる
問題: 良い状態ができても保存を忘れると、問題発生時に戻せなくなります。対策: 機能実装のたびに、変更履歴で保存を確定しましょう。