DASAアンバサダーが話すアジャイルとDevOpsの関係　今のソフトウェア作りは映画よりドラマ作りに似ている

DASAが位置づけているDevOpsの原則

長沢智治 氏（以下、長沢）：今日は「アジャイルとDevOps」の話をします。長沢です、よろしくお願いいたします。みなさん聞こえてますかね？

阿部 一也 氏（以下、阿部）：聞こえてます！

長沢：大丈夫ですね。よかったです！私は何者かと言うと話すと長くなるんですが、いろんな会社を渡り歩いて会社を作ってしまった人になります。今はアジャイルやDevOpsの支援とか働き方の支援とかと、あとはマーケティングですとかプレゼンテーションですね。これらを掛け合わせたかたちでお仕事をさせていただいています。

もし何かこの辺りでお困りのこととかありましたら、まずはお気軽にお声掛けいただけるとうれしいです。

あと、今回のテーマに関わるところではDevOps Agile Skills Association、DASAというオープンなグローバルな団体があります。今、日本にアンバサダーが3人おり、私はそのうちの1人です。

DASAが位置づけているDevOpsの原則は下に書いてある6つになります。今日もこれらに関連するお話をします。もしDASAに興味のある方はぜひこちらのURLからたどっていってください。

アジャイルとDevOps とは何か

最初にアジャイルやDevOpsの背景をお話をします。ちなみに事前のアンケートでもアジャイルとDevOpsに関しては知らないよという方がけっこういて、とくにDevOpsがそうですね。あとはアジャイルも知っているよという方はいるんですが使ったことがない、実践されていないという方が大半だという認識でいます。

ですので、今日はぜひアジャイルやDevOpsがなぜ必要なのか、そしてそれをもし必要だと思った場合には現場で「こういうのをやってみない？」と言えるようになってもらえればと思います。テーマとゴール設定として、テーマは非常に抽象度が高いです。先ほどまでの素晴らしいセッションをしていただいたような技術の細かい話とかは私からはいたしません。

先に言っておきますが、コードは1行も出てきません。初学者向け、そしてディープダイブはしないスタンスで今日はやります。ゴールは、まずはアジャイルやDevOpsを自分事にしてもらえれば。その上で今日聞いた話を明日とかに誰かと話してみたくなったら私としてはゴール達成です。

そもそもアジャイルとDevOpsなんですが、いつごろからそういった考え方とか提唱とかをされてきたかというのを時系列で出してみました。実はこういったムーブメントというのは20年前からあったんですよ。本来であればアジャイルが何かとかDevOpsって何という話は、話したら老害扱いされるぐらいでいいはずのものかなと思っています。

ただ、やっぱり時代背景とかが今まさにこういったアジャイルとかDevOpsとかを必要としているかたちになってきているので、言い方を変えるとやっと時代が追いついてきたというような感じなんですね。ちょっとその中身をこれから見ていきたいなと思います。

変化しない世界がテクノロジーによって変化する

ビジネス、サービス/アプリ、チームの３つ挙げますが、これらは今までは変化しない前提だったんですね。例えばビジネスモデルは、それがあった状態からITとかサービス化とかを考えますよね。

サービスやアプリというのは、そもそも作ってしまえばそのあと何年も使える、使ってもらえるものだという前提です。チームも、いったんチームを作ってモノを作るまでは必ずそこにいるし、誰でもアサインすればそれなりのパフォーマンスを発揮してくれると。それで仕事が終わればプロジェクト解散でまた新しいチームができる。そこでは最大のパフォーマンスを発揮してくれるものだと前提だったんですね。

ちょっとみなさん考えてほしいんですが、これら3つは変わらないものですよね。これがすべてかどうかはみなさんの状況によりけりなんですが、だいぶ変わってきてるかなと思います。ちょっと見ていきますね。

何が変えているのかというと、一番大きいのはテクノロジーです。いろいろなデバイスが出てきてクラウドも出てきて、その他いろんなものとかがどんどん出てくることによって何が変わっているかというとビジネスのモデルが変わってきているんですよね。

どこに一番影響があるのかというと、やっぱり一番は直接顧客にタッチできるようになったところだと考えています。今までだったら中間業者さん、仲介業者さんを介してコンシューマにアクセスをしていたり、お客さんにつないでもらっていたりしていたところが、直接ダイレクトにタッチができる。直接フィードバックがもらえるという土壌がテクノロジーで揃ったんですよね。言い方を変えると言い訳できなくなるんですよね。

そうなってくると当然ですけど、その情報のデータをもつ者ともたない者で差が出てしまいます。必然的に競争も激化していくかたちになってくるという感じですね。ですからテクノロジーにはビジネス自体と社会自体を変えていくちからがあるんですよね。

開発のやり方は今までと同じで大丈夫なのか

「テクノロジーとビジネスの不確実性」と題しましたが、ステイシーマトリクスという図はみなさん見たことがありますか？　ざっくり説明すると縦が合意の難しさ、横が技術などの不確実性の高さを示しています。こうやって見ていて、みなさんが今携わっていらっしゃるプロジェクトとかでどこのコンディションにいるのかというのを考えてみてください。

極論を言うとほぼ複雑と呼ばれる領域になります。要するに不確実性の出にくい、ビジネスモデルが不安定だったり要件が固まらないというものですね。そういったようなプロジェクトがやはり増えてきていると言われています。

そのあたりをざっくり10年区切りでいつも示して説明しているんですが、そうすると1990年から2020年までを見るとこんな感じで変わってきているのかなと。もちろんみなさんが携わっている現場がどこのポジションかというのは別に2000年とかだから古いとかそういう話ではなくて、一番大事なのは現場が今どこのポジションにいるのかをちゃんとわかっていることです。

90年代とか2000年代というのは既存の安定したビジネスモデルがあって、そこの中でITやソフトウェアをうまく使うというようなかたちになります。従ってIT部門とか開発部門が主導権を握れるということがけっこうあります。

それが2020年ぐらいになるとビジネスモデルも変わってくるし、先ほども言ったようなパラダイムシフトも起きてくる。テクノロジーのちからですね。経営陣だけでも意思決定ができず、マーケットの流れに乗っていないとビジネス自体が危なくなってしまうことがあるような時代に入ってきています。

そういうふうに見ていくと、みなさんで考えてほしいのが開発のやり方とか、あとは利害関係者との付き合い方といったところが今までと同じで大丈夫なのかどうかということですね。そこはぜひみなさんが現場で議論してほしいポイントになります。

もともと安定していなかったもの

続きまして、先ほどの変わらないものが変わるようになってきたと話をしたんですが、これが今まで安定していて変わらないものと言われていた代表例ですね。ビジネスモデルはさっき話しました。あとは顧客ですよね。今までこのビジネスモデルでしっかりやっていて、お客さんはこういう方々がいる。この人たちは裏切らない、他の会社さんに浮気をしないとかですね。

それが前提で組織が組まれて、この縦割り構造のしっかりとした盤石な組織ならばそれを保っていけるよねというのができてたんですよね。これが今揺らいでいるということです。

もう1つ気を付けなければいけないのは、とくにソフトウェアの場合はそもそももともと安定していないものが実はあるんですね。それがまずソフトウェアというもの自体です。これはビジネスにとっても開発も運用もそうですね。まだ出てきて半世紀ちょっとぐらいですよね。それぐらいなのでまだまだ他の業界というか他のものに比べると未成熟な分野になります。もちろん、それ以上にテクノロジーの進化がものすごく早すぎるので、やはりなかなか安定しないですよね。

あともちろんなんですが人由来のもの、人に関係するものですね。気持ちとか能力とスキルとか教育、こういったようなところはそう簡単に固まるものではないといったところがあります。

そういった中で大事なのが、今までは予測通りに行くだろうというある意味理想主義的な計画の仕方をしたり、組織の運営の仕方をしたりというのが多かったんですが、今はどちらかと言うと実証主義と言われるような、英語で言うとエンピリカルですね。

代表例で挙げると、ビジネスのところではリーンスタートアップに出てくるBMLというモデルです。アイデアをビルドしてプロダクトを作って、プロダクトからメジャーしてデータを作り、そこから学んでいくと。このサイクルを回していくというやり方ですね。仮説検証と言われているやり方です。

開発ではまさにアジャイルと言われているバリューアップの仕組みですね。これも同じく小さなサイクルで開発をして、その中で学んで開発のやり方を進めながら確立していく。もちろんプロダクトも進めながらいいものにしていくといわれる発想になります。ここで重要なキーワードが検査と適応ですね。これはアジャイルのプロセスの中のスクラムと呼ばれているものの柱にあたる概念になります。

今のソフトウェア作りは映画よりドラマ作りに似ている

その辺のところを考えていって、よく私が経営者の方々にお話するときにするのがこのスライドです。よく「何かのプロセスを入れましょう」とか、「やり方を変えましょう」、あとは「ツールやテクノロジーを導入しましょう」も、そうですよね。という話になると、「費用対効果はどうなの？」という話にだいたいなるんですよね。

みなさんはならないですか？　なりますよね？　反応が見えないですけど、きっとなりますよね。そういうことにしましょうか。

そのとき昔から、2000年ぐらいからよく「ソフトウェア作りは映画作りと一緒だよね」と、言われていました。日本だとけっこう建築のメタファーが多いんですけど、けっこう出るのは映画作りが多いですね。映画作りというのは、細かいところはみなさん想像した通りですので省略するとして、だいたい数年単位の非常に長いサイクルでいいものを作りますよね。

公開するか中止するか。もしくは公開したけどポシャるかみたいな話になります。ただ、映画はそのために莫大な予算と準備期間が用意されています。ソフトウェアもそういうものだと捉えられていたんですけど、今はなかなかそうではなく、どちらかというとビジネス自体もそうなんですがドラマに近い、連ドラですよね。

3ヶ月単位の1クールとかが用意されていて、1週間だったり2週間単位で見直しを掛けたり。視聴率によって変わるとかお客さんの意向によって変わるとか、どこまでやってるかわからないですけど、そういったことが起こったりしていると。どちらかというと持続可能にやる。その3ヶ月間の予算と準備期間でやりくりができるといったところですね。

今はちょっとコロナの事情もあって、いくつか延期になったりとか撮影が止まっていたりというのもあると思うんですが、今クールの4月から始まるドラマですら、もちろんですけど始まる時点で全部撮り終えているわけではないということですよね。ソフトウェア作りもそんなかたちに変わってきているところがあります。