**ソフトウェア開発において、テストは品質を担保する上で大変重要な工程**です。ソフトウェアのテストをレベルに分けると、大別して次の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つの観点がある。

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

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

## アプリケーションエンジニアはきつい？

アプリケーションエンジニアに転職したいものの、転職に不安を覚える方も多いのではないでしょうか。「アプリケーションエンジニア」で検索すると「きつい」「やめとけ」などが関連ワードに出るため、転職後についていけるか不安な方も多いでしょう。

確かに、アプリケーションエンジニアの仕事はきつい場合もあるかもしれませんが、そもそもアプリ開発にはさまざまな種類があるうえに、開発を行う企業もベンチャーから大手まで幅広くあります。

そのため、*すべてのアプリケーションエンジニアを一括りにして考えるのは難しいです。*転職する際は「アプリケーションエンジニアは〇〇だ」という先入観を捨て、各企業の業務内容や残業時間などをしっかり確認することが重要でしょう。

## アプリケーションエンジニアは楽しい面も多くある仕事

**アプリケーションエンジニアには楽しい面も多くあります。**アプリ開発に興味があり、長く働き続けたい場合は転職も視野に入れた方が良いでしょう。他のエンジニア職からアプリケーションエンジニアに転職するのもおすすめできます。

アプリ開発の種類にもよりますが、Webアプリやスマホアプリなどは特に需要が高く、アプリ開発を行うエンジニアも市場価値が高まっています。

## アプリケーションエンジニアとは？

ここでは、アプリケーションエンジニアとは何かについて簡単に解説します。アプリケーションエンジニアの種類や年収についてまとめました。

### アプリケーションエンジニアの種類

アプリケーションエンジニアとは、コンピュータのOS上で動作するソフトウェア（アプリケーション）を開発するエンジニアのことです。アプリといっても以下のようにさまざまな種類があります。

- 業務系アプリ
- スマホアプリ
- Webアプリ
- 組み込みアプリ
- デスクトップアプリ

*各アプリの開発で必要な技術やプログラミング言語は異なるため、アプリケーションエンジニアを目指す場合、まずはどのアプリ開発に携わりたいのかを決める必要があります*。たとえばWebアプリ開発を行いたいなら、スクリプト言語やデータベース、Webサーバなどの知識を身につける必要があります。

アプリケーションエンジニアになるために身に付けるべきスキルとは？

### アプリケーションエンジニアの年収

アプリケーションエンジニアの年収についてですが、ここでは近い業種のプログラマーの年収例を紹介します。プログラマーの年収は「マイナビエージェント職業別年収ランキング」での平均年収は344万円、経済産業省2017年発表の「IT関連産業の給与等に関する実態調査結果」から近い職種のSE・プログラマ（ソフトウェア製品の開発・実装）を参考にすると、平均年収568万円と分かりました。

国税庁2020年発表の「民間給与実態統計調査」における民間企業平均年収は433万円なので、プログラマーは一般平均年収よりも、やや低めであることが分かります。

**アプリ開発の需要が高まっていることを考慮すると、年収はさらに上がっていくことが予想されます。**また、マネジメントやコンサルタント職にキャリアアップすることで年収を上げていく道もあります。

【参考】：[マイナビエージェント職業別年収ランキング/職種図鑑](https://mynavi-agent.jp/it/jobindex/05.html?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv07)
※【平均年収 調査対象者】2020年1月～2020年12月末までの間にマイナビエージェントサービスにご登録頂いた方
【参考】：[IT関連産業における給与水準の実態① ~ 職種別（P7）](https://warp.da.ndl.go.jp/info:ndljp/pid/11623215/www.meti.go.jp/press/2017/08/20170821001/20170821001-1.pdf)
【参考】：[民間給与実態統計調査-国税庁](https://www.nta.go.jp/publication/statistics/kokuzeicho/minkan2020/pdf/002.pdf)

## アプリケーションエンジニアがきついと言われる理由

アプリケーションエンジニアがきついと言われる理由について、以下にまとめました。これらはすべてのアプリケーションエンジニアに該当するわけではなく、一部のみ該当する点には注意が必要です。

### ユーザの要望によって修正が必要

*アプリ開発はユーザに公開して終わりではなく、その後ユーザからフィードバックを受け改良を繰り返していく必要があります。*たとえばオンラインゲームなどは、SNSでの意見などを元に何回もアップデートがされています。

改良作業は新規開発よりも面白くないと感じる方もいるため、それがきついと言われることに繋がることがありますが、改良はアプリをより良いものにするために必要な工程でもあります。改良を経てユーザからの評判が良くなっていけば、そこにやりがいを感じられるでしょう。

**アプリケーションエンジニアは、業務をこなすために勉強しなければならないことが多い職種です。**IT技術が日々アップデートされているため、1人前になった後も最新技術を随時勉強していかなくてはいけません。勉強が苦なく行える人はアプリケーションエンジニアとしての素質があると言えます。

### 人によっては担当する箇所が多い

アプリケーションエンジニアは担当箇所が増えてしまうこともあります。たとえば、Web開発の現場では、いわゆるフルスタックエンジニアと呼ばれる方は、サーバサイドからバックエンド、インフラ関連まで担当している場合もあります。*担当箇所が広ければその分作業時間も増えてしまいます。*

ただ、そういった方は技術レベルが高く、本当に好きで開発を行っている場合がほとんどであるため、作業時間が多少長くても苦にしていない場合が多いでしょう。

フルスタックエンジニアとは？必要な条件・年収・将来性を解説

### 少ない人数で回している会社も多い

アプリ開発を行う企業によっては少ない人数で回している場合もあり、1人のアプリケーションエンジニアの負担が大きくなっていることもあります。特にベンチャー企業はどうしても少ない人数で開発をこなす必要があります。

アプリ開発企業のすべてが少ない人数で回しているわけではありませんが、*残業時間や休日出勤の有無は企業によって差があるので、転職前に入念に調べましょう。*

## アプリケーションエンジニアの楽しい・魅力的な面

アプリケーションエンジニアの仕事は大変な面もある反面、楽しかったり魅力的だったりする面も多くあります。ここでは、アプリケーションエンジニアの楽しい点・魅力的な面について解説します。

### ユーザからフィードバックを得られる

自分達で開発したアプリはユーザからフィードバックを得られます。感謝の言葉を直接聞くこともあり、モチベーションアップに繋がることもあるでしょう。

*また、アプリの人気が高まればSNSなどで知名度がどんどん高まり、売上も上がっていきます。*事業の成長を実感できれば、さらに開発のモチベーションが高まるでしょう。

スマホアプリやWebアプリといったアプリ開発の需要は、年々高まっています。パソコンやスマホが普及し、企業でも業務アプリを導入して業務効率化を図る動きが強まっています。そのため、**アプリケーションエンジニアは仕事を失う心配が少ないと言えます。**

Windows 11でAndroidアプリが動作？プレビュー版概要

### 上流工程にキャリアアップすれば年収も上がる

*アプリケーションエンジニアにはプロジェクトマネージャーやコンサルタントなど、上流工程の仕事にキャリアアップする道もあります。*上流工程にキャリアアップすれば責任が増える反面年収も上がりやすくなる傾向があります。

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

ITコンサルタントにおすすめの資格7選！年収や将来性も解説

### 学習意欲が高い人は活躍しやすい

IT関連は新しい技術がどんどん出ています。アプリケーションエンジニアは随時それに対応しなくてはいけない大変さがありますが、裏を返せば学習意欲が高い人には活躍の場が与えられやすいということでもあります。

自己学習で最新技術を勉強しておくことで、社内で関連する新規事業が立ち上がったときに活躍することができます。アプリケーションエンジニアは自己学習した分だけ成果を出せる仕事と言えます。

プログラマになるには？プログラミング学習の心構え・学習方法を解説！

## アプリケーションエンジニアに転職するなら

本記事では、アプリケーションエンジニアの仕事がきついと言われる理由とやりがいや年収を解説しました。確かにアプリ開発の仕事は大変ではあるものの、アプリ開発は需要が高く年収も上がりやすいと想定されます。**アプリケーションエンジニアの仕事にやりがいがあると感じた方は、他のエンジニア職から転職することを視野に入れても良いでしょう。**

しかし、他のエンジニア職への転職に不安を覚える方も多いのではないでしょうか。今持っている技術をどうアピールすべきか分からないなど、不安な点は多々あるでしょう。

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

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

マイナビ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>

アプリケーションエンジニアへの転職に興味があるものの、きつい・やめとけという声を聞き、転職をためらっている方もいるのではないでしょうか。本記事ではアプリケーションエンジニアがきついと言われる4つの理由、楽しさ・魅力的な点、仕事の種類や年収について解説します。

アプリケーションエンジニアは楽しい面も多くある仕事

アプリケーションには業務系アプリ・スマホアプリ・Webアプリなどの種類がある

仕様変更が多かったり学ぶべきことが多いのがアプリケーションエンジニアが大変と言われる理由

他のエンジニア職への転職が不安なら、IT業界に精通した専任アドバイザーのいる[マイナビIT エージェント](https://mynavi-agent.jp/it/?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv16)への相談がおすすめ

アプリケーションエンジニアがきつい理由4選！やりがいや年収も解説

**ER図とは、システムが扱うデータ構造や、データ間の関連性が一目でわかるように可視化した設計書のこと**です。ERとは「Entity Relationship」の略称であり、データ間の関連性を指します。ER図を作成することで、そのシステムがどんなデータを扱っているかを理解しやすくなります。

ExcelやPowerPoint等といったよくあるOffice製品でもER図の作成は可能ですが、*専用のツールを用いることで作成・管理にかかるコストを減らす*ことができます。本記事ではおすすめのER図描画ツールを紹介した上で、ER図を書くのに必要な知識、作成した際のメリットについて解説します。是非あなたの開発プロジェクトへの導入を検討してください。

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

LucidChartは、**シンプルなUIを備えておりとても使いやすいツール**です。図形のドラッグ&ドロップでER図を作成することができます。本記事で紹介するER図だけでなく、他にもPERT図やインフラ構成図など、開発業務に必要となる様々なドキュメントの生成も簡単になります。

またLucidChartの最大の特徴として、GoogleやAtrassian、Slackなど*多くの外部サービスと連携できる*ことが挙げられます。例えば、Googleドライブ上に居ながらER図を作成したり、Slackのチャネル上に居ながらLucidChartで作られたER図を閲覧することができます。

【参考】[クラウドベースER図作成ツール | LucidChart](https://www.lucidchart.com/pages/ja/examples/ER-diagram-tool)

diagrams.netも**LucidChartと同じくらい高機能なER図生成ツール**です。元々は「draw.io」という名称で利用されていました。ダウンロードしてデスクトップアプリとして使うも良し、オンラインのみで使うも良しの便利なツールです。

専用のプラグインを使えば、*Visual Studio Code（以下、VSCode）上でも編集が可能*です。VSCodeのプラグイン検索で「Draw.io Integration」と検索しインストールするだけで、手元のエディタ上でER図を編集できるようになり、Gitによるバージョン管理も可能になります。

ドキュメントのバージョン管理に苦労するプロジェクトに悩んでいる方は、是非導入してはいかがでしょうか。

【参考】[Diagram Software and Flowchart Maker](https://www.diagrams.net/)

CacooはER図生成ツールの中でも、**作業状況をチームメンバーへ共有することに優れたツール**です。作成した図にコメントを付けたり、Cacoo内でビデオ通話を行いながら議論を深めたりすることができます。

CacooをリリースしているNulab社は「チームのコラボレーションを促進するサービスの開発・提供」を理念に掲げており、他にもプロジェクト管理ツールの「Backlog」やチャットツール「Typetalk」を提供しています。

テレワークが増えた結果、メンバ―間のコミュニケーションに課題を感じ始めた開発現場は多いでしょう。そういった現場にいるエンジニアの方は、一度マネージャーにCacooの導入を提案してはいかがでしょうか。

【参考】[フローチャートやワイヤーフレーム、プレゼン資料まで作れる | Cacoo(カクー)](https://cacoo.com/ja/)

今回紹介するツールの中では、最も昔から使用されているツールです。特にWindows端末ユーザーの中では、SQLクライアントとして、データベースに接続してSQLを実行するために使っている方も多いのではないでしょうか。*Oracle Database・SQL Server・MySQL・PostgreSQLなど様々なデータベースシステムと連携できる*のが魅力です。

データベースに直接接続できることから、**既存のデータベースのテーブル構造を基にER図を生成することが可能**です。「既にデータベース設計も終わり開発が始まっているけど、後からER図だけ作りたい」といった現場にはマッチするツールです。

【参考】[A5:SQL Mk-2 - フリーのSQLクライアント/ER図作成ソフト (松原正和)](https://a5m2.mmatsubara.com/)

**GitMindは、あらゆるデバイスで利用できるツールとして人気です。**対応デバイスはWindows・Mac・Linux・iOS・Androidで、各デバイス間でデータの保存や同期ができます。クラウド版や無料版があるため利用しやすく、「どのツールを使ったらいいのかわからない」という方も、気軽に使うことができます。

また、豊富なテンプレートがあり簡単にER図を作成できるため、ER図を作成するのが苦手な方にもおすすめです。

【参考】[GitMind - あらゆる端末で利用可能なマインドマップツール](https://gitmind.com/jp/)

**Gliffyは図形をドラッグ&ドロップしてER図を作成できるため、直観的な作図が可能**なツールです。書き方は、あらかじめ用意された図形をホワイトボード上にドラッグ&ドロップするだけです。また、複数のメンバーと共同で作業するのに便利な変更履歴・コメント・共有機能などがあります。

無料のトライアル版も用意されているため、事前に使い勝手を確かめることができるのもメリットです。

【参考】[Diagramming Software & Team Collaboration Tools | Gliffy Diagram Apps](https://www.gliffy.com/)

**EdrawMaxは、多種多様な素材と豊富なファイル形式に対応している**ツールです。IT以外にも建築・教育・科学などの専門分野に特化した素材が用意されており、わかりやすい且つオリジナリティのあるER図を作成できます。また、図と図を繋げるパスを自動生成する機能があり、複雑なリレーションを描くのに便利です。

対応しているファイル形式はOffice系・画像ファイル系・HTMLとなっており、用途によってさまざまなファイル形式で保存やエクスポートができます。

【参考】[優れたフローチャートソフト＆作図ツール | Wondershare EdrawMax](https://www.edrawsoft.com/jp/edraw-max/)

Visual Paradigm Onlineは、多くの種類の図とテンプレートが魅力のツールです。**図の種類は200以上、テンプレートの種類は2000以上用意**されており、どんな内容を作図するにも適切な図とテンプレートが見つかります。また、メンバーとのライブチャット・ビデオ会議機能があり、ER図の作図やER図の共有をリアルタイムで行うことが可能です。

【参考】[Visual Paradigm Online - Suite of Powerful Tools](https://online.visual-paradigm.com/ja/)

ここまでER図描画ツールを紹介しましたが、そもそも何故ER図を作る必要があるのでしょうか？開発現場にはドキュメントが付き物ですが、ドキュメントが多くなりすぎて管理しきれない現場も数多くあります。つまり、**多すぎるドキュメントが開発効率を下げてしまう場合もあります。**

下記では、ER図を作ることで得られるメリットを2点紹介します。これらを基に「自分の現場では、ER図は必要だろうか？」を一度考えて、必要だった場合には是非ER図を導入してください。

### 開発フェーズにおいて、データ構造が分かりやすくなる

エンジニアとして開発業務をしていると、「このデータって、他のどんなデータと紐づいてるんだっけ？」という疑問が生じることが多いでしょう。システム規模が大きくなってくればなおさらです。

この時に*ER図がないと、設計したデータ構造を確認するために、ソースコードのモデルクラスやデータベースを直接確認する必要があります。*これにより開発効率は下がってしまいます。

逆に**ER図があれば、図を見るだけでデータ同士の関連性が分かる**ので、エンジニアは更に開発に集中できるでしょう。生産性の高いエンジニアを目指す方で、現場にER図がなくて困っている方 は、是非ER図の作成を提案してはいかがでしょうか。

### 保守運用フェーズにおいて、データ定義の変更がしやすい

一度リリースしたシステムに機能を追加をする際、テーブルのカラム追加・削除を検討することもあるでしょう。その際にER図があれば、**どのテーブルにカラムを追加すべきか判断しやすくなります。**また、ER図ではデータ同士の関連性も分かります。このことからデータ構造変更の際に*既存の機能・データに影響がないか（=デグレードがないか）の判断材料にもなります。*

デグレードを起こすことは、ユーザーの幸せの為に作った機能が結果的にユーザーを困らせてしまうことに他なりません。開発チームとしては絶対に避けたいものです。信頼のおけるエンジニア組織になるためにも、是非ER図を使ってメンバーと議論を重ねてください。

ここではER図を作成・管理した経験のない方のために、**基本的なER図の構成要素を紹介**します。本記事で紹介したツール上でも、これらを知らないとER図を上手く書くことができません。また*ER図の構成は データベース設計の際にも必須の概念*となるので、是非この機会に覚えてください。

**システムが処理する「モノ」や「コト」を言語化し、定義したものがエンティティ**です。データベース設計では、テーブルに相当します。ネット通販サイトを例にすると、「会員」「商品」「注文」「会員登録」などがエンティティに相当します。エンティティは大きく二つに分類されますので、以下で詳しく紹介します。

マスタ系エンティティとも呼ばれます。システムが管理するデータの中で、実在する「モノ」を表すことが多いエンティティです。上記の例では「商品」や「会員」がこれに相当します。

システムが管理するデータの中で、業務上発生したデータを表します。上記の例では「注文」や「会員登録」がこれに相当します。

**エンティティが持つ情報を更に細分化したものがアトリビュート**です。データベース設計では、テーブルが持つ各カラムの情報を表すことが多いです。

「会員」情報を例にすると、「名前」「メールアドレス」「パスワード」「名前」等です。データベース設計では、「会員がネット通販サイトにログインする」といった*業務上の行動のために必要なデータ*は何かを考え、アトリビュートとして表現します。

その名の通り、**エンティティ同士の関係性を表したものがリレーション**です。ER図上では、エンティティとエンティティの間に線を引いて表します。例えば、「会員」が居ない状態では「注文」は発生しません。このような*一方のエンティティが他のエンティティに依存するような関係性*の時、ER図上ではエンティティ間に依存リレーションがある状態で描かれます。

カーディナリティとも呼ばれます。**エンティティ1つに対し、他のエンティティがいくつ保持される可能性があるか**を表します。上記の「会員」「注文」の例では、会員一人が複数注文することはあれど、一件の注文が複数の会員から行われることはありません。こういった場合、「会員」と「注文」には*1対多の関係がある*としてER図には表されます。

データベース設計には必須！ER図の書き方を分かりやすく解説します

## ツールをうまく使って、効率的なER図作成をしよう！

本記事では、*おすすめのER図描画ツールについて解説*しました。ER図はExcelやPowerPoint等のOffice製品でも作成は可能ですが、ここで紹介したツールを用いることで、より効率的にER図を導入することができます。

ER図は、システムの扱うデータ規模が大きくなってくれば、必ずどこかで必要になってくるドキュメントです。開発現場が成長した際あなたがER図の作成を任された場合には、この記事で紹介したツールを用いて、是非分かりやすいER図を作ってください。

開発や保守の効率化のためには、ER図を導入することをおすすめします。Excel等でも作れますが、専用の描画ツールを用いることでより効率的にER図を作成・管理できます。本記事ではツールの紹介をした上で、ER図の基本的な構成要素についても解説します。

ER図は、システムが扱うデータ構造を可視化し、メンバー間で共有できるようにしたもの。

おすすめのER図描画ツールは「LucidChart」「diagrams.net」「Cacoo」「A5:SQL Mk-2」「GitMind」「Gliffy」「EdrawMax」「Visual Paradigm Online」。

ER図を使うことで開発効率を高め、システムのデグレードを未然に防ぐことができる。

ER図の作成ツールおすすめ8選！データ構造をわかりやすくしよう

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

## HTML編集ソフト（エディタ）を活用する

HTML/CSSを学び始めると、HTML作成ツールとしてHTML編集ソフトが必要になってきます。ここでは、*HTML/CSSの初心者の方に向けて、使い勝手が良く、GUIに優れたHTMLエディタを紹介していきます。*皆さんに合うHTMLエディタ選定の参考にしてください。

**HTMLエディタは、HTML/CSSの作成や編集を効率的に行えるテキストエディタです。**そもそも「テキストエディタ」とは、ソースや文書ファイルなどを編集するためのプログラムのことです。HTMLエディタは、HTMLの作成ツールと考えて良いでしょう。

WindowsやMacに標準搭載されているテキストエディタは、主にテキストの編集を行うためのアプリですが、*HTMLエディタにはテキストの編集に加えてソースコードの入力補助・タグの自動補完・エラーチェック・ファイル連携などの機能が備わっています。*

これらの機能を用いて効率的なHTML記述やWebページの制作を行えますので、HTML/CSSを日常的に使うエンジニアの方にはHTMLエディタの利用がおすすめです。

### なぜHTMLエディタにこだわる必要があるのか

Windwos標準の「メモ帳」、Mac標準の「テキストエディット」でもHTML/CSSの作成や編集は可能です。しかし、これらの標準ソフトはHTML/CSSに特化したものではないので最低限の機能しか搭載しておらず、HTML/CSSの作成・編集に最適とは言えません。

ITエンジニア、プログラマーの仕事は常に時間との勝負です。しかも、スピードだけではなく高い品質も求められます。プログラムの品質とボリュームを保ちながら納期までにシステムを完成させなければなりません。

**ITエンジニアは高い生産性が求められる職種であり、それを実現するには使い勝手の良いテキストエディタに出会う必要があります。**自分に合う良いエディタを使うことは、自らの仕事の生産性を上げるために欠かせません。

では、HTMLエディタを使うことで具体的にどのようなメリットがあるのでしょうか？まずはHTMLエディタの一般的なメリットについて確認しておきましょう。

**HTMLエディタには自動補完機能が付いており、入力ミスや入力漏れを防いでくれるため、HTMLの記述をスムーズに行うことができます。**

自動補完機能とは、開始タグを打つと自動的に終了タグが記述されるなど、打ち込んだ記号や文字の関連タグを自動で入力してくれる機能です。この機能があることで、効率的にHTMLの記述作業ができます。

HTMLは記述ミスをしても思い通りの表示がされないだけで、プログラムのように重大なエラーにはなりにくいです。そのため、うっかりミスに気付かずに記述を進めてしまうことがあります。しかし、仕事でHTMLを記述する際に、そのようなミスは許されません。

お役立ち記事