システム開発の基礎知識

～ DX人材育成プログラム 事前学習テキスト ～

本テキストについて

このテキストは、システム開発に初めて触れる方を対象に、業務のデジタル化（DX）を推進するために最低限知っておくべき基礎知識をまとめたものです。プログラミングのスキルは問いません。「システムとは何か」「どうやって作られるのか」「自社の業務改善にどう活かせるのか」を理解することがゴールです。

想定読了時間：約1時間

第1章　コンピュータとソフトウェアの基本

1-1. コンピュータの5大機能

コンピュータは、どれほど高性能なものでも、基本的には次の 5つの機能 の組み合わせで動いています。

すべてのシステムは、この「入力 → 処理（演算・制御） → 出力」の流れで動いています。たとえば、Excelで売上データを入力し、合計を計算して、グラフを表示するのも、この流れそのものです。

1-2. ハードウェアとソフトウェア

コンピュータは ハードウェア（物理的な機器）と ソフトウェア（プログラム）の2つで構成されます。

• ハードウェア: パソコン本体、キーボード、モニターなど、目に見えて触れるもの
• ソフトウェア: ハードウェア上で動くプログラム。大きく2種類に分かれる
  • OS（オペレーティングシステム）: ハードウェアを管理し、他のソフトウェアが動く土台を作る基本ソフト（例：Windows、macOS、Android）
  • アプリケーションソフト: 特定の目的のために作られたソフト（例：Excel、ブラウザ、業務システム）

OSは「建物の基礎や配管」、アプリケーションは「その上に作られた部屋や設備」だと考えるとわかりやすいでしょう。私たちが普段使っているアプリケーションは、すべてOSという土台の上で動いています。

1-3. 2種類の記憶装置

コンピュータの「記憶」には、速度と持続性の異なる2種類があります。

パソコンの動作が遅くなるのは、メモリ（作業机）がいっぱいになって処理しきれなくなっている場合が多くあります。この仕組みを知っておくと、「なぜ不要なアプリを閉じると動作が速くなるのか」が理解できます。

第2章　Webシステムの仕組み

2-1. クライアントとサーバー

私たちが普段使っているWebサービス（ネットショッピング、クラウド会計ソフトなど）は、クライアント と サーバー という2つの役割に分かれて動いています。

• クライアント（利用者側）: Webブラウザやスマートフォンのアプリなど、利用者が操作する側
• サーバー（提供者側）: データの保存や処理を行い、結果をクライアントに返すコンピュータ

たとえば、ネット通販で商品を検索するとき、次のようなやり取りが行われています。

[あなたのブラウザ]  →  「"タオル"で検索して」というリクエストを送る
                         ↓
[サーバー]          →  データベースから該当商品を探す
                         ↓
[あなたのブラウザ]  ←  検索結果の一覧を受け取って画面に表示する

このリクエスト（要求）とレスポンス（応答）のやり取りが、Webシステムの基本的な動き方です。

2-2. Webシステムの3つの層

規模の大きなWebシステムは、役割ごとに 3つの層 に分けて作られるのが一般的です。

層を分けることで、たとえば「画面のデザインを変えたいが、裏側の計算ロジックは変えたくない」といった変更が、互いに影響を与えずに行えるようになります。これは、システムの保守（メンテナンス）を楽にするための重要な考え方です。

2-3. APIとは何か

API（Application Programming Interface） とは、ソフトウェア同士がデータをやり取りするための「窓口」のことです。

身近な例を挙げると、天気予報アプリは自分で天気を観測しているわけではありません。気象データを提供しているサービスの「API」を通じてデータを受け取り、画面に表示しています。

APIの仕組みを理解しておくと、「あるシステムのデータを、別のシステムで自動的に使う」という システム連携 の発想ができるようになります。これはDXの推進において非常に重要な考え方です。

たとえば：

• 受注システムのデータをAPIで会計ソフトに自動連携する → 手入力の手間とミスが減る
• 勤怠システムのデータをAPIで給与計算に連携する → 転記作業が不要になる

第3章　システム開発の進め方

3-1. 2つの開発手法

システム開発には、大きく分けて2つの進め方があります。

ウォーターフォール型

水が上から下に流れるように、工程を順番に1つずつ進めていく手法です。

要件定義 → 設計 → 実装（プログラミング） → テスト → 運用開始

• 向いている場面: 要件が最初から明確で、途中変更が少ないプロジェクト（例：法令対応のシステム改修）
• 注意点: 後の工程で問題が見つかると、前の工程に戻るコストが大きい

アジャイル型

短い期間（通常2〜4週間）で「設計→実装→テスト」の小さなサイクルを繰り返し、動くものをまず作って、利用者のフィードバックを得ながら改善していく手法です。

• 向いている場面: 短期間でまず市場に投入したい場合、利用者の反応を見ながら方向性を決めたい場合
• 注意点: 「完成」の定義が曖昧になりやすく、管理が難しい。「要件が変わりやすいからアジャイルにする」という考え方は危険で、要件定義の重要性はどちらの手法でも変わらない

どちらが良い・悪いではなく、プロジェクトの性質に応じて使い分けることが重要です。

3-2. 開発工程の全体像

どちらの手法でも、システム開発は基本的に以下の工程を経て進みます。

特に重要なのは、最初の「要件定義」がシステムの品質を決定づける という点です。ここで業務の課題や必要な機能を正確に洗い出せないと、どれほど優れた技術で実装しても、使えないシステムになってしまいます。

3-3. テストの種類

テストは1回やれば終わりではなく、段階的に行われます。

テストで不具合（バグ）が見つかるのは、むしろ正常なプロセスです。テストの目的は「バグがないことを証明する」ことではなく、「バグを早期に発見して修正する」 ことにあります。

第4章　業務改善とシステム化の考え方

4-1. As-Is / To-Be 分析

業務をシステム化する際、いきなり「どんなシステムを作るか」を考えるのは危険です。まずは次の2つを整理します。

• As-Is（現状）: 今の業務がどのように行われているか
• To-Be（理想）: どのような状態になれば課題が解決するか

As-Is と To-Be のギャップ（差分）こそが、システムで解決すべき課題 です。

具体例：紙の申請書を使った経費精算

4-2. 要件定義の基本

As-Is / To-Be のギャップが明確になったら、それをシステムの 要件 として整理します。要件には2種類あります。

初学者がつい見落としがちなのが 非機能要件 です。「動く」だけでは不十分で、「どれくらいの速さで」「どれくらいの負荷に耐えて」「どれくらい安全に」動くかまで定義する必要があります。

非機能要件が見落とされやすいのには理由があります。機能要件は「経費を申請できる」「承認できる」のように目に見える動作なので、現場の人も言語化しやすい。一方、非機能要件は「画面が3秒以内に表示される」「月末の集中アクセスでも落ちない」のように、普段は意識されない"当たり前"の期待です。利用者はそれが満たされないとき初めて不満を感じますが、事前に自分から要望として言語化することはほとんどありません。

近年の生成AIは、機能要件の洗い出しや整理を効率よく手伝ってくれます。しかし、非機能要件はシステムを実際に使う人間の業務環境・利用状況に深く依存するため、AIだけでは引き出しきれません。「月末に何人が同時にアクセスしますか？」「出先からスマートフォンで使うことはありますか？」「停止が許されない時間帯はありますか？」といった問いを、人間が意図して投げかけて聞き出すことが不可欠です。

4-3. ユーザーヒアリングの重要性

要件を正しく定義するためには、実際に業務を行っている現場の人にヒアリングを行うことが不可欠です。

ヒアリングでよくある落とし穴は、現場の人が「今のやり方」を前提に要望を出してしまう ことです。

• NG例：「今のExcel帳票をそのままWeb画面にしてほしい」
• 深掘り：「その帳票で本当にやりたいことは何ですか？」→「月次の売上傾向を把握したい」→ ならば帳票の再現ではなく、ダッシュボードの方が適切かもしれない

表面的な要望の裏にある 「本当に達成したいこと（目的）」 を引き出すのが、要件定義の難しさであり、最も価値のあるスキルです。

第5章　AI時代のシステム開発

5-1. 生成AIがもたらした変化

2023年以降、ChatGPTに代表される 生成AI の急速な進化により、システム開発のあり方は大きく変わりつつあります。

従来のシステム開発では、プログラミング言語を習得し、コードを1行ずつ書く技術が必須でした。しかし現在では、AIに対して自然な言葉（日本語）で「こういう機能を作りたい」と伝えるだけで、AIがプログラムのコードを生成してくれる時代になっています。

この「自然言語でAIに指示を出し、アプリケーションを作る」手法は Vibeコーディング（Vibe Coding） と呼ばれ、プログラミング経験のない人でもアプリケーション開発に参加できる可能性を広げました。

5-2. AIが力を発揮する領域

生成AIは、システム開発のさまざまな場面で人間の生産性を大きく引き上げています。具体的にどのような作業が変わったのかを見てみましょう。

コードの自動生成

最も大きな変化は、プログラムのコードをAIが書いてくれるようになったことです。「ログイン画面を作って」「入力されたデータをデータベースに保存する処理を書いて」といった指示を日本語で出すだけで、数秒〜数分でプログラムが生成されます。

従来は数日かかっていたような機能の実装が数時間で終わるケースも珍しくなく、開発のスピードは飛躍的に向上しました。

ドキュメント・仕様書の作成支援

要件定義書、設計書、テスト仕様書、マニュアルなどの文書作成にもAIは有効です。たとえば「経費精算システムの要件定義書のたたき台を作って」と指示すれば、必要な項目が網羅された草案が即座に出力されます。ゼロから書き始める負担がなくなり、人間は内容の精査と判断に集中できるようになりました。

データの整理・分析

大量のデータを読み込ませて傾向を分析したり、Excelに散在するデータを整理・変換したりする作業も、AIが得意とする領域です。「この売上データから月別の推移をグラフにまとめて」といった指示で、従来は手作業で何時間もかかっていた分析がすぐに完了します。

テストと品質確認の支援

第3章で学んだテスト工程でも、AIの活用が進んでいます。「この仕様に対して、考えられるテストケースを洗い出して」と指示すれば、人間が見落としがちなパターンも含めた網羅的なテスト項目を生成してくれます。

既存システムの理解と調査

前任者が作ったプログラムの中身がわからない、引き継ぎ資料がない ── 業務現場ではよくある問題です。AIにプログラムのコードを読み込ませて「このプログラムは何をしているか、日本語で説明して」と聞けば、コードの意味を平易な言葉で解説してくれます。

5-3. ソフトウェア産業に起きている変化

AIの進化は、個々の作業効率を上げただけでなく、ソフトウェア産業全体の構造を変えつつあります。

「作る人」のすそ野が広がった

従来、システム開発はプログラミングスキルを持つ専門のエンジニアだけの仕事でした。しかしAIを介することで、プログラミング未経験の営業担当者が自分の業務ツールを作ったり、経理担当者が集計処理を自動化したりすることが現実になっています。

これは 「市民開発者（Citizen Developer）」 と呼ばれる動きで、現場の業務を最もよく知っている人自身が改善ツールを作れるという大きな利点があります。

開発にかかるコストと期間の短縮

以前は数百万円・数ヶ月かかっていた業務アプリの開発が、AIを活用することで数十万円・数週間で実現できるケースが増えています。これは中小企業にとって特に大きなインパクトです。「システム開発は大企業がやるもの」という前提が崩れ、規模の小さな企業でも自社に合ったシステムを持てる時代になりつつあります。

人間の役割が「実装」から「判断」へ

AIがコードを書いてくれるようになった結果、人間に求められるスキルは大きく変わりました。

つまり、プログラミングの技術そのものよりも、「何を解決したいのか」を明確にする力と、「AIの出力が正しいかどうかを見極める力」が重要になっています。

5-4. AIを活用した業務改善の具体イメージ

ここでは、地域の中小企業でAIを活用した業務改善がどのように実現するかを、具体的な例で紹介します。

例1：紙の日報をデジタル化

例2：問い合わせ対応の効率化

社内のよくある問い合わせ（「有給の申請方法は？」「経費の締め日は？」など）にAIチャットボットが自動回答することで、総務・人事担当者の対応時間を削減できます。AIは社内のマニュアルやFAQを学習し、回答を自動生成します。

例3：見積書・提案書の作成支援

過去の見積書や提案書をAIに読み込ませておくことで、新しい案件に対して「過去の類似案件を参考にしたたたき台」を自動生成できます。ゼロから書く時間が大幅に短縮されます。

5-5. AIを使う上での注意点

しかし、生成AIは万能ではありません。AIを活用する際には、以下のリスクを必ず理解しておく必要があります。

ハルシネーション（もっともらしい嘘）

AIは、事実に基づかない情報をあたかも正しいかのように出力することがあります。これを ハルシネーション と呼びます。たとえば、存在しない法律の条文を引用したり、架空の統計データを提示したりすることがあります。AIの出力を鵜呑みにせず、必ず人間が確認・検証することが重要です。

ブラックボックス化

AIが生成したプログラムの中身を人間が理解しないまま使い続けると、不具合が起きたときに原因を特定できなくなります。さらに、改修や機能追加をしようとしても、既存のプログラムが何をしているのかわからないため手が付けられない ── という事態に陥ります。

「コードを書けなくてもよいが、読めること（何をしているか理解できること）は必要」 というのが、AI時代の開発者に求められる基本姿勢です。

セキュリティリスク

AIに対して不正な指示を紛れ込ませる攻撃（プロンプトインジェクション）や、AIが意図せず脆弱なコードを生成してしまうリスクがあります。AIが作ったものであっても、セキュリティの確認は人間の責任です。

機密情報の取り扱い

AIサービスに入力したデータは、サービス提供元のサーバーに送信されます。顧客情報や個人情報、社内の機密データをAIに入力する際は、そのサービスの利用規約やデータの取り扱い方針を確認する必要があります。「便利だから」と安易に機密情報を入力してはいけません。

5-6. AI時代に人間に求められること

AIが進化しても、人間にしかできない重要な役割があります。

つまり、AI時代のDX人材に求められるのは「プログラミングができること」ではなく、「業務の課題を正しく分析し、AIやシステムをツールとして使いこなし、成果を出せること」 です。AIは強力な道具ですが、道具を使う方向を決めるのは、あくまで人間です。

第6章　セキュリティの基礎知識

6-1. なぜセキュリティが重要なのか

システムを導入すると、業務データがデジタル化され、ネットワークを通じてやり取りされるようになります。これは利便性が高い反面、情報漏洩や不正アクセスのリスク が生まれることを意味します。

中小企業だからといってサイバー攻撃の対象にならないわけではありません。むしろ、セキュリティ対策が手薄な中小企業は攻撃者にとって狙いやすいターゲットです。また、取引先の大企業への攻撃の踏み台として、サプライチェーン上の中小企業が狙われるケースも増えています。

6-2. 知っておくべきセキュリティの基本

認証と認可

• 認証（Authentication）: 「あなたは誰ですか？」を確認するプロセス（例：IDとパスワードの入力）
• 認可（Authorization）: 「あなたは何をしてよいですか？」を制御するプロセス（例：一般社員は閲覧のみ、管理者は編集可能）

この2つは混同されがちですが、まったく別の概念です。正しいパスワードでログインできた（認証）からといって、すべてのデータにアクセスしてよい（認可）わけではありません。

パスワード管理の原則

• 使い回さない: 1つのサービスから漏洩すると、他のサービスも芋づる式に突破される
• 推測されにくいものにする: 誕生日、電話番号、「password123」などは絶対に避ける
• 多要素認証（MFA）を有効にする: パスワードに加えて、スマートフォンへの通知やワンタイムパスワードを組み合わせることで、安全性が大幅に向上する

フィッシング詐欺への対策

フィッシング詐欺とは、銀行やサービス提供元を装った偽のメール・Webサイトで、パスワードやクレジットカード情報を盗み取る手口です。

• メール内のリンクを安易にクリックしない
• URLが正規のものか確認する（例：amazon.co.jp と amaz0n.co.jp の違い）
• 少しでも不審に感じたら、メール内のリンクではなく、ブックマークや検索から正規サイトにアクセスする

6-3. 組織としてのセキュリティ対策

個人の注意だけでは限界があるため、組織としての対策も重要です。

まとめ

本テキストで学んだ内容を振り返ります。

次のステップとして、Google Formによる確認テスト（10問）に取り組んでください。テキストの内容を理解していれば、すべて正解できる内容です。