「アジャイル」とは、すばやく簡単に動くことができ、機敏であることを意味します。
言い方を変えると、方向をすばやく、巧みに変える力を指します。
このアジャイルという考え方は、巨大化して身動きがとりづらくなっている大企業・組織において変化の激しい市場の中で製品やサービスといった価値を出し続けていくために重要な考え方として考えられ始めています。
アジャイルとは、手法やフレームワークではなく、マインドセットであり定期的なフィードバックによって経験、学習し改善を行うようなマインドセットです。これは製品だけでなく業務プロセスや計画の仕方にも適用します。
チームメンバー間での密な連携をとることでアジャイルがよりよく機能します。
アジャイルにおける4つの要素：Heart of Agile
1．協調する：
チームやステークホルダーなどが一緒になって価値を作り上げていきます。
2．提供する：
実用最小限な（incrimental）価値を常に提供し、カスタマーによるフィードバックをもらいます。
3．振り返る：
常にカスタマーやマーケットからのフィードバックを受けたり、自分たちの活動を振り返ります。
4．改善する：
価値（プロダクト・サービス）において、フィードバックや振り返りをもとに「たゆまぬ改善（relentless improvement）」をしていきます。
アジャイルによる恩恵
全体の作業時間を短縮
一つのチームで一貫した業務を担当することで、処理待ちによる遅延や手戻りを最小化します。オーナーシップの向上
業務が細分化されることで提供価値に対する当事者意識が薄れてしまいがち
⇨チームで成果を出すことに責任を持ち意思決定をすることで、メンバーの顧客体験の向上に対する当事者意識が強くなります。プロジェクトでの様々な複雑性への対応
短期間でのフィードバックループにより、常に課題を可視化して軌道修正をかけることが可能です。
ビッグバンでのローンチをする「ウォーターフォール」と
インクリメンタルに価値を積み上げていくアジャイル（スクラム）
以下の図を見てみてください。こちらは、「馬（Houre）の絵」を期限までに書き上げるプロセスにおいて、ウォーターフォールとアジャイル（スクラム）を比較している有名なイラストです。
ウォーターフォールでは、緻密に計画を立てて忠実に進めていこうと考えます。しかしこれだとカスタマーは最後に完成したところでしか見ることができません。
さらに、「計画通りにいくプロジェクトはない」といっても過言ではありません。結果、緻密に計画を立てたものの遅延が発生することで、最終的に何とかして終わらせようとすることから品質が下がってしまうわけです。
ウォーターフォール型の進め方は、「作るものが明確であり量産するようなもの」であれば有効な進め方ですが、依頼した相手も何を求めているかよく分からない、未知なものを作り上げていくには良いやり方とは言えないでしょう。
未知なもの、カスタマーも何を求めているかはっきりしない中で作る際、有効な進め方として考えられるのは、最初から計画や設計を詳細に作らずに、必要なものから作り最小限のものを定期的に提供してフィードバックを得ることで改善していくやり方です。
これが、「スクラム」であり、アジャイルの考え方です。
定期的なフィードバック・振り返りによって成果物の価値（インクリメント）を積み上げ、ブラッシュアップしていくことで、品質を担保しつつ期限までにカスタマーが納得のいくものを提供することができるのです。
このアジャイルというマインドセットをもとに、様々な手法・フレームワークがあります。
後ほど学んでいくスクラム・カンバンもそれらの一つです。
私たちの活動やお客様へのサービスにおいてもこのアジャイルという考え方に基づいています。
アジャイルの由来
2001年にアジャイルソフトウェア開発手法の分野において名声のある17人がアメリカ合衆国のユタ州のスノーバードというスキーリゾートに集まり、それぞれが提唱していた開発手法の重要な部分を統合することについて議論して「アジャイルソフトウェア開発宣言」として文書化したことが始まりです。
2001 年初頭、 17 人が集まりソフトウェア開発の将来について議論しました。グループのメンバーは開発の現状に不満を抱いていましたが、現状の改善方法にも反対していました。
問題は、企業がソフトウェア開発サイクルの「計画」と「文書化」に集中し過ぎているために、顧客を喜ばせるという、本当に重要なことを見失っているのだという点に彼らは同意しました。
企業は「卓越性」や「誠実さ」などの企業価値を宣伝していたかもしれませんが、これらの価値が人々を、特にソフトウェア開発者をより良い方法に導くために役立ったことはほとんどありませんでした。
変えなければならないのはそこでした。
集まった17名の多くは、ソフトウェア開発の新しい時代を先導する方法についてのアイデアをすでに持っていました。
この週末の議論によって、わずか 68 ワードの「アジャイルマニフェスト」が生まれました。
そして、この短くて要領を得たドキュメントがソフトウェア開発を抜本的に変えました。作成されてから20 年あまり、これらの言葉 (それに続く 12 の原則) は、数え切れないほどの個人、チーム、企業によって受け入れられてきました。
アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動
を通じて、よりよい開発方法を見つけ出そうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を
包括的なドキュメントよりも動くソフトウェアを
契約交渉よりも顧客との協調を
計画に従うことよりも変化への対応を
価値とする。すなわち、左記のことがらに価値があることを認めながらも、
私たちは右記のことがらにより価値をおく。
アジャイルマニフェストの背後にある12の原則
顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
動くソフトウェアこそが進捗の最も重要な尺度です。
アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
アジャイルは「マインドセット」
「アジャイル開発」といわれ、開発チームが取り組む手法と考えられがちです。
しかし、そんなことはありません。
カスタマーに対して価値を提供しているのであればどんなチームにおいても必要な考え方です。
Presenter: Takahiro Minagawa (Solution Engineer at Atlassian)
INNOOV株式会社×アトラシアン株式会社共催ウェビナー（2020/10/16）より
Youtube - 12mins
Youtube - 6mins
なぜアジャイルなのか？
ビジネスでは、多大な時間やお金を「働き方を変えること（トランスフォーメーション）」に投資しています。今までは多大な時間をかけて製品を開発することができましたが、ますます加速していく時代の中、顧客が手に取る製品は著しく移り変わり、ニーズに追いついていかなくてはなりません。
多くの企業で「顧客が必要としているときに製品を提供できない」「問題の発見が遅すぎる」なんてことが常態化しています。その結果、顧客の満足度は下がってしまうでしょう。
私たちは「顧客中心」的な考えを持って、継続的に「適応」していかなくてはならないわけです。
顧客に対して価値を提供するいかなるチーム・組織において「アジャイル」が必要なのです。
まとめ
アジャイルは、プロダクトマネージメントに対する「経験的アプローチ」ともいえるでしょう。
定期的なフィードバックによって経験・学習し、判断をする（継続的な改善）
⇨これは「製品」だけでなく、計画の仕方やプロセス（活動）自体も継続的に改善を行います。部門横断チームとして活動します。（クロスファンクショナル・チーム）
⇨アジャイルでは、様々な専門性を持つ人が一つの場所で協働することで、一連の業務プロセスをチームで遂行します。アジャイルはコラボレーション・信頼
⇨チームメンバー間でのオープンなコミュニケーション、コラボレーション、適応、そして信頼がアジャイルを支える柱です。手法やフレームワークではなく、「マインドセット」：思考様式・価値観