『LeanとDevOpsの科学』（2018年）は、ソフトウェア開発と組織パフォーマンスの接点を探ります。厳密な研究をもとに、ハイパフォーマーなテクノロジー主導の企業が、変化の速いデジタル時代に卓越し、競争優位を築くための実践方法と能力を明らかにします。
この一冊で得られるものは？ 効率的なソフトウェアデリバリーを極めるための道案内
パン屋を想像してみてください。長い列のお客さんが、それぞれユニークなデコレーションのケーキを、しかもすぐに欲しがっています。昔ながらのやり方なら、ひとつひとつ丁寧に時間をかけて焼くしかありません。でも、ひとりひとりに合わせた、見た目も味も最高のケーキを、驚くほどスピーディーに提供できたらどうでしょう？
これこそが、ソフトウェアの世界でいう「継続的デリバリー」の魔法です。
本要約では、この『LeanとDevOpsの科学』を通して、モダンなソフトウェア開発の本質をひも解きます。あなたのビジネスが、顧客に“より速く、より良く”サービスを届けるために何が必要か。それは、あなたのパン屋を変革し、チームが効率よく、そして楽しく最高の作品を生み出せるようにするロードマップです。
最高峰のソフトウェアデリバリーを支える技術と科学に、飛び込む準備はできていますか？
継続的デリバリーなら、組織を混乱させずに変更を繰り出せる
2001年に「アジャイルソフトウェア開発宣言」が発表されました。当時、業界の多くの人が頼りにしていたアジャイル手法が、エクストリーム・プログラミング（XP）です。スクラムとは異なり、XPは極めて技術的で、開発中にソフトウェアのテストと統合を継続的に行うことに重点が置かれていました。継続的デリバリーは、この考え方をさらに一歩進めたものです。「美味しいケーキを焼くには、良いレシピと適切な材料を最初から揃えなきゃいけないよね」という発想に近いでしょう。
では、継続的デリバリーを簡単に説明するとどうなるでしょう？新しい機能の追加でも、エラーの修正でも、ちょっとした実験でも、ソフトウェアに対して「あらゆる種類の変更」を加え、それをスムーズかつ迅速にリリースできる“道具箱”を手に入れるイメージです。
ここにはいくつかの鉄則があります。
第一に「最初から品質をつくり込む」こと。後でミスを直すよりも、最初に正しく始める方がずっと簡単だ、という考え方です。
第二に「タスクを小さく分解する」。パズルを組み立てるように、一歩ずつ全体像に近づいていけば、うまくいっていることや調整すべき点を途中で把握できます。
第三に「繰り返し作業は機械に任せる」。つまり、リソースを賢く使うのです。人間は複雑な課題を解決するのが得意ですから、そこに集中させましょう。退屈な部分は自動化してください！
第四に「常にもっと上を目指す」。最強のチームは、常に改善しようと動いています。
そして最後に「チームワークが夢を現実にする」。関係者全員が、パズルのピースだけでなく、大きな全体像を共有しながら一緒に働くことが大切です。
さて、継続的デリバリーを機能させるには、しっかりとした土台が必要です。この土台も3つの格言に分解できます。
まず「しっかりした設計図をもつ」こと。ソフトウェアのビルド、テスト、リリースに至るすべてのステップを自動化します。最終承認のようなごく一部の手順だけが、人の判断を必要とします。
次に「マージし続ける」。チームは作業を絶えず統合し、問題を早期に発見できるように動作を保証します。
最後に、これが最も重要ですが「常にテストし続ける」！テストは後回しにしてはいけません。テストは常に動いていて、すべてのテストに合格してはじめて「完了」とみなします。
要するに、継続的デリバリーとは、質の高いソフトウェアを定期的かつ確実に世に送り出すことです。それは、プログラマーからデザイナー、テスターまでがシームレスに連携する、よく油の差された機械のようなもの。そして研究が示すメリットは、ソフトウェアデリバリーの質が上がるだけでなく、チームの士気が高まり、ストレスやデプロイに関する問題が減るということです。ただし、どんな大きな変化にも言えるように、時間やツールへの投資、そして変化を受け入れる意志が必要です。
もう少し深く見ていくと、この継続的デリバリーを、企業のシステム全体やソフトウェア構造という大きな枠組みに溶け込ませることが課題だとわかります。それについては次に見ていきましょう。
疎結合なチームは細部に足を引っ張られない
継続的デリバリーのプラクティスは、ソフトウェアを速くユーザーに届け、職場の士気を高め、アップデート作業をシンプルにしてくれます。しかし落とし穴もあります。ソフトウェアそのものの構造が、時に足かせになるのです。
車のエンジンがあまりにナーバスで、ほんの少しの変更が他すべてに影響を与えてしまうとしたら嫌ですよね。ソフトウェアではその逆を求めます。私たちが目指すのは「疎結合」な設計、つまり、ある部分に変更を加えても他の部分に支障が出ない構造です。そうすれば、ビジネスの成長に合わせて、大きなトラブルなしに改善を続けられます。
では、優れたソフトウェア構造とはどんなものでしょう？目立つのは次の二点です。システム全体を混乱させずに変更をテストできること、そして他の部分を待たずにソフトウェアの各部分を更新できること。最も優れた環境では、チームは許可を求めたり、他チームに余計な仕事を発生させたりすることなく、大きな変更を加えられます。しかも、その変更はピーク時間であってもダウンタイムを起こさず本番環境にリリースできます。
ここでもうひとつ面白い点があります。この柔軟な設計を持つ組織では、チームが常にコミュニケーションを取る必要はありません。まるで広い厨房で働くシェフたちのように、それぞれが自分のステーションとメニューの一部に責任を持ちながら、それでも全員が完全な一食を目指しています。会話が不要だと言っているのではなく、コミュニケーションは細かい手順ではなく、より大きな目標のためにとっておくべきだという意味です。シェフたちは「エビの調理法」や「サラダのドレッシング」ではなく、「お客様にどんな気持ちになってほしいか」を話し合うのです。
「特にチームワークを重視するDevOpsの世界では、コミュニケーションは多ければ多いほどいい」と主張する人もいるでしょう。しかしこう考えてみてください。大きなイベントを企画するときは、細かい部分を逐一話し合うよりも、大まかなアイデアを共有するほうが効率的です。ソフトウェアでも同様に、コミュニケーションは大局的な目標にフォーカスすべきなのです。
ソフトウェアが効率的で、ビジネスの要求に即応できるためには、その構造は柔軟でなければなりません。チームが独立性を保ちながらも、必要なときには協力できるようにする。このバランスが、ビジネスの成長と変化にソフトウェアが無理なくついていける秘訣です。
チームにツール選択の裁量を与えるとパフォーマンスが向上する
ビジネスのパフォーマンスを思い浮かべるとき、多くの人は売上グラフや重役会議などのイメージを持つかもしれません。しかし、その下には欠かせない土台があります。チームが実際の仕事をこなすために使うツールとシステムです。
あらゆる企業には通常、プレイブック（行動指針）があります。エンジニアやテクノロジーチームは、あらかじめ決められたツールやフレームワークのリストから選ぶことになっています。なぜか？その方が環境をシンプルに保てて、チーム全員が同じ技術言語を話せるようになり、ベンダーとの取引でも有利になるし、何よりツールが法的にクリアだと保証できるから、と考えられています。
しかしここに落とし穴があります。チームにそんなに狭いレーンしか用意しないのは、彼らの進路にスピードバンプを置くようなものです。ツールの選択肢を制限すれば、イノベーションが阻害され、より新しく、より効率的かもしれない方法に挑戦する気持ちを削いでしまいます。データもこれを裏づけています。自分たちでツールを選ぶ裁量を与えられたチームは、より良い成果を出し、組織全体も速く動きます。当然ですよね。日々ソフトウェアを作り、技術マネジメントに浸っているエキスパート以上に、何が必要かを知っている人がいるでしょうか？
一方で「ある程度の標準化は悪くない」という意見もあるでしょう。それも間違いではありません。特にシステムの構造について言えば、共通の基盤があれば問題の診断や解決に手間取ることが減ります。さらに、セキュリティに対する標準化されたアプローチによって、プロジェクトの最初から安全性を組み込むことができるでしょう。ただし、こうしたツールやセキュリティ手順は、あまり意識せずに使えるものでなければなりません。自然とフィットするものなら、チームは押し付けられなくても受け入れます。無理やり感があれば、誰も使いたがりません。
結局のところ、どんな消費者向け製品とも同じです。ユーザー中心ならヒットする。社内向けのツールも変わりません。優れたものは自然と使われるのです。
ビジネスの世界では、次のビッグテックは何か、どのツールが覇権を握るかといった議論が賑わいがちです。でも本当にフォーカスすべきは別のところにあります。それは、そのツールがユーザーにどんな感情を抱かせるか、そしてどのような成果を生むか、です。ツールの選択をトップダウンで決めてしまうより、より賢いのはコラボレーションを育むことです。エンジニアの声に耳を傾け、彼らのニーズを理解する。そのうえで、仕事を可能にし、「やりたい」と思えるようなツールを手渡すのです。
リーン・マネジメントがソフトウェアチームの進化を加速する
アジャイルは、ソフトウェア開発の世界でバズワードになっていますが、多くの企業はその表面をなでただけで、本来の可能性を探求しきれていません。旧来の習慣にしがみついて、予算や計画に長い時間をかけ、大きなアップデートはめったにリリースせず、顧客フィードバックは後回しです。
ここで「リーン」の出番です。リーンスタートアップ運動にインスパイアされたこの考え方は、とにかく継続的なユーザーフィードバックを重視します。アメリカの起業家エリック・リースは著書『リーン・スタートアップ』で、こうした新しい視点を提示しました。すなわち、プロトタイプから始め、プロジェクトは小さく管理可能なままにし、現実の反応を見ながら製品はもちろん、場合によってはビジネスプラン自体も変えていく準備をする、というものです。
多くのチームが「自分たちはアジャイルだ」と言いながら、外部から与えられたルールや要求に縛られたまま動いています。本物のアジャイルとは、最初から顧客を巻き込むこと。もし開発者がリアルタイムのインサイトにもとづいて仕事を修正・変更するのに、上司の承認を得なければならないとしたら、それは本当に素晴らしいものをつくるチャンスを逃していることになります。
研究は、チームに少しの自由を与え、開発の過程で実験したり、方向を変えたりすることを許すメリットを示しています。ごく初期段階から顧客フィードバックを集め、それを活用できる場合、利益率、市場獲得、効率性などの面でビジネスが繁栄するのです。
もっとも、これは開発者を好き放題にさせることではありません。バランスが必要です。「ひと口サイズの単位で働く」「進捗をチーム全員に共有する」「常に顧客の声を聞く」といったプラクティスと自由とを組み合わせることが、秘伝のソースです。このアプローチによって、意思決定は賢く、戦略的で、全員にとって有益なものになります。
本物のアジャイルプラクティスがソフトウェアデリバリーと結びつくと、チームのモチベーションは高まり、ストレスは減ります。視点を変えれば、ソフトウェアデリバリーがうまく回ると、それがリーンなプロダクトマネジメントの手法をさらに後押しします。これは好循環です。一方を改善すれば、他方の恩恵もさらに大きくなる。このサイクルこそが成長と成功を導くのです。
ここでの大きな収穫はなんでしょう？小さく区切って働き、常にユーザーを念頭に置き、“試して・テストして・適応する”というアプローチを受け入れること。それが、これからのソフトウェア開発の成功を約束します。
デプロイの痛みに正面から取り組むと、チームのパフォーマンスと士気が向上する
ソフトウェアチームの健康とパフォーマンスは複雑に絡み合っています。燃え尽き症候群やストレスフルなデプロイ（リリース）プロセスがもたらす、金銭的にも人間的にも高いコストをテクノロジー業界はよく知っています。では最後に、「デプロイの痛み」について見てみましょう。
エンジニアが新しいコードを本番環境にリリースする直前に感じる不安を想像してみてください。この不安感は、チームのソフトウェアデリバリー能力を示す強力な指標です。痛みの根源は、ソフトウェア開発とIT運用の狭間にあります。両者は、環境、考え方、プロセス、さらには用語の違いまで、まるで異なる世界が衝突しているようなものです。この痛みが深刻であればあるほど、ソフトウェアデリバリー、組織文化、そして全体的なパフォーマンスの劣化を示す兆候が増えていきます。
マイクロソフトの事例を考えてみましょう。同社のエンジニアリングチームは継続的デリバリーを取り入れ始め、目覚ましい結果を得ました。現代的なデリバリー手法を導入する前、エンジニアのワークライフバランス満足度は、わずか38パーセントでした。しかし導入後は、なんと75パーセントにまで跳ね上がったのです。エンジニアが業務時間内により効率的にタスクを管理できるようになり、手作業のデプロイが最小化され、仕事のストレスがオフィスの外に持ち出されなくなったからです。
しかし、経営者が気にかけるべき痛みはデプロイだけではありません。同じくらい憂慮すべき兆候は、開発チームがデプロイのプロセスそのものに無自覚な場合です。もしデプロイについて尋ねたとき、「考えたこともなかった」という答えが返ってきたら、警鐘を鳴らすべきです。この可視性の欠如は、通常、隠れた障壁があることを意味し、その障壁が開発者を、自分たちの仕事が本番環境に及ぼす影響という面から遠ざけてしまいます。
テクノロジー関係者の多くが口にする疑問、「どうすればデプロイの痛みをやわらげ、技術スタッフの働く体験を向上できるのか？」包括的な研究は、この痛みを減らすために特定の技術的ケイパビリティが有効だと明らかにしています。自動化されたテストとデプロイ、継続的インテグレーションの採用、最初からセキュリティに焦点を当てること、テストデータの効率的な管理、柔軟なアーキテクチャの活用、チームが自律的に動ける権限の付与、そしてバージョン管理の徹底、これらが鍵です。
つまり、ソフトウェアを迅速かつ確実にデリバリーする力を高める技術的な施策は、同時に、コードのデプロイにまつわるストレスを軽減するうえでも大きな役割を果たすのです。これらの施策が整っていることは、ソフトウェアデリバリーシステムの堅牢さだけでなく、満足度が高く、高いパフォーマンスを発揮するチームをも保証します。
総括
アジャイルソフトウェア開発宣言とエクストリーム・プログラミングは、開発におけるアジャイル手法と継続的テストを重視します。継続的デリバリーは、品質やタスクの分解、自動化、チームワークといった核となる原則に基づき、ソフトウェアを定期的に更新することにフォーカスします。柔軟なソフトウェア設計は、摩擦のないアップデートを可能にし、組織は標準ツールとチームの自律性のバランスを取る必要があります。リーンの原則は、ユーザーフィードバックと適応力を提唱します。そして、コードリリース時の不安である「デプロイの痛み」に対処することが極めて重要です。
これらの手法を受け入れることで、ソフトウェア開発は効率的で、ストレスの少ないものになるのです。
