DX(デジタルトランスフォーメーション)元年とも言われた2020年が終わり、いよいよ多くの企業がDXを推進することになるでしょう。
DXに必要となるアジャイル開発やアジャイルな組織、スクラム。
そもそもアジャイル開発とは何でしょうか。
アジャイルの概要と、メリットなどに触れていきます。
DXに必要となるアジャイル開発やアジャイルな組織、スクラム。
そもそもアジャイル開発とは何でしょうか。
アジャイルの概要と、メリットなどに触れていきます。
アジャイル開発は、何のためにある？
世間ではだいぶ浸透したアジャイルですが、まだ理解不足や誤解があるのも事実です。
手段と目的を取り違えない為に、そもそも何のためにアジャイル開発があるのか、おさえておきましょう。
アジャイル開発は「手段」です。
目的は「顧客や世の中に価値を提供する」ためのものであり、その価値を提供するためにどうしたら良いのか。
そのマニフェストとして、2001年にアジャイル開発で名を馳せていた17名が議論し、下記宣言がされました。
＜アジャイルソフトウェア開発宣言＞
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。…後略…
(引用: http://agilemanifesto.org/iso/ja/manifesto.html)
忘れてはいけないポイントです。
手段と目的を取り違えない為に、そもそも何のためにアジャイル開発があるのか、おさえておきましょう。
アジャイル開発は「手段」です。
目的は「顧客や世の中に価値を提供する」ためのものであり、その価値を提供するためにどうしたら良いのか。
そのマニフェストとして、2001年にアジャイル開発で名を馳せていた17名が議論し、下記宣言がされました。
＜アジャイルソフトウェア開発宣言＞
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。…後略…
(引用: http://agilemanifesto.org/iso/ja/manifesto.html)
忘れてはいけないポイントです。
アジャイル開発とは？既存開発モデルとの違い
従来の開発で代表的なモデルといえば「ウォーターフォール」モデルでしょう。
ウォーターフォールモデルは、[ 要件定義・設計・開発・テスト] というように、開発フェーズを順番に進める方法です。
一方、アジャイル開発は、[ 要件定義・設計・開発・テスト] → [ 要件定義・設計・開発・テスト] …を繰り返します。
それって、スパイラルモデルと同じじゃないの？と思うかもしれませんが、答えはNOです。
スパイラルモデルも、工程を繰り返しながら進めますが、スケジュールや開発する機能、いつ何を開発するか等は明確に決めて開発します。
アジャイルの場合、ざっくりとしたスケジュールは切りますが、開発を進めながらチームの生産性を計り、納品可能時期の精度を徐々に上げていきます。
また、開発対象も最初から決まっているわけではなく、日々変わる顧客の要望や社会情勢などに応じる形で柔軟に対応します。
これだけ聞くと、随分フワフワした手法のように見えますが、全くそんなことはありません。
アジャイルを支える素晴らしい「しかけ」が色々あるのです。
ウォーターフォールモデルは、[ 要件定義・設計・開発・テスト] というように、開発フェーズを順番に進める方法です。
一方、アジャイル開発は、[ 要件定義・設計・開発・テスト] → [ 要件定義・設計・開発・テスト] …を繰り返します。
それって、スパイラルモデルと同じじゃないの？と思うかもしれませんが、答えはNOです。
スパイラルモデルも、工程を繰り返しながら進めますが、スケジュールや開発する機能、いつ何を開発するか等は明確に決めて開発します。
アジャイルの場合、ざっくりとしたスケジュールは切りますが、開発を進めながらチームの生産性を計り、納品可能時期の精度を徐々に上げていきます。
また、開発対象も最初から決まっているわけではなく、日々変わる顧客の要望や社会情勢などに応じる形で柔軟に対応します。
これだけ聞くと、随分フワフワした手法のように見えますが、全くそんなことはありません。
アジャイルを支える素晴らしい「しかけ」が色々あるのです。
アジャイル開発のメリット
既存の開発方法と比べ、どういったメリットがあるのでしょうか。
ざっと大きなものを挙げてみます。
アジャイル開発では、開発を始める前に「何のためのどういう製品なのか、何を解決する製品なのか」という『エレベーターピッチ』を関係者で作ります。
エレベーターピッチを作る工程で、関係者と議論しながら認識合わせ・合意を行っていきます。
また『トレードオフスライダー』というものも作ります。
プロジェクトを進行する中で、予期しないことは次々に起こります。
「問題は解決して、この仕様変更もして、とにかく費用も増やさず、スケジュールも遅延させるな！」となるのが世の常で、結果、現場の開発者だけが大変な思いをするのはよくあることです。
そのような不幸な状況を避けるために「予算・スケジュール・品質・スコープ(機能) 」で優先順位をつけ、何を優先させ、何を捨てるのか関係者間で認識を合わせます。
受託開発している場合は、これらを発注者も含めて合意します。
例えば、どうしても必要な仕様変更があった場合に、合意したトレードオフスライダーを元に折衝や調整をしていきます。
これら「方向性」と「指針」があることで、開発を進める中での判断基準ができ、ブレずにゴールに向かいやすくなります。
しばしば発生する、こんな機能必要ないだろう、無駄でしょ、と思いながら「ただ言われたものを作る」という「やらされ感」。
アジャイル開発では、一人一人が目的を認識してプロジェクトに参加します。
そしてプロジェクトの羅針盤とも言える「インセプションデッキ」を皆で作り、朝会やふりかえりを行うなどで、自分が何のための開発をしていて、どこにいるのかを認識することで「やらされ感」を失くしていきます。
アジャイル開発では、開発を小さな単位「イテレーション」で区切り、[ 要件定義・設計・開発・テスト・ふりかえり] を繰り返します。
イテレーションはプロダクトにもよりますが、2週間程度で設定することが多いでしょう。
これは、期限がすぐそこにあり、気を抜くとすぐ予定をオーバーしてしまうので、毎日の仕事に良い緊張感が生まれます。
アジャイルは、プロジェクトにエンジンを積み込むといっても過言ではないでしょう。
チームが成長するに従い、エンジンも高性能に、スピードも上がっていきます。
イテレーションの中で小さくテストを実施して行くので、そこで発見したバグは即座に修正するか、次のイテレーションで修正していきます。
テストをするには、仮にでもソフトウェアを目に見える形で動かせる状態にしなければいけません。
動かすにはスタブを作ったり、仮の実装をする必要も出てくるでしょう。
一見無駄に見えますが、そこでバグとなり得るものや、設計上の不足などを発見することも多いのです。
常に動くソフトウェアの提供を実現していくことで、ウォーターフォールモデルで発生しがちな、結合テストやテストの最終段階で大きなバグが発見されて大炎上、ということが発生しにくくなります。
イテレーション内で発見したバグや設計不備は、修正の影響範囲も小さく済むことが多くあります。
イテレーションごとに、ふりかえりを行うのがアジャイルのひとつの特徴でもあります。
開発に関係ないような些細なことから、重要なことまで、カイゼンをし続けます。
これは、楽しくもあり、時には苦しい作業でもあります。
しかし、チームで取り組んでいくことで、次第に様々なことが『他人事』から『自分ごと』に変わり、仕事に対する姿勢自体も変わります。
ひとりひとりの成長が促され、チームが自走し、自己組織型のチームになっていきます。
その他にもメリットはたくさんありますが、チームやプロジェクトごとにも、会社ごとにも感じるメリットは異なってくるでしょう。
ただ、すべての開発にアジャイルを導入してメリットがあるかというと、そこは見極めなければいけません。
ざっと大きなものを挙げてみます。
メリット1：価値のあるプロダクト、ゴールに行きやすい
アジャイル開発では、開発を始める前に「何のためのどういう製品なのか、何を解決する製品なのか」という『エレベーターピッチ』を関係者で作ります。
エレベーターピッチを作る工程で、関係者と議論しながら認識合わせ・合意を行っていきます。
また『トレードオフスライダー』というものも作ります。
プロジェクトを進行する中で、予期しないことは次々に起こります。
「問題は解決して、この仕様変更もして、とにかく費用も増やさず、スケジュールも遅延させるな！」となるのが世の常で、結果、現場の開発者だけが大変な思いをするのはよくあることです。
そのような不幸な状況を避けるために「予算・スケジュール・品質・スコープ(機能) 」で優先順位をつけ、何を優先させ、何を捨てるのか関係者間で認識を合わせます。
受託開発している場合は、これらを発注者も含めて合意します。
例えば、どうしても必要な仕様変更があった場合に、合意したトレードオフスライダーを元に折衝や調整をしていきます。
これら「方向性」と「指針」があることで、開発を進める中での判断基準ができ、ブレずにゴールに向かいやすくなります。
メリット2：やらされ感をなくす
しばしば発生する、こんな機能必要ないだろう、無駄でしょ、と思いながら「ただ言われたものを作る」という「やらされ感」。
アジャイル開発では、一人一人が目的を認識してプロジェクトに参加します。
そしてプロジェクトの羅針盤とも言える「インセプションデッキ」を皆で作り、朝会やふりかえりを行うなどで、自分が何のための開発をしていて、どこにいるのかを認識することで「やらされ感」を失くしていきます。
メリット3：開発にスピード感が出る
アジャイル開発では、開発を小さな単位「イテレーション」で区切り、[ 要件定義・設計・開発・テスト・ふりかえり] を繰り返します。
イテレーションはプロダクトにもよりますが、2週間程度で設定することが多いでしょう。
これは、期限がすぐそこにあり、気を抜くとすぐ予定をオーバーしてしまうので、毎日の仕事に良い緊張感が生まれます。
アジャイルは、プロジェクトにエンジンを積み込むといっても過言ではないでしょう。
チームが成長するに従い、エンジンも高性能に、スピードも上がっていきます。
メリット4：後工程での大爆発、大炎上が発生しにくい
イテレーションの中で小さくテストを実施して行くので、そこで発見したバグは即座に修正するか、次のイテレーションで修正していきます。
テストをするには、仮にでもソフトウェアを目に見える形で動かせる状態にしなければいけません。
動かすにはスタブを作ったり、仮の実装をする必要も出てくるでしょう。
一見無駄に見えますが、そこでバグとなり得るものや、設計上の不足などを発見することも多いのです。
常に動くソフトウェアの提供を実現していくことで、ウォーターフォールモデルで発生しがちな、結合テストやテストの最終段階で大きなバグが発見されて大炎上、ということが発生しにくくなります。
イテレーション内で発見したバグや設計不備は、修正の影響範囲も小さく済むことが多くあります。
メリット5：プロダクトとともに、チームも成長する
イテレーションごとに、ふりかえりを行うのがアジャイルのひとつの特徴でもあります。
開発に関係ないような些細なことから、重要なことまで、カイゼンをし続けます。
これは、楽しくもあり、時には苦しい作業でもあります。
しかし、チームで取り組んでいくことで、次第に様々なことが『他人事』から『自分ごと』に変わり、仕事に対する姿勢自体も変わります。
ひとりひとりの成長が促され、チームが自走し、自己組織型のチームになっていきます。
その他にもメリットはたくさんありますが、チームやプロジェクトごとにも、会社ごとにも感じるメリットは異なってくるでしょう。
ただ、すべての開発にアジャイルを導入してメリットがあるかというと、そこは見極めなければいけません。
アジャイル開発のデメリット
もしアジャイル開発にデメリットがある、と感じていたり経験していたりする場合は、まだうまくアジャイルを導入できていない事が考えられます。
アジャイル開発自体のデメリットは、その「開発モデル」ではなく、どちらかといえば導入のハードルや、顧客やチームを巻き込んで進めることの難しさにあります。
アジャイル開発自体のデメリットは、その「開発モデル」ではなく、どちらかといえば導入のハードルや、顧客やチームを巻き込んで進めることの難しさにあります。
アジャイルに進めるための『しかけ』と『ツール』
アジャイルに進めるためのツールやしかけは多くありますが、最初はセオリーに従うべきでしょう。
そこから各々の開発現場に合わせてカスタマイズすると、より強い武器となっていきます。
そのしかけやツールのキーワードを見ていきましょう。
・インセプションデッキ
・ユーザーストーリー
・ポイント見積
・朝会(デイリースタンドアップ)
・カンバン
・ふりかえり(KPT、OKRなど)
・バーンダウンチャート
・テスト駆動開発
・リファクタリング
・継続的インテグレーション
等々あります。
個々の解説はここでは控えますが、手にする武器が多くあるということです。
そこから各々の開発現場に合わせてカスタマイズすると、より強い武器となっていきます。
そのしかけやツールのキーワードを見ていきましょう。
・インセプションデッキ
・ユーザーストーリー
・ポイント見積
・朝会(デイリースタンドアップ)
・カンバン
・ふりかえり(KPT、OKRなど)
・バーンダウンチャート
・テスト駆動開発
・リファクタリング
・継続的インテグレーション
等々あります。
個々の解説はここでは控えますが、手にする武器が多くあるということです。
