要件定義から設計、コーディングをしてレビューとテストを挟んで本番稼働するというのがよくある開発の流れです。
この流れ、実は名前がついていて「ウォーターフォール開発」と呼ばれています
このウォーターフォール開発は、納品スケジュールや人手が予想しやすい一方、手戻りが発生すると納期を圧迫してデスマーチ開始…なんてことも。色々なソフトウェアが出回る今、毎回開発計画を丁寧に作っていく暇があるともいえません。
そこで注目されている開発手法が、アジャイル開発。
特にスタートアップでよく見られる手法なので、新進気鋭の会社で挑戦したいエンジニアは知っておくべき事項です。今回はアジャイル開発についてざっと説明します。
\エンジニアに上場企業の給与と自由を/
アジャイル開発とウォーターフォール開発、何が違うの?
名前は聞いたことがあるけど、結局どう違うの?
すごく簡単にいうと、アジャイル開発はすべてが同時進行で進みます
アジャイル開発と従来のウォーターフォール開発との違いを、4つの観点で説明しましょう。
1.開発工程の進め方
1つ目は進め方です。ウォーターフォール開発は要件定義を行い、内容が固まり次第設計書を書いて、設計書ができたら開発……と、一工程ごとに内容をすべて決めてから進めます。テスト後、バグを徹底的につぶして100%完成したものをリリースします。
一方、アジャイル開発は「計画・設計・実装・テスト」のワンサイクルを短いスパンで繰り返します。
なので、「とりあえずこの機能を完成させてリリースする」という進行方法が可能です。
リリース後も「やっぱりこの機能必要だね」「バグが発生しているから、機能追加のついでに改修しよう」という感じで機能を追加しながら改良を重ねます。
2.ユーザーの声を取り入れる方法
2つ目はユーザーの声を入れるタイミングです。
ウォーターフォール開発の場合、要件定義のタイミングでユーザーの声を聞きます。いざ開発に入ってしまうと方針変更が難しく、開発途中で変更が入ると納期なども変更になり、エンジニアへの負担が増えてしまいます。
一方でアジャイル開発は優先度が高い機能をリリース後、すぐに次の機能開発に着手可能です。
新機能開発中にユーザーの声が聞けて、ユーザーの要望のほうが優先度が高ければ、すぐに開発内容を差し替えられます。
3.開発途中の追加対応
3つ目は、開発途中に追加があった場合の対応です。
従来のウォーターフォール開発で追加があった場合、頭を抱えることはありませんか?
えぇ…追加機能分の工数の見積もり出して、人工(にんく)も計算しなおさなきゃ…
ウォーターフォール開発は、内容を固めてから次のステップに行くのが基本。開発途中に変更が入ると、追加分の要件定義から始めなければいけません。
一方でアジャイル開発は開発サイクルが細かいので、仮に機能追加があっても柔軟に対応可能。仕様変更にとても強く、よりよいプロダクト開発に注力できます。
4.ミスや手戻りが発生した場合の対応
4つ目はミス・手戻りが起きた時の対応です。ウォーターフォール開発でミスや手戻りが発生すると大変です!
納期に間に合わせるように残業増やさなきゃ…!
手戻り対応していたら、別で進めてる開発が滞る!うわぁ~~~…
このミスや手戻りの内容次第では、炎上案件が生まれてしまいます。
アジャイル開発の場合は、開発中の機能と並行して再度設計しなおす、といった対応もしやすいのが特徴。開発速度が速いので、仮にリリース後の不具合が起きても修正にかかる工数が少なく済みます。
アジャイル開発が活かされる場面
最近色々なアプリが出ている中、一部のアプリ開発ではアジャイル開発を積極的に取り入れています
実際にアジャイル開発を行っているアプリケーションはたくさんあります。例えば…
- 大手旅行会社の予約アプリ
- 地方銀行の決済アプリ
- インターネットラジオサイト・アプリ
- 大手グルメサイト…アジャイル開発を採用業務に応用
例外ですが、スタートアップ企業の中にはアプリケーションだけではなく、採用フローをアジャイル化して、より現場主導で採用活動を進めるという事例もあります。
リベロエンジニアでは小規模な開発の場合は、アジャイル開発になる傾向があります。
クライアントの要望を叶えるためには、アジャイル開発のほうが最適であれば、こちらから提案することも
大規模開発だと、クライアントの社内体制によっては、ウォーターフォール開発にせざるを得ないんでしょうね~
\エンジニアに上場企業の給与と自由を/
アジャイル開発(スクラム)における登場人物
アジャイル開発には種類があります。一例ですが、下記のような開発手法が存在しています。
- エクストリーミングプログラム…仕様変更への対応力に特化した手法。仕様変更が多いシステムとの相性がよい
- ユーザー機能駆動開発…機能ごとの開発チームを分けて対応する手法。大規模プロジェクトでも難なく導入できる
- リーンソフトウェア開発…某自動車メーカーの生産方式であるリーン生産方式を用いた開発。大手検索サイトで採用されている
- 適応的ソフトウェア開発…継続的な仕様変化に対応しやすい開発方法。未確定情報が多い中開発を進めるので、導入する際の難易度が高め
とくに有名なのが、スクラム(スクラム開発)です。
スプリントという1〜4週間の開発工程を複数回繰り返す手法で、スクラムというチームで開発に取り組みます。スクラムでは、きちんと役割分担をすることが重要とされています。
スクラムはラグビーのスクラムと同じ意味で使ってます
この項目では、スクラムにおける登場人物についてご紹介しましょう。
スクラムマスター
もっとも重要な役割ともいえるスクラムマスター。スクラムを作り、定期的に行うスクラムイベントを主催し、トラブル時には開発が止まらないよう、問題解決に向けた旗振り役を担います。
スクラムを進めるためには色々ルールがあるのですが、そのルールの浸透普及に努めるのもスクラムマスターの重要な役割です
役割を聞いただけだと「PMみたいなものなの?」と思うかもしれません。PMのようにプロジェクトを管理するのではなく、関わる人全員がスクラムのモットーに沿って動けるよう環境を整えるのが、スクラムマスター最大のミッションです。
例えば、スクラム開発では目的ごとにミーティング(スクラムイベント)を頻繁に行います。毎日行うデイリースクラムに進捗確認を行うスプリントレビューなどいろいろありますが、これらを主催するのがスクラムマスターです。
スクラム開発も結構ややこしいですよね~。何かわかりやすい、いい記事はないだろうか…
PO(プロダクトオーナー)
プロダクトオーナーはプロダクトの責任者です。いかに市場に求められるプロダクトを作るかに注力し、売れるプロダクト開発のための環境整備を進めます。
マーケティングや効果分析、企画立案に経営層との交渉などビジネス領域の知見が必要になってきます。
開発現場も見に行くけど、あくまでスケジュール通り行っているかの確認程度
メンバー
最後に紹介するメンバーは、実際に開発をするエンジニアを指します。スクラム開発においてPMとエンジニアのようなはっきりとした上下関係は存在せず、メンバーからPO・スクラムマスターに意見する場面が比較的多いです。
ウォーターフォール開発のようなマネジメントする/されるという意識は薄いんですよね~。全員の立場が平等なので
さいごに
最近はプロダクトの種類が増えて、改修までのサイクルが早いほうが、よりニーズを満たしやすくなっています。開発サイクルが早く、プロダクトの改善を素早くできるアジャイル開発は色々な案件で採用され始めています。
アジャイル開発=スクラム開発となりがちですが、実際にはプロダクトや開発環境に合わせて手法を選ぶのが普通です。
でも、文字だけじゃイメージしにくいんだよなぁ…
じゃあうちのアジャイル開発の事例、直接説明しようか?
先ほどお伝えした通り、リベロエンジニアでもアジャイル開発案件がいくつか存在しています。
無料で行っている面談では案件の詳細をお伝えできるので、「結局アジャイル開発ってなんなの?」という方は一度お話してみましょう!転職の意向がなくてもOKですよ!
\エンジニアに上場企業の給与と自由を/