KDDIの2つのセグメント「パーソナル」と「ビジネス」
岡澤克暢氏（以下、岡澤）：みなさんこんにちは。「KDDI流の『アジャイル開発』の取り組みと事例」について説明いたします。
登壇者の紹介をします。まず私ですが、KDDIのアジャイル開発センターでグループリーダーをしています。主にエンジニアリングマネージャーや、開発系のサービスでいうとIoTサービス、教育サービスに携わっていて、それを生かしながら学生支援などもしています。
2番目にソリューション系について佐々木がお話します。佐々木は、主にエンタープライズ系のアジャイル開発を推進しています。オフショアマネジメントや、プロダクトにおける企画側のコミュニティ立ち上げなどを実施しています。
最後にコンシューマ系のサービスを須田が説明します。須田はMaaSサービスだったり「auでんき」というアプリのスクラムマスターを主に経験しています。また、社内でコミュニティ活動なども推進しています。
最初に、KDDIの紹介を簡単にします。セグメントとしては、パーソナルとビジネスがあります。この領域において、アジャイル開発を進めています。パーソナルでいいますと「auスマートパス」「auでんき」「au HOME」です。もちろん、みなさんが使っている携帯電話、スマートフォンもあります。
もう1つのセグメントが、ビジネスです。こちらは企業向けの通信ソリューションです。KDDI Business IDやネットワーク、あとは世界各国にTELEHOUSEなどを展開しています。
もう1つ紹介したいのが、KDDIの2つのブランドメッセージ、「Tomorrow,Together」と「おもしろいほうの未来へ。」です。こちらを紹介した背景としては、「おもしろいほうの未来へ。」の補足にある、「つねに楽しく遊び心のある未来を選び、世の中にワクワクする変化を生み出す。」というのがあります。
特にアジャイル開発は、「ワクワクしたものを生み出す」とか、「常に改善していく」というのがあり、会社のブランドメッセージとも紐づいてるので紹介しました。
今日のアジェンダですが、3つあります。1つ目がKDDIにおけるアジャイル開発、2つ目が法人向けサービスにおけるマイクロサービス化、3つ目がコンシューマ向けサービスにおけるDevOpsです。
最初に、KDDIにおけるアジャイル開発について、組織の広げ方とチーム構成、あとDevOpsのスタックについて説明します。さらにリモートワーク。今までオフィスで仕事していたところからリモートワークに変わっていますので、どういった開発をしているのかについて説明します。
KDDIにおけるアジャイル開発の歴史
KDDIにおけるアジャイル開発の歴史を説明いたします。KDDIは2013年ごろに法人向けサービスを一部立ち上げまして、そこからアジャイルを導入しています。そのあと、法人向けからパーソナル領域に広げて、「auでんき」「au HOME」などにアジャイルの領域を拡大してきています。
少人数で始めてから2年後、3年後に、アジャイル開発センターが部として登場しています。その後、オフショア・ニアショアに拡大していき、UI/UXの取り組みとして、デザインシンキングを導入しています。デザインシンキング自体は2013年ごろから各チームで取り入れてはいたんですけど、チームとして大きく取り入れ出したのが2017年になります。
その後、これまで内部や外部で養ったナレッジを生かして、「KDDI DIGITAL GATE」という、お客さんとともに共創するビジネスを立ち上げています。あとは、スクラムを推進していますので、海外のScrum inc.社と、また別の企業とも手を組みまして、新しくScrum inc. Japanを設立しました。こちらも、いろいろな法人のお客さんにサービスを展開している状況です。
「リーンスタートアップ」と「デザインシンキング」
もともと1チームから始まったアジャイル開発センターですが、今は30チーム、約300名ぐらいが所属している開発チームになります。アジャイル開発センターにおいて、開発ですごく意識していることが3点あります。1点目がリーンスタートアップ、2点目がデザインシンキング、3点目がアジャイル開発です。
「アジャイル開発」というと、どうしても開発のイメージが強いと思うんですが、サービスを考えるうえではリーンスタートアップ、デザインシンキングのほうが非常に重要です。ちょっとこちらを補足したいと思います。
リーンスタートアップは、みなさんご存じかもしれませんが、“小さく始めて成功に近づける”手法になります。こういった手法をなぜ取るかというと、今は世の中が、どのように対応し、どういうサービスが売れるか、非常にわからないものがあるからです。そういったものを成功に近づけるために、この手法をとっています。
リーンスタートアップは、サイクルがすごく早い状態になります。そのサイクルが早い状態に、いかに開発がついていくかというところで、アジャイル開発においてすごく有益な方法になります。
もう1つのデザインシンキングは、人間中心設計とも言われるんですけど、お客さんのPoCを作り、実際に試してもらって、効果があるかをグルグル回すかたちになります。ジャーニーマップやペインポイントを洗い出して、そこに対して価値を届けるところをサービスとして作っていくかたちになります。
スクラムを組みながら作った「auでんき」
これらを生かして、直近で提供してきたものを、3つ紹介したいと思います。1つ目は「auでんき」です。コンシューマのお客さま向けに、電力小売業がオープンになった段階で、KDDIも参入しています。短期間で初期アプリのリリースをしたり、コストを削減したり、非常に有益なスクラムを組みながらサービスを作りました。
後ほど説明するメンバーは、こちらのスクラムマスターを担当したメンバーになります。
2つ目はMaaSサービスです。こちらは沖縄の観光向けにリリースしています。左下にあるのがジャーニーマップで、使いながらユーザのペインポイントを解決するためのフローを組みながら、いろいろなパートナーと連携してサービスを生み出している事例になります。
3つ目は実際にKDDIが提供している「auショップ」の事例になります。みなさんがauショップに行ったときに「この携帯はどれぐらいの利用料になるんだろう」ということを非常にわかりやすい状態にすることで、お客さんに理解してもらうとか、お客さまが不便に感じている部分をスムーズに解決したいなというのがあります。
こういったところにも、実はアジャイル開発センターのメンバーが入っていて、デザインシンキングをしてサービスを届けています。
スクラムのチーム構成
ここからは、実際にどういったチーム構成で進めているかを説明します。スクラムは、基本的にスクラムチームの中に開発メンバーがいて、フロント、バック、インフラ、デザイナー、あとはQA、スクラムマスターがいます。そういったメンバーとプロダクトオーナーがいて、プロダクトオーナーがマーケットやステークホルダー、社内関係者とやり取りをしています。
実際どういった感じで進めているかというと、だいたいスプリントを1weekから2weekで回しています。たまに1dayスプリントを回しているチームもあります。大規模になるとScrum@scaleやLeSSを導入しています。こちらはあとで説明します。
振り返りはKPTやFun Done Learn。スプリントごとにスクラムマスターが変えていたりします。開発方法は主にペアプロ、モブプロが多いかなと思います。最近は、モブプロを導入しているチームが非常に多いかと思います。
先ほど紹介したScrum@scaleを簡単に紹介すると、基本的にはスクラムを回していくかたちです。規模が大きくなってメンバーが多くなったり、対応する箇所が多くなってきたら、スクラムチームも増やし、横のつながりや縦の問題などを解消するために、エグゼクティブチームを置いて、問題解消のためのスクラムをスケールしています。
こちらはDevOpsのスタックになります。今回Operator Daysということで、運用面でどういったツールを使っているかを、アジャイル開発センターメインに紹介いたします。まずチケット管理は、JIRAをメインに行っています。
アトラシアン系のツールで初期の立ち上げをしているものですから、JIRAやConfluenceをメインに進めています。一方で、一部のメンバーはTrelloを使っています。
次にコミュニケーション。こちらはSlackが基本的にメインです。当初はChatworkも使っていましたが、オンラインになった現段階では、VS Code shareも使っていたりします。
情報共有については、先ほど言ったアトラシアン製のConfluenceや、GitHubを使っているため「GitHub pages」を使っています。ここにロゴが載っているものが、メインで使っているサービスです。リポジトリについては、GitHubメインです。当初はBitbuketを使っていたので、ソリューション系の最初に始めたチームは、まだBitbuketを使っているところもあるかもしれないです。
CI/CDについて。こちらは、当初はBambooメインで始まっていたんですけど、最近はJenkinsのシェアが多くなってきています。その後CircleCIを使うところが出てきて、横のスクラムに展開したりして、Drone、Siderあたりを使うようになっています。ネイティブ系のシェアについては、Bitriseを使っているチームが非常に多いです。
テスティングについては開発している言語によって変わってきますが、GatlingとかSeleniumはよく使われてます。あとはTestcafeやterratestという新しいテストケースも使っています。
ここにSecurityと書いてあるんですけど、最近DevSecOpsと言われる部分で紹介されるツールのBlack DuckやCoverity。yamoryも使っています。yamoryの使い方も後半で紹介いたします。カオスエンジニアリングについては、当初からGremlinを使っています。
現状Kubernetesベースのサービスが立ち上がっていないので、もしそれが立ち上がってくると、また別のオープンソース系を使うことになるかと思ってます。
次にデプロイです。コンフィグ系はTerraformが非常に多いかなと思っています。HashiCorp製品は使いやすいのでTerraform、CloudFormationを使っています。あとはFargateなどが多いかなと思います。
AWSのIAMを作る場合に、Ansibleを使いながらTerraformを使うことが多いかなと感じています。リポジトリはコンテナを多く使いますので、各サービスに寄り添ったものになります。クラウドの基盤としては、AWSが圧倒的に多いかなと感じています。主にコンテナベースやサーバーレス系を使用してます。
KCPSは、KDDIが提供しているクラウドサービスで、主に法人向けのセキュリティ強化などが非常に有益なサービスです。後ほど説明しますけど、AWSとKCPSの併用などを進めています。
最後はモニタリングの監視系です。昔はたぶんZabbixとかが非常に有名で、よく使われていたと思うんですけど、アジャイル開発センターの場合、Datadogを非常によく使っています。あとはInstana、mackerelなど。各チームで導入する際に、例えばDatadogの場合は、あるチームが1個使いだして「これ使いやすいよ」となり、他のチームが使いだして、今広く使われている状況になります。
なので、ここに載っているサービスは、どんどん新しいものが出てくる段階で、各チームがチャレンジしてみて、有益だなと思ったらすぐにそちらに乗り換える動きがあります。
リモートの開発状況
次にリモートの開発状況です。アジャイル開発センターはこのコロナが起きる前からリモートワークだったりニアショアを一部やっているので、ツール群とかが大きく変わっていないのが、正直なところあります。開発中のコミュニティはSlackで、あとはDiscordを使っているところが非常に多いです。
ペアプロ（ペアプログラミング）やモブプロ（モブプログラミング）をするときには、VS Code shareを使っています。スクラムのイベントの振り返りや計画はMiroを使ったり。MiroとZoom、CacooとZoom、そういったところを使っています。ちょっとしたクイックQAとかはSlack上で行うんですけど、ちょっと長いディスカッションになると、Zoomを使うことが多いかなと思いますね。
例えばハッカソンなどのイベント。小さいハッカソンを開くときは、今はRemoやSpatial.Chat（スパチャ）かSococoを使ってみて、どういった可能性があるかを試しています。ホワイトボードの代わりによく使っているのは、Miroが多いかなと思います。あとはCacooを代わりに使っているところも多いです。
もともとは全員集まってモブプロで開発を行うのがKDDIのスタイルだったんですけど、オンラインになって、VS Code shareを使ったりSlackの画面共有を使ったりZoomの画面共有を使いながら、モブプロで継続して開発している状況です。ワークショップも、Miroを使ったりCacooを使って、共同編集しているかたちになります。
チケットは、もともとJIRAで管理していますので、JIRAベースで見積もりを出すようにしています。スクラムマスターとか開発メンバーに、「オンラインになってからどんなTipsがありますか？」と聞いたとき、「モブの休憩は非常に細かく取るようになりました」と言っていました。オフラインでやっているときも、非常に集中力を使うそうなので。
いろんなところで言われていますが、雑談ですね。雑談はけっこういろんなチームがトライしています。雑談タイムを固定してみたりとか、急に雑談ルームを作ってみたりとか。「雑談をしよう」といって始まることはあまりないので、ゲームをしてみるとかランチタイムを一緒に過ごすとか、そういった試みをしています。
エンジニアマネージャーの観点からいうと、やはり1 on 1の間隔を少し短くしたりしています。こういう状況でいると実際に3ヶ月経って久しぶりに会ったメンバーも、久しぶりに会った感覚はなくて、昨日も会話してた感覚になります。なので、すごくいい状態でリモート開発をしているような感覚があります。
ちょっと紹介になるんですけど、（スライドの）その他のところにAnycommと書きました。これは、スクラムで使うレトロスペクティブ向けの開発アプリで、KDDIがリモートワークになって、開発チームがKPTの振り返りをやるときに「ちょっと不便だね」となりました。
開発チームなので、じゃあそれを作っちゃいましょうということで、レトロスペクティブ向けの専用のアプリをKDDIのエンジニアメンバーで、短時間でテストして開発して、今実際に世の中にリリースされています。もし使いたい方がいれば、使っていただければなと思います。
組織におけるアジャイル開発の問題点
最後にアジャイル開発の組織における問題を書きます。我々が歩んだ道を説明するとSTEP1、STEP2、STEP3とあります。最初に導入期があります。その頃の日本企業、特にユーザー企業は、内部にエンジニアがいないことが多いと思いますので、まずは人材育成。アジャイルとかは、権限の委譲やマネジメントの理解がすごく重要になりますので、そこのマインドセットが必要です。
次の拡大期に向けて、チーム単位で自律的に動いてもらわないと広がっていかないので、そのチームの成長が非常に重要になります。最後の変革期に向けては、どんどん拡大していきますので、チームを大きくしていく。その大きくなり方に課題がありました。
だんだん大きくなると、そもそもの組織の変化が必要になります。開発部門と企画部門を一緒にするとか、仮想を止めていくとかが必要になってきます。本日しゃべることがたくさんあるので、（スライドの）3番と6番について軽く説明しようかなと思います。
まずはチームの成長について。なんでチームの成長が必要かというと、継続的にサービスの価値を出していくためには、何が目的かをチームがちゃんと把握しながら進んでいく必要があります。そのために我々は、スキルアップの状況や自己組織化、チームワークを推進しています。スキルアップについては、会社内全体でTech-inというコミュニティを設けて、そこで横のつながりを推進しています。
自己組織化については、マネジメント層がコーチングをやったり1 on 1をやったりしながら、チームメンバーが自発的に動くように推進しています。チームワークについては、いろんな問題とか課題が出たときに、各スクラムイベントのPO間でコミュニティが取れるように、POコミュニティを立ち上げたりしています。
Tech-inをちょっと紹介します。社内でTech-inというコミュニティでイベントを開催して5分ぐらいライトニングトークすると、いろんな人が集まって会話をします。今ここに出ているような案件を、LTでしゃべってもらったりもしました。
その後、例えばIoT支部だったり、いろんなカテゴリに応じて支部が立ち上がってきています。各々のスキルを共有する状況が生まれてきているので、非常にいい事例かなと思っています。
アジャイル開発センター憲章
最後にアジャイル開発センター憲章を紹介したいと思います。最初にメンバー5人から始めて300人に広がりましたが、5人から300人はけっこうな規模になるんですよね。そうするとマイクロマネジメントがほとんど難しい状態になります。
先ほどの「チームで動いてください」という権限を渡すと、事細かく指示をしても、いい方向に向かないことがわかっているので、方向性だけこの中で示しています。こういったことを示すことによって、各チームが迷ったときに、定めた方向性に向かって走っていくのを推奨しようとします。コアバリューとしては、アジャイル開発ですので、アジリティを最先端にもってきています。
先ほども言ったんですが、開発に特化しているセンターでは、名前が「アジャイル開発センター」となっていますが、開発ではなくてビジネスなどを意識してやっていきましょうということで、ビジネスとテクノロジーと振る舞い。その3本に分けて、各々どうやって動いたらいいかを考えています。
もともとKDDIは、フィロソフィーとかいろいろあって、その配下にこれとつながって、実際のエンジニアが一番わかりやすい状態に落として説明しています。一番注目してもらいたいのは、カルチャーです。働く時はとにかく楽しくやることが非常に重要なので、そこを基盤として、働いていることを示しています。
もし興味があったら、KDDIが展開しているブログ「KDDI Cloud Blog」に、この背景とか詳細を記載していますので、ぜひご覧ください。
（次回につづく）
