PERT図は、「PERT」というレビュー手法に用いられるツールです。「PERT（Program Evaluation and Review Technique）」は、1950年代にアメリカの海軍によってはじめて導入された、**業務の流れや所要時間を図式化し、大規模なプロジェクトや複雑な業務のスケジュールを管理するための手法**です。この「業務の流れや所要時間を図式化」したものがPERT図です。具体的には、プロジェクト案件の工程の所要時間や順序の関係をフローチャートなどの形で図式化していきます。

**PERT図の目的は、プロジェクトの必要工程や必要日数を把握することです。PERT図を活用することで、プロジェクトのなかでも最も重要な工程やタスクを発見することができるでしょう。**複数の業務が同時に並行するようなプロジェクトでは、1つのタスクが遅れてしまうとプロジェクト全体に影響が出てしまう可能性もあります。そのため、顧客から与えられた納期のなかでプロジェクトを成功させるためには、進捗の遅れが生じないように各タスクの「最早開始時刻」や「最遅完了時刻」などを明確にし、重点を定めて進捗管理を行うことが重要です。その際に、活用できるのがPERT図と言えるでしょう。

PERT図には、*結合点を示す数字が入っている円をタスクの順番を示す矢印で結びつける「アローダイアグラム」と、各作業工程をボックスに記述し、各工程同士の順序や流れを矢印で結びつける「フローダイアグラム」の2種類があります。*ただし、方法が異なるだけで、必要な構成要素などは変わりません。

ここではPERT図の主な構成要素を4つ紹介します。

*1.最早開始時刻*
**最早開始時刻とは、最も早く作業をはじめることができる時点のことです。**これは、前工程の最早開始時刻に所要時間を足し合わせることで求めることができます。

*2.最遅完了時刻*
**最遅完了時刻とは、最遅でも作業が完了していなくてはならない時刻のことを指します。**最遅完了時刻は、次の工程の最遅完了時刻から所要時間を引くことで求めることが可能です。たとえば、最遅完了時刻より作業の完了が遅れる場合、本来予定している納期に間に合わなくなるということになります。

*3.余裕日数*
**余裕日数とは、各工程がもっている作業開始時点までの日程の余裕のことを言います。**たとえば、余裕時間がゼロとなっている工程では、進捗の遅延が発生してしまうとプロジェクト全体に影響する作業が含まれていることを意味します。余裕日数は、最遅開始時刻から最早開始時刻を引くことで求めることが可能です。

*4.クリティカルパス*
**クリティカルパスとは、プロジェクトのなかで、最も長い工程の経路のことを指します。**クリティカルパスの各工程にかかる所要時間の合計が、納期予定日と同じになります。つまり、余裕時間がゼロの工程を結んでいったものがクリティカルパスとなります。スケジュールの遅れが生じた場合は、そのままプロジェクトの遅延となるため、クリティカルパスは、予定している納期までにプロジェクトを達成できるか、プロジェクトの実行可能性を検討するために用いることが多いでしょう。
またクリティカルパスは、プロジェクトに対して1つのみとは限らず複数存在する場合もあります。さらに、クリティカルパスにスケジュール遅延が生じないようにするために、リソースの配分などについても検討することや対策を練ることが必要です。

これまでにPERT図の詳細について解説してきました。ここからは、PERT図を作成する方法を順番に紹介しましょう。なお、今回は「アローダイアグラム」を基に例を挙げます。

*1.PERT図を作成する対象を決める*
まずは、PERT図を作成する対象を決めることが大切です。プロジェクト単位なのか、さらに細かく分けた工程単位なのかを定めましょう。対象を決めないと次のステップに進むことができません。

*2.必要な業務を把握する*
PERT図を作成する対象を決めたら、定めた対象に対する必要な業務を洗い出し、それぞれの業務に対して必要な時間の設定を行います。この時、作成者の視点ではなく、一般的にかかる時間を設定するようにします。また、「Microsoft社」の「PowerPoint」や「Excel」、PERT図作成用のツールを利用すると、必要な業務を把握するのが簡単になるのでおすすめです。PERT図作成用のツールの代表として「Lucidchart」があります。「Lucidchart」は豊富なテンプレートやオンライン機能を備えているため、効率よくPERT図を作成することができるでしょう。

*3.業務の流れを整理する*
必要な業務を把握できたら、業務の流れを整理します。各工程を矢印で結び、図式化を行っていきます。矢印には、各工程にかかる所要時間を併せて書いておくようにしましょう。

*4.最早開始時刻と最遅完了時刻を計算する*
業務の流れまで整理ができたら、各工程で取り掛かることのできる時間を計算します。たとえば、最早開始時刻を計算する場合は、一般的に左の工程から順番に足していきます。次に、各業務にかけることのできる時間を計算します。最遅完了時刻を計算する場合は、最早開始時刻とは反対で、右の工程から順番に引いていきます。ここまでできれば、PERT図は完成できるでしょう。

*5.クリティカルパスの把握*
最後に、PERT図が完成できたらクリティカルパスを把握しましょう。前項でも説明しましたが、クリティカルパスとは、プロジェクトのなかで最も長い工程を指します。また同時に、クリティカルパスはそのプロジェクトや工程の最短日数とも言えるでしょう。クリティカルパスは時間的に余裕のない業務であり、遅延が生じるとプロジェクト全体が遅れてしまうので、プロジェクトマネージャーはクリティカルパスを正確に把握し、スケジュール管理に注意しておく必要があります。

これまでにPERT図の詳細や作成方法について紹介してきました。ここからはPERT図を採用するメリットについて3点解説しましょう。

### 経験のみに頼らず必要な工程の依存関係や所要時間を確認できる

PERT図を活用することができれば、経験のみに頼らず、プロジェクトにおける工程の依存関係や所要時間の管理について正確に把握できます。PERT図が普及するまでは、プロジェクトマネジャーの経験によって工程の管理は行われてきました。そのため、経験値が低いプロジェクトマネージャーでは工程の管理に失敗してしまうことが多い状況でした。たとえば、 プロジェクト全体から見ると優先度の低いような目の前にあるタスクに気を取られてしまい、プロジェクトを完了することができなかったという事例もありました。しかし、**PERT図を活用すれば、各工程の進め方や所要時間、依存関係について整理できるため、経験がまだ浅いプロジェクトマネージャーであっても、プロジェクトの工程管理が適切にできるでしょう。**

### プロジェクト完了までの最短のスケジュールを知ることができる

プロジェクトは納期予定日が決まっていることが多いため、効率的に作業を行い、納期に間に合わせることが大切です。PERT図を活用すれば、作業の優先順位や進め方について把握することができるため、プロジェクト完了までの最短のスケジュールを計画できるようになるでしょう。それだけでなく、クリティカルパスを理解することにより、工程における作業時間の短縮も期待できます。

### プロジェクトにおけるメンバー間で情報共有をスムーズに行うことができる

プロジェクトが大規模になると、規模の大きさに比例して関与する関係者も多くなっていきます。多くの方と情報共有を行うのは時間や労力が必要です。しかし、**PERT図を活用すれば、プロジェクトの流れをわかりやすく関係者に示すことができるため、作業や工程の進め方が明確となり、業務を滞りなく進めていくことができるでしょう。**

## PERT図を活用する際には作業の漏れや時間の見積りに注意！

当記事では、PERT図の詳細や作成方法、メリットについて紹介してきました。PERT図を用いることで、プロジェクトの各工程の進め方や所要時間、依存関係について整理できるため、業務を滞りなく進めていくことができます。また、プロジェクトの流れをわかりやすく関係者に示すことができるため、プロジェクトにおけるメンバーの間で情報共有もスムーズに行うことができるでしょう。

一方、PERT図では事前に計画した作業工程の情報やそれに費やす時間の見積りを頼りに作成していくため、仮にこれらの情報に間違いがある場合、作成したPERT図は現実との乖離を起こしてしまい、役に立たないものになってしまう可能性があります。

そのため特に、**新しいプロジェクトに携わる場合は、作業日数について慎重に見積もることが重要でしょう。**最後に、PERT図を作成した後は、工程の順番や関係性に誤りがないかを再度確認を行うことで間違いがないようにしましょう。

PERT図とは、業務の流れや所要時間を図式化し、大規模や複雑な業務のスケジュール管理するために用いられる手法です。当記事では、PERT図の目的、種類、構成要素、アローダイアグラムを用いたPERT図の作成方法、PERT図のメリットを解説します。

PERT図とは、業務の流れや所要時間を図式化し、大規模かつ複雑な業務のスケジュールを管理するための手法！

PERT図は、プロジェクトの必要工程や必要日数を把握するために用いられる！

新しいプロジェクトに携わる場合は、作業日数について慎重に見積もることが重要！

PERT図とは？目的・種類・構成要素・作成方法とメリットを解説！


Javaプログラマーの方ならよくご存と思いますが、**JUnitはJavaで作られたプログラムのユニット(単体)テストで使われるフレームワーク(ソフトウェア)です。**JUnitの読み方ですが、”ジェイユニット”と称しますので、覚えておきましょう。

Java自体はWebアプリや大規模開発でも用いられるメジャーな開発言語であり、ITエンジニアを目指す人には*習得しておきたい言語*といえるでしょう。

Javaプログラマーになると、自ら記述したコード(プログラム)が正しく動作するか否かのユニットテスト(単体テスト)をしますが、ユニットテストをするためには*テストコード*というものを記述しなければなりません。これがかなり面倒な作業で、プログラムの生産性を損なうことさえあります。

**JUnitはJavaで書かれたプログラムのユニットテストを自動的に行ってくれる大変便利なツールです。**Javaプログラマーを目指す人にとっては、Javaと同じく習得すべきフレームワークの1つです。

単体テストという言葉が出てきましたので、単体テストについて一度整理しておきましょう。**単体テストはユニットテストとも呼ばれ、プログラムが必要な要件通りに動く(機能する)かどうかを確認するために、プログラミングの後に最初に行われるテストのことです。**

単体テストは基本的にプログラマー自身の手で行われますが、大きな組織では*QA*と呼ばれる品質管理専門のエンジニアによって行われる場合もあります。単体テストの次は、プログラム間の連続テストである*結合テスト*、次に完成したシステム全体の*総合テスト*があります。

単体テストで合格となっても、結合テストや総合テストでエラーが発生し、プログラムの修正を迫られ、単体テストを再度行うこともあります。

**Javaなどのユニット(単体)テストを行う場合は、プログラマーがテストコードを生成します。**テストコードは、*自分が書いたコード(プログラム)が想定した通りに動作するかを確認するために作成*するものです。この単体テストを通過して初めて、プログラムが作成出来たことになります。

例えば「あるメソッド(オプジェクト志向言語における操作を定義したもの)で、2つの引数の値を足して結果を返す」という機能を作ったとすると、「1と2を足したら結果が3になる」ことを確認するのがテストコードです。

ITエンジニアにとっては大変身近な存在であるJavaについて触れておきましょう。**JUnitを語る上ではJavaの理解が必要になります。**ここではJavaの概要に加えて、JavaScriptとJavaの関係についても触れておきましょう。

JavaはITに関わる人であれば、誰もが知る汎用プログラム言語です。**仮想マシン上で動作するため、WindowsやMacOS、LinuxなどのOSを選ばず、どんなマシンでも動くのが特徴です。**

JavaはWebプログラムとしてもよく使われておりTwitterのWebサービスもJavaを利用して作られています。他、スマホアプリ、家電、カーナビなど、あらゆるものでJavaは活躍しています。

**プログラム言語としてもJavaの人気は高く、さまざまな調査で常にランキングトップにあり、エンジニアを目指す人にとってJavaは必須プログラム言語とも言えます。**

時代は1990年代に遡ります。当時のアメリカでは「*ワークステーション*」と呼ばれるコンピュータが市場を席捲していましたが、その「*ワークステーション*」を開発したのが「Sun Microsystems」です。実はJavaはこの「Sun Microsystems」で作られました。

彼らが目指したのは、**ハードウェアに依存しない「ソフトウェア開発プロセスの仕組み」**でした。Javaはプログラミング言語だけに留まらず、プログラムの実行環境まで包含していました。

当初は家電製品への組み込みからスタートしたJavaでしたが、当時脚光を浴び始めたインターネットに照準を当てたことから大きな発展を遂げたのです。

*Java*は最初、*Oak*という名前でスタートしていますが、*Oak*が他社で商標として使用されていたことが判明し、*「Java」*に改名されました。

Javaの名前の由来には諸説ありますが、Javaの開発者たちがよく利用していたコーヒーショップで提供されていたコーヒーの名前から取ったという説が濃厚です。

こうして「Java」は1996年に「Java1.0」としてスタートし、1999年にはソフトウェア開発業者向けの「*Java SE*」、サービス提供事業者向けの「*Java EE*」、デバイス事業者向けの「*Java ME*」の3パターンで再構築されました。

その後も順調にJavaはユーザーを獲得し続け、ITのスタンダード言語として定着していきます。その後2010年にJavaを開発した「Sun Microsystems」はOracle社に買収され、JavaはOracle社の主力製品の1つとしてさらに進化を続けています。

Javaと言えば、JavaScriptをイメージする人もいるようですが、*JavaとJavaScriptは全く別物*です。名前が似ているので、両者を同一視する人が後を絶ちませんが、食べ物にたとえるとメロンとメロンパンくらいの違いがあります。

**JavaScriptはJavaの弱点を補う言語**と言えるでしょう。**Javaはありとあらゆるマシンで動作しますが、画面に動きをつけるのがあまり得意ではありません。一方、JavaScriptは対話型で、細かい動きを求められるような機能に適しています。**そんなことから、**Javaは裏方で動き、ユーザーの目に触れる表舞台はJavaScriptというような役割分担**になっています。

実際にJavaは業務アプリやTwitterのようなWebサービス、スマートフォンアプリ(Android）開発などによく使われ、一方の**JavaScriptはWebブラウザ上で動きを付けたり、色を変えたり、ポップアップ表示をさせたりするようなWebページの開発に主に使われています。**

では、なぜ名前が似ているのでしょう。それは後発の*JavaScriptがJava人気にあやかってネーミング*されたからなのです。そこはエンジニアとしては押さえておきましょう。


### JUnitは両方の単体テストができる？

少し横道にそれましたが、JUnitに話を戻しましょう。JUnitはJavaプログラム向けのユニットテストツールでしたね。では、Javaとは別言語であるJavaScriptにはJavaScript用のテストツールがあるのでしょうか？

答えはYESです。*Jest*というテストツールがあります。他にもJasmineやMochaなどのツールがありますが、今のところ*Jest*が主流です。

では、JUnitでJavaScriptのテストはできないのでしょうか？その答えは、NOです。**実はJUnitはJavaScriptにも対応しています。**

というのも、*Java自体にJavaScriptエンジンが組み込まれている*ので、JUnitはJavaScriptで組まれたコードのユニットテストも出来ます。いずれにしても、**JavaとJavaScriptは別言語でありながら、表裏一体的な関係でもあり、Javaを習得したエンジニアの方はJavaScriptも覚えておくと良いでしょう。**

**JUnitで作成したテストコードは自動実行が可能であり、しかも実行時にエラーが発生した際は、エラーの箇所や状態が即座に分かり、テストの負担を大きく軽減できます。**

また前に行ったテストを再度実行することが可能なため、デグレード(性能・品質の悪化)を検知するためのリグレッションテスト（退行テスト）の自動化、やリファクタリング(内部構造の改善)実施も容易になります。これらを整理すると以下の通りです。

*▪ユニットテストを行うためのテストコードを簡単に生成できる*
*▪作成したテストコードを用いて迅速にユニットテストができる*
*▪テストコードを標本としてバグの訂正が容易となる*
*▪テストコードを見ると仕様が一目で分かる*
*▪誰もが同じテストを実施できるようになる*
*▪独自にテストコードを作成する手間が省ける*

そんなJUnitもメリットばかりではありません。例えば、JUnitで行うテストはユニットの独立性が前提で、**テストするユニットが他のユニットとの間に依存関係がある場合、テストの実行順序を定義する必要があり、そのための時間が余分に掛かってしまいます。**

他、プログラムのイレギュラー処理が正しく機能するかのテストでは、テストコードがかなり複雑になるため、**テスト作成者がテストコードにある程度精通している必要があります。**

JUnitには上記のようなデメリットもありますが、基本的に**JUnitは活用する対象を厳選して継続的に修正を行っていけば、高い効果が得られるツールであり、大きな開発プロジェクトになるほどそのメリットを発揮します。**以下、デメリットとその対処法を列挙しておきます。

*▪仕様変更する度にテストコードの作り直しが発生する*
　→解決法として、*EclipseなどのIDE(統合開発環境)を使う*と、テストコードを作り直す手間を軽減できます。

*▪テストコードの作成に時間を要する*
　→同様にEclipseなどのIDE(統合開発環境)を使うとテストコードの作成をスピードアップできます。

## アジャイル開発におけるテスト

Javaは大規模開発でもよく利用されますが、これまでの大規模システム開発においては、ウォーターフォール型開発が一般的でした。しかし近年はアジャイル型開発手法を採用するケースが増えています。

**アジャイル開発では、テストコードとプログラムコードを同時並行で書いていくことになり、テストを効率良く進めるツールとして「テスティングフレームワーク」を利用しますが、その1つがJUnitです。**


### アジャイル開発におけるTDD

**テスト駆動開発(TDD)という概念があります。これはテストに重きを置いた開発手法です。**ウォーターフォール型開発では、きっちりと手順を踏んで開発を進めるため、テスト工程は必須になっています。

エンジニアとしては、自分が担当したプログラムやシステムからバグを完全に排除したいと考えます。しかも、システムの出来栄えが仕様通りか否かが評価要素となります。

一方、近年より主流になっている**アジャイル開発では、「とりあえずやってみよう」の考え方で、スピード開発に重きを置きます。**ユーザー志向で、柔軟に対応をしていきます。このアジャイル開発とウォーターフォール型のTDDに、相容れない面があるのは事実です。


ここまでテストコードを自動生成してくれるJUnitについて考察してきました。しかし、果たしてテストコードは必要なのでしょうか？

確かに、テストコードはあるに越したことはありません。しかし、テストコードの生成が自動化され、バグ潰しは軽減できますが、**テストの目的はバグ潰しだけではありません。**

例えば、100人が操作して1回エラー画面が出るのと、100人が操作して5人が離脱するような不親切なUI(ユーザーインターフェース)があったとしたら、どちらがユーザーから支持されるかか、ということです。

**「テストのカバレッジが高い=ソースコードの品質が高い」とはなりません。品質の最終判断はユーザーの評価です。**

*アジャイル開発の時代においてはソフトウェアの品質基準が従来とは変わってきている*ということです。Javaプログラマーを目指す方はぜひJUnitを学んでください。しかし、JUnitを絶対に使わなくてはならないということではありません。使う方が良い局面では使えばよいのです。

これからエンジニアを目指す方は、画一的な思考に陥ることなく、ユーザーやクライアントの視点で何を優先すべきかということを常に考えていただきたいと願っています。

Javaブログラムのユニットテスト(単体テスト)に欠かせない、テストコード自動生成ツールのJUnitはITエンジニアやJavaプログラマーにとって必修ツールと言われています。このJUnitとは何なのか、そのメリット・デメリット、アジャイル開発における必要性などについて解説します。

JUnitはJavaのユニットテスト(単体テスト)で欠かせないツール、エンジニアを目指す人は習得しよう

JUnitにはデメリットもあり、その対策をしっかり講じた上で利用しよう

アジャイル開発においてユニットテストは必須ではない。ユーザー目線でプログラミングしよう

ITエンジニアやJavaプログラマーを目指す人に必須のJUnitってなに？

FP法とはファンクションポイント法の略で、1979年に米国IBMのAllan Albrecht氏により考案されました。FP法の目的は*誰が見積もりの計測を行っても同じ結果*が得られ、見積もり作業のばらつきを抑えることです。

そのため、ソフトウェア開発の生産性を測定するためのユーザー要件を、ファンクションとして定義しカテゴリー化することで、**見積もりの平準化**を行います。

FP法ではシステムの機能をファンクションと呼び、そのファンクションごとに点数を定めています。そのため誰が見積もりをしても、*ファンクションの数を数えるだけでシステム規模の見積もりが同等に実施できる*メリットを持っています。

そのファンクションは**システムの実装形式による違いがなく**、従来の*オンプレミス*(所有型)でも*クラウド*(利用型)でも同じスコアとなります。同様に*システム開発の形式*にも依存しないので、*新規開発*でも*パッケージ利用*でも同等の結果となります。

さらに*開発手法*においても、従来型の*ウォータフォールモデル*でも*アジャイル型*でもスコアに差がありません。もちろん、*開発言語*にも依存しません。

### FP法のファンクションの詳細は？

FP法ではファンクションを*データ処理に関するトランザクションファンクション*と、*データ格納に関するデータファンクション*に大別して集計されます。各区分のファンクションごとに点数を定めていますので、点数表に**集計すると合計のスコアが簡単に求められます**。

各機能はそれぞれ*外部入力*(EI)・*外部出力*(EO)・*外部照会*(EQ)・*内部論理ファイル*(ILF)・*外部インターフェイスファイル*(EIF)に分類し算出されます。

FP法のメリットは、誰が算定しても同等の結果が得られることです。そのため*見積もり作業のばらつきを抑える*ことができます。同様に、プロジェクト期間中に仕様変更が生じた場合も*FP数が変わることを指標として算定できます*ので、要件変動による影響をあらかじめ可視化することが可能となります。

また、求める*品質評価の目標値をFP法で設定する*ことにより、**品質の評価がより簡単に実施できる**メリットがあります。

FP法は工数の見積もりだけでなく、*プロジェクトサイクル全般で活用できます*。具体的には見積もりやその評価、工数管理・品質管理や進捗管理、ベンダーの評価や運用評価、ソフトウェア資産管理や投資対効果の評価等**多岐に渡ります**。

*大規模なプロジェクト*では、ソフトウェア開発に着手するまでにシステム戦略策定からシステム化計画、そして要件定義・設計・開発と多くのフェーズを経由します。

特に、先行して検討されるシステム戦略策定時には、システム化の方向性を決定するために多くの要求事項が挙げられるため、実際に*システム開発で必要とする部分とのズレやブレが発生*します。そのため、*見積もり誤差がリスク分として多く計上*されてしまいます。

そのリスク分は不確実性によるもので経験値によるところが大きい領域です。特に未確定の要求仕様については累積してリスク計上されていきますので、システムが肥大化する要因となります。

これを防ぐために、同様の要求を満たすシステム事例を参照したり、プロジェクトサイクル全般を想定した見積もり手法が必要となります。FP法では*早期から実装機能をファンクションとして算定できます*ので**ブレを吸収し実装していくことがてきます**。

FP法では機能要件を低・中・高の複雑度の分類で算定するため、対象とする*アプリケーション開発の工数とソフトウェア製造量*と直接的に*合致しない場合もあります*。そのため、あらかじめ同等の業務での*開発実績のデータを蓄積し、見積もり制度を向上させる*ことが重要となります。

特に要求仕様書が確定する前の見積もりでは精度のブレが生じますので、ユーザが認識していない要件が潜んでいる場合は**別途追加見積の必要性**が出てきます。

FP法は*国際標準化機構ISO*(International Organization for Standardization)および*国際電気標準会議IEC*(International Electrotechnical Commission)によって認定されています。その標準化の中でFP法は、以下のそれぞれの方法が**各実装グループによって定義**されています。

・*FiSMA*(FiSMA 1.1 functional size measurement method)
・*IFPUG*(IFPUG functional size measurement method)
・*Mark-II*(Ml II Function Point Analysis)
・*Nesma*(Nesma functional size measurement method)
・*COSMIC*(The Common Software Measurement International Consortium)
・*OMG*(Object Management Group Automated Function Points)

*IFPUG*(International Function Point User Group)は米国にあり、Allan Albrecht氏の考え方を引き継いでFP法を発展させています。その*ガイドラインはISOで標準化*されています。海外支部も多くあり、**日本ではJFPUG**(Japan Function Point User Group)として活動を行っています。
参考：[IFPUG](http://www.ifpug.org/)
参考：[JFPUG](http://www.jfpug.gr.jp/introduction/top.htm)

### その他のソフトウェア開発見積もりモデルは？

*■COCOMO*
*COCOMO*(Constructive Cost Model)は1981年に提唱されたものです。COCOMOでは、開発するソフトウェアの規模が大きいほどより多くの工数が発生するという考え方に基づいています。具体的には、開発するソフトウェアの想定ソースコード行数に、ソフトウェアの規模を表す係数を掛けて開発工数を算定します。

*■LOC*
次に*LOC*(Lines Of Code)について紹介していきます。LOCは長年にわたり見積もりに用いられていた手法で*ステップ数による見積もり*と言えばピンとくる人も多いでしょう。つまりプログラムソースの行数に比例して工数を求めるものです。

こちらは長きにわたり利用されていますが、空行やコメント行を除外したりする作業の誤差や、難易度がステップ数に反映されないので*誤差のブレ幅が大きい*ものです。そのため、大規模システムでは**客観的な指標としては適さない**とされています。

## FP法のスキルを高めるには？

FP法は*プロジェクト開発では標準的に活用*されています。そのため、実際のプロジェクトで実務能力を高めることが可能です。

それ以外にも市販の書籍が数多く出版されていますし、ITエンジニアのプロジェクト教育としてeラーニングが各社より提供されています。したがって最初のステップとしては**机上で知識を高めて実践する**ことをお勧めします。

先に述べた*IFPUG*並びに*JFPUG*より、FP法に関連する*ドキュメントを入手すること*ができます。その他、情報処理推進機構(IPA)により2006年「*ソフトウェア開発見積りガイドブック*」が発行されています。**各種見積もり手法の紹介と実例**が記載されており、PDF形式で*ダウンロードが可能*となっています。
参考：[情報処理推進機構(IPA) ソフトウェア開発見積りガイドブック](http://www.ipa.go.jp/sec/publish/tn05-001.html)

### FP法による実際の調達知識は？

平成26年において総務省より「*政府情報システムの整備及び管理に関する標準ガイドライン*」が発行されています。事業者からの経費の見積もりは、原則として*ファンクションポイントの見積もり並びにその見積もり根拠*を**提示すること**が求められています。*政府系システムに関連する方*は一読されることをお勧めします。
参考：[政府情報システムの整備及び管理に関する標準ガイドライン](http://www.soumu.go.jp/main_content/000353305.pdf)

## FP法をマスターしてプロジェクトでの見積もり手法をマスターしよう

FP法はプロジェクトの*見積もり手法として広く浸透しています*。FP法が効果的なのは要求仕様書が確定してからの各工程ですから、まずは市販の書籍やeラーニング等で学習し、実際の*プロジェクトで実践してみましょう*。

FP法はプロジェクトでの*ソフトウェア開発の品質評価に活用可能*ですから、**全体のレビューや費用対効果の評価にも活用できます**。ぜひとも色々なプロジェクト工程で活用いただくことを期待しています。

FP法は米国で考案され、40年以上の活用実績がある手法です。その目的は誰が見積もりの計測を行っても同じ結果が得られることです。FP法を効果的に活用することでプロジェクトの見積もり品質が高められます。ぜひ実際のプロジェクトで実践してみましょう。

FP法は米国で考案されたソフトウェア開発の生産性を測定するための手法です

FP法ではシステム規模の見積もりが誰でも同等に実施できるため広く用いられています

FP法は工数の見積もりだけでなく、プロジェクトサイクル全般の評価として活用可能です

FP法とは？ソフトウェア開発の見積もり手法を解説します！

EVMとは｢Earned Value Management(アーンド・バリュー・マネジメント)｣の略語で、**プロジェクトにおける計画、作業工程、成果物などを全てコストに換算し、｢計画(予算)｣と「実績｣、｢要したコスト｣を比較して、｢どの程度進んだのか｣｢費用はいくら掛かったのか｣を把握するための手法**です。

これらを分析することで、**プロシェクトの進捗状況を把握し、将来的に発生する可能性のある問題を予め察知**します。このようにEVMはコストの視点を取り入れたプロジェクト管理の有効な手法のひとつです。

EVMは元々、米国総務省における物資調達規則の一部として制定されたのが始まりです。その後、国家的なプロジェクトのパフォーマンスを上げるために何度も見直しが行われ、発展を繰り返しています。

**EVMの大きな特徴は、従来のプロジェクト進捗管理においてはメジャーな指標だった時間軸だけではなく、コスト指標を取り入れた点です。**日本においては、経済産業省において*EVMに関するガイドライン策定の動き*があり、今後政府案件では、受注条件に「EVM」を用いた管理の採用を含めるべきとの意見もあります。

### これまで利用されることが多かったのは、PERT図とWBSという手法

これまでIT開発のプロジェクトでは、プロジェクト管理に*PERT図*や*WBS*がよく利用されていました。これらは時間軸（スケジュール）でプロジェクトを管理する手法です。

*PERT図*は、なじみのある方が多いと思いますが、プロジェクトの流れや所要時間を図に表し、業務計画を立てます。

 複数の作業が並行して行われるプロジェクトでは、1つの作業が遅れると他方の作業が遅れ、結果として全体が遅れます。このように、*各作業間の依存関係や重要性がよく分かり、進捗管理がしやすいというメリット*があります。

一方で*WBS*も、よく用いられる手法なのでご存知の方が多いと思いますが、プロジェクトの目的達成に必要なタスクを洗い出し、各タスク毎のスケジュールを明確にします。*各タスクの工数も見積もるため、全体工数が把握でき、進捗管理がやりやすくなるというメリット*があります。

**いずれも進捗管理の指標は時間です。それらに対し、コストとスケジュールの両面から管理するのがEVMです。**

あなたが仮にプロジェクトリーダーを任され、EVMを用いたプロジェクト管理を行うことになったとしましょう。プロジェクトメンバーには、EVMについて説明をしなければなりません。

しかも簡潔に、分かりやすく説明をしなければ、メンバーはあなたに従わないかもしれません。かといって、勉強会を開くほどの時間もありません。そんな時は次のような説明してみてください。

**「EVMはプロジェクト管理の手法で、すべてをコストに換算し、計画に対して進捗をコストで管理するやり方です」**と。

では続いてEVMに対する理解を深めるため、EVMを採用するメリット、デメリットについて考えてみましょう。

## EVMのメリット・デメリットについて

経済産業省によるガイドライン策定を筆頭に、日本国内において導入しようという動きが高まっているEVMですが、メリットだけではなく、もちろんデメリットも存在します。

ここでは、そんなEVMのメリットとデメリットを解説します。

前述の通り、EVMはコストによる管理を取り入れたプロジェクト管理手法です。それを踏まえたうえで、次の2点が*メリット*として挙げられます。

*1.プロジェクト管理をより客観的に管理ができる*
従来のプロジェクト管理手法はあくまでもスケジュール面の進捗管理が主であり、「計画に対して遅れている」「計画よりも早く進捗している」という点でしか、進捗が把握できませんでした。

**EVMにはコスト指標が加わり、コストマネジメントの要素が入ることで、より客観的、合理的な判断や意思決定を促す**ことができます。

*2.プロジェクトの予測精度が高まる*
プロジェクト管理に**コスト指標が加わったことで、将来予測の精度が高まります。**例えば、プロジェクトの折り返し地点で、スケジュール進捗率が50%、予算進捗率が50%なら、プロジェクトは予定納期と予定コスト内で収まる可能性が高いことが分かります。

仮に予算進捗率がスケジュール進捗率を上回っている場合は、コスト圧縮策を講じる必要が出てきます。逆に予算進捗率がスケジュール進捗率を下回っている場合は、さらなるリソース確保が可能と判断され、*いずれにしても早めの対策を打つことができます。*

一見、万能に思えるEVMですが、次のような*デメリット*を抱えており、プロジェクトの前に何らかの補完策を講じておく必要があります。

*1.品質コントロール機能がない*
EVMにはコストとスケジュール以外の指標がなく、**品質を管理するためには別の管理手法を追加する必要**があります。

*2.クリティカルパスが不明確*
プロジェクトの工程にはクリティカルな工程があります。この工程を他の工程と同様にコストだけで管理すると、その工程で問題が発生した際に、他の工程や全体工程に影響を及ぼす可能性があります。

**クリティカルパスはプロジェクト管理の基本ですので、必ずこの管理手法を除外しないよう気を付ける必要**があります。

ここまでで、EVMの概念はある程度理解されたかと思います。続いて、*EVMの構成要素*について触れておきます。次の(a)から(e)まで、5つの構成要素(指標)は頭に入れておいてください。

### (a). PV (Planned Value)－計画価値

**計画作成段階で見積もった予算**を意味し、ある期限までに完了しなければならない作業に対する総予算・総コストのことです。たとえば「〇〇ツールの開発にあたり、1カ月間に必要な予算はいくらか」という視点で、主に開発要員のコストを推定して算出することです。

1カ月間に人件費が50万円/月の初級プログラマーを投入する計画であれば、PVは50万円です。50万円が基準値(ベースライン)となり、60万円/月の中級プログラマーを投入した場合は、10万円のコストオーバーが発生し、この10万円が基準値からの*遅れ*と判断されます。

### (b).AC (Actual Cost)－実際に要したコスト

**ACは実コストのことで、ある時点から特定の時点までに要したコストのこと**です。

例えば「〇〇ツールの開発にあたり、1カ月で実際にかかったコストは60万円」というようにACを用いて表現します。

### (c).EV (Earned Value)－出来高実績値

**EVMのEVのことで、｢出来高実績値｣とも訳されます。**作業の達成度を時間で判断するのではなく、金銭的価値に置き換えて判断します。

AC(実際に要したコスト)に対するEV(出来高実績値)の比率を*CPI(Cost Performance Index)*と称します。CPIは「コスト効率指数」という指標で、*『EV ÷ AC = CPI』*の算式で表され、1を下回るとコスト超過と判断します。プロジェクト進行管理で、コストが予算内に収まっているか否かを判断する際に用います。

### (d).SV (Schedule Variance)－スケジュール差異

**SVはスケジュール差異を示します。EV(出来高実績値)と、PV(計画価値)の差分です。**

*『EV ‐ PV = SV』*の算式で表され、結果がプラスなら、オン・スケジュールと判断し、結果がマイナスならスケジュール遅延と見なします。

 例えば、「〇〇ツールの開発」にあたり、2カ月目までのEV(出来高実績値)が80万円、2カ月目までのPV(計画価値)が70万円なら*『EV(80万円）－PV(70万円） = SV(10万円）』*で、スケジュールは計画よりも早く進んでいると判断できます。

### (e).CV (Cost Variance)－コスト差異

**CVはコスト差異を示します。AC(実際に要したコスト)と、EV(出来高実績値)との差分です。**

*『EV－AC = CV』*の算式で表され、結果がプラスなら、その時点でのコストは予算内、マイナスの場合は予算オーバーと判断できます。

例えば、「〇〇ツールにあたり」、2カ月目までのEV(出来高実績値)が70万円、2カ月目までにのAC(実際に要したコスト)が90万円なら、*『EV（70万円）－AC(90万円）= CV(－20万円）』*となり、予算オーバーと判断します。

以上5項目がEVMの基本的な指標です。EVMに対するイメージが明確になったのではないでしょうか?まずはプロジェクト管理でこの5つの指標を実際に用いてみることをおすすめします。

従来型のIT開発プロジェクトにおいて、主に重きを置かれたのはスケジュールでした。納期厳守のためにSEやPGの徹夜を黙認するような風潮すらありました。この結果、**プロジェクトが終了してから、予算オーバーが発覚するという事態が常態化**してきました。

これは、日本のIT開発の生産性が高まらない1つの原因と見られています。*EVMがそのスケジュール偏重のプロジェクト管理を打破する1つの手段*です。

EVMと聞くと、何か難しいことのように感じますが、この記事をお読みになられた方は意外に簡単だということを理解されたと思います。

**EVMでは、EV(出来高実績)、PV(計画価値)、AC(実コスト)の各指標について縦軸をコスト、横軸を期間とするグラフで、3本の曲線で表します。**

このグラフを基にして、*リソースの使用状況が明瞭になり、完成時点の数値まで見積もることができます。*EVMの管理をする上で、このグラフを用いることで「予算に対して、消費したコストは下回っているのか、上回っているのか?」、「使用したコストに対して、成果は上回っているのか、下回っているのか?」が一目瞭然となり、**プロジェクト内の情報共有や上層部への進捗報告にも有効なツール**になるでしょう。

**EVMは計画と実績の見える化**です。各指標は数字で表さなければなりません。数値化するには*人的資源能力*や*品質出来高*をいかに定量的に把握するかによって、精度が変わってきます。まずはこれらの指標の客観的根拠をしっかり形成することが求められます。

*正しい人事評価制度、品質評価の仕組みが必要*になります。関係者で知恵を出し合って、皆が納得し得る基準を設けることで、プロジェクト管理の精度はさらに高まり、メンバーのモチベーションアップにもつながるでしょう。

記事をお読みいただいた皆さんがEVMを更に理解し、自身の関わるプロジェクトに採用されることを願っています。

IT開発のプロジェクト進捗管理に有効と言われるEVM(Earned Value Management)は、PMやSEにとって体得しておくべき管理手法の1つです。ここでは、そんなEVMの概要、メリット・デメリット、構成要素、EVM活用法などを解説します。

EVMは、従来型のスケジュール視点にコスト管理の視点を加えた、プロジェクト管理の手法

EVMには品質管理の視点が不足しており、EVMだけでプロジェクトを管理するのには限界がある

PMやSEはEVMを体得し、スキルアップやキャリアアップにつなげられる

PMやSEに必須のプロジェクト・マネジメント手法のEVMについて理解しよう

## DFDの特徴（概要、メリット・デメリット、要素など）を解説

DFDについて、SE(システムエンジニア)やPM(プロジェクトマネージャー)の方、システム開発を勉強中の方はよくご存じだと思います。この記事では、SEを目指しているプログラマーや他の職種の方を対象に解説していきますので、ご存知のところは読み飛ばしてください。

**DFD（Data Flow Diagramの略称）は、システムの中でデータの流れ(flow)を表現するための図です。要件定義フェイズなど、システム設計の初期段階で作成されるのが一般的です。**

DFDは、システムにおける入力(input)と出力(output)が何であるか、またデータの出所、発生元や出力先、データの保管場所などを示します。**DFDでは処理のタイミングを示すものではありませんし、順序も関係ありません。**

同じ用途で使用するツールとしてはフローチャートなどがあります。また、DFDは依存関係を示しますので、相互依存関係がない処理については並列、並行性を表現します。

DFDでは、**「システム機能」と「データ」の流れを表す図**ですが、DFDには次のような*目的*があります。
*▪関係者でシステムイメージを確認し共有する*
*▪既存システムを整理して、全体像を把握する*
*▪機能の漏れや重複がないように機能を整理する*
*▪処理(プロセス)を詳細化していく*

では続いて、DFDの*メリット*と*デメリット*について見ていきましょう。

DFDではシステム構成要素を分割し、図形でデータの流れを記述するため、**「あいまい」な部分を排除ができ、さらにシステムの「抜け」を防ぐ**ことができます。

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

**データベース設計との関係を見るとすれば、データストア（ファイルやデータベース）がエンティティ候補**になります。また、データの発生元や入力元・出力先（外部実体）もエンティティの候補となります。

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

*b.コントロールフローの表現が難しい*
DFDの要素として、**「条件分岐」などのコントロールフローのマッピングが難しい**ため、記述されないことが多いのですが、要素としては追加していくことが必要と思われます。

**DFDの作成に際しては、**「データフロー(流れ)」「データストア(データベース)」「プロセス(処理)」「外部エンティティ」の4つの要素があります。**非常にシンプルなので、ユーザーにも分かりやすいのが特徴です。下にDFDの4つの要素について表にしましたので、確認してみてください。

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

Excelのセルを方眼紙のように使い、Excelに標準で実装されている図形を使います。文字はテキストボックスを利用して記載します。

一度作ってしまえば、それをテンプレートにして簡単に作成できるようになります。多くのSEの方はExcelを用いてDFDを作成されていますので、ぜひお試しください。

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

**たとえば、受発注在庫管理システムをDFDで表すと、以下のような図になります。ここでは外部エンティティは顧客と物流倉庫です。インプットは商品注文データで、アウトプットは顧客に届けられる商品です。

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

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

お役立ち記事