アジャイル宣言の背後にある原則（後半）｜本質を読み解く

アジャイルソフトウェア開発宣言の価値観とセットになっているアジャイル宣言の背後にある原則（12個の原則）を読み解きます。こちらは後半の7個の原則について読み解きます。

※「アジャイル宣言の背後にある原則（前半）｜本質を読み解く」の続きとなります。

６.フェイス・トゥ・フェイス（対話）を大事にする

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

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

アジャイル宣言の背後にある原則より引用

「フェイス・トゥ・フェイスで話をする」とは顔を付き合わせて対面で対話をするということです。

「もっとも効果的」であることは当然であると考えており、対話に勝るコミュニケーション手段はありません。話す言葉だけでなく、声の調子、表情、しぐさ、態度、間合い等を含めて、「文字」だけより圧倒的に情報量が多いからです。また、双方向のコミュニケーションをリアルタイムに行うことができるため、互いの認識を確実に合わせることができます。

「もっとも効率的」については少し考察します。「効率的」であるというのは、コストに対して得られる結果が大きいことを指します。さて、どのようなコストが考えられるでしょうか。

人は無意識にコストと得られる結果を天秤にかけて判断しますので、上記のコストを可能な限り下げてあげることで、自然と「対話」の頻度が高くなっていくと考えています。

一方で、対面で会うことが難しい状況や環境になることもあります。その場合は、オンラインツールなどを活用することができます。顔が見えるかたちでオンライン会議を行えれば対面に近い効果を得ることができます。画質や音質、映像の範囲（顔だけでなく全体を見渡せるようにするなど）を工夫するとより一層よくなります。

「フェイス・トゥ・フェイス」にこだわるのではなく、そこで得られる効果に着目して、手段を選択できるとよいですね。

７.動くソフトウェアで進捗を測る

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

Working software is the primary measure of progress.

アジャイル宣言の背後にある原則より引用

下記のような進捗の尺度を使うことが多いのではないでしょうか。「動くソフトウェア」が尺度であるとはピント来ないかもしれません。

まず、「進捗」とは何かについて考察します。ここでは目的の達成（ソフトウェアによるユーザーの満足）に対する達成率になると考えています。そして、そのための指標（measure）は意味のあるものでなければなりません。

上記の尺度に意味がないわけではありませんが、いくらドキュメントを作成しても、バグを改修しても、課題を解決しても目的を達成することができるか分かりません。機能開発の進捗率では「90%」でずっと止まるといったケースが起こることもあります。

それに対して「動くソフトウェア」を現物として見れば、確実にユーザーの満足に繋がるものかどうかが分かります。中間成果物状態で進捗を把握したつもりになるのはリスクが高いのです。

スクラムではスプリントレビューを経て、受け入れられたスプリントバックログのことを『インクリメント』と言います。日本語では「潜在的リリース可能なプロダクト」となります。これが、『動くソフトウェア』と同義です。

つまり、『動く』という意味は動的に動けばいいというわけではなく、リリースに耐えうる品質を備えて、価値を提供できる働きをしてくれるもの、となります。

『潜在的に』は少し説明が難しいです。実際に世に出すためには組織のルールや必須の手順があるでしょう。そのため、すぐにリリースできないとしても、モノとしてはいつでもリリースできるもの、という意味で潜在的に、となります。

補足として、『品質』は大きく2つに分けることができます。アジャイルでは両方の品質が求められます。

８.持続可能なペースで開発する

アジャイル･プロセスは持続可能な開発を促進します。

一定のペースを継続的に維持できるようにしなければなりません。

Agile processes promote sustainable development.

The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

アジャイル宣言の背後にある原則より引用

「持続可能（sustainable）」という言葉を多く目にするようになりました。それは、「持続可能な開発目標（SDGs）」に起因していると考えています。SDGsは2015年9月の国連サミットで採択された「持続可能な開発のための2030アジェンダ」にて記載された2016年から2030年までの国際目標です。その中で「環境、人権、平和」を守っていくことが宣言されています。

一方で、アジャイルソフトウェア開発宣言は2001年ですから、かなり時代を先取りしているように思えます。

さて、誰が持続可能なペースになるべきなのでしょうか。主語が英文では「The sponsors, developers, and users」となっています。「sponsors」は「顧客」、「developers」は「開発チーム」、「users」は「ユーザー」と考えています。

プロジェクトの現場ではデスマーチ（death march）と呼ばれる、過酷な労働環境になってしまうケースがあります。開発チームだけではなく顧客についても高稼働（高ストレス）の状態が続いてしまいます。そうすると、肉体的にも精神的にもダメージが蓄積し、倒れてしまうことも珍しくありません。近年は「働き方改革」等も功を奏し、以前よりはマシになってきましたが、まだまだ過酷なプロジェクトは後を絶ちません。

そのような労働環境では良いソフトウェアはできませんより、何より、誰も幸せになりません。一定のペースを維持することができれば、人もソフトウェアも健康を維持しやすくなります。

一定のペースにするために「アジャイル・プラクティス」は役立つということです。

ここで、なぜ「users」が主語に入っているのか気になった方はおりますでしょうか。ソフトウェア開発する側が一定のペースになるのは分かりますが、利用者である「ユーザー」は労働するわけではありません。また、日本語訳では主語が省略されています。

私は下記のように解釈しています。

一定のペースで継続的に「ユーザー」に対してソフトウェア（価値）を提供する。

つまり、開発をする側の人だけでなく、ビジネス自体も持続的であるべきだという意図が含まれているのではないでしょうか。

「DevOps」という言葉もあります。開発と運用を合わせた造語ですが、運用と同時に開発が終わりなく続くと考えると、持続的にならざるを得ないと考えています。

９.クリーンコードがアジリティを高める

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

Continuous attention to technical excellence and good design enhances agility.

アジャイル宣言の背後にある原則より引用

アジリティ（機敏さ）を高めるために、技術と設計が優れているかについて継続的に意識するということです。

特に、常に「クリーンコード」の状態を保つことが最も重要です。レガシイなシステムのスパゲティソースは目も当たられません。開発のサイクルの中にリファクタリングを組み込んでいかないと、どんどんと生産性が下がっていきます。この「クリーンコード」を維持していくためにドメイン駆動設計（DDD）を学ぶことをおすすめします。

また、プロジェクト開始時の技術を組み合わせて設計したものに固執するのではなく、最新の技術をウォッチして適用することや、外部の環境変化（顧客ニーズ、等）に合わせて設計を変えていくことが必要です。

さらに、継続的な変更やリリースをしていくための設計（アーキテクチャ）も積極的に取り入れたいところです。例えば、クラウドネイティブ環境（DevOps、MSA、CI/CD、コンテナ）を構築することもアジリティを高めることができます。

レガシーなシステムはアジリティを高めるにあたって足枷となりますので、モダナイゼーション（トランスフォーメーション）を検討できるとよいですね。

１０.常にシンプルな状態を保つことがアジャイルの本質

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

Simplicity–the art of maximizing the amount of work not done–is essential.

アジャイル宣言の背後にある原則より引用

やらないことを最大限に増やすと、その分、使える時間が増えるため、本当に大事なこと（作業、機能、等）にフォーカスすることができます。そうして、本当に大事なことだけが残っているという状態が、結果としてシンプルだということです。

必要かもしれない機能を開発することは無駄になるだけでなく、技術的負債を生み、開発したコスト以上のコストがかかります。また、ソフトウェアの開発作業だけでなく、必要かもしれない会議に出席することも無駄です。全ての作業（仕事）には目的がありますので、「それは本当に必要か？」と自身や作業の依頼者に対して問いましょう。

また、一度開発した機能を削減することもシンプルさを維持するために必要になる場合があります。せっかく作ったものを消すのはもったいない気もします。しかし、あまり使われない、価値を発揮しない機能は技術的負債になり、消したほうがプロダクト全体として価値が上がる場合があります。

消すコストが小さいのはソフトウェアの大きな大きな利点です。

一方で対義語となる「複雑さ」がアジリティを落としてしまうことは容易に想像がつくかと思います。複雑なものは理解するのも時間がかかり、実装にも時間がかかり、バグを産みやすく、結果としてユーザーの利用も難しくします。常にシンプルであることを目指します。

１１.自己組織的なチームの中に意思決定がある

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

The best architectures, requirements, and designs emerge from self-organizing teams.

アジャイル宣言の背後にある原則より引用

まず、「自己組織的なチーム」とはどのようなチームでしょうか。

私は、意思決定が中にあり、目的に向かう作業、課題解決、カイゼンを自律的にできるチームと理解しています。簡単に言うと、開発チームが組織として成り立っているということです。組織になっている（成熟している）のであれば、チームに対する細かいチェックは不要となり、サーバント型の支援をすればよいだけです。

次に「最良のアーキテクチャ・要求・設計」の部分を読み解いていきます。「要求」は顧客が出すものであるため、チームから生み出されるという表現には違和感があります。例えば、顧客も開発チームの中に入るのであれば理解できないこともありません。しかし、ここでは「生み出す」というところを「判断する」にした方が自然になると考えています。

ソフトウェア（および顧客ニーズ）に対するコンテキストを一番理解しているのはチームとなります。数多あるアーキテクチャ・要求・設計の案がある中で、実際にどれを最良（最適）として取り入れるかを「自己組織的なチーム」が判断することが最もアジャイルとなります。もちろん、外部の有識者の意見などは参考にしますが、あくまで意思決定はチームです。事件は会議室ではなく現場（チーム）で起きています。

チームも自分たちで判断することで、能動的に、モチーベーション高く取り組むことができ、合わせて責任感も持つことになります。

そして、「アーキテクチャ・要求・設計」とスコープが広いと感じます。それぞれを高いレベルでこなすことができるスキルのあるメンバーがチームの中にいることが理想です。そんなプロフェッショナル集団になれたら楽しくてしかたないでしょう。

１２.チームは定期的に振り返り、やり方を自律的にカイゼンし続ける

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

At regular intervals, the team reflects on how to become more effective,

then tunes and adjusts its behavior accordingly.

アジャイル宣言の背後にある原則より引用

チームが成長を続けることで、アジリティも継続的に高めることができます。そのための手段として定期的な振り返り（レトロスペクティブ）が有効です。

ウォーターフォール開発の場合の振り返りに関して下記のようなことが起こるケースがあります。

一方で、アジャイル開発の場の振り返り（レトロスペクティブ）は下記のようになります。

やりたいけど時間の都合等で優先順位が低くなってしまう振り返りを、アジャイルでは強制的にスケジュールに組み込みます。

ここで特に重要なのは「チーム」が主体者であることです。外部のマネージャー等がカイゼンを促すのではなく、チーム自らが気づき、カイゼンすることで成長することができます。振り返りの場には可能な限り「心理的安全性」を保ち、チームメンバーのみとするとよいでしょう。

アジャイル宣言の原則：まとめ

ここまで12個の原則を読んでみていかがでしたでしょうか。最初から全て実行するのは難しいため、徐々に導入していけたらと思います。

また、この原則自体も定期的に振り返りのために目を通すとセルフチェックにもなり、よりアジャイルの本質を理解する気づきとなります。

そして、原理原則という言葉は変えられないもの、というイメージがありますが、あるべき論に捉われず、今その状況でどのような手段が効果的であるかを常に考えて判断していけたらと思います。