2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
ログミーTech 用語解説「アジャイル開発」(全1記事)
リンクをコピー
記事をブックマーク
アジャイル開発とは、ソフトウェアを開発する手法のひとつです。ソフトウェアを機能ごとに小さく分けて、小さな単位での設計、実装、テストという工程を反復しながらプロジェクトを進めていきます。
小さな単位で開発を進めることから、開発途中での仕様変更や機能追加にも柔軟に対応可能で、ある程度は見切り発車的に開発を進めることができます。ソフトウェアの短期開発にもつながる柔軟な考え方から、アジャイル(Agile:機敏)と名付けられました。
アジャイル開発というと、スクラムなどの開発手法そのものに注目が行きがちですが、そもそもアジャイル開発とはより良い開発方法を求めてたどり着いた考え方を指す言葉です。その考え方については、2001年に17人の開発者が議論の末に公開したマニフェスト「アジャイルソフトウェア開発宣言」に示されています。
私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。
「アジャイルソフトウェア開発宣言」より引用。
このマニフェストを実現するために、スクラムといった開発手法が用いられています。
【関連記事】
ソフトウェア開発の手法として古くから用いられているものに、ウォーターフォール開発があります。開発の始まりを上流、終わりを下流に見立てて、滝(ウォーターフォール)の水が流れ落ちるように、一方向へ順に開発を進めていく開発手法です。
ウォーターフォール開発では、開発初期段階に行う要件定義や設計を重要視しており、詳細に至るまでの計画書をしっかり作り上げてから開発に移ります。計画書どおりに作業工程をこなしていけば完成へと向かっていくのが、ウォーターフォール開発です。
ウォーターフォール開発の特徴
アジャイル開発の特徴
アジャイル開発は、次に挙げるようなプロジェクトに適しています。
要件定義の全体像が明確ではないプロジェクトとは、主に既存経験のないソフトウェア新規開発が当てはまります。作りたいソフトウェアのイメージはあるけれど、どのような機能が必要か把握しきれていないようなケースです。そんな時は企画段階で詳細まで詰める必要がなく、把握している部分から開発を進めて徐々に機能を増やしていけるアジャイル開発が適しています。
変化の激しい分野とは、市場のニーズに左右されやすかったり、新技術が次々と登場したりする分野です。市場のニーズに左右されるのは、ビジネスにとっては当たり前のことと言えるかもしれません。このような場合もアジャイル開発が適しており、常に最新の状況を取り入れたソフトウェア開発が可能です。
顧客との密接な連携を行えるプロジェクトでは、顧客満足度の高いソフトウェアを開発できる可能性が高まります。アジャイル開発には顧客を開発プロセスに巻き込み、コミュニケーションを重ねながら、より顧客満足度の高いソフトウェアを開発していく手法が確立されています。
ウォーターフォール開発は、次に挙げるようなプロジェクトに適しています。
要件定義がはっきりしているプロジェクトとは、既存システムのリプレースなど、ソフトウェアの機能をしっかり把握できる場合などが当てはまります。
仕様変更の発生する可能性が低いプロジェクトとは、ニーズ変化の激しい市場向けや、最新技術を扱うようなソフトウェアではなく、社内システムなど用途がほぼ固定され、仕様変更することが滅多にないケースを指します。
安定性や信頼性が重要視されるプロジェクトとは、金融システムやインフラシステムなど、誤作動が許されない分野を指します。このような分野では、時間と手間をかけてでも要件定義や設計を綿密に行い、確実に正しく動くシステムの開発が求められます。
多くの開発者が携わる大規模なシステム開発の場合は、仕事の割り振りや全体スケジュールの把握が容易なウォーターフォール開発が適しています。
ウォーターフォール開発はアジャイル開発と比べて古くて劣っているという印象を持つ人も多いかもしれませんが、ここで挙げたように仕様変更の可能性が低かったり、大規模なシステム開発といった場合はアジャイル開発よりもウォーターフォール開発が適していると言えます。
ここでは、アジャイル開発の基本的な流れを見ていきましょう。アジャイル開発は大きく2つの工程に分けられます。
リリース計画とは、製品の目標やビジョンを掲げ、開発の方向性を示す製品管理手法です。特にアジャイル開発に合わせて製品の段階的なリリースを計画する製品管理手法を、アジャイルリリース計画とも言います。
イテレーションとは、反復と言う意味を持ち、一連の開発工程を短期間で繰り返す開発サイクルのことを指します。アジャイル開発では短期間のイテレーションを終えるごとに開発の評価や見直しを行うことで、仕様変更やトラブルへの高い順応性を実現しています。
では次に、それぞれの工程について、もう少し詳しく見ていきましょう。
リリース計画の作成は、主に次のようなステップに沿って行われます。
1.目標を明確にする製品がリリースされることで、どのような成果や利益を生み出すのかといった製品のビジョンを定義し、最終的にたどり着くプロダクトの目標(ゴール)を明確にします。この目標に到達するまで、ソフトウェアの開発が続けられることを意味します。
2.プロダクトバックログのランク付けプロダクトバックログ(プロダクトを目標へ導くために必要となる機能)を確認し、各機能のストーリーポイント(難易度)を見積もったり、優先順位を決めます。
3.リリース計画会議開発メンバーや関係者を集め、リリース計画を確認するためのミーティングを行います。リリースに向けていつまでに何を達成する必要があるのか、全員で共通認識を持っていることを確認します。
また、開発チームの実力に鑑みて、1回のイテレーションの長さ(通常1~4週間)や、開発チームのベロシティ(1イテレーションでどれだけの成果を出せるかという開発力を示す値)を算出し、機能の優先順位やストーリーポイントを参考に、開発チームへタスクを割り振っていきます。これで本格的な開発がスタートします。
4.リリース計画の更新リリース計画は一度出したら終わりではなく、例えばイテレーション終了のタイミングで開発チームのベロシティを見直したり、機能の開発が間に合わなかった場合は開発の順番を組み替えるなど、状況が変わるたびに見直していくことが一般的です。
イテレーションでは、手順に則ってプロダクトへ組み込む機能の開発を行います。
1.計画プロジェクトの目標やスケジュールなどを定義し、考えられるリスクの洗い出しや対策を講じます。
2.設計アーキテクチャ設計やプログラム設計を行います。
3.実装設計に基づいてソフトウェアをプログラミングで開発します。
4.テスト単体テストや結合テストを行い、開発したソフトウェアが仕様どおり動作することを確認します。
5.改善テストで不具合が出たり改善の余地が見つかった場合は、2.設計の段階まで戻って改善を加えます。イテレーションの期間内であれば何回でも改善可能です。
6.リリース成果物を本番のプロダクトへ組み込むためにリリースします。これで1つのイテレーションが完了です。次のイテレーションへ活かすために、チームで開発時のふりかえりを行ったりもします。
これら一連の工程を1~4週間の短いスパンで繰り返していくのが、アジャイル開発の基本的な流れとなります。
【関連記事】
アジャイル開発のイテレーションで実際に用いられる開発手法には、いくつかの種類があります。それぞれに異なる特徴を持ち、プロダクトの目標や開発チームの性質で使い分けられています。ここではよく使われている3つの手法を説明します。
スクラムは代表的なアジャイル開発の手法です。選手が一丸となって突進するラグビーのスクラムが由来となっていて、開発メンバー同士のコミュニケーションが重要な開発手法です。事あるごとに開発メンバーでミーティングを行い、進捗状況や課題を共有して、一致団結でプロダクトに挑むことが求められます。
スクラムでは、チームを構成するメンバーに次のような役割があります。
プロダクトオーナーは、プロダクトの価値を最大化する最高責任者です。プロダクトバックログの管理、顧客との折衝、開発チームの連携、その他マーケティングや予算管理など、さまざまな役割を担っています。
スクラムマスターは、スクラムのコーチ的な存在です。スクラムが正しく機能しているか逐一チェックし、開発メンバーへのアドバイスや指導も行います。
開発メンバーは、実際にコーディングを行うメンバーです。プログラミングスキルはもちろんのこと、スクラムにおいてはコミュニケーション能力も求められます。
アジャイル開発では、1つの開発チームの人数を10名以下とすることが推奨されており、スクラムの場合もチームは3~10人が理想的です。
スクラムでは1回の開発期間をスプリントと呼び、スプリントの期間は1~4週間が一般的です。短期間で成果を出しやすく、変化への柔軟な対応力や生産性向上にもつながっています。
スプリント期間中には、次の4つのイベントが行われます。
1.スプリントプランニングスプリントプランニングはスプリントの最初に行うイベントで、チーム全体でスプリントの作業計画を立てます。スプリントで達成したいゴール(実装したい機能)を明確にしたり、ゴールに至るまでのタスクを1日分の作業量に分割したりします(スプリントバックログの作成)。
スプリントが始まると、途中での仕様変更などは基本的に認められないので、スプリントプランニングでは十分な検討を行う必要があります。
また、スクラムは仕様変更に対応できる開発手法ではあるものの、いったんスプリントが走ったらスプリントが終わるまでは変更を受け付けません。スプリント期間が長いと仕様変更への対応力が下がってしまう点には注意が必要です。
2.デイリースクラムデイリースクラムとは、スクラムの特徴的なイベントの1つで、スプリント期間中に毎日行う短時間のミーティングのことを言います。昨日までの進捗や本日の目標、開発の課題などを発表し開発メンバーで共有する場です。
3.スプリントレビュースプリントレビューは、スプリントが終わった後に行うイベントです。今回のスプリントの成果や今後の流れを関係者に披露して共有します。
4.ふりかえりふりかえりはスプリントの最後に行うイベントで、今回のスプリントに対する評価や反省点を議論し、次回に向けた改善点を検討します。
【関連記事】
エクストリーム・プログラミングは、仕様変更やトラブルへの高い対応力といったアジャイル開発の特徴に加え、顧客の意見や要望を取り入れられる柔軟性の高さも持ち合わせられるようにするための方法論です。
開発手法自体はスクラムと同様に、短いイテレーションでの開発を基本とします。そこにエクストリーム・プログラミングの方法論を取り入れることで、継続的な開発チームの成長が期待できます。顧客満足度の高いソフトウェアを開発するための方法論です。
エクストリーム・プログラミングでは、開発で重視すべき5つの価値が示されています。
シンプルとは、本当に必要な機能を優先したシンプルな設計に重きをおくことを意味します。
フィードバックとは、顧客からの要望を意味します。シンプルな機能のみを実装したソフトウェアに、フィードバックを得て機能を追加していく工程を繰り返すことで、無駄のないソフトウェアができあがります。エクストリーム・プログラミングでは、顧客からのフィードバックを頻繁に取り入れます。
勇気とは、変化を受け入れる勇気を意味します。最初に綿密な計画を立てないエクストリーム・プログラミングでは、途中で大幅な仕様変更が起こることもあります。
尊重とは、開発者同士や顧客とのコミュニケーションにおいて、お互いの意見や姿勢を尊重することを意味します。心地良いコミュニケーションを行う上で、不可欠な心持ちです。
これら5つの価値を踏まえた上で、エクストリーム・プログラミングにはプラクティスと呼ばれる習慣や実践内容が示されています。プラクティスは対象者別に4つに大別し、それぞれのプラクティスには4~6個の実践内容が内包されています。プラクティスと実践内容の一覧は次のとおりです。
これらの実践内容をソフトウェア開発に取り入れることが、エクストリーム・プログラミングを実践するということになります。
【関連記事】
ユーザー機能駆動開発とは、ユーザー目線で価値のある機能を中心に開発を行うアジャイル開発手法です。顧客がプロジェクトに求めるものを正確に把握することで必要な機能を選定し、顧客が必要とする機能から優先的に開発を進めるというのが基本的な流れです。
そのため、顧客との入念なコミュニケーションが重要なのはもちろんのこと、開発者側もシステムの利用場面やビジネスモデルをしっかり把握しておく必要があります。
また、アジャイル開発と言えば反復開発ですが、ユーザー機能駆動開発の場合、実際に動作するシステムを短期間でリリースして反復する部分が特徴と言えます。ユーザー機能駆動開発は、次に挙げる5つの基本活動をベースに作業が進められます。
1.全体モデル開発ユーザー機能駆動開発は、モデル駆動型の短期反復を採用する開発方式です。この開発方式では、最初にモデル図と呼ばれる仕様に沿った全体モデルを開発します。まずはシステム全体の範囲と内容についての検討を行うことから始まり、次に部門ごとの専門的なモデルを制作していきます。こうしてできあがった特定分野ごとのモデルを結合したものが、全体モデルです。
2.フィーチャーリスト構築全体モデル開発時に得られた知見をもとに、顧客の求める重要度で分類したフィーチャー(機能)をリストアップします。1つのフィーチャーは2週間程度の短期間で開発できる規模のものとし、それ以上に複雑だと考えられる場合は、さらに細かいフィーチャーに分割するなどの調整を加えます。
3.フィーチャーごとの計画フィーチャーリストをもとに開発計画を立案します。開発チームの負荷状況や、フィーチャーの複雑さや優先度などに鑑みて、どの開発チームにどのフィーチャーを割り当てるかを決定します。開発チームでは、フィーチャーごとに責任を持つプログラマ(オーナー)を決めて分担させます。
4.フィーチャーごとの設計フィーチャーのオーナーは、2週間で開発すべきフィーチャーを選択し設計を行います。その際、フィーチャーごとの詳細なシーケンス図を作成して、全体モデルの更新も行います。
5.フィーチャーごとの構築設計が完了すると、コーディングでフィーチャーの実装を行います。
ユーザー機能駆動開発は、多くの開発チームにフィーチャーを割り当てて開発を進められるので、アジャイル開発の中でも大規模プロジェクトに対応しやすいという特徴を持ちます。
またユーザー機能駆動開発は、ソフトウェア工学に基づいたベストプラクティスを採用しているのも特徴です。代表的なベストプラクティスをいくつか次に挙げておきます。
フィーチャーごとの開発とは、2週間以内に実装できる小さな機能単位の開発です。バグの少ない実装が可能となり、システムの拡張や改善も容易になります。
クラスごとのオーナーシップとは、オーナーが各クラスの一貫性や性能などに責任を持つことを示しています。
フィーチャーチームとは、小規模で動的に結成されるチームです。個人や固定チームで陥りやすい独善を防ぎます。
定期ビルドとは、顧客に対して常に公開可能な最新システムを構築しておくことを意味します。ソースコード結合時の不具合を早期発見するのにも役立ちます。
アジャイル開発についてさまざまな開発方式を見てきましたが、ここであらためてアジャイル開発のメリットをまとめていきましょう。
アジャイル開発のメリット
開発スピードの速さは、アジャイル開発の大きなメリットの1つです。開発の初期段階でしっかりとした設計や計画を詰めるのではなく、大まかに骨子ができた時点で重要な機能から開発に取り掛かることができ、素早く形にできる点が強みとなります。
また、イテレーションという短期間で納期を区切ることにより、長期開発でありがちな中弛みの余地を持たせないのも、開発スピードの速さにつながっていることでしょう。
仕様変更やトラブルへの対応力の高さも、アジャイル開発の大きなメリットです。これも、アジャイル開発のイテレーションという、短い開発スパンからもたらされるメリットになります。イテレーションという短期間で区切りながら開発を進めるアジャイル開発であれば、仕様変更に伴う損切りの量も最小限になり、今後の方針転換への対応も容易です。
顧客の要望を取り入れやすいのも、イテレーションからもたらされるメリットです。イテレーションが終了するたびに顧客と意見のすり合わせを行えるので、その際に要望を取り入れることができます。顧客と一緒にプロジェクトを完成させていくというスタイルも、アジャイル開発の特徴と言えるでしょう。
【関連記事】
【関連記事】
アジャイル開発には大きなメリットがある一方で、デメリットもいくつかあることを知っておきましょう。
アジャイル開発のデメリット
スケジュール管理や全体の把握の難しさは、イテレーションによる柔軟性の高い開発の弊害です。ウォーターフォール開発のようにスケジュールを順番に埋めていくのではなく、変更や追加も頻繁に行われるため進捗状況が見えにくいのです。これは納期や予算に関わる問題になりかねず、開発チームが複数になるとさらに顕著となります。
開発方針にブレが生じやすいのも、変化への対応力の高さの裏の面と言えます。修正や追加を加えていった結果、最初の目標とは大きくかけ離れたものになってしまう恐れがあります。
組織全体でアジャイル開発を理解しなければ成果を上げられないという点も、デメリットと言えなくありません。アジャイル開発は単純にそのスタイルを真似ればOKというわけではなく、組織のトップから開発メンバーの1人1人に至るまでの意思統一が重要です。
管理者が目標に向かって適切な指示を出し、開発メンバーは自己組織化で十分な実力を出してイテレーションという短期間の開発に打ち込むことにより、アジャイル開発が本来の力を発揮します。
アジャイル開発について、代表的な開発手法を中心に説明してきました。
アジャイル開発はプロジェクトの骨子が大まかにできあがった段階で機能ごとの開発に取り掛かれるフットワークの軽さが魅力で、何と言っても開発スピードの速さと変化に対応する柔軟性の高さが利点です。
ただ、従来のウォーターフォール開発にも適した分野はあるので、盲目的にアジャイルオンリーとなるのではなく、適材適所で使い分けていけるのが理想的と言えます。
【関連記事】
【関連記事】
関連タグ:
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには