アジャイル開発12の原則 #

アジャイルソフトウェア開発宣言で宣言されていた内容は、アジャイル開発をする上で大事なマインドセットを述べたものでした。ではその背景にもなるアジャイル開発12の原則を見ていきましょう。先のアジャイルソフトウェア開発宣言のページにリンクがあります。

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


私たちは以下の原則に従う:
顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。

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

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

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

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

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

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

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

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

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

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

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

次はこれについて読み解いてみましょう。

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

開発者にとって最も重要な活動は顧客のビジネスを成功させ満足させることです。そのため、価値のあるソフトウェアを素早く継続的に提供する必要があります。

ウォーターフォールモデルにおいて、開発の目的はQCDの達成でした。これは、顧客とベンダの間で請負契約があり、ベンダは決められた納期までに、予算内に、品質を担保してプロダクトを提供する必要があるためです。しかし、アジャイル開発では前述の通り、準委任契約が前提になります。顧客とベンダは共同でエンドユーザに価値のあるソフトウェアを提供することを共に目指していきます。そのため、アジャイル開発において、開発の目的はQCDの達成ではありません。 もちろんバグがないこと、コストを下げること、納期を守ることは大事です。しかし、エンドユーザに価値のあるソフトウェアを素早く継続的に提供することが最も目指すべきものです。その目的を見失ってはいけません。

要求の変更はたとえ開発の後期であっても歓迎する #

開発者は価値があるのであれば変更を積極的に受け入れます。価値があるのであればというのが大事なポイントです。顧客に言われるがままに変更を受け入れるようなことはしません。

では価値があるかどうかはどうやって見極めるのでしょうか？

価値があるかどうかはエンドユーザが見極めます。 「開発もしてないのにどうやって？」と思われるかもしれませんが、それを検証する仮説検証というプロセスがアジャイル開発にはあります。プロトタイプを作って実際にユーザにヒアリングを行うのです。そうして、この機能は作ったほうがエンドユーザにとって利益があると分かって初めて開発に着手します。

すなわち要求の変更があるということは、改善につながる要求は新しい価値を見つけた証拠にほかなりません。要求の変更は「新しい価値」の発見の機会と捉え変更を前向きに受け入れることが大事です。

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

ウォーターフォールでは要件定義で抽出したすべての機能を一斉に作って、出揃ったら一斉にテストして、完了したらリリースという流れでプロダクトをリリースしてました。しかし、それではエンドユーザが確認できるのはプロダクトがすべてできてからとなります。

そこで、アジャイル開発では動くソフトウェアを短い間隔でリリースし、少しずつ機能追加していく形でプロダクトを作っていきます。なぜかというと、エンドユーザがプロダクトを触ってみないと具体的な意見を引き出せないからです。少しずつ実際に動くプロダクトをエンドユーザに提供することで、仮説検証をやりやすくしています。それがひいてはエンドユーザによりよい価値を提供することに繋がるわけです。

ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働く #

繰り返しになりますが、アジャイル開発において顧客とベンダは、エンドユーザによりよい価値を提供するという目標に向かって共に行動する仲間です。

アジャイル開発では状況が刻々と変化します。そうしたなかで共通の目標が見えないまますすめると認識齟齬などが発生する可能性が出てきます。そうしたコミュニケーションエラーを低くするために関係者全員が一緒の場所で働くことが理想です。

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

開発チームには意欲のある前向きな人々を集める。よくアジャイル開発には開発スキルが必須で、コストをかけて高度な開発スキルをもつ人材をあつめなければならないと誤解をしている人が多い。実はこれは半分正解、半分間違っていて、高度な開発スキルを持っている人材は、そもそも技術習得に意欲的で前向きというオチです。しかし、必ずしもアジャイル開発チームを立ち上げるにあたって、そういった人材を集める必要があるかというとそうではなく、 現時点でスキルはなくとも学習意欲があって前向きな人を集めるのが正しいです。もちろん開発スキルの高い人を集められるのであればそれに越したことはないですが、現実的には難しい場合が多いでしょう。そもそも、アジャイル開発ではどのような仕様になるかはプロジェクトが始まってみないとわかりません。そうした中で「高度なスキルを有する」といっても、どの技術に明るい人材を集めれば？となってしまうと思います。アプリケーションアーキテクチャや、フレームワークもプロジェクトが実際に始まって仮説検証をしてみないと決定できないのですから。ですので集めるメンバとしてはオブジェクト指向プログラミングの開発に長けているぐらいで大丈夫でしょう。

人材を集めることができれば、関係者は開発チームを信頼して仕事を任せて、気持ちよく働けるよう配慮する。開発者はエンドユーザへの価値創造のために、自らが考え、自らの行動と判断に責任を持たないといけません。

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

世の中には様々なコミュニケーションツールがありますが、 相手とその場で会話する以上のコミュニケーション方法はありません。直接的な対話こそもっとも早く効率的で、それでいて最も効果的です。

コミュニケーションにおいて大事なのは双方向であるということです。特にメールは決まった仕様を伝えるだけのような一方通行なやり取りになりがちです。双方向なコミュニケーション構築のため、 SlackやTeamsといったチャットベースのコミュニケーションツールのほうが良いでしょう。しかし、そうしたチャットベースのコミュニケーションを使う場面においても、直接的な対話にまさるものはないという意識はもってコミュニケーションするべきです。

コミュニケーションにおいて表情や声のトーンといったノンバーバルなコミュニケーションが伝える情報はとても大きいです。ツールをつかったコミュニケーションはそういったノンバーバルな部分をつかったコミュニケーションがとれないためです。

関係者全員が同じ空間に集まり、対面で双方向に対話することでお互いの意図を汲み取りやすくなります。

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

アジャイル開発では動くソフトウェアを短い間隔でリリースしますが、動いているすでに完成した機能が進捗をはかる重要な尺度になります。

設計書の完成度など動くソフトウェア以外のものではかる進捗は実際に動作するまで問題に気づけない可能性があり尺度としては使えません。そこでアジャイルでは動くソフトウェアをなるだけ早いタイミングで見せられるように小さな単位でリリースする計画を立てます。

ある機能がリリースまでに数週間かかるという場合、それは機能が大きすぎるとアジャイルでは判断します。機能を細分化して一つ一つの機能は数時間、どんなに長くても2~3日程度でリリースが完了する単位まで細分化すべきです。

リリースする単位が大きいとそれだけ開発時に考慮すべき事項が増えますし、見積もりも難しくなります。 受け入れも難しくなるでしょう。機能を細分化して数時間で終わるような単位になっていれば、メンバー間での認識齟齬が起きにくくなるという利点もあります。

アジャイル･プロセスは持続可能な開発を促進する。一定のペースを継続的に維持する #

アジャイルにおいて大事なのは無理をしないことです。ウォーターフォールの開発ではQCDの達成のために、（特に下流工程で起きがちですが）ときに残業をしてでも納期に間に合わせるといったことが行われます。これができるのはプロジェクトにおわりがあるからです。（すべきではないですが）期限があるからこそムチャがききます。

しかし、アジャイルではプロジェクトに明確な終わりはありません、プロダクトをリリースしたあとも、エンドユーザにより良い価値を提供する、あるいは顧客が目指すビジョンの実現に向けて継続的な開発が続きます。そうした中において、無茶をせず持続可能な無理のない開発ペースを保つというのはとても大事なことです。 無理をした状態では、創意工夫をしたり、改善をしたりといった意欲が起きにくく、トータルでパフォーマンスが低下してしまいます。 開発者だけでなく顧客も心身ともにベストな状態を保ちましょう。

技術や設計をレベルアップさせる意識が、俊敏（アジャイル）さを高める #

開発者は常に最新の技術を学び、効果的な技術はプロダクトに適用することが求められます。特に昔ながらのプロジェクトによくある話として、“稼働実績"という言葉があります。本番稼働していてバグが起きないことを確認しているから、該当箇所には手を入れないようにする仕草です。しかし、機能を追加開発していく中でそうした"稼働実績"を考慮したソースコードの改変はいつか無理が出てきます。気づけば歪なソースコードになってしまいます。

なぜ"稼働実績"にこれまで頼っていたかというと、テストやデプロイのプロセスの自動化がなされていないため、テスト・品質保証に膨大な時間がかかることからそれを削減するためです。逆に言うとテストやデプロイのプロセスを自動化し短時間で実施することができれば、 “稼働実績"に頼ることなく容易に変更できるようになり、ソフトウェアを"あるべき姿"に保てるはずです。

ソフトウェアをきれいに保つということは俊敏さを高めるためにとても大事です。歪になったソフトウェアは影響範囲を見極めるだけで大ごとで、ちょっとした改修でも非常に大きなコストがかかります。プロダクトをリリースした直後は問題なくても、次第にどんどん改修コストが大きくなっていくことでしょう。ソフトウェアをきれいに保つことができていれば、変更も容易になり、たとえシステム全体の規模が大きくなっても、継続的な短期間での機能リリースが可能になるはずです。

しかし、自動テストやデプロイの自動化はとても大変です。機能の実装以上に単体テストの実装難易度が高いこともよく起こります。またソフトウェアの自動テストが短い時間で完了するようソフトウェアを設計することも非常に大変です。非常に大変ですが、自動テストや自動デプロイは俊敏さを保つための分水嶺であり、これを怠ってはいけません。

開発に関わる関係者全員が最新技術を学ぶということに対して価値を認めることがとても大事です。

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

アジャイルはウォーターフォールに比べて少ない要員で早く開発できるとよく言われます。これは半分正解、半分間違っています。アジャイルが早く開発できるのは 無駄なもの(=価値を生まないもの)を作らないから です。たとえエクストリーム・プログラミングのプラクティスを採用したとしても、ウォーターフォールモデルのように最初に全ての機能を定義して、それを全部作っていたらとても時間がかかるでしょう。それこそウォーターフォールと違って人員が少ないのですから、ウォーターフォール以上に時間がかかるのは火を見るより明らかです。

アジャイルでは 「ムダ=価値を生まない」を探して「やめる勇気」を持つこと がとても大事です。これはプロダクトの機能だけでなく、アジャイル開発チームの開発プロセスも対象です。

日々の作業の中から、全員が無駄を見つけ削減することが、開発チームの機敏性を高め、生産性を向上させることに繋がります。

自己組織化したチームのメンバーが協調して動く方が、パフォーマンスが高い #

自己組織化チームという言葉が出てきました。これこそアジャイル開発チームが目指すべき姿です。 自己組織化チームとはチームの外部から指示されるのではなく、自分の仕事を達成するための最善の方法を選択する自律性を持つチームです。開発チームは自分たちで規律やルールを決め、自ら率先して作業の改善や課題の解決に取り組みます。

この自己組織化したチームというのは言葉で言うのは容易ですが、実現するのは非常に大変です。当たり前ですがチームがある日突然急に自己組織化するなんてことはありません。少なくとも、変えようという思いを持ったメンバーがいなければできませんし、そうしたメンバーが少しずつ少しづつ地道に変化を促してようやく実現できるのが自己組織化したチームです。

自己組織化した組織になるとどうなるかというと、特定メンバーに依存しすぎないチームになります。そうすると特定の誰かが抜けてもプロジェクトが行き詰まることが少なくなります。また、メンバーの当事者意識が高まるという効果もあります。それがひいてはパフォーマンスの向上に繋がるというわけです。

定期的な「ふりかえり」により、開発チームのパフォーマンスをより高めるようにする #

先の自己組織化したチームにも関連した話になりますが、アジャイルではチームが常に成長し続けるために毎週振り返り（よく"レトロスペクティブ”、“レトロ"と呼ばれます）を開発メンバ全員で行います。この振り返りこそアジャイルの開発プロセスにおいて最も肝心な部分です。

このレトロの場でチームが抱えている課題や、ムダを見つけていきます。例えば今週はパフォーマンスが上がらなかったとか、リモートワークの難しさなど、日頃の開発の中で上がるモヤモヤをここで共有します。メンバーが抱えているモヤモヤこそ改善のポイントです。ここで大事なのは開発で直面する様々な問題はチームで立ち向かうべき問題であり、個人の責任にしないということです。

例えば、開発をすすめる中で障害を作り込んだとします。効率の悪い自動テストができているとかでもいいでしょう。アジャイルチームはこの問題を作り込んだ開発プロセス自体に問題があると考え、それに対処する手をチーム全員で考えます。決して問題を作り込んだ個人を責めるようなことがあってはいけません。

特定の個人が責められることがないということは、それは心理的安全性が高いということです。 チームの心理的安全性が高くなければモヤモヤを共有することもできません。 振り返りの場では気楽に何でも相談できる空気を作ることが大事です。

ここまででアジャイルの概要の説明はおわりです。最後にまとめます。

まとめ