アジャイルソフトウェア開発

重量級開発プロセスとの違い

　アジャイルには、「ドキュメントよりも動くソフトウエア」という考え方がありますので、この点では、考え方をさらに推し進めただけで、反復型の重量級開発プロセスと似ているとも思えます。しかし、アジャイルな開発プロセスと重量級開発プロセスとの根本的な違いが、アジャイルソフトウエア開発宣言の価値に表れています。重量級プロセスが「事前に予見」「手続き中心」という考え方なのに対して、アジャイルな開発プロセスでは「計画よりも変化への対応」「プロセスよりも個人」という考え方を重視していることです。

　では、アジャイルな開発プロセスでは、どのようなプロジェクトに適用できるのでしょうか。判断基準として、下記のような切り口があります。アジャイルな開発プロセスは、重量級プロセスを置き替えるものではなく、適材適所で適用していくことが重要なのです（図3）。

・種類
　クリティカルなシステムでは、厳密な統制下で開発を進めることにより、計画通りの品質を保つことが最重要ですので、アジャイルな進め方は向かないと言われています。

・規模
　アジャイルの特徴として「個人と相互作用」とか「変化への対応」があります。これらは、プロジェクトの規模が大きくなると、統制を保つのが難しくなっていくものです。そのため、規模拡大に対応するためには、ある程度「手続き中心」の考え方を取り込む必要があります。

・経験
　アジャイルでは、開発メンバーが自律的な動きすることを期待します。つまり、ある程度のスキルを持った開発者でないと、効率よく開発を進めていくことができません。また、プロジェクト管理の側面においても、アジャイル開発の管理を行える管理者がいないと、カウボーイ開発になってしまいます。

・契約
　アジャイルは「変化に対応」します。すなわち、見積もり時点の要件と完成時点の要件が違うことが少なくありません。そのため、少なくとも一括発注の場合には、契約に落とし込むのが難しく、ここがアジャイルの障壁になっていることが多いのではないでしょうか。

こぼれ話

　ここでは、アジャイルに関連したよくある落とし穴として、私が携わったPJでの話を披露したいと思います。皆さまも十分注意してください。

・「アジャイルでやりましょう」
　画面設計が全く進んでいない状況での、ユーザー側担当者のご提案。その開発PJでは、画面設計書を使ってドキュメントベースで設計を進めていたが、進ちょくが芳しくなかったため、やり方を変える一案として提案された。プロジェクトメンバーの中には、アジャイルの経験者はおろか、アジャイルの理解者もいなかったが、なぜか、PM判断によりアジャイルでの開発を行うこととなった。結果、アジャイルという名を借りた「無駄な作業」を1か月間行った後に、元の開発プロセスに戻ることとなった。

　「アジャイル」という言葉の響きは、バズワードと同様、人の判断力をまひさせる効果があるようです。プロジェクトの進ちょくが芳しくなかったために、何か進め方を変えなければならない、といった意識を持つのは当然のことだと思いますが、プロジェクトメンバーの誰も理解していない「アジャイル」なる進め方で開発を行うことに対しては、もう少し慎重な判断が必要だったと言えます。

　また、「アジャイルはダメだ」という意見もよく耳にしますが、このような「似非（えせ）アジャイル」に対する意見も多いと思われます。現在ではアジャイルという言葉が先行している感がありますが、アジャイルの中身が普及し、アジャイルの考え方や個々の開発プロセスが理解されるようになれば、アジャイルに対する評価が上がり、結果、普及が進むのではないでしょうか。