アジャイル開発で闇堕ちしないために

## 楽なアジャイルはおかしい

まず、アジャイルは開発者にとってきついです。確実にウォーターフォールよりきついです。  
開発側はやりがいという意味で充実しているかもだけど、楽であれば、それはアジャイルじゃない可能性が高い。

:::note
顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。要求の変更はたとえ開発の後期であっても歓迎します。
[アジャイル宣言の背後にある原則](https://agilemanifesto.org/iso/ja/principles.html)
:::
ウォーターフォールでいう無茶振りが、アジャイルではようこそ！と変わるのが、アジャイルの本来です。「無茶振られ」ても、なんとかしようとするのがアジャイルです。

:::note
契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を、
[アジャイルソフトウェア開発宣言](https://agilemanifesto.org/iso/ja/manifesto.html)
:::

これはアジャイルのおおもとになっている、「アジャイルマニフェスト」の一部です。「期待値調整」とか、「ブロック」ということをかなぐり捨てている様子が分かるかと思います。「計画に従う」より「変化に対応」ですよ。「契約交渉」より「協調」ですよ。もはやノーガードのフルコミットです。

## でも計画は変更可能なんでしょ？期日とかさ

これは、アジャイルの専門家の間でも意見が分かれると思いますが、私は期日の変更はアジャイル自体で予定されているとは思いません。「アジャイルマニフェスト」に付随する「プリンシパル」の以下の言葉が率直に示していると思います。

:::note
要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
[アジャイル宣言の背後にある原則](https://agilemanifesto.org/iso/ja/principles.html)
:::

「要求の変更」が直ちに「開発納期の変更」を意味するなら、「開発の後期であっても」なんて書き方をするでしょうか。つまり、「変更」はビジネスの成功のために行うものであって、開発チーム内部の都合で行うものではない。ビジネスサイドから来る変更を歓迎するのがアジャイルなんです。開発チームの都合によるネガティブな計画変更は、少なくとも「アジャイルマニフェスト」や「プリンシパル」では触れられていませんし、逆に、ギリギリまで開発チームは変更があれど吸収して期日に反映させないようにすべき、という記述に見えます。

:::note
技術的卓越性と優れた設計に対する 不断の注意が機敏さを高めます。
[アジャイル宣言の背後にある原則](https://agilemanifesto.org/iso/ja/principles.html)
:::

休ませてくれませんね。

そんなのエンジニアにとってきつすぎない？

はい。きついです。その理由はアジャイルマニフェストの冒頭に書かれています。

:::note
私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。
[アジャイルソフトウェア開発宣言](https://agilemanifesto.org/iso/ja/manifesto.html)
:::

これは私の、アジャイルマニフェストが作られた経緯などを読んでの想像ですが、とにかく、非効率がいやだったんだと思います。苦労しても別にいいから、いいもの、喜ばれる物を効率よく作らないと気が済まない、そういう価値観が底流にあるように感じます。だから、安定感や余裕なんてギリギリまでそぎ落とし、まるで効率厨のように研ぎ澄まされた方法、いえ、価値観。それがアジャイルなんだと、私は考えています。

## 改めて アジャイルとはどんなものか

大航海時代に、貴族に出資してもらう船長を想像してください。「ウォーターフォール」なら、出資者に航海のスケジュールと寄港する港をあらかじめ、全日程明らかにして、その通りに進んでいき、貿易する内容も決まっている。一回出港したら、出資者に報告はするけど、仮に目的地の近くに寄り魅力的な貿易品が見つかったとしても、変更することはないし、変更のための準備もしていない。

「アジャイル」の場合も、出資者に航海のスケジュールやルート、日程は提出します。それも決めずに海に繰り出すなんて無謀すぎますからね。そして、定期的に、出資者に連絡して情報を伝えます。また出資者の方も、ただお金を出して終わりではなく、航海がより価値があるものになるよう考え続けます。隣の国で胡椒が人気が出てきているらしい。船長に連絡して、もともと綿を目的にしていたけど、胡椒に変えることはできるか。船長はそれを聞いて船員と知恵を絞ります。創意工夫をして、なんとか出資者の希望に応えようとします。初めと違うじゃないか、なんて言いません。これがアジャイルの「変化」であり、「協調」です。

## 船長達の船出前

### 出航前

#### 「ウォーターフォール」船長
『日数分の食料と水は積み込んだかー？レモンを忘れるなよ！用心のために、えーと、この航路なら2割余裕を見とけ』うん、シンプルですね

#### 「アジャイル」船長
『よし、日数分の食料は積み込んだな。さて、どんな変更がありうるか。隣国で東洋の陶器が人気が出だしているという噂があるな。となると、そちらに向かうことを考えれば、割れ物も運べるように、、いや、もともと綿を求めに行っているから、、うん、緩衝材に綿を使う手もあるか。いや、それだと高くつきすぎる。あとは、胡椒のウワサも聞いたぞ。さてさて、、とにかく、陶器や胡椒、いずれにしても梱包技術が優れたものが必要だな。ああ、あと、陶器は偽物をつかまされちゃかなわんから鑑定士に、、いや、店員オーバーだ。副船長、あいつに出港までの間に鑑定の勉強してもらうか、、、間に合うかな、、、あ、レモンは忘れちゃいけない、、、』いろいろな可能性を考えて、たいへん

## アジャイルってもっと柔軟な感じでは？

広くそう思われていますが、「柔軟」の意味が違います。構造上、「アジャイル」は計画作成を先延ばしにしても"見た目"上進められるので、計画自体を後で考えてもいいようにとらえられ、そのことを「柔軟」と言ってしまっている。でも、これはアジャイルではありません。闇堕ちしてます。

アジャイルの柔軟性とは気が効くお寿司屋さんのようなもので、「顧客の」要望の変更に柔軟という意味です。エンジニアはお寿司屋さん、なんとか要望に応えるようにベストと創意工夫を凝らす。お客さんのいろんな要望に応えて、すごく高いお会計を後で請求なんて、そういうことじゃないって思います。もちろんね、原価がかかる高いマグロやウニを無料で出すことは出来ませんよ。でも、技術によって要望に応えることは出来る。

:::note
技術的卓越性と優れた設計に対する不断の注意
[アジャイル宣言の背後にある原則](https://agilemanifesto.org/iso/ja/principles.html)
:::

技術を身につける努力に対する対価も得たい？たぶん、そこは価値観なんだと思います。アジャイルマニフェストを見る限り、私には、よいものを作ることの喜びが優先されているように見えます。

:::note
要求の変更はたとえ開発の後期であっても歓迎します。
[アジャイル宣言の背後にある原則](https://agilemanifesto.org/iso/ja/principles.html)
:::

「変化」はプロジェクトを顧客のビジネスにより適応させるためのもの、それが原則で、開発が遅れている、見通せないから納期などが変化するってのはアジャイルと関係がないことです。

つまり、アジャイルはゆるふわでないし、厳しく難しいものです。

---

これは私の読み取り方で、実際は世の中、様々な意見があります。ただ、アジャイルマニフェスト（アジャイルソフトウェア開発宣言）を素直に読む限り、私にはこう読めます。また、下記IPAが作成した、「読み解き方」とも大きな齟齬があるとは思いません。なにより、こういったものでなければ、お客様にご提案する意味がないのではないか、とも考えています。

---
参考
- [アジャイルソフトウェア開発宣言](https://agilemanifesto.org/iso/ja/manifesto.html)
  - [アジャイル宣言の背後にある原則](https://agilemanifesto.org/iso/ja/principles.html)
- [IPA アジャイルソフトウェア開発宣言の読みとき方(PDF)](https://www.ipa.go.jp/jinzai/skill-standard/plus-it-ui/itssplus/ps6vr70000001i7c-att/000065601.pdf)