今の時代に増えている「いきなり大きく始める」開発　変化する“大規模アジャイル”のかたちにどう向き合うか？

過去と現在のITプロダクトの前提の違い

朱峰錦司氏：主題の1つである「大規模」についてお話しします。スライドにチャートを貼りました。私見ではありますが、アジャイルという開発の文化はわりと小規模なWebプロダクトだったり、モバイルというアーキテクチャの拡大が伴ったものだったり、そういった製品ドメインから、小さなチームで素早くやるところから始まったものととらえています。しかし、今ではどこもスケールの課題にぶち当たりつつあると考えています。

（スライドを示し）こちらは2021年版の『State of Agile』です。1年に1回、アジャイルに関するリサーチをしている会社があって、ちょっと古くて申し訳ありませんが、そこのデータを引用しています。

このリサーチに回答したアジャイル実践企業のうち、4分の3は何かしらのかたちで自分たちのチームが2チーム以上となっています。もしかしたら、3チーム、4チーム、10チーム、100チームかもしれません。とにかく、スケールするかたちでプロダクトを作っています。スケールしたチームが必要な規模でプロダクトを作っていることが見て取れると思います。

（スライドを示し）このスライドは私見です。あまりこのようなかたちのスライドは見たことがないので、自分の中ではオリジナルだと思っています。このような分類は他では見たことがないのではないでしょうか。アジャイルチームがスケールするかたちは2つあると思っていて、それをスライドで左右に並べています。

1つ目は、小さく始めた人たちが結果的にプロダクトがヒットしてスケールした場合。これはハッピーケースだと思います。いろいろな人がプロダクトを使ってくれて、プロダクトの規模がどんどん大きくなって、ラインナップが多くなって、Web版、モバイル版、iOS版、Android版と、バリエーションが増えて。さすがに1チームではやりきれなくなって、少しずつチームが大きくなっていったパターンですね。こういったパターンがあると思います。

一方、私もイベントの紹介文に書きましたが、今のITプロダクトはそもそもアーキテクチャが最初から巨大なのです。

それこそ、コネクテッドカーがいい例です。後半でも車の事例を何回か出していこうと思っていますが、そもそも車というどでかいハードウェアがあって、その上に車の制御ソフトがあって、それがクラウドとつながって、最終的にモバイルとつながる。到底1チームで作れるわけがないそのようなプロダクトを、素早くローンチしていく必要があります。

特にWebのユーザーのチャネルに近くなればなるほど、そういった領域のスピード感が求められる、非常にタフな時代になっています。

あとは決済系のアプリです。おそらくみなさんの手元のスマートフォンにも「ナントカPay」が入っていると想像します。こういった決済系のプロダクトは、最終的には日本の中枢にある何かしらの決済システムにつながっています。

なので、1チームですべてをまかなえる物では到底なく、社外のいろいろなシステムとつながっていて、最終的に価値を届けることができるものなのです。自分たちの会社で完結しないプロダクトがいっぱいあって、そのようなシステムは手軽に・気軽にいつでもテストできるわけがないので、いろいろな工夫が必要になってきます。

いずれにせよ、大規模なアジャイルのもう1つのスタイルとして、最初から大規模前提のものをスピーディに作らなければならない。こういったケースが最近増えていると思っています。

最初から大きいものを作るつもりなのだから、最初から大きなチームを組むしかないわけです。いきなり大きく始めることも、今の時代に求められている1つのかたちなのだと思います。

（スライドを示し）この左と右、どちらがいいかという話ではなく、単純に文化が違って、扱っているものが違うというだけの話なのです。

「大規模前提のものをスピーディに作る」が増えた背景

（スライドを示し）特に、後者のパターンは昔はなかったのですが、最近増えてきました。それにはいろいろな事情があります。世の中のニーズが高まっているという話があれば、そもそも技術的にできなかったことが技術的にできるようになってきているという話もあります。技術が大規模アジャイルを加速させている、後押ししていると私は考えています。

例えば、サーバーシステムにおいてはマイクロサービスアーキテクチャです。ふだん、業務系のシステムやエンタープライズ系のシステム、Web系のシステムを扱っている人はおそらく一度は聞いたことがあると思います。

昔のシステムはいわゆる一枚岩で、モノリシックと呼ばれます。1個のどでかいアプリケーションがあって、その中がサブシステムとされています。DBもでかいのが1個ある時代から、アプリをとにかく細切れにして、それぞれ独立して作るかたちになっています。1つのアプリを1つのチームにあてがって、複数のチームがそれぞれの守備範囲で活躍します。

しかし、それぞれが好き勝手にするわけにはいかないので、インターフェースはしっかり気をつけて切って、インターフェースを崩さないように開発していきます。なるべく俊敏に、機能追加が少しでも早くできるように、チームのあり方とアーキテクチャのあり方を連動させていきます。こういったアーキテクチャの変遷が見られます。

これを支えるためには、Kubernetesのようなどでかい物理サーバーにドカンとアプリケーションをデプロイするのではありません。OSの上にコンテナと呼ばれる小さなアプリケーション実行空間を細かく区切って、それぞれの上で軽いアプリを一つひとつ動かせるようにします。

そういった基盤技術・アーキテクチャ技術によって、例えばエンタープライズシステムとWebシステムはアジリティが上がりました。

そしてもっと話を進めると、組み込みソフトウェアですらアップデートできるようになりました。これまで語られてきた組み込み製品とWeb製品の大きな違いの1つに、「組み込み製品は出したらもう終わりなのだ」というものがありました。「お客さまの手元に届いたらその先はもうアップデートできないのだから、しっかり品質保証しなきゃね」という論説がありました。

その考え方自体は今も崩れていませんが、組み込み製品でもインターネットを経由してソフトウェアアップデートすることは、もう何年も前から技術として確立されています。いわゆるOTAですね。On The Airと呼んだり、アップデート対象がファームウェアであることが多いので、頭にFを付けてFOTA、フォタと呼んだりします。

こういったアップデート技術が、いわゆる運用技術です。運用技術が進化したことによって、組み込みの製品であっても、後から機能を増やすことができるようになりました。

これは有名な話ですが、アメリカで非常に大きな竜巻か何かの災害が起きた時、テスラがリアルタイムでリミッターを外したことがありました。その地域にいる人はもっとスピードが出せるようになって避難行動につながった。このあたりが今の時代だと思います。

大規模アジャイルにどう向き合っていくのか

今までのは技術の話でしたが、一方で大規模アジャイルにどう向き合っていくのかについて取り上げます。1チームでスクラムをやっていた話とは違ってくるので、大規模アジャイルには大規模アジャイルならではの方法論・フレームワークがいろいろ存在します。これも何が良い・悪いではなく、世の中にいろいろあるので、いろいろチャレンジしていけばいいと思います。

（スライドを示し）私見で代表的なものを2つ持ってきました。左と右に並べているのは、先ほど紹介したちょっとずつ育ってきたチームのパターンと、最初から大きいものを作るチームのパターンの対比です。

前者のちょっとずつ育ってきたパターンの人たちにとっては、基本的にはなるべく文化を変えずに、今までのフラットな構造を維持するほうが仕事がしやすいと思います。例えばLeSSがあります。

一方で、エンタープライズ企業が大きなものを作るためには、またちょっと違ったアプローチが必要になってきます。それに向いているものとして、例えばSAFeがあります。これはScaled Agile Frameworkの略です。

とはいっても、組織の階層構造をやたらに作ると、やはりアジリティが下がってしまいます。必要最低限の階層構造を仮想的に作って、既存の組織にマッピングしていくことがノウハウといえます。

あと、意外と重要なのが経営の巻き込みです。そもそも経営の考え方が変わらなければ、具体的には予算の当てがい方が変わらなければアジャイルになれないことにちゃんと言及しているのが、SAFeの1つの価値だと私はとらえています。

要は計画経済なのです。既存の開発の考え方は、最初にしっかり見積もって、それだけの予算を取って、基本的にそれを超えないようにする。しかし、それはもうアジリティとは合いません。

1ヶ月に使えるバジェットを固定して帯で取る。予算の当てがい方の考え方から変えないと、エンタープライズ企業はアジャイルになれない。そういった非常に示唆に富んだ話をうまくフレームワークとして扱っていると思います。

SAFeを嫌いな人はけっこう多いですが、エンタープライズ企業が変わるためには有用な物だと私はとらえています。完全に私見ですが。

このように、大規模アジャイルにもいろいろなフレームワークがあります。知らなかった人は、取っかかりとして引き出しにいれておいてください。

（次回につづく）