こんにちは！ABEJA でスクラムマスターをしている小川です！
最近、新規加入メンバーやステークホルダー向けにアジャイルとは？について説明/解説をする機会が増えたので、そこでよく話している内容をまとめてみました。
アジャイルについてギュッと短くまとめてみましたので、「知らないよ」という人には学びのきっかけに、「もう知ってるよ」という方にもチームや組織への説明材料の一つとしてお役に立てれば幸いです！
目次 世の中のつよつよプロダクトに目を向けてみます。
突然ですが...
このような世界トップシェアを誇るようなプロダクトでは、「価値探索」、「チームを跨いだ協力」、「継続的な改善」、「ユーザー志向」、「短期間の開発サイクル」などのいわゆるアジャイルな組織やプロセスを実践しています。プロダクトをよりよくするためにアジャイルを実践しているようですね。
ウォーターフォール型の開発プロセスをおさらい
アジャイルの比較対象として、ウォーターフォール型の開発プロセスが挙がることが多いので、ここでもウォーターフォール型の開発プロセスをおさらいしてみます。*4
ウォーターフォール型の開発プロセスでは、最初にコンセプチュアルな企画/検討を行い、プロジェクトが実現する価値の大枠を定義します。そして、プロジェクト計画（クオリティ/コスト/スケジュール/スコープ）を決めて、工程単位に成果物をレビュー/承認していきます。基本的には前工程（より上位の工程）で決めた通りに後工程は実行されます。
多くのプロジェクトは、要件などの変更が後から湧いて出てきます。ですが、ウォーターフォール開発では、変更はプロジェクトの計画に影響を与える（色々とコストもかかる）ので基本的には避けたいです。
例えば、開発の依頼元（お客さんやプロダクト企画担当）から要件変更依頼があれば、その変更に対する追加見積もりやスケジュールの遅延などを提示して、変更影響を理解してもらった上で、プロジェクトチームで変更に対応するための再設計などを実施する必要があります。*5
場合によっては「変更するとこんな悪いことがあるんだよ」と伝えて、依頼元に変更を踏みとどまらせる（変更をしない・避ける）ケースもあります。
少々極論&暴論かもしれないですが、ウォーターフォール型のプロジェクトの成功とは、「上流工程で決めたとおりのものを作って、プロジェクト計画通りにプロジェクトを終わらせること」だとも言えるのかもしれません。*6
アジャイルとは？
正解がわからない、誰も確たる正解を持っていない目標への到達や問題の解消に立ち向かうとき、要件定義、仕様策定、スケジュール策定、コスト見積もりを高い確度で行うことは難しいです。*7
じゃあどうするか？
小さく試してみて感触/学びを得るのが良さそうじゃないでしょうか？ それこそ遠い未来を予測して計画したところで、どうせ後で変更があるから精緻にやっても仕方ないのです。遠い未来の計画はだいたいでいいのです。
やってみて、反応を集めて、だいたいの計画（目標到達への道すじ）に修正を加えることを短期間/高頻度に繰り返すのが無駄がなく手っ取り早そうです！
仮に失敗があったとしてもコストをかけてなければダメージも小さいしリカバリーも簡単そうです！（もっといえば失敗さえも学びになります）
というのが非常にざっくりとしたアジャイルの考え方です。
アジャイルの思想と手法
実はアジャイルと言っても、「ウォーターフォール開発」のような具体的なプロセスを指し示しているわけではなく、価値観や行動指針に「アジャイル」という名前をつけただけなのです。
もしアジャイルを「プロセス、方法論、フレームワーク」などのような理解で導入してしまうと、活用の道は険しく、「なんかイマイチだなあ...」という印象を抱くことになるでしょう...*8
そんなアジャイルの価値観や行動指針を明文化しているものが「アジャイルソフトウェア開発宣言」です。
アジャイルを実践するための具体的な手法にはスクラムやエクストリームプログラミング（XP）、クリスタルなどがありますが、いずれも上記のアジャイルソフトウェア開発宣言に書かれている価値観や行動指針を実際に実現するための（先人たちの経験と改善によって培われてきた）方法論やフレームワークという位置付けになっています。*9
アジャイルの実践とその先にあるもの
注意したいのは、手法や仕組み/プロセスを、ただ闇雲に実践してもアジャイルな組織になるわけではないということです。
例えば、スクラムでは「理解は容易だが習得は困難」とよく言われています。
実際に、スクラムガイドが示すイベントや各種アクティビティを実行すること自体はそれほど難しいことではありません。*10
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
前述の通り、不確実性に立ち向かう状況では、誰も確たる正解を持っていないので、特定の誰かの指示や計画だけを頼りにすることは筋が悪そうです。
なので、価値の探索/実現/検証のサイクルの実行といった手法だけではなく、さまざまなスキルセットや視点を集結させて、成功も失敗も学びとして素早く柔軟に自分たちの活動に反映させる、そんなアジャイルの思想や行動指針の実行がされている「Be アジャイル」な状態である必要があります。
例えばスクラムを採用するとしても、その各種イベントやアクティビティの形だけ実践しても、マインドセットや行動指針のレベルでアジャイルを導入できていないと「Be アジャイル」な状態にはなり得ません。*11
アジャイルの思想や行動指針のレベルまでチームに浸透させるには、スクラムの価値基準などで表現されるようなマインドセットなどを理解/実践できるメンバーが集まり、チーム/組織の文化作りまでなされている必要があります。（スクラムマスターの働きかけが重要です！）
このような考えをベースにすると、アジャイルをただの開発フレームワーク（役割や各種イベント、プラクティスの集合体）として捉えてしまうと、期待はずれと感じたり、うまくいかないであろうことは想像に難くありません。
大事なことです、「Do スクラム」でも「Do XP」でもなく、「Be アジャイル」であるからこそ不確実性に向き合えるのです。
Be アジャイルな活動
アジャイルの目指すものは、変化に対応できる柔軟性です。むしろ変化を歓迎できるレベルにまでチームの成熟度を上げていくことが大切です。
価値の仮説検証をして、実際に動くものを作り、効果測定して、見直しを行う、という一連のサイクルを高頻度かつ継続的に行うことで、予測困難な目標を実現させようということです。
なので、アジャイルの開発プロセスでは、短いイテレーション（スプリント）を通じて、優先順位の高い機能を素早く開発し、漸進的にユーザーや依頼元のフィードバックを取り入れること（フィードバックサイクル）が重要です。
また、市場やユーザーのフィードバックは、今この瞬間だから得られるものもあるはずです。 例えば、最近だとLLM（大規模言語モデル（LLM：Large language Models））に関連した新機能は、市場やユーザーからさまざまな反応が得られそうです。半年後はもう遅いかもしれません。 なので、ジャストインタイムに価値を提供するというのもアジャイルな活動で大切な要素です。
さらに、良質なフィードバックを得るためには、設計やドキュメントによる説明よりも、実際の成果物をユーザーに触ってもらうことが重要です。 なので、アジャイルでは動く成果物をリリースすることを重視します。
そして、変化に対応できるということは、都度さまざまな視点や意見を取り入れることができるということです。それによってまた仮説の軌道修正の機会が増えます。 なので、アジャイルでは顧客や利害関係者との密な協力（同じ目標を見据えたコラボレーション）が重視されます。
もう一つ重要な要素として、チームは自己管理型（自己組織化）である必要もあります
「特定の誰かがいないと開発できない、意志決定ができない」という状態では、フィードバックサイクルを活かしたジャストインタイムなリリースを安定的に継続させることができません。機能横断（クロスファンクショナル、属人化防止）的に価値実現の活動を行うこと、フラットな関係（上下関係による指示命令系統がない）でチームを作ること、また、チーム活動の目的や状況は常に透明性が担保されていて展開に応じた行動と判断が自律的に行える、そんな自己管理型なチームを目指す必要があります。
そうしていくうちに、ウォーターフォール型の開発ではなるべく避けたかった「変更」は、アジャイルでは歓迎すべきものになるハズです。 「あちゃ〜、それは気づいていなかった…」が「やったね！いい学びを得られた！」になるハズです！
結びのようなもの
アジャイルを実践するための心構え
- やってみてからわかることが多いことを念頭におき、初期計画に正しさと緻密さを求めすぎない
- フィードバックサイクルを活用して、継続的な小さな改善を行うことを前提にして、最初から価値の完成形を決めすぎない
- より良い価値実現に向けてさまざまな視点やスキルセットで対話と協力を行うために、役割や組織の責任分解点のような必要以上の線引きをしない
- 誰も正解を持っていないことを認めて、現場の自律的な判断と行動によって変化への柔軟性と速度を上げる（上位者による指示駆動を是としない！）
こんなチーム/組織におすすめ
- 不確実性の高い領域で成果を出したい
- チームとしての長期的な継続性を向上させたい場合にもおすすめ！
無理に採用しない方が良さそうなケース
アジャイルなチーム/組織づくりは難しく時間もかかります。以下のようなケースでアジャイルを無理に採用するメリットはないかもしれません。（アジャイルが足枷になる可能性すらあります）
- 正解のある開発をおこなっている（具体的かつ詳細に実現することが明確に決まっている）
- 1ヶ月など、短い期間で解散するプロジェクト
- 上位下達型の指示命令系統を維持したいとき*12
おまけのようなもの
スクラムマスターやアジャイルコーチの要否
- 必要です！
- ここに書いたような、アジャイルの価値観や行動指針に加えてノウハウや経験も有していて、チーム活動を支援できて、チームとメンバーの成長を助ける役割を担える人である必要があります。
- また、マインドセットの醸成や文化形成と言ったエモい部分に構築していくことになるので、もしスクラムマスターがいないと形だけはアジャイル/スクラムっぽいけど違う何かになるでしょう。（大概この「それっぽい何か」は非効率的な開発スタイルとして実践されてしまい、「アジャイルってダメだな」という残念な結論で終了します。）
- チームの成熟度を上げて「Beアジャイル」な状態にしていきます。そして、最後はスクラムマスター/アジャイルコーチは自分自身をクビにします。（そういう状態になるくらいチームとメンバーの成長を促すのです！）
We Are Hiring!
ABEJAは、テクノロジーの社会実装に取り組んでいます。 技術をどのようにして社会やビジネスに組み込んでいくかを考えるのが好きな方はもちろん、アジャイルの開発体制の中で幅広い技術を活用・習得したい方も、下記採用ページからエントリーください！ （新卒の方のエントリーもお待ちしております）
*1:https://investor.fb.com/investor-events/default.aspx
*2:https://spotifynewsroom.jp/2023-10-26/spotify-2023年度第3四半期決算を発表/
*3:https://www.paypal.com/jp/business
*4:実は私は元々、ウォーターフォール型プロダクト開発のプロジェクトマネージャーをしていました。この記事の中でのウォーターフォールの説明は、私の経験上の話も取り入れています。
*5:中にはスケジュールはずらさずに変更を受け入れるというデスマーチな開発もあったりしますね💦
*6:とはいえ、変更や課題が発生しないプロジェクトなんてないと思います。なので、顧客との信頼関係を構築しながら、後から出てくる変更や課題を対応・解決してプロジェクトをドライブしていくのもプロジェクトマネージャーの腕の見せ所ではあるとは思っています！ウォーターフォールのプロジェクトマネージャーは圧倒的リスペクトです！
*7:まれに全てを見通していたかのように、非常に精度が高い計画を立てられる人もいますが、例外中の例外なので、そういう人が計画をするという前提ではプロジェクトを開始しないほうが良さそうですね...
*8:アジャイル導入失敗談は世の中にたくさんあります
*9:実際にはスクラムやXP といった軽量ソフトウェア開発（アジャイルの昔の呼び名）が先にあり、2001 年にその提唱者たちが集まって上記のアジャイルソフトウェア開発宣言を作成したとのことです。
*10:このスクラムガイドに至っては本編１０ページにも満たない程度のボリュームです！
*11:それでもスクラムは優秀で、まずはそのまま試してみるだけでもアジャイルに近づくことができるはずです！「時間がもったい無いからレトロスペクティブはやめました！」とかやり始めると終わりの始まりです。
*12:一概に上位者の指示が悪だということもないハズです。作業に危険が伴うリスクがあり、そのリスクは経験豊富な上位者の指示によって避けられるといったケースもありえます。
