アジャイルをやるのではなく、アジャイルであれ。
アジャイルをやることで開発スピードは上がり、要件変更にも柔軟に対応することができます。
一方で、押さえるべきポイント・コツを知らないと、むしろ開発スピードが落ちる/要件変更が容易にいかず工数が嵩む/etc… といった課題に衝突します。
この記事では、アジャイル開発をこれからやる・やっている方どちらであってもアジャイルに本気で向き合おうとしている方へ、”やる”だけにならないコツをお渡しできればと思います。
もくじ
はじめに
こんにちは。アジャイル・スクラム開発をメインとして日々精進しているkikuchi.sです。
この記事は アイソルート Advent Calendar 2025 3日目の記事です。
アイソルートには多様なアジャイル開発の経験・ノウハウがあります。
これらを活かし、お客様のお悩みに寄り添い解決していくことを目指して、2025年からアジャイルソリューショングループを発足しました。
今年もアジャイル開発の専門家としてお客様に寄り添い、様々な課題に取り組んで参りました。そんな年の締めくくりに、アジャイルが何のために存在するのか立ち止まって見つめ直す機会にしたいと思い、この記事に残します。
アジャイル開発とは
ズバリ、「必要なものを必要な分だけつくる」です。
従来のウォーターフォール開発では、以下のような課題がありました。
- 計画が長期化しやすい
ウォーターフォールは、要件定義 > 設計 > 製造 > テスト を順に進める開発手法です。前工程が終わらないと次工程に進めないため、全体として開発に時間を要します。後工程に差し掛かったタイミングで前工程に不備があった場合は大きな遅延となるリスクもありました。 - 要件変更のコストが大きい
製造やテストの工程でやっと動くもの目にします。このタイミングで要件変更したくなるケースがありますが、要件定義から見直す必要があるのでオーバーヘッドがかかりやすいです。 - サービスや機能が使われない
リリースして初めてサービスがユーザーの目に触れます。苦労してつくった機能が意外と使われなかったり、実際のところはユーザーに触れてもらわないと価値があるかを見極めるのは難しいです。
アジャイル開発は、これら課題を解決する手段になり得ます。
- 短期計画をつくる
アジャイル開発のメジャーなフレームワーク「スクラム開発」では、最短1週間でリリースする計画を立てて進めます。直近1週間程度の計画なので見通しが立てやすく、見込みズレを起こしにくくなります。 - こまめに計画変更する
開発を進める中で見つかった課題だったり、状況の変化に合わせて次の計画の見直し・修正を行います。要件定義や設計で見えなかった部分も次の1週間の計画に取り込めるので、手戻りのコストを最小限に抑えます。 - できたモノからリリースする
優先度の高い機能から開発してできたモノからリリースします。短期間でリリースすることができるとユーザーからの反応をすぐに得られ、早々に改善のための計画を立てることができます。使われないと分かった機能に開発コストを振り込みすぎないという効果もあります。
まさに、「必要なものを必要な分だけつくる」ことで開発コストを最小限かつ最適な配分で振り分けることができます。さらには、ユーザーにとって本当に欲しいものを提供する近道となり得ます。
アジャイル開発のメリット・デメリット
メリット
「アジャイル開発とは」でご紹介した内容はアジャイル開発のメリットの一部です。
- 短期計画をつくる
- こまめに計画変更をする
- できたモノからリリースする
細かいことを言うと他にもメリットは多くありますが、本記事の趣旨から外れるので列挙は避けておきます。本記事では、とりわけ「必要なものを必要な分だけつくる」ことで「不確実性への適応が容易である」のが大きなメリットであると覚えておいてください。理由は先に触れた内容で、こまめな計画→修正→リリースをすることで不確実な未来の状況変化でも対応がしやすいという点になります。
デメリット
ここまでで触れた内容を聞くと「アジャイル開発、いいじゃん！」と思ってもらえるかもしれません。そうなんです、アジャイル開発ってすごくいいんです。
ただ、気を付けなくてはいけない点はもちろんあります。以下に注意点をいくつか挙げます。
- すべての機能がいつまでに完成するか分からない
先に述べたように、短期的な計画とリリースを繰り返すので中長期的な見通しを立てにくく、すべての機能を揃えてリリースできる日がいつになるかが曖昧になります。そもそも開発スタート時点の想定以上に途中で追加する機能・破棄する機能が発生する前提なので、必要な機能をすべて揃えた状態でリリースできる日なんて誰も予想できません。 - アジャイル開発は高度なスキルを求められる
本当の意味で「必要なものを必要な分だけつくる」ためには、開発者もクライアントと同じ目線を持って開発計画に携わる必要があります。逆に、クライアントも開発者と同じ目線に立ってチーム課題に向き合わないといけません。それが例え技術的な課題であっても、把握に努めて最善な計画変更を検討しなければいけません。
つまり、アジャイル開発も適材適所で手段として検討することをおススメします。
いつまでに完成するか分からない開発をどのように折り合いをつけようかを考えることができ、高度なアジャイル開発の経験・ノウハウを持っていれば大きく失敗することはないでしょう。そもそも「アジャイルは失敗しない」という言葉があるくらいです。それでもアジャイルで失敗することはあります。
では、何故「アジャイルで失敗する」ということが起き得るのか？
次の節で説明していきます。
アジャイルをやるのではなく、アジャイルであれ
Stop doing Agile. Start being Agile.
「アジャイルをやるのではなく、アジャイルであれ。」
これは私の心に強く残っている大事な言葉で、アジャイル開発の核心を非常によく表した言葉です。
“アジャイルをやる”とは
カタチ・形式を実践することを指します
- スクラムやカンバンといった特定のフレームワークに従う。
- 毎日デイリー(朝会)を行う。
- スプリントやイテレーションといった期間を設定する。
- 特定のツール（JiraやConfluenceなど）を使用する。
“アジャイルである”とは
アジャイルの価値観や原則に基づいたマインドセットや文化を指します
- 適応と学習：計画通りに進めることよりも、変化に適応し、学習し続けることを重視する。
- 顧客中心：常に顧客に価値を提供することを最優先する。
- コラボレーション：チームメンバーや顧客と密接に協力し、信頼関係を築く。
- 透明性：作業の進捗や課題をオープンにし、全員が同じ認識を持てるようにする。
- 改善の文化：失敗を恐れず、継続的にプロセスを見直し、改善していく。
アジャイルをやるのではなく、アジャイルであれ。
何故、アジャイルで失敗するのか？
アジャイルに限らず、何事も新しいことを始めようとしたときにカタチ・形式から入るというのは悪いことではありません。そうでないと初心者の門は狭くなってしまい、そもそも始めようという人はいなくなってしまいます。そういうことを言いたいのではなく、本当の意味で良くないのはカタチ・形式だけでやった気になっていることです。
カタチ・形式にこだわるばかりで、開発スピードは期待ほど上がらない・むしろ下がることもあり得ます。
カタチ・形式を模倣するだけでは仕様変更がしやすいシステムには成りません。変更を容易にする開発計画をチーム全員で考えなければいけません。
「アジャイルをやるのではなく、アジャイルであれ。」という言葉が表すように、アジャイルの強みである「不確実性への対応」を発揮するには、ただカタチ・形式を模倣するではなく、アジャイルならではの考え方を理解する必要があります。
まとめ
アジャイルはカタチ・形式だけでは100%の力を発揮することはできません。アジャイルを本当の意味で理解しようとチーム一丸となり、日々コミュニケーションや学習を繰り返すことで期待する効果を得られるようになります。
本記事をキッカケとして、アジャイルと本気で向き合おうとしている方へ、カタチ・形式を”やる”だけにならないようにするコツ（=アジャイルの考え方を理解しようとすること）をお渡しできたなら幸いです。
