第3回従来型開発とアジャイル開発の違いその１

この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。

第3回目のテーマは、「従来型開発とアジャイル開発の違い」です。

この内容はUdemyで公開しているオンラインコース「現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム入門編」の内容を元にしています。

なぜ比較をするのか？
プロセス全体の比較
プロジェクト運営の比較
組織・チームの比較
要求・要件・仕様・タスクの比較

なぜ比較をするのか？

従来型の代表的な開発手法としてウォーターフォール手法があります。従来型は予測しやすい開発に適用しやすい方法なので、予測型と呼ばれたりもします。一方、アジャイル型は変化に積極的に対応していきます。そのため、適応型と呼ばれたりもします。

この記事では従来型とアジャイル開発を様々な点で比較していきます。

比較することでそれぞれの違いがわかるようになり、選択肢が増えるはずです。選択肢が増えるので、自分の置かれた状況で何を選択すべきか意思決定しやすくなるでしょう。

また、それぞれの方法の理解が進むと、上手に使えるようになるのと同時に、今やっている方法がうまくいかない場合、何が原因なのかを特定しやすくなります。

それでは、従来型とアジャイル開発の比較を進めていきましょう。

プロセス全体の比較

まずはプロセス全体を比較してみましょう。上記の図は従来型とアジャイル開発のプロセス全体の流れを表現したものです。

上側は従来型です。図を見てのとおり、リリースまで一方通行で、滝のように流れていく工程のためウォーターフォール型と呼ばれます。

従来型では、それぞれの工程（フェーズ）を重視しています。工程をきちんと完了させ、うまくできてない場合は、次の工程に進めません。従来型でよく失敗してしまうのは、工程がうまくいっていないのに、期限があるから次の工程に進んでしまうケースです。ちゃんとやれば、従来型でもプロジェクトは成功するはずです。

従来型は最後の最後で完成品をリリースするため、最後に大きな利益を期待する方法です。うまくいけば大きな利益を得られますが、うまく行かない場合はやり直すにも時間がかかる方法なので大損害になります。

下側はアジャイル開発を表した図です。アジャイル開発は、短い開発サイクルを繰り返しながら進んでいきます。

短い開発サイクルのたびに、小さくリリースを繰り返しながら進んでいくため、リリースのたびに利益を小さく生み出せます。従来型のように大きな利益は期待できませんが、収益は小さくとも、従来型よりはやく利益を生み出せます。さらに、小さなリリースの繰り返しでプロダクトの改善がうまくすすめば、利益を増やしていくことができます。

アジャイル開発は、短い開発サイクルを繰り返すので、変化が起きたときに柔軟に対応できます。課題の改善も、次の開発サイクルから試せるため、すばやくやり直せます。

それぞれの方法の特徴を見ると、作りたいものがクリアに見えていたり、スケジュールがはっきりしていたり、物事を予測できる情報が多いなら従来型が進めやすいと思います。

一方で、見通せる情報が小さかったり、軌道修正に柔軟に対応しなければならないのであれば、アジャイル開発が進めやすいはずです。

プロジェクト運営の比較

次にプロジェクトの運営方法の比較をしてみましょう。従来型の特徴をいくつか見ていきましょう。

管理でコントロール
プロマネが全体を管理（成熟した手法PMBOKもある）
工程ごと

従来型のプロジェクト運営は、どちらかというとかっちりした運営になります。これは、お客様と契約の関係があるケースが多いからでしょう。スコープ、スケジュール、コストが大切な変数になるプロジェクト型が多く、プロジェクトマネジメント手法を活用して、全体をきちんと管理していく必要があります。管理と言うとあまりいいイメージがわかないかもしれませんが、従来型では変化をできるだけ小さくしたいと考えています。

工程に分かれているのも特徴的です。工程ごとに担当する人や企業がわかれる場合も多いので、事前に決めた責務を、各自がやり遂げていく必要があります。だから、次の工程に進む場合、間違いがないようにバトンを渡す必要があるので、必然的にドキュメントが増えます。

一方で、アジャイル開発のプロジェクト運営はどうでしょうか？

自主性を重視
サーバント・リーダーシップ
開発サイクルごと

アジャイル開発は、誰かが管理するのではなく、アジャイルチームメンバー全員で管理していこうとしています。アジャイル開発は、チームの自律性を重視します。アジャイルチームは、自分たちのゴールを常に意識し、それが達成できるかを日々確認しながら開発を進めます。

となると、アジャイル開発には、プロジェクトマネージャーは必要ないのかもしれません。そのかわりに登場するのがサーバント・リーダーシップです。サーヴァントとは、召使いという意味になり、サーバントリーダーシップが、自律したアジャイルチームを支える存在になります。

アジャイル開発は短い開発サイクルでわかれています。開発サイクル

こうやって比較してみると、管理を行うのは誰か？が大きな違いとしてあります。リーダーシップの点も大きく異なり、従来型のリーダーシップと比べると、サーバントリーダーシップはだいぶ毛色の違う考え方になります。

組織・チームの比較

組織・チームを比較していきましょう。従来型の特徴以下です。

工程ごとの専任チーム
階層構造
プロジェクトや工程ごとにチームは解散

従来型は、先程も書きましたが、工程ごとに担当する人や企業がわかれる場合も多い方法です。ひとつの工程に複数企業が階層的に参加するケースも多いでしょう。

チームは、プロジェクトや工程の終わりに解散するケースもあります。

次に、アジャイル開発を見ていきます。

職能横断型チーム
フラット
メンバー固定

アジャイル開発では、職能横断型のチームを作ろうとします。職能横断型チームとは、やりたいことを実現できる人材の揃ったアジャイルチームです。もちろん、メンバーごとに専門性が異なったりするでしょうが、チームとしてゴールするという点が考えの中心にあることを忘れないでください。チームメンバーはフラットな関係性です。

アジャイル開発の場合、チームメンバーを固定します。固定して継続的に開発を繰り返していくので、チームの練度がどんどん高まっていきます。

従来型は、管理体制下で効率よく働ける組織・チームの構成になっています。アジャイル型は、チームを中心とした構成で、成果物の価値を高めていきます。