アーカイブ動画
■登壇者プロフィール
ダイキン工業株式会社
空調生産本部 商品開発グループ
ITデバイス開発エグゼクティブリーダー 主席技師 橋本 雅文氏
空調機の省エネ性を左右するインバータの組込みエンジニアを経験した後に商品のエンベデットシステムにおいてハードウエアを筆頭に、組込みシステムからコネクテッドと、ステージを拡大して開発責任者を歴任。２０１９年より、ＩＴソリューション分野のエクゼクティブリーダとして組込みソフトウエアからＩｏＴクラウドまで空調システム全体の開発を統括している。
ダイキン工業株式会社
空調生産本部 商品開発グループ 主任技師 佐藤 智宏氏
住宅用ルームエアコンの制御ソフトウェア設計の開発担当者を経験後、住宅用商品のソフトウェア開発に従事。現在は、住宅用のIoTを用いたコンシューマ向けシステムの開発責任者を担当。
ダイキン工業株式会社
空調生産本部 商品開発グループ 主任技師 北村 拓也氏
SIerで自社プロダクト開発のPM、ベンチャーのコンサル会社で技術導入とアジャイル導入のコンサルタントを経て、2017年にダイキン工業に入社。現在は、空調IoTサービスを実現するため自社IoTプラットフォームの開発責任者を担当。
ダイキン工業株式会社
テクノロジー・イノベーションセンター 前川 博志氏
製造業やWebサービス企業での開発経験を経て、IoTプラットフォームのSRE業務を経験。現在はベンチャーと連携した新サービスのアーキテクトを務める一方、様々なプロジェクトの開発における困りごとをサポートし、グループ規模でソフトウェア開発の最適化を目指している。
顧客データをもとに、空調システムの新たな価値を創造
最初に登壇した橋本雅文氏は、ダイキンの特徴を説明した。
「皆さんがイメージされているように、ダイキンはまさしくエアコンの会社です。実際、従業員の多くは朝から晩までエアコンのことばかり考え、仕事に臨んでいます」（橋本氏）
▲空調生産本部 商品開発グループ ITデバイス開発エグゼクティブリーダー主席技師 橋本 雅文氏
実際、同社の2019年度の売上2兆5503億円のうち、約9割が空調事業である。2000年に入ってからは海外展開も積極的で、現在は160カ国以上で事業を展開、生産拠点は90拠点以上となった。
アフリカからロシアなど全世界・幅広い地域で展開しており、売上のシェアも約8割が海外を占める、まさにエアコンをグローバルに展開する企業と言える。
なぜ、世界各地に100か所以上の生産拠点を持っているのか。その理由は、エアコンがその土地特有の気候や文化の影響を大きく受けるからだ。
「世界には様々な気候や風土・人の生活があり、建物にも違いがあります。そのため、デザインから利用用途まで、各地に適した多様なエアコンを開発する必要があります。
エアコンは他の家電とは異なり、設置やメンテナンスの際には専門知識が必要です。電気をそれなりに消費する家電ですし、フロンガスも環境に負荷を与えるため、地球温暖化などの環境問題も我々の解決すべき課題だと思っています。
また、『良い空気』とは何なのか、快適とは何か。空気というのは文字通り、なかなかつかみづらいところがあります。」（橋本氏）
このような課題をデータやソフトウエアで解決しようと、全世界の空調機をインターネットでつなげ、クラウド、機械学習などの技術を活用した「グローバル空調IoTプラットフォーム」の構築を進めている。
そして、同プラットフォームから得たデータを、従来のハードウエアや組み込みソフトウエアによる機能としてだけではなく、スマホアプリなどのソフトウエアサービスとして提供していく。その結果、顧客全員が真に望む、空調の価値を創造する。
つまり、単なるエアコンという製品価値だけではなく、「ソフトウェアやデータを活用して空気・空間を的確に制御し、利用者に快適な環境を提供する」ことこそ、これからのダイキンが目指す価値だと強調し、最初のセッションを締めた。
IoTとデータ活用で新たなプロダクトサービス開発を目指す
続いて登壇した佐藤智宏氏は、住宅用の遠隔操作ダイキンスマートアプリの歴史や現状の開発体制、IoTプラットフォームのアーキテクチャならびにデータ解析を活用したサービス事例を紹介した。
▲空調生産本部 商品開発グループ 主任技師 佐藤 智宏氏
「まずはエアコンに無線LANアダプタを装着しました。当初は外付けでしたが、現在では内蔵型となっていて、室外機や空気清浄機など、多くの製品に備えています。無線LANアダプタの規格は、スマートハウスを実現（構成）する『HEMS（Home Energy Management System：ホーム エネルギー マネジメント システム）』に対応する通信プロトコル、『ECHONET Lite規格』を採用。AlexaやGoogle Homeなどのスマートスピーカーにも対応します」（佐藤氏）
グローバル連携のプラットフォームアーキテクチャについては上記の図のとおりだ。
まず、以前のAmazon RDS（Amazon Relational Database Service）から、AWS Lambdaを使ったAWSのサーバーレスアーキテクチャにシフトした。
同プラットフォームにより、全世界で数千万台以上提供してきたエアコンや空気清浄機といったデバイスから大量データの取得。BIツールによる見える化なども行いデータを解析し、新たなサービスの創造や開発につなげようとしている。
たとえば、今回の新型コロナウイルスの影響を受け、自宅で過ごす機会が増えたことで、エアコンの利用時間が前年に比べて増えていることがわかった。
・リモコンには豊富な機能ボタンがあるが、約6割は使われていない。
・自動運転はメーカーの想定より利用されていない。
・室外機は場所によっては想定以上の高温に晒されている。
例えばIoT化することで、上記のようなことが多く見えてきたという。
「リアルタイムな空調データが豊富に取得できるようになったことで、今後は、同データを素早く分析できます。どのようなプロダクト・サービスを開発すれば、ユーザーに満足してもらえるのか。その仮設立案・検証をスピーディーに行い、市場に素早く投入します。
戻ってきたフィードバックを再び検証する。このようなループを高速でまわすハイサイクルな開発体制を続けていくことで、ユーザーが快適に過ごせる環境を実現していきたいと考えています」（佐藤氏）
佐藤氏が説明しているのは、まさにアジャイルな開発体制だ。実際、ベンチャーとの協創で、データ活用を反映したプロダクト・サービス的な製品もローンチしている。AI搭載のエアコンコントローラー「Beside（ビサイド）」だ。
Besideは香港のベンチャー「Ambi Labs社」との協創で誕生した製品で、AIが搭載されており、IAQセンサーで検知する様々な環境情報とクラウド情報から、顧客が最も快適だと感じる環境をAIが自動で制御する。
データのパラメータは温度に限らず、湿度、照度、CO2、天気など。スマートフォンとも連携し、リモコンを使うことなくスマホによる遠隔操作も可能だ。なお、スマホによる遠隔操作に関しては、ダイキンは2013年から手がけていたという。
利用者視点に立った反復型開発手法を導入
続いては、上記のプラットフォーム、アプリなどのサービスが、どのような開発環境やプロセスによって生まれたのか。商品開発グループの主任技師である北村拓也氏が登壇し、課題や苦労、実際の開発体制、マネジメント、今後の展望などを紹介した。
▲空調生産本部 商品開発グループ 主任技師 北村 拓也氏
「ダイキンは機器メーカーのため、大規模なサービス開発のノウハウが乏しいという課題がありました。特に、クラウドやアプリに関する知見やノウハウは、経験不足が否めませんでした。そのため、サーバーレスアーキテクチャやモダンフロントエンドなどの最先端技術に、挑戦する必要がありました」（北村氏）
そこでまずは、メンバーを「アプリフロントエンド」「アプリバックエンド」「IoTプラットフォーム」「エッジデバイスのソフトウエア」「統合テスト」の5つのチームに分け、それぞれ10名を配置。合計50名、そこにPM2名が加わる体制とした。
統合テストチームを設けたのは、統合作業だけでも数カ月かかると予想されていたこと、また、利用者視点に立ち、Feature視点から開発を行いたいと考えたからだ。
開発に要する期間は、1年以上になる。サーバーレスアーキテクチャやモダンフロントエンドの知識を学びながら進めていくため、途中で何度も見直す状況に瀕することが想定された。そこで、一度決めたら変えずに進む従来のウォーターフォール型の開発ではなく、状況に応じて見直す柔軟なアジャイル型の開発体制とした。
具体的には、1カ月をひとつの期間と区切り、その期間をイテレーション、つまり反復していくことで、精度向上などさまざまな効果を狙った。北村氏が導入した開発体制を一言で説明すると、「フィーチャー単位の反復型開発手法」と言えるだろう。
イテレーションの期間内は、メンバーは作業に没頭してもらうようにした。北村氏は特に、利用者の視点から考えた機能や特徴を基準に、多くの作業や計画を進めていくフィーチャー視点を強調した。たとえば進捗に関しては、フィーチャーを詳細にタスク化し、具体的に日々のスケジュールに落としていった。
「情報の共有や連絡はチーム内では日々行い、チーム間では週一ペースとしました。イテレーションの開始・終了日は統一し、インテグレーションはイテレーション毎に行う。進捗状況の確認ではガントチャートやドキュメントでの確認ではなく、実際にソフトウエアが動いている状況を見て確認しました」（北村氏）
振り返りや計画の見直しにおいては、気合や根性といった定性的な指標ではなく、定量化したメトリクスなど、きちんとしたエビデンスのもと行った。
同フローで開発を進めると、初期開発機能のデグレードの確認が必要となった。回帰テストやE2Eである。しかし、メンバーには現状の作業に没頭してもらうため、できるだけ手動でのテストは排除した。コストをかけてでも、効率優先で自動化を進めたのだ。
北村氏は次のように今後の課題や展望を話し、セッションを締めた。
「現在は1カ月単位のイテレーションを、アジャイルスクラム開発のように、1週間単位で行いたいと考えています。イテレーションの期間が短ければ短いほど、市場の変化に素早く対応できる、フィーチャー単位の開発ができると考えているからです。
そういった意味では、メンバー一人ひとりが多能なスキルを持つように成長してほしいと考えています。実現すればチーム自体もより小さく、マクロな体制でまさにクイックに開発を進めていけるからです」（北村氏）
ダイキンにおけるDevOpsにおける課題と解決策
セッションの最後は前川博志氏が登壇し、グローバルプラットフォームに限らず、ダイキン全体におけるDevOpsについて解説した。
▲テクノロジー・イノベーションセンター 前川 博志氏
「開発初期は、すべての環境を自動化スクリプトを用いて構築していました。たとえば、コンポーネントのビルドやデプロイはJenkinsを活用し、スムーズに自動化されていました。ところが次第に、Jenkinsによるビルドの失敗率が高まり、手動に切り替えて行うなど、他のタスクに支障が出る状態に陥ったのです」（前川氏）
ビルド失敗の原因を調べてみると、Jenkins Jobが3桁を超えるまでの数に膨大していた。しかもそれぞれのJobが複雑に相関しており、設定が正しくないとビルド設定がうまくできないこともわかった。
しかし設定は手動かつ相応のスキルが必要なため、属人（職人）的なシステムとなっていた。つまり、自動化からは程遠い状況になっていたのである。
課題は他にもあった。Jenkins Jobとソフトウエアバージョンの不整合だ。開発が進むにつれ、異なるバージョンのシステムを同時にデプロイする必要が発生したが、想定が甘かったと前川氏は振り返る。
さらに、CIパイプラインの開発とソフトウエア開発が分離しており、課題が顕在化しなかった。パイプラインの設計を外部ベンダーに任せきりであったことも課題だったという。
「このような状況を改善しようと、壊れないことを第一に、まずはJobをシンプルな構成に変更。複数バージョンのビルドシステムが展開できるよう、Job上でパイプラインのバージョンも指定可能に改造しました。そしてこれらの改善作業は、内製メンバー主導のもと行いました」（前川氏）
状況は改善するが、開発が進むと再びJenkins Jobの構成は複雑化し、一部のメンバーしか扱えない状況が再来。さらに、本番で利用するリリーススクリプトとJenkins Jobが大きく乖離していたこともあり、本番のリリースではJenkinsを利用しないことに決めた。
現在は膨大で複雑な状態のJenkins Job郡そのままに、新規にJenkinsを立ち上げ、新たにJobを構築しDevOpsを進めている。
利用するツールは最小限に抑え、シンプルなプロセスに
前川氏はグローバルプラットフォームのDevOpsに携わった後、所属するテクノロジー・イノベーションセンター（TIC）で別のプロジェクトに参画した。当日は、他のプロジェクトにおけるDevOpsについても紹介した。
TICはいわゆるR＆Dであり、グローバルプラットフォームの開発はもちろん、機械、電気、化学など多様な領域での研究開発が日々行われている。
前川氏が携わったのは、東大発のベンチャー、フェアリーデバイセズとダイキンが協業して進めている「コネクティッドワーカーソリューション」のDevOps環境の構築だ。
先述したように、エアコンの取り付けには専門知識が必要だが、発展途上国では知識を持つ技術者が乏しい。とはいえ、日本の技術者を各地に派遣するリソースはない。
そこで、首掛け式の通信デバイス「THINKLET（シンクレット）」を通して、遠隔にいる日本の技術者が現地の様子をモニタリング。作業員に指示を出すことで、工事を行うという仕組みだ。
前川氏は先のグローバルプラットフォームでのDevOpsの課題を踏まえ、開発ツールは最小限に抑える環境を意識した。具体的には、これまではGitLab、Jenkins、AWS CodeBuild、AWS CloudFormationと4つのツールを使っていたが、GitLabとAWS CloudFormationの2つに絞った。
その結果、コード・デプロイ・成果物管理といった開発に関わる内容は、すべてGitLabを見れば分かるような環境を構築。バグなどのフィードバックが素早くまわるようになり、開発者自らが特に指示を受けなくても、自主的にトラブルに対処している好循環が生まれている。その他、テクノロジー・イノベーションセンターで気づいたDevOpsの勘所についても紹介してくれた。
最後に前川氏は、グローバルプラットフォームが今後進むべき開発の方向性についての持論を述べ、セッションを締めた。
「Linuxなどの巨大なOSSの開発方式や環境が、ダイキンがグローバルに開発を進めていく上での参考になると考えています。具体的には、重厚長大な伽藍（がらん）的な組織やチームではなく、小さなお店が並んでいるバザールのようなもの。まさに、エリック・レイモンド氏の著書『伽藍とバザール』に書かれている、オープンソフトウェアの開発方式です。
同方式であれば、ダイキンのように文化や考え方、データの規制レベルなどが異なる世界各地で開発を進めている環境でも、各部門が独自に業務を進めることなく、ひとつの大きな仕組みを作れることを証明しているからです」（前川氏）
【Q＆A】参加者から寄せられた質問を紹介
セッション後は、参加者から寄せられた質問に、登壇者たちが答えるQ&Aタイムが設けられた。
Q：空調機のIoT化のアイデアはいつ頃からか
橋本：業務用については25年前から、電話回線で行っていた歴史があります。一方、住宅用は、2011年ごろに、一人のエンジニアのアイデアから始まりました。
Q：エアコンのインターネット接続率と、その向上に向けた取り組みについて
佐藤：接続率は10％ほどです、向上に向けては設定方法をわかりやすくイラストで紹介するなどの工夫を行っています。
Q：空調機のIoT化の今後の展望について
橋本：すべてのデバイスをクラウドプラットフォームでつなぐことで新たな価値を創造し、お客様にいち早く届けたいと考えています。
前川：IoT化、ソフトウエアエンジニアリングという観点から考えると、GAFAが参入するのではとのレベル感があり、実際にテスラが参入するとの噂もあります。そのため研究部門としては、ハードウエアが優れているから勝てるわけではなくなってきていると考え、ソフトウエア化含めた総合的なサービスの開発を進めていかないといけないという危機感を常に持っています。
Q：Webやアプリ、クラウドの開発者50名もどのように集めたのか。また外注とのバランスはどうか
北村：実は、8割は外部のベンダーさんです。ただ主導は我々が担うよう意識して、各チームに必ず1人もしくは2人、自社のエンジニアを配置しています。
最近は自社の若手エンジニアがプログラミングを行うなど、開発の最前線で学んでもらっており、実際にスキルアップもしています。そのため1チーム内の自社メンバーが3～4人に増えてきましたし、いずれは内製化を果たしたいとも考えています。
Q：アジャイル開発など、ITのノウハウや人材はあったのか。また初期メンバーはどのように集めたのか
北村：当時ダイキンにアジャイルの経験はありませんでしたし、実施しようと思っている人材もいませんでした。しかし、先ほど紹介したように、従来のアプローチでは失敗することが分かっていたので、新たなスキームを構築した。それがたまたまアジャイルのプラクティスであった、ということです。
そのためアジャイルという言葉は使いませんでした。短いサイクルで切る、見直す、自動化といったキーワードを使いながらエンハンスすることを伝え、こっそり始めていったというのが実際のところです。
Q：アジャイル開発や自動テスト導入はトップダウンで進められたのか、ボトムアップか？
北村：実は取り組みはじめた当初は、管理職ではなく、いちメンバーでした。しかし肩書に関係なくメンバーの声に耳を傾けてくれる文化であったことが大きいと思いますが、やるんだったらこういう風にやらせてほしいという自分の意思を主張しているうちに、「じゃぁお前やってみろよ」みたいな感じで、割と軽いタッチで、いちメンバーだった僕に100人ぐらいのプロジェクトのプロジェクトマネジメントを任せてくれることになりました。
Q：AWSを選んだ理由は？
前川：当時、グローバル展開を考慮したら、AWSしかない状況だったかと思います。
北村：完全にサーバーレスアーキテクチャにしたかったこと。かつ、技術者の確保を考えた上でAWSに決めました。
Q：クラウドサービスを利用することでの苦労、解決方法は？
前川：クラウドはオンプレミスよりも信頼性が高いとのバイアスがあります。確かに高い傾向にはありますが、とはいえ、大規模にやっていると落ちることもあることを経験しました。
何回やってもデプロイできないとか、日本リージョンだったらできるのにフランクフルトリージョンだとできないとか。AWSに問い合わせてみると、バグだと。他のAWSアカウントで再びデプロイを行ったら、正常に動作しました（笑）。
このような経験から、DevOps的には作る範囲を大きくしすぎてしまうと壊す単位も大きくなってしまうので、それぞれを細かくコンポーネント化しておくことで、トラブルに対応できると学びました。
Q：仮説検証は地域を限定して行うのか、それともグローバルで全展開しているのか
佐藤：全展開はリスクがあるため、POCなどレベルにより変えています。
前川：運用も含め、全地域の状況を完全に把握しているわけではありません。そのため佐藤の言うとおり、リスクヘッジの観点から地域はもちろん、ユーザーも限定して行っています。
Q：データの取得ではなく、既存のIOTデバイスのアップデートは可能か
佐藤：エアコンのような組み込み機器でも、インターネットを介したバージョンアップは可能で、実際、機能追加などを実施しています。
ダイキン工業株式会社
https://www.daikin.co.jp/
ダイキン工業株式会社の採用情報
https://www.daikin.co.jp/recruit/
関連するイベント
