この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。
第14回目のテーマは、リーンスタートアップとDevOpsを解説します。
この内容はUdemyで公開しているオンラインコース「現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム 入門編」の内容を元にしています。
＜あらためて学びたいアジャイル開発 連載一覧＞※クリックで開きます
第1回：アジャイル開発の過去、現在、未来を知ろう！
第2回：声に出して読みたいアジャイルマニフェスト
第3回：従来型開発とアジャイル開発の違い その１
第4回：従来型開発とアジャイル開発の違い その２
第5回：アジャイル開発のよくある誤解を解いていこう！
第6回：世界中で大人気の秘密に迫る！スクラムを使ったソフトウェア開発
第7回：わかるようでわかりにくいスクラムチームの責任
第8回：スクラムイベントの実践方法
第9回：エクストリーム・プログラミングとその価値
第10回：エクストリーム・プログラミングの原則と基礎プラクティス
第11回：エクストリーム・プログラミングの応用プラクティス
第12回：リーンソフトウェア開発
第13回：ソフトウェア開発における「かんばん」
第14回：さまざまな方法論 − リーンスタートアップ・DevOps
リーンスタートアップ
リーンスタートアップは、2011年にエリック・リースさんが考えた、主にスタートアップのための起業の開発手法です。アジャイル開発から派生した開発手法ですが、これまでの開発手法が開発寄りだったのに対し、事業やプロダクトよりの内容なので、ビジネス側の人間や起業家など、開発外の人たちに影響を与え、もう10年以上前になりますが、日本語訳がでたときは、とても話題になりました。
とくに、当時MITメディアラボの所長だった伊藤穰一氏がリーンスタートアップを、「地図を捨ててコンパスを頼りに進め」と例えているのも有名です。この言葉は、まさにアジャイル開発を表した言葉と言えます。
その名のとおり、リーン思考の影響をうけており、起業して開発したプロダクトに対して、成功に導く確率を高めるための方法がまとめられています。起業家だけでなく、ソフトウェアを使った新規事業を立ち上げるときにも参考になる内容です。
リーンスタートアップのフィードバックサイクルは上の図のようになっています。アイデアができ、コードが作られ、データを集め、さらにアイデアにつなげていく流れになっています。このあたりはXPやスクラム、アジャイル開発全般の流れにとても似ていますが、データを重要視している点が、今風なスタートアップが好むところでしょう。
リーンスタートアップが広まったあとに、リーンUX、リーンキャンバスなど、たくさんのリーン系アイデアも登場するようになってきました。当時のシリコンバレーでは、リーン思考がブームになっていたのだと思います。
一方で、10年経った今、リーンスタートアップを見てみると、あまり話題になることはなくなりました。時代遅れという言葉もちらほら見かけます。リーンスタートアップの実績が国内でどれだけ出てくるのかが楽しみです。
DevOps
切り離してはならないものを切り離してしまうと、問題が起きがちです。たとえば、開発とテスト。たとえば、開発と運用です。開発と運用が別れてしまった場合、問題の多いソフトウェアをデリバリーしてしまい、運用が疲弊するといった問題が起きたりします。こういった弊害を解決する方法はずっと議論されてきましたが、そこから「DevOps」という言葉が生まれてきたのだと思います。
DevOpsについては、ここでは開発手法として列挙していますが、Wikipediaやさまざまなイベントの発表資料を調べてみると、開発手法としてのDevOpsもあるみたいです。一昔前だと、開発と運用が分離している組織において「サーバのAdmin権限を与えるのがDevOpsだ」という意見もありました。ちょうどそういう現場で働いていたので、「権限を与える ＝ 信頼する ということなのだな」と妙に納得した記憶があります。
DevOpsは、上記の画像のように、無限大の形で表現されることが多いです。見てのとおり、左側に開発をさす「Dev」があり、右側には運用をさす「Ops」があります。それぞれのループでPlan、Branch・・・といったアクティビティが並んでおり、2つのループがつながって無限大のような形になっています。このサイクルを高速にまわすことで、改善を続けていきます。
DevOpsに関しては、画像共有サイトのフリッカーのエンジニアが発表した「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr（意訳： 一日に10回以上デプロイする： フリッカーにおける開発と運用の協力体制）というスライドが有名です。
DevOpsが誕生する2009年の発表ですが、今見てもヒントがたくさんある内容です。当時のフリッカーはブロガーに大人気のサイトでしたが、トップクラスの企業は、日に10回もリリースするのか！と私は当時衝撃を受けました。この日に何回もデプロイ・・・というのは、現在でも継続的デリバリなどの文脈で話題になるプラクティスと言えます。そして、Flickerの発表から10年がすぎ、今では日に何回もリリースするのは当たり前になりました。
DevOpsを実現するツール
DevOpsのそれぞれのカテゴリ・アクティビティは、ツールで実現できます。
- コード： GitHubやGitLabなど
- ビルド： JenkinsなどのCIツール
- テスト： 自動テスト、
- パッケージ ： コンテナ技術、ライブラリ管理
- リリース： リリース自動化
- コンフィギュレーション： インフラの自動構築、オーケストレーションツール
- モニター： パフォーマンスモニタリングツール
これまで紹介したプラクティスとは違い、ツールで実現しようとしているのは興味深い点です。ツールを活用するのが得意な日本人であれば、DevOpsの導入障壁は比較的低いかもしれません。
DevOpsのメトリクス： デプロイ頻度
DevOpsの目標はとても具体的なメトリクス（指標）として示されています。
ひとつめの指標は、デプロイの頻度です
フリッカーの事例にもありましたが、リリースの頻度をカウントします。リリース回数を数えることで、継続的な改善が行われているかどうかの目安になります。
DevOpsのメトリクス： 変更のリードタイム
2つ目は「変更のリードタイム」です。
ソースコードに変更のコミットが行われ、それが本番環境にリリースされるまでの時間をリードタイムとして計測します。これは短ければ短いほど、ユーザに価値が素早く提供されていると考えることができます。
DevOpsのメトリクス： 変更障害率
3つ目は「変更障害率」です。
いくらリリース回数が増え、リードタイムがはやくなっても、変更したときの障害が多くなってしまったらもともこもありません。回数を増やし、時間を短くするのと同時に、障害が発生する割合をかぎりなくゼロにしていく必要があります。
DevOpsのメトリクス： サービス復元時間
最後は「サービス復元時間」です。MTTR (平均復旧時間または平均修復時間)とも呼ばれます。
障害が起きてしまった場合にどれぐらいの時間で回復できるかを計測します。短ければ短いほど、ユーザーへの影響は小さくなります。
これらの目標は、4 Key Metrics と呼ばれています。 4 Key Metricsは、2022年にリリースされた最新のテクノロジー動向がまとめられた「テクノロジーレーダー」というレポートでも、積極的に採用すべきものとして取り上げられています。よって今後、 この4 Key Metricsが、世界中に広がっていく可能性を秘めています。
DevOpsについては、さまざまな書籍が出ていますが、今回紹介した4 Key Metricsという目標を中心に調べるとわかりやすいです。このあたりの情報がよくまとまっているのは、書籍『LeanとDevOpsの科学 テクノロジーの戦略的活用が組織変革を加速する』です。継続的デリバリーのJezz Hanbleさんも著者に名を連ねています。
Googleからも 4 Key Metricsのレポートが公開されています。ご興味があれば、あわせてご確認ください。
連載一覧
第1回：アジャイル開発の過去、現在、未来を知ろう！
第2回：声に出して読みたいアジャイルマニフェスト
第3回：従来型開発とアジャイル開発の違い その１
第4回：従来型開発とアジャイル開発の違い その２
第5回：アジャイル開発のよくある誤解を解いていこう！
第6回：世界中で大人気の秘密に迫る！スクラムを使ったソフトウェア開発
第7回：わかるようでわかりにくいスクラムチームの責任
第8回：スクラムイベントの実践方法
第9回：エクストリーム・プログラミングとその価値
第10回：エクストリーム・プログラミングの原則と基礎プラクティス
第11回：エクストリーム・プログラミングの応用プラクティス
第12回：リーンソフトウェア開発
第13回：ソフトウェア開発における「かんばん」
第14回：さまざまな方法論 − リーンスタートアップ・DevOps
【Sqripts編集部より】
藤原大さんの連載記事『現役アジャイルコーチによる「あらためて学びたいアジャイル開発」』はいかがでしたでしょうか。
読者のみなさまからの感想や今後の連載のリクエストをぜひお寄せください！
Sqriptsお問い合わせ、または公式XアカウントのDMでも受け付けています。
