ここはウォーターフォール市、アジャイル町 第1章 解説編：ウォーターフォールとアジャイル

アジャイルの原則

　これらの価値だけでは、まだ、フワフワした感じがするでしょう。アジャイルには宣言とは別に「原則」が存在します。これには行動の指針となる12個の原則が記されています。この12個の原則、すなわちアジャイル宣言の背後にある原則を確認しておくことで、アジャイル像はもう少し鮮明になってきます。

　この原則には、顧客満足を最優先することや、ビジネス側と開発者は日々一緒に働くこと、価値あるソフトウェアを提供すること、定期的にふりかえることなどが書かれています。ここから顧客のこと、チームのこと、プロダクトのこと、そしてプロセスの原則が読み取れます。顧客にとって価値あるものを開発し、よりよいもの提供するために必要なことばかりなので、どれも頷ける内容でしょう。

　実は、アジャイルの定義としては、これらの「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」しか存在しません。

　アジャイルとは、とてもシンプルだと思われたことでしょう。シンプルだからこそ、実践するのが難しいと言えるかもしれません。アジャイルを実践する中で判断に迷ったときは、これら2つを読み直してみるとよいでしょう。これらの言葉が価値基準や判断基準を教えてくれます。

新規ソフトウェア開発の方法論ではない

　アジャイルソフトウェア開発宣言の中の「対話」や「協調」という言葉からもわかるように、開発の方法論以外にも、自身の現場で適用できそうなことが見えてきたのではないでしょうか。すべてを同時に完璧に行う必要はなく、一部を取り入れてみるだけでも構いません。

　表 1-1に、アジャイル宣言の背後にある原則をチーム、プロセス、プロダクト、顧客の視点で切り出してみました。

　プロダクトやプロセスだけではなく、顧客の競争力を引き出すことや、人を信頼しチームのコラボレーションも重要であると位置づけています。そのために、自分の現場で「定期的なふりかえり」から始めてみるのもよいでしょう。

　情シス部門であれ、運用部門であれ、開発以外の部門であれ、チームの視点やプロセスの視点で適用できそうなことを本書で学び、実践していきましょう。

ゼロイチの二項対立ではなく共存できる

　ウォーターフォールもアジャイルも二項対立する考え方ではなく、それぞれのメリットがあります。つくるプロダクトの要件や仕様が明確で変更もほぼなく、開発メンバーなどもほぼ同じであれば、複雑性が低いといえます。すると、きっちりと計画し、予定通りに開発を進めていくことが可能になるため、ウォーターフォールで進めるのが得策です。

　一方、世の中の状況が変わったり、つくるものの要求が変わったりといった複雑性が高い状況もあるでしょう。その場合は、プロセスを繰り返しながら徐々に成果を積み上げ、早く失敗し学びに変え、そのつど見直しながら開発を進めるアジャイルが適しています。

　アジャイルは17名の賢人たちが持ち寄った開発手法がもとになったという説明をしました。具体的には、スクラム、XP、TDD、FDD、Crystal、DSDMと呼ばれる開発方法論が提唱されていて、そのどれもがアジャイルなのです。

　そして、世の中の開発プロジェクトは、複数の方法論を組み合わせ、いいとこ取りをしながら開発しているケースが多々あります。どれか1つだけを採用しなければいけないということはありません。ウォーターフォールも同様です。アジャイルと対立させる必要なんてないのです。

　業務の文脈や開発フェーズ、チームのセイチョウ段階など、目標の段階に合わせて強弱を変えながら、組み合わせて活用していくのでも構いません。世の中がどうなるのかもわからないのに、何かを網羅的に調べるために長期間を使ってしまったり、そうしてつくられた計画がムダになってしまう恐れがあるのであれば、少しずつでもアジャイルの方法論を組み合わせてみるとよいでしょう。最短でビジネス上のゴールに到達できるように、よいところを共存させましょう。