## 日本がDXの推進をすべき理由

**日本がDXの推進をしなければならない理由は、ズバリ企業の競争力強化と事業成長のためです。**2018年に経済産業省が「DX(デジタルトランスフォーメーション)を推進するためのガイドライン」を発表しましたが、これがDXブームの契機となりました。

日本企業のIT化の遅れは、日本経済成長の阻害要因と見られています。*陳腐化したレガシーシステム(技術刷新すべき既存のシステム)が足かせ*となって、企業がITシステムの刷新に消極的になっているという現状があります。

こうした状況を打破しなければ、日本経済は大きな負の遺産を抱えたまま、ひん死の状態に陥るといった懸念があります。

これを打破する鍵がDXです。*IT技術を駆使し、ビジネスモデルを抜本的に変革し、業務や組織、プロセスや企業文化を見直し、競争上の優位を確立すること*が企業に求められています。

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

「2025年の崖」という言葉は経産省のDXレポートの中で用いられました。このまま2025年を迎えると、崖から転がり落ちるような危機が訪れるという比喩です。

レポートでは**複雑化、老朽化した既存のシステムがそのまま残ると、国際競争への対応ができず、日本経済に大きなダメージを及ぼす**ということが述べられています。今後予想される*IT人材の引退や不足、既存システムに対するサポート終了*などがこの経済停滞の要因になるというのです。

既に多くの企業は、新たなデジタル技術の活用によるビジネス変革の必要性を理解はしているものの、レガシーシステムの存在がこれを阻害しているのです。

DXレポートによると、21年以上も稼働しているレガシーシステムが2026年には、システム全体の6割を占めると予測し、この刷新に乗り遅れた企業は事業機会を失うというのです。またレポートでは*2025年以降、最大で12兆円/年の経済損失が生じる*と推定しています。

参考:[経産省「DXレポートサマリー」](https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/pdf/20180907_01.pdf)

**日本は先進諸外国と比べてデジタル競争で大きく遅れています。**日経BPの「DXサーベイ(900社の実態と課題分析)」によると、調査対象となった900社でも、「DXに本気で取り組み、成果を上げている」とした企業は全体の1/4、26.3%に止まっています。

デジタル先進国では大半の企業がDXに取り組んでいるという状況から見ても、日本のDX推進がかなり遅れを取っているということが分かります。

参考:[DXサーベイ(900社の実態と課題分析)]( https://info.nikkeibp.co.jp/nxt/campaign/b/275300/)

デジタルマーケティングとは？エンジニアにとっての重要性も確認

DXの推進においては遅れをとっている日本企業ですが、中にはDXを推進して成果を上げている企業も少なからずあります。

こうした**成果を上げている企業のDX事例について見ていきましょう。そこには何らかのDX成功の鍵があります。**事例に学び、良い点は参考にして自社のDXを推進していくことが求められています。

**日本でもDX推進を課題として掲げる企業が増加しています。**ここでは主に、*消費者と直接接点を持つ小売業、飲食業、タクシー業での導入事例*を、実体験を交えながら紹介してまいります。

*1.UNIQLO*
小売業でDXに積極的な企業というと、真っ先に思い浮かぶのは*ユニクロ*でしょう。2020年6月にはOMO(リアルとバーチャルの融合)を実験店として原宿店、さらには同6月にマロニエゲート銀座2に旗艦店「UINIQLO TOKYO」をオープンさせるなど、DX推進の動きには目覚ましいものがあります。

アパレルの販売であればネットでも完結できますが、そうした中ユニクロはあえて店舗を出店し、**UX(顧客体験)とショールームという機能を店舗に持たせ、ネットとリアルの良いところをうまく融合させています。**

他に、アバレルチェーンでは類を見ないセルフチェックアウトシステムを展開し、店舗における決済という負担を軽減している点も目を引きます。小売業の最先端を走るユニクロのこうした姿勢は、創業社長である柳井氏のデジタルに対する造詣の深さと理解、リーダーシップに負うところが大きいでしょう。

*2.トライアルカンパニー*
スーパーセンター(ディスカウト型の大型スーパー)を展開するトライアルカンパニーは、お客が自ら商品のバーコードをスキャンし、カートに設置されたタプレットで決済をする*「スマートレジカート」*を導入しています。

これと同様の取り組みを、大手スーパーのイオンも「レシゴー」として展開中です。

さらにトライアルでは、*独自のAIカメラを開発し、売場の棚の状況をモニタリングして、商品管理や品揃え*に生かしています。

その他、*電子プライスカード*を導入してリモートでプライス変更を行い、プライスカード付け替えなどの人的作業を不要にしています。

**トライアルは自動発注、自動補充、無人店舗の開発にも取り組むなど、徹底的なローコスト運営を実現し、圧倒的なロープライスで顧客への還元を図っているのです。**

参考:[リテールガイド]( https://retailguide.tokubai.co.jp/strategy/1251/)

*3.はま寿司*
大手外食グループのゼンショーホールディングス(牛丼チェーンの「すき家」などを展開)が手掛ける回転寿司チェーンの「はま寿司」はコロナ禍に対応し、店舗システムの全面刷新に取り組んでいます。

まず、衛生面に配慮しながら、出来立ての寿司をお客に届ける*超高速レーン*を導入しました。回転寿司屋でありながら、寿司は回転しておらず、お客が専用タプレットで注文したものだけが、お客の席に高速で届くという仕組みです。

これで同時に*廃棄ロス*を減らし、ロスを減らした分だけ寿司ネタを増量してお客に還元をしています。また*専用のスマホアプリ*を開発し、お客はアプリを利用して時間予約をし、待ち時間ゼロで席に座れます。アプリにはおすすめ商品の紹介やクーポンがあり、お客にとっても利便性が大きく向上しています。

また、会計は入店時に発券されたシートをレジに持っていくだけで決済が行え、従来のように店員が皿数を数えるという動作が不要になりました。

**これらの取り組みによって、人と人の接触を避け、サービスや品質は向上し、コストカットやロス削減につなげるなど、顧客と店舗の双方に大きなメリットをもたらしています。**

*4.スターバックス*
コーヒーショップのブランドとして顧客から圧倒的な支持を得ているスターバックスコーヒーは、早くからDXやCX(カスタマーエクスペリエンス)の向上に取り組んできました。

**DXやCXの向上は目的ではなく、彼らが「スターバックス体験」と呼ぶ「顧客満足実現」の1つの手段なのです。**

スターバックスの従業員はパートナーと呼ばれ、スターバックスが掲げる*「Our Mission and Values」*の精神を全員で共有し、「Our Mission and Values」の精神がが店舗設計、サービス、ITや経営意思決定、マーケティングなど全ての企業活動に生かされています。

最近では、*「スターバックスさくら2020」*と題するAR(仮想現実)を利用したお花見体験の提供や、スマホのアプリで事前に注文と決済が出き、店舗に着くと直ちに商品を受け取れる*「モバイルオーダー&ペイ」*など、*デジタルを使ってCXを向上*させるという取り組みを続けています。

「スターバックスに行けば、すてきな体験がある」という顧客の意識が定着することで、さらにリピーターが増えていくという考え方が、スターバックスのDXの根底にあるのでしょう。

*5.JapanTaxi(日本交通)*
コロナ禍で苦境に立たされているタクシー業界ですが、ここでも積極的にDXに取り組んでいる企業があります。日本交通からスピンオフしたJapanTaxiです。JapanTaxiは日本版Uberですが、運転手と乗客の双方に好評です。

**乗客はスマホでJapanTaxiのアプリを立ち上げ、ボタンを押すだけで周辺にいる空車タクシーがすぐに迎えに来てくれるという便利アプリです。**

アプリでは迎えに要する時間や推定運賃も分かります。また決済機能があり、タクシー内のQRコードを読み取って、目的地に到着する前に決済ができます。運転手にとっても、お客を乗せる前から目的地が把握でき、しかも現金のやり取りがなく、運転に専念できます。

この*ライドシェアサービス*の便利さは、外国でUberを利用するとよく分かります。運転手と会話する必要がなく、言葉も問題はありません。乗る前から運賃が決まっており、運転手にわざと遠回りさせられて運賃を余分に取られる心配もありません。

車を降りた後、運転手の評価を付けるようになっているので、運転手も良い評価を得るために必死ですから、自らサービスに努めます。中にはドリンクサービスまでしてくれる運転手もいるほどです。

白タクが禁止されている日本では、まだまだ配車アプリで利用できるタクシーが多いとは言えませんが、今後さらにこうした配車アプリの活用が広がっていくでしょう。

**DXを推進している企業、DX推進に成功した企業には共通するポイントがあります。**その共通項がDX成功の秘訣と言えるのではないでしょうか?ここでは、DX成功のポイントを3つにわけて解説します。

### トップの理解とリーダーシップ

**DX推進にはトップの深い理解とリーダーシップが必要です。**成功している企業のDXはトップダウン型が大半です。DXはシステム部門だけでは進められません。

特にレガシーシステムを多く抱えた企業は、既存システムの改廃に膨大なコストが掛かります。トップの大英断がなければ、なかなかGOサインが出ません。

### 徹底した顧客第一、現場主義

「DXの推進は政府方針だから」、「DXがブームだから株主対策で実施する」と考えた企業の多くはDXに失敗します。

なぜなら**DXは顧客の理解と顧客満足の裏付け、現場の理解と協力が無ければ絵に描いたモチ**で終わってしまうからです。DXは顧客第一、顧客視点・現場視点で取り組むことが大事です。

DXはトップから現場まで、全社一丸となって進めるものです。**DXは「IT技術を駆使し、ビジネスモデルを抜本的に変革し、業務や組織、プロセスや企業文化を見直し、競争上の優位を確立すること」だからです。

**業務、組織が変わるためには、全ての従業員の理解と協力が欠かせません。そのためには徹底した情報共有と教育が必要です。**それができて初めて全従業員の意識が1つになります。

**DXはIT人材抜きでは実現し得ません。**しかし一方では、IT人材の絶対的な不足が国家的な問題にもなっています。*ITエンジニアである皆さんの力が求められています*。

ITエンジニアはきついがやりがいがある！その仕事内容や年収、求められるスキルを解説

DXはデジタル化であり、ITを徹底活用することです。**DXを進める上ではIT技術に関する知識や経験が求められます。**よってDX人材が求められていると言ってもよいでしょう。

DXではこれまで以上に*クラウドやAI・データ分析、アジャイル開発、マイクロサービス・アーキテクチャー*といった技術が求められます。DXを推進するITエンジニアには、そうした技術を積極的に体得していくことが求められます。

### ITエンジニアはDXの旗手であれ

日本は残念ながら、デジタルにおいては遅れをとっています。アジアでは韓国、台湾、中国に先行されています。**この現状を打破し、日本が経済大国として再生していく鍵はDXです。

**DXは企業や組織だけではなく、日本の国家的課題です。今こそ、ITエンジニアである皆さんが必要とされているのです。この記事を読まれた皆さんにはぜひ、日本のDX推進の旗手として活躍をしていただきたい**と願っています。

多様化しているエンジニアの働き方について分かりやすく解説！

DX（デジタルトランスフォーメーション）の推進は日本の大きな課題ですが、DXの取り組みは遅れており、DXに対する間違った理解もあるようです。実際の導入事例を元に、DXとは何かについてや成功のポイント、DX推進におけるITエンジニアの役割についても考察します。

2.日本におけるDXの推進状況を事例などから具体的に知る

3.DX成功のポイントと、ITエンジニアとしてDXとどのように関わっていけばよいのか

DXの取組事例に学ぶDX成功のポイントとITエンジニアへの期待

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について理解しよう

従来、システム開発やソフトウェアの開発手法は、ウォーターフォール開発が一般的でした。2000年代以降は、アジャイル開発という開発手法が注目されています。アジャイル(Agile)sとは「素早い」を意味する英語です。まさにその意味の通り、**アジャイル開発は、大まかなシステムの仕様が決まったら、「手直しを前提に、まずは作ってみる」という考え方にのっとり、極力少ない工数で、短期間で開発をする手法**のことです。

### ウォーターフォール開発とは

アジャイル開発が一般化する前は、「ウォーターフォール開発」がシステム開発手法の中心でした。**ウォーターフォール開発は、システム開発の際に、最初にプロジェクトの要件定義や綿密な設計をしてから開発に取り掛かる手法**です。「*システム分析→システム設計→システム開発→システムテスト→保守*」というシステム開発の一連の工程を、一斉に最初から順番に実行していくため、*滝のように上から下に水が落下するイメージからウォーターフォール開発*と呼ばれています。

ウォーターフォール開発はメインフレーム(汎用コンピューター)で主に用いられた伝統的な開発手法ですが、ダウンサイジングやクラウド、モバイルといった新しい技術が主流となり、日進月歩で技術が進展する中、ウォーターフォール型の開発手法は時代にマッチしなくなってきました。

【保守・運用】仕事内容や将来性、必要なスキルについて徹底解説！

ウォーターフォール開発よりもはるかに**システム開発の期間短縮が可能なアジャイル開発**の基本的な流れについて触れておきましょう。

*■リリース計画*
**仕様やユーザー要求の取りまとめ過程を、アジャイル開発では「リリース計画」と称します**。「リリース計画」は開発における方向性を示したもので、厳密さは求められません。開発の過程で、当初の「リリース計画」ではなかった仕様やユーザー要求が追加されるのは当たり前にあるという前提に立っています。

*■イテレーション*
リリース計画が決まると開発に着手します。アジャイル開発では**各機能単位で「要件定義→設計→実装→テスト」のサイクルを短期間で繰り返します。これをイテレーション(反復)と称します**。

このように、時代の変化にそぐわなくなってきたウォーターフォール開発に代わって、仕様変更に柔軟に対応できるアジャイル開発が主流となってきましたが、**アジャイル開発にもいくつかの手法が存在します**。ここでは代表的な3つの手法について簡単にご紹介します。

*1.スクラム開発*
スクラム開発のスクラム（Scrum）とは、ラグビーのスクラムが語源です。**ラグビーの様にチーム一丸となって、システム開発を進めるフレームワークです**。

スクラム開発とは？エンジニアが知っておきたい情報をまとめました！

*2.エクストリーム・プログラミング(XP)*
エクストリーム・プログラミング（Extreme Programming）は「XP」と略され、技術者、**とくにプログラマーを重視した開発手法です**。仕様変更、要求変更、機能追加を当然のこととして想定し、プログラマーが常にペアで相互チッェクをしながら開発を行います。

*3.ユーザー機能駆動開発(FDD)*
ユーザー機能駆動開発（Feature Driven Development）は「FDD」と略され、**ユーザー(顧客)の機能価値（feature）という視点に重きを置いた開発手法です**。初めにユーザー機能一覧を作成し、短い間隔で反復 (イテレーション) を繰り返しながら、ユーザー機能を実装していきます。

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

アジャイル開発はウォーターフォール開発に苦手な部分をカバーし、**システム開発の生産性を高める優れた手法ですが、アジャイル開発にも弱点は存在します**。その弱点、デメリットを理解した上で、適切な手法を選択していくことが重要です。

まずは、アジャイル開発のメリットを理解しておきましょう。**アジャイル開発手法の強み、メリット**を整理すると以下のようになります。

*1.仕様変更にスムーズに対応することが可能*
仕様変更が当たり前だという前提で、あまり細かく仕様を決めないため、逆に*仕様変更に対応しやすくなります*。

*2.開発スピードが早い*
仕様変更を前提とした開発手法のため、ウォーターフォール開発のような*大きな手戻りが発生しにくくなります*。

*3.顧客の要望を満たしやすい*
開発途中で顧客の要望(=仕様変更、仕様追加)に柔軟に対応できるため、*顧客の要望を満たせる確率が上がります*。

*4.UI(User Interface)重視のシステムに強い*
途中で仕様変更が発生しやすい*WEB開発、WEBアプリ、スマホアプリの開発には対応しやすい*のもメリットと言えます。

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

良いことずくめに見えるアジャイル開発ですが、実は次のような**弱点、デメリットもあります**。

*1.開発の方向性や目的がぶれてしまうことがある*
現状調査や分析、要件定義のフェイズを大きく省略するため、*仕様変更を繰り返している内に当初のシステム開発の目的から外れてしまうことがあります*。

*2.全体の進捗管理がしづらいことがある*
アジャイル開発では、開発スケジュールを詳細に決めず、*進捗状況を把握するための物差しが明確ではないことから進捗管理がしづらくなることがあります*。

*3.要件が定まっているプロジェクトには向かない*
汎用系やレガシー系システムのリプレイスなど、*要件が定まっており、途中での仕様変更が発生しにくいプロジェクトではウォーターフォール開発が適しています*。

スクラム開発手法のメリット・デメリットと失敗から学ぶ成功の秘訣

## IT人材の枯渇とアジャイル開発

日本ではIT人材の枯渇が国家的な問題として指摘されています。一方で経済産業省が警鐘を鳴らす*「2025年の崖」問題*があり、このギャップ解消を図らなければ、日本経済は致命的な損失を被るとされています。その**解決手段がDX(テジタル・トランスフォーメーション)と言われています**。

世界ではソフトウェア開発の生産性向上にアジャイル開発が当たり前になっていますが、*日本ではいまだにウォーターフォール型の開発が主流であり、世界との格差が顕著になっています*。

**日本が世界に追いつくためには、アジャイル人材の育成や確保が急務なのです**。では、アジャイル人材にはどのような知識、スキルが求められるのてしょうか?

### アジャイル人材に求められる知識

**■アジャイル開発の原理・原則の理解**
アジャイル開発を担ううえで、アジャイル開発に関する原理、原則の理解が欠かせません。アジャイル開発の原理、原則を理解するには、*「アジャイルソフトウェア開発宣言」*を知っておく必要があります。「アジャイルソフトウェア開発宣言」は2001年にソフトウェア開発の将来について議論をするために、17人の著名な有識者が集まり、その議論の結果を宣言としてまとめたものです。
この宣言では*アジャイルソフトウェア開発がもつ4つの特徴と価値*を明らかにしています。

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

すなわち、『”左記の事柄”に価値があることを認めつつ、*「右記のことがら」*により価値をおく』として、この他にも12の原則を示しました。
これらが、今日のアジャイル開発における礎(いしずえ)となっているのです。

### アジャイル人材に求められるスキル

アジャイル開発のメンバーには、ソフトウェア開発の基本スキルに加えて、次のスキルが求められます。

**■技術スキル**
アジャイル開発の参加メンバーには、ソフトウェア開発に関する基本スキルと合わせ、以下のような技術スキルが求められます。

●ペアプログラミング
●テスト駆動開発
●テスト自動化
●継続的インテグレーション

**■チーム運営スキル**
アジャイル開発は*スクラム*と呼ばれるチームで進めることが多くなりますが、そのスクラムの成否は*スクラムマスター*と呼ばれるリーダーの手腕にかかっています。*スクラムマスター*がメンバーの力を最大限に引き出すには、次のようなチーム運営ノウハウを押さえておくことが必要です。

●スプリント計画、推進
●日次ミーティング
●タスクかんばん
●バーンダウンチャート
●振り返り

**■ヒューマンスキル**
アジャイル開発には*ヒューマンスキルも重要な要素*です。これは*自ら体得*していくしかありませんので、アジャイル開発に参加し、失敗を経験し、試行錯誤で悩みながら、身に付けていくしかありません。例としては次のようなものがあります。

●継続的改善
●コーチング
●ファシリテーション
●サーバントリーダーシップ

以上、学ぶべきことが多いというよりは、それらの**概念を理解した上で自ら獲得していくもの**が大半です。これらの体得には不断の努力が求められますので、自らのステップアップ計画と連動させ、ぜひアジャイル人材を目指してください。

## アジャイル開発はDX実現の切り札となる!

アジャイル開発においては、**テクノロジー面も必要ですが、何よりも行動変容が求められます**。アジャイル組織、アジャイル人材が求められています。一方、経済産業省が提唱している**DX(：Digital Transformation）も、単にデジタル化ということではなく、行動変容を通じて組織を変え、人を変え、ビジネスモデルの変革することを目的**としています。そうした意味では、**アジャイルとDXは表裏一体の関係にある**と言っても過言ではないでしょう。

DXのタイムリミットは2025年、余すところ4年もありません。この間に、企業は大転換を迫られています。一方で冒頭に述べたように、*IT人材の不足は深刻化*しています。この**限られた時間の中で、システム開発のスピード、生産性を飛躍的に向上させる必要があるからこそ、スピード開発に強いアジャイル開発が求められるのです**。

今や、ペーパーレス、印鑑の廃止、ワークフローやSFAが当たり前になっています。一方で、古い組織や、古いやり方をなかなか打破できないのも事実です。その原因は人です。だからこそ行動変容が必要なのです。過去の成功体験は捨てましょう。頭をまっさらにして、まずは自分を変えることです。**意識が変わらなければ行動は変わりません**。

今、DXを実際に推進する多くの企業では、DX推進の有効なアジャイル開発の検討や適用を始めています。**アジャイル開発の普及や成功が、企業の競争優位を獲得する重要なバロメーター**になってきます。

しかしアジャイル開発は、IT部門だけの問題ではありません。トップも含めて企業全体にアジャイルの導入や定着が必要です。マネジメントそのものもアジャイル思考に変えなければなりません。

ウォーターフォール型の組織や開発手法を全面否定する必要はありません。ウォーターフォールが適した業務やシステム開発はあります。これまでウォーターフォールで培ってきた考え方は理解し、必要な部分は活かし、企業や組織の目的、方針や戦略に合わせた、それぞれのアジャイルを志向すべきでしょう。いずれにしても、今変わらなければ、未来はありません。**DX推進の鍵はアジャイルにある**といっても過言ではないのです。

迅速なソフトウェア開発を目的として生まれた「アジャイル開発」手法の特徴やメリット、デメリットは？伝統的な開発手法「ウォーターフォール開発」との違い、「アジャイル開発」はDX推進の切り札となるのか、「アジャイル開発」人材に必要なスキルなどについて考察します。

アジャイル開発とは何か？ウォーターフォール開発との違い

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

アジャイル開発はDX推進の切り札になる

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

## ITシステムの品質確保の考え方は？

*ITシステムにおける品質とは、想定したことが想定通り動作する度合い*のことをいいます。仮に、仕様通り作成されたシステムでも、*操作方法が使いにくかったり、エラー処理が複雑だったりするもの*は、**ユーザの満足度が低下**します。この状態では、高品質のシステムとは言えません。ここでは、ITシステムにおける品質に関して、開発者側とユーザ側での対応を解説します。

開発者は、ユーザの満足度を高めるために**品質特性**を考えて、*企画・設計・開発・テストを進めます*。*品質特性とは、ソフトウェアの品質を評価する基準*のことで、ISO/IEC 9126(JIS X 0129)に定義されています。ISO/IEC 9126(JIS X 0129)では、以下の6つの特性と、それぞれの品質特性をさらに細分化した21の副特性が定められています。**以下が6つの品質特性です**。


◆ *機能性*(Functionality)
　目的から求められる必要な機能の実装の度合いで、想定条件の下で要求仕様を満たす能力
◆ *信頼性*(Reliability)
　想定条件の下で機能が正常動作し続ける度合いで、障害の起こりにくさの度合い
◆ *使用性*(Usability)
　ソフトウェアの想定動作に関して、利用者に対する分かりやすさ、使いやすさの度合い
◆ *効率性*(Efficiency)
　与えられた条件で、目的達成のために使用する時間や資源の度合い
◆ *保守性*(Maintainability)
　保守作業や改修作業に対する、必要なコストの度合い
◆ *移植性*(Portability)
　別の環境へ移した際、移植のしやすさや、そのまま動作する度合い

ユーザ側は、*業務システムに実装したい要求を、要求仕様としてまとめていきます*。同様に、運用に必要な各種要求についても要望として整理します。特に、レスポンス時間保証が求められるシステムや、システムダウンの影響を最小化する場合は、**動作品質の十分な考慮が必要**となってきます。ユーザ側で開発を主導する場合はこのような内容をもとに検討していきます。

*テスト工程は、要求発生から納品までの流れに従ってステップ化*していきます。その際は品質特性を意識したチェック項目を作成し、**品質基準をクリアする判断**を進めていきます。

開発者はユーザ側から要求を受けてから、以下の**ステップに従って、開発工程を進めていきます**。まず*要求分析*(Requirements analysis)の工程で、ユーザの要求を理解するために、ユーザから要望書である*要求仕様書を入手*します。続いて*要件定義*(Requirement definition)の工程で、ユーザの要求が実装可能なIT要素で実現できるかどうかを確認し、*要件定義書*として作成します。

次に、*基本設計*(Basic design)の工程で、要件定義書の記載事項に基づき、*外部設計仕様*として設計していきます。さらに、*詳細設計*(Detailed design)の工程では、基本設計書の各項目に対応する開発を想定し、*設計の詳細化*を進めていきます。その後の詳細工程では、*開発・製造*(Development / Manufacturing)で、詳細設計の項目・ルールに従い、*モジュールの開発・製造*を行います。

上記の開発工程の品質を保証するために、以下の**ステップでテストを進めていきます**。まず*コードレビュー*(Code review)では品質を確保するために、*ソースコードの品質評価*を行います。続いて*単体テスト*(Unit Test)では、開発・製造の工程での品質を確保するために、テストデータとテストロジックに基づいて*単体動作の妥当性を検証*します。

次に、*結合テスト*(Integration Test)では、詳細設計工程での品質を確保するために、テストデータにより、*モジュール間の動作の妥当性を評価*します。加えて、上限値・下限値やエラー処理の振る舞いが妥当かを確認します。その後に*システムテスト*(System Test)で、疑似ユーザデータを用いて*システム全体での動作が妥当か確認*します。また高負荷環境での動作が安定するかどうかや、運用想定のエラー処理が妥当かどうかもみていきます。

最終工程となる*運用テスト*(Operations Test)では、要件定義工程の品質を確保するために、ユーザの運用環境と実データを用いて、*ユーザの要求が満たされていることを確認*していきます。この工程では、ユーザ側からも運用担当者を派遣し、運用方法の*要員教育*を並行して実施することもあります。

ここでの要員教育とは、「*想定した環境下で、運用方法の差異をユーザ側から派遣し、確認すること。差異がある場合は、受入テスト前に差異について習熟し、不備がないことを事前評価し、受入準備を図ること*。」です。

その目的を果たすために、ユーザ側の要員が運用テスト期間に実施するパターンです。これにより、受入テストを円滑に進めることも可能となります。並行して、引渡しに際し、別途運用計画と要員育成計画を作成・実施します。


*運用テスト*(OT: Operations Test)は、**開発者側が責任を持ち**、進めていきます。*要件定義書の記載が、開発システムでカバーされていることを保証*するために実施します。この運用テストについて具体的な内容を見ていきましょう。

運用テストは、ユーザ側の要求する機能が満たされていることを確認し、保証するものです。そのために、ユーザの動作環境や実際のデータを用いて、*商用環境を想定した操作方法・手順を用い、確認*していきます。同様に、誤ったこと(エラー)が、想定通りに(想定エラーとして)処理されることを、**最終評価**していきます。

加えて、機能性のみならず、性能維持が高負荷でも守られるか、操作が安定しているか等の*非機能要件の適合状況を検証*します。さらに、ユーザ側は、運用テスト工程を活用して、*受入後の操作の習熟を図る*ことができます。

運用テストでは、開発者の作成したテスト計画書とテスト仕様書、テストデータを用います。*テスト環境の定義が妥当か、開発者側の責任範囲の設定が適切かについて確認*しましょう。

*応答時間、処理時間、操作エラー、障害発生時の動作や、エラー処理手順、障害検知・障害対応フローの確認*についても、**運用テストで見極めます**。

*運用テストは開発者の責任により実施*されます。しかし、求められる要件はユーザ環境で必要とされる事項です。したがって、**ユーザ側の立場に立って計画立案・実施をすること**が求められます。そのため、テストシナリオを事前に用意し、ユーザ環境に合わせたテストパターンを複数定義して適合性を確認します。

運用テストってどんなテスト？目的や内容、注意すべきポイントとは？

*受入テスト*(UAT: User Acceptance Test)とは、発注要件を満たしているかについて、**ユーザ側が最終確認をする**ものです。*検収テスト*とも言われています。したがって、*ユーザのニーズや要件を満たしているか*が、**判断基準**となります。同様に、ビジネスプロセスを満足していることが重視されます。

基礎知識の記事（96ページ目）