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

アジャイルソフトウェア開発宣言の価値観とセットになっているアジャイル宣言の背後にある原則（12個の原則）を読み解きます。こちらはアジャイルを実践する人（ならびにステークホルダー）向けとなる共通の行動指針となります。

アジャイル宣言（アジャイルマニフェスト）については「アジャイルソフトウェア宣言の読み解き方」に詳しく書いています。

アジャイル宣言（アジャイルマニフェスト）１２の原則

この原則は「アジャイルソフトウェア開発宣言」における4つの価値観（マインドセット）に加えて、具体的な行動指針を原則として示しています。様々なケースについて記載されており、実際の行動に移しやすいものとなっています。しかしながら、この12個の原則も正しく解釈するには多かれ少なかれ難しい文章となっています。

ちなみに、書籍「アジャイルサムライ」ではこの原則を指針として多用しながらアジャイルを丁寧に解説されています。

※Amazonでしたらこちらとなります。

アジャイルサムライ−達人開発者への道− | Jonathan Rasmusson, 西村 直人, 角谷 信太

AmazonでJonathan Rasmusson, 西村 直人, 角谷 信太郎, 近藤 修平, 角掛 拓未のアジャイルサムライ−達 ...

 https://amzn.to/3r7FhuA

それでは、一つひとつ丁寧に読み解いていきます。

気をつけたいポイントとしましては、原則は具体的に書かれていることで分かりやすい（イメージしやすい）反面、価値観ほどの普遍性がありません。文面のママを信じるのではなく、その背景（コンテキスト）を読み取った上で現代流、日本流に解釈したいです。

※アジャイル宣言はアメリカ人（白人男性たち）が中心となって書かれているものでため、その文化的な背景が自然と組み込まれています。よって、日本でアジャイルを導入する場合は、日本の文化への考慮が大切になります（ローカライズ）。例えば「〜しなければなりません」といった表現がありますが、「〜を推奨します」ぐらいに捉えてください。

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

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

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

まず、「顧客（customer）」とは誰のことなのでしょうか。それを理解するところから始めます。私は下記のように解釈しています。

※「ソフトウェア」という表現は、プロダクト（製品）やサービスに置き換えていただいても構いません。

システム開発者（受注者）の視点では、ソフトウェアの納品先は顧客（発注者）となり、顧客に対して納品して検収いただかないとお金をもらえないため、顧客満足を最優先にすることは一見すると真っ当に見えます。

しかしながら、顧客満足を最優先にして顧客が望んでいた素晴らしいソフトウェアが開発されたものの、ユーザーに使われないものであったらどうでしょうか。ユーザーに使ってもらうことで価値の提供ができないソフトウェアは無駄です。使ってもらえないソフトウェアには価値がありません。つまり、最優先にすべきなのは「ユーザー満足」なのです。

※「エンドユーザー」という表現もできますが、ここでは単に「ユーザー」とします。

ときおり、顧客の権力者（経営層、等）からの鶴の一声でソフトウェアの方針が変わったり、機能が追加されるケースがあります。しかしながら、それが「ユーザー満足」に繋がらないのであれば、その変更を避けるべきです。組織構造上、部下の立場から抗うことはとても難しいため、権力者（経営層、等）自身が意識を変えなければなりません。誰のためのソフトウェアなのかを考えれば、自ずと答えに辿り着けるはずです。価値あるソフトウェアは私物ではありません。

「customer」を「顧客」ではなく、「ユーザー」と訳す方が良いと考えています。

※顧客組織の中にユーザーがいる場合もあります。

一方で、アジャイルソフトウェア開発宣言における「顧客との協調」の顧客も同様に「customer」ですが、それは「顧客」の訳で正しいと考えています。

「顧客」と「システム開発者」が協調して「ユーザー満足」を最優先にすれば良いのです。

次に、「価値のあるソフトウェアを早く継続的に提供」を考えてみましょう。

価値のないものを提供しても利益を得られないため、「価値があるもの」であることはソフトウェアにおいて必須条件となります。「価値があるもの」の定義は難しいですが、「使ってよかったと思ってもらえるもの」と考えています。

「早く継続的に」というのは、プロジェクト費用の早期回収と顧客ニーズの変化への適応の2つが理由です。早く提供（リリース）すればそれだけ早く利益を得られるため、結果的に費用回収が早くなります。

早くというのは、アイデアの着想（または仮説検証による学び）から実際に価値をユーザーに届けるまでのリードタイムを短くするということです。

例えば、これまでソフトウェア開発で2年をかけてリリースし、そこからようやく利益を得られていたところを、最も価値のあるフィーチャー（機能を価値で表現したもの）にフォーカスして3ヶ月でリリースすることができれば、そこから費用の回収を始めることができます。

そして、一度リリースをしてからも、早いサイクルで継続的にリリースすることが望まれます。

社会、ビジネス、人々を取り巻く環境は日々変化しているため、顧客ニーズも常に変化しています。提供が遅くなればなるほど顧客ニーズとの乖離が大きくなりますし、提供後も顧客ニーズが変化するため、それに適応するために継続的な提供（改修、修正、機能追加・削減したものをリリース）が必要となります。そうすることによってソフトウェアを使って実現しようとするビジネスの成功確率（競争力）が上がっていきます。

また、トヨタ生産方式における「ジャスト・イン・タイム」にも通じると考えています。それは、生産現場の「ムダ・ムラ・ムリ」を徹底的になくし、良いものだけを効率良く造る、という方式、考え方です。

※トヨタ生産方式はこちらです。

クルマの場合は注文を受け付けてから作るというものですが、ソフトウェア開発の場合はユーザーニーズがあると検証されたフィーチャー（ユーザーストーリーと呼ばれるユーザー視点で書かれた文章を用いることが多い）単位に開発し、リリースすることです。在庫、仕掛品、中間成果物は管理コストを生み、価値を生み出さないため、可能な限り少ない方が良いのです。そして、リリースするまで価値を生むか分からないため、在庫が増えれば増えるほど、それに比例してリスクも積み上がっていきます。

２.ユーザー満足（ニーズ）に適応し続ける

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

変化を味方につけることによって、お客様の競争力を引き上げます。

Welcome changing requirements, even late in development.

Agile processes harness change for the customer’s competitive advantage.

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

「要求の変更」とありますが「要求」と「要件」の違いを確認しておきます。似ている言葉であるため混同して使っているケースが見受けられます。

次にウォーターフォール開発における一般的な工程（フェーズ）を記載します。これらが上流から下流に一方通行で流れていきます。※工程の切り方や名称は諸処の流派がありますが、代表的なものを例として記載します。

要求定義→要件定義→基本設計→詳細設計→開発（PG）→テスト（単体・結合・シナリオ・運用）→受入→リリース（サービスイン）

「開発の後期」とはテスト工程や受入工程のことを指します。このタイミングで「要求の変更」が入ってしまうと一番最初の工程（要求定義）まで遡ることになるため、手戻りコストが膨大になります（ひとつ前の工程に変更が入るだけでも手戻りコストはかかります）。コストだけではく、同時期に複数の工程の作業が並行することになるため、プロジェクトが失敗するリスクが高まります。そのため、通常のプロジェクトでは要求や要件の変更は極力避けることになります。

現実的には、一定規模以上のプロジェクトではほぼ必ず要求・要件・仕様の変更が発生します。それぞれの工程内で全てを見通すことはできないためです。変更が発生した場合は、その変更への対応が必須であるかを見極めて、コストとスケジュールを見積もった上で組み込んでいくことになります。発注者は想定外のコストを支払いたくなく、受注者も追加費用をいただけないと苦しくなるため（受注者もビジネスとしてソフトウェア開発をしている）、その「変更」と言われているものが、本当に「要求・要件・仕様」の変更なのか、バグや受注者の過失なのかで揉める場合があります。前の工程で定義した内容の証拠（エビデンス）がなかったり曖昧であったりする場合は、「言った言わない」の論議になってしまい、その調整にも多くの無駄なコストがかかります。

※内製開発の場合は発注者と受注者が同一組織（企業、等）となるため、あまり費用は問題にならないかもしれません。それであっても「手戻り」は特に開発者の労働時間・モチベーション、プロジェクトの成功確率に多大なる悪影響を与えます。

そのような中でも本原則では「要求の変更を歓迎する」と謳われています。

なぜなら、そもそもソフトウェアを開発する目的が「ユーザー満足」であるため、その満足のために実現したいことが変わったのなら、ソフトウェアも変えないと目的を達成することができません。「要求」が変わってもそれを無視して、過去に決めた計画（要求・要件・仕様）通りにソフトウェアを開発すると、結果的にユーザー満足との乖離が大きくなり、最悪は使われないものになってしまい、プロジェクトの全てが無駄になる事態が起こり得ます。

一方で、要求の変更（変化）を柔軟にソフトウェアに対して取り入れることができれば、ユーザー満足に繋がり、結果としてビジネスの競争力を引き上げることに繋がります。

「お客様の競争力」とありますが、なぜか「お客様」という新しい言葉が急にでてきてしまっています。英文では「customer’s 」です。正しくは「顧客の」になると考えています。

ここで問題となるのが、「要求の変更」における「膨大な手戻りコスト」と「ユーザー満足への追従」をいかに解決するかです。

ウォーターフォール開発では「要求定義からリリース」までの期間（リードタイム）が数ヶ月〜数年程度かかることから手戻りコストが膨大になります。

一方、英文では「Agile processes」とあり、「アジャイルのプロセス（複数形）」が主語となっています。なぜ、日本語訳から「アジャイル」の言葉が抜け落ちているのかは不明です。例えば、下記の日本語訳にしてみてはいかがでしょうか。

「アジャイルのプロセスをもってすれば、要求の変更を生かしニーズに適応することができ、結果として顧客の競争力を引き上げます。」

ここでひとつ、疑問が生まれるかもしれません。アジャイルのプロセスって「魔法」なの？と。

よくあるアジャイル開発のプロジェクトでは1〜4週間単位のスプリント（イテレーション）開発を複数回実施し、リリースの準備期間を経て、リリースします。ウォーターフォール開発と比べるとかなり短いリードタイムとすることができます。

1つのスプリントで開発する量をベロシティ（チームが受け入れられる開発量）の範囲内に調整するため、優先順位の高い変更の作業が急に入っても、相対的に優先順位の低い作業が落とされ、持続的なペースを維持することができ、変化が歓迎されるでしょう。

上記のプロセスとなっていれば、リリース前の最終スプリントの開始までであれば受け入れられるでしょう。

ただ、この場合でも開発の後期である「リリースの準備期間」の間に変化が入ってきたらどうでしょうか。きっと、歓迎できません。やることが増えてしまうからです。

開発の後期でも歓迎するためには「完了の拡張（Doneの拡張）」が必要です。

スクラムには「完了の定義（Doneの定義）」というものがあります。

スプリント（イテレーション）内で開発するフィーチャー（機能）について、なにをしたら「完了（Done）」と呼べるかを定義します。そして、リリースまでに必須のことだが、スプリント内にはやらないことを「未完了（Undone）」と定義します。

例えば、下記のような定義をしているチームがあるとします。

スプリト内でDoneを積み上げ、その後にUndoneを片付け、ようやくリリースをすることができます。（スプリント開発後にリリースまでの作業をする期間のことをリリーススプリントと呼ぶことがあります）

この、Undoneの定義のリストをDoneの定義の中に入れていくことを「Doneの拡張」と言います。

全て入れることができれば、毎回のスプリント単位にリリースすることができ、開発の後期という概念がなくなるでしょう。

もっと究極的にはフィーチャー単位にリリースをすることです。ここまで達すれば毎日リリース、そして、1日に複数回のリリースも可能となります。

３. 短い時間間隔でリリースする

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

Deliver working software frequently, from a couple of weeks to a couple of months,

with a preference to the shorter timescale.

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

こちらはすでに最初の文に記載されている「早く継続的に提供」とほぼ同じことを具体的な数値を使って表現しています。

また、「2-3週間から2-3ヶ月」というのは2001年当時の感覚としての短い時間間隔です。通常、ウォーターフォール開発の場合にリリースまでのリードタイムが数ヶ月から数年間に渡ることがざらにあります。それが当たり前の世界から見た場合には2-3週間というのはとても短く感じるのです。

現代はどうでしょうか。クラウドネイティブの時代となり、技術的には毎日リリースすることも十分可能となり、1日の中で複数回リリースをかけることもあります。そして、大事なことは期間を固定したタイムボックスにすることです。それによって、開発チームにリズムが生まれます。

「2-3週間から2-3ヶ月」という数字に囚われるのではなく、可能な限り短い間隔でリリースをかけることで、ユーザー満足の期待に応えていきましょう、ということです。将来的に、AI等の自動化（オートメーション）が発達し、リアルタイムにソフトウェアが変化する時代がくるかもしれません。

一般的には、1週間から4週間単位のイテレーション（スプリント）をタイムボックスとして開発をします。そのイテレーションの中で「要求」を「動くソフトウェア」にします。大抵は複数回のイテレーションを実施したのちにリリースをします。

イテレーション（スプリント）の期間（日数）は固定ですが、リリースまでに必要なイテレーションの数は可変です。リリースのタイミングはビジネスに大きく左右されるからです。

４. プロダクトチームとして顧客と開発者は協働する

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

Business people and developers must work together daily throughout the project.

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

新しく「ビジネス側の人」という言葉がでてきましたが「顧客」と同義と考えています。

こちらの文は宣言の価値観にある「顧客との協調を」について原則として具体的に書いています。

ウォーターフォール開発の場合に工程ごとに役割分担がされる場合が多いです。

上記のように工程ごとに役割が変わるため協調が薄い工程で認識の乖離が大きくなっていきます。

そのため、工程で区切るのではなくプロジェクトの開始から終わりまでずっと協調しなければ結果としてユーザー満足に繋がるソフトウェアを開発することはできない、と謳われているのです。

開発チームだけでなく、顧客も巻き込みプロダクトチームとし、一丸となって協働する必要があるということです。

ただ、顧客とされる人は大抵がとても忙しいため、「日々一緒に」は現実的には難しいでしょう。

大事なのはチームとして共通の目標を持ち、緊密なコミュニケーションが取れ、相互に支援し合う関係になっていることです。

※「together」は「一緒に」より、「協働・協調・協力・力を合わせる」の方が表現としてよく、同じ目的に向かって伴走するという意味合いです。必ずしもいつも同じ場所にいる必要はありません。

５. 意欲あるメンバーに対するサーバント型のリーダーシップ

意欲に満ちた人々を集めてプロジェクトを構成します。

環境と支援を与え仕事が無事終わるまで彼らを信頼します。

Build projects around motivated individuals.

Give them the environment and support they need, and trust them to get the job done.

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

日本語訳を読むとかなり難しいことを要求されているように感じるのではないでしょうか。そもそも、一定規模以上のプロジェクトで全員が意欲に満ちているということは99%あり得ません。

英文からすると「モチベーションが高い人を中心に集めて、プロジェクトの体制を構築する」と解釈できます。つまり、可能な限りそのプロジェクトに対してモチベーションの高い人を集めた方がプロジェクトがうまくいくはず、ということです。この、一見当たり前のように見えることがなかなかできていません。

ソフトウェア開発の現場では人を人として思っていないないような配員（アサインメント）が行われることがあります。

理想的にはプロジェクトメンバーを公募し、手上げで配員ができたらよいですが、既存プロジェクトの状況やメンバーのバランス等もあり、それだけで体制を構築することは難しいです。

せめて、新規アサインメンバーの方と事前に対話し、プロジェクトに対して期待すること、貢献できることについて意識合わせをし、納得した状態で参画を決めたいものです。さらに、その配員プロセスをマネージャー（管理職）クラスだけにせず、既存のプロジェクトメンバー（主にリーダークラス）も関わることができると参画後がスムーズとなり、互いの期待とのギャップも小さくなります。

プロジェクト参画当初の意欲は低くとも、そこから上げる手段はいくらでもあるはずです。

何のために自分がアサインされたかも分からないようではモチベーションを上げようがありません。互いを知り、その人に合わせた期待を寄せることで、自分の存在価値を見出せ、貢献しようと思えるのではないでしょうか。

一方、人のモチベーションのスイッチ（ポイント）は千差万別です。本人に聞いて答えてもらえる場合もあれば、答えてもらえないこともあるでしょう。例えば、プライベートな理由であった場合に答えたくない方が一般的です。この事実を受け入れ、モチベーションを直接的に上げることが難しい場合は「モチベーションを下げる行為、言動、依頼、指示」を極力減らすようにしましょう。

「環境と支援を与え仕事が無事終わるまで彼らを信頼します。」とあります。「彼ら」とはもちろん「開発チーム」のことを指します。

ここで重要なことはユーザー満足に追従して価値を生み出すのは経営者でもマネージャーでもなく、「開発チーム」であるということです。その「開発チーム」が最大限のパフォーマンスを発揮できるように、必要な環境（場）と支援を与えましょうということです。トップダウンより、サーバント型のリーダーシップが求められます。

また、「信頼」という言葉は要注意です。「丸投げ」でも「放置」でも「任せる」でもありません。プロジェクトの全てを委ねるということではなく、開発チームを尊重した上でプロジェクトのマネジメントを行うことが必要です。開発チームを信用せず疑って細かくヒアリングしたり、細かく報告を求めたり、報告のためだけの資料を作らせることなく、見守り（現場、現実、現物を見ます）、適切なタイミングを見計らって手を差し伸べる姿勢、意識が求められます。

私であれば下記のように訳します。

「経営層、マネージャーはプロジェクトを通して開発チームを尊重し、適切な環境と支援の提供を行います。」

本原則では全て「わたしたちは」が主語になっています。全体的に、「わたしたち」は「開発チーム」と解釈できますが、ここの文は明らかに「開発チーム」がすべきことではありません。「開発チーム」の周りにいるステークホルダー（顧客、マネージャー、等）がすべき支援のことを謳っています。

原文の英文自体も怪しいため、いつか書き換えらもらえたら誤解しにくい素敵な文になるかと思います。

アジャイル宣言＝アジャイルマニフェスト

「アジャイルソフトウェア開発宣言」と「アジャイル宣言」と「アジャイルマニフェスト」は全て同じものです。省略形、英語からの表現、となります。

アジャイル宣言（アジャイルマニフェスト）とスクラム

アジャイル開発の現場では「スクラム」を導入しているケースが多くなっています。アジャイルとスクラムの関係はどのようになっているのかを補足します。

「スクラム」はアジャイルフレームワークのひとつです。そして、アジャイル宣言の価値観と一致しています。

つまり、「アジャイル」という大きな括りの中に「スクラム」が含まれています。「スクラム」を理解するためには「アジャイル」を理解する必要があります。

このあたりはスクラムアライアンスの作成したスクラムの原典「Core Scrum」に明記してあります。残念ながら公式ドキュメントとして日本語版がなく、それを日本語訳した記事を書いていますので、そちらに詳しく解説していますのでぜひご覧ください。

Core Scrum (2014) の日本語訳｜スクラムガイドとどちらが原典？アジャイル開発で最も普及している手法

本記事にて5個の原則を見てきましたがいかがでしたでしょうか。次は「アジャイル宣言の背後にある原則の読み解き方（後半）」をぜひご覧ください。