**「アジャイル」が「ウォーターフォール」の対極にある新しいシステム開発手法**だということは、ITエンジニアの皆さんならご存知だと思いますが、「アジャイル」開発には「*スクラム開発*」という手法もあります。今1度ここで確認し、DX時代に対応したシステム開発手法として活用しましょう。

アジャイル開発という言葉は、今から20年前の2001年に生まれました。従来の*ウォーターフォール開発*では、「要件定義→仕様策定→設計→開発→テスト」の各プロセスごとに厳密な文書化が求められます。そのため開発プロセスは重厚で時間を要するものですが、仕様変更に弱く、*プロジェクトがしばしば頓挫するという難点*もありました。

そのような問題を解決するために、ソフトウェア工学の専門家17名が中心となって、互いの主張や考えをぶつけ合い「*アジャイルソフトウェア開発宣言*」という文書で表明をしたのがアジャイル開発の始まりでした。

ちなみに"アジャイル（Agile）"は「素早い」を意味する英語で、**アジャイル開発は、大まかな仕様が決まったら、「手直しを恐れず、まずは作る」という考え方です。「できるだけ少ない工数」で、「短期間」でシステム開発をする手法**と覚えておきましょう。

### *ウォーターフォールからアジャイルへ*

今でこそ「アジャイル開発」はメジャーな開発手法ですが、従来は「ウォーターフォール開発」が主流でした。システム開発の際、まずプロジェクトの要件定義を行い、綿密な設計を行ってから開発に着手するのがウォーターフォール開発の段取りです。「システム分析」から始まり、「システム設計」→「システム開発」→「システムテスト」→「保守」の一連の工程を、*上から下に落ちるように実行して様子が、滝をイメージさせることからウォーターフォール開発*と呼ばれています。

ウォーターフォール開発は主に汎用コンピューター（メインフレーム）で用いられたシステム開発手法ですが、**ダウンサイジングなどの新しい技術が主流となる中、ウォーターフォール型の開発手法がマッチしなくなってきたことから、アジャイル開発に置き換わってきた**のです。

### *アジャイル開発の各種手法について*

アジャイルとは開発スタイルの総称であり、アジャイルの中には「スクラム」をはじめとして、さまざまな手法があります。「スクラム」については後述しますが、スクラム以外のアジャイル開発手法を以下で紹介します。

*▪リーン開発*
無駄は「価値」の対極にあるものと捉えて、無駄を最小化し、（顧客）価値の最大化を目指す手法です。トヨタの生産方式をシステム開発に適用させたものです。

*▪ エクストリームプログラミング（XP）開発*
「コミュニケーション」「シンプル」「フィードバック」「尊重」「勇気」の5つの価値（ポイント）を重視した開発手法で、「テスト駆動開発」や「ペアプログラミング」などを取り入れて短期のシステム開発と変化への対応を実現しています。

*▪ カンバン*
カンバンは「作業を可視化」を基本とし、作業の効率（生産性）を最大化する手法です。 カンバンボード（ホワイトボードやWebボードなど）を使用して、作業フローの継続的な改善を進めます。

## スクラム開発はアジャイル開発の1つの手法

「アジャイル開発」にはさまざまな手法がありますが、「スクラム開発」はその代表的な手法で、*チームメンバーのコミュニケーションに特に重きを置いた手法*といえます。

スクラムは、ジェフ・サザーランド氏とケン・シュエイバー氏によって1990年代に編み出されたアジャイル開発の1つの手法です。

*アジャイル開発では、計画を厳密には作成しない*ため、システム開発全体の方向性が定まっていないと、個々の機能がうまく実装されていても*結果的に一貫性に欠けるシステムとなってしまうリスク*があります。これに気付く頃にはある程度システム開発が進んでいるため、修正する場合には負荷や工数が大きくなってしまうという問題があります。

**こうした問題を解決するため、アジャイル開発で多く採用されている作業管理のフレームワークが、「スクラム」です**。スクラムはプロジェクト管理の枠組みで、「チームの統制」や「コミュニケーション」を重視します。また、スクラムにはアジャイル開発の最大の特徴ともいえる柔軟性や自由さを保ちつつ、チームの意識統一を高め、プロジェクトを円滑に進めるという利点があります。

詳細は[スクラムガイド](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese-2.0.pdf)を参照ください。

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

*1.機能単位での開発*
機能をプロダクトに対する要望の高いものから優先順位をつけ、その順位に従って機能を構築します。

*2.個別の開発期間を短期間で設定*
機能ごとの開発に区切り、その中で開発計画を立てます。個々の期間は1週間から最大4週間程度です。この期間のことをスプリントと称します。

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

*4.プロダクトの機能のレビュー*
機能がユーザーの要望に合致しているかを定期的にレビューします。

スクラム開発ではチームの単位で活動を行いますが、チームメンバーは3人～10人程度で編成します。またその活動主体はメンバーであり、*リーダーはおらず主役はメンバー*です。

*1.プロダクト・オーナー*
プロダクト・オーナーの役目はチームの舵取りです。チームへの口出しはせず、チームメンバーが主体的に最高のパフォーマンスが発揮できるように、*側面サポート*します。

*2.スクラム・マスター*
スクラム・マスターの位置づけはメンターです。メンターとはよきアドバイザーのことで、スクラム・マスターとメンバーは対等な関係にあります。メンバーが悩みや問題に目を向けて、その改善や治療を行う*ドクター的な存在*です。

*3.メンバー*
スクラム開発のチームにはリーダーがいない代わりに、舵取り役のプロダクト・オーナー、ドクター的存在のスクラム・マスターがいます。どんな組織にもリーダーはいますが、スクラムではリーダーは存在しません。**全員が対等で、全員が主役**です。スクラム・マスターはリーダーに近い存在ですが、チームをリードするのではなく舵取りでメンバーをサポートします。スクラムチームの主役はメンバーの1人1人だという点を覚えておいてください。

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

スクラム開発はアジャイル開発の優れた1手法で多くのメリットがありますが、デメリットも存在します。スクラム開発についての理解を深めるために、メリット、デメリットについて確認しましょう。

*1.チームメンバー全員が主役*
ラグビーのスクラムをイメージすると分かりやすいと思いますが、スクラム開発の主役はチームのメンバー全員です。スクラムを組んでシステム開発を進める上では、**チームの1人でも手抜きをするとスクラムが崩れてしまいます**。そうならないよう、チーム全員がモチベーションを高め、維持しながら取り組めるように努めるのがスクラム・マスターです。

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

*3.計画通りに開発が進行*
スクラム開発では、**機能単位に工数を見積もって開発**を進めていきます。機能単位でテストを行うので障害の早期発見、早期対応が可能で、*計画通りに開発が進行する*確率が上がります。

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

スクラム開発は開発スピードを高め、効率的な開発手法ですが、条件や状況によっては思うような効果が得られない可能性があります。

*1.メンバーの協力体制が整わない*
スクラム開発のチーム活動は最短で1週間です。不慣れなメンバーばかりでチームが編成された場合、準備や習熟に時間を要し、メンバーがそれぞれの力を充分に発揮することなく活動が終了してしまいます。**開発のリズムを維持するためにもメンバー編成をなるべく変えずに進める**ことが大切です。

*2.コミュニケーション能力に左右される*
スクラム開発では毎日行われるミーティングで、自身のタスクの進捗状況や課題について簡潔に発表するとともに、他のメンバーの進捗状況を正しく理解することが求められます。**仕事ができてもコミュニケーションが苦手というエンジニアはスクラム開発に向いていません**。その点に留意してメンバーの人選や育成を行うことが求められます。

*3.開発全体のスケジュール管理がしにくい*
スクラム開発は柔軟な開発がメリットですが、逆にそれが仇になることがあります。柔軟であるが故に、開発の方向性の変化やスケジュールのぶれが生じることがあります。また機能単位に工程が細かく分かれていることから、*全体スケジュールの管理が難しくなる*というデメリットもあります。

## スクラム開発を失敗させない秘訣

従来型開発手法のウォーターフォールはプロセス重視で、手順も細かく規定されています。一方、スクラム開発の細かいプロセスは規定されておらず、柔軟な開発スタイルとチームメンバーが主役のやり方です。このスクラム開発を成功に導く鍵はそこにあります。スクラム開発を成功に導く秘訣について解説していきます。

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

先ほど、スクラム開発が失敗する要因として、コンセンサスの不足をあげました。スクラム開発は関係者の理解が大前提です。まずは**関係者全員がアジャイルの考え方やマインドを正しく理解する**必要があります。システム部門ばかりではなく、経営層・マネジメント層・人事部門・管理部門など関係者全員の理解が必要です。

変化即応型の「アジャイル型組織」への組織変革が求められるのです。*システム部門だけではなく、企業そのものを「アジャイル型組織」に変革することができれば、成功に向かって大きく前進*するでしょう。

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

システムの開発には、必ず明確な目的や目標があります。チームのメンバーのベクトルがずれていると、スクラム開発は成果を上げるのが難しくなります。スクラムチームが何を目指すのか、**メンバーの意見を集約して目指すゴールを設定し、共有する**ことが必要です。

また、なぜスクラム開発方式を採用するのかについても、しっかりメンバーのコンセンサスを得ることが大事です。ウォーターフォール開発をイメージしているメンバーが1人でもいると、そのメンバーによってスクラムが崩れます。スクラム開発は柔軟な開発手法ですが、スクラム方式には一定のルールがあります。きちんとゴールを定め、チームのルールに従って進めていくことが成功の秘訣です。

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

スクラム開発ではチームメンバー全員が主役です。メンバー全員が対等であり、1人1人を尊重し、その働きを褒めたたえる、感謝をするところからスタートさせます。スクラム・マスターは個々のメンバーを尊重し、*感謝やねぎらい*の気持ちを伝えると、**メンバーが互いに尊重し合い、チームとして強い結束力が生まれます**。スポーツチームのように、一緒に汗を流し勝利を喜び合う仲間という意識の一体感が鍵です。これこそがスクラムの最大の強みとなるのです。

## DX時代にこそ求められるスクラム開発

ジェフ・サザーランド氏が編み出した開発手法を、『アジャイルソフトウェア開発スクラム』という本にまとめて発表したのは2003年のことですが、実際にサザーランド氏がスクラム開発を提唱したのは、そのさらに10年前だといわれています。

この30年近い歴史を持つアジャイル開発手法が、今注目されているのには理由があります。それは、政府主導で*DXの必要性が叫ばれ、ビジネス領域とITとの距離が一気に縮まったから*ではないでしょうか。

アジャイル開発の概念が生まれた約20年前、ソフトウェア開発はエンジニアだけの世界でした。今やDX時代に入り、DXの取り組みを通じてビジネス変革を推進する企業では、企業そのものがIT的な組織になっています。アジャイル思考を持つ人材がDXを主導しています。

システム開発手法やアジャイル的な組織づくりが経営課題となっています。スクラムはシステム開発のみならず、あらゆるブロジェクトに適用が可能です。プログラム開発手法やノーコード開発よりも、**スクラム開発のためのアジャイルチームづくりがDX成功の大きな鍵**となっています。

「スクラム開発」はDX時代に脚光を浴びるアジャイル開発の1つの手法で、ラグビーのスクラムのようにチーム全員が主役となる手法です。あらゆるプロジェクトに応用できる「スクラム開発」を身に付け、DX時代をリードするITエンジニアを目指してスキルアップを図りましょう。

「スクラム開発」はDX時代の開発手法として注目される「アジャイル開発」の主な開発手法である

「スクラム開発」を成功に導く鍵は、目的やゴールをチーム全員が共有することにある

DXを成功させるには、組織をスクラムを中心としたアジャイル組織に変えることである

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

従来、システム開発やソフトウェアの開発手法は、ウォーターフォール開発が一般的でした。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人材の不足は深刻化*しています。この**限られた時間の中で、システム開発のスピード、生産性を飛躍的に向上させる必要があるからこそ、スピード開発に強いアジャイル開発が求められるのです**。

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

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

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

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

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

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

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

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

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

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

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

アジャイル開発の記事（2ページ目）