デンソーが「mobi-Crews」をリリース
昨年のデブサミでデンソーは、「残業ゼロで開発スピードが10倍に！ もう元の開発体制には戻れないデンソー流のアジャイル開発」と題してセッションを行い、アジャイル開発のスタートを宣言した。多くのチームが社内向けシステムを手がけているものの、うち2017年末に発足したチームは顧客向けサービスを開発し、ほぼ1年で本番稼働にまでたどり着いた。
もともとデンソーはグローバルに自動車部品などを手がける企業だ。モノづくりが中心なので、ソフトウェア開発はECUなど限られた分野だった。しかし2017年4月にデジタルイノベーション室を新たな拠点で開設し、徐々にチームや人員を増やしてきた。新設時には社員2名だったところ、今では社員24名、協力会社の社員48名の合計72名でアジャイル開発を進めている。なおプロジェクトが終わったらチームは解散するのではなく、チームに新たなプロジェクトをアサインしている。
今回新しく開発したのは、「フリートオペレーションサービス mobi-Crews」。ドライブレコーダーをベースとした車載端末を用いて、車両位置や運転状況を管理者に送信するなどして安全性を高める。例えば急ブレーキが生じるようなヒヤリとする場面が発生すると、リアルタイムで管理者に動画が送られる。またドライバーや地点ごとの運転状況を分析し、安全運転指導に生かす。これは、自動車運転を伴う業務を対象としたサービスである。
mobi-Crewsは車載端末からの情報をデンソーが管理するセンターに送信し、社有車の管理者はこのセンターにアクセスして情報にアクセスする。eSIMを搭載した車載端末からセンターまでのデータ送信は既存インフラを活用するため、開発チームは主にバックエンドとフロントエンドを開発した。
デンソーのアジャイル開発はこう進めている
ここから開発の経緯を追っていこう。チームが発足したのは2017年末。開発チームは兼務せず、チームごとに専用の部屋が割り当てられているという。ここがポイントで、「閉じた環境のほうが周囲に気を遣わずに済みます」とデンソー 佐藤氏は指摘する。
同社においてアジャイル開発やスクラム開発は新しい取り組みとなる。プロジェクトには開発者以外にPO（プロダクトオーナー：ビジネス面での意思決定者）とSM（スクラムマスター：チーム開発のプロセス管理者）がいる。POは開発チームがいる新横浜だけではなく、顧客からの情報収集、車載器の開発責任者も兼任し、全体の情報を把握し決定権を持つ。佐藤氏は「POの存在がプロジェクトを円滑にしたポイントとなりました」と話した。
開発チームがいる部屋のホワイトボードには、メモがびっしり貼られている。左がバックログで上にあるものほど重要性が高くなる。中央が次にやるべきタスク。マグネットで「Ready/Not Ready」を分かるようにしているのもポイントだ。右が現在のタスク。「Doing/Review/Done」と段階が分かるようになっている。
チームは1週間を単位に動く。まず木曜日にスプリントのレビューやプランニングを行う。毎朝、今日のゴールを10分で確認、困っていることがあれば昼前に10分で共有する（解決策は後で考える）。水曜の午後に開発メンバー全体でレビューする、といった流れだ。
2018年4月からは顧客も関与するようになる（顧客巻き込みフェーズ）。佐藤氏は「アジャイルを理解してもらうことが大変でした。しかしそれが新しい価値提供につながりました」と話す。顧客には開発ルームにて、ドキュメントではなく、その時点で動作するソフトウェアの実物を見てもらうようにした。
佐藤氏らが注意したのは開発の複雑性を抑えることだった。具体的には並行バージョン開発は行わず、バックエンドとフロントエンドでソースコードを分けないようにした。一般的には顧客ごとにソースを分けることもあるが、同社では機能の切り替えなどを環境変数で制御するようにした。
アジャイル開発なので動きは速い。2018年7月には商用テストフェーズに突入した。ここでは機能追加の要請で開発規模が拡大するなか、どう対応していくかが課題となった。佐藤氏は「理想としてはメンバーを追加せずにスコープの調整で済ませられればいいのですが」と話すものの、現実は突然生じた不具合対応などで「間に合わない」状況だった。メンバー追加を避けたのは、チーム経験値に影響を及ぼすためだ。
複数チームで対応するとなると、コミュニケーションで問題が発生することが懸念された。そこで同一の開発部屋で、メイン機能開発チームとサブ機能開発チームの複数チーム開発体制で進めた。それぞれのチームにPOがいて、SMは両チームを見る。バックログの扱いを検討するのは各チームで行い、スクラムイベントは両チームで一緒に進めていった。
インフラ管理はコード化、テンプレート化、マネージドサービス積極活用
ここでいったん、視点をインフラ管理に向けよう。インフラ管理はアジャイル開発チーム全体が対象となる。2018年8月にはアジャイル開発チームは6つまで拡大した。限られた人数で6チームが要求するインフラを提供しなくてはならない。アジャイル開発なので構成変更に対応しなくてはならないこともある。開発メンバーがアプリケーション開発に専念できる環境が要求された。インフラチームにも生産性が求められていたことになる。
そこでインフラ担当はインフラをコード化し、横展開が可能となるようにテンプレート化して、工数削減に努めた。またインフラを担当した冨田氏は「極力マネージドサービスを使用して、運用や保守の負担を軽減しました」と話す。
インフラのコード化にはTerraformを用いた。これにより、たった1コマンドでインフラが作成可能となった。開発チームに提供されるインフラは個別カスタマイズした環境ではないため、インフラ構築時の設定ミスをなくし、「インフラは問題ない。アプリケーションを調べよう」といった具合に問題を切り分けることができるようになった。複雑性を排除することはトラブルシューティングにも役立つ。
アプリケーションのデプロイには、AWS Elastic Beanstalkを使うことにした。マネージドサービスなので構成管理の手間を減らし、障害発生時には自動復旧を頼ることができる。インフラ管理者の負担を大きく減らすことにつながっている。
ほかにも各種ツールやマネージドサービスがあるが、「本当に必要か。なぜ必要か」を確認しながら、できるだけ絞るように心がけたという。実際に使っているものを挙げると、ソースコード管理はBitbucket（Git）、アカウント管理はKeycloak、通知はSlack、データベースはAmazon Aurora、インフラや管理に関するものはほとんどがAWSのマネージドサービスが並ぶ。
「もう前の開発体制には戻れない」「みんなで作ると楽しい」
mobi-Crewsは2019年1月にリリースされた。本番運用になると、サービスが止まらないための「監視」、データ量が増えても劣化しない「性能」、大事な情報を守るための「セキュリティ」が重要になる。
こうした問題に対処するため、開発、検証、運用に強みを持つ、別チームを結成した。各プロジェクトで忘れがちな点を拾って対策し、さらにそのノウハウを横展開できるようにするためだ。
監視については必要なメトリクスを洗い出して横展開した。性能は性能評価用の環境を用意し、定期的に性能測定し、問題があれば対策案を提示できるようにした。セキュリティについては外部機関と連携してセキュリティ評価を実施し、こちらも問題があると判断されたら対策案を示せるようにした。こうして、一般向けサービスを提供できる組織体制も整ってきた。
最後に佐藤氏は、こうしたアジャイル開発を通じて「期待されているサービスを作っている実感があります。盤石なインフラのおかげでアプリケーション開発に専念できてうれしいです。もう前の開発体制には戻れません」と満足げに笑う。ほかにもメンバーからは「新しい技術に触れ、自分が進化しました」、「みんなで作ることがこんなに楽しいとは思いませんでした」、「みんなで解決する方式に安心感を覚えました」と喜びの声が上がっているという。
お問い合わせ
株式会社デンソー
