「『気合と根性』でねじ伏せる不夜城状態だった」――KDDIは大規模スクラム開発の課題をどう乗り越えたか：開発迅速化に向けた組織変革のポイント

コンテナ、Kubernetes、CI/CDなど変化対応力を高めるための技術が重要視される一方で欠かせないのが、開発を迅速に進めるための組織変革だ。スクラム開発を導入していたKDDIは大規模プロジェクトで大きく3つの課題に直面していた。どう改善していったのか。

[高橋睦美，＠IT]

　スクラム開発は、比較的小規模な開発チームが一体となって柔軟に開発を進め、目的を達成するための手法だ。スケジュールを「スプリント」と呼ばれる短い期間に区切り、「バックログ」に基づいて優先項目を決め、少しずつ機能を開発することを繰り返すことで、大きな手戻りが発生することなく、高品質なソフトウェア開発を迅速に進めることができるとされる。

　ただ、プロジェクトの規模が大きくなり、開発チームが拡大していくのに反比例して、スクラムならではの良さが損なわれかねない。KDDIでスクラムマスターを務める岩間解氏も、その課題に直面した一人だった。同氏は2021年7〜8月に開催された「Cloud Operator Days Tokyo 2021」の講演「継続的デリバリーを実現する大規模スクラム開発体制への挑戦」を通じて、課題の解決に向けた取り組みを紹介した。

「気合と根性」で生産性低下――スクラムチームの大規模化に伴って浮上した課題

　KDDIでは法人向けに、仮想サーバやベアメタルサーバをオンデマンドで利用できる「KDDI クラウドプラットフォームサービス」を提供している。岩間氏らはサービスで提供している購買用ポータルサイトなどフロントエンドからバックエンドまで、ベアメタルサーバに関するサービスの開発を担当してきた。

KDDI サービス企画開発本部 プラットフォーム技術部 岩間 解氏

　岩間氏らのチームは2020年上期、それまでの開発プロジェクトに比べて5倍規模の大型プロジェクトに対応することになった。「当時の人数では対応できないことは分かっていたので、人数を増やし、体制を拡充して当たりました。しかし結果的に、不夜城状態のスクラム開発になってしまいました」と同氏は振り返った。

　プロジェクトそのものは開発チームの「気合と根性」で完了させたものの、メンバーのエンゲージメントが大きく低下してしまうという問題に直面した。岩間氏は「やはりスクラム開発においては、エンゲージメントを高めて成果を高めることが基本の考えになります。エンゲージメントの低下は大きな問題と捉え、改善を決意しました」と述べた。

　最初の取り組みは、冬休みを半ば強制的に取得してもらい、休んでもらうこと。そしてもう一つは「振り返り会」の開催だった。そして振り返り会を通じて、幾つかの課題が見えてきたという。

　「1つ目は、有識者が少ないシステムコンポーネントの開発が必要だった点です。触れたことのないシステムを理解する工数がかかり、開発が遅れてしまった部分がありました。2つ目は、メンバーの増加に伴ってミーティングでの議論も白熱することがあり、イベントが長時間化してしまったこと。そして3つ目の問題は、新規メンバーのフォローに想定以上の工数がかかったことです」（岩間氏）

　岩間氏は、日々の小さな改善ではこうした課題は解決しきれないと考え「チームの根本を変えていく必要がある」と判断。根本にはチームのスケールアウト手法に課題があると考え、スクラムチームの体制変革を決意したという。

　岩間氏らが抱えた3つの課題は、スクラムチームの拡大時に共通する課題といえるだろう。こうした課題を解決して「メンバーの技術力やサービス知識に差が生まれてもフォローできるチーム」「イベントに費やす時間を最小限にして、開発に集中できるチーム」「品質を維持しながら、開発ボリュームによって柔軟にメンバー変更が可能なチーム」にできるなら、チームを拡大したいと考える人は多いはずだ。

Scrum of Scrumsを採用し、エンジニアが開発に集中できる体制に

　岩間氏は、スクラム開発のスケールアウト手法の一つである「Scrum of Scrums」を採用することで、課題解決に取り組んだ。「社会インフラを担う通信事業者として、24時間365日、安定したサービスを提供するという使命があります。それに必要とされる高品質な開発を維持しながら、Scrum of Scrumsを採用してスケールアウトしました」（岩間氏）

　Scrum of Scrumsは文字通り、複数のスクラムチームでスクラムを構成する手法だ。各チームは5〜8人程度のメンバーが在籍し、それぞれプロダクトオーナーとスクラムマスター、複数のエンジニアで構成する。そして各スクラムチームは通常のスクラム開発と同じように、独立してバックログの元で開発を進め、スクラムを回していく。

Scrum of Scrumのイメージ

　ただ、大規模なプロジェクトでは、各チームが作成したそれぞれの成果物を連携させなければいけない部分が生じる。そこは、Scrum of Scrumsのプロダクトオーナーとスクラムマスターが主体となり、各チームのプロダクトオーナーとスクラムマスターと情報を共有しながら解決していく。

　「各チームのエンジニアに伝えなければいけない話が出てきた場合には、チームのスクラムマスターが各チームに共有します。エンジニアは各チームのイベントにだけ参加すればよく、イベントに費やす時間を最小限に抑え、開発に集中できます」（岩間氏）

　岩間氏らのプロジェクトも、以前は数十名以上の大きなチームを1人のプロダクトオーナーが取り回すという体制だった。案件に追われてシステムそのものの改善が後回しになったり、新規に加わったメンバーが相談しづらかったりすることがあったそうだ。

　「私たちもScrum of Scrumsに合わせて体制を変更し、1チーム当たり5〜8人で、各チームにプロダクトオーナーとスクラムマスターがいる体制にしました。エンジニアが開発に集中できるチームに変革でき、各チームでどんどんスクラムを回すことができるため、どんどん独自に進化していく様子を見て取ることができたのも、非常に良かった」（岩間氏）

キャリアグレード品質の担保に向け、プロジェクト横断的なチームも結成

　だが、この新体制でも解決できなかった課題もあった。「それは、全チームでキャリアグレード品質が維持できていないという問題です」（岩間氏）。原因をさらに深掘りすると、「システムの全てを把握できているメンバーが全チームにいない」「メンバー変更のあったチームで品質およびベロシティーが低下する」という2つの問題が見えてきた。

　ただ、システムの全てを把握できるようなメンバーは短期間に育成できるものではない。従って、Scrum of Scrumsを構成する全チームにそうしたメンバーをアサインするのは非現実的だ。代わりに、全チーム横断的に設計レビューを実施し、成果物の品質を一定に保つ責任を担う「アーキテクトチーム」を結成してキャリアグレードの品質を保つようにした。

　同時に「システム全てを把握できているメンバーが少ないということは、システムがシンプルではないとも言えます。そこでシステムのシンプル化を目的に、技術の負債をなくすことを目的にした『技術負債チーム』も作成しました」（岩間氏）

　技術負債チームは、まず対象システムの各機能の利用実績を見える化し、その結果に基づいて利用頻度の少ない機能を削除し、シンプル化した。また、利用しているコンポーネントも、サポート期限が終了し、かつ必要性がないものは削除し、別のコンポーネントに移管した。これはソース保守費の削減という面でもメリットがあったという。

　こうしてKDDIでは、Scrum of Scrumsの体制にアーキテクトチームと技術負債チームという2つのチームを組み合わせ、さらに各チームに役割を与え、案件ではなくその役割ベースでバックログを割り振るように変革していった。

Scrum of Scrumを実践した上で技術負債専門チームを設立

オンボーディングの充実に加え、ちょっとしたことでも話しかけやすい文化作りも

　残る課題である、メンバー変更があったチームでの品質およびベロシティーの低下は、新規に加わったメンバーが素早く開発に取り組んでもらえるよう、オンボーディングプロセスの改善を通して解決に取り組んだ。

　KDDIでも新型コロナウイルス感染症対策として、ほぼリモートで開発プロジェクトを進めている。そうした環境でもチームに馴染（なじ）めやすく会話しやすい環境を整えるため、幾つかの施策を実施した。

　まず、新メンバーと育成者をセットにする他、「15分ルール」を定めた。「15分間ハマって前に進まなければ相談を推奨するルールを定めました。とはいえ、15分ではすぐに相談しづらいかもしれませんが、このルールを作ることによって『何でも、少しでも相談していい』という雰囲気を作ることを目指しました」（岩間氏）。コミュニケーションツールとして利用している「Zoom」もチーム単位でブレークアウトルームを設け、会社で何かあったらすぐ隣の人に相談するのと同じ感覚で、声を掛けられる体制にした。

リモート開発でもコミュニケーションの取りやすい組織に

　またオンボーディングプロセスも含め、チーム内の情報を記しているWikiの充実も進めていった。それも、新規に参画したメンバーが実際悩んだ点、つまずいた点を更新することで、これまでの記述のうち分かりづらかった点を更新し、Wiki自体を成長させていく形にした。

　ユニークなところでは、資料をまとめるだけでなく、説明内容を動画コンテンツにして充実させていったという。「説明者も毎回説明する必要がなく、新しい方もその動画コンテンツを見ればすぐ理解できるため、双方の工数の削減になると思っています」（岩間氏）

日々の改善では解決できない課題は「根本から変えていくことが重要」

　このようにKDDIでは、プロジェクトの大規模化、チームの拡大に伴って生じた課題を踏まえ、Scrum of Scrumsを採用して改革に取り組んだ結果、さまざまな効果が得られた

　「まずチームが小さくなったため、エンジニア1人当たりのイベント参加時間が約半分になっただけでなく、コミュニケーションが活性化しました。この結果、各チームがいろいろなことにチャレンジしやすくなり、独自に進化するようになったのも良かった点だと思います」（岩間氏）。結果として、求められる品質を維持、向上させながら、開発物は約2倍に増えたという。

　岩間氏は一連の取り組みを振り返って、「日々の改善で解決できない課題にぶつかったときには、思い切って根本から変えていくことが重要だと感じました。品質を向上させながら、ベロシティーが200％向上し、オンボーディング時間が半分になったという目に見える効果ももちろんありますが、何よりエンジニアが開発に集中でき、いきいきと働ける環境になったことが最大の改善点です」とし、根本原因に目を向けた抜本的な改善が重要だと呼び掛けた。

特集：クラウドネイティブに「一歩踏み出す」現実的な処方箋-今のスキルで乗りだす秘訣-

素早く価値を生み出すためにビジネスとITサービス開発、運用を直結させる取り組みが不可欠となる中、注目されているアプローチがスピーディーにアプリケーション＝ビジネスをデプロイし、その後も高度な変化適応力を持ちながら、安定的に運用する「クラウドネイティブ」だ。だがクラウドネイティブの実践に当たっては、コンテナ、オーケストレーション、マイクロサービスアーキテクチャなどの開発、運用技術の知識が不可欠で、人材も予算も不足する企業で全てを実践するのは難しい。本特集では、クラウドネイティブの実践に向けてどのような取り組みを進めていくべきか指南する。

特集：クラウドネイティブに「一歩踏み出す」現実的な処方箋-今のスキルで乗りだす秘訣-