**ソフトウェア開発において、テストは品質を担保する上で大変重要な工程**です。ソフトウェアのテストをレベルに分けると、大別して次の4つがあります。*「単体テスト」（コンポーネントテスト）、「結合テスト」、「システムテスト」、「運用テスト」*です。ソフトウェアの品質を担保するには、各テスト工程において各種検証を通じ、*バグの洗い出しと、その改修を行うこと*です。

ここでは、「結合テスト」を中心にして「単体テスト」も含め、その種類・目的・観点・手法などについて解説していきます。「結合テストは難しい」というイメージがありますが、実際にやってみるとさほど難しくはありませんので、ぜひ体得してエンジニアとしてのスキルを磨いてください。

「テスト」について解説していく前に、それぞれのテストがシステム開発工程のどこに位置するのかを確認しておきましょう。

システム開発の工程の「単体テスト」と「結合テスト」の違いを徹底解説！

システム開発の工程には、*「ウォーターフォールモデル」「アジャイルモデル」「プロトタイプモデル」*などがありますが、ここでは**伝統的な「ウォーターフォールモデル」を念頭に置いて、システム開発の工程について解説**していきます。
各工程については略語も表記しておきますので、この機会に覚えてください。

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

### 要件定義：RD（Requirements Definition）

要件定義フェイズは、システム化計画やシステム企画フェイズで作成した計画書をベースにして、**ユーザーやクライアントが実現したいことを機能要件、技術要件にまとめる工程**です。*成果物としては要件定義書*で、内容について*クライアントやユーザーの合意*を得た上で基本設計フェイズに進みます。

高品質なシステム開発に欠かせない機能要件と非機能要件とは？

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

### 基本設計（外部設計）：UI（User Interface）

基本設計フェイズでは、**要件定義工程で決定した内容に従って、主にユーザーインターフェースを決定**します。プロジェクトの規模にもよりますが、*基本設計書は一般的にシステムの大きな機能ごとに作成*されます。「システム構成図」「画面一覧」「帳票一覧」など、数十種類の資料が成果物となります。また、*機能は「機能要件」と「非機能要件」に分かれます*。

### 詳細設計（内部設計）：DD（Detail Design）

詳細設計フェイズでは**基本設計書の内容に従い、システムに搭載する機能をモジュールごとに分割して、詳細設計書にブレイクダウン**していきます。*「機能仕様書」「データフロー図」「データベース設計書」などもここで確定*していきます。

### プログラミング：PG（Programing）

主に**プログラマーが詳細設計書の内容に従ってプログラミングを行います**。プログラミングとコーディングを同義と考える方もいますが、*プログラミングはプログラムを作成する作業全般のことで、コーディングはプログラミング言語を用いてソースコードを作成することを意味します。つまり*コーティングはプログラミング作業の一部*です。

現場で多く使われるプログラミング言語一覧！種類別に詳しく解説

### 製造・単体テスト：M（Manufacture）、UT（Unit Test）

**詳細設計書に基づいて作成したプログラムが、詳細設計書通りの動きをするかどうかを確認**します。プログラマー自身がテスト仕様に基づいてテストするケースが大半ですが、*テスターと呼ばれる担当者がテスト工程を担当することも*あります。

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

### 結合テスト：IT（Integration Test）or JT（Joint Test）

単体テストで問題が発見されなければ、**複数のモジュールからなるサブシステム全体のテスト**を行います。ここで、*各サブシステム間のインターフェースに問題がないか、各サブシステムの連携が正常に行えているかなどの確認*を行います。

### システムテスト（総合テスト）：ST（System Test）

結合テストフェイズで、各サブシステムに問題がないことを確認できたら、**システム全体を動かして不具合がないかどうかを確認**します。要件定義通りの動きをしているかを確認しますが、*パフォーマンスチェック*も行います。
アクセスが集中した時や処理データ量が急増した時など、*イレギュラー時の動きについても確認*します。

結合テストとシステムテストの違いは、*結合テストはあくまでもサブシステム内の全体テスト、システムテストはシステム全体のテストである*点が大きく異なります。

### 運用テスト：OT（Operation Test）

運用テストは、**開発したシステムを納品・リリースする前に行う最終工程**です。*実際の本番イメージでシステムが正常に稼働するかどうか、誤操作などで不具合が起きないか、操作性に問題がないかなど、起こりうるトラブルをすべて想定して、細かくチェック*を行います。


ここで不具合を発見できないと、クライアントやユーザーに重大な損害をもたらす事もあるため、*小さな不具合も見逃せない重要な工程*と言えます。この後、*システム移行（リリース）の工程を経て、システムの「保守・運用」フェイズ*へと進みます。

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

前述した通り、単体テストはプログラム毎にテストを行います。ここでは単体テストについて、目的や観点を簡単に解説します。

**単体テストを行う目的は、プログラム単位の不具合を発見し、早期に修正して結合テストの効率を上げ、ソフトウェアの品質を担保すること**です。

**単体テストの観点としては、主に「条件網羅テスト」と「境界値テスト、異常値テスト」の2種類**があります。

「条件網羅テスト」は一般的によく行われるテストで、*詳細設計書に記述されたロジックの条件を網羅したテスト*で、仕様通りに動作するかどうかを確認します。

「境界値テスト、異常値テスト」では、本来受け付けてはならないイレギュラーなデータを意図的に入力して、それらが正しく弾かれるかどうかを確認します。基本的にはこの両方の観点で単体テストを行います。

単体テストを無事通過すると、結合テスト工程に入ります。**結合テスト工程では、複数のモジュールから構成されるサブシスムごとにテストを行います**。ここでは、*結合テストの目的・観点・手法について紹介*していきます。

**結合テストは、モジュール間の連携やデータの受け渡しなどに問題がないことを確認するのが目的**です。ここで不具合が発見されると、仕様書に遡って仕様書の修正、プログラムの修正が行われることもあります。しかし、*結合テストを確実に実施おくと、総合テストで大きな問題が起きることは少ない*でしょう。

結合テストには、*同一サブシステム内でモジュール間で行う「内部結合テスト」と、サブシステム間の機能連携について確認を行う「外部結合テスト」*があります。

前述の通り、結合テストには「内部結合テスト」と「外部結合テスト」があり、それぞれ確認する観点が異なります。

*「内部結合テスト」では、1つのサブシステム内における機能連携の観点から確認し、「外部結合テスト」では、サブシステム間や他のシステム間との機能連携の観点から確認*を行います。両者に**共通するのは、機能と機能同士の連携が正常に行われているかどうかを確認する**点です。
また、テストの観点を見逃すことがないよう、次項の*「テスト観点リスト」*を作成してテストを行う開発者もいます。

「システムテストの観点に基づくサンプル」や「結合テスト計画書」の記述項目などが以下、IPA作成のガイドブックなどにも載っていますので、ぜひ参照してみてください。

*【参照1】：[高信頼化ソフトウェアのための開発手法ガイドブック（IPA：独立行政法人 情報処理推進機構）](https://www.ipa.go.jp/files/000005144.pdf)*

*【参照2】：[ソフトウェアテスト見積りガイドブック（IPA：独立行政法人 情報処理推進機構）](https://www.ipa.go.jp/files/000005132.pdf)*

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

前述のテスト観点をまとめたものを*「テスト観点リスト」*と呼びます。

結合テストを行うエンジニアが「テスト観点」を理解はしていても、*属人的な判断に委ねてしまうと、エンジニアによって「テスト観点」に温度差が生じ、必要なテストが漏れてしまうリスク*があります。

そこで役立つのが「テスト観点リスト」です。システム開発は、さまざまな設計書、仕様書に基づいて進められていきますが、*テストにもテストとしての仕様書が必要*です。
「テスト観点リスト」には定型パターンがありませんので、システムの種類や特性ごとに個別に作成する必要がありますが、**重要なことは観点がずれない、観点を漏らさないこと**です。

### テスト観点リストの作成方法

*ソフトウェア品質評価の国際規格に「ISO/IEC9126」*があります。「ISO/IEC9126」は、*品質特性として機能性・信頼性・使用性・効率性・保守性・移植性の6つ*を挙げています。テスト観点リストは、それらを**「大きな観点」から「小さな観点」にブレイクダウン**していきます。
たとえば、品質特性の中で「機能性」を1つの観点にして次のようにブレイクダウンしてみましょう。信頼性・使用性・効率性・保守性・移植性についても同様に記述します。

 　　　　　　　　　　　（観点リストの例）

*大分類　>   中分類    > 小分類  >　細分類    >　テスト観点*

・機能性> 機能テスト>画面表示>レイアウト>配置・サイズ・タイトル

・　　　　　〃                      　 > 画面項目  >文字の内容・文字サイズ・文字の書式・初期値...

以上はあくまでも1つの例てす。*「テスト観点リスト」は自由に作成して構いません。作成し、改廃して、組織ノウハウとしていきます*。
その際、エンジニアのミーティングで*衆知を集め、「テスト観点リスト」の完成度を高めていけば、テストはより効率的、効果的になり、品質向上に大いに役立つ*でしょう。

コードレビューの観点とは？やり方や便利なツールについても紹介！

**結合テストにはいくつかの種類や手法**があります。以下、*代表的な結合テストの種類や手法*について紹介します。

*■インターフェーステスト*
それぞれの**プログラムやモジュールが、互いに正しく連携して動くかどうかを確認するテスト**です。AのプログラムからBのプログラムに正しくデータが引き渡しをされているか、といった観点で検証します。

*■ブラックボックステスト*
内部構造は把握せず、**ユーザーの視点で、入力したものから正しい出力が得られているかを確認**します。このテストでは開発の知識は求められませんので、開発関係者以外のメンバーや、初心者でも行えることから、費用対効果の高いテストであるといえます。

*■業務シナリオテスト*
こちらはさらに**実際の業務を想定した動作確認を行うテスト**です。業務に則した操作が中心となるため、実際にシステムを操作、利用するユーザーに行ってもらう場合もあります。そこで*重要なことは、イレギュラーな操作を必ず行うこと*です。たとえば、本来あり得ないような数値やデータを入力したり、エンターキーを何度も叩いたり、といったことを実施することです。

*■負荷テスト*
**負荷テストは、システムに最大の負荷をかけた場合の動作状態を確認し、システム停止やパフォーマンス低下が起こらないかを確認するテスト**です。たとえば、想定する最大のアクセス数があった場合や、想定する最大のデータ量を処理した際のパフォーマンスなどを確認します。
また、結合テストは納期がタイトになると、スケジュールを圧迫することが少なくありません。*テストの自動化ツールやシミュレーターソフト*などを利用することで結合テストを効率化し、その負荷をかなり軽減することができますので、ツールの活用も検討してみましょう。

## システムの品質アップの鍵はテスト

システムはどんなに手を掛けて開発しても、*本番で大きなトラブルを招くと、失うものも大変大きなものに*なります。クライアントやユーザーに多大な迷惑を及ぼすばかりか、その企業の顧客に対しても損害を与え、企業の根幹を揺るがす事態も起こり得ます。


また、*システムエンジニアとしての信用が落ち、取引ができなくなる*かもしれません。そこで、重要なポイントとなるのはテストやスケジュールです。納期優先で工数を短縮した結果、テストが不十分となり、本番で重大な不具合が生じるケースを避けるには、**余裕のあるスケジュールと確実なテストの実施**です。

多くのシステム障害の原因の大半は、イレギュラーケースを想定した結合テストや総合テストをしていないことにあります。これは不可抗力ではなく*ヒューマンエラー*です。

**エンジニアの成果は、作成したシステムの品質で決まります**。品質を高めるには、高いテストスキルを持つことです。これを読まれたエンジニアの皆さんは、ぜひ*テストを重視するエンジニアを*目指してください。

システム開発においては必ず単体テストや結合テストを行いますが、各テストは目的や観点が異なります。システムはプログラムやサブシステムの集合体であり、目的や観点に応じた正しいテストを行うことが重要です。ここでは結合テストの目的、観点などを中心に解説していきます。

ソフトウェア開発において、テストは品質を担保する上で大変重要な工程である。

結合テストには「内部結合テスト」と「外部結合テスト」の2つの観点がある。

エンジニアの成果は、作成したシステムの品質で決まるため、品質を担保するテストは確実に行うことである。

結合テストの「内部結合テスト」と「外部結合テスト」は何が違う？観点や目的も解説

## システム保守はきついって言われるけど本当？

システム保守の仕事は「きつい」「やめとけ」などと言われることがあり、実際にシステム保守を経験したエンジニアの中にもこの意見に賛同する方が多くいます。どうしてこのように言われるのでしょうか。

確かにシステム保守と言えば、閉鎖された監視室で24時間交代制でサーバーやネットワーク監視をする、という聞いただけでもきつい環境で業務を行うことが多いのは事実です。また、毎日同じ作業の繰り返しばかりで学ぶことが少なく、つまらなく感じやすいという性質の業務でもあります。

さらに、AI技術や自動化の進化によりオートメーションが進むことが考えられることから将来性が見込めないという意見もあります。*このように労働環境や仕事内容、将来性に対する不安などがきついと言われる主な要因と考えられます。*

## システム保守業務で学んだことを生かして次のステップを考える

きついだけでなく、システム保守の仕事は3年以上続けることにメリットが少ないという見方もあります。技術力を高める機会が少ないシステム保守を長くやりすぎるとエンジニアとしての向上心を持つことが難しくなり、大きなスキルの成長も見込めずにそこからのキャリアアップが困難になるためです。

**そのため、将来的にキャリアアップを目指すエンジニアにはシステム保守を長年続けることはあまり向いていません。**

プログラマやシステムエンジニア、システム保守の経験が生かせるインフラエンジニアなどITエンジニアにはたくさんの種類があります。より上を目指したい人は積極的に勉強してキャリアアップを目指しましょう。

## システム保守とはどんな業務を行うの？

そもそもシステム保守とはどんな業務を行うのでしょう。運用中の業務システムが問題なく稼働を続けるための定常業務や、異常を検知して障害発生を未然に防いだり被害を最小限にとどめる監視業務、そして障害発生時の復旧対応などが主な仕事です。

システムが正常に動作し、想定通りのパフォーマンスが出せるように監視・調整を行います。*運用マニュアルや作業手順書に従って間違いのないように業務を行うことが必要とされます。*必要に応じてシステムメンテナンスを実施したり、運用マニュアルの修正を行う場合もあります。

*サーバやネットワーク、各種サービスが正常に動作しているか監視します。*

例えば、サーバのCPUやメモリの負荷に問題はないか、異常な通信量が検知されないかなどのハードウェア的なリソース状況を監視します。あらかじめ機器には閾値が設定されており、担当者は閾値を超えると通知されるアラートに注意を払います。

また、システムに外部からpingコマンドを打って応答があるかを監視する死活監視や、HTTP・FTP・DNSなどの主要なサービスプロトコルや、サーバ内で動作するアプリケーションやサービスの動作に問題がないかの監視を行います。

システムやサーバー、ネットワークに異常が発生した時に復旧や原因調査を行います。*障害はそのままユーザの不利益につながることが多く、早急な復旧を求められます。*

原因はソフトウェアの異常や物理的な故障、通信量の増大など様々な理由があり、問題箇所を切り分けてシステムの再稼働を目指します。システムが復旧した後も、再発を防止するための原因調査やシステムアップデートが欠かせない業務です。

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

## システム保守はきついと言われる理由

システム保守がきついと言われる理由にはどんなものがあるのでしょうか。具体的な理由を挙げていきます。 

業務システムは多くの場合24時間365日の稼働を求められます。そのためシステム保守担当者もそれに合わせて、夜勤を含むシフト制で24時間体制の勤務が必要です。現場や会社によって3交代制や2交代制などの体制は異なりますが日勤と夜勤を交互に繰り返す場合もあり、そうなると体調を整えるのも非常に困難です。

入社した頃は、夜勤を行うと昼にプライベートな時間が持てる、深夜の勤務には手当が付くなどのメリットもあり頑張れる気持ちになるものですが、長く続くとさすがに体調を崩すことも多くなり気持ちも滅入ってきます。

**生活リズムが乱れて身体的に影響が出やすいことから、これがシステム保守がきついと言われる最大の理由だと考えられます。**

### ルーティンワークが多く技術が身につきにくい

システム保守の仕事は運用マニュアルや作業手順書に従ったルーティンワークが主になります。*携わっているシステムや現場のやり方には習熟していきますが、定常業務をこなせるようになれば新しいことを習得することは減ってきます。*

開発系のエンジニアなどと違い業務を通して新しい学びや技術を得る機会が少ないため、エンジニアとしてこのままで良いのかと悩んでしまうこともあるでしょう。

システム保守の現場は、任された役割によって忙しさも様々です。*システムアップデートやハードの交換、障害対応などやることがあれば良いのですが、ほぼ監視業務だけ任されてやることが他にないような場合は、逆に暇すぎてきついというケースもあります。*

もちろん監視も立派な業務ですので真面目に取り組まなければなりませんが、動きの少ない長時間業務はなかなかつらいものです。

システム保守業務を行う場所はサーバやインフラを守るための堅牢な建物内であることも多いです。*日光が入らないような閉鎖された空間で仕事をすることが多くなり、そんな中で夜勤を含む長時間労働を行うと生活リズムが崩れる要因にもなり得ます。*

### 怒られることが多く感謝されることが少ないのでやりたくない

システム保守を行うエンジニアが最も忙しく動くのは障害対応の時でしょう。*ユーザにとってはシステムが問題なく動作することは当たり前ですので、障害が発生するとユーザは混乱し「すぐに復旧させろ」「原因を究明して二度と起こらないようにしろ」などと保守エンジニアが怒られるケースもあります。*

十分に対策しても防げない障害もありますし、可能な限り最速の対応で復旧させたとしてもユーザは費用を出して保守を依頼しているため納得してくれない場合もあり、厳しい立場に立たされることもあります。

一方で障害対応以外でユーザと触れ合うことは少なく日頃システムが正常に稼働していることを感謝してもらうような機会もあまりないため、やりがいを感じられないと思う人もいるでしょう。

### 自分の成長や将来性が感じられない

システム保守の仕事でルーティンワークを続けていると、携わっている業務に関することについては知識が蓄積されますが範囲が限られますので、知識が偏りがちになって自分の技術力の向上を感じにくくなる傾向があります。

*また、近年のAI技術の普及でシステム保守作業の自動化によりシステム保守業務自体の需要の減少が懸念されたり、クラウド化によりこれまでのシステム保守業務自体の内容が変わる可能性があるという点で、将来性に不安があると感じる方もいます。*

## システム保守エンジニアからステップアップや転職するには

きついながらもシステム保守が楽しいと感じたりやりがいを得られるのであれば、そのまま現場チーフやマネージャークラスを目指す道もあります。しかしそうでないなら、**部署移動を願い出て別の部門でステップアップを目指したり、異なる職種のITエンジニアとして転職するという選択肢もあります。**

### インフラエンジニア（設計・構築）へのステップアップがおすすめ

**システム保守から異なる職種を目指すのであれば、インフラエンジニア（設計・構築）がおすすめです。*システムを運用・保守する側から、インフラ自体の設計・構築する側になるということです。

インフラエンジニア（設計・構築）になるとお客様と要件を打ち合わせたり実際の構築作業を行うなど監視運用や保守とは異なるスキルが新たに必要とされますが、保守で培ったインフラに関する知識は十分役に立ちます。インフラ構築に携わり技術や経験を得ることができればキャリアパスが大きく広がるでしょう。

インフラエンジニアはきついのか？その仕事内容やスキル、将来性を解説！

インフラエンジニアに必要な資格は？スキルについても徹底解説

務めている会社がシステム保守専業であるなどの事情で、会社内で部署移動ができない場合もあります。その場合は思い切って転職も視野に入れてみても良いでしょう。

*将来に不安を抱いたままつらいシステム保守を続けるよりも、希望職種に転職して環境を一気に変え、キャリアアップを目指すことをおすすめします。*

*転職する場合には自分のスキルを対外的に証明できる資格を持っていると有利です。*システム保守で培ったハードウェアやネットワーク機器の知識を活かして、ベンダー資格のCCNA(Cisco Certified Network Associate)などの資格取得を考えるのも良いでしょう。

【参考】：[CCNA - Training & Certifications - Cisco](https://www.cisco.com/c/ja_jp/training-events/training-certifications/certifications/associate/ccna.html?utm_medium=content-text&utm_campaign=acv07)

## システム保守から転職を目指すなら

ここまでシステム保守がきついと言われる理由と、システム保守からのキャリアアップについて解説してきました。自分自身がやりがいを感じられないのであれば、転職してキャリアアップを目指すことも選択肢の1つだとおわかりいただけたかと思います。

しかし、1人で転職先を探すのはなかなか難しいものです。**これからのキャリアパスを考えた上で転職先を選ばないといけませんし、これまでシステム保守で学んだことを上手にアピールできるかどうかもポイントとなります。**

そこでぜひご活用いただきたいのが[マイナビIT エージェント](https://mynavi-agent.jp/it/?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv07)です。 

マイナビITエージェント【公式】IT・Webエンジニアの求人・転職エージェント

【マイナビIT AGENT】迷ったら相談すればいいんだ

マイナビIT エージェントは、IT・Webエンジニア向けの無料の転職⽀援サービスです。

IT・Webエンジニアの転職事情に詳しいキャリアアドバイザーが、あなたのご経験やスキルをお伺いし、転職活動のプランをご提案致します。

アドバイザーは企業側の人事担当者と直接連携を取れますので、求人票に載っていない企業情報も確認することができます。残業時間や給与面など、働き方などをしっかり確認の上で応募企業を選んでいくのが良いでしょう。

・資格やプログラミングの勉強をしているけれど、企業が求めるレベルに達しているのかわからない
・スキルアップをして市場価値を上げていける企業の選び方を知りたい
・数多くあるITエンジニアの職種の中で、自分に向いている仕事は何か知りたい

こうした悩みを抱えていらっしゃる方は、まずは無料登録でキャリアカウンセリングをおすすめ致します。

<center>[あなたに合った企業選びをサポート致します。 エンジニア転職のご相談はぜひ *『マイナビIT エージェント』*へ！](https://mynavi-agent.jp/it/?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv07)</center>

エンジニアの間では時折システム保守業務はきついという話題が持ち上がります。それはシステム保守業務が他のITエンジニアと異なる業務性質を持つためです。当記事ではシステム保守エンジニアがきついと言われる理由と、将来的に目指すべき道を探す方法について解説します。

システム保守がきついと言われる理由がわかる

システム保守を長年続けるのは将来的にエンジニアとしてキャリアップをしたい人にはあまり向いていない

システム保守から転職する場合インフラエンジニア（設計・構築）を目指すと良い

転職先選びで迷ったら、IT業界に精通した専任アドバイザーのいる[マイナビIT エージェント](https://mynavi-agent.jp/it/?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv16)の利用がおすすめ

システム保守はきついって本当？その実態と目指すべき道を探す方法を紹介

*[【マイナビ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を用います。

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を目指す人に必修のデータフロー図の書き方を習得しよう!

[【関連記事】独学で合格！基本情報技術者試験におすすめの参考書8選！](https://and-engineer.com/articles/Y6Rd9BIAACUAZnkk)

[【関連記事】基本情報技術者試験は意味ない？メリット・デメリット・勉強法を解説](https://and-engineer.com/articles/YTxjQhAAACUAmTAZ)

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