CODT2021、組織変革でスクラム開発を加速したKDDIのセッションを紹介

Cloud Operator Days Tokyo 2021から、KDDIのクラウドサービス開発における組織変革のセッションを紹介する。

「継続的デリバリーを実現する大規模スクラム開発体制への挑戦」と題されたセッションで、プレゼンテーションを担当したのは岩間 解（いわま さとる）氏だ。岩間氏はKDDIのクラウドインフラストラクチャーサービスであるKDDIクラウドプラットフォームサービス（KCPS）で、ベアメタルサーバーサービスの開発を担当するチームのスクラムマスターである。

セッションを担当する岩間氏

岩間氏の所属するKCPSでは2020年上半期に大きな開発プロジェクトが立ち上がり、それに対応すべくメンバーの拡大を行ったという。しかしそれまでの開発の5倍という規模から、多くのメンバーが不夜城状態のスクラム開発になってしまったそうだ。結果として開発自体は完了したものの、メンバー間の繋がり、エンゲージメントが弱くなってしまったという。このことに対する反省を元に、組織変革を行うというのが今回のプレゼンテーションの始まりだ。

大型プロジェクト開発の結果、従来の組織では不具合が発生

次にエンゲージメントの向上のために冬休みの強制取得と振り返り会を行った結果、課題を解決するためにスクラム開発をスケールさせるスクラムオブスクラム（Scrum of Scrums）を採用したことを説明した。

振り返り会で明らかになった課題

ここでスクラムオブスクラムを紹介した。スクラムチームの単位を小さくし、上位にチーム間を繋げる役割のScrum of Scrums（SoS）を設置し、このチームが下位の個別チームのプロダクトオーナーとスクラムマスターを招いてスクラムを行うという階層構造を採ることを解説。

スクラムオブスクラムの説明。各チームは独立して開発を進め、SoSがチーム間での調整を行う形

そしてこの形になる前のスクラムの概要も紹介した。初期のスクラムではプロダクトオーナーが1名おり、その下に機能案件ごとにチームを構成し、それぞれのチームには10名以上のエンジニアがいるというもので、スクラムの理想と比べると粒度が大きくなっていたことを紹介した。

変革以前の組織概要。チームのサイズが大きい

この組織変革によってチームのサイズは小さくなり、それぞれのチームが効率的に開発に集中できるようになったと解説。

最初の変革でスクラム開発が効率化

しかし最初の変革だけでは「開発されたソフトウェアの品質が維持できない」という課題が解決できておらず、さらなる変革が必要になることがわかったというのが次のスライドだ。

新体制で解決できなかった2つの課題

「システムの全体を把握しているメンバーが全チームにいない」という問題は、そもそも巨大なシステム全体を理解しているようなエンジニアの絶対数が少なく、それを各チームに割り振れないという事情があるのだろう。結果として考案されたのは、全チームを横断的に見通せるシステムアーキテクトの専任チームを作ること、同時にコード自体をシンプルにするために技術負債チームを作ることの2点だ。

2つの変更点でシステム全体を見通すことを可能に

アーキテクトチームは全チームが開発したソフトウェアの品質に責任を持つというミッションを持ち、そのために設計レビューを行うというのが仕事になる。

アーキテクトチームの仕事とは

また技術負債チームはシステムをシンプルにするために機能の利用状況を可視化するという役割を持つ。具体的には、使われていない機能をソースコードから外すほか、利用しているコンポーネントのバージョンアップやEOL（End of Life）に対応するための管理などを行っている。技術負債チームがこのような役割を果たした結果、保守費などが削減できたという。この辺りは、キャリアグレードのソフトウェア開発のために保守費が発生するようなサブスクリプション付きのコンポーネントを利用していることが透けて見えるのが興味深い。

技術負債チームの仕事とは

組織変革の第2段階においてはアーキテクトチームや技術負債チームに加えて、各チームが共通して利用する特定コンポーネント開発に特化したチームも設置された。ビジネスが要求する機能を開発するチーム、それを統括するスクラムオブスクラムのチーム、技術負債を解決するチーム、特定コンポーネント開発チームが上手く機能するようになったと説明した。

さらなる変革後のチーム構成

また開発メンバーが追加・変更された時に品質と開発速度が落ちるという問題には、立ち上がりをサポートするための工夫として、チームメンバーはZoomに常駐すること、個人で15分間かけて解決できないような問題が発生した時は一人で悩まずにZoomで相談するというルールを設けた。その結果、完全にリモート開発となった場合でも上手くコミュニケーションが取れるようになり、メンバーの追加・変更時の課題は解決したと説明した。

新しい開発メンバーをサポートする環境を作った

またオンボーディングの支援のためにWikiを充実させ、動画による解説やオンボーディングのマニュアルであるWikiの改良はオンボーディングしたメンバー自身が行うことなどの工夫が行われたことを解説した。

オンボーディングを改善するための工夫を紹介

結果としてコミュニケーションが活発になり、無駄なイベントも減ったことで品質を維持しながら開発物（ソフトウェアやドキュメント）が2倍になったことを紹介した。

2回の組織変革の結果を紹介

最後にまとめとして、課題を解決するためには思い切って根本から変えることの必要性を解説した。結果的に2倍の生産物、新メンバーのオンボーディング時間の短縮などが定量的に可視化されたという。

サービスとして提供するインフラストラクチャーの品質を維持しながら、素早くソフトウェアを開発したKDDIの組織変更にまつわる成功談のセッションだった。スクラムチームの大きさを10名以上から5名程度のチームに組織を変えたという辺りはマニュアル通りと言える。

アーキテクトチームを作った際の人選やスクラムオブスクラムを実施する際の苦労、また技術負債チーム、特定コンポーネント開発チームを作った背景や苦労などについても聞きたかったというのが本音だ。組織を改革することは、新しいツールを組織に入れるよりもはるかに難しく、人事や総務部門との調整も必要となるだろう。次回はその辺りの泥臭い経験談も盛り込んでほしい。