*[【マイナビITエージェント】応募書類の添削から面接対策まで、幅広くサポートします](https://mynavi-agent.jp/it/?utm_source=and-engineer&utm_medium=banner&utm_campaign=acv01)*

DFDというIT用語について、SE（システムエンジニア）やPM（プロジェクトマネージャー）の方、システム開発を勉強中の方はよく耳にする単語でしょう。ITパスポート試験でもこのDFDについて出題がされています。この記事では、SEを目指しているプログラマーや他の職種の方を対象に解説します。

**DFD（Data Flow Diagram）は、システムにおけるデータ全体の流れ（flow）を表した図のことです。**一般的には要件定義フェイズといったシステム設計の初期段階で作成されます。システムを作る際に、まずは「このシステムがどう動くのか」といったシステム全体の流れとデータ処理のプロセスを図表にすることで、*開発内容を文字だけでなく視覚的に捉えることができます。*また、DFDはシステム構築以外にも、さまざまな業務フローを分析するためにも用いられている便利な手法です。

具体的に言えば、システムにおける入力（input）と出力（output）が何であるか、またデータの出所・発生元・出力先・データの保管場所などを示します。*DFDは処理のタイミングを示すものではなく、順序も関係ありません。*また、DFDは依存関係を示すため、相互依存関係がない処理については並列・並行性を表現します。同じ用途で使用するツールとしては、フローチャートがあります。

<center>[『マイナビIT AGENT』なら、 IT業界に精通した専任アドバイザーと豊富な求人で、 あなたの転職活動を丁寧にサポートします。](https://mynavi-agent.jp/it/?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv15)</center>

DFDでは、「システム機能」と「データ」の流れを表す図ですが、DFDには次のような目的があります。

*・関係者でシステムイメージを確認し共有する*

*・既存システムを整理して、全体像を把握する*

*・機能の漏れや重複がないように機能を整理する*

*・処理（プロセス）を詳細化していく*

DFDを作成する上で理解すべき要素は、*「データフロー（流れ）」「データストア（データベース）」「プロセス（処理）」「外部エンティティ」の4つです。*非常にシンプルなので、ユーザーにも分かりやすいのが特徴です。下記の表でDFDの4つの要素についてまとめていますので、確認してください。

DFDを作成する際、ホワイトボードに書く方法もありますが、ドキュメントとして残すためには電子的に保管可能な形式にした方が良いでしょう。DFD作成専用ツールを利用するのも手ですが、**汎用的で誰でも使えるExcelがおすすめです。**

Excelのセルを方眼紙のように使い、Excelに標準で実装されている図形を使います。文字はテキストボックスを利用して記載します。1度作ってしまえばテンプレートにして簡単に作成できるようになります。多くのSEは、DFDを作成する際にExcelを用います。

*まずは[マイナビIT エージェント](https://mynavi-agent.jp/it/?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv02)に無料登録いただいて、キャリアアドバイザーにキャリアや転職に関する相談をしてみてはいかがでしょうか。*

<center>[*『マイナビIT エージェント』*なら、 IT業界に精通した専任アドバイザーと豊富な求人で、 あなたの転職活動を丁寧にサポートします。](https://mynavi-agent.jp/it/?utm_source=and-engineer&utm_medium=banner&utm_campaign=acv02)</center>

DFDを使用する前に、メリットとデメリットについて理解しましょう。DFDはシステムの機能や仕組みを可視化することで、ユーザーと開発者の相互理解を深めることが可能です。その一方で、実際のシステムの動きや機能の詳細が把握しにくいなどの欠点もあります。以下で詳しく説明します。

DFDのメリットは、なんと言っても*視覚的でわかりやすい点です。*システムの構成要素を分割し、図形でデータの流れを記述するため、業務全体を把握しやすくなります。これにより、**「あいまい」な部分を排除でき、さらにシステムの「抜け」を防ぐことができます。**

DFDを1枚に書ききれない場合は、*レベル分けして書くことでより詳細を把握できます。*まず全体像を書き、レベルを下げた形でそれぞれの内部プロセスを細かく記載しましょう。

DFDのデメリットは以下のようなものが挙げられます。

DFDを作成する時点では、*各プロセス間の依存関係や処理の順序が実態とは一致しないことがあります。*実際の動きはあとから決定されるため、実際にプロセスを動作させた際にDFDと同じレベルで可視化することが難しいという問題があります。

**コントロールフローの表現が難しい**

*DFDでは「条件分岐」といったコントロールフローのマッピングが難しいです。*そのため、コントロールフローは記述されないことが多く、別に資料を追加して記載する必要があります。

DFDはあくまでもデータ中心の機能関連図で、**インプット・アウトプット・処理・データの保管の流れを表すだけです。**そこには「誰が」「いつ」「どのように」という情報は記述されません。それらを示すのは別の図です。

例えば、受発注在庫管理システムをDFDで表すと、以下のような図になります。ここでは外部エンティティは「顧客」と「物流倉庫」です。インプットは商品注文データ、アウトプットは顧客に届けられる商品です。以下で、作成手順について順番に解説します。

### 全体のストーリーを確認する

DFDは要件定義においてユーザー（クライアント）とのヒアリングを通じて作成することが多いです。しかし、いきなりDFDの作成に入ってもすぐに書けるものではないため、無理に書き進めても齟齬が生じる可能性があります。

**まずは現状を確認し、そこからどんなシステムにしたいのかストーリーを描いてみるとよいでしょう。**ストーリーから*両者ユーザーと開発者で共通のシナリオが生まれれば、DFDの目的は半ば達成したといえます。*

### データの発生場所と利用を把握する

**DFDはシステムのデータの流れにフォーカスすることで、システム全体を確認するのに適しています。**どこでどんなデータが発生するのか、どこでデータが利用されるかを先に把握しておくと書きやすいです。

続いて「受注データ」や「在庫データ」のような、**常時または一時的にデータが蓄積されるものを洗い出します。**DFDでは、データを蓄積する場合は上下に線を引きます。

最後に、上記.までで必要な処理を洗い出し、それらを記述すればDFDは完成です。**処理は丸で表記し、矢印線で繋ぐと見やすいです。**

DFDは好き勝手、自由に書いていくものではありません。*DFDを書く上で最低限のルールがあります。*わかりやすく見やすいDFDを作成するために、ルールに従って記載してください。また、DFDで記載できる内容には限りがあります。DFDを作成する上での注意点も説明しますので、併せてチェックしてください。

### プロセスには入力と出力がかならずある

DFDに記されるプロセスは人やコンピューターによって実行されることを示し、他から受け取ったモノやデータを加工する働きをします。

そのため、*プロセスには必ず「入力（input）」と「出力（output）」が必要です。*逆に言えば、「入力」と「出力」がないプロセスは記載できません。これは、**すべての業務は「input」→「process」→「output」で構成されていることを示しています。**

### データストア間は直接データフローで結ばない

DFDを書いている際に、いきなりデータストアから他のデータストアにデータフロー（線）を結んでしまう人がいますが、**必ずデータストア間にはプロセスが入ります。**例えば「受注管理簿」から「出荷管理簿」を作成する場合、必ず両者の間には「出荷指示」というプロセスが入ります。

DFDは「データフロー（流れ）」「データストア（データベース）」「プロセス（処理）」「外部エンティティ」という4つの要素で構成されています。**それぞれの要素には必ず名前をつけてください。**特にデータフローの名称は忘れずにつけましょう。

プロセスに名称をつけ忘れても、データフローにそれぞれ名称が付いていればプロセスの内容は推測できます。しかしデータフローに名称がない場合、何のデータがやり取りされているのかがわからなくなるため注意が必要です。

**要素ごとに違う記号を使うことで、DFDは各段に見やすくなります。**DFDは文字・線・矢印だけでシステム構造を示すため、記号を使い分けることで他の要素との違いを明確にすることが可能です。すべての要素に同じ記号を使うと要素の違いがわかりにくくなるため、丸・四角・三角などの複数のオブジェクトを使い分けましょう。

**DFDはあくまでもデータの流れを中心とした図であり、表せるものには限りがあります。**DFDの特徴を踏まえ、有効活用することが重要です。

重複しますが、DFDはあくまでもデータの流れを矢印で示したものであり、そこには「順序」「時間の変化」「役割分担」などは表せません。そうした部分を示すのは「業務フロー」です。

ユーザーにとっては「業務フロー」で業務のイメージが掴めますが、システム開発ではデータとプロセスが重要になるので、DFDを用います。*DFDと業務フローの両方を用いて要件定義を進めるのが良いでしょう。*

DFDには粒度があります。*粒度を細かくし過ぎるとシステム全体を把握しにくくなるため注意が必要です。*最初は大まかにシステムを把握できるよう、主要な機能や動きのみを書きましょう。

粒度を細かく落とし、レベルをブレークダウンしていくことで、最終的にコンピューターで自動化可能な単位のプロセスとなります。プロセス=プログラムとはなりませんが、プログラムの対象になりうる業務であるということが把握できるようになります。

要件定義においては、システム開発側とユーザー側が互いに確認し合うドキュメントを作成します。*文章だけでは確認がとりづらい、全体が見えにくいものなどは図表で表現します。*

システム概念図もありますが、図表としてよく利用されるものの内、**DFD（Data Flow Diagram）、ユースケース図、ER（Entity Relationship）図のそれぞれの役割について確認しましょう。**また、DFDと似ているUMLについても補足で説明していますので、参考にしてください。

### DFDだけでは足らないものがある

DFDではデータの流れや処理は分かりますが、「誰が何をする」という役割までは曖昧です。例えば、顧客は商品を注文しますが、具体的に注文行為で何をするのかが分かりません。電話で注文するのか、PCやスマホから注文するのかによってシステムの中での役割が異なります。

*顧客はストーリーの中で主役となるのか、脇役になるのかがDFDでは不明です。*それを明らかにするものとして、ユースケース図というものがあります。その他、データベースシステムを構築する場合はER図というものが必須です。*要件定義では、DFDのほかにユースケース図とER図もあると便利です。

DFDについて改めて整理しましょう。DFDはデータの流れを表す記法で、「データフロー（流れ）」「データストア（データベース）」「プロセス（処理）」「外部エンティティ」という4つの要素を用いて、データを中心に処理や機能の関連性を記述します。

**DFDにおける矢印はデータの流れを表しており、処理の順序とは無関係である点に注意が必要です。**DFDにおいては時系列は考慮しません。またDFDには階層があり、処理の全体を表すレベル1、レベル2はそれをブレークダウンしたもの、というように*レベル（階層）が上がるにつれて詳細な内容になります。*

### ユースケース図は操作や機能に着目

**DFDでは表現できないユーザーとシステム機能の関係に着目した図法が、ユースケース図です。**DFDとは逆にユーザーの操作を中心にしてシステム機能をメインに書きます。

「アクター」と称されるシステムとの間でやり取りを行うユーザーや他システム、「ユースケース」というシステム機能、「アクター間とユースケース間の関連」という3つの要素を用いて、システム機能とシステムを利用するユーザーや他システムとの相関関係を記述します。

### ER図はデータのグループ同士の関係に着目

**ER図は主にデータベースシステムで用いられます。**会社・社員・商品などの属性を持った管理対象をエンティティと称し、リレーションと呼ぶ線でそのエンティティ同士を繋いで表現します。各エンティティはキー項目を持ち、同一種類のエンティティを識別します。*データベース設計に利用すれば、そのまま活かすことが可能です。*

UML（Unified Modeling Language）は「統一モデリング言語」と呼ばれるもので、オブジェクト指向のソフトウェアを構築する上で使用されます。**UMLはシステムを構成するコンポーネント、構造や動作を視覚化する上で一定のルールを設け、書き方を統一することでわかりやすくする目的があります。**DFDがユーザーと開発者両方がシステムを理解できるように作成されるのに対し、UMLは開発者がシステム構造を視覚的に理解するために作成されるといった違いがあります。

## DFDを習得してシステム開発に役立てよう

当記事では、システムの中でデータフローを表現するための図として「DFD」を解説しました。DFDは、システムにおける入力や出力が何か、データの出所・発生元・出力先・データの保管場所などを示します。

*DFDによってシステムのイメージの確認・共有ができたり、プロセスを詳細化したりできます。*DFDを作成する際はルールに沿った書き方が必要なため、この記事を1つの参考してシステム開発に役立ててください。

ER図とは？詳細・メリット・作成方法についてわかりやすく解説！

DFD（データフロー図）は、システム開発におけるデータ全体の流れをわかりやすく表した図のことです。SEを目指す方に向けて、DFDの特徴・メリット・デメリット・注意点・書き方などを詳しく解説します。「DFDを学びたい」という方は是非参考にしてください。

DFDはシステム開発の要件定義フェイズでデータの流れを確認するために作られる図である

DFDには4つの要素があり、 ルールに従って、ユーザーと確認し合いながら作成する

DFDだけではすべてを表現できないため、別途業務フロー図やユースケース図、ER図なども用いる

DFDとは? SEを目指す人に必修のデータフロー図の書き方を習得しよう!

## 管理者の方がエンジニアの目標設定を行うには

管理者としてエンジニアを管理し、育成する場合、エンジニアに適切な目標を設定することが、エンジニア本人や企業にとって重要です。

目標設定によって、長期的なエンジニアの成長度合いや、企業への貢献度が大きく変わっていきます。そのため、**管理者はエンジニアの目標設定を適切に行い、その過程と結果を管理する必要があります。**

この記事では、管理者の方のために、エンジニアの目標設定の重要性や目標設定のポイント、目標設定の評価のためのコツについて解説し、エンジニア1年目・3年目・5年目の目標設定の具体例も紹介します。ぜひ参考にしてください。

プロジェクトマネージャーとは？仕事内容や将来性、必要なスキルを紹介

## エンジニアの目標設定の重要性

まず、エンジニアが適切に目標設定を行うことが、具体的にどのようなメリットをもたらすのかについて解説します。

### エンジニアの将来のビジョンを具体化させる

目標設定の大きな目的の1つが、エンジニアの方向性やキャリアプランを明確にすることです。

将来どのようなエンジニアになりたいのかによって、どういった知識・スキルを習得し、経験を積めば良いのかが変わります。そのため、方向性の決定が早ければ早いほど、エンジニアが目指す将来像に真っ直ぐ向かうために使える時間が増えます。

*管理者はエンジニアの目標設定を通して、単なる業務目標の達成を目指すだけでなく、本人がエンジニアとしてどのような将来像を描き、どのようなキャリアパスを考えるのかを把握することが重要です。*

### エンジニアのモチベーションの向上

エンジニアは日々の業務をこなすだけでは、モチベーションを保つことが難しいものです。目標を設定することで、目標を達成することの喜びを感じ、毎日の仕事にもやりがいを感じられます。

*企業で長く勤められるかどうかも、仕事にやりがいを感じられるかどうかが大きく影響します。*目標設定をしっかり行い、エンジニアに長く活躍してもらえる環境を作りましょう。

エンジニアのスキルアップやキャリアアップは、企業の業績アップや成長につながります。*管理者がエンジニアの目標設定を通して適性や方向性を見極め、育てていくことができれば、数年後には企業を支える人材となります。*

## エンジニアの目標設定のポイントとは

エンジニアの目標を適切に設定するためには、いくつかのポイントがあります。個人目標と事業目標を意識すること、スペシャリスト志向かマネジメント志向かを見極めること、大きな目標に向かって小さな目標を逆算して設定することです。

### 個人目標と事業目標を意識する

エンジニアの目標は、個人目標と事業目標を意識して設定しましょう。個人目標とは、エンジニア個人として達成したいタスクや、身に付けたいスキルなどのことで、事業目標とは、会社としてエンジニアに達成を期待する目標値や身につけて欲しいスキルなどのことです。

これを混同すると、適切な目標が立てづらくなります。*管理者は企業の目標を達成するためにエンジニアに事業目標目線の目標設定を期待しがちですが、エンジニアは個人目標を達成しようとする方がモチベーションが上がるためです。*

各エンジニアの特性や志向をしっかりととらえて目標設定を行い、それぞれの個人目標の達成の延長線上で事業目標が達成されるよう、個人目標と事業目標がリンクする目標設定ができれば理想的です。

### スペシャリスト志向かマネジメント志向か

エンジニア個々の将来への志向は、専門分野を極めたいスペシャリスト志向なのか、チームや組織をまとめてマネジメントしたいマネジメント志向なのかに大きく分けられます。入社から3〜5年程度経ったエンジニアには、将来的にどちらへ向かいたいのか、キャリアビジョンを確認しましょう。

スペシャリスト志向の場合は、高度な資格の取得や、さらに技術を高めるための学習、周辺分野の知識の習得など、さらに専門分野を極め、企業の技術力向上に貢献できる人材になることが期待できます。

マネジメント志向の場合は、メンバーを管理し、プロジェクトリーダーなどプロジェクトを円滑に進めるスキルや、コミュニケーション能力を向上させ、将来的に管理職やマネージャー職で活躍してもらうことができるでしょう。

どちらの人材も企業にとっては重要です。*エンジニアの目標設置を通して、スペシャリスト志向、マネジメント志向の人材をバランスよく育てることが、組織の安定的な運用につながります。*

ITスペシャリストとはどんな職種？仕事内容や未経験におすすめの資格

プロジェクトリーダーの役割とは？必要なスキル・平均年齢・おすすめの資格について

### 目標とするキャリアパスから逆算する

エンジニアの目標設定をする時には、まず将来どういった仕事をしたいか、何を達成したいかなどのキャリアビジョンを明確にしておきましょう。そして、それを達成するためにその手前で達成するべき小さな目標を立てて行きましょう。

*そうすることで、目標設定がとりあえずの形だけのものにならず、自分の将来につながる大切なものであるという意識を持って達成に取り組むことができます。*

まだビジョンがはっきりしない若手のエンジニアであれば、「〇〇さんのような仕事ができるようになりたい」など、具体的に手本にしたい人を挙げて、ロールモデルに設定するのが効果的です。

## エンジニアの目標達成を評価するために

管理者はエンジニアの目標達成を適正に評価する必要があります。そのためには、定量的な目標を設定することと、目標達成の期限を定めるという2点が重要です。

### 数値を盛り込み定量的な目標を設定する

目標設定をする場合、「フロントエンドエンジニアとしてのスキルを向上させる」のように曖昧で数値化できない、いわゆる定性的な目標も重要ですが、これではどの程度達成できたかの指標が明確でなく、評価を行うのが難しい場合があります。

*そのため、定性的な目標を達成するため、さらに具体的に数値で表される、定量的な目標を設定することも有効です。*

例えば、前述の「フロントエンドエンジニアとしてのスキルを向上させる」という定性的な目標のために、「2ヶ月に1度勉強会に参加する」や、「業務関連資格を1つ取得する」などの定量的な目標設定があると、客観的に評価しやすくなります。

フロントエンドエンジニアとバックエンドエンジニアを詳しく解説！

目標設定を行うときは、目標達成の期限を設定しましょう。期限がないと、いつまでに達成すればいいか分からなくなり、目標達成への行動になかなか着手しないことになりかねません。

設定する目標の内容によって、1ヶ月・3ヶ月・半年・1年くらいのスパンで適切な期限を切りましょう。*そうすることで、エンジニアも期限を守るというモチベーションを保つことができ、管理者も進捗の確認を行いやすくなります。*

## エンジニアの目標設定の具体例

ここでは、エンジニアの1年目・3年目・5年目における目標設定の具体例を挙げ、解説していきます。実際の目標設定の参考にしてみてください。

### エンジニア1年目の目標設定

新人のエンジニアとして入社した1年目は、エンジニアはまだ会社についてよく分からず、仕事の内容を覚えることに精一杯でしょう。この時期は、業務内容の習熟・基本的な技術の習得・必要な基礎的資格の取得などが分かりやすい目標設定となるでしょう。

*管理者としては、新人エンジニアがどのような人材なのかを見極める必要があります。*目標設定とその評価を通して、設定した目標にどのような姿勢で取り組むか、進捗に対する意識は高いか、専門知識の習得度合いの速さはどの程度かなど、エンジニアの特性をよく把握しておきましょう。

*■1年目のエンジニアの目標設定の具体例*
・3ヶ月で業務マニュアルを通読する
・半年で基本的な業務を行えるようになる
・1年以内に基本情報技術者試験に合格する

2023年から基本情報技術者試験が変わる？変更点を確認して対策しよう！

### エンジニア3年目の目標設定

新人エンジニアも2年目にはおおむね業務をこなせるようになり、3年目になると会社や仕事にも慣れ、後輩の指導もするようになる時期です。安定した業務ができるようになり、会社の中でも業務の推進を担うメンバーとして見なされるようになります。

*エンジニア自身の一層の技術向上を目指すとともに、社内のより広い範囲や社外にも目を向けてもらい、自分だけでなく、チームや組織の向上に貢献できるような目標設定ができると良いでしょう。*

*■3年目のエンジニアの目標設定の具体例*
・開発でよく使うライブラリをまとめてナレッジを作成する
・自動化による業務効率化で日々の定常業務の時間を20%短縮する
・2ヶ月に1度インフラエンジニアの社外勉強会に参加し、会社へフィードバックする

インフラエンジニアの種類とは？適性や興味から目標分野を定めよう！

### エンジニア5年目の目標設定

エンジニアも5年目になると、自分自身でスペシャリスト志向、マネジメント志向の意識も明確になってくるでしょう。**スペシャリストとして技術を極めるか、プロジェクトマネージャとしてチームや組織を率いるか、どちらを目指すかによって、立てる目標は大きく変わっていきます。**

管理者としても、会社のため本人のためを考えて、個々のエンジニアそれぞれにどのようなキャリアパスを歩んで欲しいという思いもあるでしょう。しっかりと話し合って、目標設定を行うことをおすすめします。

*■5年目のエンジニアの目標設定の具体例*

■スペシャリスト志向の場合
・スペシャリスト向けの専門的な資格を1つ取得する
・月に3本ずつ後輩のコードレビューを行う
・機械学習の新しい技術を取り入れた実装を担当する

■マネジメント志向の場合
・プロジェクトにおける納期と進捗管理を行う
・クライアントと予算や納期などの交渉を行えるようになる
・開発チームのエンジニアの目標設定を行い、管理する

プロジェクトマネージャーに向いてる人は？未経験者でも転職できる？

## エンジニアの目標設定を適正に行って継続的に成長できる組織を作ろう

ここまで、管理者の方に向けて、エンジニアの目標設定の重要性やポイント、具体的な目標設定例について解説してきました。目標設定がエンジニア本人だけでなく、企業にとっても大きな意味を持つことをおわかりいただけたと思います。

エンジニアが高いモチベーションを保ち、適性に合ったキャリアパスを歩んでいくことで、エンジニアと企業は共に成長を遂げていきます。ぜひ、エンジニアとよく対話をしながら目標設定をしてみてください。

プロジェクトマネージャーの役割とは？他職種との違いや必要スキルを解説！

プログラマのキャリアパス4選！年収を上げるために考えたいこと

管理者としてエンジニアの目標設定を行うことは、本人のモチベーション維持のためにも、企業の活性化のためにも重要です。この記事では、管理者としてエンジニアの目標設定を行う方のために、エンジニアの目標設定の重要性やポイントを解説し、具体的な目標設定例も紹介します。

個人目標と事業目標を意識し、エンジニア本人と企業が成長できる目標設定行うことが必要

エンジニアの目標設定は、スペシャリスト志向かマネジメント志向かで大きく変わる

1年目、3年目、5年目のエンジニアの目標設定例を通して目標設定のポイントがわかる

管理者から見るエンジニアの目標設定のポイントは？具体例を交えて解説

*[【マイナビITエージェント】あなたの転職活動を無料でサポートいたします](https://mynavi-agent.jp/it/?utm_source=and-engineer&utm_medium=banner&utm_campaign=acv12_2)*

## 「単体テスト」と「結合テスト」の違いとは？

開発の現場では、エラーを検知する「テスト」作業が非常に重要です。ここでは、「単体テスト」と「結合テスト」はどういったものなのかを、システム開発の工程とともに紹介します。

### どちらもシステム開発で重要な工程の1つ

システム開発を行う上で、エラーや不具合はつきものです。どんなに細かくチェックを行っても、実際動かしてみると予期しないエラーが出たり、求めている機能が使えなかったりすることは多々あります。

そこで、必要になるのが「テスト工程」です。作成したシステムを納品するまでに、顧客が求める要件が満たされているか、たとえエラーが出力されてもシステムが稼働するような作りになっているかを地道にテストしなければなりません。

そんなテスト工程のうち、よく知られているのが「単体テスト」と「結合テスト」です。**同じシステム開発において実施されるテスト工程ですが、「単体テストは機能を小さい単体でテストする」、「結合テストは複数のモジュールを組み合わせてテストする」といった違いがあります。**

それぞれのテストを行う目的やタイミングは異なりますが、どちらもシステム開発では欠かせない重要な工程の1つです。

そもそも、このシステム開発はどのような流れで行われるのでしょうか？システム開発は決められた手順通りに進めていきます。例えるなら、家を建てる過程と似ています。

一般的には、*「要件定義→外部設計→内部設計→プログラミング（構築）→単体テスト→結合テスト→システムテスト→運用テスト→システム移行」といった流れをたどります。*

なお、「インフラエンジニア」と「アプリエンジニア」ではプログラミングの有無など、多少工程は変化します。今回は「アプリのシステム開発」を基準に紹介します。

システム開発の工程とは？基本的な流れや略語の意味を解説！

要件定義とはシステム開発プロジェクトを進める前に、顧客にとって必要な機能や要件をまとめる作業のことです。プロジェクトが進んでいくとともに要件定義に立ち返ることも多く、目的をはっきりさせる工程でもあります。プロジェクトが上手くいくかは要件定義で決まると言っても過言ではありません。

要件定義書とは？仕様書との違いや書き方のポイントを解説

外部設計では要件定義で作成した内容をもとに、外見的な見た目の部分を設計していきます。ユーザーの使いやすさに影響を与える部分になるので、使いやすいシステムを作るために大切な工程になります。

内部設計では、システムの中身であるプログラミングの設計をします。外部設計はユーザー側からの視点よりでしたが、内部設計では開発者側からの視点よりで設計していきます。

内部設計でプログラミングの設計が決まったら、設計書通りプログラミングを行っていきます。ただプログラミングを行うのでなく、設計書を作成した人やテストを行う人と積極的にコミュニケーションを行うのも大切です。

プログラミングを使う仕事とは？種類別の例や向いている人の特徴

後で詳しく紹介しますが、単体テストではプログラミングの粒度（単位）ごとにテストを行っていきます。この単位はモジュールと言われることもあります。単純作業になりがちなため、より効率が求められる工程でもあります。

こちらも後で詳しく紹介しますが、結合テストは複数のモジュールを組み合わせて、正しく機能しているかを検証します。結合テストはテスト項目の洗い出しが難しい部分でもあります。

*・総合テスト（システムテスト）*

総合テストでは全ての作成したプログラムが、要件定義で作成したシステム要件通りに正しく動くかをテストする工程です。性能や機能のテストを行います。ここからは、アプリの基盤を作成したインフラエンジニアの人と協力して行っていくこともあるでしょう。

システムテストとは？その手法やシステムテストの仕事に転職するには

運用テストでは実際にシステムを運用する顧客先の環境を設定し、システムに影響や不具合がでないかをテストしていきます。これまでのテストと比較すると実用性に重きを置いたテストとなっています。

運用テストってどんなテスト？目的や内容、注意すべきポイントとは？

システム移行は、古いシステムから新しく開発システムへ切り替える工程です。成功するか、ハラハラする工程でもあります。

保守・運用では、システムが問題なく運用しているかチェックしたり、よりよい状態にシステムを稼働させることができないか、プログラムを修正したりします。システムは24時間365日稼働していなければならないものもあるため、常にシステムを監視する業務も含まれます。

【保守・運用】仕事内容や将来性、必要なスキルについて徹底解説！

### システム開発のモデルの紹介

**システム開発には、さまざまな種類の開発モデルが存在します。**例えば、「ウォーターフォールモデル」、「アジャイル開発」、「プロトタイプモデル」、「スパイラルモデル」などです。ここでは、システム開発で最もよく使われる2種類のモデルを紹介します。

*・ウォーターフォールモデル*

**ウォーターフォールモデルは、要件定義や設計などの上流工程から、テスト、保守・運用などの下流工程へ、順を追って行われていくのが特徴です。**例えば、設計が完全に行われていないのに、プログラミングを行うことはありません。

スケジュール管理がしやすいので、大規模なシステム開発に適している開発手法と言えます。一方、工程でのミスが生じた場合の手戻りがある場合、時間を要してしまうのがデメリットです。

ウォーターフォール開発モデルとは？各工程やメリット・デメリットを解説！

アジャイルには「素早い、機敏な」という意味があります。アジャイル開発は文字通りスピード感のある開発手法です。**短い開発期間で単位を区切り、変更や修正を行います。**

メリットは、新しい技術開発などですぐに成果物が欲しいとき、とりあえず作ってみることができる点です。一方、スケジュール管理がしづらいのはデメリットです。

アジャイル開発の特徴、メリット・デメリット、DXとの関係など

<center>[『マイナビIT AGENT』なら、 IT業界に精通した専任アドバイザーと豊富な求人で、 あなたの転職活動を丁寧にサポートします。](https://mynavi-agent.jp/it/?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv12_2)</center>

ここでは、まず「単体テスト」について詳しく紹介します。上述したように、単体テストでは、プログラミングの対象単位ごとにテストを行っていきます。具体例を詳しく説明します。

新人が任されやすい単体テストとその仕様書の作成について徹底解説！

単体テストは「Unit Test（UT工程）」とも呼ばれる通り、メソッドや関数などの1つ1つの小さな単位ごとに行うテストのことです。**1つの画面や1つの機能で実施される動作をテストすることが目的となっています。**

しかし、実際にシステム開発で作るプログラムでは、画面や機能が複数存在している場合が多いです。そのため、動作の連携に関しては単体テストではなく、後で紹介する結合テストでチェックを行います。

一般的に、単体テストは条件分岐を網羅する観点からテストを行います。**理由としては、条件分岐を網羅することで、品質をある程度は確保できるからです。**

ただし、コスト、納期、品質のバランスの観点から、100％の品質を確保するテストはできないことは頭に入れておきましょう。

単体テストの手法の種類はさまざまです。代表的な手法である、「ホワイトボックステスト」と「ブラックボックステスト」を取り上げて紹介します。

**ホワイトボックステストは、プログラムが設計したとおりに動作するかを1つ1つ網羅的に確認するテストです。**つまり、「開発者側の視点」に立ったテストとも言えます。

例えば、設計書ではエラーが発生すると定義された文字列を入力し、出力結果が正常かどうかを検証します。ホワイトボックステストのメリットは、1つ1つのモジュールに対して網羅的に検証できることです。一方、デメリットは工数が増えてしまうことです。

**ブラックボックステストは、開発するシステム自体の仕様を満たしているかどうかを確認する機能のテストです。**つまり、「利用者側の視点」にたったテストと言えます。内部のプログラムについては考慮しないため、「ホワイトボックス」とは逆の「ブラックボックス」と呼ばれています。

テスト例として、設計書で0～100までの数値を正常と設定した場合、境界付近である値（例えば、0、-1など）を選んでテストします。理由としては、境界付近にプログラムの欠陥が多いためです。

ブラックボックステストのメリットは、利用者の要件を満たしていることが確認できる上に、工数を抑えることができる点です。一方で、プログラムの内部処理が適切に行われているのかわからない点はデメリットです。

### 単体テストの仕様書を作成する

単体テストを実施する際は、単体テスト仕様書と呼ばれるドキュメントを用意します。仕様書を作成する際は、「入力手順」「テスト方法」「テスト観点」などを詳しく記載しましょう。単体テストの仕様書を丁寧に作成すると、網羅的にテストを行うことが可能になり、結果的にシステムの品質を上げられます。

<center>[エンジニア転職を成功させるため ぜひ*『マイナビIT エージェント』*をご活用ください！](https://mynavi-agent.jp/it/?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv12_2)</center>

結合テストでは複数のモジュールを組み合わせて、正しく機能しているかを確認します。ここからは結合テストについて詳しく紹介します。

「結合テスト」の観点や目的を押さえ、システムの品質を担保しよう！

結合テストは「Combined Test（CT工程）」とも呼ばれており、複数のモジュールを組み合わせて行うテストのことです。**「モジュールを結合させたときに、設計したように動作するのか」「想定外の状況のエラーが出力されても、システム要件が満たされているか」といったことを検証するのが目的です。**

また、単体テストで正常を確認できたモジュール同士を組み合わせるだけでなく、その他の外部モジュールを結合したテストも行うことがあります。

**結合テストは要件定義に基づいて、機能要件や非機能要件の観点からテスト項目を洗い出します。**単体テスト同様に、コスト、納期、品質のバランスの観点からテスト項目を選定することが大切です。

単体テストと違い、結合テストではシステムの全体的なデータの流れを把握ができる技術が必要になります。1つ1つの機能にエラーがなくても、連携させると問題が発生する可能性があるためです。

プロジェクトの成否を左右する非機能要件の一覧について詳しく解説！

**結合テストの手法としては、「インターフェーステスト」「ブラックボックステスト」の2つが代表的です。**具体的に紹介します。

インターフェースとは、モジュール同士を接続したときに、データの引き渡しを仲介する仕組みのことを指します。インターフェーステストは、結合テストの中では「定番」と言ってもいいほど一般的なもので、「連結テスト」とも呼ばれます。

インターフェーステストでは、機能間やモジュール間でデータを引き渡す際に、引き渡されるべきデータがきちんと引き渡されているか、連携に関わるモジュールが設計した通りに正常に動作しているかなどを検証します。

単体テストで説明した通り、ブラックボックステストはプログラムの内部構造を考慮しないで、入力に対して正常な出力結果を得ることができるか検証するテストです。

システムエンジニアの記事（3ページ目）