アジャイルソフトウェア開発宣言とは?成り立ちから読み解く

目次

アジャイルの成り立ち

アジャイルという言葉は、開発手法がある程度確立したあとに出現している。先にあったのは、個別の開発手法や流儀である。

XP(エクストリームプログラミング)、スクラム、DSDM、FDD、リーン、カンバンなどの先人たちによって培われた手法が様々存在する。

こうした先駆者たち17人が2001年ユダ州で会議を開いた。そこで、それぞれの考え方や手法について、共通点とは何か?また、相違点とは何か?を確認しあった。

その結果、変化に対応することの必要性や、より重視する4つの価値、そしてその価値を具現化するための12の原則について全員が同意し、お互いが同意した方向性に「アジャイル」という言葉が選択された。

アジャイルが派生したものがスクラム、XPというわけではない。

アジャイルは、共通性を表現するための言葉である。

ゆえに、アジャイル開発と一口に言っても、その実態はスクラムかもしれないし、リーンかもしれない。

そのような理由から、アジャイルの解釈が人によって異なってしまうことは当然である。

不同意の同

上記で上げた、三つ(変化への対応、4つの価値、12の原則)の以外に、「不同意の同意」というものもあった。

それは、プロダクトづくりを行うための詳細なやり方についてはそれぞれで違っており、同意が難しいことから、同意できないことを同意した。

プロダクトづくりの詳細のやり方まで同意してしまうと、やり方を統一する動きとなり、それがかえって新しいプラクティスの発見を阻んでしまう。

四つの価値

三つの同意事項のうちの一つである「四つの価値」について説明する。具体的な内容は、下の画像に示すように「アジャイルマニフェスト」にまとめられている。

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

私たちは、ソフトウェア開発の実践

あるいは実践を手助けをする活動を通じて、

よりよい開発方法を見つけ出そうとしている。

この活動を通して、私たちは以下の価値に至った。

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

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

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

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

価値とする。すなわち、左記のことがらに価値があることを

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

1つ目「プロセスやツールよりも個人と対話を」は、決められたプロセスとあっているか、正しくツールが使えているかといった人間の行動を規定するよりも、人と人との会話を重視するということ。

プロセスやツールに適したふるまいをすれば問題が解決するわけではなく、どうやって問題を解決するのかは、対話の中から発見することができる人間の相互理解に価値を置いている。

2つ目「包括的なドキュメントよりも動くソフトウェアを」は、網羅的なドキュメントを作成するよりも動くソフトウェアが作られることを重視している。ドキュメントは、必要に応じて作成する必要はあるがそれが目的となってはならない。進捗や状況を知るすべは、動くソフトウェアであり、ドキュメントだけでは正しく判断できない。

3つ目「契約交渉よりも顧客との協調を」は、何か問題が生じたり、持っていきたい方向性があったときは、駆け引きで一方の優位性の確保に走るのはやめて、相手と強調し合う選択をとろうという考えである。交渉に時間と精神を費やすよりも協力して問題にあたったり、調和して意思決定を行ったほうが圧倒的に早い。

4つ目「計画に従うよりも変化に対応を」は、事前に決めた計画に現実を合わせるのでなく、現実に起きていることを踏まえたうえで対応を取っていくということである。

12 の原則

  1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
  2. 要求の変更はたとえ開発後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
  3. 動くソフトウェアを、2-3週間から2-3か月というできるだけ短い時間間隔でリリースします。
  4. ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
  5. 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与えれば仕事が無事終わるまで彼らを信頼します。
  6. 情報を伝える最も効率的で効果的な方法は、フェイス・トゥ・フェイスで話をすることです。
  7. 動くソフトウェアこそが進捗の最も重要な尺度です。
  8. アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
  9. 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
  10. シンプルさ(無駄なく作れる量を最大限にすること)が本質です。
  11. 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
  12. チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやりかたを最適に調整します。
よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

新卒4年目です。spring boot, jquery, vue を使ってフロントエンド開発、quarkus、azure kubernetesを使ってバックエンドを作ってました。 今は、UXデザイナーを目指して勉強中です! よろしくお願いします。

コメント

コメントする

CAPTCHA


目次