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

アジャイルソフトウェア開発の本質

アジャイルソフトウエア開発の種々な手法が紹介されて、すでに20年を経ようとしています。この間種々なシステム構築プロジェクトでこの手法が採用され、また種々なプロジェクト環境やシステム要件に柔軟に対応して来ました。これは素晴らしい事でもありますが、最近少しばかり気になっていることがあります。それは、

• アジャイルなソフトウエア開発の本質とは何か？

• また自分たちはこの基本的な考え方を実現できているのか？

• 適応することは素晴らしいが、本来の目的、考え方から逸脱した新たな自己流を生み出して、さもこれがアジャイルの真髄と言うような驕りに至っていないか？

20年間の経験を振り返って見たいと思います。これからアジャイソフトウエアル開発にチャレンジする若人エンジニアにアジャイルソフトウエア開発の真の意義（思想）を学ぶ機会になれば良いと思います。

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

2001年2月（旅米国ユタ州スノーバード）制定

私たちは、ソフトウエア開発の実践あるいは実践を手助けする活動を通じて、より良い開発方法を見つけ出そうとしている。

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

プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウエアを、契約交渉よりも顧客との協調を、計画に従う事よりも変化への対応を、価値とする。

すなわち左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値を置く。

http://agilemanifesto.org/

Kent Beck、　Mike Beedle、　Arie van Bennekum、　Alistair Cockburn、　Ward　Cunningham、 Martin Fowler、James Grenning、Jim Highamith、Andrew Hunt、Rin Jeffries、Lon Ker、Brian Marick、Robert C.Martin、Steve Mellor、Ken Schwaber、Jeff Sutherland、Dave Thomas

前掲のアジャイルソフトウエア開発宣言は、あまりにも有名で度ある毎に目にされた事が有ると思います。そしてこの宣言文の後ろには、『アジャイルソフトウエア開発の原則』と言う12の原則が付加されており、宣言文ではこの12の原則も含めてコピーフリーで誰でも引用できると書かれています。そして、宣言文はコピーフリーで引用可能ですが、引用するには必ず『アジャイルソフトウエア開発の原則』を一緒に掲載することが、フリーに引用する条件になっていると言えます。

実はこの12の『アジャイルソフトウエア開発の原則』こそがアジャイルを志向するエンジニア、管理者や関係者にとって強く意識しなければならない重要な教えです。

アジャイルを志向する全ての人は、この12の原則に照らし合わせて、自らの行動や考え方を軌道修正する必要があります。またこの原則を実践する事がアジャイルソフトウエア開発だと言えます。自身の行動が型崩れを起こしていないか？本当にアジャイルなソフトウエア開発を志向できているか？を振り返るための羅針盤としてください。

12のアジャイルソフトウエア開発の原則とは、

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

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

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

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

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

6. 情報を伝える最も効率的で効果的な方法は、フェイス・ツー・フェイスで話をすることです。

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

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

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

10. シンプルさが本質です。

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

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

では一つずつ解説を加えていきましょう。

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

この文でのキーワードは、『顧客満足を最優先』と『早く継続的に提供』と言う言葉です。何を意味していますか？まず最初の『顧客満足を最優先』にするという事は、どういう事でしょうか？皆さんがソフトウエア（システム）の設計をしている時に社内のQA部門とか、社内管理基準から当然のごとく仕様を追加している事はありませんか？それって本当に顧客に満足して貰える仕様ですか？単に自己満足、自己保身で追加していませんか？特に非機能要件は、要チェックです。

次にソフトウエアを『早く継続的に提供』と言う意味を考えましょう。『早く』は文字の通り素早くと言う意味で、誤解は無いと思いますが、重要なのは『継続的に提供』です。従来からの発想から見れば、ソフトウエア開発プロジェクトは終わりがないエンドレスのプロジェクトになるとイメージしていませんか？実はこの言葉の裏側に大きなパラダイムシフトが含まれているという事に気が付いたでしょうか？今まではソフトウエア開発とはシステムを作るという目的志向でした。ですから企画されたシステムが完成するという節目が存在し、それまでプロジェクトを組織して完成させるという考え方です。あくまでもシステムを作ると言う視点で見ていますから完了（完成）というゴールがはっきりとします。

一方アジャイルソフトウエア開発はシステムを作ると言う視点を持っておりません。あくまでもビジネスに必要なITサービスを実装して安定して提供し続け、ビジネス遂行を支援するという視点で見ています。ですから『継続的に提供』と言う表現が使われているのです。そうです、ソフトウエア開発とはシステムを作るという目的からビジネスを支援するITサービスを提供すると言うパラダイムシフトが起こらなければなりません。

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

ここで大事な事は、『ビジネスを支援するために変更要求が出されてもいつでも対応できる能力』を保持しているという意味です。具体的には、

• 常に『持続可能なペース』でのソフトウエア開発ができる事、

• 変更要求に対処できる開発能力キャパシティーが管理されている事、

• 更にタスク粒度が細かく（小さく）分解されて均一化している事、

が前提条件になります。TPS（トヨタ生産方式）的に表現すれば、平準化（タスク粒度と作業負荷）とプル型の後工程引き取りの仕事の流れが確立されていることにほかなりません。

３．『動くソフトウエアを、2～3週間から2～3ケ月というできるだけ短い時間間隔でリリースします。』

この言葉から連想される技術は何でしょうか？そうですね、それはソフトウエア（システム）のアーキテクチャ設計で、マイクロサービス・アーキテクチャを採用するという事になります。また従来のWFでの開発の様に、ただコードを書けば良い。後でテストをするからと言った開発姿勢では、対応できません。確実にコードを書いたならば即リリースできるレベルまで品質を作り込む事が求められます。

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

この言葉も実行するのは大変難しいです。皆さんも幾度となく苦い経験をお持ちではないでしょうか？ビジネスユーザー（お客様）に協力をお願いして、「はい判りました協力します。」と返事していただけるケースは本当に稀なケースです。ほとんどが非協力的では無いでしょうか。ではどうやってユーザーの協力姿勢を引き出しますか？

開発チームの皆さんからアプローチをしなければユーザーは応えてくれません。開発チームの姿勢が重要です。開発チームがユーザーにとって大変有益有用な仕事の仕方をして信頼に値するという感覚を持てば、ユーザーは積極的に皆さんのプロジェクトに参加して来ます。どうやってこの信頼を得たら良いでしょうか。一番大事な要素は常日頃の皆さんの行動です。徹底的に開発チームの状態や仕事の進捗、技術的課題などを『見える化』してください。これだけで信頼を得られます。要は開発チームの皆さんの姿勢いかんだという事です。

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

この言葉は特に管理者の皆さんへの言葉です。アジャイルソフトウエア開発ではプロジェクトの期間中は誰も開発チームに対して指示命令を出すことができません。管理者の皆さん、権限委譲をして、プロジェクトが完結するまで何も指示せず、アドバイスもしないで黙って見て居られますか？

ではどうやってこのような信頼できる開発チームを育成しますか？この様な自律した開発チームを育成することが管理者の最大の仕事です。スクラムマスターと協力してチームビルディングを支援してください。

６．『情報を伝える最も効率的で効果的な方法はフェイス・ツー・フェイスで話をすることです。』

これはコミュニケーションの基本です。コロナ禍以降リモートワーク流行りでアジャイル開発チームもリモート環境という事が多くなりました。ではどうやって実際にフェイス・ツー・フェイスでプロジェクトルームに集合して開発作業していた時と同じレベル（コミュニケーション、品質、作業進捗など）でプロジェクトを推進できるか？チームで考えて改善していますか？単にリモートワークのツール（Zoom, Team, Trello, miroなど）を導入すれば良いと言ったレベルの話ではありません。チーム自身による改善活動が必須です。このような改善活動が振り返りの中で実行されていますか？

７．『動くソフトウエアこそが進捗の最も重要な尺度です。』

ここでは『動くソフトウエア』がキーワードですね。でもただテストを通ったとか機能が使えると言ったレベルでは無いことを皆さんもお気づきではないでしょうか。そうです、『ユーザーの要望通りに働くソフトウエア』と言う意味です。そこまで品質や完成度を高める開発作業を考えてみてください。スプリントレビューが終わったら、即リリースできるレベルでスプリントレビューをしていますか？プロダクトオーナー、開発チームは、共にレビューの質の向上を振り返ってください。

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

『持続可能な開発』がキーワードです。この言葉が再び登場しますが、原則の２番目の変化へ対応するための方策ばかりではありません。思い出してください。アジャイル開発で作るプロダクト目標は、ソフトウエアでもシステムでも無いことです。ITサービスを実装して通常のビジネスプロセスの中で、ユーザーを支援し続ける事が目標です。従ってユーザーのビジネスオペレーションと同期が取れ、ビジネスの拡大（拡張）と合わせてITサービスを進化（深化）させていくために持続可能な開発（ペース）が求められているのです。

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

機敏性を高めるためには、次の１０番目の原則と同様に、常にシンプルな技術を活用し、シンプルな設計を心掛ける必要があります。『Gallの法則』で言われている事そのものです。シンプルな設計をするためには、技術的に優れていなければできません。開発チームの皆さんは常に自身の技術レベルの向上に努めなければなりません。そしてチームの技術レベルを一層向上させる為に振り返りで、技術レベルの話題も上げてください。

更に開発チームの皆さん自ら自分たちの知識レベル、スキルレベルと言った技術能力を『見える化』して、チーム自身で管理できるようになってください。能力開発も開発チームが自ら実施するものです。自律したチームとは、このようなチームです。

10．『シンプルさが本質です。』

正にGallの法則そのものです。アジャイル開発に関わる全ての活動を出来るだけシンプルにする様にしてください。シンプルに出来ればできるほど、機敏性は向上します。

Galls Law（ゴールの法則）

彼の音書1977年ニューヨークタイムス出版から刊行した『Systematics: Haw Systems Work and Especially How They Fail by Quadrangle.』(体系学：どの様にシステムは作用するか？そして特にどの様にそれらは四方から囲まれて失敗に終わるのか？」より抜粋

"A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system."

~ John Gall

複雑なシステム、それは例外なくしっかりと動くシンプル（単純）なシステムから発展（進化）している事が解る。最初から複雑なシステムを設計すると決して上手く動かないし、動くようにまとめ上げる事が出来ない。確実に動くシンプル（単純）なシステムから始めなさい。【ジョン・ゴール】

JennGall（ション・ゴール 1925年9月18日まれ、2014年12月15日法、アメリカの作家、元小児科医

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

人（役職）によっては、この文面の意味は少し刺激的ですね。自律した開発チームが全てと言った意味です。お判りですね。どんなに優れた要求仕様をまとめようが、どんなに優れた設計ができても、どの様にソフトウエアとして機能してITサービスが利用できるかは、実装されたプログラムによって決まります。ですからプログラムを書く開発チームが全てなのです。優れた設計をしても開発チームがその設計を実装できなければ、ただの絵にかいた餅です。このようなシステム開発プロジェクトが多くありませんか？そして設計者、開発者双方が相手の非を問う。無意味な事ですね。ですから開発チームが全てなので、最初から開発チームにすべてを委ねる様にしようという考え方です。

ここでちょっと考えてみてください。それでは要求仕様や設計はいつ誰がやるのが適切なのか？勿論開発チームです。そしてスプリントプランニングの時です。ですからここで大事な事はプロダクトバックログの表現についてよくよく考えてみてください。開発チームの能力を最大限発揮できるプロダクトバックログの表現とはどんな形でしょうか？このプロダクトバックログの表現如何で、プログラム（システム）の良し悪しが決まってしまうと言っても過言ではありません。

プロダクトバックログでよくIT用語（例えば、DBとかクラウド、コンテナ）を使って表現されているのを見かけますが、このような表現を使うと開発チームに『この技術を使え。』と言った指定をしてしまいます。必ずしも、ITサービスを実装するうえで、その技術が適切であるかどうかは、環境等も踏まえて開発チームが実装し易い、メンテし易い技術で実装して貰う方が得策です。ですからできる限りビジネス用語（IT用語を排除して）で目的、目標（ゴール）が明確に理解できる程度で、技術的な要素については少し曖昧さを残して、開発チームに選択権を与える表現が優れたプロダクトバックログの書き方です。

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

『振り返り』の重要性を説いていますが、よく見かける振り返りは単にプロジェクト、特にシステム構築面での振り返りが中心です。これは全く誤ったやり方です。ここで言われている振り返りは、プロジェクトのみならずスクラムチームの職場環境やメンタリティーなど人（関係者全員）の営みすべてを振り返るという意味です。そうでなければアジャイルソフトウエア開発が目指す機敏性や変化への対応（即応）、ビジネススピードの向上など実現できません。TPS（トヨタ生産方式）と全く同じ考え方です。アジャイルソフトウエア開発とは常に改善活動のPDCAを廻しながらソフトウエアを開発してITサービスをビジネスユーザーにジャストインタイムで提供し続ける手法です。

如何でしょうか？アジャイルソフトウエア開発の本質（真髄）をご理解頂けましたでしょうか。皆様の実践と成功を期待します。

令和４年５月１日

戸田孝一郎