アジャイルソフトウェア開発宣言を読み解く

開発手法のアジャイルですが、とてもふわっとしていて、アジャイル開発宣言からどのようなものか読み解いて行こうかと思います。
※これが正しいアジャイルだとも言えないものなので注意してください。

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

まずはアジャイルソフトウェア開発宣言を見てみましょう。
アジャイルソフトウェア開発宣言

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

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

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

良くある誤解

よく「アジャイルってこうでしょ？」という勘違いを多々見かけます。

ドキュメントは要らない
柔軟な対応が必要なので計画は立てない

他にも多々見受けられますが、明らかにアジャイルソフトウェア開発宣言と違うものだけ を選びました。

誤読の原因

これらの誤読の原因は以下の部分が原因があると推測します。

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

記載されているのは より価値をおく をおくです。
例えばドキュメントを書かないとは一切書かれておりません。
アジャイルソフトウェア開発宣言でも 左記のことがらにかちがあることを認めながら と記載されています。

アジャイル宣言の背後にある原則

アジャイルソフトウェア開発宣言とは別に アジャイル宣言の背後にある原則 というものがあります。

私たちは以下の原則に従う:

顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。

要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。

動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。

ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。

意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。

情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。

動くソフトウェアこそが進捗の最も重要な尺度です。

アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。

技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。

シンプルさ（ムダなく作れる量を最大限にすること）が本質です。

最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。

チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

アジャイル宣言の背後にある原則

アジャイル宣言の背後にはこれだけの原則があります。

アジャイル原則まとめ

アジャイル原則を簡単にまとめると以下のようになります。

顧客の満足度が最優先
価値のあるソフトウェアを早く継続的に提供
変化を味方につけ、お客様の競争力を引き上げるために要求変更は開発の後期でも歓迎
動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリース
ビジネス側の人と開発者は、プロジェクトを通して一緒に働く
一定のペースを継続的に維持できるようにしなければならない
技術的な卓越性と優れた設計に対する注意が速さを高める
無駄なく作れる量を最大限にすることが本質
最良のアーキテクチャ・要求・設計は自己組織的（チームメンバが個々が直接的な管理者が居なくても成り立つ）なチームから生み出される
チームが効率を高めることが出来るか定期的に振り返り、最適に調整

アジャイル開発宣言を読み解く

アジャイル原則を踏まえてアジャイル開発宣言を読み解いていきます。

顧客満足度が最優先
顧客と良く話し合う
開発者だけではなく、ビジネス側の人間もチームとしてプロジェクトを通して働く
2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリース
動くソフトウェアが進捗の最も重要な尺度
動くソフトウェアは重要ではあるがドキュメントは不要ではない
価値のあるソフトウェアを早く継続的に提供
計画を立てるが計画よりも顧客のために開発の後期でも変化への対応を行う
無駄なく作れる量で行う
技術的に高いメンバーを揃える必要がある
チームメンバーが自己管理でき必要である
定期的に振り返りを行い、改善を行う

なんちゃってアジャイルになる問題点

アジャイル開発宣言だけを読んでアジャイル開発をやってみようとすると良く以下のような問題が発生します。

チームメンバが自己管理出来る高いレベルがないと成り立たないのにチームメンバの管理が必要になる
動くソフトウェアに価値が置かれすぎてドキュメントが作られない
開発後期に大きな仕様が変更される
計画が度々変わるので計画を立てない、立てづらい
短い間隔で無駄なく開発出来る量で行う必要があるのに顧客満足が優先される
定期的な振り返りがなく、問題点の改善が行われない

まとめ

アジャイル開発において多々問題が発生するのは「アジャイル」という開発手法がアジャイル開発宣言からふわっと広まってしまったせいだと考えています。
また間違ったアジャイルを経験した人が、そのまま「アジャイル開発」といって開発を広めている気もします。

アジャイルソフトウェア開発宣言、背後の原則を読んでいたら本来のアジャイルは個々人に高いレベルが要求されるように感じました。
チームに経験が浅い人が入ると問題が発生するような気がします。

またIPAもアジャイル開発宣言について資料を出していますのでよく読んでください。
アジャイルソフトウェア開発宣言の読みとき方

参考

アジャイルソフトウェア開発宣言
 アジャイル宣言の背後にある原則
 アジャイルソフトウェア開発宣言の読みとき方
 アジャイル開発版「情報システム・モデル取引・契約書」～ユーザ／ベンダ間の緊密な協働によるシステム開発で、DXを推進～：IPA 独立行政法人情報処理推進機構