そのアジャイル開発はうまくいくのか？

　ソフトウェア産業に、アジャイル開発という開発手法が登場してから、結構な年月が経っていますが、最近この言葉を目にすることが多くなってきました。DXの流行とも相まってソフトウェア業界以外でも注目され、アジャイルの概念は拡大されてソフトウェア開発だけの話ではなくなってきています。色々なところでアジャイル開発が取り入れられるようになりましたが、実際にやってみると、なかなかうまくいかないことの方が多いのではないでしょうか？

　今回は、アジャイル開発とは何を意味しているのかを改めて紐解き、どういう場合に有効に働き、どういう場合にうまくいかないのかを考えてみたいと思います。

アジャイル開発の成り立ち

ソフトウェア開発としてのアジャイル

　アジャイル開発は、顧客要求やビジネスの変動に迅速に追従することが難しく硬直化しやすいウォーターフォール型のソフトウェア開発での反省から、よりスピードや柔軟性を高めたソフトウェア開発手法として2000年台に登場しました。2001年にソフトウェア開発手法の専門家たちによってまとめられた「アジャイルソフトウェア開発宣言（Manifest for Agile Software Development）」では、「個人との対話」「動くソフトウェア」「顧客との協調」「変化への対応」からなる、アジャイル開発の４つの価値が示されています。

　アジャイル開発の手法にもいくつかありますが「スクラム」と呼ばれる手法が代表格で、これによるアジャイル開発の特徴は概ね以下のようになります。

• 全てを一度に開発するのではなく、小さい単位に分け、短いサイクルで計画・設計・実装・テスト・デプロイを行う。これを反復することにより、漸進的に開発範囲を増やしていく。
• ソフトウェアはこの反復ごとにユーザに提供され、得られたフィードバックを次のサイクル以降で反映する。
• 短いサイクルで迅速に開発を行うために、比較的小規模な「チーム」により開発を行う。コミュニケーション方法としてはチーム内での対面での会話を重視する。
• ドキュメントよりも実際に動くソフトウェアを見せることによって、関係者の共通理解を得ることを目指す

　この方法では少人数で開発を行うことになるので、作れるソフトウェアの量が限られるという制約があり、当初は規模の小さいソフトウェア開発にしか使えないものと目されてきました。しかし、ビジネス用の開発フレームワーク、ライブラリやSaaSによるサービスなどが整備されるにつれ、これらを組合わせてソフトウェアを開発できるようになりました。一人で実現できる規模は格段に大きくなり、ものによっては、昔は数十人がかりで作っていたソフトウェアを、今では一人で作ることも可能です。このようなソフトウェア技術の進化により、かなりの規模のソフトウェアを少人数で作れるようになったのも、アジャイル開発普及の要因の一つです。

ビジネスとしてのアジャイル

　素早く、柔軟に、企画と開発を一体で行うアジャイルの考え方は、ビジネスの手法としても取り入れられています。2011年にエリック・リースにより、シリコンバレーでの新事業、新製品をスタートアップする手法が書かれた「リーン・スタートアップ」が出版されました。リーン・スタートアップは、あらかじめ綿密な計画を立てるのではなく小さくスタートし、顧客の反応を見ながら方向を修正していくというやり方です。

• まず仮説を立てて、これが本当に合っているかを早い段階で検証する
• 検証するために、実際に最低限の製品であるMVP(minimum viable product)を作る。
• MVPに対する顧客からの反応を計測し、そこから得られた結果を製品にフィードバックするというサイクルを繰り返す。良い部分は取り込み、無駄な部分は削っていく
• このサイクルを繰り返しても、望む結果が得られない（顧客からの反応があまり良くない）場合は、方向転換（ピボット）する。最初に立てた仮説を見直し、修正する

　新規事業や新製品開発には失敗がつきものなので、いかに小さく失敗し、そこから学んで短期間で結果を出していくかという考え方です。リーン・スタートアップと、アジャイル開発は非常に近い概念のものです。近年の新製品・新事業はソフトウェアやサービスによるものがほとんどなため、リーン・スタートアップにおけるMVPをアジャイル手法で開発するなど、両者が融合した形が取られるようになってきています。リーン・スタートアップの一部にアジャイルが使われることになるのですが、「リーン」より「アジャイル」の方が有名な用語になっていることもあり、リーン・スタートアップもひっくるめて「アジャイル」と呼ばれていることも多いようです。

アジャイル開発はなぜ人気なのか？

　このような経緯で成り立ってきたアジャイル開発ですが、最近これに取り組む企業は増え、アジャイルを導入すること自体がある種の流行のようにもなっています。なぜアジャイル開発が人気を集めているのでしょうか？

現状に不満なソフトウェアエンジニア

　現場の優秀なソフトウェア開発者は、分業化され硬直化したこれまでのソフトウェア開発の状況にウンザリしています。ソフトウェアを作ったこともない人がSEとして仕様を決め、プログラムの制作側はそれに従って決められたものを淡々と作ります。打合わせの回数は多くて長いのに、ソフトウェアの仕様はなかなか決まらず、決まってもすぐ変更され余計な仕事が増えます。安い価格で雇われたプログラマーを投入して作ったソフトウェアの品質は悪く、障害への対応に多くの時間を取られてしまいます。

　アジャイル開発は、従来の開発手法の欠点を解消するシンプルで理にかなったソフトウェア開発方法ですので、現状に不満なソフトウェア開発者には、非常に魅力的に思えます。特に、自分で設計してコードも書ける、優秀でクリエイティブなソフトウェア開発者には理想的です。彼らは、全てを自分でコントロールしたいと思っており、技能に劣る他の人に任せるくらいなら、全てのコードを自分で書きたいと思っているからです。

新事業や新製品を開発したい上層部

　多くの会社の上層部は、VUCA時代と言われる中で従来の事業の継続が困難になる恐怖を感じており、新たな事業や製品の創出が必要だと考えています。少なくとも機関投資家からはそのようなプレッシャーを受けています。そんな訳で、どんな新事業ができるのかはわからないままに、手探りで何かを始めてみることになります。この際に拠り所となるものとして、スタートアップの方法論と目されているリーン・スタートアップやアジャイルに注目が集まり、期待されます。

　アジャイル開発が支持される理由は全く違うのですが、経営層と現場のソフトウェア開発現場の両方から支持されます。上からも下からも望まれているものに、中間層が抗うのはなかなか難しく、何らかの形でとりあえずアジャイル開発が導入されていることが多いように思います。

　しかし、実際には、全てのソフトウェア開発がアジャイルに置き換えられるわけではありませんし、アジャイルの手法を導入しただけで新事業ができる訳でもありません。やってはみたけれども、うまくいかないことの方が多いのではないでしょうか。

アジャイル開発がうまくいかない理由

　本当に重要で導入すべきなのは、不明確なものに対し仮説を立て、検証し、小さな失敗を繰り返しながら結果を出していくという、アジャイル開発の「考え方」です。しかし、実際は「考え方」ではなく「手法」にばかり目が行きがちです。手法だけを導入してもうまくはいきません。教科書的な手法がうまくいくためには、以下のような前提となる条件が必要だからです。

１. 使えるソフトウェア群が豊富にあること

　前に述べたように、アジャイル開発では少人数で短期間のサイクルの開発を行うことになります。全てのソフトウェアをスクラッチから作っていたのでは間に合わないので、ソフトウェアフレームワークやライブラリや、クラウドによるSaaSなどを駆使します。しかし、ソフトウェアの全ての分野に、このようなソフトウェア群がある訳ではありません。例えば組込みソフトの領域では、再利用できるフレームワークやライブラリは多くはなく、各種サービスやフレームワークが豊富なWebによるネットサービス用のソフトウェアの開発などとは状況が違います。このような分野では、アジャイルで開発できるものの規模はかなり小さくなってしまいます。

2.  ソフトウェア開発者に高い技術力が必要なこと

　アジャイル開発に求められる、変更がしやすく、小さな機能の単位で頻繁にリリースでき、ユーザ数の増加にも対応してスケールできるようなソフトウェアを設計するのは簡単なことではありません。使えるソフトウェア群を駆使して、ソフトウェアモジュール間の独立性が高く、疎結合、かつスケーラブルなアーキテクチャやデータの設計ができ、それを維持できる技術力が必要です。また、品質の確保と短期間開発を両立するために、回帰テストの自動化などのテスト技術も重要です。

3.  ステークホルダーとの距離が近いこと

　アジャイル開発では、短い期間での開発を繰り返し、それごとに顧客をはじめとしたステークホルダーに提供しフィードバックを得ることになります。作ったものを評価するステークホルダーとしては、顧客の代表者、製品企画者、プロダクトオーナー等が考えられ、このような人がアジャイル開発プロジェクトの近くで緊密にコミュニケーションが取れることが前提になります。ステークホルダーが開発プロジェクトのメンバーとなっているのが理想です。しかし、ほとんどの場合そうなりません。例えば、ソフトウェアを外部に請負発注で開発している場合は、ステークホルダーはユーザ側企業、開発チームはITベンダーに属しているため、そもそも組織構造的に無理があることも多いのです。

　4.   検証すべき仮説があること

　当たり前の話ですが、まず仮説がないと何も始まりません。例えば、新事業開発の場合であれば「こういうサービスに需要があるはずだ」という仮説、ソフトウェア開発であれば「この仕様ならユーザの要求を満足するはずだ」という仮説を立てることになります。しかし、この仮説を立てることができなかったり、立てた仮説が曖昧で検証のしようがなかったりすることにより、アジャイル開発まで行きつかないというのが良くある話です。信じ難いことに、検証すべき仮説がないままにアジャイル開発を始めてしまうというケースもあるようです。アジャイルに対する理解不足と「とにかく何かを始めなければならない」というプレッシャーがこのような不幸な失敗を生み出します。

今後のアジャイル開発

　とは言え、私は、アジャイル開発は今後ますます普及し発展していくだろうと思っています。考え方に対する理解が深まり、適用事例が増えるにつれて、色々な分野に合わせた手法が考えられていくようになると思っています。

　また、現時点では成立していない前提条件の問題も、そのうち解決していくだろうと考えています。今はそうでない分野でもソフトウェアのフレームワーク化やサービス化は進んでいくでしょう。これまでITシステムのユーザであった企業もソフトウェアエンジニアを自社に取り込むことになると予想しており、ステークホルダと開発チームの距離の問題も解消される方向になると思います。アジャイル開発ができるようなソフトウェアエンジニアへの需要が大きくなれば、待遇も含めた評価も上がり、優秀なエンジニアが増えるきっかけにもなることを期待しています。

　今後の話で興味深いのが「アジャイル開発はどこまで大規模・複雑なシステムに対応できるか」というテーマです。開発規模がさらに大きくなると、複数のアジャイル開発チームを同時並行で動かすことになるのですが、どういう単位でチームを組成し、連動させ、共通理解を形成していくのかなど、多くの問題が出てきます。この問題への取組みはすでに多数あるようですが、方法論が確立されるところには、まだ到達していないようです。今後どのように進化していくのか注目したいと思っています。

余談

　アジャイル開発の前提として「検証すべき仮説があること」と書きましたが、仮説を立てるのは結構難しい話です。特に新事業開発などで、０から１を産むような仮説の立案は簡単ではありません。仮説を見つけるための手法なんてあるのでしょうか？身も蓋もない言い方になりますが、仮説とは「単なる思いつきにそれっぽい理屈がついたもの」にすぎないのではないかと思います。このための手法とか方法論があるようには思えません。

　民泊仲介サービスのAirBnBのエピソードを紹介します。AirBnBの創業者は美大を卒業したデザイナーで、サンフランシスコに移り住んだもののルームシェアーの家賃を払うお金に困っていたそうです。ちょうどその時にサンフランシスコで国際デザインカンファレンスが行われ、近隣のホテルはみんな満室だったことから、カンファレンスの参加者に自分の家で朝食と宿泊を提供することを思いついたそうです。ここから「旅行者向けに一般の民家を貸し出すサービスは、旅行者にも部屋を有効活用したい人にも需要があるはずだ」という仮説が生まれています。

　このエピソードを見ても、思いつきは偶然であり、やはり方法論があるようには見えません。ただ、全く仕事とは関係ないことも含め世の中に興味を持っていることと、「こうなったらいいのになあ」とか「こんな物が欲しいなあ」という自分自身の願望の両方が揃うと、何かを偶然に思いつく可能性が高くなるのかもしれません。人の願望を考えるより、自分の願望から仮説を導き出す方がよっぽど簡単だと思いますので。