システム開発の初期段階では必ず登場する**「要件定義」は、その出来栄えがプロジェクトの成否を大きく左右する**と言われるほど重要な工程です。プロジェクトの工期遅延の原因の55%が要件定義のミスから生じているという調査結果もあるほどです。

ここでは、要件定義とは何か・要件定義で行うべきこと・その作成までの流れ・重要なポイント・書き方などについて解説していきます。

*【参考】：[失敗しない要件定義とリスク対策（IPA）](https://www.ipa.go.jp/files/000057381.pdf)*

### ユーザーの要求に対する解決策を明らかにする

要件定義のインプットは「ユーザー（クライアント）の要求や要望」です。アウトプットは「ユーザー（クライアント）の要求や要望に対する解決策である要件定義書」です。

システム開発のゴールは、ユーザー側の要求を実現することであり、そのためのシステム開発において、ユーザーの要求に応えるために実装する機能や性能の要件を定め、それらを具体的にどう進めるのかを決定します。ゴールが明確になっていないと、解決法は定まらず、プロジェクト計画も立てられません。

**ゴールの認識やベクトルがユーザー（クライアント）側と開発側で一致していることが、プロジェクトの成功に欠かせません**。

このゴールイメージに食い違いがあると、プロジェクトが失敗する確率が高まります。どんなに精緻で、どんなに素晴らしいプロジェクト計画が作れても、ゴールの認識が異なれば、出来上がったシステムはユーザー（クライアント）に評価はされません。わかりやすくまとめると、*「要件定義はユーザーの要求に対する解決策」*と言えるでしょう。

### 要件定義の目的はユーザーの合意を得ること

要件定義は何のために行うのでしょうか？それは、ユーザー（クライアント）の要求をシステム化の要件として整理し、開発側とユーザー（クライアント）双方の合意をとるためです。特に受託開発においては、この「合意をとる」ということが非常に重要です。

システム開発プロジェクトで炎上するケースでは、両者の合意が取れておらず、出来上がったシステムが「要求したものと違う」とユーザーの怒りを買う場合が少なくありません。こうした事態を避けるには、**要件定義の内容について必ずユーザーの合意、承認を得ておくことが必要**です。

### 要件定義のアウトプットは基本設計のインプット

システム開発の実際のステップはユーザーに対する「システム提案」から始まり「受注」を経て、要件定義からスタートします。「要件定義工程」の次は「基本設計」です。

すなわち、**要件定義のアウトプットは基本設計のインプットになる**ということです。この「要件定義」に手抜きがあると、「基本設計」工程で「基本設計に必要な情報が不足している」という事態を招き、設計フェーズが止まってしまいます。

設計フェーズに正しいインプットを提供するためには、システム開発の視点も欠かしてはなりません。ユーザーとの合意、システム開発視点の両立は簡単なことではありません。この難しいことに立ち向かうのもシステムエンジニアの役割なのです。

システムエンジニア（SE）とは？仕事内容や年収、必要スキルを解説！

要件定義書と仕様書は同じではないかという見方をする人がいます。要求仕様書というものも存在しますので、混同しがちです。

**要件定義書は一般的に、開発側がクライアント（ユーザー）から提示されたRFP「Request for Proposal」（提案依頼書）を元にして作成をします。要求仕様書はクライアント（ユーザー）が開発側（ベンダー）に対して依頼する開発要件を文書化したもの**です。要求仕様書を精査し、要件定義書の要件を満たしている場合は、それを要件定義書として採用する場合もあります。

RFP(提案依頼書)を作成するメリット、デメリットと活用方法について

要件定義を適切に行うことが、システム開発プロジェクト成功のために重要です。**どのような手順で要件定義を行えばよいのか**について解説をしていきましょう。要件定義の流れから紹介していきます。

適切な要件定義を進めるには、きちんと手順を踏むことです。要件定義の正しい手順、基本的な流れについて以下、順を追って解説します。

*1.ユーザー要求についてヒアリングする*
ITベンダーでは、クライアントからRFPの提示を受け、そこからシステム開発案件がスタートするケースが大半です。提案要請を受けた営業担当はシステムエンジニア同行で、改めて詳細のヒアリングを行い、社内に持ち帰って大まかな要件定義に基づく提案書を作成し、クライアントに提示します。

*2.ユーザーの要求を細分化する*
システム開発の受注に至ると、開発側はクライアントにアプローチし、システム化の対象について全体像を把握し、ユーザーヒアリングを通じてユーザー要求の細分化を行い、要件を固めていきます。それらを実際の業務フローに落とし込み、実装する機能に関する洗い出しを行います。

この段階で、ユーザー要求の取りこぼし、業務フローの漏れがないよう十分に配慮をしなければなりません。

*3.要件定義書の作成*
機能要件の細分化ができたら、要件定義書の作成に入ります。要件定義フェーズで作成するそれぞれのドキュメントは、「基本設計フェーズ」のインプットになります。設計フェーズを意識しつつ、ユーザー要求、要件に漏れや齟齬がないよう、クライアント側と開発側の双方が納得し、合意できるよう要件定義書の作成には細心の注意を払います。

RFPとRFIとの違いとは？エンジニアがシステム開発に活用するコツ

### 要件定義で気を付けるべきポイント

要件定義は手順に従って進めることも大切ですが、守るべき重要なポイントがいくつかありますので、ここではそのポイントを挙げていきます。

*1.クライアントの要求は漠然としている*
多くの場合、クライアントは自ら機能レベルに落とし込んだ要求を具体的に示してくれるわけではありません。そのため、要求から必要な機能に落とし込むには、クライアントの漠然とした要望や課題、問題点を開発側で引き出し、具体化することが重要です。

また、要件定義を行う上では、クライアント側の関係する人すべてからヒアリングをする必要があります。従って、要件定義の前提として、全面的な協力を得られることが精度の高い要件定義を行う上で欠かせません。

さらに、要件定義についてはクライアントのIT部門の合意のみで、利用部門の合意を得られていない場合には、最終的に大きな手戻りが発生し、検収をしてもらえないケースが起こり得ます。対象システムのオーナーが誰であるのかを最初に確認し、システムオーナーと要件定義内容について合意をとれるようにしておきましょう。

*2.要件定義はシステムエンジニアが行う*
要件定義のアウトプットは基本設計フェーズのインプットです。基本設計や詳細設計を知らない人に要件定義をさせるのは無理があるでしょう。業務知識は必要ですが、システム開発スキルのない人が要件定義を行うと、システム目線が欠けており、設計フェーズやプログラミングにまで悪影響が及ぶ可能性があります。

**要件定義でミスがあると、大きな手戻りが発生したり、工数の大幅な増加を招いたりする原因となります。**よくありがちなのは、基本設計・詳細設計の経験がない上級SEやコンサルタントに要件定義を任せた結果、技術的裏付けを得ずに理想論に走ってしまい、結果としてプロジェクトが失敗するケースです。

コンサルタントや上級SEが要件定義に参加するのは構いませんが、システムエンジニアのベテランを必ず交えるようにしましょう。

*3.曖昧な記載は厳禁*
要件定義の内容に曖昧な部分があると、その解釈も人によって異なり、結果的に設計ミスをする可能性があります。曖昧な部分は、期限を決めて必ず曖昧さを除去しなければなりません。システム更改のプロジェクトで、よくありがちなのは「〇〇の機能については変更せず、既存システムと同様とする」などと、中身を書かないことです。

既存システムの〇〇機能について、クライアントも開発側も完璧に理解しているならともかく、そうでないならこうした定義は厳禁です。初めての人でも分かるように、変更しない機能であっても曖昧にせず、その機能を明らかにするのも要件定義の重要なポイントです。

*4.必要な機能であること*
要件定義のユーザーヒアリングで、「あったら嬉しい」というレベルの要求が次々と出てくることがあります。ユーザーは「せっかくヒアリングをしてくれているのだから、何でもぶつけてみよう」という気になり、さほど重要ではないことまで挙げてくることが往々にしてあります。

すべての要求に応えると、予算やスケジュールの枠を超えてしまいますので、要求を聞く際には、その必要度合いを確認し、機能要件に優先順位を付けるようにし、最終的に必要な機能に絞れるようにしておきます。

他、「非機能要件」では定義が難しく、特に性能やセキュリティなどについては、実現が困難な目標を定めてしまう、後々開発側の首を絞めることになりかねませんので、実現性の観点から専門分野のエンジニアの参画を求めるとよいでしょう。

ここまで要件定義の流れや、気を付けるべきポイントについて解説しました。ここからは、**要件定義書に記載すべき項目（成果物）**について解説していきます。併せて、「機能要件」と「非機能要件」の違いについても確認しておきます。

*【参考】：[ユーザーのための要件定義ガイド第 2 版（IPA）](https://www.ipa.go.jp/files/000079352.pdf#page=397)*

要件定義書のアウトプットが基本設計のインプットになることから、**要件定義の要はシステムに関する項目**だということは理解できたと思います。

かつ、要件定義書はクライアント側の合意や承認を得る必要があることから、クライアントにも分かりやすい内容でなければなりません。以下、システムに関する項目について挙げていきます。

*1.システムの概要と背景・目的など*
クライアントに対して、開発するシステムの概要や背景、予算やスケジュール、実装する機能、業務フロー（現行とシステム導入後）などについて確認と合意を得るためのドキュメントです。どのような項目を盛り込むかは、個々に異なりますが、テンプレートやサンプルを利用する場合は以下のサイトが手助けになります。

*【参考】：[IPA公式サイト_超上流から攻めるIT化の事例集：要件定義](https://www.ipa.go.jp/sec/softwareengineering/tool/ep/ep2.html)*

*2.機能要件に関する内容*
機能要件はヒアリングしたクライアントの要求内容であり、これがプロジェクトのゴール（実現目標）となります。機能要件はシステムのゴールを記述しますが、システム化によって何がどう変わるのかが分かる内容であることが求められます。

*3.非機能要件に関する内容*
非機能要件は、クライアントが機能要件以外で求めている要件を指します。例えば、システムの性能（レスポンスや拡張性など）・セキュリティ・保守サービスなどに関する要件です。非機能要件は、機能要件と同じく重要なシステム開発のゴールです。できるだけ、数値化できるものは数値で示すようにします。

機能要件とは？非機能要件との違いや書き方をわかりやすく解説

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

## 要件定義はシステムエンジニアの勲章

要件定義の精度がシステム開発の成否を左右することは理解できたと思います。

要件定義で、システムエンジニアはクライアントの要求を完全に理解し、その背景や業務、システムに必要な機能などを設計書に落とし込めるレベルまで漏れなくまとめなくてはなりません。これは大変な作業ですが、やりがいのある仕事です。

そして、システムがクライアントの要求通りに完成して、クライアントからお褒めの言葉を頂いた時に、エンジニアとしての無常の喜びを感じるでしょう。**システムの成功の鍵を握る要件定義書が自身の勲章と呼べるようになるよう、システムエンジニアとしてのスキルアップ**を目指してください。

要件定義とはシステム開発の成否を左右する重要な鍵です。「要件定義書」はクライアントやユーザーの要求に対する解決策を示したものであり、その内容は必ずユーザーの同意を得ておくことが必要です。ここではシステムエンジニアにとって大切な「要件定義」について解説をします。

要件定義とはユーザーの要求に対する解決策を明らかにすること

要件定義はシステムの成否を左右する重要な鍵となる

システムエンジニアにとって要件定義は勲章である

要件定義書とは？仕様書との違いや書き方のポイントを解説

## つらいと考えられている金融系SEの現場での実情

ニーズが非常に多く、さまざまな金融機関で仕事を行えるのが金融系SEです。しかし、業務内容が複雑でボリュームあり、激務になったり**残業時間が増えたりするケース**もあります。

今回は金融系SEが*つらいと思われる状況*について、その要因などを解説していきます。

### 金融系SEは残業や激務が多く、つらいと言われている

銀行や保険そして証券などの金融機関は、基本的に顧客からお金を預かりながら業務を進めます。その中でシステムトラブルなどが発生すると、業務影響が大きくなり顧客からの信頼も失う可能性があります。

金融系SEはシステムトラブルの際、対応を求められるケースも多く、時には*激務になる*傾向があります。取り扱っているシステムでトラブルが生じたり、作業でミスが発生したりすると社会的信頼も失いかねません。

また、その際にシステムトラブルなどの説明を求められ、責任が大きくなることもあります。さらに、新たにリリースしたシステムなどで致命的なバグなどのトラブルが見つかった場合は、早急に対応する必要も出てきます。

作業が終わるまで相当な時間がかかることもあり、**時には残業が長く続く日々**もあります。

### 昼夜問わずに仕事を求められることもある

例えば顧客データが数百万件あり、その情報を新しいシステムへ通信によって転送する業務が発生したとします。これを多くの人がシステムを利用している日中に実施してしまうと、時には遅延や停止といったトラブルに結びつくことがあります。

日々運用しているシステムは、それぞれパフォーマンスなどの基準が業務に対応できるように定められています。その中で作業で大容量のデータ通信を行えば、時には**トラブルになり信頼を失う**こともあり得るのです。

金融系SEは、さまざまな作業について*時間調整を行う*ことになりますが、時には深夜で対応するケースも出てきます。通信や顧客の利用頻度が少ない時期を狙って、大容量のデータ転送などを行うので不規則な生活にもなります。

しかし、最近ではシフト調整などでしっかりと業務を*管理できるシステム*を作り上げているところも増えてきています。

プロジェクトを組む際にもマネージャーは人材などを考慮しながら、ベストな状態で日程を組み立てていきます。対応すべき内容からリソースを活用していくので、管理体制がしっかりしていれば**金融系SEとして仕事しやすい**でしょう。

### コミュニケーション能力も問われるのがつらい時もある

激務でつらいと考えられている金融系SEですが、*金融機関ならではの理由*が存在します。それは、多忙な中で顧客の対応も行うことがあり、コミュニケーションが困難だというケースです。

トラブルが発生した時には、素早く正常な状態へ戻す必要があります。対処方法、実施後の振り返りなどを顧客に報告する必要もあり、時には叱責されることもあれば非難されるケースもあるでしょう。その際、コミュニケーションが上手に取れず、他の激務にしわ寄せが行くこともあります。

また、顧客の中には多忙などによって十分なコミュニケーションを取りづらい人がいれば、**人間関係を構築するのがつらい**と感じる金融系SEは少なくありません。

## 金融系SEが各金融機関で関わる仕事内容について

さまざまな金融業がありますが、金融系SEは**それぞれの顧客に対して提供するシステム構築や開発**を実施していきます。

仕事内容も*多岐に渡ります*が、仕事を通してスキルアップできると期待できるのが金融系SEです。最先端のシステムなどを活用しながら構築や運用を行っていくので、*将来が期待できる職種*といえるでしょう。

### スキルアップしながら仕事ができる

金融系SEが携わる主な業務は、**保険や銀行そして証券会社などのシステム**を顧客に対して提供していくことになります。金融業の種類や顧客が活用しているシステムによって各所で異なりますが、大半は業務で欠かせないサービスを管理することに使われます。

ATMや各顧客の口座など昨今システムによって管理しており、通信や処理で業務影響も大きくなるほどITに対する依存度が高い業種です。金融系SEは社会インフラの一部を手がけていくとともに、最先端のシステムを扱うこともあります。

残業も時には多くなりますが、難問を解決していく力を身に着けることもできます。達成感が非常に大きいので、金融系SEはやりがいの仕事が多いといえるでしょう。

また、金融系列の多くのシステムはビッグデータやAIを活用していくケースが増えており、積極的に導入が進んでいます。システムなどで技術変化を感じながら、*柔軟に対応*していくことも金融系SEには求められます。

### 金融系SEは内外の情報管理を中心に業務を行う

金融系SEが行う構築や運用システム業務の多くは、**顧客管理をメイン**としています。日々システムに付随する業務が発生するので、*担当業務*も多岐にわたります。

例えば、銀行系列であれば預金・貸し出し・利息計算などのシステム・管理を行うためのシステムを分けながら構築や運用を行っていきます。また従業員のシステムを構築することもあり、リリースした後もトラブル対応などに追われることも多くなります。

保険関係だと、業務関連としては保険料関連・顧客管理・契約管理などを行うシステムを対応していきますが、時には営業支援などの分析などを担当することもあります。

また、証券会社関連では注文や成立後の約定関係や顧客管理のシステムなどを請け負い、内部業務ではコンプライアンス関連のシステム構築や運用を任されることもあります。

### フリーランスで活躍している金融系SEも多い

長期間金融関係のシステムを使うと、時にセキュリティ対策がしっかりと講じられなくなってしまうことがあります。そこで一部の金融期間では、数年ごとにその時々の最先端のシステムを利用し、セキュリティ対策を万全なものにしています。しかし、人材不足が懸念される状況もあります。昨今は*フリーランス*で活動しているSEに依頼するケースも増え、フリーランスSEは各金融機関で活躍をしています。

金融系SEの肩書を持つフリーランスであれば、金融系システムに対しても精通していることがあります。各金融機関でも資産運用などのアプリケーションやシステム構築などに精通しているフリーランスを*募集*しており、ニーズの高さを伺わせます。

極力職務領域が広いフリーランスを求めていますが、最近ではビッグデータなど複雑かつ大容量のシステム構築や運用そして分析が行える人材を求めることもあります。

職種は金融系SE以外にも社内ヘルプデスクが多く募集をかけていることもあるので、**斡旋を行っているエージェント**などに相談しながら、案件を獲得するフリーランスも増えています。

[金融系SEの仕事内容](https://freelance.levtech.jp/guide/detail/589/)

[金融系SEが激務な理由5つ｜金融系SEの魅力と平均年収・メリット](https://i-am.jp/job-change-opportunity/boring-work-low-salary/1078536)

## 金融系SEに向いている人はいる？　

つらいと感じる人が多い金融系SEですが、スキルによっては*適正がある人*もいます。例えば、コミュニケーション能力や正確な仕事ぶりなどのスキルのことです。

そして**キャリアアップしたい時には、金融系SEは転職が有利**になります。金融系SEに向いている人の特徴を、具体的に見ていきましょう。

### コミュニケーション能力がある

*コミュニケーション能力*は金融系SEで求められるスキルの1つですが、金融系SEとして向いていると考えられています。社内外で多くの人と関わることがありますが、時には複雑なIT関連の用語を咀嚼して伝えていく技術を求められることがあります。

作業などを調整していく役目も金融系SEではありますが、内容を分かりやすく伝えていく力をつけていく必要があります。

そこで**プレゼンテーションなどで伝える力**を持ちつつ、相手からの質問などに分かりやすく回答を行えるスキルがある人は金融系SEに向いているといえるでしょう。

またプロジェクトに携わる時には、常に*情報を収集できる力*も必要です。それをコミュニケーションに活用しながら、顧客に対して金融系SEとして的確に説明できる力があると重宝されます。

常に学ぶ姿勢で責任感を持って取り組めるのが理想的です。金融系SEはコミュニケーションを取りつつ、**積極的に動いている人**ほど求められます。

### 求められる結果を遂行できれば大成できる

金融機関で使われているシステムは、1度トラブルやミスが生じてしまうと**社会的信頼を一気に失ってしまう**ことがあります。その中で金融系SEでは高いスキルを常に求められており、長い間利用できるシステムを作り出せる力を求められます。

継続して品質を担保し、トラブルなどを少なくできるように考えられる人を金融系SEとして各金融機関は探している状況です。

テストなどをしっかりと計画し、大規模なシステムであろうと*正確*に顧客のリクエスト通りの内容に仕上げることができれば、*金融系SEとして重宝される*でしょう。

経験を地道に積んでいきながら、**精緻な検証力や分析力そしてコミュニケーション能力など**を身に着けていきましょう。

### 厳しい時には転職を検討することも必要

金融系SEとしてつらいと感じる時は、転職も検討することになりますが、経験を積んだ方が*市場では評価が高く*なります。

また、過酷な労働環境でもシステムトラブルを起こさずに仕事を行う人ほど**スキルが高いと評価されることが多い**です。市場価値を事前に見い出しておき、本当の自分に向いている仕事を見つけていきましょう。時には職場環境を変えることで働きやすくなることもあります。

## 金融系SEはつらいながらもスキルアップができる

金融系SEは求められる内容も多く、**コミュニケーション能力など**が必要とされます。時には激務が続いたり、深夜や早朝対応があったりなど、不規則な時間帯での業務が行われることもあります。

しかし、金融系SEは続けることで着実にスキルアップしていき、*キャリアアップが十分可能な職種*です。さまざまな業務で経験を積み、次のステージではどのように進めるのか考えていきましょう。

金融系SEの業務は多く、時には激務になったり不規則な出勤になるのでつらいと考えられています。しかし最先端のシステムを取り扱うこともあり、レベルアップを激務の中でも行うことは十分可能です。市場での評価も高いため、業務を重ねればキャリアアップも目指せます。

銀行や保険そして証券会社などで求められるシステムは異なっている

時にはコミュニケーション能力や深夜や早朝などの不規則な出勤などを求められるケースもある

向いている人はスキルアップを重ねながら、転職時に評価を上げていくこともできる

業務や人間関係などがつらいと考えられている金融系SEの実情

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

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

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

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

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

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

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

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

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

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

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

IT開発プロジェクトで必須のWBSについて、改めて見直してみよう

あなたが仮にプロジェクトリーダーを任され、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について理解しよう

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