アジャイルソフトウェアの12の原則


こんにちは、ライトパスの建守です。

先日は「アジャイルソフトウェア開発宣言」についての記事を書きました。今回は、この宣言に付随する「アジャイルソフトウェアの12の原則」について書きたいと思います。また教科書的なお話しになってしまいますが、アジャイル開発を掲げているライトパスとしては避けて通れないものなので、よろしくお付き合いください。

アジャイルソフトウェアの12の原則

「アジャイルソフトウェアの12の原則」とは、アジャイルなソフトウェア開発をするうえで則るべきルールです。先日ご紹介した「アジャイルソフトウェア開発宣言」がアジャイルなソフトウェア開発をする際に心に留めておくべき心構えであったのに対し、こちらはどのような行動をとるべきかを示したものになります。

さっそくですが、まずは12の原則を列挙しましょう。

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

以下、それぞれについて詳しく見ていきます。

 

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

説明するまでもない簡潔な文章ですが、キーポイントは3つ、「顧客満足」「価値のあるソフトウェア」「早く継続的」です。

プロジェクトを進めていると、担当者はとかく上司の反応だったり、PMO(Project Management Office。プロジェクト横断型で進行管理を監督する部門)や品質保証部門など監督部門からのダメだしだったりを気にしてしまいがちです。しかしここは初心にかえってお客様を満足させることに集中しましょう、という話です。

どうすれば満足させられるか?という問いへの答えが、「価値のあるソフトウェア」を提供すること、しかもそれを「早く継続的に」おこなうことの2つです。これがアジャイルなシステム開発の基本です。

 

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

従来型の開発とアジャイル開発との大きな違いは、従来型の開発が「計画駆動」であるのに対し、アジャイル開発は「価値駆動」である点です。計画ありきの従来型開発の場合、計画とのズレを生じさせる要求の変化はプロジェクトの大敵です。しかし、価値ありき、つまりお客様にとってのお役立ち度合が最優先事項となるアジャイル開発では、変更を加えることで価値が上がるのであれば喜んでそれを受け入れます、というのが、この2つ目の原則です。

 

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

お客様に満足いただけるものが作れているか、それを確かめる唯一の確実な方法は、作ったものを実際に使っていただくことです。開発開始から1年をかけて作り上げたものを使ってみていただいたらイマイチな反応だった・・・。これでは1年間という時間とそこにかけたコストが無駄になります。

アジャイル開発では、本当に顧客満足が得られるか、万が一方向性がずれていたらすぐに修正できるよう、短期間でリリースしてフィードバックをもらい、すぐに軌道修正する、というプロセスを繰り返すことで、このような無駄が生じるリスクを最小化します。

 

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

ここまではどちらかというと、システム開発側の担当者に対する戒めのようなことが列挙されていましたが、ここではじめて「ビジネス側」の話が登場します。唐突に、という気がするかもしれませんが、一つ上の原則(短い時間間隔でリリース)を実現するために欠かせないルールということで、この順番になっているのでしょう。

アジャイル開発では多くの場合、2週間か1か月を1つの区切りとして、システムを部分的に作ってはリリースすることを繰り返します。これを可能にするには、開発者がビジネス側の思いを深く理解して迷うことなく開発作業を進められること、疑問点があればすぐに解消できることが必要です。そしてそのための手段として、ビジネス側のご担当者と開発者は密にコミュニケーションが取れる状態をプロジェクト期間中は維持しつづけなければいけませんよ、というお話しです。

 

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

アジャイル開発かどうかにかかわらず、組織として当たり前のことだろ、という声が聞こえてきます・・・。まぁその通りなのですが、アジャイル開発では特に重要なんです(いや、やっぱりどんな組織でも重要だな・・・)。

変化を受け入れる、短期間でリリースを繰り返す、言うは易しというもので、実際にこれをやろうと思うと、担当者はたいへん疲弊します。従来型のプロジェクトに携わるとき以上にハイパフォーマンスを求められるからです。担当者がプロジェクトの最後まで高い生産性を維持できるようにするには、彼らのやる気を引き出す環境の整備が必要になります。

開発者というものは、多かれ少なかれ職人気質なところがあります。こうした人々のやる気を引き出すには、裁量権を与えること、同レベル以上のメンバーと組ませて日々成長できる状況におくこと、これが肝です。ですからアジャイルチームでは、こうした環境の整備を必須としているのですね。

 

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

従来のシステム開発では、情報伝達手段の中心はドキュメントでした。ドキュメントというのは、情報を残すという観点では最強のツールなのですが、作るのに時間とコストがかかる、そのため情報伝達のスピードが遅い、という欠点があります。

アジャイル開発ではスピードが命。よって、フェイス・トゥ・フェイスのコミュニケーションを重視します。

もちろん、文書化したほうが伝わりやすい情報、後々まで残さなければいけない情報は何らかの手段で文書化・電子化して残します。法律や契約で作成が定められている文書も作ります。しかし、最重要なのは「顧客満足」をもたらす「価値あるソフトウェア」です。ドキュメントのないソフトウェアが出来上がった状態と、ソフトウェアは不完全だけど完璧なドキュメントがある状態、どちらが顧客に満足をもたらすのかは考えるまでもないことです。このことを忘れずに、状況に応じて最適なコミュニケーション手段が選択できるようになりましょう、というのが、この原則の本当に意味しているところではないでしょうか。

 

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

従来型の開発では、「〇〇設計書が60%書きあがりました」「△△機能の開発が30%終わっています」といった進捗報告の仕方をしていました。しかし、この「予定の60%の項目が埋められた設計書」や「30%ほどできた機能」は顧客価値をもたらすでしょうか?もちろん、何ももたらしません。

顧客価値をもたらしうるのは、動作するソフトウェアだけ。であれば、動作するソフトウェアがどのくらい出来上がったかでプロジェクトの進み具合を見ましょうよ、というのがこの原則です。ビジネス上の価値を生み出さない中間成果物によって進捗管理をする、ということをアジャイル開発ではしません。

「じゃあ、ソフトウェアが完成するまでずっと進捗率ゼロ%なの?!」とお思いになるかもしれませんが、そんなことはありません。3つ目の原則にあったように、アジャイル開発では短期にリリースを繰り返します。リリースというのは、動作するソフトウェアを提供する、という意味です。そして1回のリリースに複数の「機能」(ユーザーが何らかのタスクを完遂できるソフトウェアのモジュールのこと)が盛り込まれているのが一般的です。ユーザーがそのソフトウェアを使ってできるようになったタスクの数で進捗を図るのだ、というほうがわかりやすいかもしれませんね。

 

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

端的にいえば「燃え尽き」防止!ということですね。近年「働き方改革」の文脈で語られる「長時間労働の抑制」につながるものがあります。

先にも述べましたが、アジャイル開発をするのは簡単なことではありません。単位時間あたりに出すべき成果の量や質が、従来型の開発プロジェクトよりも高い水準になります。短期間でリリースを繰り返すということは、常に締め切りに追われているということでもあり、心身にかかるストレスは並大抵のものではありません。この状態で長時間労働をしたら、おそらく開発者はすぐに燃え尽き症候群にかかってしまうことでしょう。

燃え尽きた人間を働かせ続けることはできないので、こうなると担当交代は避けられません。そして担当交代は引継ぎによるパフォーマンス低下をもたらします。たとえ燃え尽きるまで行かなくても、疲労がたまれば集中力が落ち、作業のスピードや質が下がって、やはりプロジェクトに悪影響を及ぼしてしまいます。

価値あるソフトウェアを継続して素早くお客様にご提供するには、チームのメンバーが疲弊することなく稼働し続けられるペースを守る必要がある、そうすることで結果的に、お客様のビジネス価値の最大化につながる、というのがこの原則の意味です。

 

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

妙に硬い文章ですね(汗)。原文では「Continuous attention to technical excellence and good design enhances agility」となっています。うーん、原文もわかりにくい。。

アジャイル開発とは、文字通り「アジリティ」=「俊敏性」「機敏さ」を重視した開発プロセスです。このアジリティを維持し高めるためには、技術的に優れていることと、設計を美しく保つことが必要なんです、ということですね。

インターネットで見つけた技が使えそうだから詳しいことはわからないけど使っちゃえ、とか、ここは本当は作り直したほうがきれいな設計になるんだけど時間がもったいないからこのままでいいや、とかいう判断は、目先の開発生産性を高めることにはつながりますが、将来的なことを考えると賢明な判断とは言えません。

技術力を磨く時間をいとわないこと、多少の時間を割いてでも分かりやすい設計を保つことが、トータルで見たときに高いアジリティを発揮する近道なのです。

 

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

こちらの原文は「Simplicity–the art of maximizing the amount of work not done–is essential」となっています。ん?なんか日本語訳とちょっと違うような・・・?カッコの中は、「やらない仕事の分量を最大化すること」という意味じゃないのかな、、と思うのですが。

残念なことに、世の中のシステムが備えている機能のうち60%はまったく使われていない、もしくはほとんど使われていない機能なのだそうです。「もしかしたら必要になるかもしれないから」「あったら便利そうだから」という理由で機能がどんどん増えていくのが、従来型のシステム開発の特徴でした。

多機能な電化製品と単機能な電化製品を比べると、後者のほうが見た目も作りもシンプルで、かつ長持ちするというイメージがありませんか?システムも同じで、機能が少なければ少ないほど、使いやすく、メンテナンスもしやすいものです。なのに、使われない機能で膨れ上がり、ちょっとした機能変更にも莫大な時間とコストがかかってしまう、というのが大半のシステムの現実。

これを避けて、本当に使う機能だけを作るぞ!ということをアジャイル開発では原則としているのです。

 

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

「自己組織的なチーム」ってなんやねん・・・。原文は「The best architectures, requirements, and designs emerge from self-organizing teams」です。「self-organaizing teams」。確かに「自己組織的なチーム」ですね・・・。

ここでいう「self-organaizing」は、自律的・自発的・自助努力で、といった意味合いかと思います。チーム外からの指示や情報に惑わされることなく、チームメンバーたちが自分たちの力で調べ、話し合い、考え抜いた結果のアーキテクチャや要件、設計が、(そのチームにとって)ベストな答えである、ということです。

もちろん、チームメンバーたちに欠けているスキルや情報がある場合に、周囲の助力を仰ぐのは当然のことです。ですが、結果に対して責任を負うのはあくまでチームメンバーなのだという自覚のもと、常に自分事として取り組まなければいけないという自戒が込められた原則ですね。

 

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

従来型システム開発の代表格であるウォーターフォール開発では、プロジェクトの最後に振り返り(反省会のようなもの)を実施するのが一般的です。プロジェクトの途中で振り返りを実施する現場もありますが、いずれにせよ振り返りで得られた教訓を生かす場がありません。なぜなら、プロジェクトは滝の水が上段から下段に向けて流れ落ちるように、決められたルートを一直線にたどっていくのがウォーターフォール開発だからです。完了した工程をもう一度実施することは(原則としては)ありえないので、教訓を生かすのは次に担当する別のプロジェクトの時、ということになります。

いっぽうアジャイルでは、短い期間でリリースを繰り返します。つまり、要件定義・設計・開発・テスト・リリースという流れを何度も何度も繰り返し実施するわけです。ですから、1回のリリースの終わりに振り返りをおこない、教訓を得ることができたらな、それをすぐに次の繰り返しで適用することができるわけです。こうすることでアジャイル開発は、高い生産性を維持し、つねに向上し続けることができるのです。

 

さいごに

大変長い文章になってしまいましたが、シンプルな12の文章に込められた思いの丈が深いゆえだということで、ご容赦ください。

従来型のシステム開発プロジェクトにおける最大の関心事が「プロジェクトの目的をいかに当初計画通りに達成するか」ということであったのに対し、アジャイル開発プロジェクトにおける最大の関心事は「いかに顧客価値を最大化するか」ということにあるという違いがあります。

この違いが、プロジェクトへの取り組み方に影響を及ぼしています。そして、変化の早い今の時代において、どちらのやり方がより適しているかと考えれば、多くの場合、アジャイル開発に軍配が上がるのではないでしょうか。