From: リスキルテクノロジー 松田航
新宿本校にて、、、
これまで、
ウォーターフォールモデル開発（以下「WF」）と
アジャイル開発（以下「アジャイル」）についてご紹介しました。
それぞれに特徴はありますが
ではどのような点が異なっているのでしょうか？
今回はWFのアジャイルの違いについて説明しましょう。
また、最近では
WFとアジャイルそれぞれのメリットを活かせる...
「ハイブリッド型開発」
...という開発手法も注目されています。
ハイブリッド型とはどのような開発手法なのでしょうか？
目次
ウォーターフォールとアジャイルの違い
WFとアジャイルの違いについて表にまとめました。
1.開発文化
WFはプロジェクトの制御や命令系統を重視しますが
アジャイルはプロジェクトチームの協力を重視します。
組織的な統制を重視するのがWFであり
協業による自由な結合を重視するのがアジャイルです。
2.計画・管理
WFは統制を重視するため、
開発計画を立てやすくプロジェクト管理が行いやすい。
対してアジャイルは柔軟な変化に対応すべく
案件や規模に応じての管理を行うため、管理方法には工夫が必要です。
3.仕様変更
WFは基本的に仕様変更しないことが前提。
変更が発生すると後工程に大きな影響を与えますが、
アジャイルは柔軟な仕様変更にも対応できるような手法です。
4.ドキュメント
WFは工程別に成果物として
ドキュメントの作成が必須要件になっています。
対してアジャイルでは
不必要なドキュメントは極力作りません。
「アジャイルではドキュメントを全く作らない」
という誤解を持っている方もいるのですが
実際には開発において最低限必要なドキュメントは作成します。
というより、きちんとしたアジャイル開発では、
ドキュメントは必須です。
5.ユーザー承認
開発費用の支払は
ユーザー承認のタイミングで行われる事が多いですが、
WFはドキュメント等の成果物をもって承認を受けます。
対してアジャイルでは
実際に動作するアプリケーションをもって承認を受けます。
6.プログラム
WFでは要件定義～詳細設計の上流工程で設計された
全機能を一気にプログラミングします。
アジャイルではあらかじめ
優先順位で定められた機能を順番にプログラミングします。
ただ、小規模な開発案件の場合は
一気にプログラミングを行うケースもあります。
7.リリース
WFでは原則的に全機能を一度にリリースします。
ただし、リリース計画によっては
サブシステム単位にリリースするケースも。
アジャイルではイテレーション毎にリリースを行い、
ユーザーからのフィードバックを受け、次のイテレーションに移ります。
8.開発規模
WFは計画、管理のしやすさや
指揮系統が重視されることから大規模開発に向いています。
アジャイルは小規模開発向きですが
最近では管理方法なども工夫されつつあり
大規模なシステム開発にも採用される傾向にあります。
見える開発、見えない開発
WFとアジャイルの違いをまとめましたが
もうひとつ大きな違いとして...
「ユーザーから見える開発・見えない開発」
...という特徴があります。
WFでは要件定義や基本設計、
そして総合テストやユーザーテストなど
上流工程と下流工程においては開発の動きが見えやすいですが...
詳細設計や製造、単体テストなど
開発チームが主体となってしまうフェーズでは
どのような開発を行っているのかユーザーからは見えにくいのです。
対してアジャイルでは
原則的にユーザーも開発チームの一員とすることから、
開発中でもどのような開発を行っているのかが見えやすい。
大型の長期案件ともなると
WFで開発されることが多いのですが、
製造などの中流工程になるとユーザーによっては...
「ちゃんと開発は進んでいるのだろうか？」
...といった不安を抱くケースも。
不安を払拭する為に
定期的な進捗報告などは行うのですが、
開発やテスト内容が見えないというのは変わりありません。
ユーザーは後から成果物で
開発結果やテスト結果を知るのみです。
では、アジャイルの方が
ユーザーにとって安心かというと、そうでもありません。
確かに開発中の動きが見えるのは良いのですが...
WFの様に最初から綿密に要件定義などを行うのではなく、
優先順位別に開発・リリース・フィードバックを繰り返すため...
見えるからこそ、
変更が頻発して要件が膨れすぎたり、
他機能との整合性が取れなくなったりするケースも。
また、システムの最終形が完成するのは
複数回のイテレーションを繰り返した後になることから、
総合テストなど、他機能と連携したテストを行いにくいという特徴も。
このような理由により、
アジャイルは小規模開発向きと言われているのです。
それぞれのメリットを最大限に発揮する
ハイブリッド型開発とは？
WFは上流工程と下流工程、
アジャイルは中流工程における変化に強い。
最近では、
それぞれのメリットを活かした手法として...
「ハイブリッド型開発」
...という開発手法があります。
これは要件定義や基本設計、総合テストなど
WFが得意とする上流工程や下流工程はWFで行い...
詳細設計や製造、単体テストなど、
アジャイルが得意とする中流工程はアジャイルで開発するというもの。
ハイブリッド型開発の流れを簡単に説明すると...
(1)要件定義
(2)基本設計
(3-1-1)機能A 詳細設計
(3-1-2)機能A プログラミング
(3-1-3)機能A 単体テスト
(3-1-4)機能A ユーザーフィードバック
(3-2-1)機能B 詳細設計
(3-2-2)機能B プログラミング
(3-2-3)機能B 単体テスト
(3-2-4)機能B ユーザーフィードバック
…
＜(3)は必要に応じてイテレートを行う＞
…
(4)結合テスト
(5)総合テスト・ユーザーテスト
(6)リリース
...といった流れで開発が進みます。
WFのデメリットである...
・フィードバックが少なく、変更対応に弱い
・開発内容が見えにくい
アジャイルのデメリットである...
・開発管理を行いにくい
・上流工程、下流工程に弱い
ハイブリッド型においては
このようなWFとアジャイルのデメリットをカバーし、
それぞれのメリットを活かした開発を行えるのが特徴です。
開発手法にのみ捉われてはいけない
トータル的なシステム開発サービスの品質が大切
企業における
ビジネススピードは加速しており、
システム開発側もそのスピードに対応すべく、
さまざまな開発手法が検討されています。
ハイブリッド型も
そのような風潮から生まれた手法のひとつであり、
アジャイル体制を構築しにくいと言われる
SIerでも注目されています。
しかし、
WFが良い、アジャイルが良い…というように
開発手法にばかり目が行ってしまうのも問題です。
開発の進め方については
ユーザーに提案し、きちんと説明することが大切。
そして開発中には
ユーザーに不安を抱かせず、
不透明な部分ができるだけないように進めることも重要です。
自社のアプリケーションであれば、
内部のエンジニアの総意を汲み取って決めるべきでしょう。
アジャイルはひとりが理解していないと、
その時点で崩壊しがちです。
手法も確かに大切ですが、
エンジニアが考えるべきは...
・ベストプラクティスなシステム
・アプリケーションの品質
・柔軟性
・スピード
...などといった...
「トータル的な品質」
であるという事を忘れないでください。
リスキルテクノロジー
松田
PS
どの業界でもそうですが
ユーザーに提供するのはトータル的な品質です。
いくら品物が良くても
売り手の対応が良くなければ、
それはユーザーにご提供するサービスとして
品質が低いと言わざるを得ません。
