## アジャイル開発が失敗するときのパターン

アジャイル開発が失敗するのは、プロジェクトが「*生き物*」であることを忘れてしまったときです。木に竹をつないでも成長しないように、**従来の開発姿勢に「アジャイルの良さそうなところ」を接ぎ木しようとしても上手くいきません。**

アジャイル開発を導入しようとして失敗するパターンに共通しているのが、*プロジェクトという生き物（有機体）への不適切な介入*です。それには下記のようなパターンがあります。

### トップが理解不足のまま「アジャイルで行こう」と指示する

経営トップ、あるいはクライアントであるユーザー企業から「このプロジェクトはアジャイルで」とオーダーされても、開発現場がすぐに順応することはできません。

特に、トップがアジャイル開発についての理解が不十分で、プロジェクトが機能する環境や支援を与えずに現場に「丸投げ」すると、成果を得る前に現場は枯死します。

トップがまず配慮すべき環境（土壌）とは、「契約と計画」を第一義とする従来のプロジェクトの枠組みをどのように、あるいはどこまでアジャイルに（柔軟に）するかということです。**契約ありき・計画ありきの従来の価値観のまま、現場にアジャイル開発を要求するのは、砂漠で稲を育てようとするようなものです。**

### アジャイル開発を「手法」「ソリューション」と考える

アジャイル開発を「開発手法の1つ」と考えたり、「従来のプロジェクトにあった問題のソリューション」と捉えたりするのも、失敗に終わるパターンの1つです。

アジャイル開発を最初に提唱した開発者たちが書いた有名な文書に「*アジャイルソフトウェア開発宣言*」があります。そこに記されているのが次の「宣言」です。

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

これは、アジャイル開発が根付いて育ち、実を結ぶ環境が従来のウォーターフォール開発とは全く異なることを示しています。つまり、**アジャイル開発は単なる手法やソリューションではなく、1つの「ソフトウェア開発文化」**なのです。

ウォーターフォール開発の文化にアジャイル開発の「良いところ」を部分的に取り入れようとするのは、喩えて言うなら、明治維新のときの日本がちょんまげ2本差しのままで（士農工商の身分差別を温存したまま）文明開化をしようとするようなものでしょう。

### 指導者不在のままプロジェクトをスタートする

プロジェクトマネージャにアジャイル開発の経験・理解が乏しい場合も、失敗の確率が高くなります。「プロセスやツールよりも個人と対話を」を重視するはずが、**個人のモチベーションを高めることができず、クリエイティブなコミュニケーションを引出すことができない**からです。

「動くソフトウェア」を2週間ごとあるいは1月ごとに作ろうとしても間に合わなかった場合は、ユーザー企業が激怒するかもしれません。「ドキュメントよりも動くソフトウェアを」といっても、品質管理部門が、ドキュメントも要求してくるかもしれません。そんなときのPMやスクラムマスターの対応次第で、チームの士気が一気に低下する可能性があります。

### ユーザー企業を巻き込むことができない

初期の計画よりも変化への柔軟な対応を旨とするアジャイル開発では、ユーザー企業を巻き込んでプロジェクトを進めていく必要があります。

「アジャイル開発宣言」の補足文書である「*アジャイル宣言の背後にある原則*」で「ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません」と述べられているのも同じ意味です。

**ユーザー企業や営業とのコミュニケーションがギクシャクしている中で、あるいは丸投げされた状態では「変化への対応」が困難**で、アジャイル開発を成功させることはできません。

## アジャイル開発を成功させる5つの心得

アジャイル開発を成功させるには、発注側と開発現場の双方に、アジャイル開発が1つの「有機的なソフトウェア開発文化」だという認識が必要です。

### 1.経営サイド、ユーザー企業がアジャイル開発の本質、文化を理解する

自社開発の場合は経営サイドが、委託開発の場合はユーザー企業が、アジャイル開発の本質をよく理解しようとすることが大切です。

「アジャイルなら短期間で開発できる」「低コストで開発が可能」などの**部分的な理解、いいとこ取りの発想でアジャイル開発を指示しても上手くいきません。**

RFP（提案依頼書）に「アジャイル開発で」と書くだけではなく、*アジャイル開発を指示する場合は発注側が何をしなければならないのか*を充分に理解しておく必要があります。

### 2.契約と計画の柔軟性、変更許容度にある程度の目途をつけておく

ビジネスである以上、アジャイル開発でも契約と計画は必須です。アジャイル開発の「契約交渉よりも顧客との協調を」「計画に従うことよりも変化への対応を」という原則に従うのは簡単ではありません。

しかし、ウォーターフォール開発でも初めから粒度の細かい計画を立てられるわけではなく、変化の対応の経験がないわけでもありません。どのようなプロジェクトにも「やってみなければ分らない」ことがあるからです。

より機敏に、柔軟に対応が可能な契約や計画をどのように立てるかに対する一義的な答えはなく、**発注サイドと開発サイドが経験を積みながら相互理解を深めて行く**しかありません。それによって、プロジェクトの内容に合わせて、契約と計画の柔軟性、変更許容度にある程度の目途をつけられるようになります。

### 3.プロジェクトマネージャにアジャイル開発の経験がある人を招聘する

PM、スクラムマスターにアジャイル開発の経験が豊富な人を据えることは、関係者との協議においても、開発チーム内のコミュニケーションにおいても、プロジェクトの成否を決める重要なポイントです。

「アジャイル宣言の背後にある原則」の1つに「意欲に満ちた人々に環境と支援を与え、仕事が無事終わるまで彼らを信頼します」と述べられています。**ビジネス側と開発側をつないでアジャイル開発の原則を遂行するキーマン**となるのがPMです。

### 4.開発現場に丸投げしないでユーザー企業もいっしょに働く

「原則」のもう1つに「ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません」とあります。

2週間ごとの「動くソフトウェア」のイテレーション（反復）が間に合わなかったといってビジネス側が怒る、開発側は2週間ごとの徹夜に疲弊するというよくあるパターンを回避するには、「日々一緒に働く」しかありません。

アジャイル開発で重視される「フェイス・トゥ・フェイスのコミュニケーション」とは、エンジニアたちのコミュニケーションだけではありません。**ビジネス側の人間が不在の、開発者間だけのコミュニケーションでは議論が前に進まないことが多い**のです。

### 5.チームのメンバーを教育する機会、期間を設ける

アジャイル開発が初めてのチームの場合は、教育機会・訓練期間を設けて、*マインドセット*することが肝要です。

その役を担うのはもちろんPMで、**各プロセスにおけるシーンを想定した、経験に基づく具体的な説明**が求められます。メンバーがそれぞれに持っているアジャイル開発についての知識やイメージを修正・統一しておく必要もあります。

## 「アジャイル開発宣言の背後にある原則」を読み直してみよう

上記の各所に紹介してきた「アジャイル開発宣言の背後にある原則」を、ここで改めて読み直してみましょう。下記の12の原則には、**失敗を避けるため理解しておきたい「アジャイル開発の本質」**が端的に示されています。

1.顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
2.要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
3.動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
4.ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
5.意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
6.情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
7.動くソフトウェアこそが進捗の最も重要な尺度です。
8.アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
9.技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
10.シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
11.最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
12.チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

以上の「原則」には、**エンジニアだけではコントロールできないものが多く含まれていますが、エンジニアなしにはどれも無意味である**とも言えます。これは、まさにアジャイル開発のプロジェクトが関係者のすべてが有機的につながっている「生き物」であることを示しています。

アジャイル開発においては、どのエンジニアも「開発の駒」ではなく、「一緒に働く」「意欲に満ちた」「信頼される」人間なのです。

近年、プロジェクト開発において「これはアジャイル開発で行こう」と言われることが増えてきました。しかし、流行りに乗って安易に取り組んで失敗に終わるケースも少なくありません。本記事では、アジャイル開発が失敗するパターンと、成功に導くための心得について解説します。

アジャイル開発を便利な開発手法やソリューションと考えると失敗する

アジャイル開発を1つの開発文化と捉えて、その精神を理解することが成功の鍵

ビジネス側とエンジニアが一緒に働き、前向きに協力し合うことが肝要

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

**「アジャイル」が「ウォーターフォール」の対極にある新しいシステム開発手法**だということは、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時代に脚光を浴びる「アジャイル開発」の本命「スクラム」とは？

ソフトウェアの開発手法としては、従来主流だった*「ウォーターフォール開発」*と最近主流になりつつある*「アジャイル開発」*の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.ウォーターフォール開発はプロセス重視だが、スクラム開発はマインド重視

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

## システム開発の形態を知ろう

システム開発に携わっていると、開発方式について「受託開発」や「自社開発」という言葉が聞こえてきます。ほかには、「SES」や「SE派遣」、「請負」といった用語もあります。

こうした**契約や取引は営業や上層部が決めていますが、エンジニアとしても自分の仕事がどれに属するのか、それらがどんな意味を持つのかを知っておく必要があります。**

ここではエンジニアとして知っておくべき開発の方式について、「受託開発」を中心に採り上げながら、やさしく解説し、皆さんの疑問に答えていきます。

ITエンジニアの視点から、*受託開発と自社開発の違い*を見ていきましょう。

**受託開発とは委託先からシステムの開発を委託され、委託先の要求内容に従って開発する方式**を指します。

受託開発のイメージを具体的な例として表すと次の通りです。

*1.A社はB社に、あるシステム(ソフトウェア)の開発を依頼します。*

*2.B社はシステム要件についてA社からヒアリングし、システム提案書と見積書を提示します。*

*3.A社はB社からの提案書、見積書を精査し、社内調整を経て開発に関する経営側の承認を得ます。*

*4.B社はA社との間に、受託開発に伴う請負契約を締結します。*

*5.B社はA社との間でプロジェクトを編成し、要件定義、基本設計、詳細設計、プログミング、単体テスト、結合テスト、総合テストを経て完成品をA社に納品します。*

*6.A社は納品されたシステムを稼働させて検収を行い、問題がなければ委託費用の支払いを行います。*

大まかには以上が受託開発の流れです。

**自社開発はまさに、自社でシステムを開発する方式です。自社の企画部門などで考えたアイデアを企画書にして、然るべき会議体(企画会議、経営会議など)で承認後にシステム開発部門にシステム開発の依頼をします。**社外向けにパッケージ製品として開発するケースもあれば、自社内システムとして社内だけで利用する場合もあります。また社内開発では、開発パワーの不足をSESなどで補うケースもありますが、開発主体が社内であれば、社内開発と言えます。

ITベンダーやSIerでは、受託開発という言葉に対して、SESという言葉をよく耳にします。**SESとは(System Engineering Service)の略語で、IT企業などにエンジニアを常駐させて業務をおこなう契約形態を指します。「準委任契約」とも呼ばれる契約形態で、人月単価契約となります。**例えばSEは1人月80万円、PGは1人月60万円といった形で報酬額が決まります。報酬額はエンジニアのスキルや仕事内容によって変わってきます。この**SESでは、あくまでも労働力の提供であり、ソウトウェアなどの完成責任は負いません。派遣する側としては、リスクが少ないのがメリットです。**

SIerとSESの違いとは？それぞれの詳細から将来性まで徹底解説

「SESってSE派遣と同じでは？」と考えた方は多いと思いますが、実はこの2つは異なりますので、説明しておきます。ここを間違えると法令違反となりますので、注意しましょう。

**SES契約でクライアント企業に常駐するエンジニアは、外注契約を受注した側の企業の指揮の下に仕事を行います。**

これに対して、**労働者派遣の形でクライアントに派遣されたエンジニアは、クライアントの管理、監督下で仕事を行います。**両者は非常によく似ていますが、契約形態によって指示命令系統が大きく異なるのです。

*SESのエンジニアに対して、クライアント側の企業が直接、指示や命令を行うことは違法です。これがよく言われる「偽装請負」です。*

またITベンダーがSEを派遣する場合は、「派遣元責任者資格」が必要です。「派遣元責任者資格」を得たら、さらに「派遣事業の許可」を得る必要があります。

### 受託開発に納品義務はない？

「受託」と「請負」という契約形態があります。

**「受託」とは、クライアントからの依頼により、業務を行う契約のことです。その契約には期間、条件などが定められていますが、成果物などの納品義務はありません。**一方、「請負」もクライアントからの依頼によって業務を行いますが、**請負の場合は成果に対する責任を負います。**クライアントに対して、完成物や成果物の納品義務がある点が大きく異なります。

受託契約には「納品義務」がないことが分かりましたが、では「受託開発」にも納品義務がないのでしょうか？実は**「受託開発」は請負契約**なのです。言葉が紛らわしいので混乱してしまいそうですが、*「受託開発」は完成義務、納品義務を負います*ので誤解のないようにしてください。

受託開発の概要については理解されたと思いますが、より理解を深めるために、そのメリットについても確認しておきましょう。但し、*メリットはあくまでも発注者側の視点でのメリット*です。

自社で新たにシステムを開発する場合、システム開発のリソース(要員、時間、手間)確保の負担が大きくなりがちです。受託開発方式を採用し、システム開発を外出しすることで、**自社のリソース負担を抑えることが可能になります。**受託開発の場合は、複数社によるコンペが一般的で、*価格競争によるコスト引き下げが期待*できます。

自社開発方式では、自社内にエンジニアを確保する必要があります。システム開発の業務量に波があるため、ある程度の余裕を持った人員確保が必要なため、人件費が水膨れしがちです。**受託開発を併用することで、要員過剰や要員不足を防ぎ、安定開発が可能になります。**

### 開発ノウハウの吸収ができる

受託開発を採用することで、自社だけではなかなか獲得ができない**システム開発ノウハウを、外部企業から吸収することが可能**となります。このノウハウを吸収するためには、外部企業に丸投げするのではなく、*自社も主体的に関わるという姿勢が求められます。*

受託開発には前記のようなメリットがある反面、デメリットがあることも理解しておくことが求められます。*デメリットは発注者側の意識や姿勢によっては解消することも可能*ですので、デメリットを理解した上で採用することが必要です。

### 自社のエンジニアの成長機会が減る

当然のことですが、**自社のシステム開発を外部企業に委託すれば、自社エンジニアが関わる機会は減り、成長の機会が制限される**のは致し方ないことです。それを防ぐには、可能な限り、自社のエンジニアもプロジェクトに関わらせることが必要です。開発作業そのものはアウトソーシングしても、定例ミーティングやレビュー会議など、受託開発企業との接点をできるだけ設け、**自社エンジニアの参画機会を極力増やすことが望ましい**でしょう。

幅広いIT知識とスキルを求められる「社内SE」について徹底解説！

### 開発着手後の仕様変更や改良が難しくなる

*丸投げ*のような形で、システム開発の外出しをしてしまうと、**仕様変更が難しくなるばかりか、システム稼働後の改良も困難になります。**ユーザーの立場から要件定義やレビューに能動的に関わり、あくまでも*プロジェクト管理の主体は自社にあるという意識を持って受託開発を活用する*ことをおすすめします。

**「受託開発は終わった」「受託開発はオワコン」といった声がありますが、実際のところはどうなのでしょう。**そう言われる*理由と、今後の受託開発の方向*について考察をしてみましょう。

受託開発は終わったと言われる主な理由は次の通りです。

受託開発を依頼すると、見積書に提示される人月単価に唖然とすることがあります。この見積もり方式は何十年も変わっていません。まるで人をモノのように扱うことには抵抗すら覚えます。また*"人月単価が高い=優秀"ではありません*。こうした前時代的な見積もりを続けている限りは受託開発への期待は下がる一方です。

一方、*ステップ単価での見積もりをする受託開発会社もあります*が、ステップ単価にも合理性は見出せません。**クライアントを納得させられる見積もり方式を編み出す必要性**を感じます。

**クラウド技術の進展と普及が、システムの形を根本から変えようとしています。**SIer業界のあり方を大きく変えると言われています。クラウドが普及する以前は、メーカー系の大手SIerが自社の大型サーバと抱き合わせで大規模システムの開発を請け負っていました。ハードとシステム開発がセットになり、その価格の合理性、妥当性もあいまいなまま、出精値引きという文言に誤魔化され、顧客は何の疑問も持たず発注をしてきました。

クラウドの進展によって、今はハードを1から調達する必要もなく、初期投資は最小限で、利用した分だけ費用を払うという従量制料金体系のおかげで、システム開発が見える形になってきました。

この**クラウド化の結果、中小企業やベンチャー系IT企業の活躍分野が広がり、しかも従来型のウォーターフロー型開発から、アジャイル型開発に移行し、大手SIer企業による受託開発の強みが失せてきた**というのが現実ではないでしょうか?

### それでも受託開発は残り続ける

政府系、自治体、大企業中心の大規模案件はDXブームのおかげで残っていますが、*中小を中心にクラウドやWeb、スマホ中心のシステム開発が中心となっており、大手Sierがその辺をカバーしきれていないのが実情*です。

とは言っても、企業のシステム化ニーズがある限り、受託開発はなくならないでしょう。専門分野は専門家に任せるという発想は一般化しており、アウトソーシング化の流れは変わりません。まして、DX推進が企業の義務にもなっている今日、**システム化の需要は増えることはあっても、減ることはありません。しかし、その需要に応えていくには、受託開発の在り方そのものが見直される必要があります。**エンジニアの単価で見積もるような受託開発はもはや限界です。またSIerもその認識は持っており、クライアントを納得させられる見積もり手法を編み出しています。システムは投資です。投資を上回るリターンがあれば、システムを開発する意味があります。そのリターンを見積もる手法が求められています。

### エンジニアとして備えること

*DX推進、エンジニア不足*という追い風がある一方、その先を考えた時にエンジニアの方々が将来に不安を感じるのは当然のことです。しかし、現実を直視し、未来を見据えて、未来に備える事はできます。

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