2023年12月20日にオンラインセミナー『アジャイル開発の落とし穴とは？ よくある失敗を回避し成功へ導くポイントを解説』を開催いたしました。
この記事では当日用いた資料を公開しています。
目次
なぜ今、アジャイル開発なのか
今の時代をVUCAと表すことがあります。
VUCA（ブーカ）とは、Volatility（変動性）、Uncertainty（不確実性）、Complexity（複雑性）、Ambiguity（曖昧性）の頭文字をとった造語で、目まぐるしく変転する予測困難な状況を意味します。
変化が激し予測困難な時代を表すVUCAというキーワードがビジネス領域でよく使われるようになったことから、「変化を受け入れ、素早くリリースできる」という特徴を持つアジャイル開発にも今脚光があたっています。
アジャイル開発に「失敗」はないが…
アジャイル開発にはある意味では「失敗」がないといえます。
アジャイル開発は、うまくいかないことを改善しながら進み続けていく開発手法であるため、途中でトラブルがあってもそこで諦めずに改善して前進できれば、それは「失敗」ではないのです。
しかし、「失敗」はないとはいっても、アジャイル開発でよく起こりがちなトラブルのパターンはいくつも挙げることができます。
- ウォーターフォール開発のように成果物が予定通りに出てこない
- できたものがリリースできる品質ではなかった
- 完成までに想定より長い期間が必要になり予算超過になってしまった
これらのトラブルもアジャイル開発を継続する中で改善さえできれば「失敗」ではないのですが、もちろんプロジェクトの過程で問題が起きないに越したことはありません。よくあるトラブルの中には知識があれば予防や回避が可能なものもあります。
本記事では何を準備すれば不要なつまずきを避けられるのかという観点から「アジャイル開発のよくある失敗」について解説していきます。
うまくいかないアジャイル開発のパターン
理解不足で起こるアジャイルのトラブル
割とよくあるのが、アジャイルに対しての理解不足が起因となるトラブルです。
アジャイル開発というのは短期間で動く機能をつくり、できたものの改善を繰り返しながら開発を継続していく手法です。そのため、ウォーターフォール型の開発よりも機能単位で「素早くリリースできる」といえます。
しかし、「短期間で動くものをつくる」ことに加えて「安い」や「品質がいい」ことまで期待して考えてしまうとトラブルの元です。
もちろん費用を抑えて品質がいいものをつくることは価値があるので、それを目指しはしますが、アジャイル開発にその要素が内在するわけではありません。
それどころか、ウォーターフォール型と異なり、アジャイルの場合は途中で修正や変更を繰り返すことを許容するため、総工数を見るとウォーターフォール型のプロジェクトより工数が増えてしまう（開発費用が高くなる）こともよくあります。
品質面でも、もちろん一定の品質は保つのですが、ウォーターフォール型のように長いテスト期間をとって複数デバイスでテストを行うようなことは困難なため、アジャイル開発がすなわち品質が高いことには繋がりません。
アジャイルの「変化に柔軟に対応できる」という特徴は、仕様の追加・変更を無制限に受け入れられるという意味ではありません。もしリリース直前で追加要望が出てくれば、開発期間、費用、品質などに当然ながら響いてしまいます。
この原則を理解せずに、都合よく「途中の仕様変更が可能で、早く、安くシステム開発ができる手法だ」というような思い込みをしてしまう（理解不足がある）と、落とし穴があるわけです。
そもそもアジャイルが適していないケース
そもそもアジャイルが適さないプロジェクトにアジャイル型の開発を適用しようとしてトラブルにつながることもあります。
冒頭で「今はVUCAの時代であり、予測困難な状況に対応できるアジャイルが注目されている」と紹介しましたが、例えば変化の少ない定型業務で使う業務システムの開発など、確実性が高いプロジェクトもたくさん存在します。
決まった仕様のものを確実に作ることが重要なプロジェクトはウォーターフォール型の開発が適しているので、わざわざアジャイル型の開発を適用するのはお勧めできません。
もちろん確実性が高いプロジェクトでも、途中でユーザーの意見を取り入れて、何度も改善を繰り返しながら開発を進めたいというような目的があればアジャイルは有効です。また、他にもアジャイルでの開発を体感したいなど教育目的で取り組むケースもあります。
しかし、それらの目的とアジャイルでの開発を成功させたいという目的を混在させるのは危険です。
特別な理由がなく「アジャイルでやってみたい」というような考えだけでアジャイルが適していないプロジェクトに無理やり導入するとトラブルの元になります。
計画が甘い「部分的アジャイル」
部分的アジャイルは「ハイブリッドアジャイル」とも呼ばれ、さまざまなフレームワークが存在します。NCDCのアジャイル方法論もこれに当たり、決して部分的にアジャイル開発を取り入れることが即トラブルになるわけではありませんが、部分的アジャイルならではといえるアンチパターンも確実に存在します。
１つ目がフェーズ分離型のハイブリッドアジャイルにおけるアンチパターンです。
要件定義・設計・開発・テストのうち、設計までをウォーターフォールできちっと固めて、実装とテストはアジャイルでやるという計画をされるケースがありますが、この進め方は要注意です。
せっかくはじめに時間をかけて設計を固めたのに、開発をアジャイル型で行い仕様変更を繰り返した結果、設計書の見直しが頻発し、品質も良くないというトラブルが起き易くなります。
2つ目はアーキテクト分離型のハイブリッドアジャイルにおけるアンチパターンです。
変化が少ないバックエンドの開発はウォーターフォールで行い、変化が多いフロントエンドの開発はアジャイルで行いたいという話はよく聞きますが、この場合、両方の開発が終わるまで最終的なテストができないことに注意が必要です。
まずバックエンドを完成させてからフロントエンドをアジャイルで進めるなど、しっかり計画できていれば良いのですが、計画が甘いまま両者を同時並行で進めると、結果的に最終テストがいつできるか不明確になり、なかなかリリースできないというトラブルが起きやすくなります。
よくある失敗を回避するポイントは？
うまくいかないアジャイル開発のパターンをいくつか紹介しましたが、これらのアンチパターンにはどのような対策が有効なのでしょうか？
結論から書くと、プロジェクトの初めが肝心で「準備を手厚く行うこと」が大切です。
いくら変化に柔軟に対応できるアジャイルといえども、初めに考えるべきことを決めずにプロジェクトを開始してしまうと後々混乱するのです。
次項からはNCDCが取り入れている具体的な手法をいくつか紹介します。
準備をしっかり行うNCDCのアジャイル開発方法論
インセプションデッキ
NCDCではよく、インセプションデッキの作成を行います。
インセプションデッキというのは、「最初の山札」という意味で、プロジェクトメンバーが集まって行うワークで構成されており、これによって、メンバー全員がプロジェクトの理解を深めます。
1.我々はなぜここにいるのか
１つ目は「我々はなぜここにいるのか」というワークです。そのプロジェクトが何のために発足したのか、根幹となる理由を書き出し、メンバーの意識を合わせます。
また、プロジェクトは生き物で、メンバー一人一人の想いがプロジェクトに紐づいているので各メンバーがどのような想いでプロジェクトに参加しているかも理解します。例えば、１メンバーが技術の向上を目的としている場合もあります。その場合、コワークを多くして成長を促す環境をつくるなど、柔軟な計画をすることもできます。
2.ご近所さんを探せ
続いて、「ご近所さんを探せ」というワークもあります。プロジェクトメンバーを中心に各自の関係や、誰がどのロールを担当するのかを整理したり、決裁権がどこにあるのかを明確にしたりします。これにより、プロジェクトの遅延リスクを軽減します。
とくに、開発チームから見て「お客様」にPO（プロダクトオーナー）がいる場合は、プロジェクトを円滑に進めるためにこのワークでPOの重要性を理解いただくことを重視しています。
3.トレードオフスライダー
続いて「トレードオフスライダー」です。アジャイル開発は変更を受け入れながら進める手法でありますが、むやみやたらに変更を歓迎するわけではありません。変更を受け入れる条件をあらかじめ決めておくのがこのワークです。
トレードオフなので、途中で計画に変化を加えることで何かを得るなら、その代わりに何かを諦めることになります。例えば機能変更を加えても「リリース日が最優先」であれば、「予算オーバーは諦める」という原則を決めておきます。
リリース日と予算に限らず、プロジェクトで重要視する指標が他にもあればこのトレードオフスライダーを追加して方針を共有しておきます。
例えば「プロジェクトを通じた人材育成が重要」であれば、その代わりに「完成期日が守れないことは受け入れる」などの方針を決めていきます。
4.何がどれだけ必要か
プロジェクトに必要な期間や予算を見積もります。ただし、この見積は超概算見積であることを認識し、柔軟に調整していくべきものです。アジャイル開発を進める中で追加要件発生したときなどには、トレードオフスライダーなどの指標を用いて、期間や予算の調整を行います。
トレードオフスライダーを作る際に「全部が優先事項」と言われてなかなか優先・非優先を決められないケースもあります。その場合「このプロジェクトは変化に柔軟に対応できなさそうだ」ということがこの過程でわかるので、アジャイルといいながらも比較的固めの計画を立てて（期間や予算のバッファを多めに見積もるなどして）プロジェクトを進めることになります。
冒頭にも触れた通り、インセプションデッキは「最初の山札」という意味なので、プロジェクトを進める中で振り返り、状況が変われば再調整し、運用していきます。
リリースの定義
インセプションデッキに続いて「リリースの定義」を紹介します。
アジャイル開発は、新規サービスのMVP開発やPoCでよく用いられますが、MVPにどの程度の品質を求めるのかは発注者側と受注者側で認識の乖離があることがあります。そのため、キックオフ時に認識合わせを行うことを推奨しています。これをリリースの定義と呼んでいます。
プロジェクトのスコープ確認と最終成果物の認識合わせなどをして、同じMVPという言葉でも発注者側と受注者側で想定が異なるというトラブルを未然に防ぎます。
また、どのレベルのテストを行うかまではじめに詳しく議論しておくことも有効です。たとえば、当初「PoC用のアプリなのでテストに時間やコストはかけない」と合意していても、実際には一部の一般ユーザーにアプリを公開するというようなケースがあります。この場合、公開範囲を考えると複数端末でのテストや脆弱性診断なども必要になるため、たとえ発注者が「テストに時間やコストはかけない」と言っていても、その通りにはいかなくなります。発注者と認識がずれているかもしれないと感じたら、開発側から「一般ユーザーも使うものであればテストにそれなりの時間とコストをかける必要がある」等の説明した方が良いでしょう。
全体的なアーキテクチャを描く
プロジェクトの準備段階で全体的なアーキテクチャを描いて、新たな要望が入った際に、破壊的な変更にならないようにします。採用する技術やIaaSなどもこれに含まれます。
極端な例ですが、AWS上で開発を進めていたたら新たな要望がありMicrosoft Azure上で開発しなければいけなくなるという可能性もあります。はじめに全体的なアーキテクチャを描いて認識を合わせておけば未然に防げるかもしれませんし、どうしても途中変更が必要な場合は「計画していたアーキテクチャとこれだけ変わるので移行コストが発生する、開発期間が延びる」などの相談がしやすくなります。
共通言語集の作成
ユビキタス言語集といったりもしますが、プロジェクト関係者が同じ単語で同じ認識を持てるよう共通の言語集を作成します（特に業界内だけの一般的ではない専門用語や、アジャイルの知識について、認識合わせを行います）。
開発メンバーは業務のことがわからない。POは業務のことがわかっても開発のことがわからない。という体制のままプロジェクトを進めても、決してうまくいきません。はじめにプロジェクトの辞書のようなものを作成しておくと相互の理解が深まりますし、もし途中からプロジェクトに入るメンバーがいた時も、キャッチアップがスムーズになります。
共通言語集ははじめに用意するのがお勧めですが、時にはプロジェクト内で定期的に勉強会を開催するなど、随時、関係者の相互理解を深める取り組みも行います。
リリースの認識合わせ
アジャイル開発は途中で計画変更が入ったり、一度できた機能を改善し続けたりするので、どこまでの機能ができていればリリースできるか判断基準が曖昧になりやすいという問題があります。そのため、どうなればリリース可能なのか認識を合わせておきます。
要求の一覧であるプロダクトバックログに「これがないとリリースできない」という機能から優先順位をつけておき、それをベースにスプリントを回していくのがお勧めです。
また、リリースの定義があればそれに従ってテスト計画をしていきます。
まだ一般ユーザー向けにリリースするわけではない機能単位のテストであれば、ツールを使った自動テストなど簡単な検証でかまいません。しかし、リリース先が一般ユーザーになるタイミングでは、実際のユーザーの利用を想定してあらゆる不具合を潰していく必要があります。
このように、リリースの計画に合わせて各スプリント内でどのようなテストを行うべきかのイメージをすり合わせてからスタートするのがお勧めです。
アジャイル開発に取り組みたい方、改善したい方へ
アジャイルの「よくある失敗」を防ぐための策をいくつかご紹介しましたが、いずれもとにかくプロジェクトの初めが肝心で「準備を手厚く行うこと」が大切です。
NCDCでは本講演でご紹介した方法論をベースに、これからアジャイル開発に取り組みたい方や、既存のやり方を改善したい方へのご支援を行なっています。
アジャイルを用いた開発案件の依頼先をお探しの方、または自社でアジャイル開発体制を構築したい、改善したいといったご相談がある方は、お問い合わせフォームからご連絡ください
