↑Google翻訳でアジャイルを翻訳した結果

アジャイル開発では開発チーム単位で、限られた時間の中でこういうものを作ろうね、ってやっていく感じですね。

で、それでどんなものがアウトプットできるかを定めてやるわけです。

アジャイル以外の開発の場合、大体は作るものが定まっていて、そのためにスケジュールを立てて、費用はどんなもんか、あわなかったら機能を削るか他をこのようにしようと決めていきます。

そうなると、開発途中に運用変更があったら。そのシステムの仕様も変更する必要があるのですが、手戻りのコストがバカ高いです。なぜなら全ての仕様を決めて動いているから。

でも、アジャイル開発の場合は、期間を短く決めて、作るもの決定→仕様決定→開発→アウトプットのサイクルで反復（イテレーション）しながら、やっていくので、途中の運用変更にも柔軟に対応させることができます。

どんな開発スタイルがあるの？

それについてもこちらでまとめられているので、抜粋です。

（と思ったら、ほぼコピペになっちゃうので、独自解釈して書きます）

ボクシルマガジン：アジャイル開発とは | 他のソフトウェア開発手法との比較・違い・メリット

ウォーターフォール

開発工程の上流工程（打ち合わせ、設計など）から下流工程（コーディング、テストなど）を一貫して進めていく開発スタイルです。滝が流れ落ちるように進めていくので、「ウォーターフォール」と名付けられたと高校の時にならいましたｗ

仕様を固めて一気に開発できるので、効率がいいです。

設計と開発と分けてできるので、大手と下請けではこの方法が用いられることが多いです。

ただし、仕様を固めているので途中の仕様変更に弱いところがあります。運用がコロコロ変わっていくタイプの企業の場合、オススメできません。

プロトタイプ

プロトタイプという名の通り、試作を作ってレビューをして、こういう機能にしていこう、でまた施策を作ってレビューをして、とどんどんよくしながら進めていきます。

最初から仕様が明確になってなくても、プロジェクトを開始できます。途中から仕様がはっきりしてきたときに費用がかかりやすい部分はあります。

実際にモノを見てみないとわからないんだよね、ってタイプの担当者さんがいる企業の場合は、プロトタイプで開発していくのがいいかもしれないです。

スパイラル

プロトタイプやアジャイルに似ており、説明をすると混乱するので省きます。気になる方は元記事をご覧ください。

アジャイル開発の手法はどんなものがある？

もうこの記事はただのまとめだよね、例によって既にまとめられているものがあるので、それを参考にして説明します。

発注ラウンジ：アジャイル開発とは？今さら聞けない開発手法のメリット・デメリット

スクラム開発

開発チームのコミュニケーションを大事にしており、チーム一丸で取り掛かる開発手法です。

作るもの決定→仕様決定→開発→アウトプットのサイクルで反復（イテレーション）を自分たちで決めてやっていきます。イテレーションごとに品質OK？　進捗OK？　をチェックしながらやっていきます。

アジャイル開発の中でも、これが一番オーソドックスなようです。

エクストリーム・プログラミング（XP：Extreme Programming）

これについては、お恥ずかしながら初見なので引用します。

事前に立てた計画よりも途中変更などの柔軟性を重視する手法です。初期の計画よりも技術面を重視しているため、プログラマー中心の開発手法といえます。

開発者にやさしい世界。

ユーザー機能駆動開発（FDD：Feature Driven Development）

これについても、初見です。名前から何となく察せられるけど、引用します。

実際に動作するソフトウェアを適切な間隔で繰り返す手法で、顧客にとっての機能価値（feature）という観点で開発が進められているのが特徴です。実際に動作する機能を開発するには、ユーザー側のビジネスの見える化を行います。

ユーザーにやさしい世界。

大手がアジャイル開発するとダメなの？

今までは、ウォーターフォールな開発で大手が設計して下請けに流す、というのがありました。

（大手は設計すらしていないかもしれませんが）

こういう仕様で、この費用というのが明確になっていたからこそ、ある程度の仕様変更には追加費用をもらって対応というのができました。

アジャイル開発は基本的にざっくりとした方向性を決めてフットワーク軽く進めていく短期間開発を繰り返すものなので、その開発手法によって、下請けがさらに地獄になるのでは、と考えている人が多いのではないかと思います。

上記にも書いていたように、ウォーターフォールは仕様変更に弱いが、アジャイルは仕様変更に強いため、これからの時代に適していると読んでの、アジャイル人材を増やそうとしているのだと思います。

ですが、「アジャイルだから仕様変更あるのは当たり前という前提なの、わかってるよね？　じゃあ無償対応でよろしく」と下請けに押し付けられそうなイメージを持つのもわかります。

アジャイル開発は内製の場合良いと思うのですが、外注エンジニアを使う場合は適していないかもしれません。

大事にしてよね、エンジニアを。

こうやって考えてみると社内SEのお仕事はアジャイル開発なことが多いかも。

改めて情報をまとめてみると、僕が現在開発しているのは、アジャイル開発でスクラムしているんですね。最近流行っているから、こういうやり方をしようといって始めたわけではないのですが、自然とそうなっていきました。

僕はシステム開発をする会社で働いているわけではなくて、特定の商材のEC販売している会社の社内SEなのですが、そのSE間で話し合いながら進めることが多いです。

そうやって考えてみると、小中規模の開発チームにとって、アジャイル開発が一番自然な姿なのかもしれません。

今はクラウドサービスの開発2次フェーズで今月末完成に向けて必死に頑張ってます。

ちなみに今の時点でやりたいことが多すぎて、6次フェーズぐらいまで先を考えてたりしますが、これも社会の流れや求められる機能のニーズによって優先度を変えてやっていきます。

誰かに作ってと言われて作っているのではなく、これが必要、あれが必要、とエンジニア主体での開発をしているので楽しいです。

これからもアジャイル開発を採用するところは増えていくと思いますので、理解を深めておきたいですね！

技術論