アジャイル開発を始める上で重要なこと
アジャイル開発を導入する企業が増えている一方で、アジャイル開発が上手く行かないケースも見られています。
本記事では、「アジャイル開発を始める上で重要なこと」として、
具体的なスクラムなどの開発手法については触れず、あくまで始める上での考え方について説明します。
アジャイルとは「ある状態」を指している
「アジャイル開発」を行う上で、「アジャイル」という言葉と生まれた背景を理解することが非常に重要です。
そのため、まずアジャイルという言葉について説明します。
アジャイルと聞くとスクラム、XPなどの開発手法の話がよく持ち出され、ウォーターフォール開発などと対比されますが、アジャイル自体の意味としては「ある状態」を指しています。
では「ある状態」とはどういった状態なのか。
「顧客に対して継続的に価値を提供出来ており、そのためにチームが改善をし続けられている」
この状態が、アジャイルが指し示す言葉と考えています。
「スクラムやXPをやっていること」がアジャイルではなく、上の状態になっていることがアジャイルと言えます。
アジャイルが生まれた背景
「顧客に取って価値がある成果物を作り続け、顧客が満足すること」を達成するためにはどう開発するのがベストなのか？
それを考える上で、ソフトウェア開発におけるリスクを考える必要があります。
ソフトウェア開発でのリスクは様々なリスクが存在しますが、その中で最も深刻なリスクは「無駄なものを作るリスク」です。
バグも無く、処理速度も完璧なソフトウェアを期日通りにリリースしたとしても、顧客に取って必要なものでなければ、掛けたコストが全て「無駄」になってしまいます。
過去のようにインターネットが普及していない時代と違い、世の中に情報が溢れ、誰でも簡単にアクセス出来る状態になっている今、欲しいものを顧客が手に入れることは容易になっています。
そのため、今では代えが効かないような、本当に必要なものを作ることは過去より難しく、不確実性が高くなっています。
このリスクを避けるために、どのように開発していけば良いのか。
これがアジャイルが生まれた重要な背景の1つです。
アジャイルソフトウェア開発宣言
では「無駄なものを作るリスク」をどう避ければ良いのか？
有識者が議論し、出た結論が「アジャイルソフトウェア開発宣言」に記されています。
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
これらは具体的に何をすれば良いか、が書かれているわけではなく、
「価値観」について書かれている文章になります。
この「価値観」に共感し、この「価値観」を根底に行動していくことがアジャイル開発チームとして非常に重要になります。
この「価値観」に準じて、より具体的な原則として「アジャイルソフトウェア開発の12の原則」があります。
1.顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
2.要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。
3.動くソフトウェアを、2-3週間から2-3ヶ月という
できるだけ短い時間間隔でリリースします。
4.ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。
5.意欲に満ちた人々を集めてプロジェクトを構成します。
6.環境と支援を与え仕事が無事終わるまで彼らを信頼します。
7.情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。
8.動くソフトウェアこそが進捗の最も重要な尺度です。
9.アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。
10.技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
11.シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
12.チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。
これらの原則はソフトウェアを作っている方なら「無駄なものを作るリスクを避ける」意味で、共感できる部分も多々あるかと思います。
例えば、
3.「動くソフトウェアを、2-3週間から2-3ヶ月という できるだけ短い時間間隔でリリースします。」
は、1年と掛けて作ったシステムが全く無駄なものにならないために、
短いスパンでリリースしフィードバックを見せることで本当に無駄ではないのか、を試すことに繋がると私は考えています。
スクラム、XPなどの開発手法はこれらの宣言に書かれていることを根底におき、プロジェクト開発に落とし込んだ開発手法になっています。
わかりやすい例で言えば、
12.チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。
これはスクラムの「レトロスペクティブ」に当たります。
方法論に捉われない
ここまで、アジャイルは「状態」を表しており、
その「状態」になるために必要な「価値観」「原則」があることを書きました。
アジャイル開発を行う上で重要なのはここまでのことをチームで共通認識を持ち、後の開発手法についてはチームで最適な手法を考え、自らで改善していくことです。
よく開発現場でもスクラムを導入していく中で、上記に対して理解しているメンバーとそうでないメンバーでは、スクラムに掛けるコストや方法論に対して本質ではない議論が行われます。
例えば、私の所属していたプロジェクトでは「スクラム」をやるのであれば「このイベントをこの形式で必ずやらなければいけない」という議論が出たことがあります。
これは、スクラムの形式を守ることが目的になってしまっています。
もっとも重要なのは「顧客に対して継続的に価値を提供出来ており、そのためにチームが改善をし続けられている」かどうかです。
自分たちのチームの状況を踏まえて、スクラムの形式をチームなりにカスタマイズしていき、改善していけることが非常に重要です。
手段に捉われず、全てのイベントに対して目的をはっきりさせることで、チームの状態を改善出来ます。
自分たちが何のためにアジャイルを始めたのか、どういう状態がゴールなのか、そのためにはどうすべきなのか？の目線を常に合わせることがアジャイル開発チームを成功させる要因の1つです。
最後に
本記事のまとめです。
1.アジャイルとは「顧客に対して継続的に価値を提供出来ており、そのためにチームが改善をし続けられている」状態を指し、その状態になるには「無駄なものを作らないリスク」を避けることが重要。
2.「無駄なものを作らないリスク」を避けるための価値観や原則として「アジャイルソフトウェア開発宣言」や「アジャイルソフトウェア開発の12の原則」がある
3.価値観や原則の上でチームにとって最適な開発手法を選定し、状況に応じて手法をカスタマイズし、常に改善することが重要
アジャイル開発は導入すれば全てが上手くいくような銀の弾丸ではなく、
むしろ本質の共通理解しないまま進めるとステークホルダーやメンバーとの期待値がずれ、失敗する可能性が高くなります。
アジャイル開発をこれから始める際は、まず「なぜアジャイルをやりたいのか」を自問し、目的をはっきりさせることがアジャイル開発の成功を高める第1歩になります。ぜひ、行なってみてください。