小さな課題意識から全社の「協創」へ──ダイキン工業はソフトウェア開発をどう変えてきたのか

【B-5】技術とともに進む、ダイキン工業のソフトウェア開発

　空調機器を中心にグローバルで事業を展開するダイキン工業。そのR&D部門では、AWSをはじめとする開発インフラの標準化、内製アジャイル開発チームの支援、技術情報を交換するコミュニティ運営などを通じて、ソフトウェア開発の基盤づくりを進めてきた。出発点は、AWSの設計指針が十分に整理されていない、開発環境をより効率よく管理したい、立ち上げたばかりのアジャイルチームをどう育てるかといった、現場の具体的な課題だった。これらの取り組みはやがて、リファレンスアーキテクチャやセキュリティ自動化、開発者コミュニティ、生成AI活用へと広がっていく。本稿では、ダイキン工業 テクノロジー・イノベーションセンター 主任技師の前川博志氏の講演をもとに、同社が「技術とともに」ソフトウェア開発を進めてきた歩みを紹介する。

　※本記事は講演時点（2025年9月）の情報をもとに構成しており、現在の取り組みと異なる場合があります。

大企業で「技術とともに進む」ために──取り組みの始まり

　ダイキン工業は1924年創業。2024年度の連結売上高は4兆7,523億円で、その92％を空調事業が占める。170カ国以上で事業を展開し、海外売上高比率は83％。従業員は10万人以上にのぼり、海外従業員比率も8割以上だ。

　日本では住宅用エアコンの印象が強いが、前川氏によれば、同社が強みとするのはビルなどに入る業務用空調だという。その中で、前川氏が所属するR&D部門は、AWSをはじめとする開発インフラの標準化やアジャイル開発チームの支援に取り組んできた。

　前川氏は、講演タイトルにある「技術とともに歩む」という言葉に、2つの意味を込めたと説明する。1つは、技術を獲得しながら、それに合わせて戦略を変えていくこと。もう1つは、最新技術を見極め、適切に取り入れていくことだ。前者は、AWS設計指針やアジャイルチーム支援のような小さな取り組みを、どう全社的な活動へ広げていくかという話であり、後者は生成AIのような変化の速い技術を、企業の開発現場にどう適用するかという話でもある。講演では、この2つの観点から、入社後に進めてきた取り組みが紹介された。

　前川氏が入社後、まず取り組んだのは3つのテーマだった。AWSの設計指針づくり、開発インフラの整備、そしてアジャイル内製開発の支援である。「これら3つの取り組みが、当初想定していたわけではありませんが、結果的に有機的に組み合わさっていき、現在は大きな開発コミュニティを作ったり、AIを開発に取り入れたりといった話につながっています」と前川氏は振り返る。

ダイキン工業株式会社 テクノロジー・イノベーションセンター 主任技師 前川博志氏

　AWSの設計指針づくりでは、社内に暗黙的な知見はあるが整理されていないという課題があった。WordやPowerPointで作成するとAWSの進化スピードについていけないため、「AsciiDoc」とGitHubを組み合わせたテキストベースの管理を選択した。AsciiDocを使えば、テキストで管理しながらWebやPDFなど複数の形式に出力できる。これにCI/CDパイプラインを組み込み、プルリクエスト（PR）単位でドキュメントのレビューをコードレビューと同じフローで実施できるようにした。「Reviewdog」や「textlint」によるスペルチェック・表記ゆれの自動検出、URLのステータスコード確認によるリンク切れ検知も組み込んだ。完成した設計指針はPDF換算で150ページを超える規模となった。

AWS指針、開発インフラ、アジャイル内製開発を起点に、取り組みはコミュニティ形成や生成AI活用へと広がった

　開発インフラの整備では、AWSの権限管理が課題だった。アカウントと人のアクセス権を一覧管理することが煩雑で、管理権限を広く渡しすぎるとセキュリティリスクが生じ、絞りすぎると申請対応が滞るというジレンマがある。

　これを解決するため、ユーザーや権限をYAMLファイルで記述できる独自の仕組みを開発した。Microsoft Formsからの申請を受けてGitHub上にIssueが立ち、YAMLを半自動編集し、GitHub ActionsがAWSにデプロイするフローにより、社内固有の予算番号バリデーションも自動化できた。GitHubにも同様のYAML管理を導入した。さらにGitHub AuditからPullやPushなどのユーザーアクティビティを取得し、24時間以内に特異な動きがあった場合にアラートを出す仕組みも構築している。

　アジャイル内製開発の支援では、立ち上げたばかりのチームにアジャイルコーチとして半年から1年伴走した。「教えたことは二つだけ」と前川氏は言う。「スクラムガイドをちゃんと読んで腹落ちしてやろう」と「内にこもらず、どんどん外に出ていこう」だ。

　その後、チームは開発に関心のあるメンバーを巻き込み、人数も倍以上になった。営業部門やサービス部門も関わるようになり、アジャイル開発を実践するチームとして広がっていった。チームトポロジーやダイナミックリチーミングなど組織論的な観点も取り入れ、状況に応じてチームを組み替えるようになっている。「Regional Scrum Gathering Tokyo」にも2年連続でメンバーが登壇するようになった。

周囲の巻き込み

　こうした取り組みは、やがて周囲を巻き込む段階へ進んでいく。その一つが、AWS設計指針をベースにしたリファレンスアーキテクチャの整備だ。150ページを超える設計指針をすべて読んでから使うのは難しい。そこで、IoTデータをS3に入れてMLOpsにつなげる構成など、具体的な用途に沿った「使える」アーキテクチャとして提供していった。

　セキュリティ面では、社内のセキュリティルールをAWS向けにアレンジしたチェックリストをIT部門と合意・作成し、AWS Config上で違反リソースを自動検知する仕組みを構築した。この仕組みはIaCの実装段階から検知できるため、セキュリティプロセスのシフトレフトにもつながる。検知結果はセキュリティダッシュボード「DIRECT」で可視化し、どのリソースがエラー対象になっているか、どのチェックリスト項目に該当するかを確認できるようにした。

AWS Configを用いた自動チェックにより、セキュリティ確認を開発プロセスの早い段階に組み込んだ

　コミュニティ形成も並行して進めた。「AWSガイドを配るから、質問がある人はここに来て」という形で立ち上げたAWSコミュニティは約200名規模に成長し、たとえば、前日の夕方に投稿された技術的な相談が、翌朝には解決していることもあったという。インフラにとどまらないシステム開発全般の知識共有を目的とした「システム開発倶楽部」も立ち上げ、アジャイル開発やTDD（テスト駆動開発）の講座、Wikiによる知識集約も実施した。