翔泳社主催のソフトウェア開発者向けITカンファレンス「Developers Summit 2019」が2月14日～15日に開催されました。セッション「デンソーのMaaS開発～アジャイル開発で顧客との協調・チームビルディング・実装概要～ 」に登壇したのは、当社MaaS開発部デジタルイノベーション室の佐藤義永と冨田進。昨年のDevelopers Summitで発表した内容をベースに、この1年で実際にサービスをリリースするまでの知見やアジャイル開発・チームビルディングについて語りました。

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

はじめに、去年のデブサミでもおうかがいしましたが、デンソーという会社を「知ってますよ」という人、どれぐらいいますか？

（会場挙手）

おー。ありがとうございます。デンソーはB to B向けのビジネスをメインでやっているものですから、去年はご存知ないエンジニアの方も多くて、「ダイソーですか？」「電通ですか？」とか、そういうふうに間違われることがけっこう多かったんですね。

（会場笑）

ただ、我々MaaS開発を始めて2年経つんですけれども、この2年の間に、デブサミも含めて外で「こんなことやってますよ」という発表をさまざまさせてもらっていて、少しずつ知名度が上がってきているのであればうれしいなと思いますし、今日の話をぜひ楽しんで聞いていただけたらなと思っています。よろしくお願いいたします。

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

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

デンソーに入社した理由は、「アジャイルでいろんなおもしろいことやりたいな」と思ったからです。現在はデベロッパーもやっていますし、本日ご紹介する内容であるMaaS開発で実際にサービスが開始しまして、そのなかでより良く安心して安全に使えるようにということで、SREチームを立ち上げて、担当しています。

冨田進（以下、冨田）：みなさま、おはようございます。冨田です。私も自己紹介させていただきます。

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

その後、紆余曲折あって、いったんアメリカの日系企業に転職しました。そこでは、IoTプラットフォームのLumadaの開発をしていました。

2018年のデブサミの開発資料を偶然インターネット経由で見たときに、「なんかおもしろそうだな」「開発スタイル楽しそうだな」と興味を持って、10月にデンソーへ入社しました。

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

今日は主にAWSまわりの話を説明したいなと思っております。

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

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

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

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

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

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

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

なので去年から1年経ち、この1年の間に実際に本番サービスを開始したプロジェクトを、ご紹介させていただこうと思います。

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

では、実際にプロジェクトを進めてくるにあたって、我々が所属するMaaS開発部デジタルイノベーション室とその成り立ちをご紹介いたします。

我々の部署は、2017年4月に設立いたしました。その翌5月に私もジョインいたしまして、トータル4名体制で、新横浜にガレージみたいなかたちでオフィスを立ち上げました。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まず立ち上げとしては、2017年12月にチームが一番最初に立ち上がった頃の話になります。

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

立ち上げるために我々がとくに力を入れたところですが、環境としてはまず専用の開発ルームを用意することが重要かと思っております。

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

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

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

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

あとは、デベロッパーはPO（プロダクトオーナー）の間でも、「優先順位はこうなんじゃないか」という議論をしたりするんですけれども、そういうときにも、やっぱり利害関係のない第三者のスクラムコーチがいるというのは、非常に重要だと思っています。

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

我々の場合、（スライドに）「新横浜」と書いてあるのは我々の開発の部屋なんですけれども、ここに1週間のうち4割ぐらいはいていただく。あと、当然お客さんの要望を聞いてもらわなければ、開発自体が本当にこれでいいのかということがわからなくなってくるので、4割行っていただく。あと、IoTの開発の場合だと、モノとインターネットをつなげなければいけないので、例えばクルマにおけるドライブレコーダーになにか不具合があったり、仕様の漏れがあったり、あるいは齟齬があったりすると、当然上がってきたデータが予期しないものになってしまうので、そこのつながりが重要で。やっぱりそこに2割ぐらい軸足を置いている方に、POになっていただきました。そういったことで、全体の情報が把握できて決定権がある方というのが重要で、これが円滑に進んだ理由の1つかなと考えています。

続きまして、実際に開発部屋で「どんなことを紹介しようかな？」と考えたんですけれども、ホワイトボードの全体レイアウトというのは、意外と見学に来ていただいている方……我々の開発部屋はいろいろ見学に来ていただいているんですけれども、「ホワイトボードはどうなってるんですか？」と聞かれるので、ちょっとご紹介したいと思います。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

これは「お腹が空いているので早めに終わらせましょう」というところもあって、お昼ぐらいにデイリースクラムを置いています。

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

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

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

「なるべくここまでにこれぐらいの機能がほしい」という要望がきまってきます。では「アジャイル開発の場合どうやるんですか？」と。

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

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

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

それは開発ルームで一緒に検討できる場があるというのも重要です。また、第三者の意見として、アジャイルコーチや外部顧問の方に入っていただいて、我々は及川卓也さんに入っていただいているんですけれども、お客さんも含めて全員で話し合うことで、アジャイル開発を浸透させていくというのがいいと思います。

従来だと、どこかの会議室で「なんでこうなったんだ？」というのを上層部だけで話をする、なんていうことがけっこう多かったと思うんですけれども、エンジニアも一緒になって話して解決していくことが重要だと考えています。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

近日公開予定：続編「アジャイル開発を支えるインフラ」