3つ目は、アジャイル開発をどのようにエンタープライズ規模にスケールアップするかという点です。
アジャイル(スクラム)は、もともと比較的小規模な開発のために考案された開発手法です。すなわち、スクラムは開発のサイクルを1チーム(5~9人程度)でどのように回すのかという点で示唆に富むものの、複数チームで開発を行う場合の回し方については触れられていません。
さらには、「開発で実現する要件(ユーザーストーリー)をどのように洗い出すのか」「ソリューション全体のアーキテクチャーをどのように構想するのか」、といった開発の前段の活動、あるいは反復(スプリント)を通じて作成したソリューションを継続的にデリバリーしていくために必要な、作成したコードを効率的に統合・ビルドし、テストのためにデプロイする仕組みの構築や、リリース前に必要な作業をどのように実施すべきか、といった後段の活動についての言及がありません。
スクラムで言及されていない部分を補い、アジャイル開発をエンタープライズ規模にスケールアップする方法として、ディシプリンドアジャイル(DA)やScaled Agile Framework(SAFe)といったフレームワークが考案され、浸透しつつあります。これらフレームワークの概要と利点を紹介します。
本連載では、前述の3つのポイントについて解説する予定です(内容については多少変更する場合があります)。
回 | 主な内容 |
---|---|
1. アジャイル開発手法の生い立ちと基本原則の理解 | |
#1 (今回) |
(はじめに) |
#2 |
20世紀のソフトウェア開発手法であるウォーターフォール誕生から、不確実性の時代である21世紀の到来―早く安く失敗し、そこから学ぶ
|
#3 |
アジャイル開発の基本原則おさらい – なぜ成果が出るのか?出しやすいのか?
|
2. マインドセットの転換 | |
#4 |
アジャイルに対する誤解(1) – 設計せずに、いきなり作る?文書を書かない?
|
#5 |
アジャイルに対する誤解(2) – ウォーターフォールと比べて品質はどうなの?
|
#6 |
自己規律、自己組織化 – アジャイルとともに成長していくチームと開発者たち
|
#7 |
「アイデンティティ」ではなく、「タスク」としてのリーダーシップ:何がモチベーションか?
|
3. スケールアップと今後の展望 | |
#8 |
デザイン思考、DevSecOps – 単なる開発を超えて
|
#9 |
アジャイルの課題-どうスケールアップ(大規模に対応)するか?
|
#10 |
まとめと今後の展望
|
次回は、ウォーターフォール開発手法と、それに対するアンチテーゼとしての反復型開発、その発展形としてのアジャイルの生い立ちを見ていきます。ウォーターフォールの考案者はその手法がソフトウェア開発にうまく適合するか懸念を持っていたのですが、それを裏付けるように、反復型開発はなんとその実の息子によって考案されたという話とともに、アジャイルマニフェストの意味するところについて解説します。
- 岡本 修治(おかもと・しゅうじ)
- KPMGコンサルティング Technology Strategy & Architecture シニアマネジャー
- 外資系総合ITベンダーにおいて大規模SI開発をはじめ、ソフトウェア開発プロセス/ツール展開のグローバルチーム、コンサルティング部門などを経て現職。金融、製造、情報通信など業界を問わずITソリューション選定、開発プロセスのアセスメント(評価)と改善、BPR支援などさまざまな経験を有し、中でも不確実性の時代と親和性が高いアジャイルトランスフォーメーションを通じた意識改革、開発組織の能力向上支援をライフワークとし注力している。