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

アジャイル開発とはなにかという問いに対して簡潔に答えるとすると、 「アジャイルソフトウェア開発宣言のマインドに則り、アジャイル開発12の原則に従った開発」 となります。 ではさっそく アジャイルソフトウェア開発宣言 に目を通してみましょう。

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

私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。

この宣言はKent BeckやRobert C. Martin(アンクルボブ)といった著名なソフトウェア開発者らによって2001年に生み出されました。 「プロセスやツールよりも個人との対話」「包括的なドキュメントよりも動くソフトウェア」「契約交渉よりも顧客との協調」「計画に従うことよりも変化への対応」 これら4つがアジャイル開発において遵守すべきマインドセットとして宣言されています。

まずこれらについてまず噛み砕いて理解してみましょう。

プロセスやツールよりも個人との対話 #

これはどういうことかというと 「信頼し合う個人間でのコミュニケーションが最良」、 「プロセスを守ることが常に正しいとは限らない」、 「ツールに『使われている』状態を避ける」 ということです。

アジャイル開発ではメンバー間の密なコミュニケーションを重視します。 例えばプロジェクトのコミュニケーションツールとして、 メールやメーリングリストを使うことは往々にしてよくあります。 チーム間の連絡に連絡票のようなものを使うこともあるでしょう。 しかし、そうした伝票やツールでのやり取りはとても時間がかかります。 それよりも直接対話したほうが問題の解決が早い場面は非常に多いということをここでは言っています。

また、アジャイル開発ではプロセスは常に見直されます。 アジャイル開発の重要なキーワードとして変化への俊敏な対応というのがあります。 これはプロダクトの仕様だけにとどまらず、チームの開発プロセスについても必要に応じて自律的にどんどん変化させていきます。 アジャイル開発においてチームに適した開発プロセスはチームによって異なります。 もちろん、XPやスクラムといった基本的な考え方はありますが、それが本当にそのチームに適しているかはわかりません。 プロダクトの開発を進めていく中で、チームごとに開発プロセスは最適化され変化していきます。

包括的なドキュメントよりも動くソフトウェア #

最終的なエンドユーザーが求めているものはなにかというと、 それはプロダクトそのものになります。 プロダクトを作成するための設計書をいくら作り込んだところで 利用者にはなんのメリットもなく、そこに注力すべきではありません。 私達が注力するべきはプロダクトそのものに他なりません。

さらに、設計書は書き捨てが許されず、書いたあともメンテナンスし続けないといけません。 しかし、アジャイル開発ではプロダクトの仕様はどんどん変化していきます。 その変化に合わせて設計書もメンテナンスしていくのは非常に大変です。 設計書をメンテナンスして、それでいてプロダクトも迅速にリリースして、両者を両立させるのが困難だというのは想像に難くないでしょう。

プロダクトの設計書は不要だと分かりました。ではプログラムのコメントについてはどうでしょうか？

これも不要だというのがアジャイルの考え方です。 どういうことかというと、そもそも一読して理解できないようなプログラムを書いてはいけないということです。 アジャイル開発者は読みやすく綺麗なコードを書き、それを維持する努力をしていかなければなりません。

では、アジャイル開発においてドキュメントは一切不要でしょうか？

答えはNOです。例えば、今まさにあなたが読んでいるこのドキュメントは、 アジャイル人材を育成し、チームをスケールしていくために必要なものです。 この他にも人員がプロジェクトに新たにアサインされたときに読むオンボーディングの資料はあったほうがいいでしょう。

プロジェクトによって必要な文書は異なりますが、必要に応じて必要なドキュメントだけを作ることが大事です。

契約交渉よりも顧客との協調 #

これまでのSIビジネスにおいては顧客とベンダーという関係があり、 ベンダーは請負契約に則って、要件定義で定義した機能を充足するシステムを作ることが求められてきました。 しかし、開発を進めていく中で対応が難しい課題がでてきたり、 もっとこうしたらプロダクトは良くなるのにと思う場面がでてくるのはよくある話です。

しかし、従来のSIビジネスにおいては契約は絶対です。 途中で要件定義から外れることをしようものなら契約違反ですし、 それを正しくやろうとしても追加契約をして、前工程までの成果物を見直してと多大な時間と労力、コストが掛かります。 しかしながら、顧客もベンダーもエンドユーザに対して、いいプロダクトを提供したいという思いは共通のはずです。 その目標に対して契約は大きな障壁となります。 そのため、アジャイル開発では請負契約ではなく、準委任契約で作業をすすめることが大前提になります。

アジャイル開発ではエンドユーザに対して、よりよい価値を提供するという目標のもと、 顧客とベンダは一体となって取り組みます。そこに顧客とベンダという上下関係はあってはいけません。 その目標の実現のために「もっとこうしたらもっとよくなるのではないか？」という提案を顧客もベンダも自由に出し合い、 すぐにそれを実現してエンドユーザに提供することをアジャイルは重要視します。

計画に従うことよりも変化への対応 #

ウォーターフォールモデルは要件定義で定義した機能を、 細分化して見積もりを実施し、計画を立てて、計画通りに開発をすすめるモデルでした。 ところが多くの場合で計画通りに進むことはありません。なぜでしょうか？

それは単純に、正しく計画することはできないからです。 要件定義工程で正しく機能を要件として抽出できないこともありますし、 要件として抽出したつもりが、結果的には必要なかったりすることもあります。 また、スケジュールを見積もる段階で正しく見積もることができなかったり、 実装の過程で思わぬ課題に直面することもあるでしょう。

ウォーターフォールにおいて計画は多くの場合で計画通りに進まなくなるわけですが、 アジャイル開発では変更があることを前提に物事をすすめるという考え方をします。 変更があることを前提にするので詳細な見積もりをとったりすることはありませんし、 事前に要件をすべて洗い出すこともしません。 「これは絶対に必要になる」という機能を順序付けして必要最小限の機能を、 少しずつ追加開発していきます。 開発を進めていく過程で必要な機能が追加になるかもしれません。 それもアジャイル開発では受け入れます。 変化を前提とした開発プロセスがアジャイルなのです。

アジャイルソフトウェア開発宣言はアジャイル開発に臨む開発者持つべきマインドセットについて述べているということがわかると思います。 では次にこれらのマインドセットの背景にあたるアジャイル開発12の原則を見ていきましょう。