開発手法の選択はプロジェクトの成功に直結します。
私自身はアジャイル専門のコンサルタントではありませんが、メーカーでの開発プロセス改善のコンサルの中でアジャイルの導入も行っています。その中で、アジャイル、ウォーターフォール、V字モデルはよく誤解されがちな概念です。
この記事では、これらの違いと適用の際の考慮点について、私の個人的な経験と具体的な事例を交えて解説します。

多くの場合、V字モデルとウォーターフォールは同一視されますが、これには誤解があります。
ウォーターフォールは、一連のフェーズ（要件定義、設計、実装、検証、保守）を段階的に進める方法で、1つのフェーズが100％完了すると次のフェーズに移ります。一度次のフェーズに進むと、前のフェーズに戻ることはありません。
それに対して、V字モデルは次のように「スムーズなモノづくりの順序」を示したものです。要件定義（＝手に入れたいモノを明確にする）・設計（＝そのモノの構造を検討する）・実装（検討結果に従って作る）という考え方を示しているだけです。100%完了してから次の工程に進むという意味はなく、むしろ各工程の行き来が前提になっています。

考えてみてください。手に入れたいものを何ひとつ明確にしないで、モノの構造を検討したり、実装すると、一体どれだけの手戻りを起こすのでしょうか。V字モデルは、このような手戻りをより少なくする作業の順序を示しているだけなのです。

ここからウォーターフォールとV字モデルの関係を見直すと、
「ウォーターフォールは、V字モデルの左上→下→右上の各工程を行き来しないで100%完了後に進む方法」
と説明できます。

アジャイル開発はアンチ・ウォーターフォールの文脈で説明されることが多いため、V字モデルとウォーターフォールを混同している人達の間で「アジャイルはV字モデルを使わない」という話が、今でもよく聞かれます。しかし、アジャイルはウォーターフォールがプロジェクト終了直前に大きな手戻りを起こすことを問題視しているだけであり、手戻りを少なくするV字モデル自体を否定しているわけではないのです。

ウォーターフォール

Created by OpenAI's DALL-E

V字モデル

Created by OpenAI's DALL-E

先ほど書いた通り、V字モデルは「スムーズなモノづくりの順序」を示したものです。コードを実装する前に、要件や設計を考えられるだけ机上で考えることによって、手戻りを少なくすることができます。

アジャイルな進め方を考えると、次のように考えると良いでしょう。

1. V字モデルに基づいて、考えて分かることは机上でしっかりと考え、
2. 机上では分からない要素を残したままの状態で（薄く）モノを作り、
3. フィードバックを得て、1.に戻る

デイリーやスプリントの中に従来通りのV字モデルが存在します。

私は様々なメーカーでの組み込みソフトの開発に関わっています。メーカーでの組込みソフトの開発は、Web開発などに比べると「アジャイルではない古い開発」というイメージを持たれていると感じています。しかし、メーカーの実際の開発は決して下図のようなウォーターフォールではありません。

ウォーターフォール

Created by OpenAI's DALL-E

特に、民生品ではないBtoBの製品を扱うメーカーでは、短期的な製品化を求められることが多いです。そのため、製品をリリースしてから、より高度な機能を追加したソフトだけを後から出荷する（＝アップデート）インクリメンタルな開発がよく行われています。

インクリメンタルな開発

Created by OpenAI's DALL-E

たとえば、典型的な例はこのようになります。
１回のステップが数か月で、以下のように続きます。
ここでは誤解を恐れずに書きますが、このようなインクリメンタルな開発ステップを、現場では「イテレーション」と呼んでいたりします。

• 「イテレーション１：基本機能によるハードウェア単独動作の確認」
• 「イテレーション２：小さな応用機能の開発1」
• 「イテレーション３：小さな応用機能の開発2」
  この内、製品リリースせざるを得ないタイミングが来ると製品リリースし、その後に残った機能を開発していきます。

このため、メーカーの開発者はアジャイル導入を提案されると「俺たちはウォーターフォールじゃなくイテレーション開発をしているから開発スタイルを変える必要はない」と感じてしまいます。
また、「アジャイルには様々な流派があるから、それもまたアジャイル」という柔軟な考え方で語られることもあります。

しかし、この開発スタイルは、通常１回のイテレーションが長く、フィードバックサイクルを回していません。
製品の要求のフィードバックサイクルも回りませんし、レトロスペクティブも実質的なPDCAサイクルが回っていない風景を私はよく見ました。
私にとって、これではアジャイル開発の持つ良さが発揮されていないと感じられました。

このようなことが、メーカーにおけるアジャイル開発導入への誤解の要因の1つだと考えています。そして、開発期間の延長や、品質低下、メンテナンス工数の肥大化は、解決されないままになってしまいます。

私が関わったあるチームでは、プロダクトバックログやスプリントなどのアジャイルの手法を採用しつつも、実際にはフィードバックが得られない「ウォーターフォール化」したスプリントを見ました。メーカーでのアジャイルの皮を被った非アジャイル開発の一例としてご紹介します。

前述した通り、メーカーでは、インクリメンタルな開発が散見されます。
この場合、アジャイル開発を導入は、開発者にとって、インクリメンタルな開発のイテレーション期間を非常に短くするもの、という感覚になります。たとえば、「今までの開発の区切り方を１週間や２週間に区切ればよい。その周期ごとに振り返りをすれば良い」という理解のチームが多く発生します。
そのような誤解がある一方で、メーカーでアジャイルを取り入れようというチームは、新しいものを取り入れることに挑戦的です。ペアプロなどのプラクティスの導入をするチームもあります。私が関わったチームでも、ペアプロの効果でプログラマ全体のスキルアップが進みました。そこでアジャイルへの満足が生まれます。

しかし、ここから、成長が止まります。やはり、誤解の部分に大きな問題があったのです。
彼らは、プロダクトバックログをうまく作れない...。無意識に、従来のインクリメンタルな開発の開発ステップを小さく切る考え方を基本としてしまいます。ユーザーストーリーらしいものを書いたとしても、その実、中身はV字モデルの中の一工程を小さくしたものにすぎないのです。それを、スプリントとして実行してしまうのです。

私は時折チームを訪れて様子を見るのですが、朝会やプロダクトバックログリファンメントを見ていると、どうにもメンバーが楽しくなさそうに感じます。成長が続いていない・難しい技術課題を抱え込んでいる様子でした。

蓋を開けてみると、（プロダクトバックログをユーザーストーリーに寄せたとしても）スプリントの内容が実質的に以下のようになっていました。

• 「スプリント1：〇〇の分析 + ... 」
• 「スプリント２：〇〇の設計1 + ... 」
• 「スプリント３：〇〇の設計2 + ... 」
• 「スプリント3：〇〇の実装 + ... 」

１回のスプリントが Ｖ字モデルの一工程をやっているだけなので、俊敏にフィードバックを得て学んでゆくという果実を得られていなかったのです。おいしい果実が得られなければ、それは楽しくなくて当然だと思いました。

説明をして、理解して貰いましたが、まだ、みんなが消化できている訳ではないと思います。

１週間や２週間という短い期間で実際に動くプログラムを作ることで、課題に気づいたり、問題がないことに安心できます。このとき、１回のスプリント内でV字モデルの範囲全体を実施しているはずです。

繰り返しますが、この中では、以下の２つが両立しているのです。

• 「コード実装しなくとも机上で考えれば分かることは、机上で考えることで手戻りを減らす」
• 「コード実装してみないと分からないことは、イテレーティブなフィードバックサイクルを回すことで、プロジェクト後期の大きな手戻りを減らす」

こう説明すれば、簡単なことのはずなのですが、手戻りを減らす手段が「コードをすぐに実装しないこと」と「コードをすぐに実装すること」という逆のことを言っているため、混乱してしまうのかも知れません。
この2つを両立させるのがイテレーティブなV字モデルなのです。

この私の経験は、「このチームはインクリメンタルだがイテレーティブではなった」とも表現できます。
メーカーの現場には、今までのインクリメンタルな開発の経験が沁みついていることから、このような問題が起きやすいことを、理解しました。
今後は、イテレーティブを通してフィードバックサイクルが回る大切さ、を明確に言葉にしたいと考えています。

インクリメンタルな開発

Created by OpenAI's DALL-E

イテレーティブな開発

Created by OpenAI's DALL-E

近年、お客様たちと触れるにつれ、アジャイル開発はメーカーでも重要になってきていると感じます。しかし、アジャイルなプロセスの導入を目的にするのではなく、その成果/果実を手にすることの方を目的としなければなりません。

成果/果実ではなくアジャイルなプロセスの導入の方を強調してしまうと、「俺たちは元々アジャイルをやっている」と豪語されることもあるでしょう。
しかし、チームや製品に際立った成長が見られず、楽しそうな表情をしていないようでは、やはりそれはアジャイル（＝俊敏な）開発ではないのだと思います。俊敏なフィードバックサイクルが回っていないのでしょう。

私にアジャイルを教えてくれた人が「アジャイルでは、自分たちが楽しいと思えるようにすると良い」と言っていました。良い製品と成長する自分たち、という果実を手にし続けられる、楽しいと感じられるアジャイルライフを送って欲しいと思います。

皆さんのプロジェクトでの経験や、これらの方法論の適用に関する考えをぜひ共有してください。異なる視点からの意見交換は、さらなる学びと成長の機会を提供します。