現実世界のアジャイルソフトウェア開発：変化への対応と計画

この記事は、Michael Parkerの「Agile Software in the Real World: Responding vs Planning」を本人の許諾を得て日本語訳したものです。Michael ParkerはDocker, IncのSenior Software Engineerで、Docker HubやDocker Desktopなどのツールの開発に携わっています。日本語訳の誤りなど、お気づきの点があれば御連絡ください。

「アジャイルソフトウェア開発宣言」にある４行のうち、この記事では最後の１行に焦点をあてている。

計画に従うことよりも変化への対応―アジャイルソフトウェア開発宣言

計画しすぎないようにしよう

ソフトウェア開発プロジェクトの計画は難しいものだ。誰もが成功を確信したうえでプロジェクトを開始したいと考えている。しかし、どうすればプロジェクトの成功を予め確信できるだろうか。

顧客は本当にこの製品や機能を望んでいるだろうか。スケジュール通りに製品を開発できるだろうか。もっと詳細に計画すれば、製品の技術的複雑さを予測できるだろうか。開発が完了するまでに市場が変化してしまわないだろうか。

一部の企業では、プロジェクトを開始する前にこうした疑問のすべてに答えを探そうとする。こうした企業では、失敗する運命にあるプロジェクトに無駄な開発時間を充てることはしない。

どれくらい計画を実施すべきかはプロジェクトに依存するが、多くの企業ではその認識が無いようだ。

1. 開発チームが何かをリリースし、顧客からフィードバックを得るまでにかかる時間
2. 顧客や製品に関するフィードバックの量
3. 良くないプロダクトをリリースしてしまった場合の損害
4. 製品をリリースした後に顧客エンゲージメントを測定する方法

これらの条件はプロジェクトによって異なるが、多くの企業ではどのプロジェクトでも同じように計画してしまう。したがって、計画し過ぎのプロジェクトもあれば、計画が不十分なプロジェクトも存在するということだ。

計画することが良くない場合もあるのは何故か

計画は、MVP（Minimum Viable Product、実用最小限の製品）のリリースを遅らせてしまう。結果として、時機を逃し競合製品がシェアを奪ってしまう。（市場投入の遅延）

・計画は、実際に実装するまでは関係がないことの議論で時間を浪費してしまう可能性がある。

・計画は、実際に使ってみたユーザーからのフィードバックを遅らせてしまう。ユーザーからのフィードバックは、あれこれ推測するよりも重要だ。（早期にリリースし、頻繁にリリースする）

・計画は、サンクコストの問題を引き起こす。計画に時間を費やせば費やすほど、計画の変更または中止を会社に納得させるのは難しくなる。

・計画は、ビジネスをデータ駆動から逸らす。データに基づく意思決定では、ある機能を出荷したら必ずデータを確認する。ユーザーはその機能を意図したとおりに使っているだろうか。ユーザーはその機能を気に入ってくれただろうか。何か想像もしなかったような意見は出ていないだろうか。意思決定プロセスがプロジェクト開始前の計画に依存し過ぎていると、プロジェクトの途中での分析に割けるリソースは少なくなる。

計画することが良い場合もある

1. 市場調査は良いアイディアだ。競合製品を調査しなければ、他社と似たような製品を開発してしまうかもしれない。とはいえ、既に市場にあるような製品を開発しつつも、最終的には勝者になることもある。計画によってイノベーションが阻害されないように注意しなければならない。
2. 開発しようとしているシステムの概要をスケッチし、コンポーネントに肉付けするのが良いときもある。しかしながら、開発チームはプロジェクト開始の一環としてこの作業を自分たちで実施してしまうことがある。更に、できるだけ早くMVPを得ようとせずに、過剰に設計してしまう危険がある。12か月から18ヶ月に及ぶプロジェクトについて考えている場合には、追加のコンポーネントや抽象化レイヤーが必要だなと考えてしまいがちである。しかしこのような考え方は、アジャイルなソフトウェア開発では避けなければならない。
3. プロダクトによっては、マーケティングリリースや広告キャンペーンなどが必要になる場合がある。どのようなものがあるかは、あなたの会社や製品によって様々だろう。開発チームは、こうした部門と可能な限り切り離しておくことを推奨する。プロジェクトの開始前にスケジュールや締め切りに同意しないで済めれば、ソフトウェア開発をアジャイルに進めることが可能になる。プロジェクトが開始されたら、ベロシティとスコープに関する実際のデータをもとに、（直観ではなく）予測するのだ。次のように実験してみよう。プロジェクトがひどく間違った方向に進んでおり、考えていたより4倍かかるとしたら？あるいはプロジェクトが途中で放棄されたとしたら？どのようにビジネスを変化させたら良いだろうか。長期に渡るロードマップで部門間の結びつきを強固にして共同で物事を進めるよりも（これは絶対に失敗する）、もっと良い方法はいくつかあるだろう。

プロジェクトによってはアジャイルなソフトウェア開発が向いていない場合もある。こちらの記事も参照してほしい。：A Critical View of the Agile Manifesto（アジャイル宣言の批判的見解）

不確実性と変化を受け入れる

計画に費やす時間を減らそうと考えているなら、不確実性と変化を受け入れなければならない。これは、プロジェクトについて今日考えていることが、明日になれば完全に間違ったものになってしまう可能性があるという事を意味する。おそらく、どれだけたくさんの計画を立てていたとしても当てはまるだろう。

実際には、「不確実性を受け入れる」とは次のことを意味する。

1. ビジネスを非常に迅速に方向転換する準備ができていなければならない。プロジェクトの中盤に差し掛かったところで、誰かがより良いアイディアを思い付いたら、即座に適応してそのアイディアを実行しなければならない。すでにプロジェクトを開始しているからと言って、新たに出てきた、より良いアイディアを無視してはならない。「ちょっと待って、こうすればもっと簡単にできるんじゃない？」と思ったことがあるだろう。そのアイディアを実行しても「ああ、このプロジェクトは時間の無駄だったか」という気持ちにはならないようにしよう。代わりに「次にやるときは、すごいアイディアを知っているんだ！」と考えるようにしよう。
2. ビジネスを完全にキャンセル・中止する準備ができていなければならない。プロジェクトに関わる誰もが時間の無駄だとわかったときに、あなたはプロジェクトをキャンセルするだろうか、それともプロジェクトを継続するだろうか。アジャイルであろうとするならば、謙虚でなければならない。顧客が欲しいものは何一つわからないし、開発したものは時間の無駄に過ぎないかもしれない。顧客から得られたフィードバックこそが貴重な情報である。得られたフィードバックを踏まえて何をすべきだろうか。それまでと同じように続けるべきか、それとも変更すべきだろうか。真にアジャイルな企業でありたいのであれば、MVPを可能な限り早く出荷して、直ぐに次のことを確認する必要がある。MVPは成功しているだろうか？他にもっと良い方法があるだろうか？このプロジェクトはキャンセルすべきだろうか？計画を減らしてMVPを速く開発することができれば、プロジェクトを中断しなければならない場合でも無駄な費用を減らすことができる。
3. 製品の利用状況に関する情報収集にもっと投資しなければならない。MVPを出荷したら、顧客の利用状況を分析して次にやるべきことを判断したり、プロジェクトを中断すべきかどうかを検討したりしなければならない。事前に計画するという文化から、プロジェクトの途中でデータを分析して判断するという文化に切り替えるのである。
4. プロダクトオーナーやデザイナーは、もっと開発チームの近くで仕事をしなければならない。ウオーターフォール型開発の場合には、デザイナー／製品チームが設計書を作成する場合がある。彼らは、技術的リーダーシップを発揮して、行ったり来たりしながら実現可能で有用なものをなんとか設計しようとする。アジャイルなソフトウェア開発では、MVPをリリースしてから新たな方向転換をする際に、開発チームが新しい機能のデザインを必要とする場合がある。いくつかの会社では、部門横断的なチームを持ち、プロダクトオーナーとデザイナーを開発チームの中に組み込むことでこの問題を完全に受け入れている。

プロトタイプや技術的負債を抱えた製品を出荷してしまうことを受け入れる

素早く洗練されていないMVPを開発する上で危険なのは、低品質なコードや技術的負債を抱えている可能性があることだ。洗練されていないMVPは使い捨てされるものであり、長期的に安全で安定したものにするにはある程度の書き換えが必要になる場合があるが、開発チーム外の人間がこれを理解するのは難しい場合がある。

技術的負債は、顧客に向けてより迅速に製品をリリースするために、一般的には意図的かつ戦術的に取り除かれるべきだ。たとえば、プロジェクトを中止してすべてのコードを削除する可能性がある場合には、リリース前に完璧を目指して技術的負債の解消に時間を費やす価値は無いだろう。

ドキュメントによる指示を止める

情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。―アジャイル宣言の背後にある原則

事前の計画を重視すると、設計書を「壁の向こうにいる」開発チームに投げて渡すということに陥りがちだ。これは非常に遅くかつ非効率なコミュニケーションの取り方だ。ドキュメントのコメントか何かについて、電子メールを介して長期（数日もしくは数週間）に渡って議論した経験はないだろうか。

最悪の議論というものは、双方の当事者が他方の当事者の考え方をまったく理解せず、まったく異なる波長で話しているように見えるものだ。たとえば、ある人は低レベルの要件を望んでおり、またある人はプロジェクトが時間の無駄だと考えているような場合がある。早い段階から一緒に仕事し、プロジェクトを通して定期的に協力することで、こうした状況が発生するのを止めよう。

ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。―アジャイル宣言の背後にある原則

こうした議論は、対面で議論することでほとんどの場合は迅速に解決する。そして、こうした対面での議論は、プロジェクトの成功の基礎となる人間関係を構築してくれるものだ。

開発チームがプロジェクトを開始するために知っておくべきことは、設計書の中には書かれていないことが多い。そして、プロジェクトの途中で回答しなければならない質問は、ドキュメントで回答するには具体的過ぎることが多い。ゆえに、ドキュメントとはプロジェクトの開始時点では投機的過ぎるし、プロジェクト全体を通しては漠然とし過ぎていて古すぎるものなのである。

より良いアプローチは、対面でのキックオフミーティングで開始し、プロジェクトの期間全体を通して対面式のミーティングを頻繁に持つことだ。計画に従うのではなく、変化に対応しよう。

開発者をプロジェクトの初期から巻き込んで、モチベーションを高める

意欲に満ちた人々を集めてプロジェクトを構成します。最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。―アジャイル宣言の背後にある原則

開発チームのモチベーションを「下げる」のに良い方法がある。開発チームに大量の設計書を渡して、こう言うのだ。「これを開発して。では1年後に会おう」

成功する開発チームは、外部委託の「コーディング」チームのような仕事の仕方はしない。通常、成功する開発チームはプロジェクト計画に開始段階から関与し、コードだけでなくプロジェクト全体へのオーナーシップを感じているものだ。プロジェクトの最初の開発は、要件や技術的リスクを探索し、顧客がその製品を本当に必要としているかどうかを発見するものであるべきだ。

プロジェクトがいつ終わるかを推測しない

プロジェクトを開始した時点というのは、プロジェクトがいつ終わるかを推測するには最悪の時期である。なぜか。プロジェクトの開始時点では、分かっていることは最も少ないからだ。プロジェクトの開始時点では、何もデータは無いのだ。

例外：開発チームが過去に複数のプロジェクトを完遂させていて、これまでに開発チームが経験したプロジェクトとの類似点が十分にある場合は、過去のデータを使用して予測することはできるだろう。予測する上でのポイントは、(a)推測ではなくデータに基づくものであり、(b)日付ではなく日付範囲（〇日から〇日の間）であり、( c)日付範囲は十分に幅広くなければならず、プロジェクトの進行に伴って日付の幅は徐々に狭まってこなければならない。

当てずっぽうにプロジェクトが終わるのがいつになるかを推測するのではなく、数スプリント（だいたい４~６週間）経過後に得られたデータを使って予測レンジを計測する。そして定期的に予測を更新しよう。プロジェクト管理ツールを使っていれば自動化することができるだろう。

注意：プロジェクトのバックログには常に目を向けておこう。もしもタスクの完了よりもバックログの増加の方が早ければ、プロジェクトがいつ終わるかを予測することはできない。

もしも終了予定日がズルズルとずれていく場合には、立ち止まってプロジェクトを分析し、その理由について話し合おう。ベロシティが低下しているのだろうか。あまりに多くの技術的負債を抱えているのだろうか。それともスコープが増大しているのかもしれない。あるいは追加機能が多すぎるのかもしれない。

企業にとっては、スピードよりも予測可能性の方が重要な場合が多い。

注意：企業によって事情は異なる

ソフトウェアが関わる分野は広く、日々広がっている。すべての企業やプロジェクトがまったく同じプラクティスを使用する必要は無い。たとえば、資金の限られているスタートアップ企業では、資金が尽きてしまうまでに様々なプロダクトを素早く試すことに重点が置かれるだろう。一方、既存顧客の維持に重点を置いている成熟企業では、品質の低い製品や実験的な製品をリリースするには消極的だろう。

大規模なエンタープライズソフトウェアを構築している一部の企業では、顧客からのフィードバックを迅速に得られない場合がある。ソフトウェアを使い始めるのに2年以上もかかる場合、迅速なフィードバックを得るのは非常に困難だ。この場合、プロジェクト期間を通じて一緒に作業してもらう顧客に「スポンサー」として参加してもらうか、リモートユーザーテストやデモセッションを実施して、顧客に開発中のソフトウェアを使ってもらうように依頼すると良い。

アジャイルのプラクティスを単にコピーしてはいけない。「アジャイルソフトウェア開発宣言」が作成された理由を理解し、自らのビジネス（プロジェクト）に関連付け、調整できるようにしよう。どのくらい計画を立てるかはあなた次第だ。賢明に決定しよう！