聞いたことはあるけれど、きちんと説明できないかもしれない…という方もいるかもしれません。
今回は、0からでも分かる「アジャイル開発」の解説をしたいと思います。
CLOVERでは、「アジャイルアプローチへの挑戦」と題し、実際のシステム運用プロジェクトの中で、アジャイルアプローチの適用に挑戦したコンサルタントの経験をもとに、アジャイルによる業務アップデートのやり方を紹介しました。
その記事の執筆者であり、実際に社内プロジェクトをアジャイル開発（スクラム）で進めたご経験のある坂口さんや、アジャイル開発に携わったエンジニアメンバーにもご協力いただき、「アジャイル開発」とは何かを解説します。
「アジャイル」とは素早い・機敏なという意味
「アジャイル開発」とは、迅速かつ適応的にソフトウェア開発をおこなう、軽量な開発手法の総称です。
迅速かつ適応的にソフトウェア開発をおこなう、とは具体的にどんな開発でしょうか。「アジャイル（agile）」という単語は、素早い・機敏なという意味です。システム開発においては、小さな単位で計画・実装・テスト・リリースを繰り返すことで、高品質なソフトウェアを早く提供できます。
（引用：LTS社内の勉強会資料より引用）
従来行われてきた多くのシステム開発は「ウォーターフォール型」と呼ばれ、計画・実装・テスト・リリースが横並びの一直線で進みます（図1）。
それに対し「アジャイル型」は、計画・実装・テスト・リリースという流れを小さく、何度も繰り返しおこないます。そうすることで、早い段階から「価値のあるソフトウェア」を作ることを目指します。
どちらのプロセスを選択しても、価値あるソフトウェアを作ることがゴールであることは変わりません。
ポイント①早い段階から価値を提供できる
「早い段階から価値のあるソフトウェア」が出来上がる、とはどういうことか図2を使って説明します。
（引用：https://charleneparks.net/2020/01/18/agile-vs-waterfall/）
これは、車という製品を製造する流れを、ウォーターフォール型とアジャイル型で例えたものです。
ウォーターフォール型では、車のタイヤなどの部品を一つずつ作り、最終的にそれを組み立てて車という製品を完成させます。ここでは、製品が完成するのは一番最後（4）の段階であり、ここでようやく製品としての価値を発揮します。その前段階（1）（2）（3）の、タイヤだけ、部品だけ、では車という製品としての価値を発揮できません。
それに対しアジャイル型では、まず目標を「車という製品を作る」ではなく「徒歩より早い乗り物をつくる」とします。その目標のもと、一貫して開発がおこなわれます。最後に出来上がるものは、ウォーターフォール型と同じ「車」ですが、車が出来上がるよりも前に、スケートボードや自転車など、徒歩よりも早い乗り物ができ、早い段階からその価値（ ＝徒歩より早い乗り物である ）を発揮する製品ができています。
ここで重要なことは、 ウォーターフォール型とアジャイル型、どちらが優れているかは問題ではないということです。
最大の違いは「不確実性」への向き合い方です。ウォーターフォール型でも要求の変更管理など、要求が変化した際にどのように対応するか、ということは検討されていますが、アジャイル型ではそもそも要求は変わるものだ、モノを作りながら要求を探る、といった前提で考えられたモノづくりの思想です。
どちらにも、メリット・デメリットはあります。最終的な目的を達成するためには、どちらのほうが良いのか、しっかりと検討する必要があります。実務上では、様々な判断軸があります。例えば、開発規模やメンバーのスキルセット、選択するソリューション、事業環境、要求の不確実性などをもとに、どちらの手法を選択するか検討します。
ポイント②同じ思想のもと、さまざまな手法がある
「アジャイル開発」とは、迅速かつ適応的にソフトウェア開発をおこなう、軽量な開発手法の総称です。…と紹介しました。この、軽量な開発手法の総称とは、どういうことでしょうか。
（引用：https://speakerdeck.com/kawaguti/kanban-and-scrum）
アジャイル開発の手法には、スクラム、エクストリーム・プログラミング（XP）、などがあります。これらはそれぞれ別ものではなく、ある思想を根底に持つ手法群です。
これらの開発手法の関係者が集まり、共通項を宣言化したものがアジャイルソフトウェア開発宣言（2001）で、これが「根底にある思想」です。
私たちは、ソフトウェア開発の実践
（アジャイルソフトウェア開発宣言 2001）
あるいは実践を手助けする活動を通じて、
よりよい開発方法を見つけ出そうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
みとめながらも、私たちは右記のことがらにより価値をおく。
プロジェクトは不確実で、先が見えないものです。小さく作り小さくリリースすることで、部分的なシステムを作り、そのシステムを実際に動かすことで得られた気付きを反映しながら完成度を高めていきます。お客さまの「欲しいもの」や技術的な「実現方法」の変化に迅速に対応しながら、提供する価値の最大化を目指していきます。
その目的を達成するために、アジャイル開発には様々な手法があります。簡単にご紹介します。
スクラム
スクラムとは、チームが一体となってシステム開発をおこなうフレームワークで、ラグビーのスクラムが語源となっているそうです。
作るシステムに責任を持つ「プロダクトオーナー」と、プロジェクトを円滑に進めることに責任をもつ「スクラムマスター」がチーム全体を支援します。実際にシステム開発をおこなうのは、開発チームです。アジャイル開発の中でも、エンジニアや顧客がチームとなり、プロジェクトを遂行することに重きを置いています。そのため、チーム内でコミュニケーションを取ることが、非常に重要視されています。
エクストリーム・プログラミング（XP）
エクストリーム・プログラミング（XP）は、プログラマー中心の開発手法で、仕様や要求が途中で変更になることや、機能が追加になることを想定されている手法です。
二人一組でプログラミングを実施する「ペアプログラミング」、チーム内で共通のコード記法を定める「コーディング規約」という原則をもとに開発を実施します。
リーンソフトウェア開発
リーンソフトウェア開発は元々アジャイルとは別の流れで発展し、ソフトウェア開発手法としてアジャイルに合流したものと言われ、1980年代の日本でトヨタやホンダが短期間で高品質の製品を生産した手法を、ソフトウェア開発にも取り入れたものとされています。
こちらも、変化に柔軟に対応するアジャイル開発の一つとして注目されています。22の思考ツールと、7つの原則をもとに開発を実施します。
アジャイル開発では3つの要因がキーとなる
アジャイル開発を円滑に進めるためには、以下の３つの要因に対し取り組み・工夫することが大切です。事例も踏まえ、一つずつ見ていきましょう。
アジャイル開発への理解
アジャイル開発は、従来一般的とされていたウォーターフォール型と比べると、考え方や関係者の役割が大きく異なります。そのため、アジャイル開発を正しく理解し、実行することが大切です。
アジャイル開発の考え方を理解しないまま、手法だけを取り入れて失敗してしまう例は多くあります。また、各関係者が自分の役割を理解できず、協力体制が築けないことにもつながります。そのようなことを防ぐためにも、アジャイル開発の考え方・手法を正しく理解しましょう。
例えば、アジャイル開発は「要求は変わるものだ」という思想が前提にあるとご説明しました。
メンバーにはそれぞれ役割がありますが、状況は絶えず変化するため、その時のチームにとってベストな自分の役割やタスクを自主的に考え、自律的に動く必要があります。自分のタスクだけを見て進めるのではなく、チーム全体を俯瞰しながら柔軟に対応します。
このように、アジャイル開発の考え方や手法をメンバー全員で正しく理解することで、円滑なプロジェクト運営につながります。プロジェクト運営の中で、定期的に勉強会の場を設けるのも良いかもしれません。
チームの自己組織化
自己組織化されたチームとは、チームに共有された目標に是認が興味を持ち、お互いに管理し合う能力を身に着けたチームのことです。メンバー一人一人が自発的に行動し、チームが集団として責任を持ちます。
メンバー一人一人が自発的に行動するというのは、それぞれが自分勝手に動くということではありません。特定の人だけが主体的に発言したり行動したり、逆に、全員が全体やほかの人の状況を把握できていなかったりすると、このチームの自己組織化ができていないということになります。
チームの自己組織化には時間がかかり、場合によっては一時的に生産性が下がることもあります。そこを、チームとしてうまく乗り越えることが大切です。
この自己組織化を進めるには、定期的にチームでふりかえりをする場を設けることをおすすめします。
その振り返りの時間の中で、チームメンバーや自分の良かったところ、改善したいところ、気づいたところを共有し合います。そして、メンバー全員で今後どうしていくのが良いのか、改善案を検討し次につなげます。メンバー全員で考えることで、「チームとして動く」ことを意識し、他の人の視点から気づきや学びを得ることができます。
最も大切なことは、前提に「ユーザーに価値を提供すること」という思想があることです。そのためにチームとして必要な改善活動を、継続して実施するサイクルを意識できると理想的ですね。
心理的安全性の確保
これは、チームの全員が自由な発言や行動で、対人関係を損なわないと思えるような、信頼関係を築くことです。先に紹介した、チームの自己組織化の土台ともなります。
自由に発言・行動しづらい雰囲気がある、課題や懸念点がチーム全体に共有されていない、否定的な意見が飛び交う、という場合には、失敗を前向きに取らえる、日ごろからチームメンバーに感謝を伝える、などの工夫が大切です。
定期的にチームメンバー全員が顔を合わせ雑談する場を設けたり、ランチの時間を共にする時間を設けたりするのも良いかもしれません。実際に、アジャイル開発プロジェクトにおいて、業務以外の会話を積極的にすることで、チームの雰囲気が良くなり、コミュニケーションをしやすくなったという例もありました。
LTSのアジャイル開発事例
ここまで、アジャイル開発とは何か？を解説しました。では、実際のアジャイル開発はどのように進められているのでしょうか。経験したメンバーには、どのような気づきや学びがあったのでしょうか。
LTSでは実際にアジャイル開発の手法を活用し、ITサービスや社内システムの構築をする取り組みがおこなわれています。そのプロジェクトメンバーへのインタビューはこちらからどうぞ！
最後までお読みいただき、ありがとうございました。
取材協力
基幹システム導入PJを中心に、IT導入PJにおけるユーザー側タスクの支援に一貫して携わるビジネスアナリスト。構想策定から導入後の運用安定化支援まで、システム導入のライフサイクル全てに関わる。Scrum Alliance認定スクラムマスター（CSM）。（2021年6月時点）
ライター
自動車部品メーカーにて、グローバルで統一された品質管理の仕組みの構築・定着化を支援。産休・育休を経て、CLOVER Lightの立ち上げ、記事の企画・執筆を務める。現在、社内システム開発PJに携わりながら、アジャイル開発スクラムを勉強中。Scrum Alliance認定スクラムマスター（CSM）、アドバンスド認定スクラムマスター（A-CSM）、Outsystems Delivery Specialist保有。（2023年12月時点）
