アジャイルを成功させるために理解しておきたい本質

私は、アジャイルが大好きです。

ありがたいことに様々なアジャイルプロジェクトに参加させていただいていますが、うまく機能しているアジャイルプロジェクトの一体感・躍動感を一度味わってしまうと、忘れることができません。こういったプロジェクトに参加しているメンバーは「必ず成果を出す！」という、自信とやる気に満ち溢れています。そして、実際に成果を出し続けることで、関係者からの信頼を得ています。

一方で、機能していないアジャイルプロジェクトが多くあるのも事実です。右往左往する方針、一向に出てこないアウトプット、多発する品質問題、疲れ切った関係者の表情。メンバーは口をそろえて「もう二度とアジャイルなんてやりたくない」と言います。

また、アジャイルを経験したことのない方に、「アジャイルはスピード偏重で、品質を犠牲にした無責任な開発スタイルだ」と言われることも少なくありません。

私は、アジャイルが誤解され、嫌われてしまうことを極めて残念に思っています。アジャイルが誤解されてしまう原因は何なのでしょうか。

私は、現場での経験やお客様との議論を通じて、こういった誤解のほとんどは「アジャイルの本質が正しく理解されていないことが原因」であることに気づきました。言い換えれば、アジャイルプロジェクトを機能させるためには、関係者全員がその本質を正しく理解する必要がある、ということです。

関係者は、開発部門だけではありません。実際にサービスを利用する業務部門の方も関与しますし、プロジェクトによってはより多くの関係者、いわゆるステークホルダーがいることでしょう。開発者だけが努力しても、アジャイルプロジェクトは機能しないのです。

この記事は、私が考えるアジャイルの本質について、関係者全員、つまりエンジニアでない方にもご理解いただけるよう意識して執筆しました。この記事が、アジャイルへの理解を深めていただくきっかけとなることを祈っています。

この記事では、アジャイルの目的、アジャイルを成功させるための考え方を中心にお伝えします。アジャイルの進め方や、技術的な要素については触れていません。アジャイルの具体的な進め方を知りたい、技術的な要素を知りたい、という方に向けた記事は、今後執筆していく予定です。

はじめにお伝えしますが、アジャイルの目的は、サービス開発のスピードを向上させるためでも、コストを削減するためでもありません。ましてや、エンジニアが楽しく、心地よく働ける環境を作るためのいわゆる”働き方改革”でもありません。アジャイルを実践した結果として、サービス開発のスピードが飛躍的に上がり、コストが大幅に下がり、エンジニアがイキイキと働いているプロジェクトが多いことは事実ですが、それはあくまで結果の話です。

では、アジャイルの目的とは何でしょうか？

私は、企業にとってのアウトカム（成果）を創出することだと考えています。以降で詳しくご説明します。

通常、事業の流れは以下 ^* のようになっています。何かしらのインプット（投入）をもとにしてアクティビティ（活動）を起こし、生み出されたアウトプット（結果）を市場に投入することで、アウトカム（成果）を得る、という流れです。

これはサービス開発においても同様で、与えられたリソース（インプット）を使って、サービスを開発（アクティビティ）し、できあがったサービス（アウトプット）を利用して、企業としてのアウトカム（成果）を得る、という流れです。

オンラインショッピングサイトを例にあげてみましょう。この場合、アウトカムとしては、「売上を伸ばして事業を維持・拡大すること」や、「新規会員登録者数を伸ばすことで企業認知度を向上させ、新たなチャネルを開拓すること」などが考えられます。そのアウトカムを得るためにリソースが割り当てられ、そのリソースを活用してサービスを開発し、完成したサービスを市場に投入する、というイメージです。

この流れにおいて、事業やサービス開発が成功したかどうかは、求めていたアウトカムが得られたか否かによって判断するはずです。アクティビティが効率化されているか、アウトプットがどの程度生み出されたかよりも、アウトカムがどれだけ得られたか、のほうが遥かに重要です。

アジャイルは、このアウトカムを創出することが目的です。アクティビティを効率化することも、それによってアウトプットを増やすことも、アウトカムを創出するための要素のひとつに過ぎません。極端なことを言えば、開発スピードが遅くても、アウトプット量が少なくても、求めていた以上のアウトカムをすばやく創出できているのであれば、それは紛れもなくアジャイルである、と私は考えています。

アジャイルを実践するときには、アウトカムを創出するという目的を絶対に忘れないでください。そして、困ったときには目的を達成するためにはどうすべきか、を考えてみてください。

アジャイルの目的がアウトカムの創出と聞いて、「基幹システムを例にした場合、想像ができない」とご質問をいただくケースがあります。ここでは、アジャイルを適用すべき領域について説明します。

以下の図は、Cynefin framework ^* と呼ばれるもので、実世界の状況・問題を４つの領域に分類するフレームワークです。

明白な領域は、原因と結果の関係が明白で、いわゆるマニュアル的な対応が可能な領域です。事象を分類して、既に存在するベストプラクティスを適用すれば答えにたどり着ける領域、と言い換えることもできます。ローンの貸付を例にとってみましょう。「年収がＸＸ万円以上であれば、ＸＸ万円までの貸付が可能」や「年収ＸＸ万円以上で、既にＸＸ万円以上の借入をしている場合、それ以上の貸付は不可」といった具合に、事象を分類してマニュアル通りに対応すれば、答えを導き出すことができます。

次に、込み入った領域です。これは、専門家が分析すれば原因と結果の関係を把握することができ、適切な対処を行うことができる領域です。明白な領域のような唯一解（ベストプラクティス）は存在しませんが、有効な選択肢（グッドプラクティス）が既に存在している領域と言えます。専門家が事象を分析したうえで、有効な選択肢の中から最適なものを選んでいきます。例としては、ソフトウェアのバグへの対応があげられます。発生した問題に対して、ソフトウェアの開発者が原因を分析し、いくつかある対応策、いわゆるグッドプラクティスの中から最適なものを選択して適用する、という流れです。

ここでお伝えしたいのは、明白な領域と込み入った領域は、考えれば答えにたどり着ける領域である、ということです。難易度の差はありますが、正解が存在しているので、じっくりと考えることに意味があります。

次に、複雑な領域です。この領域は、簡単に言ってしまえば、試してみなければわからない領域です。顧客接点増加の施策、新事業の創出などはここに該当します。この領域に属するものは、実際に市場に投入してフィードバックを得るまでは、成功したかどうかがわかりません。複雑な領域は、明白な領域や込み入った領域と異なり、考えても答えがない領域と言えます。つまり、じっくりと考えることよりも、スモール・クイックに仮説検証を繰り返すことのほうが重要な領域です。

もうお分かりかもしれませんが、アジャイルがもっとも効果を発揮するのは複雑な領域です。一方、明白な領域と込み入った領域は、じっくり考えれば答えを出せる領域なので、ウォーターフォールに適している、と言えるでしょう。

この記事を理解していただくためには、ひとまず以下の内容を覚えておいてください。

・アジャイルは、試してみなければわからない、複雑な領域に適している
・複雑な領域は顧客接点の増加や新事業の創出など、アウトカムを求めて行われる事業が属している
・基幹システムのほとんどは明白な領域、込み入った領域に属している
・それらの領域は、ウォーターフォールが適している

都合上、カオスな領域の説明は省略しています。ご興味のある方は、Wikipedia（https://en.wikipedia.org/wiki/Cynefin_framework ）をご覧ください。

ここでは、アジャイルのプロセスフレームワークであるScrum ^* の用語を使います。Scrumに関する基礎的な知識がなくイメージが付かない場合には、読み飛ばして頂いて構いません。

なぜ先ほどアジャイルの目的を説明したのか。それは、これからアジャイルを実践される方であっても、既に実践されている方であっても、お持ちの疑問のほとんどは、アジャイルの目的さえ意識すれば自分たちで答えを出せるようになるからです。例をあげて説明します。

「業務部門の方は忙しく、プロダクトオーナーを任命してもらうことができない。代理プロダクトオーナーを設けてはいけないのか？」という質問をよくいただきます。模範的な回答はインターネットの記事に譲るとして、ここでは考え方をお伝えしたいと思います。

まず、プロダクトオーナーについて簡単に整理します。プロダクトオーナーは、プロダクトバックログの順番を決定する権限を持っている唯一のロールで、プロダクトの結果責任を負っています。また、スプリントレビューでは、参加者であるステークホルダーに対して、「どういうコンセプトでプロダクトバックログを投じて、このスプリントで何が完成して、次にどのような姿を目指していくか」、といったビジョンを説明する責任も持っています。そして、スプリントレビューで得たフィードバックや、市場の反応をもとに、プロダクトバックログをメンテナンスしていくのも、プロダクトオーナーの責任です。

ここまでの説明で、プロダクトがアウトカムを創出できるかどうかは、プロダクトオーナーの手腕に大きく依存していることがお分かりいただけるかと思います。

質問に対する回答に戻ります。ここでもう一度、アウトカムを創出するというアジャイルの目的を思い出してください。

代理のプロダクトオーナーを立てた場合、前述したプロダクトオーナーのロールを全うし、アウトカムを創出できるでしょうか？もし、代理のプロダクトオーナーがプロダクトのビジョンを理解し、実装すべき機能・実装しない機能、それらの優先順位を判断する権限を持っており、さらにはプロダクトの結果責任を負える立場であるなら、代理プロダクトオーナーを立てても問題ないでしょう。しかし、ほとんどの場合、これらの条件を満たすことは極めて困難です。

そうであれば、質問に対する答えは「代理プロダクトオーナーは立ててはいけない。なぜならアウトカムを創出できないから」となります。

いずれにしても、アウトカムを創出するためには、関係者全員にプロダクトオーナーの重要性を根気強く説明し、理解してもらったうえで、どういったスキームでプロジェクトを進めればアウトカムが最大化できるか？を議論していく必要があります。場合によっては、アジャイルの採用を見送ったほうが良いこともあるでしょう。

いかがだったでしょうか？企業やプロジェクトによって置かれている状況は異なるため、唯一解は存在しません。ただ、アウトカムを創出するという目的を意識しながら、自分たちが置かれている状況を整理することで、答えは自分たちで見つけることができる、と私は考えています。

アジャイルの目的は、企業にとってのアウトカムを創出することだとお伝えしました。

ただ、実際にサービスを開発する際には、直接的なアウトカム以外にも、市場投入までのスピード・品質・可用性・セキュリティなど、考えなければならない要素が数多く存在します。また、利用できるリソースも異なるでしょう。すべての要素で100点が取れれば良いですが、現実的には不可能です。コンテクスト（置かれている状況や背景）が大きく異なる中で、どうすればアウトカムを最大化できるのでしょうか？

私は、「サービスのコンテクストを整理したうえで、各要素のバランスを調整し、最適解を導き出す活動」を、サービスをデザインする、と呼んでいます。ここでは、サービスをデザインすることについて説明していきます。

顧客との接点を増やすための情報発信サービスを例に考えてみましょう。このサービスは、登録してくれた会員に向けて自社製品の情報を発信するサイトです。将来的には、公式オンラインショップとも連携させる予定です。

このサービスは、魅力的な情報発信をすることで、顧客に自社製品をアピールする機会を増やし、自社製品の売上向上に寄与するために開発します。アウトカムとしては以下のようなものがあげられるでしょう。

・情報発信サービスへの登録者数が10万人
・発信した情報へのアクセス数が1万
・発信情報をきっかけとしたオンラインショッピングサイトへのアクセス数が1,000
・オンラインショッピングでの購買数が100
※ アウトカムは必ず計測可能な指標を設定します。計測ができなければ、客観的な成否の判断ができないからです。


次に、その他のコンテクストを整理していきましょう。このサービスは情報発信による顧客接点の増加が目的なので、ミッションクリティカルなサービスと同等の可用性は不要です。それよりも、魅力的な情報を、頻繁に発信するほうが重要だと考えられます。また、顧客との接点となるサービスであることから、サービスのレスポンスやデザイン性、操作性も重視すべきです。ただ、このサービスによって本当に売上向上に寄与できるかは不明であるため、与えられた予算は限られています。

これまでの内容を整理してみましょう。

・このサービスは、顧客接点の増加を目的としており、明確なアウトカムが設定されている
・ミッションクリティカルなサービスと同等の可能性は不要
・魅力的な情報を、頻繁に発信したい
・レスポンスやデザイン性、操作性など、利用者からの評価に直結する部分を重視する
・利益につながるかは不明なため、スモールスタート、クイックスタートを前提とする

上記の内容は、ビジネス的なコンテクストが中心ですが、技術的なコンテクストも存在します。例えば、セキュリティ規約でパブリッククラウドを利用できない、統一されたプラットフォームが用意されていて利用するツールが定められている、などです。

コンテクストを構成する要素は、それぞれ独立しているわけではなく、トレードオフの関係にあります。

前述の通り、すべてにおいて100点を取ることはできませんから、限られたリソースで最大限のアウトカムを創出するためのバランス調整を行わなければなりません。

今回の例では、パブリッククラウド（PaaS*）を利用できると仮定しましょう。パブリッククラウドを利用することで、負荷に応じて柔軟にスケールするサービスを、スピーディに開発することができます。また、パブリッククラウドは従量課金であるためスモールスタートという方針にも合致しています。しかし、稼働率は99.95%程度となるので、月に22分程度はサービスが停止してしまうリスクがあります。今回のサービスではこの稼働率を許容できますが、プロダクトの特性によっては、スピードやインフラの柔軟性を犠牲にしてでも99.95%以上の可用性を担保したい、という場合もあるでしょう。こういったトレードオフを各要素間で行っていくことで、最適解を探っていきます。

* Platform as a Serviceの略称。AWS Elastic Beanstalk（https://aws.amazon.com/jp/elasticbeanstalk/）などを利用することで、負荷に応じて柔軟にスケールするプラットフォームを容易に手に入れることができ、サービスのリードタイムを大幅に短縮できます。

この最適解はサービスのコンテクストに依存するため、唯一解は存在しません。コンテクストを丁寧に整理したうえで、関係者と議論をして優先順位をつけながら、すべての要素のバランスがとれる着地点を探していく必要があります。

これが、サービスのコンテクストを理解したうえで最適解を探すことであり、サービスをデザインする、ということなのです。

サービスをデザインする、ということをより深く理解するために、Uber Technologiesの事例をご紹介します。

配車サービス Uberで有名な同社は2009年3月に設立され、たった10年で、非上場スタートアップとして世界最大級の時価総額を誇るまでに成長しました。2014年8月から開始されたUber eatsも、2020年2月時点で、日本を含めた45以上の国と地域、6,000以上の都市でサービスを提供しています。

Uberを使えば、以下のような流れで目的地にたどり着くことができます

言葉が通じなくても、あらかじめ料金が決まっているので、安心して乗車することができます。また、どんな国でも同一の操作で目的地に辿り着けるというのは、利用者にとって大きなメリットです。

ここで、Uberというサービスの中身に目を向けてみましょう。上記の例で使われている機能は、以下の４つです。

・利用者とドライバーのマッチング
・地図／位置情報
・クレジットカード決済
・ドライバー到着時のSMS通知

実は、Uberは利用者とドライバーのマッチング機能以外は、外部のサービスを利用しています。

配車アプリにおいて極めて重要な地図情報はGoogle Mapsを、決済はBraintreeを、ドライバー到着時のSMS通知はtwillioを、Eメールの送信はSendGridを、API経由で利用することでUberというサービスを実現しています。

こういった、複数のAPIを組み合わせて新しいサービスを生み出すことを、マッシュアップ・エコノミーと呼びます。Uberは外部サービスを賢く利用することで、限られたリソースで莫大なアウトカムを生み出しているのです。

もし、Uber Technologiesが、決済機能を自社で開発していたらどうなっていたでしょうか。アウトカムの創出に割くべき貴重なリソースの多くを、決済機能の開発・維持に投じていたことになります。きっと、非上場スタートアップとして世界最大級の時価総額を誇る企業にはなっていなかったでしょう。

この記事では、「アジャイルを成功させるために理解しておきたい本質」と題して、アジャイルの目的、サービスをデザインするという考え方についてお伝えしました。

再三お伝えしていますが、アジャイルの目的はアウトカムを創出することです。そして、アウトカムを創出するためには、コンテクストを丁寧に整理したうえで最適解を導き出す、サービスをデザインするという考え方が極めて重要です。

私は、「アジャイルの目的を理解したうえでサービスをデザインするという考え方」こそが、アジャイルの本質であると考えています。

アジャイルプロジェクトがうまく機能していないときには、この本質を思い出してください。

アウトカムを創出するためにはどうすべきか、アウトカムを創出するためにサービスをどうデザインするか。関係者全員が共通の目的に向かって議論すれば、きっと最適解が見つかるはずです。

また、アジャイルが無責任な開発スタイルになるかどうかも、サービスがデザインできているかに依存します。求められる品質レベルも、コンテクストのひとつです。つまり、コンテクストを構成する他の要素（例えばスピードやコスト）とのトレードオフになります。そして、求められた品質レベルを担保するためには、明確な品質保証戦略 ^* を用意しておかなければなりません。品質保証戦略も、サービスをデザインすることの一部なのです。

この本質を関係者全員が正しく理解できれば、冒頭にご説明した機能しているアジャイルプロジェクトを生み出すことができると確信しています。

いかがだったでしょうか？

私はもともとウォーターフォールの開発現場にいました。「もっとこうしたらいいのに」と漠然とした課題感を持っていた中で出合ったアジャイルは、どこかキラキラとしていて、抱えている課題をすべて解決してくれるのではないか？とワクワクしたことを覚えています。

しかし、アジャイルはすべてを解決してくれる魔法の杖ではありませんでした。スクラムで定義された通りにプロジェクトを進めているのに、一向にアウトカムが出ない。技術的な要素を突き詰めて開発プロセスを効率化したのに、アウトカムにつながらない。アジャイルの本質を理解するまでは、挑戦と失敗の連続でした。

スクラムガイド™には、以下のように書かれています。
～ 理解は容易だが、習得は困難 ～

アジャイルの素晴らしさについて、頭で理解することは簡単です。書籍やインターネットの記事を読めば、いくらでも知識を得られます。しかし、それらを頭で理解することと、実践してアウトカムを出せるようになることには大きなギャップがあります。

ただ、そのギャップを埋めた先には、きっと素晴らしい世界が待っているはずです。

弊社では、アジャイル開発スタートアップソリューション と題して、お客様の置かれた状況に応じた様々なサービスを提供しています。これからも、ひとつでも多くのアジャイルプロジェクトをご支援し、ひとつでも多くの成果を共創し、喜びを分かち合いたい。そう考えています。

最後までお付き合いいただき、ありがとうございました。

最後までご覧いただきありがとうございました。
本記事でご紹介した製品・サービスに関するコンテンツをご用意しています。また、この記事の他にも、IT技術情報に関する執筆記事を多数公開しておりますのでぜひご覧ください。