📚 ナレッジベース

システム開発_経営者向け基礎知識マップ

最終更新 2026年05月15日 ／ 21_ナレッジベース/プロダクト開発/システム開発_経営者向け基礎知識マップ.md

システム開発 経営者向け基礎知識マップ

AIがコードを書ける時代こそ、経営者の「判断力」が事業を分ける。
月額15万円で毎月1サービス作る破格モデルを成立させるための、非エンジニア経営者必修ナレッジ集。

30秒で全体像

観点 一言
核心 AIにコード書かせるからこそ、経営者は「設計判断」「品質判定」「事故対応」の3点で技術力が必要
キーワード 全体像 / DB / セキュリティ / インフラ / 契約 / SLA / 退化防止
使う人 大串（SCALE代表）/ 月額15万SaaS事業を背負う非エンジニア経営者
読了目安 25分
きっかけ CRM稼働後の大問題多発 → 知識不足の痛感（2026-05-15）
目標 月額15万で毎月1サービス × 業界破壊

なぜ知識が必要か（CRMで体験した問題から逆算）

「AIにコード書かせる」≠「経営者の知識ゼロでOK」

AI（Claude Code等）は 書かれた要件通りに動く。でも：
- 何を要件として書くべきか
- できたコードが本当に大丈夫か
- 障害が起きた時に何を調べるべきか
- ユーザーの不満が技術問題か仕様問題か

→ これらは AI じゃなくて経営者が判断する。判断には基礎知識が要る。

CRMで起きた典型「大問題」と知識不足の対応関係

よくあるトラブル 必要だった知識
データが消える・上書きされる データベース設計・トランザクション
急に重くなる・止まる パフォーマンス・インデックス・キャッシュ
ログイン突破される 認証・パスワードハッシュ化・JWT
個人情報漏洩リスク セキュリティ（XSS/CSRF/SQLi）・暗号化
機能追加で他が壊れる テスト・バージョン管理・退化防止
バックアップなくて復旧不可 インフラ・運用・DR（災害復旧）
メール届かない SMTP・DNS・SPF/DKIM/DMARC
同時編集で消える 排他制御・楽観/悲観ロック
スマホで崩れる レスポンシブデザイン・CSS
API無料枠超過で請求爆発 レート制限・モニタリング

→ 全部「知ってれば防げた」案件。知らないとAIに正しい指示も出せない。

必須10知識領域マップ

1. システムの全体像（最初に絶対）

[ユーザー]
   ↓ HTTP/HTTPS（インターネット）
[フロントエンド]（HTML/CSS/JavaScript・ブラウザで動く）
   ↓ API呼び出し
[バックエンド]（サーバーで動く・ロジック処理）
   ↓ SQL等
[データベース]（データ保存）
   ↑
[インフラ]（サーバー・ネットワーク・ストレージ）

わかるべきこと:
- 画面（フロント）とロジック（バック）とデータ（DB）が分離されてる
- それらが API で通信してる
- 全部「インフラ」の上で動いてる
- どこに何の責任があるか

2. ネットワーク・通信（HTTP/API）

わかるべきこと:
- HTTP/HTTPS の違い（HTTPS = 暗号化）
- GET / POST / PUT / DELETE の意味
- REST API の基本
- ステータスコード（200成功 / 404未発見 / 500サーバーエラー）
- API の認証（API Key / OAuth / JWT）
- レート制限・タイムアウト

典型トラブル: 「APIが急に動かない」→ レート制限超過 / 認証切れ / サーバーダウン

3. データベース（最重要）

わかるべきこと:
- リレーショナルDB（MySQL / PostgreSQL / SQLite / D1）と NoSQL（MongoDB / Firebase / KV）の違い
- テーブル・カラム・行の概念
- 正規化（重複データを排除する設計）
- インデックス（検索を速くする仕組み）
- トランザクション（複数の処理をまとめて成功 or 失敗）
- バックアップ・リストア
- マイグレーション（スキーマ変更）

典型トラブル: 「データ消える」「重い」「同時更新で壊れる」 → 全部DB知識で防げる

4. セキュリティ（事業継続の生命線）

わかるべきこと:
- 認証（誰か）と認可（何ができるか）の違い
- パスワードのハッシュ化（平文保存は犯罪レベルNG）
- XSS（クロスサイトスクリプティング）
- CSRF（クロスサイトリクエストフォージェリ）
- SQLインジェクション
- 個人情報保護法 / GDPR
- HTTPS必須化
- セッション管理

典型トラブル: 漏洩→賠償・信用失墜・廃業リスク → これだけは絶対知っとく

5. インフラ（クラウド・サーバー）

わかるべきこと:
- クラウド（AWS / GCP / Cloudflare）の基本サービス
- サーバー / コンテナ / サーバーレスの違い
- CDN（コンテンツ配信）
- ロードバランサー（負荷分散）
- DNS（ドメインとIPの紐付け）
- スケーリング（垂直 / 水平）
- 料金体系（従量課金の罠）

典型トラブル: 「請求書が¥100万」→ スケーリング失敗 / 設定ミス / 攻撃

6. デプロイ・運用（CI/CD・モニタリング）

わかるべきこと:
- デプロイ = 本番反映する行為
- CI/CD = 自動テスト・自動デプロイ
- モニタリング（システムの健全性監視）
- ログ収集
- アラート設計
- ロールバック（前のバージョンに戻す）

典型トラブル: 「壊れたまま気づかない」→ モニタリング・アラート未設定

7. バージョン管理（Git / GitHub）

→ 既に GitHub_経営者向け完全ガイド でカバー済み

8. 開発手法（アジャイル・MVP・テスト）

わかるべきこと:
- ウォーターフォール vs アジャイル
- MVP（必要最小限の製品）
- スプリント（2週間サイクル等）
- 単体テスト・結合テスト・E2Eテスト
- コードレビュー
- 退化防止（リグレッション）

→ 既存ノート: 開発手法（アジャイル MVP）

9. ビジネス・契約（SLA / 著作権 / 個人情報）

わかるべきこと:
- SLA（サービス品質保証）= 稼働率99.9%等
- 著作権（コードの所有権）
- 個人情報保護法（収集・保管・削除のルール）
- 業務委託契約 vs 請負契約 vs 準委任
- 瑕疵担保責任（バグの責任範囲）
- リスク移転（保険・免責条項）

典型トラブル: 「契約曖昧で永久サポート要求される」→ 月額15万モデルで致命傷

10. ユーザビリティ（UI/UX・アクセシビリティ）

→ 既存ノート: UI UXデザイン原則

厳選おすすめ書籍12冊（フェーズ別）

Phase 1: 経営者の教養（最初の1ヶ月・必読4冊）

# 書籍名 著者 なぜ読む
1 プロになるためのWeb技術入門 小森裕介 Webシステムの全体像が掴める。最初の1冊はこれ
2 なぜ、システム開発は必ずモメるのか？ 細川義洋 発注者・経営者必読。契約・要件定義の地雷地図
3 絵で見てわかる ITインフラの仕組み 山崎泰史 他 サーバー・ネットワーク・クラウドの全体像
4 ソフトウェア・ファースト 及川卓也 IT経営戦略・自社開発の組織論

Phase 2: 技術知識の基礎（2ヶ月目・必読4冊）

# 書籍名 著者 なぜ読む
5 Webを支える技術 山本陽平 HTTP・REST・API の基礎。APIで困らなくなる
6 SQL ゼロからはじめるデータベース操作 ミック DB操作の基礎。データ事故を防ぐ
7 体系的に学ぶ 安全なWebアプリケーションの作り方（徳丸本） 徳丸浩 セキュリティの聖書。漏洩したら廃業
8 リーダブルコード Dustin Boswell コード品質の判定基準。AI生成コードのレビュー力

Phase 3: 開発組織と運用（3ヶ月目・推奨4冊）

# 書籍名 著者 なぜ読む
9 エンジニアリング組織論への招待 広木大地 技術組織のマネジメント・技術負債
10 SCRUM BOOT CAMP THE BOOK 西村直人 他 アジャイル開発の入門書
11 プロダクトマネジメントのすべて 及川卓也 他 PM思考・優先度判定
12 入門 監視（オライリー） Mike Julian モニタリング・運用の基礎

上級・興味あれば

  • 詳解HTTP/2（HTTP最新動向）
  • SREサイトリライアビリティエンジニアリング（Google式運用）
  • マイクロサービスアーキテクチャ（システム分割設計）
  • データ指向アプリケーションデザイン（DB深掘り・大型本）

学習ロードマップ（3ヶ月プラン）

Month 1: 全体像把握（経営者の言語化フェーズ）

Week 1-2:
  - 『プロになるためのWeb技術入門』を読む
  - 既存CRMの構造を「フロント / バック / DB / インフラ」で分解してみる

Week 3-4:
  - 『なぜ、システム開発は必ずモメるのか？』を読む
  - 過去CRMトラブルを「どの章の問題か」で分類
  - 月額15万契約書の SLA・責任範囲を見直す

Month 2: 技術深掘り（判断力フェーズ）

Week 5-6:
  - 『Webを支える技術』+ Postman でAPIを実際に叩く
  - SCALE Base / CRM のAPI仕様を読む

Week 7-8:
  - 『SQL ゼロから』+ SQLite で実際にクエリを書く
  - 既存システムのDB設計を確認・問題点洗い出し

並行:
  - 徳丸本（セキュリティ）を毎日30分
  - 自社全システムのセキュリティチェック

Month 3: 運用・組織（事業化フェーズ）

Week 9-10:
  - 『リーダブルコード』+ AI生成コードのレビュー実践
  - PRレビュー文化を社内導入

Week 11-12:
  - 『エンジニアリング組織論』+ SCALE体制の組織設計
  - 月額15万モデルの「運用フロー」「契約書」を完成

月額15万モデル特有のリスクと対策

構造的リスク

リスク 内容 対策
永久サポート要求 「月額払ってるんだから何でも対応して」 契約書で 作業範囲・対応時間 を明記
要件膨張 月15万で機能追加無限要求 「月1サービス＝1事業の新規構築」と定義
AI生成バグの責任 バグの責任は誰が負う？ 瑕疵担保期間を明記（例: 納品後30日）
セキュリティ事故 1社の漏洩で22社全部失う サイバー保険加入・SLA明記
AIの料金高騰 Claude API料金が将来上がったら赤字 契約に「インフラ費別途」条項
顧客のスケール対応 サービスが当たって急成長したら追加料金は？ 利用量別プラン（Free→Team→Enterprise）

月額15万モデル成立の必須条件

1. 開発時間を圧縮する仕組み
   - テンプレ化（共通基盤）
   - AI活用（Claude Code）
   - 自動化（CI/CD・テスト）

2. 運用コストを圧縮する仕組み
   - インフラ自動化（Cloudflare Pages 等の従量制）
   - モニタリング自動化
   - サポート FAQ・自動応答

3. 責任範囲の明確化
   - SLA（稼働率99.5% 等）
   - サポート時間（平日10-18時 等）
   - 瑕疵担保期間
   - 個人情報の取り扱い

4. 顧客の選別
   - スタートアップ・中小企業向け
   - 大企業（高SLA要求）は別プラン

月額15万 × 22社 × 12ヶ月 = ¥3,960万/年（ARR）

コスト構造試算:
- AI API費用: ¥3,000-10,000/社/月
- インフラ費: ¥1,000-5,000/社/月
- サポート工数: 1社あたり月2時間
- 22社合計: ARR ¥3,960万 - 経費 ¥800-1,200万 = 利益 ¥2,700-3,200万

→ 利益率 70%超え可能。ただし「事故ゼロ」が前提。
→ 1社のセキュリティ事故で全社失う構造リスクあり

非エンジニアが陥る7つの罠

# 罠 防ぎ方
1 「動いてる = 正しい」と思う 自動テスト・モニタリング・ログ確認の習慣化
2 AIに「いい感じに」依頼する 要件を具体的に・受け入れ基準を明確に
3 デプロイ = 完了と思う 本番動作確認・モニタリング監視・退化検知まで
4 バックアップを軽視 自動バックアップ・復元テストを定期実行
5 セキュリティを後回し 設計段階で組み込む（後から足すのは10倍コスト）
6 エンジニアに丸投げ 自分でも基礎知識を持って判定する
7 契約書を曖昧にする SLA・責任範囲・解約条件を必ず明記

知識チェックリスト（自己診断）

Level 1: 経営者最低限（全部わかるべき）

  • [ ] HTTP と HTTPS の違いを説明できる
  • [ ] フロントエンド・バックエンド・データベースの責任分担を説明できる
  • [ ] API とは何か説明できる
  • [ ] パスワードを平文保存することがNGな理由を説明できる
  • [ ] バックアップが必要な理由を説明できる
  • [ ] バージョン管理（Git）が必要な理由を説明できる

Level 2: 中級（半年以内に到達したい）

  • [ ] SQL の SELECT / INSERT / UPDATE / DELETE が読める
  • [ ] REST API の設計を見て妥当性が判断できる
  • [ ] DB のテーブル設計を見て正規化されてるか判断できる
  • [ ] クラウドサービスの料金体系を理解している
  • [ ] CI/CD パイプラインの目的が説明できる
  • [ ] XSS / CSRF / SQLi の攻撃パターンと対策を説明できる

Level 3: 上級（1年以内に到達）

  • [ ] システムアーキテクチャ図を見て改善点を指摘できる
  • [ ] パフォーマンス問題の切り分けができる
  • [ ] セキュリティ事故時の初動対応フローを設計できる
  • [ ] SLA / SLO / SLI を区別して契約に組み込める
  • [ ] 技術負債を ROI で経営判断できる

SCALE固有の戦略提案

月額15万モデル成立のための SCALE 強み活用

SCALE の強み 月額15万モデルへの活用
Claude Code 活用ノウハウ 開発時間 1/10 化
22サービス並行体制 共通基盤の再利用率最大化
Cloudflare Pages 運用 インフラ費 ¥1,000/月レベル
AI エージェント13名 サポート工数の AI 化
Vault（Obsidian）で知見集約 失敗パターンの再発防止

共通基盤の重要性

1社あたりゼロから作る → 月15万では赤字
共通基盤（認証・課金・通知・DB）を持つ → 月15万で利益70%

必須共通基盤:
- 認証システム（OAuth + パスワード）
- 課金システム（Stripe 連携）
- 通知システム（Email・Slack）
- データベース基盤（D1 / Supabase）
- デザインシステム（既存活用）
- API ゲートウェイ

→ 22サービスで使い回せる「土台」を作る投資が先。

今日からのアクション

最優先（今週）

1. 『プロになるためのWeb技術入門』を Amazon でポチる
2. 『なぜ、システム開発は必ずモメるのか？』も同時購入
3. 通勤・移動時間で読む（毎日30分）

今月

4. 『絵で見てわかる ITインフラの仕組み』読了
5. 既存CRMの問題リストを「10知識領域」でマッピング
6. 月額15万契約書のドラフト作成（SLA・責任範囲）

今四半期

7. Phase 1-2 の8冊読了
8. SCALE 共通基盤の設計
9. 月額15万モデルのパイロット顧客1社獲得

関連ノート

改訂履歴

日付 内容
2026-05-15 初版作成。CRM稼働後の問題多発（知識不足の痛感）+ 月額15万SaaS事業構想をきっかけに、非エンジニア経営者向け基礎知識を体系化