1. 「作る前に捨てる」フェーズ：構想を削ぎ落とす
-
目的を1文に絞る
- 例：「営業が毎日の報告を3分で済ませられるアプリ」
-
KPIを明文化
-
「全部作らない」ことを前提にする
- MVP（最小構成）に絞る：ユーザー1人・機能1つでOK
2. ノーコード/ローコードツールの選定
| 目的 |
推奨ツール |
| UI重視 |
Glide, Adalo, OutSystems |
| 業務効率化 |
Power Apps, Kintone, Retool, AppSheet |
| データ連携重視 |
Make, Zapier, n8n |
| 分析・可視化 |
SmartDB, QuickBase, Notion + API |
💡 ポイント：自前で拡張したくなる時だけコードを足す（コード化は最後の手段）
3. 0→1の開発：超短サイクルMVP
- 「3日以内に使える」ものを作る
- 最小構成：
- 画面：最大3つ（例：入力 / 一覧 / 詳細）
- ユーザー：1部署 or 1人
- フィードバックは“その場”で聞く
-
ドキュメントは不要
- 操作動画（1分以内） or スクリーンショットで十分
4. 改善サイクル：週単位で運用・改善
- 毎週1回：ユーザーと15分ミーティング
- フィードバックはNotionやSlackで即記録
- タスク管理しすぎず、「改善ログ」として残す
5. 拡張判断：コード化 or 他ツール連携の基準
-
処理が複雑化したら → API連携 or 外部SaaSと接続
-
動作が重くなったら → 特定処理だけコードに移行
-
セキュリティ要件が増したら → IT部門と連携 or 有償版導入
🔁 継続のポイント
-
使われない機能は削除：追加より削除の方が重要
-
KPIが改善しなくなったら作り直す：無駄な改修はやらない
-
常に「現場の人」と並走する：IT部門主導にさせない
🧠 よくあるムダ（排除すべきもの）
| ムダな工程 |
なぜ不要か |
| 詳細な要件定義 |
実際に触ってもらうと前提が変わるため |
| 画面モック長期検討 |
動くものを見せる方が早く正確 |
| 操作マニュアル整備 |
UIが直感的なら動画1本で済む |
| 完璧なデータ設計 |
最初は「必要な項目だけ」で運用して改善すべき |
| テスト計画書作成 |
実際のユーザーが触って問題なければ十分 |
✅ まとめ：成功の鉄則
- 🎯 目的とKPIを最小限に絞る
- ⚡ まずは動くものを3日で出す
- 🔄 週1回の小さな改善サイクル
- 🧹 機能は削りながら洗練させる
- 👥 「使う人」と常に並走する
