書籍転載：エンタープライズアジャイルの可能性と実現への提言（2）
アジャイル開発でよく見られるアンチパターンと落とし穴、その対策
――第2章 エンタープライズアジャイル探求の軌跡、2.1――
日本企業での失敗事例から、企業でアジャイル開発に取り組む際の典型的なアンチパターンを紹介。その原因となる落とし穴と、本来のあるべき姿を明らかにする。
書籍転載について
本コーナーは、インプレスR＆D［Next Publishing］発行の書籍『エンタープライズアジャイルの可能性と実現への提言』の中から、特にBuild Insiderの読者に有用だと考えられる項目を編集部が選び、同社の許可を得て転載したものです。
『エンタープライズアジャイルの可能性と実現への提言』（Kindle電子書籍もしくはオンデマンドペーパーバック）の詳細や購入はAmazon.co.jpのページをご覧ください。書籍全体の目次は連載INDEXページに掲載しています。
ご注意
本記事は、書籍の内容を改変することなく、そのまま転載したものです。このため用字用語の統一ルールなどはBuild Insiderのそれとは一致しません。あらかじめご了承ください。
■
本章では、アジャイル開発に取り組む際の典型的なアンチパターンをまず説明する。さらにそのようなアンチパターンを防ぎ、アジャイル開発をよりよく活用したり、導入するための提言を当勉強会の実行委員の講演に基づき提供する。
エンタープライズアジャイルの実現を阻む障害を理解するために、まず日本企業でアジャイル開発を行う際の失敗例について触れておこう。現状の開発方法に大きく手を加えずにアジャイル開発の形だけをなぞってみることは、ネガティブな影響しかもたらさないことがよくわかるだろう。
2.1.1. 「うちでもアジャイル開発やってみました」アンチパターン
日本の企業でアジャイル開発を試みる場合、明確な失敗ではないものの、単発のお試しで終わることも多い。これを「うちでもアジャイル開発やってみました」アンチパターンと名付けてみる。
このアンチパターンの各ステップには、さまざまな落とし穴が存在する。落とし穴にはまると開発が悲惨な形で失敗する可能性も高くなる。
アジャイル開発は多くの場合1チーム体制で実行されるだろうが、複数チームの体制で取り組むと失敗した場合の損害が大きくなるため、このアンチパターンに現れる問題が雪だるま的に巨大化する。また、複数チームの調整や同期などの問題がさらに加わることになる。
2.1.1.1. 「うちでもアジャイル開発やってみました」アンチパターンのシナリオ
アジャイル開発自体はなんとか成功する、というシナリオでは、事態は以下のように推移する。
- 1IT部門の上層部が、雑誌等の記事を読んだり他社のアジャイル開発の事例を耳にするなどして「わが社でもアジャイル開発に取り組まねば」と思い付く。アジャイル開発の事業における必要性やアジャイル開発の特性をあまり考えずに、とにかくアジャイル開発を実践してみるように部下に指示する
- 2部下は、事業部門や品質管理部門（PMO）にアジャイル開発を認めてもらうために、以下のように開発を進める
A品質管理部門（PMO）が受け入れやすいように、要求や基本設計書は開発当初に文書化する
B事業部門の担当者の時間をあまり取らないように、開発チーム側にプロダクトオーナー代理を立てる - 3IT部門が事業部門の要求が不確定な開発対象にアジャイル開発適用を提案する
A事業部門には、開発途上でのある程度の要求変更には対応できる、等のメリットを示して説得する
B失敗の可能性を考慮して、要求の不確定性はそれほど高くないテーマが選ばれる - 4開発メンバーを集めるが、アジャイル開発の経験者の割合は低い
- 5要求や基本設計書の準備ができたところで、アジャイル開発を開始するが、最初数回の反復は当初の計画通りに開発が進まない
- 63回程度の反復で計画がほぼ達成できるようになり、期日までに要求や基本設計書の内容＋αの開発をなんとか完了する
- 7プロジェクトの評価としては、要求変化への対応等である程度のメリットはあるものの、結局従来開発とそれほど大きく異なる結果が得られないため、従来開発を置き換えられるものではないと結論づけられる
- 8アジャイル開発の特性を活かした開発対象であったかどうか、開発の進め方が妥当だったかどうか等の補足情報が伝わることなく、「アジャイル開発は従来開発に置き換わるものではない」という結論が組織内に広がる。
2.1.2. 「うちでもアジャイル開発やってみました」アンチパターンを考える
前節で述べた「うちでもアジャイル開発やってみました」パターンの「不明確な動機」ステップから「不十分な理解と支援、高いオーバーヘッドの下で開発を行う」ステップまでについてどこが問題かという点と、そのステップに存在し得る落とし穴と、望ましい姿を以降記述する。
2.1.2.1. 不明確な動機
事業で必要なソフトウェア／システム／サービス（以降ソフトウェアと略す）の要求が仮説であると分かっており、ソフトウェアの一部を作ることでその仮説の妥当性をすばやく確認しながら、ソフトウェアを成長させる必要性があるような状況こそが、アジャイル開発や反復開発の適用にマッチした状況である。逆に、以下のようなソフトウェアではアジャイル開発のメリットを感じるのは難しくなる。
- 事業で必要なソフトウェア/システム/サービスの要求が既に分かっている
- 要求の妥当性の確認においてスピードが求められない（競争があまりない）
2.1.2.2. 担当者に任せる
アジャイル開発で成果を出すためには、部下が制御できる範囲を越えて、以下のような組織の協力も得る必要が生じる。
- 業務部門や企画部門
- 品質管理部門（PMO）
部下に丸投げすると、業務部門や企画部門、品質管理部門（PMO）の理解を得るのが難しいため、結果的に従来開発に近い形でアジャイル開発や反復開発を行うようになりがちである。
2.1.2.3. 従来手法のしがらみに囚われる
自明かもしれないが、このステップには以下の2点の問題点がある。
- A既存の開発方法（要求などの文書化）をあまり変えないという方針
- B事業部門の担当者の負荷が増やさないという前提
「既存の開発方法をあまり変えない」ということ自体が常に悪いことだとは言えない。しかし、あまり変えないことで「従来手法とあまり変わらない結果」がもたらされる可能性が高まる。特に、要求や基本設計を作成するということはそれなりに時間を要する（＝スピードを落さなければいけない）ことであるとともに、要求の不確定性が少ないことを暗示している。
「既存の開発方法をあまり変えない」方針により、要求や基本設計に加えて詳細設計書など開発途上で作成する成果物を作成し、開発途上で要求変更があった度毎にそれらの成果物をすべて更新していくと、開発実行時のオーバーヘッドが非常に大きくなる。このオーバーヘッドが大きいと、下手をすると従来の開発よりも生産性が下がる可能性がある。そのため、開発途上で更新する開発成果物はなるべく最低限のものに絞り込むことが望ましい。より積極的には、反復（スプリント）毎に実行されるテストの負荷を削減し、品質を確保するために単体テストや受け入れテストなどの自動化を考えることが望ましい。
「事業部門の担当者の負荷を増やさない」ことは、そもそも開発対象のシステムの事業上の位置づけが低くてもよいことを暗示しているかもしれない。事業上の位置づけが高く、早期のリリースを望まれるシステムであれば、事業部門の担当者の負荷が高まることに対する理解が得られる可能性がある。
2.1.2.4. 無難な開発対象を選ぶ
このステップには以下の問題がある。
- C要求が少し不確定な開発対象の提案
「既存の開発方法をあまり変えない」のと同様に「要求が少し不確定な開発対象」を開発した場合、「結局従来手法でも開発できたのではないか」と受け取られる可能性がある。それにもかかわらず、要求が少し不確定な開発対象を提案するのは、事業部門側が度を超えて要求を変更することで開発チームの負荷が高まるのではないかとの恐れに基づいているかもしれない。そうであれば、事業部門側に度を越えた要求には対応できないことを理解してもらう必要がある。
事業部門側が限度を超えた要求をすることで開発チームの負荷が高まることを防ぐためには、事業部門に以下の2点を理解してもらう必要がある。
- 開発チームが一定期間に開発できる開発規模（ベロシティー）は一定である
- 個別の要求変更を行うことで当初想定していたリリース内容の一部を諦めることになる
また、時として事業部門の担当者がアジャイル開発の生産性等に対して過大な期待を抱くこともある。そのような過大な期待を防止するためにも、最終的に得られるソフトウェアのスコープについての開発当初の見通しを明確に説明した方がよい。
2.1.2.5. 経験者をあまり集められない
近年アジャイル開発に取り組む企業が増えていることで、アジャイル開発の実践経験がある技術者に対する需要が高まっているが、供給が追い付いていない。そのため、開発メンバーの大半がアジャイル開発の実践経験があるという状態を実現するのは困難だろう。開発メンバーの大半がアジャイル開発の経験がない場合は、最低限実践経験のあるスクラムマスターまたはアジャイル開発のコーチが支援しないと開発に失敗する可能性が高い。
そのような場合に、プロジェクトのメンバーとなるアジャイル開発の未経験者の多くが以下のような条件に当てはまるとアジャイル開発を円滑に実践することが難しくなる。
- 今までの開発のやり方を変えることに抵抗がある
- 受身で指示された作業しか行わない
そのため、少なくともこのような条件に当てはまらない開発メンバーを集めることが大事である。特に、開発メンバーが別の会社の社員の場合は、アジャイル開発で達成したい事業上の目標に対する共感がなかったり、前述した度を越した要求変更への恐れ等から従来の開発手法を変えることに対して消極的になることもある。要は、既存の開発と異なる方法で開発を進めた結果、開発がうまく進まなかった場合のしわ寄せが自分達に押しつけられるのではないかと警戒するのである。
スクラムをベースにしたアジャイル開発を適用する場合には、アジャイル開発の未経験者に対しては以下のような最低限のトレーニングを実施することが望ましい。
- スクラムのトレーニング
- プロジェクトで使う技術プラクティスのトレーニング
これらのトレーニング後に、スクラムマスターを中心に開発メンバー全員で開発の作業のまとまりごとの完了基準について合意を取ることが望ましい。このような完了基準をスクラムでは「完了の定義」と呼ぶが、そのような「完了の定義」の例として以下のようなものがある。
- 反復（スプリント）の完了の定義
- リリースの完了の定義
この完了の定義において、反復（スプリント）で開発したコードに対してどのようなテストを実施するかということや、リリースに必要なテストやその他の作業を明示する。
さらに、大規模な開発では最低限以下のような体制を整えることが望ましい。
- スクラムで安定的に開発できるチーム
- 複数チームを統括する上位のプロダクトオーナーやスクラムマスター
- 複数チーム間のアーキテクチャー的な一貫性やUXの統一を確保することを支援するアーキテクトやUXの専門家
2.1.2.6. 不十分な理解と支援、高いオーバーヘッドの下で開発を行う
前節で述べたスクラムマスターやコーチの支援が無かったり、開発メンバーの多くがアジャイル開発に抵抗したり、トレーニングを受けないで開発の実行段階に突入すると、大混乱に陥る可能性が高い。それらに加えて、開発の実行段階では、以下のようなさまざまな落とし穴がある。
- Aアジャイル開発の理解不足
⇒プロダクトオーナー（PO）やスクラムマスターが、従来のPM的な観点でスプリント計画はPMが計画を説明する場だと位置づけてスプリント計画を実行したり、デイリースクラムや振り返りは時間の無駄だと考えて省略する - BPOの関与とコミュニケーション不足
⇒POの開発への関与が少ない
疑問に回答しない
動くソフトを確認しない
⇒開発チームがPOに確認せずに自分らで勝手に仕様を決める - C開発チームが物理的に分散している
⇒開発チームが分散していてメンバー間で直接的がコミュニケーションを取りづらい - D設備が不十分
⇒常時開発メンバーが見える場所にタスクボード、バーンダウンチャートなどを設置できない - Eリスク管理が不十分
⇒アーキテクチャーなどの潜在的な技術リスクを開発の早い段階で動くコードで確認せずに開発を進めてしまう - Fアジャイル流のガバナンスの欠如
⇒計画を立てない、見積もりをしない、計画と実績を対比しない
⇒時間枠を守らない
⇒スプリントの振り返りに基づく改善を行わない
アジャイル開発を初めて実践するメンバーが多い場合には、最初の数回のスプリント（反復）が計画通りに進捗しないことも多い。そのような場合に、「計画通りに進捗しない」ことを問題にするのではなく、それらのスプリントで振り返りが実践され、そこで何らかの具体的で実行可能な改善策が得られるように見守った方がよい。具体的で実行可能な改善策が得られれば、それが次のスプリントでどう効果を表すかを見守るべきである。
これらの問題の多くは、経験のあるスクラムマスターまたはアジャイル開発のコーチが開発チームに割り当てられることで解決できる。しかし、POとのコミュニケーションの問題の解決には開発チームの所属とPOの所属の両方に影響力があるようなシニアな管理職の支援が必要になる可能性がある。
また、「従来手法のしがらみに囚われる」の節に記したことの繰り返しになるが、「開発途上で要求変更があるたびにそれらの成果物をすべて更新する」ことを求めると、その作業負荷のために開発チームの生産性が従来手法よりも低下する危険性が高まることに気をつけるべきである。
2.1.3. まとめ
もっとも大事なことは、事業部門と開発部門の両方に対して影響力がある立場の人が利点と難しさの両面でアジャイル開発を理解し、アジャイル開発を適用する事業上の狙いを明確にすることである。さらに、アジャイル開発を適用する事業上の必然性があるならば、その人がアジャイル開発の推進者を任命し、その推進役が関係する所属元との調整を行う際に必要な支援を提供することである。
また、アジャイル開発を適用する方針が定まったら、アジャイル開発の推進者は社内の関係者がアジャイル開発を正しく理解するように支援する必要がある。さらに、プロダクトオーナーや開発メンバーにはアジャイル開発の実践に関するトレーニングを提供するとともに、経験のあるスクラムマスターやアジャイル開発のコーチを割り当てる必要がある。
この節を読んで、アンチパターンや多くの落とし穴があるためアジャイルの実践は一筋縄ではいかず、難しいとの印象を持たれた方も多いかもしれない。本章の残りの部分では、このようなアンチパターンや落とし穴に陥らないための様々な提言を提供する。本章の内容を念頭に事例の章を読めば、事例の多くがここで挙げているようなアンチパターンや多くの落とし穴を巧みに回避していることが分かるだろう。これらの事例でアンチパターンや多くの落とし穴を回避できたのは、アジャイル開発を適用する事業上の狙いが明確で、アジャイル開発の推進者が適切に任命され、十分な支援が得られたことに負うところも大きい。これがアジャイル開発を適用する際の要点だと考えられる。
■
今回は企業でアジャイル開発に取り組む際の典型的なアンチパターンについて説明しました。次回は、エンタープライズアジャイル開発の戦略について考察します。
1. スクラムによるアジャイル開発の進め方、従来手法とのギャップ
アジャイル開発を概説。また、その中の人気手法の一つである「スクラム」の基礎の基礎として、開発の進め方や従来手法との違いについて説明する。
2. 【現在、表示中】≫ アジャイル開発でよく見られるアンチパターンと落とし穴、その対策
日本企業での失敗事例から、企業でアジャイル開発に取り組む際の典型的なアンチパターンを紹介。その原因となる落とし穴と、本来のあるべき姿を明らかにする。
3. 企業でのアジャイル開発の戦略 ― その狙い、注意点、投資効果
企業や事業部がどんな狙いでアジャイル開発を使うのか？ 注意すべき点は何か？ 投資効果をどう考えるか？ というエンタープライズアジャイル開発の戦略について考える。
