1. AIツール実践ラボ~ITツール、AI、そして働き方~
  2. アジャイル開発はソフトウェア..
アジャイル開発はソフトウェアだけのものじゃない
2026-02-08 09:08

アジャイル開発はソフトウェアだけのものじゃない

アジャイル開発という考え方は、もはやソフトウェアの世界だけのものではなくなってきています。ハードウェアの開発現場でも、デジタルコンテンツの制作でも、この「小さく作って、フィードバックをもらって、改善する」というサイクルは非常に有効だと思います。


※Jiraを解説したUdemy講座のクーポンはこちら

https://kurihara-naoki.com/udemy-coupon/jira/


※※今回のお話のソース情報

- 成功確率データ: Standish Group「CHAOS Report 2015」

- アジャイル: 成功39% / グレーゾーン52% / 失敗9%

- ウォーターフォール: 成功11% / グレーゾーン60% / 失敗29%

- 参考: https://www.infoq.com/articles/standish-chaos-2015/

- 参考: https://www.scrum.org/resources/blog/key-lessons-standishs-2015-chaos-report

- 日本のアジャイル導入率: IPA「DX白書2023」(日本: 約23%、米国: 53%以上)

感想

まだ感想はありません。最初の1件を書きましょう!

00:01
スピーカー 2
今回は、アジャイル開発という考え方についてお話ししたいと思います。 アジャイル開発という言葉を聞いたことがある方も多いかもしれません。
簡単に言うと、完璧なものを一発で作ろうとするのではなくて、 小さく作って、もうすぐに使ってもらって、フィードバックをもらって改善してまたリリースすると。
そういったサイクルを繰り返していく開発の進め方をアジャイル開発というふうに呼ばれています。
この全く反対の考え方というのがウォーターフォールというものがあります。
これは最初にすべての設計を固めてから順番通りに進めていって、最後に完成品を出すというようなやり方ですね。
水が一気に落ちてくるみたいなウォーターフォールです。
この2つの違いを身近な例で例えると、ウォーターフォールがレシピを完璧に決めてから一気に作れる料理みたいな感じで、
アジャイルは味見をしながら少しずつ味を調整していく料理みたいな感じかなと思います。
日本ではどちらがよく行われているのかというと、このウォーターフォール的な考え方がずっと主流だったようです。
製品はやっぱり完璧な状態で出すべきという完璧思考みたいな思想がやっぱり日本は強いですよね。
実際に先ほど確認してみたんですけれども、IPAという情報処理推進機構というIPAという組織があるんですけれども、
そのDX白書2023を見てみると、日本企業のアジャイル開発の導入率はまだ約23%にとどまっているそうです。
一方でアメリカでは53%以上の企業がアジャイル開発を導入しているということで、この差かなり大きいですよね。
日本は23%に対してアメリカは53%ですから、アジャイルという考え方が出てきてからもう結構経つんですけど、
10年以上経つと思うんですけど、それでもまだ日本は約23%にとどまっているということですね。
これもある方のXのポストで知ったんですけれども、スタンフォール大学のソフトウェア工学の講義の中では、
ウォーターフォール開発というのはトラディショナルアプローチという文章で説明されている。
つまり従来型の開発手法ということですね。という表現で大学の講義の中で語られているそうなんですね。
もはや主流じゃなくて過去のやり方という位置づけなんですよね、ウォーターフォール開発というのが。
さらにその講義ではアジャイル開発とウォーターフォール開発の成功確率を大規模、中規模、小規模という3つのプロジェクト規模に分けて比較したデータというのも紹介されていまして、
結果として大、中、小、どの規模でも、どのプロジェクトにおいてもアジャイル開発のほうが成功確率が高いということをデータとして出ているようです。
03:02
スピーカー 2
具体的な数字で紹介すると全ての規模の平均でアジャイル開発の成功確率が39%に対してウォーターフォール開発の成功確率は約11%だそうです。
39に対して11ですからかなり低いですよね。
成功でも失敗でもないいわゆるグレーゾーンというのが50から60%くらいあるんですけど、
スピーカー 2
逆に失敗の確率というのを見てみるとアジャイル開発はわずか9%なのに対してウォーターフォールは29%ということで、
ウォーターフォールというのはアジャイルの3倍以上失敗しやすいということがデータで出ているみたいです。
スピーカー 2
これ実は2015年のデータなんですよね。結構古いですよね。
それでも3倍以上失敗しやすいというのが分かっていて、
実は近年のデータというのもちょっと見たんですけどもっと差が広がっているみたいですね。
アジャイル開発の成功確率がもっと上がっているということです。
もともとはソフトウェア開発の手法として広まったこのアジャイル開発という手法なんですけど、
こういったアカデミックな場でももう裏付けられているということで、
最近はソフトウェアの世界だけにも留まらなくなってきているというふうに考えています。
例えばなんですけど、ハードウェアですね。物理的な製品の開発、なんかデバイスみたいなものですね。ガジェットみたいな。
開発の現場でもアジャイルの開発がすごく取り入れられてきているというようになっていると思っています。
試作品を作ってすぐに実際に触ってもらってフィードバックをもらって改善していくというような、
そのサイクルを回しながら製品を育てていくようなイメージですね。
なので物理的な製品ですらそういう開発の進め方に変わってきているというふうに思います。
我々ゆうでみ講師のゆうでみ講座のようなデジタルコンテンツはどうなのかというと、
やっぱりもっと柔軟にできるはずなんですよね。
スピーカー 2
何でかというと物理的な製品と違って公開した後でもすぐに修正や追加というのができるからですね。
物理的な製品はなかなか難しい面もあるんですけど、それでもアジャイル開発が採用されつつあるので、
デジタルコンテンツはもっと使えるかもというふうに思っています。
このアジャイル開発を実践するときに欠かせないツールというのがありまして、それがJIRAですね。
アルファベットでJIRAですね。
これはアトラシアンというオーストラリアの会社が開発しているプロジェクト管理ツールなんですけれども、
以前のエピソードでもお話ししたんですけど、私はこのJIRAのゆうでみ講座を作っても公開しています。
スピーカー 2
制作する中でJIRAの機能を隅々まで触ってみて改めて感じたのが、
アジャイル開発をするならもうJIRAは必須だというふうに言っていいんじゃないかというふうに思っています。
スピーカー 2
なぜかというとJIRAは本当にいろんな素晴らしい機能がたくさん詰め込まれているんですけど、
スクラムボードの機能が非常に優秀でして、
このスクラムっていうのはアジャイル開発の具体的な進め方の一つなんですけれども、
06:00
スピーカー 2
このスクラムの流れをそのままJIRA上で完全に管理できるようになっています。
スプリントと呼ばれる短い開発期間を設定して、その期間内にやるべきタスクっていうのを管理して、
終わったら振り返りをして次のスプリントに進むっていうような一連の流れがJIRA上で完結できるようになっているんですね。
さらにチームの進捗を可視化するレポート機能とかも充実してますし、
スピーカー 1
アジャイル開発といえばJIRAという関係は決して大げさではないと思っています。
ここからが私自身の話なんですけれども、
このアジャイルの考え方はUdemy講座の制作にも当てはまるんじゃないかと思うようになりました。
Udemyの講座っていうのは一旦公開した後も内容を更新できるんですよね。
受講生の方からレビューやフィードバックやコメントをいただいて、
ここが分かりにくかったという声があればそこを改善することもできますし、新しいセクションを追加することもできるようになっています。
なので小さくリリースしてフィードバックをもらって改善していくっていうアジャイルのサイクルですよね。
そういったサイクルで作ることもできます。
ただここで一つ大事なことがあって、
アジャイル的にまず出して早くリリースするっていうのは適当でいいから出すっていう意味合いでは全くないんですよね。
小刻みに改善を重ねて最終的には極めて高品質なものに高めていくっていうのがアジャイルの本質だと思ってますので、
最後は必ず高品質なゴールがあるというのを常にイメージしておくというのが大事なんじゃないかなと思います。
スピーカー 1
私の場合で言うとまず核となる内容をしっかり作り込んで公開します。
そこまではかなり大変ですけど、その核の部分はしっかり作るまでやります。
そこから受講生の声を聞きながらですねセクションを追加したり説明を追加したり、
ちょっと改善した方がいいところがあれば改善していくというような感じですね。
最初から100%の完成度を目指して公開が遅れるよりも、まずはしっかりとした土台を早めに出してそこから育てていくっていうのが
今考えているアジャイル的なUDemy講座の作り方なのかなというふうに思ってます。
アジャイル開発っていう考え方はソフトウェアの世界の中だけのものではなくなっているというふうに思ってます。
ハードウェアの開発現場でも研究開発みたいなところでもかなり採用されていると思ってますし、
スピーカー 1
デジタルコンテンツのような制作でも小さく作ってフィードバックをもらって改善していくというサイクルは非常に重要な考え方だと思ってます。
これを聞いてくださっているあなたが何かを、何かデジタルでもハードウェアでもソフトでも何かを作っているなら
スピーカー 2
完璧になるまで世に出さないっていうのではなくて、まずはしっかりとした土台を作って公開して
スピーカー 1
そこから改善を重ねていくっていう進め方もあると思いますので、一度試してみてもいいのかもしれません。
09:08

コメント

スクロール