『Learning Agile』（2015年）は、しばしば誤解される概念——アジャイル——についての、無駄を省いた実践的ガイドです。その誤解の理由は単純です。アジャイルは、組織が抱えるあらゆる問題に対する万能薬のように語られすぎているのです。長年アジャイルを実践してきたアンドリュー・ステルマンとジェニファー・グリーンは、そうは考えません。彼らにとってアジャイルは優れたツールですが、いつ、なぜ、どのように使うかを知る必要があります。その第一歩は、アジャイルの根底にある原則を理解することです。
この要約で得られるもの——アジャイル入門
顧客は、自分が何を欲しいか——あるいは何を必要としているか——を常にわかっているわけではありません。ヘンリー・フォードがかつて言ったように、もし人々に何が欲しいか尋ねていたら、「もっと速い馬」という答えが返ってきたでしょう。
もちろん、フォードは彼らに車を与えました。しかし、もしそうしなかったらどうなっていたでしょう。その要求を満たそうとするうちに、何年も無駄にしていたはずです。フォードの製品が市場に出る頃には、他の誰かが安くて信頼できる車をすでに売り始めていた可能性が高い。彼の製品は、投入時点で失敗作になっていたでしょう。
この要約で取り上げるのは車ではなく、ソフトウェア開発です。しかし、同じ問題を検討します。その問題は、次の一言に集約できます。「顧客が本当に欲しいものや必要なものを説明できなくても、価値ある製品をどう届けるか？」という問いです。
その答えのひとつが、アジャイルと呼ばれる一連の実践と原則です。この言葉を聞いたことがあるなら、おそらくスクラム、カンバン、XP、リーンといった関連概念にも触れたことがあるでしょう。往々にして、これらの方法論をアジャイルと一緒にすぐ議論したくなるものです。
『Learning Agile』の著者であるアンドリュー・ステルマンとジェニファー・グリーンは、それは本末転倒になりかねないと言います。そもそも、なぜあなたとあなたの組織がアジャイルを検討すべきなのか、つまり理由を示さないまま細部に入っても意味がありません。だからこの要約で行うのは、アジャイルの「なぜ」を探ることです。
そのために、ひとつのプロジェクトを最初から最後まで追いかけます。その過程で、アジャイルの原則がソフトウェア開発チームの効率と効果を高め、より良い製品を届けるのにどう役立つかを見ていきます。
優れたソフトウェアは、孤立した環境では設計できない
ちょっと電子書籍リーダーについて話しましょう。
人気の理由は一目瞭然です。端末自体は普通のペーパーバックほどの大きさなのに、何千冊もの本を収納できます。さらに良いのは、どのテキストも読者であるあなたに合わせて反応することです。文字を拡大したり、フォントを変えたり、本文と参照情報を行き来したりできます。ワンクリックで図書館やカタログにアクセスでき、もう一度クリックすれば、新しい本を端末に借りたりダウンロードしたりできます。
要するに、これは優れたソフトウェアです。設計が行き届いていて、便利で、直感的。すべての利害関係者を満足させます。読者は使いやすく、テキストが正確に表示されるため、著者にとっても重要です。書店や出版社が本を販売・配布するのにも役立ちます。
ただし、初期の電子書籍リーダーはこれらすべてを備えていたわけではありません。実際、ソフトウェアが現在の水準に達するまで10年以上の開発が必要でした。2000年代初頭、当時は何が電子書籍リーダーに価値をもたらすのか明確ではありませんでした。今それがわかるのは後知恵だからです。というわけで、ちょっとした思考実験をしてみましょう。
時間をさかのぼりましょう。真新しい携帯端末に電子書籍を表示するソフトウェアの開発を任されたと想像してください。私たちはこの課題にどう取り組むでしょうか。
実は、私たちは最悪の方法でやろうとしています。なぜなら、ここはソフトウェア開発の新しい方法を模索するような会社ではないからです。ここは昔ながらの組織で、指示を出すリーダーと、従うフォロワー——それが開発者である私たち——がいます。要するに、「アジャイル」という言葉が聞こえてくるような職場ではありません。では、どうなるか見てみましょう。
ハードウェアチームはすでに試作品を作っています。本を取り込むためのUSBポートと、操作しにくい小型キーボードを備えた、ぶ厚い黒いタブレットを想像してください。この端末に電子書籍を表示するソフトウェアを構築するのが私たちの仕事です。
私たちの会社は、プロジェクトにいわゆるウォーターフォール・プロセスを適用しています。これは、プロジェクトの作業を前倒しにするという意味です。すべての製品要件は最初に定義されます。先ほど言ったように、リーダーが導き、フォロワーが従います。上級管理職、出版社の代表、オンライン小売業者などのすべての利害関係者が集まり、計画を練ります。彼らは要件を概説し、それぞれの要望を満たす仕様書を作り上げます。設計から開発、テストに至るまでの他のすべての段階は、滝から水が下流へ流れるように、これらの決定から流れ出ていきます。
では、仕様書には何が書かれているのでしょう。一言で言えば、すべてです。この電子書籍リーダーは画期的なものになります。たくさんの機能を搭載。出版社向けに市場統計を収集します。読者が本を購入できるオンラインストアも備えます。著者は執筆中に自分の本をプレビューして編集できるようになります。そして、これらすべてが18か月で完成する予定です。
1年半、時間を早送りしましょう。これは思考実験なので現実的でなくてもよく、プロジェクトは期限内に完了したことにします。しかも、仕様書のすべての要件が実装され、テストされ、検証されています。みんな満足しています。
次に何が起きるかわかりますか？その端末は市場に出ます……しかし大失敗します。まったく売れません。
何が間違っていたのでしょう？
問題は、人々のニーズは静的なものではなく、時代とともに変化するということです。選べるのが馬だけなら、もっと速い馬が欲しくなるでしょう。しかし、どんなに速い馬でも、他のみんながすでに車を運転しているなら、ほとんど役に立ちません。同じように、18か月前に人々が必要としていたソフトウェアは、今必要なソフトウェアではありません。プロジェクトを始めてから、電子書籍の新しい業界標準が登場しました。小売業者は、標準化されていない私たちの形式を扱いたがりません——面倒すぎるのです。そのため、私たちの画期的な機能はどれもサポートされず、誰の役にも立ちません。
これは、価値のあまりないソフトウェアの開発に多くの時間とお金を無駄にしたことも意味します。では、どうすれば違う結果になっていたでしょうか。
不完全なソフトウェアを今日リリースすれば、明日はより良い最終製品にたどり着く
私たちが間違っていたのは、対応力がなかったことです。市場に届く前にすでに時代遅れになっていた計画を、18か月も閉じた環境で実行してきました。調整もなく、柔軟性もありませんでした。要するに、私たちのプロジェクトは反復的ではなかったのです。
反復的な設計プロセスは、孤立した環境では行われません。むしろ、製品をすばやく世に出し、できるだけ早く顧客の手に届けてフィードバックを集めます。そのフィードバックを改善の土台とし、改善版を再び顧客に送り——やはりできるだけ早く——新たなフィードバックをもらいます。そこからサイクルが再び始まります。そもそも「反復する」とは「繰り返し実行する」という意味です。
このフィードバックループは、アジャイル・プロセスの核心にあります。日常言語で使う「敏捷性」という言葉を考えてみてください。それは、素早く身軽に動き、環境に反応し、目の前のものに取り組む動き方を表します。たとえば敏捷なクライマーは、遭遇するすべての手がかりや足場に反応し、滑りや握り損ないを防ぐために素早く体勢を調整します。ソフトウェア設計におけるアジャイルも同じです。アジャイルチームは反復的プロセスを使い、遭遇したバグや混乱に対して素早く機敏に対応します。当初作ろうとしたソフトウェアとは違うものになるかもしれませんが、役に立たないものを作るよりはるかにましです。
ここにアジャイルの第一原則があります。次のように言い表せます。最高の優先順位は、価値あるソフトウェアを早期に、継続的に届けることで顧客を満足させることである。
では、この原則をもう少し詳しく分解してみましょう。
ソフトウェアは現実世界——不完全な人間の世界——でしか作れません。どんなに働き者のチームでも、重要な細部を見落とします。どんなに才能ある開発者でも、重要な要件を予測し損ねます。間違いを正す唯一の方法は、開発中のソフトウェアを実際に使うことになる顧客の手に渡すことです。開発者として、私たちは顧客のフィードバックに完全に依存しています。だからこそ、ソフトウェアを早期にリリースする必要があるのです。
ソフトウェアを早期にリリースすることは、完璧主義の解毒剤というだけでなく、顧客に価値を届けます。たとえバグだらけでも、今日ひとつの機能があれば、昨日はできなかったことができます。実際に製品を使うことで、顧客は自分のニーズを明確にできます。つまり、製品に何をしてほしいのか、より明確な考えを私たちに伝えられるようになります。そして一度このフィードバックループに入れば、実際にそのニーズを満たす最終製品の創造へと向かっているのです。
変化を受け入れるとは、正しい考え方を身につけること
さて、先ほどの問いへの答えはこうです。私たちがすべきだったのは、ソフトウェアを顧客の手に渡し、実際に使ってもらいフィードバックをもらうことでした。そうしていれば、問題に気づいて進路を変えることができたはずです。そうすれば、高価な失敗作の構築につぎ込んだ時間、労力、お金を節約できたでしょう。
もちろん、プロジェクトの途中で進路を変えるのは口で言うほど簡単ではありません。実際には、たいてい苦痛で不愉快な経験です。難しい決断をしてきて、何を作っているかもわかっている。顧客が何を期待しているかもわかっている。ワークフローも確立されています。順風満帆とはいきませんが、前進はしています。そこへ、プロジェクト外部の誰かが来て、これまでずっと間違った道を進んでいたと言います。計画も作業もすべて無駄だったと。引き返して最初からやり直せと言います。さらに悪いことに、進路変更を求める相手は、そもそもその道にあなたを乗せた張本人なのです！彼らはこれを作れと言い、半分まで作った今、別のことをしろと言う。士気をくじかれ、失礼だとさえ感じます。防御的になり、変更に抵抗したくなるのも無理はありません。
理解できる？もちろん。役に立つ？まったく。しかし重要な問いは、どうすればその感情を乗り越えられるかです。
それは考え方の問題であり、2つの部分があります。第1は、自分の前提を絶えず確認し、修正していなければ、価値あるソフトウェアを作るのは本当に難しいと認めることです。確かに、プロジェクトの途中で進路を変えるのはフラストレーションがたまりますが、プロジェクトの最後にガラクタを作っていたと気づくことに比べれば、はるかに気が楽です。
第2は視点についてで、ひとつのエクササイズの形を取ります。
これは必ずしも簡単なエクササイズではありません。冷静さと、あなたの一日を台無しにした相手に対して抱きたくなるよりも多くの共感が必要です。しかし、多くの気づきを与えてくれます。まず、自分に次の2つの問いを投げかけましょう。第1に、顧客は故意にあなたを間違った道へ導いたのか？おそらく違いますよね。第2に、自分がしくじってあなたの何か月もの作業を無駄にしたと気づいたとき、相手はどう感じたか？おそらく、かなり恥ずかしかったはずです。あなたのところへ来て自分の間違いを認めたくなかったでしょう。それでも来てくれたのは、良いことです。さらなる時間の無駄を省いてくれたのですから！期限が吹き飛んだのはあなただけではありません。クライアントのスケジュールも遅れています。相手の会社は、ニーズを満たすソフトウェアを作るために大金を投じています。このミスのせいで、プロジェクトは成果を出せていません。つまり、これは誰にとってもフラストレーションがたまる状況なのです。
突き詰めれば、あなたたちは二人とも難しい立場にいます。理論上、失敗を避けられる唯一の方法は、顧客の心を読むことです。逆に顧客は、未来を予測できなければなりません。理想の世界なら、両方ができるでしょう。しかし、ソフトウェアは理想の世界で作られるのではありません。テレパシーを持つ予言者と働くことにはならないのです。それを受け入れれば、ミスと、それに伴う変化はずっと扱いやすくなります。
反復的なプロセスが顧客との接点を保つ
では、最初の話に戻りましょう。ここまで見てきたアジャイルの原則は、問題を抱えた電子書籍リーダーのプロジェクトにどう役立つのでしょうか。プロジェクトをもう一度やり直して確かめてみましょう。
まず、あのリーダーがなぜ失敗したのかを振り返りましょう。競合する電子書籍リーダーが備えていた重要な機能——たとえば業界標準フォーマットへの対応——が欠けていました。ただし、この問題は予測も回避もできなかったことに注意してください。私たちのチームが作業を始めた時点では、業界標準は存在しなかったのです。だからこそ、作業が始まった後に判明することへのチームの対応力に重点を置く必要があります。
今回は、プロジェクトをアジャイルで進めます。大きな会議で要件と仕様を練り上げるところから始めますが、その計画に18か月間ずっと固執するわけではありません。代わりに、その1年半を1か月ごとのスプリント——先ほど述べたフィードバックループの1サイクル——に分割します。つまり、毎月フィードバックに応じて設計を更新していくのです。
もちろん、最初はテストできるものがほとんどありません。ですから第4スプリントまで早送りしましょう。プロジェクトマネージャー、チーム、利害関係者が集まると、開発者のひとりが電子書籍フォーマットの新しい業界標準が登場したと報告します。チームはこの新しい情報を次のスプリントに取り入れ、その標準フォーマットをサポートするライブラリを構築します。第6スプリントまでには、そのフォーマットをリーダーのユーザーインターフェースに組み込む準備が整います。
ご覧のように、各スプリントは、チームが構築しているソフトウェアのイテレーション、つまり各バージョンにおおむね対応します。では第11月——第11スプリント、第11イテレーション——に飛びましょう。現在は動作するビルドがあり、ハードウェアチームが作った試作品にロードできます。バグはありますが、実環境でのテストには十分で、それはまさにチームが望んでいることです。プロジェクトマネージャーが早期ユーザーに話を聞くと、ユーザーは新聞記事やPDFを自分の端末にメールで送れるようにしたいと考えていることがわかります。それがチームの次のスプリントの焦点になります。
ただし、このアプローチは新しい機能のテストと取り込みだけではありません。いくつかの機能は捨てることもできます。たとえば、オンラインストアは意味をなさないかもしれません。何しろ標準化された電子書籍フォーマットがあるので、独自のプラットフォームを作る必要はありません。これで時間が空き、他のより重要な機能に取り組めるので好都合です。
このバージョンのプロジェクトは、はるかにうまく終わる可能性が高いです。私たちは継続的に実環境テスト用のソフトウェアをリリースし、そのテストに応じてタイムリーに変更を加えてきました。ここでの大きな違いは、顧客やユーザーとの接点を持ち続けていることです。ウォーターフォール・プロセスを使っていたときは、プロジェクト要件が承認されると、これらの人々から完全に遮断されていました。しかし今回は、最終的な目的——現実のニーズを満たす価値ある、動作するソフトウェアを構築すること——を見失っていません。そしてそれこそが、アジャイルの「なぜ」なのです。
最終要約
ここまで、アンドリュー・ステルマンとジェニファー・グリーンによる『Learning Agile』の要約をお読みいただきました。
本書の重要なメッセージは次のとおりです。
アジャイルな働き方には多くの方法がありますが、どのアプローチも同じ中核原則に基づいています。第1は対応力です。アジャイル・プロセスはすべてフィードバックが中心です。作ったソフトウェアをテストするのにプロジェクトの終わりまで待たず、できるだけ早く世に出します。実環境でのテストは問題を早期に特定し、顧客がそのソフトウェアに何をしてほしいのかを明確にする助けとなります。第2の原則は？完璧な計画など存在しないということです。すべてのプロジェクトには、その場に応じた修正、変更、設計のやり直しが必要になります。しかしそれは良いことです。最高のソフトウェアはそうやって作られるのですから。
