![SELECK [セレック]](https://seleck.cc/wp-content/themes/SELECK-v1/images/seleck-header-logo-white.png){kind=logo}
【事例7選】「アジャイル」とは？ 開発やHRなど多くの分野で注目される理由を徹底解説！
2000年代以降、日本では主にソフトウェア開発において「アジャイル」という言葉が浸透してきており、近年では開発の現場以外でも耳にする機会が増えてきました。
SELECKでも2015年のメディアリリース当時から、各社のアジャイルにまつわる事例を扱ってきましたが、Googleトレンドで「アジャイル」の検索推移を見てみると、ほぼ横ばいや微増だったところから、2022年に入って検索が増えている傾向が見て取れます。
おそらく、「アジャイル」の定義から調べている方や、今まさに導入を検討していて、企業の具体的な事例を知りたいという方などが増えているのだと推測されます。
▼Googleトレンドでの5ヵ年の検索回数推移（2017年7月〜2022年7月現在）
実は、海外と比較して日本のアジャイル開発の導入は遅れていると言われています。
実際に、2021年7月に発表されたState of Agile Report（出典：Digital.ai）では、下記の通り海外市場のアジャイル開発の導入は90％近くに達していると記されています。
This year’s findings indicate significant growth in Agile adoption within software development teams, increasing from 37% in 2020 to 86% in 2021.
（訳：今年の調査結果では、ソフトウェア開発チームにおけるアジャイル導入が大幅に増加し、2020年の37%から2021年には86%に増加することが示されました。）
一方で、ガートナー ジャパンが2019年に発表した調査結果では、日本国内のアジャイル開発の導入率は2,000人以上の企業で40%弱に留まっており、その後2021年にアジャイルPM研究会から発表された「アジャイルプロジェクトの実態」 に関するアンケートでも導入率に大きな変化はなく、海外の水準とは大きな差がある現状です。
▼アジャイル型開発手法に関する方針×従業員数規模（出典：ガートナー ジャパン）
そこで今回は、これからアジャイル開発の導入を検討されている方や、開発以外でもアジャイルの考え方を取り入れたいという方に向けて、「アジャイルとは」といった基礎知識から厳選7社のアジャイル事例までをご紹介します。ぜひご参考ください。
＜目次＞
- アジャイル（開発）とは？
- アジャイル開発の起源
- アジャイル開発の流れと、主な手法について
- 4つの開発手法と、ウォーターフォール開発・アジャイル開発の違い
- アジャイル開発のメリット
- アジャイル開発に移行する際に重視すべきポイント
- 【事例7選】アジャイル開発や、他分野のアジャイル化に取り組む企業
アジャイル（開発）とは？
「アジャイル」とは、「機敏な」「素早い」といった意味で、主にソフトウェア開発の手法や考え方において「アジャイル開発（アジャイルソフトウェア開発）」という表現が用いられています。（出典：Weblio辞書）
また、ある書籍では、アジャイルを次のように定義しています。
「環境に適応して、最も効率よく不確実性を減少させられている状態」
書籍：エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリングより
アジャイル開発とは、機敏・迅速・柔軟なソフトウェア開発の手法の「総称」を指しており、特定のひとつの手法を指すわけではありません。
共通点としては、「実装した機能をいち早くリリースし、細かく反復して改良する」といった特徴が見られます。
最近では、ソフトウェア開発に限らず、「アジャイル経営」や「アジャイルHR」、「アジャイルな働き方」といったように、様々な分野にもアジャイルの考え方が広がりつつあります。
アジャイル開発の起源
アジャイル開発における開発手法のひとつである、「スクラム」が登場したのが1986年。
当時、日本とアメリカの組織における「新製品開発のプロセス」を比較・分析した研究論文の中で、日本発の開発手法の柔軟さや自由度の高さをラグビーのスクラムに例えて表現したのがはじまりと言われています。
その後、従来とは異なる手法を実践していた17名の世界的に著名な開発者が、それぞれの手法やマインドセットについて議論した内容をまとめ、2001年に「アジャイルソフトウェア開発宣言」として発表しました。
そこには、
「成果物を数週間から数ヶ月という短期で、頻度高くリリースし続ける」
（原文：Deliver working software frequently, from a couple of weeks to a couple of months, with a preference tothe shorter timescale.）
といった、アジャイル開発における12の原則が示されています。
※詳細を知りたい方は、参考としてIPAが公開した「アジャイルソフトウェア開発宣言の読みとき方」をご覧くださいませ。
アジャイル開発の流れと、主な手法について
アジャイル開発の流れは、おおよその仕様と要求を決める「リリース計画」と、要件定義→設計→実装→テスト→リリースを短期サイクルで繰り返す「イテレーション（Iteration / 反復・繰り返し）」の順となります。
アジャイル（機敏な・素早い）の名の通り、開発プロジェクトの途中で仕様や設計の変更があっても素早く対応できるように、リリース計画の段階では厳密な仕様を決めないことが特徴です。
また、アジャイル開発には様々な開発手法（フレームワーク）があるため、ここでは代表的な下記3つをご紹介します。
- スクラム
- エクストリーム・プログラミング（XP）
- ユーザー機能駆動開発（FDD）
▼全体像：アジャイル開発の中に、様々な開発手法がある形（編集部作成）
チームで密にコミュニケーションを取りながら開発する「スクラム」
アジャイル開発の中で、最も有名な開発手法がこのスクラムです。
まず、「プロダクトオーナー」がプロダクトの価値を最大化する責任を持ち、開発の優先順位を記したプロダクトバックログを常に最新化しながら、全体を管理する役割を担います。
また、プロジェクトを円滑に進めることに責任をもつ「スクラムマスター」がチーム全体を支援し、複数名のメンバーが実際に開発を行う形態が基本となります。
▼スクラムの全体像（出典：Scrum.org）
スクラム開発における主な手順は、下記の通りです。2〜5の開発工程をまとめて「スプリント（イテレーション）」と呼び、このサイクルを1〜4週間（多くの企業では2週間）単位で繰り返していきます。
- プロダクトバックログの作成
- スプリント計画（スプリントバックログ）：プロダクトバックログの優先順位から、今回の開発内容などを決定
- デイリースクラム：日ごとにチーム全体の状況や課題、予定の確認などを実施
- スプリントレビュー：成果物としてミスなく実装できているかなどのテスト確認を行い、フィードバックを実施
- 今回のスプリントの振り返り（→2に戻る）
基本的に、1回のスプリント期間内に新たな機能の追加や変更、削除が行われることはありません。 また、機能ごとに完成したら都度リリースをしていきます。
開発中の仕様変更も柔軟に受け入れる「エクストリーム・プログラミング（XP）」
XPとスクラムは基本的に似通っていますが、XPは仕様や要件の途中変更に対する柔軟な対応を重視した手法となっており、スクラムよりもさらに短い1〜2週間単位で「設計→実装→テスト→リリース」を繰り返す点が特徴です。
また、「コミュニケーション」「シンプル」「フィードバック」「勇気」「尊重」という重視すべき5つのポイントと、開発におけるリスクを軽減する活動として19のプラクティスが定められています。
このプラクティスの中には、例えば2人1組で開発を行う「ペアプログラミング」を行うことなどが挙げられており、顧客がチームに加わることがある点もスクラムとの大きな違いと言えます。
（参考：こちらの記事などでXPの詳細をご覧いただけます）
ユーザーにとって価値ある機能を最優先する「ユーザー機能駆動開発（FDD）」
スクラムやXPは開発体制に関する手法であるのに対して、FDDはユーザー機能価値重視という価値観に関する手法です。
FDDでは、ユーザーに対するより深い理解が必要となり、ユーザーにとって真に価値のある機能は何かを定めた上で、その機能ごとにチームを分けて開発を進めていきます。その特徴から、アジャイル開発の中でも大規模な案件に対応しやすい手法とも言えます。
主な流れとしては、「全体モデル開発→機能リスト構築→機能ごとの計画→機能ごとの設計→機能ごとの構築」となっており、細かい単位でユーザーに成果物の品質を確認してもらい、プロダクトがきちんと価値あるものになっているかどうかを見極めながら開発を進める形となっています。
4つの開発手法と、ウォーターフォール開発・アジャイル開発の違い
ここで、今回のテーマである「アジャイル開発」以外の開発手法についても解説していきましょう。
まず、ソフトウェアの主な開発手法としては、「アジャイル開発」「ウォーターフォール開発」「スパイラル開発」「プロトタイプ開発」の4つがあります。
▼ソフトウェアの主な開発手法4つ
アジャイル開発とよく比較され、従来から多くの組織で採用されているのが「ウォーターフォール開発（ウォーターフォールモデル）」です。
英語表記のWaterfallを直訳して「滝」と表すように、開発工程の上流から下流に沿って、順番に開発を進める手法となっています。
基本的にプロジェクトの最初に完璧な計画を立て、開発の途中で計画を変更せずに、前の工程を完全に終えてから次の工程に進めるため、全工程が完了するまで開発したシステムを使うことはできません。
ウォーターフォール開発の主なメリットとして、進捗管理のしやすさや、開発に必要な費用や人員といったリソース計画が立てやすい点が挙げられ、作りたいシステムが明確な大規模プロジェクトなどに特に適していると言えるでしょう。
このようにウォーターフォール開発は「予測型」とされ、開発要件の変更や手戻りが起きないものと想定して、事前の計画通りに進めるのに対し、アジャイル開発は「適応型」として、開発要件には変更が起きるものとして、随時状況を把握しながら柔軟に進めていく形となります。
現在でも国内企業ではウォーターフォール開発を実施している割合が最も多く、徐々にアジャイル開発に移行する企業が増えているという傾向があります。
▼ウォーターフォール開発とアジャイル開発の全体像（編集部作成）
また、それ以外の開発手法をご紹介すると、アジャイル開発と近しいものに「スパイラル開発」があります。
アジャイル開発ではひとつの機能の開発が完了し、品質が保証された段階でその都度リリースするのに対し、スパイラル開発では機能ごとに「要件定義→設計→実装→テスト→評価・改善」を繰り返し行いながら、最終的にすべての機能の品質が保証されてから、システム全体を一挙にリリースする形です。
そのため、スパイラル開発は「品質を重視する手法」と言われています。
スパイラル開発における開発の速さは、アジャイル開発ほど素早くはありませんが、大規模な開発案件ではアジャイル開発と比較して運用が容易になるケースがあります。
そして、AI開発などに役立つ開発手法として知られる「プロトタイプ開発」は、開発の初期段階に試作モデル（プロトタイプ）を作り、ユーザーから操作性などのフィードバックを受けて、それを本番のシステムに反映して完成させていく開発手法です。
この手法では、ユーザーの反応を直に反映することでユーザビリティ向上を図ることができるメリットがありますが、プロトタイプを作るコストがかかったり、プロトタイプの確認のために多くのステークホルダーのスケジュールを調整する労力がかかります。
そのため、大規模案件には向かない場合が多いと言われており、主に新規開発やUIを重視するプロジェクトに適しています。
アジャイル開発のメリット
あらためてアジャイル開発のメリットをまとめると、主に以下のようなものがあります。
- 開発スピードが早い
- トラブルや不具合の発生時に修正工数が少なく済みやすい
- 柔軟に計画を変更することで、経営上のリスクを低減できる
- 細やかなニーズに応じることができ、ユーザビリティが向上しやすい
- チームワークが向上しやすい
最初に決定した計画を重視し、開発途中での変更が難しいウォーターフォール開発と比べて、アジャイル開発では優先度の高い機能から完成させて順次リリースするため、その開発スピードの速さが1番のメリットとなります。
加えて、小さな機能単位で開発することから、不具合が発生しても少し前の工程に戻って修正すれば済むなど、その手戻りの少なさも開発スピードの速さに繋がっていると言えます。
また、市場変化に合わせて柔軟に計画を変更できたり、開発工程の中で幾度とユーザーからの意見を取り入れられることで、よりユーザビリティの高いプロダクトの完成が期待できるでしょう。
そして、アジャイル開発では少人数の開発チームを組むことが多く、毎日こまめにミーティングを行うことから、チームワークの向上にも繋がりやすいという側面があります。
そのような多くのメリットが期待できる一方で、開発サイクルが短く計画の柔軟性に富むことから、「全体のスケジュールを管理・把握しにくい」「開発の方針がぶれやすい」といった特徴もあります。
そのため、プロジェクトの性質によって、アジャイル開発とその他の開発手法の中から、最適な手法を選択することが重要となってきます。
アジャイル開発に移行する際に重視すべきポイント
従来のウォーターフォール開発などの手法から、アジャイル開発への移行を検討する際には、まず下記のポイントを確認しましょう。
- 自社のプロダクト開発が、アジャイル開発の特性・メリットに合致しているかどうか
- 一気に導入するか、部分的に訓練しながら導入するか
- 社内外のステークホルダーにアジャイル開発への理解を得られるかどうか
それでは、ひとつずつ解説していきます。
【自社のプロダクト開発が、アジャイル開発の特性・メリットに合致しているかどうか
前述の通り、アジャイル開発は環境や状況の変化に柔軟に対応できる一方で、必要なリソースや全体スケジュール、完成品の見通しが立ちにくいといった特徴もあります。
もし厳密に期限が決まっていて、作りたいプロダクトの仕様が明確になっているプロジェクトの場合は、ウォーターフォール開発の方が適している可能性があります。
それぞれの開発手法の特性を鑑みて、移行すべきタイミングを判断しましょう。
【一気に導入するか、部分的に訓練しながら導入するか】
そもそもウォーターフォール開発とアジャイル開発は、正反対と言っても良いほど手法も考え方も異なります。これまでウォーターフォール開発に携わってきたエンジニアにとっては、開発手法を切り替えることで大きな不安や戸惑いを抱えることになるでしょう。
従来の手法とアジャイル開発で特に異なるのは、一定期間を区切りながらこまかく開発を繰り返す「反復」の観点です。
例えば「開発途中にレビューを加える」「小さな計画変更を試みる」「開発すべき機能を区切って開発サイクルを徐々に早めていく」など、メンバーの状態に合わせて順応していく期間を挟むことで、よりスムーズに移行できるのではないでしょうか。
【社内外のステークホルダーにアジャイル開発への理解を得られるかどうか】
開発プロジェクトによっては社内で完結せず、顧客からの依頼を受けて開発を行うケースもあるかと思います。
その場合、最初から計画や仕様が固まっているウォーターフォール開発と比べて、自由度の高いアジャイル開発では要望を反映しやすい反面、途中段階での見通しが立ちにくくなるなど、顧客からの見え方が全く異なってきます。
また、アジャイル開発ではごく短いサイクルで顧客からの要望を反映していくため、開発チームと顧客のコミュニケーションを密に設けることが重要になります。
そのため、社内外の各ステークホルダーには、従来の開発手法との違いをきちんと理解してもらった上で、より細やかな意思疎通が必要になるでしょう。
【事例7選】アジャイル開発や、他分野のアジャイル化に取り組む企業
1.スプリントは1週間。素早く直せるシステム設計も実行 / AnyMind Group
2016年の創業後、世界13ヵ国、17拠点で事業を展開するAnyMind Group社。
ブランドの生産・EC構築・マーケティング・物流をワンストップで支援するプラットフォームを提供する同社では、「Product Developmentチーム」が7つのプロダクトの開発を担っています。
開発においてはスピーディーに成果を発揮することを何よりも重視し、「チームは小さく」「スプリント（開発サイクル）は1週間で回す」「マネジメントは現場の邪魔をしない」「個人よりチームの目標達成にフォーカスする」といった方針のもとで組織づくりを行っているそうです。
Product Developmentにおいては、エンジニアやプロダクトマネジャーがプロダクトごとにチームを編成し、それぞれが開発を行っています。これを、社内では「縦の軸」と呼んでいます。
それぞれのチームは、多くても15人、少ないチームでは3、4人ほどです。エンジニアって、一人ひとりが独立して動けるわけじゃないんですよね。プロダクトはひとつなので、最終的にはひとつのソースコードにマージする必要がある。
人数が増えるとコミュニケーションコストも増え、整合性も取れなくなるので、増えてきたら分割することになります。
マネジメントに関しては、そもそも多数のプロダクトを抱えるエンジニア組織を束ねることを考えると、「マネージャーが全部見る」というのは無理なんですね。ですから基本的には、現場が何でも決定していくことを良しとする、という大前提があります。
なので、あくまでも現場の意思決定の邪魔をしない、彼らがタスクに集中できるように整える、というサーバントリーダーシップに近いことを意識していますね。
2.ひとつのプロダクトを全員で作る大規模スクラム（LeSS）を導入 / Retty
日本最大級の実名型グルメサービス「Retty」を展開するRetty株式会社。
当初はサービスの「ネット予約」「検索」といった目的別のチームに分けて、領域ごとに強く権限移譲をして開発していたものの、全社として何を優先すべきかという視点ではなく、自分たちの守備範囲の中で動く「部分最適」のような開発になってしまっていたといいます。
結果として、サービス全体としてユーザー体験がちぐはぐだったり、思っていた通りに成長しなかったり、といった課題が挙がっていたことから、全社的に大規模スクラム「LeSS」の体制へと移行しました。
LeSSにおいては、「組織全体でひとつのスクラムを回すことを考える。その上で、人数が多くスケールが必要なところを工夫する」という考え方を基に、ワンチームで開発を行っているそうです。
参考：「ひとつのプロダクトを全員で作る」大規模スクラム（LeSS）を導入したRetty開発組織の進化
3.要件定義をアジャイル化し、「リーンなプロダクト開発」へ移行 / dely
レシピ動画サービス「kurashiru（クラシル）」を運営するdely株式会社。
同社では、「ユーザーの課題を受けて開発した新機能が、実はたった10人にしか使われていなかった」という過去の失敗体験から、当時のウォーターフォール型の要件定義ではリリース前に解決策の「確からしさ」を検証するアプローチが全くできていなかったと気付いたそうです。
そのため、従来の開発体制を見直し、要件定義をアジャイル化する「リーンなプロダクト開発」へと移行。
具体的には、デザインと呼ばれる要件定義のフェーズにおいて、「アイデア（解決策）→プロトタイプ→検証→ラーニング」というサイクルを回し、デザインと実装フェーズの双方をアジャイルにする開発体制に変わったといいます。
▼【左】以前の開発体制、【右】リーンなプロダクト開発
参考：要件定義もアジャイル化！「正しいアイデア」の確度を高める、リーンなプロダクト開発
4.アジャイルHRによって、変化に強く主体性のあるチームに / クックパッド
急速に環境が変化する現代においては、企業の基盤を支える「人事」の仕事にも進化が求められ、「アジャイルHR」という概念も広がりつつあります。
アジャイルHRとは、組織の課題を特定し、アジャイル開発と同様に小さく実験・実践を繰り返すことで、組織の進化を導いていくものです。
クックパッド株式会社では、早くも2018年よりアジャイルHRを導入したことで、業務の属人化が解消され、1人ひとりがより主体性を持って仕事に取り組めるようになったそうです。
我々のようなベンチャー企業の場合、「どれだけハイスキルなエンジニアを採用できるか」ということが、事業的にも非常に大きな意味を持っています。一方で、エンジニアの獲得競争は激化しており、その中でいかに競争力を持つかということが非常に重要です。
このように市場・競合・自社を見た際に、これからどのように採用をしていくべきか、ということは大きな課題だなと感じていました。
今では、採用チームで毎週水曜日にプランニングを行い、火曜日に振り返りを実施しています。また、チームの席にホワイトボードでつくった「カンバン」を置いていて、それを見るとメンバー1人ひとりが「今どの仕事をしているのか」がわかるようになっています。
チームの中で、この仕事に対してどのような施策を打っているのか、他の人が今何をしているのか、といった情報を皆で共有できるようになり、とてもわかりやすくなりました。
毎日ホワイトボードの前に集まって朝会を実施し、仕事の進捗を共有するようになったことも良かったですね。
参考：アジャイルHRの導入で、自律的なチームが生まれる。クックパッド採用チームの取り組み
5.1,000人の組織でも「品質とアジリティ」を担保すべく改革を実行 / ゆめみ
国内最大規模のWebサービスの内製化支援を行う株式会社ゆめみ。
同社は、1,000人規模の組織への拡大を目指すにあたり、階層が深くなるにつれて組織が硬直化して、現在顧客に評価されている「クオリティ（品質）」と「アジリティ（迅速性）」を担保することが難しくなると考えたそうです。
そこで、組織の骨格を再設計するため、2018年10月に「今日からアジャイル組織にします！」と宣言。「自律」「分散」「協調」という3つの基本原則に則って、秩序を保ちながらも素早く変化に対応しうる組織を構築してきたといいます。
どうしたら組織が自律的に、適応的に行動できるようになるのか。そこには意思決定プロセスが大きく関与するという。
そこでゆめみでは、「ティール組織」の中から「助言プロセス」を採用している。それによると、誰もがどのような意思決定でも行うことができるが、その前に「深く影響があるすべての関係者」「その分野の専門家」に助言を受ける必要がある。
この「助言プロセス」は、トップダウンとコンセンサスの真ん中にあり、両方の利点を取り入れた優れた意思決定プロセスで、シンプルに運用しやすい。さらに運用しやすくするように「プロリク（プロポーザルレビューリクエスト）」という仕組みを設けているという。
「プロリク」では、すべての意思決定を実施することが決められており、一方的に否決されることはない。そして、全メンバーが代表取締役権限を持ち、ここでの意思決定プロセスで全社が動くことになるという。
つまり、会社をソフトウェアとして見立て、責務に従って責任分解し、それぞれマイクロサービスでチームを作り、意思決定し、全体を作っていこうというわけだ。
※「アジャイルHR」については、こちらの記事もご参考ください
AppleやUberも実践！組織を進化させ続ける「アジャイルHR」を始める4ステップ
6.採用活動にスクラムを導入し、トップ主導から現場にシフト / BASE
Eコマースプラットフォーム「BASE」などを運営するBASE株式会社。
同社では、チームの階層が増えて取締役が直接現場を見る機会が少なくなったことと、役割や専門領域ごとにチームを編成していたことで、採用チームと取締役だけですべてを把握することが難しくなったため、採用の成果が出づらくなってきていたといいます。
そのため、エンジニアを中心に「スクラム採用」へと方針を転換。現場への採用業務の移譲にあたっては、スクラム採用の「必要性」の理解を最優先し、ハードルをひとつずつ取り除きながら、段階的に進めていったとのことです。
スクラム採用をする上では、人事はあくまでプロジェクトマネージャーです。関係者と密にコミュニケーションを取り、現場主導で採用が回るようになるまでサポートをすることが役割になります。
採用広報などにも取り組んだことやリファラルを促進したこともあり、採用決定人数は前年より43%増えて、計画人数を達成しました。計画を達成するだけでなく、選考人数に対しての入社決定率、つまり採用効率は21%向上しました。
今では、採用に関わるSlackチャンネルもかなりアクティブになり、メンバーの意識が変わってきたように感じています。
7.膨大な技術的負債を解消し、アジャイルに価値を届けられる状態へ / ラクスル
高速でサイクルを回すアジャイル開発のトレードオフとして生まれるのが、システム開発における「技術的負債」です。最後に、その側面に触れた事例もご紹介します。
ラクスル株式会社でHead of Engineeringを務める二串 信弘さんは、技術的負債とは「ソフトウェアを作る過程で、その時点で最適なソリューションを選択したことにより引き起こされる、暗黙の追加コスト」だといいます。
長年の負債が積もった無理のある状態でそのまま開発を進めると、人的なコストが多くかかってしまうことから、同社では2017年に「Raksul Platform Project」を立ち上げ、PHP40万行、JavaScript10万行という規模の巨大なアプリケーションが抱えた技術的負債の返済に着手しました。
現代の変化が非常に速い世の中においては、早くプロダクトを世の中に出してフィードバックをいただき、素早くプロダクト磨く、いわゆるリーンな開発が重要になっていますよね。これ自体は、ラクスルも非常に得意とすることです。
早くリリースすれば、それだけ早くお客様も増えて売上も上がるので、一見良い状態に見えます。しかし、「早くリリースする」ということは、いわば時間の「前借り」をしているということです。
その負債を溜めすぎるとどんどん開発効率が落ちてきて、事業にとって重要な新たな開発が進まなくなる…というリスクがあります。
一方で、こうした取り組みを進める中では、ビジネスサイドから「早く新しいもの作ってくれよ」「リファクタリングなんて、エンジニアのエゴではないか」と言われる可能性もあると思います。
ですから、エンジニアではないメンバーの理解を促進するための取り組みがとても大切です。そのためには、まず定期的に発信するということ。繰り返し飽きるまで、わかりやすく伝えることが必要です。
結果としていまでは、各機能ごとに独立した小さなチームの中で、開発効率を追求しながら、アジャイル（俊敏）に開発ができるようになり、多角化な事業展開に大きく貢献できたと考えています。
今回は、ソフトウェアの開発手法として「アジャイル開発」をテーマに、その定義から各社の事例までご紹介させていただきましたが、いかがでしたでしょうか？
日本国内でアジャイル開発がどれほど広まるかはまだまだ未知数ですが、確実に導入する企業は増えていく傾向にあります。
本記事が、各社様が「アジャイル」の導入を検討する上で、少しでもお役に立てますと幸いです。（了）
【読者特典・無料ダウンロード】UPSIDER/10X/ゆめみが語る
「エンジニア・デザイナー・PMの連携を強める方法」
Webメディア「SELECK」が実施するオンラインイベント「SELECK LIVE!」より、【エンジニア・デザイナー・PMの連携を強めるには？】をテーマにしたイベントレポートをお届けします。
異職種メンバーの連携を強めるために、UPSIDER、10X、ゆめみの3社がどのような取り組みをしているのか、リアルな経験談をお聞きしています。
▼登壇企業一覧
株式会社UPSIDER / 株式会社10X / 株式会社ゆめみ
