COBOLとは、事務処理コンピューター用の汎用プログラミング言語です。1959年に誕生し、60年以上もの間世界中で使用され続けています。

多くの方はプログラミング言語と聞くと、Java・C言語・Pythonなどをイメージされるでしょう。しかし、一昔前はプログラミング言語といえば、COBOLが中心でした。

今や「COBOLは古い言語」というイメージを持つ方も少なくありませんが、昨今、再び注目を浴びるようになってきました。その理由や将来性を含めて、ここでは『COBOLとは』をテーマに、COBOLの概要についてわかりやすく解説していきます。

### COBOLは読みやすくて書きやすい言語

COBOLは『Common Business Oriented Language』の略称で、読み方は「コボル」です。直訳すると「共通事務処理用言語」を意味します。COBOLは『グレース・ホッパー氏』によって開発され、誰もがプログラミングできるようにと、自然言語である英語に近い構文である点が大きな特徴です。

COBOLが登場するまでは、コンピューター言語はアセンブラやFORTRANが主流で、難解であるというイメージがありました。**しかし、COBOLは英語に近く読みやすくて書きやすいことから人気を博し、一気に広がっていきました。**

日本には1963年頃に上陸し、銀行などの金融関係・大企業の会計業務などを中心に普及していき、事務処理システムの開発言語として定着しました。

COBOLと言えば事務処理用言語としてのイメージがありますが、コンピューターの性能向上により、大規模データの処理にも多く利用されています。

若いエンジニア層では、「Javaは分かるけれどもCOBOLはさっぱり分からない」という方が少なくありません。**違いを一言で述べるとすれば、COBOLは手続き型言語であり、Javaはオブジェクト指向言語であるという点です。**

その他、外部のライブラリを使用する場合、COBOLではモジュールを呼び出してメインから一通り実行しますが、Javaはメソッドを呼ぶという点も大きな違いです。

オブジェクト指向言語とは？基本的な概念と代表的な言語を解説

Javaとは？人気プログラミング言語Javaの将来性やメリットについて解説

年収は需要と供給の関係で決まります。DXブームによって、COBOLで組まれたレガシーシステムの見直しが大きな課題となっている企業が増える中、前述したようにCOBOLエンジニアに対する需要は高まっているようです。

一般的なシステムエンジニアの年収は「マイナビエージェント 職種図鑑」での平均年収は431万円（※2023年5月執筆時点）、経済産業省2017年発表の「IT関連産業の給与等に関する実態調査結果」からエンジニア/プログラマを参考にすると、平均年収592万円と分かりました。

国税庁2020年発表の「民間給与実態統計調査」における民間企業平均年収は433万円なので、システムエンジニアの年収は、調査媒体によってバラつきがあることが分かります。

ITエンジニアの報酬は実績が重要視される傾向があるため、COBOLエンジニアを求める企業では、一般的なエンジニアよりも収入がアップする可能性もあります。また、COBOL言語のほかにもさまざまな言語を習得することで、さらなる年収アップ・キャリアアップが図れるでしょう。

【参考】：[マイナビエージェント 職種図鑑](https://mynavi-agent.jp/it/jobindex/04.html?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv12_2)
※【平均年収 調査対象者】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)

### COBOLはどこで使われている？

COBOLは主に以下のようなシステムで使用されています

**・行政システム**
**・金融機関の業務システム**
**・ホテルや交通機関の予約システム**
**・一般企業の基幹システム**

多くのデータを取り扱っていたり、金額の計算が必須であったりするシステムでは、COBOLを採用しているところが多い傾向です。

### COBOLは常に進化を続けている

レガシーのイメージが強いCOBOLですが、誕生当初の第1規格から現在の第4規格に至るまで、多くの機能が追加されたり廃止されたりしてきました。例えば、帳簿作成を簡単にする「報告書作成機能」や、データベースの操作を可能にする「データベース機能」は追加された代表的な機能です。

2002年の変更では、当時主流となりつつあったオブジェクト指向にも対応しました。このように、COBOLは時代の流れにあわせて、常に進化・洗練され続けているプログラミング言語です。

COBOL言語は誕生してから60年以上もの間、多くのシステムで使用されてきました。ここからはCOBOL言語の主な特徴を見ていきましょう。

1959年に誕生したCOBOL言語は60年以上の実績があり、行政・金融系・勘定系システムを多く生み出してきました。**中には20年、30年と安定稼働しているシステムもあります。**この長年に渡る稼働実績と、積み上げられたノウハウはCOBOL言語の信頼性の証です。

### マルチプラットフォームに対応

COBOL言語のコンパイラは、異なるプラットフォームでの相互利用を可能とする連携プロトコルに対応しています。そのため、マルチプラットフォーム環境でのCOBOL言語を用いたシステム構築が可能です。

**COBOL言語は安定性が高く互換性に富み、プラットフォームに依存しないため、移植性の高い言語であると言えます。**

COBOL言語は元々事務処理、特に計算処理に優れており、勘定系システムや給与システムなどで多く使われています。計算能力が高いという評価は、小数点以下の計算が正確である点にあります。

Java言語などでは計算処理は内部的に2進数で表現され、浮動小数点計算で誤差発生の可能性があります。これで積みあがると、整数での誤差を生みます。この誤差を生まないための計算は非常に複雑で、その検証も手間が掛かります。

*勘定系システムでは誤差が許されないため、10進数演算を定義できるCOBOL言語が重用されるのです。*

バッチ処理とは、一定量のデータを一括処理することです。特に事務処理では夜間などにデータをまとめて処理するケースがあり、バッチ処理が行われる場面が多くあります。

**COBOL言語はこのバッチ処理が得意な言語であり、勘定系システムや銀行システムでは、利用時間外にまとめて取引データの更新・残高更新・利息計算などで使われてきました。**

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

扱いやすいCOBOL言語ですが、いくつかの懸念点も存在します。ここでは、COBOL言語に関するやや心配な点をご紹介します。

### 扱えるエンジニアが減りつつある

近年は、オープン系システム開発に向いたC・Java・C++などが言語の主流となっており、COBOLを扱えるエンジニアの年齢層が高くなっています。実際、COBOLエンジニアの中心年齢は40代後半〜50代にシフトしており、60代のフリーランスが活躍している例もあるほどです。

**今後、こうした年齢層の高いCOBOLエンジニアの引退時期を迎えると、COBOLエンジニアの絶対数が不足し、COBOLシステムがブラックボックス化するリスクが想定されます。**

システムの刷新が強く叫ばれている昨今ですが、依然として官公庁や大企業を中心に、COBOLで組まれた1,000万ステップ規模の基幹システムが現在でも多く稼働しています。*上述したとおり、COBOLを扱える技術者は減少しつつあるため、トラブルの根本解決ができないといった問題も表面化しています。*

そうした中、COBOLで組まれたシステムをJavaなどを用いたオープン系のシステムに切り替える動きも少なからず見られますが、COBOLを扱えるエンジニアの減少が足枷になり、思うように進んでいないというのが現状です。

こうしたことから、COBOLを負の遺産と見る向きもありますが、一方で貴重な資産として残していくという声も聞かれます。

*現在のところまだまだ多くのシステムで稼働を続けているCOBOL言語ですが、新たにCOBOL言語を使用して開発を行うという企業はほぼありません。*そのため、COBOL言語の主な使用用途は、現状のシステム保守、トラブル対応、システム切り替え時の対応などです。

「今後システム開発を主に行っていきたい」という方は、COBOLではなく現在主流の言語を学ぶのが得策です。

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

## 今、再びCOBOL言語が注目されている

デメリットとも取れる懸念点があるCOBOL言語ですが、実は近年再び注目が集まっているという話があります。その実態や理由について見ていきましょう。

登場してから60年以上が経過し、衰退したレガシーのプログラム言語と目されていたCOBOLが注目を浴びたきっかけの1つは、新型感染症の流行だと言われています。

2020年4月にアメリカ・ニュージャージー州の州知事が、COBOLについて触れました。新型感染症の流行によって、アメリカでは次々とロックダウンが起きましたが、この結果、失業者が増加して失業保険給付申請が急増し、給付申請システムがダウンしました。

*このシステムはCOBOL言語で実装されていたことから、ニュージャージー州知事が「システム強化のためにCOBOLプログラマーが必要だ」と会見で述べたのです。*このことがCOBOL言語注目のトリガーとなったという次第です。

【参考】：[COBOLがコロナで大注目?! 60年以上前の言語が最近話題](https://news.mynavi.jp/techplus/article/programinglanguageoftheworld-28/)

### DX化によるシステム移行で需要増

日本のシステムが他国と比べて遅れているという指摘が政府からなされています。この20数年間日本経済は低迷していますが、その原因の1つに日本企業がデジタルを有効利用できていない点が指摘されています。

「日本企業においてもデジタルトランスフォーメーションを進めるべき」として、2018年に経済産業省が「DX推進ガイドライン」を策定しました。現在はデジタルガバナンス・コード2.0としてまとめられ、公表されています。

この中でも、「DX化はIT技術による業務改革が競争力を高める上で欠かせない」と述べられています。

しかし、先で述べたとおりCOBOLを扱えるエンジニアは大きく減少しています。そのため、レガシーシステムの移行や再構築のハードルが一気に上がってしまいました。このことから、COBOL言語を扱えるエンジニアの需要は増えつつあるのです。

もしも、COBOLエンジニアとしてより有利な転職を目指すなら、条件に合った企業を探してくれる転職エージェントの活用をおすすめします。

【参考】：[経済産業省:デジタルガバナンス・コード](https://www.meti.go.jp/policy/it_policy/investment/dgc/dgc.html)

DXとは？その意味と日本の現状、DX推進の障壁となる要因を分かりやすく解説！

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

### COBOL言語を見直す動きもある

ここまで述べたように、COBOLの必要性は逆に高まってきました。それとともに、COBOLを見直す動きもあります。

**かつてのCOBOLは、非常に高価な大型の汎用マシンであるメインフレーム上で利用されるのが一般的でしたが、最近ではオープンCOBOLと呼ばれる、Unixなどのオープンシステム上で利用されるCOBOLが登場しています。**

実際に、AWSのLambda上でCOBOLアプリをサーバーレスで動かせるサービスも登場するなど、COBOLへの需要に対応する動きが見られます。

AWS Lambdaとは？できることを分かりやすく解説！

COBOLは官公庁や銀行や保険会社などを中心に、多くの組織や企業で定着している言語です。COBOLで構築されたシステムの多くが信頼性や堅牢性が求められるため、逆に安定稼働している企業では、そのリプレイスに対して慎重です。その一方では、リプレイスの必要性に対する認識は年々高まっています。

最近、有名銀行のシステムトラブルが社会問題化していますが、COBOLで組まれたレガシーシステムの複雑化、COBOLエンジニアの退職などによって、なかなか思い切った手を打てないという状況も、リプレイスに慎重になっている要因とされています。

**こうした状況から、COBOLに対する高い需要は当面の間続くでしょう。**いずれにしても、求人に対する人材不足は顕在化しており、COBOLエンジニアの確保と育成は喫緊の課題であることは否めません。

ここまで今話題のCOBOL言語について解説しました。COBOL言語は古いイメージがありますが、官公庁・地方自治体・金融機関・大企業などで、重要なシステムとして数多く採用され、今も日夜動いています。

リプレイスやメンテナンスなども含めて今後も高い需要が見込まれることから、減少傾向にあるCOBOLエンジニアへの期待はますます高まることでしょう。**Javaなどのオープン系のプログラミング言語を使えて、さらにCOBOLを習得すれば、活躍の機会は一気に広がります。**

COBOL入門書や解説サイトも多数あり、またWindowsやMacでもプログラミングを行えるため、ハードルは高くありません。この機会にCOBOLの勉強をスタートさせれば、さらに大きな仕事にチャレンジできる可能性があります。とはいえ、1人でCOBOL言語を活かせる職場を見つけるのは、なかなか難しいものです。

そこで利用を推奨するのが[マイナビIT エージェント](https://mynavi-agent.jp/it/?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv12_2)です。 

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

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

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

未経験からのキャリアチェンジは心身ともに本当に大変だと思います。少しでもご自身の負担を減らすべく、エージェントサービスを活用して、失敗のない転職活動に臨んでいただければ幸いです。

COBOLとは主に事務処理を目的に1959年に開発されたプログラミング言語で、誕生から60年以上経過していますが、現在でも大企業を中心に基幹システムで利用されています。この記事では、COBOLとは何か・特徴・メリット・将来性などについて解説していきます。

COBOLとは、事務処理コンピューター用に1959年に開発された汎用系のプログラミング言語である

COBOLは計算能力が高く、信頼性や安定性があり、勘定系システムを中心に官公庁や金融機関などで今も利用されている

COBOLエンジニアの現象やDXにより、逆にCOBOLエンジニアに対する需要が高まっている

COBOL（コボル）とは？なぜなくならない？将来性と特徴をわかりやすく解説

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

Docker Composeとは、一言で表現するならコンテナ管理ツールです。Dockerコマンドのみでアプリケーションを実行する場合、コンテナごとにパラメータを設定したり、起動したりする必要があります。

管理するコンテナが少ない場合はそれでもよいのですが、コンテナが増えれば増えるほど、パラメータや起動・停止の手順管理が煩雑になり、ミスも増えてしまいます。

そこで登場するのが、Docker Composeです。Docker Composeを利用すると、複数のコンテナの設定やオプションをファイル単位にまとめることができます。

*1つのファイルで複数のコンテナを定義できるため、コンテナの数だけコマンドを実行する必要がなくなり、余分な作業やミスを減らすことができます。*

他にも、ファイルを流用することで、環境の複製が簡単にできたり、テスト環境の一括デプロイに活用できたり、Dockerを利用する上では必須とも言える大きなメリットがあります。

Dockerとは？使いどころやメリット・デメリットについて解説！

## Docker Composeをインストールする方法

それでは、早速Docker Composeをインストールしていきましょう。

### Docker Desktopの利用可否を検討

まず、Docker Desktopが利用可能か確認しましょう。Docker Desktopは、Docker Engine、Docker CLI クライアント、Docker ComposeといったDockerの主要なアプリケーションをすべて含んだパッケージで、さらにGUIによる視覚的・直感的なコンテナ管理を利用できる特徴があります。

**Docker Desktopを利用すると煩雑なインストール作業をシンプルにできるため、Docker公式でもDocker Desktopの利用を推奨しています。**Docker Desktopをインストールする場合は、Docker Composeに必要なアプリケーションがすべて含まれているため、個別にインストールする必要はありません。

【参考】：[Docker公式-Docker Desktop 概要](https://docs.docker.jp/desktop/index.html)

ただし、Docker Desktopは従業員が251人以上または年間の収益が1,000万ドル以上の規模での利用は商用利用となり、有料のサブスクリプション契約が必要です。商用規模の利用でDocker Desktopの有償契約を選択できない場合は、次から解説する手順で個別にインストールしましょう。

Docker Desktop 4.6が登場！最新版の新機能やインストール手順を解説

まず、事前準備として、Docker ComposeにはDocker自体は含まれていませんので、事前にDockerのインストールを済ませておく必要があります。

【参考】：[Docker公式-Docker のダウンロードとインストール](https://docs.docker.jp/get-started/index.html#download-and-install-docker)

また、ご使用のOSによってインストール方法が違いますので、確認しておきましょう。*Docker Composeは各種LinuxOSおよびWindows、macOSで動作します。*

Windows・Linux・MacOSのDockerインストール

### Docker Composeをインストールする

Docker Compose をインストールする方法はいくつかありますが、ここではLinux環境でDockerリポジトリから最新バージョンのDocker Composeをダウンロードしてインストールする方法について解説します。

*Dockerリポジトリとは、Docker Composeのインストールパッケージが格納されている場所のことです。*まずは、DockerリポジトリにアクセスしてDocker Composeの最新バージョンを確認して、メモしておきます。

【参考】：[Docker公式-Dockerリポジトリ](https://github.com/docker/compose/releases)

それでは、早速インストールを進めましょう。Dockerのインストールされている環境で、以下の手順でコマンドを実行してください。

```sudo curl -L https://github.com/docker/compose/releases/download/＜Docker Composeの最新バージョン＞/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose```

このコマンドでは、Dockerリポジトリから最新バージョンのDocker Composeをダウンロードして、/usr/local/bin/docker-composeの配下に保存しています。

```sudo chmod +x /usr/local/bin/docker-compose```

このコマンドでは、/usr/local/bin/docker-composeの配下のファイルに実行権限を付与しています。これにより、docker-composeコマンドが実行できるようになります。

このコマンドは、インストールされているDocker Composeのバージョン情報を出力します。バージョン情報が出力されない場合はインストールできていないので、インストール手順を再度見直してみましょう。

```docker-compose version 2.14.2, build <ビルド>```

このように、最新バージョンの表示が確認できればインストールは成功です。

## Docker Composeで環境を構築する

それでは、実際にDocker Composeを使用して環境構築を実践してみましょう。*ここでいう環境構築とは、複数のコンテナを定義して起動し、コンテナ同士が通信を確立し、連携した状態にすることを指します。*

今回は例として、WordPressをDocker Composeで構築する方法について解説します。この方法は、Docker公式のクイックスタートガイドでも紹介されています。

【参考】：[Docker公式-クィックスタート: Compose と WordPress](https://docs.docker.jp/compose/wordpress.html)

### Docker Composeのプロジェクトを定義する

まずは、プロジェクト用のディレクトリを作成しましょう。名前は任意で構いませんが、ここではmy_wordpressとしておきます。

*Docker Composeを使用するには、まず「docker-compose.yml」というファイルを作成します。先ほど作成したプロジェクト用のディレクトリ配下に作成しましょう。*

### Docker-Compose.ymlにコンテナを定義

**このファイルには、Dockerイメージをビルドするために必要な情報、コンテナを起動するために必要な情報、コンテナ同士の通信で使用するDockerネットワークなどを定義します。**

       MYSQL_ROOT_PASSWORD: somewordpress

       WORDPRESS_DB_USER: wordpress

       WORDPRESS_DB_PASSWORD: wordpress

「services:」配下にコンテナ情報を定義しています。このサンプルコードでは、MySQLデータベース用の「db」と、WordPress用の「wordpress」の2つのコンテナが定義されています。

### Docker Composeでコンテナを起動するには

docker-compose.ymlファイルに定義したコンテナを起動するには、以下のコマンドを実行します。

*docker runコマンドと比較すると、オプションをコマンドに付与する必要がないため、とてもシンプルになっていることが分かります。*

コンテナの起動確認をするには、以下のコマンドを実行します。

StateがUpになっていれば、そのコンテナが起動中であることを表しています。以上で、Docker Composeによる環境構築の手順は完了です。

このように、Docker Composeを利用すると複数のコンテナをファイル単位でまとめて管理できるため、運用上のオーバーヘッドを解消できることがお分かり頂けたかと思います。

## Docker Composeでワンランク上のコンテナ活用を

コンテナ管理をより便利にするツールとして、Docker Composeの導入を検討している方も多いのではないでしょうか。この記事では、具体的なインストール方法や、インストール後の環境構築の方法についても分かりやすく解説します。

Docker Composeの概要をざっくり理解する

Docker Composeのインストール方法が分かる

言語・開発の記事（60ページ目）