このDevOpsと組織改革の記事では、ソフトウェア開発におけるビルドやテスト、リリースやデプロイの自動化に留まらず、自動化やそこで得られる指標をどう活用し、組織の改革を進めていくのかについてわかりやすくご紹介しています。
DevOpsの壁とは
ソフトウェアを開発・運用している皆さまの組織では、DevOpsに関わる取り組み、つまり開発チームと運用チームが一体になり、相互に協力し合う取り組みをどれだけ進められているでしょうか？
『LeanとDevOpsの科学』という書籍をすでにお読みになった方もいらっしゃるでしょうが、この本は、Puppet社が毎年まとめているState of DevOps Report (DevOpsの現況に関するレポート)の2014~17年版をまとめ、解説を加えたものです。
レポートの公開や書籍の出版当初からDevOpsに取り組んできた組織において、進化が進み成果を感じているケースもあるでしょう。その一方で、DevOpsの取り組みに取り掛かったものの、壁を感じているケースもあるかと思います。
本稿では、2021年版のレポートから、DevOps取り組みの壁と、その乗り越え方をご紹介していきます。
なお、2020年、21年版レポートの日本語訳はCircleCIから公開されています。レポート全体をご覧になりたい方はリンク先から入手ください。
自組織のDevOps成熟度をデータから知る
DevOpsの成熟度は何らかの形でモデル化できるのでしょうか？ レポートでは以前より、自組織のDevOps成熟度を捉えるための4つの指標を提唱しています。
最初の２つの指標
- デプロイ頻度 (より頻繁に)
- 変更に必要なリードタイム (より短く) は、利用者にソリューションを迅速に提供することで、他社との比較優位性を獲得することに繋がります。
また、残りの２つの指標
- 変更失敗率 (より低く)
- 問題発生時の平均修復時間 (より短く) は、システムをより安定した形で利用者に提供することに繋がります。
「DevOps = 自動化」では必ずしもありませんが、ビルドやテスト、リリースやデプロイが自動化されることで、これらの指標から仕事の質の向上を数値的にトラックし続けることが可能になります。
別の角度から捉えてみましょう。DevOpsの進化が進んだ組織では、
- 90%が反復作業のほとんどを自動化済み
- 97%が自動化により仕事の質が向上 という結果が出ています。自動化によって、効率化といった質の向上と、その裏付けとなるデータ(指標)のトラッキングができることの両方が重要なのです。
DevOpsの壁 〜 自動化に取り掛かっても成果を感じられない
さて、自動化に取り組むことで一定の成果、つまり、ビルドやテスト、リリースやデプロイが担当者の作業を前提とせずに行えたり、作業ミスが発生しないといった成果は得られたものの、DevOpsの導入で実現したかった絵姿とはどこか違う、といった壁を感じている組織も少なくないのではないでしょうか？
自動化を進めても、組織におけるチーム内の動きであったり、チーム対チームの動きが最適化されていなければ、４つの指標で捉えようとしていた「ソリューションの迅速な提供」と「システムの安定した提供」が実現できず、「実現したかった絵姿とどこか違う」という結果に陥ってしまう、壁を感じてしまうのです。
それでは、自動化に最適化された組織とはどのような組織を指すのでしょうか？ レポートでは次の４つを挙げています。
- 各グループは少数のメンバーで構成
- 自チームが他のチームに対してどのような役割と責任を持っているのかを理解
- 隣接チームがどのような役割と責任を持っているのかを理解
- プラットフォームチームの存在
そして、少数のメンバーから構成される各チームは、
- バリューストリーム思考のアプリチーム(提供価値をどう実現)
- アプリの実現チーム(アプリとしてどう実現)
- 複雑なサブシステムのチーム(どのような技術で支えるか)
- プラットフォームチーム(開発・運用基盤のサービス化)
これらのそれぞれ異なるチームが自チームの役割・責任と、他チームの役割・責任をそれぞれ理解した上で、チーム同士が積極的に知識や情報を共有することが重要であると述べています。
作業のサービス化(ツール化)とは
また、チーム同士がお互いに役割・責任を理解し、知識や情報を共有することが重要な反面、日常の開発業務はチーム間で作業依頼などをやりとりしながら進めるのではなく、自律的に、セルフサービスで進められるようにしておくことが、スピーディーに始める上でも、継続的に進化を進める上でも重要であると述べています。
DevOpsの成熟度が中位よりも上位にある組織においては、(単にビルドプロセスが自動化されているということに留まらず)、次に挙げるような作業が他の人やチームに依頼することなく、セルフサービスでスピーディーに進められています(カッコ内は中上位組織におけるセルフサービス化の割合)。
- CI/CDワークフロー (62%)
- クラウドインフラ (58%)
- 監視、アラート、可観測性の適用 (57%)
- 開発環境 (53%)
- 社内インフラ (52%)
組織の7SとDevOps
レポートにおいても、進化が進まない組織の落とし穴は「組織構造」と「組織力学」であるとはっきり述べられており、具体的に、
- リスクを避ける組織文化
- 責任が不明確
- 迅速なフロー最適化が優先事項になっていない
- フィードバックループが不完全
であることが問題であると指摘されています。
レポートの話から外れますが、組織の全体像と要素間の連携を捉えるフレームワークとして、マッキンゼー・アンド・カンパニー社が提唱する7Sモデルでは、組織の要素を７つの要素で表し、それぞれの要素間の関係と「変わりやすさ」を図示しています。
ハードのS (組織の構造) - 変更が容易
- 戦略(Strategy) - プロダクトやサービスの方向性
- 組織(Structure) - 組織の形態、構造
- システム(System) - 作業や情報の流れ
ソフトのS (人) - 変更に時間を要する
- 価値観(Shared value) - 社員間で共有される会社の価値観
- スキル(Skill) - 組織が持つ能力(技術力、営業力、マーケティング力など)
- 人材(Staff) - リーダーやメンバーが持つ能力
- スタイル(Style) - 社風、組織文化
DevOpsは自動化でもツールでもありませんが、自動化と指標の見える化、共有がシステム(作業や情報の流れ)を支え、他の６つのSを巻き込んでの変化を停滞させることなく、加速させることができます。
CircleCIで自社の開発を加速し、提供するシステムやサービスでお客様の業務の加速化を支援しましょう。
