アジャイル開発の定義

アジャイル開発とは

アジャイル開発とは短期間で小さな機能を繰り返していく開発手法です。1つのチーム内で繰り返しやっていく事でノウハウを蓄積していき、工数の削減や成果物が発注者と受注者で齟齬が起きないようにしていくやり方です。

アジャイル開発の誤解

アジャイル開発というとウォーターフォール型の開発と比べ、誤解が多くあります。この記事でアジャイルソフトウェア開発宣言を引用してその誤解が何かを書いていきます。

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

プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を、価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。

「左記のことがらに価値があることを認めながらも」と最後に書いています。これを見落としていることが誤解の原因です。価値があることを認めているんです。軽んじたりないがしろにしていいなんて書いていません。

プロセスやツール

プロセスを無視しては経緯が見えにくくなり、責任の所在やゴールがうやむやになります。最悪、「なんでこれ作ったんだっけ？」「なんでこれこうなったんだっけ？」「誰だこんなことしたの？」とチームも成果物もばらばらになってしまいます。アジャイルは1つのチームですからチームとして責任があるため、責任の所在はそこまで明確にしなくても…と思うかもしれませんが、それでは再発防止策がとれません。

ツールもないがしろにしてしまうとアジャイルの本質である素早い開発がしにくくなります。新しいツールを導入すればいままでの工数より短縮できるかもしれないのに、「アジャイルだからツールはまぁいいや」としてしまうともったいないことになります。

包括的なドキュメント

各種設計書やテスト成績書・エビデンスなんて適当に作っておけばいい、ということではありません。ウォーターフォール型の開発と同じくらいとなるときついですが、ドキュメントはまともに残しておかなければなりません。

どうしてもこの業界は人材が流動的です。いなくなる人もいれば新たに入る人もいる業界です。そんななか何にも引き継げる資料がない状態は大きなリスクでしかありません。

契約交渉

どこまでかっちりやるかの話にはなりますが、どうしても会社対会社、人対人の関係になりますので、「契約交渉なんて別に適当にやっておけばいいでしょ」なんて考えると危険です。

計画に従う

計画は計画として立てたものですから、それを守ることは当然のことです。「アジャイルだから計画を守れなくたってしょうがない」と考えることはNGです。これは単なる甘えでしかありません。

アジャイルではもしも何かが起きた時に「これをやると計画が達成できなくなるから対応しません、できません。」となることはやめよう、としています。変化が起きた時はチームとして「ではどうしようか」と対話をして今後の事を決めて実行することが重要なのです。