本コラムでは、筆者が「エンタープライズアジャイル」に関係すると判断した雑多なトピックスを徒然なるがままに取り上げて論じていくつもりである。第 1 回は、筆者が最近執筆に関与した書籍「エンタープライズアジャイルの可能性とその実現への提言」 [1] 向けに執筆した「よく見られるアンチパターンと落とし穴」を掲載する。
エンタープライズアジャイルの実現を阻む障害を理解するために、本記事では日本の企業でアジャイル開発を行う際のアンチパターンを説明する。従来の開発方法に大きく手を加えないアジャイル開発風の開発を行うことでは、アジャイル開発の良さは現れないことがよく分かるだろう。
1. 「うちでもアジャイル開発やってみました」アンチパターン
日本の企業でアジャイル開発を試みる場合、明確な失敗ではないものの、単発のお試しで終わることも多いように思える。これを「うちでもアジャイル開発やってみました」アンチパターンと名付けてみる。
このアンチパターンの各ステップには、様々な落とし穴が存在し得る。これらの落とし穴にはまると開発が悲惨な形で失敗する可能性もある。
「うちでもアジャイル開発やってみました」アンチパターンは１チームの体制でたいてい実行されるだろうが、複数チームの体制で取り組むと失敗した場合の損害が大きくなる。そのために、複数チームの体制ではこのアンチパターンに現れる問題の多くの難易度が高まる。また、複数チームの調整や同期などの問題がさらに加わる。
2. 「うちでもアジャイル開発やってみました」アンチパターンのシナリオ
このパターンは、アジャイル開発自身はなんとか「成功する」というシナリオにおいて例えば以下のように進行する。
- IT部門の上層部が、雑誌等の記事を読んだり、他社のアジャイル開発の事例を耳にして、わが社でもアジャイル開発に取り組まねばという気持ちが先に立ち、アジャイル開発の事業における必要性やアジャイル開発の特性をあまり考えずに、とにかくアジャイル開発を実践してみるように部下に指示する
- 部下は、事業部門や品質管理部門 (PMO) にアジャイル開発を認めてもらうために、以下のように開発を進めることにする
- 品質管理部門 (PMO) が受け入れやすいように、要求や基本設計書は開発当初に文書化することにする
- 事業部門の担当者の時間をあまり取らないように、開発チーム側にプロダクトオーナー代理を立てる
- IT部門が事業部門の要求が少し不確定な開発対象にアジャイル開発の適用を提案する
- 事業部門には、開発途上でのある程度の要求変更には対応する等のメリットを示して説得する
- 失敗を恐れて、要求の不確定性はそれほど高くないテーマが選ばれる
- 開発メンバーを集めるが、アジャイル開発の経験者の割合は低い
- 要求や基本設計書の準備ができたところで、アジャイル開発を開始するが、最初数回の反復は当初の計画通りに開発が進まない
- ３回程度の反復で計画がほぼ達成できるようになり、期日までに要求や基本設計書の内容＋αの開発をなんとか完了する
- プロジェクトの評価としては、ある程度の要求変化への対応等でメリットはあるものの、結局従来開発とそれほど大きく異なる結果が得られたわけではないため、従来開発に置き換わるものではないと結論づけられる
- アジャイル開発の特性を活かした開発対象や開発の進め方であったか無かったか等の補足情報が伝わることなく、「アジャイル開発は従来開発に置き換わるものではない」という結論だけが組織内に広がる
3.「うちでもアジャイル開発やってみました」アンチパターンを考える
前節で述べた「うちでもアジャイル開発やってみました」パターンの「不明確な動機」ステップから「不十分な理解と支援、高いオーバーヘッドの下で開発を行う」ステップまでについてどこが問題かという点と、そのステップに存在し得る落とし穴と、望ましい姿を以降記述する。
3.1 不明確な動機
事業で必要なソフトウェア/システム/サービス（以降、ソフトウェアと略す）の要求が仮説であると分かっており、ソフトウェアの一部を作ることでその仮説の妥当性をすばやく確認しながら、ソフトウェアを成長させる必要性があるような状況こそが、アジャイル開発や反復開発の適用にマッチした状況である。逆に、以下のようなソフトウェアでアジャイル開発のメリットを感じるのは難しくなる。
- 事業で必要なソフトウェアの要求が既に分かっている
- 要求の妥当性の確認においてスピードが求められない（競争があまりない）
3.2 担当者に任せる
アジャイル開発で成果を出すためには、部下が影響力を行使できる範囲を越えた、以下のような組織の協力も得る必要が生じる。
- 業務部門や企画部門
- 品質管理部門 ( PMO )
この際に、上司の後ろ盾無しに部下に丸投げすると、結果的に業務部門や企画部門、品質管理部門 ( PMO ) の理解を得るために従来開発に近い形でアジャイル開発や反復開発を行うようになりがちである。
3.3 従来手法のしがらみに囚われる
明らかかもしれないが、このステップには以下の2点の問題点がある。
- 既存の開発方法（要求などの文書化）をあまり変えないという方針
- 事業部門の担当者の負荷が増やさないという前提
「既存の開発方法をあまり変えない」ということ自身が常に悪いことだとは言い切れない。しかし、あまり変えないという方針により「従来手法とあまり変わらない結果」がもたらされる可能性がある。特に、要求や基本設計を作成するということはそれなりに時間を要する（＝スピードを落とす）ことであるとともに、要求の不確定性が少ないことを暗示しているかもしれない。
「既存の開発方法をあまり変えない」方針により、要求や基本設計に加えて詳細設計書など開発途上で作成する成果物を作成し、開発途上で要求変更があった度毎にそれらの成果物をすべて更新することにすると、開発実行時のオーバーヘッドが非常に大きくなる。
「事業部門の担当者の負荷を増やさない」ことは、そもそも開発対象のシステムの事業上の位置づけが低くてもよいことを暗示しているかもしれない。事業上の位置づけが高く、早期のリリースを望まれるシステムであれば、事業部門の担当者の負荷が高まることに対する理解が得られる可能性がある。
要求の変更に起因する成果物更新のオーバーヘッドを減らすため、アジャイル開発では開発途上で更新する開発成果物はなるべく最低限のものに絞り込むことが望ましい。さらに、反復（スプリント）毎に実行されるテストの負荷を削減し、品質を確保するために単体テストや受け入れテストなどの自動化を考えることが望ましい。
3.4 無難な開発対象を選ぶ
このステップには以下の問題がある。
- 要求が少し不確定な開発対象の提案
「既存の開発方法をあまり変えない」のと同様に「要求が少し不確定な開発対象」を開発した場合「従来手法でも開発できたのではないか」と受け取られる可能性がある。それ以上に、「要求が少し不確定な開発対象を提案する」のは「事業部門側が度を超えて要求を変更することで開発チームの負荷が高まる」のではないかとの恐れに基づくものである可能性がある。
「事業部門側が度を超えて要求を変更することで開発チームの負荷が高まる」ことを防ぐためには、事業部門に以下の2点を理解してもらう必要がある。
- 開発チームが一定期間に開発できる開発規模（ベロシティー）は一定である
- 個別の要求変更を行うことで当初想定していたリリース内容の一部を諦めることになる
また、時として事業部門の担当者が過大な期待を抱くこともある。そのような過大な期待を防止するためにも、最終的に得られるソフトウェアのスコープについての開発当初の見通しを明確に説明した方がよい。
3.5 経験者をあまり集められない
近年、アジャイル開発に取り組む企業が増えてくることでアジャイル開発の実践経験がある技術者に対する需要が高まっているが、供給が追い付いていない。そのため、開発メンバーの大半がアジャイル開発の実践経験がある技術者であるという状態になるのは困難かもしれない。開発メンバーの大半がアジャイル開発を未経験である場合は、最低限実践経験のあるスクラムマスターまたはアジャイル開発のコーチ（アジャイルコーチ）が支援しないと開発に失敗する可能性が高い。
そのような場合に、開発メンバーとなるアジャイル開発の未経験者についても未経験者の多くが以下のような条件に当てはまるとアジャイル開発を円滑に実行できなくなる。
- 今までの開発のやり方を変えることに抵抗がある
- 受け身で指示された作業しか行わない
そのため、少なくともこのような条件に当てはまらない開発メンバーを集めることが大事である。特に、開発メンバーが別の会社の社員の場合は、アジャイル開発で達成したい事業上の目標に対する共感がなかったり、前述した度を越した要求変更への恐れ等から従来の開発手法を変えることに対して消極的になることもある。それは、既存の開発と異なる方法で開発を進めた結果、開発がうまく進まなかった場合のしわ寄せが自分達に押しつけられるのではないかとの警戒からである。
スクラムをベースにしたアジャイル開発を適用する場合、アジャイル開発の未経験者に対しては以下のような最低限のトレーニングを実施することが望ましい。
- スクラムのトレーニング
- プロジェクトで使う技術プラクティスのトレーニング
これらのトレーニング後に、スクラムマスターを中心に開発メンバー全員で開発の作業のまとまりごとの完了基準について合意を取ることが望ましい。このような完了基準をスクラムでは「完了の定義」と呼ぶが、そのような「完了の定義」の例として以下のようなものがある。
- 反復（スプリント）の完了の定義
- リリースの完了の定義
注：完了の定義
スクラムガイドの日本語版では、「完成の定義」という訳語が用いられている。
この完了の定義において、反復（スプリント）で開発したコードに対してどのようなテストを実施するかということや、リリースに必要なテストやその他の作業を明示する。
さらに、大規模な開発では最低限以下のような体制を整えることが望ましい。
- スクラムで安定的に開発できるチーム
- 複数チームを統括する上位のプロダクトオーナーやスクラムマスター
- 複数チーム間のアーキテクチャー的な一貫性やUXの統一を確保することを支援するアーキテクトや UX の専門家
3.6 不十分な理解と支援、高いオーバーヘッドの下で開発を行う
開発の実行段階では、以下のような様々な問題が発生しうる。
- アジャイル開発の理解不足
- プロダクトオーナーやスクラムマスターが従来のPM的な観点でスプリント計画はPMが計画を説明する場だと位置づけてスプリント計画を実行したり、デイリースクラムや振り返りは時間の無駄だと考えて省略する
- プロダクトオーナーの関与とコミュニケーション不足
- プロダクトオーナーの開発への関与が少ない
- 疑問に回答しない
- 動くソフトを確認しない
- 開発チームがプロダクトオーナーに確認せずに自分らで勝手に仕様を決める
- プロダクトオーナーの開発への関与が少ない
- 開発チームが物理的に分散している
- 開発チームが分散していてメンバー間で直接的がコミュニケーションを取りづらい
- 設備が不十分
- 常時開発メンバーが見える場所にタスクボード、バーンダウンチャートなどを設置できない
- リスク管理が不十分
- アーキテクチャーなどの潜在的な技術リスクを開発の早い段階で動くコードで確認せずに開発を進めてしまう
- アジャイル流のガバナンスの欠如
- 計画を立てない、見積もりをしない、計画と実績を対比しない
- 時間枠を守らない
- スプリントの振り返りに基づく改善を行わない
アジャイル（反復）開発を初めて実践するメンバーが多い場合には、最初の数回のスプリント（反復）が計画通りに進捗しないことも多い。そのような場合に、「計画通りに進捗しない」ことを短兵急に問題にするのではなく、それらのスプリント（反復）で振り返りが実践され、そこで何らかの具体的で実行可能な改善策が得られるかを見守った方がよい。具体的で実行可能な改善策が得られれば、それらが次のスプリント（反復）で効果を表すかどうかを見守った方がよい。
これらの問題の多くは、経験のあるスクラムマスターまたはアジャイルコーチが開発チームに割り当てられることで解決できる可能性がある。しかし、例えばプロダクトオーナーとのコミュニケーションの問題の解決には開発チームの所属とプロダクトオーナーの所属の両方に影響力があるようなシニアな管理職の支援がさらに必要になる可能性がある。
また、「従来手法のしがらみに囚われる」の節に記したことの繰り返しになるが、「開発途上で要求変更があるたびにそれらの成果物をすべて更新する」ことを求めると、その作業負荷のために開発チームの生産性が従来手法よりも低下する危険性が高まることに気をつけるべきである。
4. まとめ
アジャイル開発を用いて従来の開発を用いた場合と異なる結果を得ようとするならば、以下のように開発を進める必要がある。
もっとも大事なことは、事業部門と開発部門の両方に対して影響力がある立場の人が利点と難しさの両面でアジャイル開発を理解し、アジャイル開発を適用する事業上の狙いを明確にすることである。さらに、アジャイル開発を適用する事業上の必然性があるならば、その人がアジャイル開発の推進者を任命し、その推進役が関係する所属との調整を行う際に必要な支援を提供することである。
また、アジャイル開発を適用する方針が定まったら、アジャイル開発の推進者は社内の関係者がアジャイル開発を正しく理解するように支援する必要がある。さらに、プロダクトオーナーや開発メンバーにはアジャイル開発の実践に関するトレーニングを提供するとともに、経験のあるスクラムマスターやアジャイルコーチを割り当てる必要がある。
本記事を読まれて、アンチパターンや多くの落とし穴があるためアジャイル開発の実践は一筋縄ではいかず、難しいとの印象を持たれた方も多いかもしれない。しかし、 [1] の事例を紹介している第 3 章を読まれると、それらの事例の多くでここで挙げているようなアンチパターンや多くの落とし穴を巧みに回避していることが分かると思う。これらの事例でアンチパターンや多くの落とし穴を回避できたのは、アジャイル開発を適用する事業上の狙いが明確で、アジャイル開発の推進者が適切に任命され、十分な支援が得られたことに負うところも大きいと考えられる。これらがアジャイル開発を活かすための要点なのである。
第 1 回の終わりに
本記事では日本の企業でアジャイル開発を行う際のアンチパターンを説明した。次回の記事では、アジャイル開発と反復開発の投資効果をどのように考えればよいかについて論ずる予定である。
参考文献
[1] エンタープライズアジャイル勉強会 , エンタープライズアジャイルの可能性と実現への提言～アンチパターンとその克服事例～, インプレス R&D, 2016