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

## アジャイル開発が失敗するのはなぜ？

アジャイル開発とは、「イテレーション（Iteration：反復）」と呼ばれる短い開発期間の単位を採用し、各機能単位で「要件定義→設計→実装→テスト」のサイクルを繰り返すことで開発期間の短縮とリスクの軽減を図る開発モデルです。

従来のウォーターフォール開発に比べ効率的にシステム開発ができるため、多くの現場でアジャイル開発への挑戦が行われています。しかし、*いざやってみたものの失敗に終わるケースも少なくありません。*

### アジャイル開発の「型」だけ模倣しても上手くいかない

アジャイル開発が失敗するのは、プロジェクトが「生き物」であることを忘れてしまったときです。木に竹をつないでも成長しないように、**従来の開発姿勢に「アジャイルの良さそうなところ」を接ぎ木しようとしても上手くいきません。**

アジャイル開発を成功させるには、プロジェクトに関わる組織全体の姿勢を、アジャイル開発に合ったものへと変えていかなければいけません。これが上手くできていないことが、日本でアジャイル開発が普及しない原因の1つです。

### アジャイル開発のメリットとデメリット

*アジャイル開発の主なメリットは、「開発スピードが速い」「仕様変更に対応しやすい」「顧客に寄り添った開発ができる」ことです。*仕様変更があっても各イテレーション内での影響に留まるほか、途中経過もわかりやすいため顧客とのコミュニケーションが取りやすいです。

一方で、*「開発の方向性がブレやすい」「進捗管理が難しい」といったデメリットもあります。*また、初めに要件を固める必要があり、正確性や安全性が求められる基幹システムの開発には向かないなど、向き不向きもあります。

アジャイル開発を検討する際には、こうした特徴もしっかりと把握しておく必要があります。

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

### アジャイル人材の需要は高い

日本での普及率が低いとはいえ、DXが推進される中でアジャイル開発の需要は高まっています。需要の高さに比べてそれを担える人材の不足が課題になっており、アジャイル開発経験のあるプロジェクトマネージャー（PM）やスクラムマスターは価値の高い人材です。

プロジェクトマネージャーの年収は「マイナビエージェント職業別年収ランキング」での平均年収は670万円（※2023年4月執筆時点）、経済産業省2017年発表の「IT関連産業の給与等に関する実態調査結果」から近い職種のプロジェクトマネージャを参考にすると、平均年収891万円と分かりました。

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

これは開発モデルや開発内容が考慮されていない数値なので、**アジャイル開発を担えるPMやスクラムマスターとなればさらに年収が高いケースもあると予想されます。**

【参考】：[マイナビエージェント職業別年収ランキング](https://mynavi-agent.jp/helpful/income2020/category/it01/?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv12_2)
※【平均年収 調査対象者】2019年12月～2020年5月末までの間にマイナビエージェントサービスにご登録頂いた方
【参考】：[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)

## アジャイル開発が失敗するときのパターン

アジャイル開発を導入しようとして失敗するパターンに共通しているのが、*プロジェクトという生き物（有機体）への不適切な介入です。*それには下記のようなパターンがあります。

### トップが理解不足のまま「アジャイルで行こう」と指示する

経営トップ、あるいはクライアントであるユーザー企業から「このプロジェクトはアジャイルで」とオーダーされても、開発現場がすぐに順応することはできません。

特に、トップのアジャイル開発についての理解が不十分で、プロジェクトが機能する環境や支援を与えずに現場に「丸投げ」すると、成果を得る前に現場は枯死します。

トップがまず配慮すべき環境（土壌）とは、「契約と計画」を第一義とする従来のプロジェクトの枠組みをどのように、あるいはどこまでアジャイルに（柔軟に）するかということです。**契約ありき・計画ありきの従来の価値観のまま、現場にアジャイル開発を要求するのは、砂漠で稲を育てようとするようなものです。**

### アジャイル開発を「手法」「ソリューション」と考える

アジャイル開発を「開発手法の1つ」と考えたり、「従来のプロジェクトにあった問題のソリューション」と捉えたりするのも、失敗に終わるパターンの1つです。

アジャイル開発を最初に提唱した開発者たちが書いた有名な文書に「アジャイルソフトウェア開発宣言」があります。そこに記されているのが次の「宣言」です。

*プロセスやツールよりも個人と対話を、*
*包括的なドキュメントよりも動くソフトウェアを、*
*契約交渉よりも顧客との協調を、*
*計画に従うことよりも変化への対応を、*

これは、アジャイル開発が根付いて育ち、実を結ぶ環境が従来のウォーターフォール開発とは全く異なることを示しています。つまり、アジャイル開発は単なる手法やソリューションではなく、1つの「ソフトウェア開発文化」なのです。

ウォーターフォール開発の文化にアジャイル開発の「良いところ」を部分的に取り入れようとするのは、喩えて言うなら、明治維新のときの日本が士農工商の身分差別を温存したまま文明開化をしようとするようなものでしょう。

### 指導者不在のままプロジェクトをスタートする

プロジェクトマネージャにアジャイル開発の経験・理解が乏しい場合も、失敗の確率が高くなります。「プロセスやツールよりも個人と対話を」を重視するはずが、**個人のモチベーションを高めることができず、クリエイティブなコミュニケーションを引き出すことができないからです。**

「動くソフトウェア」の開発が予定通りに進まなかった場合、ユーザー企業の反感を買うかもしれません。「ドキュメントよりも動くソフトウェアを」とはいっても、品質管理部門がドキュメントも要求してくるかもしれません。

そんなときのPMやスクラムマスターの対応次第で、チームの士気が一気に低下する可能性があります。

### ユーザー企業を巻き込むことができない

初期の計画よりも変化への柔軟な対応を旨とするアジャイル開発では、ユーザー企業を巻き込んでプロジェクトを進めていく必要があります。

「アジャイル開発宣言」の補足文書である「アジャイル宣言の背後にある原則」で「ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません」と述べられているのも同じ意味です。

**ユーザー企業や営業とのコミュニケーションがギクシャクしている中で、あるいは丸投げされた状態では「変化への対応」が困難で、アジャイル開発を成功させることはできません。**

## アジャイル開発を成功させる5つの心得

アジャイル開発を成功させるには、発注側と開発現場の双方に、アジャイル開発は1つの「有機的なソフトウェア開発文化」であるという認識が必要です。

失敗の多さに比例して「アジャイルは疲れる」「意味ない」「アジャイルは嫌い」といったネガティブな声も目立ちますが、失敗の本質を理解し正しい認識を持つことで、アジャイル開発のメリットを発揮した開発を行うことができます。

### 1.経営サイド、ユーザー企業がアジャイル開発の本質、文化を理解する

自社開発の場合は経営サイドが、委託開発の場合はユーザー企業が、アジャイル開発の本質をよく理解しようとすることが大切です。

「アジャイルなら短期間で開発できる」「低コストで開発が可能」などの**部分的な理解、いいとこ取りの発想でアジャイル開発を指示しても上手くいきません。**

RFP（提案依頼書）に「アジャイル開発で」と書くだけではなく、アジャイル開発を指示する場合は発注側が何をしなければならないのかを充分に理解しておく必要があります。

### 2.契約と計画の柔軟性、変更許容度にある程度の目途をつけておく

ビジネスである以上、アジャイル開発でも契約と計画は必須です。アジャイル開発の「契約交渉よりも顧客との協調を」「計画に従うことよりも変化への対応を」という原則に従うのは簡単ではありません。

しかし、ウォーターフォール開発でも初めから粒度の細かい計画を立てられるわけではなく、変化の対応の経験がないわけでもありません。どのようなプロジェクトにも「やってみなければ分らない」ことがあるからです。

より機敏に、柔軟に対応が可能な契約や計画をどのように立てるかに対する一義的な答えはなく、**発注サイドと開発サイドが経験を積みながら相互理解を深めて行くしかありません。**それによって、プロジェクトの内容に合わせて、契約と計画の柔軟性、変更許容度にある程度の目途をつけられるようになります。

### 3.プロジェクトマネージャにアジャイル開発の経験がある人を招聘する

PM、スクラムマスターにアジャイル開発の経験が豊富な人を据えることは、関係者との協議においても、開発チーム内のコミュニケーションにおいても、プロジェクトの成否を決める重要なポイントです。

「アジャイル宣言の背後にある原則」の1つに「意欲に満ちた人々に環境と支援を与え、仕事が無事終わるまで彼らを信頼します」と述べられています。**ビジネス側と開発側をつないでアジャイル開発の原則を遂行するキーマンとなるのがPMです。**

アジャイル開発においてはアジャイルモデルの本質を理解しているPMやスクラムマスターの存在が欠かせません。アジャイル開発の経験があるアジャイル人材は社会的にも需要が高いです。

経験を活かしPMなどへの転職を目指す際は、転職エージェントを利用して最適な現場を見つけましょう。

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

### 4.開発現場に丸投げしないでユーザー企業も一緒に働く

「原則」のもう1つに「ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません」とあります。

2週間ごとの「動くソフトウェア」のイテレーション（反復）が間に合わなかったと言ってビジネス側が怒る、開発側は2週間ごとの徹夜に疲弊するというよくある失敗パターンを回避するには、「日々一緒に働く」しかありません。

アジャイル開発で重視される「フェイス・トゥ・フェイスのコミュニケーション」とは、エンジニアたちのコミュニケーションだけではありません。**ビジネス側の人間が不在の、開発者間だけのコミュニケーションでは議論が前に進まないことが多いのです。**

### 5.チームのメンバーを教育する機会、期間を設ける

アジャイル開発が初めてのチームの場合は、教育機会・訓練期間を設けて、マインドセットすることが肝要です。

その役を担うのはもちろんPMで、**各プロセスにおけるシーンを想定した、経験に基づく具体的な説明が求められます。**メンバーがそれぞれに持っているアジャイル開発についての知識やイメージを修正・統一しておく必要もあります。

## 「アジャイル開発宣言の背後にある原則」を読み直してみよう

上記の各所に紹介してきた「アジャイル開発宣言の背後にある原則」を、ここで改めて読み直してみましょう。下記の12の原則には、失敗を避けるために理解しておきたい「アジャイル開発の本質」が端的に示されています。

1.顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
2.要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
3.動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
4.ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
5.意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
6.情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
7.動くソフトウェアこそが進捗の最も重要な尺度です。
8.アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
9.技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
10.シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
11.最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
12.チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

以上の「原則」には、**エンジニアだけではコントロールできないものが多く含まれていますが、エンジニアなしにはどれも無意味であるとも言えます。**これは、まさにアジャイル開発のプロジェクトが、関係者のすべてが有機的につながっている「生き物」であることを示しています。

アジャイル開発においては、どのエンジニアも「開発の駒」ではなく、「一緒に働く」「意欲に満ちた」「信頼される」人間なのです。

## アジャイル開発の本質を理解して失敗を避けよう

アジャイル開発が失敗する根本的な原因は「アジャイル開発の本質を理解していないこと」です。この記事で紹介した失敗パターンと、アジャイル開発宣言に基づく成功の心得を心に留め、開発の失敗を避けましょう。

アジャイル開発の経験があるエンジニアは需要が高いです。**プロジェクトを成功に導くことができれば、その経験を活かしてアジャイル開発におけるPMやスクラムマスターとして活躍する道も開けます。**

アジャイル開発に携わりたい、経験を活かしてキャリアアップしたいという方は、転職活動を通じて最適な環境を探すことをおすすめします。

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

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

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

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

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

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

## その他のアジャイル開発関連記事

その他、アジャイル開発に関連する内容は、下記の記事でも紹介しています。ぜひ参考にご覧ください。

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

アジャイル開発が失敗するパターンと成功に導くための5つの心得

アジャイル開発宣言の内容を解説！開発に活かす道筋を探る

DX時代に脚光を浴びる「アジャイル開発」の本命「スクラム」とは？

アジャイル開発の要件定義とは？システムエンジニアの必須知識を解説

アジャイル開発のメリット・デメリットや代表的な手法について解説！

近年、プロジェクト開発において「これはアジャイル開発で行こう」と言われることが増えてきました。しかし、流行りに乗って安易に取り組んで失敗に終わるケースも少なくありません。本記事では、アジャイル開発が失敗するパターンと、成功に導くための心得について解説します。

アジャイル開発を便利な開発手法やソリューションと考えると失敗する

アジャイル開発を1つの開発文化と捉えて、その精神を理解することが成功の鍵

ビジネス側とエンジニアが一緒に働き、前向きに協力し合うことが肝要

## 機能要件の書き方が知りたい

システム開発に関しては「要件定義」が重要です。要件定義は顧客の行うことをまとめた要望書のことであり、それに基づいてシステムで実装できる設計書を作成します。*顧客の要望を網羅するために、「機能要件」「非機能要件」として見えない要望を可視化しなければなりません。*

システムエンジニアは、このような機能要件を正しく作成するのも仕事の1つです。顧客やチームメイトが理解しやすいような書き方が必要です。ここでは、機能要件と非機能要件の違いについて解説し、機能要件の作成を担当するシステムエンジニアの年収も併せて紹介します。

**機能要件とは、ユーザ（顧客）がシステムに対して求めている機能のことです。**システム化をすることで、具体的に何が変わり、何が可能となるのかを具体的に記述します。それはプロジェクト全体の目標でもあり、システム開発サイドにとっては作成した機能要件によってプロジェクトのゴールが明らかになります。

機能要件はユーザ（顧客）の要望やニーズを文書にしたものですが、書き出された機能の全てをシステムに盛り込めるわけではありません。

ユーザ（顧客）の予算・スケジュール・組織などの制約がありますので、それらの制約の中でシステムへの実装の可否・優先順位を明確にし、ユーザと調整して認識を一致させておかなければなりません。

非機能要件とは、ユーザ（顧客）が機能面以外でシステムに対して求める要件のことを言います。例えば、**稼働率であるとか、システムの性能（処理スピードや拡張性など）・セキュリティ面・保守サービスなどの要件です。**非機能要件は、機能要件と並んでシステム目標であり、プロジェクトのゴールと言えます。

ユーザから非機能要件を引き出すのは、システムエンジニアの手腕です。非機能要件はシステム設計における重要なパラメーターなので、パラメーターに不足や不備があるとユーザが納得できるシステムの構築が難しくなります。

システム稼働後にユーザから性能などに対する不満の声が上がると、エンジニアは「私たちはユーザの要求通りに開発した」と言い訳をする場面をよく見ますが、それは非機能要件をしっかり洗い出せていなかったエンジニアに責任があります。

機能要件の洗い出しは手順通りにヒアリングをしていれば、大きな齟齬や欠落は起きにくいのですが、非機能要件は想像力・洞察力・共感性などのシステムエンジニアの資質に左右される面があり、機能要件と比べると難易度は高くなります。

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

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

国税庁2020年発表の「民間給与実態統計調査」における民間企業平均年収は433万円なので、システムエンジニアは一般平均年収と比較して、やや高めの年収を目指せることが分かります。

**システムエンジニアはスキルや実績を積むことで、年収が上がりやすい職種です。**

【参考】：[マイナビエージェント 職種図鑑](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)

システムエンジニアの給料は安い？年収を上げる具体的な方法を解説！

システム開発の中で、*要件定義フェイズの機能要件は初期段階の工程です。*ユーザ（顧客）がシステムの完成形に対して具体的なイメージを作り上げている場合は、この機能要件の洗い出しは容易ですが、基本的には具体的なイメージがないという前提で進めるべきでしょう。以下では、その具体的な手順を紹介します。

要件定義を行う前の段階では、ユーザのシステムイメージはまだ漠然としています。まずは、**その漠然としたものを具象化するためにシステム化の背景・理由・目的を明確にします。**背景と目的がしっかり理解できていないと議論がまとまらず、要件を絞り込む際の判断材料が不足してしまいます。

背景や目的が明らかになったら、ユーザが求める機能を1つずつヒアリングするところからスタートします。**ヒアリングした内容を文書・図・表にまとめ、具体的な画面や帳票のイメージを作成しながらユーザの抱くイメージをより具体化していきます。**

業務改善をメインとする仕組みであれば、現状の業務フローと導入後の業務フローを対比させるなどして、必要な機能を洗い出していきます。

*必要な機能を全て洗い出したら、その中から機能単位で優先度を付けていきます。*すべての機能を網羅できれば良いのですが、予算・納期・技術的な問題などの制約条件があるため、すべての要求を満たすことは難しいでしょう。

機能毎に概算の工数や費用を提示し、カットする機能に対しては延期・機能縮小・業務の見直しなどの代替案を検討していきます。予算が足らずに代替案を提示する場合は、開発フェイズを分けて予算確保ができるという条件で2次フェイズに回すという方法が、ユーザにも受け入れられやすくなります。

## 機能要件に書く項目と書き方

機能要件はユーザ（顧客）とのヒアリングを通じて、聞き取り・確認を行いながら記述していきますが、視点を外さず手順に気を付けて行ってください。

### ユーザ要求の背景や目的は何か

ユーザ（顧客）の要求やニーズには必ず背景があり、目的があります。その点を理解しておかないと、認識のズレや齟齬を招く危険性があります。例えば、ユーザから「顧客の買い物動向について、本社で前日の状況を翌日に把握できるようにしてほしい」という要求があったとします。

その目的が、単に集計作業を軽減したいのか、或いは分析をしたいのか、報告用のレポートを作成したいのかによって実装する機能が異なります。

また、それは非機能要件にも大きく関わってくることです。ユーザの要求がどのような背景から生じたのか、その目的や狙いは何なのか、ここで明らかにすることが大切です。

ユーザ要求のレベル、温度感をつかむことは重要です。「システムに対して何か求めるものはありますか？」という問いに対して、「〇〇を実現してほしい」という要求が出された際、それは単なる願望レベルのものから、非常に強い要求であるものまで、温度差があると見なければなりません。

実装すべき機能は何か、可能であれば実装した方が良い機能は何か、特に必要性のない機能は何かを正しく見極めることが重要です。

機能要件を確定するフェイズでは、その最終確定が難航するケースがあります。必要と思われる機能を正しく洗い出せたものの、全ての機能を実装すると予算内に収まらないという問題に直面した時です。

何を残し、何を削るのかをユーザと話し合って決めるのですが、ユーザにしてみれば、折角出した案や要求を断られるというのは大変残念なことです。削る場合はユーザを納得させられる理由や代替案を示さなければなりません。ユーザの立場に立って、ユーザが納得できる方策を詰めていくことが重要です。

機能要件を進める上で、ゼロから始めるというのは現実的ではありません。ネット上にアップされているサンプルを参考にし、自分なりにカスタマイズして利用することをおすすめします。

機能要件のサンプルについては、これがベストだというものはありませんが、**独立行政法人の情報処理推進機構（IPA）が公表している、機能要件一覧が参考になるでしょう。**

こちらは要件定義に関して機能要件（プロセス）・機能要件（インターフェイス）・非機能要件など、フェーズごとに細かく分類されており、それぞれにサンプルが添付されています。

【参考】：[IPA 独立行政法人 情報処理推進機構：超上流から攻めるＩＴ化の事例集：要件定義](https://www.ipa.go.jp/sec/tool/ep/ep2.html)

上記を参考に、正しい機能要件の書き方を身につけましょう。見やすい・分かりやすい書き方ができるエンジニアは優秀だと捉えられやすくなります。こうした丁寧な対応が自身の価値を高め、キャリアアップや転職の際にも武器になります。

機能要件の書き方については理解されたでしょうか？機能要件は要件定義の重要な要素です。機能要件を正しく書けるようにするためには、要件定義について押さえておかなくてはなりません。ここでは要件定義について解説します。

システム化において、要件定義はユーザ（顧客）がシステム化に求めるものを明確にするものであり、システム開発側がユーザの要求を正しく認識・理解する上で、双方が意識合わせを行う重要な工程です。

*双方の意識合わせに重要なのは機能要件、非機能要件であり、これらを正しく書けること、書き方を習得することが大切です。*

精度の高い、正しい要件定義がシステム成功の鍵です。ここでは、要件定義をどのような手順で行うのかについて押さえておきましょう。以下、要件定義の基本的な流れについて解説します。

*1.ユーザ要求のヒアリング*
基本的に多くのITベンダーでは、最初に営業担当がユーザ（顧客）を訪問して、システム化に対する要求事項をヒアリングし、大まかな要件を確認することでシステム案件がスタートします。この後、システムエンジニア帯同で改めて詳細のヒアリングを行い、ある程度の要件定義を行って提案書を作成し、提示します。

*2.要求の細分化*
システム化対象の全体像を把握したら、システムに実装する機能について、細分化をして要件をまとめていきます。業務フローに落とし込んで機能の詳細を把握し、実装する機能についての洗い出しを進めます。ここではユーザ要求や業務フローに関して、漏れや取りこぼしがないよう十分に配慮する必要があります。

*3.要件定義書の作成*
機能要件について細分化をしたら、ここから要件定義書の作成です。要件定義フェイズで作成するドキュメントの内容は、「システム設計フェイズ」につながっていく前段階と捉えます。

要件定義書はシステム開発において全ての基盤ですので、ユーザ側と開発側双方が納得がいくまで、要件定義書の中身にはこだわりましょう。

開発の記事（2ページ目）