早く作って早くデリバリーする

須田一也氏（以下、須田）：コンシューマ向けサービスにおけるDevOpsについて、私須田がご説明いたします。

コンシューマ向けのプロダクト開発においては、ビジネス価値にフォーカスした仕組みを取り入れています。まずCI/CDですけど、“早く作って早くデリバリーする”かたちでCI/CDの仕組みを取り入れ、毎日進捗確認をして短いサイクルで開発し、振り返ってすぐ改善するようなスクラムのフレームワークを取り入れています。

そして疎結合、マイクロサービス、モダンアプリケーションといったインフラストラクチャーの仕組みも取り入れており、可観測性、サービス状況の可視化、ビジネスKPIの可視化といったかたちで、モニタリングやダッシュボードの仕組みも取り入れています。これらすべては、ビジネス価値を生み出すために作る仕組みとして、選択をしています。

CI/CDとMaaS開発サイクルの事例

続いて、その中からCI/CDの事例に関して紹介いたします。DevSecOpsの事例に関して、とあるチームの事例を紹介いたします。まず開発者がコードを書いて、TDDサイクルを回すことをルール化しています。それによって仕様の明確化であったり、変更容易性であったり、品質の維持に役立てています。

そして、モブプログラミングを採用することで、コードレビューの省略や、スキルシェア、多能工化を目的として実施しています。そうしてできあがったコードがsiderを使った静的コードレビューに用いられたり、CircleCIでテストとビルドとデプロイを行って、環境にデプロイをしています。

そのテストの中で「yamory」というサービスを使い、OSSの脆弱性診断を実施しています。環境にデプロイされたモジュールに対しては、定期的なリグレッションテストや、さまざまなモニタリングを実施することで、品質面に関しても自動的に確認を行う仕組みを導入しています。

続きまして、MaaSの開発サイクル事例に関して説明いたします。同じように、開発者がペアとかモブプログラミングをやっていますが、コードレビューの省略とかスキルシェア、多能工化につきましては、先ほどの事例と同じような効果を期待しています。それと併せて、最近はリモートワークなので、リモートワークでの孤独感の排除にも役立つかたちになっています。

このように作られたコードも同じく、CircleCIでテスト、ビルドを行い、AWS環境にデプロイしています。iOSだけはBitriseを使い、テスト、ビルド、デプロイを行って、DeployGateにアップロードして、アプリを配布しています。それぞれの仕組みに対しての状況に関しては、Slackに通知されるようになっています。

スクラムでの取り組み

続いて、スクラムでの取り組みに関して紹介いたします。CI/CDもチームごとに適したものを選んで使っていますが、スクラムに関する、スケール方法もチームごとに選択しています。「auでんき」アプリの事例では、Scrum@scaleの仕組みを使っています。こちらは各開発チームごとにプロダクトバックログがあり、スプリントごとにバックログを選択しています。

各チームのスクラムマスターが、毎日スクラム・オブ・スクラムというかたちで集まり、その中で話し合いながら、障害の除去や解決、ナレッジの共有につなげていくようになっています。

「au HOME」アプリに関しては、LeSS（Large-Scale-Scrum）方式を使っています。こちらは、1つのプロダクトバックログの中から、各開発チームがスプリントごとにバックログを取っています。開発チーム間の垣根を排除してフラットに編成することで、チームの障害やナレッジの共有も自発的に横展開される仕組みを採用しています。

「Slack」「JIRA」「Confluence」チームのコミュニケーションツール

チームのコミュニケーションのツールを紹介いたします。リモートワーク導入前に関しては、ほぼオフィスワークで開発を進めていました。メインのコミュニケーションツールはSlackを使っており、オフィスにいるので、雑談とか相談はその場でできます。

地方で開発している1名とのコミュニケーションは、Slackのテキストチャットとビデオを使っています。スクラムイベントもオフィスで実施しており、壁に付箋を貼って看板を設け、JIRAとかConfluenceにバックログの詳細などを保存しています。

リモートワーク導入後にどう変わったかというと、当然ながら全員リモートワークになりました。メインのコミュニケーションツールは変わらずSlackを使っていますが、やっぱり雑談・相談が少なくなったので、Tandemというボイスチャットのツールを入れてみたりしました。

スクラムイベントに関しても、Zoomを使って実施するかたちになったので、リモートワーク前とはかなり違ったやり方になってきています。看板についても物理的な看板を見るのはちょっと難しいので、GitHub Enterpriseの中でIssueとかProjectを使って看板代わりに使ったり。JIRA、Confluenceは、変わらずバックログの詳細を格納するというかたちで使っていました。

KDDIにおけるアジャイル開発のマインドセット

最後に、マインドについても触れたいと思います。アジャイル開発の考え方なんですが、もともとアジャイルソフトウェア開発宣言というかたちで「プロセスやツールよりも個人との対話を」が重視されています。それと、我々の中でアジャイル開発センター憲章というのがあり、ベースのカルチャーとして「楽しくやる」ことを謳っています。

「個人との対話を重視して楽しくやる！」ところが我々のカルチャーとして根づいているので、そういったかたちでこれからも開発を続けていきたいなと思っています。

ご視聴ありがとうございました。

Published at