アジャイルを語る上で、アジャイルソフトウェア開発宣言は避けては通れない道である。これについて個人的な見解を考える。今日はコレ。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
さて、これっていったいどういうことなのか？考えてみよう(◕‿‿◕｡)
アジャイルチームは価値を生み出すために存在する
ここで指している価値というのは、プログラマが書いたソースコードでもない。プロデューサーがまとめた仕様書でもない。ユーザーが実際に使って、メリットとして感じられたものであったり、それを使いつづけることだ。使われないものに価値はない。
マルチファンクショナルな動きがアジャイルを加速させる
プログラマだからコードしか書かない。要求定義されたものしかやりません。という姿勢ではアジャイルは成功しない。アジャイルチームは会社で定められたプロセスやツールよりも実際に要求をしている人間との対話を得て、価値として求められているものを探求するのだ。
要求されるものだけつくって、結局ユーザーには使われずに、満足されないというのは良くある話だ。成功するためには、それだけではダメなのだ。
RFPや要求仕様書が十分な品質であがってくるとは限らない。むしろ、抜けや漏れがあるのがあたりまえであり、不確実性を含んでいる。だからこそ、アジャイルのアプローチが評価されるのである。ころころ変わる、曖昧な表現満載の仕様書よりも、プロトタイプに対する明確なフィードバックの方が、満足いくものを提供できるはずだ。それすなわち、価値を提供することにつながる。
アジャイルで重要なことは、“対話 >>>>>>>>>> 記述”ということ
これは、ドキュメントなどを記述するなと言うことではなく、漏れや曖昧さや、各人間によって、質が違ってくるドキュメント記述よりも、対話を持って補正していくことを重視するということである。完璧なドキュメントは存在しない。完璧っぽい電話帳のようなドキュメントよりも、簡素にまとめられたドキュメントとすぐにフィードバックをもらえる隣人の方がより価値の高いものを生み出していけると考えている。
完璧っぽい電話帳ドキュメントを読むのにも、能力がいるわけで、書き出しで質が下がり、読んで理解する時点でも質が下がる。そして、そんなドキュメントを作成するのに膨大な時間をかけている間に、要求仕様は変化していたりするものだ。そう。まだ、動くソフトウェアは何一つできていないのにもかかわらず。
そして、電話帳ドキュメントを書き上げた人物は仕事を終えた気になっているのである。俺の仕事は終わった、たとえプロジェクトが失敗したとしても他に問題があると言い切るのだ。
プロトタイプに対するフィードバックもコミュニケーション（対話）である
書き慣れないRPFなんていうドキュメントを待っている膨大な時間にコストをかけるぐらいなら、対話によって、プロトタイプを作成して、それに対する具体的なフィードバックを得れば、価値との距離にどれぐらい差があるのか、具体化しやすい。補正もしやすい。
書き出されたドキュメント通りにつくったソフトウェアが、「実はドキュメントに書いていなかったのだが…」といわれる内容や「勘違いして理解していました」という、要素が満載である。きっと、スクラップ＆ビルドする可能性が高い。
一方、対話で信頼関係を気づき、本音で対話したうえでのできたソフトウェアは、価値への補正で済む可能性が高い。
価値を探求しよう！
