GOTO Berlin 2015カンファレンス初日の閉会講演は，Nicole Forsgren氏によって行われた。講演の中で氏は，ハイパフォーマンスな組織がDevOpsとリーン管理で信頼性の高いサービスを迅速に提供する，その方法について論じた。
InfoQは氏とのインタビューから，企業がDevOpsメソッドの採用に動き始めた理由，迅速なデプロイがITの安定性向上に与える影響，リーン管理によるパフォーマンス向上などを聞くとともに，パフォーマンス向上の手段としてのDevOps導入を望む企業へのアドバイスを得ることができた。
InfoQ: "State of DevOps 2015"の報告では，信頼性の高いコードの迅速な提供を実現した，ハイパフォーマンスな企業が取り上げられていますが，これらの結果が興味深い理由と，ソフトウェア開発と提供のプロセスとして企業がDevOps手法を採用し始めた理由について，説明をお願いできますか？
Forsgren: 2014年と2015年の“State of DevOps”はいずれも，ハイパフォーマンスなIT組織が他に対して，スループット –– １日当たりのデプロイ数，サイクルタイムの速さなど –– および安定性 –– 平均回復時間(mean time to restore)および変更成功率(change success rate) –– の両面で，はるかに高い成果をあげている，と報告しています。スループットと安定性を提供する能力は，ソフトウェアの提供においては大きな付加価値であり，従来のITでは達成できなかったものです。これまでは常に，安定性を維持するためにはスループットのトレードオフが必要だと言われていました。それがDevOpsでは，もっとよい結果が約束されているのです。スループットと安定性の基準値が両立する – 安定性を得るためにはスループットのトレードオフが不可避であるとするITILの主張が，事実上成立していないことを，このデータは示しています。安定性のためにはスループットの妥協が必要だとするパターンが，このデータには現れていないのです。ではユーザにとって，これは何を意味するのでしょう？スループットの向上は，コンテンツや新機能の市場への早期提供，あるいはコンプライアンスや規制の変更に対する対応の迅速化となって表れます。これが，ソフトウェアないしインフラストラクチャの信頼性を保ちながら実現可能になるのです。
InfoQ: 迅速なデプロイがITの安定性向上を可能にする，という点について，詳しく説明して頂けますか？
Forsgren: デプロイの迅速化はサイクルタイムの短縮(コードのコミットからデプロイまで)やデプロイ頻度の向上につながりますし，一般的には，作業の集約化やバッチの縮小化という成果にも現れます。バッチが小さくなることは，問題の素早い発見と修正を可能にし，安定性に貢献します。さらには，修正プロセスの迅速なシステム移行が可能になることも，安定性に貢献します。ここで２つのシナリオを想定してみてください。ひとつは，開発者が小さな変更をコミットしたものを自動的にテストし，ビルドして，–– テストがすべて通れば –– 承認後に実運用にデプロイするという，新たなパラダイムです。このシナリオでは，ほとんどのエラーはプロセスの早期に捕捉されるので，修正の失敗やサービスの中断といった可能性は低減されますし，もし発生しても，サービスの復旧時間は短くて済みます。これに対して，古いパラダイムでは，大きなコードブロックに対して，大勢の開発者が何週間も，あるいは何ヶ月も作業した結果が運用にデプロイされていました。前者のシナリオでは，デプロイで何らかの問題が発生したとしても，デバッグ対象となるのは小さなコードブロックですから，問題をロールバックして解決法を見つけるのは容易です。後者のシナリオでは，非常に大きなコードブロックで運用環境が大きく変わっているので，ロールバックは不可能かも知れません。可能であったとしても，コードのデバッグは困難でコストも掛かります。これが原因で製品への変更点の導入に失敗したり，何らかの理由でサービスが中断する可能性が高くなります。極端に長く遅いデプロイメントプロセスは緊急の変更にも影響しますし，サービスの復帰も遅くなるのです。
InfoQ: 組織文化を変えてパフォーマンスを向上したいと考えている企業は，どのようなことを重視するべきなのでしょう？
Forsgren: DevOpsパラダイムにおいて，優れた文化を認める観点として重要なのは，情報の流れと信頼です。通常ならば一緒に作業することはない上に，これまでは相反した目標(提供コンテンツの最大化を目指す開発者に対して，安定性維持のために運用システムの変更を阻止しようとする運用担当者，というように)を持っていたグループをまとめようというのですから，これらは特に重要です。情報の流れは，これらのグループ間で，彼らの行動の理由に関するコミュニケーションを可能にします。また信頼は共感を拡張し，存在するすべてのギャップの解消を実現します。情報の流れの促進や信頼性向上を支援する上でしばしば使われるのが，スタンドアップやブレームレスポストモータム(blameless post mortem)などといったものです。
InfoQ: これらすべてに対して，リーン管理がどのように適しているのか，詳しく説明して頂けますか？パフォーマンス向上に対して，リーン管理の何が有効なのでしょう？
Forsgren: うーん， これについては，何から話せばいいのか分かりませんね。リーン管理がDevOps活動に与えた影響があまりにも大きいですから。リーン管理は，ITパフォーマンス定義の大きな部分を占めています。ちょうどハイパフォーマンスと１ピースフローが，リーン生産の概念とムダ排除の中心的な構成要素であるのと同じです。また，継続的インテグレーションや，迅速なフィードバックの重要性，さらにはDevOps活動それ自体の範囲にもその影響が見られます。DevOpsとは，そもそも開発(Development)とIT運用(Operation)が，おそらくは物理的な部分も含めて，緊密に関係して動作することなのです。これはリーン生産の中でも，価値を創造する生産活動に特化したマニュファクチュアリングセルの導入として見られます –– 彼らはこれまでのチームを，もっと緊密に結び付けられた組織として再構成することで，引き継ぎコストを最小化し，コミュニケーションを最適するのです。2015 State of DevOpsでは，WIP制限や可視化などといった，リーン固有のプラクティスも調査していますが，結果として，それらがITパフォーマンスに大きな影響を与えることを報告しています。
InfoQ: パフォーマンス向上のためにDevOpsの採用を望む企業に対して，どのようなアドバイスをしたいですか？
Forsgren: DevOpsの旅に出る準備ができたのならば，ツーリングとオートメーションだけが目的ではないことを忘れてはなりません。プロセスと文化，この２つにも注目することが必要です。基準値を決めておくことも大切です。尺度がなければ進歩もあり得ません。それが大丈夫ならば，適切なプロジェクトを選択することがとても重要です。重要なプラクティス(開発，QA，テスト，運用，セキュリティなど)をすべてしなえた，ビジネスに価値を提供するプロジェクトを選んでください。４ヶ月以内にプロトタイプを提供可能であることも必要です。このアプローチで大きな成功を収めた事例が，TargetとNordstromです。初期のプロジェクトを使った反復と学習を行い，そこで学んだことを他のビジネス領域に拡張する中で，価値を提供してきたのです。