デンソーのアジャイル開発チームができるまで––チームビルディングにおける工夫と実装の裏側

デンソーのMaaS開発について

佐藤義永氏（以下、佐藤）：ご紹介ありがとうございます。デンソーの佐藤と冨田です。今日は「デンソーのMaaS開発が具体的にどんなことをやっているのか？」ということをご紹介できればと思っています。

でははじめに、私たちの自己紹介をいたします。佐藤義永と申します。私はエンジニアとして実装を担当しているんですが、大学で並列計算機を博士課程でやってきました。

その後、入社した会社では、組み込みのデータベースエンジンの実装や、ストレージのミドルウェア、あとはAI、ディープラーニングなどのアプリケーションの実装をしていたり、当然インフラに携わることもあったので、そういった知識を持っています。

デンソーへ転職してからはデベロッパーもやっていますし、本日ご紹介する内容であるMaaS開発で実際にサービスが開始しまして、そのなかでより良く安心して安全に使えるようにということで、SREチームを立ち上げて、担当しています。

冨田進氏（以下、冨田）：みなさま、おはようございます。冨田です。

僕は、2018年10月にデンソーに入社したので、まだトータルで4ヶ月ぐらいです。それ以前は、ソフトウェア事業部でJP1とか、あとはサーバーとストレージとスイッチを筐体にガッチャンコしたようなコンバージドプラットフォームというものがあるんですけど、それを管理するUCP Directorの開発に従事していました。

その後アメリカの会社に転職しました。そこでは、IoTプラットフォームのLumadaの開発をしていました。

今は佐藤さんと同じチームで、主にインフラ、AWSまわりの運用や構築をやっていて、あとはSREということで、いかに運用を止めないかとか、落ちないサービスを作っていくかというところで、日々活動しています。

今日は主にAWSまわりの話を説明したいなと思っております。もしかしたら少し技術的な話、インフラ寄りの話になっちゃうかもしれないんですけど、そのときは適宜言葉を補足しつつ説明したいと思います。よろしくお願いします。

前回のデブサミから1年、本番サービスを開始

佐藤：去年のデブサミで登壇させてもらったという話をしましたが、今回は去年からの続きの話になります。

デンソーという会社が主に作っているのは、クルマのエアコンやエンジンであるとか、吸排気系であるとか、そういったクルマのなかのハードの部品になります。

ITというと、社内のITインフラ、あとは組み込み系のエンジンECUとか、そういったところのソフトウェアが主体となっていて、サービスというものはほとんどやっていませんでした。当然Webアプリケーションもほとんど社内では手つかずで、あまり開発してないという状況でした。

今後、新しくカーシェアなどのMaaSを進めるにあたって、価値の中心がWebのクラウドのソフトウェアというところになってくるので、それをぜひ手の内化して、技術力を高めて、よりお客さんからの要望に迅速に応えられる体制を作っていく。そのために「デンソー、ITはじめます」という宣言をしたのが、去年の発表になります。

そのとき、3つの柱、1つは「ゼロからイチを創るためのデザイン思考を取り入れる」。そして、「早く作る、安く作る」。単純に安いから良いというわけではなくて、インフラの構築・維持、さらには早く出して、もしうまくいかなければもう一度やり直す、繰り返し試すという意味での「安く、早く」ですね。やるためのオープンソースやクラウドプラットフォームの利用。

最後に、「さらに一緒にお客さんと一緒に創りながら考えていきましょう」というための、内製化、アジャイル開発。この3本を押していきましょう、ということを話させてもらいました。

この発表をした後、去年のデブサミのアンケートや、講演後のAsk the Speakerなどで、「具体的にプロジェクトでどうやっているか？」「デンソーさんならではの話を聞きたい」というご要望をたくさんいただきました。

この、1年の間に実際に本番サービスを開始いたしました。そのプロジェクトを具体的にご紹介させていただきながら、「デンソーはどんなことをやってきたのか？」ということを、みなさんに知っていただければと思っています。

とくに、本番サービスというところが非常に苦労した部分でして、最初にサービスを始めるための知見がない場合には、トラブルに遭遇します。そういったものをなるべく低減して、うまくサービスインしていくためにどんなことをやってきたのか、ということの参考になればと思っております。

MaaS開発部デジタルイノベーション室がリリースした「mobi-Crews」

では、実際にプロジェクトを進めてくるにあたって、どんな組織構造でやってきたのかということをご紹介いたします。

我々が所属するMaaS開発部デジタルイノベーション室は、2017年4月に設立いたしました。その翌5月に私も参画し、トータル4名体制で、新横浜にガレージみたいなかたちでオフィスを立ち上げました。

そこから5月末に協力会社さんも入っていただいて、一番最初のアジャイル開発チームが発足し、そこからだいたい3ヶ月おきですかね、第1チーム、第2チーム、第3チームと立ち上げていくことになります。

本日ご紹介するのが、第3チームでやってきたクルマのサービスになります。その後、第4、第5、第6と立ち上げ、サービスインする直前にSREチームを発足したのが2018年11月となります。

トータルで社員数24名、あとパートナーさんとして入っていただいているのが現在48名で、（合計）72名でやっています。

我々の体制としては、プロジェクト主体のチームではなくて、本当にチームごとにそれぞれ独立した体制になっているので、プロジェクトが解散したからメンバーも解散といった体制ではなくて、あくまでもそのチームにプロジェクトをアサインする、あるプロジェクトが終われば、そのチームに新しいプロジェクトをアサインする、という体制でやっています。

すでに第1、第2チームなどは、もう2つ3つとプロジェクトをこなしています。一方で、第3チームは、このときはじめたプロジェクトを商用として今回リリースいたしております。

リリースしたサービスがこちら、「mobi-Crews」という名前になります。

mobi-Crewsは営業車向けサービスです。営業車というと、例えばある会社のなかでなにか販売する車両であるとか、なにかを配送するようなサービスであるとか、そういったことをやっている業者さんでは、当然それらのクルマを管理する必要があります。

それらのクルマを管理するためにどんなことをやっていたかというと、クルマの台帳に「今日はどこどこ走りました」「誰がどこをどんなクルマで走りました」というのを記入したり、「飲酒運転してないですよね？」「免許はきちんと携帯して、有効期限大丈夫ですよね？」というのを管理しなければいけないんですが、それを紙ベースでやっていたところがけっこう多いんですね。いまだに多いと聞いています。

それをまずは自動化します。そしてクラウドのなかですべてシステム化して、提供いたします。

それだけではなくて、さらにドライブレコーダーが、当然いろんなところで使われるようになってきております。ドライブレコーダーも、これまでのただ付けるだけのものですと、SDカードに記録されていればそれを走り終わったときに抜き取って、パソコンに差し込んで動画を抜き出す作業が当然必要ですし、なにかトラブルがあっても、会社に戻ってくる、あるいは電話で一報を投げるまでは誰も状況がわからない、というような状況です。

これらを、なるべく即時対応できる、あるいは自動化して人の手がかからないようにしてあげようというのが、今回のmobi-Crewsのコンセプトになります。

具体的には、こちらの絵で示す左側のクルマに、まずドライブレコーダー型の通信端末を設置します。

このドライブレコーダーにはeSIMが内蔵されており、そこから電話回線網を通じて、具体的にセンターのほうにデータを飛ばします。

そのときに定期的に飛ばすのが、「いまどこを走ってますよ」というデータや、「そのときの前後や左右にどれぐらいのG値がかかったか？」ということ、それから「どれぐらいの速度で走ったか？」といった細かい情報もありますし、もし大きな衝撃を検知すれば、そのときに一緒にドライブレコーダーで撮っている動画を抜き出して転送することもできます。そうすることで、センター側はそれを受信し、あとはユーザー側に「こういうことがありました」と通知をすることで、ほぼリアルタイムで事故情報を見ることができます。

あるいは、走行情報をまとめあげれば、「いまどこを走ってますか？」「どういう走行をしましたか？」「1日何キロ走りましたか？」ということが一目でわかります。

（スライドの）右側の例で話していますが、例えば急ブレーキでヒヤリハットがあったらリアルタイムで送信されます。

ヒヤリハットがあるときに、何が原因だったのかということを分析しようと思ったときに、例えばいろんなことが考えられますよね。クルマが飛び出してきたかもしれないし、スピードを出しすぎて運転してたかもしれないし、ちょっと居眠りみたいなことをしてしまったかもしれない。

それらの要因を即時、さまざまなデータを使って解析することができます。安心・安全のためにこれらを利用することで、世の中に走っているクルマの約半分ぐらいが営業車と聞いているので、みなさまの安全に寄与できるシステムなのではないかと考えております。

サービスを支える技術の説明

サービスの話はこれぐらいにしまして、具体的にどんな技術を使っているか、どのように開発したのか、ということをお話しします。

まず全体の概要なんですが、我々のチームで作ってきたのは、このなかで言う「バックエンドサーバ」と「フロントエンドサーバ」というところになります。

車載器というのは一番左側のドライブレコーダーですね。ドライブレコーダーもデンソーで作っています。そこと接続されるIoT基盤も既存のものを使いました。その後、バックエンド・フロントエンドという、今回のサービスを提供する心臓部を我々のチームで開発いたしました。

主な開発技術を（スライドの）下から説明していきます。まず開発現場のところで、プロセスとしてはスクラム開発を使っています。

さらに、なるべく本番環境と我々の開発環境の動作環境を同じにしたいので、仮想環境としてDockerをインストールして、例えばWindowsであればDocker for Windowsを導入しています。アプリケーションはRuby on Railsを使っていて、Ruby on RailsをそのままDockerのなかでDocker Composeを使って動かす。それでまったく本番と同じような環境で動くという状況を再現させています。

自動テストや静的解析には、CircleCIやCodeClimateを使って、これもなるべく自動的に、なるべくヒューマンエラーが入らないようなかたちで使っています。

バックエンドサーバ・フロントエンドサーバはAWS上にありまして、インフラの実際のプロビジョニングにはTerraformという技術を使って自動的にやっています。

アプリケーションデプロイにはElastic Beanstalkを使って、こちらも自動的にローリングアップデートをかけて、都度最初のデータ、最新のアプリケーションのバージョンが適用されるようにしております。

さらにデータベースですが、各種マネージドサービスを使っていて、具体的にはこの後ご紹介いたします。それで、同じくDockerを動かして、そのなかでRuby on Rails（を使っている）。開発環境と同じですね。これが、まず全体の技術のマップになります。

チーム立ち上げ期のポイント

それでは、我々の取り組みのヒストリーを使いながら、「どのように立ち上げから商用まで持っていったか？」というところを、ご紹介したいと思います。

2017年12月にチームが一番最初に立ち上がりました。

環境で大切なことの1つ目、この積み上げのピラミッドの一番下の土台がとても重要です。「きちんとメンバーが安心して開発できる開発ルームを構築しよう」「チームビルディングもしよう」「どんなアジャイルイベントが必要か？」というところを考えて、整理していきました。

立ち上げ期に我々がとくに力を入れたのは、環境としてはまず専用の開発ルームを用意することです。

2つ目に、おそらくアジャイル開発ではよく言われていることだとは思うんです。「こうやりましょう」「ああやりましょう」と議論をしたり、お客さんを議論に巻き込むたびに、お客さんも開発ルームに入ることがあります。そんなときクローズドな環境でないと、大きな声でしゃべり合ったりして、とにかくうるさくなるんですね。きちんとなかで閉じたほうが他に気を遣わなくていいですし、あるいは別に会議室を押さえてそこでやらなきゃいけないとか、そういったファシリティも必要ないので、専用開発ルームを用意するということが非常に有用です。

開発メンバーについても、やっぱり兼務をさせずに専任化させてあげて、きちんとこのプロジェクトに100パーセント関わるようにする。例えば、設計のときちょっと顔を出して、あとはいなくなってしまうと、実際その人が何を考えてたのか後から確認しなければいけない。その分だけ待ち時間が出てしまうので、当然専任化することが重要です。

3つ目はスクラムコーチですね。我々のようにまだスクラムを始めて間もないチームですと、「こういうときどうしたらいいだろうか？」「こうしたらいいんじゃないか」と、けっこう間違ったほうに舵を切ってしまうことも、やっぱり多々ありました。

そういうときに、スクラムコーチに入っていただくと……我々の場合だと吉羽龍太郎さんに入っていただいてるんですけれども、「こういうときはこうしたほうがいいよ」とか、「こういうときには、一般的にはこういうことをやるよ」「Webアプリケーションの開発の基本はこうだよ」とか、いろんなところでアドバイスをいただくことができます。

デベロッパーはPO（プロダクトオーナー）の間でも、「優先順位はこうなんじゃないか」という議論をするんですけども、その際も、利害関係のない第三者の存在が、非常に重要だと思っています。

次にPOの関わり方です。スクラム開発のなかで一番忙しくなるのは、おそらくPO。少なくとも我々の開発現場ではそうです。POにきちんと聞けば、すべての意見が一本化できるということが非常に重要で、そのPOがきちんと判断できるということが重要になってきます。

我々の場合、（スライドに）「新横浜」と書いてある我々の開発の部屋に、1週間のうち4割いていただく。当然お客さんの要望を聞いてもらわなければ、本当にこれでいいのかわからなくなってくるので、4割行っていただく。あと、IoTの開発の場合だと、モノとインターネットをつなげなければいけないので、例えばクルマにおけるドライブレコーダーになにか不具合があったり、仕様の漏れがあったり、あるいは齟齬があったりすると、当然上がってきたデータが予期しないものになってしまうので、そこのつながりが重要です。

全体の情報が把握できて、決定権があるPOというのが重要で、これが円滑に進んだ理由の1つかなと考えています。

ホワイトボードの全体レイアウト

続きまして、実際の開発部屋です。ホワイトボードの全体レイアウトというのは、多くの方から「どうなってるんですか？」と聞かれるので、ご紹介したいと思います。

我々は、左から右に時間が流れるようにバックログを置いています。左側が一番遠い未来で、逆に一番右側に現在やっているスプリントのバックログをやっております。一番左側から説明していきますね。

左側が実際お客さんが「ほしい」と言っているもの、上側が新しいもの、「できればほしいな」というもの、下側が「ちょっとあまりいらないけど、あったらうれしいかな」、あるいは「遠い将来、こんなのがあったらいいな」というのが書かれています。

そして、真ん中が来週やるもの。来週やるものをここに移動してきて、なるべく細かくしています。

実際そのスプリントに入ったときに作るものがまだ決まってないという状況になってしまうと、エンジニア、デベロッパーは動けないし、待ちに入ってしまって、そのまま開発に入ってしまうとそこのタスクがいわゆるボトルネックになってしまうので。

こういったものをなるべく外すように、我々は「READY」「NOT READY」というマグネットを用意して、最初は赤の「NOT READY」なんですけども、これをひっくり返すと「READY」になるようなマグネットを使っています。

それで、一番右側ですね。これがいま現在取り組んでいるバックログです。一番上側にスプリントの振り返り、レトロスペクティブで出た改善を挙げています。改善を一番上に置いているのは、やっぱり改善をすることで、そのスプリントのベロシティ、バックログを早く終わらせる速度が速くなるはずだという前提に立って、改善を一番上に置いて最優先でやっていく、という体制を取っております。

1週間のスケジュール

我々はスプリントというかたちで、1週間で1つの工程を終えます。

まず、すべてのはじまりは木曜日にあります。木曜日というのはメンバーのスケジュールの都合なので、プロジェクトによって変わってくるとは思うんですけれども、我々は木曜日に置いています。

それで、木曜日の午前中にスプリントレビューというのを置いておりまして、ここが一番重要なポイントで、お客さんと一緒に作ったものをレビューする場になります。なので、お客さんに具体的に作ったものを見せて、「これ、どうですか？」「これ、お客さんが求めたとおりのものですか？」というところを詰めていくと。

逆に、「あ、そうだね」となれば、「でも、やっぱりもうちょっとこうしたらおもしろいよね」と。ここで実際に動くものを見せることができるので、動くものを見せることで、具体的にさらにもう一度フィードバックをもらう。そしてそれをまた次のバックログに反映していくというかたちを行っていきます。

このスプリントレビューが終わった後、チーム内で振り返りをやります。スプリントレビューもチーム内で誰か1人だけが説明するとか、リーダー的が説明するということはせず、あくまでもチーム全員でローテーションしています。もうベテランも若手も関係なくローテーションすることで、我々が作っているものをきちんとみんなが理解して、責任を持って作っていけるような体制を作っていきたいと思いやっています。

レトロをやって、あとはスプリングプランニングもやっていきます。スプリングプランニングは午後早くても2時間、3～4時間かかることもあります。それをやって、1週間分のやることを構築し、わからなければ絵を描いてます。

その後のスプリントの日々は、朝10分間朝会をやって、その日のゴール、「今日はどこまでやるんだっけ？」という目標を共有する。逆にできそうでなければ、途中でPOに対して「今日これできなそうです。できない場合には、優先順位はこのままでいいですか？」というのを聞いています。

その後、1スロット50分程度で回していき、適宜休憩をはさんでデイリースクラムに入ると。デイリースクラムは、いま着手中のもので困っていることを共有し、あくまでも解決策だけの議論はしないで、「いま困ってることは何ですか？　じゃあ、その解決策を午後話しましょう」というところまできちんと意識合わせをする、という場です。

夕会には、新しい技術や設計を共有するような場を設けています。例えば、調査系のバックログなんかもよくあるわけですけれども、例えば「こういうとき、どういったJavaScriptのプラグインを使ったらうまくいくかな？」とか、カレンダー機能やタイムライン機能など、いろんな新しいJavaScriptを入れようと思ったときに、「どういうふうな使い方がいいんだろうね？」というのをみんなで共有したり、議論する場としていますね。

最後、水曜日の夕方午後には、翌日にスプリントレビューが控えているので、お客さんに見せるためのデモなど準備します。みんなでプロダクトを触って、「こんなのでいいかな？」「お客さんにどう見せたら伝わりやすいかな？」「どうやったらお客さんからより良い意見、あるいは希望を引き出せるかな？」ということを話し合いながら、準備したプロダクトを遊んでいくといったことをやっています。

アジャイル開発の理解を浸透させる

続いて、実際お客さんをさらに巻き込んで、「実際のサービスをどうしましょうか？」という話になっていきます。

「なるべくここまでにこれぐらいの機能がほしい」というお尻が決まってきますね。「じゃあ、アジャイル開発の場合どうやるんですか？」と。

お客さんが複数いる場合、お客さんごとのカスタイマイズも入ってくるので、「そのときにコードをなるべく複雑化させないような並行開発をどうやるか？」をご紹介いたします。

動作するソフトウェアを見せるというのがアジャイル開発の基本ですね。これはとても重要です。結局動かないからといって、ドキュメントだけで紹介をすると、齟齬が生まれてしまう。1回やってしまうと、次もそうなりがちになってしまう。

「まだ途中で、ここまでしか動かない」でもいいので、まずは実際に動くものをお客さんに見せて、お客さんと「なんでここまでしかできなかったんだろうね？」というのを一緒に議論して解決していくことが、とても重要です。

我々だと技術顧問の及川卓也さんに入っていただいているんですけれども、第三者から意見をいただいて、お客さんも含めて全員で話し合うというところで、アジャイル開発を浸透させていくというのがいいと思います。エンジニアも一緒になって話して解決していくことが重要だと考えています。

あと、開発の複雑度ですね。我々はなるべくいろんなものを「しない」ということを、割り切ってやっています。

例えば、並行バージョンというのは、もう開発しないと考えています。

例えば複数顧客向けに、A社向けのリポジトリ、B社向けのリポジトリとして、リポジトリを分けるというのも1つのやり方だと思うんですけれども、そうなってくると、当然リポジトリのスイッチも大変ですし、どっちにどのパッチを当てたかというのもわかんなくなってきてしまうので。

当然それを管理するようなツールもあるんですけれども、それを入れるとプロセスがどんどん積み重なって重くなってしまうので、なるべくやりたくないということで、ソースコードを分けずブランチも切らないというのを、我々はなるべく意識してやっています。

機能の切り替えは、我々はいまのところ環境変数でやっています。この後ご紹介するAWSのマジ―ジドサービスのElastic Beanstalkだと、簡単に環境変数の切り替えができるので、そういったものをうまく使って、環境変数だけで各お客さん向けのサービスをリリースしています。

あと、（冒頭で）「バックエンドとフロントエンドの2つを作っている」と言ったんですけど、当然フロントエンド側はお客さんに対してWebアプリケーションの画面を提供するもので、バックエンドはバッチ処理やIoT基盤からデータを引っ張ってくるような機能を提供するんですけど、それらでソースコードを分けずに、まったく同じソースコードでやっています。

これも環境変数で、バックエンドとして動くのか、フロントエンドとして動くのかということをコントロールしています。これをせずにバックエンド・フロントエンドでソースを分けてしまってリポジトリを分けると、当然データベースの……Railsでいうmodelですね。modelのマイグレーションファイルが分かれてしまって、データベースのスキーマが変わってしまって。

例えば、スキーマを変えた瞬間に、「このバージョンだと動くけど別のバージョンだと動かない」とか、「このプルリクをこなすためには、バックエンドをこのバージョンにしなくちゃいけない」とか、いろんな制約が出てきてしまって、テストにとても時間がかかってしまうので、ソースコードを全部一緒にしてしまうというのは、非常に有効でした。

デベロッパーとしても、同じソースコード上にバックエンド・フロントエンド両方入っているので、フロントを触った人も自然にバックの知識も蓄えられていくことになるので、こういったところが、同時に進めていくには非常に有効でした。

規模拡大に対応するためのチーム編成

では、いよいよ、ここまで顧客を巻き込んできて、次に、「じゃあ、商用で実際に使われます」というところに来ました。

こうなってくると、機能追加も、やっぱり「もっとこうしたいよね」という要望がどんどん出てくるし、お客さんのニーズや実際の台数も増えてきたりすると、規模拡大も出てきてしまうので、対応に追われていくシーンもありました。

そして、メンバー。開発のボリュームが増えるにつれて、「メンバーを追加したほうがいいんじゃないの？」という話もあって、その場合にはメンバーは追加しないでスコープ調整をするというのが理想なんですけれども、ただ実際はなかなか間に合わないのが現実です。

なので、我々はチームを2つ用意しました。メイン機能チームとサブ機能チームという2つに割って、メインチームのほうに独立したPOを押さえ、POとDEVというかたちで、切り分けられる機能を分ける。

ただし、スクラムイベントは一緒にやります。あと、各チームでバックログの扱いを分けたり、あとはたまに一緒にやってみたり、というのも織り交ぜながら、うまいこと折り合いをつけながら、チーム体制を構築し、メンバー増員に対応しました。

では、「アジャイル開発を支えるインフラ」として、ここでスピーカーを冨田さんにお願いします。