ソフトウェアの開発手法としては、従来主流だった*「ウォーターフォール開発」*と最近主流になりつつある*「アジャイル開発」*の2つの手法がよく知られています。

**「アジャイル開発」では、少人数の開発メンバーが協力しあいながら作業を進めていきます。**また、「ウォーターフォール開発」方式のような、一度決定した事を絶対視せず、*都度見直しながら柔軟*に進めていきます。各チームメンバーから定期的にフィードバックを得て、*その時点でベストと思われる方法*を採用していきます。システム開発においては、1度にすべての機能をまとめて作るのではなく、*機能単位に、あるいは一定期間ごとに開発を繰り返し、積み上げ*ていきます。

**「スクラム開発」は「アジャイル開発」の代表的な手法で、特にチームメンバーのコミュニケーションを重視した手法**です。この「スクラム開発」には次のような要素があります。

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

スクラム開発の要素は大きく分けると以下の4つですが、この手法はシステム開発以外のプロジェクトにも適用が可能です。

*1.機能単位で開発*
していくのがスクラム開発の特徴ですが、機能はプロダクトに対する要望を優先順位の高いものから並べ、その順番に従って機能を作ります。

*2.個別の開発期間は短期間（1～4週間程度）*
に区切って、その中で計画を立てていきます。

*3.メンバー同士のミーティング*
は毎日行い、その中でプロジェクトの状況を共有し、進捗に問題がないかなどを確認**していきます。

*4.プロダクトの機能*
がユーザーの要望通り正しく作られているのかを、*定期的にレビュー*します。

スクラム開発ではチーム単位で活動をしていきますが、1つのチームは3人から多くて10人程度までで編成します。またその活動は責任者に任せず、**メンバーが主体的に行動**するのが原則です。

*1.プロダクト・オーナー*
プロダクト・オーナーと言うと仰々しいですが、**プロダクト・オーナーの役割はチームの舵取り役**です。舵取りはしますが、チームへの*口出しはしません*。チームが最高のパフォーマンスを発揮できるよう側面からサポートする役目を負っています。

*2.スクラム・マスター*
**スクラム・マスターはメンターという立場**です。よき助言者といえば良いでしょうか。*チームメンバーとの関係は対等*です。メンバーが困っていることや、不都合な問題などに目を向け、その改善や治療を行います。*ドクター*のような存在です。

*3.主役はメンバー*
スクラム開発のチームにリーダーはいません。舵取りをしてくれるプロダクト・オーナーや、ドクターのような存在のスクラム・マスターはいますが、*チーム・リーダーの立ち位置の人はいない*のです。リーダーのいないチームとは？と不思議に感じると思いますが、一般的な組織のリーダーとは役割が違います。一応、リーダーに近い存在はスクラム・マスターですが、**スクラム・マスターはメンバーのサポートに徹します。あくまでもスクラムチームの主役はメンバー1人1人**なのです。

## スクラム開発のメリット・デメリット

**スクラム開発は新しく編み出されたアジャイル開発の1つの手法**で、多くのメリットがありますが、一方でデメリットもあります。スクラム開発をより理解するために、そのメリット、デメリットについて確認しておきましょう。

*1.チームメンバーが当事者意識を持って主体的に取り組める*
**スクラム開発の主役はメンバー個々人**です。スクラムを組んで全員でシステム開発を進めていくため、1人でも手抜きをすればスクラムは崩れます。そうならないよう、うまくサポートし、全員がモチベーションを維持しながら取り組めるように動くのが*スクラム・マスター*です。このため、メンバーはチームメンバーと協力し合いながら最高のパフォーマンスを発揮できるのです。

*2.問題が起きても迅速に発見し、迅速に解決できる*
スクラム開発では毎日ミーティングを行い、昨日の成果、今日の課題、問題点などを共有します。**問題点や障害となっていることはスクラム・マスターがさらに浮き彫りにし、メンバーと共同でその解決**に努めます。そのため、問題発見と問題解決が早く行えるため、プロジェクトが予定通り進みます。

*3.工数見積もりの精度が上がり予定通り開発が進む*
最初にプロジェクトの全工数を見積もる「ウォーターフォール開発」と異なり、アジャイル開発の一種であるスクラム開発では、**機能単位で工数を見積もりながら開発を進めていき、障害などの早期発見、早期対応が行えるので、計画通りに開発が進行**します。

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

スクラム開発は開発の生産性を高める上で大変効果的な手法なのですが、一方で**必要な条件を満たさないと、スクラム開発の効果が得られない**ことがあります。その*デメリット*ついて述べていきます。

*1.短い期間での対応でメンバーの協力体制が整わないことがある*
スクラム開発の最短のスパンは1週間です。**未習熟のメンバーが参画した場合、ウォーミングアップ期間や教育機関が十分に設けられない**ため、力を発揮することなく期間が終了してしまいます。開発リズムを崩さないよう、*できるだけメンバー編成を変えずに開発を進めること*が求められます。

*2.コミュニケーションが苦手なエンジニアには不向き*
スクラム開発では*メンバーのコミュニケーション力が問われます*。日々のミーティングで自分のタスクの進捗や課題を簡潔に発表し、他のメンバーの状況を正しく理解する能力が求められます。仕事はできるが、**コミュニケーションが苦手というメンバーはスクラム開発に不向き**です。こうした事を考慮し、メンバーの人選や、メンバーの育成に配慮する必要があります。

*3.開発全体のスケジュール管理がしにくい*
スクラム開発は柔軟な開発ができるメリットがある一方で、柔軟が故に開発の方向が変わることがあり、スケジュールそのものがぶれる可能性があります。また**工程が機能ごとに細かく分かれており、それも全体スケジュールの管理を難しくする要因**です。クライアントからスケジュールの進捗の確認を求められた際、説明が難しい点は、ウォーターフォール開発と比較してデメリットと言えます。

*スクラム開発が失敗する原因は非常に多くあります*が、ここでは絞って、代表的な失敗の原因について解説します。

スクラム開発という手法は、従来の開発手法とは大きく異なります。単なる掛け声だけで進められる手法ではありません。**チームメンバーの理解と協力も欠かせませんが、会社全体、経営者、利用部門など幅広い理解とコンセンサスが必要**です。これらを飛ばして、いきなりスクラム開発を進めると必ずと言ってよいほど失敗します。そのためには、関係者に対して、アジャイル開発・スクラム開発の目的や狙い、得られる効果、スクラム開発を進める上で必要なことをきちんと説明し、承認を得ておくことです。「単なるシステム開発の一手法だから、予算さえ確保しておけば問題ない」という甘い考えは通用しません。*周到な準備*を忘れないでください。

###  2.導入までの準備がおろそか

これは1.の失敗原因とも共通する部分がありますが、性急な導入は失敗する原因です。例えば、システム開発案件があり、そのプロジェクトを任されたとしましょう。納期が厳しく、従来型のウォーターフォール開発では間に合わないと判断し、スクラム開発方式の採用が頭に浮かびます。しかし、**スクラム開発方式を採用するには準備期間が必要**です。これまでに開発メンバーを含めて十分な経験があれば、問題はありませんが、*初めての経験なら6カ月程度の準備期間が必要*です。まさに「急がば回れ」です。

*アジャイル型開発に計画は不要だという誤った考え*を持つ方がいますが、これは大きな誤解です。どんなプロジェクトでも目標や計画は必要です。ただ、アジャイル開発の場合は機能単位に計画が分解されるだけのことで、**少なくとも全体の大まかな計画は立てなければなりません。**また、スクラム方式が初めての採用であるなら、スタートするまでの準備期間のスケジュールも組んでおく必要があります。関係者への根回しや説明、勉強会やセミナーの実施、進め方の決定、会議体やレビューボードの設定、役割分担など、やるべきことは山ほどあります。それらを進めるための*緻密なスケジュールも必要*です。これらを飛ばしていきなり着手するのは、飛行プランも立てずに飛行機を飛ばすようなものです。

###  4.企業や組織の体質に合っていない

アジャイル型開発が適した組織やプロダクトがあります。**若い組織、古い考えに侵されていない組織、あるいは従来のプロダクトとは全く異なる新しいプロダクトにおいてアジャイル型開発は向いています。**

一方、古い組織や成熟したプロダクトを対象にアジャイル開発、スクラム開発がブームだからと飛びついたら、失敗する可能性が高まります。スクラム開発を検討する際は、どの開発方式がベストパフォーマンスを得られるのか、きちんと精査することが求められます。

###  5.スクラム・マスターが役目を果たせていない

スクラム・マスターはスクラム開発におけるリーダー役ですが、一般的なリーダーとは立ち位置が異なります。**スクラム・マスターはチームを牽引するというよりは、ユーザーとの調整弁であり、チームのドクター的存在**で、チームメンバーのサポートに徹しなければなりません。一般組織の古いタイプの管理者のような振る舞いをしてしまうと、メンバーが萎縮し、それぞれの能力を発揮できなくなることがあります。スクラム・マスターはスクラム・マスターとしての研修を受け、しっかり役割を認識しておく必要があります。

## スクラム開発を成功させるためには

従来型の開発手法、**ウォーターフォールはあくまでもプロセス重視ですが、スクラム開発は人であり、マインド**です。細かいプロセスが規定されているわけではなく、あくまでも*メンバーが主役のやり方*です。スクラム開発成功の鍵はそこにあると言えます。以下、もう少しかみ砕いて説明をしていきます。

### スクラム開発(アジャイル開発)を正しく理解する

先ほど、スクラム開発の失敗原因として、コンセンサス不足をあげました。スクラム開発は関係者の理解が最大の力になります。まずはアジャイルの考え方、マインドを関係者が正しく理解することが前提です。それはシステム部門だけではなく、経営層、マネジメント層、人事や管理部門、関係者全員の正しい理解が必要です。*「アジャイル型組織」とは変化即応型で、迅速な意思決定と対応ができる組織*です。できれば、経営者の理解と共感を得て、**企業そのものを「アジャイル型組織」に変革できれば、それがベストです。**まずは、企業変革と併せて、スクラム開発方式を利用できると、成功に大きく近づくでしょう。

### 目指すゴールを全員が共有する

システムやプロダクト開発には必ず目的があり、ゴールがあります。スクラムチームとして何を目指すのか、メンバーの意見を集約しながら目指すゴールを設定し、それを全員で共有する必要があります。**メンバーのベクトルが一致した時に組織は最大限の力を発揮できます。**また、なぜアジャイル開発・スクラム開発方式を導入するのかについても、しっかり*メンバーのコンセンサス*を得ておくことが大事です、スクラム開発にはスクラム方式のルールがあります。ゴールを決め、ルールに従って進めていくことが成功の秘訣です。

### チームメンバーが主役であることを忘れない

スクラム開発のチーム*メンバーは全員が主役*です。主役ということは、メンバー1人1人を尊重し、その働きに対して感謝をすることからスタートします。**スクラム・マスターがメンバーを尊重し、感謝の気持ちを伝えることで、チームメンバーが相互に尊重し合い、強い結束力が生まれます。**チームに必要なのはロボットではなく、人です。血の通った人間です。*ともに悩み、ともに汗を流し、ともに喜びを分かち合う仲間*です。アナログ的な発想かもしれませんが、*これがスクラムの強みとなるのです*。

アジャイル開発の中でも重要な位置を占めるスクラム開発ですが、スクラム開発に失敗するとプロジェクトそのものがとん挫しかねません。スクラム開発の概要、メリット・デメリットを知り、アジャイル開発を成功に導くスクラム開発の効果的、効率的な方法について学びましょう。

1.アジャイル開発の1つの手法、スクラム開発の主役は1人1人のメンバー

2.スクラム開発はメリットが多い反面、使い方を誤ると失敗する

3.ウォーターフォール開発はプロセス重視だが、スクラム開発はマインド重視

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

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

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

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

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

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

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

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

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

このように、時代の変化にそぐわなくなってきたウォーターフォール開発に代わって、仕様変更に柔軟に対応できるアジャイル開発が主流となってきましたが、**アジャイル開発にもいくつかの手法が存在します**。ここでは代表的な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人材の不足は深刻化*しています。この**限られた時間の中で、システム開発のスピード、生産性を飛躍的に向上させる必要があるからこそ、スピード開発に強いアジャイル開発が求められるのです**。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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