Skip to main content

ベストプラクティス

Jeliqでアプリを作成する際のベストプラクティスをまとめました。これらのヒントを活用して、より効率的に、より良いアプリを作成しましょう。

開発の進め方

1. 小さく始めて段階的に拡張

最初からすべての機能を盛り込まず、コア機能から始めて段階的に追加していくのが成功の鍵です。
推奨アプローチ:
  1. Phase 1:基本機能
    • データの登録・編集・削除
    • 一覧表示
    • 基本的な検索
  2. Phase 2:便利機能
    • 詳細な検索・フィルター
    • ダッシュボード
    • 集計・レポート
  3. Phase 3:高度な機能
    • 通知機能
    • 外部連携
    • 権限管理

2. こまめに確認・保存

プレビューで確認

ビルド後は必ずプレビューで動作確認を行いましょう。

変更履歴で保存

良い状態ができたら、すぐに保存しましょう。

3. リンク切れチェックを習慣化

仕様書作成後、ビルド前に必ず以下のコマンドを入力しましょう。
仕様書にリンク切れがないかチェックして
これにより、仕様書間の依存関係に問題がないかチェックされ、バグを事前に防げます。

プロンプトのコツ

具体的に伝える

いい感じの管理システムを作って
問題点:
  • 何を管理するのか不明
  • 誰が使うのか不明
  • 必要な機能が分からない

業務フローを説明する

単に「〇〇を管理したい」だけでなく、実際の業務フローを説明すると、より適切な設計になります。
顧客から問い合わせがあったら:
1. 顧客情報を登録(まだ登録がなければ)
2. 問い合わせ内容を商談として記録
3. 担当者をアサイン
4. 対応後、ステータスを更新
5. 月末に担当者別の対応件数をレポート

この流れに沿ったシステムを作りたい。

例外ケースも伝える

通常のケースだけでなく、例外ケースも伝えておくと、より堅牢なアプリになります。
顧客のステータスは通常「見込み→商談中→成約」の順で進むが、
「商談中」から「保留」になるケースもある。
保留後は「見込み」に戻ることも、「失注」になることもある。

データモデルのポイント

必須/任意を明確に

データ項目を伝える際は、必須か任意かを明示しましょう。
顧客情報として以下を管理したい:
- 会社名(必須)
- 担当者名(必須)
- メールアドレス(必須)
- 電話番号(任意)
- 住所(任意)
- メモ(任意、自由記述)

選択肢は具体的に

ステータスやカテゴリなど、選択肢がある項目は具体的に伝えましょう。
商談ステータスの選択肢:
1. リード(新規問い合わせ)
2. ヒアリング(要件確認中)
3. 提案中
4. 見積提出済
5. 成約
6. 失注
7. 保留

この順番で選択肢を表示してほしい。

データ間の関係を説明

複数のデータを管理する場合は、それらの関係を説明しましょう。
以下のデータを管理したい:
- 顧客:1つの顧客に複数の商談がある
- 商談:1つの商談は1人の担当者が担当
- 担当者:1人の担当者は複数の商談を担当できる

画面設計のポイント

必要な画面を列挙

作りたい画面を具体的に列挙しましょう。
必要な画面:
1. ダッシュボード(トップページ)
   - 今月の売上、商談数、成約率を表示
   - 直近の商談一覧

2. 顧客一覧
   - 会社名で検索可能
   - ステータスでフィルター可能

3. 顧客詳細
   - 基本情報の表示・編集
   - 関連する商談の一覧

4. 商談登録/編集
   - 入力フォーム

ユーザーの動線を考える

ユーザーがどのような順序で画面を見るか、動線を考えましょう。
典型的な使い方:
1. ダッシュボードで全体を把握
2. 顧客一覧で特定の顧客を検索
3. 顧客詳細で過去の商談を確認
4. 新しい商談を登録
5. ダッシュボードで成果を確認

トラブル対処

ビルドが失敗した場合

  1. エラーメッセージを確認
  2. AIにエラーメッセージを伝える
    ビルドでこのエラーが出た:[エラーメッセージ]
    修正して。
    
  3. 仕様書が修正されたら再ビルド

意図と異なる動作の場合

  1. プレビューで問題を特定
  2. 具体的に問題を伝える
    顧客一覧画面で「会社名」で検索しても、結果が表示されない。
    部分一致検索できるように修正して。
    
  3. 仕様書が修正されたら再ビルド

仕様書が複雑になりすぎた場合

仕様書が複雑になりすぎて修正が難しい場合は、新しいアプリを作成して最初からやり直すことも選択肢の一つです。
このアプリをコピーして、新しいアプリとして作り直したい。
以下の点を改善して:
- [改善点1]
- [改善点2]

よくある失敗と対策

問題: 複雑な要件を一気に伝えると、AIが混乱したり、意図と異なる設計になることがあります。対策: 小さく始めて、動作確認しながら段階的に機能を追加しましょう。
問題: 「いい感じに」「適当に」などの曖昧な表現は、意図と異なる結果になりやすいです。対策: 具体的な要件を、箇条書きで明確に伝えましょう。
問題: 仕様書を確認せずにビルドすると、意図と異なるアプリが生成され、修正の手間が増えます。対策: ビルド前に仕様書を確認し、リンク切れチェックを実行しましょう。
問題: 良い状態ができても保存を忘れると、問題発生時に戻せなくなります。対策: 機能実装のたびに、変更履歴で保存を確定しましょう。