Shoeisha Technology Media

CodeZine(コードジン)

特集ページ一覧

アジャイル開発チーム発足からわずか1年でMaaSリリース! デンソーのチームビルディング【デブサミ2019】

【15-D-2】デンソーのMaaS開発~アジャイル開発で顧客との協調・チームビルディング・実装概要~

  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加
2019/05/10 12:00

 デンソーは2017年からデジタルイノベーション室を新設し、アジャイル開発を始めた。そしてたった1年で顧客向けにMaaSの新サービスを提供するまでに至った。デンソーの開発体制やアジャイル開発を通じて得た知見を、同社 佐藤義永氏と冨田進氏が発表した。

目次

デンソーが「mobi-Crews」をリリース

 昨年のデブサミでデンソーは、「残業ゼロで開発スピードが10倍に! もう元の開発体制には戻れないデンソー流のアジャイル開発」と題してセッションを行い、アジャイル開発のスタートを宣言した。多くのチームが社内向けシステムを手がけているものの、うち2017年末に発足したチームは顧客向けサービスを開発し、ほぼ1年で本番稼働にまでたどり着いた。

 もともとデンソーはグローバルに自動車部品などを手がける企業だ。モノづくりが中心なので、ソフトウェア開発はECUなど限られた分野だった。しかし2017年4月にデジタルイノベーション室を新たな拠点で開設し、徐々にチームや人員を増やしてきた。新設時には社員2名だったところ、今では社員24名、協力会社の社員48名の合計72名でアジャイル開発を進めている。なおプロジェクトが終わったらチームは解散するのではなく、チームに新たなプロジェクトをアサインしている。

 今回新しく開発したのは、「フリートオペレーションサービス mobi-Crews」。ドライブレコーダーをベースとした車載端末を用いて、車両位置や運転状況を管理者に送信するなどして安全性を高める。例えば急ブレーキが生じるようなヒヤリとする場面が発生すると、リアルタイムで管理者に動画が送られる。またドライバーや地点ごとの運転状況を分析し、安全運転指導に生かす。これは、自動車運転を伴う業務を対象としたサービスである。

 mobi-Crewsは車載端末からの情報をデンソーが管理するセンターに送信し、社有車の管理者はこのセンターにアクセスして情報にアクセスする。eSIMを搭載した車載端末からセンターまでのデータ送信は既存インフラを活用するため、開発チームは主にバックエンドとフロントエンドを開発した。

デンソーのアジャイル開発はこう進めている

 ここから開発の経緯を追っていこう。チームが発足したのは2017年末。開発チームは兼務せず、チームごとに専用の部屋が割り当てられているという。ここがポイントで、「閉じた環境のほうが周囲に気を遣わずに済みます」とデンソー 佐藤氏は指摘する。

株式会社デンソー MaaS開発部 デジタルイノベーション室 SREチーム チーフエンジニア 佐藤義永氏
株式会社デンソー MaaS開発部 デジタルイノベーション室 SREチーム チーフエンジニア 佐藤義永氏

 同社においてアジャイル開発やスクラム開発は新しい取り組みとなる。プロジェクトには開発者以外にPO(プロダクトオーナー:ビジネス面での意思決定者)とSM(スクラムマスター:チーム開発のプロセス管理者)がいる。POは開発チームがいる新横浜だけではなく、顧客からの情報収集、車載器の開発責任者も兼任し、全体の情報を把握し決定権を持つ。佐藤氏は「POの存在がプロジェクトを円滑にしたポイントとなりました」と話した。

 開発チームがいる部屋のホワイトボードには、メモがびっしり貼られている。左がバックログで上にあるものほど重要性が高くなる。中央が次にやるべきタスク。マグネットで「Ready/Not Ready」を分かるようにしているのもポイントだ。右が現在のタスク。「Doing/Review/Done」と段階が分かるようになっている。

 チームは1週間を単位に動く。まず木曜日にスプリントのレビューやプランニングを行う。毎朝、今日のゴールを10分で確認、困っていることがあれば昼前に10分で共有する(解決策は後で考える)。水曜の午後に開発メンバー全体でレビューする、といった流れだ。

 2018年4月からは顧客も関与するようになる(顧客巻き込みフェーズ)。佐藤氏は「アジャイルを理解してもらうことが大変でした。しかしそれが新しい価値提供につながりました」と話す。顧客には開発ルームにて、ドキュメントではなく、その時点で動作するソフトウェアの実物を見てもらうようにした。

 佐藤氏らが注意したのは開発の複雑性を抑えることだった。具体的には並行バージョン開発は行わず、バックエンドとフロントエンドでソースコードを分けないようにした。一般的には顧客ごとにソースを分けることもあるが、同社では機能の切り替えなどを環境変数で制御するようにした。

 アジャイル開発なので動きは速い。2018年7月には商用テストフェーズに突入した。ここでは機能追加の要請で開発規模が拡大するなか、どう対応していくかが課題となった。佐藤氏は「理想としてはメンバーを追加せずにスコープの調整で済ませられればいいのですが」と話すものの、現実は突然生じた不具合対応などで「間に合わない」状況だった。メンバー追加を避けたのは、チーム経験値に影響を及ぼすためだ。

 複数チームで対応するとなると、コミュニケーションで問題が発生することが懸念された。そこで同一の開発部屋で、メイン機能開発チームとサブ機能開発チームの複数チーム開発体制で進めた。それぞれのチームにPOがいて、SMは両チームを見る。バックログの扱いを検討するのは各チームで行い、スクラムイベントは両チームで一緒に進めていった。


  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

バックナンバー

連載:【デブサミ2019】セッションレポート

もっと読む

All contents copyright © 2005-2019 Shoeisha Co., Ltd. All rights reserved. ver.1.5