プログラムを開発されている方にとって、
・ウォーターフォール
・アジャイル
という名前は、よく聞く言葉かと思います。
ここで改めて概要を記載いたしますと
ウォーターフォール
おそらく、これが以前よりやってきた開発スタイルかと思います。
読んで字のごとく、滝の流れのように開発を進めるスタイルで、
上流工程からきっちりと仕様を固め、その後に基本設計、詳細設計〜単体テスト、結合テスト、総合テストとの流れで開発を集結させるスタイルです。
このスタイルは、予めきっちりと仕様を固めて進めることにより、各工程での成果物の検証、その後この成果物を用いて、次の工程へ作業を進め、ゴールイメージが決まっていることから、エンジニア視点では完成形が見えやすいことがあったりと、馴染みやすいかと思います。
ただし、前提としては、「確実な仕様固め」が求められるため、途中の仕様変更は手戻りが発生し、変更に対する工数が発生することや、納期が決められている場合で、かつそのゴールを動かせない時は非常に厳しい状況に落ちいることになりかねません。
よく、デスマーチという言葉が出回った頃は、この開発スタイルが多かったのではと思います。
アジャイル
大まかな仕様を決め、かつ優先順位を決めて機能単位にチームを編成し、UnknowのところがあってもPDCAのサイクルを繰り返し、開発をしていくもので、個別機能単位に分けて徐々に螺旋階段のごとく積み上げて開発をしてリリースしていくため、開発期間が短く、仕様変更にも柔軟に対応ができるため、昨今では多くの開発現場で導入されています。(私の現場でも導入しています)
ただし、仕様がきっちりと決められていないことにより、仕様変更が入ったりすることで、当初のゴールイメージからブレが生じることがあります。(ブレた結果として、良い方向に進んだ場合は良いのですが・・・)また、チーム内のレビューは頻繁にやることはもちろんのこと、顧客とのレビューも認識相違を無くすため、よく実施する必要があります。
また、仕様や要件ごとにスケジュールを設定するため、全体のスケジュールや進捗管理がしにくくコントロールが難しい側面があり、マネージャとしては慣れないと厳しいかと思われます。
(かくいう私も、導入当初は試行錯誤でかなり苦労しましたw)
では、今後の開発スタイルとして、どちらが良いのかということが、とかく話題になったりしますが、
ウォーターフォール
仕様が確実にFIXした事を前提にするならば、各工程でのチェックが入るため成果物をもとに品質面のチェックがやりやすいため、品質を重視する場合は良いかと思います。
アジャイル
とにかくIT業界は時代の流れが早いため、すぐにリリースをしないと社会状況や環境変化に追従できなくなることから、スピード感をもって開発するには良いか。
(米国でもこの開発スタイルは非常に多いようです)
のメリットがあるため、システムの用途を考慮すると、今後は開発する対象により、ウォーターフォール or アジャイルの使い分けをして開発が進むのではないかと考えています。(各工程での成果物を非常に重要視している企業も多い事や、工程別に見積/発注をしている現状もある。かたや、とにかく早く世にリリースして、他社に対して牽制や主導権をとる必要がある場合等)
とはいえ、アジャイル開発の経験者やリーダ、マネージャは現状決して多くないため、今後スキルを身につけるとしたらアジャイル開発経験はとても重要になってくると思います。
(個人的には大量にドキュメントを作成しなければならないウォーターフォールは嫌いだったりしていますw)
現在携わっているLinuxを使ったシステムの開発スタイルは少し前から確実にアジャイルにシフトをしてきており、かつ結果として開発効率も向上していること、そしてチームメンバーの一体感があるがゆえに、困っている時に積極的にフォローをしてくれる体制も、非常に良いと思いますので、前述の個人的な主観のように棲み分けが進んでいくのか、注視しながら引き続きアジャイル開発のスタイルを続けていきます。
ひょっとしたら、今後別の新しい開発スタイルが登場したりするかもしれませんね。
ということで、今回はLinuxとはかけ離れた内容となりました。(スミマセン)