「DevOps」というキーワードをご存じだろうか。ソフトウェア開発の現場から生まれたこのソリューションがいま、組織変革に有効な手法の一つとして世界中で注目を集めている。VUCAといわれるこの時代において、ビジネスモデルだけでなく、その土台となる組織をどうトランスフォームしていくかが大きな課題となる企業にとって、DevOpsが持つ変革力のインパクトは見逃せない。Claris Internationalが、みずからの変革体験を通じて知ったDevOpsの真価を語る。
なぜDevOpsが
企業から注目されるのか
編集部(以下青文字):企業のDXが加速する中、ソフトウェア/システムソリューション開発の現場から生まれた「DevOps」という手法に注目が集まっています。いったいどのようなものなのでしょうか。
Director of Platform Evangelism
アンドリュー・ルケイツ ANDREW LECATESDirector of Platform Evangelism。1990年にシステムエンジニアとしてClaris入社。以来、コンサルタント、開発、PM、トレーナー、技術執筆など、開発プラットフォームに関連する役職を歴任。現在、Clarisにおけるプロダクトマーケティングとエバンジェリズムを主導し、組織変革を主導する Scrum of Scrumの責任者でもある。
ルケイツ(以下略):DevOpsは、品質の高いソフトウェアをできるだけ早く提供するため、開発側と運用側を連携させるフレームワークです。アジャイル開発を補完する手法と考えればわかりやすいでしょう。
DevOpsがもたらす最大の果実は、圧倒的な「スピード」です。DevOpsがうまく実行されると、開発リードタイムを大幅に削減できます。さらには顧客のフィードバックを受け、無駄やボトルネックを取り除くための改善サイクルを高速で回せるようになります。
DevOpsを実践する企業はパフォーマンスが非常に高いとされますが、我々もDevOpsによってスピードとパフォーマンスを劇的に高めてきました。以前はソフトウェアのバージョンアップに1年かかっていたのですが、いまでは最短2週間でアップデートができるようになっています。
DevOpsをパフォーマンス向上に結び付けた企業の共通点は、「組織文化を変容できたこと」と指摘する調査結果もあります。貴社の場合はいかがでしたか。
20年前までは、当社も従来型のウォーターフォール開発を行っていました。メジャーリリースに時間がかかるためスクラム開発に切り替えたのですが、最初はうまくいきませんでした。というのも、当時の組織カルチャーでは失敗を寛容に受け入れられず、実験的にトライ・アンド・エラーしていくことに抵抗を感じる人が多かったからです。
そこでカルチャー変革に着手しました。まず打ち出したのが「パーパス」です。そしてパーパスを実現するためのミッション、戦略を全組織に落とし込んだうえで、実現手法としてのスクラム開発を理解してもらうべく努めました。
スクラム開発はアジャイル開発の一つであり、少人数チームがチームの内外とコミュニケーションしながら短期間でプロダクトを生み出す手法です。我々は開発チームのみならず、営業、マーケティングなど、他のあらゆる部署にもスクラム開発を浸透させ、メンバーをプロジェクトに巻き込んでいきました。
この時に活用したのが、DevOpsです。具体的には2つの仕組みで導入しました。
一つはチーム同士のコミュニケーションを促進する「チーム・オブ・チームズ」です。スクラム開発においては小さなチームを結成し、短く区切られた開発期間でそれぞれ実験的なプロジェクトを回します。ただし、各チームがサイロ化しては意味がありません。そこでチームの代表が週に何度か顔を合わせ、意思疎通を徹底する機会を設けました。開発側と運用側のリーダーたちが集まり、膝を突き合わせて議論することで、より密な連携が実現しました。
もう一つは、開発において障害があれば声を上げていく「インペディメント・レイズ」の取り組みです。あるチームが抱える障害は、他のチームがDevOpsに加わることで解決できるかもしれない。我々は部署間の意思疎通を促す専門のコミュニケーションチームを立ち上げ、各チームの課題発見、課題解決に結び付けるようにしました。
こうしたDevOpsを実践することで組織間の連携力や透明性は高まりましたが、けっして既存の組織構造を破壊するアプローチをしたわけではありません。ミッションの割り当てやプロジェクトの優先付け、トラブル対処の指示などはあくまで上意下達で行われていました。その意味でDevOpsはトップダウンを助ける手法ともいえるわけです。
また変革には抵抗が付き物ですから、トップのコミットメントなしには進みません。当社の場合もCEOをはじめとする経営陣のフルサポートがなかったら、DevOpsは実践できなかったでしょう。